Re: [opensc-devel] Status of the server migration
Hi, On Thu, Dec 27, 2012 at 04:26:38PM +0100, Ludovic Rousseau wrote: I do not like it at all but we may have lose all the bugs reported at opensc-project.org and start a new collection at github. There's some valuable stuff in Trac like a GemSafeV2 driver which never got merged (http://www.opensc-project.org/opensc/ticket/267). Losing that would really be unfortunate. Kind regards, Lukas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PIN login broken in 0.13.0rc1
Hi, I've issued pull request #111 which enhances pkcs15-gemsafeV1.c by two features: (1) Multiple key containers are now supported. Previously the code would only make the first certificate found on the card available to the user. By reverse-engineering the USB communication of the native Windows driver (Gemalto Classic Client) it turned out that all certificates are stored in the same file (3F001604). Up to 12 key containers are supported, this seems to be the maximum that Gemalto's cards are capable of. I have a card here which can store up to 10 key containers of which 2 are allocated. This card works perfectly now. The private key and certificate are no longer labeled DS key / DS certificate, but: DS key #1, DS key #2, ... / DS certificate #1, DS certificate #2, ... @Douglas E. Engert: The code introduced by you with commit 9468d989cf5f279e11f1551164624c2cd1b25948 is still there, i.e. the key_ref may be overridden by the opensc.conf card flag, but it will override the key_ref of *all* keys on the card if there's more than one. I'm not sure if this functionality is still necessary. (2) ATR-specific PIN policies are now supported. Previously the code would use the PIN policy: BCD, min length 6, max length 8, padded with 0xFF However the card I was given uses the following policy: ASCII, min length 4, max length 8, padded with 0x00 I tried to find out, again based on the USB communication of the native Windows driver, whether the card may be queried for its PIN policy. But to no avail. More specifically, I tried to find out if the tries_left can be queried from the card, thinking that the PIN policy is probably returned in the same APDU. So I deliberately logged in with the wrong PIN once (= tries_left=2) and compared the USB communication to the case when the correct PIN is entered right away. Turns out there's no difference. So apparently the tries_left can't be queried from the card and it seems likely that the PIN policy can't be queried either. If it can, I don't know where it is stored. I then realized that the Windows driver installs two files: policy.ppc and policyname.ini. Turns out the PIN policy is encoded in these files. The equivalent to these files would be if the user could specify a PIN policy in opensc.conf. Since that doesn't seem to be possible so far, I modified the code so that ATR-specific PIN policies may be specified. This is similar to pkcs15-infocamere.c which uses different card initialization functions based on the ATR of the card. I also fixed the indentation in gemsafe_detect_card(), sc_pkcs15emu_gemsafeV1_init() and sc_pkcs15emu_gemsafeV1_init_ex(). That makes reviewing the patch more difficult, sorry. People who are using gemsafeV1 cards in production may want to give this patch a try. Best, Lukas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PIN login broken in 0.13.0rc1
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 3f001604. 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
Re: [opensc-devel] PIN login broken in 0.13.0rc1
Hi, On Mon, Dec 03, 2012 at 11:20:14AM +0100, Viktor Tarasov wrote: In OpenSC the '0C' value for P2 is used when there is no need to return FCI data in 'SELECT' command: Aha. Thanks. I was wondering where the additional key containers are stored on the card and thought that maybe P2 = 0C would select the key container that's inaccessible with OpenSC. I was guessing in the wrong direction: It turns out that the key containers are all concatenated into the same file. There's a file at address 3f001604 (filename GemSAFE) which begins with 2 bytes for the length of the file (0x0a36 in this case) followed by a table which looks like this on my card: 01 f0 00 03 03 b0 00 03 01 f0 00 04 03 b0 00 04 01 fe 14 00 05 03 b0 00 05 = private key ref of third key container 01 fe 14 01 06 03 b0 00 06 = private key ref of fourth key container 01 f0 00 07 03 b0 00 07 01 f0 00 08 03 b0 00 08 01 f0 00 09 03 b0 00 09 01 f0 00 0a 03 b0 00 0a 01 f0 00 0b 03 b0 00 0b 01 f0 00 0c 03 b0 00 0c This table is followed by some garbage, then followed by the two certificates. What pkcs15-gemsafeV1.c:gemsafe_get_cert_len() currently does is look for the first private key in the table (recognizable by 0xfe), then look for the first certificate (starts with 0x3082 further down in the file) and be done with it. The other certificate which follows right behind in the same file is ignored. I'm using the master branch, i.e. 0.13.0rc1. I don't have any documentation by Gemalto, only the ISO 7816 standard on cardwerk.com (which seems to be outdated). Kind regards, Lukas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Need help building Mac OS X packages
On Thu, Nov 22, 2012 at 01:44:45PM +0200, Martin Paljak wrote: On Sun, Oct 14, 2012 at 3:27 PM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: I would suggest to drop the OpenSC tokend, unless someone volunteer to maintain it. I think my current mbp running 10.7 will be the last piece of Applet hardware/software combo I'll run, so the future is uncertain, but current situation is solid. OpenSC tokend is still useful. For the record, I managed to get it running with opensc 0.13.0rc1 on 10.4.11 using Xcode 2.5 with some fiddling: The Security and SecurityTokend frameworks that shipped with Xcode 2.5 are missing a few #define's. On the other hand, linking against the compiled frameworks included in Martin's build-10.5.tar.gz failed because of linker commands that the Xcode 2.5 linker (gcc 4.0.1) doesn't understand. The solution was to compile against the 10.5 version of the frameworks and link against the native 10.4 versions. The security_cdsa_client and security_cdsa_utilities frameworks are not included with Xcode 2.5. They're available on opensource.apple.com but I couldn't be bothered to download and compile them. I just compiled and linked against the versions included in Martin's build-10.5.tar.gz. The only problem is that these versions call UNIX2003 symbols in libc which don't exist on 10.4.11. This can be overcome by having the linker translate the symbols like this: '-Wl,-i_write$UNIX2003:_write' '-Wl,-i_read$UNIX2003:_read' '-Wl,-i_close$UNIX2003:_close' and so on. With OpenSC tokend compiled like this, a GemSafeV1 card correctly shows up in Keychain and when connecting to a website which requires client authentication, Safari will query for the PIN of the card. It's a shame that Apple stopped their in-house work on the tokend infrastructure. As for openssl, the build script automatically found and used the fink-installed openssl in /sw, so one (albeit not so user-friendly) solution for the removal of openssl in 10.8 may be to ask users that they pre-install openssl with brew, fink or whatever. Lukas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
