Yubico Forum https://forum.yubico.com/ |
|
[SOLVED] - how to transition to a new OpenPGP key (reset) https://forum.yubico.com/viewtopic.php?f=4&t=2405 |
Page 1 of 2 |
Author: | linsam [ Fri Aug 26, 2016 5:10 am ] |
Post subject: | [SOLVED] - how to transition to a new OpenPGP key (reset) |
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) |
Author: | SporkWitch [ Sat Aug 27, 2016 8:21 pm ] |
Post subject: | Re: [question] - how to transition to a new OpenPGP key (res |
linsam wrote: 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):
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: Code: gpg2 --edit-key --expert <keyid> 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: Code: gpg2 --edit-key robert@klebes.info gpg (GnuPG) 2.1.11; Copyright (C) 2016 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. sec rsa2048/0xC13607BD83A9E927 created: 2016-08-25 expires: 2017-08-25 usage: SC trust: ultimate validity: ultimate ssb rsa2048/0x970B4C0FC47073FE created: 2016-08-25 expires: 2017-08-25 usage: E [ultimate] (1). Robert Klebes <robert@klebes.info> [ultimate] (2) Robert Klebes <rob.klebes@gmail.com> [ultimate] (3) Robert Klebes <rfk3806@rit.edu> [ultimate] (4) Robert Klebes (Keybase User: sporkwitch) <sporkwitch@keybase.io> gpg> addkey Secret parts of primary key are stored on-card. Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (10) ECC (sign only) (11) ECC (set your own capabilities) (12) ECC (encrypt only) (13) Existing key Your selection? 4 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 2048 Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) 1y Key expires at Sun 27 Aug 2017 14:49:19 EDT Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. sec rsa2048/0xC13607BD83A9E927 created: 2016-08-25 expires: 2017-08-25 usage: SC card-no: 0006 03647658 trust: ultimate validity: ultimate ssb rsa2048/0x970B4C0FC47073FE created: 2016-08-25 expires: 2017-08-25 usage: E ssb rsa2048/0xAD5F52AC4DEB718E created: 2016-08-27 expires: 2017-08-27 usage: S [ultimate] (1). Robert Klebes <robert@klebes.info> [ultimate] (2) Robert Klebes <rob.klebes@gmail.com> [ultimate] (3) Robert Klebes <rfk3806@rit.edu> [ultimate] (4) Robert Klebes (Keybase User: sporkwitch) <sporkwitch@keybase.io> 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): Code: gpg> addkey Secret parts of primary key are stored on-card. Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (10) ECC (sign only) (11) ECC (set your own capabilities) (12) ECC (encrypt only) (13) Existing key Your selection? 8 Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Sign Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? s Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? e Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? a Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Authenticate (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? q RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 2048 Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) 1y Key expires at Sun 27 Aug 2017 14:53:57 EDT Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. sec rsa2048/0xC13607BD83A9E927 created: 2016-08-25 expires: 2017-08-25 usage: SC card-no: 0006 03647658 trust: ultimate validity: ultimate ssb rsa2048/0x970B4C0FC47073FE created: 2016-08-25 expires: 2017-08-25 usage: E ssb rsa2048/0xAD5F52AC4DEB718E created: 2016-08-27 expires: 2017-08-27 usage: S ssb rsa2048/0xCD560758CC50C8A8 created: 2016-08-27 expires: 2017-08-27 usage: A [ultimate] (1). Robert Klebes <robert@klebes.info> [ultimate] (2) Robert Klebes <rob.klebes@gmail.com> [ultimate] (3) Robert Klebes <rfk3806@rit.edu> [ultimate] (4) Robert Klebes (Keybase User: sporkwitch) <sporkwitch@keybase.io> 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: Code: gpg2 -u <newkeyid> --edit-key <oldkeyid> 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): Code: gpg2 --export-secret-keys --armour <newkeyid> > privkey.bak.asc Next we want to get the master key off of this system: Code: gpg2 --export-secret-subkeys <newkeyid> > subkeys.asc gpg2 --delete-secret-key <newkeyid> gpg2 --import subkeys.asc shred --remove subkeys.asc 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). |
Author: | SporkWitch [ Sat Aug 27, 2016 8:27 pm ] |
Post subject: | Re: [question] - how to transition to a new OpenPGP key (res |
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. |
Author: | ChrisHalos [ Sat Aug 27, 2016 9:17 pm ] |
Post subject: | Re: [question] - how to transition to a new OpenPGP key (res |
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 |
Author: | SporkWitch [ Sun Aug 28, 2016 2:55 am ] |
Post subject: | Re: [question] - how to transition to a new OpenPGP key (res |
ChrisHalos wrote: 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. |
Author: | linsam [ Tue Aug 30, 2016 6:40 am ] |
Post subject: | Re: [question] - how to transition to a new OpenPGP key (res |
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. |
Author: | SporkWitch [ Tue Aug 30, 2016 10:00 am ] |
Post subject: | Re: [question] - how to transition to a new OpenPGP key (res |
linsam wrote: 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've added a warning, though, just to be clear 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). |
Author: | mouse008 [ Fri Sep 02, 2016 3:48 am ] |
Post subject: | Re: [SOLVED] - how to transition to a new OpenPGP key (reset |
Quote: 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... 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. |
Author: | SporkWitch [ Fri Sep 02, 2016 4:48 am ] |
Post subject: | Re: [SOLVED] - how to transition to a new OpenPGP key (reset |
mouse008 wrote: Quote: 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... 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). |
Author: | mouse008 [ Fri Sep 02, 2016 6:00 am ] |
Post subject: | Re: [SOLVED] - how to transition to a new OpenPGP key (reset |
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: Code: $ ./token-rng.py Set PKCS11_LIBRARY to "/Library/OpenSC/lib/opensc-pkcs11.so" INFO 2016-09-02 00:56:25,705 - token-rng - run_loop: TokenRNG initializing at Fri Sep 2 00:56:25 2016 INFO 2016-09-02 00:56:29,883 - token-rng - run_loop: Random data length: 128 bytes, hex value: b'fe866aa513280bb895dbb0eeaa6ea6194448d631d2d32966f8d6fadc902570e6c784d7a731f5325de5f7fe9716bf328d22e3165fc65c49b227b50761e5fc6e955ccec0271809bf08e8676bc70162e10ada23bf3757eb3815fb843a42543e29c6b7cfa8b1bad0ab0f4e55ab4ea216bc98a403057ce66536ccd1e69f60420bbd24' INFO 2016-09-02 00:56:30,171 - token-rng - run_loop: Random data length: 128 bytes, hex value: b'f21d9a8247c3832f3dea6d39d083504775dc3d81099674ea2503db97b47d1740f79d1521733fc60551e218ca794a656406be05a52cce4168fd61122ee3b21629f4f2bc4f346a06428d54986bee36fd8b523c751360618aa760412ff321e71b512e45b0e78c62b9207c8a4fab4dbb777390b7272ad7a85cf3189d2aff856d76bf' I must add that I don't quite understand how token-rng.py was supposed to be used. |
Page 1 of 2 | All times are UTC + 1 hour |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |