Solo – Open-source FIDO2 security key | Hacker News Reader

Solo – Open-source FIDO2 security key

solokeys.com

174 pointsfabiofederici64 comments

What processor parts will this be using?

A major benefit of the Yubikey U2F parts is that they're almost indestructible. I've heard over and over again about how flimsy the Feitian parts are, and from people who have run over their Yubikeys with cars and still had them work. How resilient (in particular: waterproof) will these be?

Of two U2F yubikeys I own, one of them has stopped working when touching it, in less than 2 years. I don't know about other companies, but my personal experience is that they are not that long lasting.

(I have them alongside my keys; one is a NEO - still working - the other is (was) U2F only)

My NEO has been on my keyring for several years. Still going strong.

My Yubikey Neo has been on my keyring for over three years, too. No problems at all. They seem pretty rugged.

I've found that washing the Yubikeys, especially if they are on a keychain, can be helpful. Soap and water, and then let it dry thoroughly before using it again. The theory here is that build up on the contacts make them not able to conduct as well, and so touches aren't detected. It worked for, YMMV.

I accidentally bricked one when I walked across a carpeted room and zapped it with a static charge.

The one in the pictures uses a EFM32 Jade/Pearl [1]. More details are in the discussion on github: [2].

[1] https://www.silabs.com/products/mcu/32-bit/efm32-pearl-gecko

[2] https://github.com/conorpp/u2f-zero/issues/76

That's a better MCU, but aren't they using a secure element to store keys?

Right. Why not add a ATECC608A?

ATECC608A is nice but can't provide total key isolation with the key derivation method most U2F keys use. E.g. it calculates the key using an HMAC, it gets sent back to MCU, the MCU writes it as a private key back to the ATECC608A to be used for signature. Also the ATECC608A requires an NDA.

Given this, I think having a 1 chip solution really simplifies the design and allows more flexibility.

Maybe a 3D printed mold so one could pot the thing in urethane?

Yubikey 4C is very fragile. Mine has quite severe cracks on its plastic casing after 4 months of casual use (nothing extreme!), and I expect it to break in some months.

YK4 (non-C) is quite robust, though.

My experience has been the same, I've had a 4 for years and it is still going strong but my 4C died in less than 12 months; the USB-C connector is too flimsy.

The connector itself is okay; it's just that the casing is poor. When it finally breaks apart, I'm going to try to cast the board in epoxy. Either I'll succeed, and it will be (hopefully) durable, or I'll completely ruin it - but it'll be broken by that time anyway.

We are using a EFM32 Silabs chipset and plan to use some sort of conformal coating to add water/weather resistance. We also plan to have a silicone case. I don't know about getting run over by a car, but they will certainly be resilient to dropping, getting wet, surviving key-chains.

Having been a part of a few large Yubikey rollouts I can say while the individual/SMB perspective is that they are "indestructible", large fleets see hardware failure rates above what you would expect from similar types of devices.

I don't setup hardware 2FA on personal accounts with less than 3 enrolled devices (and from 2 different vendors).

I've spent some time building small open source USB devices, I went through a "let's just use the PCB to make the USB plug" phase but frankly they're not wonderfully reliable, I'm not a fan, and actual USB plugs are cheap and reliable (you do need to use one that has thru-hole lugs to be robust, not just surface mount which is an extra manufacturing step).

I just finished building my first USB-C (for standard USB) board board, it's surprisingly easy, 2 extra resistors - pad tolerances are tight, but it's not hard

If you could manage to modify Signal so it's keys were stored on the security key, and the user had to tap each time they log in, that would be far more valuable than GPG.

As cool as that would be its probably not doable because gpg doesn't support curve 25519, which is what signal uses for its authentication keys. So either needs gpg decides to support the curve or hardware keys need to explicitly support either signal or the 25519.

GnuPG supports Curve 25519: https://gist.github.com/jmgrosen/5e646d6a6624c0d0e45f241be21...

However, perhaps you're referring to the OpenPGP Smart Card spec, which does indeed lack support for Curve 25519 and EdDSA.

Even though Gnuk supports them: https://debconf17.debconf.org/talks/162/

I wish the spec would be updated to include them...

Can confirm, I use a NitroKey Start (which is a gnuk token) with that curve. I have used it for GPG signing/encryption and SSH authentication without any issues.

> It protects against phishing

Not so much. U2F proves only that the user tapped the device when asked to do so.

You still have to trust your browser and your entire desktop that the tap will be used to log in to the service you are browsing instead of e.g. quietly logging to your home banking.

To prevent "tap hijacking" we need a display on the U2F key to show the URL/service you are really authenticating to.

Assuming valid FIDO2/U2F implementation and same origin policy, this shouldn't be an issue. A browser will enforce that the APP-ID/domain name submitted to the token is the same as the origin requesting it. So in order to be tricked into signing into your bank, it would actually have to be your bank requesting the authentication. HTTPS is also a requirement.

What you're describing is a different attack vector than phishing. I would describe it as malware. The classic phishing attack is to convince a target to visit a web page with a subtly different URL than the real thing, where they enter their credentials, which could include most second factors (OTP codes or push notifications). With U2F however, the browser will pass the URL of the requesting site to the U2F token, and that will be signed by the U2F token. The resulting signature cannot be used to login to the real service. You have to own the user's device or browser in order to do a phishing attack with U2F. And if you own the device or browser, it's probably easier to steal the short lived session auth credentials than it is to man in the middle U2F. You are correct, however, that U2F is not resistant to malware. Unfortunately, nothing really is, and it's not an easy problem to solve.

No: the phishing attack leads the browser to parse and run malicious javascript and HTML.

If the phishing page is then able to compromise the browser the security is breached.

For example it could trick the browser into presenting the legitimate URL to the U2F token, or wait for the user to log on the home banking site for real and then perform transaction, or many other attacks.

I wonder where are they going to manufacture it, and what control and visibility will they have into their supply chains, both upstream and downstream?

Absent some very serious issue with the crypto implementation, that would be my greatest concern -- how easy would it be for a state-level actor to introduce some sort of backdoor or other vulnerability (even a subtle one, e.g. modification to EM radiation pattern) to either all or just a select subset of devices, either into components "upstream" in the supply chain, in manufacturing itself, or downstream in transit to the retailer/customer.

It's worse than that, I think. Part of the security is that each key has to be unique, as I understand it. So to compromise security, all they have to do is make duplicate keys...

This is a good point and generally a hard issue to solve completely.

Right now, we plan to do the programming ourselves to at least verify that goes okay. Since we are bootstrapping, we are outsourcing the PCB-A, but hopefully since this is pretty expensive threat for an adversary to invest in, I don't think it would be an issue unless we show to have a large market. By then, we can move more supply chain in house :)

Is it U2F only or can it also do some of Yubikey stuff like storing GPG keys, etc?

First version will be fido2 only, thought the firmware is open, so easy to extend.

We'll just have to verify which features are copiable vs proprietary for yubikeys. To be honest I don't know at this point, I mostly use my keys for auth, rarely otp, but no gpg/ssh/etc.

Do you have any primary use case that you're interested in?

Secure storage of GPG/SSH keys preferably 4096bit, so I can have offline "cold signing"/emergency keys that are valid for a long time.

I'm using Yubikey for that too and would also be interested in open source solution, especially if it included ed25519 and secure, tamper proof element. (Gnuk has the former but not latter).

I use mine everyday for signing Git commits and tags. Also as my SSH keys.

If it did that then it would potentially replace my YubiKey(s).

There is also open source firmware used on old Yubikeys that could be reused: https://github.com/Yubico/ykneo-openpgp

I've just switched over to using the Yubikey Neo, so I'd love to chime in here.

My first and primary use of my key is that I use HMAC hashing on the Yubikey to unlock my KeepPassCX database. This solution works very well for me because it works seamlessly on multiple platforms (Linux and Windows) and is also compatible with Keepass2Android for my phone. I've looked into GPG only solutions and the ones I looked at didn't offer either the cross-platform compatibility and or browser integration, which is nice. The strong advantage of the Neo (vs the other hardware keys) is the use of NFC, which means less plugging things into my phone. In an ideal world, I'd love to get NFC working with my computers too.

I also use the PGP/SSH smartcard capabilities of my Yubikey on Linux (Ubuntu) and that's been flawless. I don't use SSH on Windows, but I hear the integration there is fairly solid as well.

I've not yet begun to use U2F for authentication, yet. My focus is on my most important services first, which is my passwords and logins. I'll be moving to U2F soon though.

If there was a way to store my passwords easily using PGP instead of HMAC, I'd be interested in that. The issue isn't the storage, but the interface to that storage being easy to use and cross platform (which is not the domain of the hardware, obviously). If I had that, I could consider not needing the HMAC.

I've heard that there is a way to use U2F offline for SSH, but I haven't looked into it. I'm still using SSH keys for things like SSH and Git. Perhaps if there was a solution to that, I might drop the GPG requirement, but I'd need either HMAC or GPG for decryption of my password database, so in any case, FIDO alone isn't enough.

Regarding password storage with GPG, there is pass(1) (https://passwordstore.org) which is a wrapper around Git and GnuPG, and there are a number of front-ends for it. :)

You mentioned the firmware is open, but I couldn't find it anywhere. Could you post a link, ideally to the Git repository where it's developed?

It's an upgrade to a part that used an ATECC508A crypto chip and an 8051, so presumably not.

See also the all in one OnlyKey - https://crp.to/

Solo describes itself as "An upgrade to U2F Zero." What does it do better than U2F Zero?

It implements FIDO2: https://www.yubico.com/2018/05/what-is-fido2/

FIDO2, possibly some other extensions.

Also planning to have case, USB-C option, NFC option

Bit of a tangent, but out of interest, why KickStarter as opposed to CrowdSupply?

Ehm, our ignorance. I’m investigating, though now we’re a bit of in an “advanced stage” with Kickstarter and I’m not sure we can easily swap to CS.

What's nitrokey's status regarding fido2 ? I know that their current open source products don't support it, but they were planning to add it.

FIDO2 is planned but prior to this we are going to release a FIDO U2F first.

Does FIDO2 imply WebAuthn? How do the two relate to each other, other than WebAuthn being an 'outgrowth of' FIDO2?

webauthn is the in-browser API that allows using existing U2F keys, new "FIDO2" keys, built-in "secure elements" / TPMs, and whatnot.

FIDO2, according to https://fidoalliance.org/fido2/ , is the overall project that includes both WebAuthn and CTAP — the latter being the new protocol for talking to the keys.

Woohoo! My urge-zero key stopped working mysteriously and I wasn’t happy about that but I’ll give them another chance.

Thanks!! This next should will come with case and be more robust!

From the image it doesn't look like it'll be easily hand solderable. I love that about the U2F zero (though I'm still torn on if I should build it or buy it).

Yes :(. I've been soldering with paste, stencil, and air gun and have had a good success rate, but it can be a bit more difficult.

I'm thinking about making a short video showing how to solder one reliably for folks interesting in making their own. Unfortunately newer MCUs these days often don't come in easy-to-solder packages.

Any chance someone might make this work with Nextcloud?

Do you know if Nextcloud supports any form of 2fa?

There's a plugin for TOTP 2FA.

There is a U2F and TOTP Plugin for Nextcloud, yes.

If they have u2f then it should work out of the box. I’ll try to test it, time permitting.

I think I like my tomu.im gadget better.

Just sayin'.

So far, the tomu only supports U2F though. Is anyone working on FIDO2 for it?

Looks awesome, just one thing about the website if anybody knows them personally. The motto under the Product, "Secure login, open, easy." is mostly hidden by the photo.

Thank you, I’ll fix it later tonight. Can you confirm your resolution? I mostly tested it on small screens, I wasn’t expecting the front page.

Overlaps on widths >1500px.

(My recommendation would be to not make this a background image, but simply an image in the markup after the headline.)

It should be fixed, thanks again for catching it.

(followed the recommendation -- only for large screens though, it's late and I don't want to make mistakes ehehe)

Reply on news.ycombinator.com