Re: [opensc-devel] PIN not sent to card before signing
On Wednesday 24. October 2012 10:45:12 you wrote: On 10/24/2012 9:44 AM, Mathias Tausig wrote: Hy! OK, I did install 0.13.0pre1 and patched with your patch, ran pkcs11-tool very verbose. Still no success, but at least a little improvement: Oct 24 16:35:40 off17 pcscd[4490]: 6361 APDU: 00 A4 08 0C 02 50 15 Oct 24 16:35:40 off17 pcscd[4490]: 00013633 SW: 6A 82 Oct 24 16:35:40 off17 pcscd[4490]: 0390 APDU: 00 A4 08 00 02 50 31 00 Oct 24 16:35:40 off17 pcscd[4490]: 00013839 SW: 6A 82 Oct 24 16:35:40 off17 pcscd[4490]: 0499 APDU: 00 A4 08 00 02 2F 02 00 Oct 24 16:35:41 off17 pcscd[4490]: 00013895 SW: 6A 82 Oct 24 16:35:41 off17 pcscd[4490]: 0453 APDU: 00 A4 08 0C 04 50 4B 00 01 Oct 24 16:35:41 off17 pcscd[4490]: 00014052 SW: 6A 82 Oct 24 16:35:41 off17 pcscd[4490]: 0495 APDU: 00 A4 08 0C 04 30 00 00 01 Oct 24 16:35:41 off17 pcscd[4490]: 00014010 SW: 6A 82 Oct 24 16:35:41 off17 pcscd[4490]: 0434 APDU: 00 A4 08 00 04 10 03 B2 00 00 Oct 24 16:35:41 off17 pcscd[4490]: 00014184 SW: 6A 82 Oct 24 16:35:41 off17 pcscd[4490]: 7703 APDU: 00 A4 08 0C 02 1F FF Oct 24 16:35:41 off17 pcscd[4490]: 00022255 SW: 90 00 Oct 24 16:35:41 off17 pcscd[4490]: 0243 APDU: 00 20 00 81 06 31 32 33 34 35 36 Oct 24 16:35:41 off17 pcscd[4490]: 00040760 SW: 90 00 Oct 24 16:35:41 off17 pcscd[4490]: 9640 APDU: 00 A4 08 0C 02 1F FF Oct 24 16:35:41 off17 pcscd[4490]: 00019360 SW: 90 00 Oct 24 16:35:41 off17 pcscd[4490]: 0359 APDU: 00 20 00 81 06 31 32 33 34 35 36 Oct 24 16:35:41 off17 pcscd[4490]: 00040640 SW: 90 00 Oct 24 16:35:41 off17 pcscd[4490]: 2532 APDU: 00 A4 08 0C 02 1F FF Oct 24 16:35:41 off17 pcscd[4490]: 00016460 SW: 90 00 Oct 24 16:35:41 off17 pcscd[4490]: 0383 APDU: 00 22 01 B6 03 83 01 02 Oct 24 16:35:41 off17 pcscd[4490]: 00010609 SW: 90 00 Oct 24 16:35:41 off17 pcscd[4490]: 0477 APDU: 00 2A 9E 9A 80 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 04 75 95 D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80 Oct 24 16:35:41 off17 pcscd[4490]: 00048524 SW: 67 00 Actually here is the problem. The above 67 00 is wrong length. The card-cardos.c tried this: 0xb721d900 16:35:41.223 [opensc-pkcs11] card-cardos.c:836:cardos_compute_signature: trying RSA_PURE_SIG (padded DigestInfo) but it failed, so it tries again: 0xb721d900 16:35:41.272 [opensc-pkcs11] card-cardos.c:842:cardos_compute_signature: trying RSA_SIG (just the DigestInfo) Oct 24 16:35:41 off17 pcscd[4490]: 0378 APDU: 00 2A 9E 9A 23 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 04 75 95 D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80 Oct 24 16:35:41 off17 pcscd[4490]: 00023629 SW: 69 82 The 69 82 is Command not allowed, Security Status not satisfied (i.e. user_consent) The question is why does it try the padded DigestInfo first? See the comments in card-cardos.c at line 821. If the right FLAGS are set, it should get it right the first time. You are right! Reselecting the signature DF keeps the security status active (I tried it). I looked at the source code of the corresponding part (card- cardos.c, line 821), and the commentary gives it away: /* XXX As we don't know what operations are allowed with a * certain key, let's try RSA_PURE etc. and see which operation * succeeds (this is not really beautiful, but currently the * only way I see) -- Nils * * We also check for several caps flags here to pervent generating * invalid signatures with duplicated hash prefixes with some cards */ This is wrong. You can read those informations from the supportedAlgorithms sequence in the TokenInfo file (I have to lines there with RSA_PKCS and SHA1_RSA_PKCS as mechanisms and both with RSA2_SIG for the algorithm (which is also the algorithm of the key)). There are 4 other pkcs15-*.c modules that use the card-cardos.c driver. It looks like your card is not one of them. This is were others on the list with CardOS cards could help. I don't understand that. Do you mean, that it selects the wrong card driver? I have manually created the PKCS#15 application to reference a seperate signature application. Oct 24 16:35:41 off17 pcscd[4490]: 0377 APDU: 00 2A 9E 9A 14 04 75 95 D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80 Oct 24 16:35:41 off17 pcscd[4490]: 00015614 SW: 69 82 It tried a third time, but the Security status is not satisfied. Now it doesn't change back to the PKCS#15 DF anymore, but it reselects the signature DF anyhow, with the same result. The decicsive lines in the debug log appear to be those: 0xb721d900 16:35:41.195 [opensc-pkcs11]
Re: [opensc-devel] PIN not sent to card before signing
On 10/25/2012 3:12 AM, Mathias Tausig wrote: On Wednesday 24. October 2012 10:45:12 you wrote: On 10/24/2012 9:44 AM, Mathias Tausig wrote: Hy! OK, I did install 0.13.0pre1 and patched with your patch, ran pkcs11-tool very verbose. Still no success, but at least a little improvement: Oct 24 16:35:40 off17 pcscd[4490]: 6361 APDU: 00 A4 08 0C 02 50 15 Oct 24 16:35:40 off17 pcscd[4490]: 00013633 SW: 6A 82 Oct 24 16:35:40 off17 pcscd[4490]: 0390 APDU: 00 A4 08 00 02 50 31 00 Oct 24 16:35:40 off17 pcscd[4490]: 00013839 SW: 6A 82 Oct 24 16:35:40 off17 pcscd[4490]: 0499 APDU: 00 A4 08 00 02 2F 02 00 Oct 24 16:35:41 off17 pcscd[4490]: 00013895 SW: 6A 82 Oct 24 16:35:41 off17 pcscd[4490]: 0453 APDU: 00 A4 08 0C 04 50 4B 00 01 Oct 24 16:35:41 off17 pcscd[4490]: 00014052 SW: 6A 82 Oct 24 16:35:41 off17 pcscd[4490]: 0495 APDU: 00 A4 08 0C 04 30 00 00 01 Oct 24 16:35:41 off17 pcscd[4490]: 00014010 SW: 6A 82 Oct 24 16:35:41 off17 pcscd[4490]: 0434 APDU: 00 A4 08 00 04 10 03 B2 00 00 Oct 24 16:35:41 off17 pcscd[4490]: 00014184 SW: 6A 82 Oct 24 16:35:41 off17 pcscd[4490]: 7703 APDU: 00 A4 08 0C 02 1F FF Oct 24 16:35:41 off17 pcscd[4490]: 00022255 SW: 90 00 Oct 24 16:35:41 off17 pcscd[4490]: 0243 APDU: 00 20 00 81 06 31 32 33 34 35 36 Oct 24 16:35:41 off17 pcscd[4490]: 00040760 SW: 90 00 Oct 24 16:35:41 off17 pcscd[4490]: 9640 APDU: 00 A4 08 0C 02 1F FF Oct 24 16:35:41 off17 pcscd[4490]: 00019360 SW: 90 00 Oct 24 16:35:41 off17 pcscd[4490]: 0359 APDU: 00 20 00 81 06 31 32 33 34 35 36 Oct 24 16:35:41 off17 pcscd[4490]: 00040640 SW: 90 00 Oct 24 16:35:41 off17 pcscd[4490]: 2532 APDU: 00 A4 08 0C 02 1F FF Oct 24 16:35:41 off17 pcscd[4490]: 00016460 SW: 90 00 Oct 24 16:35:41 off17 pcscd[4490]: 0383 APDU: 00 22 01 B6 03 83 01 02 Oct 24 16:35:41 off17 pcscd[4490]: 00010609 SW: 90 00 Oct 24 16:35:41 off17 pcscd[4490]: 0477 APDU: 00 2A 9E 9A 80 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 04 75 95 D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80 Oct 24 16:35:41 off17 pcscd[4490]: 00048524 SW: 67 00 Actually here is the problem. The above 67 00 is wrong length. The card-cardos.c tried this: 0xb721d900 16:35:41.223 [opensc-pkcs11] card-cardos.c:836:cardos_compute_signature: trying RSA_PURE_SIG (padded DigestInfo) but it failed, so it tries again: 0xb721d900 16:35:41.272 [opensc-pkcs11] card-cardos.c:842:cardos_compute_signature: trying RSA_SIG (just the DigestInfo) Oct 24 16:35:41 off17 pcscd[4490]: 0378 APDU: 00 2A 9E 9A 23 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 04 75 95 D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80 Oct 24 16:35:41 off17 pcscd[4490]: 00023629 SW: 69 82 The 69 82 is Command not allowed, Security Status not satisfied (i.e. user_consent) The question is why does it try the padded DigestInfo first? See the comments in card-cardos.c at line 821. If the right FLAGS are set, it should get it right the first time. You are right! Reselecting the signature DF keeps the security status active (I tried it). I looked at the source code of the corresponding part (card- cardos.c, line 821), and the commentary gives it away: /* XXX As we don't know what operations are allowed with a * certain key, let's try RSA_PURE etc. and see which operation * succeeds (this is not really beautiful, but currently the * only way I see) -- Nils * * We also check for several caps flags here to pervent generating * invalid signatures with duplicated hash prefixes with some cards */ This is wrong. You can read those informations from the supportedAlgorithms sequence in the TokenInfo file (I have to lines there with RSA_PKCS and SHA1_RSA_PKCS as mechanisms and both with RSA2_SIG for the algorithm (which is also the algorithm of the key)). There are 4 other pkcs15-*.c modules that use the card-cardos.c driver. It looks like your card is not one of them. This is were others on the list with CardOS cards could help. I don't understand that. Do you mean, that it selects the wrong card driver? I have manually created the PKCS#15 application to reference a seperate signature application. There are 4 pkcs15 emulation modules that appear to use the card-cardos.c driver, pkcs15-aactalis.c, pkcs15-infocamere.c, pkcs15-postecert.c, and pkcs15-tccardos. The PKCS15 emulation modules help fill in some of the details. The setting of the SC_CARD_CAP_ONLY_* flags used in card-cardos.c, are set in pkcs15.c in a fix_starcos-pkcs15-card(), and maybe a similar response to the type of problem you are seeing. (but not a generic fix, if the flags can be derived
Re: [opensc-devel] [Muscle] pcscd / firefox / ubuntu on android
On Thu, Oct 18, 2012 at 9:48 PM, Douglas E. Engert deeng...@anl.gov wrote: So until FF and TB get the fixes, OpenSC-0.13.0 adds a new option to the opensc.conf file to cache the pin to accommodate older applications. pin_cache_ignore_user_consent = true; Just a suggestion-question: OpenSC behavior in not caching the user consent PIN is logically correct, so why not disregard the user consent bit instead on the PKCS#15 object level? IMHO it feels a bit weird, that there is the PIN caching (to be turned on or off, on by default), then this mechanism that first disables PIN caching (user consent), then there is a mechanism that enables it again. This would of course unfortunately mean crippling the semantics of the module (reporting a normal key when in fact it has CKA_ALWAYS_AUTHENTICATE implemented in the hardware). The real problem is the difficulty in exposing the different PKCS#11 hacks and tweaks to different applications in an easily managed way, with concurrent applications... Just a thought. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
