Hi Tudor, >>> This patch set introduces Microchip / Atmel ECC driver. >>> >>> The first patch adds some helpers that will be used by fallbacks to >>> kpp software implementations. >>> >>> The second patch adds ECDH support for the ATECC508A (I2C) >>> cryptographic engine. The I2C interface is designed to operate >>> at a maximum clock speed of 1MHz. >>> >>> The device features hardware acceleration for the NIST standard >>> P256 prime curve and supports the complete key life cycle from >>> private key generation to ECDH key agreement. >>> >>> Random private key generation is supported internally within >>> the device to ensure that the private key can never be known >>> outside of the device. If the user wants to use its own private >>> keys, the driver will fallback to the ecdh software implementation. >> can we get this testing with the Bluetooth SMP code? I would really like to see this being offloaded to hardware. For Bluetooth SMP we never really need the private key either. The end result is an symmetric 128-bit key for AES. And we throw the generated key pairs away. >> With the limitation of private is not available to Linux directly, we should make sure that KPP users that don’t require the private key are working properly and can utilize the offload. > > The driver was tested with testmgr, the offload worked. > > I've extended recently the ecdh software implementation with > ecc privkey generation support. I also added a kpp test in > testmgr to prove that it works correctly (see [1]). > > I will take a look at Bluetooth SMP code. you can test this without Bluetooth hardware, just need to make sure you have hci_vhci module available. And then from the BlueZ user space source code, you run ./tools/smp-tester (no need to install) to exercise the pairing with ECDH P-256. If you run ./monitor/btmon in a separate terminal, then it will show you the public keys exchanged. Regards Marcel
