Arduino FIDO2 Authenticator
en.ovcharov.me
en.ovcharov.me
It would be amazing if this supported FIDO2 resident mode, it could store thousands of credentials (Yubikeys can only do 25 non-thousand credentials).
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 :(
I have the USB-C version mounted under my desk with a USB-C extension cable. Works well.
https://www.amazon.com/Faracent-Extension-Charging-Nintendo-...
Other than that - I've got one on my keyring as well. But buying one is not as fun as making :)
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.
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.
EDIT: I'm going to post a writeup tomorrow detailing how to do this, because it's wonderful and super secure.
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.
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.
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...
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.
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.
@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.
Conservatively I'd say we'll start shipping around Sep/Oct. But for sure there'll be some "limited edition" tokens in circulation before.
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)
On the topic of the implementation, is there any estimate for arrival of the PGP support?
It works through an app on your phone.
https://www.theverge.com/2019/5/15/18625028/google-titan-sec...
https://nakedsecurity.sophos.com/2019/05/17/google-recalls-t...
edit: formatting
Bluetooth is a 3000+ pages spec that's a mess and will likely always remain a mess. Maybe it's time for something better?
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.
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?
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...
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 it that much worse in smaller form-factor? NDA only?
The biggest downside - it's more that 3 times more expensive than the device I have now.
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.
It's definitely trending that way IME...
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.
Actually I'm using it in my other device according to the exactly same thoughts.
It has only six huge pads and can be soldered either with hot air or normal soldering iron as a charm.
P.S. the link has hotlink protection for anyone wanting to click; you'll need to paste the link straight into your address bar
> 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.
As well keep in mind number of ready-made libraries for Arduino that can be reused here almost out of the box.