C_Login failed: rv = CKR_USER_PIN_NOT_INITIALIZED (0x102) #1995
Comments
|
Could this be one of the ASN.1 changes in |
|
My reading of the ASN1/DER is that Integer should be encoded to minimum number of octets [1]:
which the value given in your log ( Your log do not show enough context to see where is the asn1 parser called, but assuming there might be other cards providing not strictly valid DER encodings, we can default to non-strict parsing. Can you check with the following patch? |
|
Yes, this patch works. I have seen your attempts to differentiate I tried to dump a PIN structure into the decoder: https://lapo.it/asn1js/#MCswDAwDUElOAwIGwAQBAjADBAEBoRYwFAMCA4gKAQICAQQCAQACARCAAgAB |
|
Right. The parsing should be probably less strict by default here. Let me go back to this or let @dengert to pick up this change to his branch as it is quite related bugfix. |
|
Thanks, unfortunately signing/verification problems with CardOS 5.3 do not improve with this small change :( It merely enables me to use the card at all. |
|
Thanks. Looks good. |
|
@Jakuje I wonder if we should use the non-strict parsing everywhere. Our main goal is to make the cards usable instead of playing police. I think during normal operation, we don't have a use for the "strict" mode. It could be useful in debug mode but that's it. What do you think? |
|
I am aboard (see the initial patch few comments above). |
|
Your patch above removes strict for every integer. If that is what you and Frank want, OK. |
|
I'd even go a step further without adding new flags: diff --git a/src/libopensc/asn1.c b/src/libopensc/asn1.c
index bf951782f..ad8419347 100644
--- a/src/libopensc/asn1.c
+++ b/src/libopensc/asn1.c
@@ -1506,7 +1506,7 @@ static int asn1_decode_entry(sc_context_t *ctx,struct sc_asn1_entry *entry,
case SC_ASN1_INTEGER:
case SC_ASN1_ENUMERATED:
if (parm != NULL) {
- r = sc_asn1_decode_integer(obj, objlen, (int *) entry->parm, 1);
+ r = sc_asn1_decode_integer(obj, objlen, (int *) entry->parm, 0);
sc_debug(ctx, SC_LOG_DEBUG_ASN1, "%*.*sdecoding '%s' returned %d\n", depth, depth, "",
entry->name, *((int *) entry->parm));
} |
|
As Frank said, our job is not playing police but making the cards work. Let's relax this. |
Yes, indeed. If a card really wants to have strict encoding, it's still available, but for the general part relaxed parsing is enough. |
|
Is |
|
If I read it right, It is valid BER, but not valid DER, which should be minimal: https://en.wikipedia.org/wiki/X.690#DER_encoding And from here the confusion as we have asn1 "library" without clean distinction if it should handle DER/BER or other ASN.1 subset. As already said, I am fine with applying the above patch. |
|
Any self-respecting DER library would parse/understand BER (at least most of it, maybe excluding truly atrocious encodings), and produce/encoder strict DER. "Be liberal in what you receive, and conservative on what you send" - this old IETF approach still makes sense. |
For a counter point, see https://tools.ietf.org/html/draft-iab-protocol-maintenance-03, titled "The Harmful Consequences of the Robustness Principle". |
|
I wonder if I can build "a feedback cycle" with the certificate provider that gave me this card. Sure I can try. With all the IAB wisdom, I wonder how'd they deal with the badly-specified HTML vs strict XHTML. "Feedback cycle" with all webpage authors? This is all fine if there are few protocol implementors. |
see: OpenSC#1995 (comment) On branch cardos-5.3 Changes to be committed: modified: asn1.c
see: OpenSC#1995 (comment) On branch cardos-5.3 Changes to be committed: modified: asn1.c
see: OpenSC#1995 (comment) On branch cardos-5.3 Changes to be committed: modified: asn1.c
see: OpenSC#1995 (comment) On branch cardos-5.3 Changes to be committed: modified: asn1.c
see: OpenSC#1995 (comment) On branch cardos-5.3 Changes to be committed: modified: asn1.c
see: #1995 (comment) On branch cardos-5.3 Changes to be committed: modified: asn1.c
|
This was fixed as part of #1987 with the commit we talked about. Closing. |
|
I am experiencing the same issue on the latest stable and nightly on macOS. Here is the output of the |
|
Can you check with #2217 ? It is still WIP so not merged yet, but it should work. |
|
@Jakuje it seems promising but I am not sure how to build and test it on Mac as there isn't a ready build to download. |
|
I've pushed #2217 onto our remote so that CI picks this up for our nightly builds. use https://github.com/OpenSC/Nightly/tree/2021-03-04_db1e178b |
|
I can confirm that the test login works: But trying to login in Chrome fails (the certificate is detected successfully and a pin input is shown but then the authentication fails): In Safari the certificate is detected but the pin input is not shown. I am testing after having ran the |
|
The pkcs11-tool errors: flags |= SC_ALGORITHM_RSA_HASH_SHA1 | The card may support it, but the returned signature is not formatted as expected. |
|
Now I'm completely confused. If I'm not mistaken, the problem of @konstantintuev is not related to this issue. I assume that the issue in question has been fixed with #1987. Further, I assume that @konstantintuev 's token is currently not supported by OpenSC, but gets (some) support with #2217. If this is the case, then please use #2217 or a new issue for your problem description. There may be more work required to get your card supported.... |
|
You are right, @saper and original comment is for "CardOS V5.3" |
|
Hello I have a brand new Italian CNS ('Tessera Sanitaria', TS-CNS), the provider is ACe 2021 (official driver here). After rebuilding OpenSC from git cloning, on Linux (Debian Bullseye amd64) I'm still getting this error. I've rebuilt CCID too. Logs: results in the full logs of using the official driver for this card ( returns the full log with |
can you open a new issue about that, this is unrelated... |
|
my bad, the error appeared to be the same. |
Problem Description
After upgrading from 0.20.0 (built from FreeBSD ports or from source) to master 7840804 (built with
--configure --prefix=/usr/localbothpkcs11-toolandpkcs15-toolcould not find PINs:With 0.20.0:
Steps to reproduce
Logs
After finding both PIN objects the decoding process fails trying ASN.1 decode:
With 0.20.0 it works:
The text was updated successfully, but these errors were encountered: