Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IASECC: Algo_refs not set, pkcs15_prkey_can_do() CKR_FUNCTION_NOT_SUPPORTED #2267

Closed
vjardin opened this issue Mar 19, 2021 · 42 comments
Closed

Comments

@vjardin
Copy link
Contributor

vjardin commented Mar 19, 2021

When parsing 3f00/0001/5032, we get the algRef = 66:

$ pkcs15-tool -k --verify-pin --pin PIN
[...]
 [pkcs15-tool] asn1.c:1499:asn1_decode_entry:    decoding 'algRef', raw data:42
 [pkcs15-tool] asn1.c:1527:asn1_decode_entry:    decoding 'algRef' returned 66
 [pkcs15-tool] asn1.c:1766:asn1_decode: returning with: 0 (Success)

because, from opensc-explorer's asn1 parser, it is:

      30 SEQUENCE (26 bytes)
         02 INTEGER (1 byte): 4
         02 INTEGER (1 byte): 64
         05 NULL
         03 BIT STRING (2 bytes): 10
         06 OBJECT IDENTIFIER (9 bytes):  1.2.840.113549.1.1.11, RSA-SHA256
         02 INTEGER (1 byte): 66

but as a bottom line, Algo_refs is not set:

pkcs15-tool -k --verify-pin --pin 1234 
Using reader with a card: ACS ACR33U-A1 3SAM ICC Reader 00 00
Private RSA Key [CPS_PRIV_SIG]
	Object Flags   : [0x01], private
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_cds:01;
	ModLength      : 2048
	Key ref        : 129 (0x81)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001001
	MD:guid        : e7aab727-f2af-e673-37bb-7d43867a6349

Private RSA Key [CPS_PRIV_AUT]
	Object Flags   : [0x07], private, modifiable
	Usage          : [0x06], decrypt, sign
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_decrypt:01; int_auth:01;
	ModLength      : 2048
	Key ref        : 130 (0x82)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001002
	MD:guid        : 2b6bf284-225c-80bc-8cbe-1c791db33543

It leads to some issues because pkcs15_prkey_can_do() fails and returns CKR_FUNCTION_NOT_SUPPORTED because of

        /* Return if there are no usage algorithms specified for this key. */
        if (!pkinfo->algo_refs[0])
               return CKR_FUNCTION_NOT_SUPPORTED;

so, the card's signature fails.

As a workaround, I can enforce a proper signature with this crappy patch:

diff --git a/src/pkcs11/mechanism.c b/src/pkcs11/mechanism.c
index 983d8dcb..bb4be109 100644
--- a/src/pkcs11/mechanism.c
+++ b/src/pkcs11/mechanism.c
@@ -381,6 +381,7 @@ sc_pkcs11_signature_init(sc_pkcs11_operation_t *operation,
 
        if (key->ops->can_do)   {
                rv = key->ops->can_do(operation->session, key, operation->type->mech, CKF_SIGN);
                rv = CKR_OK; // XXX XXX XXXXXXXXX
                if (rv == CKR_OK)   {
                        /* Mechanism recognised and can be performed by pkcs#15 card */
                        can_do_it = 1;

how to get pkcs15_prkey_can_do() working properly ? I have a feeling that the values from algRef should lead to some settings of Algo_refs so pkcs15_prkey_can_do() would work properly, but I cannot get the point.

@vjardin vjardin changed the title IAS/ECC: Algo_refs not set, pkcs15_prkey_can_do() CKR_FUNCTION_NOT_SUPPORTED IASECC: Algo_refs not set, pkcs15_prkey_can_do() CKR_FUNCTION_NOT_SUPPORTED Mar 19, 2021
@vjardin
Copy link
Contributor Author

vjardin commented Mar 20, 2021

For the records, if we compare the 7002 of a Polish card and the one of the French Healthcare cards, we get:

In case of the Polish cards, the logs are:

P:2772; T:5776 2018-05-11 11:20:05.173  decoding 'classAttributes', raw data:040102030306EE400101FF030204B002...
P:2772; T:5776 2018-05-11 11:20:05.173   called, left=24, depth 2
P:2772; T:5776 2018-05-11 11:20:05.173 Looking for 'iD', tag 0x4
P:2772; T:5776 2018-05-11 11:20:05.173   decoding 'iD', raw data:02
P:2772; T:5776 2018-05-11 11:20:05.173 Looking for 'usage', tag 0x3
P:2772; T:5776 2018-05-11 11:20:05.173   decoding 'usage', raw data:06EE40
P:2772; T:5776 2018-05-11 11:20:05.173 Looking for 'native', tag 0x1, OPTIONAL
P:2772; T:5776 2018-05-11 11:20:05.173   decoding 'native', raw data:FF
P:2772; T:5776 2018-05-11 11:20:05.173 Looking for 'accessFlags', tag 0x3, OPTIONAL
P:2772; T:5776 2018-05-11 11:20:05.173   decoding 'accessFlags', raw data:04B0
P:2772; T:5776 2018-05-11 11:20:05.173 Looking for 'keyReference', tag 0x2, OPTIONAL
P:2772; T:5776 2018-05-11 11:20:05.173   decoding 'keyReference', raw data:0082
P:2772; T:5776 2018-05-11 11:20:05.173   decoding 'keyReference' returned 130
P:2772; T:5776 2018-05-11 11:20:05.173 Looking for 'algReference', tag 0x21000001, OPTIONAL
P:2772; T:5776 2018-05-11 11:20:05.173   decoding 'algReference', raw data:020108
P:2772; T:5776 2018-05-11 11:20:05.189    called, left=3, depth 3 
P:2772; T:5776 2018-05-11 11:20:05.189 Looking for 'algorithmReference', tag 0x2, OPTIONAL
P:2772; T:5776 2018-05-11 11:20:05.189    decoding 'algorithmReference', raw data:08
P:2772; T:5776 2018-05-11 11:20:05.189    decoding 'algorithmReference' returned 8
P:2772; T:5776 2018-05-11 11:20:05.189 Looking for 'algorithmReference', tag 0x2, OPTIONAL
P:2772; T:5776 2018-05-11 11:20:05.189 'algorithmReference' not present
[...]
P:2772; T:5776 2018-05-11 11:20:05.189 [opensc-pkcs11] asn1.c:1651:asn1_decode: returning with: 0 (Success)

while in case of a French card, the logs are:

 [pkcs15-tool] asn1.c:1731:asn1_decode: 'accessControlRule' not present
 [pkcs15-tool] asn1.c:1715:asn1_decode: Looking for 'accessControlRule', tag 0x20000010, OPTIONAL
 [pkcs15-tool] asn1.c:1731:asn1_decode: 'accessControlRule' not present
 [pkcs15-tool] asn1.c:1715:asn1_decode: Looking for 'accessControlRule', tag 0x20000010, OPTIONAL
 [pkcs15-tool] asn1.c:1731:asn1_decode: 'accessControlRule' not present
 [pkcs15-tool] asn1.c:1715:asn1_decode: Looking for 'accessControlRule', tag 0x20000010, OPTIONAL
 [pkcs15-tool] asn1.c:1731:asn1_decode: 'accessControlRule' not present
 [pkcs15-tool] asn1.c:1766:asn1_decode: returning with: 0 (Success)
 [pkcs15-tool] asn1.c:1766:asn1_decode: returning with: 0 (Success)
 [pkcs15-tool] asn1.c:1715:asn1_decode: Looking for 'classAttributes', tag 0x20000010
 [pkcs15-tool] asn1.c:1499:asn1_decode_entry:  decoding 'classAttributes', raw data:040EE828BD080F8025000001FF001002...
 [pkcs15-tool] asn1.c:1691:asn1_decode:   called, left=31, depth 2
 [pkcs15-tool] asn1.c:1715:asn1_decode: Looking for 'iD', tag 0x4
 [pkcs15-tool] asn1.c:1499:asn1_decode_entry:   decoding 'iD', raw data:E828BD080F8025000001FF001002
 [pkcs15-tool] asn1.c:1715:asn1_decode: Looking for 'usage', tag 0x3
 [pkcs15-tool] asn1.c:1499:asn1_decode_entry:   decoding 'usage', raw data:0560
 [pkcs15-tool] asn1.c:1715:asn1_decode: Looking for 'native', tag 0x1, OPTIONAL
 [pkcs15-tool] asn1.c:1499:asn1_decode_entry:   decoding 'native', raw data:FF
 [pkcs15-tool] asn1.c:1715:asn1_decode: Looking for 'accessFlags', tag 0x3, OPTIONAL
 [pkcs15-tool] asn1.c:1499:asn1_decode_entry:   decoding 'accessFlags', raw data:04B0
 [pkcs15-tool] asn1.c:1715:asn1_decode: Looking for 'keyReference', tag 0x2, OPTIONAL
 [pkcs15-tool] asn1.c:1499:asn1_decode_entry:   decoding 'keyReference', raw data:0082
 [pkcs15-tool] asn1.c:1527:asn1_decode_entry:   decoding 'keyReference' returned 130
 [pkcs15-tool] asn1.c:1715:asn1_decode: Looking for 'algReference', tag 0xa0000001, OPTIONAL
 [pkcs15-tool] asn1.c:1731:asn1_decode: 'algReference' not present
 [pkcs15-tool] asn1.c:1766:asn1_decode: returning with: 0 (Success)

Could the root cause of the issue with the French card be due to the lack of this algorithmReference records from 7002 ? Why would it be needed ?

@vjardin
Copy link
Contributor Author

vjardin commented Mar 20, 2021

For the records, the Peru's card from this issue is reporting some similar logs #1194 with the Polish's card.

@dengert
Copy link
Member

dengert commented Mar 20, 2021

But it appears the keys have all zero Algo_refs. this is not an OpenSC problem, it is a problem of the card vendor/issuer creating inconsistent PKCS15 data structures.

When a PKCS15 card is is first used, the tokenInfo is read. I believe that is what you are seeing in:

 [pkcs15-tool] asn1.c:1499:asn1_decode_entry:    decoding 'algRef', raw data:42
 [pkcs15-tool] asn1.c:1527:asn1_decode_entry:    decoding 'algRef' returned 66
 [pkcs15-tool] asn1.c:1766:asn1_decode: returning with: 0 (Success)

(Use pkcs15-tool --list-info to the tokenInfo. The tokenInfo may be correct.

Then when pkcs15-tool -k is run, it lists for each key the Algo_refs which is an array of indexes into the table in tokenInfo. But it looks like this is not correct see comments in

The real way to fix a bad pkcs15 card is to have add a pkcs15-iasecc.c that gets control before and after the pkcs15 data is read sc_pkcs15_bind_internal. It can then fix up the data as needed for your card. All other iasecc cards would remain as is.

db41cd9 is a recent an example where cardos_fix_token_info is called to fix up the tokenInfo for some cards. But in you case you need to fix up the keys to set the algo_refs. You could also then fixup the bitString flags on the keys too.

When adding one of these pkcs15-<card>.c files, the pkcs15-syn.c and the pkcs15-syn.h are also modified to get control after the read sc_pkcs15_bind_internal is called.

@vjardin
Copy link
Contributor Author

vjardin commented Mar 20, 2021

Thanks for your analysis. I get your points and I'll try to follow the example of cardos that you highlighted.

@vjardin
Copy link
Contributor Author

vjardin commented Mar 21, 2021

From your analysis, @dengert, the Tokeninfo seems to be correct, we get some algo_ref with the following command:

# pkcs15-tool --list-info
[...]
	Flags          : Read-only, Login required
		 sc_supported_algo_info[0]:
			 reference  : 1 (0x01)
			 mechanism  : [0x220] CKM_SHA_1                    
			 operations : [0x40], hash
			 algo_id    : 1.3.14.3.2.26
			 algo_ref   : [0x10]
		 sc_supported_algo_info[1]:
			 reference  : 2 (0x02)
			 mechanism  : [0x250] CKM_SHA256                   
			 operations : [0x40], hash
			 algo_id    : 2.16.840.1.101.3.4.2.1
			 algo_ref   : [0x40]
		 sc_supported_algo_info[2]:
			 reference  : 3 (0x03)
			 mechanism  : [0x06] CKM_SHA1_RSA_PKCS            
			 operations : [0x02], compute_signature
			 algo_id    : 1.2.840.113549.1.1.5
			 algo_ref   : [0x12]
		 sc_supported_algo_info[3]:
			 reference  : 4 (0x04)
			 mechanism  : [0x40] CKM_SHA256_RSA_PKCS          
			 operations : [0x02], compute_signature
			 algo_id    : 1.2.840.113549.1.1.11
			 algo_ref   : [0x42]
		 sc_supported_algo_info[4]:
			 reference  : 5 (0x05)
			 mechanism  : [0x01] CKM_RSA_PKCS                 
			 operations : [0x02], compute_signature
			 algo_id    : 1.2.840.113549.1.1.1
			 algo_ref   : [0x02]
		 sc_supported_algo_info[5]:
			 reference  : 6 (0x06)
			 mechanism  : [0x01] CKM_RSA_PKCS                 
			 operations : [0x20], decipher
			 algo_id    : 1.2.840.113549.1.1.1
			 algo_ref   : [0x1a]

So, I'll try your comments, let's add a iasecc_cardos_fix_token_info into the current pkcs15-iasecc.c

I am wondering if it is "a bug" from the manufacturer of if it is an acceptable way of supporting the IAS/ECC standard. I do not have any documents that could state the point.

@dengert
Copy link
Member

dengert commented Mar 21, 2021 via email

@vjardin
Copy link
Contributor Author

vjardin commented Mar 21, 2021

I think the problem is in the keys not the tokenInfo on your card.

OK.

I am quite "newbie" with opensc. I face two issues:

  • sc_pkcs15emu_iasecc_init() is never called, how to get it called ?
  • does you comment mean that cardos_fix_token_info() is not the right example to follow since the tokenInfo is correct on the card ? pkcs15-iasecc.c has a _iasecc_parse_df()/_iasecc_md_update_keyinfo() call flow that never occurs from the logs because it would need to be called from this callback:
p15card->ops.parse_df = _iasecc_parse_df;

but ops.parse_df = NULL:

(gdb) bt
#0  __sc_pkcs15_search_objects (p15card=0x555555578110, class_mask=64, class_mask@entry=0, type=1537, func=0x0, func_arg=0x0, 
    ret=0x7fffffffe0e0, ret_size=32) at pkcs15.c:1375
#1  0x00007ffff7b2dbcc in sc_pkcs15_get_objects_cond (p15card=<optimized out>, type=<optimized out>, func=<optimized out>, 
    func_arg=<optimized out>, ret=<optimized out>, ret_size=<optimized out>) at pkcs15.c:1608
#2  0x000055555555ca6d in verify_pin () at pkcs15-tool.c:1378
#3  main (argc=5, argv=<optimized out>) at pkcs15-tool.c:2444
(gdb) p p15card->ops.parse_df
$9 = (int (*)(struct sc_pkcs15_card *, struct sc_pkcs15_df *)) 0x0
(gdb) l
1370				continue;
1371			}
1372			if (df->enumerated)
1373				continue;
1374			/* Enumerate the DF's, so p15card->obj_list is populated. */
1375			if (p15card->ops.parse_df)
1376				r = p15card->ops.parse_df(p15card, df);
1377			else
1378				r = sc_pkcs15_parse_df(p15card, df);
1379			if (r != SC_SUCCESS)

instead, the legacy sc_pkcs15_parse_df() is called.

@vjardin
Copy link
Contributor Author

vjardin commented Mar 21, 2021

I got the point, (I hope), sc_pkcs15_is_emulation_only() needs a case of the SC_CARD_TYPE_IASECC_CPX too.

Once set, we get the previous p15card->ops.parse_df = _iasecc_parse_df; and then we get the call to pkcs15-iasecc.c:_iasecc_parse_df():

#0  _iasecc_parse_df (p15card=0x555555577ec0, df=<optimized out>) at pkcs15-iasecc.c:190
#1  0x00007ffff7b2da61 in __sc_pkcs15_search_objects (p15card=0x555555577ec0, class_mask=2, class_mask@entry=0, 
    type=256, func=0x0, func_arg=0x0, ret=0x7fffffffddc0, ret_size=32) at pkcs15.c:1376
#2  0x00007ffff7b2dbcc in sc_pkcs15_get_objects_cond (p15card=<optimized out>, type=<optimized out>, 
    func=<optimized out>, func_arg=<optimized out>, ret=<optimized out>, ret_size=<optimized out>) at pkcs15.c:1608
#3  0x0000555555560a22 in list_private_keys () at pkcs15-tool.c:686
#4  0x000055555555c883 in main (argc=<optimized out>, argv=<optimized out>) at pkcs15-tool.c:2468

I guess that I still need to set the proper logic in order for _iasecc_md_update_keyinfo() to be called ; currently, it is only supported for the IASECC_GEMALTO_MD_APPLICATION_NAME / IASECC_GEMALTO_MD_DEFAULT_CONT_LABEL.

I need to guess the proper container to be used, I have the 11 following dobjs->label:

CPS_DIR
CPS_ATR
CPS_TECH_1
CPS_TECH_2
CPS_ID_TECH 
CPS_ID_CARD
CPS_DATA 
CPS_NAME_PS
CPS_LANG_PS 
CPS_INFO_PS
CPS_ACTIVITY_01_PS

while Gemalto was applying their fixup for:

IASECC_GEMALTO_MD_DEFAULT_CONT_LABEL "Default Key Container"

