Hi, I've got a GemSafeV1 card here which has 10 key containers. The native Gemalto Windows driver shows that there's a certificate in the third and fourth key container, all others are empty.
OpenSC only sees the certificate in the third key container. Using a USB Sniffer I can see that the native Windows driver sends two kinds of select_file commands to the card: 00 a4 08 00 04 16 00 00 04 => This is the normal select_file command that is also sent by OpenSC. It selects the file at address 3f0016000004. Note that P1 = 08 (select from MF by path) and P2 = 00 (return FCI). 00 a4 08 0c 04 16 00 00 04 => This command is only sent by the native Windows driver, not by OpenSC. Note that P1 = 08 as before, but P2 = 0c. According to ISO 7816 part 4 section 6 table 59, that value is reserved for future use: http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_6_basic_interindustry_commands.aspx#chap6_11 My guess is that the latter select_file command is used to access the fourth key container. I'm puzzled by P2 = 0c, is that a proprietary extension by Gemalto? How should OpenSC be extended to support these additional key containers? Right now apdu.p2 is hardwired to 0 in line 463 of src/libopensc/iso7816.c. Also, I found out that this card has a somewhat peculiar PIN policy: ASCII, min length 4, max length 8, padded with 0x00. The hardwired values in line 84 of src/libopensc/pkcs15-gemsafeV1.c are: BCD, min length 6, max length 8, padded with 0xFF. The GemSafe-based code in pkcs15-pteid.c uses yet another variation: ASCII, min length 4, max length 8, padded with 0xFF. What is the preferred way to support the PIN policy of this card in OpenSC? One way would be to define a new card type (e.g. SC_CARD_TYPE_GEMSAFEV1_EPO). A more elegant solution would be if we could query the card for its PIN policy. Since the Gemalto Windows driver should work with any GemSafe card, it probably does exactly that. I can see with the USB Sniffer that right before sending the PIN, the Gemalto driver sends the following APDU: 80 ca 9f 7f 2d and gets the following back: 9f 7f 2a 42 50 32 72 12 91 61 81 07 00 91 38 01 03 c4 75 28 32 00 00 91 62 20 03 91 62 20 04 7c 00 01 00 01 01 00 00 00 00 00 00 00 00 90 00 Maybe the PIN policy is encoded in there? The APDU sent to the card is a get_data command with P1 = 9f, P2 = 7f. Lacking any documentation for these cards, I can't tell what the values in the response APDU mean. The ATR of this card is 3B:7D:96:00:00:80:31:80:65:B0:83:11:48:C8:83:00:90:00 and the product name is Classic TPC IS v2 (new name: IDClassic 300). Firmware version is 1.11. Thanks & kind regards, Lukas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
