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
