Hello, On Mon, Dec 3, 2012 at 9:06 AM, Lukas Wunner <lu...@wunner.de> wrote:
> 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 According to ISO/IEC 7816-4:2005(E) Table 40 -- P2: 0 0 0 0 1 1 x x — No response data if Le field absent, or proprietary if Le field present In OpenSC the '0C' value for P2 is used when there is no need to return FCI data in 'SELECT' command: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/iso7816.c#L472 > > 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. > What version of OpenSC are you referencing ? I propose you to use the master branch of the OpenSC/OpenSC github project. The P2 value in 'SELECT' card command have nothing to the number of detected key containers by gemsafeV1 card. As far as I see, gemsafeV1 card uses the PKCS#15 emulator. In this case the key containers (as well as certificates, public keys, ...) are hard-coded into the card's driver: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-gemsafeV1.c#L114 https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-gemsafeV1.c#L65 > 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). > In OpenSC there is no common management of the PIN policy: format and manner to get/put PIN policy are too different from one card type to another. Specific PIN policy is/may-be implemented by the specific card driver. > > 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. > These data are the 'Card Production Life Cycle (CPLC)' data, there is no PIN Policy data. https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/types.h#L290 > > > 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 > Kind regards, Viktor. > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel >
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
