Hacker News Reader

Comment by nbernard | Hacker News Reader

Well, considering that Yubikeys can generate crypto keys (for SSH, PGP, etc.) on device, I assume it would be possible for a fake one to use a backdoored/weak random number generator so that encryption/authentication based on these keys could be broken...

Another potential attack (for those who use them to store keys created on another device), would be to have a way, for an attacker that would steal your (fake) Yubikey, to get back the secret key (which is normally impossible/hard on a genuine Yubikey).

View on HN

Tangential but IMO it's almost always better to generate the private key off-device and store it somewhere securely. It doesn't matter when the Yubikey gets lost because you'll be revoking the GPG key, but when you accidentally destroy your Yubikey, it's convenient to be able to set up a new Yubikey without generating a new GPG key and changing it everywhere.

Doesn't taking the key off the device sort of defeat the purpose?

> ... generate the private key off-device and store it somewhere securely.

Doesn't even have to stored securely if it is protected with a strong passphrase. You can keep it anywhere. ... and with contemporary versions of GPG that might only have to be 4 diceware words.

For PGP stuff, the advantage of something like a Yubikey is that the unencrypted private key is never exposed to a possibly insecure end device. The actual cryptography is done on the Yubikey. This is a somewhat different situation than with other uses where the Yubikey only protects the secret information.

Strong disagree on that.

That means the key has existed in RAM, which largely defeats the point of it being HW based.

The point of HW based is that no matter what, if a key is not connected then it is not used to auth. If it requires touch then all the hackers in china cannot auth using it, without getting on a plane and breaking in.

You should have a backup hardware device, and for GPG subkeys or something.

That's why the standard recommendation is to generate keys on an airgapped computer without persistent storage, and run keytocard from there.

I have a set of dead Yubikey 4s that are blacklisted from GitHub because the onboard key generation code generated insecure keys (nevermind that I didn't use that feature, but wygd).

The overarching best practice is to reduce the number of points of compromise/failure to a bare minimum: if your trusted hardware can generate its own keys, then you shouldn't establish a separate trust relationship with a different machine to generate keys that get imported into your trusted hardware.

This is bad advice, for precisely the reason you've described. It should not be possible to sign things with a key that has been ostensibly destroyed.

If you need to be able to recover from a destroyed key, you should either (a) repeat your initial trust process, or (b) prematurely attest to a second key using your first one.

Reply on news.ycombinator.com