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

2. Communication Setting Insecure network … Full Control

3. Secure Communication from Shared Random Key Trusted Party k 2 R D K k 2 2 R D K Trusted Party Simple Very efficient

4. Key Exchange (KE) A protocol between two parties Both output (the same) randomly chosen k 2 D K 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 Powerful But complicated Real Ideal ¼ 8 9

7. Game Style KE Definition Seems to be almost as powerful Self-contained Simpler 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

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. On independence of player instances No global state, all comm. thru Adv Can a player know for sure that some global event happened (e.g. n P ? ’s occurred)? Only if it is in the interest of Adv. Players must sign messages to each other Can only use to uncover weaknesses in definitions

16. Tightness of allowed success of Adv Can we allow Adv some slack over ? No! This would allow “bad” protocols  : Once there was a P ? for C, players S C output an all 0 key with small, but not neg. probability Adv can ask for a single challenge; he cannot keep picking until he gets the 0 key, so  is secure (Adv advantage within the slack).

17. 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

18. 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