Re: [OpenSC] Enhanced ECC handling (#191)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSC] Enhanced ECC handling (#191)

Douglas E. Engert
Toni, Viktor, we need your comments on this...

On 10/31/2013 11:27 AM, CardContact Software & System Consulting wrote:
> So why does the old sc_pkcs_encode_pubkey_ec() [1] then take
> key->ecpointQ.value and put it into an OCTET STRING TLV object ?


Good question. In Up until 11 months ago the code looked like the original code:

>  549 int sc_pkcs15_encode_pubkey_ec(sc_context_t *ctx,
>  550                 struct sc_pkcs15_pubkey_ec *key,
>  551                 u8 **buf, size_t *buflen)
>  552 {
>  553         *buf = malloc(key->ecpointQ.len);
>  554         if (*buf == NULL)
>  555                 return SC_ERROR_OUT_OF_MEMORY;
>  556
>  557         memcpy(*buf, key->ecpointQ.value, key->ecpointQ.len);
>  558         *buflen = key->ecpointQ.len;
>  559
>  560         sc_debug(ctx, SC_LOG_DEBUG_NORMAL,"DEE-EC key->ecpointQ=%p:%d *buf=%p:%d",
>  561                 key->ecpointQ.value, key->ecpointQ.len, *buf, *buflen);
>  562
>  563         return 0;
>  564 }
>  565

Which just copied the ASN1 DER version, as it was already encoded.

BUT

"MyEID ECDSA support" Commit 457426543dfa02597895d57013dde94cc9e7d038
  by Toni Sjöblom commited by Viltor modified the code.

There is a lot of EC code in this commit, and I suspect that in some routines,
the ecpointQ is stored as 04||X|Y, but in others it is stored as DER OCTET STRING
as the comments in pkcs15.h say it should be.

The PIV code continued to work as expected.

What maybe happening the myEID card treat the string as raw
but the PIV treats it as ASN1 DER OCTET STRING

Both cards may work as they may use different code paths,

But now that you are trying to work with the card-sc-hsm, things don't work
and you may be calling some routines that expect ASN1, and other as raw.

We need to get the code consistent across all card.

Toni, can you comment...











IN the change, there is a comment:

CardContact  9 months ago
This changes breaks existing code, as before ecpointQ.value already contained the EC public key as OCTET STRING !



>
> That step would be useless if key->ecpointQ already contained the DER
> encoded value.
>
> [1]
> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-pubkey.c#L646
>
>
> Am 31.10.2013 17:10, schrieb Doug Engert:
>  >
>  >
>  > On 10/30/2013 2:25 PM, CardContact Software & System Consulting wrote:
>  >> I guess I know understand where the confusion comes from: In the old code ecpointQ was used to store the point in the X9.62 octet string format (04||X||Y).
>  >
>  > Looking closer at the code, The original EC code was added by me on Nov, 30, 2010 c34cadeb...f198da
>  >
>  > The ecpoint has always been stored as an ANS1 DER encoded string. For a 256 this would be
>  > (0x04,0x41,0x04,X,Y) and for a 384 it would be (0x04,0x61,0x04,X,Y) with the first 0x04 being the
>  > ASN1 OCTET STRING tag, and the second 0x04 being EC uncompressed format.
>  >
>  > Only uncompressed formats are currently supported by OpenSC, as some of the code gets the field_length
>  > from the size of the decoded data. 0x41 = 65 = (256/8 * 2) + 1 and 0x61 = (384/8 *2) + 1
>  >
>  >
>  > Now that has changed to a DER encoded OCTET
>  >> STRING (04 || L04 || 04||X||Y), so that pksc15_encode_pubkey_ec() has nothing more to do - it just takes the already encoded public key.
>  >>
>  >> However I think that change in the encoding format is wrong (and the documentation at sc_pkcs15_pubkey_ec/sc_pkcs15_prikey_ec /* note this is der */ is misleading).
>  >>
>  >> sc_pksc15_pubkey_ec should store a key value in it purest form, that being the octet string (lower letters!) format from X9.62 (i.e. 04||X||Y). pkcs15_encode_pubkey_ec() should then take care of
>  >> encoding that key into either an ECPoint oder SPKI DER encoding.
>  >
>  > The point could be stored in the 04||X||Y, and encoded in DER as needed. I would like to here from others on this list.
>  >
>  > Note: (04||X||Y) is not ASN1 DER. PKCS#11 says the CKA_EC_POINT is a byte array DER-encoding of X9.62 ECPoint value P
>  > I believe the code with the last patch is consistent.
>  >
>  > Some of the test with the previous OpenSC code has been to use NIST developed change to Mozilla NSS with the OpenSC
>  > PKCS#11 to sign e-mail using ECDSA.
>  >
>  >>
>  >> —
>  >> Reply to this email directly or view it on GitHub <https://github.com/OpenSC/OpenSC/pull/191#issuecomment-27430538>.
>  >>
>  >
>
>
> --
>
> --------- CardContact Software & System Consulting
> |.##> <##.| Andreas Schwier
> |# #| Schülerweg 38
> |# #| 32429 Minden, Germany
> |'##> <##'| Phone +49 571 56149
> --------- http://www.cardcontact.de
> http://www.tscons.de
> http://www.openscdp.org
>
> —
> Reply to this email directly or view it on GitHub <https://github.com/OpenSC/OpenSC/pull/191#issuecomment-27501340>.
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel