"Invalid ASN.1 object" with ePass2003 about opensc HOT 18 CLOSED

It's a bug, introduced by 3a6e7ba or d4be8ec -- SPKI encoding of public key is applied to all type of cards.
It was not really tested with a different cards.

from opensc.

Also happens with Aventra EID. Did a git bisect, d4be8ec is apparently the problem.

from opensc.

On 1/9/2014 6:12 AM, astrand wrote:

Also happens with Aventra EID. Did a git bisect, d4be8ec d4be8ec is apparently the problem.

—
Reply to this email directly or view it on GitHub #202 (comment).

Do you have a opensc debug trace? That would help show where is is coming from.

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

from opensc.

@dengert
This error is returned by 'sc_pkcs15_encode_pubkey_as_spki()' called for RSA key by 'sc_pkcs15init_store_public_key()'.

My inline question was: is it your real intention to use the 'sc_pkcs15_encode_pubkey_as_spki()' for all key types ?

(There are no debug messages in 'sc_pkcs15_encode_pubkey_as_spki' in original sources)

0xb7443a30 19:05:21.734 [pkcs15-init] pkcs15-pubkey.c:698:sc_pkcs15_encode_pubkey_as_spki: called
0xb7443a30 19:05:21.734 [pkcs15-init] pkcs15-pubkey.c:702:sc_pkcs15_encode_pubkey_as_spki: Decoding of public key type 0
0xb7443a30 19:05:21.734 [pkcs15-init] asn1.c:1495:asn1_encode_entry: encoding 'publicKeyCoefficients'
0xb7443a30 19:05:21.734 [pkcs15-init] asn1.c:1500:asn1_encode_entry: type=129, tag=0x1000010, parm=0xbfbb6108, len=0
0xb7443a30 19:05:21.734 [pkcs15-init] asn1.c:1495:asn1_encode_entry:  encoding 'modulus'
0xb7443a30 19:05:21.734 [pkcs15-init] asn1.c:1500:asn1_encode_entry:  type=4, tag=0x02, parm=0x900b750, len=128
0xb7443a30 19:05:21.734 [pkcs15-init] asn1.c:1678:asn1_encode_entry:  length of encoded item=132
0xb7443a30 19:05:21.734 [pkcs15-init] asn1.c:1495:asn1_encode_entry:  encoding 'exponent'
0xb7443a30 19:05:21.734 [pkcs15-init] asn1.c:1500:asn1_encode_entry:  type=4, tag=0x02, parm=0x900dd50, len=3
0xb7443a30 19:05:21.734 [pkcs15-init] asn1.c:1678:asn1_encode_entry:  length of encoded item=5
0xb7443a30 19:05:21.734 [pkcs15-init] asn1.c:1678:asn1_encode_entry: length of encoded item=140
0xb7443a30 19:05:21.734 [pkcs15-init] pkcs15-pubkey.c:726:sc_pkcs15_encode_pubkey_as_spki: rv 0
0xb7443a30 19:05:21.734 [pkcs15-init] asn1.c:1495:asn1_encode_entry: encoding 'publicKey'
0xb7443a30 19:05:21.734 [pkcs15-init] asn1.c:1500:asn1_encode_entry: type=129, tag=0x1000010, parm=0xbfbb621c, len=0
0xb7443a30 19:05:21.734 [pkcs15-init] asn1.c:1495:asn1_encode_entry:  encoding 'algorithm'
0xb7443a30 19:05:21.734 [pkcs15-init] asn1.c:1500:asn1_encode_entry:  type=259, tag=0x1000010, parm=(nil), len=0
0xb7443a30 19:05:21.734 [pkcs15-init] asn1.c:1528:asn1_encode_entry: unexpected parm == NULL
0xb7443a30 19:05:21.734 [pkcs15-init] asn1.c:1634:asn1_encode_entry: encoding of ASN.1 object 'publicKey' failed: Invalid ASN.1 object
0xb7443a30 19:05:21.734 [pkcs15-init] pkcs15-pubkey.c:739:sc_pkcs15_encode_pubkey_as_spki: rv -1401
0xb7443a30 19:05:21.734 [pkcs15-init] pkcs15-pubkey.c:745:sc_pkcs15_encode_pubkey_as_spki: returning with: -1401 (Invalid ASN.1 object)
0xb7443a30 19:05:21.734 [pkcs15-init] pkcs15-lib.c:1560:sc_pkcs15init_store_public_key: Encode public key error: -1401 (Invalid ASN.1 object)
0xb7443a30 19:05:21.734 [pkcs15-init] pkcs15-lib.c:1359:sc_pkcs15init_generate_key: Failed to store public key: -1401 (Invalid ASN.1 object)

