OpenSC PIV doesn't expose all available Yubikey 4 slots

[titanous]

Expected behaviour

When using the OpenSC PIV module, it should provide access to the 20 "retired" slots on the Yubikey 4. These slots don't appear to have any limitations and can be used in the same fashion as the other four slots on the device.

Actual behaviour

The 20 slots are not displayed when using the PIV module provided by OpenSC, but do appear when using the YKCS11 module from Yubico.

Logs

https://gist.github.com/titanous/57a8993894d457cadf8d2057f036d112

[dengert]

NIST 800-73-3 defines the Key History Object which has a
keysWithOnCardCerts and keysWithOffCardCerts These say how many of the keys
and certs are on the crd and how many have keys on the card with the
certificate off the card and a URL to get to the offline certificates.

The OpenSC PIV driver is following the NIST specs and tries to read the Key
History Object to find out how many of the retired keys and certs are on
the card.

(The OpenSC PIV driver will read from the user's home directory the offline
certs
if the file from the URL has been downloaded. It has to do this because the
only way to find the public key from the cert so it can get the key type
and key size needed to use the key.)

Note the key usage for these keys is for key management not signatures, The
PIV driver sets the key usage accordingly.

The proper way to deal with is is add a KeyHistoryObject to the card.
To see Key History Object in:

http:https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf

On Sat, Aug 6, 2016 at 3:17 PM, Jonathan Rudenberg <[email protected]

wrote:

Expected behaviour

When using the OpenSC PIV module, it should provide access to the 20
"retired" slots on the Yubikey 4. These slots don't appear to have any
limitations and can be used in the same fashion as the other four slots on
the device.
Actual behaviour

The 20 slots are not displayed when using the PIV module provided by
OpenSC, but do appear when using the YKCS11 module from Yubico.
Logs

https://gist.github.com/titanous/57a8993894d457cadf8d2057f036d112

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#847, or mute the thread
https://github.com/notifications/unsubscribe-auth/AA00MZQ-W7qNT2GOe9PmIYvxIkwVrsqfks5qdOvHgaJpZM4JeW0_
.

[titanous]

The Yubikey 4 allows using all 24 keypairs/certificates for any purpose, and does not expose a Key History Object. Since I don't work at Yubico and the devices are not flashable, there is no way to expose the "Key History Object". Thus in order for the additional 20 keys to be accessible to OpenSC's PIV driver it would need to be modified to support the way the Yubikey does things.

[dengert]

The Yubico-piv-tool can be used to write objects. One just has to create a
binary file with teh contents of the object. I am not able to give you all
the details, I am on vacation. But look at
#479
This has example of writing some other objects,

NIST 800-73 defines the usage, and the keys must be in order. So this is
another example of Yubico not following the PIV standard!

On Sat, Aug 6, 2016 at 4:56 PM, Jonathan Rudenberg <[email protected]

wrote:

The Yubikey 4 allows using all 24 keypairs/certificates for any purpose,
and does not expose a Key History Object. Since I don't work at Yubico and
the devices are not flashable, there is no way to expose the "Key History
Object". Thus in order for the additional 20 keys to be accessible to
OpenSC's PIV driver it would need to be modified to support the way the
Yubikey does things.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#847 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA00McLz2hM3hgnR6I6BJEG2tOpOlE2bks5qdQMRgaJpZM4JeW0_
.

[dengert]

The OpenSC PIV driver was written to match NIST 800-73 3, as are most card
in the field. 800-73-4 is the latest version, but ASAIK there are no cards
that support all the features of version 4.

800-73-3 has 4 parts:
http:https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-73-3.pdf

The Key History Object is well defined in 800-73-3.

On Sat, Aug 6, 2016 at 7:10 PM, Douglas E Engert [email protected] wrote:

The Yubico-piv-tool can be used to write objects. One just has to create a
binary file with teh contents of the object. I am not able to give you all
the details, I am on vacation. But look at
#479
This has example of writing some other objects,

NIST 800-73 defines the usage, and the keys must be in order. So this is
another example of Yubico not following the PIV standard!

