Follow

jookia reads fido2 specs 

passwords are a fucking maintenance and security nightmare for everyone. for good security you need a long random password which humans are not optimized for remembering. there's no way to audit passwords so there's a bunch of rules saying 'please just add a symbol', maintaining passwords is fatiguing. the one redeeming factor is they don't rely on anything physical so you can't lose them. unless you forget them. which could never ever happen right? so what's alternative?

jookia reads fido2 specs 

right now basically everything in linux wants my password. sudo wants my password, luks wants my password, ssh wants my password, gpg wants my password. just fucking stooop already. websites want my passwords too so that's fucking great. for security's sake you can use two-factor auth and add phone auth codes and that makes things more secure but double inconvenient. WHY IT GOTTA BE LIKE THIS? it don't i don't think

jookia reads fido2 specs 

so one solution is to store keys on an external device. you use a yubikey or nitrokey. fucking sick, linux solved. passwords over. BUT WHAT ABOUT WEBSITES? WHY ARE THEY SO EXPENSIVE? THEY CAN ONLY HOLD LIMITED KEYS? aaaargh. well recently fido u2f dropped, and by recently i mean years ago. i bought the key-id fido u2f token for $20 AUD and tested it out

jookia reads fido2 specs 

the key-id u2f key is kind of clever: it has a public key (or many, idk how it works ITS NOT OPEN SOURCE) and will sign 'yes website i have this key' and website will let you in. this is pretty cool for multi-factor auth, it replaces the phone and tokens with a single pressable button in usb. however it still can't decrypt things, it only signs them. still, pretty good

jookia reads fido2 specs 

eventually ssh added two-factor auth using u2f which is cool (i don't use it) but i've really just wanted a cheap key that would let me unlock disks and auth my identity. and is open source or something. anyway, fido2 dropped while i wasn't looking and it seems to do a LOT

jookia reads fido2 specs 

apparently there's like multiple specifications for fido2:

- webauth for accessing public key credentials
- client-to-auth protocol which is used by applications to access physical dongles or keys over USB, NFC and bluetooth
- uaf which talks about a stack of software that can auth, so like windows hello or biometrics or touchid

this is pretty incredible because it seems to cover all the bases for authentication

jookia reads fido2 specs 

but what about decrypting drives? well there's an extension devices can support called hmac-secret. so like, everything covered?

so i'm going to read the standard and give notes on this because im interested. NERD TALK INCOMING

jookia reads fido2 specs: fido u2f 

starting off with the original fido u2f standard, it's a standard challenge response thing. server has database of keys, client proves it has that key using public-key auth. but also it supports devices shipping with manufacturer keys that say 'yes, i am this device'

the standard talks about being resiliant to phishing, being unlinkable/private, that's pretty cool. it also mentions channel binding! fuck yeah!

jookia reads fido2 specs: fido u2f 

ok, so let's look at the USB HID API. this is what computers use to talk to the friggin device. it's interesting to use USB HID for this but it makes sense and means you don't need OS level drivers for this- oh, that was one of the goals. the actual protocol just lets you send data messages which are defined elsewhere. this goes over USB/NFC/bluetooth. so what commands we got?

jookia reads fido2 specs: fido u2f 

U2F_REGISTER, U2F_AUTHENTICATE, U2F_VERSION. neat. so let's start with U2F_REGISTER. you give a challenge parameter and an application parameter. the application parameter is an 'application facet'. these are basically a typle of username, authenticator and relying party (probably the website).

jookia reads fido2 specs: fido u2f 

so how do you like register? obviously there's a challenge, but you also have to link keys with like ... some identity. and not accidentally share that you have that identity to services that aren't part of that identity, that leaks personal info. the immediate idea is to link it to a URL, but what about when you're not using browsers? what about apps and stuff?

jookia reads fido2 specs: fido u2f 

well fido u2f introduces the idea of an application facet, which describes different parts of a wider application. it uses a bank with a website and various mobile apps as an example. so it breaks it in to two IDs: an application ID and the facet ID, which is the application you're using to auth. its kinda backwards but fuck it right. so in web, the facetID must be the web origin, like the URL + scheme. on android it's the hash of the apk signing cert

jookia reads fido2 specs: fido u2f 

the algorithm for checking if a facetID is authorized for an appID is just by looking up a URL and doing some sanity checks. now to be clear, the dongle doesn't do this. this is entirely for the broweser/application/OS to decide if an untrusted website or app is allowed to auth using a token for a broader app

jookia reads fido2 specs: fido u2f 

so yeah, you register using the application ID (not the facet) and a hash of the challenge parameter. the challenge includes the server's challenge, the facet ID, and channel ID. you get back a public key, a key handle, an attestation certificate, and a signature of the application, challenge, handle and public key. the server verifies this signature, so it can check if there's been some sketchy mitm shit

jookia reads fido2 specs: fido u2f 

as an aside, channel binding here takes the TLS key and uses that as part of the hash. this ensures the server and the client have a private TLS session regardless of any rogue CA. do browsers support this? apparently chrome does. apparently firefox doesn't

jookia reads fido2 specs: fido u2f 

not gonna lie, it's a bit weird seeing the channel ID here in the registration stuff. XMPP uses channel binding for every connection which is the right thing to do. this just uses it only once: when you register. like i get the idea but it only really secure registration, not actual use. ANYWAY MOVING ON

jookia reads fido2 specs: fido u2f 

U2F_AUTHENTICATE lets you ask authenticate a user. you send a challenge, the application identity, a key handle, and a control byte. control byte can ask to check if the device created a key for the application, and says yes or no. i guess to check if you already have a key enrolled. otherwise you can ask for a signature to prove the dongle has the key, with or without user presence.

you get back a signature and a counter. that counts how many times it's authed

jookia reads fido2 specs: fido u2f 

something interesting about this is that devices don't actually have to store multiple keys. they can just generate them deterministically each time they're needed by wrapping their single key. this kinda makes it weird for the counter? but apparently the counter can be global for all actual u2f auths

jookia reads fido2 specs: fido2 

so after a few years, fido u2f was replaced with fido2 ctap, the client to auth protocol. SO WHAT'S CHANGE? well, it uses a lot more webauthn terminology so i'll kind of be reading back and forth between those two standards as i go

jookia reads fido2 specs: fido2 

first off, no more AppIDs or facets. just a domain name. instead you have a data structure which includes human-readable text, URLs, and the domain name which is verified by the client. to register you includes user information like an identifier, and a bunch of human-readable nice stuff. then you have the key types you want (in preferred order)

Show newer
Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!