Testing FIDO U2F security keys | Hacker News Reader

Testing FIDO U2F security keys

imperialviolet.org

151 pointsstargrave58 comments

You'd assume that a device as sensitive as a hardware security key would get extensive testing from the vendor, from 3rd parties contracted to the vendor, and from random unauthorized 3rd parties testing out of personal or public interest.

But in fact there are almost certainly commercial hardware security keys that receive no testing at all at the level AGL is working at --- which, while impressive and super interesting, isn't as low-level as serious third party specialized crypto validation goes.

My takeaway from this is: buy the most popular U2F key (which happens to be Yubico's). This isn't a place where you want to shop around for interesting alternative brands.

Nobody pays me to say this and I have no relationship with Yubico of any sort.

I tend to agree, but this is Hacker News - how does a new player break into the market in this case?

Due your due diligence. Get third-party validation from someone with a good reputation you can trade on. Proudly flaunt that validation on your website, marketing material, etc., rather than hiding it behind some NDA for big customers only.

I know that some people feel that it isn't worth the paper it's printed on but I looked for FIPS 140-2 validated devices when I was looking for smart cards (for storing the private keys of CAs in an internal PKI). I'm not aware of any U2F keys that have been FIPS-validated (I realize that it is a very expensive and long process), though. Yubico's web site [0] says that validation is in process (for some of their devices) but it has said that for as long as I can remember.

I like and recommend the Yubikeys as well (not that my opinion is worth anything) and, other than that one "PIN bypass" issue in the OpenPGP applet on some NEOs [1] (which was inherited from upstream), I don't recall hearing of any issues with them. There may be better devices out there but I'm sure there are much worse ones that you could buy (as AGL just showed us) and I'm quite happy with my (~7!) Yubikeys.

ETA: "The YubiKey ... meets the highest level of assurance (LOA) requirements, based on NIST Electronic Authentication Guideline SP 800-63-2 ..." [2].

[0]: https://www.yubico.com/products/yubikey-hardware/compare-yub...

[1]: https://developers.yubico.com/ykneo-openpgp/SecurityAdvisory...

[2]: https://www.yubico.com/wp-content/uploads/2016/06/Yubico_Whi...

I'd recommend watching this [1] talk once the videos go online. It paints a pretty nasty picture of all the things you can screw up and still end up FIPS validated.

1. https://www.blackhat.com/us-17/briefings/schedule/index.html...

Oh, I'm well aware that FIPS -- or any other certification program, actually -- isn't a panacea. There were issues found with the RNG in some country's national ID cards (smart cards) as well; the RNG had also achieved FIPS 140-2 validation.

All things being equal, though, I would still be inclined to have a little more trust in something that has been through the process than I would in, say, the homebrew RNG [0?] used by Honest Achmed's Used Cars and Certificates.

[0]: https://xkcd.com/221/

> Honest Achmed's

FYI, I was making a reference to a "bug" from 6.5 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=647959

(another HN'er thought this was a "little racist")

FWIW: I'm absolutely certainly guilty of the same mistake, but referencing a racist stereotype that somebody else (jokingly) used doesn't make it not racist (1). It's easy to fall into the trap and me, too, considered Honest Achmed a good joke at the time, but I don't, any more. (the joke is still good, but the names picked are not)

(1) unless you use the reference to put it into context, or discuss it, ...

TBQH, I really don't care if anyone thought it was racist or was offended by it or whatever. They're completely missing the point -- and "Honest Achmed" wasn't even a key part of that sentence anyways. It could've been Honest Achmed, Honest José, or, hell, even Honest Abe, but I suddenly remembered that ticket and so I replaced "some fly-by-night crypto startup" (or whatever I had originally written) with that.

I'm over all the politically correct bullshit and people actively looking for things to be offended by. It wasn't meant to be racist. It was meant to illustrate a point. I come to HN to get away from all of that shit so, please, go be offended by something else.

When you respond to private trolling by publicly counter-trolling, you're not so much taking a stand on principle as you are jamming the thread with noise. If it's PC BS, it doesn't deserve discussion.

He's right though, because the name was Achmed and not Joe or Robert, people automatically assumed he was being racist which is ironic because as he pointed out the but is specifically "add Honest Achmed's root certificate" and it is in fact about "Honest Achmed's Used Cars and Certficiates". Was the original bug filing racist, maybe, maybe not. So in this instance, someone let their emotions jump the gun and were quick to accuse racism. The only way to stop the behavior is to identify it. Considering the whole "PC" movement prevalent these days, his response was tactful and relates to the original story which is more than those than those accusing racism could claim.

Validation in this space is nosebleed expensive. The "usual suspect" security assessment firms don't do this kind of work (or have no business doing it).

Well, for starters, remember to zero your damn memory before using it so you don't leak old content...

Wouldn't that make Bitcoin Hardware wallets the most secure then? They don't have the same software support and documentation as Yubico but they are targeted heavily by hackers.

The two popular options are: Trezor and Ledger. Both supports FIDO U2F and have a large user base.

Does the FIDO U2F feature on them get targeted by hackers?

My understanding is that it depends on the secure components that secure the private key and sign the messages. So hacking FIDO means hacking the crypto private key or the wallet.

TIL they also support U2F. Interesting.

Related (but slightly OT) question: has anyone ran into any issues when using either 1) a single Yubikey for both U2F and SSH authentication or 2) multiple Yubikeys simultaneously on the same machine (i.e., one for U2F, one for SSH)?

For SSH authentication, I use Yubikeys (and only Yubikeys) everywhere: my workstation at home (I WFH 99% of the time), my primary laptop, and a "backup" laptop. Each of these machines has its own "dedicated" Yubikey that I use to authenticate to remote SSH servers (a "Nano" that is left plugged in 24/7). I also use these (with challenge/response) to unlock encrypted LUKS volumes (containing ZFS pools) at boot, FWIW.

I would like to begin using U2F (AFAICT, U2F support should be coming to Firefox soon, if it hasn't already; running FF57 Developer Edition here), preferably with these same Yubikeys I am already using for SSH. If there are any issues, however, I'm fine with using a separate Yubikey just for the U2F side of things (I have a few U2F-only Yubikeys laying around as well).

Basically, I want it to be as easy/convenient as possible and, before I begin to attempt this, I'm just curious if anyone else is already doing this and, if so, what their experiences were and any issues they may have encountered. In theory, it should all just work but, in reality, well, who knows. TIA!

U2F should work with your Yubikeys, irrespective of your slot 1/2 configurations. U2F does not depend on slot provisioning. Unlike your slot/gpg keys, U2F authenticators are unique to each individual hardware component and cannot be replicated between Yubikeys.

I thought as much. I'm mostly curious about any possible "inter-op" issues with GnuPG and U2F functionality (for example, I have heard reports that gpg-agent would "reset" after a U2F auth and so would require a PIN on next use regardless of any timeouts; that's not a problem for me, just something I'd like to be aware of beforehand). Thanks!

Be prepared to pull and replace the Yubikey when switching between applets. I currently use a key configured with U2F, gpg (and ssh via gpg-agent), and oath totp. Usually it switches between applets seamlessly, requiring pin entry for gpg any time I switch back to gpg.

Occasionally whichever applet I'm attempting to use will appear unavailable, requiring the token be pulled and reseated.

Yeah, I've heard similar reports before and that's exactly the kind of thing I was wanting to hear about because, e.g., the Nano can be a PITA to remove sometimes -- especially on my workstation, where it is plugged into one of the USB ports on the "back" of a Das Keyboard. I don't mind punching in my PIN all the time (I already use short timeouts anyways), but removing and reinserting the Nano several times a day is inconvenient and will get annoying real quick.

Thanks.

I used to run into this regularly as well, usually with gpg-agent refusing to work. I recently switched to a 4C Nano, which made it quite cumbersome to pull the key, so I looked into it and found out that reloading gpg-agent does the trick as well. I use this alias to do that quickly:

    alias gpgpls='gpg-connect-agent reloadagent /bye'

I haven't needed to pull the key since. I'm on macOS and use gpg-agent, U2F and yubioath-desktop.

Oh, excellent, that's great to know. I run Arch Linux on these particular machines but, in this case, it probably doesn't matter. Thank you.

If people are going to leave the USB device in all the time, why not just use the onboard TPM the machine probably already has? At least on Windows, the TPM can create a virtual smart card so existing infrastructure can just use that as normal.

Then you get keys protected by hardware. Though the TPMs might commonly be easier to physically hack than good USB devices.

For U2F, there are two issues. First, communication doesn't use a smart card protocol, it uses a custom protocol over USB/HID. So to implement U2F using the TPM you would need to write a virtual USB device driver, which is a pain. Github wrote one for Mac, but there's nothing for Linux or Windows to my knowledge. Second, U2F calls for a physical presence check. With most existing hardware, there's no way for the TPM to verify physical presence, so it has to be done in the client software, which reduces the point somewhat. Newer hardware may address the second point, as I've seen some new laptops with TPMs hooked up to the fingerprint reader.

For other smartcard-y things: a lot of stuff gets called a "smart card", but any given application is going to involve a particular applet on a smartcard, and a particular client side implementation to use it. The Windows virtual smart card implements a PIV applet, I believe, whereas most of the Yubico stuff works using either non-standard applets or a PGP smartcard applet. So the client side would not be compatible with the Windows virtual smartcard.

I'm replying to myself here but to anyone else interested, you can now -- unofficially, as of v57 -- use a U2F-enabled YubiKey in Firefox.

See the details on Mozilla's Wiki [0] (short version: in "about:config", enable "security.webauth.{u2f,webauthn}") and visit Yubico's online demo [1] to test it out.

[0]: https://wiki.mozilla.org/Security/CryptoEngineering#Using_U2...

[1]: https://demo.yubico.com/u2f

A while back I looked into building my own hardware two factor key. I wanted to experiment with the technology. I've since backed off the idea due to several serious challenges with designing secure hardware for this purpose.

* By necessity there's a pretty large attack surface, you've likely got a vendor specific bluetooth stack and coprocessor. The same goes for wired solutions with hardware USB peripherals (though atleast significantly less complex). Being sure the hardware peripheral doesn't have any major memory safety issues is a complete bear to test, and that's not even touching on sidechannel analysis.

* Running public key crypto on microcontroller (excluding specific hardware crypto support) is a little more novel than a desktop machine, the leading libraries are no where near as extensively battle tested. And there's architectural concerns about sidechannel attacks and often the lack of any memory protection units (bigger chips solve these issues, but power budget concerns are tricky).

* And given all software has bugs, how do you update the firmware? Signed firmware patches as part of driver update? Who's to say somebody hasn't already owned your bootloader.

I think the solution to all this, is to abandon the idea of additional hardware, what if your smartphone could act as a two factor hardware token over Bluetooth? The big problem is pairing really, and how to make this an easy process for users, I never figured that out. On the other hand I did come up with a scheme that would allow usb based hardware tokens to work without additional drivers / software and on all current major operating systems and browsers. I really ought to work on it, but as above I don't trust embedded hardware (embedded hardware is such an antithesis to, move fast and break things).

How'd your scheme work? I suspect HN wants to know ;) A lot of hardware just acts as HID keyboard, but that only works one direction unless you use a side channel like visual (QR code like TOTP and/or camera like the Bloomberg unit).

I think the Bloomberg auth units are some of the most advanced examples of this - they're protected against almost any imaginable physical attack, too (freezing memory state, power sidechannels, xray/delidding to dump mask ROM, etc.) But they have a lot of money to spend on it...

Broadly based on abusing USB ethernet and browser origin policies. Relies on the fact browsers are used to treating the network layer as a hostile environment.

The Yubico and VASCO tokens aren't simply doing RSA on a microcontroller; they're using parts that probably provide hardware RSA.

Yeh it's a coprocesser arrangement for sure these days. Probably the only way to do it remotely safely, sure doesn't provide a ton of flexibility though and definitely adds to the total BOM cost for the devices.

> I think the solution to all this, is to abandon the idea of additional hardware, what if your smartphone could act as a two factor hardware token over Bluetooth?

I'm glad my hardware security token is not running a full smartphone OS updated only with delay and for a few years until the vendor wants me to buy a new one, does not connect to public wifi and mobile networks, won't run games and other third party software, does not break after falling from waist height.

I'd be very interested to see the author review how the cryptocurrency hardware wallets Ledger[0] and Trezor[1] compare - they also have U2F functionality. I use my hardware wallet for U2F and I am guessing they are becoming more widely used for consumer users.

[0]: https://www.ledgerwallet.com/

[1]: https://trezor.io/

EEVblog did a video about the Trezor[1].

[1]: https://youtube.com/watch?v=BzxGoJdd8a4

I'm using the Ledger for U2F and it is easy enough. For SSH and GPG, not really. The software for SSH and GPG is made by a third-party. It is not well tested and the documentation is lacking.

However, I hope it improves in the future. The Ledger wallet can do:

1. FIDO/U2F

2. SSH/GPG

3. Password Management

4. Wallet for Bitcoin, Ethereum and a bunch of other altcoins.

So, yes, I think it is worth the deal.

I'd really like to buy a U2F token, but need to find one that let's me use it mobile (Android) as well as on desktop.

I know that Yubico offers an NFC-enabled on, but it doesn't support 4096-bit keys if I understand correctly.

The Fidesmo dual-interface smartcard might fit the bill: http://shop.fidesmo.com/product/fidesmo-card-dual-interface You would need to buy and install the U2F applet ("card app") onto it. There are other applets available for PGP and for Bitcoin wallets, which can co-exist on the same card AFAIR. Not sure about supported key lengths. I'm not affiliated with Fidesmo or the applet vendors.

Any opinions on this product from the HN crowd? E.g., what do you think about the security implications of their user-installable applet model?

FIDO U2F is just enterprise stuff. My mom will never own one to log in to Facebook. So the market is very difficult for newcomers. That's why we see lots of low quality products which come and go.

Maybe not Facebook, but if the government does it right, she'll use something like that in place of her SSN to be able to use social services, get credit, vote, etc.

Sweden got a system a bit like this called BankID.

BankID isn't operated by the government but rather by the system critical banks however it's really ubiquitous today and supported by most government sites, banks and other high security web systems.

BankID comes both as hardware keys with smartcards or as a mobile application where you use a local key to sign a request.

Yes, biometric authentication is the future. And intelligent wearables or some other assets carried daily like mobile phones. USB dongles are just for techies and last season anyway.

what's biometric about bankid?

But she will enter the info from the SMS that Facebook sends to her?

I mean, comparing U2F keys with the alternative 2FA methods (like SMS and Google Authenticator), it sure seems simpler to just tap the USB key instead of taking out your phone, unlocking it, seeing the message, and writing the code from the message.

They're convenient as hell.

You're right. 2FA is convenient as hell until biometric authentication will do it with user's consent ( just tap something ). Yubico is quite near this target, but fragile usb dongle hanging from the side of your laptop isn't still optimal. FIDO is doing great work trying to bring secure authentication on the market, but the risk is that it'll be another complex OpenID which is killed by the giants ( Google, M$ etc ).

> but fragile usb dongle hanging from the side of your laptop isn't still optimal.

And that's why we have Yubikey Nano versions. And as for them being fragile, I really don't experience that. Mine one has been sitting on my keychain for about a year and a half and it seems rock-solid. Even though it has been through rains and thrown around countless times, it still works like it did on the day one. Even though it's plastic, it is pretty durable from my perspective.

Slightly OT, what do people use for U2F, Google Mail and Firefox?

Here's a list of sites that support 2FA, via hardware tokens and other methods: https://twofactorauth.org

Yubico do a short (but I think that's realistic) list of sites that specifically support u2f

https://www.yubico.com/solutions/#FIDO-U2F

Thanks I have a Yubico key and use it with Gmail on Chrome, to better phrase my question: How do I use it with FF? (my main browser).

On Firefox Nightly, it works without extensions, but you have to set security.webauth.u2f to true in about:config.

It only worked with some sites that I tried, for others you probably have to fake the user agent.

Yeah... The Google Cloud Console and Google Accounts do that for one. I can't set up or use my U2F key in anything but Chrome. Hangouts similarly barfs when you're using Firefox because they believe the WebRTC support is missing (instead of checking). Works fine with GitHub though :).

lastpass supports yubikeys as 2fa, but you have to have a subscription to premium for it to be enforced. i let mine lapse for a while and it simply stopped making me use my yubikey. i'm not really sure what was going on behind the scenes but it made me a little less confident in the particular aspect of lastpass.

That was the last drop. I switched to an alternative immediately as soon as I've noticed LastPass requesting premium for something as essential as a 2FA method.

There's an extension: https://addons.mozilla.org/en-GB/firefox/addon/u2f-support-a...

Works perfectly for me.

This extension will become deprecated with Firefox 57 (WebExtensions update).

Unfortunately, it seems that they've failed with shipping U2F support in Firefox at the time, so the browser support seems to be coming to 58 (currently in Nightly). So, your options in November will be either Firefox ESR or switching to Firefox Beta.

EDIT: Source: https://github.com/prefiks/u2f4moz/issues/59#issuecomment-32...

EDIT2: My previous coworker also discovered some high-CPU issues with that add-on on Ubuntu, so be aware of that as well: https://github.com/prefiks/u2f4moz/issues/51

At Google we also use it internally on all corp systems.

I cannot fathom that folks still can't parse DER correctly. It really isn't complicated.

Reply on news.ycombinator.com