PIN login broken in 0.13.0rc1

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

PIN login broken in 0.13.0rc1

Lukas Wunner
Hi,

when logging in to a GemSafeV1 card with 0.13.0rc1, opensc first retrieves
the number of tries_left using C_GetTokenInfo() and then calls C_Login().
Both functions invoke sc_pin_cmd() to communicate with the card.

It seems that somehow in-between the two invocations of sc_pin_cmd(),
the sc_pkcs15_auth_info structure holding the PIN information is destroyed:


$ OPENSC_DEBUG=9 pkcs11-tool --module opensc-pkcs11.so --test --login -p XXXXXXX
[...]
 pkcs11-session.c:57:C_OpenSession: C_OpenSession(0x1)
 pkcs11-session.c:83:C_OpenSession: C_OpenSession handle: 0x6100f0
 pkcs11-session.c:86:C_OpenSession: C_OpenSession() = CKR_OK
 framework-pkcs15.c:426:C_GetTokenInfo: C_GetTokenInfo(1)
 sec.c:157:sc_pin_cmd: called
 sec.c:204:sc_pin_cmd: returning with: -1408 (Not supported)        <------ data structure okay
 pkcs11-session.c:259:C_Login: C_Login(0x6100f0, 1)
 pkcs15-pin.c:293:sc_pkcs15_verify_pin: called
 pkcs15-pin.c:294:sc_pkcs15_verify_pin: PIN(0xXXXXXXXX;len:8)
 pkcs15-pin.c:295:sc_pkcs15_verify_pin: Auth(type:0;method:0)
 pkcs15-pin.c:299:sc_pkcs15_verify_pin: PIN value validated
 card.c:315:sc_lock: called
 reader-pcsc.c:517:pcsc_lock: called
 card.c:610:sc_select_file: called; type=2, path=3f0016000004
 card-gemsafeV1.c:184:gemsafe_select_file: called
[...]
 card.c:636:sc_select_file: returning with: 0 (Success)
 sec.c:157:sc_pin_cmd: called
 sec.c:204:sc_pin_cmd: returning with: -1300 (Invalid arguments)    <------ data structure destroyed
 pkcs15-pin.c:367:sc_pkcs15_verify_pin: PIN cmd result -1300
[...]
error: PKCS11 function C_Login failed: rv = CKR_ARGUMENTS_BAD (0x7)


The final error message is caused by "method:0". That value is assigned
to data.pin_type in pkcs15-pin.c:sc_pkcs15_verify_pin(). A value of 0
means SC_AC_NONE. The correct value would be 1 which means SC_AC_CHV.
There's a check in card-gemsafeV1.c:gemsafe_build_pin_apdu() for
pin_type == SC_AC_CHV which returns SC_ERROR_INVALID_ARGUMENTS on failure.
That's what causes the error message.

If I hardwire "data.pin_type = SC_AC_CHV" in sc_pkcs15_verify_pin(),
it still doesn't work: The card answers with CKR_PIN_INCORRECT even
though the PIN is correct. Somehow the data structure holding the
authentication info gets garbled.

The curious thing is that upon the first invocation of sc_pin_cmd()
(by C_GetTokenInfo()), the data structure seems to still be okay:
The check for pin_type == SC_AC_CHV in gemsafe_build_pin_apdu()
succeeds and the function just returns SC_ERROR_NOT_SUPPORTED
because SC_PIN_CMD_GET_INFO is not implemented for GemSafeV1 cards.

I'm at a loss here, if somebody has an idea what's going awry I'd be
grateful to hear it.


Thanks,

Lukas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN login broken in 0.13.0rc1

Viktor Tarasov-3
Hello,

On Tue, Nov 6, 2012 at 2:45 PM, Lukas Wunner <[hidden email]> wrote:
when logging in to a GemSafeV1 card with 0.13.0rc1, opensc first retrieves
the number of tries_left using C_GetTokenInfo() and then calls C_Login().
Both functions invoke sc_pin_cmd() to communicate with the card.

It seems that somehow in-between the two invocations of sc_pin_cmd(),
the sc_pkcs15_auth_info structure holding the PIN information is destroyed:


$ OPENSC_DEBUG=9 pkcs11-tool --module opensc-pkcs11.so --test --login -p XXXXXXX
[...]
 pkcs11-session.c:57:C_OpenSession: C_OpenSession(0x1)
 pkcs11-session.c:83:C_OpenSession: C_OpenSession handle: 0x6100f0
 pkcs11-session.c:86:C_OpenSession: C_OpenSession() = CKR_OK
 framework-pkcs15.c:426:C_GetTokenInfo: C_GetTokenInfo(1)
 sec.c:157:sc_pin_cmd: called
 sec.c:204:sc_pin_cmd: returning with: -1408 (Not supported)        <------ data structure okay
 pkcs11-session.c:259:C_Login: C_Login(0x6100f0, 1)
 pkcs15-pin.c:293:sc_pkcs15_verify_pin: called
 pkcs15-pin.c:294:sc_pkcs15_verify_pin: PIN(0xXXXXXXXX;len:8)
 pkcs15-pin.c:295:sc_pkcs15_verify_pin: Auth(type:0;method:0)
 pkcs15-pin.c:299:sc_pkcs15_verify_pin: PIN value validated
 card.c:315:sc_lock: called
 reader-pcsc.c:517:pcsc_lock: called
 card.c:610:sc_select_file: called; type=2, path=3f0016000004
 card-gemsafeV1.c:184:gemsafe_select_file: called
[...]
 card.c:636:sc_select_file: returning with: 0 (Success)
 sec.c:157:sc_pin_cmd: called
 sec.c:204:sc_pin_cmd: returning with: -1300 (Invalid arguments)    <------ data structure destroyed
 pkcs15-pin.c:367:sc_pkcs15_verify_pin: PIN cmd result -1300
[...]
error: PKCS11 function C_Login failed: rv = CKR_ARGUMENTS_BAD (0x7)


The final error message is caused by "method:0". That value is assigned
to data.pin_type in pkcs15-pin.c:sc_pkcs15_verify_pin(). A value of 0
means SC_AC_NONE. The correct value would be 1 which means SC_AC_CHV.
There's a check in card-gemsafeV1.c:gemsafe_build_pin_apdu() for
pin_type == SC_AC_CHV which returns SC_ERROR_INVALID_ARGUMENTS on failure.
That's what causes the error message.

If I hardwire "data.pin_type = SC_AC_CHV" in sc_pkcs15_verify_pin(),
it still doesn't work: The card answers with CKR_PIN_INCORRECT even
though the PIN is correct. Somehow the data structure holding the
authentication info gets garbled.

The curious thing is that upon the first invocation of sc_pin_cmd()
(by C_GetTokenInfo()), the data structure seems to still be okay:
The check for pin_type == SC_AC_CHV in gemsafe_build_pin_apdu()
succeeds and the function just returns SC_ERROR_NOT_SUPPORTED
because SC_PIN_CMD_GET_INFO is not implemented for GemSafeV1 cards.

I'm at a loss here, if somebody has an idea what's going awry I'd be
grateful to hear it.

 
Try to apply the following:

diff --git a/src/libopensc/pkcs15-gemsafeV1.c b/src/libopensc/pkcs15-gemsafeV1.c
index c05578e..3e04d40 100644
--- a/src/libopensc/pkcs15-gemsafeV1.c
+++ b/src/libopensc/pkcs15-gemsafeV1.c
@@ -436,6 +436,7 @@ sc_pkcs15emu_add_pin(sc_pkcs15_card_t *p15card,
 
        info = calloc(1, sizeof(*info));
        info->auth_type = SC_PKCS15_PIN_AUTH_TYPE_PIN;
+       info->auth_method = SC_AC_CHV;
        info->auth_id           = *id;
        info->attrs.pin.min_length        = min_length;
        info->attrs.pin.max_length        = max_length;

 

Thanks,
Lukas

Kind regards,
Viktor.
 
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN login broken in 0.13.0rc1

Viktor Tarasov-3
Le 06/11/2012 15:54, Viktor Tarasov a écrit :

> Hello,
>
> On Tue, Nov 6, 2012 at 2:45 PM, Lukas Wunner <[hidden email] <mailto:[hidden email]>> wrote:
>
>     when logging in to a GemSafeV1 card with 0.13.0rc1, opensc first retrieves
>     the number of tries_left using C_GetTokenInfo() and then calls C_Login().
>     Both functions invoke sc_pin_cmd() to communicate with the card.
>
>     It seems that somehow in-between the two invocations of sc_pin_cmd(),
>     the sc_pkcs15_auth_info structure holding the PIN information is destroyed:
>
>
>     $ OPENSC_DEBUG=9 pkcs11-tool --module opensc-pkcs11.so --test --login -p XXXXXXX
>     [...]
>      pkcs11-session.c:57:C_OpenSession: C_OpenSession(0x1)
>      pkcs11-session.c:83:C_OpenSession: C_OpenSession handle: 0x6100f0
>      pkcs11-session.c:86:C_OpenSession: C_OpenSession() = CKR_OK
>      framework-pkcs15.c:426:C_GetTokenInfo: C_GetTokenInfo(1)
>      sec.c:157:sc_pin_cmd: called
>      sec.c:204:sc_pin_cmd: returning with: -1408 (Not supported)        <------ data structure okay
>      pkcs11-session.c:259:C_Login: C_Login(0x6100f0, 1)
>      pkcs15-pin.c:293:sc_pkcs15_verify_pin: called
>      pkcs15-pin.c:294:sc_pkcs15_verify_pin: PIN(0xXXXXXXXX;len:8)
>      pkcs15-pin.c:295:sc_pkcs15_verify_pin: Auth(type:0;method:0)
>      pkcs15-pin.c:299:sc_pkcs15_verify_pin: PIN value validated
>      card.c:315:sc_lock: called
>      reader-pcsc.c:517:pcsc_lock: called
>      card.c:610:sc_select_file: called; type=2, path=3f0016000004
>      card-gemsafeV1.c:184:gemsafe_select_file: called
>     [...]
>      card.c:636:sc_select_file: returning with: 0 (Success)
>      sec.c:157:sc_pin_cmd: called
>      sec.c:204:sc_pin_cmd: returning with: -1300 (Invalid arguments)    <------ data structure destroyed
>      pkcs15-pin.c:367:sc_pkcs15_verify_pin: PIN cmd result -1300
>     [...]
>     error: PKCS11 function C_Login failed: rv = CKR_ARGUMENTS_BAD (0x7)
>
>
>     The final error message is caused by "method:0". That value is assigned
>     to data.pin_type in pkcs15-pin.c:sc_pkcs15_verify_pin(). A value of 0
>     means SC_AC_NONE. The correct value would be 1 which means SC_AC_CHV.
>     There's a check in card-gemsafeV1.c:gemsafe_build_pin_apdu() for
>     pin_type == SC_AC_CHV which returns SC_ERROR_INVALID_ARGUMENTS on failure.
>     That's what causes the error message.
>
>     If I hardwire "data.pin_type = SC_AC_CHV" in sc_pkcs15_verify_pin(),
>     it still doesn't work: The card answers with CKR_PIN_INCORRECT even
>     though the PIN is correct. Somehow the data structure holding the
>     authentication info gets garbled.
>
>     The curious thing is that upon the first invocation of sc_pin_cmd()
>     (by C_GetTokenInfo()), the data structure seems to still be okay:
>     The check for pin_type == SC_AC_CHV in gemsafe_build_pin_apdu()
>     succeeds and the function just returns SC_ERROR_NOT_SUPPORTED
>     because SC_PIN_CMD_GET_INFO is not implemented for GemSafeV1 cards.
>
>     I'm at a loss here, if somebody has an idea what's going awry I'd be
>     grateful to hear it.
>
>
>  
> Try to apply the following:
>
> diff --git a/src/libopensc/pkcs15-gemsafeV1.c b/src/libopensc/pkcs15-gemsafeV1.c
> index c05578e..3e04d40 100644
> --- a/src/libopensc/pkcs15-gemsafeV1.c
> +++ b/src/libopensc/pkcs15-gemsafeV1.c
> @@ -436,6 +436,7 @@ sc_pkcs15emu_add_pin(sc_pkcs15_card_t *p15card,
>  
>         info = calloc(1, sizeof(*info));
>         info->auth_type = SC_PKCS15_PIN_AUTH_TYPE_PIN;
> +       info->auth_method = SC_AC_CHV;
>         info->auth_id           = *id;
>         info->attrs.pin.min_length        = min_length;
>         info->attrs.pin.max_length        = max_length;

The patch has been applied to the Github OpenSC/OpenSC.

>  
>
>
>     Thanks,
>     Lukas
>
>
> Kind regards,
> Viktor.
>  
>
>     _______________________________________________
>     opensc-devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN login broken in 0.13.0rc1

Lukas Wunner
In reply to this post by Viktor Tarasov-3
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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN login broken in 0.13.0rc1

Viktor Tarasov-3
Hello,

On Mon, Dec 3, 2012 at 9:06 AM, Lukas Wunner <[hidden email]> 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:




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:


 
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.

 


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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN login broken in 0.13.0rc1

Lukas Wunner
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 3f0016000004 (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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN login broken in 0.13.0rc1

Lukas Wunner
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.


(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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN login broken in 0.13.0rc1

Douglas E. Engert


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
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN login broken in 0.13.0rc1

Viktor Tarasov-3
In reply to this post by Lukas Wunner
Hello,

Le 10/12/2012 17:46, Lukas Wunner a écrit :
> I've issued pull request #111 which enhances pkcs15-gemsafeV1.c
> by two features:

Build of the merged repository for pull request #111 fails on Windows (Vista).
You can reach the compilation logs of the failed jenkins job using the link in description of your pull request.

Kind regards,
Viktor.

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel