Format of extracted ECC public keys

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Format of extracted ECC public keys

Philip Wendland
Hello everyone,

Sorry, this is going to be a long E-Mail..
I'm writing a Java Card applet targeting newer cards together with an
OpenSC driver (including read/write support).

I am trying for some time now to get ECC working. The problem is the
storing and/or extracting of the EC public key. As I discovered, the
extracted (.pem) file neither contains any curve name/identifier nor any
explicit parameters. OpenSSL can't read the extracted keys because of
this. If I decode the .pem's base64 to hex, add the curve identifier as
it is done when generating public keys with OpenSSL and encode to base64
again, OpenSSL is able to read the key and I can verify signatures
generated by the applet.

I'm using "standard means" to store the key in the pkcs15-generate_key
function (i.e. no PKCS#15 emulation and no read_publc_key from
sc_card_operations or encode_public_key from sc_pkcs15init_operations).
The curve name and OID, and also the parameters are available when
exiting generate_key. Using gdb I realised that
sc_pkcs15init_store_public_key (pkcs15-lib.c:1475) stores the data
returned by sc_pkcs15_encode_pubkey ("DER encoded public key
components") in the EF containing the public key. This function,
however, only stores the ecpointQ. I'm not quite sure how OpenSC is
supposed to get any information about the curve when extracting the
public key from the filesystem. I guess I could circumvent this by using
card->ops->read_publc_key and encode_public_key, however, I think this
might be a problem with OpenSC itself.

Is there any card (driver) without PKCS#15-emulation and
card->ops->read_publc_key that is known to extract working ECC keys?


As [1] states (section 6.4.3) there is a CHOICE between RAW ecPointQ
encoding (used by OpenSC) and SPKI for the public key in the EF. Here is
the SPKI extract [2]:

SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm         AlgorithmIdentifier,
        subjectPublicKey  BIT STRING
      }

with the algorithm identifier:

AlgorithmIdentifier  ::=  SEQUENCE  {
         algorithm   OBJECT IDENTIFIER,
         parameters  ANY DEFINED BY algorithm OPTIONAL
       }

I.e. at least the algorithm identifier must be saved using SPKI. This
encoding would solve the problem (One could use
sc_pkcs15_fix_ec_parameters() after reading the OID from the file to
populate the pubkey->u.ec.params). (However, changing the encoding could
break certain existing drivers?)

I also want to refer to a TODO mark at pkcs15-pubkey.c:819
(sc_pkcs15_encode_pubkey_as_spki). The data returned by this function is
the content of the .pem file later, as I understand it. The TODO says:
/* TODO make sure algorithm params are available*/
/* if not can we copy them from the u.ec. */
This is, of course, part of the problem. BUT gdb shows the u.ec. is not
populated. I guess this has to do with the encoding of the public key
file described earlier.


So...
1) Do you agree that the EF(public key) needs to contain at least the
curve name? Or is the information available elsewhere?
2) I'd be happy to make sure that at least the curve OID is part of the
SPKI encoding (TODO mark) and make a pull request later. However, I am
not sure where to get that information about the curve from.
3) Or am I totally wrong and should rather use card->ops->read_publc_key
or pkcs15 encode_public_key / store_key  because OpenSC is correct?


You can view the OpenSC driver at (allthough I think it's not necessary
to understand the problem):
https://github.com/philipWendland/OpenSC
The Applet:
https://github.com/philipWendland/IsoApplet


Thank you for your time and answer!

Philip


[1] PKCS#15, v1.1: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-15/pkcs15v1.pdf
[2] http://tools.ietf.org/html/rfc5480

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Format of extracted ECC public keys

Douglas E Engert


On 9/22/2014 7:53 AM, Philip Wendland wrote:

> Hello everyone,
>
> Sorry, this is going to be a long E-Mail..
> I'm writing a Java Card applet targeting newer cards together with an
> OpenSC driver (including read/write support).
>
> I am trying for some time now to get ECC working. The problem is the
> storing and/or extracting of the EC public key. As I discovered, the
> extracted (.pem) file neither contains any curve name/identifier nor any
> explicit parameters.

Right now OpenSC only works with curve names.

> OpenSSL can't read the extracted keys because of
> this. If I decode the .pem's base64 to hex, add the curve identifier as
> it is done when generating public keys with OpenSSL and encode to base64
> again, OpenSSL is able to read the key and I can verify signatures
> generated by the applet.
>
> I'm using "standard means" to store the key in the pkcs15-generate_key
> function (i.e. no PKCS#15 emulation and no read_publc_key from
> sc_card_operations or encode_public_key from sc_pkcs15init_operations).

pkcs-15v1_1.pdf
6.4.3 Public Elliptic Curve key objects


> The curve name and OID, and also the parameters are available when
> exiting generate_key. Using gdb I realised that
> sc_pkcs15init_store_public_key (pkcs15-lib.c:1475) stores the data
> returned by sc_pkcs15_encode_pubkey ("DER encoded public key
> components") in the EF containing the public key. This function,
> however, only stores the ecpointQ.

This may be a bug. There was a lot of work in this area last year to add
the SPKI choice, to avoid having to look at the Parameters in:
  keyInfo KeyInfo {Parameters, PublicKeyOperations} OPTIONAL,

The problem comes from PKCS#15 referring to public key as ECPublicKeyChoice
without parameters, where as OpenSC and PKCS#11 refers to a public key with
the parameters. The use of the SPKI stores the parameter with the ecpointQ.

> I'm not quite sure how OpenSC is
> supposed to get any information about the curve when extracting the
> public key from the filesystem.

It should be using 6.3.4, and either use the SPKI, or the RAW + Parameters.

Note last line says:
"The field is not needed if the information is available through other means."

> I guess I could circumvent this by using
> card->ops->read_publc_key and encode_public_key, however, I think this
> might be a problem with OpenSC itself.

Yes some OpenSC code was storing EC parameters in 2 places, And you may have
hit upon a problen when writing the key or reading the key. Thus the need for the
sc_pkcs15_fix_ec_parameters

>
> Is there any card (driver) without PKCS#15-emulation and
> card->ops->read_publc_key that is known to extract working ECC keys?

I believe the CardContact SmartCard-HSM may be doing this.
(I use the PIV card that is using emulation and only 2 curves and would not
use the routines in question.)

>
>
> As [1] states (section 6.4.3) there is a CHOICE between RAW ecPointQ
> encoding (used by OpenSC) and SPKI for the public key in the EF. Here is
> the SPKI extract [2]:
>
> SubjectPublicKeyInfo  ::=  SEQUENCE  {
>          algorithm         AlgorithmIdentifier,
>          subjectPublicKey  BIT STRING
>        }
>
> with the algorithm identifier:
>
> AlgorithmIdentifier  ::=  SEQUENCE  {
>           algorithm   OBJECT IDENTIFIER,
>           parameters  ANY DEFINED BY algorithm OPTIONAL
>         }
>
> I.e. at least the algorithm identifier must be saved using SPKI. This
> encoding would solve the problem (One could use
> sc_pkcs15_fix_ec_parameters() after reading the OID from the file to
> populate the pubkey->u.ec.params). (However, changing the encoding could
> break certain existing drivers?)

Probably not, if the Parameters are available, they should be written
to the EF.

>
> I also want to refer to a TODO mark at pkcs15-pubkey.c:819
> (sc_pkcs15_encode_pubkey_as_spki). The data returned by this function is
> the content of the .pem file later, as I understand it. The TODO says:
> /* TODO make sure algorithm params are available*/
> /* if not can we copy them from the u.ec. */

No one had as card to test this when the comment was added.


> This is, of course, part of the problem. BUT gdb shows the u.ec. is not
> populated. I guess this has to do with the encoding of the public key
> file described earlier.

Sounds like the bug. How did you create the key and write it to the EF?
Did it include the Parameters?

I believe that if you chose to write out the SPKI, then every thing would work,
but then again if you are using an existing card written by some other software
using RAW, the read should process the Parameters to get the curve.


>
>
> So...
> 1) Do you agree that the EF(public key) needs to contain at least the
> curve name? Or is the information available elsewhere?


PKCS#15 says: "The field is not needed if the information is available
through other means."  Ithink this was a compromise at the time of writting...

The Curve name could be found in a matching certificate, or the application
has to provide the curve. Early IETF RFC had some issues with this as well,
I believe all the current RFC require the curve name to be in the SPKI.

> 2) I'd be happy to make sure that at least the curve OID is part of the
> SPKI encoding (TODO mark) and make a pull request later. However, I am
> not sure where to get that information about the curve from.

Did you write the key to the card?
If so was the curve available when you write it?
In that case it should have been written as a Parameter or in the SPKI.
If not then there is not much that can be done.


DO you have an opensc debug log or gdb output showing the EF as writtne
or read from the card?

> 3) Or am I totally wrong and should rather use card->ops->read_publc_key
> or pkcs15 encode_public_key / store_key  because OpenSC is correct?
>

Open SC may have some problems in this area, as the routines in question
were not needed by any of the current drivers.


>
> You can view the OpenSC driver at (allthough I think it's not necessary
> to understand the problem):
> https://github.com/philipWendland/OpenSC
> The Applet:
> https://github.com/philipWendland/IsoApplet
>
>
> Thank you for your time and answer!
>
> Philip
>
>
> [1] PKCS#15, v1.1: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-15/pkcs15v1.pdf
> [2] http://tools.ietf.org/html/rfc5480
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Format of extracted ECC public keys

Douglas E Engert
In reply to this post by Philip Wendland
P.S. Can you get your repository up to dat with OpenSC/OpenSC
It would help to see what are your changes.

On 9/22/2014 7:53 AM, Philip Wendland wrote:

> Hello everyone,
>
> Sorry, this is going to be a long E-Mail..
> I'm writing a Java Card applet targeting newer cards together with an
> OpenSC driver (including read/write support).
>
> I am trying for some time now to get ECC working. The problem is the
> storing and/or extracting of the EC public key. As I discovered, the
> extracted (.pem) file neither contains any curve name/identifier nor any
> explicit parameters. OpenSSL can't read the extracted keys because of
> this. If I decode the .pem's base64 to hex, add the curve identifier as
> it is done when generating public keys with OpenSSL and encode to base64
> again, OpenSSL is able to read the key and I can verify signatures
> generated by the applet.
>
> I'm using "standard means" to store the key in the pkcs15-generate_key
> function (i.e. no PKCS#15 emulation and no read_publc_key from
> sc_card_operations or encode_public_key from sc_pkcs15init_operations).
> The curve name and OID, and also the parameters are available when
> exiting generate_key. Using gdb I realised that
> sc_pkcs15init_store_public_key (pkcs15-lib.c:1475) stores the data
> returned by sc_pkcs15_encode_pubkey ("DER encoded public key
> components") in the EF containing the public key. This function,
> however, only stores the ecpointQ. I'm not quite sure how OpenSC is
> supposed to get any information about the curve when extracting the
> public key from the filesystem. I guess I could circumvent this by using
> card->ops->read_publc_key and encode_public_key, however, I think this
> might be a problem with OpenSC itself.
>
> Is there any card (driver) without PKCS#15-emulation and
> card->ops->read_publc_key that is known to extract working ECC keys?
>
>
> As [1] states (section 6.4.3) there is a CHOICE between RAW ecPointQ
> encoding (used by OpenSC) and SPKI for the public key in the EF. Here is
> the SPKI extract [2]:
>
> SubjectPublicKeyInfo  ::=  SEQUENCE  {
>          algorithm         AlgorithmIdentifier,
>          subjectPublicKey  BIT STRING
>        }
>
> with the algorithm identifier:
>
> AlgorithmIdentifier  ::=  SEQUENCE  {
>           algorithm   OBJECT IDENTIFIER,
>           parameters  ANY DEFINED BY algorithm OPTIONAL
>         }
>
> I.e. at least the algorithm identifier must be saved using SPKI. This
> encoding would solve the problem (One could use
> sc_pkcs15_fix_ec_parameters() after reading the OID from the file to
> populate the pubkey->u.ec.params). (However, changing the encoding could
> break certain existing drivers?)
>
> I also want to refer to a TODO mark at pkcs15-pubkey.c:819
> (sc_pkcs15_encode_pubkey_as_spki). The data returned by this function is
> the content of the .pem file later, as I understand it. The TODO says:
> /* TODO make sure algorithm params are available*/
> /* if not can we copy them from the u.ec. */
> This is, of course, part of the problem. BUT gdb shows the u.ec. is not
> populated. I guess this has to do with the encoding of the public key
> file described earlier.
>
>
> So...
> 1) Do you agree that the EF(public key) needs to contain at least the
> curve name? Or is the information available elsewhere?
> 2) I'd be happy to make sure that at least the curve OID is part of the
> SPKI encoding (TODO mark) and make a pull request later. However, I am
> not sure where to get that information about the curve from.
> 3) Or am I totally wrong and should rather use card->ops->read_publc_key
> or pkcs15 encode_public_key / store_key  because OpenSC is correct?
>
>
> You can view the OpenSC driver at (allthough I think it's not necessary
> to understand the problem):
> https://github.com/philipWendland/OpenSC
> The Applet:
> https://github.com/philipWendland/IsoApplet
>
>
> Thank you for your time and answer!
>
> Philip
>
>
> [1] PKCS#15, v1.1: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-15/pkcs15v1.pdf
> [2] http://tools.ietf.org/html/rfc5480
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Format of extracted ECC public keys

Philip Wendland
 > P.S. Can you get your repository up to dat with OpenSC/OpenSC
 > It would help to see what are your changes.

Thanks for your answer. I updated my repo after writing the first
E-Mail, I think you were quicker than me :-)

 > It should be using 6.3.4, and either use the SPKI, or the RAW +
 > Parameters.

I agree.

 > I believe the CardContact SmartCard-HSM may be doing this.
 > (I use the PIV card that is using emulation and only 2 curves and
would not
 > use the routines in question.)
 >

I've had a quick look at this. Seeing
sc_pkcs15emu_sc_hsm_get_public_key() and some other functions I have
some doubts. But I don't fully understand what is happening there :-)

 >> This is, of course, part of the problem. BUT gdb shows the u.ec. is not
 >> populated. I guess this has to do with the encoding of the public key
 >> file described earlier.
 >
 > Sounds like the bug. How did you create the key and write it to the EF?
 > Did it include the Parameters?

The key is generated on-card. The answer of the smartcard contains the
public key. This is used to fill in the pubkey before exiting generate_key.
This is what is available when exiting isoApplet_generate_key
(pkcs15-isoApplet.c):

(gdb) p pubkey->u.ec.params.named_curve
$3 = 0x62bec0 "prime256v1"
(gdb) p pubkey->u.ec.params.id
$4 = {value = {1, 2, 840, 10045, 3, 1, 7, -1, -1, -1, -1, -1, -1, -1,
-1, -1}}
(gdb) p pubkey->u.ec.params.der
$5 = {value = 0x62bea0 "\006\b*\206H\316=\003\001\a\377\366\377\177",
len = 10}
(gdb) p pubkey->u.ec.params.field_length
$6 = 256
(gdb)

After I exit this function, it is out of my hands. It returns to
pkcs15-lib.c:1327.
This later calls sc_pkcs15init_store_public_key. This is where the
public key is being stored in the EF.

After looking at this I found something that looks weird to me:
(pkcs15-lib.c:1571)

/* DER encode public key components */
        r = sc_pkcs15_encode_pubkey(p15card->card->ctx, &key,
&object->content.value, &object->content.len);
        LOG_TEST_RET(ctx, r, "Encode public key error");

        r = sc_pkcs15_encode_pubkey(p15card->card->ctx, &key,
&key_info->direct.raw.value, &key_info->direct.raw.len);
        LOG_TEST_RET(ctx, r, "RAW encode public key error");

        /* EC key are encoded as SPKI to preserve domain parameter */
        r = sc_pkcs15_encode_pubkey_as_spki(p15card->card->ctx, &key,
&key_info->direct.spki.value, &key_info->direct.spki.len);
        LOG_TEST_RET(ctx, r, "SPKI encode public key error");

        /* Now create key file and store key */
        r = sc_pkcs15init_store_data(p15card, profile, object,
&object->content, &key_info->path);

The SPKI encoding for EC keys is written to key_info (which is
object->data).
But the object->content, a seperate field containing only the ecPointQ
encoded by sc_pkcs15_encode_pubkey() is being written to the EF:

0x7ffff7fca700 18:47:04.021 [pkcs15-init] apdu.c:185:sc_apdu_log:
Outgoing APDU data [   72 bytes] =====================================
00 D6 00 00 43 04 41 04 C1 36 E2 CC 7C 1C 3D F3 ....C.A..6..|.=.
6C 5E 29 C0 31 45 75 54 24 55 D2 85 8E 46 B4 AB l^).1EuT$U...F..
3A 3B DB 18 16 67 16 55 A4 B9 72 F0 76 CF ED 5A :;...g.U..r.v..Z
08 04 AA F5 46 11 91 90 66 90 C8 B9 CD 67 F2 ED ....F...f....g..
86 A7 81 0D A5 18 1E 6E                         .......n
======================================================================
0x7ffff7fca700 18:47:04.022 [pkcs15-init]
reader-pcsc.c:182:pcsc_internal_transmit: called
0x7ffff7fca700 18:47:04.044 [pkcs15-init] apdu.c:185:sc_apdu_log:
Incoming APDU data [    2 bytes] =====================================
90 00 ..
======================================================================

I think that at this point the SPKI should be written to the EF. Or as
you said, at RAW + Parameters (at least curve name).

 >
 > I believe that if you chose to write out the SPKI, then every thing
would work,
 > but then again if you are using an existing card written by some
other software
 > using RAW, the read should process the Parameters to get the curve.
 >

This would address my concern with breaking things.

However, only RAW + Parameters would also solve my problem. RAW without
Parameters is causing my issues.

 >>
 >> So...
 >> 1) Do you agree that the EF(public key) needs to contain at least the
 >> curve name? Or is the information available elsewhere?
 >
 >
 > PKCS#15 says: "The field is not needed if the information is available
 > through other means."  Ithink this was a compromise at the time of
writting...
 >
 > The Curve name could be found in a matching certificate, or the
application
 > has to provide the curve. Early IETF RFC had some issues with this as
well,
 > I believe all the current RFC require the curve name to be in the SPKI.
 >

Thanks for the hint. In my case, I unfortunately don't see any other
means of obtaining the curve name right now.

Which application do you mean when writing "the application has to
provide the curve"?

 >
 > Did you write the key to the card?
 > If so was the curve available when you write it?
 > In that case it should have been written as a Parameter or in the SPKI.
 > If not then there is not much that can be done.
 >
 >
 > DO you have an opensc debug log or gdb output showing the EF as writtne
 > or read from the card?

See above.


Thanks and best regards,

Philip

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Format of extracted ECC public keys

Douglas E Engert


On 9/22/2014 1:03 PM, Philip Wendland wrote:

>   > P.S. Can you get your repository up to dat with OpenSC/OpenSC
>   > It would help to see what are your changes.
>
> Thanks for your answer. I updated my repo after writing the first
> E-Mail, I think you were quicker than me :-)
>
>   > It should be using 6.3.4, and either use the SPKI, or the RAW +
>   > Parameters.
>
> I agree.
>
>   > I believe the CardContact SmartCard-HSM may be doing this.
>   > (I use the PIV card that is using emulation and only 2 curves and
> would not
>   > use the routines in question.)
>   >
>
> I've had a quick look at this. Seeing
> sc_pkcs15emu_sc_hsm_get_public_key() and some other functions I have
> some doubts. But I don't fully understand what is happening there :-)
>
>   >> This is, of course, part of the problem. BUT gdb shows the u.ec. is not
>   >> populated. I guess this has to do with the encoding of the public key
>   >> file described earlier.
>   >
>   > Sounds like the bug. How did you create the key and write it to the EF?
>   > Did it include the Parameters?
>
> The key is generated on-card. The answer of the smartcard contains the
> public key. This is used to fill in the pubkey before exiting generate_key.
> This is what is available when exiting isoApplet_generate_key
> (pkcs15-isoApplet.c):
>
> (gdb) p pubkey->u.ec.params.named_curve
> $3 = 0x62bec0 "prime256v1"
> (gdb) p pubkey->u.ec.params.id
> $4 = {value = {1, 2, 840, 10045, 3, 1, 7, -1, -1, -1, -1, -1, -1, -1,
> -1, -1}}
> (gdb) p pubkey->u.ec.params.der
> $5 = {value = 0x62bea0 "\006\b*\206H\316=\003\001\a\377\366\377\177",
> len = 10}
> (gdb) p pubkey->u.ec.params.field_length
> $6 = 256
> (gdb)
>

In pkcs15-lib.c:

What is passed to:
1261 sc_pkcs15init_generate_key(struct sc_pkcs15_card *p15card, struct sc_profile *profile,
1262                 struct sc_pkcs15init_keygen_args *keygen_args, unsigned int keybits,
1263                 struct sc_pkcs15_object **res_obj)

especially keygen_args.


1323         else if (keygen_args->prkey_args.key.algorithm == SC_ALGORITHM_EC)
1324                 pubkey_args.params.ec = keygen_args->prkey_args.params.ec;
1325
1326         /* Generate the private key on card */

Could line 1324 be setting the wrong values?
What is in keygen_args->prkey_args.params.ec
This should have the curve.

THIS MAY BE THE PROBLEM, you did not set the curve in the keygen_args->prkey_args.params.ec.

Since you only support 2 curves, and each has a different algorithm_ref
ISOAPPLET_ALG_REF_EC_GEN_BRAINPOOLP192R1 or ISOAPPLET_ALG_REF_EC_GEN_PRIME256V1
you are in effect passing the curve to the card, where as in a more general
situation the curve would be passed in the generate key.



