Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FIDO2 security key company releases hardware that's open source and uses Rust

solokeys.com

Post reply on HN
Print view View original

81–90 of 160 posts

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#81

Post by kelnos »

ahnick wrote: post #42
kelnos wrote: post #31

Earlier quoted context omitted.

Others have answered most of your questions, but there's something I think deserves emphasizing: In general, you cannot (by design) back up these devices; if you could, that would defeat a lot of the security they provide. That means that if you lose it, you will have to find a way to get 2FA disabled for each and every account you enabled it for. Some orgs will have pretty onerous (but necessary!) processes for doin…

Some devices derive their keys from a recovery seed that you can store offline in paper form. The benefit of this approach is that you can recreate the key on a backup device using the recovery seed, should you lose your primary.

Ah, neat, so basically the recovery seed would let you buy a new device and then use it to "clone" your old one?

Definitely useful in case you lose it or it gets stolen, but you'd end up wanting to rotate to a new key with fresh seeds anyway, since the old key could be in the hands of an attacker. I guess this is still useful in the case where you don't lose the old key, but instead damage or destroy it by accident.

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#82

Post by kelnos »

tialaramex wrote: post #43
kelnos wrote: post #31

Earlier quoted context omitted.

Others have answered most of your questions, but there's something I think deserves emphasizing: In general, you cannot (by design) back up these devices; if you could, that would defeat a lot of the security they provide. That means that if you lose it, you will have to find a way to get 2FA disabled for each and every account you enabled it for. Some orgs will have pretty onerous (but necessary!) processes for doin…

> Some sites will allow you to simultaneously enroll two devices, so you can keep one as a backup For WebAuthn (the actual standard for how to do this which is what you should be rolling out if you have a greenfield authentication environment that doesn't already do U2F today) the specification explicitly says: > Relying Parties SHOULD allow and encourage users to register multiple credentials to the same account. Re…

That's good to hear! I was under the impression that it was much more common for sites to not support a second device. Glad to know most do.

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#83

Post by tialaramex »

kelnos wrote: post #79
stouset wrote: post #39

Earlier quoted context omitted.

> Some (like Yubico) let you purchase a "cloned" set of devices Wait, they do? How? I would love to do this, but I can't find anything relevant on their website.

After going through their "what do I need?" quiz, it seemed to indicate that was an option. It's possible that I misunderstood, and they just give you two independent keys.

I think that quiz would like you to buy two of their products, which is a thing you might want to do (I'd suggest maybe one of theirs and one from a rival, but they're not going to suggest that) but it is not implying those keys are identical inside, they are as you say "independent keys".

So you'd register both keys. Or if you own more, you'd register at least two of them and at least one stays somewhere safe (but like, not in a bank safety deposit box, maybe the sort of place you keep a passport). This way, when inevitably your toddler throws mummy's key ring into a fast moving river, it's just very inconvenient and doesn't ruin your whole year. After you call somebody to bring a spare car key, and ask the toddler to think about what they did, go revoke all those now useless keys and order a new FIDO authenticator.

Edited to add: Even if they started identical you can reset any Yubikey, making the keys inside it random - and very paranoid people might want to before using it, since you don't know what happened to the keys inside it before you got it.

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#84

Post by kevdev »

georgyo wrote: post #62
nickray wrote: post #56

Earlier quoted context omitted.

We hope and think that PIV can replace all the practical use cases for PGP. Specifically among those mentioned, `age` for file encryption, and either FIDO resident keys with hmac-secret for password managers, or something like `passage` (fork of `pass` using, again, `age` for encryption). For SSH you can use FIDO for newer OpenSSH, and either `pivy` or `yubikey-agent` via PIV. Cheers!

What about code signing? People like to dislike PGP and replace it with a myriad of different solutions. But PGP is everywhere and awesome. It's very wide spread adoption is invaluable. I really don't want to see it replaced with zillions of different bespoke solutions.

This. I’m a backer for their Kickstarter but the lack of PGP is unfortunate. Yes, there are problems with it. But as you said, it’s everywhere. It’s not going anywhere anytime soon, so what’s the harm in supporting it for now?

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#85

Post by ohazi »

IgorPartola wrote: post #75
ohazi wrote: post #8

Earlier quoted context omitted.

FWIW, their choice of microcontroller (LPC55s, which is a Cortex-M33 w/ crypto peripherals and TrustZone) doesn't seem completely terrible. There's still a lot of things that need to go right for the whole system to be secure, but "everything happens inside one chip, and we cover it in epoxy" seems pretty reasonable. If you can get rid of the epoxy, the only tampering I'd be worried about is removing capacitors for p…

What would be your choice of microcontroller?

I don't actually think it's a bad choice... but that may say more about the state of what's available than about this particular chip.

The Cortex-M version of TrustZone is still fairly new, and these M33 devices are some of the first that implement it. You need a lot of care to use it correctly, but it has the potential to reduce the attack surface significantly. Crypto operations and key memory can live in the trusted world, while things like the USB stack can live in the non-trusted world.

If you really wanted a die shield, Maxim makes a line of "DeepCover" secure microcontrollers (Cortex-M3/M4, no TrustZone) that might fit the bill. They also have tamper pins for driving an external shield (e.g. https://www.edn.com/wp-content/uploads/media-1203638-p118fig...). You could do something like that and then fill the void with epoxy. External shields can be somewhat useful if your device stores keys in battery backed RAM (e.g. ATMs, POS terminals), because the shield remains active even when the device is off (if the shield is ever de-energized, the keys are wiped). USB security tokens typically store keys in (encrypted) flash, and don't have a battery, so you can take all the time you want grinding off the shield while the token is off, and then just short the right pins together before you power it up again.

ARM has a Cortex-M35P design that has TrustZone as well as some more advanced physical security features, but as far as I'm aware, nobody is selling one yet.

Downsides across the board:

Both ARM and silicon manufacturers are cagey about releasing any information about their security products. Most require NDAs before they'll even tell you what's in these chips, let alone how to use them, or how they work. I've worked with a few, and most of them have had some pretty scary bugs. They're worried that if they released the chip errata publicly, nobody would buy their chips. That's probably fair, but it also leaves you (understandably) less than confident that anyone has ever implemented a hardware crypto accelerator correctly.

Trusted execution contexts and memory protection seems like a good idea in theory, but I'm worried about all the complexity we're adding to these little chips. To lock the thing down, you have to pour over a thousand page datasheet and disable all of the debug interfaces you find, and enable all of the protection features that you find. If you're being thorough, you might write some little test programs to confirm that you at least can't use the easy methods to access things that should be protected. But at the end of the day you're crossing your fingers and hoping that there isn't a giant gaping hole off to the side that you forgot about. Reference software for these platforms is often crap.

¯\_(ツ)_/¯

I do have high hopes for this chip though... Apparently Oxide is also using it and has been sharing notes with SoloKeys (https://twitter.com/kc8apf/status/1360415931940302850). I think they'll get there eventually, but I think it'll be a while before we can be confident that it works correctly and that nothing obvious was missed.

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#86

Post by tialaramex »

smichel17 wrote: post #49
kelnos wrote: post #31

Earlier quoted context omitted.

Others have answered most of your questions, but there's something I think deserves emphasizing: In general, you cannot (by design) back up these devices; if you could, that would defeat a lot of the security they provide. That means that if you lose it, you will have to find a way to get 2FA disabled for each and every account you enabled it for. Some orgs will have pretty onerous (but necessary!) processes for doin…

> But many sites only allow a single device to be enrolled. Ugh, I hate these. I want to use u2f, but I am not willing to risk being locked out of my account if I lose the key. So I only enable it if there is some other 2fa I can enable (either adding a second key or totp).

Most sites which offer U2F (or WebAuthn, which is what they ought to be doing for new sites) have a last ditch "Write down this huge random string" way back in. If you're the sort of person who'd hate to lose an account (seems like you are) then you should definitely write that down, and keep it somewhere damn safe.

But, as I wrote elsewhere in this thread, the only site I'm aware of that forbids multiple Authenticators (Security Keys) is AWS. And to be fair, AWS accounts are multi-user. If Bob loses his Security Key and Bob was your only admin, the biggest mistake wasn't AWS forbidding Bob from having two keys (though I agree that's bad) it's you not assigning another admin. Jim, the company secretary, may not know a t2.nano from m4.xlarge but he can keep a Security Key in his desk drawer and never give it to anybody unless the Big Boss authorises it.

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#87

Post by ahnick »

kelnos wrote: post #81
ahnick wrote: post #42

Earlier quoted context omitted.

Some devices derive their keys from a recovery seed that you can store offline in paper form. The benefit of this approach is that you can recreate the key on a backup device using the recovery seed, should you lose your primary.

Ah, neat, so basically the recovery seed would let you buy a new device and then use it to "clone" your old one? Definitely useful in case you lose it or it gets stolen, but you'd end up wanting to rotate to a new key with fresh seeds anyway, since the old key could be in the hands of an attacker. I guess this is still useful in the case where you don't lose the old key, but instead damage or destroy it by accident.

Yes, exactly. If you lose it or it's stolen, then you'd want to rotate to a new key quickly. Some of these devices have a pin too, so the attacker needs to crack the pin before they can actually use the device. This should hopefully buy you enough time to bring up a new device and switch over accounts. That's why it's probably a good idea to buy your second device when you buy your first one and store it in a separate, reasonably secure, but more importantly, quickly accessible, location.

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#88

Post by rlctntpgpusr »

nickray wrote: post #56
_abox wrote: post #46

Nice, I'd love this as an open source yubikey replacement. But it doesn't do OpenPGP, I rely on that way too much sadly. Not just for SSH which supports fido2 now but also for file encryption and my password manager. If they add that in the future I might jump ship.

We hope and think that PIV can replace all the practical use cases for PGP. Specifically among those mentioned, `age` for file encryption, and either FIDO resident keys with hmac-secret for password managers, or something like `passage` (fork of `pass` using, again, `age` for encryption). For SSH you can use FIDO for newer OpenSSH, and either `pivy` or `yubikey-agent` via PIV. Cheers!

As a reluctant PGP user who has backed Solo Keys v2 for 4+ for personal use, and who has written Rust code in the pursuit of using PIV over OpenPGP, this answer is disappointing.

Age isn't there. It does NOT have good (read, right now, really, any) support for hardware tokens. I'm skeptical of what I've seen. And age still punts on authentication. And PIV still doesn't have decent keys at decent sizes standardized and thus is awkward to use in practice.

I'm really not convinced, and I really want to be. I wrote a bunch of forward-looking Rust, and then permanently backburner-ed it because age/yubikey just isn't there yet.

Using FIDO2 for SSH, when you're used to the portability and versatility of OpenPGP, stinks. I can use my Yubikey perfectly to do SSH and GPG in Windows. I can forward SSH agent and GPG from Windows to Linux such that it is identical in functionality to me sitting in front of my actual Linux box with my Yubikey plugged in. I have never seen that done with PIV.

I have this extreme fear that I'm going to wind up with four solokeysv2 that just sit in a drawer.

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#89

Post by mkj »

stouset wrote: post #39
kelnos wrote: post #31

Earlier quoted context omitted.

Others have answered most of your questions, but there's something I think deserves emphasizing: In general, you cannot (by design) back up these devices; if you could, that would defeat a lot of the security they provide. That means that if you lose it, you will have to find a way to get 2FA disabled for each and every account you enabled it for. Some orgs will have pretty onerous (but necessary!) processes for doin…

> Some (like Yubico) let you purchase a "cloned" set of devices Wait, they do? How? I would love to do this, but I can't find anything relevant on their website.

I assume the solokey generates its master key on-device. Seems like it wouldn't be too hard for it to perform Diffie Hellman key exchange with another device to get a shared secret (at first setup) then they could be a cloned pair.

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#90

Post by schrodingersket »

xur17 wrote: post #20
Groxx wrote: post #19

Earlier quoted context omitted.

> - The ideal backup for this is to have a separate key, both authorized. This in particular is important. Security is only as strong as your weakest link, so any backup methods (e.g. "forgot password" flows) might as well be your primary method, if you actually care to strongly secure things. Adding another (or more) key gets you same-security redundancy if one fails or is lost. Nothing else will achieve this. Degra…

This is one thing I hate about these keys though - some services only support one key, and for ones that support multiple, I struggle to figure out a storage system for my backup key. I don't want to keep it with me (because then I am at risk of losing both), but if I keep it separate, I need to remember to add it to new accounts - there's no way to see a list of accounts a key has been associated with. I'm curious h…

I keep one of my keys in a fireproof safe at home, and the other on my keychain as my daily driver. If a site allows me to enroll multiple U2F keys, I just bring the backup to work (my home office, currently) with me the next day and enroll it then. For sites that only allow a single key (looking at you, AWS), I will usually enroll the key I have on me, and then when I have both, I write the same TOTP seed to both keys (usually by scanning the QR code with each key plugged into my phone before entering the one-time code used to verify and finalize TOTP enrollment) and use that instead so that there's effectively a TOTP duplicate.

This gives me a pretty convenient list of sites I've set up the Yubikey with (at least for TOTP), since Yubico's OTP app lists all the sites I've used it for.

If a site only allows a single U2F key to be registered, I'd rather have a backup with TOTP over the better security of a single U2F key, so this arrangement works reasonably well for me.

Post reply on HN