-
Notifications
You must be signed in to change notification settings - Fork 730
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
Comments
For the records, if we compare the In case of the Polish cards, the logs are:
while in case of a French card, the logs are:
Could the root cause of the issue with the French card be due to the lack of this |
For the records, the Peru's card from this issue is reporting some similar logs #1194 with the Polish's card. |
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:
(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 The real way to fix a bad pkcs15 card is to have add a db41cd9 is a recent an example where 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. |
Thanks for your analysis. I get your points and I'll try to follow the example of cardos that you highlighted. |
From your analysis, @dengert, the Tokeninfo seems to be correct, we get some algo_ref with the following command:
So, I'll try your comments, let's add a 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. |
I think the problem is in the keys not the tokenInfo on your card.
…On Sun, Mar 21, 2021, 6:05 AM Vincent JARDIN ***@***.***> wrote:
From your analysis, @dengert <https://github.com/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 commends, 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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2267 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGTIMKNS345X7FP67KMVLTTEXHHBANCNFSM4ZPWLFAA>
.
|
OK. I am quite "newbie" with opensc. I face two issues:
but
instead, the legacy |
I got the point, (I hope), Once set, we get the previous
I guess that I still need to set the proper logic in order for I need to guess the proper container to be used, I have the 11 following
while Gemalto was applying their fixup for:
Is the |
For the Gemalto's card, the ie IASECC card is patching the following for the PrKey:
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:
please, what should be the logic in order to "patch" the |
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
You set the title to: pkcs15_prkey_can_do CKR_FUNCTION_NOT_SUPPORTED
Set a breakpoint for this (check the line number in you source)
As you found from
it looks like algo_refs are not set. As you pointed out pkcs15-iaeecc.c has a It may need to look at your card, and you may need to make some changes here. pkcs15-prkey.c See if in
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"? |
It's also strange that your code jumps into sc_pkcs15_parse_df although your card offers a specific implementation for that... Calling 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. |
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
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 But https://github.com/vjardin/OpenSC/blob/fixAlgoRefs/src/libopensc/card-iasecc.c#L637-L645 sets multiple flags. the flags and calls to 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 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: |
with The following case fails:
But this case does not abort:
You can notice that they are two different IDs:
which is confusing but related to these logs:
|
The card can provide SHA1 and SHA256 hashes in HW with the following APDU:
see: OpenSC/src/libopensc/card-iasecc.c Line 3291 in 5f9085f
|
It can sign a hash that was previously computed off the card using the following APDU:
see: OpenSC/src/libopensc/card-iasecc.c Line 3303 in 5f9085f
|
It can authenticate using the following APDU:
See: OpenSC/src/libopensc/card-iasecc.c Line 3341 in 5f9085f
|
Can you post a full opensc-debug.log at level 9 for the case that aborted, and the case that did not abort? |
In response to: "You can notice that they are two different IDs". You card has two keys:
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. For example the 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. |
For a signature, with this command:
When
, the logs are:
When
, the logs are:
|
I would like to see the whole log. |
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 From the above, and source code, there is another whole area that needs to be looked at.
is enforcing a restriction to have the card or card driver do the SHA1 or SHA256. So unlike other cards, the use of just So only need the log when using the original flags. |
Enclosed the full logs.
|
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. So what is still outstanding? |
The verify is the following:
|
From https://github.com/OpenSC/OpenSC/files/6198174/opensc-debugIASECC_CARD_DEFAULT_FLAGS.log.gz the signature appears to be:
pubkey from certificate is:
or this from the other certificate:
But I don't know what was the data.in file. Using openssl dgst -verify key.pub -keyform PEM -sha256 -signature data.zip.sign -binary data.zip |
data.bin is just a string of 'x':
One more inside regarding the SHA256 APDU, with opensc, it is:
with the card's driver, it is:
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:
then opensc has a proper APDU:
I'll perform some investigations tonight. |
Thanks for the feed back. Your dump has: It looks like you need to add right after this:
|
see the WIP branch: https://github.com/vjardin/OpenSC/blob/c7a477e1e43d2310a9f3464759bab5af9c7debc8/src/libopensc/pkcs15-iasecc.c#L167 |
my issue is to find the proper N values of each algo_refs[x] = N for each x. |
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
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
Thanks to your tips @dengert , with the latest update, we get the signature working. Moreover, the keys are enumerated:
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 |
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 For the CPS_PRIV_AUT if the operation == decipher then add it. i.e. index 5 or reference 6 I would not add the In one of the debug logs, iasecc cards can support Secure Messaging. |
The logic is from pkcs15_prkey_can_do(), OpenSC/src/pkcs11/framework-pkcs15.c Lines 4551 to 4568 in 83162c5
I mean,
Newbie question: how do I get the
Do you mean something like:
???
Frankly, I do not know what
ok
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 |
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".
|
The only call to
So, I do not understand how to apply your tip ? |
Something like this to use the existing routine in |
Thanks @dengert , the outcome of your patch leads to:
that includes the following call:
So, the case
but the case
because we are missing the enumeration of its Algo_refs:
I do not get the point yet: why is iasecc_pkcs15_encode_supported_algos() missing this case ?! |
The problem could be in `pkcs15init/pkcs15-iasecc.c
based on Try changing line 800 to: Having just |
I'll double check. I think you are right but... |
Did you change line 800? lines 800 and 801 look very similar. Can you use gdb and set |
I keep saying the card vendor failed to add the So any fix we come up with might apply to other PKCS15 cards not just iasecc cards. https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-prkey.c#L323-L354 is also interesting. |
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
Thanks @dengert , I included your suggestions : it works fine and it is much better thanks to the usage of Regarding:
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". |
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
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
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
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
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
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
Can be closed thanks to #2270 |
When parsing
3f00/0001/5032
, we get the algRef = 66:because, from opensc-explorer's asn1 parser, it is:
but as a bottom line,
Algo_refs
is not set:It leads to some issues because
pkcs15_prkey_can_do()
fails and returnsCKR_FUNCTION_NOT_SUPPORTED
because ofso, the card's signature fails.
As a workaround, I can enforce a proper signature with this crappy patch:
how to get
pkcs15_prkey_can_do()
working properly ? I have a feeling that the values fromalgRef
should lead to some settings ofAlgo_refs
sopkcs15_prkey_can_do()
would work properly, but I cannot get the point.The text was updated successfully, but these errors were encountered: