True2F: Backdoor-resistant authentication tokens Emma Dauterman , - PowerPoint PPT Presentation

True2F: Backdoor-resistant authentication tokens Emma Dauterman , Henry Corrigan-Gibbs, David Mazières, Dan Boneh, Dominic Rizzo Stanford and Google IEEE Security & Privacy 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

U2F Step #1: Registration Associate a token with an account. github.com github.com pk github.com pk github.com github.com 5

U2F Step #2: Authentication Log into an account. github.com , github.com , challenge challenge signature signature github.com 6

U2F defends against phishing and browser compromise Even if malware takes over your browser, it can’t authenticate without the token. github.com , challenge sk github.com github.com 7

… but what about vulnerabilities in the token itself? sk github.com github.com 8

… but what about vulnerabilities in the token itself? 1. Implementation bugs 2. Supply-chain tampering sk github.com github.com 9

Security threat #1: Implementation bugs in token [NSS+17] 10

Security threat #1: Implementation bugs in token [NSS+17] 11

Security threat #1: Implementation bugs in token [NSS+17] 12

Security threat #1: Implementation bugs in token [NSS+17] 13

Security threat #1: Implementation bugs in token [NSS+17] 14

Security threat #2: Supply-chain tampering 15

True2F: U2F protections + faulty-token protection 16

True2F: U2F protections + faulty-token protection U2F protection Browser learns no secrets. 17

True2F: U2F protections + faulty-token protection U2F protection Browser learns no secrets. True2F addition: Faulty-token protection Browser enforces correct behavior 18 to prevent token leaking secrets.

True2F: U2F protections + faulty-token protection Goals: ● Augment U2F to protect against faulty tokens ○ Same protections as U2F even if token is buggy or backdoored ● Backwards-compatible with U2F server ○ Only requires changes to token and browser, not server ● Practical on commodity hardware tokens ○ Evaluated on Google hardware 19

True2F: U2F protections + faulty-token protection Goals: ● Augment U2F to protect against faulty tokens ○ Same protections as U2F even if token is buggy or backdoored ● Backwards-compatible with U2F server ○ Only requires changes to token and browser, not server ● Practical on commodity hardware tokens ○ Evaluated on Google hardware Design principles: ● Both browser and token contribute randomness to the protocol. ● Browser can verify all deterministic token operations. 20

True2F implementation Google production USB token with same hardware specs. ARM SC-300 processor Google development clocked at 24 MHz board running True2F. 21

U2F protocol steps 1. Registration (associating a token with an account) 2. Authentication (logging into an account) 22

True2F protocol steps 0. Initialization (after purchasing a token) [New] 1. Registration (associating a token with an account) [Modified] 2. Authentication (logging into an account) [Modified] 23

True2F protocol steps 0. Initialization (after purchasing a token) [New] ➔ Ensure token master secret incorporates good randomness. 1. Registration (associating a token with an account) [Modified] 2. Authentication (logging into an account) [Modified] Principle: Both browser and token contribute randomness to the protocol. 24

Step #0: Initialization collaborative key generation 25

Step #0: Initialization collaborative key generation msk mpk 26

Initialization: Security properties The token cannot bias mpk. msk mpk [GJKR99], [CMBF13] 27

Initialization: Security properties The token cannot The browser learns bias mpk. nothing about msk. msk mpk [GJKR99], [CMBF13] 28

Initialization properties The token cannot The browser learns bias mpk. nothing about msk. Our protocol reduces the number of group operations by 3x compared to [CMBF13] (see paper). 29

True2F protocol steps 0. Initialization (after purchasing a token) [New] ➔ Ensure token master secret incorporates good randomness. 1. Registration (associating a token with an account) [Modified] 2. Authentication (logging into an account) [Modified] 30

True2F protocol steps 0. Initialization (after purchasing a token) [New] ➔ Ensure token master secret incorporates good randomness. 1. Registration (associating a token with an account) [Modified] ➔ Ensure per-site keys generated correctly. 2. Authentication (logging into an account) [Modified] Principle: Browser can verify all deterministic token operations. 31

Step #1: U2F Registration Associate a token with an account. github.com github.com pk github.com pk github.com github.com 32

Security threat #1: Implementation bugs in token github.com github.com pk github.com pk github.com Generate (sk github.com , github.com pk github.com ) using weak randomness Bad randomness in embedded devices: [EZJ+14], [LHA+14], [NDWH14], [YRS+09] 33

Security threat #2: Supply-chain tampering evil.com evil.com pk evil.com pk evil.com pk evil.com ← f(sk github.com ) evil.com sk github.com ← f -1 (pk evil.com ) 34

Verifiable Identity Families (VIFs) mpk msk Derive server-specific keypairs in a deterministic and verifiable way from a master keypair. 35

Verifiable Identity Families (VIFs) mpk msk Formally, we prove that VIFs are unique , verifiable , unlinkable , and unforgeable . 36

Contribution: Simple (weak) VIF construction mpk msk github.com 37

Contribution: Simple (weak) VIF construction github.com 38

Contribution: Simple (weak) VIF construction github.com 39

Contribution: Simple (weak) VIF construction github.com 40

Contribution: Simple (weak) VIF construction github.com Unique: The token can produce the unique keypair for github.com . 41

Contribution: Simple (weak) VIF construction github.com Verifiable: The token can prove to the browser that pk github.com is really the unique public key for github.com . 42

Contribution: Simple (weak) VIF construction github.com Unforgeable: The browser cannot forge a signature under pk github.com . 43

Contribution: Simple (weak) VIF construction github.com Weak unlinkability: github.com cannot distinguish pk github.com from a random ECDSA public key. 44

Contribution: Simple (weak) VIF construction github.com Full unlinkability: Informally, browser cannot generate public keys without the token (see paper). 45

True2F protocol steps 0. Initialization (after purchasing a token) [New] ➔ Ensure token master secret incorporates good randomness. 1. Registration (associating a token with an account) [Modified] ➔ Ensure per-site keys generated correctly. 2. Authentication (logging into an account) [Modified] 46

True2F protocol steps 0. Initialization (after purchasing a token) [New] ➔ Ensure token master secret incorporates good randomness. 1. Registration (associating a token with an account) [Modified] ➔ Ensure per-site keys generated correctly. 2. Authentication (logging into an account) [Modified] ➔ Ensure authentication leaks no data. Principle: Both browser and token contribute randomness to the protocol. 47

Step #2: U2F Authentication Log into an account. github.com , github.com , challenge challenge signature signature github.com 48

Security threat #1: Implementation bugs in token github.com , github.com , challenge challenge signature signature Choose signing nonce with github.com weak randomness Bad randomness in embedded devices: [EZJ+14], [LHA+14], [NDWH14], [YRS+09] 49

Security threat #2: Supply-chain tampering github.com , github.com , challenge challenge signature signature Hide sk github.com in evil.com signature Subliminal channels: [Sim84], [Des88] Unique signatures: [BLS01] 50

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. [AMV15], [MS15], [DMS16] 51

True2F protocol steps 0. Initialization (after purchasing a token) [New] ➔ Ensure token master secret incorporates good randomness. 1. Registration (associating a token with an account) [Modified] ➔ Ensure per-site keys generated correctly. 2. Authentication (logging into an account) [Modified] ➔ Ensure authentication leaks no data. 52

Other contributions (see paper) ● Cryptographic optimizations tailored to token hardware ○ Offload hash-to-point to the browser ○ Cache Verifiable Random Function outputs at the browser ● 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 53

Multiple Browsers 1. Token gives mpk to browser (protect against bugs) 2. Sync mpk across browser instances 54

True2F evaluation Google production USB token with same hardware specs. ARM SC-300 processor Google development clocked at 24 MHz board running True2F. 55