to appear at oakland 2019 true2f: backdoor-resistant ...stanford and google to appear at oakland...
Post on 11-Aug-2021
2 Views
Preview:
TRANSCRIPT
True2F: Backdoor-resistant authentication tokens
Emma Dauterman, Henry Corrigan-Gibbs, David Mazières, Dan Boneh, Dominic Rizzo
Stanford and Google
To appear at Oakland 2019
U2F: effective hardware 2FA
2
U2F: effective hardware 2FA
3
U2F protocol steps
1. Registration (associating a token with an account)
2. Authentication (logging into an account)
4
5
U2F Step #1: Registration
github.comgithub.com
pkgithub.com pkgithub.com
Associate a token with an account.
github.com
6
U2F Step #2: Authentication
github.com,challenge
signature signature
github.com,challenge
github.com
Log into an account.
7
github.com,challenge
github.com
Even if malware takes over your browser, it can’t authenticate without the token.
U2F defends against phishing and browser compromise
8
github.com
skadv
skadv
… but what about token compromise?
9
github.com
github.com
… but what about token compromise?
skadv
skadv
10
github.com
github.com github.com
… but what about token compromise?
skadv
skadv
11
github.com
github.com github.com
… but what about token compromise?
pkadv
skadv
skadv
12
github.com
github.com github.com
… but what about token compromise?
pkadv pkadv
skadv
skadv
True2F: enhancement of U2F
Goals of True2F:
- Augment U2F to protect against backdoored tokens- Strongest-link security between the token and the browser
- Backwards-compatible with existing U2F servers
- Performant on commodity hardware tokens
13
True2F: enhancement of U2F
Goals of True2F:
- Augment U2F to protect against backdoored tokens- Strongest-link security between the token and the browser
- Backwards-compatible with existing U2F servers
- Performant on commodity hardware tokens
14
Design principles for True2F:
- Both browser and token contribute randomness to the protocol.
- All deterministic token operations can be verified by the browser.
U2F protocol steps
1. Registration (associating a token with an account)
2. Authentication (logging into an account)
15
True2F protocol steps
0. Initialization (after purchasing a token)
1. Registration (associating a token with an account)
2. Authentication (logging into an account)
16
True2F protocol steps
0. Initialization (after purchasing a token)
1. Registration (associating a token with an account)
2. Authentication (logging into an account)
17
Approach: Both browser and token contribute randomness to the protocol.
18
Step #0: Initialization
mskmpk
collaborative key
generation
19
The token cannot bias the public key that the protocol outputs.
Collaborative Key Generation properties
[CMBF13]
20
The token cannot bias the public key that the protocol outputs.
The browser learns nothing about the secret key.
Collaborative Key Generation properties
[CMBF13]
21
Our Collaborative Key Generation protocol
22
Our Collaborative Key Generation protocol
23
Our Collaborative Key Generation protocol
24
Our Collaborative Key Generation protocol
25
Our Collaborative Key Generation protocol
26
Our Collaborative Key Generation protocol
27
Our Collaborative Key Generation protocol
28
Our Collaborative Key Generation protocol
29
Our Collaborative Key Generation protocol
The token cannot bias the public key that the protocol outputs.
30
Our Collaborative Key Generation protocol
The browser learns nothing about the secret key (except the public key).
True2F protocol steps
0. Initialization (after purchasing a token)
1. Registration (associating a token with an account)
2. Authentication (logging into an account)
31
True2F protocol steps
0. Initialization (after purchasing a token)
1. Registration (associating a token with an account)
2. Authentication (logging into an account)
32
Approach: All deterministic token operations can be verified by the browser.
33
Step #1: U2F Registration
github.comgithub.com
pkgithub.com pkgithub.com
Associate a token with an account.
github.com
34
evil.com
Supply-chain attack on U2F registration
35
evil.com
evil.com
Supply-chain attack on U2F registration
36
evil.com
evil.com
evil.com
Supply-chain attack on U2F registration
37
evil.com
evil.com
evil.com
pkevil.com ← f(skgithub.com)
Supply-chain attack on U2F registration
38
evil.com
evil.com
evil.com
pkevil.com
pkevil.com ← f(skgithub.com)
Supply-chain attack on U2F registration
39
evil.com
evil.com
evil.com
pkevil.com
pkevil.com ← f(skgithub.com)
pkevil.com
Supply-chain attack on U2F registration
40
evil.com
evil.com
evil.com
pkevil.com
pkevil.com ← f(skgithub.com)
pkevil.com
skgithub.com
Supply-chain attack on U2F registration
41
Verifiable Identity Families (VIFs)
mskmpk
Derive server-specific keypairs in a deterministic and verifiable way from a master keypair.
42
VIF properties
1. Unique: The token can produce the unique keypair for github.com.
43
VIF properties
1. Unique: The token can produce the unique keypair for github.com.
2. Verifiable: The token can prove to the browser that pk is really the unique public key for github.com.
44
VIF properties
VIF properties
1. Unique: The token can produce the unique keypair for github.com.
2. Verifiable: The token can prove to the browser that pk is really the unique public key for github.com.
3. Unlinkable: The VIF public key for github.com is indistinguishable from a random ECDSA public key.
45
VIF properties
1. Unique: The token can produce the unique keypair for github.com.
2. Verifiable: The token can prove to the browser that pk is really the unique public key for github.com.
3. Unlinkable: The VIF public key for github.com is indistinguishable from a random ECDSA public key.
4. Unforgeable: The browser cannot forge signatures under VIF-generated public keys.
46
47
VIF construction overview
github.com
mskmpk
48
VIF construction overview
github.com
mskmpk
github.com
49
VIF construction overview
github.com
mskmpk
github.comgithub.com
50
VIF construction overview
github.com
mskmpk
github.comgithub.com
VIF.Eval(msk, github.com) → (sk, pk, π)
51
VIF construction overview
github.com
mskmpk
github.comgithub.com
pk, π
VIF.Eval(msk, github.com) → (sk, pk, π)
52
VIF construction overview
github.com
mskmpk
github.comgithub.com
VIF.Verify(mpk, github.com, pk, π) → {0,1}
pk, π
VIF.Eval(msk, github.com) → (sk, pk, π)
53
VIF construction overview
github.com
mskmpk
github.comgithub.com
pk
VIF.Verify(mpk, github.com, pk, π) → {0,1}
pk, π
VIF.Eval(msk, github.com) → (sk, pk, π)
54
Simplified VIF construction
github.com
55
Simplified VIF construction
github.com
56
Simplified VIF construction
github.com
57
Simplified VIF construction
github.com
58
Simplified VIF construction
github.com
59
Simplified VIF construction
github.com
60
Simplified VIF construction
github.com
61
Simplified VIF construction
github.com
Unique: The token can produce the unique keypair for github.com.
62
Simplified VIF construction
github.com
Verifiable: The token can prove to the browser that pk is really the unique public key for github.com.
63
Simplified VIF construction
github.com
Unlinkable: The VIF public key for github.com is indistinguishable from a random ECDSA public key.
64
Simplified VIF construction
Verifiable Random Functions [MRV99], [DY05], [GRPV18]
github.com
Unlinkable: The VIF public key for github.com is indistinguishable from a random ECDSA public key.
65
Simplified VIF construction
Verifiable Random Functions [MRV99], [DY05], [GRPV18]
github.com
Unforgeable: The browser cannot forge signatures under VIF-generated public keys.
66
evil.com
evil.com
evil.com
pkevil.com
pkevil.com ← f(skgithub.com)
Browser verifies public key
True2F protocol steps
0. Initialization (after purchasing a token)
1. Registration (associating a token with an account)
2. Authentication (logging into an account)
67
True2F protocol steps
0. Initialization (after purchasing a token)
1. Registration (associating a token with an account)
2. Authentication (logging into an account)
68
Approach: Both browser and token contribute randomness to the protocol.
69
Step #2: U2F Authentication
github.com,challenge
signature signature
github.com,challenge
github.com
Log into an account.
70
evil.com
signature signature
Supply-chain attack on U2F authentication
evil.com,challenge
evil.com,challenge
Hide skgithub.com in signature
skgithub.com
71
evil.com
signature signature
Supply-chain attack on U2F authentication
evil.com,challenge
evil.com,challenge
Hide skgithub.com in signature
ECDSA signatures are not unique.
Unique signatures: [BLS04]Subliminal channels: [Sim84], [Des88]
skgithub.com
Firewalled ECDSA Signatures
Two ideas:
1. The token and browser use collaborative key generation to generate a signing nonce.
2. Because of ECDSA malleability, signatures are re-randomized by the browser.
… see paper for details.
72[AMV15], [MS15], [DMS16]
True2F protocol steps
0. Initialization (after purchasing a token)
1. Registration (associating a token with an account)
2. Authentication (logging into an account)
73
Other contributions (see paper)
- Flash-optimized data structure for storing U2F authentication counters- Provides stronger unlinkability than many existing U2F tokens- “Tear-resistant” and respects constraints of token flash
- Cryptographic optimizations tailored to token hardware- Offload hash-to-point to the browser- Cache Verifiable Random Function outputs at the browser
74
True2F implementation
75
Google production USB token with same hardware
specs.
Google development board running True2F.
ARM SC-300 processor clocked at 24 MHz
76
True2F imposes minimal authentication overheadCollaborative KeygenVIF.EvalECDSA.Sign
Browser
Toke
n
77
Collaborative KeygenVIF.EvalECDSA.Sign
Browser
Toke
n
True2F imposes minimal authentication overhead
78
Collaborative KeygenVIF.EvalECDSA.Sign
Browser
Toke
n
True2F imposes minimal authentication overhead
79
Collaborative KeygenVIF.EvalECDSA.Sign
Browser
Toke
n
True2F imposes minimal authentication overhead
80
Collaborative KeygenVIF.EvalECDSA.Sign
Browser
Toke
n
True2F imposes minimal authentication overhead
81
Collaborative KeygenVIF.EvalECDSA.Sign
Browser
Toke
n
True2F only ~2.5x slower than U2F
True2F imposes minimal authentication overhead
82
Comparatively small end-to-end slowdown
83
Comparatively small end-to-end slowdown
True2F only 12-16% slower than U2F
True2F: don’t settle for untrustworthy hardware
Emma Dautermanedauterman@cs.stanford.edu
https://arxiv.org/abs/1810.04660Paper to appear at Oakland 2019
84
True2F- Augments U2F to protect against backdoored tokens- Backwards-compatible with existing U2F servers
Practical to deploy: performant on commodity hardware tokens
Next step: FIDO standards body
References[ACMT05] G. Ateniese, D. H. Chou, B. De Medeiros, and G. Tsudik. Sanitizable signatures. In ESORICS, 2005.[BPR14] M.Bellare, K.G.Paterson,and P.Rogaway. Security of symmetric encryption against mass surveillance. In
CRYPTO, 2014.[BLS04] D. Boneh, B. Lynn, and H. Shacham. Short signatures from the Weil pairing. Journal of cryptology, 17(4),
2004.[Des88] Y. Desmedt. Subliminal-free authentication and signature. In EUROCRYPT, 1988.[DMS16] Y. Dodis, I. Mironov, and N. Stephens-Davidowitz. Message transmission with reverse firewalls—secure
communication on corrupted machines. In CRYPTO, 2016.[DY05] Y. Dodis and A. Yampolskiy. A verifiable random function with short proofs and keys. In PKC, 2005.[GRPV18] S. Goldberg, L. Reyzin, D. Papadopoulos, and J. Vcelak. Verifiable random functions (VRFs). IETF CFRG
Internet-Draft (Standards Track), Mar. 2018. https://tools.ietf.org/html/ draft-irtf-cfrg-vrf-01.[MRV99] S. Micali, M. Rabin, and S. Vadhan. Verifiable random functions. In FOCS, 1999.[MS15] I. Mironov and N. Stephens-Davidowitz. Cryptographic reverse firewalls. In EUROCRYPT, 2015.[Sim84] G. J. Simmons. The Prisoners’ Problem and the Subliminal Channel. In CRYPTO, 1984.
85
86
top related