Unknown Key Share Attacks and the MQV Protocol

1
Unknown Key Share Attacks and the MQV Protocol

• Burt Kaliski, RSA Laboratories
• April 11, 2000
• RSA Euro 2000

2
Introduction

• Key establishment protocols have traditionally
  been among the hardest protocols to design
• whether based on symmetric cryptography,
  public-key cryptography, or both (as in the case
  of recent password-based protocols)
• Many different attributes to consider
• Unknown key share attribute illustrates the
  challenges of design for the MQV protocol

3
Outline

• Unknown key share
• The MQV protocol
• An unknown key share attack
• Countermeasures
• Lessons learned
• Conclusions

4
Unknown Key Share

• Alice, Bob each run a key establishment protocol,
  intending to share a key with another party
• An unknown key share occurs if one party shares a
  key with a different party than intended and does
  not know it
• May lead to confusion when the key is applied, if
  parties are not otherwise identified
• a motivation for good key usage in general

5
Example

• Suppose Bob is running a protocol with Eve
• Meanwhile, Alice is running a protocol with Bob
• If Eve can manipulate the exchanges so that Bob
  and Alice compute the same key, then Bob will
  have an unknown key share with Alice
• Alice believes she shares the key with Bob
• Bob believes he shares it with Eve
• Bob doesnt know he shares it with Alice!
• Eve doesnt even know the key in this attack

6
The Confusion

• Suppose Bob wants to send a message to Eve
• e.g., Youre fired!
• Bob encrypts the message and sends the ciphertext
  to Eve
• Eve forwards the ciphertext to Alice
• Alice decrypts the ciphertext and recovers the
  message
• Confusion
• Bob believes the message is from Bob to Eve
• Alice believes the message is from Bob to Alice

7
The MQV Protocol

• Key agreement protocol in Diffie-Hellman family
• Proposed by Menezes, Qu and Vanstone (1995)
• Improved with Law and Solinas (1998)
• current version in IEEE P1363
• Several variants
• one-pass (store-and-forward)
• two-pass without key confirmation
• three-pass with key confirmation
• Attack applies to one- and two-pass variants only

8
Domain Parameters

• Group G with hard discrete logarithm problem
• e.g., finite field mod p, elliptic curve
• Base P of prime order n
• Cofactor h G/n
• for protecting against small subgroup attacks
  typically small for elliptic curve groups
• Mapping ? G ? 2m,2m1-1
• where m length in bits of sqrt(n)

9
Notational Conventions

• Notation is from elliptic curve arithmetic
• Group operation is written additively U V
• multiplication in finite field
• Repeated operation is scalar multiplication
• c U U U U U (c times)
• exponentiation in finite field
• O is group identity

10
Key Pairs

• Public key W ? G
• Private key w ? 1,n-1
• where W wP

11
Protocol Setup

• Alice has static key pair (WA,wA)
• Bob has static key pair (WB,wB)
• Each party has a certificate certA, certB

12
MQV Protocol(Two-Pass Variant, 1998 Version)
RA, certA
Alice
Bob
(WB,wB) (RB,rB)
(WA,wA) (RA,rA)
RB, certB
sA rA µ(RA) wA SB RB µ(RB) WB KAB h sA
SB
sB rB µ(RB) wB SA RA µ(RA) WA KBA h sB
SA
13
Details

• 1. Alice generates ephemeral key pair (RA,rA),
  sends RA, certA to Bob.
• 2. Bob generates ephemeral key pair (RB,rB),
  sends RB, certB to Alice.
• 3. Alice verifies certB, checks that RB ? G,
  computes sA rA µ(RA) wA, SB RB µ(RB) WB
  and KAB h sA SB, checks that KAB ? O.
• 4. Alice verifies certA, checks that RA ? G,
  computes sB rB µ(RB) wB, SA RA µ(RA) WA
  and KBA h sB SA, checks that KBA ? O.
• KAB KBA is the shared secret key

14
Protocol Attributes

• Implicit key authentication
• only Alice, Bob can determine key (assuming
  theyre honest)
• Forward secrecy
• past keys remain secret if WA, WB compromised
• Bandwidth efficiency
• only ephemeral public key, certificate exchanged
• Computational efficiency
• only about 2.5 scalar multiplications per party
• vs. 3 for unified Diffie-Hellman

15
An Unknown Key-Share Attack

• Eves goal is to manipulate the exchange so that
• Alice, Bob compute the same key
• Bob believes he shares it with Eve, not Alice
• Eve must at least replace Alices certificate
  with her own certificate
• Eve may also replace other items in exchange
• Several kinds of attack trivial, better and best
• Only the best is really an attack

16
A Trivial Attack

• Eve obtains a certificate for Alices static
  public key, substitutes it for Alices
  certificate in the protocol exchange
• Applicable to many protocols
• Easily prevented if certificate issuer checks for
  duplicate public keys
• Also prevented if issuer requires Eve to prove
  possession of the corresponding private key

17
A Better Attack

• Eve obtains a certificate for a related public
  key, where she does not know the corresponding
  private key
• Applicable to MTI, Goss protocols
• Not prevented if certificate issuer only checks
  for duplicates
• But easily prevented if issuer requires Eve to
  prove possession of the private key

18
The Best Attack

• Eve generates a new key pair, obtains a
  certificate for the public key, substitutes it
  for Alices certificate, replaces other items so
  that Bob computes same key as Alice
• Applicable to one- and two-pass MQV protocols,
  early version of Station-to-Station protocol
• Not easily prevented by issuer, because Eve knows
  the private key
• But how to generate the new key pair?

19
Succeeding at the Best

• Eve needs a new static key pair (WE,wE) and an
  ephemeral public key RE such that Alice, Bob
  compute the same key
• KBE h sB SE KAB KBA h sB SA
• where SE RE µ(RE) WE
• To do this, Eve must solve SE SA, i.e.
• RE µ(RE) wE P SA
• for RE and wE

20
Solving the Equation

• Equation
• RE µ(RE) wE P SA
• Solution
• 1. Let u ? 1,n-1
• 2. Compute RE SA u P
• 3. Compute wE µ(RE)-1 u mod n
• Proof
• RE µ(RE) wE P SA u P u P SA

21
The Attack
RA, certA
Alice
Bob
(WB,wB) (RB,rB)
(WA,wA) (RA,rA)
RB, certB
RE, certE
Eve
sB rB µ(RB) wB SE RE µ(RE) WE SA KBE
h sB SE KAB
(WE,wE) RE
22
Discussion

• Since Eves static public key depends on Alices
  ephemeral public key, Eve must obtain the
  certificate during the protocol run
• However, certificate issuers are often on-line,
  and Alice might not notice the delay
• though Bob might notice that the certificate is
  new
• Not an obstacle if Bob is off-line (as in the
  one-pass protocol)

23
Countermeasures

• Key confirmation
• Alice, Bob demonstrate knowledge of KAB, as in
  the three-pass variant
• Identification within exchanged messages
• e.g., Youre fired, Eve! (Signed, Bob)
• Key derivation based on parties identities
• KAB f(KAB, A, B, time, )
• Ephemeral public key commitment exchange
  Hash(RA), Hash(RB) before exchanging RA, RB
• but more passes ...

24
Lessons Learned

• Countermeasures are easily implemented, so the
  attack is not a major concern in practice
• However, the attack does illustrate several
  principles of protocol design
• 1. Double-check minor changes
• 2. Consider all parties
• 3. Assess system requirements

25
Double-Check Minor Changes

• Original MQV protocol was not vulnerable to an
  unknown key-share attack
• as described in early IEEE P1363 drafts, U.S.
  Patent 5,761,305 (different than SAC 95 version)
• A minor change to improve efficiency introduced
  an unexpected vulnerability
• Interestingly, efficiency could have been
  improved in many environments without any changes

26
Original MQV Protocol(Two-Pass Variant, 1995
Version)
RA, certA
Alice
Bob
(WB,wB) (RB,rB)
(WA,wA) (RA,rA)
RB, certB
sA rA µ(RA) µ(WA) wA SB RB µ(RB) µ(WB)
WB KAB h sA SB
sB rB µ(RB) µ(WB) wB SA RA µ(RA) µ(WA)
WA KBA h sB SA
27
Unknown Key-Share Resistance

• To mount an attack, Eve must solve
• RE µ(RE) µ(WE) WE SA
• for RE, wE and WE wE P
• This is difficult because the equation is
  nonlinear in both RE and WE
• current protocol is nonlinear only in RE
• Original protocol thus appears to resist unknown
  key share attacks

28
The Minor Change

• Original protocol apparently involved 3 scalar
  multiplications per party
• ephemeral key pair generation
• µ(RB) µ(WB) WB
• h sA SB
• Protocol was changed to save 0.5 scalar
  multiplications
• µ(RB) µ(WB) WB became µ(RB) WB
• µ(RB) is half-length
• As a result, resistance to attack was lost!

29
No Change Was Necessary!

• Trick Rewrite KAB
• KAB h (?A RB ?A WB)
• where ?A sA and ?A sA µ(RB) µ(WB) mod n
• Sum of two scalar multiplications can be done
  with slightly more work than one scalar
  multiplication by Shamirs method
• Original protocol (as well as current one) can
  thus be implemented with only 2? scalar
  multiplications better than 2.5 goal
• needs a little extra code, memory, but
  straightforward

30
Consider All Parties

• Why was the attack overlooked at first?
• not only by designers, but also by reviewers
• Perhaps because certificate issuer wasnt
  expected to be on-line?
• All interactions should be considered in
  analysis, not just parties that share the key

31
On-Line vs. Off-LineA Big Difference

• Recall that Eve must solve
• RE µ(RE) WE SA
• for RE, wE and WE wE P
• If certificate issuer is off-line, then Eve must
  solve for RE, given WE and SA
• difficult because the equation is nonlinear in RE
• SA is a one-way function of RE for a given WE
• sA rA µ(RA) wA is called an implicit
  signature on RA
• If issuer is on-line, then Eve can solve for WE
  and RE together

32
Two Parties or More?

• Certificate issuer has traditionally been
  considered a trusted third party, but analysis
  has often abstracted this to an off-line role of
  providing a certificate
• Whether on-line or not, issuers interactions
  with other parties can influence results
• e.g., whether proof of possession performed
• Analysis should thus consider all interactions
  that may influence the result
• Alice and Bob
• Alice and her issuer Bob and his issuer
• Alice and Bobs issuer Bob and Alices issuer

33
Two Parties or More? (contd)

• Some recent architectures (e.g., OCSP) are moving
  toward on-line status checking
• and future protocols could move away from static
  certificates entirely in many cases
• This brings the status providers on-line as full
  parties
• Eventually, perhaps a return to the traditionally
  on-line third party, but with public keys instead
  of symmetric keys
• and a substantial body of protocol analysis to
  build on

34
Assess System Requirements

• Bottom line question Is the attack really a
  weakness?
• Answer What does the system require?
• Requirements probably need more research

35
Is It a Weakness?

• In the certificational sense, yes a claimed
  attribute does not hold
• perhaps other conjectured attributes dont hold
  either?
• In the practical sense, no the claimed attribute
  doesnt need to hold, if key confirmation is
  employed as generally recommended
• Even without key confirmation, the confusion
  exists only in a special setting
• Bob sends unidentified messages to an
  unauthenticated recipient
• and Eve doesnt learn the key

36
What Does the System Require?

• Consider a standard three-pass key agreement
  protocol with key confirmation, where parties
  exchange static and ephemeral keys
• not the only model, but a common one
• Keys are combined with certain cryptographic
  operations, e.g.,
• KAB F (rA,wA,RA,WA,RB,WB)
• KBA F (rB,wB,RB,WB,RA,WA)
• following IEEE P1363, F is a secret value
  derivation primitive
• As recommended, followed by key confirmation

37
A General Protocol
RA, certA
Alice
Bob
RB, certB, TB
(WB,wB) (RB,rB)
(WA,wA) (RA,rA)
TA
KAB F (rA,wA,RA,WA,RB,WB)
k f (KAB) TA MACk (3,A,B,RA,RB)
KBA F (rB,wB,RB,WB,RA,WA) k f (KBA) TB
MACk (2,B,A,RB,RA)
38
Defining Secret Value Derivation Primitives

• Input
• partys private key(s)
• other partys public key(s)
• Output
• shared secret key
• What properties needed by general protocol?
• probably not unknown key share resistance
• but what else? To be continued!

39
Conclusions

• MQV experience reconfirms challenge of designing
  key establishment protocols
• Minor change introduced an unknown key share
  attack, perhaps overlooked because certificate
  issuer was considered off-line
• Bottom line a certificational weakness, readily
  addressed in practice
• Security definitions remain an interesting topic
  for further study