On Sat, Aug 6, 2016 at 4:56 PM, Jonathan Rudenberg <
[email protected]> wrote:

The Yubikey 4 allows using all 24 keypairs/certificates for any purpose,
and does not expose a Key History Object. Since I don't work at Yubico and
the devices are not flashable, there is no way to expose the "Key History
Object". Thus in order for the additional 20 keys to be accessible to
OpenSC's PIV driver it would need to be modified to support the way the
Yubikey does things.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#847 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA00McLz2hM3hgnR6I6BJEG2tOpOlE2bks5qdQMRgaJpZM4JeW0_
.

[titanous]

Thanks for the pointer, I was able to write the object and now OpenSC sees the keys. However, it won't let me use the keys in the retired slots for for signatures, reporting:

error: PKCS11 function C_SignInit failed: rv = CKR_KEY_TYPE_INCONSISTENT (0x63)

Here's the whole object dump: https://gist.github.com/titanous/d76eb86c7e9dcf76aaf2858d74ff3faf

And in case anyone is wondering, here's the command to write the Key History object specifying 20 keys with on-card certificates:

echo -n C10114C20100FE00 | yubico-piv-tool -k -a write-object --id 0x5FC10C -i -

[dengert]

NIST 800-73-3 calls the certificates (and keys) "Retired X.509
Certificates for Key Management key N (Key reference MM)" for a reason.
They were defined to be for encryption only. A compliant PIV card may
enforce the usage. With RSA the RAW (x509) method is used for both
signature and decryption. But with EC keys , ECDSA and ECDH are different
operations, so a card could enforce it only allow ECDH.

For the NEO, Something could be added onto #816. This might be a flag in
the opensc.conf, to treat the NEO differently from a rreal PIV card.

I believe Yubico wrote an almost PIV applet was to allow the NEO to be used
by the Windows builtin PIV drivers (no additional software needed.) If you
expect your NEO to work on Windows and use the Retired keys for signatures
it may not work.

I can look at this after Aug 15.

.

On Sun, Aug 7, 2016 at 7:44 PM, Jonathan Rudenberg <[email protected]

wrote:

Thanks for the pointer, I was able to write the object and now OpenSC sees
the keys. However, it won't let me use the keys in the retired slots for
for signatures, reporting:

error: PKCS11 function C_SignInit failed: rv = CKR_KEY_TYPE_INCONSISTENT (0x63)

Here's the whole object dump: https://gist.github.com/titanous/
d76eb86c7e9dcf76aaf2858d74ff3faf

And in case anyone is wondering, here's the command to write the Key
History object specifying 20 keys with on-card certificates:

echo -n C10114C20100FE00 | yubico-piv-tool -k -a write-object --id 0x5FC10C -i -

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#847 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA00MenYY6qlv-EGAHHeTVuJB6d_b7-5ks5qdnvZgaJpZM4JeW0_
.

[titanous]

FWIW this is the Yubikey 4, which is newer than the NEO. I think the NEO only has the standard 4 slots, not the extra 20 key management slots.

And yeah, it is not intended to be a normal PIV card, all 24 keys should be allowed to do both ECDSA and ECDH or RSA signing and decryption.

I'm happy to test anything you come up with when you get back, and I'd also be willing to order a Yubikey 4 and send it to you if that would make things easier. Just send me an email (address in my GitHub profile) if you'd like me to do that.

I'm not worried about native Windows support right now, I just want to be able to use all of the keys via the OpenSC PKCS11 interface.

Thanks!

[mouse07410]

If you expect your NEO to work on Windows and use the Retired keys for signatures it may not work.

I was not aware that "Retired keys" could be used for anything but Key Management (because the only reasonable employment of retired keys IMHO is decrypting data that was encrypted before that key got retired). Frankly, any other use does not make sense to me. The reported error CKR_KEY_TYPE_INCONSISTENT seems to show that the designers were in agreement with me.

So while Yubico indeed wrote "almost PIV" applets for NEO and (later) Yubikey 4, I would not expect any PIV to be able to sign with retired keys.

[dengert]

The card-piv.c and pkcs15-piv.c code is enforcing the key usage policies as
defined in NIST 800-73 by setting the PKCS#11 attributes..Any issuer of a
compliant PIV card would set the certificate key usage to match the PIV
standards.

The user wants to use the keys and certs for other purposes not compliant
with PIV and FIPS-201.

I plan to allow the Yubico devices to do what the user wants, as these
devices are not following the policies anyway. The certificates also
enforce the key usage policies and card-piv.c is reading and parsing the
certificate to get the publikey (SPKI). I will look if it could use the
keyUsage from the certificate to set the PKCS#11 attributes.

On Mon, Aug 8, 2016 at 9:33 PM, Mouse [email protected] wrote:

If you expect your NEO to work on Windows and use the Retired keys for
signatures it may not work.

I was not aware that "Retired keys" could be used for anything but Key
Management (because the only reasonable employment of retired keys IMHO is
decrypting data that was encrypted before that key got retired). Frankly,
any other use does not make sense to me. The reported error
CKR_KEY_TYPE_INCONSISTENT shows that the designers appears to agree with
me.

So while Yubico indeed wrote "almost PIV" applets for NEO and (later)
Yubikey 4, I would not expect any PIV to be able to sign with retired keys.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#847 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA00MQJxNVvukoh2yevAX4QSU76cJLs1ks5qd-bggaJpZM4JeW0_
.

[mouse07410]

Well, maybe Yubico does enforce Key Usage on the Retired keys? Especially Yubikey 4, that they tried to make stricter and more conformant? Also, while Yubico does not follow all the policies, those devices seem to follow enough of the PIV policies to be very useful (to us at least) as an affordable convenient PIV-compatible token. I just completed integration of PIV login with Active Directory - using Yubikey NEO as the test-card. Worked wonders. I'll probably keep using it as my PIV token even after PIV smart card get provisioned and deployed.

Back to the retired keys. Maybe in this case we should not allow the user to do every stupid illegal thing he wants? Or at least guard this action by requiring the user to set an explicit flag, something like "Yes I want to F the standard"?

P.S. You probably know that while CAC signing keys are not replaceable, one can request a copy of his CAC encrypting key pair? So the usefulness/necessity of retired keys IMHO is fairly low.

[titanous]

Well, maybe Yubico does enforce Key Usage on the Retired keys? Especially Yubikey 4, that they tried to make stricter and more conformant?

They do not in their YKCS11 library or on the key itself.

My use cases are code signing, SSH, and GPG, none of which require strict compliance with the PIV standard. Having more key slots available is really useful, especially since the hardware supports it.

I believe that using the key usage attributes from the certificate in the slot is a reasonable tradeoff.

[dengert]

I don't have access to AD anymore. I assume you are using the built in
Windows PIV driver on Windows machines? If you are going to issue NEO
cards to people good luck with all the card management issues.

As for copies of any of the encryption keys,they are normally escrowed by
policy of the card issuer in case your card breaks or you are doing
something illegal. They could create a new card with the same key or law
enforcement or your employer could retrieve what you encrypted.

As for the keyUsage, the security of the system depends on the key,
certificate and the CA,. It does not depend on OpenSC enforcing the key
usage. Anyone in possession of the card could use whatever middleware they
wanted including a modified version of OpenSC. The current code sets the
PKCS#11 attributes to make it easier to select the correct cert and key.

I will look at the key usages in certificates on the NIST demo cards, and
ever other certificate I may have that was from a valid PIV card to see if
the key Usage match what is in the specs.

On Tue, Aug 9, 2016 at 9:51 PM, Mouse [email protected] wrote:

Well, maybe Yubico does enforce Key Usage on the Retired keys?
Especially Yubikey 4, that they tried to make stricter and more conformant?
Also, while Yubico does not follow all the policies, those devices seem
to follow enough of the PIV policies to be very useful (to us at least)
as an affordable convenient PIV-compatible token. I just completed
integration of PIV login with Active Directory - using Yubikey NEO as the
test-card. Worked wonders. I'll probably keep using it as my PIV token even
after PIV smart card get provisioned and deployed.

Back to the retired keys. Maybe in this case we should not allow the
user to do every stupid illegal thing he wants? Or at least guard this
action by requiring the user to set an explicit flag, something like "Yes I
want to F the standard"?

P.S. You probably know that while CAC signing keys are not replaceable,
one can request a copy of his CAC encrypting key pair? So the
usefulness/necessity of retired keys IMHO is fairly low.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#847 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA00MaC96hKwnIZKnsbvqRlDkNoWFe45ks5qeTypgaJpZM4JeW0_
.

[mouse07410]

My use cases are code signing, SSH, and GPG, none of which require strict compliance with the PIV standard. Having more key slots available is really useful, especially since the hardware supports it.

Well, I'll leave this to you and @dengert .

I don't have access to AD anymore. I assume you are using the built in Windows PIV driver on Windows machines?

No, I'm using OpenSC on Mac, with my fork of OpenSC.tokend. As that was the purpose of that exercise - to get Mac users login using PIV-compliant smart cards, via AD.

If you are going to issue NEO cards to people good luck with all the card management issues.

Thanks, regarding this aspect I had all the luck I needed. Participants of the Mac 2-factor pilot have NEOs. When the time comes to deploy wider - (hopefully) PIV smart cards (that you can print on, etc) would be available.

As for copies of any of the encryption keys,they are normally escrowed by policy of the card issuer in case your card breaks or you are doing something illegal. They could create a new card with the same key or law enforcement or your employer could retrieve what you encrypted.

Exactly! And the above does not apply to signing/authenticating keys, only to encrypting ones.

[mouse07410]

Interestingly, once I've added the Key History Object to the card, Keychain stopped recognizing the token as PIV:

8/18/16 14:32:33.740 Keychain Access[5695]: Failed to connect (_showExpiredCerts) outlet from (KeychainApp) to (NSMenuItem): missing setter or instance variable

@dengert, how do I delete Key History object from the token, so I can be sure it was the cause of the problem?

[dengert]

The yubico-piv-tool should have a way to delete an object. 

For many PIV cards writing a zero length object works:

https://github.com/OpenSC/OpenSC/wiki/PivTool#clear-a-certificate-on-the-card
Change the command to use DF:C1:0C  like this:

 00:DB:3F:FF:07:5C:03:5F:C1:0C:53:00 

If that does not work you could write a Key History Object with zero
on card keys and zero with off card keys and no URL. 

On 8/18/2016 1:40 PM, Mouse wrote:


  Interestingly, once I've added the Key History Object
    to the card, Keychain stopped recognizing the token as PIV:
  8/18/16 14:32:33.740 Keychain Access[5695]: Failed to connect (_showExpiredCerts) outlet from (KeychainApp) to (NSMenuItem): missing setter or instance variable

  @dengert, how do I delete
    Key History object from the token, so I can be sure it was the
    cause of the problem?
  —
    You are receiving this because you were mentioned.
    Reply to this email directly, view
      it on GitHub, or mute
      the thread.







  {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/OpenSC/OpenSC","title":"OpenSC/OpenSC","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/OpenSC/OpenSC"}},"updates":{"snippets":[{"icon":"PERSON","message":"@mouse07410 in #847: Interestingly, once I've added the *Key History Object* to the card, Keychain stopped recognizing the token as PIV:\r\n```\r\n8/18/16 14:32:33.740 Keychain Access[5695]: Failed to connect (_showExpiredCerts) outlet from (KeychainApp) to (NSMenuItem): missing setter or instance variable\r\n```\r\n\r\n@dengert, how do I *delete* Key History object from the token, so I can be sure it was the cause of the problem?"}],"action":{"name":"View Issue","url":"https://github.com/OpenSC/OpenSC/issues/847#issuecomment-240816437"}}}


-- 

Douglas E. Engert [email protected]

[dengert]

dengert@0884c6c

This is a first cut at allowing the certificate associated with a Retired Key to specify the keyUsage for the key. It requires PR #852

It only works for Yubico4 or NEO PIV like tokens which loosly follow the NIST 800-73 specifications. But the PIV specifications defines the "Retired Keys" as retired key management keys which have a single purpose use.

@titanous This needs a lot of testing so is not a PR yet. I am looking for comments.

[mouse07410]

The yubico-piv-tool should have a way to delete an object.

I agree. But it doesn't (yet?).

For many PIV cards writing a zero length object works: https://github.com/OpenSC/OpenSC/wiki/PivTool#clear-a-certificate-on-the-card
Change the command to use DF:C1:0C like this: 00:DB:3F:FF:07:5C:03:5F:C1:0C:53:00

Pardon me, what command? How should the complete command look like? I tried this without success:

$ opensc-tool -s "00 20 00 80 08 31 32 33 34 35 36 37 38" -s "00 DB 3F FF 07 5C 03 5F C1 0C 53 00"
Using reader with a card: Yubico Yubikey 4 OTP+U2F+CCID
Sending: 00 20 00 80 08 31 32 33 34 35 36 37 38 
Received (SW1=0x90, SW2=0x00)
Sending: 00 DB 3F FF 07 5C 03 5F C1 0C 53 00 
Received (SW1=0x69, SW2=0x82)

If that does not work you could write a Key History Object with zero on card keys and zero with off card keys and no URL.

That seemed to work: yubico-piv-tool -k -a write-object --id 0x5FC10C

Thanks!

P.S. Somebody somewhere must note and warn the user that enabling this thing will not only break the PIV standard compatibility, but likely disable the token for all the other PIV purposes on Mac, like email signing, etc.

[dengert]

What command? Read : https://github.com/OpenSC/OpenSC/wiki/PivTool#clear-a-certificate-on-the-card

Someone? Should be Yubico, its thier device. They claim its PIV and OpenSC compatable. It has many issues.

It could be the MacOS keychain problem, or the user who wrote the Key History Object on the device.

This issue #847 is experimental, and needs lots of testing.

[mouse07410]

What command? Read : https://github.com/OpenSC/OpenSC/wiki/PivTool#clear-a-certificate-on-the-card

Well, since the other way worked, I guess the details are unnecessary.

Should be Yubico, its their device. They claim its PIV and OpenSC compatible. It has many issues.

True, but I've been successfully using both NEO and 4 for pretty much everything on Mac now: smartcard logon (local and using Active Directory), screen unlock, application access (native Apple apps like Mail andSafari), access by OpenSSL (with libp11). Yes, I haven't made any use of retired certs - too bad. Chalk it off to PIV incompatibility of NEO, and tokend imperfection with Yubikey 4. I personally don't care. My usage model does not have room for 20 retired Key Management keys on my token, let alone for standard "extension" of using those 20 keys for whatever other purpose the user decides to.

It could be the MacOS keychain problem, or the user who wrote the Key History Object on the device.

Or the tokend...

This issue #847 is experimental, and needs lots of testing.

True. Perhaps it could stay as a patch rather than being integrated into the master. Especially since there doesn't seem to be a whole lot of testers.

[dengert]

If you don't write a key History Object the code is not used. If you start using the Key History Object and write the certificate(s) with the correct keyUsage (Key Encipherment for RSA or Key Agreement for EC) the PKCS#11 attributes should match the current code.

You said you added a Key History Object. Did you also add private keys and certificates to match the number of keys listed in the KeyHistory Object?

[mouse07410]

If you don't write a key History Object the code is not used.

Good to know.

You said you added a Key History Object. Did you also add private keys and certificates to match the number of keys listed in the KeyHistory Object?

Hmm... No I did not... So that's the problem that bit me, in your opinion?

[dengert]

That may be your problem. The PIV driver assumes the cards have been
issued by an approved card management system which  makes sure the
certs, keys and other objects on the card are consistent and follows
the NIST specifications. i.e. a government issued card. 

The ability of a user to write objects on the card opens up a
can-of-worms*. The driver expects the KeyHistoryObject to be
consistent with what is on the card. The Key History Object has 3
fields: keysWithOnCardCerts, keysWithOffCardCerts, and
offCardCertURL.
 keysWithOnCardCerts +  keysWithOffCardCerts <= 20. The driver
will look for the file as specified in offCardCertURL, but requires
the user to have pre-loaded it. At the time I wrote the code, there
were no off card certs, and even today there may not be any in the
field.  The NIST demo cards have examples of both on and off card
certs. 

See "NIST 800-73-3 Part1 3.2.7 Key History Object" for full
documentation. 

* U.S. idiom: "A situation that, once started, is likely to become
problematic or have a negative outcome."

On 8/18/2016 10:13 PM, Mouse wrote:


    If you don't write a key History Object the code is not used.

  Good to know.

    You said you added a Key History Object. Did you also add
      private keys and certificates to match the number of keys
      listed in the KeyHistory Object?

  Hmm... No I did not... So that's the problem that bit me, in
    your opinion?
  —
    You are receiving this because you were mentioned.
    Reply to this email directly, view
      it on GitHub, or mute
      the thread.







  {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/OpenSC/OpenSC","title":"OpenSC/OpenSC","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/OpenSC/OpenSC"}},"updates":{"snippets":[{"icon":"PERSON","message":"@mouse07410 in #847: \u003e If you don't write a key History Object the code is not used.\r\n\r\nGood to know.\r\n\r\n\u003e You said you added a Key History Object. Did you also add private keys and certificates to match the number of keys listed in the KeyHistory Object?\r\n\r\nHmm... No I did not... So that's the problem that bit me, in your opinion?\r\n"}],"action":{"name":"View Issue","url":"https://github.com/OpenSC/OpenSC/issues/847#issuecomment-240917049"}}}


-- 

Douglas E. Engert [email protected]

[mouse07410]

First, thank you! I think I understand better now.

The ability of a user to write objects on the card opens up a can-of-worms

The "user" does not have this ability. Possession of the "Card management key" is the equivalent of being the IT/provisioning center. So this is like IT experimenting with a card before deployment.

Needless to say, when I distribute cards/tokens, I don't give the management keys with them. ;-)

[dengert]

Yubico sells tokens to anyone, including individuals. So my
statement stands about users and a can-of-worms.

Base on who you work for,  I am sure you will run a good card
management system.  


On 8/19/2016 11:35 AM, Mouse wrote:


  First, thank you! I think I understand better now.

    The ability of a user to write objects on the card opens up a
      can-of-worms

  The "user" does not have this ability. Possession of the "Card
    management key" is the equivalent of being the IT/provisioning
    center. So this is like IT experimenting with a card before
    deployment. 
  Needless to say, when I distribute cards/tokens, I don't give
    the management keys with them. ;-) 
  —
    You are receiving this because you were mentioned.
    Reply to this email directly, view
      it on GitHub, or mute
      the thread.







  {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/OpenSC/OpenSC","title":"OpenSC/OpenSC","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/OpenSC/OpenSC"}},"updates":{"snippets":[{"icon":"PERSON","message":"@mouse07410 in #847: First, thank you! I think I understand better now.\r\n\r\n\u003e The ability of a user to write objects on the card opens up a can-of-worms\r\n\r\nThe \"user\" does not have this ability. Possession of the \"Card management key\" is the equivalent of being the IT/provisioning center. So this is like IT experimenting with a card before deployment. \r\n\r\nNeedless to say, when I distribute cards/tokens, I don't give the management keys with them. ;-) "}],"action":{"name":"View Issue","url":"https://github.com/OpenSC/OpenSC/issues/847#issuecomment-241067738"}}}


-- 

Douglas E. Engert [email protected]

[mouse07410]

Yubico sells tokens to anyone, including individuals. So my statement stands about users and a can-of-worms.

Like everywhere else, an ability comes with responsibility. Any card you could buy must come with the ability to do something with it - like provisioning. If an organization (and we know that not all of them are competent :) or an individual buys such a token (or a bunch of them), the assumption is they either know how to use it, or know where/how to learn that. If not - whose fault is that?

Speaking of other tokens, I've no idea whether OpenSC can be used to provision, e.g., Oberthur PIV cards - or they'd require a system that costs thousands of dollars (because I won't be buying such on my own dime anyway :).

Yubico allows anybody to buy a few tokens and provision them for himself, his family, his friends. Plus, I suspect that the majority of Yubico token buyers use OTP and OpenPGP modes/applets (maybe now U2F mode). Regardless, I love the capabilities these tokens offer, for quite reasonable price.

Perhaps other smart cards can be purchased and used the same way as Yubico PIV - that depends on whether they can be provisioned without specialized and expensive equipment.

[dengert]

@titanous, Can you try #852 and dengert/OpenSC@740a41b with a Yubico with retired keys and certificates that have various keyUsage bit set?

[titanous]

Yes, I'll do so this weekend. Thanks!

[hadmut]

Is there any progress about this matter?

Since yubikeys are not exactly cheap, it would greatly reduce costs if all 24 key slots could be used for regular key use, and thus a single yubikey would cover what it takes three or four otherwise.

regards

[dengert]

The code was committed as part of #905
being rebased in November from original Aug 18, 2016 67ea96d

I am going to close this issue. Please open a new issue if it does not meet your needs.

[madjam002]

@dengert Is this going to get released in a new version of OpenSC? I can't see the commit included in any of the latest releases. Cheers

[dengert]

@madjam002 67ea96d it is in the master branch so should be in next release.

@frankmorgner another request to get a 0.17.0 release....

[madjam002]

@dengert That's great, thanks! 😄

[gebi]

I just wanted to say thx for this!!

This feature is awesome, as we are also searching for a way to have more than one ssh key on the yubikey. Now only support for 4096bit rsa would need to be enabled on the PIV side on the yubikey.

[apollo13]

I am on opensc 0.17.0 and using trying to use a reserved slot with openvpn:

openvpn --show-pkcs11-ids /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so

openvpn calls pkcs11h_certificate_enumCertificateIds (see https://github.com/OpenVPN/openvpn/blob/c68a025a1ca687c19d7ae8599464f768b7525df5/src/openvpn/pkcs11.c#L888-L895 ) but apparently does not "see" the retired slots. Is this still expected behavior after 67ea96d or am I missing something?

[dengert]

Yes you are missing something. You may need a Key History Object.

This comment on how to say write a Key History Object to use 20 of the retired keys and certificates. #847 (comment)

[apollo13]

@dengert Nice, that works now. Thanks for the tip!

[fgervais]

This is getting quite old but I just used this info for ssh auth with slot 82 on yubikey 5 nfc. It works fine as expected.

My use case is that I want my ssh auth to require touch so if I ever get hacked and someone is trying to trampoline out of my machine to somewhere else I'll be notified. However I sometimes need to fetch the android aosp and I don't want to touch 300+ times so for that I have another key which does not require touch in slot 82.

If it helps, I did this as mentioned above:

echo -n C10114C20100FE00 | yubico-piv-tool -k -a write-object --id 0x5FC10C -i -

Then I generated the certificate as follow:

cat cert.conf 
[ req ]
x509_extensions = v3_req
distinguished_name = req_distinguished_name
prompt = no
[ req_distinguished_name ]
CN=Home SSH key (no touch)
[ v3_req ]
subjectKeyIdentifier=hash
keyUsage=digitalSignature,keyEncipherment

openssl req -new -x509 -key home-key_no-touch.pem -out home-cert_no-touch.pem -subj '/CN=Home SSH key (no touch)' -days 3650 -config cert.conf 

If I understood correctly, the important bit here is the "keyUsage" part.

If you don't have it you'll get what I had at first:

OPENSC_DEBUG=3 ssh -I /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so -p 2222 192.168.2.59
...
0x7f2a90091f80 13:36:48.821 [opensc-pkcs11] pkcs11-object.c:653:C_SignInit: C_SignInit() = CKR_KEY_TYPE_INCONSISTENT
C_SignInit failed: 99
sign_and_send_pubkey: signing failed: error in libcrypto

[mouse07410]

First, why are you using slot 82? Are the normal four slots not enough?

Second - key usage your specified is only for CA to sign certificates. That could explain "key type inconsistent" error. Finally, "yubico-piv-tool" allows setting touch policy, but I don't remember/know whether the applet adds more restrictions (like, enforces "PIN Always" for signing keys).

[fgervais]

I'm sorry if my comment sounded like a question. Everything is working fine. I just dumped what I did so others could do the same if there use case matches mine.

I'm using slot 82 because I'm already using 9a for is intended purpose and the other 3 slots had a very specific purpose, I didn't want to mess that up. I though if I would go against the standard and add an extra authentication key, I might as well use one of these extra slots.

As for the key usage, I'm not familiar with this, what would you recommend for ssh public key authentication? keyAgreement? keyCertSign?

[mouse07410]

"Digital Signature". Probably also "Key Encipherment" if your keys are RSA, or "Key Agreement" if they're ECC.

[fgervais]

Thanks for pointing that out, it makes a lot more sense.

I'll edit my post to reflect the change.

[dengert]

You said: "This is getting quite old but I just used this info for ssh auth with slot 82 on yubikey 5 nfc. It works fine as expected."

Because of security risks, NIST 800-73-3 does not allow access to most objects and keys over the contactless interface (NFC) . Compliant PIV card enforces this. Yubico does not. Use at your own risk.

NIST 800-73-4 does allow this contactless bur requires "VCI" using "Secure Messaging". I have recently obtained an approved demo card (populated with 25 certs/25 keys) the can do this, and have started implementing these optional features in the PIV driver.

[Theliel]

A lot of thank guys, this conversation finally solved my problem with my YubiKey 5 NFC too. After a lot of headache, thank to write the KeyHistory, Im able to store and use some others certs (tested already). I understand the "Retirement" importance, but in other hand is pretty useful we can able to use additional slots.

Yubiko allow us disable NFC interface for PIV, can be... "dangerous" allow NFC for all applets.

[flapee]

I'm at a loss, KeyHistory was enabled, can generate self-signed keys in retired slots using piv,
but using pagent (from putty-cac ) with opensc PKCS, login fails stating that cert cannot be used to sign data. Was the change reverted ?

[banana110]

Thanks for the pointer, I was able to write the object and now OpenSC sees the keys. However, it won't let me use the keys in the retired slots for for signatures, reporting:

error: PKCS11 function C_SignInit failed: rv = CKR_KEY_TYPE_INCONSISTENT (0x63)

Here's the whole object dump: https://gist.github.com/titanous/d76eb86c7e9dcf76aaf2858d74ff3faf

And in case anyone is wondering, here's the command to write the Key History object specifying 20 keys with on-card certificates:

echo -n C10114C20100FE00 | yubico-piv-tool -k -a write-object --id 0x5FC10C -i -

hello ,i wonder how to revert this operation thanks alot. i mean "echo -n C10114C20100FE00 | yubico-piv-tool -k -a write-object --id 0x5FC10C -i -"

[banana110]

Thanks for the pointer, I was able to write the object and now OpenSC sees the keys. However, it won't let me use the keys in the retired slots for for signatures, reporting:

error: PKCS11 function C_SignInit failed: rv = CKR_KEY_TYPE_INCONSISTENT (0x63)

Here's the whole object dump: https://gist.github.com/titanous/d76eb86c7e9dcf76aaf2858d74ff3faf

And in case anyone is wondering, here's the command to write the Key History object specifying 20 keys with on-card certificates:

echo -n C10114C20100FE00 | yubico-piv-tool -k -a write-object --id 0x5FC10C -i -

I tested on a YK5 nfc.
first i exec
echo -n C10114C20100FE00 | yubico-piv-tool -k -a write-object --id 0x5FC10C -i -
then exec
"C:\Program Files\Yubico\YubiKey Manager\ykman.exe" piv certificates import 82 i:/MySmimeCert.pfx

reinsert key ,i see my cert in windows certificate manager "certmgr.msc", but it can't be used actually.
i test outlook ,it can show the windows smartcard pin input dialog but with right password it still can't decode encrypted email
i also test word to sign a docx file also show pin input but finally show error

finally i delete slot 82 and test to use gui manager import my cert to 9a,9c,9d,9e slot
result:
slot: 9a 9d 9e can be used in outlook to decode encrypted email and in word to sign docx
slot 9c can't be used in outlook to decode encrypted email
slot 9c can be used in word to sign docx

how can i do to use retired slot cert in outlook or word
thanks a lot