[openssl-dev] ECDH engine

Wed Jan 20 19:17:09 UTC 2016

On Wed, Jan 20, 2016 at 9:46 AM, Blumenthal, Uri - 0553 - MITLL <
uri at ll.mit.edu> wrote:

> 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.
>

Direct link: https://github.com/AtmelCSO/cryptoauth-openssl-engine/wiki

>
> 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.
>
Thanks

>
> 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.
>

Check our patches here:
https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches.
It is non-official openssl patches and probably will never go into but they
are enabling ECDH enginee in stable-1.0.2. Limited use of course.

>
> 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.
>

I see your point. We'll look into it
Thank you,
Alex.

>
>
> 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
>
>
> _______________________________________________
> 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/8dc3b6ec/attachment.html>