Key Exchange Using Passwords and Long Keys

1. Key Exchange Using Passwords and Long Keys Vladimir Kolesnikov Charles Rackoff Comp. Sci. University of Toronto

2. Communication Setting … Full Control Insecure network

3. Secure Communication from Shared Random Key Trusted Party k 2R DK • Simple • Very efficient k22R DK Trusted Party

4. Key Exchange (KE) A protocol between two parties • Both output (the same) randomly chosen k 2 DK Security • Adv does not know anything about k even if it sees all other exchanged keys • Adv cannot mismatch players • If Alice instance ``thinks’’ she exchanged a key with Bob, then at most one instance of “Bob talking to Alice” may have the same key • Players must have secret credentials

5. Defining KE • Large amount of prior work • An intuitive notion, but hard to define • We want our definition to: • Be intuitive and easy to use • Reject “bad” protocols (allow powerful adversaries) • Accept “good” protocols (avoid unnecessary restrictions)

6. Simulation Style KE Definition Ideal Real ¼ 8 9 • Powerful • But complicated

7. Game Style KE Definition Plays the game: • challenge a completed • honest player • Challenge: • Present either a key • or a random string • Adversary guesses which • Should not do too well • Seems to be almost as powerful • Self-contained • Simpler

8. Our Setting • Asymmetric – Server (e.g. Bank) and Clients • Large secure storage • of credentials • Key on storage card • can be lost or stolen • Memorized password • low entropy • guessing attack possible • if card not stolen • have full security. Password guessing not possible • If card is stolen, still have password security

9. Some of Related Work • Hybrid model (C has a pwd and pk of S) • Halevi Krawczyk 99, Boyarsky 99 • Simulation- vs game-style KE • Simulation-style KE • Shoup 99, Boyko MacKenzie Patel 00 • Universally Composable (UC) Canetti Halevi Katz Lindell MacKenzie 05 • Game-style KE • Bellare Pointcheval Rogaway 00

10. Denial of Access (DoA) Attack • In Password-Authenticated KE, it is necessary to stop service if “too many” password failures P? • Adv can deny access for good guys • We can protect against such attacks • Require that Adv cannot cause P?, unless he stole key card • Don’t know of previous formalizations of DoA • Complements Denial of Service notion

11. Our Protocol Note: No Mutual Authentication

12. Password updates • Usually handled externally to the definition • If C updates his pwd, then DoA attack is possible (Adv can replay old msgs) • Problem: have users with related credentials • Solutions • Update long key as well • Have a challenge-response protocol • Keep password update counters • In the last two cases also need to update definition

13. Can a definition allow for mistyping passwords? • We don’t model this • What if we allowed Adv to create instances with mistyped passwords? • Adv specifies the password • Is this how people mistype? •  can behave badly on pwd’ = pwd+1 • Adv specifies a mistyping function • Only f that has 0,1,|D|-1 or |D| fixed points is allowed • UC-based definitions can handle this [CHKLM05]

14. Definitional Choices: Counting passwords attacks • Adv can guess passwords • Quantify advantage; “password attack” • Previously • Act of Adv interfering with traffic • (Insignificant change? Successful guess?) • In our definition • Count failed password attacks – player outputs P?

15. Summary • Define Key Exchange (KE) in a new model • Generalization of the hybrid model of Halevi-Krawczyk (HK) • (Some of) our discussion applies to other models (password-only and hybrid model of HK) • Give a new efficient KE protocol • Discuss a potential flaw in the HK protocols • Some members of the family of the HK protocols are vulnerable to password guessing attacks

16. Other Extended version is on Eprint. Contains: • Proofs • Discussion on storing passwords on the server • Discussion on password updates http://eprint.iacr.org/2006/057