That guide is great --- really helped me out when I started! Then I realized why no one uses GPG in practice: this stuff is way too hard even for security experts. That's why I believe in making things as easy and usable as possible w/o sacrificing security.
But you already succeeded at sacrificing security, because there is no note about performing key generation not in an internet-connected machine, ideally a live cd / usb image boot.
From the drduh guide:
> It is recommended to generate cryptographic keys and configure YubiKey from a secure operating system and using an ephemeral environment
To the best of my knowledge, if you trust the YubiKey firmware, and assuming that it behaves correctly, the private keys are generated on the YubiKey itself, and cannot be exported.
Also I'd strongly encourage generating encryption subkey in software (offline, air-gapped machine) and then copying it to Yubikeys. If you lose your Yubikey (or mistype 3 times the PIN) you wouldn't be able to decrypt your secret data.
We're aware of hardware vulns like ROCA (we used to check the exact version of the YK, now we support only the major version 5).
We're taking the risk anyway because the benefits of having the private keys generated and stored entirely on the YK is entirely worth it.
We're also not primarily using the YK to encrypt messages. If continuing to decrypt shared messages in the future is critical, I'd personally look into HSMs which offers key-wrapped backup.
"Trust" isn't really that binary. I trust smart cards and key fobs much more with not leaking key material than generating said keys in a safe fashion.
That specific best practice might not be the most important for most people to follow, compared to other things on the list, but it is definitively a good idea and has saved me before. Random number generators on embedded devices aren't always the best.
Oh that's great, alleviates my concerns, which was like, how do you know you're even asking the yubikey to do key generation rather than a malicious actor generating a private key and placing it on the yubikey. Thanks!
I didn't say I distrusted the hardware, I said the very opposite. I said I didn't see how, before this attestation feature, you could guarantee your computer software even asked the hardware to generate the key.
> To remove the transmission and on-card storage of OpenPGP PINs in plain text, the YubiKey supports the Key Derived Function (KDF) functionality. With the KDF function enabled, the PIN is stored as a hash on the YubiKey. When entering the PIN to the OpenPGP Smart Card, the OpenPGP client will only pass the hashed value, never passing the PIN directly. KDF functionality is set on the card itself, and communicated to the client; it is transparent to the user. Should the KDF functionality not be enabled, the PIN function will work as previously. The KDF function is listed in section 4.3.2 of the OpenPGP Smart Card 3.4 spec.
Can someone explain to me how KDF matters at all here?
It seems like the keys are encrypted on the yubikey via pin, or at least protected in hardware via pin, and that the pin is stored on the device. KDF seems to take that plain text pin and replace it with a hashed pin. If you steal my yubikey, it looks like KDF would prevent you from... dumping the PIN? But if you could dump the pin, wouldn't you just dump the key instead? I can't seem to figure out the threat model for this feature.
How would that help though? If you have a compromised USB interface, and you're entering your pin on that machine, you could just capture the keyboard input anyway.
Nope, you were right. It's for USB MITM. I guess the assumption is that the keyboard is wired in a different way (a laptop?) or in wireless scenarios (NFC Yubikey).
New firmware is quite interesting if one is using OpenPGP: it supports newer algorithms (25519) and key attestation (proofs that the key was generated in hardware, useful for enterprises). Still, PIV applet has some more advantages (like dozens of possible encryption subkeys) but this is mainly a limitation of OponPGP Card spec.
This statement has no effect when using Yubikey - the PIN is cached by the key itself and it will remain unlocked indefinitely until it's physically unplugged. See https://dev.gnupg.org/T3362
No, but try unplugging the YubiKey and trying again. Also, the script officially supports only YubiKey 5, but I've heard that 4 works if you remove the code that checks the version.
The tool also supports a raw output mode which can be piped to a QR encoder. 4096 bit RSA secret keys fit in binary QR codes and they are much easier to use compared to manual data entry.
Current versions of zbar can't decode binary data in QR codes properly. I've sent some patches that fix the problem but they haven't been reviewed yet. Hopefully it will be possible to automate this process with zbarcam soon.
> Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less. It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one. So signing each commit is simply missing the point.
I think "sign every commit useful?" is less about whether signing is useful, and more about the trade-off of signing every commit vs just signing a tag on a commit.
Signing every commit is going to make it a mindless task. It's easier to be vigilant when signing if you sign less frequently.
this turns commit signing on for every commit, you don't have to explicitly sign commits as a separate step.
the criticism I've always heard of this practice is, what do you do with those signatures? github displays a little widget showing that the commits are signed, but beyond that I don't think it cares which public key they were signed with, so it's not really helping anything.
Entering a key passphrase each time is going to be annoying without providing benefit over just signing some git tag.
Leaving the key unlocked in an agent is going to be somewhat less secure than requiring the key to be unlocked on every use.
> github displays a little widget showing that the commits are signed, but beyond that I don't think it cares which public key they were signed with, so it's not really helping anything.
As I understand it, "verified" means it's either a commit made on GitHub's website with that user signed in, or the commit was signed with one of the keys associated with that user's profile.
I guess for the case of "I only trust commits signed by a certain key", you'd need to use a different GitHub profile.
Gentoo org was hacked on GitHub, and had their source code modified. Luckily, their private build infrastructure used only their own personal git repo, which required signing all commits (and presumably checking them).
It is simply an audit trail to trace back to the origin, since anyone can set any email address as the author of a commit. GitHub will show the signature fingerprint I think when you hover over that widget, so you can at least distinguish between your key and an impostor’s.
I use this but it causes weird usability issues for me when using multiple iTerm tabs or git GUIs when the GPG daemon’s unlock timeout expires and I need to input my passphrase in again. I wish it could just be tied to the mac’s keychain, so when I unlock my computer it is ready to go. Or at least tie it into TouchID or Watch like unlocking the mac does.
Yes, it's so easy with this YK setup that there's no reason not to do it. The only exception is during rebase, but there's an option in GPG to disable signing then.
I sign all my commits so that everyone knows it was most likely me. You can even turn on branch protection in GitHub these days that rejects unsigned commits.
With all due respect, Mr. Torvalds isn't exactly famous for having designed the most secure kernel.
Slightly related: Anyone know why Google Chrome (not upstream Chromium, nor any derivative) is the only browser on Android that implements WebAuthn as intended? Do they implement it as a proprietary component?
Nice repo.
For those starting from scratch with a YubiKey I always recommend this guide:
https://github.com/drduh/YubiKey-Guide
Then they know how this stuff works and how to fix it when it breaks.
That guide is great --- really helped me out when I started! Then I realized why no one uses GPG in practice: this stuff is way too hard even for security experts. That's why I believe in making things as easy and usable as possible w/o sacrificing security.
But you already succeeded at sacrificing security, because there is no note about performing key generation not in an internet-connected machine, ideally a live cd / usb image boot.
From the drduh guide:
> It is recommended to generate cryptographic keys and configure YubiKey from a secure operating system and using an ephemeral environment
To the best of my knowledge, if you trust the YubiKey firmware, and assuming that it behaves correctly, the private keys are generated on the YubiKey itself, and cannot be exported.
Yes but do mind hardware bugs that affected YubiKeys such as https://magicofsecurity.com/roca-critical-vulnerability-in-i...
Also I'd strongly encourage generating encryption subkey in software (offline, air-gapped machine) and then copying it to Yubikeys. If you lose your Yubikey (or mistype 3 times the PIN) you wouldn't be able to decrypt your secret data.
We're aware of hardware vulns like ROCA (we used to check the exact version of the YK, now we support only the major version 5).
We're taking the risk anyway because the benefits of having the private keys generated and stored entirely on the YK is entirely worth it.
We're also not primarily using the YK to encrypt messages. If continuing to decrypt shared messages in the future is critical, I'd personally look into HSMs which offers key-wrapped backup.
Do you know a HSM that use key wrapping and are OpenPGP compatible? I've seen only X.509 compatible ones.
"Trust" isn't really that binary. I trust smart cards and key fobs much more with not leaking key material than generating said keys in a safe fashion.
That specific best practice might not be the most important for most people to follow, compared to other things on the list, but it is definitively a good idea and has saved me before. Random number generators on embedded devices aren't always the best.
This is assuming the binary you are running on your internet-connected computer is doing what you expect.
The GPG applet is inside the YubiKey and running entirely on there, to the best of my knowledge.
Update: new YKs with new firmware are apparently able to provide proofs that the keys were generated on hardware.
https://news.ycombinator.com/item?id=21523354
Oh that's great, alleviates my concerns, which was like, how do you know you're even asking the yubikey to do key generation rather than a malicious actor generating a private key and placing it on the yubikey. Thanks!
If you don't trust the hardware, then don't use it. I'm not sure what solution would fit your threat model, other than building your own.
I didn't say I distrusted the hardware, I said the very opposite. I said I didn't see how, before this attestation feature, you could guarantee your computer software even asked the hardware to generate the key.
Which means you have no backup...
It's trivial to make backup YubiKeys. Just takes another 5m, and storing it in a secure place. I'll make a note in our README that we do do this.
Well, you have no backup for your brain either, yet here we are.
I just got a yubikey and found this guide today. It's quite good.
One thing that I still haven't found a good answer for that's not mentioned in the guide: what's KDF for?
The new yubikey firmware has release notes here: https://support.yubico.com/support/solutions/articles/150000...
This is the bit that has me lost:
> To remove the transmission and on-card storage of OpenPGP PINs in plain text, the YubiKey supports the Key Derived Function (KDF) functionality. With the KDF function enabled, the PIN is stored as a hash on the YubiKey. When entering the PIN to the OpenPGP Smart Card, the OpenPGP client will only pass the hashed value, never passing the PIN directly. KDF functionality is set on the card itself, and communicated to the client; it is transparent to the user. Should the KDF functionality not be enabled, the PIN function will work as previously. The KDF function is listed in section 4.3.2 of the OpenPGP Smart Card 3.4 spec.
Can someone explain to me how KDF matters at all here?
It seems like the keys are encrypted on the yubikey via pin, or at least protected in hardware via pin, and that the pin is stored on the device. KDF seems to take that plain text pin and replace it with a hashed pin. If you steal my yubikey, it looks like KDF would prevent you from... dumping the PIN? But if you could dump the pin, wouldn't you just dump the key instead? I can't seem to figure out the threat model for this feature.
I'm guessing it's to protect against MITM of the USB interface
How would that help though? If you have a compromised USB interface, and you're entering your pin on that machine, you could just capture the keyboard input anyway.
That's a good point!, it has to be for another reason.
Interested to hear what it's for
Nope, you were right. It's for USB MITM. I guess the assumption is that the keyboard is wired in a different way (a laptop?) or in wireless scenarios (NFC Yubikey).
Quality discussion, both of you, thanks!
New firmware is quite interesting if one is using OpenPGP: it supports newer algorithms (25519) and key attestation (proofs that the key was generated in hardware, useful for enterprises). Still, PIV applet has some more advantages (like dozens of possible encryption subkeys) but this is mainly a limitation of OponPGP Card spec.
I've been very pleasantly surprised by how easy it was to get everything set up on NixOS:
``` programs.gnupg.agent = { enable = true; enableSSHSupport = true; };
services.udev.packages = [ pkgs.yubikey-personalization pkgs.libu2f-host ]; services.pcscd.enable = true;
environment.shellInit = '' export GPG_TTY="$(tty)" gpg-connect-agent /bye export SSH_AUTH_SOCK="/run/user/$UID/gnupg/S.gpg-agent.ssh" ''; ```
The only surprise I had was that I forgot to tell gpg to trust the imported key after I imported it.
Combine this with GoPass... its the start of something good :)
Are you using Gnome? I remember when this was impossible to get working on Gnome for a couple of releases. Hoping that's fixed now.
I'm using awesome wm.
What was the problem with gnome? I vaguely recall a problem with polkit or something.
> Optional: verify public key on Keybase.
For organizations publishing employee keys via Web Key Directory can also be an additional signal that the key is trustworthy.
It's also quite simple: for example exporting the key 5C090ED7318B6C1E (binary, not armored) and putting it on this exact URL: https://datadoghq.com/.well-known/openpgpkey/hu/964aj6q73iat... is enough to discover the key using e-mail address.
This post goes into more detail: https://spacekookie.de/blog/usable-gpg-with-wkd/
WKD is used by Linux distros (ArchLinux, Gentoo, Debian...) and kernel.org itself: https://www.kernel.org/category/signatures.html#using-the-we... as well as some OpenPGP sites (e.g. ProtonMail).
Good idea, will make a note, thanks!
> For usability while balancing security, cache PIN for at most a day.
https://github.com/DataDog/yubikey/blob/master/gpg.sh#147
This statement has no effect when using Yubikey - the PIN is cached by the key itself and it will remain unlocked indefinitely until it's physically unplugged. See https://dev.gnupg.org/T3362
Interesting. This hasn't been my experience, so not sure what's going on yet...
It's not polished, but here's a vagrant box which can provision Yubikey's PGP and PIV applications. Additional hardening can be performed.
https://github.com/justintaft/yubikey-gpg-piv-provision
Main contributor here! Let me know if you have questions.
This looks like it's MacOS only, right? Surely it wouldn't be too hard to get the same stuff working for Linux?
Yes! We are primarily a macOS shop, so I don't see us supporting Linux very much, but you are more than welcome to fork :)
This is pretty useful to me, thanks! I specially like how small the code is: it means I can easily audit it :)
Maybe you should edit the title of this submission and add "Show HN" (https://news.ycombinator.com/showhn.html).
Done, thanks!
Any issues using Catalina? mine shows Error: No YubiKey detected!
No, but try unplugging the YubiKey and trying again. Also, the script officially supports only YubiKey 5, but I've heard that 4 works if you remove the code that checks the version.
Using a hardware token to protect the subkeys is important but it is also necessary to protect the primary key by keeping it offline.
The best method I know is to store it on paper with the help of paperkey:
http://www.jabberwocky.com/software/paperkey/
The tool also supports a raw output mode which can be piped to a QR encoder. 4096 bit RSA secret keys fit in binary QR codes and they are much easier to use compared to manual data entry.
Current versions of zbar can't decode binary data in QR codes properly. I've sent some patches that fix the problem but they haven't been reviewed yet. Hopefully it will be possible to automate this process with zbarcam soon.
Personally I mostly use it for SSH via PKCS11. I found that simpler than GPG because it's already integrated with SSH.
Still looking forward to SSH supporting U2F (some day).
It's here: https://marc.info/?l=openssh-unix-dev&m=157259802529972&w=2
It landed 1 november[0]
[0]: https://marc.info/?l=openssh-unix-dev&m=157259802529972
That day may be rather soon: https://news.ycombinator.com/item?id=21417182
Yubikey as a second factor for macOS login is still not possible, right?
I don't think so. That's what TouchID is for, and we are thinking of storing signing keys in that secure enclave in the future.
Is signing every commit really that useful?
Linus says "don't do it" [0]:
> Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less. It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one. So signing each commit is simply missing the point.
[0]: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
If you care about who produced your source code, yes.
I think "sign every commit useful?" is less about whether signing is useful, and more about the trade-off of signing every commit vs just signing a tag on a commit.
Signing every commit is going to make it a mindless task. It's easier to be vigilant when signing if you sign less frequently.
What trade-offs should be considered?
the criticism I've always heard of this practice is, what do you do with those signatures? github displays a little widget showing that the commits are signed, but beyond that I don't think it cares which public key they were signed with, so it's not really helping anything.
> this turns commit signing on for every commit
My understanding is:
Entering a key passphrase each time is going to be annoying without providing benefit over just signing some git tag.
Leaving the key unlocked in an agent is going to be somewhat less secure than requiring the key to be unlocked on every use.
> github displays a little widget showing that the commits are signed, but beyond that I don't think it cares which public key they were signed with, so it's not really helping anything.
As I understand it, "verified" means it's either a commit made on GitHub's website with that user signed in, or the commit was signed with one of the keys associated with that user's profile.
I guess for the case of "I only trust commits signed by a certain key", you'd need to use a different GitHub profile.
Gentoo org was hacked on GitHub, and had their source code modified. Luckily, their private build infrastructure used only their own personal git repo, which required signing all commits (and presumably checking them).
https://www.gentoo.org/news/2018/06/28/Github-gentoo-org-hac...
You can even turn on branch protection in GitHub these days that rejects unsigned commits.
https://help.github.com/en/github/administering-a-repository...
It is simply an audit trail to trace back to the origin, since anyone can set any email address as the author of a commit. GitHub will show the signature fingerprint I think when you hover over that widget, so you can at least distinguish between your key and an impostor’s.
I use this but it causes weird usability issues for me when using multiple iTerm tabs or git GUIs when the GPG daemon’s unlock timeout expires and I need to input my passphrase in again. I wish it could just be tied to the mac’s keychain, so when I unlock my computer it is ready to go. Or at least tie it into TouchID or Watch like unlocking the mac does.
Yes, it's so easy with this YK setup that there's no reason not to do it. The only exception is during rebase, but there's an option in GPG to disable signing then.
I sign all my commits so that everyone knows it was most likely me. You can even turn on branch protection in GitHub these days that rejects unsigned commits.
With all due respect, Mr. Torvalds isn't exactly famous for having designed the most secure kernel.
Is there a similar guide for TouchID?
Slightly related: Anyone know why Google Chrome (not upstream Chromium, nor any derivative) is the only browser on Android that implements WebAuthn as intended? Do they implement it as a proprietary component?
No, sorry.