> After I exit this function, it is out of my hands. It returns to
> pkcs15-lib.c:1327.
> This later calls sc_pkcs15init_store_public_key. This is where the
> public key is being stored in the EF.
>
> After looking at this I found something that looks weird to me:
> (pkcs15-lib.c:1571)
>
> /* DER encode public key components */
> r = sc_pkcs15_encode_pubkey(p15card->card->ctx, &key,
> &object->content.value, &object->content.len);
> LOG_TEST_RET(ctx, r, "Encode public key error");
>
> r = sc_pkcs15_encode_pubkey(p15card->card->ctx, &key,
> &key_info->direct.raw.value, &key_info->direct.raw.len);
> LOG_TEST_RET(ctx, r, "RAW encode public key error");
>
> /* EC key are encoded as SPKI to preserve domain parameter */
> r = sc_pkcs15_encode_pubkey_as_spki(p15card->card->ctx, &key,
> &key_info->direct.spki.value, &key_info->direct.spki.len);
> LOG_TEST_RET(ctx, r, "SPKI encode public key error");
>
> /* Now create key file and store key */
> r = sc_pkcs15init_store_data(p15card, profile, object,
> &object->content, &key_info->path);
>
> The SPKI encoding for EC keys is written to key_info (which is
> object->data).
> But the object->content, a seperate field containing only the ecPointQ
> encoded by sc_pkcs15_encode_pubkey() is being written to the EF:
>
> 0x7ffff7fca700 18:47:04.021 [pkcs15-init] apdu.c:185:sc_apdu_log:
> Outgoing APDU data [   72 bytes] =====================================
> 00 D6 00 00 43 04 41 04 C1 36 E2 CC 7C 1C 3D F3 ....C.A..6..|.=.
> 6C 5E 29 C0 31 45 75 54 24 55 D2 85 8E 46 B4 AB l^).1EuT$U...F..
> 3A 3B DB 18 16 67 16 55 A4 B9 72 F0 76 CF ED 5A :;...g.U..r.v..Z
> 08 04 AA F5 46 11 91 90 66 90 C8 B9 CD 67 F2 ED ....F...f....g..
> 86 A7 81 0D A5 18 1E 6E                         .......n
> ======================================================================
> 0x7ffff7fca700 18:47:04.022 [pkcs15-init]
> reader-pcsc.c:182:pcsc_internal_transmit: called
> 0x7ffff7fca700 18:47:04.044 [pkcs15-init] apdu.c:185:sc_apdu_log:
> Incoming APDU data [    2 bytes] =====================================
> 90 00 ..
> ======================================================================
>
> I think that at this point the SPKI should be written to the EF. Or as
> you said, at RAW + Parameters (at least curve name).
>
>   >
>   > I believe that if you chose to write out the SPKI, then every thing
> would work,
>   > but then again if you are using an existing card written by some
> other software
>   > using RAW, the read should process the Parameters to get the curve.
>   >
>
> This would address my concern with breaking things.
>
> However, only RAW + Parameters would also solve my problem. RAW without
> Parameters is causing my issues.
>
>   >>
>   >> So...
>   >> 1) Do you agree that the EF(public key) needs to contain at least the
>   >> curve name? Or is the information available elsewhere?
>   >
>   >
>   > PKCS#15 says: "The field is not needed if the information is available
>   > through other means."  Ithink this was a compromise at the time of
> writting...
>   >
>   > The Curve name could be found in a matching certificate, or the
> application
>   > has to provide the curve. Early IETF RFC had some issues with this as
> well,
>   > I believe all the current RFC require the curve name to be in the SPKI.
>   >
>
> Thanks for the hint. In my case, I unfortunately don't see any other
> means of obtaining the curve name right now.
>
> Which application do you mean when writing "the application has to
> provide the curve"?
>
>   >
>   > Did you write the key to the card?
>   > If so was the curve available when you write it?
>   > In that case it should have been written as a Parameter or in the SPKI.
>   > If not then there is not much that can be done.
>   >
>   >
>   > DO you have an opensc debug log or gdb output showing the EF as writtne
>   > or read from the card?
>
> See above.
>
>
> Thanks and best regards,
>
> Philip
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Format of extracted ECC public keys

Philip Wendland
On 09/22/2014 11:37 PM, Douglas E Engert wrote:

>
>
> On 9/22/2014 1:03 PM, Philip Wendland wrote:
>>    > P.S. Can you get your repository up to dat with OpenSC/OpenSC
>>    > It would help to see what are your changes.
>>
>> Thanks for your answer. I updated my repo after writing the first
>> E-Mail, I think you were quicker than me :-)
>>
>>    > It should be using 6.3.4, and either use the SPKI, or the RAW +
>>    > Parameters.
>>
>> I agree.
>>
>>    > I believe the CardContact SmartCard-HSM may be doing this.
>>    > (I use the PIV card that is using emulation and only 2 curves and
>> would not
>>    > use the routines in question.)
>>    >
>>
>> I've had a quick look at this. Seeing
>> sc_pkcs15emu_sc_hsm_get_public_key() and some other functions I have
>> some doubts. But I don't fully understand what is happening there :-)
>>
>>    >> This is, of course, part of the problem. BUT gdb shows the u.ec. is not
>>    >> populated. I guess this has to do with the encoding of the public key
>>    >> file described earlier.
>>    >
>>    > Sounds like the bug. How did you create the key and write it to the EF?
>>    > Did it include the Parameters?
>>
>> The key is generated on-card. The answer of the smartcard contains the
>> public key. This is used to fill in the pubkey before exiting generate_key.
>> This is what is available when exiting isoApplet_generate_key
>> (pkcs15-isoApplet.c):
>>
>> (gdb) p pubkey->u.ec.params.named_curve
>> $3 = 0x62bec0 "prime256v1"
>> (gdb) p pubkey->u.ec.params.id
>> $4 = {value = {1, 2, 840, 10045, 3, 1, 7, -1, -1, -1, -1, -1, -1, -1,
>> -1, -1}}
>> (gdb) p pubkey->u.ec.params.der
>> $5 = {value = 0x62bea0 "\006\b*\206H\316=\003\001\a\377\366\377\177",
>> len = 10}
>> (gdb) p pubkey->u.ec.params.field_length
>> $6 = 256
>> (gdb)
>>
>
> In pkcs15-lib.c:
>
> What is passed to:
> 1261 sc_pkcs15init_generate_key(struct sc_pkcs15_card *p15card, struct sc_profile *profile,
> 1262                 struct sc_pkcs15init_keygen_args *keygen_args, unsigned int keybits,
> 1263                 struct sc_pkcs15_object **res_obj)
>
> especially keygen_args.
>
>

(gdb) p keygen_args->pubkey_label
$5 = 0x0
(gdb) p keygen_args->prkey_args->id
$6 = {value = '\000' <repeats 254 times>, len = 0}
(gdb) p keygen_args->prkey_args->auth_id
$7 = {value = "\377", '\000' <repeats 253 times>, len = 1}
(gdb) p keygen_args->prkey_args->label
$8 = 0x0
(gdb) p keygen_args->prkey_args->guid
$9 = (unsigned char *) 0x0
(gdb) p keygen_args->prkey_args->guid_len
$10 = 0
(gdb) p keygen_args->prkey_args->usage
$11 = 0
(gdb) p keygen_args->prkey_args->x509_usage
$12 = 0
(gdb) p keygen_args->prkey_args->flags
$13 = 0
(gdb) p keygen_args->prkey_args->access_flags
$14 = 29
(gdb) p keygen_args->prkey_args->params.ec.named_curve
$15 = 0x612810 "prime256v1"
(gdb) p keygen_args->prkey_args->params.ec.id
$16 = {value = {0 <repeats 16 times>}}
(gdb) p keygen_args->prkey_args->params.ec.der
$17 = {value = 0x0, len = 0}
(gdb) p keygen_args->prkey_args->params.ec.field_length
$18 = 0

