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
