[openssl-dev] ECDH engine

Wed Jan 20 17:46:14 UTC 2016

> The ATECC508A is a chip. There are few USB devices built by Atmel on its base.
> Or you can use the chip directly over I2C (that many people like to do). You
> can follow the links that we posted on the ATECCX08 Engine repository WiKi to
> learn about the chip.

I see, thanks.

> Well, our first indent was to use the pksc11 library. But it didn't go to well
> for many reasons. I should go back for several months to collect these reasons
> but I think the main reason was that ATECC508A hardware is based on ECC-256
> algorithms while pkcs11 is originally written for RSA - the overhead was
> looking too high (many ATECC508 customers are using limited hardware and want
> direct I2C connection to the chip).

There are a few hardware tokens (USB-pluggable), e.g. Yubikey, that support
ECC256 and (in case of Yubikey 4) ECC384.

> But let's talk about pkcs11. Can you point me to the set of documentation for
> EC-DERIVE? It may be a good time now to add the ATECC508 support to there.

Honestly, I’m more interested in adding ECDH support – assuming that it
would also serve ATECC508, rather than working on ATECC508B and hoping that
perhaps it would be usable for other ECC-capable tokens.

Here’s the PKCS#11 spec
http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf,
which covers ECDH including ECDH1_DERIVE and ECDH1_COFACTOR_DERIVE. I think
older versions (like v2.20) have more content, but this is the current one.

Hope it helps.

P.S. At this time I’m standing by my original opinion – that a better way is
incorporating ECDH1_*DERIVE in libp11 and engine_pkcs11, rather than
creating an engine specifically for one chip that add uncertainly of
non-interoperability with other chips/tokens.

> On Jan 20, 2016, at 8:11 AM, Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu>
> wrote:
> 
>> What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it
>> accessible via PKCS#11 at all? Is it accessible by/via OpenSC?
>> 
>> I am trying to figure why such a generic and useful set of ECC operations
>> (Sign, Derive) is implementation-limited to one single <whatever>.
>> 
>> A much better solution to me would be adding EC-DERIVE to engine_pkcs11, and
>> automatically get all the tokens covered.
>> 
>> Since I'm probably‎ missing something, could you please educate me?
>> 
>> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
>> From: Alexander Gostrer‎
>> Sent: Wednesday, January 20, 2016 10:47
>> To: Dr. Stephen Henson
>> Reply To: openssl-dev at openssl.org
>> Cc: openssl-dev at openssl.org
>> Subject: Re: [openssl-dev] ECDH engine
>> ‎
>> Hi Steve,
>> ‎ 
>> And here is the ENGINE implementation for Atmel ATECC508A with few small
>> patches to OpenSSL_1_0_2-stable:
>> https://github.com/AtmelCSO/cryptoauth-openssl-engine
>> 
>> Your comments are welcome.
>> 
>> Regards,
>> Alex.
>> 
>> On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson <steve at openssl.org>
>> wrote:
>>> On Fri, Dec 18, 2015, Alexander Gostrer wrote:
>>> 
>>>> > Hi Steve,
>>>> >
>>>> > John and I completed writing an ECDH engine based on the
>>>> > OpenSSL_1_0_2-stable branch. We were planning to expand it to the master
>>>> > but found some major changes made by you recently. What is the status of
>>>> > this task? Is it stable enough to follow it? Are you planning another
>>>> > changes? Is there a design document that we can use in our work?
>>>> >
>>> 
>>> The version in master shouldn't change much any more. Documentation will be
>>> available in the near future. The changes were meant to remove some of the
>>> weird "quirks" of ECC compared to other algortihms and to permit future
>>> expansion to a wider range of curves.
>>> 
>>> In the meantime it shouldn't be too hard to follow how the new code works.
>>> Instead of separate ECDH/ECDSA methods with weird locking and ex_data and
>>> minimal ENGINE support everything is combined into a single EC_KEY_METHOD
>>> which can contain ECDSA, ECDH and key generation (something which was
>>> impossible with the old code) and be tied directly to an ENGINE.
>>> 
>>> Most of the primary APIs such as ECDH_compute_key can be redirected directly
>>> through an engine supplied function in EC_KEY_METHOD.
>>> 
>>> Having said that the code is very new and may have the odd bug that needs to
>>> be fixed. If you have any problems let me know and I'll look into them.
>>> 
>>> Steve.
>>> --
>>> Dr Stephen N. Henson. OpenSSL project core developer.
>>> Commercial tech support now available see: http://www.openssl.org
>> 
>> 
>>> _______________________________________________
>>> openssl-dev mailing list
>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160120/542111e1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4308 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160120/542111e1/attachment.bin>