Re: [PATCH 0/3] crypto: introduce Microchip / Atmel ECC driver

[Herbert Xu]

On Wed, Jul 05, 2017 at 01:07:57PM +0300, Tudor Ambarus wrote:
> Hi,
> 
> 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.
> 
> Tudor Ambarus (3):
>   crypto: kpp: add get/set_flags helpers
>   crypto: introduce Microchip / Atmel ECC driver
>   MAINTAINERS: add a maintainer for Microchip / Atmel ECC driver

All patches applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/3] crypto: introduce Microchip / Atmel ECC driver

[Marcel Holtmann]

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

Re: [PATCH 0/3] crypto: introduce Microchip / Atmel ECC driver

[Tudor Ambarus]

Hi, Marcel,

On 05.07.2017 13:54, Marcel Holtmann wrote:

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.

Thanks,
ta

[1] http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg25835.html

Re: [PATCH 0/3] crypto: introduce Microchip / Atmel ECC driver

[Marcel Holtmann]

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.

Regards

Marcel

[PATCH 0/3] crypto: introduce Microchip / Atmel ECC driver

[Tudor Ambarus]

Hi,

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.

Tudor Ambarus (3):
  crypto: kpp: add get/set_flags helpers
  crypto: introduce Microchip / Atmel ECC driver
  MAINTAINERS: add a maintainer for Microchip / Atmel ECC driver

 .../devicetree/bindings/crypto/atmel-crypto.txt|  13 +
 MAINTAINERS|   6 +
 drivers/crypto/Kconfig |  14 +
 drivers/crypto/Makefile|   1 +
 drivers/crypto/atmel-ecc.c | 781 +
 drivers/crypto/atmel-ecc.h | 128 
 include/crypto/kpp.h   |  10 +
 7 files changed, 953 insertions(+)
 create mode 100644 drivers/crypto/atmel-ecc.c
 create mode 100644 drivers/crypto/atmel-ecc.h

-- 
2.7.4