Pinned post

what stream content of mine do you enjoy? (select all applicable)

fido ctap 2.1 interesting changes 

back to fido dongle shit, let's see what's new in fido ctap 2.1

first things first, the 'user verification' option key is deprecated. ctap 2 requires devices to verify the user anyway so uv is kind of redundant. HOWEVER, fido 2.1 authenticators may allow creating non-discoverable credentials without user verification

fido, predefined values 

there's a lot of authentication algorithms, mostly standard. one is optional: 'Chinese SM2 elliptic curve based signature algorithm combined with SM3 hash algorithm [OSCCA-SM2][OSCCA-SM3].'

Show thread

fido, predefined values 

confirmation for registering/authenticationg is done as a transaction, TRANSACTION_CONFIRMATION_DISPLAY can be any/privileged_software/tee/hardware/remote

Show thread

fido, predefined values 

KEY_PROTECTION lets you specify software/hardware/tee (trusted execution environment)/secure_element/remote_handle (for wrapped keys)

MATCHER_PROTECTION is the same but for how the verification is done. software/tee/on_chip is supported

ATTACHMENT_HINT explains how something is attached, so internal/external/wired/wireless/nfc/bluetooth/network/ready/wifi_direct

Show thread

fido, predefined values 

passcodes and patterns can be handled by the authenticator or with help from a host system. so like, entering your passcode on the device by pressing buttons, or on the computer by typing and sending the code to the device.

i really don't know how i feel about requiring specific verification when some of them may not be available to all users. HOPEFULLY websites and stuff won't gatekeep to specific devices and methods

Show thread

fido, predefined values 

so fido actually has a registry of PREDEFINED VALUES which are used in their protocols, so let's have a peek. USER_VERIFY constants are a bitmask that lets you ask for a specific verification. this allows: presence, fingerprint, passcode, voiceprint, faceprint, location, eyeprint (ouch), pattern, handprint, pattern.

Show thread

fido uaf, tls 

"TLS Extended Master Secret Extension [RFC7627] and TLS Renegotiation Indication Extension [RFC5746] should be used to protect against MITM attacks."

"The use of the tls-unique method is deprecated as its security is broken, see [TLSAUTH]."

honestly this is WAY too specific for a standard, especially for 'SHOULD' requirements

Show thread

fido uaf, tls 

"TLS Client and Server should use TLS v1.2 or newer and should only use TLS v1.1 if TLS v1.2 or higher are not available. The "anon" and "null" TLS crypto suites are not allowed and must be rejected; insecure crypto-algorithms in TLS (e.g. MD5, RC4, SHA1) should be avoided [SP800-131A] [RFC7525]."

i think this is fair for a standard, though it's a bit sketch allowing anything lower than TLS v1.2. Ideally TLS v1.3 would be the minimum but we're not there yet

Show thread

fido uaf, tls 

FIDO UAD client and FIDO Server auth require protected TLS communication. the rules here are a little bit interesting.

the server endpoint of the TLS must be the 'Relying Party', so the website. so there's no room here for company proxies fucking you up i think

the client endpoint might be the FIDO UAF client OR the app. that gives some room for out of band communication

Show thread

fido uaf, tls certificates 

one interesting thing is 'tlsServerCertificate'. this isn't actually channel binding but instead just the certificate. this seems like a good approach IF BROWSERS SUPPORTED IT WHY

i hate browsers

Show thread

fido uaf, channel binding 

the protocol doesn't look particularly exciting especially if you've read the fido2 ctap spec. it's just a bit more generalized. so what's the juicy deets?

well, multiple channel bindings are supported. token binding, tls channel ID, tlsUnique, tlsServerCertificate, serverEndPoint. now web browsers seem to legitimately hate channel binding so none of this is useful.

Show thread

fido uaf 

so the idea is that the browser or app talks to the fido uaf client which talks to the authenticators. so its a daemon i guess. then the app/browser speak the UAF protocol between client and server

the message flow goes that you log in to a server, asks for specific types of auth methods (fingerprint, dongle, face, TPM, voice) and the user selects them and then registers with it

the same thing happens for authentication

Show thread

fido uaf 

so like, should you be using fido2 dongles over USB/NFC/etc directly? MAYBE. in linux there's libfido2 for this.

but what about non-dongles? TPMs? biometrics built in to machines? would be cool to just have some unified framework for looking at these devices and using them right?

i mean kinda i don't give a fuck but apparently others do so lets look at the FIDO UAF protocol, universal authentication framework!

fido 2.1 stuff 

i'm looking a little bit through the fido 2.1 spec. i might (read: probably) will go through it and look at what's changed that i care about and post here

fido2 HOT DRAMA 

it's hilarious and sad to me how fascist windows is with its policies. just let applications use USB damnit

Show thread

fido2 HOT DRAMA 

gee i wonder how fido2 is on windows- *opens door to find everything on fire* we'll check back on it in a bit

so windows doesn't actually let you use fido2 directly, it requires going through Windows Hello which hides certain extensions. this is currently the bane of why things like KeePass don't support it, because Windows doesn't expose hmac-secret, despite using it for their disk unlocks

fido 2.1 

It's nice that in the FIDO 2.1 CTAP spec they explicitly list that hmac-secret must work with non-residential keys too. In fact the terminology now that makes it clear that 'resident keys' are meant to mean 'discoverable keys', not 'stateful or saved on the device keys'. So there's still a lot of intention to make it so key wrapping is used to generate keys at runtime, which is a pretty good move.

fido2 hmac-secret 

as a side note, generally encrypted disks and stuff don't use this key directly. there's a big random master key, and various key slots. each slot encrypts a copy of the master key, so multiple slots can decrypt it.

Show thread

fido2 hmac-secret 

so with hmac-secret it works like this:

- you generate a random, public salt
- you ask the authenticator to hash your salt with its secret key
- you use the resulting hash as a key to encrypt/decrypt

without the secret key you can't get the resulting hash

this is basically the same as entering a password for disk decryption i think, but the password hash is off-device

Show thread

fido2 hmac-secret 

the only times i've heard of this type of hashing (HMAC) is for message authentication codes: when sending encrypted messages you hash the message with your shared secret key, and then the other party will hash the message with their shared secret key and confirm it matches as a form of authentication

Show thread
Show older
Mastodon

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