Note that for a PGP key, the idea of using cheap microcontrollers is significantly worse.
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.
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.
Doesn't it depend on the threat model? If your thread model does not include physical access compromise, then the commodity STM32 approach is quite ok right? At least, in most cases it provides more security than storing the private key on disk.
I do agree that given the low prices of secure elements it is surprising that keys still don't use them. But that may depend on the lower-priced parts not being fit for FIDO2 or OpenPGP (though the Nitrokey FIDO does use an ATECC608A).
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.