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 security has as it has e-fuses and has enough umph for cryptography, it would be interesting option to see (maybe with optional wifi/bluetooth faraday cage on it)
The backup plan is mostly having a backup key. The whole point is that there's a secret inside the key that can't be stolen, and that means there's no way of exporting it either. Most services I deal with allow registering multiple keys. Some like Paypal don't, but allow having both a key and TOTP so you can use TOTP as a fallback.
It mostly acts as a keyboard (bluetooth or USB). It supports TOTP, and will type it out for you. It has an internal battery and for TOTP the clock is set by the management application for it.
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'm disenchanted with it because it seems to lean heavily on an app on the host computer for functionality.)
> 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.
> 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).
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.
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.
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.
> I really would like to use it, but without ability to backup it
I totally know the feeling. I was there, I don't believe for a second that enrolling another key is an acceptable option and I solved that problem in a way that works for me.
You can clone your own security key if you're willing to deal with the problem that now becomes: "How do I safely store the secret allowing to restore another security key?".
I'm using paper seeds, split over several countries. A $5 wrench attack on my mom to have her open her safe won't be sufficient. The attacker would need to $5 wrench another half too, which my mom doesn't have.
Ledger Nano S (supposedly a cryptocurrency hardware wallet but I only care about the U2F support) has a U2F "nano app" installable on the key which shall do U2F (and webauthn, which is backward compatible from the device's point of view... It's not clear to me if it's going to work as a "passkey" too or not). They cost $79 or something.
Ledger kinda knows what they're doing: their CTO was part of the original FIDO spec group.
Buy two of them, initialize them with the same seed. Make sure to secure your paper seed.
In my case the issue of "cloning and backuping a U2F/webauthn key" is solved. But it's a trade off: now I have to deal with storing the paper seed allowing to restore the U2F key.
In exchange for that hassle I get U2F everywhere (SSH being a big, big, big one) and my security keys are protected by a PIN (three wrong PINs and they reset to factory default). And I don't leave with the constant fear of losing my security key and being locked out of all my services / having to reset everything.
As an added bonus that Ledger Nano S has a tiny device telling you if you're registering or authenticating and it's telling you where you're registering/authenticating. It becomes very hard to trick you into registering/authenticating to a bad party.
Also for me to be really in trouble I'd need to both lose the ability to restore/clone another key and I'd need to lose access to the two security keys that are configured with the same seed.
Have you tested this solution? Unless something has changed since the initial spec, each handshake includes a usage counter, which the relying party sees and is supposed to remember. If the usage counter ever fails to increase, then that means something weird happened (like two keys acting as one), and the site can reject you.
There are crude ways to deal with this issue, which are fine if you intend for the second to be used only in case of emergency.
> ESP32 S3 has hardware potential to act as security
You'll probably want a tamper-proof MCU instead (i.e. the type used on payment smart cards and SIMs), if physical access is a concern to you at all.
> without ability to backup it
Your backup can be another security key. If you are concerned about design flaws (of the reliability/durability kind, not security), you can get FIDO-certified keys from many vendors other than Yubico these days.
