The document summarizes the FIDO U2F security standard for two-factor authentication. It describes how U2F works by having a single authentication device that can be used across multiple services. When a user wants to log in, their U2F device signs a challenge from the website to prove the user is present, with the signature verified by the website. The document outlines the U2F protocol and APIs, explaining the registration and authentication flows. It also provides guidance for websites wanting to implement U2F login and manufacturers wanting to produce U2F security keys.
2. The U2F solution: How it works
● One device, many services
● Easy: Insert and press button
● Safe: Un-phishable Security
3. U2F Protocol
Core idea: Standard public key cryptography:
● User's device mints new key pair, gives public key to server
● Server asks user's device to sign data to verify the user.
● One device, many services, "bring your own device" enabled
Lots of refinement for this to be consumer facing:
● Privacy: Site Specific Keys, No unique ID per device
● Security: No phishing, man-in-the-middles
● Trust: Verify who made the device
● Pragmatics: Affordable today, ride hardware cost curve down
● Speed for user: Fast crypto in device (Elliptic Curve)
Think "Smartcard re-designed for modern consumer web"
8. proofThatUserIsThere
“I promise a user is here”,
“the server challenge was: 337423”,
“the origin was: accounts.google.com”,
“the TLS connection state was: 342384”
Signed
9. proofThatUserIsThere
“I promise a user is here”,
“the server challenge was: 337423”,
“the origin was: accounts.google.com”,
“the TLS connection state was: 342384”
Signed
this is where the key is
this guy knows the key
16. U2F Token
FIDO Client/
Browser
Relying
Party
app id, challenge
a; challenge, origin, channel id, etc.
c
a
check
app id
generate:
key kpub
key kpriv
handle h
kpub, h, attestation cert, signature(a,c,kpub,h)
c, kpub, h, attestation cert, s
store:
key kpub
handle h
s
Registration
cookie
17. U2F Token
FIDO Client/
Browser
Relying
Party
handle, app id, challenge
h, a; challenge, origin, channel id, etc.
c
a
check
app id
retrieve:
key kpriv
from
handle h;
counter++
counter, signature(a,c,counter)
counter, c, s
check:
signature
using
key kpub
s
h
retrieve:
key kpub
from
handle h
Authentication
set cookie
18. What if…
...I want to accept U2F logins?
● Browser: Call JS APIs
o available in Google Chrome, others need extensions
● Server: Implement registration flow
o decide how to handle attestation certificates
o verify registration response
o store public key, key handle with user account
● Server: Implement login flow
o check username/password, look up key handle
o verify authentication response (origin, signature, counter, …)
● Check your account recovery flow
19. What if…
...I want to offer a USB U2F token?
● Implement ECDSA P-256
● Implement counter
● Decide on key handle strategy
o must recover private key, app id
● Implement USB framing spec
● No responses without user presence!
o (with one exception)
o check that app id matches
20. Coming Soon
● Other platforms: browsers on Android, etc.
● Other platforms: native apps on Android, etc.
● Other message framing: BLE, NFC, etc.
● Other plugin mechanisms: ASM