(gdb) p keybits
$19 = 0

I.e. at the beginning, this function only has the curve name.
But the first thing that is being called there is
check_keygen_params_consistency() which calls sc_pkcs15_fix_ec_parameters().

 > 1323         else if (keygen_args->prkey_args.key.algorithm ==
SC_ALGORITHM_EC)
 > 1324                 pubkey_args.params.ec =
keygen_args->prkey_args.params.ec;
 > 1325
 > 1326         /* Generate the private key on card */
 >
 > Could line 1324 be setting the wrong values?
 > What is in keygen_args->prkey_args.params.ec
 > This should have the curve.

After calling check_keygen_params_consistency() the keygen_args is filled:

(gdb) p keygen_args->prkey_args->params.ec.named_curve
$22 = 0x612810 "prime256v1"
(gdb) p keygen_args->prkey_args->params.ec.id
$23 = {value = {1, 2, 840, 10045, 3, 1, 7, -1, -1, -1, -1, -1, -1, -1,
-1, -1}}
(gdb) p keygen_args->prkey_args->params.ec.der
$24 = {value = 0x614e60 "\006\b*\206H\316=\003\001\a\377\366\377\177",
   len = 10}
(gdb) p keygen_args->prkey_args->params.ec.field_length
$25 = 256
(gdb) p keybits
$26 = 256

I think this is correct.

>
> THIS MAY BE THE PROBLEM, you did not set the curve in the keygen_args->prkey_args.params.ec.
>

I do not call sc_pkcs15init_generate_key(), in fact, I am being called
by it right after 1324.

pkcs15-init/main()->do_generate_key()->sc_pkcs15init_generate_key()
->isoApplet_generate_key()

> Since you only support 2 curves, and each has a different algorithm_ref
> ISOAPPLET_ALG_REF_EC_GEN_BRAINPOOLP192R1 or ISOAPPLET_ALG_REF_EC_GEN_PRIME256V1
> you are in effect passing the curve to the card, where as in a more general
> situation the curve would be passed in the generate key.
>
>
See above, IMHO not related to the problem.

But the problem aside, you are correct. I am thinking of using the data
field of GENERATE ASYMMETRIC KEYPAIR to pass the actual curve to the card.


I am going to investigate further in the encoding of the EF(public key)
in the smartcard's filesystem - knowing that the parameters SHOULD be
part of it (either RAW or SPKI).
I'll report back when I come up with something, hopefully with a solution.

Thanks for the help so far.

Philip

>
>> After I exit this function, it is out of my hands. It returns to
>> pkcs15-lib.c:1327.
>> This later calls sc_pkcs15init_store_public_key. This is where the
>> public key is being stored in the EF.
>>
>> After looking at this I found something that looks weird to me:
>> (pkcs15-lib.c:1571)
>>
>> /* DER encode public key components */
>> r = sc_pkcs15_encode_pubkey(p15card->card->ctx, &key,
>> &object->content.value, &object->content.len);
>> LOG_TEST_RET(ctx, r, "Encode public key error");
>>
>> r = sc_pkcs15_encode_pubkey(p15card->card->ctx, &key,
>> &key_info->direct.raw.value, &key_info->direct.raw.len);
>> LOG_TEST_RET(ctx, r, "RAW encode public key error");
>>
>> /* EC key are encoded as SPKI to preserve domain parameter */
>> r = sc_pkcs15_encode_pubkey_as_spki(p15card->card->ctx, &key,
>> &key_info->direct.spki.value, &key_info->direct.spki.len);
>> LOG_TEST_RET(ctx, r, "SPKI encode public key error");
>>
>> /* Now create key file and store key */
>> r = sc_pkcs15init_store_data(p15card, profile, object,
>> &object->content, &key_info->path);
>>
>> The SPKI encoding for EC keys is written to key_info (which is
>> object->data).
>> But the object->content, a seperate field containing only the ecPointQ
>> encoded by sc_pkcs15_encode_pubkey() is being written to the EF:
>>
>> 0x7ffff7fca700 18:47:04.021 [pkcs15-init] apdu.c:185:sc_apdu_log:
>> Outgoing APDU data [   72 bytes] =====================================
>> 00 D6 00 00 43 04 41 04 C1 36 E2 CC 7C 1C 3D F3 ....C.A..6..|.=.
>> 6C 5E 29 C0 31 45 75 54 24 55 D2 85 8E 46 B4 AB l^).1EuT$U...F..
>> 3A 3B DB 18 16 67 16 55 A4 B9 72 F0 76 CF ED 5A :;...g.U..r.v..Z
>> 08 04 AA F5 46 11 91 90 66 90 C8 B9 CD 67 F2 ED ....F...f....g..
>> 86 A7 81 0D A5 18 1E 6E                         .......n
>> ======================================================================
>> 0x7ffff7fca700 18:47:04.022 [pkcs15-init]
>> reader-pcsc.c:182:pcsc_internal_transmit: called
>> 0x7ffff7fca700 18:47:04.044 [pkcs15-init] apdu.c:185:sc_apdu_log:
>> Incoming APDU data [    2 bytes] =====================================
>> 90 00 ..
>> ======================================================================
>>
>> I think that at this point the SPKI should be written to the EF. Or as
>> you said, at RAW + Parameters (at least curve name).
>>
>>    >
>>    > I believe that if you chose to write out the SPKI, then every thing
>> would work,
>>    > but then again if you are using an existing card written by some
>> other software
>>    > using RAW, the read should process the Parameters to get the curve.
>>    >
>>
>> This would address my concern with breaking things.
>>
>> However, only RAW + Parameters would also solve my problem. RAW without
>> Parameters is causing my issues.
>>
>>    >>
>>    >> So...
>>    >> 1) Do you agree that the EF(public key) needs to contain at least the
>>    >> curve name? Or is the information available elsewhere?
>>    >
>>    >
>>    > PKCS#15 says: "The field is not needed if the information is available
>>    > through other means."  Ithink this was a compromise at the time of
>> writting...
>>    >
>>    > The Curve name could be found in a matching certificate, or the
>> application
>>    > has to provide the curve. Early IETF RFC had some issues with this as
>> well,
>>    > I believe all the current RFC require the curve name to be in the SPKI.
>>    >
>>
>> Thanks for the hint. In my case, I unfortunately don't see any other
>> means of obtaining the curve name right now.
>>
>> Which application do you mean when writing "the application has to
>> provide the curve"?
>>
>>    >
>>    > Did you write the key to the card?
>>    > If so was the curve available when you write it?
>>    > In that case it should have been written as a Parameter or in the SPKI.
>>    > If not then there is not much that can be done.
>>    >
>>    >
>>    > DO you have an opensc debug log or gdb output showing the EF as writtne
>>    > or read from the card?
>>
>> See above.
>>
>>
>> Thanks and best regards,
>>
>> Philip
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Opensc-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Format of extracted ECC public keys

