Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Yubikey

debugging.works

Post reply on HN
Print view View original

181–186 of 186 posts

Re: How to Yubikey

#181

Post by lxgr »

EvanAnderson wrote: post #56
sheerun wrote: post #21

I really would like to use it, but without ability to backup it, I don't wanna. I've read some time ago Yubikey of some other company showed initial spec, but I never heard any followup, I don't remember the link. For now I'm using TOTP but it's a chore. Salesforce Authenticator has nice idea with custom push-based protocol, but it's not running on dedicated hardware. I think ESP32 S3 has hardware potential to act as…

I'm with you re: backups. The whole "just have a backup key" methodology seems tediously manual and fraught with opportunities for error/laziness. I've been looking into OnlyKey[0] recently. It seems to have sensible backup functionality at least. Using something The Mooltipass[1] (USB HID password vault w/ TOTP support that has a sensible backup strategy) comes closest to what I want, but not quite close enough. (I'…

> It seems to have sensible backup functionality at least.

The backup functionality seems to completely negate all security benefits of using separate/minimal security key hardware, since it requires passphrase entry on a computer and then exposes the backup file encrypted under that passphrase to the same computer.

Re: How to Yubikey

#182

Post by EvanAnderson »

lxgr wrote: post #181
EvanAnderson wrote: post #56

Earlier quoted context omitted.

I'm with you re: backups. The whole "just have a backup key" methodology seems tediously manual and fraught with opportunities for error/laziness. I've been looking into OnlyKey[0] recently. It seems to have sensible backup functionality at least. Using something The Mooltipass[1] (USB HID password vault w/ TOTP support that has a sensible backup strategy) comes closest to what I want, but not quite close enough. (I'…

> It seems to have sensible backup functionality at least. The backup functionality seems to completely negate all security benefits of using separate/minimal security key hardware, since it requires passphrase entry on a computer and then exposes the backup file encrypted under that passphrase to the same computer.

You commission the device on an air-gapped device. If you type the password on a network-connected computer you’re doing it wrong. Bonus points for physically destroying the computer you commission the device on.

It’s just like commissioning an HSM.

Re: How to Yubikey

#183

Post by lxgr »

EvanAnderson wrote: post #182
lxgr wrote: post #181

Earlier quoted context omitted.

> It seems to have sensible backup functionality at least. The backup functionality seems to completely negate all security benefits of using separate/minimal security key hardware, since it requires passphrase entry on a computer and then exposes the backup file encrypted under that passphrase to the same computer.

You commission the device on an air-gapped device. If you type the password on a network-connected computer you’re doing it wrong. Bonus points for physically destroying the computer you commission the device on. It’s just like commissioning an HSM.

> You commission the device on an air-gapped device. If you type the password on a network-connected computer you’re doing it wrong.

This is a pretty unrealistic requirement for a purported Yubikey alternative. This assumption/requirement also not mentioned anywhere in its manual, as far as I can tell.

There are ways to get secure backups of hardware authenticators (or even HSMs), but they generally require some form of secure I/O. I don't see how it would be possible with a Yubikey-like device, unless you're fine with entering a high-entropy secret using on-device buttons.

> Bonus points for physically destroying the computer you commission the device on. It’s just like commissioning an HSM.

I've worked with HSMs, and there is no need for any destruction of hardware (unless you consider the paper sometimes used for ZMK key exchanges hardware).

Re: How to Yubikey

#184

Post by EvanAnderson »

lxgr wrote: post #183
EvanAnderson wrote: post #182

Earlier quoted context omitted.

You commission the device on an air-gapped device. If you type the password on a network-connected computer you’re doing it wrong. Bonus points for physically destroying the computer you commission the device on. It’s just like commissioning an HSM.

> You commission the device on an air-gapped device. If you type the password on a network-connected computer you’re doing it wrong. This is a pretty unrealistic requirement for a purported Yubikey alternative. This assumption/requirement also not mentioned anywhere in its manual, as far as I can tell. There are ways to get secure backups of hardware authenticators (or even HSMs), but they generally require some form…

I am being a little hyperbolic with the whole “destroy the PC” thing. I did have one engagement where we generated keys on a PC before importing into an HSM. (We did this to be vendor agnostic on the HSM for an intended 25 year lifetime for the keys.) The PC was destroyed after the ceremony and after the plaintext keys were committed to tamper-evident envelopes.

I would prefer a “security key” device with its own USB host port so I could plug a keyboard of my own choosing directly into it. A poor man’s secure PIN pad.

Edit now that I'm not on my phone:

I'm resigned to the fact that no mainstream hardware is ever going to be made that will do what I want. There isn't enough of a market for my desires, like so much technology today. It's yet one more step toward in my ending up a "digital hermit" figuratively living in a shack in Montana.

Re: How to Yubikey

#185

Post by lxgr »

EvanAnderson wrote: post #184
lxgr wrote: post #183

Earlier quoted context omitted.

> You commission the device on an air-gapped device. If you type the password on a network-connected computer you’re doing it wrong. This is a pretty unrealistic requirement for a purported Yubikey alternative. This assumption/requirement also not mentioned anywhere in its manual, as far as I can tell. There are ways to get secure backups of hardware authenticators (or even HSMs), but they generally require some form…

I am being a little hyperbolic with the whole “destroy the PC” thing. I did have one engagement where we generated keys on a PC before importing into an HSM. (We did this to be vendor agnostic on the HSM for an intended 25 year lifetime for the keys.) The PC was destroyed after the ceremony and after the plaintext keys were committed to tamper-evident envelopes. I would prefer a “security key” device with its own USB…

That's an interesting idea actually!

Ledger (and some other hardware wallets) solve this with a few buttons and a display, but that's pretty unergonomic for longer key inputs. They're mainly advertised for crypto purposes, but at least Ledger's implementation seems decent and is usable for e.g. SSH keys and OpenPGP as well.

It does the job if you only very rarely import keys, though – and in modern (asymmetric cryptography based) systems, you ideally import exactly one secret key and do the rest with public/private key cryptography derived from it, rather than having to do the tamper-evident envelope shenanigans with every partner you share keys with.

Re: How to Yubikey

#186

Post by EvanAnderson »

lxgr wrote: post #185
EvanAnderson wrote: post #184

Earlier quoted context omitted.

I am being a little hyperbolic with the whole “destroy the PC” thing. I did have one engagement where we generated keys on a PC before importing into an HSM. (We did this to be vendor agnostic on the HSM for an intended 25 year lifetime for the keys.) The PC was destroyed after the ceremony and after the plaintext keys were committed to tamper-evident envelopes. I would prefer a “security key” device with its own USB…

That's an interesting idea actually! Ledger (and some other hardware wallets) solve this with a few buttons and a display, but that's pretty unergonomic for longer key inputs. They're mainly advertised for crypto purposes, but at least Ledger's implementation seems decent and is usable for e.g. SSH keys and OpenPGP as well. It does the job if you only very rarely import keys, though – and in modern (asymmetric crypto…

The device that comes closest to what I'd like is the NitroKey HSM (and the underlying SmartCard-HSM applet it's based on). It doesn't have any secure PIN pad option that I'm aware of, though. Buying a random USB keyboard from an office supply store would be good enough for me.

The tamper-evident envelope thing was for CA root keys for a DRM system to 'protect' embedded device firmware (read: revenue model) that we implemented for a Customer.

The product line has a 25 year field service life. It was a requirement to be able to issue new intermediate CA certs for that period. We met with a couple large HSM vendors and decided the lock-in risk with the proprietary HSM platforms was too great.

Instead we opted for a key generation and HSM commissioning ceremony modeled after the DNSSEC root key signing ceremony. It was the best way we could come up with to have the key material available for loading onto other HSMs down-the-road.

I guess it turned out to be good idea (so far). I heard the Customer switched HSM in the last couple years.

Post reply on HN