Re: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

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

Re: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Viktor Tarasov-3
Hello Andreas,

in d4be8ec74 the encoding of public key "AS SPKI" was introduced in pkcs15init
as a generic method for all types of key.
This change is at the origin of recent issues for some cards.

The card specific pkcs15init drivers use this encoded data to store PUBLIC KEY object in it's card specific manner.
Currently we have no rapid possibility to review all card drivers and to adjust them for this change.

I propose you to return the common framework to the using of the previous "bare" encoding
and to implement in the sc-hsm pkcs15init driver the sm-hsm specific procedure to store public key,
in the same manner as it currently done to store the CERTIFICATE and DATA objects
https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-sc-hsm.c#L427


Kind regards,
Viktor.


Le 16/01/2014 09:59, astrand a écrit :
>
> Thanks, you were right. After pointing to the correct/built version of opensc-pkcs11.so, it works fine. Thanks for your help.
>
> —
> Reply to this email directly or view it on GitHub <https://github.com/OpenSC/OpenSC/issues/206#issuecomment-32451728>.
>


------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Viktor Tarasov-3
Hi Andreas,

when you change encoding for all key types here

then different card specific drivers,
that need their own manner to store objects, implemented as card specific emu_store_data callback
used by sc_pkcs15init_store_data() called here

these drivers will obtain the data blob that they do not get used to.

The patch from Douglas do not resolve this problem


What I propose you is to implement here:
your own handler to store public key.
In this handler you have an access to all pkcs15 data, including the public key object.
Here you can encode "AS SPKI" and store object as you like .


On Mon, Jan 20, 2014 at 8:43 AM, Andreas Schwier <[hidden email]> wrote:
I'm fine to change default encoding for RSA, but we need SPKI encoding
for public key objects, as the domain parameter are lost otherwise
between PKCS#15 und PKCS#11 layer.

Can you tell more about it ?
Where exactly in PKCS#11 this information is lost.



