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.



Reply via email to