Is the Default Key Container ~ to CPS_DIR ?!?! or any other one ? Or maybe, is it something else ??? How to get a tip ?

@vjardin
Copy link
Contributor Author

vjardin commented Mar 21, 2021

For the Gemalto's card, the ie IASECC card is patching the following for the PrKey:

        rv = sc_aux_data_set_md_guid(ctx, prkey_info->aux_data, dobj->label);
        LOG_TEST_RET(ctx, rv, "Cannot set MD CMAP Guid");

        rv = sc_aux_data_set_md_flags(ctx, prkey_info->aux_data, flags);
        LOG_TEST_RET(ctx, rv, "Cannot set MD CMAP record flags");

that was introduce by @viktorTarasov with the patch 9abf8ee

I understand that it is not going to help in order to get another value that 0 for:

	Algo_refs      : 0

please, what should be the logic in order to "patch" the Algo_refs ?

@dengert
Copy link
Member

dengert commented Mar 21, 2021

What would help you debug any changes is to use a debugger. I don't know what OS you are using, but I use Ubuntu, and the gdb debugger. gdb can run on almost any OS.
If you configure OpenSC with something like:

export CFLAGS=-g 
export LDFLAGS=-g
configure 

gdb can look at the code, set breakpoints list backtraces, execute line by line and examine variables and structures as you go and even change variable value too.

You set the title to: pkcs15_prkey_can_do CKR_FUNCTION_NOT_SUPPORTED
and it is failing at:

4463         if (!pkinfo->algo_refs[0])
4464                 return CKR_FUNCTION_NOT_SUPPORTED;

Set a breakpoint for this (check the line number in you source)

b framework-pkcs15.c:4463
run
(when it stops) 
backtrace
p *pkinfo
p *prkey

As you found from pkcs15-tool -k --verify-pin --pin 1234

Private RSA Key [CPS_PRIV_SIG]
	Object Flags   : [0x01], private
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0

it looks like algo_refs are not set.

As you pointed out pkcs15-iaeecc.c has a _iasecc_parse_df
but only looks at SC_CARD_TYPE_IASECC_GEMALTO cards.

It may need to look at your card, and you may need to make some changes here.

pkcs15-prkey.c sc_pkcs15_decode_prkdf_entry is where the algo_refs are set.
setting a breakpoint here and step through would also help.

See if in _iasecc_parse_df these lines are executed:

119         if (df->enumerated)
120                 LOG_FUNC_RETURN(ctx, SC_SUCCESS)

As I do not have one of these cards, you will have to do some debugging.

You asked: "logic in order to "patch" the Algo_refs"?
That depends on what the card can do. Based on the tokenInfo I would guess for
the CPS_PRIV_SIG and the ,CPS_PRIV_AUT keys they would have one algo_refs with value 0x04 to point to the sc_supported_algo_info[4]

@frankmorgner
Copy link
Member

It's also strange that your code jumps into sc_pkcs15_parse_df although your card offers a specific implementation for that...

Calling sc_pkcs15_parse_df is not legacy, it's just the default implementation for parsing (PR.)KDF. This very function is also used in _iasecc_parse_df for initialization. It looks like _iasecc_parse_df continues to initialize an additional minidriver data. This is not related to the data used in pkcs15_prkey_can_do.

From your data it looks like that tokeninfo (algo_refs) is correctly initialized (FID 5032). However, it seems that the private key's metadata (pkinfo) doesn't reference one of those algorithms (EF.PRKD, differen FID )... To analyze your private key's metadata, set a breakpoint in sc_pkcs15_decode_prkdf_entry as suggested by Doug.

vjardin added a commit to vjardin/OpenSC that referenced this issue Mar 22, 2021
Same than Gemalto's IASECC, the CPX cards need a workaround since
the PrKey does not have its Algo_regs.

We get:
pkcs15-tool -k --verify-pin --pin 1234
Using reader with a card: ACS ACR33U-A1 3SAM ICC Reader 00 00
Private RSA Key [CPS_PRIV_SIG]
	Object Flags   : [0x01], private
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_cds:01;
	ModLength      : 2048
	Key ref        : 129 (0x81)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001001
	MD:guid        : e7aab727-f2af-e673-37bb-7d43867a6349

Private RSA Key [CPS_PRIV_AUT]
	Object Flags   : [0x07], private, modifiable
	Usage          : [0x06], decrypt, sign
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_decrypt:01; int_auth:01;
	ModLength      : 2048
	Key ref        : 130 (0x82)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001002
	MD:guid        : 2b6bf284-225c-80bc-8cbe-1c791db33543

We need to get Algo_regs to be set to something that is not 0.

Fix: issue OpenSC#2267
@dengert
Copy link
Member

dengert commented Mar 22, 2021

Looking at your https://github.com/vjardin/OpenSC It looks like you are close.

Note that the 0x04 is the index into the tokenInfo sc_supported_algo_info[4] that supports
just CKM_RSA_PKCS.

But https://github.com/vjardin/OpenSC/blob/fixAlgoRefs/src/libopensc/card-iasecc.c#L637-L645 sets multiple flags. the flags and calls to _sc_card_add_rsa_alg should define what the card is capable of doing in hardware and lets OpenSC do the hashing and padding. But this driver actually does the SHA1 and SHA256 and maybe other stuff in the driver.

I have not looked close enough to see the card can actually do.

So there is a mis-match between what the alg_ref of 0x04 says the card and driver can do and what OpenSC thinks the card and its driver can do.

I suggest for testing only that you add just the 0x04 for now, and changed the flags to just flags = SC_ALGORITHM_RSA_PAD_PKCS1; so OpenSC will do the rest.

Then if you can get that to work, then look at what the card can really do, and what other other algo_refs need to be added for the keys. Note different cards may have the tokenInfo listed in a different order, so it may not always be 0x04.

Look at: sc_supported_algo_info and sc_pkcs15_get_supported_algo
./pkcs15init/pkcs15-iasecc.c use it to initialize one of these cards which would be similar to what you may need to do to fix the missing algo_refs. The fix maybe to just make these same calls to get the alg_refs for the two key.

@vjardin
Copy link
Contributor Author

vjardin commented Mar 22, 2021

with flags = SC_ALGORITHM_RSA_PAD_PKCS1;

The following case fails:

 ./pkcs11-tool --module ../lib/pkcs11/opensc-pkcs11.so --slot-index 0 -l --pin 1234 -s -i ./data.bin --id e828bd080f8025000001ff001001 -m SHA256-RSA-PKCS -o ./data.signed_OpenSCSHA256
Using slot with index 0 (0x0)
Using signature algorithm SHA256-RSA-PKCS
error: PKCS11 function C_SignFinal failed: rv = CKR_FUNCTION_FAILED (0x6)
Aborting.

But this case does not abort:

./pkcs11-tool --module ../lib/pkcs11/opensc-pkcs11.so --slot-index 0 -l --pin 1234 -s -i ./data.bin --id e828bd080f8025000001ff001002 -m SHA256-RSA-PKCS -o ./data.signed_OpenSCSHA256
Using slot with index 0 (0x0)
Using signature algorithm SHA256-RSA-PKCS

You can notice that they are two different IDs:

./pkcs15-tool -k --verify-pin --pin 1234
Using reader with a card: ACS ACR33U-A1 3SAM ICC Reader 00 00
Private RSA Key [CPS_PRIV_SIG]
	Object Flags   : [0x01], private
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_cds:01;
	ModLength      : 2048
	Key ref        : 129 (0x81)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001001
	MD:guid        : e7aab727-f2af-e673-37bb-7d43867a6349

Private RSA Key [CPS_PRIV_AUT]
	Object Flags   : [0x07], private, modifiable
	Usage          : [0x06], decrypt, sign
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_decrypt:01; int_auth:01;
	ModLength      : 2048
	Key ref        : 130 (0x82)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001002
	MD:guid        : 2b6bf284-225c-80bc-8cbe-1c791db33543

which is confusing but related to these logs:

 [opensc-pkcs11] card-iasecc.c:1811:iasecc_set_security_env: CKM_RSA_PKCS asked -- use 'AUTHENTICATE' sign operation instead of 'SIGN'
 [opensc-pkcs11] card-iasecc.c:1825:iasecc_set_security_env: INTERNAL_AUTHENTICATE is not allowed for this key: -1209 (Not allowed)
 [opensc-pkcs11] sec.c:109:sc_set_security_env: returning with: -1209 (Not allowed)

@vjardin
Copy link
Contributor Author

vjardin commented Mar 22, 2021

I have not looked close enough to see the card can actually do.

The card can provide SHA1 and SHA256 hashes in HW with the following APDU:

CLA 00
INS 2A
P1 90
P2 A0
Lc <= 60 means SHA1
Lc <= 6C means SHA256

see:

sc_format_apdu(card, &apdu, SC_APDU_CASE_3_SHORT, 0x2A, 0x90, 0xA0);

