If you set all this up, then it would be an expected outcome that the most likely thing you'll be doing is needing to recover from a disaster, not prevent a compromise.
Can't stress this enough. I had a yubikey nano that I literally never pulled from my laptop, that sat on my desk for basically the entirety of COVID. It just up and died after about 14 months. Fortunately, I had only set it up for testing purposes because I was worried about this exact scenario, and while I had a backup in my safe, had I been on my normal travel schedule that wouldn't have helped much.
The fact that it died after 0 abuse was a MAJOR turnoff for me ever proceeding down the path further. I'm sure my failure was a one-off but it left an extremely bad taste in my mouth.
I get a failure of a key that's on a keychain or being beaten up on the regular, but failure from literally just sitting in a usb-c port for less than two years is... not a great look.
I guess this might be an expected failure mode too, because their warranty is only 1 year for manufacturing defects.
Backup is a serious question though. I once started down this rabbit hole trying to type up a guide for using my yubikey and I found myself giving up when I realized there was no perfect solution.
This is the same for encryption: the number 1 threat is lost encryption keys; the number 2 threat is broken backups; the number 3 threat is stolen encryption keys. Having #1 occur is equivalent to being ransomwared with no way to pay.
In both cases, you need multiple copies, or if you are using non-copyable aspects of security keys like U2F or OTP, then you need multiple backup keys registered to the same services.
The yubikey ends up being solely for convenience for less important things(it's easier to press the yubikey physically than it is to bring out my google authenticator app and copy/paste a TOTP).
Agreed that the article goes into extreme technical depth from a security/cryptographic perspective, whereas losing/breaking/being_stolen is actually the vastly more likely scenario.
This is not an option for the vast majority of people. But While we are at it, if the government wants to confiscate your bank locker they totally can and have access to all your secrets. So then what do you suggest?
Or often also just ask the service that you’re protecting a login for for your data directly.
But there are actual setups where storage can be encrypted with a Yubikey, and the Yubikey is protected by a PIN that's in your head, and other possible factors, so now we're in $5 wrench territory.
Very few people have this threat level and the will power to go that far.
A bank SD box costs $50/year. Why is this not an option for a majority of people? If anything, it's more accessible to use a bank SD box than being a technical enough person to run code from a GitHub repo.
> But While we are at it, if the government wants to confiscate your bank locker they totally can and have access to all your secrets. So then what do you suggest?
The bank SD box isn't full proof (as any bank employee could take a peek), which is why you'd want to shard the secret into multiple SD boxes. I.e. if your secret is ABC, you could store three secrets of AC + AB + BC, wherein you need only 2/3 to recover the entire secret. This scheme is effectively the same as Shamir Secret Sharing, but way easier to recover.
If your threat level is that the government might confiscate your bank locker, then you're probably at the level that you'd want geo-distributed sharded secrets in privacy-centric countries like Switzerland.
This is so true. I worked on v1 of BitLocker. Key management was a much bigger feature than the actual full-disk encryption. I only recently got a Yubikey because I know how easy it is to shoot myself in the foot, and I’m still very nervous about it.
https://www.jabberwocky.com/software/paperkey/
https://wiki.archlinux.org/title/Paperkey
gpg --export-secret-key $KEY | paperkey --output-type raw | qrencode --8bit --output $KEY.png
zbarcam --raw --oneshot -Sbinary | paperkey --pubring $KEY.gpg | gpg --import
The article even actively suggesting you DO NOT make backups of things.
Now you’re ready to generate a new set of OpenPGP keys on the YubiKey, using the generate command:
gpg/card> generate
Make off-card backup of encryption key? (Y/n)
Enter n to ensure that the private keys never leave the YubiKey, and enter the admin PIN when prompted:
I usually don't go through quite so many steps, so if my machine was already actively compromised when I generated my keys, then the attacker has my keys.
If you're all in on the idea and have a robust process around key custody it's great, but if you just deploy it without thinking especially to an environment that may not be fully rebooted for 1-2 years at a time, it's far more likely someone will lose the keys and then only months or years later when the entire thing is restarted realise they lost all their data. And I'd put this as more likely than encryption at rest ever saving most people from data privacy.
You have to include availability and user experience in your "threat model".