Problems with OpenSC and PKCS#15 ASN.1 coding of keyInfo

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

Problems with OpenSC and PKCS#15 ASN.1 coding of keyInfo

Douglas E Engert
While researching with Philip Wendland:
"[OpenSC] add the possibility to store public ECC keys encoded according to SPKI (#288)"

   https://github.com/OpenSC/OpenSC/pull/288

It became apparent that OpenSC does not ASN.1 encode keyInfo and ParametersTypes correctly even for RSA.
This also applies to the PuKDF entries.

The problem may show up if the current OpenSC tries to use a card created with correct ASN.1 by some other software,
or OpenSC creates a keyInfo that some other software fails to parse.

If this is corrected, there would be a backwards comparability issue, with older cards not having the parameter in the keyInfo.

OpenSC could for (RSA at least) treat reading the NULL parameter as OPTIONAL to handle existing
cards without the NULL for RSA.



In PKCS#15 v1.1

  6.1.13 KeyInfo

        KeyInfo {ParameterType, OperationsType} ::= CHOICE {
                reference Reference,
                paramsAndOps SEQUENCE {
                        parameters ParameterType,
                        supportedOperations OperationsType OPTIONAL
                                }
                }


Note that parameters are *NOT* optional, OpenSC has not been adding parameters even for RSA.

OpenSC could for (RSA at least) treat reading the NULL parameter as OPTIONAL to handle existing
cards without the NULL for RSA.


6.4.2 Public RSA key objects

        PublicRSAKeyAttributes ::= SEQUENCE {
                value ObjectValue {RSAPublicKeyChoice},
                modulusLength INTEGER, -- modulus length in bits, e.g. 1024
                keyInfo KeyInfo {NULL, PublicKeyOperations} OPTIONAL,
                ... -- For future extensions
        }

keyInfo is OPTIONAL, but if keyInfo is defined for RSA, ParameterType must be NULL.
NULL is *the* ASN.1 NULL object, not an indication that the object can left out or is optional.

OpenSC ASN.1 can handle NULL as SC_ASN1_NULL object which is a 05.

6.4.3 Public Elliptic Curve key objects

PublicECKeyAttributes ::= SEQUENCE {
value ObjectValue {ECPublicKeyChoice},
keyInfo KeyInfo {Parameters, PublicKeyOperations} OPTIONAL,
... -- For future extensions
}

Here for EC the KeyInfo ParameterType = Parameters

PKCS#15 also says:
        ECPoint, Parameters
                FROM ANSI-X9-62 {iso(1) member-body(2) us(840) ansi-x962(10045) module(4) 1}

i.e. is is defined in ANSI-X9-62 (not having access to ANSI-X9-62, then next best definition is from PKCS#11)

PKCS#11 says:

The CKA_EC_PARAMS or CKA_ECDSA_PARAMS attribute value is known as the
“EC domain parameters” and is defined in ANSI X9.62 as a choice of three parameter
representation methods with the following syntax:

        Parameters ::= CHOICE {
                ecParameters ECParameters,
                namedCurve CURVES.&id({CurveNames}),
                implicitlyCA NULL
        }

Note that if no ecParameters, or namedCurve is available, the ASN.1 NULL must be used.

IETF RFC 5480 also defines it as:

        ECParameters ::= CHOICE {
                namedCurve         OBJECT IDENTIFIER
        -- implicitCurve   NULL
        -- specifiedCurve  SpecifiedECDomain
                }
But for use in RFC 5480, only the namedCurve is allowed.


With other pubkeys PKCS#15 say:

6.4.4 Public Diffie-Hellman key objects
  uses DomainParameters

6.4.5 Public Digital Signature Algorithm objects
  uses DomainParameters

6.4.6 Public KEA key objects
  uses DomainParameters

These are defined in:
DiffieHellmanPublicNumber, DomainParameters
        FROM ANSI-X9-42 {iso(1) member-body(2) us(840) ansi-x942(10046) module(5) 1}

PKCS#11 says: "See the ANSI X9.42 standard for more information on X9.42 Diffie-Hellman domain parameters."

I don't have a ANSI-X9-42 to see the ASN.1 encoding of the DomainParameters.

Where are the PKCS#15 ASN.1 definitions For GOST?

Comments?
opensc

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&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: Problems with OpenSC and PKCS#15 ASN.1 coding of keyInfo

Douglas E Engert
I do not have a good way to test this. But looking at the code it appears that only GOST uses the keyInfo
so the problem may only exist if OpenSC tries to use a card created by some other software that did use a keyInfo.

So for EC keys, it looks like #288 may solve the problem by using SPKI for the key as it includes the parameters.


On 9/29/2014 9:06 AM, Douglas E Engert wrote:

> While researching with Philip Wendland:
> "[OpenSC] add the possibility to store public ECC keys encoded according to SPKI (#288)"
>
>    https://github.com/OpenSC/OpenSC/pull/288
>
> It became apparent that OpenSC does not ASN.1 encode keyInfo and ParametersTypes correctly even for RSA.
> This also applies to the PuKDF entries.
>
> The problem may show up if the current OpenSC tries to use a card created with correct ASN.1 by some other software,
> or OpenSC creates a keyInfo that some other software fails to parse.
>
> If this is corrected, there would be a backwards comparability issue, with older cards not having the parameter in the keyInfo.
>
> OpenSC could for (RSA at least) treat reading the NULL parameter as OPTIONAL to handle existing
> cards without the NULL for RSA.
>
>
>
> In PKCS#15 v1.1
>
>   6.1.13 KeyInfo
>
>      KeyInfo {ParameterType, OperationsType} ::= CHOICE {
>          reference Reference,
>          paramsAndOps SEQUENCE {
>              parameters ParameterType,
>              supportedOperations OperationsType OPTIONAL
>                  }
>          }
>
>
> Note that parameters are *NOT* optional, OpenSC has not been adding parameters even for RSA.
>
> OpenSC could for (RSA at least) treat reading the NULL parameter as OPTIONAL to handle existing
> cards without the NULL for RSA.
>
>
> 6.4.2 Public RSA key objects
>
>      PublicRSAKeyAttributes ::= SEQUENCE {
>          value ObjectValue {RSAPublicKeyChoice},
>          modulusLength INTEGER, -- modulus length in bits, e.g. 1024
>          keyInfo KeyInfo {NULL, PublicKeyOperations} OPTIONAL,
>          ... -- For future extensions
>      }
>
> keyInfo is OPTIONAL, but if keyInfo is defined for RSA, ParameterType must be NULL.
> NULL is *the* ASN.1 NULL object, not an indication that the object can left out or is optional.
>
> OpenSC ASN.1 can handle NULL as SC_ASN1_NULL object which is a 05.
>
> 6.4.3 Public Elliptic Curve key objects
>
> PublicECKeyAttributes ::= SEQUENCE {
> value ObjectValue {ECPublicKeyChoice},
> keyInfo KeyInfo {Parameters, PublicKeyOperations} OPTIONAL,
> ... -- For future extensions
> }
>
> Here for EC the KeyInfo ParameterType = Parameters
>
> PKCS#15 also says:
>      ECPoint, Parameters
>          FROM ANSI-X9-62 {iso(1) member-body(2) us(840) ansi-x962(10045) module(4) 1}
>
> i.e. is is defined in ANSI-X9-62 (not having access to ANSI-X9-62, then next best definition is from PKCS#11)
>
> PKCS#11 says:
>
> The CKA_EC_PARAMS or CKA_ECDSA_PARAMS attribute value is known as the
> “EC domain parameters” and is defined in ANSI X9.62 as a choice of three parameter
> representation methods with the following syntax:
>
>      Parameters ::= CHOICE {
>          ecParameters ECParameters,
>          namedCurve CURVES.&id({CurveNames}),
>          implicitlyCA NULL
>      }
>
> Note that if no ecParameters, or namedCurve is available, the ASN.1 NULL must be used.
>
> IETF RFC 5480 also defines it as:
>
>      ECParameters ::= CHOICE {
>          namedCurve         OBJECT IDENTIFIER
>                 -- implicitCurve   NULL
>                 -- specifiedCurve  SpecifiedECDomain
>          }
> But for use in RFC 5480, only the namedCurve is allowed.
>
>
> With other pubkeys PKCS#15 say:
>
> 6.4.4 Public Diffie-Hellman key objects
>   uses DomainParameters
>
> 6.4.5 Public Digital Signature Algorithm objects
>   uses DomainParameters
>
> 6.4.6 Public KEA key objects
>   uses DomainParameters
>
> These are defined in:
> DiffieHellmanPublicNumber, DomainParameters
>      FROM ANSI-X9-42 {iso(1) member-body(2) us(840) ansi-x942(10046) module(5) 1}
>
> PKCS#11 says: "See the ANSI X9.42 standard for more information on X9.42 Diffie-Hellman domain parameters."
>
> I don't have a ANSI-X9-42 to see the ASN.1 encoding of the DomainParameters.
>
> Where are the PKCS#15 ASN.1 definitions For GOST?
>
> Comments?
> opensc
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel