Hacker News new | past | comments | ask | show | jobs | submit login
Arduino FIDO2 Authenticator (ovcharov.me)
176 points by snakeye 16 days ago | hide | past | favorite | 88 comments

This is pretty cool, and being able to make a FIDO2 device that I can just keep at home next to the PC is pretty appealing. I already have a Yubikey in my keychain for carrying with me, but the keychain isn't at my desk, so having a second one would be pretty great.

It would be amazing if this supported FIDO2 resident mode, it could store thousands of credentials (Yubikeys can only do 25 non-thousand credentials).

Not sure if applicable to your use-case, but I'm using a HyperFIDO Mini[1]. Much cheaper than the Yubikey, and the form factor is also nice for just keeping it in a (reachable by hand) USB port. Though I carry mine on the keychain (and have an older, bigger one at home as a backup).

[1] https://hypersecu.com/tmp/products/hyperfido

This project is a spin-off from my wireless biometric authenticator. I was asked to make it open source many times.

Other than that - I've got one on my keyring as well. But buying one is not as fun as making :)

/me looks at his collection of electronic parts: Absolutely :) However, there is only so much time one can spent on this. Reminds me I should continue working on some FOSS after $dayjob is done for today...

That's surprisingly cheap, less than $10 for a token. Any downsides?

No FIDO2 so it won't work with everything. No NFC.

Oh, it's just U2F? You want FIDO2 with resident key support to get the really nice OpenSSH workflow (plug the key in to a new computer, run ssh-add -k, now you can SSH to all your computers).

Can I do this with a Yubikey?

Last time I tried there were a few, more complex commands than this. Could I use a udev rule to add my SSH keys as the device is plugged so I don't have to run anything?

I think I was using PIV last time.

Yes you can, SSH 8.3ish uses FIDO2 and doesn't do anything Yubikey-specific. That means you don't have to bother with all the agent stuff, and it works with any dirt-cheap FIDO2 key.

EDIT: I'm going to post a writeup tomorrow detailing how to do this, because it's wonderful and super secure.

Thanks, going to look into it more tonight, see if I can get a 5C setup.

It is literally just the two commands, I can send them to you when I'm at the pc. I have a 5C too.

That'd be great, thanks. I'll have to do a follow up to my blog post: [SSH 2-Factor's First Factor](https://2byt.es/post/totp2/) once I've had a play.

Have Nitro keys on the way. Looking forward to your writeup, mate.

Yes, any vaguely modern YubiKey implemented FIDO2 which is what you need.

However you need fairly modern OpenSSH (this year) for both clients and servers. Both need to be upgraded because the authentication protocol itself is different, so an older server has no idea how to authenticate with FIDO2.

To get the behaviour the parent describes you must make sure to follow the instructions for resident keys, and these instructions won't work on cheaper FIDO (not FIDO2) devices that designed be used as second factors. Without resident keys the authenticator only works when at the computer you used to enrol it, which is fine for a personal workstation/ laptop but not great if you need to roam.

Thanks, I have a few 5C's so they should be new enough, I'll need to check my laptop/desktop to make sure SSH is new enough (I run Ubuntu 20.04/Manjaro respectively).

My servers most likely aren't, but I run most of my workloads in Docker or Kubernetes so it's just a matter of time to get them all updated.

Not strictly true, you can copy the "private" key (just a pairing file for the dongle) around and still use the USB key fine with it.

Looks like they have a FIDO2 "Pro" version coming soon: https://www.amazon.co.uk/HYPERFIDO-MINI-FIDO2-HOTP-Security/...

That's the PRO version. As flipbrad said, it doesn't appear to be available yet. At least I can't find how to purchase one.

There are some available here (in the UK): https://www.amazon.co.uk/gp/product/B0813YWZB2

What are some use cases where you must use FIDO2? A sibling comment mentioned SSH authentication, but what about websites?

FIDO2 enables resident keys. With resident keys the web site can have a flow where you just go "It's me" (maybe you enter a PIN, or touch a fingerprint sensor, Apple just announced they're doing this with FaceID) and you're signed in. Without a resident key, there's a back and forth where you give a username, then maybe a password, and then your authenticator comes in to provide a second factor.

This is because the FIDO2 device actually has (finite) slots to remember e.g. credentials for funky-jokes.example so when you're at funky-jokes.example a WebAuthn API call can ask for those credentials and sign you in. No username, no password, you've presented all the credentials needed in one step. Whereas when keys are not resident the authenticator is relying on the web site to know (from your username) its ID, without being told the ID it can't do the authentication dance, so you will need to enter a username/ email address.

Resident keys are clearly a great idea in a phone (iPhone, Pixel, whatever) because it's not like gigabytes of flash storage will be exhausted storing credentials for the dozens or even thousands of sites you have credentials for.

It's less obviously a great idea for a Yubikey or cheap USB Security Key that maybe only has space for a dozen credentials. Maybe it makes sense to use it for that one web site you sign into every day, or to replace the main SSH key you use but if a Yubikey has 25 slots it doesn't make much sense for one to be "bush-jokes.example" which you last visited ten years ago...

That sounds worse to me. I don't like the idea of having my identity tied to a device. What if I lose it? My favorite setup right now is to keep my username / password in a password manager that I sync to multiple places to ensure it doesn't get lost. Then I use a YubiKey with FIDO / U2F on sites I consider important. I have a main and a spare YubiKey and both get added to my profile (except AWS who only support one key).

All the FIDO2 capable devices I'm aware of are intended to be used with some external factor. For a Yubico Security Key 2 that's a PIN (unlike your passwords the PIN isn't sent anywhere, it's verified by the device) and some other devices use a fingerprint. Platform authenticators are going to do all sorts of stuff, like Apple's FaceID.

So if you lose it the credentials are now essentially worthless (anybody who found it or stole it presumably doesn't have your PIN / fingerprints / face) and you should revoke them from sites where they were trusted.

Nothing prevents you from enrolling multiple FIDO2 resident key devices for a site, the site would store all the relevant credentials and you could use any of them to log in. I expect Apple's implementation notes for that demo last week tell implementers to allow multiple enrolment because some of Apple's best customers own an iPhone and an iPad and a MacBook Pro and expect to use all three.

But sure, you can use the second-factor-only FIDO behaviour on a FIDO2 key just fine, it's just that FIDO2 resident keys can offer a nicer user journey while still being secure.

The thing to be wary of here is knowing which platform should be used, on a given site. These devices are to establish strict lines of trust, but not all those who use them are technically proficient, so a MitM that downgrades the authenticator from "platform" to "cross-platform" (or roaming) can alter the registration process such that what should have had a biometric tie now just has a PIN (or no PIN depending). This attack depends on how the vendor is managing AAGUIDs and Attestment Certificates, but a lot simply don't.

This seems like a pretty complicated attack with relatively low value, but maybe I don't understand something important. So let me run it back by my understanding.

You're proposing a TLS MitM (maybe plausible in a corporate environment that has this configured anyway) which downgrades the authenticator enrolment to have less protections, and then passing the resulting credentials to the real backend which will assume it has two factors without checking?

And later you steal the device so you can now use it without an additional factor because it wasn't enrolled using multi-factor anyway.

This would work as an element of the over-complicated schemes in an Oceans movie, but it doesn't feel very plausible in the real world. The skill sets to "Steal someone's iPhone" and "Obtain fraudulent Web PKI certs" don't overlap very much and this attack doesn't scale so it would need to be targeted.

I didn't explain it really well. I wasn't too worried about it being stolen. I was worried about having a single device, so losing it means losing all the identity info. I guess it's no different than now where I enroll 2 keys everywhere.

I've had detection issues with some (unpopular) Linux command line tools. No issues with Firefox on Windows and Linux, though.

I didn't try any command line utilities and only use it for the web with Firefox (e.g. GitHub). Can confirm: Works well on both Linux (needs some udev rule, but I think that's true for all these sticks?) and Windows.

To further answer GP: Lacks Bluetooth/NFC, so it's not usable with a smartphone (okay, maybe with a large USB-OTG adapter). No idea on the supported protocols, I think Yubikeys offer a lot more options there, but it's good enough for web authentication.

Manufacturer support was pretty good: My first token was DOA, and I got a replacement token plus a free Mini. The replacement is now my backup unit and, as mentioned, carry the Mini on my keychain.

Could you say which ones? It would be good to know whether anything I use is known to be problematic with these.

Despite having a 'buy now' link to amazon.{de,fr,es,uk}, it refuses to ship to the Netherlands. That's disappointing (and sloppy).

Oh, that's really weird. I got it from .de delivered to DE. Maybe send the manufacturer a mail and ask them to fix it? Mine came DOA and I remember them to be pretty friendly.

Chiming in to mention SoloKeys, it's open source, FIDO2 certified and supports 50 resident keys.

@snakeye, please feel free to port over the CTAP implementation to your device (same for the other tokens I'm reading in the thread). We have already 3 products selling with our firmware.


Is Somu the same as the current Solo? (Not that I've had much opportunity to exhaust it...) I don't remember seeing that documented, or if the processor/storage is the same.

On the topic of the implementation, is there any estimate for arrival of the PGP support?

I mentioned SoloKeys farther down the thread, I'm really excited about the new version. Is that coming out soon? I know it was supposed to come out in June, but haven't heard anything yet. I actually sent you guys an email a few minutes ago.

Currently manufacturing the very first batch: we're waiting for the PCBs to be shipped, then we'll proceed with assembly, testing, etc.

Conservatively I'd say we'll start shipping around Sep/Oct. But for sure there'll be some "limited edition" tokens in circulation before.

That's good news, thanks! Do you know how many resident keys you're going to end up storing? I'm really suffering with the Yubikey's 25, I'm going to write a post on SSH auth with FIDO2 and would like to be able to recommend SoloKeys.

With the current Solo we have 256kB of flash so we sort of arbitrarily reserved space for 50 RKs, but you can prob tweak the firmware if you need.

With the next gen of Solo we have 2MB of flash, so assume virtually unlimited RKs, at least given the number of sites that currently support them.

(note: double checking w/ the team for correctness)

That's really exciting, thanks. I'm kind of banking on FIDO2 RK becoming the standard on the web, so I really want a key that can support thousands of sites. I might be customizing the firmware (AFAIK it's in Rust), and I'm really hoping I can get one of the preview devices to help testing.

Thank you! I will definitely take a look at your CTAP implementation!

What I am doing, and I find it to work really well is to have a yubikey nano (https://www.yubico.com/product/yubikey-5-nano) in one of the front USB ports of my PC case. Super easy to reach and takes no room at all.

Awesome project.

I have the USB-C version mounted under my desk with a USB-C extension cable. Works well.



I don't want to pay $50 for another Yubikey when I have a box full of $4 ESP32s, though.

Weld it into an anvil to prevent tampering while you are away!

Haha, I was thinking of a 50lb block of epoxy resin cast around the device, with metal rods protruding down to the touch sensors.

The couple dozen keys storage limit definitely feels limiting if this ever supposed to be commonly used. Is anyone using the resident mode which OP mentions?

I am, and yes, it's definitely limiting. I wouldn't buy a Yubikey because of that, I'm very excited about the new Solo keys that should be coming out soon, those will probably support thousands of keys.

Would the Krypton Authenticator be of any help to you?

It works through an app on your phone.


I had used this for a while, the problem I had was that I change phones much more often than I change hardware keys, so I had to change every key on every site every year or so, which was too tedious.

What is the case against using a bluetooth-linked 2fa from your phone the way Google Advanced Security does?

Thank you! I'm looking for a simple and convenient solution as well.

I have opened a few issues in your repo, I want to try this out but there's very little documentation. I know I can probably just `pio build -t upload`, but I'm not sure about the schematics.

Oh, right, need some documentation there as well.

In general you can try the project with ESP32 development board and upload the firmware using `pio run -t upload -t monitor`

Then you need to pair the Bluetooth device. Afterwards you should be able to see connection requests in the serial monitor when you start authentication.

The actual authentication commands are not implemented yet, so it will not go further. Sorry :(

Ah, I see, thanks. I will watch the project and hopefully will use it when it's finished, thanks!

Yes, I have seen this recently. Google is so unsatisfied with BLE in FIDO2 so they removed support for it from the Chrome browser.

Yubico has said from the very beginning that they will stick to NFC because Bluetooth is not secure.

Bluetooth is a 3000+ pages spec that's a mess and will likely always remain a mess. Maybe it's time for something better?

I'm using a bluetooth keyboard and I type my passwords in plain text. I don't think that public key sent over bluetooth is less secure. So it's a very tricky topic and I think it's more about corporate insterests that actual security.

Bluetooth security has always been a mess and even the specification itself has had egregious bugs that almost all devices were and often are still vulnerable to: you can force 8bit symmetric keys if you like: https://knobattack.com

I would never trust any wireless keyboard or mouse on any even marginally important computer. Bluetooth security is a broken mess, and taken together with the mess most bluetooth functionality is (e.g. perpetually broken, laggy, stuttering, forgetful, lofi audio profiles) bluetooth needs to die asap.

Is Bluetooth not encrypted? It would be disastrous if just anyone could read what your Bluetooth keyboard is sending.

It is encrypted with MITM protection. That's why I do not believe in severe security issues in BLE. There can be problems with particular implementations, but in general it should not be less secure that typing password on a keyboard.

Your keyboard very likely isn't using BLE (Bluetooth Low-Energy). The issue appears specific to BLE which behaves differently than Bluetooth X (4.0, 4.1, 5.0, etc) "proper" and has a different security profile.

Just so we're on the same page, "Bluetooth X" was discontinued at 3.0 -- it's now named "Classic Bluetooth."

Bluetooth 4.0 (4.1, 4.2, 5.0, 5.1) are almost exclusively the artist formerly known as Bluetooth LE. LE is a totally different standard than classic Bluetooth, and was developed by Nokia ("Wibree") and dropped on the desk of the SIG with a big thud. Nokia told the SIG this was Bluetooth now, and they adopted it as "LE" and it forms the core of all version of Bluetooth 4.0 and later.

4.0 and later specs include "LE", "Classic" and "High-Speed". It's very unlikely developers are building for Classic mode anymore, that protocol is an utter nightmare. I don't know anyone building High-Speed devices.

I'd be surprised if a new keyboard opted for anything other than LE. That's just the kind of embedded system it was designed for.

Thanks for the clarification. That's interesting, I had wondered why I always "felt" Bluetooth had gotten slower lately, but thought it was just me!

Perhaps you can clarify whether I was barking up the wrong tree in my original comment; My understanding is that keyboards, HID devices in general, are usually using something like "Classic mode" or perhaps even actual classic Bluetooth (particularly cheaper/older hardware)

The security keys like the are using the "modern" type, which is a different "spec". I don't know if it's using something like like (G)ATT, but it's not the same spec/tech?

I'm not sure where the industry is at these days, to be honest. So as far as I know all LE devices use the GATT profile (though I wonder about headphones). The LE spec includes HOGP (HID over GATT Profile) which defines a set of services and characteristics for LE HID devices. [1]

Older devices almost certainly use a Classic Bluetooth HID profile, but newer devices like the Apple Magic Keyboard are LE HOGP devices. It uses much less energy so IMO a battery-powered HID device would be pretty nutty to implement using Classic Bluetooth in this day and age.

Interestingly there's no concept of "pairing" in LE devices, just "bonding" (where previously derived keys are persisted and re-used as an optimization). All LE peripherals operate in promiscuous mode by default and vendors have to implement their own pairing system -- or piggyback off bonding.

[1] Warning PDF link: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...

You are probably right. However, the BLE transport was not removed from the 2.1 specification and supported by Microsoft Hello. And, anyways, for Arduino based DIY project existing security is more than enough.

That's what I thought, thank you.

What about Google's use of "Smart Lock" via bluetooth to secure each sign on attempt with Google Advanced Protection?

Not Arduino, but there is an open-source fingerprints reader for RPI: https://www.raspberrypi.org/blog/raspireader-fingerprint-sca...

Is it that much worse in smaller form-factor? NDA only?

There is small UART biometric module https://www.digikey.com/products/en?keywords=2304-100018754-...

The biggest downside - it's more that 3 times more expensive than the device I have now.

Fantastic. I have been thinking that the best possible thing would be an external device with a screen and a key pad input. This seems to be exactly that.

You need the screen because the protocol includes the concept of an authenticator with a screen, and that allows you to verify the information even more compared to a yubikey or something like that.

That was my assessment as well a few years back, which drove the project I'm working on now. I embedded both the authentication (TOTP at the time) and content encryption functions directly into the keyboard and added an internal screen. I had been working through all the attack surfaces of trying to do it in the same kernel space as a compromised node and just decided that was the wrong way to go. Demo of the prototype I built is here: http://www.anomie.tech/deck/anigma-keyboard.m4v

Thank you! :)

I love this project. right approach for the problem. Will pitch in on the code.

Is it really necessary to use external ATECC508A with ESP32? I would not be surprised if software implementation on ESP32 is actually faster.

You can not extract private key from ATECC508A while it can be an issue with custom key storage built on Arduino. The chip itself costs around one dollar so why not?

> But, wait, is it difficult to find a charger or power bank with Micro USB nowadays?

It's definitely trending that way IME...

I understood the point the article was trying to make here, but, actually, it's become almost a nightmare to find a Micro USB cable in my home, so I had to answer "yes".

Every time one breaks or gets tatty I bin it and don't replace, because, really, the only thing I need it for is my PS4 controller and the baby monitor. I've burned through a decade or so worth of them thrown in boxes and drawers.

It gets really hard these days to find one when I need to charge my PS4 controller and the baby monitor needs charging at the same time.

While I'm on the go, I guarantee I don't have one. Phone, wife's phone, Switch, tablet, power bank, laptop, earbuds, all USB-C charging. It's taking me some time and careful purchasing choices to get to the point where I can carry a single power brick to fast charge all the devices I carry with one connector/cable, adding Micro USB back in would actually be an inconvenience.

Nothing can stop us from making the same PCB but with USB Type C connector for charging.

Actually I'm using it in my other device according to the exactly same thoughts.

I've never tried hand soldering a USB-C SMT connector, expecting it to be somewhat harder than Micro USB, is it reasonably doable with hot air?

Oh, in fact it's much simpler than MicroUSB. There is special type of USB Type C used for charging - https://en.ovcharov.me/uploads/2020/04/06/20200404_092055.jp...

It has only six huge pads and can be soldered either with hot air or normal soldering iron as a charm.

Oh, now this is a revelation, I had no idea!

P.S. the link has hotlink protection for anyone wanting to click; you'll need to paste the link straight into your address bar

I have a neat cable with an attached micro/C adapter, and is A-to-C unless you un-nest the micro end.

Isn't there is a good option is to use wireless charging instead of USB one?

Can anyone explain or further expand on this statement

> plain C and ESP IDF are too difficult for the broad audience

My intuition is that most folks who hack on EPS32 and other microcontrollers have no problem with these things.

From my experience - most people say "Arduino is ok" but struggle working with plain C.

As well keep in mind number of ready-made libraries for Arduino that can be reused here almost out of the box.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact