Yubico Forum

I've been using a yubikey4 for some months now and just today decided to set the option to require a touch in addition to pin when signing or decrypting in gpg.

Unfortunately, I forgot my admin pin and after 3 tries I am locked out of admin access for my key.

As I understand it, I have to reset the OpenPGP app to recover, and doing so will wipe the private keys from the yubikey4.

Also as far as I can tell, to transition from an old OpenPGP key to a new one, people generally cross sign the old and new keys, and write a key transition statement that is signed by both the old and new key. However, as near as I can tell, I cannot have both a new and old key on the yubikey4 at the same time[*], so I don't see how I can do cross signing nor the double signed transition statement.

How can I update my key in an acceptable fashion?

Some additional information: I did not create a backup when I generated the original key. I have not locked myself out of signing/decrypting with the old key yet (PW1 is still good, only the admin pin is at 0 attempts remaining)

EDIT: Resetting the PGP applet will wipe out any keys currently stored. This should only be performed if you cannot remember your PIN/PUK, or you've already had the applet locked out. So, first things first, resetting the OpenPGP Applet (source):

1. Check versions:
   GPG >= v2.0.22
   
   Code:
   gpg2 --version
   
   EDIT: this is only required on yubikeys prior to the YubiKey4: The below indicates v1.0.6; this is the minimum required.
   
   Code:
   gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
   D[0000]  01 00 06 90 00
2. Reset the applet:
   Create a file and paste the following into it:
   
   Code:
   /hex
    scd serialno
    scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40
    scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40
    scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40
    scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40
    scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40
    scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40
    scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40
    scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40
    scd apdu 00 e6 00 00
    scd apdu 00 44 00 00
    /echo Card has been successfully reset.
   
   Now run it.
   
   Code:
   gpg-connect-agent -r FILE

So the way to deal with the transition is to generate the key on your computer and then move it to the yubikey. In general, you should be doing this anyway, as otherwise you're unable to make a backup of the master key (this would mean that if the yubikey is lost or damaged, so is your master, and you have to start accumulating signatures from scratch).

Generate your key on the computer. Use 2048 bit keys or make sure you're using the versions listed in the link that follows. Even though the yubikey4 supports 4096bit RSA, there's a problem in currently-shipped versions of libgcrypt that reduces the effective entropy and can cause the default encryption key to be mathematically related to the master key; this is a Bad Thing™ (CVE-2016-6316). Once you've generated the key, open it and inspect:

You should see your master key with "Usage: SC" and a key with "Usage: E". This is your master and your encryption key respectively. The first thing you should do is generate a separate signing key:

And if you want an authentication key (authentication keys should be separate from signing keys, otherwise there's the possibility of a malicious system tricking you into signing something when you were meant to be authenticating):


Once this is done, you should now have a sane key setup in your machine's gpg keyring, as well as the old key still residing on your yubikey. You can now use the old key to sign the new one in gpg as normal. Once you've done this, you can then sign the old key with the new:


Similarly, you can create a text document discussing the transition. This should include (but is not limited to) the old keyid (with full fingerprint), the new keyid (with full fingerprint), and the date of supersession. You can sign this statement with both keys via the -u flag to specify which key to use.

Last steps.

If this is your only copy of the old master key, you should revoke it now, and in the revocation statement you should include a supersession statement (include the date of supersession and the full fingerprint of the new key). EDIT: if you have the master backed up somewhere, you should make the new key a revoker on it (edit the old key and use "addrevoker"), and hold off on revoking the old key for a short while after posting the supersession statement. This helps keep it from looking as suspicious as an immediate creation -> revocation would.

Before moving the new keys onto the yubikey, you should make a backup (EDIT: this should be kept somewhere safe, such as on an encrypted flash drive and stored in a safe):


Next we want to get the master key off of this system:


Check the key and you should now only see the Encryption, Signing, and (if you made one) Authentication subkeys.

Finally, we can move the keys to the yubikey. Simply open your new key for editing again and use the "keytocard" command to move the signing, encryption, and authentication keys to the yubikey.

Congratulations, you're done! You've now migrated to a new key and have a secure setup. In the event your yubikey is lost, you still have a backup of the master key, and more importantly, the master key itself has not been compromised; you can simply revoke the keys on the yubikey and generate new ones, without losing the signatures others have placed on your key.

I hope that helped :)

[b]EDIT: Final note: only a key with the C(ertification) usage can be used to sign keys (including the signature required to extend the expiry or add new subkeys), and per RFC 4880, only the master key should be permitted to Certify. This means that you will need to use the backup in order to perform those actions or sign other people's keys. This is feasible because, in general, these activities are relatively rare. A more secure setup would involve the use of a second token (such as yubikey) in which you store the master key, so that your master is not exposed when you need to use it (in theory it would take destructive methods and probably a SEM to extract the secret key from the secure module, and let's be honest, that means your adversary is a government, in which case they've got far more effective methods of getting you to turn it over, and you've got far bigger problems than losing your keys).

_________________
Keybase User: sporkwitch
PGP Public Key: B54A 454A 2B29 9D83 0201 CB1B C136 07BD 83A9 E927

Oh, and sorry, as you noted you're basically SOL re: locking out the old one unless you made a backup like I recommended above. All you can do at that point is contact everyone you use PGP with and inform them out-of-band about the transition. I also can't stress enough the importance of securing that backup of the master key; I wasn't joking about an encrypted flash drive (even though the key's already encrypted) and a physical safe. Your master key is arguably the equivalent of your digital passport, it is your identity online, and those signatures you gather over the years are invaluable. As long as the master key is safe, so is that signature history.

_________________
Keybase User: sporkwitch
PGP Public Key: B54A 454A 2B29 9D83 0201 CB1B C136 07BD 83A9 E927

Only one tiny correction - with the YubiKey 4 you never have to run "gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye" - this is only needed for older NEOs to make sure you have version 1.0.6 or newer of the applet, so we're talking anything summer 2014 and newer isn't relevant (Unless you have a NEO applet older than 1.0.10, of course, which would be affected by the vulnerability, but it still isn't applicable for the discussion of resetting the applet). Since the YK4 was released in late 2015, this doesn't need to be run (and in fact, if you've locked out the card this will usually result in an error anyway which just confuses the user, thinking there is something else wrong).

Otherwise, thanks for adding your thoughts here, very well-informed post

Note added

Just trying to help out where I can. Someone I was helping on Freenode IRC was kind enough to donate a NEO he said he hadn't used to me as thanks, so I've been playing with it and seeing what I can't get out of it. Looking forward to picking up a fresh one as a spare (and not wipe out the cc-prefix slot like an idiot...) once I have some spare cash, heh.

_________________
Keybase User: sporkwitch
PGP Public Key: B54A 454A 2B29 9D83 0201 CB1B C136 07BD 83A9 E927

Thank you for the detailed procedure! I think one minor correction is to hold off on doing the reset on the yubikey until just before transferring the new keys to the yubikey (else I won't be able to revoke or add a revoker or do the cross signing on the old key).

I had originally generated my keys within the yubikey and not my computer on the grounds that doing so would be more secure (both from the standpoint of not needing an air-gapped system for protection and also better RNG on the key). I see now that it is a huge tradeoff against the risk of loss and inconvenience of migrating. I also just discovered the DRNG on my CPU as a better entropy source for my PC, so that worry is also reduced.

I'm definitely using your method now.

Well the sequence was more a response to your original query, you said you locked it out, so you needed to reset it before you could do anything else on the yubikey itself anyway.

As far as the RNG, it should also be possible to use the TRNG (at least I assume it's a TRNG and not a PRNG) on the yubikey itself to generate entropy for your system. I've not tried getting it to work yet with my yubikey NEO, but I did manage to patch TokenTools to work on current ubuntu(-derivatives) and it works great using an old Feitian card I had laying around. As best I can tell from the NIST suite and dieharder, the randomness generated is of very good quality, too (though it's possible I'm not using the NIST suite quite right; it's not the most user-friendly of tools, but it's a beast at its job).

_________________
Keybase User: sporkwitch
PGP Public Key: B54A 454A 2B29 9D83 0201 CB1B C136 07BD 83A9 E927

I assume you're using OpenPGP applet? What's the command(s) (APDU) to request/retrieve random data from a token (say, NEO, or Feitan)?

Can you do the same with PIV applet? What would the command be for it?

P.S. On an Intel computer I'm using RDRAND (PRNG seeded and re-seeded by TRNG). But it would be nice to mix the YubiKey-generated random data in.

It uses uses opensc and pcscd to access a PKCS11-compliant card, repeatedly call for 128 bytes of random, and pipe it into the kernel's entropy pool. That's why I'm not sure if it'll behave with the yubikey, as it was specifically designed for dedicated PKCS11 cards, such as the Feitian FTCOS/PK-01c I used when I was writing the patch for TokenTools. I've not done any testing with the Yubikey, so I don't even have a baseline to go from. It's on my to-do list, I just haven't gotten around to attacking it yet.

More info on it can be found [url=https://github.com/infincia/TokenTools]here[/here]. I'm not the original author, I just patched it to get it running on current systems (the deps it used in the past no longer have python2.7 versions in the repos, so updated it to use python3 to allow installing the deps from the default repos).

_________________
Keybase User: sporkwitch
PGP Public Key: B54A 454A 2B29 9D83 0201 CB1B C136 07BD 83A9 E927

Thank you! Cloned that repo, and got it to work on my Mac. I must say that (a) it doesn't work with Python2 any more - only Python3, and (b) it required some minor hacking to port it from Linux to Mac. I would need to add conditions to make it running on both Mac and Linux. Here's a sample:



I must add that I don't quite understand how token-rng.py was supposed to be used.