Hacker News Reader

Hacker News

Comment by dkanejs | Hacker News Reader

Parent Full thread

dkanejs

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.

View on HN

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.

Reply on news.ycombinator.com