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).

Follow

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)

jookia reads fido2 specs: fido2 

OPTIONS stuff: a list of credentials that the device should check and abort if it contains (to prevent duplicates), EXTENSIONS, OPTIONS, and pin tokens (you enter a pin on the computer and if its correct you get a token to avoid re-entering). webauth extensions include support for u2f, printing things on the screen, user verification indexes (ie to make sure the same user verified, big privacy bad tho), location, and user verification methods

jookia reads fido2 specs: fido2 

anyway ctap supports two options: resident key (store the key on the device) and user verification (make sure the user verifies using a button, fingerprint, PIN, etc). my u2f token for example can't handle resident keys as it doesn't store keys at all.

you get back on success auth data and an attestation statement that says 'this device manufactured by this company created this'. not gonna lie, A BIT CLOSE TO DRM. anyway what's in the auth data?

jookia reads fido2 specs: fido2 

you get a hash of the server url or domain or whatever the fuck identities are, you get some flags (was the user present? verified? is there extensions? was this attested?), the signature counter. the spec does say that the signature counter should be scoped to prevent correlating users, which makes sense

jookia reads fido2 specs: fido2 

so next up is authenticatorGetAssertion which has client data, the domain, an allow list for which credentials are accepted, extensions, options, pins, etc. its the same thing basically. you get back the auth data, a signature, the credential, user account info(given during registration, omitted for U2F), and number of credentials for the domain. some of those are optional.

jookia reads fido2 specs: fido2 

it is worth nothing that in webauthn, you can store public keys using wrapping like u2f keys do, or persistent storage. basically this works by having the server store an encrypted key, and the authenticator takes it as part of the auth process, decrypts, then signs. sneaky and smart. a big difference here is that you can't discover credentials if they aren't stored

jookia reads fido2 specs: fido2 

authenticatorGetNextAssertion lets you get an assertion for the next credential in the list asked by the server. this happens if you have multiple keys you can auth i guess?

authenticatorGetInfo lets you discover the versions of supported protocols, extensions, AAGUID, options, max message size, and pin protocols. options include whether it can store keys, do a pin, verify user using biometrics.

jookia reads fido2 specs: fido2 

wait, AAGUID? that's actually the per-model UUID for the device. so you could blacklist certain broken authenticators server-side. that's fine, but this may be hidden so i dunno. seems fine.

ANYWAY, authenticatorClientPIN! it's kind of weird because it uses a sharedSecret here. this function lets you set/change/get pins and gives you a token to avoid dealing with sharedSecrets later

jookia reads fido2 specs: fido2 

oops, you can't get the pin itself- you get the token. there's also authenticatorReset which is kinda of under defined.

EXTENSION: hmac-secret. a key on the authenticator and the platform both have two halves of a secret. if authenticated, you can get the authenticator's half. neat

jookia reads fido2 specs: token binding 

you heard me talk about channel binding before, but the cool new thing is TOKEN BINDING. token binding's idea is that you send with each request a proof that you have the private TLS key. neat. clients keep a private key for the actual binding, and i'm guessing webauthn would auth the client key- oh, it's gone. chrome ditched it, firefox never implemented it. why???????

jookia reads fido2 specs: token binding 

like i'm semi-convinced browsers deliberately just don't implement any kind of usable client to server auth because the NSA hates it

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!