FIDO2 security key company publishes results of internal security audit

https://www.yubico.com/blog/secure-hardware-vs-open-source/

The one thing I'd love out of a security key is the ability to set up a "Twinned Pair". So I can have one key on my keychain that I use everyday and one I keep in my safe in case something happens to the primary. Yes, I know some services support multiple security keys - but setting up two is more work and not all services do support two.

U2F/FIDO2, sure, whatever- the worst failure state there is "your account is only secured by a password", and more likely attacks require physical access. I could post the secrets off the security key I use for my Google account right now and...eh, I'd probably be fine.

PGP? Ohohohoh. Now we're talking about long-term keys and non-forward-secure crypto.

If I leak your keys once- say, through power analysis, glitching, whatever- I can decrypt everything that has ever been encrypted for that key, and everything that ever will be. Compromise is total. Grab the device while it's unlocked, or use a camera, keylogger, or shoulder-surf to get your PIN- or just crack it, decrypting the encrypted keyblobs from flash ... the only thing protecting you is a barely-above-popcorn Cortex-M.

At that point, just use the fTPM in your CPU. Otherwise... hardened hardware is much more important for PGP.

If I had to design a PGP key storage mechanism, I'd probably use a reasonably well-known, well-tested "secure microprocessor"- or a 'TPM-on-a-chip' connected to an untrusted microcontroller (which would be basically just an adapter/protocol translato...hm, no, plaintext would still go across its bus, right? Forget the gpgcard spec right now, might do some link encryption, but that would be good and it's GPG so it probably doesn't. Yeah, no, I think you need the full stack on one die- or else open to attacks like replacing the untrusted microcontroller with one that logs all plaintexts it sees (and...is gpgcard challenge-response? Gotta be ...but if not, can log the pin too...anyways, ignore this aside))

Anyways, a secure microcontroller- hardware crypto engine so the microcontroller code never sees raw key material, hardware rate limiting/lockout if possible, reasonable secure boot, maybe even disable firmware upgrades entirely, self-zeroizes if you sneeze at the wrong time, etc. Attacks are still possible, but the cost goes WAY up- at least past the six figure mark, hopefully.

I'd also ban all use of RSA private keys- too easy to mess up generation, and especially since we're "secure hardware" now which means, apparently, we can't generate primes too good. No, EC keys exclusively.

Anyways ...a commodity STM32 is fine for fido2. Not great, but it's fine.

It's almost a nonstarter for PGP, and honestly any PGP support needs a giant warning label that it shouldn't be relied on to protect against physical attacks.

The most basic attack and test is to verify and/or reduce the entropy of secret symmetrical (AES) keys in the SE after personalization.

The challenge with hardware security modules is verifying outputs from the same keys but on different devices, because the key is derived/instantiated in the secure tamper proof environment. The whole point is the key doesn't exist anywhere else.

If your threat model includes the intelligence agencies of super powers, your main problem is more diplomatic than technical.