Re: Support for ECDH P-192 and P-256

Marcel Holtmann [off-list ref] 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 [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt