Password Authenticated Key Exchange for Practical Password Security

Password Authenticated Key Exchange for Practical Password Security Prof. Stanislaw Jarecki, ICS, UCI (95% of this talk is a Ph. D defense of my student, Tatiana Bradley, which she defended yesterday!) December 2, 2020 Donald Bren School of Information and Computer Science University of California, Irvine

About Me • I have been a professor at UCI since 2003, my field is cryptography • I started working on cryptography as an undergrad at MIT, 1991 -1995 • internship at IBM Labs computational linguistic distributed algorithms crypto… • I worked on cryptography as MIT Ph. D student, 1996 -2000 • worked with Shafi Goldwasser, but wrote many papers with postdocs and other students… • Then joined a research-focused start-up “Intertrust” in Sillicon Valley • but it collapsed within a year: 2001 crisis! • Then worked as a postdoc at Stanford, with Dan Boneh, 2002 -2003 • Then joined UCI in 2003… 2

Examples of My Areas of Research on Crypto • Threshold Cryptography Can a private key of a cryptosystem (e. g. RSA) be split among n computers s. t. • any > n/2 of them can decrypt/sign • but compromise of any <n/2 of them does not leak the key! Applications? Protecting cryptographic server keys in industry and military; Distributing trust (blockchains…) • Secure Computation Can there be efficient algorithms that allow a group of n computers to compute arbitrary computation on joined data revealing only the computation output? Example: Find intersection between two datasets, one held by UCI and one held by UCLA, without revealing anything else to either party Applications? Privacy-protecting computation, e. g. between agencies, companies, and users, protecting data privacy (e. g. genomic computation!) • Signature (or Encryption) Aggregation Can one combine signatures from n parties into O(1)-sized aggregate signature which can be verified in O(1) time as signature of all n parties? Applications? Blockchains! • Covert Computation Can we have secure computation (including e. g. authentication or routing messages) which looks indistinguishable from random bits even to active man-in-the-middle attackers? Applications? Censorship-avoidance, like TOR [protocol messages can be covertly embedded into random sources like lower-order bits of images] • Authentication Privacy and Security 3

Talk Overview Intro to Password Authenticated Key Exchange (PAKE) and Universally Composable Security Solution Example: Strong Asymmetric PAKE based on Trapdoor Conditional Key Agreement 4

Setting 1: Persistent Password charles. com LOGIN Intern et Ada (User) charles. com server L 0 ve. L 4 ce User Password Alan tu. R 1 n. G Ada L 0 ve. L 4 ce Grace h 0 pp 3 r Whitfield d 1 ff 13 5

Setting 2: One-time password oth Ada o Bluet Type the code to connect your keyboard z. D 3 h. N 7 6

Internet But what is happening over Bluetooth ? By default, they are insecure networks, so we can’t just send passwords back and forth… Let’s look at a cryptographic solution: PAKE 7

Password Authenticated Key Exchange (PAKE) Goal: Establish shared key and “prove” identity Ada Charles PAKE 8

(Brief and partial) Overview of PAKE results • Two prominent PAKE construction paradigms 1. Password-Blinded Diffie-Hellman protocols [BM 92, BMP 00, . . ] • Most efficient PAKEs in ROM: SPEKE [Jab 96], SPAKE 2 [AP 05], TBPEKE [PW 17], CPace [HL 19] 2. Encrypt + Projective. Hash [KOY 01, GL 03, JG 04, CHK+05, GK 10, KV 10, ………] • Standard model (no ROM), but less efficient • Implication in practice • No real adoption for a long time • Internet needs asymmetric (client-server) PAKEs One of my results: In ACNS’ 19 we show PAKE variant, “passwordauthenticated encryption”, which makes symmetric PAKE robust against communication failures (security of protocol message reuse) • Symmetric PAKEs still useful for Internet-of-Things? (the Bluetooth example) • 2019 - 2020: IETF CRFG competition on PAKEs Coming up: In Crypto’ 19 we show asymmetric PAKE that beats OPAQUE in rounds (=2 instead of 3) with small computational cost increase • Symmetric PAKE finalists: SPAKE 2 and CPace (winner: CPace) • Asymmetric PAKE finalists: OPAQUE and Au. CPace (winner: OPAQUE [Jarecki, Krawczyk, Xu]) • Active efforts on security validation, prototyping, testing, integration with TLS

PAKE security models • Game-based [BPR 00, …] vs. Universally Composable (UC) [CHK+05] • UC PAKE model is stronger • Allows arbitrary protocol composition • Naturally models arbitrary password distributions • Models password reuse, password mistypes, partial password information disclosure, & more • UC viewed as gold standard for analysis, including in the IETF CFRG competition • Utility of protocol composition: compiler results! • UC PAKE UC a. PAKE • UC a. PAKE UC strong a. PAKE [GMR 06, HJK+18] [JKX 18] If time allows: In Crypto’ 20 we show that all these practical PAKEs are UC secure realizations of a (minimally) modified ideal PAKE security notion • The most efficient PAKEs (SPEKE, SPAKE 2, TBPEKE, CPace) only proven game-based secure • …yet no explicit attacks on any of them were shown • SPAKE 2 and CPace are IETF symmetric PAKE competition finalists! 10

Chapter 3 Strong Asymmetric PAKE based on Trapdoor CKEM Stanisław Jarecki Tatiana Bradley Jiayu Xu UC Irvine (now at George Mason University) * Originally presented by Tatiana at CRYPTO 2019

This talk • The problem: Password-Authentication over the Internet • Can crypto help us do better? (Of course!) • Our solution: Strong Asymmetric Password-Authenticated Key Exchange • Building blocks • Salted Tight One-Way Function • (Implicit-Statement) Conditional Key Encapsulation Mechanism • Construction • Open Questions 12

Ada’s password file Password Authentication Practice: “Password-over-TLS” Problem 1: random salt H(salt, pw) PKI attacks possible ✗ pk, cert valid? Ada (Client) Input: pw, CA public key pk sk TLS Charles (Server) Input: (sk, pk, cert), password file k k c pw’ = Dec(k, c) Problem 2: Cleartext password on server ✗ H(salt, pw’) =? H(salt, pw) 13

Can crypto help us do password-authentication better? First attempt: Password-Authenticated Key Exchange (PAKE) Informal [BM 92, Jablon 96…] Game-Based [BPR 00, BMP 00, KOY 01, AP 05, GL 03, …] Universally Composable (UC) [CHKLM 05, …] 14

Password Authenticated Key Exchange (PAKE) Goal: Establish shared key and “prove” identity Server does not get Ada’s pw in the clear during protocol ✓ Ada Charles PAKE No PKI attacks ✓ …but server stores pw’ in the clear ✗ 15

Can crypto help us do password-authentication better? Second attempt: Asymmetric PAKE (a. PAKE) Informal [BM 93, …] Game-based [BP 13, …] UC [GMR 06, JR 16, HJKLX 18, …] 16

Asymmetric PAKE (a. PAKE) Offline dictionary attack (ODA) required to learn pw from z ✓ Ada No PKI attacks ✓ Server never sees cleartext pw ✓ Ada’s password file Charles a. PAKE …but computation for ODA can be done BEFORE server compromise ✗ 17

Can crypto help us do password-authentication better? Doing it better: Strong Asymmetric PAKE (a. PAKE) Introduced recently by [JKX 18] 18

Strong Asymmetric PAKE Ada’s password file random salt s No ODA pre-computation ✓ Ada No PKI attacks ✓ Server never handles cleartext pw ✓ ODA required to learn pw ✓ Charles sa. PAKE Finally, an option strictly stronger than Password-over-TLS! 19

Strong a. PAKE: Our Contribution vs. Previous Work • Current de-facto standard: Password-over-TLS • Benefits: Standard, efficient, modular • Problems: reliance on PKI, server handles cleartext password • OPAQUE [JKX 18] • UC strong a. PAKE, password-only (independent of PKI) • 3 -rounds, interactive assumption “One More DH” on prime-order group + ROM • Our Contribution: new UC strong a. PAKE • • 2 rounds, similar number of exps, but no hash onto group Requires SDH + DDH + ROM + UC Tight OWF assumption on algebraic OWF (GGM) New tool: “Implicit-Statement” Conditional KEM (≈ CCA-secure SPHF) New paradigm for PAKE: CPA Enc + CCA-Secure SPHF in one direction only 20

Tool 1: Salted Tight One-Way Function 21

Tool 2: Smooth Projective Hash Function (SPHF) • • • Let L be a “language”, i. e. a well-defined set of bitstrings Think of LPK = { (pwd, c) s. t. c = Enc. PK(pwd; r) for some random r} Bitstring x=(pwd, c) is called a statement in the language LPK if x LPK If Enc is secure randomized encryption, then it’s infeasible to decide if (pwd, c) is in L PK Except if you created c= Enc. PK(pwd; r), in which case w=r is a witness for (pwd, c) in LPK Ada SPHF Charles 22

Building sa. PAKE Start with CPA Enc + SPHF paradigm for PAKE [KOY 01, GL 03. . . ] 23

Building sa. PAKE CPA Enc + SPHF paradigm for a. PAKE + TOWF [BP 13, JR 18] 24

Building sa. PAKE CPA Enc + SPHF paradigm + STOWF for sa. PAKE 25

Building sa. PAKE CPA Enc + SPHF paradigm + STOWF. for sa. PAKE We need more features: 1. CCA-security 2. Ability to carry statement as encrypted payload Implicit-Statement CKEM 26

Similar to Implicit Zero Knowledge [BPPW 15] Implicit-Statement Trapdoor Conditional Key Encapsulation Mechanism (CKEM) Goal: establish shared key if statement in language L, and one party has witness Sender Statement privacy: x is hidden without w Receiver Trapdoor Receiver (Simulator) Simulation Soundness (think CCA): k appears random if x is not in language L, even in presence of TRec oracle 27

Implicit-Statement Trapdoor CKEM from SPHF in ROM Sender Receiver Think Fujisaki-Okamoto [FO 99] transform from CPA to CCA PKE: Ciphertext carries encryption randomness and statement “Non-Malleable SPHF” 28

Construction: sa. PAKE from TCKEM+STOWF in ROM • Ada authenticates to Charles by CKEM security: statement x must be correct if she decrypts • Charles authenticates to Ada by including his encrypted password file (s, z) in CKEM payload 29

Construction: sa. PAKE from TCKEM+STOWF in ROM • Ada authenticates to Charles by CKEM security: statement x must be correct if she decrypts • Charles authenticates to Ada by including his encrypted password file (s, z) in CKEM payload 30

Conclusions and Some Open Questions Summary: • Two-round UC strong asymmetric PAKE from PKE + SPHF + STOWF in ROM • Efficient Instantiation: 1 -2 v. b. exp / party from s. DH+DDH+ROM + GGM for STOWF • Tool: Implicit-Statement Trapdoor CKEM ( CCA-secure & private SPHF) Some Questions: • • • Other Strong Tight OWF constructions, from alternative assumptions/models? Tight OWF without idealized computational model (like GGM and ROM)? One-round sa. PAKE? (on-going work) Trapdoor CKEM following DHIES instead of Fujisaki-Okamoto? Extensions: T-PAKE? Two-Factor Authentication? Integration with TLS? 31

Chapter 4 Universally Composable Relaxed Password Authenticated Key Exchange Michel Abdalla Manuel Barbosa Tatiana Bradley École normale supérieure FCUP UC Irvine INRIA INESC TEC Stanisław Jarecki Jonathan Katz Jiayu Xu* UC Irvine George Mason University * Originally presented by Jiayu at CRYPTO 2020

Our results: 1. We define two relaxations of UC PAKE functionality of [CHK+05] • lazy-extraction UC PAKE • stronger variant: relaxed UC PAKE (le. PAKE) (r. PAKE) 2. SPAKE 2, TBPEKE, SPEKE, CPace all realize UC le. PAKE in ROM • SPAKE 2 with tight(*) relation to Gap DH assumption • TBPEKE under Gap DH & Gap Simultaneous DH assumptions [PW 17] • implies same level of security for SPEKE and CPace 3. Standard key confirmation converts UC le. PAKE to UC r. PAKE • in addition to providing explicit entity authentication 4. Sanity check: any UC r. PAKE is game-based secure with PFS • bonus: any UC le. PAKE is game-based secure with weak PFS (*) : Simulator’s work Protocol’s cost + O(q. RO) group operations 33

Key observation: UC PAKE functionality of [CHK+05] requires the simulator to • extract a password which the adversary effectively uses in its PAKE messages • before session completes, i. e. , before attacked party outputs a key • the simulator then learns a bit (= correct guess / wrong guess) 34

SPAKE 2 g: group generator M, N: random group elements H: hash function (= RO) Pedersen commitment to password (IT hiding, no extraction) Can extract password here? 36

Proposed relaxation of UC PAKE model: allow “Post-Execution Input Extraction” • Allow password extraction after session completes • after honest session key is computed no more protocol messages… • yet extraction possible from adversary’s local computation! • requires idealized computation models: e. g. Random Oracle or Ideal Cipher • Allows only one post-execution password test query per session • as in UC PAKE, the adversary cannot test >1 passwords on an attacked session • Two relaxation flavors: • “lazy-extraction” PAKE : the adversary learns a session key (= real / random) • “relaxed” PAKE : the adversary learns a bit (= correct guess / wrong guess) 37

Active Attack w/o on-line password extraction Post-execution password extraction here “Lazy-Extraction” PAKE: adversary gets real/random key “Relaxed” PAKE: adversary gets only correct/wrong bit 38

Thm 1: SPAKE 2 realizes UC le. PAKE in ROM under Gap DH (with tight reduction) g: group generator M, N: random group elements H: hash function (= RO) 39

Theorem: SPAKE 2 realizes UC le. PAKE in ROM under Gap DH (with tight reduction) Ada (simulated) ~~~~~ g: group generator M, N: random group elements H: hash function (= RO) Charles (adversary) 40

Adding explicit authentication Ada Charles PAKE 41

Theorem: UC le. PAKE + Key Conf. ⇒ UC r. PAKE with Explicit Authentication Lazy-Extraction PAKE 42

Thm 2: UC le. PAKE + Key Conf. ⇒ UC r. PAKE with Explicit Authentication Charles (adversary) Ada (simulated) ~~~~~ Lazy-Extraction PAKE Functionality If Adv doesn’t query (Late. Test. Pwd, pw. C) to Fle. PAKE s. t. pw. C=pw. A then k. A is hidden and attacked session aborts 43

Model Validation: Perfect Forward Secrecy (PFS) • PFS security: After party corruption, previous sessions are still secure • PFS security for PAKEs: Future revealing of password does not endanger security of past sessions • Thm 3: UC r. PAKE ⇒ game-based PAKE with PFS Proof analogous to UC PAKE ⇒ game-based PAKE with PFS in [CHK+05] • Also: UC le. PAKE ⇒ game-based PAKE with weak PFS 44

Related Results • Some prior appearances of “lazy input extraction” UC models • UC Oblivious PRF [JKK 14]: unbinds online/offline evaluation allows post-execution extraction • relaxed asymmetric UC PAKE in OPAQUE [JKX 18, e. Print] (post-execution extraction due to UC OPRF!) • Concurrent result by Victor Shoup [e. Print 2020/313] UC security of SPAKE 2 and asymmetric SPAKE 2 extension using equivalent UC PAKE model relaxation − non-modular analysis (requires key confirmation) − uses weaker version of Gap DH: DDH oracle with fixed DH exponent • Recent result by Ian Mc. Quoid, Mike Rosulek, and Lance Roy 2 -round Feistel realizes “one-time Ideal Cipher” in ROM, suffices for EKE to realize (standard) UC PAKE − bandwidth increase, 2 hash-onto-curve ops (none in SPAKE 2), 1 fixed-based exp (vs. 3 in SPAKE 2) − non-tight security reduction to DDH (vs. tight relation to Gap DH in SPAKE 2) 45

Conclusions • Main Result: Practical PAKEs realize lazy extraction UC PAKE functionality • Including SPAKE 2, TBPAKE, SPEKE, CPace (all in ROM) • SPAKE 2 and CPace finalists in IETF CFRG PAKE competition • Adding key confirmation adds explicit authentication • and strengthens the model to relaxed UC PAKE (= post-execution extraction attack only reveals a correct guess / wrong guess bit) • Model validation: Every UC r. PAKE is game-based PFS-secure • One open question: Is UC lazy-extraction PAKE weaker than UC PAKE ? • We have some preliminary results but no general answer 46