To appear at Oakland 2019 True2F: Backdoor-resistant ...Stanford and Google To appear at Oakland...

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

Log into an account.

7


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


skadv

skadv

10

github.com

github.com github.com


skadv

skadv

11

github.com



pkadv

skadv

skadv

12

github.com



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



15

True2F protocol steps

0. Initialization (after purchasing a token)



16





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 browser learns nothing about the secret key.

Collaborative Key Generation properties

[CMBF13]

21

Our Collaborative Key Generation protocol

22


23


24


25


26


27


28


29



30


The browser learns nothing about the secret key (except the public key).





31





32

Approach: All deterministic token operations can be verified by the browser.

33

Step #1: U2F Registration


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


36

evil.com

evil.com

evil.com


37

evil.com

evil.com

evil.com

pkevil.com ← f(skgithub.com)


38

evil.com

evil.com

evil.com

pkevil.com



39

evil.com

evil.com

evil.com

pkevil.com


pkevil.com


40

evil.com

evil.com

evil.com

pkevil.com


pkevil.com

skgithub.com


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


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



3. Unlinkable: The VIF public key for github.com is indistinguishable from a random ECDSA public key.

45

VIF properties



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


github.com

mskmpk

github.com

49


github.com

mskmpk


50


github.com

mskmpk


VIF.Eval(msk, github.com) → (sk, pk, π)

51


github.com

mskmpk


pk, π


52


github.com

mskmpk


VIF.Verify(mpk, github.com, pk, π) → {0,1}

pk, π


53


github.com

mskmpk


pk

VIF.Verify(mpk, github.com, pk, π) → {0,1}

pk, π


54

Simplified VIF construction

github.com

55


github.com

56


github.com

57


github.com

58


github.com

59


github.com

60


github.com

61


github.com

Unique: The token can produce the unique keypair for github.com.

62


github.com

Verifiable: The token can prove to the browser that pk is really the unique public key for github.com.

63


github.com

Unlinkable: The VIF public key for github.com is indistinguishable from a random ECDSA public key.

64


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


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


Browser verifies public key





67





68

Approach: Both browser and token contribute randomness to the protocol.

69

Step #2: U2F Authentication


signature signature


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]





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


Browser

Toke

n


79


Browser

Toke

n


80


Browser

Toke

n


81


Browser

Toke

n

True2F only ~2.5x slower than U2F


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 [email protected]

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

To appear at Oakland 2019 True2F: Backdoor-resistant ...Stanford and Google To appear at Oakland...

Documents

Transcript of To appear at Oakland 2019 True2F: Backdoor-resistant ...Stanford and Google To appear at Oakland...