15 ms·

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

396 points by conorpp 6y ago

Foxboron 6y ago
I'm still curious how the key is tamper resistent when filling it with transparent epoxy. I asked when the article was published on lobste.rs but never got an answer. It seems to me it should be fairly easy to remove the epoxy and refill after tampering. I should probably email them about this at this point, but I think it's weird they haven't explained the "tampering resistent" part in their marketing material in any detail.
- zie 6y ago
  AIUI, Tamper Resistant doesn't mean it's not possible to do, but that it will likely be obvious that tampering was done.
  - Foxboron 6y ago
    Then it would be tamper evident, not resistent?
    - smnrchrds 6y ago
      Water resistant means some resistance to water. Water proof means full resistance to water. And that is a standard term that has been in use for decades to describe watches, tents, jackets, etc. When I read tamper resistant, I imagine the tamper equivalent of water resistant.
    - AmericanChopper 6y ago
      Tamper evident is the correct description of what the parent comment is talking about. You can Google “tamper evident stickers” to see it’s how the phrase is widely used. I would say the epoxy in question is both tamper resistant and evident though. Because it’s both difficult to remove and you’d risk breaking the device if you tried it, and those seem like obvious tamper resistance controls to me.
      - zie 6y ago
        Yes, 2 birds, 1 stone.
    - deleted 6y ago
      [deleted]
- conorpp 6y ago
  The epoxy can't be physically removed without great risk of ripping off the electronics on the underlying circuit. The epoxy can be chemically dissolved, but would deteriorate the outside of the device as well. It the epoxy isn't completely cleaned out, then refilling it with new epoxy would look messy. With great care and skill, it could be done with little damage, but would be time consuming.
- ohazi 6y ago
  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 power supply glitching. Power analysis can still be done on an uncompromised device via the USB port (capacitors will make this harder, but may not rule it out). To go beyond this, you'd probably need to decap the chip. I haven't seen anything about an active die shield in the documentation for this chip, but we're now well beyond the scope of epoxy tamper resistance. Edit: No die shield, but apparently "cryptographically sensitive" signals and bits have additional out-of-band signals and bits to make shenanigans more difficult. Certainly not perfect, but "not completely terrible" seems like a fair assessment.
  - IgorPartola 6y ago
    What would be your choice of microcontroller?
    - ohazi 6y ago
      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-p118figure-6.jpg 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 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.
- g_p 6y ago
  It's a good question, and I believe they mean in terms of the epoxy making it harder to get easy access to the chip to do any shenanigans. It's worth remembering the threat model for U2F tokens (let's set aside PIV, FIDO2, etc for the moment) - if the attacker has physical possession then they're into your account. Game over. As the authentication is to tap the button. Sure you can add PIN via FIDO2 (then these protections make more sense), but I can't see any particular threat whereby you would be concerned about this threat under normal circumstances. U2F helps normal (and expert) users resist phishing attacks, credential relaying, and avoid keyloggers etc. It doesn't protect you against in-person physical adversaries who can steal your things, or take them against your will. The only edge case I can see where this matters more is if a user leaves the token unattended (try not to! Put it on your keyring, though admittedly your backup token probably is at risk a little here) and an attacker can covertly extract the keys and leave it as found, such that the user is unaware. But at that point you are dealing with adversaries in the real world, and most users have already lost at that point (passwords written down, etc.)
- notatoad 6y ago
  have you ever tried to remove epoxy from a PCB? it's definitely possible, but it's annoying and makes a mess. i'm not sure how you'd remove epoxy without it being blindingly obvious that the epoxy had been removed and replaced. they're claiming tamper-resistant, not tamper-proof. and counting on the epoxy for that seems reasonable to me.
- chaz6 6y ago
  My biggest concern is that the key's software is updatable. I would have preferred to have an efuse I could blow to make the keys completely read-only.
leafmeal 6y ago
How does this compare to a Yubikey for example?
- _underfl0w_ 6y ago
  The hardware is open-source, you can theoretically update the firmware so you're not vulnerable if a researcher finds a bug after your purchase, there's currently no support for getting it to act as a keyboard and type the password for you AFAICT, to name a few.
  - ericseppanen 6y ago
    I don't think this is true in the general case. Most Solokeys come in a "locked" form-- they will only accept firmware updates that are signed by the manufacturer. You can buy a "hacker" variant that is unlocked (meant for those that want to tinker with the firmware), but if you were to use one of those you're giving up security against someone loading malicious firmware onto your device. This is probably the right tradeoff for most users. Solokeys has done a great job of providing continuous support for all of their products, and their software stack has been open source since the beginning. That (combined with the low price) makes them my first choice for a hardware security token.
    - Dylan16807 6y ago
      > You can buy a "hacker" variant that is unlocked (meant for those that want to tinker with the firmware), but if you were to use one of those you're giving up security against someone loading malicious firmware onto your device. You can't set it to wipe when updated?
      - ericseppanen 6y ago
        I have no firsthand information, but reading https://github.com/solokeys/solo https://github.com/solokeys/solo "Solo Hacker can be converted to a secure version, but normal Solo cannot be converted to a Hacker version."
l0b0 6y ago
As someone who is comfortable with TOTP but hasn't tried FIDO-/Yubikey-style devices, I have a few questions: - Are drivers for this already installed as part of desktop Ubuntu 20.10/Windows 10? Any driver installation will absolutely make this a no-go for family members. - Is additional software required for anything non-techies might reasonably want to do with this device, including resetting it, adding an entry or checking which entries are already on the device? The ideal would probably be if the device acts like a USB stick, with entries being shown as .bin/.txt files which can be manipulated in the normal ways. - How easy is it to create a backup? The ideal (for non-techies) would probably be something like plugging a device into a PC and simply copying files across. Ditto for duplicating to another device. - Is there anything else which would likely stop non-techies from using this for basically everything they care about?
- lvh 6y ago
  Can't speak for this thing specifically, but FIDO2 keys in general: - Yes, you have everything you need on every major OS/browser - These devices are zeroconf; resetting it actually kills a security feature (key use increments) aiming at cloned devices - The ideal backup for this is to have a separate key, both authorized. They don't need to have the same material, in fact, cloning it would be considered a weakness (how do you know someone hasn't cloned it without your knowledge?)
  - Groxx 6y ago
    >- 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. Degrading to "forgot password" may be entirely fine for [person's] use of a security key, but you must be explicit about that decision, or it's mostly security snake-oil.
    - xur17 6y ago
thinkmassive 6y ago
"Reversible USB-A" now there's a feature I wish we'd see more often!
- anonisko 6y ago
  Would have been nice to be common before USB-C started becoming standard...
notatoad 6y ago
am i reading their marketing stuff correctly that this doesn't include any new fido-protocol features vs the solo key v1? that is, as far as chrome sees it, it might as well be the same product?
- nickray 6y ago
  Website can distinguish via the optional attestation key. In terms of features, CTAP v2.1 (https://fidoalliance.org/specs/fido2/ https://fidoalliance.org/specs/fido2/) is still draft only, but yes both v1 and v2 keys support hmac-secret and credential management. We could add authnSelection and authnConfig, but not clear if any browsers actually implement/use it. The major new feature is PIV.
GekkePrutser 6y ago
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.
- fsflover 6y ago
  Librem Key can do OpenPGP and uses FLOSS: https://puri.sm/posts/introducing-the-librem-key/ https://puri.sm/posts/introducing-the-librem-key/
  - ptman 6y ago
    Librem Key is just a branded Nitrokey https://www.nitrokey.com/news/2018/nitrokey-partners-purism-build-librem-key https://www.nitrokey.com/news/2018/nitrokey-partners-purism-...
- nickray 6y ago
  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!
  - georgyo 6y ago
    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.
    - tadfisher 6y ago
      Yep! It's magical having everything signed automatically by plugging in my Yubikey and setting some git config once. I will not go to something that doesn't enable this.
t0astbread 6y ago
As someone who's not familiar with U2F or comparable standards I have a general question about the topic: When registering a key for multiple accounts (at the same site or at different sites) can website owners link those accounts by some common "key ID"? In the sense of: "Oh, this is Bob's key so this account must belong to Bob".
- mightybyte 6y ago
  I think that would be the public key. You can roughly think of it as the hardware key has a private key embedded in it in a way that it (supposedly) can't be gotten off. That private key has a corresponding public key. You can think of the private key as the password and the public key as the username. So I think the public key is the "key ID" you're looking for.
  - sneak 6y ago
    This is not how U2F works. The sites never see the device's long-term public key.
- nickray 6y ago
  No, they cannot. This is an explicit design goal of FIDO (https://fidoalliance.org/specs/fido-security-requirements/fido-authenticator-security-requirements-v1.4-fd-20201102.html#privacy https://fidoalliance.org/specs/fido-security-requirements/fi...). The actual public key used for logging in to a specific site is completely random. Optionally, the website can ask for "attestation", which is intended to prove that the public key is from a specific vendor/model. To make this also unlinkable, devices are supposed to share attestation keys in batches of 100k units.
  - pstrateman 6y ago
    I think he's asking about have two accounts on the same website. I'm not so sure they cannot associate.
  - t0astbread 6y ago
    Ah, I see! So cross-site (across multiple relying parties) linking is prevented but if I have multiple accounts within one relying party they can be linked?
eeZah7Ux 6y ago
Reminder: FIDO2 is mostly useless if your browser or your OS is compromised. Also if someone hijacks your account using bruteforced recovery codes and/or email. Also if the servers are compromised or account data leaked. In short, it protects from some forms of phishing. (I'm not trying to criticize FIDO2, just pointing out what to expect from it)
- dhdhhdd 6y ago
  Otoh if your browser/os is not compromised, it's safer than authentication code and SMS OTP. And hopefully recovery codes have maximum retry count?
  - eeZah7Ux 6y ago
    > Otoh if your browser/os is not compromised, it's safer than authentication code and SMS OTP. ...but less safe than an external token if someone steals your laptop with the FIDO2 key in the USB port. Yet, this are really very minor improvements to the (sorry) state of web and desktop security.
- eeZah7Ux 6y ago
  A good bunch of downvotes for this? Congratulations HN crowd.
65a 6y ago
I'm really hoping they bring GPG to the Solokey V1, but I'm starting to lose confidence
- ibotty 6y ago
  https://github.com/solokeys/kickstarter2021/discussions/26#discussioncomment-319155 https://github.com/solokeys/kickstarter2021/discussions/26#d... TLDR: it's not as easy as thought. It will be easier for the new one.
gorgoiler 6y ago
In life, every so often one hears of a concept that is so simple and so elegant that the fact that one had not heard of it before today makes one’s jaw drop in disbelief: > Reversible USB-A. Well this maybe wasn't the most critical feature anyone expected, but, consequence of our new PCB & case combined construction, it was easy to make USB-A reversible. So why not!
- mNovak 6y ago
  I'm more impressed by the cavity PCB construction--fill with epoxy and boom dead simple waterproofing! I've never encountered this before; wonder if it's available with the batch fabs.
  - SecurityLagoon 6y ago
    Pretty common in ruggedized devices. Has the benefit of keeping components stuck down under vibration and tamper evident too.
  - jononor 6y ago
    The technique is called "potting", and is common for small rugged devices. I think nearly all assembly houses will offer it. Some electronics components, such as relays, power converter modules also use it.
  - mastax 6y ago
    The difficult part is the step milling for the cavity. Its unusual so you need to work with the fab to get it right. Bunny Huang had a good post about it.
- JunkDNA 6y ago
  USB remains the only connector I use where I routinely get the orientation wrong 3 times.
- sowbug 6y ago
  This is a good discussion of how it works: https://electronics.stackexchange.com/questions/209941/two-sided-connectorless-usb-on-a-pcb https://electronics.stackexchange.com/questions/209941/two-s...
mNovak 6y ago
Does anyone know if these types of keys and/or protocols can be made to work without a full USB bus? I'd love to have this kind of functionality in embedded systems, without running an OS.
StavrosK 6y ago
This looks great and I'm very excited for it, but it's been "coming soon" for more than a year. The original release date was last June, now it's this June for the first backer keys, AFAIK. I hope it doesn't take that long, but there's a history of delays, unfortunately.
brabel 6y ago
From the founder of Solo, I assume: "I've been working on Solo for almost 3 years now. It started back when I was in college and on a whim, ordered a run of 1000 security keys that I designed and then shipped them all to Amazon. " Hm... not sure I can trust my keys to something developed on a whim by a college student.
- an_ko 6y ago
  Linux was designed on a whim by a college student.
  - petee 6y ago
    But would you have trusted your secrets on a 3yr old linux?
- leipert 6y ago
  That’s why it is open source. Both hardware and software. You should be able to trust it more than some closed source version because you (or someone else) could verify the security more easily.
- baq 6y ago
  I have multiple solo v1s from the first Kickstarter. Still work like a charm. Haven’t used the nfc version.
als0 6y ago
> releases hardware that's open source and uses Rust This is an LPC55S69. So it's open source firmware, not open source hardware.
- smarx007 6y ago
  Arduino is OSHW but its AVR microcontroller isn't, yet we still regard Arduino boards as OSHW. But I see your point that the crucial component of this OSHW key is not OSHW.
- nickray 6y ago
  I see your point too, and we're looking forward to a world in which low-power (to enable NFC) open source chips with security features exist. For instance, https://tropicsquare.com https://tropicsquare.com is a project that is working towards that. For now, what we mean by open source hardware is on the one hand that all components are freely available (without NDAs, which nearly all secure elements entail), and on the other that the schematic of the device is open source and passes OSHWA Certification (the CERN license https://ohwr.org/project/cernohl/wikis/Documents/CERN-OHL-version-2 https://ohwr.org/project/cernohl/wikis/Documents/CERN-OHL-ve... is relevant here). This means that you can in principle build a device yourself. The certification will be done post-campaign (we want to avoid copycat products appearing before ours is available in the open market). Like we did with our three previous keys (e.g., https://certification.oshwa.org/us000155.html https://certification.oshwa.org/us000155.html and https://github.com/solokeys/solo-hw https://github.com/solokeys/solo-hw).
_JamesA_ 6y ago
Is there a Linux compatible NFC reader that would allow a simple tap to authenticate with one of these?

396 points by conorpp 6y ago

I'm still curious how the key is tamper resistent when filling it with transparent epoxy. I asked when the article was published on lobste.rs but never got an answer. It seems to me it should be fairly easy to remove the epoxy and refill after tampering. I should probably email them about this at this point, but I think it's weird they haven't explained the "tampering resistent" part in their marketing material in any detail.

zie 6y ago
AIUI, Tamper Resistant doesn't mean it's not possible to do, but that it will likely be obvious that tampering was done.
- Foxboron 6y ago
  Then it would be tamper evident, not resistent?
  - smnrchrds 6y ago
    Water resistant means some resistance to water. Water proof means full resistance to water. And that is a standard term that has been in use for decades to describe watches, tents, jackets, etc. When I read tamper resistant, I imagine the tamper equivalent of water resistant.
  - AmericanChopper 6y ago
    Tamper evident is the correct description of what the parent comment is talking about. You can Google “tamper evident stickers” to see it’s how the phrase is widely used. I would say the epoxy in question is both tamper resistant and evident though. Because it’s both difficult to remove and you’d risk breaking the device if you tried it, and those seem like obvious tamper resistance controls to me.
    - zie 6y ago
      Yes, 2 birds, 1 stone.
  - deleted 6y ago
    [deleted]
conorpp 6y ago
The epoxy can't be physically removed without great risk of ripping off the electronics on the underlying circuit. The epoxy can be chemically dissolved, but would deteriorate the outside of the device as well. It the epoxy isn't completely cleaned out, then refilling it with new epoxy would look messy. With great care and skill, it could be done with little damage, but would be time consuming.
ohazi 6y ago
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 power supply glitching. Power analysis can still be done on an uncompromised device via the USB port (capacitors will make this harder, but may not rule it out). To go beyond this, you'd probably need to decap the chip. I haven't seen anything about an active die shield in the documentation for this chip, but we're now well beyond the scope of epoxy tamper resistance. Edit: No die shield, but apparently "cryptographically sensitive" signals and bits have additional out-of-band signals and bits to make shenanigans more difficult. Certainly not perfect, but "not completely terrible" seems like a fair assessment.
- IgorPartola 6y ago
  What would be your choice of microcontroller?
  - ohazi 6y ago
    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-p118figure-6.jpg 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 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.
g_p 6y ago
It's a good question, and I believe they mean in terms of the epoxy making it harder to get easy access to the chip to do any shenanigans. It's worth remembering the threat model for U2F tokens (let's set aside PIV, FIDO2, etc for the moment) - if the attacker has physical possession then they're into your account. Game over. As the authentication is to tap the button. Sure you can add PIN via FIDO2 (then these protections make more sense), but I can't see any particular threat whereby you would be concerned about this threat under normal circumstances. U2F helps normal (and expert) users resist phishing attacks, credential relaying, and avoid keyloggers etc. It doesn't protect you against in-person physical adversaries who can steal your things, or take them against your will. The only edge case I can see where this matters more is if a user leaves the token unattended (try not to! Put it on your keyring, though admittedly your backup token probably is at risk a little here) and an attacker can covertly extract the keys and leave it as found, such that the user is unaware. But at that point you are dealing with adversaries in the real world, and most users have already lost at that point (passwords written down, etc.)
notatoad 6y ago
have you ever tried to remove epoxy from a PCB? it's definitely possible, but it's annoying and makes a mess. i'm not sure how you'd remove epoxy without it being blindingly obvious that the epoxy had been removed and replaced. they're claiming tamper-resistant, not tamper-proof. and counting on the epoxy for that seems reasonable to me.
chaz6 6y ago
My biggest concern is that the key's software is updatable. I would have preferred to have an efuse I could blow to make the keys completely read-only.

leafmeal 6y ago

How does this compare to a Yubikey for example?

_underfl0w_ 6y ago
The hardware is open-source, you can theoretically update the firmware so you're not vulnerable if a researcher finds a bug after your purchase, there's currently no support for getting it to act as a keyboard and type the password for you AFAICT, to name a few.
- ericseppanen 6y ago
  I don't think this is true in the general case. Most Solokeys come in a "locked" form-- they will only accept firmware updates that are signed by the manufacturer. You can buy a "hacker" variant that is unlocked (meant for those that want to tinker with the firmware), but if you were to use one of those you're giving up security against someone loading malicious firmware onto your device. This is probably the right tradeoff for most users. Solokeys has done a great job of providing continuous support for all of their products, and their software stack has been open source since the beginning. That (combined with the low price) makes them my first choice for a hardware security token.
  - Dylan16807 6y ago
    > You can buy a "hacker" variant that is unlocked (meant for those that want to tinker with the firmware), but if you were to use one of those you're giving up security against someone loading malicious firmware onto your device. You can't set it to wipe when updated?
    - ericseppanen 6y ago
      I have no firsthand information, but reading https://github.com/solokeys/solo https://github.com/solokeys/solo "Solo Hacker can be converted to a secure version, but normal Solo cannot be converted to a Hacker version."

l0b0 6y ago

As someone who is comfortable with TOTP but hasn't tried FIDO-/Yubikey-style devices, I have a few questions: - Are drivers for this already installed as part of desktop Ubuntu 20.10/Windows 10? Any driver installation will absolutely make this a no-go for family members. - Is additional software required for anything non-techies might reasonably want to do with this device, including resetting it, adding an entry or checking which entries are already on the device? The ideal would probably be if the device acts like a USB stick, with entries being shown as .bin/.txt files which can be manipulated in the normal ways. - How easy is it to create a backup? The ideal (for non-techies) would probably be something like plugging a device into a PC and simply copying files across. Ditto for duplicating to another device. - Is there anything else which would likely stop non-techies from using this for basically everything they care about?

lvh 6y ago
Can't speak for this thing specifically, but FIDO2 keys in general: - Yes, you have everything you need on every major OS/browser - These devices are zeroconf; resetting it actually kills a security feature (key use increments) aiming at cloned devices - The ideal backup for this is to have a separate key, both authorized. They don't need to have the same material, in fact, cloning it would be considered a weakness (how do you know someone hasn't cloned it without your knowledge?)
- Groxx 6y ago
  >- 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. Degrading to "forgot password" may be entirely fine for [person's] use of a security key, but you must be explicit about that decision, or it's mostly security snake-oil.
  - xur17 6y ago

thinkmassive 6y ago

"Reversible USB-A" now there's a feature I wish we'd see more often!

anonisko 6y ago
Would have been nice to be common before USB-C started becoming standard...

notatoad 6y ago

am i reading their marketing stuff correctly that this doesn't include any new fido-protocol features vs the solo key v1? that is, as far as chrome sees it, it might as well be the same product?

nickray 6y ago
Website can distinguish via the optional attestation key. In terms of features, CTAP v2.1 (https://fidoalliance.org/specs/fido2/ https://fidoalliance.org/specs/fido2/) is still draft only, but yes both v1 and v2 keys support hmac-secret and credential management. We could add authnSelection and authnConfig, but not clear if any browsers actually implement/use it. The major new feature is PIV.

GekkePrutser 6y ago

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.

fsflover 6y ago
Librem Key can do OpenPGP and uses FLOSS: https://puri.sm/posts/introducing-the-librem-key/ https://puri.sm/posts/introducing-the-librem-key/
- ptman 6y ago
  Librem Key is just a branded Nitrokey https://www.nitrokey.com/news/2018/nitrokey-partners-purism-build-librem-key https://www.nitrokey.com/news/2018/nitrokey-partners-purism-...
nickray 6y ago
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!
- georgyo 6y ago
  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.
  - tadfisher 6y ago
    Yep! It's magical having everything signed automatically by plugging in my Yubikey and setting some git config once. I will not go to something that doesn't enable this.

t0astbread 6y ago

As someone who's not familiar with U2F or comparable standards I have a general question about the topic: When registering a key for multiple accounts (at the same site or at different sites) can website owners link those accounts by some common "key ID"? In the sense of: "Oh, this is Bob's key so this account must belong to Bob".

mightybyte 6y ago
I think that would be the public key. You can roughly think of it as the hardware key has a private key embedded in it in a way that it (supposedly) can't be gotten off. That private key has a corresponding public key. You can think of the private key as the password and the public key as the username. So I think the public key is the "key ID" you're looking for.
- sneak 6y ago
  This is not how U2F works. The sites never see the device's long-term public key.
nickray 6y ago
No, they cannot. This is an explicit design goal of FIDO (https://fidoalliance.org/specs/fido-security-requirements/fido-authenticator-security-requirements-v1.4-fd-20201102.html#privacy https://fidoalliance.org/specs/fido-security-requirements/fi...). The actual public key used for logging in to a specific site is completely random. Optionally, the website can ask for "attestation", which is intended to prove that the public key is from a specific vendor/model. To make this also unlinkable, devices are supposed to share attestation keys in batches of 100k units.
- pstrateman 6y ago
  I think he's asking about have two accounts on the same website. I'm not so sure they cannot associate.
- t0astbread 6y ago
  Ah, I see! So cross-site (across multiple relying parties) linking is prevented but if I have multiple accounts within one relying party they can be linked?

eeZah7Ux 6y ago

Reminder: FIDO2 is mostly useless if your browser or your OS is compromised. Also if someone hijacks your account using bruteforced recovery codes and/or email. Also if the servers are compromised or account data leaked. In short, it protects from some forms of phishing. (I'm not trying to criticize FIDO2, just pointing out what to expect from it)

dhdhhdd 6y ago
Otoh if your browser/os is not compromised, it's safer than authentication code and SMS OTP. And hopefully recovery codes have maximum retry count?
- eeZah7Ux 6y ago
  > Otoh if your browser/os is not compromised, it's safer than authentication code and SMS OTP. ...but less safe than an external token if someone steals your laptop with the FIDO2 key in the USB port. Yet, this are really very minor improvements to the (sorry) state of web and desktop security.
eeZah7Ux 6y ago
A good bunch of downvotes for this? Congratulations HN crowd.

65a 6y ago

I'm really hoping they bring GPG to the Solokey V1, but I'm starting to lose confidence

ibotty 6y ago
https://github.com/solokeys/kickstarter2021/discussions/26#discussioncomment-319155 https://github.com/solokeys/kickstarter2021/discussions/26#d... TLDR: it's not as easy as thought. It will be easier for the new one.

gorgoiler 6y ago

In life, every so often one hears of a concept that is so simple and so elegant that the fact that one had not heard of it before today makes one’s jaw drop in disbelief: > Reversible USB-A. Well this maybe wasn't the most critical feature anyone expected, but, consequence of our new PCB & case combined construction, it was easy to make USB-A reversible. So why not!

mNovak 6y ago
I'm more impressed by the cavity PCB construction--fill with epoxy and boom dead simple waterproofing! I've never encountered this before; wonder if it's available with the batch fabs.
- SecurityLagoon 6y ago
  Pretty common in ruggedized devices. Has the benefit of keeping components stuck down under vibration and tamper evident too.
- jononor 6y ago
  The technique is called "potting", and is common for small rugged devices. I think nearly all assembly houses will offer it. Some electronics components, such as relays, power converter modules also use it.
- mastax 6y ago
  The difficult part is the step milling for the cavity. Its unusual so you need to work with the fab to get it right. Bunny Huang had a good post about it.
JunkDNA 6y ago
USB remains the only connector I use where I routinely get the orientation wrong 3 times.
sowbug 6y ago
This is a good discussion of how it works: https://electronics.stackexchange.com/questions/209941/two-sided-connectorless-usb-on-a-pcb https://electronics.stackexchange.com/questions/209941/two-s...

mNovak 6y ago

Does anyone know if these types of keys and/or protocols can be made to work without a full USB bus? I'd love to have this kind of functionality in embedded systems, without running an OS.

StavrosK 6y ago

This looks great and I'm very excited for it, but it's been "coming soon" for more than a year. The original release date was last June, now it's this June for the first backer keys, AFAIK. I hope it doesn't take that long, but there's a history of delays, unfortunately.

brabel 6y ago

From the founder of Solo, I assume: "I've been working on Solo for almost 3 years now. It started back when I was in college and on a whim, ordered a run of 1000 security keys that I designed and then shipped them all to Amazon. " Hm... not sure I can trust my keys to something developed on a whim by a college student.

an_ko 6y ago
Linux was designed on a whim by a college student.
- petee 6y ago
  But would you have trusted your secrets on a 3yr old linux?
leipert 6y ago
That’s why it is open source. Both hardware and software. You should be able to trust it more than some closed source version because you (or someone else) could verify the security more easily.
baq 6y ago
I have multiple solo v1s from the first Kickstarter. Still work like a charm. Haven’t used the nfc version.

als0 6y ago

> releases hardware that's open source and uses Rust This is an LPC55S69. So it's open source firmware, not open source hardware.

smarx007 6y ago
Arduino is OSHW but its AVR microcontroller isn't, yet we still regard Arduino boards as OSHW. But I see your point that the crucial component of this OSHW key is not OSHW.
nickray 6y ago
I see your point too, and we're looking forward to a world in which low-power (to enable NFC) open source chips with security features exist. For instance, https://tropicsquare.com https://tropicsquare.com is a project that is working towards that. For now, what we mean by open source hardware is on the one hand that all components are freely available (without NDAs, which nearly all secure elements entail), and on the other that the schematic of the device is open source and passes OSHWA Certification (the CERN license https://ohwr.org/project/cernohl/wikis/Documents/CERN-OHL-version-2 https://ohwr.org/project/cernohl/wikis/Documents/CERN-OHL-ve... is relevant here). This means that you can in principle build a device yourself. The certification will be done post-campaign (we want to avoid copycat products appearing before ours is available in the open market). Like we did with our three previous keys (e.g., https://certification.oshwa.org/us000155.html https://certification.oshwa.org/us000155.html and https://github.com/solokeys/solo-hw https://github.com/solokeys/solo-hw).

_JamesA_ 6y ago

Is there a Linux compatible NFC reader that would allow a simple tap to authenticate with one of these?