Hacker News Reader

Comment by simias | Hacker News Reader

So this is only a problem if you generate a key directly on your card instead of uploading it? Nothing else?

I don't really understand why you would do that since there's no way to extract the key from the token once generated. It means that you have no backup. For this reason I always generate my keys on a trusted, offline computer, make a few backups and then upload it on the token. I guess that's one more reason to do so, at least you don't have to trust the RGN of the device.

View on HN

For many people, a core value of a hardware token is "no one ever even momentarily had the key outside of this device, and extracting the key would destroy the device, so the token is the key". If you need a backup you can have a second token with its own key and make both keys authoritative. Or you could have three tokens, again each with their own key, and make it so you need two of the three to get access to the data. If you generate the keys off of the token you can never be 100% sure "no one else has a copy of this key", which should be at least somewhat distressing.

> If you generate the keys off of the token you can never be 100% sure "no one else has a copy of this key", which should be at least somewhat distressing.

Eh. I use a laptop with no local storage nor network booted off a read-only USB stick, and for good measure I wipe the USB stick after I'm done.

I've stared at your post, for at least five minutes. I've read it at least a dozen times.

I can't figure out if you're being facetious or serious.

Because he wipes (writes to) the read-only USB stick? (The one that's had the firmware replaced with BadUSB, and which he then sticks in some other piece of hardware where it takes control of the machine and uploads his private key?

The whole laptop, no memory, no network, etc... Just for this.

I'm not sure if they are serious or if they really do so. If they do, that's quite some dedication to security.

I work with keys used to move hundreds of millions of dollars. The effort to have an air gapped network is definitely worth it.

I certainly don't do that for the keys I use to access my home computer though.

Security is economics: what's it worth to attack you?

Ah! That makes more sense. The closest I've come is working on an isolated network in a secured environment.

I can't be specific, but I'm pretty sure the data I worked with had very little comparative value.

It's an old laptop. Instead of throwing it in the trash, I kept it around.

Not sure what you mean. The USB stick gets mounted as read-only on boot, so while technically you could write to it, this does not happen. The key never gets written to the USB stick, and is only kept in memory, sent to the wired printer as an QR code, and of course the Yubikey. I then wipe the USB just because, but there is no real point in doing so.

The largest vulnerability here would be the printer having some kind of memory, since BadUSB is a myth.

The point of an SSH key whose RSA key lives on a Y4 token is that you can't back it up; that key is tied permanently and irrevocably to a specific piece of hardware. Since you can obviously lose that token, you simply install a backup SSH key along with the Y4 key.

There are somewhat understandable reasons for wanting to back up TOTP secrets (it's a royal pain to re-enroll with a new device). But people who back up their Y4 RSA keys are sort of missing the point.

I use my yubikey as GPG key for mail and for pass(). I really like having a backup.

What email program do you use with Yubikey? I'm wanting to integrate more GPG into my email.

mutt works wonderfully w/ GPG.

Thunderbird does the job. Used apple Mail with GPG for Mac before switching to Linux. That had a few glitches but was workable.

Anything that can work with GPG and GPGAgent should work with a Yubikey

Mail.app and GPGTools gives a pretty good experience if you’re on macOS

You can use your yubikey to store your subkeys (still generated on the yubikey itself) while your master key is stored somewhere else. If you lose your yubikey you can revoke the subkeys and generate new ones signed by your existing master key.

With few exceptions: A) you won't be able to decrypt old messages B) you'll have to upload new public SSH keys to all servers

If you use 'pass' for storing passwords, then (A) will make your password store unavailable.

And (B) is a lot of places you have to update. In fact I aim to make it impossible to connect and update my servers key without having the existing key.

-- In short, since sub-key infrastructure really works for signatures, it seems easiest to just backup your subkeys.

> B) you'll have to upload new public SSH keys to all servers

openssh supports a CA model, so .. you can set it up so that the servers trust the CA and the CA blesses the new key. Obviously, it just shifts the "but what if we lose the .." question from the user key to the CA key, but in many cases it makes a difference.

You could also have some sort of mechanism that updates the various servers (puppet, ...) or central authentication via LDAP. SSH logins are the least of my worries. Not being able to access my passwords would suck, though :)

My password manager, hunter2 (https://chiselapp.com/user/rkeene/repository/hunter2/ ), overcomes this by spring multiple keys per password. If you change the password then all keys that currently know the password will also be updates.

pass() can make passwords readable by multiple keys as well, but then I'd have to add the keys before loosing one. Possible, but, well, a usb stick in a safe location does the job for me currently.

Seems so.

I used my Yubikeys the same way as you did (using an old laptop which was wiped), not only to have a backup copy but because with well known software it is less likely to be problematic than some embedded chip developed on a budget somewhere.

It was my impression at the time that this was best practice for setting up Yubikeys for personal use.

> It means that you have no backup.

That's actually a feature as it means you have physical access to the device. Obviously you don't want a single card to be the only key that can access a system, but it's a good technique to authenticate users. Lose the widget and you have to go talk to IT.

But then you're trusting the key generation software/hardware of your PC and some people feel this is less secure unless you're able to take drastic measures to secure the PC doing the key generation. Some people prefer the risk of losing their keys should their card/dongle get damaged or stolen so that they can have the card/dongle generate the keys itself using a verified mechanism (although in this case, clearly that verified mechanism wasn't working correctly).

That is incorrect: you can extract the key _once_ when generated on the device (at least with the OpenPGP applet) and hand it to e.g. paperkey for safekeeping.

do you have a source that private PGP keys are exportable?

A statement in a blog-post by YubiKey:

> Note that moving usage of an OpenPGP key to a new YubiKey NEO requires that you have saved a backup copy of the private key on the card as there is no way to retrieve the private key from any YubiKey, including the YubiKey NEO.

https://www.yubico.com/2015/04/yubikey-neo-openpgp-security-...

I have done this myself several times. That comment is accurate, but it's referring to the general case, post key generation.

Can you explain how to do this? I've never seen this functionality before.

Reply on news.ycombinator.com