
Show HN: Solo, open source FIDO2 security key - ecesena
https://github.com/SoloKeysSec/solo
======
ecesena
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)

~~~
linuxdude314
Has it been cross compiled for Tomu.im ?

~~~
conorpp
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.

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

~~~
conorpp
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.p...](https://i.imgur.com/sVQ34em.pnghttps://i.imgur.com/sVQ34em.png)

Still have to document this better on Github :)

~~~
craftyguy
Thank you(!!!!) for releasing the schematic!

------
jaytaylor
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/...](https://i1.wp.com/vaultumllc.com/wp-
content/uploads/2017/03/YubiKey-4-Nano-In-Use-1.png?fit=1200%2C800&ssl=1)

[0]
[https://news.ycombinator.com/item?id=18036336](https://news.ycombinator.com/item?id=18036336)

~~~
zaarn
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
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.

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

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

~~~
underko
> 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?