from opensc.

On 1/10/2014 3:15 AM, viktorTarasov wrote:

@dengert https://github.com/dengert
This error is returned by 'sc_pkcs15_encode_pubkey_as_spki()' called for RSA key by 'sc_pkcs15init_store_public_key()'.

There are no debug messages in 'sc_pkcs15_encode_pubkey_as_spki'

My inline question was: is it your real intention to use the 'sc_pkcs15_encode_pubkey_as_spki()' for all types of keys ?

The sc_pkcs15_encode_pubkey_as_spki() can work on RSA or EC today. I have asked for the GOST developers
to look if it is handling GOST correctly or not.

PKCS15 allows a pubkey to be stored as RAW, or as a SPKI.

The sc-hsm developers may have change the sc_pkcs15init_store_public_key() to always call
sc_pkcs15_encode_pubkey_as_spki(). I think that that should be an option, as some cards may not
accept it or have not setup the sc_pkcs15_pubkey structure to work with sc_pkcs15_encode_pubkey_as_spki()

I don't have the code in front of my, to check I will have to look on Monday.

A gdb print out of the sc_pkcs15_pubkey passed to sc_pkcs15_encode_pubkey_as_spki() by sc_pkcs15init_store_public_key()
would be very helpful.

—
Reply to this email directly or view it on GitHub #202 (comment).

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

from opensc.

It looks like in pkcs145init/pkcs15.lib the call to sc_pkcs15_encode_pubkey() was replaced with
sc_pkcs15_encode_pubkey_as_spki()

sc_pkcs15_encode_pubkey_as_spki() is expecting the sc_pkcs15_pubkey->data to have a DER encoding
of the raw pubkey, normally it does as it is read from the card. But during pkcs15init
it has not been read.

astrand, can you (or someone) try this attached patch that makes sure the raw DER value is available?

On 1/10/2014 3:15 AM, viktorTarasov wrote:

@dengert https://github.com/dengert
This error is returned by 'sc_pkcs15_encode_pubkey_as_spki()' called for RSA key by 'sc_pkcs15init_store_public_key()'.

There are no debug messages in 'sc_pkcs15_encode_pubkey_as_spki'

My inline question was: is it your real intention to use the 'sc_pkcs15_encode_pubkey_as_spki()' for all types of keys ?

—
Reply to this email directly or view it on GitHub #202 (comment).

Douglas E. Engert [email protected] [email protected]
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
diff --git a/src/libopensc/pkcs15-pubkey.c b/src/libopensc/pkcs15-pubkey.c
index b83d580..738f808 100644
--- a/src/libopensc/pkcs15-pubkey.c
+++ b/src/libopensc/pkcs15-pubkey.c
@@ -697,7 +697,12 @@ sc_pkcs15_encode_pubkey_as_spki(sc_context_t *ctx, struct sc_pkcs15_pubkey *pubk

pkey.value =  NULL;
pkey.len = 0;

• /* make sure we have a der encoded value first */
• if (pubkey->data.value == NULL)(

•   r = sc_pkcs15_encode_pubkey(ctx, pubkey, pubkey->data.value, pubkey->data.len);
  

• }

switch (pubkey->algorithm) {
case SC_ALGORITHM_EC:
/*

from opensc.

The previous patch had 3 errors.

Astrand, can you (or someone else) try this new patch?

On 1/10/2014 3:15 AM, viktorTarasov wrote:

@dengert https://github.com/dengert
This error is returned by 'sc_pkcs15_encode_pubkey_as_spki()' called for RSA key by 'sc_pkcs15init_store_public_key()'.

There are no debug messages in 'sc_pkcs15_encode_pubkey_as_spki'

My inline question was: is it your real intention to use the 'sc_pkcs15_encode_pubkey_as_spki()' for all types of keys ?

—
Reply to this email directly or view it on GitHub #202 (comment).

Douglas E. Engert [email protected] [email protected]
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
diff --git a/src/libopensc/pkcs15-pubkey.c b/src/libopensc/pkcs15-pubkey.c
index b83d580..d052ebe 100644
--- a/src/libopensc/pkcs15-pubkey.c
+++ b/src/libopensc/pkcs15-pubkey.c
@@ -697,7 +697,12 @@ sc_pkcs15_encode_pubkey_as_spki(sc_context_t *ctx, struct sc_pkcs15_pubkey *pubk

pkey.value =  NULL;
pkey.len = 0;

• /* make sure we have a der encoded value first */
• if (pubkey->data.value == NULL){

•   r = sc_pkcs15_encode_pubkey(ctx, pubkey, &pubkey->data.value, &pubkey->data.len);
  

• }

switch (pubkey->algorithm) {
case SC_ALGORITHM_EC:
/*

from opensc.

The patch doesn't help for me. See log: http://www.cendio.com/~astrand/opensc/issue202-1.log

from opensc.

@astrand
Please, try current master (5437f87).

from opensc.

Well, now pkcs15-init --generate-key works. However, in our script, we are continuing with creating a certificate using openssl and engine_pkcs11, and that fails instead:

• openssl req -engine pkcs11 -new -key slot_01 -keyform engine -x509 -out /tmp/tmp.5EVKsBpxRA/cert.pem -text -config /tmp/tmp.5EVKsBpxRA/openssl.cnf
  initializing engine
  engine "pkcs11" set.
  Looking in slot 1 for key:
  Found 2 slots
  [18446744073709551615] Virtual hotplug slot no tok
  [1] OmniKey CardMan 3121 00 0 login (MyEID (Basic PIN))
  Found slot: OmniKey CardMan 3121 00 00
  Found token: MyEID (Basic PIN)
  Found 0 certificate:
  Found 1 key:
  PKCS11_get_private_key returned NULL
  cannot load Private Key from engine
  140615219554120:error:80028012:PKCS11 library:PKCS11_get_attribute:Attribute type invalid:p11_attr.c:53:
  140615219554120:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:eng_pkey.c:126:

This worked before. I've put up the entire script at http://www.cendio.com/~astrand/opensc/pkcs15-selfsigned.sh in case you are interested.

from opensc.

Based on your opensc debug trace, I think it looks like the sc_pkcs15_pubkey struct sc_algorithm_id * alg_id;
may not be setup correctly.

Can you use gdb and set a breakpoint at asn1.c:1528 (the place where the "unexpected parm == NULL" message is produced.

Then get a stack trace and send it.

And can you go up in the stack to find the call to sc_pkcs15init_store_public_key then

print *keyargs
print *keyargs->key

and send these these too. I am looking to see what is passed in as the publey.

On 1/13/2014 6:34 AM, viktorTarasov wrote:

@astrand https://github.com/astrand
Please, try current /master/ (5437f87 5437f87).

—
Reply to this email directly or view it on GitHub #202 (comment).

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

from opensc.

Please disregard my previous message, on the gdb trace, since you said the patch worked.
I will get that committed. in the next few days.

The following is a different problem, and should be submitted as a new bug report.

On 1/13/2014 9:18 AM, astrand wrote:

Well, now pkcs15-init --generate-key works. However, in our script, we are continuing with creating a certificate using openssl and engine_pkcs11, and that fails instead:

• openssl req -engine pkcs11 -new -key slot_01 -keyform engine -x509 -out /tmp/tmp.5EVKsBpxRA/cert.pem -text -config /tmp/tmp.5EVKsBpxRA/openssl.cnf initializing engine engine "pkcs11" set. Looking
  in slot 1 for key: Found 2 slots [18446744073709551615] Virtual hotplug slot no tok
  [1] OmniKey CardMan 3121 00 0 login (MyEID (Basic PIN)) Found slot: OmniKey CardMan 3121 00 00 Found token: MyEID (Basic PIN) Found 0 certificate: Found 1 key: PKCS11_get_private_key returned NULL
  cannot load Private Key from engine 140615219554120:error:80028012:PKCS11 library:PKCS11_get_attribute:Attribute type invalid:p11_attr.c:53: 140615219554120:error:26096080:engine
  routines:ENGINE_load_private_key:failed loading private key:eng_pkey.c:126:

This worked before. I've put up the entire script at http://www.cendio.com/~astrand/opensc/pkcs15-selfsigned.sh http://www.cendio.com/%7Eastrand/opensc/pkcs15-selfsigned.sh in case you are interested.

—
Reply to this email directly or view it on GitHub #202 (comment).

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

from opensc.

@dengert With the current master, --generate-key works, so I don't know if your patch is required at all?

I will see if I can pinpoint the other problem. @viktorTarasov, in the future please avoid committing both functional changes and white space / coding style changes at the same time, as was done in 5437f87.

from opensc.

Since Viktor made a change in the pkcs15-pubkey.c to make sure alg_id was filled in, my changed to
make sure the raw DER encode pubkey was available may not have been the problem.

In the comment which I said to ignore, was about the alg_id. Viktor added the change for alg_id
at about the same time.

Just to be sure, I submitted an updated pull request for the RAW DER encoded pubkey.

Viktor, can you comment on this?

On 1/14/2014 1:51 AM, astrand wrote:

@dengert https://github.com/dengert With the current master, --generate-key works, so I don't know if your patch is required at all?

I will see if I can pinpoint the other problem. @viktorTarasov https://github.com/viktorTarasov, in the future please avoid committing both functional changes and white space / coding style changes
at the same time, as was done in 5437f87 5437f87.

—
Reply to this email directly or view it on GitHub #202 (comment).

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

from opensc.

Well, it seems that the idea to apply in pkcs15init the encoding of public key as spki to all key types was not sufficiently tested.
This weekend I will look what impact it has onto the encoding of PUKDF for the different cards.

from opensc.

On 1/14/2014 1:05 PM, viktorTarasov wrote:

Well, it seems that the idea to apply in pkcs15init the encoding of public key /as spki/ to all key types was not sufficiently tested.

As I have said, I don't have any actual pkcs15 cards and that when this code was submitted
to needs to be tested.

The SPKI was tested with PIV, (that emulates PKCS15, but does not using any of the pkcs15init code)
the CardContact submitted the final change, and defaulted to using SPKI for all key types
and all cards. (I have been saying it should be an option as some cards may not support it.)

There is a general problem with OpenSC. There are are many developers, or companies
working with the code, each with their own card. They can test against their card,
and submit changes even to very low level common routines without any notice that
this may cause problems with other cards.

Even when they do make such a statement,it is ignored be most developers.
and some cards no longer have active developers to do any testing, yet there are still
users of these cards.

OpenSC needs a release schedule with plenty of time to get new card drivers added,
and low level changes added. And then plenty of time to test the base code against all
cards drivers possible.

Accepting large code changes just before a release has caused problems in the past.
with 0.12 someone edited the piv-tool, and dropped 5 lines, that caused it to not
work at all. Just because some one has time to make a release, does not mean that
a release should be made with our sufficient warning and testing be all developers.

This weekend I will look what impact it has onto the encoding of /PUKDF/ for the different cards.

A better time might be spent adding a SPKI option to the pkcs15init code with the default to not use it.

And test if GOST works with it too.

—
Reply to this email directly or view it on GitHub #202 (comment).

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

from opensc.

I have to agree there is a general problem. After almost TWO years, I was able to use the ePass2003 on Fedora - I thought. Now after this is "messed up" again (please excuse my language... ), it might take how long again?
It simply makes a lot of HW practically unusable with a lot of systems- these "destructive patches" should be reversed and - from my perspective - the main code shouldn't have to be altered that easily from a singular vendor - is the code that unmodular or what's the reason for that (sorry no disrespect for the great dev's intended!)?

Thanks for looking into this everybody...

from opensc.

Fixed in a399905.

from opensc.