key exchange using passwords and long keys vladimir kolesnikov charles rackoff comp. sci. university...

Key Exchange Using Passwords

and Long Keys

Vladimir Kolesnikov

Charles Rackoff

Comp. Sci. University of Toronto

Communication Setting

Insecure network

…

Full Control

Secure Communication from Shared Random Key

Trusted Party k 2R DK

k2 2R DK

Trusted Party

• Simple• Very efficient

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

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)

Simulation Style KE Definition

• Powerful• But complicated

Real Ideal

¼

8 9

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 stringAdversary guesses which• Should not do too well

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

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

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

Our Protocol

Note: No Mutual Authentication

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

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]

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?

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

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