1. HMQV: A High-Performance Secure*Diffie-Hellman Protocol
Hugo Krawczyk
IBM Research
*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 gx gy
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

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