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

k2 2R 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
• Dont 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 dont 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 pwd1
• 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 SC 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