5 ms·

Who is this company and why would I buy a key from them instead of Yubico?

by ghostpepper 7y ago

plugger 7y ago
Don't know who they are but there's some speculation that Yubico is Crypto AG like.
- ghostpepper 7y ago
  Can you link to a source for that?
  - plugger 7y ago
    Have a look at the comments regarding the recent Crypto AG story here. There's some insinuation in there.
    - ghostpepper 7y ago
      This one? https://news.ycombinator.com/item?id=22297963 https://news.ycombinator.com/item?id=22297963 I did a ctrl + f on both pages of comments for "yubi" with no results. Sorry if I've missed something obvious.
- motohagiography 7y ago
  This is testable, and also very difficult to falsify without testing it. I'd say there is more value in doing or sponsoring the research to investigate it and I wouldn't cast aspersions on the vendors. They are better than passwords for the majority of consumer and corporate use cases. 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.
- lawnchair_larry 7y ago
  Not by anyone with half a clue there isn’t.
  - tptacek 7y ago
    This is such a lame conspiracy theory that me and lawnchair_larry are on the same side of it.
roblabla 7y ago
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).
- ecesena 7y ago
  OpenPGP is arriving, will be available via firmware upgrade. https://github.com/solokeys/openpgp https://github.com/solokeys/openpgp
  - XMPPwocky 7y ago
    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.

Who is this company and why would I buy a key from them instead of Yubico?

plugger 7y ago

Don't know who they are but there's some speculation that Yubico is Crypto AG like.

ghostpepper 7y ago
Can you link to a source for that?
- plugger 7y ago
  Have a look at the comments regarding the recent Crypto AG story here. There's some insinuation in there.
  - ghostpepper 7y ago
    This one? https://news.ycombinator.com/item?id=22297963 https://news.ycombinator.com/item?id=22297963 I did a ctrl + f on both pages of comments for "yubi" with no results. Sorry if I've missed something obvious.
motohagiography 7y ago
This is testable, and also very difficult to falsify without testing it. I'd say there is more value in doing or sponsoring the research to investigate it and I wouldn't cast aspersions on the vendors. They are better than passwords for the majority of consumer and corporate use cases. 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.
lawnchair_larry 7y ago
Not by anyone with half a clue there isn’t.
- tptacek 7y ago
  This is such a lame conspiracy theory that me and lawnchair_larry are on the same side of it.

roblabla 7y ago

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

ecesena 7y ago
OpenPGP is arriving, will be available via firmware upgrade. https://github.com/solokeys/openpgp https://github.com/solokeys/openpgp
- XMPPwocky 7y ago
  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.