9 ms·

Show HN: Solo, open source FIDO2 security key

98 points by ecesena 8y ago

ecesena 8y ago
We open sourced the firmware. To our knowledge this is the 1st open source implementation of FIDO2/CTAP2. Our firmware is designed to be run/developed without hardware, and we have implementations already for efm32 and nrf52840. We're actively working on a new port to SAM L11 that will use ARM TrustZone for improved security. There's still a lot to do on the ecosystem side. We'd like to improve tests, code style and comments, and make it pass some static analysis tools. Feel free to join the discussions in the github issues, and of course we'd love to see you at our Kickstarter that will launch VERY soon (like in the next couple weeks). You can join the waitlist at https://solokeys.com https://solokeys.com
- lysp 8y ago
  I'm not from America, can you please explain what "early Fall" means? Changing the website to an approximate month or a quarter would be fantastic for those of us not from that side of the world.
  - jtr_47 8y ago
    Early fall should be around end of September - through October
    - lysp 8y ago
      Many thanks!
    - ecesena 8y ago
      Yes. We're still defining the exact date, but it should be within the next two weeks. We're working on some really exciting partnerships, we need a few more days to finalize details. So far we're super excited about how the campaign is coming up!
- linuxdude314 8y ago
  Has it been cross compiled for Tomu.im ?
  - ecesena 8y ago
    Not that I'm aware of. Might be trickier than U2F (that exists already) because FIDO2 is a bit more computationally expensive, and probably larger code base. But certainly an interesting project to add to the pipeline.
  - conorpp 8y ago
    Tomu, being a ARM M0 core, might take some time to compute ECC signatures, but it is probably fine in practice. Our code is designed to be small and portable, so I think it could easily be run on the Tomu. Just need some work to change the USB drivers stuff.
- nickik 8y ago
  Would be really great to have it on the upcoming RISC-V secure hardware, that should be released soon. Then we would have open hardware implementation of this on a open application core as well. Thank you so much for open sourcing this!
  - ecesena 8y ago
    Are you involved in any ways? Do you know if there are developer previews available?
    - nickik 8y ago
      Not really involved. Just fascinated. I don't know of that actually happening officially but probably you can. See: https://keystone-enclave.org/ https://keystone-enclave.org/ MIT worked before on Sanctum that you might want to look at, its sort of the pre-version of what keystone will be. See: https://eprint.iacr.org/2015/564.pdf https://eprint.iacr.org/2015/564.pdf
deleted 8y ago
[deleted]
ohazi 8y ago
I didn't see any schematics, but maybe I just missed them. The SAM L11 doesn't have a USB peripheral... are you bit-banging USB or using a second IC or something? I was considering using an L10/L11 for another project, but this omission is what led me elsewhere. Edit: Thinking about it some more, it may be advantageous to rely on a second, physically separate chip to handle USB communication, as it's next to impossible to verify that there isn't a backdoor in the secure chip. Chips that are likely to be used as secure elements are probably juicy targets for backdoors, and a USB peripheral would be an excellent place to hide one (e.g. a special "knock" code that dumps the contents of secure memory and resets the chip and is unlikely to be found via fuzz testing). I really like the concept, though. I think we need more efforts like this, aimed at making our security tools simpler, more open, and easier to verify.
- hoos97 8y ago
  Part of the value in the concept is the simplicity.
- conorpp 8y ago
  We are using the EFM8UB1 chip to implement the USB HID interface, then communicate with the SAM L11 via SPI. After considering many MCUs with USB interfaces, it seems to always be more cost effective to get the non-USB MCU and use the EFM8UB1 (from a BOM perspective anyways). The lesser chance of having a backdoor is a plus! Here's our schematic: https://i.imgur.com/sVQ34em.pnghttps://i.imgur.com/sVQ34em.png https://i.imgur.com/sVQ34em.pnghttps://i.imgur.com/sVQ34em.p... Still have to document this better on Github :)
  - craftyguy 8y ago
    Thank you(!!!!) for releasing the schematic!
jaytaylor 8y ago
Same comment as on the other MFA key story on the front page right now[0]: Sad that the form factor looks terrible compared to YubiKey Nano. It'd be really cool to have an "open" solution which comes in a minimally invasive package. For reference: https://i1.wp.com/vaultumllc.com/wp-content/uploads/2017/03/YubiKey-4-Nano-In-Use-1.png?fit=1200%2C800&ssl=1 https://i1.wp.com/vaultumllc.com/wp-content/uploads/2017/03/... [0] https://news.ycombinator.com/item?id=18036336 https://news.ycombinator.com/item?id=18036336
- ecesena 8y ago
  Maybe the Tomu discussed in another comment here would be a good starting point. We're really focused on the Kickstarter now, so unlikely we'll have time to do it ourselves in the next, say, month or two. But the code is open now :) I personally use a Nano, but only for limited use cases like VPN. I don't like it for web access to Google/Facebook/Github simply because it feels like someone else could get access to it easily. Of course it's more like a feeling than a real threat. It'd be interesting to see some numbers on sales, to see if it's worth from a business perspective. Edit: grammar
- zaarn 8y ago
  If you get an ECAD/EDA tool you could do some work to reduce the size of the board. From what it looks like, you can squish things together by a lot still and replacing components could further reduce it. Though it's unlikely you'll be able to match the Yubi Nano easily unless you go for some expensive decisions (expensive unless you get a couple thousand keys).
  - conorpp 8y ago
    I think if we had a single chip solution, we could make it work, but since we're using 2 chips, it would be tight. I posted schematic in other comments. Maybe one "affordable" idea could be to stack 2 two-layer PCBs XD.
- conorpp 8y ago
  We'd love to make something small like the Yubikey Nano! Right now it'd be a bit tough, because to fit our chipset [1] in that tight space, it would likely involve making a custom IC package [2] or placing silicon die's directly on the circuit. I think it'd be really cool to do that, and if we get enough sales/interesting, we'll definitely go that route. Using something like the Tomu seems promising as well. It doesn't have the same security features and is just an M0 core, so it's not the best fit. [1] https://i.imgur.com/sVQ34em.pnghttps://i.imgur.com/sVQ34em.png https://i.imgur.com/sVQ34em.pnghttps://i.imgur.com/sVQ34em.p... [2] http://www.icproto.com/ http://www.icproto.com/
mtgx 8y ago
As always with open source projects, it might be a good idea to move it away from GitHub?
- underko 8y ago
  > As always with open source projects, it might be a good idea to move it away from GitHub? Could you please elaborate on to why?
zaarn 8y ago
>Extensions can be added to FIDO2/U2F to support things like SSH, GPG, and cryptocurrency. That would be quite awesome, consider me sold on this. Having a fully self-buildable and OSS Yubikey alternative would be very amazing indeed.

98 points by ecesena 8y ago

We open sourced the firmware. To our knowledge this is the 1st open source implementation of FIDO2/CTAP2. Our firmware is designed to be run/developed without hardware, and we have implementations already for efm32 and nrf52840. We're actively working on a new port to SAM L11 that will use ARM TrustZone for improved security. There's still a lot to do on the ecosystem side. We'd like to improve tests, code style and comments, and make it pass some static analysis tools. Feel free to join the discussions in the github issues, and of course we'd love to see you at our Kickstarter that will launch VERY soon (like in the next couple weeks). You can join the waitlist at https://solokeys.com https://solokeys.com

lysp 8y ago
I'm not from America, can you please explain what "early Fall" means? Changing the website to an approximate month or a quarter would be fantastic for those of us not from that side of the world.
- jtr_47 8y ago
  Early fall should be around end of September - through October
  - lysp 8y ago
    Many thanks!
  - ecesena 8y ago
    Yes. We're still defining the exact date, but it should be within the next two weeks. We're working on some really exciting partnerships, we need a few more days to finalize details. So far we're super excited about how the campaign is coming up!
linuxdude314 8y ago
Has it been cross compiled for Tomu.im ?
- ecesena 8y ago
  Not that I'm aware of. Might be trickier than U2F (that exists already) because FIDO2 is a bit more computationally expensive, and probably larger code base. But certainly an interesting project to add to the pipeline.
- conorpp 8y ago
  Tomu, being a ARM M0 core, might take some time to compute ECC signatures, but it is probably fine in practice. Our code is designed to be small and portable, so I think it could easily be run on the Tomu. Just need some work to change the USB drivers stuff.
nickik 8y ago
Would be really great to have it on the upcoming RISC-V secure hardware, that should be released soon. Then we would have open hardware implementation of this on a open application core as well. Thank you so much for open sourcing this!
- ecesena 8y ago
  Are you involved in any ways? Do you know if there are developer previews available?
  - nickik 8y ago
    Not really involved. Just fascinated. I don't know of that actually happening officially but probably you can. See: https://keystone-enclave.org/ https://keystone-enclave.org/ MIT worked before on Sanctum that you might want to look at, its sort of the pre-version of what keystone will be. See: https://eprint.iacr.org/2015/564.pdf https://eprint.iacr.org/2015/564.pdf

deleted 8y ago

[deleted]

ohazi 8y ago

I didn't see any schematics, but maybe I just missed them. The SAM L11 doesn't have a USB peripheral... are you bit-banging USB or using a second IC or something? I was considering using an L10/L11 for another project, but this omission is what led me elsewhere. Edit: Thinking about it some more, it may be advantageous to rely on a second, physically separate chip to handle USB communication, as it's next to impossible to verify that there isn't a backdoor in the secure chip. Chips that are likely to be used as secure elements are probably juicy targets for backdoors, and a USB peripheral would be an excellent place to hide one (e.g. a special "knock" code that dumps the contents of secure memory and resets the chip and is unlikely to be found via fuzz testing). I really like the concept, though. I think we need more efforts like this, aimed at making our security tools simpler, more open, and easier to verify.

hoos97 8y ago
Part of the value in the concept is the simplicity.
conorpp 8y ago
We are using the EFM8UB1 chip to implement the USB HID interface, then communicate with the SAM L11 via SPI. After considering many MCUs with USB interfaces, it seems to always be more cost effective to get the non-USB MCU and use the EFM8UB1 (from a BOM perspective anyways). The lesser chance of having a backdoor is a plus! Here's our schematic: https://i.imgur.com/sVQ34em.pnghttps://i.imgur.com/sVQ34em.png https://i.imgur.com/sVQ34em.pnghttps://i.imgur.com/sVQ34em.p... Still have to document this better on Github :)
- craftyguy 8y ago
  Thank you(!!!!) for releasing the schematic!

jaytaylor 8y ago

Same comment as on the other MFA key story on the front page right now[0]: Sad that the form factor looks terrible compared to YubiKey Nano. It'd be really cool to have an "open" solution which comes in a minimally invasive package. For reference: https://i1.wp.com/vaultumllc.com/wp-content/uploads/2017/03/YubiKey-4-Nano-In-Use-1.png?fit=1200%2C800&ssl=1 https://i1.wp.com/vaultumllc.com/wp-content/uploads/2017/03/... [0] https://news.ycombinator.com/item?id=18036336 https://news.ycombinator.com/item?id=18036336

ecesena 8y ago
Maybe the Tomu discussed in another comment here would be a good starting point. We're really focused on the Kickstarter now, so unlikely we'll have time to do it ourselves in the next, say, month or two. But the code is open now :) I personally use a Nano, but only for limited use cases like VPN. I don't like it for web access to Google/Facebook/Github simply because it feels like someone else could get access to it easily. Of course it's more like a feeling than a real threat. It'd be interesting to see some numbers on sales, to see if it's worth from a business perspective. Edit: grammar
zaarn 8y ago
If you get an ECAD/EDA tool you could do some work to reduce the size of the board. From what it looks like, you can squish things together by a lot still and replacing components could further reduce it. Though it's unlikely you'll be able to match the Yubi Nano easily unless you go for some expensive decisions (expensive unless you get a couple thousand keys).
- conorpp 8y ago
  I think if we had a single chip solution, we could make it work, but since we're using 2 chips, it would be tight. I posted schematic in other comments. Maybe one "affordable" idea could be to stack 2 two-layer PCBs XD.
conorpp 8y ago
We'd love to make something small like the Yubikey Nano! Right now it'd be a bit tough, because to fit our chipset [1] in that tight space, it would likely involve making a custom IC package [2] or placing silicon die's directly on the circuit. I think it'd be really cool to do that, and if we get enough sales/interesting, we'll definitely go that route. Using something like the Tomu seems promising as well. It doesn't have the same security features and is just an M0 core, so it's not the best fit. [1] https://i.imgur.com/sVQ34em.pnghttps://i.imgur.com/sVQ34em.png https://i.imgur.com/sVQ34em.pnghttps://i.imgur.com/sVQ34em.p... [2] http://www.icproto.com/ http://www.icproto.com/

mtgx 8y ago

As always with open source projects, it might be a good idea to move it away from GitHub?

underko 8y ago
> As always with open source projects, it might be a good idea to move it away from GitHub? Could you please elaborate on to why?

zaarn 8y ago

>Extensions can be added to FIDO2/U2F to support things like SSH, GPG, and cryptocurrency. That would be quite awesome, consider me sold on this. Having a fully self-buildable and OSS Yubikey alternative would be very amazing indeed.