Repeated login issues with Yubikey NEO

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

Repeated login issues with Yubikey NEO

David Woodhouse
I'm using a Yubikey NEO with OpenSC, from the OpenConnect VPN client.

It starts off by doing a test signature to validate that I've given it a
matching certificate and key, which works fine. PKCS#11 Spy output at
http://forum.yubico.com/viewtopic.php?f=26&t=1586

Then it connects to the HTTPS server and is required to do client
certificate authentication, so it tries another signature. Which fails
thus:


22: C_SignInit
2014-11-06 16:32:39.499
[in] hSession = 0x28a1560
pMechanism->type=CKM_RSA_PKCS                
[in] hKey = 0x2a3b950
Returned:  0 CKR_OK

23: C_Sign
2014-11-06 16:32:39.499
[in] hSession = 0x28a1560
[in] pData[ulDataLen] 00007fff6dbbf6b0 / 36
    00000000  42 B1 2E A0 4B A2 D6 C0 AD C0 CA 28 AD 0F 5D 34  B...K......(..]4
    00000010  09 AD 6C 8C 2C A1 31 1E 13 FF 91 65 59 A3 9D D9  ..l.,.1....eY...
    00000020  24 89 88 9D                                      $...            
[out] pSignature[*pulSignatureLen] NULL [size : 0x100 (256)]
Returned:  0 CKR_OK

24: C_Sign
2014-11-06 16:32:39.499
[in] hSession = 0x28a1560
[in] pData[ulDataLen] 00007fff6dbbf6b0 / 36
    00000000  42 B1 2E A0 4B A2 D6 C0 AD C0 CA 28 AD 0F 5D 34  B...K......(..]4
    00000010  09 AD 6C 8C 2C A1 31 1E 13 FF 91 65 59 A3 9D D9  ..l.,.1....eY...
    00000020  24 89 88 9D                                      $...            
Returned:  257 CKR_USER_NOT_LOGGED_IN

I believe that's a violation of the PKCS#11 spec because
CKR_USER_NOT_LOGGED_IN isn't a valid return value from C_Sign(). You're
supposed to return that from C_SignInit() if it's the case.

We modified GnuTLS to attempt to re-login when a key had the
CKA_ALWAYS_AUTHENTICATE attribute set:
https://gitorious.org/gnutls/gnutls/commit/e1a0af191

The GnuTLS pkcs11_login() function, however, does this first:

25: C_GetSessionInfo
2014-11-06 19:56:41.534
[in] hSession = 0xed7620
[out] pInfo:
      slotID:                  1
      state:                  '           CKS_RO_USER_FUNCTIONS'
      flags:                   4
        CKF_SERIAL_SESSION              
      ulDeviceError:           0
Returned:  0 CKR_OK

It sees the CKS_RO_USER_FUNCTIONS and decides that it didn't need to log
in again after all. And then the C_Sign still fails.

So I hacked it not to do that, and to call C_Login unconditionally. Now
I get this...

28: C_Login
2014-11-06 20:02:11.599
[in] hSession = 0x2c089a0
[in] userType = CKU_USER
[in] pPin[ulPinLen] 000000000293d9c0 / 6
    00000000  31 32 33 34 35 36                                123456
       
Returned:  256 CKR_USER_ALREADY_LOGGED_IN
p11: Login result = 256

29: C_SignInit
2014-11-06 20:02:11.599
[in] hSession = 0x2c089a0
pMechanism->type=CKM_RSA_PKCS                
[in] hKey = 0x269da90
Returned:  0 CKR_OK

30: C_Sign
2014-11-06 20:02:11.599
[in] hSession = 0x2c089a0
[in] pData[ulDataLen] 00007fff4449d3d0 / 36
    00000000  E9 44 15 2E 2F 04 6F 66 78 9B F1 9F 35 20 1D
EB  .D../.ofx...5 ..
    00000010  A7 8B A1 B9 70 99 36 1B 9E 75 73 2D 4D 8F 7A
A6  ....p.6..us-M.z.
    00000020  7D DE 54 B7                                      }.T.
       
[out] pSignature[*pulSignatureLen] NULL [size : 0x100 (256)]
Returned:  0 CKR_OK

31: C_Sign
2014-11-06 20:02:11.599
[in] hSession = 0x2c089a0
[in] pData[ulDataLen] 00007fff4449d3d0 / 36
    00000000  E9 44 15 2E 2F 04 6F 66 78 9B F1 9F 35 20 1D
EB  .D../.ofx...5 ..
    00000010  A7 8B A1 B9 70 99 36 1B 9E 75 73 2D 4D 8F 7A
A6  ....p.6..us-M.z.
    00000020  7D DE 54 B7                                      }.T.
       
Returned:  257 CKR_USER_NOT_LOGGED_IN


Full log including OPENSC_DEBUG=9 output at
http://david.woodhou.se/opensc-debug.txt — that final failing C_Sign()
call looks like this (not the same run, so don't be surprised that the
data we're signing are different):

0x7f6d5bc2a840 20:44:36.827 [opensc-pkcs11] reader-pcsc.c:249:pcsc_transmit: reader 'Yubico Yubikey NEO OTP+CCID 00 00'
0x7f6d5bc2a840 20:44:36.827 [opensc-pkcs11] apdu.c:185:sc_apdu_log:
Outgoing APDU data [  260 bytes] =====================================
10 87 07 9C FF 7C 82 01 06 82 00 81 82 01 00 00 .....|..........
01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF 00 84 0A 81 DA 22 ..............."
F5 48 AA 5F 12 18 9C 93 DF 99 D2 B5 A4 BA 7F 20 .H._...........
81 09 FF 51                                     ...Q
======================================================================
0x7f6d5bc2a840 20:44:36.827 [opensc-pkcs11] reader-pcsc.c:182:pcsc_internal_transmit: called
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:185:sc_apdu_log:
Incoming APDU data [    2 bytes] =====================================
90 00 ..
======================================================================
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:395:sc_single_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:548:sc_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:526:sc_transmit: called
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:380:sc_single_transmit: called
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:385:sc_single_transmit: CLA:0, INS:87, P1:7, P2:9C, data(11) 0x7fffe321f54f
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] reader-pcsc.c:249:pcsc_transmit: reader 'Yubico Yubikey NEO OTP+CCID 00 00'
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:185:sc_apdu_log:
Outgoing APDU data [   17 bytes] =====================================
00 87 07 9C 0B 9F C1 10 C1 2F 5D 66 C2 E1 54 28 ........./]f..T(
00                                              .
======================================================================
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] reader-pcsc.c:182:pcsc_internal_transmit: called
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] apdu.c:185:sc_apdu_log:
Incoming APDU data [    2 bytes] =====================================
69 82 i.
======================================================================
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] apdu.c:395:sc_single_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] apdu.c:548:sc_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] card.c:361:sc_unlock: called
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] card-piv.c:493:piv_general_io: DEE r=0 apdu.resplen=0 sw1=69 sw2=82
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] iso7816.c:102:iso7816_check_sw: Security status not satisfied
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] card-piv.c:503:piv_general_io: Card returned error


Is this simply a card error, and/or is it something that OpenSC should
be able to deal with?



--
dwmw2

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

Nikos Mavrogiannopoulos
On Thu, 2014-11-06 at 20:52 +0000, David Woodhouse wrote:

> I'm using a Yubikey NEO with OpenSC, from the OpenConnect VPN client.
>
> It starts off by doing a test signature to validate that I've given it a
> matching certificate and key, which works fine. PKCS#11 Spy output at
> http://forum.yubico.com/viewtopic.php?f=26&t=1586
>
> Then it connects to the HTTPS server and is required to do client
> certificate authentication, so it tries another signature. Which fails
> thus:
> 30: C_Sign
> 2014-11-06 20:02:11.599
> [in] hSession = 0x2c089a0
> [in] pData[ulDataLen] 00007fff4449d3d0 / 36
> [...]  
> [out] pSignature[*pulSignatureLen] NULL [size : 0x100 (256)]
> Returned:  0 CKR_OK
>
> 31: C_Sign
> 2014-11-06 20:02:11.599
> [...]        
> Returned:  257 CKR_USER_NOT_LOGGED_IN

To clarify why the two calls to C_Sign are there. The first call gets
the signature length (so sets data to NULL), and the second signs the
data. The bug seems to be on some authentication check which sets the
smart card to require login after the first call to C_Sign. My guess
would be that this check is on the firmware of the card, but someone who
knows opensc better may be able to help more.

regards,
Nikos



------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

David Woodhouse
On Thu, 2014-11-06 at 23:27 +0100, Nikos Mavrogiannopoulos wrote:
>
> To clarify why the two calls to C_Sign are there. The first call gets
> the signature length (so sets data to NULL), and the second signs the
> data. The bug seems to be on some authentication check which sets the
> smart card to require login after the first call to C_Sign. My guess
> would be that this check is on the firmware of the card, but someone
> who knows opensc better may be able to help more.

Looking at the PCSC_DEBUG output, I don't think it even talks to the
hardware at all during the (later) C_GetSessionInfo, C_Login, C_SignInit
and first C_Sign calls. It's only when it actually wants to the do the
signature that it talks to the card... and gets an unhelpful response.


--
dwmw2

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

Douglas E Engert
In reply to this post by David Woodhouse


On 11/6/2014 2:52 PM, David Woodhouse wrote:

> I'm using a Yubikey NEO with OpenSC, from the OpenConnect VPN client.
>
> It starts off by doing a test signature to validate that I've given it a
> matching certificate and key, which works fine. PKCS#11 Spy output at
> http://forum.yubico.com/viewtopic.php?f=26&t=1586
>
> Then it connects to the HTTPS server and is required to do client
> certificate authentication, so it tries another signature. Which fails
> thus:
>
>
> 22: C_SignInit
> 2014-11-06 16:32:39.499
> [in] hSession = 0x28a1560
> pMechanism->type=CKM_RSA_PKCS
> [in] hKey = 0x2a3b950
> Returned:  0 CKR_OK
>
> 23: C_Sign
> 2014-11-06 16:32:39.499
> [in] hSession = 0x28a1560
> [in] pData[ulDataLen] 00007fff6dbbf6b0 / 36
>      00000000  42 B1 2E A0 4B A2 D6 C0 AD C0 CA 28 AD 0F 5D 34  B...K......(..]4
>      00000010  09 AD 6C 8C 2C A1 31 1E 13 FF 91 65 59 A3 9D D9  ..l.,.1....eY...
>      00000020  24 89 88 9D                                      $...
> [out] pSignature[*pulSignatureLen] NULL [size : 0x100 (256)]
> Returned:  0 CKR_OK
>
> 24: C_Sign
> 2014-11-06 16:32:39.499
> [in] hSession = 0x28a1560
> [in] pData[ulDataLen] 00007fff6dbbf6b0 / 36
>      00000000  42 B1 2E A0 4B A2 D6 C0 AD C0 CA 28 AD 0F 5D 34  B...K......(..]4
>      00000010  09 AD 6C 8C 2C A1 31 1E 13 FF 91 65 59 A3 9D D9  ..l.,.1....eY...
>      00000020  24 89 88 9D                                      $...
> Returned:  257 CKR_USER_NOT_LOGGED_IN

THe code is using the PIV driver as defined in NIST 800-73-3. It has 4 cert/key on the card:
The auth cert is used for authentication to web sites and logins,
The encrypt cert/key is for encryption,
the card auth cert is so the card can authenticate itself, and does not require the PIN.

The sign cert/key  is used to sign e-mail and such,
for this cert/key. (So it is not clear if you are using the correct cert/key for the intended use,
as defined in NIST 800-73-3.

The card enforces the the CKA_ALWAYS_AUTHENTICATE on the sign cert/key by
no allowing any intervening operations to the card between the presentation
of the PIN,and the crypto operation.


>
> I believe that's a violation of the PKCS#11 spec because
> CKR_USER_NOT_LOGGED_IN isn't a valid return value from C_Sign(). You're
> supposed to return that from C_SignInit() if it's the case.

Well, That is the closest return we can give you that the card did not allow the sign
operation.

>
> We modified GnuTLS to attempt to re-login when a key had the
> CKA_ALWAYS_AUTHENTICATE attribute set:
> https://gitorious.org/gnutls/gnutls/commit/e1a0af191
>
> The GnuTLS pkcs11_login() function, however, does this first:
>
> 25: C_GetSessionInfo
> 2014-11-06 19:56:41.534
> [in] hSession = 0xed7620
> [out] pInfo:
>        slotID:                  1
>        state:                  '           CKS_RO_USER_FUNCTIONS'
>        flags:                   4
>          CKF_SERIAL_SESSION
>        ulDeviceError:           0
> Returned:  0 CKR_OK
>
> It sees the CKS_RO_USER_FUNCTIONS and decides that it didn't need to log
> in again after all. And then the C_Sign still fails.
>
> So I hacked it not to do that, and to call C_Login unconditionally. Now
> I get this...
>
> 28: C_Login
> 2014-11-06 20:02:11.599
> [in] hSession = 0x2c089a0
> [in] userType = CKU_USER
> [in] pPin[ulPinLen] 000000000293d9c0 / 6
>      00000000  31 32 33 34 35 36                                123456
>
> Returned:  256 CKR_USER_ALREADY_LOGGED_IN

Yes it failed, so the C_SignInit and C_Sign go on to try to use the signing cert
with the CKA_ALWAYS_AUTHENTICATE without sending the pin again.


Incoming APDU data [    2 bytes] =====================================
69 82 i.
======================================================================
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] apdu.c:395:sc_single_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] apdu.c:548:sc_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] card.c:361:sc_unlock: called
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] card-piv.c:493:piv_general_io: DEE r=0 apdu.resplen=0 sw1=69 sw2=82
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] iso7816.c:102:iso7816_check_sw: Security status not satisfied
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] card-piv.c:503:piv_general_io: Card returned error
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] card.c:361:sc_unlock: called
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] card-piv.c:553:piv_general_io: returning with: -1211 (Security status not satisfied)

So the problem it to get that second C_Login to work.

userType = CKU_USER
should be
userType = CKU_CONTEXT_SPECIFIC

PKCS#11 2.20 section 10.9

Re-authentication occurs by calling C_Login with userType set to
CKU_CONTEXT_SPECIFIC immediately after a cryptographic operation using the
key has been initiated (e.g. after C_SignInit). In this call, the actual user type is
implicitly given by the usage requirements of the active key. If C_Login returns
CKR_OK the user was successfully authenticated and this sets the active key in an
authenticated state that lasts until the cryptographic operation has successfully or
unsuccessfully been completed (e.g. by C_Sign, C_SignFinal,..).

> p11: Login result = 256
>
> 29: C_SignInit
> 2014-11-06 20:02:11.599
> [in] hSession = 0x2c089a0
> pMechanism->type=CKM_RSA_PKCS
> [in] hKey = 0x269da90
> Returned:  0 CKR_OK
>
> 30: C_Sign
> 2014-11-06 20:02:11.599
> [in] hSession = 0x2c089a0
> [in] pData[ulDataLen] 00007fff4449d3d0 / 36
>      00000000  E9 44 15 2E 2F 04 6F 66 78 9B F1 9F 35 20 1D
> EB  .D../.ofx...5 ..
>      00000010  A7 8B A1 B9 70 99 36 1B 9E 75 73 2D 4D 8F 7A
> A6  ....p.6..us-M.z.
>      00000020  7D DE 54 B7                                      }.T.
>
> [out] pSignature[*pulSignatureLen] NULL [size : 0x100 (256)]
> Returned:  0 CKR_OK
>
> 31: C_Sign
> 2014-11-06 20:02:11.599
> [in] hSession = 0x2c089a0
> [in] pData[ulDataLen] 00007fff4449d3d0 / 36
>      00000000  E9 44 15 2E 2F 04 6F 66 78 9B F1 9F 35 20 1D
> EB  .D../.ofx...5 ..
>      00000010  A7 8B A1 B9 70 99 36 1B 9E 75 73 2D 4D 8F 7A
> A6  ....p.6..us-M.z.
>      00000020  7D DE 54 B7                                      }.T.
>
> Returned:  257 CKR_USER_NOT_LOGGED_IN
>
>
> Full log including OPENSC_DEBUG=9 output at
> http://david.woodhou.se/opensc-debug.txt — that final failing C_Sign()
> call looks like this (not the same run, so don't be surprised that the
> data we're signing are different):
>
> 0x7f6d5bc2a840 20:44:36.827 [opensc-pkcs11] reader-pcsc.c:249:pcsc_transmit: reader 'Yubico Yubikey NEO OTP+CCID 00 00'
> 0x7f6d5bc2a840 20:44:36.827 [opensc-pkcs11] apdu.c:185:sc_apdu_log:
> Outgoing APDU data [  260 bytes] =====================================
> 10 87 07 9C FF 7C 82 01 06 82 00 81 82 01 00 00 .....|..........
> 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
> FF FF FF FF FF FF FF FF FF FF 00 84 0A 81 DA 22 ..............."
> F5 48 AA 5F 12 18 9C 93 DF 99 D2 B5 A4 BA 7F 20 .H._...........
> 81 09 FF 51                                     ...Q
> ======================================================================
> 0x7f6d5bc2a840 20:44:36.827 [opensc-pkcs11] reader-pcsc.c:182:pcsc_internal_transmit: called
> 0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:185:sc_apdu_log:
> Incoming APDU data [    2 bytes] =====================================
> 90 00 ..
> ======================================================================
> 0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:395:sc_single_transmit: returning with: 0 (Success)
> 0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:548:sc_transmit: returning with: 0 (Success)
> 0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:526:sc_transmit: called
> 0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:380:sc_single_transmit: called
> 0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:385:sc_single_transmit: CLA:0, INS:87, P1:7, P2:9C, data(11) 0x7fffe321f54f
> 0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] reader-pcsc.c:249:pcsc_transmit: reader 'Yubico Yubikey NEO OTP+CCID 00 00'
> 0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:185:sc_apdu_log:
> Outgoing APDU data [   17 bytes] =====================================
> 00 87 07 9C 0B 9F C1 10 C1 2F 5D 66 C2 E1 54 28 ........./]f..T(
> 00                                              .
> ======================================================================
> 0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] reader-pcsc.c:182:pcsc_internal_transmit: called
> 0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] apdu.c:185:sc_apdu_log:
> Incoming APDU data [    2 bytes] =====================================
> 69 82 i.
> ======================================================================
> 0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] apdu.c:395:sc_single_transmit: returning with: 0 (Success)
> 0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] apdu.c:548:sc_transmit: returning with: 0 (Success)
> 0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] card.c:361:sc_unlock: called
> 0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] card-piv.c:493:piv_general_io: DEE r=0 apdu.resplen=0 sw1=69 sw2=82
> 0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] iso7816.c:102:iso7816_check_sw: Security status not satisfied
> 0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] card-piv.c:503:piv_general_io: Card returned error
>
>
> Is this simply a card error, and/or is it something that OpenSC should
> be able to deal with?
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

David Woodhouse
On Thu, 2014-11-06 at 16:55 -0600, Douglas E Engert wrote:
> THe code is using the PIV driver as defined in NIST 800-73-3. It has 4 cert/key on the card:
> The auth cert is used for authentication to web sites and logins,
> The encrypt cert/key is for encryption,
> the card auth cert is so the card can authenticate itself, and does not require the PIN.
>
> The sign cert/key  is used to sign e-mail and such,
> for this cert/key. (So it is not clear if you are using the correct cert/key for the intended use,
> as defined in NIST 800-73-3.

Perhaps so. But this one actually shows up in 'p11tool --list-privkeys',
and if I import keys into any other slots, they don't:

[dwoodhou@i7 tool]$ ./yubico-piv-tool  -a import-key -s 9e  -p $PASSPHRASE -i ~/.cert/certificate.p12 -K PKCS12  
Successfully imported a new private key.
[dwoodhou@i7 tool]$ p11tool --provider /usr/lib64/pkcs11/opensc-pkcs11.so  --list-privkeys --login
open /home/dwmw2/pcsc-spy failed: No such file or directory
Token 'PIV_II (PIV Card Holder pin)' with URL 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=00000000;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29' requires user PIN
Enter PIN:
Object 0:
        URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=00000000;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%02;object=SIGN%20key;object-type=private
        Type: Private key
        Label: SIGN key
        Flags: CKA_PRIVATE; CKA_SENSITIVE;
        ID: 02


I still only have the 'SIGN key'. Am I doing something (else) wrong?


> So the problem it to get that second C_Login to work.
>
> userType = CKU_USER
> should be
> userType = CKU_CONTEXT_SPECIFIC

That does seem to do the trick; thanks. This hack against GnuTLS now
lets me authenticate successfully to the server:

diff --git a/lib/pkcs11.c b/lib/pkcs11.c
index 630928a..a259a7e 100644
--- a/lib/pkcs11.c
+++ b/lib/pkcs11.c
@@ -2227,8 +2227,9 @@ pkcs11_login(struct pkcs11_session_info *sinfo,
  if (rv == CKR_OK
     && (session_info.state == CKS_RO_USER_FUNCTIONS
  || session_info.state == CKS_RW_USER_FUNCTIONS)) {
- ret = 0;
- goto cleanup;
+ user_type = CKU_CONTEXT_SPECIFIC;
+// ret = 0;
+// goto cleanup;
  }
 
  /* If login has been attempted once already, check the token



--
dwmw2

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

David Woodhouse
On Fri, 2014-11-07 at 00:08 +0000, David Woodhouse wrote:

> On Thu, 2014-11-06 at 16:55 -0600, Douglas E Engert wrote:
> > THe code is using the PIV driver as defined in NIST 800-73-3. It has 4 cert/key on the card:
> > The auth cert is used for authentication to web sites and logins,
> > The encrypt cert/key is for encryption,
> > the card auth cert is so the card can authenticate itself, and does not require the PIN.
> >
> > The sign cert/key  is used to sign e-mail and such,
> > for this cert/key. (So it is not clear if you are using the correct cert/key for the intended use,
> > as defined in NIST 800-73-3.
>
> Perhaps so. But this one actually shows up in 'p11tool --list-privkeys',
> and if I import keys into any other slots, they don't:
Aha. I cannot import my *certificate* usefully, as it's larger than the
2048 bytes which the device will store. But if I store some arbitrary
*other* certificate in the certificate slot corresponding to the key,
*then* the key becomes visible.

But actually, the certificate can't be *entirely* arbitrarily chosen
because otherwise I get:

17: C_SignInit
2014-11-07 00:25:35.305
[in] hSession = 0x1950820
pMechanism->type=CKM_RSA_PKCS                
[in] hKey = 0x184f3a0
Returned:  99 CKR_KEY_TYPE_INCONSISTENT
Error signing test data with private key: PKCS #11 error in key

I had evidently done this for the 'SIGN key' slot and had even got lucky
by importing a certificate that sufficiently matches my key. Otherwise
I'd have got stuck on that CKR_KEY_TYPE_INCONSISTENT error much
sooner :)

Should I just be generating a trivial self-signed cert with the key in
question?

--
dwmw2

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

Douglas E Engert
In reply to this post by David Woodhouse


On 11/6/2014 6:08 PM, David Woodhouse wrote:

> On Thu, 2014-11-06 at 16:55 -0600, Douglas E Engert wrote:
>> THe code is using the PIV driver as defined in NIST 800-73-3. It has 4 cert/key on the card:
>> The auth cert is used for authentication to web sites and logins,
>> The encrypt cert/key is for encryption,
>> the card auth cert is so the card can authenticate itself, and does not require the PIN.
>>
>> The sign cert/key  is used to sign e-mail and such,
>> for this cert/key. (So it is not clear if you are using the correct cert/key for the intended use,
>> as defined in NIST 800-73-3.
>
> Perhaps so. But this one actually shows up in 'p11tool --list-privkeys',
> and if I import keys into any other slots, they don't:
>
> [dwoodhou@i7 tool]$ ./yubico-piv-tool  -a import-key -s 9e  -p $PASSPHRASE -i ~/.cert/certificate.p12 -K PKCS12

You would have to ask Yubico, why you can not import the other keys, as this is their tool.

What version of the NEO do you have?
On 10/30/14 their rep said:
  "The one we currently ship is version 0.1.2 fixes since 0.1.0 is related to import with ecc and rsa1024."



The NIST 800-73-3 defines the user interface, and some minimal commands to generate a key on the card,
and put-data to write objests to teh card. But for card management, NIST left that up to the vendors.
OpenSC implements the user interface to the PIV card, and the card management commands listed in 800-73.3.

(With 800-73-3 their can be more keys on the card, older encryption keys...)












> Successfully imported a new private key.
> [dwoodhou@i7 tool]$ p11tool --provider /usr/lib64/pkcs11/opensc-pkcs11.so  --list-privkeys --login
> open /home/dwmw2/pcsc-spy failed: No such file or directory
> Token 'PIV_II (PIV Card Holder pin)' with URL 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=00000000;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29' requires user PIN
> Enter PIN:
> Object 0:
> URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=00000000;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%02;object=SIGN%20key;object-type=private
> Type: Private key
> Label: SIGN key
> Flags: CKA_PRIVATE; CKA_SENSITIVE;
> ID: 02
>
>
> I still only have the 'SIGN key'. Am I doing something (else) wrong?
>
>
>> So the problem it to get that second C_Login to work.
>>
>> userType = CKU_USER
>> should be
>> userType = CKU_CONTEXT_SPECIFIC
>
> That does seem to do the trick; thanks. This hack against GnuTLS now
> lets me authenticate successfully to the server:
>
> diff --git a/lib/pkcs11.c b/lib/pkcs11.c
> index 630928a..a259a7e 100644
> --- a/lib/pkcs11.c
> +++ b/lib/pkcs11.c
> @@ -2227,8 +2227,9 @@ pkcs11_login(struct pkcs11_session_info *sinfo,
>   if (rv == CKR_OK
>      && (session_info.state == CKS_RO_USER_FUNCTIONS
>   || session_info.state == CKS_RW_USER_FUNCTIONS)) {
> - ret = 0;
> - goto cleanup;
> + user_type = CKU_CONTEXT_SPECIFIC;
> +// ret = 0;
> +// goto cleanup;
>   }
>
>   /* If login has been attempted once already, check the token
>
>
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

Douglas E Engert
In reply to this post by David Woodhouse


On 11/6/2014 6:45 PM, David Woodhouse wrote:

> On Fri, 2014-11-07 at 00:08 +0000, David Woodhouse wrote:
>> On Thu, 2014-11-06 at 16:55 -0600, Douglas E Engert wrote:
>>> THe code is using the PIV driver as defined in NIST 800-73-3. It has 4 cert/key on the card:
>>> The auth cert is used for authentication to web sites and logins,
>>> The encrypt cert/key is for encryption,
>>> the card auth cert is so the card can authenticate itself, and does not require the PIN.
>>>
>>> The sign cert/key  is used to sign e-mail and such,
>>> for this cert/key. (So it is not clear if you are using the correct cert/key for the intended use,
>>> as defined in NIST 800-73-3.
>>
>> Perhaps so. But this one actually shows up in 'p11tool --list-privkeys',
>> and if I import keys into any other slots, they don't:
>
> Aha. I cannot import my *certificate* usefully, as it's larger than the
> 2048 bytes which the device will store. But if I store some arbitrary
> *other* certificate in the certificate slot corresponding to the key,
> *then* the key becomes visible.

The PIV supports gziped certificates, that might get you some space.

 From a script to write a certificate:

if [ $ZIP -eq  1 ] ; then
        openssl x509 -in cards/$1.cert.$KEYID.pem \
                -outform DER -out cards/$1.cert.$KEYID.der
        gzip -c cards/$1.cert.$KEYID.der > cards/$1.cert.$KEYID.gz
        $OPENSC_BIN/piv-tool -A "$PIV_AUTH" -Z $KEYID -i cards/$1.cert.$KEYID.gz
else
        $OPENSC_BIN/piv-tool -A "$PIV_AUTH" -C $KEYID -i cards/$1.cert.$KEYID.pem

If you find gzip will make your cert much smaller then a der version of the cert
let me know, and I can give you more details.


>
> But actually, the certificate can't be *entirely* arbitrarily chosen
> because otherwise I get:

True,
The PIV stores private keys and certificates, but not public keys, but the only way to find out
the public key is to read the certificate to get the public key, and thus the modulus and size.
The only wayto find the modulus and size of the private key is from the public key.
This is what OpenSC does internally. And in the PKCS#11 interface will show the public key,
and the modulus, exponent and size of the private key.

>
> 17: C_SignInit
> 2014-11-07 00:25:35.305
> [in] hSession = 0x1950820
> pMechanism->type=CKM_RSA_PKCS
> [in] hKey = 0x184f3a0
> Returned:  99 CKR_KEY_TYPE_INCONSISTENT
> Error signing test data with private key: PKCS #11 error in key
>
> I had evidently done this for the 'SIGN key' slot and had even got lucky
> by importing a certificate that sufficiently matches my key. Otherwise
> I'd have got stuck on that CKR_KEY_TYPE_INCONSISTENT error much
> sooner :)
>
> Should I just be generating a trivial self-signed cert with the key in
> question?
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

Douglas E Engert
In reply to this post by David Woodhouse


On 11/6/2014 6:45 PM, David Woodhouse wrote:

> On Fri, 2014-11-07 at 00:08 +0000, David Woodhouse wrote:
>> On Thu, 2014-11-06 at 16:55 -0600, Douglas E Engert wrote:
>>> THe code is using the PIV driver as defined in NIST 800-73-3. It has 4 cert/key on the card:
>>> The auth cert is used for authentication to web sites and logins,
>>> The encrypt cert/key is for encryption,
>>> the card auth cert is so the card can authenticate itself, and does not require the PIN.
>>>
>>> The sign cert/key  is used to sign e-mail and such,
>>> for this cert/key. (So it is not clear if you are using the correct cert/key for the intended use,
>>> as defined in NIST 800-73-3.
>>
>> Perhaps so. But this one actually shows up in 'p11tool --list-privkeys',
>> and if I import keys into any other slots, they don't:
>
> Aha. I cannot import my *certificate* usefully, as it's larger than the
> 2048 bytes which the device will store. But if I store some arbitrary
> *other* certificate in the certificate slot corresponding to the key,
> *then* the key becomes visible.
>
> But actually, the certificate can't be *entirely* arbitrarily chosen
> because otherwise I get:
>
> 17: C_SignInit
> 2014-11-07 00:25:35.305
> [in] hSession = 0x1950820
> pMechanism->type=CKM_RSA_PKCS
> [in] hKey = 0x184f3a0
> Returned:  99 CKR_KEY_TYPE_INCONSISTENT
> Error signing test data with private key: PKCS #11 error in key
>
> I had evidently done this for the 'SIGN key' slot and had even got lucky
> by importing a certificate that sufficiently matches my key. Otherwise
> I'd have got stuck on that CKR_KEY_TYPE_INCONSISTENT error much
> sooner :)
>
> Should I just be generating a trivial self-signed cert with the key in
> question?

You could. Or see the comments about using gzip and writing the certificate
with the OpenSC pkcs11-tool

Thier docs:
https://developers.yubico.com/yubico-piv-tool/YubiKey-NEO-PIV-Introduction.html

says 2005 is max object size. A certificate object has about 20 bytes of extra overhead.


>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

David Woodhouse
In reply to this post by Douglas E Engert
On Thu, 2014-11-06 at 19:07 -0600, Douglas E Engert wrote:
> The PIV supports gziped certificates, that might get you some space.
> ...
> If you find gzip will make your cert much smaller then a der version of the cert
> let me know, and I can give you more details.

Yes, gzip reduces it from 2167 bytes to 1420, which would fit. Rather
than trying to work out how to get the OpenSC piv-tool to authenticate,
I just patched their yubico-piv-tool to handle compressed certs:
 http://david.woodhou.se/yubico-piv-compress.patch

I can now happily import my real certificate into all four available
slots. And now, three of the four slots are working properly (although
the Digital Signature slot needs that GnuTLS hack to handle the login).
All I need to do is add -c "pkcs11:manufacturer=piv_II;id=%04" to the
VPN client command line it Just Works. Thanks!

Only the the Key Management slot isn't working. Is that an expected
limitation? I get this:

35: C_SignInit
2014-11-07 10:20:24.856
[in] hSession = 0xece020
pMechanism->type=CKM_RSA_PKCS                
[in] hKey = 0x1419230
Returned:  99 CKR_KEY_TYPE_INCONSISTENT
Error signing test data with private key: PKCS #11 error in key

--
dwmw2

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

Douglas E Engert


On 11/7/2014 5:02 AM, David Woodhouse wrote:

> On Thu, 2014-11-06 at 19:07 -0600, Douglas E Engert wrote:
>> The PIV supports gziped certificates, that might get you some space.
>> ...
>> If you find gzip will make your cert much smaller then a der version of the cert
>> let me know, and I can give you more details.
>
> Yes, gzip reduces it from 2167 bytes to 1420, which would fit. Rather
> than trying to work out how to get the OpenSC piv-tool to authenticate,
> I just patched their yubico-piv-tool to handle compressed certs:
>   http://david.woodhou.se/yubico-piv-compress.patch
>
> I can now happily import my real certificate into all four available
> slots. And now, three of the four slots are working properly (although
> the Digital Signature slot needs that GnuTLS hack to handle the login).

That is expected. NIST 800-73-3 says the card will enforce that.
(pkcs#15 calls it user_consent, PKCS#11 its called CKA_ALWAYS_AUTHENTICATE)


> All I need to do is add -c "pkcs11:manufacturer=piv_II;id=%04" to the
> VPN client command line it Just Works. Thanks!
>
> Only the the Key Management slot isn't working. Is that an expected
> limitation?

No.

  I get this:
>
> 35: C_SignInit
> 2014-11-07 10:20:24.856
> [in] hSession = 0xece020
> pMechanism->type=CKM_RSA_PKCS
> [in] hKey = 0x1419230
> Returned:  99 CKR_KEY_TYPE_INCONSISTENT
> Error signing test data with private key: PKCS #11 error in key

It sounds like the cert and key don't match. It could be an import issue
or the way you built the p12 file, with mismatched cert and key.

Do you have a opensc-debug.log of the import?

did you do a login before trying to use it?

NIST 800-73-3 says the 9E key does not require login to be used.
It may be a bug in the Yubico card or OpenSC.

Do you have a opensc-debug.log of  trying it?




--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

Douglas E Engert
In reply to this post by David Woodhouse


On 11/7/2014 5:02 AM, David Woodhouse wrote:

> On Thu, 2014-11-06 at 19:07 -0600, Douglas E Engert wrote:
>> The PIV supports gziped certificates, that might get you some space.
>> ...
>> If you find gzip will make your cert much smaller then a der version of the cert
>> let me know, and I can give you more details.
>
> Yes, gzip reduces it from 2167 bytes to 1420, which would fit. Rather
> than trying to work out how to get the OpenSC piv-tool to authenticate,
> I just patched their yubico-piv-tool to handle compressed certs:
>   http://david.woodhou.se/yubico-piv-compress.patch


I see you have a pull request to Yubico as a patch?

NIST 800-73-3 part 1 after Table 38 refers to it as  "GZIP compression" as
opposed to IsX509 compression (IsX509 is define, but not used.)

Could you change your patch to use GZIP or GZIPPED as the parameter
to clarify what is going on and add a comment about gziped of DER encode certificate?


>
> I can now happily import my real certificate into all four available
> slots. And now, three of the four slots are working properly (although
> the Digital Signature slot needs that GnuTLS hack to handle the login).
> All I need to do is add -c "pkcs11:manufacturer=piv_II;id=%04" to the
> VPN client command line it Just Works. Thanks!
>
> Only the the Key Management slot isn't working. Is that an expected
> limitation? I get this:
>
> 35: C_SignInit
> 2014-11-07 10:20:24.856
> [in] hSession = 0xece020
> pMechanism->type=CKM_RSA_PKCS
> [in] hKey = 0x1419230
> Returned:  99 CKR_KEY_TYPE_INCONSISTENT
> Error signing test data with private key: PKCS #11 error in key
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

David Woodhouse
On Fri, 2014-11-07 at 07:40 -0600, Douglas E Engert wrote:
> I see you have a pull request to Yubico as a patch?
>
> NIST 800-73-3 part 1 after Table 38 refers to it as  "GZIP
> compression" as
> opposed to IsX509 compression (IsX509 is define, but not used.)
>
> Could you change your patch to use GZIP or GZIPPED as the parameter
> to clarify what is going on and add a comment about gziped of DER
> encode certificate?

Will do. And in fact I may just make it automatically gzip certificates
which are too large. This stuff is enough of a twisty maze already
without making the user jump through *extra* hoops :)

--
dwmw2

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

Douglas E Engert


On 11/7/2014 8:12 AM, David Woodhouse wrote:

> On Fri, 2014-11-07 at 07:40 -0600, Douglas E Engert wrote:
>> I see you have a pull request to Yubico as a patch?
>>
>> NIST 800-73-3 part 1 after Table 38 refers to it as  "GZIP
>> compression" as
>> opposed to IsX509 compression (IsX509 is define, but not used.)
>>
>> Could you change your patch to use GZIP or GZIPPED as the parameter
>> to clarify what is going on and add a comment about gziped of DER
>> encode certificate?
>
> Will do. And in fact I may just make it automatically gzip certificates
> which are too large. This stuff is enough of a twisty maze already
> without making the user jump through *extra* hoops :)

Try a gziped cert with Windows 7 or 8 first, using Microsoft's built in PIV driver first.
IE->Tools->Internet options->Content->Certificates->Personal  should show the certificates
It should work, but try it just in case. Note you will need a CHUID on the NEO. The
yubico-piv-tool can creat the CHUID.

>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

David Woodhouse
In reply to this post by Douglas E Engert
On Fri, 2014-11-07 at 07:19 -0600, Douglas E Engert wrote:
> > Only the the Key Management slot isn't working. Is that an expected
> > limitation?
>
> No.

Inspired by https://www.opensc-project.org/opensc/ticket/325 I found
that this 'fixes' it:

diff --git a/src/libopensc/pkcs15-piv.c b/src/libopensc/pkcs15-piv.c
index 7f46598..57f8efa 100644
--- a/src/libopensc/pkcs15-piv.c
+++ b/src/libopensc/pkcs15-piv.c
@@ -511,7 +511,7 @@ static int sc_pkcs15emu_piv_init(sc_pkcs15_card_t *p15card)
  SC_PKCS15_PRKEY_USAGE_NONREPUDIATION,
  "", 0x9C, "1", SC_PKCS15_CO_FLAG_PRIVATE, 1},
  { "3", "KEY MAN key",
- /*RSA*/SC_PKCS15_PRKEY_USAGE_DECRYPT | SC_PKCS15_PRKEY_USAGE_UNWRAP,
+ /*RSA*/SC_PKCS15_PRKEY_USAGE_DECRYPT | SC_PKCS15_PRKEY_USAGE_UNWRAP | SC_PKCS15_PRKEY_USAGE_SIGN,
  /*EC*/SC_PKCS15_PRKEY_USAGE_DERIVE,
  "", 0x9D, "1", SC_PKCS15_CO_FLAG_PRIVATE, 0},
  { "4", "CARD AUTH key",


--
dwmw2

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

David Woodhouse
In reply to this post by Douglas E Engert
On Fri, 2014-11-07 at 08:21 -0600, Douglas E Engert wrote:
>
> > Will do. And in fact I may just make it automatically gzip certificates
> > which are too large. This stuff is enough of a twisty maze already
> > without making the user jump through *extra* hoops :)
>
> Try a gziped cert with Windows 7 or 8 first, using Microsoft's built in PIV driver first.
> IE->Tools->Internet options->Content->Certificates->Personal  should show the certificates
> It should work, but try it just in case. Note you will need a CHUID on the NEO. The
> yubico-piv-tool can creat the CHUID.

Access to a Windows box for that would be non-trivial. Given that the
choices here are to compress or to fail outright, it's not clear that
'compress' could ever be the wrong choice, could it?

But I have to run for now, so I won't be doing that today anyway.

Are you happier with this version of the patch?

https://github.com/dwmw2/yubico-piv-tool/commit/dca2cb029ec4b983b193c617ee4095ad041cc8a6


--
dwmw2

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

Douglas E Engert


On 11/7/2014 8:43 AM, David Woodhouse wrote:

> On Fri, 2014-11-07 at 08:21 -0600, Douglas E Engert wrote:
>>
>>> Will do. And in fact I may just make it automatically gzip certificates
>>> which are too large. This stuff is enough of a twisty maze already
>>> without making the user jump through *extra* hoops :)
>>
>> Try a gziped cert with Windows 7 or 8 first, using Microsoft's built in PIV driver first.
>> IE->Tools->Internet options->Content->Certificates->Personal  should show the certificates
>> It should work, but try it just in case. Note you will need a CHUID on the NEO. The
>> yubico-piv-tool can creat the CHUID.
>
> Access to a Windows box for that would be non-trivial. Given that the
> choices here are to compress or to fail outright, it's not clear that
> 'compress' could ever be the wrong choice, could it?
>
> But I have to run for now, so I won't be doing that today anyway.
>
> Are you happier with this version of the patch?
>
> https://github.com/dwmw2/yubico-piv-tool/commit/dca2cb029ec4b983b193c617ee4095ad041cc8a6

Actually no.

card-piv.c has when reading:

1037                 tag = sc_asn1_find_tag(card->ctx, body, bodylen, 0x71, &taglen);
1038                 /* 800-72-1 not clear if this is 80 or 01 Sent comment to NIST for 800-72-2 */
1039                 if (tag && (((*tag) & 0x80) || ((*tag) & 0x01))) {
1040                         compressed = 1;
1041                 }

And when writing it has:

1244         *p++ = (flags)? 0x80:0x00; /* certinfo, i.e. gziped? */

But NIST 800-73-3 Part 1 clarified it:

  After table 38:
   "For a certificate encoded using GZIP compression CertInfo shall be '0x01'.

Looking at the TLV for the compress flag in a certificate object from a NIST demo card, shows 71 01 01

SO the OpenSC code will read either, but it is writing it wrong.
it should do this.

1244         *p++ = (flags)? 0x01:0x00; /* certinfo, i.e. gziped? */

You patch is also writing it wrong it has:


    *certptr++ = compress << 7; /* certinfo (gzip etc) */
it should have:
     *certptr++ = compress; /* certinfo (gzip etc) */
or
     *certptr++ = compress? 0x01:0x00; /* certinfo (gzip etc) */


Writing it wrong could cause cert to not work using Microsoft's PIV driver,
if it does not test for both.

I will fix OpenSC.




>
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

David Woodhouse
On Fri, 2014-11-07 at 10:54 -0600, Douglas E Engert wrote:
>
> And when writing it has:
>
> 1244         *p++ = (flags)? 0x80:0x00; /* certinfo, i.e. gziped? */

> You patch is also writing it wrong it has:
>
>
>     *certptr++ = compress << 7; /* certinfo (gzip etc) */

Right. I was looking at what OpenSC did. Will fix. Thanks for reviewing
it.

--
dwmw2

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

David Woodhouse
In reply to this post by Douglas E Engert
On Fri, 2014-11-07 at 08:21 -0600, Douglas E Engert wrote:

>
> On 11/7/2014 8:12 AM, David Woodhouse wrote:
> > On Fri, 2014-11-07 at 07:40 -0600, Douglas E Engert wrote:
> >> I see you have a pull request to Yubico as a patch?
> >>
> >> NIST 800-73-3 part 1 after Table 38 refers to it as  "GZIP
> >> compression" as
> >> opposed to IsX509 compression (IsX509 is define, but not used.)
> >>
> >> Could you change your patch to use GZIP or GZIPPED as the parameter
> >> to clarify what is going on and add a comment about gziped of DER
> >> encode certificate?
> >
> > Will do. And in fact I may just make it automatically gzip certificates
> > which are too large. This stuff is enough of a twisty maze already
> > without making the user jump through *extra* hoops :)
>
> Try a gziped cert with Windows 7 or 8 first, using Microsoft's built in PIV driver first.
> IE->Tools->Internet options->Content->Certificates->Personal  should show the certificates
> It should work, but try it just in case. Note you will need a CHUID on the NEO. The
> yubico-piv-tool can creat the CHUID.
Nice. Every time I assign the USB device to the Windows VM, Windows goes
off and looks for a driver update in Windows Update for a period of many
minutes before installing the driver (again) and claiming that the
device is working.

But even if I put uncompressed certs in, they never appear in the UI you
guided me to or in certmgr.msc. I did create a CHUID.

I think I've had about as much of Windows as I can stand for today.

--
dwmw2

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Repeated login issues with Yubikey NEO

Douglas E Engert


On 11/7/2014 2:33 PM, David Woodhouse wrote:

> On Fri, 2014-11-07 at 08:21 -0600, Douglas E Engert wrote:
>>
>> On 11/7/2014 8:12 AM, David Woodhouse wrote:
>>> On Fri, 2014-11-07 at 07:40 -0600, Douglas E Engert wrote:
>>>> I see you have a pull request to Yubico as a patch?
>>>>
>>>> NIST 800-73-3 part 1 after Table 38 refers to it as  "GZIP
>>>> compression" as
>>>> opposed to IsX509 compression (IsX509 is define, but not used.)
>>>>
>>>> Could you change your patch to use GZIP or GZIPPED as the parameter
>>>> to clarify what is going on and add a comment about gziped of DER
>>>> encode certificate?
>>>
>>> Will do. And in fact I may just make it automatically gzip certificates
>>> which are too large. This stuff is enough of a twisty maze already
>>> without making the user jump through *extra* hoops :)
>>
>> Try a gziped cert with Windows 7 or 8 first, using Microsoft's built in PIV driver first.
>> IE->Tools->Internet options->Content->Certificates->Personal  should show the certificates
>> It should work, but try it just in case. Note you will need a CHUID on the NEO. The
>> yubico-piv-tool can creat the CHUID.
>
> Nice. Every time I assign the USB device to the Windows VM, Windows goes
> off and looks for a driver update in Windows Update for a period of many
> minutes before installing the driver (again) and claiming that the
> device is working.
>
> But even if I put uncompressed certs in, they never appear in the UI you
> guided me to or in certmgr.msc. I did create a CHUID.

They can't be self signed...


https://developers.yubico.com/yubico-piv-tool/Windows-Certificate.html
claims it will work with Windows.

Before I retired, I did have a Yubico NEO at work and I believe I tested it on Windows.
The cert was signed by our Microsoft enterprise CA.

>
> I think I've had about as much of Windows as I can stand for today.

Well, take the weekend off. I am.
I have a new NEO, I will look at it next week.


>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
12