On 12/10/2012 10:46 AM, Lukas Wunner wrote: > 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 (3F0016000004). 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.
We no longer use these cards. The code in 9468d9 may no longer be needed if you are able to associate the certs and keys. > > > (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 > > -- 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