Douglas E Engert


On 9/23/2014 8:05 AM, Philip Wendland wrote:

> On 09/22/2014 11:37 PM, Douglas E Engert wrote:
>>
>>
>> On 9/22/2014 1:03 PM, Philip Wendland wrote:
>>>     > P.S. Can you get your repository up to dat with OpenSC/OpenSC
>>>     > It would help to see what are your changes.
>>>
>>> Thanks for your answer. I updated my repo after writing the first
>>> E-Mail, I think you were quicker than me :-)
>>>
>>>     > It should be using 6.3.4, and either use the SPKI, or the RAW +
>>>     > Parameters.
>>>
>>> I agree.
>>>
>>>     > I believe the CardContact SmartCard-HSM may be doing this.
>>>     > (I use the PIV card that is using emulation and only 2 curves and
>>> would not
>>>     > use the routines in question.)
>>>     >
>>>
>>> I've had a quick look at this. Seeing
>>> sc_pkcs15emu_sc_hsm_get_public_key() and some other functions I have
>>> some doubts. But I don't fully understand what is happening there :-)
>>>
>>>     >> This is, of course, part of the problem. BUT gdb shows the u.ec. is not
>>>     >> populated. I guess this has to do with the encoding of the public key
>>>     >> file described earlier.
>>>     >
>>>     > Sounds like the bug. How did you create the key and write it to the EF?
>>>     > Did it include the Parameters?
>>>
>>> The key is generated on-card. The answer of the smartcard contains the
>>> public key. This is used to fill in the pubkey before exiting generate_key.
>>> This is what is available when exiting isoApplet_generate_key
>>> (pkcs15-isoApplet.c):
>>>
>>> (gdb) p pubkey->u.ec.params.named_curve
>>> $3 = 0x62bec0 "prime256v1"
>>> (gdb) p pubkey->u.ec.params.id
>>> $4 = {value = {1, 2, 840, 10045, 3, 1, 7, -1, -1, -1, -1, -1, -1, -1,
>>> -1, -1}}
>>> (gdb) p pubkey->u.ec.params.der
>>> $5 = {value = 0x62bea0 "\006\b*\206H\316=\003\001\a\377\366\377\177",
>>> len = 10}
>>> (gdb) p pubkey->u.ec.params.field_length
>>> $6 = 256
>>> (gdb)
>>>
>>
>> In pkcs15-lib.c:
>>
>> What is passed to:
>> 1261 sc_pkcs15init_generate_key(struct sc_pkcs15_card *p15card, struct sc_profile *profile,
>> 1262                 struct sc_pkcs15init_keygen_args *keygen_args, unsigned int keybits,
>> 1263                 struct sc_pkcs15_object **res_obj)
>>
>> especially keygen_args.
>>
>>
>
> (gdb) p keygen_args->pubkey_label
> $5 = 0x0
> (gdb) p keygen_args->prkey_args->id
> $6 = {value = '\000' <repeats 254 times>, len = 0}
> (gdb) p keygen_args->prkey_args->auth_id
> $7 = {value = "\377", '\000' <repeats 253 times>, len = 1}
> (gdb) p keygen_args->prkey_args->label
> $8 = 0x0
> (gdb) p keygen_args->prkey_args->guid
> $9 = (unsigned char *) 0x0
> (gdb) p keygen_args->prkey_args->guid_len
> $10 = 0
> (gdb) p keygen_args->prkey_args->usage
> $11 = 0
> (gdb) p keygen_args->prkey_args->x509_usage
> $12 = 0
> (gdb) p keygen_args->prkey_args->flags
> $13 = 0
> (gdb) p keygen_args->prkey_args->access_flags
> $14 = 29
> (gdb) p keygen_args->prkey_args->params.ec.named_curve
> $15 = 0x612810 "prime256v1"
> (gdb) p keygen_args->prkey_args->params.ec.id
> $16 = {value = {0 <repeats 16 times>}}
> (gdb) p keygen_args->prkey_args->params.ec.der
> $17 = {value = 0x0, len = 0}
> (gdb) p keygen_args->prkey_args->params.ec.field_length
> $18 = 0
>
> (gdb) p keybits
> $19 = 0
>
> I.e. at the beginning, this function only has the curve name.
> But the first thing that is being called there is
> check_keygen_params_consistency() which calls sc_pkcs15_fix_ec_parameters().
>
>   > 1323         else if (keygen_args->prkey_args.key.algorithm ==
> SC_ALGORITHM_EC)
>   > 1324                 pubkey_args.params.ec =
> keygen_args->prkey_args.params.ec;
>   > 1325
>   > 1326         /* Generate the private key on card */
>   >
>   > Could line 1324 be setting the wrong values?
>   > What is in keygen_args->prkey_args.params.ec
>   > This should have the curve.
>
> After calling check_keygen_params_consistency() the keygen_args is filled:
>
> (gdb) p keygen_args->prkey_args->params.ec.named_curve
> $22 = 0x612810 "prime256v1"
> (gdb) p keygen_args->prkey_args->params.ec.id
> $23 = {value = {1, 2, 840, 10045, 3, 1, 7, -1, -1, -1, -1, -1, -1, -1,
> -1, -1}}
> (gdb) p keygen_args->prkey_args->params.ec.der
> $24 = {value = 0x614e60 "\006\b*\206H\316=\003\001\a\377\366\377\177",
>     len = 10}
> (gdb) p keygen_args->prkey_args->params.ec.field_length
> $25 = 256
> (gdb) p keybits
> $26 = 256
>
> I think this is correct.

Looks like it is correct.

I don't have any pkcs15 cards to test with, so can't help to much.
I do have a SmartCard-HSM that might be able to reproduce the
the situation. I will look to see if on creating a key, it returns
the ecpointQ or the SPKI or something else.

I would like to see an opensc debug trace of your code.

On the generate key on the card, it sounds like the card only returns
the ecpointQ, and thus software must fill in the curve.
That is what the code should be doing.


The code path may be untested, and there is a bug.

