[roblabla]

SoloKeys appear to use open source firmware, whereas Yubico's firmware is closed source since the Yubikey 4 I believe. Other than that, they seem about the same. SoloKeys is a lot younger and missing a couple of Yubikey Neo's bigger features (like PGP support).

[kevin_nisbet]

I don't believe it's just open firmware, but I think it's also an open hardware project.

While perhaps not as slick as yubikey, I do have several solo keys and they're great. Only real complaint is I wasn't able to get the NFC working, which I believe is a common issue, and I think they were working on an updated design that should work more widely with a range of devices.

[ecesena]

OpenPGP is arriving, will be available via firmware upgrade.

https://github.com/solokeys/openpgp

[XMPPwocky]

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.

[microtonal]

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).

[AWildC182]

Why did Yubikey ever close source their firmware? It's really saddening to see a company going back on that

[frankharv]

The YubiKey hardware with its integral firmware has never been open sourced.

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

[martin8412]

Okay - So reading through that I get two impressions. They can't release source code because they use proprietary hardware. Secondly they believe that security through obscurity is better than publishing the code for everyone to see.

[kelnos]

I doubt they keep it closed as a (dubious) security measure. Likely they believe the source gives them some sort of competitive advantage. (Not saying they're right or wrong about that, just that's likely what they believe.)

[AWildC182]

Wow... I've never read so much bullshit in one blog post. They're basically hoping that nobody who reads this has any embedded development knowledge.