The only other drivers that are using EC public keys are the PIV driver
(Douglas looked at it) and the myEid driver (we informed Tony, but he
didn't respond.

Currently in pkcs15init the "AS SPKI" encoding is applied to all types of key,
not only for EC ones.



Kind regards,
Viktor.



------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Andreas Schwier (ML)
Hi Viktor,

I understand your point, but the issue is not about the SmartCard-HSM
storing the EC public key (which it doesn't anyway), it's about
sc_pkcs15init_generate_key() calling sc_pkcs15init_store_public_key() to
encode the new public key internally and thereby dropping domain
parameter for EC.

Without domain parameter in encoded EC public keys, we don't get
CKA_EC_PARAMS at the pkcs#11 layer for newly generated keys.

Initially I had a switch in sc_pkcs15init_store_public_key() so that
only EC public keys would be encoded as SPKI and all other public keys
as before. We should probably go back to that behaviour:

if (key.algorithm == SC_ALGORITHM_EC)
   r = sc_pkcs15_encode_pubkey_as_spki(p15card->card->ctx, &key,
&object->content.value, &object->content.len);
else
   r = sc_pkcs15_encode_pubkey(p15card->card->ctx, &key,
&object->content.value, &object->content.len);

PKCS#15 allows SPKI encoding for all public keys, which is what the code
does now. If card drivers need to decode the already encoded public key,
then they should use sc_pkcs15_decode_pubkey_with_param() rather than
sc_pkcs15_decode_pubkey(), as the former can detect if it's SPKI or a
plain format.

Andreas



Am 20.01.2014 11:09, schrieb Viktor Tarasov:

> Hi Andreas,
>
> when you change encoding for all key types here
> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1568
>
> then different card specific drivers,
> that need their own manner to store objects, implemented as card specific
> *emu_store_data* callback
> used by sc_pkcs15init_store_data() called here
> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1572
>
>
> these drivers will obtain the data blob that they do not get used to.
>
> The patch from Douglas do not resolve this problem
>
>
> What I propose you is to implement here:
> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-sc-hsm.c#L427
> your own handler to store public key.
> In this handler you have an access to all pkcs15 data, including the public
> key object.
> Here you can encode "AS SPKI" and store object as you like .
>
>
> On Mon, Jan 20, 2014 at 8:43 AM, Andreas Schwier <
> [hidden email]> wrote:
>
>> I'm fine to change default encoding for RSA, but we need SPKI encoding
>> for public key objects, as the domain parameter are lost otherwise
>> between PKCS#15 und PKCS#11 layer.
>>
>
> Can you tell more about it ?
> Where exactly in PKCS#11 this information is lost.
>
>
>
> The only other drivers that are using EC public keys are the PIV driver
>> (Douglas looked at it) and the myEid driver (we informed Tony, but he
>> didn't respond.
>>
>
> Currently in pkcs15init the "AS SPKI" encoding is applied to all types of
> key,
> not only for EC ones.
>
>
>
> Kind regards,
> Viktor.
>


--

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


------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Andreas Schwier (ML)
In reply to this post by Viktor Tarasov-3
Hi Viktor,

I've created a pull request to change from SPKI to plain format for all
non-EC keys.

Can you see from regression tests which drivers are affected by the
change to SPKI ?

Andreas

Am 20.01.2014 11:09, schrieb Viktor Tarasov:

> Hi Andreas,
>
> when you change encoding for all key types here
> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1568
>
> then different card specific drivers,
> that need their own manner to store objects, implemented as card specific
> *emu_store_data* callback
> used by sc_pkcs15init_store_data() called here
> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1572
>
>
> these drivers will obtain the data blob that they do not get used to.
>
> The patch from Douglas do not resolve this problem
>
>
> What I propose you is to implement here:
> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-sc-hsm.c#L427
> your own handler to store public key.
> In this handler you have an access to all pkcs15 data, including the public
> key object.
> Here you can encode "AS SPKI" and store object as you like .
>
>
> On Mon, Jan 20, 2014 at 8:43 AM, Andreas Schwier <
> [hidden email]> wrote:
>
>> I'm fine to change default encoding for RSA, but we need SPKI encoding
>> for public key objects, as the domain parameter are lost otherwise
>> between PKCS#15 und PKCS#11 layer.
>>
>
> Can you tell more about it ?
> Where exactly in PKCS#11 this information is lost.
>
>
>
> The only other drivers that are using EC public keys are the PIV driver
>> (Douglas looked at it) and the myEid driver (we informed Tony, but he
>> didn't respond.
>>
>
> Currently in pkcs15init the "AS SPKI" encoding is applied to all types of
> key,
> not only for EC ones.
>
>
>
> Kind regards,
> Viktor.
>


--

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


------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Douglas E. Engert
In reply to this post by Viktor Tarasov-3

On 1/19/2014 8:17 AM, Viktor Tarasov wrote:

> Hello Andreas,
>
> in d4be8ec74 the encoding of public key "AS SPKI" was introduced in pkcs15init
> as a generic method for all types of key.
> This change is at the origin of recent issues for some cards.
>
> The card specific pkcs15init drivers use this encoded data to store PUBLIC KEY object in it's card specific manner.
> Currently we have no rapid possibility to review all card drivers and to adjust them for this change.
>
> I propose you to return the common framework to the using of the previous "bare" encoding
> and to implement in the sc-hsm pkcs15init driver the sm-hsm specific procedure to store public key,
> in the same manner as it currently done to store the CERTIFICATE and DATA objects
> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-sc-hsm.c#L427

I would propose the following, which is my comment to #210:


A better fix would be to have some pkcs15-profile variable set
to say if SPKI should be used to write this public key
and may depend on the encryption type.

(1) This then puts the choice in the configuration
     for the card, as some cards may never support SPKI on the
     card, especially if the card itself tries to use the public key.
     Other cards may not care.

(2) It allows the card issuer to control if SPKI is to be written.

(3) It does not restrict the use of SPKI to EC only, and allows for other
     encryption types to use SPKI. (I have been asking in these notes
     if GOST could take advantage of the SPKI, but have gotten no responses)
     I suspect GOST could, as well as DSA.

(4) No code changes would be needed to start using SPKI, only
     changes to the profile.


The secondary issue with allowing SPKI to be written to the card with the newest code
is not with the new code, but trying to use a a card with SPKI with older OpenSC code,
or other vendor's middle-ware that is reading the public key that does not know how to
parse an SPKI read from the card.

This is a transition issue.

By adding the pkcs15-profile changes (1) above, as comments in the to be released
version, people could use it by modifying the profile  when they know there is
no backward compatibility issue in their environment.

For the vendors like CardContact, they would set the pkcs15-profile to use SPKI
even in the new code for EC. as there are appear to be no backward compatibility
issues, or the requirement to use the CardContact card is to use the latest OpenSC.

For other cards, the pkcs15-profile may never set SPKI, especially with RSA
as there is no additional information in the SPKI over the RAW format.

I say this is a temporary fix at best, as there are not a lot of cards use EC yet
The CardContact and the PIV that I know of. Any Oberthur card drivers using EC yet?


The PIV is emulating a PKCS#15, and gets the SPKI from the certificate on the card,
and does not use any of the pkcs15init code at all. But it does taking advantage of
the parsing the certificate to get the SPKI for both RSA and EC.

Can you come up with a change that uses the profile to determine if public keys
should be written based on the pkcs15-profile?




>
>
> Kind regards,
> Viktor.
>
>
> Le 16/01/2014 09:59, astrand a écrit :
>>
>> Thanks, you were right. After pointing to the correct/built version of opensc-pkcs11.so, it works fine. Thanks for your help.
>>
>> —
>> Reply to this email directly or view it on GitHub <https://github.com/OpenSC/OpenSC/issues/206#issuecomment-32451728>.
>>
>
>

--

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

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Douglas E. Engert
In reply to this post by Andreas Schwier (ML)


On 1/20/2014 7:29 AM, Andreas Schwier (ML) wrote:
> Hi Viktor,
>
> I've created a pull request to change from SPKI to plain format for all
> non-EC keys.
>
> Can you see from regression tests which drivers are affected by the
> change to SPKI ?

See my comments on #210 that start with:

The first part of the patch src/libopensc/pkcs15-pubkey.c
is not needed and should not be added. The original code
will work for SPKI and non SPKI, as PKCS#15 says all encryption
types support SPKI, which is determined by a starting sequence.

The second part of the patch src/pkcs15init/pkcs15-lib.c
should be considered temporary fix at best.

>
> Andreas
>
> Am 20.01.2014 11:09, schrieb Viktor Tarasov:
>> Hi Andreas,
>>
>> when you change encoding for all key types here
>> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1568
>>
>> then different card specific drivers,
>> that need their own manner to store objects, implemented as card specific
>> *emu_store_data* callback
>> used by sc_pkcs15init_store_data() called here
>> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1572
>>
>>
>> these drivers will obtain the data blob that they do not get used to.
>>
>> The patch from Douglas do not resolve this problem
>>
>>
>> What I propose you is to implement here:
>> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-sc-hsm.c#L427
>> your own handler to store public key.
>> In this handler you have an access to all pkcs15 data, including the public
>> key object.
>> Here you can encode "AS SPKI" and store object as you like .
>>
>>
>> On Mon, Jan 20, 2014 at 8:43 AM, Andreas Schwier <
>> [hidden email]> wrote:
>>
>>> I'm fine to change default encoding for RSA, but we need SPKI encoding
>>> for public key objects, as the domain parameter are lost otherwise
>>> between PKCS#15 und PKCS#11 layer.
>>>
>>
>> Can you tell more about it ?
>> Where exactly in PKCS#11 this information is lost.
>>
>>
>>
>> The only other drivers that are using EC public keys are the PIV driver
>>> (Douglas looked at it) and the myEid driver (we informed Tony, but he
>>> didn't respond.
>>>
>>
>> Currently in pkcs15init the "AS SPKI" encoding is applied to all types of
>> key,
>> not only for EC ones.
>>
>>
>>
>> Kind regards,
>> Viktor.
>>
>
>

--

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

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Viktor Tarasov-3
In reply to this post by Andreas Schwier (ML)
On Mon, Jan 20, 2014 at 11:52 AM, Andreas Schwier (ML) <[hidden email]> wrote:
I understand your point, but the issue is not about the SmartCard-HSM
storing the EC public key (which it doesn't anyway), it's about
sc_pkcs15init_generate_key() calling sc_pkcs15init_store_public_key() to
encode the new public key internally and thereby dropping domain
parameter for EC.

I still do not see sufficient reasons to break the public key encoding (once more: for all key types)
that the other cards have used  for ages.

 
Without domain parameter in encoded EC public keys, we don't get
CKA_EC_PARAMS at the pkcs#11 layer for newly generated keys.
 
Can you tell more about this ?
I still do not understand.

Ec-params have to be present in pkcs15-pubkey-info object's data, and not only encoded into the object's blob.
In pkcs15-framefork all PKCS#15 data and PKCS#15 objects are accessibles,
and so you have look for CKA_EC_PARAMS's value in the object's info data .

If ec-params data are not present in object's info after key generation,
you have to put them there (as it's done for GOST key),
but do not change the common procedures used by other cards.

 
PKCS#15 allows SPKI encoding for all public keys, which is what the code
does now. If card drivers need to decode the already encoded public key,
then they should use sc_pkcs15_decode_pubkey_with_param() rather than
sc_pkcs15_decode_pubkey(), as the former can detect if it's SPKI or a
plain format.

......

 

Andreas



Am 20.01.2014 11:09, schrieb Viktor Tarasov:
> Hi Andreas,
>
> when you change encoding for all key types here
> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1568
>
> then different card specific drivers,
> that need their own manner to store objects, implemented as card specific
> *emu_store_data* callback
> used by sc_pkcs15init_store_data() called here
> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1572
>
>
> these drivers will obtain the data blob that they do not get used to.
>
> The patch from Douglas do not resolve this problem
>
>
> What I propose you is to implement here:
> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-sc-hsm.c#L427
> your own handler to store public key.
> In this handler you have an access to all pkcs15 data, including the public
> key object.
> Here you can encode "AS SPKI" and store object as you like .
>
>
> On Mon, Jan 20, 2014 at 8:43 AM, Andreas Schwier <
> [hidden email]> wrote:
>
>> I'm fine to change default encoding for RSA, but we need SPKI encoding
>> for public key objects, as the domain parameter are lost otherwise
>> between PKCS#15 und PKCS#11 layer.
>>
>
> Can you tell more about it ?
> Where exactly in PKCS#11 this information is lost.
>
>
>
> The only other drivers that are using EC public keys are the PIV driver
>> (Douglas looked at it) and the myEid driver (we informed Tony, but he
>> didn't respond.
>>
>
> Currently in pkcs15init the "AS SPKI" encoding is applied to all types of
> key,
> not only for EC ones.
>
>
>
> Kind regards,
> Viktor.
>


--

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Schülerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone <a href="tel:%2B49%20571%2056149" value="+4957156149" target="_blank">+49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org



------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Andreas Schwier (ML)
>> Without domain parameter in encoded EC public keys, we don't get
>> CKA_EC_PARAMS at the pkcs#11 layer for newly generated keys.
>>
>
> Can you tell more about this ?
> I still do not understand.
>
> Ec-params have to be present in pkcs15-pubkey-info object's data, and not
> only encoded into the object's blob.
> In pkcs15-framefork all PKCS#15 data and PKCS#15 objects are accessibles,
> and so you *have* look for CKA_EC_PARAMS's value in the object's info data .
>
> If ec-params data are not present in object's info after key generation,
> you have to put them there (as it's done for GOST key),
> but do not change the common procedures used by other cards.
I've tried that, but the current code doesn't preserve all elements from
a fully initialized sc_pkcs15_pubkey return from the card driver. It
rather serializes the key into the encoded form and decodes it a little
later. In the old code, domain parameter for EC public keys are lost in
that transition.

Looking at framework-pkcs15.c@pkcs15_gen_keypair() it's calling
sc_pkcs15init_generate_key(), then obtains the pkcs15 public key object
with sc_pkcs15_find_pubkey_by_id() and finally calls
__pkcs15_create_pubkey_object().

In __pkcs15_create_pubkey_object() a call is made to
sc_pkcs15_read_pubkey() which reads the encoded public key from the card
or the content buffer.

So the code only works if the public key is fully written to the card
and then read back. As this code seem central to all card operations and
I didn't write the code I don't wanna touch it.

Apparently Douglas ran into the same problem when he created the public
key object from a certificate stored in the PIV card. He did a tweak by
adding the emulated element to sc_pkcs15_object. However he also
mentioned that this needs refactored out of the code.

Encoding ec_params for EC keys in pkcs15-pubkey-info is undefined: The
PKCS#15 ASN.1 module declares an import of Parameter from X9.62, however
Parameter is not defined there. You could try to squeeze
ECDomainParameter into the Keyinfo structure, however the more logical
way is to associate the domain parameter with the public key itself, as
it's done with SPKI.

A similar issues exists when the public key is generated using
sc_pkcs15emu_add_ec_pubkey(). For that call you need to provide the EC
Public Key in it's encoded form as it's later retrieved through
sc_pkcs15_read_pubkey().

So I still believe the current approach to encode the EC Public Key
using SPKI is conforming and correct.

We could of course argue if SPKI is the right format for RSA Public
Keys, but with the automatic detection of SPKI/plain key we shouldn't
have an issue.

I also support Douglas idea to get rid of sc_pkcs15_pubkey_ec.params, as
this duplicates information from sc_pkcs15_pubkey.alg_id.params.

>
>
>
>> PKCS#15 allows SPKI encoding for all public keys, which is what the code
>> does now. If card drivers need to decode the already encoded public key,
>> then they should use sc_pkcs15_decode_pubkey_with_param() rather than
>> sc_pkcs15_decode_pubkey(), as the former can detect if it's SPKI or a
>> plain format.
>>
>
> ......
>
>
>
>>
>> Andreas
>>
>>
>>
>> Am 20.01.2014 11:09, schrieb Viktor Tarasov:
>>> Hi Andreas,
>>>
>>> when you change encoding for all key types here
>>>
>> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1568
>>>
>>> then different card specific drivers,
>>> that need their own manner to store objects, implemented as card specific
>>> *emu_store_data* callback
>>> used by sc_pkcs15init_store_data() called here
>>>
>> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1572
>>>
>>>
>>> these drivers will obtain the data blob that they do not get used to.
>>>
>>> The patch from Douglas do not resolve this problem
>>>
>>>
>>> What I propose you is to implement here:
>>>
>> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-sc-hsm.c#L427
>>> your own handler to store public key.
>>> In this handler you have an access to all pkcs15 data, including the
>> public
>>> key object.
>>> Here you can encode "AS SPKI" and store object as you like .
>>>
>>>
>>> On Mon, Jan 20, 2014 at 8:43 AM, Andreas Schwier <
>>> [hidden email]> wrote:
>>>
>>>> I'm fine to change default encoding for RSA, but we need SPKI encoding
>>>> for public key objects, as the domain parameter are lost otherwise
>>>> between PKCS#15 und PKCS#11 layer.
>>>>
>>>
>>> Can you tell more about it ?
>>> Where exactly in PKCS#11 this information is lost.
>>>
>>>
>>>
>>> The only other drivers that are using EC public keys are the PIV driver
>>>> (Douglas looked at it) and the myEid driver (we informed Tony, but he
>>>> didn't respond.
>>>>
>>>
>>> Currently in pkcs15init the "AS SPKI" encoding is applied to all types of
>>> key,
>>> not only for EC ones.
>>>
>>>
>>>
>>> Kind regards,
>>> Viktor.
>>>
>>
>>
>> --
>>
>>     ---------    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
>>
>>
>


--

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


------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Douglas E. Engert
In reply to this post by Viktor Tarasov-3


On 1/20/2014 1:19 PM, Viktor Tarasov wrote:

> On Mon, Jan 20, 2014 at 11:52 AM, Andreas Schwier (ML) <[hidden email] <mailto:[hidden email]>> wrote:
>
>     I understand your point, but the issue is not about the SmartCard-HSM
>     storing the EC public key (which it doesn't anyway), it's about
>     sc_pkcs15init_generate_key() calling sc_pkcs15init_store_public_key() to
>     encode the new public key internally and thereby dropping domain
>     parameter for EC.
>
>
> I still do not see sufficient reasons to break the public key encoding (once more: for all key types)
> that the other cards have used  for ages.

I will agree with RSA, as there are not additional parameters.

>
>
>     Without domain parameter in encoded EC public keys, we don't get
>     CKA_EC_PARAMS at the pkcs#11 layer for newly generated keys.
>
> Can you tell more about this ?
> I still do not understand.
>
> Ec-params have to be present in pkcs15-pubkey-info object's data, and not only encoded into the object's blob.
> In pkcs15-framefork all PKCS#15 data and PKCS#15 objects are accessibles,
> and so you *have* look for CKA_EC_PARAMS's value in the object's info data .
>
> If ec-params data are not present in object's info after key generation,
> you have to put them there (as it's done for GOST key),

I would suggest that the GOST code could take advantage of the SPKI as well.
It looks like GOST has only one curve.

Whereas EC can have multiple curves, and the SPKI gives a common well
documented way to get them fro the SPKI. The SPKI is also part of the certificate,
  making it easy to get the SPKI from the certificate.

> but do not change the common procedures used by other cards.

GOST specific code all over the common procedures that could be simplified
if it could use the SPKI too.


>
>     PKCS#15 allows SPKI encoding for all public keys, which is what the code
>     does now. If card drivers need to decode the already encoded public key,
>     then they should use sc_pkcs15_decode_pubkey_with_param() rather than
>     sc_pkcs15_decode_pubkey(), as the former can detect if it's SPKI or a
>     plain format.
>
>
> ......
>
>
>     Andreas
>
>
>
>     Am 20.01.2014 11:09, schrieb Viktor Tarasov:
>      > Hi Andreas,
>      >
>      > when you change encoding for all key types here
>      > https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1568
>      >
>      > then different card specific drivers,
>      > that need their own manner to store objects, implemented as card specific
>      > *emu_store_data* callback
>      > used by sc_pkcs15init_store_data() called here
>      > https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1572
>      >
>      >
>      > these drivers will obtain the data blob that they do not get used to.
>      >
>      > The patch from Douglas do not resolve this problem
>      >
>      >
>      > What I propose you is to implement here:
>      > https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-sc-hsm.c#L427
>      > your own handler to store public key.
>      > In this handler you have an access to all pkcs15 data, including the public
>      > key object.
>      > Here you can encode "AS SPKI" and store object as you like .
>      >
>      >
>      > On Mon, Jan 20, 2014 at 8:43 AM, Andreas Schwier <
>      > [hidden email] <mailto:[hidden email]>> wrote:
>      >
>      >> I'm fine to change default encoding for RSA, but we need SPKI encoding
>      >> for public key objects, as the domain parameter are lost otherwise
>      >> between PKCS#15 und PKCS#11 layer.
>      >>
>      >
>      > Can you tell more about it ?
>      > Where exactly in PKCS#11 this information is lost.
>      >
>      >
>      >
>      > The only other drivers that are using EC public keys are the PIV driver
>      >> (Douglas looked at it) and the myEid driver (we informed Tony, but he
>      >> didn't respond.
>      >>
>      >
>      > Currently in pkcs15init the "AS SPKI" encoding is applied to all types of
>      > key,
>      > not only for EC ones.
>      >
>      >
>      >
>      > Kind regards,
>      > Viktor.
>      >
>
>
>     --
>
>          ---------    CardContact Software & System Consulting
>         |.##> <##.|   Andreas Schwier
>         |#       #|   Schülerweg 38
>         |#       #|   32429 Minden, Germany
>         |'##> <##'|   Phone +49 571 56149 <tel:%2B49%20571%2056149>
>          --------- http://www.cardcontact.de
>     http://www.tscons.de
>     http://www.openscdp.org
>
>

--

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

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Douglas E. Engert
In reply to this post by Andreas Schwier (ML)


On 1/20/2014 3:38 PM, Andreas Schwier (ML) wrote:

>>> Without domain parameter in encoded EC public keys, we don't get
>>> CKA_EC_PARAMS at the pkcs#11 layer for newly generated keys.
>>>
>>
>> Can you tell more about this ?
>> I still do not understand.
>>
>> Ec-params have to be present in pkcs15-pubkey-info object's data, and not
>> only encoded into the object's blob.
>> In pkcs15-framefork all PKCS#15 data and PKCS#15 objects are accessibles,
>> and so you *have* look for CKA_EC_PARAMS's value in the object's info data .
>>
>> If ec-params data are not present in object's info after key generation,
>> you have to put them there (as it's done for GOST key),
>> but do not change the common procedures used by other cards.
> I've tried that, but the current code doesn't preserve all elements from
> a fully initialized sc_pkcs15_pubkey return from the card driver.

A lot of this goes back to the original ANS1 algorithm code, that included
parameters, but since RSA had no parameter, this code was ignored.
As far as I can tell, GOST did not take advantage of this, and some
EC code did not either. You will note that the SPKI code does use this
and the parameters are stored in the algorithm parameters.


> It
> rather serializes the key into the encoded form and decodes it a little
> later. In the old code, domain parameter for EC public keys are lost in
> that transition.
>
> Looking at framework-pkcs15.c@pkcs15_gen_keypair() it's calling
> sc_pkcs15init_generate_key(), then obtains the pkcs15 public key object
> with sc_pkcs15_find_pubkey_by_id() and finally calls
> __pkcs15_create_pubkey_object().
>
> In __pkcs15_create_pubkey_object() a call is made to
> sc_pkcs15_read_pubkey() which reads the encoded public key from the card
> or the content buffer.
>
> So the code only works if the public key is fully written to the card
> and then read back. As this code seem central to all card operations and
> I didn't write the code I don't wanna touch it.

EC has many curves, and they must be on the card somewhere.

>
> Apparently Douglas ran into the same problem when he created the public
> key object from a certificate stored in the PIV card. He did a tweak by
> adding the emulated element to sc_pkcs15_object. However he also
> mentioned that this needs refactored out of the code.
>
> Encoding ec_params for EC keys in pkcs15-pubkey-info is undefined: The
> PKCS#15 ASN.1 module declares an import of Parameter from X9.62, however
> Parameter is not defined there. You could try to squeeze
> ECDomainParameter into the Keyinfo structure, however the more logical
> way is to associate the domain parameter with the public key itself, as
> it's done with SPKI.
>
> A similar issues exists when the public key is generated using
> sc_pkcs15emu_add_ec_pubkey(). For that call you need to provide the EC
> Public Key in it's encoded form as it's later retrieved through
> sc_pkcs15_read_pubkey().
>
> So I still believe the current approach to encode the EC Public Key
> using SPKI is conforming and correct.

I believe so too.

>
> We could of course argue if SPKI is the right format for RSA Public
> Keys, but with the automatic detection of SPKI/plain key we shouldn't
> have an issue.

It may not be, but PKCS#15 allows it, but our ASN1 is wrong.
So since none has used SPKI for RSA in the past, we don't need to address
RSA use of SPKI. (I may have to tweak the PIV driver as I was planing
on using that to simpliy its code.)

>
> I also support Douglas idea to get rid of sc_pkcs15_pubkey_ec.params, as
> this duplicates information from sc_pkcs15_pubkey.alg_id.params.

We should do it for GOST some time in the future too.

>
>>
>>
>>
>>> PKCS#15 allows SPKI encoding for all public keys, which is what the code
>>> does now. If card drivers need to decode the already encoded public key,
>>> then they should use sc_pkcs15_decode_pubkey_with_param() rather than
>>> sc_pkcs15_decode_pubkey(), as the former can detect if it's SPKI or a
>>> plain format.
>>>
>>
>> ......
>>
>>
>>
>>>
>>> Andreas
>>>
>>>
>>>
>>> Am 20.01.2014 11:09, schrieb Viktor Tarasov:
>>>> Hi Andreas,
>>>>
>>>> when you change encoding for all key types here
>>>>
>>> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1568
>>>>
>>>> then different card specific drivers,
>>>> that need their own manner to store objects, implemented as card specific
>>>> *emu_store_data* callback
>>>> used by sc_pkcs15init_store_data() called here
>>>>
>>> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1572
>>>>
>>>>
>>>> these drivers will obtain the data blob that they do not get used to.
>>>>
>>>> The patch from Douglas do not resolve this problem
>>>>
>>>>
>>>> What I propose you is to implement here:
>>>>
>>> https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-sc-hsm.c#L427
>>>> your own handler to store public key.
>>>> In this handler you have an access to all pkcs15 data, including the
>>> public
>>>> key object.
>>>> Here you can encode "AS SPKI" and store object as you like .
>>>>
>>>>
>>>> On Mon, Jan 20, 2014 at 8:43 AM, Andreas Schwier <
>>>> [hidden email]> wrote:
>>>>
>>>>> I'm fine to change default encoding for RSA, but we need SPKI encoding
>>>>> for public key objects, as the domain parameter are lost otherwise
>>>>> between PKCS#15 und PKCS#11 layer.
>>>>>
>>>>
>>>> Can you tell more about it ?
>>>> Where exactly in PKCS#11 this information is lost.
>>>>
>>>>
>>>>
>>>> The only other drivers that are using EC public keys are the PIV driver
>>>>> (Douglas looked at it) and the myEid driver (we informed Tony, but he
>>>>> didn't respond.
>>>>>
>>>>
>>>> Currently in pkcs15init the "AS SPKI" encoding is applied to all types of
>>>> key,
>>>> not only for EC ones.
>>>>
>>>>
>>>>
>>>> Kind regards,
>>>> Viktor.
>>>>
>>>
>>>
>>> --
>>>
>>>      ---------    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
>>>
>>>
>>
>
>

--

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

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Viktor Tarasov-3
On Mon, Jan 20, 2014 at 11:26 PM, Douglas E. Engert <[hidden email]> wrote:
On 1/20/2014 3:38 PM, Andreas Schwier (ML) wrote:
Without domain parameter in encoded EC public keys, we don't get
CKA_EC_PARAMS at the pkcs#11 layer for newly generated keys.


Can you tell more about this ?
I still do not understand.

Ec-params have to be present in pkcs15-pubkey-info object's data, and not
only encoded into the object's blob.
In pkcs15-framefork all PKCS#15 data and PKCS#15 objects are accessibles,
and so you *have* look for CKA_EC_PARAMS's value in the object's info data .

If ec-params data are not present in object's info after key generation,
you have to put them there (as it's done for GOST key),
but do not change the common procedures used by other cards.
I've tried that, but the current code doesn't preserve all elements from
a fully initialized sc_pkcs15_pubkey return from the card driver.


So, I resume:
you were missing EC-PARAMS in pkcs#11 part,
and you have changed the framework used by all cards to store the object's blob on-card .

Just to remind that the manner in which card stores object blob is not in PKCS#15 specification.
Specification concerns only the objects descriptors.
And so, there is no reason, justified by specification conformity, to break the common pkcs15init  .

I cannot believe that it's not possible to transfer domain data from card driver to the other levels using
the sc_pkcs15_pubkey or sc_pkcs15_pubkey_info.
If something EC specific is missing in these structures, you can always add/change/improve it,
but do not change framework that have very little with your need .


 
A lot of this goes back to the original ANS1 algorithm code, that included
parameters, but since RSA had no parameter, this code was ignored.
As far as I can tell, GOST did not take advantage of this, and some
EC code did not either. You will note that the SPKI code does use this
and the parameters are stored in the algorithm parameters.


It
rather serializes the key into the encoded form and decodes it a little
later. In the old code, domain parameter for EC public keys are lost in
that transition.

Looking at framework-pkcs15.c@pkcs15_gen_keypair() it's calling
sc_pkcs15init_generate_key(), then obtains the pkcs15 public key object
with sc_pkcs15_find_pubkey_by_id() and finally calls
__pkcs15_create_pubkey_object().

In __pkcs15_create_pubkey_object() a call is made to
sc_pkcs15_read_pubkey() which reads the encoded public key from the card
or the content buffer.

So the code only works if the public key is fully written to the card
and then read back. As this code seem central to all card operations and
I didn't write the code I don't wanna touch it.


I suppose that EC-PARAMS, that you are looking for in pkcs11, are actually stored somehow on card, isn't it?
Why do you not implement the read_public_key() handler 
and leave aside the common init framework.

 

EC has many curves, and they must be on the card somewhere.


Apparently Douglas ran into the same problem when he created the public
key object from a certificate stored in the PIV card. He did a tweak by
adding the emulated element to sc_pkcs15_object. However he also
mentioned that this needs refactored out of the code.

Encoding ec_params for EC keys in pkcs15-pubkey-info is undefined: The
PKCS#15 ASN.1 module declares an import of Parameter from X9.62, however
Parameter is not defined there. You could try to squeeze
ECDomainParameter into the Keyinfo structure, however the more logical
way is to associate the domain parameter with the public key itself, as
it's done with SPKI.

A similar issues exists when the public key is generated using
sc_pkcs15emu_add_ec_pubkey(). For that call you need to provide the EC
Public Key in it's encoded form as it's later retrieved through
sc_pkcs15_read_pubkey().


I still believe that object's blob should not be the unique place to store the object's attributes.

 

So I still believe the current approach to encode the EC Public Key
using SPKI is conforming and correct.

I believe so too.

I do not agree.
Conformity of this approach is limited by PKCS#15 data itself,
limited by the case when ObjectValue is directly encoded into PKCS#15 (PukDF) descriptors.
You cannot impose to the cards the manner they use to store object's blob,
it can be in EFs, SDOs, derived from other data, ...
And it's precisely here that the current pkcs15init is broken .


 

We could of course argue if SPKI is the right format for RSA Public
Keys, but with the automatic detection of SPKI/plain key we shouldn't
have an issue.

It may not be, but PKCS#15 allows it, but our ASN1 is wrong.
So since none has used SPKI for RSA in the past, we don't need to address
RSA use of SPKI. (I may have to tweak the PIV driver as I was planing
on using that to simpliy its code.)

I do not agree,
the main task of ASN1 is to encode/parse the PKCS#15 descriptors according to specification.
And it do this.
All the rest are the tools used by different frameworks, cards, etc in particular circumstances.
This part is out of specification scope, and so it cannot be wrong.

If you are missing something -- create new, update existing -- but don't break.


Finally,
I propose you to send me the card (I will return it back afterwards) to understand better you problem.
So that our dialog will be more substantial.





I also support Douglas idea to get rid of sc_pkcs15_pubkey_ec.params, as
this duplicates information from sc_pkcs15_pubkey.alg_id.params.

We should do it for GOST some time in the future too.






PKCS#15 allows SPKI encoding for all public keys, which is what the code
does now. If card drivers need to decode the already encoded public key,
then they should use sc_pkcs15_decode_pubkey_with_param() rather than
sc_pkcs15_decode_pubkey(), as the former can detect if it's SPKI or a
plain format.


......




Andreas



Am 20.01.2014 11:09, schrieb Viktor Tarasov:
Hi Andreas,

when you change encoding for all key types here

https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1568

then different card specific drivers,
that need their own manner to store objects, implemented as card specific
*emu_store_data* callback
used by sc_pkcs15init_store_data() called here

https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1572


these drivers will obtain the data blob that they do not get used to.

The patch from Douglas do not resolve this problem


What I propose you is to implement here:

https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-sc-hsm.c#L427
your own handler to store public key.
In this handler you have an access to all pkcs15 data, including the
public
key object.
Here you can encode "AS SPKI" and store object as you like .


On Mon, Jan 20, 2014 at 8:43 AM, Andreas Schwier <
[hidden email]> wrote:

I'm fine to change default encoding for RSA, but we need SPKI encoding
for public key objects, as the domain parameter are lost otherwise
between PKCS#15 und PKCS#11 layer.


Can you tell more about it ?
Where exactly in PKCS#11 this information is lost.



The only other drivers that are using EC public keys are the PIV driver
(Douglas looked at it) and the myEid driver (we informed Tony, but he
didn't respond.


Currently in pkcs15init the "AS SPKI" encoding is applied to all types of
key,
not only for EC ones.



Kind regards,
Viktor.



--

     ---------    CardContact Software & System Consulting
    |.##> <##.|   Andreas Schwier
    |#       #|   Schülerweg 38
    |#       #|   32429 Minden, Germany
    |'##> <##'|   Phone <a href="tel:%2B49%20571%2056149" value="+4957156149" target="_blank">+49 571 56149
     ---------    http://www.cardcontact.de
                  http://www.tscons.de
                  http://www.openscdp.org






--

 Douglas E. Engert  <[hidden email]> <[hidden email]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 <a href="tel:%28630%29%20252-5444" value="+16302525444" target="_blank">(630) 252-5444


Kind regards,
Viktor.


------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Andreas Schwier (ML)
Hi Viktor,

> Finally,
> I propose you to send me the card (I will return it back afterwards) to
> understand better you problem.
> So that our dialog will be more substantial.

You should have received a card around January 2012. I did sent it to
your KEYNECTIS business address.
Let me know I you need a new card.

Andreas


------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Douglas E. Engert
In reply to this post by Viktor Tarasov-3


On 1/21/2014 7:18 AM, Viktor Tarasov wrote:

> On Mon, Jan 20, 2014 at 11:26 PM, Douglas E. Engert <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 1/20/2014 3:38 PM, Andreas Schwier (ML) wrote:
>
>                 Without domain parameter in encoded EC public keys, we don't get
>                 CKA_EC_PARAMS at the pkcs#11 layer for newly generated keys.
>
>
>             Can you tell more about this ?
>             I still do not understand.
>
>             Ec-params have to be present in pkcs15-pubkey-info object's data, and not
>             only encoded into the object's blob.
>             In pkcs15-framefork all PKCS#15 data and PKCS#15 objects are accessibles,
>             and so you *have* look for CKA_EC_PARAMS's value in the object's info data .
>
>             If ec-params data are not present in object's info after key generation,
>             you have to put them there (as it's done for GOST key),
>             but do not change the common procedures used by other cards.
>
>         I've tried that, but the current code doesn't preserve all elements from
>         a fully initialized sc_pkcs15_pubkey return from the card driver.
>
>
>
> So, I resume:
> you were missing EC-PARAMS in pkcs#11 part,
> and you have changed the framework used by all cards to store the object's blob on-card .
>
> Just to remind that the manner in which card stores object blob is not in PKCS#15 specification.

I disagree.

PKCS#15 v1.1

Section 6.2

    In the IC card case, the intention is that EF(ODF) shall consist of a number of data objects
    (records) of type PKCS15Objects, representing different object types. Each data object
    should in the normal case reference a file containing a directory of objects of the
    particular type. Since the path alternative of the PathOrObject type is recommended, this
    will result in a record-oriented ODF, which simplifies updating.

Section 5 card file format

    ... It may well be that a
    particular card is able to store the information described here in a more compact or efficient
    way than another card, however the “card-edge” representation of the information shall be
    the same in both cases. This document is therefore a “card-edge” specification.


So it does talk about card file formats, but gives the card vendor other options.


> Specification concerns only the objects descriptors.

But PKCS#15 does allow for a CHOICE of RAW or SPKI formats for public keys.
and is thus part of the PKCS#15 specifications, and should be allowed.

> And so, there is no reason, justified by specification conformity, to break the common pkcs15init  .

I agree that the CHOICE to use SPKI should not be the default, but rather a parameter
in the profile used when writing the public key. But the code whae reading the public key
should accept either, that was the point of defining the ASN1 CHOICE.

>
> I cannot believe that it's not possible to transfer domain data from card driver

You are mising the point. The domain data is not in the card driver, it is in the card,
as part of the public key. (RSA does not have any "domain data", EC has parameters, and is usually
defined by a CURVE OID)


> to the other levels using
> the sc_pkcs15_pubkey or sc_pkcs15_pubkey_info.
> If something EC specific is missing in these structures, you can always add/change/improve it,
> but do not change framework that have very little with your need .

I disagree the changes are EC in general, not just for the CardContact cards.

The ability to write a SPKI is in PKCS#15 for many encryption types.
The reason to do this is the RAW format of a public key is missing "DomainData",
"DomainParameters, or "Parameters" where it is in the SPKI.

SPKI is well defined, and is in the certificate. It is the obvious way to
store a public key.

PKCS#15 was define in 2000, when EC was still being developed. PKCS#15 says:

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




What we should be arguing is how to leave the default format as RAW when writing public keys.


Viktor, You have not commented on the proposal to make this CHOICE during writting via the
pkcs15init profile which would default to using old RAW format, but allow for the use of
SPKI at the discretion of the card provisioner.

>
>
>     A lot of this goes back to the original ANS1 algorithm code, that included
>     parameters, but since RSA had no parameter, this code was ignored.
>     As far as I can tell, GOST did not take advantage of this, and some
>     EC code did not either. You will note that the SPKI code does use this
>     and the parameters are stored in the algorithm parameters.
>
>
>         It
>         rather serializes the key into the encoded form and decodes it a little
>         later. In the old code, domain parameter for EC public keys are lost in
>         that transition.
>
>         Looking at framework-pkcs15.c@pkcs15_gen___keypair() it's calling
>         sc_pkcs15init_generate_key(), then obtains the pkcs15 public key object
>         with sc_pkcs15_find_pubkey_by_id() and finally calls
>         __pkcs15_create_pubkey_object(__).
>
>         In __pkcs15_create_pubkey_object(__) a call is made to
>         sc_pkcs15_read_pubkey() which reads the encoded public key from the card
>         or the content buffer.
>
>         So the code only works if the public key is fully written to the card
>         and then read back. As this code seem central to all card operations and
>         I didn't write the code I don't wanna touch it.
>
>
>
> I suppose that EC-PARAMS, that you are looking for in pkcs11, are actually stored somehow on card, isn't it?

Maybe it is accessable on the card, but may also be only in a certificate in the SPKI format.

> Why do you not implement the /read_public_key()/ handler

Because the read_public_key does not necessarily read the parameters.

> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/opensc.h#L656
> and leave aside the common init framework.
>
>
>
>     EC has many curves, and they must be on the card somewhere.
>
>
>         Apparently Douglas ran into the same problem when he created the public
>         key object from a certificate stored in the PIV card. He did a tweak by
>         adding the emulated element to sc_pkcs15_object. However he also
>         mentioned that this needs refactored out of the code.
>
>         Encoding ec_params for EC keys in pkcs15-pubkey-info is undefined: The
>         PKCS#15 ASN.1 module declares an import of Parameter from X9.62, however
>         Parameter is not defined there. You could try to squeeze
>         ECDomainParameter into the Keyinfo structure, however the more logical
>         way is to associate the domain parameter with the public key itself, as
>         it's done with SPKI.
>
>         A similar issues exists when the public key is generated using
>         sc_pkcs15emu_add_ec_pubkey(). For that call you need to provide the EC
>         Public Key in it's encoded form as it's later retrieved through
>         sc_pkcs15_read_pubkey().
>
>
>
> I still believe that object's blob should not be the unique place to store the object's attributes.

PKCS#15 allows for "Paramaters", "DomaminData", "DomainParamters" to be stored in the
keyInfo in the Public[RSA|EC|DH|DSA]KeyAttributes. keyInfo is optional.
(RSA has no parameters, and is NULL in the keyInfo)

I don't believe OpenSC implemeted the parameters in kinfo, be we have implemented the parameters in SPKI.
So yes there is another way, but the use of SPKI is the most straight forward
way to do it, as it SPKI is also used in certificates.

>
>
>         So I still believe the current approach to encode the EC Public Key
>         using SPKI is conforming and correct.
>
>
>     I believe so too.
>
>
> I do not agree.
> Conformity of this approach is limited by PKCS#15 data itself,
> limited by the case when ObjectValue is directly encoded into PKCS#15 (PukDF) descriptors.
> You cannot impose to the cards the manner they use to store object's blob,
> it can be in EFs, SDOs, derived from other data, ...
> And it's precisely here that the current pkcs15init is broken .

Then make it optional, via the profile.

>
>
>
>         We could of course argue if SPKI is the right format for RSA Public
>         Keys, but with the automatic detection of SPKI/plain key we shouldn't
>         have an issue.
>
>
>     It may not be, but PKCS#15 allows it, but our ASN1 is wrong.
>     So since none has used SPKI for RSA in the past, we don't need to address
>     RSA use of SPKI. (I may have to tweak the PIV driver as I was planing
>     on using that to simpliy its code.)
>
>
> I do not agree,
> the main task of ASN1 is to encode/parse the PKCS#15 descriptors according to specification.
> And it do this.
> All the rest are the tools used by different frameworks, cards, etc in particular circumstances.
> This part is out of specification scope, and so it cannot be wrong.
>
> If you are missing something -- create new, update existing -- but don't break.
>
>
> Finally,
> I propose you to send me the card (I will return it back afterwards) to understand better you problem.
> So that our dialog will be more substantial.
>
>
>
>
>
>         I also support Douglas idea to get rid of sc_pkcs15_pubkey_ec.params, as
>         this duplicates information from sc_pkcs15_pubkey.alg_id.__params.
>
>
>     We should do it for GOST some time in the future too.
>
>
>
>
>
>
>                 PKCS#15 allows SPKI encoding for all public keys, which is what the code
>                 does now. If card drivers need to decode the already encoded public key,
>                 then they should use sc_pkcs15_decode_pubkey_with___param() rather than
>                 sc_pkcs15_decode_pubkey(), as the former can detect if it's SPKI or a
>                 plain format.
>
>
>             ......
>
>
>
>
>                 Andreas
>
>
>
>                 Am 20.01.2014 11:09, schrieb Viktor Tarasov:
>
>                     Hi Andreas,
>
>                     when you change encoding for all key types here
>
>                 https://github.com/OpenSC/__OpenSC/blob/master/src/__pkcs15init/pkcs15-lib.c#L1568 <https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1568>
>
>
>                     then different card specific drivers,
>                     that need their own manner to store objects, implemented as card specific
>                     *emu_store_data* callback
>                     used by sc_pkcs15init_store_data() called here
>
>                 https://github.com/OpenSC/__OpenSC/blob/master/src/__pkcs15init/pkcs15-lib.c#L1572 <https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1572>
>
>
>
>                     these drivers will obtain the data blob that they do not get used to.
>
>                     The patch from Douglas do not resolve this problem
>
>
>                     What I propose you is to implement here:
>
>                 https://github.com/OpenSC/__OpenSC/blob/master/src/__pkcs15init/pkcs15-sc-hsm.c#__L427 <https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-sc-hsm.c#L427>
>
>                     your own handler to store public key.
>                     In this handler you have an access to all pkcs15 data, including the
>
>                 public
>
>                     key object.
>                     Here you can encode "AS SPKI" and store object as you like .
>
>
>                     On Mon, Jan 20, 2014 at 8:43 AM, Andreas Schwier <
>                     [hidden email] <mailto:[hidden email]>__> wrote:
>
>                         I'm fine to change default encoding for RSA, but we need SPKI encoding
>                         for public key objects, as the domain parameter are lost otherwise
>                         between PKCS#15 und PKCS#11 layer.
>
>
>                     Can you tell more about it ?
>                     Where exactly in PKCS#11 this information is lost.
>
>
>
>                     The only other drivers that are using EC public keys are the PIV driver
>
>                         (Douglas looked at it) and the myEid driver (we informed Tony, but he
>                         didn't respond.
>
>
>                     Currently in pkcs15init the "AS SPKI" encoding is applied to all types of
>                     key,
>                     not only for EC ones.
>
>
>
>                     Kind regards,
>                     Viktor.
>
>
>
>                 --
>
>                       ---------    CardContact Software & System Consulting
>                      |.##> <##.|   Andreas Schwier
>                      |#       #|   Schülerweg 38
>                      |#       #|   32429 Minden, Germany
>                      |'##> <##'|   Phone +49 571 56149 <tel:%2B49%20571%2056149>
>                       --------- http://www.cardcontact.de
>                 http://www.tscons.de
>                 http://www.openscdp.org
>
>
>
>
>
>
>     --
>
>       Douglas E. Engert  <[hidden email] <mailto:[hidden email]>> <[hidden email] <mailto:[hidden email]>>
>       Argonne National Laboratory
>       9700 South Cass Avenue
>       Argonne, Illinois  60439
>     (630) 252-5444 <tel:%28630%29%20252-5444>
>
>
>
> Kind regards,
> Viktor.
>

--

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

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Douglas E. Engert
In reply to this post by Viktor Tarasov-3
Tow more points.

(1)  The topic of this thread deals with the engine.
The user's problem was he was writing to the card using the latest git version
but using the OS version of OpenSC from the engine. The OS version did not have
all the changes need to read SPKI.

Keeping the default of not using SPKI, and adding options to the profile
would address this issue of using new features on the card with older
versions of OpenSC. And allow for a transition time controlled by the
users of OpenSC.

(2)
Viktor,
Is there a document describing the ASN1 for GOST with SPKI and/or PKCS#15?



On 1/21/2014 7:18 AM, Viktor Tarasov wrote:

> On Mon, Jan 20, 2014 at 11:26 PM, Douglas E. Engert <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 1/20/2014 3:38 PM, Andreas Schwier (ML) wrote:
>
>                 Without domain parameter in encoded EC public keys, we don't get
>                 CKA_EC_PARAMS at the pkcs#11 layer for newly generated keys.
>
>
>             Can you tell more about this ?
>             I still do not understand.
>
>             Ec-params have to be present in pkcs15-pubkey-info object's data, and not
>             only encoded into the object's blob.
>             In pkcs15-framefork all PKCS#15 data and PKCS#15 objects are accessibles,
>             and so you *have* look for CKA_EC_PARAMS's value in the object's info data .
>
>             If ec-params data are not present in object's info after key generation,
>             you have to put them there (as it's done for GOST key),
>             but do not change the common procedures used by other cards.
>
>         I've tried that, but the current code doesn't preserve all elements from
>         a fully initialized sc_pkcs15_pubkey return from the card driver.
>
>
>
> So, I resume:
> you were missing EC-PARAMS in pkcs#11 part,
> and you have changed the framework used by all cards to store the object's blob on-card .
>
> Just to remind that the manner in which card stores object blob is not in PKCS#15 specification.
> Specification concerns only the objects descriptors.
> And so, there is no reason, justified by specification conformity, to break the common pkcs15init  .
>
> I cannot believe that it's not possible to transfer domain data from card driver to the other levels using
> the sc_pkcs15_pubkey or sc_pkcs15_pubkey_info.
> If something EC specific is missing in these structures, you can always add/change/improve it,
> but do not change framework that have very little with your need .
>
>
>     A lot of this goes back to the original ANS1 algorithm code, that included
>     parameters, but since RSA had no parameter, this code was ignored.
>     As far as I can tell, GOST did not take advantage of this, and some
>     EC code did not either. You will note that the SPKI code does use this
>     and the parameters are stored in the algorithm parameters.
>
>
>         It
>         rather serializes the key into the encoded form and decodes it a little
>         later. In the old code, domain parameter for EC public keys are lost in
>         that transition.
>
>         Looking at framework-pkcs15.c@pkcs15_gen___keypair() it's calling
>         sc_pkcs15init_generate_key(), then obtains the pkcs15 public key object
>         with sc_pkcs15_find_pubkey_by_id() and finally calls
>         __pkcs15_create_pubkey_object(__).
>
>         In __pkcs15_create_pubkey_object(__) a call is made to
>         sc_pkcs15_read_pubkey() which reads the encoded public key from the card
>         or the content buffer.
>
>         So the code only works if the public key is fully written to the card
>         and then read back. As this code seem central to all card operations and
>         I didn't write the code I don't wanna touch it.
>
>
>
> I suppose that EC-PARAMS, that you are looking for in pkcs11, are actually stored somehow on card, isn't it?
> Why do you not implement the /read_public_key()/ handler
> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/opensc.h#L656
> and leave aside the common init framework.
>
>
>
>     EC has many curves, and they must be on the card somewhere.
>
>
>         Apparently Douglas ran into the same problem when he created the public
>         key object from a certificate stored in the PIV card. He did a tweak by
>         adding the emulated element to sc_pkcs15_object. However he also
>         mentioned that this needs refactored out of the code.
>
>         Encoding ec_params for EC keys in pkcs15-pubkey-info is undefined: The
>         PKCS#15 ASN.1 module declares an import of Parameter from X9.62, however
>         Parameter is not defined there. You could try to squeeze
>         ECDomainParameter into the Keyinfo structure, however the more logical
>         way is to associate the domain parameter with the public key itself, as
>         it's done with SPKI.
>
>         A similar issues exists when the public key is generated using
>         sc_pkcs15emu_add_ec_pubkey(). For that call you need to provide the EC
>         Public Key in it's encoded form as it's later retrieved through
>         sc_pkcs15_read_pubkey().
>
>
>
> I still believe that object's blob should not be the unique place to store the object's attributes.
>
>
>         So I still believe the current approach to encode the EC Public Key
>         using SPKI is conforming and correct.
>
>
>     I believe so too.
>
>
> I do not agree.
> Conformity of this approach is limited by PKCS#15 data itself,
> limited by the case when ObjectValue is directly encoded into PKCS#15 (PukDF) descriptors.
> You cannot impose to the cards the manner they use to store object's blob,
> it can be in EFs, SDOs, derived from other data, ...
> And it's precisely here that the current pkcs15init is broken .
>
>
>
>         We could of course argue if SPKI is the right format for RSA Public
>         Keys, but with the automatic detection of SPKI/plain key we shouldn't
>         have an issue.
>
>
>     It may not be, but PKCS#15 allows it, but our ASN1 is wrong.
>     So since none has used SPKI for RSA in the past, we don't need to address
>     RSA use of SPKI. (I may have to tweak the PIV driver as I was planing
>     on using that to simpliy its code.)
>
>
> I do not agree,
> the main task of ASN1 is to encode/parse the PKCS#15 descriptors according to specification.
> And it do this.
> All the rest are the tools used by different frameworks, cards, etc in particular circumstances.
> This part is out of specification scope, and so it cannot be wrong.
>
> If you are missing something -- create new, update existing -- but don't break.
>
>
> Finally,
> I propose you to send me the card (I will return it back afterwards) to understand better you problem.
> So that our dialog will be more substantial.
>
>
>
>
>
>         I also support Douglas idea to get rid of sc_pkcs15_pubkey_ec.params, as
>         this duplicates information from sc_pkcs15_pubkey.alg_id.__params.
>
>
>     We should do it for GOST some time in the future too.
>
>
>
>
>
>
>                 PKCS#15 allows SPKI encoding for all public keys, which is what the code
>                 does now. If card drivers need to decode the already encoded public key,
>                 then they should use sc_pkcs15_decode_pubkey_with___param() rather than
>                 sc_pkcs15_decode_pubkey(), as the former can detect if it's SPKI or a
>                 plain format.
>
>
>             ......
>
>
>
>
>                 Andreas
>
>
>
>                 Am 20.01.2014 11:09, schrieb Viktor Tarasov:
>
>                     Hi Andreas,
>
>                     when you change encoding for all key types here
>
>                 https://github.com/OpenSC/__OpenSC/blob/master/src/__pkcs15init/pkcs15-lib.c#L1568 <https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1568>
>
>
>                     then different card specific drivers,
>                     that need their own manner to store objects, implemented as card specific
>                     *emu_store_data* callback
>                     used by sc_pkcs15init_store_data() called here
>
>                 https://github.com/OpenSC/__OpenSC/blob/master/src/__pkcs15init/pkcs15-lib.c#L1572 <https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1572>
>
>
>
>                     these drivers will obtain the data blob that they do not get used to.
>
>                     The patch from Douglas do not resolve this problem
>
>
>                     What I propose you is to implement here:
>
>                 https://github.com/OpenSC/__OpenSC/blob/master/src/__pkcs15init/pkcs15-sc-hsm.c#__L427 <https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-sc-hsm.c#L427>
>
>                     your own handler to store public key.
>                     In this handler you have an access to all pkcs15 data, including the
>
>                 public
>
>                     key object.
>                     Here you can encode "AS SPKI" and store object as you like .
>
>
>                     On Mon, Jan 20, 2014 at 8:43 AM, Andreas Schwier <
>                     [hidden email] <mailto:[hidden email]>__> wrote:
>
>                         I'm fine to change default encoding for RSA, but we need SPKI encoding
>                         for public key objects, as the domain parameter are lost otherwise
>                         between PKCS#15 und PKCS#11 layer.
>
>
>                     Can you tell more about it ?
>                     Where exactly in PKCS#11 this information is lost.
>
>
>
>                     The only other drivers that are using EC public keys are the PIV driver
>
>                         (Douglas looked at it) and the myEid driver (we informed Tony, but he
>                         didn't respond.
>
>
>                     Currently in pkcs15init the "AS SPKI" encoding is applied to all types of
>                     key,
>                     not only for EC ones.
>
>
>
>                     Kind regards,
>                     Viktor.
>
>
>
>                 --
>
>                       ---------    CardContact Software & System Consulting
>                      |.##> <##.|   Andreas Schwier
>                      |#       #|   Schülerweg 38
>                      |#       #|   32429 Minden, Germany
>                      |'##> <##'|   Phone +49 571 56149 <tel:%2B49%20571%2056149>
>                       --------- http://www.cardcontact.de
>                 http://www.tscons.de
>                 http://www.openscdp.org
>
>
>
>
>
>
>     --
>
>       Douglas E. Engert  <[hidden email] <mailto:[hidden email]>> <[hidden email] <mailto:[hidden email]>>
>       Argonne National Laboratory
>       9700 South Cass Avenue
>       Argonne, Illinois  60439
>     (630) 252-5444 <tel:%28630%29%20252-5444>
>
>
>
> Kind regards,
> Viktor.
>

--

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

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Viktor Tarasov-3
In reply to this post by Douglas E. Engert
On Tue, Jan 21, 2014 at 4:55 PM, Douglas E. Engert <[hidden email]> wrote:
On 1/21/2014 7:18 AM, Viktor Tarasov wrote:
On Mon, Jan 20, 2014 at 11:26 PM, Douglas E. Engert <[hidden email] <mailto:[hidden email]>> wrote:

    On 1/20/2014 3:38 PM, Andreas Schwier (ML) wrote:

                Without domain parameter in encoded EC public keys, we don't get
                CKA_EC_PARAMS at the pkcs#11 layer for newly generated keys.


            Can you tell more about this ?
            I still do not understand.

            Ec-params have to be present in pkcs15-pubkey-info object's data, and not
            only encoded into the object's blob.
            In pkcs15-framefork all PKCS#15 data and PKCS#15 objects are accessibles,
            and so you *have* look for CKA_EC_PARAMS's value in the object's info data .

            If ec-params data are not present in object's info after key generation,
            you have to put them there (as it's done for GOST key),
            but do not change the common procedures used by other cards.

        I've tried that, but the current code doesn't preserve all elements from
        a fully initialized sc_pkcs15_pubkey return from the card driver.



So, I resume:
you were missing EC-PARAMS in pkcs#11 part,
and you have changed the framework used by all cards to store the object's blob on-card .

Just to remind that the manner in which card stores object blob is not in PKCS#15 specification.

I disagree.

PKCS#15 v1.1

Section 6.2

   In the IC card case, the intention is that EF(ODF) shall consist of a number of data objects
   (records) of type PKCS15Objects, representing different object types. Each data object
   should in the normal case reference a file containing a directory of objects of the
   particular type. Since the path alternative of the PathOrObject type is recommended, this
   will result in a record-oriented ODF, which simplifies updating.

ODF is a part of PKCS#15 file structure. We are not talking about it.

For exemple:
EF(PuKDF) -- "Public Key Directory File -- is a part of PKCS#15,
but some EF that contains the blob of key is not.

Public key blob can be a part of PKCS#15 specification if it is included into PuKDF as 'direct' value.
In this case the argues about 'raw' or 'spki' could take place.
 
 

Section 5 card file format

   ... It may well be that a
   particular card is able to store the information described here in a more compact or efficient
   way than another card, however the “card-edge” representation of the information shall be
   the same in both cases. This document is therefore a “card-edge” specification.

Once more, it's going about files that represent the PKCS#15 file system,
and not about the manner in which crypto or other objects are stored on card.

 


So it does talk about card file formats, but gives the card vendor other options.



Specification concerns only the objects descriptors.

But PKCS#15 does allow for a CHOICE of RAW or SPKI formats for public keys.
and is thus part of the PKCS#15 specifications, and should be allowed.


Choice of RAW or SPKI concerns 'direct' value.
'Direct' value is included 'directly' into the PuKDF, and so, make a part of specification.

PKCS#15 specification have nothing about how the 'non-direct' data are stored.


 

And so, there is no reason, justified by specification conformity, to break the common pkcs15init  .

I agree that the CHOICE to use SPKI should not be the default, but rather a parameter
in the profile used when writing the public key. But the code whae reading the public key
should accept either, that was the point of defining the ASN1 CHOICE.



I cannot believe that it's not possible to transfer domain data from card driver

You are mising the point. The domain data is not in the card driver, it is in the card,
as part of the public key. (RSA does not have any "domain data", EC has parameters, and is usually
defined by a CURVE OID)


Card driver has possibility to read out the on-card data, isn't it?
If it's not so, I really missing something.

 

to the other levels using
the sc_pkcs15_pubkey or sc_pkcs15_pubkey_info.
If something EC specific is missing in these structures, you can always add/change/improve it,
but do not change framework that have very little with your need .

I disagree the changes are EC in general, not just for the CardContact cards.


I do not told that it's  CardContact specific .

  
The ability to write a SPKI is in PKCS#15 for many encryption types.
The reason to do this is the RAW format of a public key is missing "DomainData",
"DomainParameters, or "Parameters" where it is in the SPKI.

SPKI is well defined, and is in the certificate. It is the obvious way to
store a public key.

PKCS#15 was define in 2000, when EC was still being developed. PKCS#15 says:

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

What we should be arguing is how to leave the default format as RAW when writing public keys.


Viktor, You have not commented on the proposal to make this CHOICE during writting via the
pkcs15init profile which would default to using old RAW format, but allow for the use of
SPKI at the discretion of the card provisioner.


Yes, it could be like this.

 



    A lot of this goes back to the original ANS1 algorithm code, that included
    parameters, but since RSA had no parameter, this code was ignored.
    As far as I can tell, GOST did not take advantage of this, and some
    EC code did not either. You will note that the SPKI code does use this
    and the parameters are stored in the algorithm parameters.


        It
        rather serializes the key into the encoded form and decodes it a little
        later. In the old code, domain parameter for EC public keys are lost in
        that transition.

        Looking at framework-pkcs15.c@pkcs15_gen___keypair() it's calling

        sc_pkcs15init_generate_key(), then obtains the pkcs15 public key object
        with sc_pkcs15_find_pubkey_by_id() and finally calls
        __pkcs15_create_pubkey_object(__).

        In __pkcs15_create_pubkey_object(__) a call is made to

        sc_pkcs15_read_pubkey() which reads the encoded public key from the card
        or the content buffer.

        So the code only works if the public key is fully written to the card
        and then read back. As this code seem central to all card operations and
        I didn't write the code I don't wanna touch it.



I suppose that EC-PARAMS, that you are looking for in pkcs11, are actually stored somehow on card, isn't it?

Maybe it is accessable on the card, but may also be only in a certificate in the SPKI format.

Why do you not implement the /read_public_key()/ handler

Because the read_public_key does not necessarily read the parameters.


I'm talking about one of the card operation implemented by card driver.
If implemented, this handler is called by common pkcs15_read_public_key procedure.
In such a way public key can be extracted from any card specific format (know to card driver).

 


https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/opensc.h#L656
and leave aside the common init framework.



    EC has many curves, and they must be on the card somewhere.


        Apparently Douglas ran into the same problem when he created the public
        key object from a certificate stored in the PIV card. He did a tweak by
        adding the emulated element to sc_pkcs15_object. However he also
        mentioned that this needs refactored out of the code.

        Encoding ec_params for EC keys in pkcs15-pubkey-info is undefined: The
        PKCS#15 ASN.1 module declares an import of Parameter from X9.62, however
        Parameter is not defined there. You could try to squeeze
        ECDomainParameter into the Keyinfo structure, however the more logical
        way is to associate the domain parameter with the public key itself, as
        it's done with SPKI.

        A similar issues exists when the public key is generated using
        sc_pkcs15emu_add_ec_pubkey(). For that call you need to provide the EC
        Public Key in it's encoded form as it's later retrieved through
        sc_pkcs15_read_pubkey().



I still believe that object's blob should not be the unique place to store the object's attributes.

PKCS#15 allows for "Paramaters", "DomaminData", "DomainParamters" to be stored in the
keyInfo in the Public[RSA|EC|DH|DSA]KeyAttributes. keyInfo is optional.
(RSA has no parameters, and is NULL in the keyInfo)

I don't believe OpenSC implemeted the parameters in kinfo, be we have implemented the parameters in SPKI.
So yes there is another way, but the use of SPKI is the most straight forward
way to do it, as it SPKI is also used in certificates.

You can add key parameters if you need.
There are already EC parameters 'named-curve', OID of named-curve, ecpointQ, ... 




        So I still believe the current approach to encode the EC Public Key
        using SPKI is conforming and correct.


    I believe so too.


I do not agree.
Conformity of this approach is limited by PKCS#15 data itself,
limited by the case when ObjectValue is directly encoded into PKCS#15 (PukDF) descriptors.
You cannot impose to the cards the manner they use to store object's blob,
it can be in EFs, SDOs, derived from other data, ...
And it's precisely here that the current pkcs15init is broken .

Then make it optional, via the profile.

Yes, it could be solution.


If we accept the current state of pkcs15init, we have to declare that we do not more support the cards
that could not be tested or
for which there is no more maintainer.


Douglas,
it's not me who initially developed support of GOST,
but I have a few tokens. I will try to look.


Kind regards,
Viktor.


 




        We could of course argue if SPKI is the right format for RSA Public
        Keys, but with the automatic detection of SPKI/plain key we shouldn't
        have an issue.


    It may not be, but PKCS#15 allows it, but our ASN1 is wrong.
    So since none has used SPKI for RSA in the past, we don't need to address
    RSA use of SPKI. (I may have to tweak the PIV driver as I was planing
    on using that to simpliy its code.)


I do not agree,
the main task of ASN1 is to encode/parse the PKCS#15 descriptors according to specification.
And it do this.
All the rest are the tools used by different frameworks, cards, etc in particular circumstances.
This part is out of specification scope, and so it cannot be wrong.

If you are missing something -- create new, update existing -- but don't break.


Finally,
I propose you to send me the card (I will return it back afterwards) to understand better you problem.
So that our dialog will be more substantial.





        I also support Douglas idea to get rid of sc_pkcs15_pubkey_ec.params, as
        this duplicates information from sc_pkcs15_pubkey.alg_id.__params.



    We should do it for GOST some time in the future too.






                PKCS#15 allows SPKI encoding for all public keys, which is what the code
                does now. If card drivers need to decode the already encoded public key,
                then they should use sc_pkcs15_decode_pubkey_with___param() rather than

                sc_pkcs15_decode_pubkey(), as the former can detect if it's SPKI or a
                plain format.


            ......




                Andreas



                Am 20.01.2014 11:09, schrieb Viktor Tarasov:

                    Hi Andreas,

                    when you change encoding for all key types here

                https://github.com/OpenSC/__OpenSC/blob/master/src/__pkcs15init/pkcs15-lib.c#L1568 <https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1568>



                    then different card specific drivers,
                    that need their own manner to store objects, implemented as card specific
                    *emu_store_data* callback
                    used by sc_pkcs15init_store_data() called here

                https://github.com/OpenSC/__OpenSC/blob/master/src/__pkcs15init/pkcs15-lib.c#L1572 <https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1572>




                    these drivers will obtain the data blob that they do not get used to.

                    The patch from Douglas do not resolve this problem


                    What I propose you is to implement here:

                https://github.com/OpenSC/__OpenSC/blob/master/src/__pkcs15init/pkcs15-sc-hsm.c#__L427 <https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-sc-hsm.c#L427>


                    your own handler to store public key.
                    In this handler you have an access to all pkcs15 data, including the

                public

                    key object.
                    Here you can encode "AS SPKI" and store object as you like .


                    On Mon, Jan 20, 2014 at 8:43 AM, Andreas Schwier <
                    [hidden email] <mailto:[hidden email]>__> wrote:

                        I'm fine to change default encoding for RSA, but we need SPKI encoding
                        for public key objects, as the domain parameter are lost otherwise
                        between PKCS#15 und PKCS#11 layer.


                    Can you tell more about it ?
                    Where exactly in PKCS#11 this information is lost.



                    The only other drivers that are using EC public keys are the PIV driver

                        (Douglas looked at it) and the myEid driver (we informed Tony, but he
                        didn't respond.


                    Currently in pkcs15init the "AS SPKI" encoding is applied to all types of
                    key,
                    not only for EC ones.



                    Kind regards,
                    Viktor.



                --

                      ---------    CardContact Software & System Consulting
                     |.##> <##.|   Andreas Schwier
                     |#       #|   Schülerweg 38
                     |#       #|   32429 Minden, Germany
                     |'##> <##'|   Phone <a href="tel:%2B49%20571%2056149" value="+4957156149" target="_blank">+49 571 56149 <tel:%2B49%20571%2056149>

                      --------- http://www.cardcontact.de
                http://www.tscons.de
                http://www.openscdp.org






    --

      Douglas E. Engert  <[hidden email] <mailto:[hidden email]>> <[hidden email] <mailto:[hidden email]>>

      Argonne National Laboratory
      9700 South Cass Avenue
      Argonne, Illinois  60439
    <a href="tel:%28630%29%20252-5444" value="+16302525444" target="_blank">(630) 252-5444 <tel:%28630%29%20252-5444>



Kind regards,
Viktor.


--

 Douglas E. Engert  <[hidden email]> <[hidden email]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 <a href="tel:%28630%29%20252-5444" value="+16302525444" target="_blank">(630) 252-5444


------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Douglas E. Engert


On 1/21/2014 12:50 PM, Viktor Tarasov wrote:

> On Tue, Jan 21, 2014 at 4:55 PM, Douglas E. Engert <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 1/21/2014 7:18 AM, Viktor Tarasov wrote:
>
>         On Mon, Jan 20, 2014 at 11:26 PM, Douglas E. Engert <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>
>              On 1/20/2014 3:38 PM, Andreas Schwier (ML) wrote:
>
>                          Without domain parameter in encoded EC public keys, we don't get
>                          CKA_EC_PARAMS at the pkcs#11 layer for newly generated keys.
>
>
>                      Can you tell more about this ?
>                      I still do not understand.
>
>                      Ec-params have to be present in pkcs15-pubkey-info object's data, and not
>                      only encoded into the object's blob.
>                      In pkcs15-framefork all PKCS#15 data and PKCS#15 objects are accessibles,
>                      and so you *have* look for CKA_EC_PARAMS's value in the object's info data .
>
>                      If ec-params data are not present in object's info after key generation,
>                      you have to put them there (as it's done for GOST key),
>                      but do not change the common procedures used by other cards.
>
>                  I've tried that, but the current code doesn't preserve all elements from
>                  a fully initialized sc_pkcs15_pubkey return from the card driver.
>
>
>
>         So, I resume:
>         you were missing EC-PARAMS in pkcs#11 part,
>         and you have changed the framework used by all cards to store the object's blob on-card .
>
>         Just to remind that the manner in which card stores object blob is not in PKCS#15 specification.
>
>
>     I disagree.
>
>     PKCS#15 v1.1
>
>     Section 6.2
>
>         In the IC card case, the intention is that EF(ODF) shall consist of a number of data objects
>         (records) of type PKCS15Objects, representing different object types. Each data object
>         should in the normal case reference a file containing a directory of objects of the
>         particular type. Since the path alternative of the PathOrObject type is recommended, this
>         will result in a record-oriented ODF, which simplifies updating.
>
>
> ODF is a part of PKCS#15 file structure. We are not talking about it.

OK.

>
> For exemple:
> EF(PuKDF) -- "Public Key Directory File -- is a part of PKCS#15,
> but some EF that contains the blob of key is not.

In the pkcs15init/pkcs15-lib.c, the routine that was modified, was to to write out
the pubkey as either the RAW data or as an SPKI stored in the object->content.value
sc_pkcs15init_store_data then writes object->content.
Is this the blob you  are referring to?

Are there cards that actually use this on the card or do they only store it for retrieval by the user?

Based on the trace from Astrand on 1/15/2014 the log:
http://www.cendio.com/%7Eastrand/opensc/issue206-1.log
shows at at line 1807 where an RSA SPKI was read by the old OpenSC code
and it could not parse it. So I think this shows what was written
by sc_pkcs15init_store_data.

If the call to sc_pkcs15_encode_pubkey_as_spki was replaced by:

if (profile->store_pubkey_as_spki == true) {
     r = sc_pkcs15_encode_pubkey_as_spki(p15card->card->ctx, &key, &object->content.value, &object->content.len)
} else {
     r = sc_pkcs15_encode_pubkey(p15card->card->ctx, &key, &object->content.value, &object->content.len)
}

(Where profile->store_pubkey_as_spki is some call to the profile routines...)

Would that work for you?

Or is the problem, the &object->content.value is not the RAW version because it use used later?
IF so the code could move the
r = sc_pkcs15init_store_data(p15card, profile, object, &object->content, &key_info->path);
inside the if above.

Only the CardContact cards would set store_pubkey_as_spki
in its profile for now. Other cards developers or users could try it too.)

>
> Public key blob can be a part of PKCS#15 specification if it is included into PuKDF as 'direct' value.
> In this case the argues about 'raw' or 'spki' could take place.
>
>
>     Section 5 card file format
>
>         ... It may well be that a
>         particular card is able to store the information described here in a more compact or efficient
>         way than another card, however the “card-edge” representation of the information shall be
>         the same in both cases. This document is therefore a “card-edge” specification.
>
>
> Once more, it's going about files that represent the PKCS#15 file system,
> and not about the manner in which crypto or other objects are stored on card.

I believe that most if not all cards don't ever use the pubkey, but use the
prviate key which contains the pubkey to do any crypto operations.

>
>
>
>
>     So it does talk about card file formats, but gives the card vendor other options.
>
>
>
>         Specification concerns only the objects descriptors.
>
>
>     But PKCS#15 does allow for a CHOICE of RAW or SPKI formats for public keys.
>     and is thus part of the PKCS#15 specifications, and should be allowed.
>
>
>
> Choice of RAW or SPKI concerns 'direct' value.
> 'Direct' value is included 'directly' into the PuKDF, and so, make a part of specification.
>
> PKCS#15 specification have nothing about how the 'non-direct' data are stored.

But OpenSC assumes in the pkcs15init that the data to be written
is produced by sc_pkcs15_encode_pubkey and when read back in is decoded
by sc_pkcs15_decode_pubkey.

>
>
>
>         And so, there is no reason, justified by specification conformity, to break the common pkcs15init  .
>
>
>     I agree that the CHOICE to use SPKI should not be the default, but rather a parameter
>     in the profile used when writing the public key. But the code whae reading the public key
>     should accept either, that was the point of defining the ASN1 CHOICE.

YES! and the  sc_pkcs15_decode_pubkey_with_param was attempting to make the CHOICE at line 776:

  776         if (*buf == 0x30) {
  777                 /* Decode  Public Key from SPKI */
  778                 return sc_pkcs15_copy_pubkey_from_spki_object(ctx, buf, len, key);
  779         } else {
  780                 key->data.value = (u8 *)buf;
  781                 key->data.len = len;
  782                 return sc_pkcs15_decode_pubkey(ctx, key, buf, len);
  783         }
  784 }

But with RSA the check does not work, as it needs a content specific tag.

The above could have been to not allow RSA:
    if (key->algorithm != SC_ALGORITHM_RSA && *buf == 0x30) {

or to limit to only EC.
    if (key->algorithm == SC_ALGORITHM_EC *buf == 0x30) {


It looks like GOST might have the same problem as RSA, in that
the parameters are stored as a sequence, much like RSA.
For now we could limit both the writting and reading to EC only.

   openssl  asn1parse -i -inform pem -in /tmp/gostpubkey.pem
     0:d=0  hl=2 l=  99 cons: SEQUENCE
     2:d=1  hl=2 l=  28 cons:  SEQUENCE
     4:d=2  hl=2 l=   6 prim:   OBJECT            :GOST R 34.10-2001
    12:d=2  hl=2 l=  18 cons:   SEQUENCE
    14:d=3  hl=2 l=   7 prim:    OBJECT            :id-GostR3410-2001-CryptoPro-A-ParamSet
    23:d=3  hl=2 l=   7 prim:    OBJECT            :id-GostR3411-94-CryptoProParamSet
    32:d=1  hl=2 l=  67 prim:  BIT STRING

>
>
>
>         I cannot believe that it's not possible to transfer domain data from card driver
>
>
>     You are mising the point. The domain data is not in the card driver, it is in the card,
>     as part of the public key. (RSA does not have any "domain data", EC has parameters, and is usually
>     defined by a CURVE OID)
>
>
>
> Card driver has possibility to read out the on-card data, isn't it?
> If it's not so, I really missing something.

It looks like there are 2 ways to store parameter date in PKCS#15. One is the
keyInfo with the "Parameters".

The other is with the SPKI.

If OpenSC wants to support PKCS#15 cards that may have been produced by other
software, we should support both.

For RSA with no paramaters and GOST with what ever you have today, ot is using
the keyInfo.

With EC we have that working, but the code in pkcs15-lib.c and pkcs15-pubkey.c need
minor patches to not affect older cards or other algorithms.

I think we are close.



>
>
>         to the other levels using
>         the sc_pkcs15_pubkey or sc_pkcs15_pubkey_info.
>         If something EC specific is missing in these structures, you can always add/change/improve it,
>         but do not change framework that have very little with your need .
>
>
>     I disagree the changes are EC in general, not just for the CardContact cards.
>
>
>
> I do not told that it's  CardContact specific .
>
>     The ability to write a SPKI is in PKCS#15 for many encryption types.
>     The reason to do this is the RAW format of a public key is missing "DomainData",
>     "DomainParameters, or "Parameters" where it is in the SPKI.
>
>     SPKI is well defined, and is in the certificate. It is the obvious way to
>     store a public key.
>
>     PKCS#15 was define in 2000, when EC was still being developed. PKCS#15 says:
>
>        ECPoint, Parameters
>        FROM ANSI-X9-62 {iso(1) member-body(2) us(840) ansi-x962(10045) module(4) 1}
>
>     What we should be arguing is how to leave the default format as RAW when writing public keys.
>
>
>     Viktor, You have not commented on the proposal to make this CHOICE during writting via the
>     pkcs15init profile which would default to using old RAW format, but allow for the use of
>     SPKI at the discretion of the card provisioner.
>
>
>
> Yes, it could be like this.
>
>
>
>
>              A lot of this goes back to the original ANS1 algorithm code, that included
>              parameters, but since RSA had no parameter, this code was ignored.
>              As far as I can tell, GOST did not take advantage of this, and some
>              EC code did not either. You will note that the SPKI code does use this
>              and the parameters are stored in the algorithm parameters.
>
>
>                  It
>                  rather serializes the key into the encoded form and decodes it a little
>                  later. In the old code, domain parameter for EC public keys are lost in
>                  that transition.
>
>                  Looking at framework-pkcs15.c@pkcs15_gen_____keypair() it's calling
>
>                  sc_pkcs15init_generate_key(), then obtains the pkcs15 public key object
>                  with sc_pkcs15_find_pubkey_by_id() and finally calls
>                  __pkcs15_create_pubkey_object(____).
>
>                  In __pkcs15_create_pubkey_object(____) a call is made to
>
>                  sc_pkcs15_read_pubkey() which reads the encoded public key from the card
>                  or the content buffer.
>
>                  So the code only works if the public key is fully written to the card
>                  and then read back. As this code seem central to all card operations and
>                  I didn't write the code I don't wanna touch it.
>
>
>
>         I suppose that EC-PARAMS, that you are looking for in pkcs11, are actually stored somehow on card, isn't it?
>
>
>     Maybe it is accessable on the card, but may also be only in a certificate in the SPKI format.
>
>         Why do you not implement the /read_public_key()/ handler
>
>
>     Because the read_public_key does not necessarily read the parameters.
>
>
>
> I'm talking about one of the card operation implemented by card driver.
> If implemented, this handler is called by common /pkcs15_read_public_key/ procedure.
> In such a way public key can be extracted from any card specific format (know to card driver).

Do any drivers do that today?

With RSA they all all appear to store the RSA RAW format.
With EC there is the problem that keyInfo parameters are not saved, and
the SPKI is a way around this, and also looks attreactive as it is the
same structure as in the certificates.

Bit the GOST it looks like you are using the keyInfo or filling in defaults,
I am not be sure which, but it is working.



>
>
>
>         https://github.com/OpenSC/__OpenSC/blob/master/src/__libopensc/opensc.h#L656 <https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/opensc.h#L656>
>         and leave aside the common init framework.
>
>
>
>              EC has many curves, and they must be on the card somewhere.
>
>
>                  Apparently Douglas ran into the same problem when he created the public
>                  key object from a certificate stored in the PIV card. He did a tweak by
>                  adding the emulated element to sc_pkcs15_object. However he also
>                  mentioned that this needs refactored out of the code.
>
>                  Encoding ec_params for EC keys in pkcs15-pubkey-info is undefined: The
>                  PKCS#15 ASN.1 module declares an import of Parameter from X9.62, however
>                  Parameter is not defined there. You could try to squeeze
>                  ECDomainParameter into the Keyinfo structure, however the more logical
>                  way is to associate the domain parameter with the public key itself, as
>                  it's done with SPKI.
>
>                  A similar issues exists when the public key is generated using
>                  sc_pkcs15emu_add_ec_pubkey(). For that call you need to provide the EC
>                  Public Key in it's encoded form as it's later retrieved through
>                  sc_pkcs15_read_pubkey().
>
>
>
>         I still believe that object's blob should not be the unique place to store the object's attributes.
>
>
>     PKCS#15 allows for "Paramaters", "DomaminData", "DomainParamters" to be stored in the
>     keyInfo in the Public[RSA|EC|DH|DSA]__KeyAttributes. keyInfo is optional.
>     (RSA has no parameters, and is NULL in the keyInfo)
>
>     I don't believe OpenSC implemeted the parameters in kinfo, be we have implemented the parameters in SPKI.
>     So yes there is another way, but the use of SPKI is the most straight forward
>     way to do it, as it SPKI is also used in certificates.
>
>
> You can add key parameters if you need.
> There are already EC parameters 'named-curve', OID of named-curve, ecpointQ, ...
>
>
>
>
>                  So I still believe the current approach to encode the EC Public Key
>                  using SPKI is conforming and correct.
>
>
>              I believe so too.
>
>
>         I do not agree.
>         Conformity of this approach is limited by PKCS#15 data itself,
>         limited by the case when ObjectValue is directly encoded into PKCS#15 (PukDF) descriptors.
>         You cannot impose to the cards the manner they use to store object's blob,
>         it can be in EFs, SDOs, derived from other data, ...
>         And it's precisely here that the current pkcs15init is broken .
>
>
>     Then make it optional, via the profile.
>
>
> Yes, it could be solution.
>
>
> If we accept the current state of pkcs15init, we have to declare that we do not more support the cards
> that could not be tested or
> for which there is no more maintainer.
>
>
> Douglas,
> it's not me who initially developed support of GOST,
> but I have a few tokens. I will try to look.

Sorry, I though you did. Do you know who did?

>
>
> Kind regards,
> Viktor.
>
>
>
>
>
>
>                  We could of course argue if SPKI is the right format for RSA Public
>                  Keys, but with the automatic detection of SPKI/plain key we shouldn't
>                  have an issue.
>
>
>              It may not be, but PKCS#15 allows it, but our ASN1 is wrong.
>              So since none has used SPKI for RSA in the past, we don't need to address
>              RSA use of SPKI. (I may have to tweak the PIV driver as I was planing
>              on using that to simpliy its code.)
>
>
>         I do not agree,
>         the main task of ASN1 is to encode/parse the PKCS#15 descriptors according to specification.
>         And it do this.
>         All the rest are the tools used by different frameworks, cards, etc in particular circumstances.
>         This part is out of specification scope, and so it cannot be wrong.
>
>         If you are missing something -- create new, update existing -- but don't break.
>
>
>         Finally,
>         I propose you to send me the card (I will return it back afterwards) to understand better you problem.
>         So that our dialog will be more substantial.
>
>
>
>
>
>                  I also support Douglas idea to get rid of sc_pkcs15_pubkey_ec.params, as
>                  this duplicates information from sc_pkcs15_pubkey.alg_id.____params.
>
>
>
>              We should do it for GOST some time in the future too.
>
>
>
>
>
>
>                          PKCS#15 allows SPKI encoding for all public keys, which is what the code
>                          does now. If card drivers need to decode the already encoded public key,
>                          then they should use sc_pkcs15_decode_pubkey_with_____param() rather than
>
>                          sc_pkcs15_decode_pubkey(), as the former can detect if it's SPKI or a
>                          plain format.
>
>
>                      ......
>
>
>
>
>                          Andreas
>
>
>
>                          Am 20.01.2014 11:09, schrieb Viktor Tarasov:
>
>                              Hi Andreas,
>
>                              when you change encoding for all key types here
>
>         https://github.com/OpenSC/____OpenSC/blob/master/src/____pkcs15init/pkcs15-lib.c#L1568 <https://github.com/OpenSC/__OpenSC/blob/master/src/__pkcs15init/pkcs15-lib.c#L1568>
>         <https://github.com/OpenSC/__OpenSC/blob/master/src/__pkcs15init/pkcs15-lib.c#L1568 <https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1568>>
>
>
>
>                              then different card specific drivers,
>                              that need their own manner to store objects, implemented as card specific
>                              *emu_store_data* callback
>                              used by sc_pkcs15init_store_data() called here
>
>         https://github.com/OpenSC/____OpenSC/blob/master/src/____pkcs15init/pkcs15-lib.c#L1572 <https://github.com/OpenSC/__OpenSC/blob/master/src/__pkcs15init/pkcs15-lib.c#L1572>
>         <https://github.com/OpenSC/__OpenSC/blob/master/src/__pkcs15init/pkcs15-lib.c#L1572 <https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1572>>
>
>
>
>
>                              these drivers will obtain the data blob that they do not get used to.
>
>                              The patch from Douglas do not resolve this problem
>
>
>                              What I propose you is to implement here:
>
>         https://github.com/OpenSC/____OpenSC/blob/master/src/____pkcs15init/pkcs15-sc-hsm.c#____L427 <https://github.com/OpenSC/__OpenSC/blob/master/src/__pkcs15init/pkcs15-sc-hsm.c#__L427>
>         <https://github.com/OpenSC/__OpenSC/blob/master/src/__pkcs15init/pkcs15-sc-hsm.c#__L427 <https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-sc-hsm.c#L427>>
>
>
>                              your own handler to store public key.
>                              In this handler you have an access to all pkcs15 data, including the
>
>                          public
>
>                              key object.
>                              Here you can encode "AS SPKI" and store object as you like .
>
>
>                              On Mon, Jan 20, 2014 at 8:43 AM, Andreas Schwier <
>         [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>__> wrote:
>
>                                  I'm fine to change default encoding for RSA, but we need SPKI encoding
>                                  for public key objects, as the domain parameter are lost otherwise
>                                  between PKCS#15 und PKCS#11 layer.
>
>
>                              Can you tell more about it ?
>                              Where exactly in PKCS#11 this information is lost.
>
>
>
>                              The only other drivers that are using EC public keys are the PIV driver
>
>                                  (Douglas looked at it) and the myEid driver (we informed Tony, but he
>                                  didn't respond.
>
>
>                              Currently in pkcs15init the "AS SPKI" encoding is applied to all types of
>                              key,
>                              not only for EC ones.
>
>
>
>                              Kind regards,
>                              Viktor.
>
>
>
>                          --
>
>                                ---------    CardContact Software & System Consulting
>                               |.##> <##.|   Andreas Schwier
>                               |#       #|   Schülerweg 38
>                               |#       #|   32429 Minden, Germany
>                               |'##> <##'|   Phone +49 571 56149 <tel:%2B49%20571%2056149> <tel:%2B49%20571%2056149>
>
>                                --------- http://www.cardcontact.de
>         http://www.tscons.de
>         http://www.openscdp.org
>
>
>
>
>
>
>              --
>
>                Douglas E. Engert  <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>>
>
>                Argonne National Laboratory
>                9700 South Cass Avenue
>                Argonne, Illinois  60439
>         (630) 252-5444 <tel:%28630%29%20252-5444> <tel:%28630%29%20252-5444>
>
>
>
>         Kind regards,
>         Viktor.
>
>
>     --
>
>       Douglas E. Engert  <[hidden email] <mailto:[hidden email]>> <[hidden email] <mailto:[hidden email]>>
>       Argonne National Laboratory
>       9700 South Cass Avenue
>       Argonne, Illinois  60439
>     (630) 252-5444 <tel:%28630%29%20252-5444>
>
>

--

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

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Viktor Tarasov-3
In reply to this post by Andreas Schwier (ML)
Hi Andreas,


Le 21/01/2014 15:09, Andreas Schwier (ML) a écrit :
> Finally,
>> I propose you to send me the card (I will return it back afterwards) to
>> understand better you problem.
>> So that our dialog will be more substantial.
> You should have received a card around January 2012. I did sent it to
> your KEYNECTIS business address.
> Let me know I you need a new card.

With the card that I have I tried (pkcs11-tool and pkcs15-init) to generate key (EC or RSA),
but there is 'transmit error' on the 'GENERATE KEY' APDU.

It do not ask for User PIN.

0x44aaf40 14:34:49.937 [pkcs15-init] apdu.c:385:sc_single_transmit: CLA:0, INS:46, P1:6, P2:0, data(51) 0x455580e
0x44aaf40 14:34:49.939 [pkcs15-init] reader-pcsc.c:249:pcsc_transmit: reader 'OmniKey CardMan 3121 01 00'
0x44aaf40 14:34:49.939 [pkcs15-init] apdu.c:185:sc_apdu_log:
Outgoing APDU data [   60 bytes] =====================================
00 46 06 00 00 00 33 5F 29 01 00 42 09 55 54 43 .F....3_)..B.UTC
41 30 30 30 30 31 7F 49 15 06 0A 04 00 7F 00 07 A00001.I........
02 02 02 01 02 82 03 01 00 01 02 02 08 00 5F 20 .............._
09 55 54 54 4D 30 30 30 30 31 00 00             .UTTM00001..
======================================================================
0x44aaf40 14:34:49.940 [pkcs15-init] reader-pcsc.c:182:pcsc_internal_transmit: called
0x44aaf40 14:34:49.943 [pkcs15-init] reader-pcsc.c:208:pcsc_internal_transmit: OmniKey CardMan 3121 01 00:SCardTransmit/Control failed: 0x80100016
0x44aaf40 14:34:49.943 [pkcs15-init] reader-pcsc.c:370:pcsc_detect_card_presence: called
0x44aaf40 14:34:49.943 [pkcs15-init] reader-pcsc.c:283:refresh_attributes: OmniKey CardMan 3121 01 00 check
0x44aaf40 14:34:49.944 [pkcs15-init] reader-pcsc.c:299:refresh_attributes: returning with: 0 (Success)
0x44aaf40 14:34:49.944 [pkcs15-init] reader-pcsc.c:375:pcsc_detect_card_presence: returning with: 1
0x44aaf40 14:34:49.944 [pkcs15-init] reader-pcsc.c:370:pcsc_detect_card_presence: called
0x44aaf40 14:34:49.944 [pkcs15-init] reader-pcsc.c:283:refresh_attributes: OmniKey CardMan 3121 01 00 check
0x44aaf40 14:34:49.944 [pkcs15-init] reader-pcsc.c:299:refresh_attributes: returning with: 0 (Success)
0x44aaf40 14:34:49.945 [pkcs15-init] reader-pcsc.c:375:pcsc_detect_card_presence: returning with: 1
0x44aaf40 14:34:49.945 [pkcs15-init] reader-pcsc.c:256:pcsc_transmit: unable to transmit
0x44aaf40 14:34:49.945 [pkcs15-init] apdu.c:393:sc_single_transmit: unable to transmit APDU: -1107 (Transmit failed)
0x44aaf40 14:34:49.945 [pkcs15-init] apdu.c:529:sc_transmit: transmit APDU failed: -1107 (Transmit failed)


After this error there is seg.fault that I could fix with:

diff --git a/src/libopensc/pkcs15-sc-hsm.c b/src/libopensc/pkcs15-sc-hsm.c
--- a/src/libopensc/pkcs15-sc-hsm.c
+++ b/src/libopensc/pkcs15-sc-hsm.c
@@ -420,6 +420,7 @@ void sc_pkcs15emu_sc_hsm_free_cvc(sc_cvc_t *cvc)
        }
        if (cvc->coefficientAorExponent) {
                free(cvc->coefficientAorExponent);
+               cvc->coefficientAorExponent = NULL;
        }
        if (cvc->coefficientB) {
                free(cvc->coefficientB);


> Andreas
>

Kind regards,
Viktor.



------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&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: [OpenSC] openssl req -engine pkcs11 fails with PKCS11_get_private_key returned NULL (#206)

Viktor Tarasov-3
In reply to this post by Andreas Schwier (ML)
Hi Andreas,

please test pull request #211 "Fix-206".
I have no functional EC card to test pkcs15init part -- parse of existing objects works.

It's not final version -- needs to be tested more.

Kind regards,
Viktor.


Le 21/01/2014 15:09, Andreas Schwier (ML) a écrit :
> Finally,
>> I propose you to send me the card (I will return it back afterwards) to
>> understand better you problem.
>> So that our dialog will be more substantial.
> You should have received a card around January 2012. I did sent it to
> your KEYNECTIS business address.
> Let me know I you need a new card.

With the card that I have I tried (pkcs11-tool and pkcs15-init) to generate key (EC or RSA),
but there is 'transmit error' on the 'GENERATE KEY' APDU.

It do not ask for User PIN.

0x44aaf40 14:34:49.937 [pkcs15-init] apdu.c:385:sc_single_transmit: CLA:0, INS:46, P1:6, P2:0, data(51) 0x455580e
0x44aaf40 14:34:49.939 [pkcs15-init] reader-pcsc.c:249:pcsc_transmit: reader 'OmniKey CardMan 3121 01 00'
0x44aaf40 14:34:49.939 [pkcs15-init] apdu.c:185:sc_apdu_log:
Outgoing APDU data [   60 bytes] =====================================
00 46 06 00 00 00 33 5F 29 01 00 42 09 55 54 43 .F....3_)..B.UTC
41 30 30 30 30 31 7F 49 15 06 0A 04 00 7F 00 07 A00001.I........
02 02 02 01 02 82 03 01 00 01 02 02 08 00 5F 20 .............._
09 55 54 54 4D 30 30 30 30 31 00 00             .UTTM00001..
======================================================================
0x44aaf40 14:34:49.940 [pkcs15-init] reader-pcsc.c:182:pcsc_internal_transmit: called
0x44aaf40 14:34:49.943 [pkcs15-init] reader-pcsc.c:208:pcsc_internal_transmit: OmniKey CardMan 3121 01 00:SCardTransmit/Control failed: 0x80100016
0x44aaf40 14:34:49.943 [pkcs15-init] reader-pcsc.c:370:pcsc_detect_card_presence: called
0x44aaf40 14:34:49.943 [pkcs15-init] reader-pcsc.c:283:refresh_attributes: OmniKey CardMan 3121 01 00 check
0x44aaf40 14:34:49.944 [pkcs15-init] reader-pcsc.c:299:refresh_attributes: returning with: 0 (Success)
0x44aaf40 14:34:49.944 [pkcs15-init] reader-pcsc.c:375:pcsc_detect_card_presence: returning with: 1
0x44aaf40 14:34:49.944 [pkcs15-init] reader-pcsc.c:370:pcsc_detect_card_presence: called
0x44aaf40 14:34:49.944 [pkcs15-init] reader-pcsc.c:283:refresh_attributes: OmniKey CardMan 3121 01 00 check
0x44aaf40 14:34:49.944 [pkcs15-init] reader-pcsc.c:299:refresh_attributes: returning with: 0 (Success)
0x44aaf40 14:34:49.945 [pkcs15-init] reader-pcsc.c:375:pcsc_detect_card_presence: returning with: 1
0x44aaf40 14:34:49.945 [pkcs15-init] reader-pcsc.c:256:pcsc_transmit: unable to transmit
0x44aaf40 14:34:49.945 [pkcs15-init] apdu.c:393:sc_single_transmit: unable to transmit APDU: -1107 (Transmit failed)
0x44aaf40 14:34:49.945 [pkcs15-init] apdu.c:529:sc_transmit: transmit APDU failed: -1107 (Transmit failed)


After this error there is seg.fault that I could fix with:

diff --git a/src/libopensc/pkcs15-sc-hsm.c b/src/libopensc/pkcs15-sc-hsm.c
--- a/src/libopensc/pkcs15-sc-hsm.c
+++ b/src/libopensc/pkcs15-sc-hsm.c
@@ -420,6 +420,7 @@ void sc_pkcs15emu_sc_hsm_free_cvc(sc_cvc_t *cvc)
        }
        if (cvc->coefficientAorExponent) {
                free(cvc->coefficientAorExponent);
+               cvc->coefficientAorExponent = NULL;
        }
        if (cvc->coefficientB) {
                free(cvc->coefficientB);


> Andreas
>

Kind regards,
Viktor.



------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel