Repeated login issues with Yubikey NEO

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

Re: Repeated login issues with Yubikey NEO

David Woodhouse
On Fri, 2014-11-07 at 15:29 -0600, Douglas E Engert wrote:
>
> >
> > I think I've had about as much of Windows as I can stand for today.
>
> Well, take the weekend off. I am.

Good idea :)

Btw, on the misbehaviour of the Key Management slot — was it sufficient
to observe that adding SC_PKCS12_PRKEY_USAGE_SIGN makes it happy, or did
you still want to the debug logs that you asked for?

Other than that, I think we fairly much have a handle on all the issues
I've seen.

> I have a new NEO, I will look at it next week.

Have fun :)

I'm going to take a look at using the ykneo-oath applet to provide
TOTP/HOTP support (I already support libpskc/liboath).

--
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 3:42 PM, David Woodhouse wrote:

> On Fri, 2014-11-07 at 15:29 -0600, Douglas E Engert wrote:
>>
>>>
>>> I think I've had about as much of Windows as I can stand for today.
>>
>> Well, take the weekend off. I am.
>
> Good idea :)
>
> Btw, on the misbehaviour of the Key Management slot — was it sufficient
> to observe that adding SC_PKCS12_PRKEY_USAGE_SIGN makes it happy, or did
> you still want to the debug logs that you asked for?

Actually, the PIV has three user cert/keys designed for specific usages with specific
access patterns. The Key Management key is for encryption or derivation,
the auth key is for authentiction, and the signing key is to sign e-mail and documents.

The Key Management is not for signing.
See NIST 800-73-3 Part 1:
3.2.4 X.509 Certificate for Key Management

Note it must be escrowed too...

But pkcs15-piv.c already has this:

  978                 /*
  979                  * When no cert is present and a pubkey in a file was found,
  980                  * means the caller is initilaizeing a card. A sign operation
  981                  * will be required to sign a certificate request even if
  982                  * normal usage would not allow it. Set SC_PKCS15_PRKEY_USAGE_SIGN
  983                  * TODO if code is added to allow key generation and reqest
  984                  * sign in the same session, similiar code will be needed.
  985                  */
  986
  987                 if (ckis[i].pubkey_from_file == 1) {
  988                         prkey_info.usage = SC_PKCS15_PRKEY_USAGE_SIGN;
  989                         sc_debug(card->ctx, SC_LOG_DEBUG_NORMAL, "Adding SC_PKCS15_PRKEY_USAGE_SIGN");
  990                 }
  991

See:
https://github.com/OpenSC/OpenSC/wiki/PivTool

"Generate a "certificate request" and "Clear a certificate on the card"









>
> Other than that, I think we fairly much have a handle on all the issues
> I've seen.
>
>> I have a new NEO, I will look at it next week.
>
> Have fun :)
>
> I'm going to take a look at using the ykneo-oath applet to provide
> TOTP/HOTP support (I already support libpskc/liboath).
>

--

  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 16:55 -0600, Douglas E Engert wrote:

>
> 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,..).
Going back to this... my application (using the p11-kit callbacks) will
currently provide the *same* PIN for the CKU_CONTEXT_SPECIFIC login, as
the user already provided for the CKU_USER login. Which works here, but
is it the right thing to do?

If invoked *again* with the P11_KIT_PIN_FLAGS_RETRY flag set, the
application will forget the previous PIN and ask the user again.

--
dwmw2

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

smime.p7s (7K) Download Attachment
12