1

Hugo Krawczyk

IBM Research

HMQV: A High-Performance

Secure*Diffie-Hellman Protocol

*Proven secure(just in case you heard rumors to the contrary)…

2

Outline of the Talk The authenticated Diffie-Hellman problem

Implicitly authenticated KE protocols

The MQV Protocol: does it deliver its wish list?

Some remarkable ideas but some design weaknesses as well

HMQV: A proven secure variant of MQV

Random oracle, computational assumptions (CDH), model-based

Rationale, validation, design (and even implementation) guide

The essential role of formal analysis

Unfortunately: no time for analysis idea (really interesting part)

3

Diffie-Hellman Exchange [DH’76]

Alice Bob

• both parties compute the secret key K=gxy=(gx)y=(gy)x

• assumes authenticated channels (+ DDH assumption)

• open to m-i-t-m in a realistic unauthenticated setting

gy

gx

4

Authenticated Diffie-Hellman

Bind key to identities via PKs (or other means)

Non-trivial: innumerable proposals, many broken

NOT that a good protocol must be complex or inefficient, only that it is incredibly easy to design them wrong

No need to compromise for weak protocols anymore

What does it mean for a KE protocol to be secure? What are the attacker’s capabilities?

Many works/approaches: much beyond preventing obvious impersonation and key recovery attacks (known-key attacks, ephemeral vs static, UKS, PFS, KCI,...)

5

Implicitly Authenticated DH [MTI’86]

Minimalist approach: Keep a plain DH exchange, but give Alice and Bob public keys (possibly with certificates)

Authentication via session key computation

No transmitted signatures, MAC values, etc

Session key must involve long-term and ephemeral keys:

K=F(PKA,PKB,SKA,SKB ,gx,gy,x,y)

Ability to compute key authentication

Possible and simple but tricky: many insecure proposals, also in standards (e.g. UM [BJM97])

6

MQV [MQV’95,LMQSV’00]

Most attractive among implicitly authenticated DH

Performance: just ½ exponentiation (25%) more than DH (with NO added bandwidth except if public keys transmitted)

Broad array of security goals considered: m-i-t-m, known-key attacks, UKS, PFS, KCI (hard to achieve with implicit auth),…

Widely standardized: ANSI, IEEE, ISO, NIST

NSA: “next generation cryptography” (including

protection of “classified or mission critical national security information“)

But is MQV secure? In what sense? Can be improved?

7

The MQV Protocol Basic DH + special key computation

Notation: G=<g> of prime order q; g in supergroup G’ (eg. EC, Z*p)

Alice’s PK is A=ga and Bob’s is B=gb,

Exchanged ephemeral DH values are X=gx, Y=gy

From which two values are computed: d=LSB(X), e=LSB(Y) where LSB(X)= 2L + X mod 2L for L=|q|/2 (this is the ½ exponentiation)

Both compute σ=g(x+da)(y+eb) as σ = (YBe)x+da = (XAd)y+eb

Session key is K=KDF(σ) (KDF unspecified: “prevent weak bits”)

Magic, isn’t it? Is it secure? Why? Can it be formally analyzed?

8

The MQV Protocol

Actual computation of σ involves co-factor h=|G’|/q

σ’ = (YBe)x+da = (XAd)y+eb

σ = (σ’)h

Adds an exponentiation: small for ECC, large for Z*p

(can replace with a q-order test)

Omitted in above description for simplicity: does not help against any of the weaknesses described here

9

Design Weaknesses in MQV

MQV cannot be proved generically (for any q-order CDH

G)

For each group G there are representations of its element under which the protocol is totally insecure

E.g. if 80 lsb’s have 50 bits of entropy then can break in 250

E.g. a simple padding can break the protocol. Also note that

subgroup G usually very sparse (e.g. |G|= 2160 |Zp*|=21024 )

Proof (if at all possible) must involve details of representation

An authentication failure: UKS [DVW]

Key bound to the wrong identities

10

UKS Attack on MQV

UKS: key-identity misbinding

Alice and Bob engage in a KE with Eve as m-i-t-m

Alice and Bob end computing the same key K (unknown to Eve)

But Alice binds the key to Bob while Bob binds it to Eve

Can UKS be prevented in MQV?

Require “proof of possession” (PoP) of private key at CA

PoP hard to do it right and not even a solution [Kaliski]

Key confirmation? Not sufficient if ephemeral state leaked

