Marcel Holtmann <mar...@holtmann.org> 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 <herb...@gondor.apana.org.au> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