@vjardin
Copy link
Contributor Author

vjardin commented Mar 22, 2021

It can sign a hash that was previously computed off the card using the following APDU:

CLA 00
INS 2A
P1 9E
P2 9A
Lc 14 means SHA1
Lc 20 means SHA256

see:

sc_format_apdu(card, &apdu, SC_APDU_CASE_2_SHORT, 0x2A, 0x9E, 0x9A);

@vjardin
Copy link
Contributor Author

vjardin commented Mar 22, 2021

It can authenticate using the following APDU:

CLA 00
INS 88
P1 00
P2 00

See:

sc_format_apdu(card, &apdu, SC_APDU_CASE_4_SHORT, 0x88, 0x00, 0x00);

@dengert
Copy link
Member

dengert commented Mar 22, 2021

Can you post a full opensc-debug.log at level 9 for the case that aborted, and the case that did not abort?

@dengert
Copy link
Member

dengert commented Mar 23, 2021

In response to: "You can notice that they are two different IDs". You card has two keys:

  • CPS_PRIV_SIG can only be used to do signatures, and it failed to do that for some reason, i.e. need a debug log.
  • CPS_PRIV_AUTH can only be used to decipher but you are trying to do a signature, and I would expect that there should be more output to stderr also need a debug log.

The APDUs listed above is the second half of the operation. The APDUs sent from iasecc_set_security_env are the first part, which will also show up in a debug log.

A general comment: PKCS#15 and ISO-7816 are so complicated and flexible that card vendors only implement the parts they need and implement card middleware to use their cards. These work together and they may not follow strict PKCS#15 and ISO-7816.
There are no requirements to follow the standards, and no compliant testing. The only requirement is the vendor's middleware work with the vendor's card.
Just because you card looks like a iasecc card, it may have its own limitations, not implemented features, quirks and bugs. OpenSC is trying to address these its drivers.

For example the sc_enum_apps may fail on this card, because it was not need by the vendor's middleware. Other are the missing algo_refs and the miscoded bit strings. I suspect there are more.

The original driver was from 2010 and back then many cards tried to do all the processing on the card. These days many cards only do RSA RAW and the rest is done in the driver. Your card may not do all the operations on the card, but must have at least RSA RAW or RSA PKCS1. This is why I recommend to start with RSA PKCS1 and once that works, see what else the card can do.

@vjardin
Copy link
Contributor Author

vjardin commented Mar 24, 2021

For a signature, with this command:

pkcs11-tool --module ../lib/pkcs11/opensc-pkcs11.so --slot-index 0 -l --pin 1234 -s -i ./data.bin --id e828bd080f8025000001ff001001 -m SHA256-RSA-PKCS -o ./data.signed_OpenSCSHA256

When

        flags = 0
                | SC_ALGORITHM_ONBOARD_KEY_GEN
                | SC_ALGORITHM_RSA_PAD_ISO9796
                | SC_ALGORITHM_RSA_PAD_PKCS1
                | SC_ALGORITHM_RSA_HASH_NONE
                ;
        flags |= SC_ALGORITHM_RSA_HASH_SHA1
                | SC_ALGORITHM_RSA_HASH_SHA256;

, the logs are:

 [opensc-pkcs11] pkcs15-sec.c:709:sc_pkcs15_compute_signature: DEE flags:0x00002002 alg_info->flags:0x8000230a pad:0x00000
000 sec:0x00002002
    [....]
 [opensc-pkcs11] card-iasecc.c:1831:iasecc_set_security_env: senv.algorithm 0x0, senv.algorithm_ref 0x0
 [opensc-pkcs11] card-iasecc.c:1832:iasecc_set_security_env: se_num 0, operation 0x2, algorithm 0x0, algorithm_ref 0x0, flags 0x2002; key size 256
 [opensc-pkcs11] card-iasecc.c:1613:iasecc_get_algorithm: found IAS/ECC algorithm 2:250:40:40
 [opensc-pkcs11] card-iasecc.c:1613:iasecc_get_algorithm: found IAS/ECC algorithm 4:40:2:42

When

        flags = 0
                | SC_ALGORITHM_RSA_PAD_PKCS1
                ;

, the logs are:

 [opensc-pkcs11] pkcs15-sec.c:709:sc_pkcs15_compute_signature: DEE flags:0x00002002 alg_info->flags:0x00000002 pad:0x00002000 sec:0x00000102
 [opensc-pkcs11] padding.c:409:sc_pkcs1_encode: called
 [opensc-pkcs11] padding.c:415:sc_pkcs1_encode: hash algorithm 0x2000, pad algorithm 0x1
 [opensc-pkcs11] padding.c:435:sc_pkcs1_encode: returning with: 0 (Success)
     [...]
 [opensc-pkcs11] card-iasecc.c:1809:iasecc_set_security_env: CKM_RSA_PKCS asked -- use 'AUTHENTICATE' sign operation inst
ead of 'SIGN'
 [opensc-pkcs11] card-iasecc.c:1823:iasecc_set_security_env: INTERNAL_AUTHENTICATE is not allowed for this key: -1209 (No
t allowed)
 [opensc-pkcs11] sec.c:109:sc_set_security_env: returning with: -1209 (Not allowed)
 [opensc-pkcs11] card.c:523:sc_unlock: called

@dengert
Copy link
Member

dengert commented Mar 24, 2021

I would like to see the whole log.

@dengert
Copy link
Member

dengert commented Mar 24, 2021

If you are worried about exposing sensitive personal information, you can remove the reading and parsing of the certificates.

At least send everything after the call to sc_pkcs15_compute_signature

From the above, and source code, there is another whole area that needs to be looked at.
iasecc_set_security_env calls iasecc_sdo_convert_acl in iasecc-sdo.c which looks like it is enforcing some ACL restrictions, and sets a sign_ref or auth_ref.
rv = iasecc_sdo_convert_acl(card, &sdo, SC_AC_OP_PSO_COMPUTE_SIGNATURE, &sign_meth, &sign_ref);

1731         if (operation == SC_SEC_OPERATION_SIGN)   {
1732                 if (!(aflags & (SC_ALGORITHM_RSA_HASH_SHA1 | SC_ALGORITHM_RSA_HASH_SHA256)))

is enforcing a restriction to have the card or card driver do the SHA1 or SHA256.

So unlike other cards, the use of just flags = SC_ALGORITHM_RSA_PAD_PKCS1; is not going to work. So testing with this simple flag will not work.

So only need the log when using the original flags.

@vjardin
Copy link
Contributor Author

vjardin commented Mar 24, 2021

Enclosed the full logs.

@dengert
Copy link
Member

dengert commented Mar 24, 2021

As noted in #2267 (comment) the card driver wants to do the hashing, or all but last block in software, so https://github.com/OpenSC/OpenSC/files/6198173/opensc-debugSC_ALGORITHM_RSA_PAD_PKCS1.log.gz will always fail.

But it looks like https://github.com/OpenSC/OpenSC/files/6198174/opensc-debugIASECC_CARD_DEFAULT_FLAGS.log.gz actually worked.
The pkcs11 C_SignInit starts at 12699 and ends at 13109.

So what is still outstanding?
Can you verify the signature using OpenSSL?

@vjardin
Copy link
Contributor Author

vjardin commented Mar 24, 2021

The verify is the following:

./pkcs11-tool --module ../lib/pkcs11/opensc-pkcs11.so --slot-index 0 -l --pin 1234 -s -i ./data.bin --id e828bd080f8025000001ff001001 -m SHA256-RSA-PKCS -o ./data.signed_OpenSCSHA256
Using slot with index 0 (0x0)
Using signature algorithm SHA256-RSA-PKCS

./pkcs11-tool --id e828bd080f8025000001ff001001 --verify -m SHA256-RSA-PKCS  --module ../lib/pkcs11/opensc-pkcs11.so  --input-file data.bin --signature-file data.signed_OpenSCSHA256
Using slot 0 with a present token (0x0)
Using signature algorithm SHA256-RSA-PKCS
Invalid signature

@dengert
Copy link
Member

dengert commented Mar 24, 2021

From https://github.com/OpenSC/OpenSC/files/6198174/opensc-debugIASECC_CARD_DEFAULT_FLAGS.log.gz the signature appears to be:

1D B0 3E 1A EB C4 28 D0 47 9E 13 A3 95 52 57 D0 
2E 77 9E A2 B9 73 F9 28 20 B9 0C 73 5F 3C 8F 10 
94 1B 16 DF 41 C5 B9 70 E9 D3 4A D1 A0 05 F7 2E 
41 16 49 64 67 FD 42 EC 7B C0 33 3D B2 0A 20 DA 
0B 7D 4D E0 A2 F9 11 C6 50 A8 A0 31 55 A8 20 9A 
0C 62 82 A5 97 50 95 AE B2 98 05 95 00 39 40 26 
CF 54 BE B1 26 4E 63 EF 6C 92 86 24 78 DE D5 64 
61 6A D6 FF 04 23 87 D6 FD 73 ED 00 70 6D 72 21 
70 F7 6D 2E 9B F0 1E 31 77 03 EB F4 D6 D6 7F 0C 
2D A6 B2 02 45 1D EE D3 72 FA A5 D1 5C 41 63 74 
85 3C EF 51 17 F0 B9 49 F0 AF 61 4F F1 89 8A 58 
5E BF A2 A1 03 E2 75 2E 7F FE 57 E5 64 1D 9B 57 
85 04 C8 D5 12 8F 2D AD D1 69 82 55 08 0B 8D F6 
F6 06 9D C0 C3 39 FC 55 D7 87 64 B1 AB 50 E7 9B 
C1 E2 86 97 CC 57 59 BB 43 2D DF 11 CF 20 B7 63 
11 8C AB 06 23 D0 6F 43 A9 8E 7E E7 66 5F 52 38

pubkey from certificate is:

30 82 01 22
300D06092A864886F70D010101050003 82010F003082010A0282010100A68A4C 541733459F0F65B62F83CE86D1533FB6
6A88A4B535499490F186DED699B76EB0 CA1866A31BA1D5BD7B6F7C14FB695F59 AC66002F4DFA14572E09CE65F081C2A9
C740296FF782055E0E23DCB27FD85F0A E2CD965BEA3986526929D399F2D7766B 95D6DE7AE4BC17841F3E7A1F7749D3CE
731A20B8303BBEFF1930B01F95B6584A CD3C67A2C2517E2F6C7DA0C6E2D16F16 739DD5F2FD50BA02C590D6046C8F0568
BB6D7CB3B4705D153E72FA900D5B9366 696790FE04BDA47D450DD77BA235FCBA 1AAE804F6796482C9F3DA393F565E332
44AD21235FF27FE49AECBE8FD1593532 FAA9C07A819EE5FE59AD544639B2CD13 5126C5E5A64A173CEE2812230F020301
0001

or this from the other certificate:

0 82 01 22
300D06092A864886F70D010101050003 82010F003082010A0282010100A68A4C 541733459F0F65B62F83CE86D1533FB6
6A88A4B535499490F186DED699B76EB0 CA1866A31BA1D5BD7B6F7C14FB695F59 AC66002F4DFA14572E09CE65F081C2A9
C740296FF782055E0E23DCB27FD85F0A E2CD965BEA3986526929D399F2D7766B 95D6DE7AE4BC17841F3E7A1F7749D3CE
731A20B8303BBEFF1930B01F95B6584A CD3C67A2C2517E2F6C7DA0C6E2D16F16 739DD5F2FD50BA02C590D6046C8F0568
BB6D7CB3B4705D153E72FA900D5B9366 696790FE04BDA47D450DD77BA235FCBA 1AAE804F6796482C9F3DA393F565E332
44AD21235FF27FE49AECBE8FD1593532 FAA9C07A819EE5FE59AD544639B2CD13 5126C5E5A64A173CEE2812230F020301
0001

But I don't know what was the data.in file. Using xxd -r -p xxxxx.txt > xxxxx.der to convert hex data from above to sig.der and pubkey.der
openssl dgst -verify pubkey.der -keyform DER -sha256 -signature sig.bin data.in

openssl dgst -verify key.pub -keyform PEM -sha256 -signature data.zip.sign -binary data.zip

@vjardin
Copy link
Contributor Author

vjardin commented Mar 25, 2021

data.bin is just a string of 'x':

$ cat data.bin
xxxxxxxxxxxxxxxxxxx
$ ls -la data.bin 
... 20 ... data.bin
$ wc -c data.bin
20 data.bin

One more inside regarding the SHA256 APDU, with opensc, it is:

00 2A 90 A0 24 90 00 80 20 B3 25 D3 6F 0C F2 0C .*..$... .%.o...
D0 77 D0 65 E1 63 CB 72 27 0B 3D D8 E2 01 C6 39 .w.e.c.r'.=....9
20 08 A1 97 1C D2 FA 41 20  

with the card's driver, it is:

00 2A 90 A0 18 90 00 80 14 78 78 78 78 78 78 78 .*.......xxxxxxx
78 78 78 78 78 78 78 78 78 78 78 78 0A          xxxxxxxxxxxx.

We can notice that the card driver is sending the 20 'x' of data.bin, while opensc seems to send a software hash of the string 'x'.

Back to the root of this issue, if I enforce:

diff --git a/src/pkcs11/mechanism.c b/src/pkcs11/mechanism.c
index 983d8dcb..bb4be109 100644
--- a/src/pkcs11/mechanism.c
+++ b/src/pkcs11/mechanism.c
@@ -381,6 +381,7 @@ sc_pkcs11_signature_init(sc_pkcs11_operation_t *operation,
 
        if (key->ops->can_do)   {
                rv = key->ops->can_do(operation->session, key, operation->type->mech, CKF_SIGN);
                rv = CKR_OK; // XXX XXX XXXXXXXXX
                if (rv == CKR_OK)   {
                        /* Mechanism recognised and can be performed by pkcs#15 card */
                        can_do_it = 1;

then opensc has a proper APDU:

Outgoing APDU (29 bytes):
00 2A 90 A0 18 90 00 80 14 78 78 78 78 78 78 78 .*.......xxxxxxx
78 78 78 78 78 78 78 78 78 78 78 78 0A          xxxxxxxxxxxx.

I'll perform some investigations tonight.

@dengert
Copy link
Member

dengert commented Mar 25, 2021

Thanks for the feed back.
The root of the problem is the key does not have any pkinfo->algo_refs[0]
https://github.com/vjardin/OpenSC/blob/master/src/pkcs11/framework-pkcs15.c#L4540-L4543
This should show up is a debug log message like:
framework-pkcs15.c:4537:pkcs15_prkey_can_do

Your dump has:
pkcs15-iasecc.c:169:_iasecc_parse_df: Warning: the 25007 card has an invalid DF, hot patch to be applied
What does this code do? I don't see it in your https://github.com/vjardin/OpenSC/blob/master/src/libopensc/pkcs15-iasecc.c.

It looks like you need to add right after this:
sc_log(ctx, "parse of SC_PKCS15_PRKDF"); something like:

rv = sc_pkcs15_get_objects(p15card, SC_PKCS15_TYPE_PRKEY, kobjs, sizeof(kobjs)/sizeof(kobjs[0]));
loop through these, and fixup the algo_refs. 
https://github.com/OpenSC/OpenSC/issues/2267#issuecomment-803555577 lists what is in the toking info,
and I would assume the CPS_PRIV_SIG key could do all the "signature" algos. So find all the "signature` ones, and add
the index to `sc_pkcs15_prkey_info`  `algo_refs` 

I would expect it to have have 3 entries, 2, 3, 4
The other key would have just one: 5.  But leave that for another day.











`sc_pkcs15_is_emulation_only` SC_CARD_TYPE_IASECC_GEMALTO











@vjardin
Copy link
Contributor Author

vjardin commented Mar 25, 2021

Your dump has:
pkcs15-iasecc.c:169:_iasecc_parse_df: Warning: the 25007 card has an invalid DF, hot patch to be applied
What does this code do? I don't see it in your https://github.com/vjardin/OpenSC/blob/master/src/libopensc/pkcs15-iasecc.c

see the WIP branch: https://github.com/vjardin/OpenSC/blob/c7a477e1e43d2310a9f3464759bab5af9c7debc8/src/libopensc/pkcs15-iasecc.c#L167

@vjardin
Copy link
Contributor Author

vjardin commented Mar 25, 2021

t looks like you need to add right after this:
sc_log(ctx, "parse of SC_PKCS15_PRKDF"); something like:

rv = sc_pkcs15_get_objects(p15card, SC_PKCS15_TYPE_PRKEY, kobjs, sizeof(kobjs)/sizeof(kobjs[0]));

loop through these, and fixup the algo_refs.

WIP here: https://github.com/vjardin/OpenSC/blob/c7a477e1e43d2310a9f3464759bab5af9c7debc8/src/libopensc/pkcs15-iasecc.c#L131

my issue is to find the proper N values of each algo_refs[x] = N for each x.

vjardin added a commit to vjardin/OpenSC that referenced this issue Mar 25, 2021
Same than Gemalto's IASECC, the CPX cards need a workaround since
the PrKey does not have its Algo_regs.

We get:
pkcs15-tool -k --verify-pin --pin 1234
Using reader with a card: ACS ACR33U-A1 3SAM ICC Reader 00 00
Private RSA Key [CPS_PRIV_SIG]
	Object Flags   : [0x01], private
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_cds:01;
	ModLength      : 2048
	Key ref        : 129 (0x81)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001001
	MD:guid        : e7aab727-f2af-e673-37bb-7d43867a6349

Private RSA Key [CPS_PRIV_AUT]
	Object Flags   : [0x07], private, modifiable
	Usage          : [0x06], decrypt, sign
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_decrypt:01; int_auth:01;
	ModLength      : 2048
	Key ref        : 130 (0x82)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001002
	MD:guid        : 2b6bf284-225c-80bc-8cbe-1c791db33543

We need to get Algo_regs to be set to something that is not 0.

Fix: issue OpenSC#2267
vjardin added a commit to vjardin/OpenSC that referenced this issue Mar 25, 2021
Same than Gemalto's IASECC, the CPX cards need a workaround since
the PrKey does not have its Algo_regs.

We get:
pkcs15-tool -k --verify-pin --pin 1234
Using reader with a card: ACS ACR33U-A1 3SAM ICC Reader 00 00
Private RSA Key [CPS_PRIV_SIG]
	Object Flags   : [0x01], private
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_cds:01;
	ModLength      : 2048
	Key ref        : 129 (0x81)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001001
	MD:guid        : e7aab727-f2af-e673-37bb-7d43867a6349

Private RSA Key [CPS_PRIV_AUT]
	Object Flags   : [0x07], private, modifiable
	Usage          : [0x06], decrypt, sign
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_decrypt:01; int_auth:01;
	ModLength      : 2048
	Key ref        : 130 (0x82)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001002
	MD:guid        : 2b6bf284-225c-80bc-8cbe-1c791db33543

We need to get Algo_regs to be set to something that is not 0.

Fix: issue OpenSC#2267
@vjardin
Copy link
Contributor Author

vjardin commented Mar 25, 2021

Thanks to your tips @dengert , with the latest update, we get the signature working. Moreover, the keys are enumerated:

$ ./pkcs15-tool --list-info --verify-pin  --pin 1234
Using reader with a card: ACS ACR33U-A1 3SAM ICC Reader 00 00
PKCS#15 Card [CPS3v3-2600971845]:
	Version        : 0
	Serial number  : 000001992148038F
	Manufacturer ID: ASIP SANTE
	Last update    : 20100316110000Z
	Flags          : Read-only, Login required
		 sc_supported_algo_info[0]:
			 reference  : 1 (0x01)
			 mechanism  : [0x220] CKM_SHA_1                    
			 operations : [0x40], hash
			 algo_id    : 1.3.14.3.2.26
			 algo_ref   : [0x10]
		 sc_supported_algo_info[1]:
			 reference  : 2 (0x02)
			 mechanism  : [0x250] CKM_SHA256                   
			 operations : [0x40], hash
			 algo_id    : 2.16.840.1.101.3.4.2.1
			 algo_ref   : [0x40]
		 sc_supported_algo_info[2]:
			 reference  : 3 (0x03)
			 mechanism  : [0x06] CKM_SHA1_RSA_PKCS            
			 operations : [0x02], compute_signature
			 algo_id    : 1.2.840.113549.1.1.5
			 algo_ref   : [0x12]
		 sc_supported_algo_info[3]:
			 reference  : 4 (0x04)
			 mechanism  : [0x40] CKM_SHA256_RSA_PKCS          
			 operations : [0x02], compute_signature
			 algo_id    : 1.2.840.113549.1.1.11
			 algo_ref   : [0x42]
		 sc_supported_algo_info[4]:
			 reference  : 5 (0x05)
			 mechanism  : [0x01] CKM_RSA_PKCS                 
			 operations : [0x02], compute_signature
			 algo_id    : 1.2.840.113549.1.1.1
			 algo_ref   : [0x02]
		 sc_supported_algo_info[5]:
			 reference  : 6 (0x06)
			 mechanism  : [0x01] CKM_RSA_PKCS                 
			 operations : [0x20], decipher
			 algo_id    : 1.2.840.113549.1.1.1
			 algo_ref   : [0x1a]
$ ./pkcs15-tool -k --verify-pin  --pin 1234         
Using reader with a card: ACS ACR33U-A1 3SAM ICC Reader 00 00
Private RSA Key [CPS_PRIV_SIG]
	Object Flags   : [0x01], private
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 1, 2, 3, 4
	Access Rules   : pso_cds:01;
	ModLength      : 2048
	Key ref        : 129 (0x81)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001001
	MD:guid        : e7aab727-f2af-e673-37bb-7d43867a6349

Private RSA Key [CPS_PRIV_AUT]
	Object Flags   : [0x07], private, modifiable
	Usage          : [0x06], decrypt, sign
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 5, 6
	Access Rules   : pso_decrypt:01; int_auth:01;
	ModLength      : 2048
	Key ref        : 130 (0x82)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001002
	MD:guid        : 2b6bf284-225c-80bc-8cbe-1c791db33543

I am not sure of the proper list (1, 2, 3, 4) then (5, 6). Feel free to comment.

If it is the proper enumeration, should I keep the 'hard corded' matrix into pkcs15-iasecc.c ? or Should I try to get something more dynamic based on some flags from sc_supported_algo_info[] ?

@dengert
Copy link
Member

dengert commented Mar 25, 2021

OK Progress!

I am not sure if the prkey Algo_refs should be the index in tokenInfo supported algos or the reference from the tokenInfo supported algos.

Rather then hard coding I would rewrite the WIP to use the tokenInfo supported algos and for the CPS_PRIV_SIG
if operation == compute_signature then add the index. i.e. will end up with 2, 3, 4 or the reference 3, 4, 5

For the CPS_PRIV_AUT if the operation == decipher then add it. i.e. index 5 or reference 6
Not sure how to handle the "int_auth". Not sure how it is to be used.

I would not add the mechanism : [0x220] CKM_SHA_1 or mechanism : [0x250] CKM_SHA256 to the key info because they are standalone mechanisms which do not need a key. Note that the PKCS11 mechanism
CKM_SHA256_RSA_PKCS has 3 parts, the hash to be used, pkcs1 padding is to be used and RSA it to be used.

In one of the debug logs, iasecc cards can support Secure Messaging.
[opensc-pkcs11] iasecc-sm.c:276:iasecc_sm_initialize: called
but it fails. Your card may not support it, or there is something else wrong. the "int_auth" might be related.

@vjardin
Copy link
Contributor Author

vjardin commented Mar 26, 2021

I am not sure if the prkey Algo_refs should be the index in tokenInfo supported algos or the reference from the tokenInfo supported algos.

The logic is from pkcs15_prkey_can_do(),

for (ii=0;ii<SC_MAX_SUPPORTED_ALGORITHMS && pkinfo->algo_refs[ii];ii++) {
/* Look for algorithm supported by token referenced in the list of key's algorithms */
for (jj=0;jj<SC_MAX_SUPPORTED_ALGORITHMS && (token_algos + jj)->reference; jj++)
if (pkinfo->algo_refs[ii] == (token_algos + jj)->reference)
break;
if ((jj == SC_MAX_SUPPORTED_ALGORITHMS) || !(token_algos + jj)->reference)
LOG_FUNC_RETURN(context, CKR_GENERAL_ERROR);
if ((token_algos + jj)->mechanism != mech_type)
continue;
if (flags == CKF_SIGN)
if ((token_algos + jj)->operations & SC_PKCS15_ALGO_OP_COMPUTE_SIGNATURE)
break;
if (flags == CKF_DECRYPT)
if ((token_algos + jj)->operations & SC_PKCS15_ALGO_OP_DECIPHER)
break;
; it seems to be the reference instead of the index, doesn't it ?
I mean,

info->algo_refs[0..SC_MAX_SUPPORTED_ALGORITHMS] = ReferenceX;

Rather then hard coding I would rewrite the WIP to use the tokenInfo supported algos and for the CPS_PRIV_SIG
if operation == compute_signature then add the index. i.e. will end up with 2, 3, 4 or the reference 3, 4, 5

Newbie question: how do I get the operation from _iasecc_cpx_fixup_prkdf() ? Should you have any "pseudo-code", it would be easier for me to catch up.

For the CPS_PRIV_AUT if the operation == decipher then add it. i.e. index 5 or reference 6

Do you mean something like:

                case 'S': /* CPS_PRIV_SIG */
                        sc_log(ctx, "Fix up algo_refs for CPS_PRIV_SIG");
#if 0
                        info->algo_refs[0] = 1; /* hash, CKM_SHA_1, TBC ??? */
                        info->algo_refs[1] = 2; /* hash, CKM_SHA256, TBC ??? */
#endif
                        info->algo_refs[0] = 3; /* compute_signature, CKM_SHA1_RSA_PKCS */
                        info->algo_refs[1] = 4; /* compute_signature, CKM_SHA256_RSA_PKCS */
                        info->algo_refs[2] = 5; /* compute_signature, CKM_RSA_PKCS */
                break;
                case 'A': /* CPS_PRIV_AUT */
                        sc_log(ctx, "Fix up algo_refs for CPS_PRIV_AUT");
                        info->algo_refs[0] = 6; /* decipher, CKM_RSA_PKCS */
                break;

???

Not sure how to handle the "int_auth". Not sure how it is to be used.

Frankly, I do not know what int_auth SC_PKCS15_ACCESS_RULE_MODE_INT_AUTH means ; please can you elaborate ?

I would not add the mechanism : [0x220] CKM_SHA_1 or mechanism : [0x250] CKM_SHA256 to the key info because they are standalone mechanisms which do not need a key.

ok

In one of the debug logs, iasecc cards can support Secure Messaging.
[opensc-pkcs11] iasecc-sm.c:276:iasecc_sm_initialize: called
but it fails. Your card may not support it, or there is something else wrong. the "int_auth" might be related.

Right, I did notice it, but I guess it can be a topic to be managed later on. Prior focusing on this topic, I would need both: (1) understand int_auth, and (2) check if the CPx can support such Secure Messaging. I do not believe that we need to get it done for this issue.

@dengert
Copy link
Member

dengert commented Mar 26, 2021

OpenSC has the ability to initialize iasecc cards. You would not do that with your healthcare card but there are a number of routines and comments that can help. Look in src/pkcs15init for any file with "iasecc".

iasecc_pkcs15_encode_supported_algos calls sc_pkcs15_get_supported_algo and sc_pkcs15_add_supported_algo_ref to update the objects algo_refs array. So the code might be a call to iasecc_pkcs15_encode_supported_algos for each of the 2 keys. You don't have to use "case 'S': /* CPS_PRIV_SIG /" or "case 'A': / CPS_PRIV_AUT */" because that is done in
iasecc_pkcs15_encode_supported_algos based on the prkey_info->usage.

@vjardin
Copy link
Contributor Author

vjardin commented Mar 26, 2021

The only call to iasecc_pkcs15_encode_supported_algos() is from iasecc_pkcs15_generate_key() which does not occur at all with pkcs15-tool -k --verify-pin --pin 1234

$ grep iasecc_pkcs15_generate_key /tmp/opensc-debug.log 
$ grep iasecc_pkcs15_encode_supported_algos /tmp/opensc-debug.log 

So, I do not understand how to apply your tip ?

@dengert
Copy link
Member

dengert commented Mar 26, 2021

Something like this to use the existing routine in src/pkcs15init/pkcs15-iaesecc.c It compiles against OpenSC master, but not tested.

iasecc-fix-algo.diff.txt

@vjardin
Copy link
Contributor Author

vjardin commented Mar 27, 2021

Thanks @dengert , the outcome of your patch leads to:

pkcs15-tool -k --verify-pin  --pin 1234
Using reader with a card: ACS ACR33U-A1 3SAM ICC Reader 00 00
Private RSA Key [CPS_PRIV_SIG]
	Object Flags   : [0x01], private
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_cds:01;
	ModLength      : 2048
	Key ref        : 129 (0x81)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001001
	MD:guid        : e7aab727-f2af-e673-37bb-7d43867a6349

Private RSA Key [CPS_PRIV_AUT]
	Object Flags   : [0x07], private, modifiable
	Usage          : [0x06], decrypt, sign
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 6, 5
	Access Rules   : pso_decrypt:01; int_auth:01;
	ModLength      : 2048
	Key ref        : 130 (0x82)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001002
	MD:guid        : 2b6bf284-225c-80bc-8cbe-1c791db33543

that includes the following call:

 [pkcs15-tool] pkcs15-iasecc.c:201:_iasecc_parse_df: parse of SC_PKCS15_PRKDF
 [pkcs15-tool] pkcs15-iasecc.c:789:iasecc_pkcs15_encode_supported_algos: called
 [pkcs15-tool] pkcs15-iasecc.c:790:iasecc_pkcs15_encode_supported_algos: encode supported algos for object(CPS_PRIV_SIG,type:101)
 [pkcs15-tool] pkcs15-iasecc.c:793:iasecc_pkcs15_encode_supported_algos: PrKey Usage:200,Access:D
 [pkcs15-tool] pkcs15-iasecc.c:825:iasecc_pkcs15_encode_supported_algos: returning with: 0 (Success)
 [pkcs15-tool] pkcs15-iasecc.c:789:iasecc_pkcs15_encode_supported_algos: called
 [pkcs15-tool] pkcs15-iasecc.c:790:iasecc_pkcs15_encode_supported_algos: encode supported algos for object(CPS_PRIV_AUT,type:101)
 [pkcs15-tool] pkcs15-iasecc.c:793:iasecc_pkcs15_encode_supported_algos: PrKey Usage:6,Access:D
 [pkcs15-tool] pkcs15.c:2623:sc_pkcs15_get_supported_algo: found supported algorithm (ref:6,mech:1,ops:20,algo_ref:1A)
 [pkcs15-tool] pkcs15.c:2623:sc_pkcs15_get_supported_algo: found supported algorithm (ref:5,mech:1,ops:2,algo_ref:2)
 [pkcs15-tool] pkcs15-iasecc.c:818:iasecc_pkcs15_encode_supported_algos: algoReference 6
 [pkcs15-tool] pkcs15-iasecc.c:818:iasecc_pkcs15_encode_supported_algos: algoReference 5
 [pkcs15-tool] pkcs15-iasecc.c:825:iasecc_pkcs15_encode_supported_algos: returning with: 0 (Success)

So, the case CPS_PRIV_AUT works fine:

$ pkcs11-tool --module ../lib/pkcs11/opensc-pkcs11.so --slot-index 0 -l --pin 1234 -s -i ./data.bin --id e828bd080f8025000001ff001002 -m RSA-PKCS -o ./data.signed_OpenSCRSA  
Using slot with index 0 (0x0)
Using signature algorithm RSA-PKCS

$ pkcs11-tool --id e828bd080f8025000001ff001002 --verify -m RSA-PKCS --module ../lib/pkcs11/opensc-pkcs11.so  --input-file data.bin --signature-file data.signed_OpenSCRSA 
Using slot 0 with a present token (0x0)
Using signature algorithm RSA-PKCS
Signature is valid

but the case CPS_PRIV_SIG does not work:

$ pkcs11-tool --module ../lib/pkcs11/opensc-pkcs11.so --slot-index 0 -l --pin 1234 -s -i ./data.bin --id e828bd080f8025000001ff001001 -m SHA1-RSA-PKCS -o ./data.signed_OpenSCSHA1
Using slot with index 0 (0x0)
Using signature algorithm SHA1-RSA-PKCS

$ pkcs11-tool --id e828bd080f8025000001ff001001 --verify -m SHA1-RSA-PKCS --module ../lib/pkcs11/opensc-pkcs11.so  --input-file data.bin --signature-file data.signed_OpenSCSHA1
Using slot 0 with a present token (0x0)
Using signature algorithm SHA1-RSA-PKCS
Invalid signature

because we are missing the enumeration of its Algo_refs:

	Algo_refs      : 0

I do not get the point yet: why is iasecc_pkcs15_encode_supported_algos() missing this case ?!

@dengert
Copy link
Member

dengert commented Mar 27, 2021

The problem could be in `pkcs15init/pkcs15-iasecc.c

 800                 if (prkey_info->usage & SC_PKCS15_PRKEY_USAGE_SIGN)   {
 801                         if (prkey_info->usage & SC_PKCS15_PRKEY_USAGE_NONREPUDIATION)   {

based on Usage : [0x200], nonRepudiation the SC_PKCS15_PRKEY_USAGE_NONREPUDIATION may be set but not the SC_PKCS15_PRKEY_USAGE_SIGN so line 801 is never tested.

Try changing line 800 to:
800 if (prkey_info->usage & (SC_PKCS15_PRKEY_USAGE_SIGN | SC_PKCS15_PRKEY_USAGE_NONREPUDIATION )) {

Having just SC_PKCS15_PRKEY_USAGE_NONREPUDIATION set and not doing anything does not make any sense for any card.

@vjardin
Copy link
Contributor Author

vjardin commented Mar 27, 2021

I'll double check. I think you are right but...

@dengert
Copy link
Member

dengert commented Mar 27, 2021

iasecc_pkcs15_encode_supported_algos should be the right routine, as it is used to set the algos before the key is written to the card. On you card it looks like that was not done when the card was issued. Calling it when we go to use the key to set bits in memory should have worked.

Did you change line 800? lines 800 and 801 look very similar.

Can you use gdb and set breakpoint iasecc_pkcs15_encode_supported_algos and check the logic.

@dengert
Copy link
Member

dengert commented Mar 27, 2021

I keep saying the card vendor failed to add the algReference but see:
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-prkey.c#L81-L82
The vendor may be following PKCS#15-v1.1 but pkcs15-iasecc.c is expecting algReference to be present.

So any fix we come up with might apply to other PKCS15 cards not just iasecc cards.
I don't do much with PKCS15, so other drivers may not depend on the algReference.

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-prkey.c#L323-L354 is also interesting.
It fixes info.key_reference but only checks: "/* If access_mode is one of the private key usage modes */" and only logs it as a warning.

vjardin added a commit to vjardin/OpenSC that referenced this issue Mar 27, 2021
Same than Gemalto's IASECC, the CPX cards need a workaround since
the PrKey does not have its Algo_regs.

We get:
pkcs15-tool -k --verify-pin --pin 1234
Using reader with a card: ACS ACR33U-A1 3SAM ICC Reader 00 00
Private RSA Key [CPS_PRIV_SIG]
	Object Flags   : [0x01], private
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_cds:01;
	ModLength      : 2048
	Key ref        : 129 (0x81)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001001
	MD:guid        : e7aab727-f2af-e673-37bb-7d43867a6349

Private RSA Key [CPS_PRIV_AUT]
	Object Flags   : [0x07], private, modifiable
	Usage          : [0x06], decrypt, sign
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_decrypt:01; int_auth:01;
	ModLength      : 2048
	Key ref        : 130 (0x82)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001002
	MD:guid        : 2b6bf284-225c-80bc-8cbe-1c791db33543

We need to get Algo_regs to be set to something that is not 0.

Fix: issue OpenSC#2267
@vjardin
Copy link
Contributor Author

vjardin commented Mar 27, 2021

Thanks @dengert , I included your suggestions : it works fine and it is much better thanks to the usage of iasecc_pkcs15_encode_supported_algos().

Regarding:

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-prkey.c#L323-L354 is also interesting.
It fixes info.key_reference but only checks: "/* If access_mode is one of the private key usage modes */" and only logs it as a warning.

I am concerned that it would have a wide impact beside the IAS/ECC cards. I feel that it should be a next step after this issue using some cards that rise this "Warning: No auth ID found".
Nevertheless, it seems it was missing from the logic from @viktorTarasov 's commit 4be79f3 ; I am wondering if he could comment.

vjardin added a commit to vjardin/OpenSC that referenced this issue Mar 30, 2021
Same than Gemalto's IASECC, the CPX cards need a workaround since
the PrKey does not have its Algo_regs.

We get:
pkcs15-tool -k --verify-pin --pin 1234
Using reader with a card: ACS ACR33U-A1 3SAM ICC Reader 00 00
Private RSA Key [CPS_PRIV_SIG]
	Object Flags   : [0x01], private
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_cds:01;
	ModLength      : 2048
	Key ref        : 129 (0x81)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001001
	MD:guid        : e7aab727-f2af-e673-37bb-7d43867a6349

Private RSA Key [CPS_PRIV_AUT]
	Object Flags   : [0x07], private, modifiable
	Usage          : [0x06], decrypt, sign
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_decrypt:01; int_auth:01;
	ModLength      : 2048
	Key ref        : 130 (0x82)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001002
	MD:guid        : 2b6bf284-225c-80bc-8cbe-1c791db33543

We need to get Algo_regs to be set to something that is not 0.

Fix: issue OpenSC#2267
vjardin added a commit to vjardin/OpenSC that referenced this issue Mar 31, 2021
Same than Gemalto's IASECC, the CPX cards need a workaround since
the PrKey does not have its Algo_regs.

We get:
pkcs15-tool -k --verify-pin --pin 1234
Using reader with a card: ACS ACR33U-A1 3SAM ICC Reader 00 00
Private RSA Key [CPS_PRIV_SIG]
	Object Flags   : [0x01], private
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_cds:01;
	ModLength      : 2048
	Key ref        : 129 (0x81)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001001
	MD:guid        : e7aab727-f2af-e673-37bb-7d43867a6349

Private RSA Key [CPS_PRIV_AUT]
	Object Flags   : [0x07], private, modifiable
	Usage          : [0x06], decrypt, sign
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_decrypt:01; int_auth:01;
	ModLength      : 2048
	Key ref        : 130 (0x82)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001002
	MD:guid        : 2b6bf284-225c-80bc-8cbe-1c791db33543

We need to get Algo_regs to be set to something that is not 0.

Fix: issue OpenSC#2267
vjardin added a commit to vjardin/OpenSC that referenced this issue Apr 1, 2021
Same than Gemalto's IASECC, the CPX cards need a workaround since
the PrKey does not have its Algo_regs.

We get:
pkcs15-tool -k --verify-pin --pin 1234
Using reader with a card: ACS ACR33U-A1 3SAM ICC Reader 00 00
Private RSA Key [CPS_PRIV_SIG]
	Object Flags   : [0x01], private
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_cds:01;
	ModLength      : 2048
	Key ref        : 129 (0x81)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001001
	MD:guid        : e7aab727-f2af-e673-37bb-7d43867a6349

Private RSA Key [CPS_PRIV_AUT]
	Object Flags   : [0x07], private, modifiable
	Usage          : [0x06], decrypt, sign
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_decrypt:01; int_auth:01;
	ModLength      : 2048
	Key ref        : 130 (0x82)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001002
	MD:guid        : 2b6bf284-225c-80bc-8cbe-1c791db33543

We need to get Algo_regs to be set to something that is not 0.

Fix: issue OpenSC#2267
vjardin added a commit to vjardin/OpenSC that referenced this issue Apr 15, 2021
Same than Gemalto's IASECC, the CPX cards need a workaround since
the PrKey does not have its Algo_regs.

We get:
pkcs15-tool -k --verify-pin --pin 1234
Using reader with a card: ACS ACR33U-A1 3SAM ICC Reader 00 00
Private RSA Key [CPS_PRIV_SIG]
	Object Flags   : [0x01], private
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_cds:01;
	ModLength      : 2048
	Key ref        : 129 (0x81)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001001
	MD:guid        : e7aab727-f2af-e673-37bb-7d43867a6349

Private RSA Key [CPS_PRIV_AUT]
	Object Flags   : [0x07], private, modifiable
	Usage          : [0x06], decrypt, sign
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_decrypt:01; int_auth:01;
	ModLength      : 2048
	Key ref        : 130 (0x82)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001002
	MD:guid        : 2b6bf284-225c-80bc-8cbe-1c791db33543

We need to get Algo_regs to be set to something that is not 0.

Fix: issue OpenSC#2267
vjardin added a commit to vjardin/OpenSC that referenced this issue Apr 15, 2021
Same than Gemalto's IASECC, the CPX cards need a workaround since
the PrKey does not have its Algo_regs.

We get:
pkcs15-tool -k --verify-pin --pin 1234
Using reader with a card: ACS ACR33U-A1 3SAM ICC Reader 00 00
Private RSA Key [CPS_PRIV_SIG]
	Object Flags   : [0x01], private
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_cds:01;
	ModLength      : 2048
	Key ref        : 129 (0x81)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001001
	MD:guid        : e7aab727-f2af-e673-37bb-7d43867a6349

Private RSA Key [CPS_PRIV_AUT]
	Object Flags   : [0x07], private, modifiable
	Usage          : [0x06], decrypt, sign
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_decrypt:01; int_auth:01;
	ModLength      : 2048
	Key ref        : 130 (0x82)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001002
	MD:guid        : 2b6bf284-225c-80bc-8cbe-1c791db33543

We need to get Algo_regs to be set to something that is not 0.

Fix: issue OpenSC#2267
frankmorgner pushed a commit that referenced this issue Apr 26, 2021
Same than Gemalto's IASECC, the CPX cards need a workaround since
the PrKey does not have its Algo_regs.

We get:
pkcs15-tool -k --verify-pin --pin 1234
Using reader with a card: ACS ACR33U-A1 3SAM ICC Reader 00 00
Private RSA Key [CPS_PRIV_SIG]
	Object Flags   : [0x01], private
	Usage          : [0x200], nonRepudiation
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_cds:01;
	ModLength      : 2048
	Key ref        : 129 (0x81)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001001
	MD:guid        : e7aab727-f2af-e673-37bb-7d43867a6349

Private RSA Key [CPS_PRIV_AUT]
	Object Flags   : [0x07], private, modifiable
	Usage          : [0x06], decrypt, sign
	Access Flags   : [0x0D], sensitive, alwaysSensitive, neverExtract
	Algo_refs      : 0
	Access Rules   : pso_decrypt:01; int_auth:01;
	ModLength      : 2048
	Key ref        : 130 (0x82)
	Native         : yes
	Path           : e828bd080f8025000001ff0010::
	Auth ID        : 01
	ID             : e828bd080f8025000001ff001002
	MD:guid        : 2b6bf284-225c-80bc-8cbe-1c791db33543

We need to get Algo_regs to be set to something that is not 0.

Fix: issue #2267
@vjardin
Copy link
Contributor Author

vjardin commented Apr 26, 2021

Can be closed thanks to #2270

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants