[opensc-devel] Failed transactions with a card in some readers with INS in 9X/6X range
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, I observed something interesting when scanning the command space (CLA+INS) of a card with a few different readers (CardMan1021 and Gemalto EzioShieldPinPad among others) Certain INS codes fail with transaction failed on CardMan1021 whereas succeed on Gemalto reader with the same card. I also tried SPR532 (another TPDU reader) and got somewhat similar results (count, INS code in hex for failed transactions with the same card in different readers) $ grep -i fail ok1021_cmd_scan.txt | cut -d' ' -f 2 | sort | uniq -c 127 68 127 69 1 6A 1 6B 1 6C 1 6D 126 6E 126 6F 126 90 126 91 1 92 1 93 1 94 1 95 127 96 127 97 $ grep -i fail spr532_cmd_scan.txt | cut -d' ' -f 2 | sort | uniq -c 127 68 1 6A 1 6D 126 6E 126 91 1 92 1 95 127 97 The file itself contains lines like the following: F0 96 00 00 = 68 84 F0 97 00 00 = Failed to transmit with protocol T0. Transaction failed. F0 98 00 00 = 68 84 The actual pcsc-lite error code is 0x80100016 (SCARD_E_NOT_TRANSACTED). Also tried with CardMan3821 (APDU reader) and got failures as well (the count of failures of INS codes does not seem consistent) I suspect it has something to do with the following in ISO 7816-4 (5.1.2): INS indicates the command to process. Due to specifications in ISO/IEC 7816-3, the values '6X' and '9X' are invalid. Is there some explanation to this (I probably can't comprehend 7816-3 in meaningful time)? The trick here is that the same command works with other cards in the same reader and with the same card in some other readers (always with T=0) I'll publish the python scripts after some formatting, this might be generally useful if you have cards you don't know much about and can afford to brick and want to scan for interesting things. Trying the same on Windows will be the next step. But maybe there's a documented explanation to this. Best, Martin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJOVjJbAAoJEHSCZV4wfjRSXCcP/A0yhdCQtkiozY7YlH2V874Z mrTKFmKzTfzzvllktDwYFaFs9/4KQAaGUKmlGRiEhavy9T7sJWsoF7iM9Ip0HHpT t7IPCu+vb9/sIR6KQhXj0SWmucdEZNweOF6RbiwixpotFJBigpvaZzOU198qQ7x5 pH+Qh6geko/fEvldmHTgGsEIJl5ir7wuCu//8Ojczpdib4JsJ5CZ61WuOLg0Cj0p lPoltDuxyDXiru4PkoWJcfz/7g/UM/J4dbMsXteB3/ygNmL6hhXLctzrliGeP3nq bz6FkvJFHhaa4bNPHwuWPvSfrejhs9Q5lfHFNRjQdjglSaLbEIlqPq80cDW82fvL PmZRA4EwJr5T4JgGj8nJc0cJ4vZbsgwUgGkmk9ZnZflfk4eof4/s43AlMxlE1mbj QLDmwzzhv76aroe+Y9SmU7O2CjSqd6/n0QADiEOBo4chbxd2OiSI4+uCJzQMsQ1j xSiOxrKKZsCPF+a/F5KR0jKOdFka3FbZAc/4Yz9alfz0YpCDyeZMchwMOaMsfX5U BA290mpHQTbv24ueAPmU36tuiaZz5IsqoNLroET5+OAL4cX7eKyxG2wnXsYtXin8 yTif1NylEvl0mzl+RX242KbEqupzqimUFAOD8Txkx+zXCJZZHshAsxpIE6ZqU1xO /iEmqVBRriQw674Q/7sj =XWyE -END PGP SIGNATURE- ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [Muscle] Failed transactions with a card in some readers with INS in 9X/6X range
2011/8/25 Martin Paljak mar...@martinpaljak.net: Hello, Hello Martin, I observed something interesting when scanning the command space (CLA+INS) of a card with a few different readers (CardMan1021 and Gemalto EzioShieldPinPad among others) Certain INS codes fail with transaction failed on CardMan1021 whereas succeed on Gemalto reader with the same card. I also tried SPR532 (another TPDU reader) and got somewhat similar results (count, INS code in hex for failed transactions with the same card in different readers) $ grep -i fail ok1021_cmd_scan.txt | cut -d' ' -f 2 | sort | uniq -c 127 68 127 69 1 6A 1 6B 1 6C 1 6D 126 6E 126 6F 126 90 126 91 1 92 1 93 1 94 1 95 127 96 127 97 $ grep -i fail spr532_cmd_scan.txt | cut -d' ' -f 2 | sort | uniq -c 127 68 1 6A 1 6D 126 6E 126 91 1 92 1 95 127 97 The file itself contains lines like the following: F0 96 00 00 = 68 84 F0 97 00 00 = Failed to transmit with protocol T0. Transaction failed. F0 98 00 00 = 68 84 The actual pcsc-lite error code is 0x80100016 (SCARD_E_NOT_TRANSACTED). Also tried with CardMan3821 (APDU reader) and got failures as well (the count of failures of INS codes does not seem consistent) I suspect it has something to do with the following in ISO 7816-4 (5.1.2): INS indicates the command to process. Due to specifications in ISO/IEC 7816-3, the values '6X' and '9X' are invalid. Is there some explanation to this (I probably can't comprehend 7816-3 in meaningful time)? The trick here is that the same command works with other cards in the same reader and with the same card in some other readers (always with T=0) The T=0 protocol has some limitations. I am not a ISO 7816-3 expert so I may be wrong on some aspects. From my ISO 7816-3-2006 page 23 10.3.3 Procedure bytes In T=0, after the reader sends the first 5 bytes of the APDU the card must respond with a procedure byte. This procedure byte can be: - 60 : wait again - 6X or 9X : this is SW1 from the card - INS : the reader can then sends the remaining bytes - INS xor FF : the reader can sends the next data byte. From this description you can see that 6X and 9X can't be valid INS byte in the APDU. See also Procedure bytes sent by the card [1]. The realy strange situation is that you can have a working T=0 card+reader with these invalid INS bytes. In your INS exploration program just skip 6X and 9X INS values. Bye [1] http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-3.aspx -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [Muscle] Failed transactions with a card in some readers with INS in 9X/6X range
Hello, On Thu, Aug 25, 2011 at 14:47, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: The realy strange situation is that you can have a working T=0 card+reader with these invalid INS bytes. In your INS exploration program just skip 6X and 9X INS values. Thanks for the explanation! For the fun of it I think I'll do the opposite instead: - make the protocol dependant probing more explicit (for several stupid reasons I'm using T=0 only currently, as this is the only supported algorithm for Estonian eID cards) - DO probe the forbidden ranges (not by default though) - see what happens with different card+reader combos :) Would it make sense to debug on USB level what is happening at different situations, to maybe make the CCID driver more robust (== predictable outcome with different readers)? I currently understand that this is up to the reader firmware currently, which also explains the different outcome from different readers. I'll see if there are more readers in my collection that can use those INS codes.. Best, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Half OT: PKCS#11+Mozilla
Sorry for the little OT. I would like to know if OpenSC PKCS#11 module added on Firefox/Thunderbird has the same problem im having on my PKCS#11 library. Seems that Mozilla its invoking C_FindObjectsInit asking for objects with CK_OBJECT_CLASS = 0xCE534351 or 0xCE534352 or 0xCE534353 or 0xCE534354 around 171 times. This type is a mask for VENDOR_DEFINED ones, and seems to be related to NSS. As far as i know, returning CKR_OK and 0 objects, or even better CKR_ATTRIBUTE_TYPE_INVALID should tell Mozilla I DONT HAVE ANY OF THIS, and Mozilla should stop asking. Instead of this, it asks again...again...and again until boredom (maybe its because i have 171 CAs on my keystore? No clue. Mozilla/NSS people doesnt seem to know anything about this (or they look to other side). As im not an OpenSC user, and have no idea of how to trace/log this stuff, i ask for the guys that would have been fighting against this. Is this also happening to you? Do you implement that VENDOR_DEFINED (undocumented?) types? Could you give me a hand? Thanx a lot anyway. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Half OT: PKCS#11+Mozilla
On 8/25/2011 7:58 AM, helpcrypto helpcrypto wrote: Sorry for the little OT. I would like to know if OpenSC PKCS#11 module added on Firefox/Thunderbird has the same problem im having on my PKCS#11 library. Seems that Mozilla its invoking C_FindObjectsInit asking for objects with CK_OBJECT_CLASS = 0xCE534351 or 0xCE534352 or 0xCE534353 or 0xCE534354 around 171 times. This type is a mask for VENDOR_DEFINED ones, and seems to be related to NSS. The OpenSC pkcs11/pkcs11-display.c has definitions for all these. #define CKO_NETSCAPE 0xCE534350 #define CKO_NETSCAPE_CRL(CKO_NETSCAPE + 1) #define CKO_NETSCAPE_SMIME (CKO_NETSCAPE + 2) #define CKO_NETSCAPE_TRUST (CKO_NETSCAPE + 3) #define CKO_NETSCAPE_BUILTIN_ROOT_LIST (CKO_NETSCAPE + 4) There are vendor attributes too. As far as i know, returning CKR_OK and 0 objects, or even better CKR_ATTRIBUTE_TYPE_INVALID should tell Mozilla I DONT HAVE ANY OF THIS, and Mozilla should stop asking. Instead of this, it asks again...again...and again until boredom (maybe its because i have 171 CAs on my keystore? No clue. Looks like looking for a CRL. When OpenSC PKCS#11 sees these, it returns 0 objects and CKR_OK Add to the environment something like this: PKCS11SPY=/opt/smartcard/lib/your-pkcs11.so PKCS11SPY_OUTPUT=/tmp/tb.spy.txt Mozilla/NSS people doesnt seem to know anything about this (or they look to other side). As im not an OpenSC user, and have no idea of how to trace/log this stuff, i ask for the guys that would have been fighting against this. You can use the OpenSC pkcs11-spy.so with TB and your own PKCS#11 module. make the pkcs11-spy.so or pkcs11-spy.dll the security device. Is this also happening to you? Do you implement that VENDOR_DEFINED (undocumented?) types? Could you give me a hand? When OpenSC PKCS#11 sees these, it returns 0 objects and CKR_OK Thanx a lot anyway. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch: remove slots of detached reader(token)
Le 11/08/2011 13:29, Ludovic Rousseau a écrit : 2011/8/11 Viktor Tarasovviktor.tara...@gmail.com: Le 08/08/2011 16:31, Ludovic Rousseau a écrit : 2011/7/19 Viktor Tarasovviktor.tara...@gmail.com: Le 18/07/2011 14:52, Ludovic Rousseau a écrit : 2011/7/10 Viktor Tarasovviktor.tara...@gmail.com: Hi, Hello, there is patch proposal to treat properly the 'detach token(reader)' event and to remove the slots associated to the removed token. Tested in Linux and windows. 'SCardGetStatusChange' have different behavior in Linux and Windows. Needs to be studied and validated for Mac. https://github.com/viktorTarasov/OpenSC/commit/62bda63bd66c4849c0ca4303a9682fb6f6bacd7d /* When token is hot-unplugged: * - in Linux (pcsc-lite) * -- SCardGetStatusChange returns OK; * -- current reader state is 'UNKNOWN'; * -- 'Refresh-attributes' returns 'SC_ERROR_READER_DETACHED'. * * - in Windows (WinSCard): * -- SCardGetStatusChange failes with SCARD_E_NO_READERS_AVAILABLE; * -- 'Refresh-attributes' returns 'SC_ERROR_NO_READERS_FOUND'. * * - FIXME: Mac? */ I just checked on Mac OS X 10.6.8 (Snow Leopard) and I have nearly the same result as on GNU/Linux. On GNU/Linux : new state is 14 = ['Changed', 'Unknown', 'Unavailable'] On Mac OS X : new state is 6 = ['Changed', 'Unknown] On Windows, do you also get the error SCARD_E_NO_READERS_AVAILABLE when you use TWO readers in the SCardGetStatusChange() call? I do not completely follow. SCardGetStatusChange is called by refresh_attributes(sc_reader_t *reader). In this context there is only one reader. When this reader is unplugged in Windows the SCardGetStatusChange returns 8010002E -- SCARD_E_NO_READERS_AVAILABLE. In Linux SCardGetStatusChange returns OK and properly sets a new reader status. Imho both have a reason. I can't reproduce the problem on my Windows XP using my Python sample. If SCardGetStatusChange() is called with a removed/unknown reader then Windows SCardGetStatusChange() returns with SCARD_E_UNKNOWN_READER. I just changed pcsc-lite in revision 5881 to also return SCARD_E_UNKNOWN_READER when called with unknown reader(s). If I unplug a reader while SCardGetStatusChange() is running I get SCARD_S_SUCCESS and the new reader state is ['Ignore', 'Changed', 'Unavailable'] Viktor, are you using Windows XP? or a newer version? I use WindowsXP SP2 in VM and pkcs11-tool from OpenSC to make the tests . I will experiment with more debugs to get know the details of the calling context . I used my Python sample test http://anonscm.debian.org/viewvc/pcsclite/trunk/PCSC/UnitaryTests/SCardGetStatusChange.py?view=markup For you the 'normal' behavior of SCardGetStatusChange() is to return SCARD_S_SUCCESS and appropriate reader status, is it so? Yes. Unless the reader is unknown (has been removed) _before_ SCardGetStatusChange() is called. In the OpenSC context the detached reader/token is unknown before the SCardGetStatusChange() called. In windows, XP or Vista, the ScardGetStatusChange called for unknown reader returns SCARD_E_NO_READERS_AVAILABLE. The last revision of pcsc-lite, in such a case, returns the SCARD_E_UNKNOWN_READER, which seems to be more appropriate to the situation. From your log opensc-debug.win32.detach-unique-token.log I interpret it as: - OpenSC gets a card removed event 2011-07-22 11:34:45.763 'Aktiv Rutoken ECP 0' before=0x00010122 now=0x000B 2011-07-22 11:34:45.763 card removed event - OpenSC calls SCardGetStatusChange() and get SCARD_E_NO_READERS_AVAILABLE 2011-07-22 11:34:45.950 [opensc-pkcs11] reader-pcsc.c:361:pcsc_detect_card_presence: called 2011-07-22 11:34:45.950 Aktiv Rutoken ECP 0 check 2011-07-22 11:34:45.950 Aktiv Rutoken ECP 0:SCardGetStatusChange failed: 0x8010002e 2011-07-22 11:34:45.950 [opensc-pkcs11] reader-pcsc.c:365:pcsc_detect_card_presence: returning with: -1101 (No readers found) Since this is a token, a card removed event is also a reader removed event. So it is normal to get an error from SCardGetStatusChange(). pcsc-lite will return SCARD_E_UNKNOWN_READER instead of SCARD_E_NO_READERS_AVAILABLE returned by Windows XP. Windows XP also returns SCARD_E_UNKNOWN_READER (with my sample). So I guess my Python sample does not do exactly what OpenSC is doing. In you sample the SCardGetStatusChange is called _before_ the reader is detached (and 'detach' event is waited for on the timeout of ScardGetStatusChange). To reproduce the problem and approach the OpenSC context you probably need to introduce 'time.sleep()' into your script before SCardGetStatusChange and withdraw the token during it. Also the SCardGetStatusChange has to be called on one reader, as it's the case of 'refresh_attributes' in OpenSC. So, without changes of your script, during your tests, your need to withdraw the unique token. I will do more testing and try to find in which cases Windows returns