The essential identity-key binding is missing (cf 2-msg HMQV)

11

How About KCI Attacks?

A KCI attack: Using Alice’s private key, Eve can imperso- nate other parties to Alice (the reverse is

unavoidable)

Resisting KCI is a major argument for MQV: does it hold?

The answer is NO if KDF(σ) is invertible (but one-wayness not a reqt in MQV: “the requirement that KDF be preimage resistant appears unnecessary”)

KCI resistance w/non-invertible KDF?? Yes for HMQV.

12

Leaked ephemeral exponents

Yet another property that requires KDF to be one-way: protection against disclosure of ephemeral exponents (revealing x or y should not compromise K or

other sessions)

Property claimed by MQV but we show not to hold if KDF is not one-way

13

PFS )perfect forward secrecy(

PFS = eventual disclosure of long-term private keys does not compromise past session keys

A fundamental property of DH (but also with mitm?)

Also claimed as a (central) property of MQV

We show: no implicity authenticated DH protocol can enjoy PFS

Hence: MQV does NOT provide PFS except for sessions where the attacker was passive (also HMQV)

This (and not UKS) is the real reason to augment the protocol with a third msg and MACs

14

HMQV: A secure MQV variant

As in MQV: basic DH (X=gx, Y=gy), PKs: A=ga, B=gb

Both compute σ=g(x+da)(y+eb) as σ = (YBe)x+da = (XAd)y+eb

d=H(X,”Bob”) e=H(Y,”Alice”) (here H outputs |q|/2 bits)

Session key K=H(σ)

Differences with MQV

Definition of d, e: binds id’s, randomizes representation

H(σ): integral (and essential) part of the protocol (OW,RO)

“HMQV = Hashed MQV” (note: 2.5 exponentiations)

15

HMQV Analysis

In the KE model of Canetti and Krawczyk [CK’01]

Attacker may access private keys, session keys, session-state information (“exposed session”)

Any unexposed session is secure (key is indist from random)

In addition: extensions to capture PFS, KCI

[CK’01] Prove that secure KE in this model secure communications (“secure channels”)

Note: protocol must specify what resides in state and what in protected memory (such as private keys)

16

Basic Security of HMQV

Thm: Under the CDH assumption and in the random oracle model, HMQV (basic 2-msg or 3-msg with KC) is a secure KE protocol in the Canetti-Krawczyk KE model

The thm applies when σ and the ephemeral x,y are specified to be in protected memory, same as the private key (cf DSA)

The Thm includes resistance to KCI and PFS (the latter only in the case of 3-msg variant with KC), and of course UKS, known-key attacks, key recovery, etc

17

Security in the face of ephemeral disclosure

Under Gap-DH, KEA1 and in the random oracle model HMQV is secure also if ephemeral x,y disclosed

Menezes: pointed out that proof assumes X, Y in G=<g> security and proof hold if parties are required to check peer’s DH value is of prime order

Checks needed only against ephemeral disclosure and one-pass. Other cases and all proofs remain unchanged.

When needed test adds an exponentiation, cost depends on underlying group (always performed in MQV)

Establishes a clear security/performance trade-off (possible only with analysis, also an implementation guide: protect σ)

18

Cryptography is a Science! Intuition, ideas, cryptanalysis, new attacks…

all necessary and important but:

Formal analysis as main confidence tool

Not a Panacea: never stronger than the model it is based on

But well-defined mechanisms and properties: can be verified (not just “trust me, I have not been able to break it”)

Formal analysis as main design tool

Guides us to choose secure mechanisms, compose them right, discern between the essential, desirable and dispensable

Result is efficiency, simplicity, rationale, even impl’n guidance e.g. avoid PoP and PK before DH, selective prime tests, essential hashing, KC for PFS (not for UKS), levels of protection, etc

19

A message to standard bodies

No reason to compromise on protocol quality

No need to “live” with UKS attacks or mandate avoidable PoPs

No need to depend on heuristics only

Cannot “afford” ignoring formal study (if we only had it for encryption and hash functions…)

Standardize on proven protocols (especially when they are equally, or even more, efficient than alternatives)

In other words: DEMAND HIGH STANDARDS…

20

Analysis: the really interesting part

Main tool: “challenge-response signatures” in which signer and verifier generate same signature

DH values serve as challenges, key = hash (signature)

Signature scheme: “exponential Schnorr” + FiatShamir

http://eprint.iacr.org/2005/176