>
>>
>> THIS MAY BE THE PROBLEM, you did not set the curve in the keygen_args->prkey_args.params.ec.
>>
>
> I do not call sc_pkcs15init_generate_key(), in fact, I am being called
> by it right after 1324.
>
> pkcs15-init/main()->do_generate_key()->sc_pkcs15init_generate_key()
> ->isoApplet_generate_key()
>
>> Since you only support 2 curves, and each has a different algorithm_ref
>> ISOAPPLET_ALG_REF_EC_GEN_BRAINPOOLP192R1 or ISOAPPLET_ALG_REF_EC_GEN_PRIME256V1
>> you are in effect passing the curve to the card, where as in a more general
>> situation the curve would be passed in the generate key.
>>
>>
> See above, IMHO not related to the problem.
>
> But the problem aside, you are correct. I am thinking of using the data
> field of GENERATE ASYMMETRIC KEYPAIR to pass the actual curve to the card.
>
>
> I am going to investigate further in the encoding of the EF(public key)
> in the smartcard's filesystem - knowing that the parameters SHOULD be
> part of it (either RAW or SPKI).
> I'll report back when I come up with something, hopefully with a solution.
>
> Thanks for the help so far.
>
> Philip
>
>>
>>> After I exit this function, it is out of my hands. It returns to
>>> pkcs15-lib.c:1327.
>>> This later calls sc_pkcs15init_store_public_key. This is where the
>>> public key is being stored in the EF.
>>>
>>> After looking at this I found something that looks weird to me:
>>> (pkcs15-lib.c:1571)
>>>
>>> /* DER encode public key components */
>>> r = sc_pkcs15_encode_pubkey(p15card->card->ctx, &key,
>>> &object->content.value, &object->content.len);
>>> LOG_TEST_RET(ctx, r, "Encode public key error");
>>>
>>> r = sc_pkcs15_encode_pubkey(p15card->card->ctx, &key,
>>> &key_info->direct.raw.value, &key_info->direct.raw.len);
>>> LOG_TEST_RET(ctx, r, "RAW encode public key error");
>>>
>>> /* EC key are encoded as SPKI to preserve domain parameter */
>>> r = sc_pkcs15_encode_pubkey_as_spki(p15card->card->ctx, &key,
>>> &key_info->direct.spki.value, &key_info->direct.spki.len);
>>> LOG_TEST_RET(ctx, r, "SPKI encode public key error");
>>>
>>> /* Now create key file and store key */
>>> r = sc_pkcs15init_store_data(p15card, profile, object,
>>> &object->content, &key_info->path);
>>>
>>> The SPKI encoding for EC keys is written to key_info (which is
>>> object->data).
>>> But the object->content, a seperate field containing only the ecPointQ
>>> encoded by sc_pkcs15_encode_pubkey() is being written to the EF:
>>>
>>> 0x7ffff7fca700 18:47:04.021 [pkcs15-init] apdu.c:185:sc_apdu_log:
>>> Outgoing APDU data [   72 bytes] =====================================
>>> 00 D6 00 00 43 04 41 04 C1 36 E2 CC 7C 1C 3D F3 ....C.A..6..|.=.
>>> 6C 5E 29 C0 31 45 75 54 24 55 D2 85 8E 46 B4 AB l^).1EuT$U...F..
>>> 3A 3B DB 18 16 67 16 55 A4 B9 72 F0 76 CF ED 5A :;...g.U..r.v..Z
>>> 08 04 AA F5 46 11 91 90 66 90 C8 B9 CD 67 F2 ED ....F...f....g..
>>> 86 A7 81 0D A5 18 1E 6E                         .......n
>>> ======================================================================
>>> 0x7ffff7fca700 18:47:04.022 [pkcs15-init]
>>> reader-pcsc.c:182:pcsc_internal_transmit: called
>>> 0x7ffff7fca700 18:47:04.044 [pkcs15-init] apdu.c:185:sc_apdu_log:
>>> Incoming APDU data [    2 bytes] =====================================
>>> 90 00 ..
>>> ======================================================================
>>>
>>> I think that at this point the SPKI should be written to the EF. Or as
>>> you said, at RAW + Parameters (at least curve name).
>>>
>>>     >
>>>     > I believe that if you chose to write out the SPKI, then every thing
>>> would work,
>>>     > but then again if you are using an existing card written by some
>>> other software
>>>     > using RAW, the read should process the Parameters to get the curve.
>>>     >
>>>
>>> This would address my concern with breaking things.
>>>
>>> However, only RAW + Parameters would also solve my problem. RAW without
>>> Parameters is causing my issues.
>>>
>>>     >>
>>>     >> So...
>>>     >> 1) Do you agree that the EF(public key) needs to contain at least the
>>>     >> curve name? Or is the information available elsewhere?
>>>     >
>>>     >
>>>     > PKCS#15 says: "The field is not needed if the information is available
>>>     > through other means."  Ithink this was a compromise at the time of
>>> writting...
>>>     >
>>>     > The Curve name could be found in a matching certificate, or the
>>> application
>>>     > has to provide the curve. Early IETF RFC had some issues with this as
>>> well,
>>>     > I believe all the current RFC require the curve name to be in the SPKI.
>>>     >
>>>
>>> Thanks for the hint. In my case, I unfortunately don't see any other
>>> means of obtaining the curve name right now.
>>>
>>> Which application do you mean when writing "the application has to
>>> provide the curve"?
>>>
>>>     >
>>>     > Did you write the key to the card?
>>>     > If so was the curve available when you write it?
>>>     > In that case it should have been written as a Parameter or in the SPKI.
>>>     > If not then there is not much that can be done.
>>>     >
>>>     >
>>>     > DO you have an opensc debug log or gdb output showing the EF as writtne
>>>     > or read from the card?
>>>
>>> See above.
>>>
>>>
>>> Thanks and best regards,
>>>
>>> Philip
>>>
>>> ------------------------------------------------------------------------------
>>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>
>>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Format of extracted ECC public keys

Philip Wendland
On 09/23/2014 03:12 PM, Douglas E Engert wrote:

> Looks like it is correct.
>
> I don't have any pkcs15 cards to test with, so can't help to much.
> I do have a SmartCard-HSM that might be able to reproduce the
> the situation. I will look to see if on creating a key, it returns
> the ecpointQ or the SPKI or something else.
>
> I would like to see an opensc debug trace of your code.

Sure, 2 files attached. One showing the generate key, the other the read
public key.

>
> On the generate key on the card, it sounds like the card only returns
> the ecpointQ, and thus software must fill in the curve.
> That is what the code should be doing.
>

My applet returns the complete curve encoded as ISO 7816-8 Table 3 -
Public key data objects.

Set of public key data objects for ECDSA
'81' Prime (a number denoted as p coded on z bytes)
'82' First coefficient (a number denoted as a coded on z bytes)
'83' Second coefficient (a number denoted as b coded on z bytes)
'84' Generator (a point denoted as PB on the curve, coded on 2z or z+1
bytes)
'85' Order (a prime number denoted as q, order of the generator PB,
coded on z bytes)
'86' Public key (a point denoted as PP on the curve, equal to x times PB
where x is the private key, coded on 2z
or z+1 bytes)
'87' Co-factor

It would be no problem to write them somewhere before exiting
isoApplet_generate_key, but I don't know where. Since you wrote OpenSC
only works with curve names I reckon the curve name/OID in the
u.ec.params should be enough.


Best regards,

Philip

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

