[openssl-dev] ECDH engine

Wed Jan 20 19:19:17 UTC 2016

Probably it was one of the main reasons why we didn't use pkcs11 for
ATECC508A and wrote an engine instead

Regards,
Alex.

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

> Are you saying it won't work on OpenSSL_1_0_2-stable?!
>
>
> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
> *From: *Douglas E Engert
> *Sent: *Wednesday, January 20, 2016 14:07
> *To: *openssl-dev at openssl.org
> *Reply To: *openssl-dev at openssl.org
> *Subject: *Re: [openssl-dev] ECDH engine
>
> Patches are underdevelopment for OpenSC's libp11 and engine_pkcs11 to
> support ECDH. There are waiting for OpenSSL-1.1 to be come stable
> and some minor bug  fixes. Testing is proceeding using OpenSSL-1.1-pre2
> today.  OpenSSL-1.1 is needed because it exposes the functions needed
> to use ECDH from an external engine i.e.  the OPenSC engine_pkcs11.
> ‎
>   https://github.com/OpenSC/libp11/issues/52
>   https://github.com/dengert/libp11/tree/prep-openssl-1.1
>   https://github.com/dengert/engine_pkcs11/tree/prep-openssl-1.1
>
> In addition to a major rewrite of combining the ECDSA_METHOD and
> ECDH_METHOD into an C_KEY_METHOD, OpenSSL-1.1  introduces a lot of changes,
> mainly because it hides many of the structures that have been exposed in
> the past. This causes a major rewrite of code to use functions to access
> these structures.
>
> Although OpenSC could still use an older version of OpenSSL, there is also
> underway changes for OpenSC to use OpenSSL-1.1:
> https://github.com/OpenSC/OpenSC/pull/654
> https://github.com/dengert/OpenSC/tree/prep-openssl-1.1
>
>
> On 1/20/2016 12:02 PM, Blumenthal, Uri - 0553 - MITLL wrote:
>
> I forgot to add that ‎OpenSSL-1_0-2-stable with the current (Github
> master) engine-pkcs11, libp11, and OpenSC successfully does ECDSA with keys
> on the token (tested for ECC256 and ECC384).
>
> OpenSC tools successfully derive (i.e., implement ECDH1_DERIVE). I'm
> waiting for libp11 and engine_pkcs11 to add this capability.
> ‎
> Ideally this is where your code would plug in, and complete the circle.
>
> As it currently is, a separate Atmel-specific ECC-specific engine is of a
> limited usefulness.
>
>
> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
> *From: *Blumenthal, Uri - 0553 - MITLL
> *Sent: *Wednesday, January 20, 2016 12:46
> *To: *openssl-dev at openssl.org
> *Reply To: *openssl-dev at openssl.org
> *Subject: *Re: [openssl-dev] ECDH engine
>
> 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>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
>
>
> --
>
>  Douglas E. Engert  <DEEngert at gmail.com> <DEEngert at gmail.com>
>
>
>
> _______________________________________________
> 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/20f50803/attachment-0001.html>