Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > Hello, > > we are looking at adding support for Bluetooth Secure Connections to the Security Manager of the Bluetooth subsystem. For that we would need support for ECDH P-256 and eventually also P-192. > > Right now we are bit lost on how this could be achieved best. I saw that the symmetric_keys feature has support for public_keys, but as far as I can tell that requires that userspace loads the public keys into the kernel and the private keys stay in userspace. > > What we need is to generate private/public key pairs using elliptic curve with P-192 and P-256. We only need the private/public key pair for the Bluetooth pairing. After successful pairing, we derive link keys or long term keys and we can throw the private/public key pair away. Any further authentication between Bluetooth devices is done via their link keys or long term keys. > > Has anybody looked into extending the kernel crypto framework to support ECDH P-192 and P-256. If nobody has, what are the best starting points to do so. Normally key exchange is conducted in user-space because it isn't performance-critical so as not to bloat the kernel. For example, only the data-path of IPsec is implemented in the kernel, while the key exchange protocol IKE Is done in user-space. That's why there is no current support for key exchange-related algorithms in the kernel crypto API. If there is agreement that Bluetooth's key exchange must be done in the kernel, then we certainly start adding these algorithms. I haven't been following this but is there a consensus from the networking folks regarding Bluetooth's key exchange code? Thanks, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