osc-debug-isoApplet-readPkey.log (69K) Download Attachment
osc-debug-isoApplet-genkey.log (180K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Format of extracted ECC public keys

Douglas E Engert


On 9/23/2014 11:43 AM, Philip Wendland wrote:

> On 09/23/2014 03:12 PM, Douglas E Engert wrote:
>
>> Looks like it is correct.
>>
>> I don't have any pkcs15 cards to test with, so can't help to much.
>> I do have a SmartCard-HSM that might be able to reproduce the
>> the situation. I will look to see if on creating a key, it returns
>> the ecpointQ or the SPKI or something else.
>>
>> I would like to see an opensc debug trace of your code.
>
> Sure, 2 files attached. One showing the generate key, the other the read public key.
>
>>
>> On the generate key on the card, it sounds like the card only returns
>> the ecpointQ, and thus software must fill in the curve.
>> That is what the code should be doing.
>>
>
> My applet returns the complete curve encoded as ISO 7816-8 Table 3 - Public key data objects.
>
> Set of public key data objects for ECDSA
> '81' Prime (a number denoted as p coded on z bytes)
> '82' First coefficient (a number denoted as a coded on z bytes)
> '83' Second coefficient (a number denoted as b coded on z bytes)
> '84' Generator (a point denoted as PB on the curve, coded on 2z or z+1 bytes)
> '85' Order (a prime number denoted as q, order of the generator PB, coded on z bytes)
> '86' Public key (a point denoted as PP on the curve, equal to x times PB where x is the private key, coded on 2z
> or z+1 bytes)
> '87' Co-factor


Line #681, #721 read in the curve parameters, and the ecpointQ length 40 DBA964DB...6EC2EDBC

line #740 says it found Curve name: 'prime256v1'
lines#749 - 750 asn1 encode it as
  044104DBA964DB...6EC2EDBC

Line# 1033 isd writing PKCS#15 info about private key.

Line#1195 knows it is prime256v1

Line #1214 encode pubkey as SPKI.

Line  #1222 looks like it encoded OID for named curve.

In libopensc/pkcs15-pubkey.c line 819, there is a TODO could this be the problem?

Line #1232 looks like it encoded as SPKI


IN src/lobopensc/pkcs15-pubkey.c:473,
can you look at lines 481 and 484, i.e. pubkey->direct.pki.value, and pubkey->direct.raw.value

This looks like pubkey->direct.pki.value == NUL, yet it looks like it converted it above.
if its NULL, then the RAW ecpointQ will be written.





















>
> It would be no problem to write them somewhere before exiting isoApplet_generate_key, but I don't know where. Since you wrote OpenSC only works with curve names I reckon the curve name/OID in the
> u.ec.params should be enough.
>
>
> Best regards,
>
> Philip
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Format of extracted ECC public keys

Douglas E Engert
In reply to this post by Philip Wendland
The problem may be here in pkcs15-lib.c


1578         r = sc_pkcs15_encode_pubkey(p15card->card->ctx, &key, &key_info->direct.raw.value, &key_info->direct.raw.len);
1579         LOG_TEST_RET(ctx, r, "RAW encode public key error");
1580
1581         /* EC key are encoded as SPKI to preserve domain parameter */
1582         r = sc_pkcs15_encode_pubkey_as_spki(p15card->card->ctx, &key, &key_info->direct.spki.value, &key_info->direct.spki.len);
1583         LOG_TEST_RET(ctx, r, "SPKI encode public key error");
1584
1585         /* Now create key file and store key */
1586         r = sc_pkcs15init_store_data(p15card, profile, object, &object->content, &key_info->path);
1587

It looks like it encodes the pubkey, as RAW and as SPKI, but then writes the object->content as the file.
As a test, in 1586, replace &object->content with  &key_info->direct.spki

There should be a flag in the profile, indicating how to store the key: RAW or SPKI at least for EC.





On 9/23/2014 11:43 AM, Philip Wendland wrote:

> On 09/23/2014 03:12 PM, Douglas E Engert wrote:
>
>> Looks like it is correct.
>>
>> I don't have any pkcs15 cards to test with, so can't help to much.
>> I do have a SmartCard-HSM that might be able to reproduce the
>> the situation. I will look to see if on creating a key, it returns
>> the ecpointQ or the SPKI or something else.
>>
>> I would like to see an opensc debug trace of your code.
>
> Sure, 2 files attached. One showing the generate key, the other the read public key.
>
>>
>> On the generate key on the card, it sounds like the card only returns
>> the ecpointQ, and thus software must fill in the curve.
>> That is what the code should be doing.
>>
>
> My applet returns the complete curve encoded as ISO 7816-8 Table 3 - Public key data objects.
>
> Set of public key data objects for ECDSA
> '81' Prime (a number denoted as p coded on z bytes)
> '82' First coefficient (a number denoted as a coded on z bytes)
> '83' Second coefficient (a number denoted as b coded on z bytes)
> '84' Generator (a point denoted as PB on the curve, coded on 2z or z+1 bytes)
> '85' Order (a prime number denoted as q, order of the generator PB, coded on z bytes)
> '86' Public key (a point denoted as PP on the curve, equal to x times PB where x is the private key, coded on 2z
> or z+1 bytes)
> '87' Co-factor
>
> It would be no problem to write them somewhere before exiting isoApplet_generate_key, but I don't know where. Since you wrote OpenSC only works with curve names I reckon the curve name/OID in the
> u.ec.params should be enough.
>
>
> Best regards,
>
> Philip
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Format of extracted ECC public keys

Philip Wendland
On 09/23/2014 11:51 PM, Douglas E Engert wrote:

> The problem may be here in pkcs15-lib.c
>
>
> 1578         r = sc_pkcs15_encode_pubkey(p15card->card->ctx, &key, &key_info->direct.raw.value, &key_info->direct.raw.len);
> 1579         LOG_TEST_RET(ctx, r, "RAW encode public key error");
> 1580
> 1581         /* EC key are encoded as SPKI to preserve domain parameter */
> 1582         r = sc_pkcs15_encode_pubkey_as_spki(p15card->card->ctx, &key, &key_info->direct.spki.value, &key_info->direct.spki.len);
> 1583         LOG_TEST_RET(ctx, r, "SPKI encode public key error");
> 1584
> 1585         /* Now create key file and store key */
> 1586         r = sc_pkcs15init_store_data(p15card, profile, object, &object->content, &key_info->path);
> 1587
>
> It looks like it encodes the pubkey, as RAW and as SPKI, but then writes the object->content as the file.
> As a test, in 1586, replace &object->content with  &key_info->direct.spki
>


Yes, this was it. Thanks for your help with this matter.

Here is the pull request to fix this, please have a look at it:
https://github.com/OpenSC/OpenSC/pull/288

 > There should be a flag in the profile, indicating how to store the
 > key: RAW or SPKI at least for EC.

I did not find such a flag in the profile, so I did read "There should
be a flag in the profile" in terms of "it should be added". I hope this
was right :-)

>
>
>
> On 9/23/2014 11:43 AM, Philip Wendland wrote:
>> On 09/23/2014 03:12 PM, Douglas E Engert wrote:
>>
>>> Looks like it is correct.
>>>
>>> I don't have any pkcs15 cards to test with, so can't help to much.
>>> I do have a SmartCard-HSM that might be able to reproduce the
>>> the situation. I will look to see if on creating a key, it returns
>>> the ecpointQ or the SPKI or something else.
>>>
>>> I would like to see an opensc debug trace of your code.
>>
>> Sure, 2 files attached. One showing the generate key, the other the read public key.
>>
>>>
>>> On the generate key on the card, it sounds like the card only returns
>>> the ecpointQ, and thus software must fill in the curve.
>>> That is what the code should be doing.
>>>
>>
>> My applet returns the complete curve encoded as ISO 7816-8 Table 3 - Public key data objects.
>>
>> Set of public key data objects for ECDSA
>> '81' Prime (a number denoted as p coded on z bytes)
>> '82' First coefficient (a number denoted as a coded on z bytes)
>> '83' Second coefficient (a number denoted as b coded on z bytes)
>> '84' Generator (a point denoted as PB on the curve, coded on 2z or z+1 bytes)
>> '85' Order (a prime number denoted as q, order of the generator PB, coded on z bytes)
>> '86' Public key (a point denoted as PP on the curve, equal to x times PB where x is the private key, coded on 2z
>> or z+1 bytes)
>> '87' Co-factor
>>
>> It would be no problem to write them somewhere before exiting isoApplet_generate_key, but I don't know where. Since you wrote OpenSC only works with curve names I reckon the curve name/OID in the
>> u.ec.params should be enough.
>>
>>
>> Best regards,
>>
>> Philip
>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Opensc-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel