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,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