Key Exchange Using Passwords and Long Keys Vladimir

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

Communication Setting … Full Control Insecure network

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

Key Exchange (KE) A protocol between two parties l Both output (the same) randomly chosen k 2 DK Security l Adv does not know anything about k even if it sees all other exchanged keys l Adv cannot mismatch players l l 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

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

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

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

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

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

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

Our Protocol Note: No Mutual Authentication

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

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

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

Summary l Define Key Exchange (KE) in a new model l l 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 l Some members of the family of the HK protocols are vulnerable to password guessing attacks

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