520 likes | 736 Views
Robust Key Exchange. Feng Hao Dependability Group Tech Chat 12 Feb, 2013. EPSRC First Grant. The talk is based on the following grant: “ Bridging Theory and Practice in Key Exchange Protocols ”, PI (Feng Hao), EPSRC First Grant, 2012-2014. Track record.
E N D
Robust Key Exchange Feng Hao Dependability Group Tech Chat 12 Feb, 2013
EPSRC First Grant • The talk is based on the following grant: “Bridging Theory and Practice in Key Exchange Protocols”, PI (Feng Hao), EPSRC First Grant, 2012-2014.
Track record • “Cryptanalysis of the Dragonfly Key Exchange Protocol” • Dylan, Hao’13 • “Security Analysis of a Multi-Factor Authenticated Key Exchange” • Hao, Dylan, ACNS’12 • “On Robust Key Agreement Based on Public Key Authentication” • Hao, SCN’12 (BPA) • “On Small Subgroup Non-Confinement Attacks” • Hao, CIT’10 • “Password Authenticated Key Exchange by Juggling” • Hao, Ryan, SPW’08 • “Kish's Key Exchange Scheme Is insecure” • Hao, IET IF’06
Background on key exchange Alice Bob
1976 Breakthrough • Diffie-Hellman key exchange protocol based on Discrete Logarithm
Ground-breaking, but vulnerable • Diffie-Hellman protocol is vulnerable to man-in-the-middle attack Bob Mallory Alice (b) (a) (a’, b’) ga' ga gb' gb Ka=gab’ Ka=gab’ Kb=ga’b Kb=ga’b
Fixing the flaw • Harder than most people had thought • Took nearly 40 years research • Still an active area
The basic solution • Authenticated Key Exchange • Three ways to add authentication • Something you know: password • Some you have: token (private/public key) • Something who you are: biometrics
A notoriously difficult task • A vast amount of protocols proposed • Nearly all have been found with security flaws • Standardization was hoped to be the solution • But several “standard” AKE protocols have been found flawed as well.
Why so difficult? • The nature of security research • Dealing with an unpredictable enemy • It’s like building a castle • Attacker only needs to find one weak entry to break in
Our contributions • Designed two AKE protocols • J-PAKE (Hao, Ryan, SPW’08) Not broken • YAK (Hao, FC’10) Not broken • Meanwhile, we have broken several others’ protocols
Our design approach • Simplicity principle • Make it as simple as possible but not more • Anderson-Needham 6thprinciple (1995) • “Do not assume that a message you receive has a particular form (such as gr for known r) unless you can check this” • Require using Zero Knowledge Proofs
Importance of Zero Knowledge Proof • ZKP forces participants to strictly follow protocol specification • Extremely important in multi/two-party secure computation problems • Universally agreed by the security community • But ZKP not used in past AKE protocols, why? • Isn’t key exchange a two-party secure computation problem ?
The devil of efficiency • ZKP widely considered too expensive! • Nearly all researchers have chosen to discard it to optimize efficiency “Optimisation is the process of taking something that works and replacing it with something that almost works, but is cheaper” - Roger Needham
Efficiency and Security Can Co-exit • We don’t discard ZKPs (we value the 6th P) • Instead, we use novel techniques to minimize the number of ZKPs, so the protocol is still efficient overall. • J-PAKE: password-based AKE • Comparable to the most efficient but more robust • YAK: public key based AKE • Comparable to the most efficient but more robust
What’s next? • J-PAKE and YAK are really the simplest we can achieve under the 6th principle • Difficult to envision any improvement in this regard
The other half of story: formal analysis • Aim: provable security • Three components in provable security • Formal security definition • Formal adversarial model • Formal security proofs • Nowadays, almost every protocol claims to have been “formally proven secure”
Harsh reality • Many “provably secure” protocols eventually prove to be insecure • In fact we have broken a few ourselves • What’s going on?
The role of security proofs • Do we need rigorous definition and proofs? • Absolutely. This applies to any science and engineering discipline. • But not good enough, the proofs must be constructed within “a formal model” • OK, but which model?
Existing formal models • Password-based AKE • Bellare-Pointchevel-RogawayEurocrypt’00 Cited by 833 • Abdalla-Pointcheval RSA’05 Cited by 144 • Katz-Ostrovsky-Yung Eurocrypt’01 Cited by 279 • Jiang-Gong SAC’04 Cited by 37 • Gennaro-Lindell Eurocrypt’03 Cited by 128 • PKI-based AKE • Cannetti-Kcrawczyk Eurocrypt’01 Cited by 668 • LaMacchia-Lauter-Mityagin ProvSec’07 Cited by 170 • Kcrawczyk Crypto’05 Cited by 289 • Multi-factor based AKE • Pointcheval-Zimmer ACNS’08 Cited by 15 * Citation data from Google Scholar (8 July, 2012)
Which is the “right” model? • A question first raised by two professors: Menezes and Koblitz • See “The uneasy relationship between mathematics and cryptography” (AMS’07) • Surprisingly, no answer even today • Every model claims to be the “right” one. • But that cannot be right.
Our criterion of truth • Fortunately, each model comes with a concrete example of a practical protocol. • Hence, We take “practice” as one and the only one criterion to evaluate the truth of a theory.
Basic intuition • A right theoretical model should give right practical results. • If not, the model may not be “right”.
Case study 1: Password based AKE • Authenticated key exchange based on a shared password without any PKI • Also known as PAKE • The first PAKE protocol is called EKE • Designed by Bellovin and Merrit in 1992.
Encrypted Key Exchange (1992) Bob (s) Alice (s) • A known weakness: the exchanged items leak password info to a passive attacker (Jaspan’96) a, g, p b, g, p B = gb mod p A = ga mod p Es(A) K = Ab mod p = gabmod p K = Ba mod p = gabmod p Es(B)
However, EKE is “provably secure” • Bellare-Pointcheval-Rogawayformally proved that EKE is “provably secure” (Eurocrypt’00) • That conclusion clearly contradicts the known information leakage problem. • What’s going on?
Implicit assumption • Bellare-Pointcheval-Rogaway define a formal “ideal cipher” model. • The ideal cipher is assumed never to leak any info even when using a low-entropy key. • What exactly is this cipher? (Boyd, 2003) • Not defined in the [BPR00] paper. • No one really knows.
Others examples • Several PAKE protocols claim provably secure under “standard” models (no idealized functions) • Katz-Ostrovsky-Yung (Eurocrpt’01) • Gennaro-Lindell (Eurocrypt’03) • Jiang-Gong (SAC’04) • Abdalla-Poincheval (RSA’05) • “Provably secure” without idealized functions • Sounds perfect in theory • How about in practice?
A realistic weakness • In practice, none of these protocols have been implemented (to the best of my knowledge). • All them require a trusted third party to define protocol parameters. • How to realize such a trusted third party?
How to define protocol parameters? • Katz-Ostrovsky-Yung’s paper: “use a trusted third party or a source of randomness” • But no concrete explanation of the “source of randomness” in the paper • Jiang-Gong’s paper: “use a trusted third party or a threshold scheme” • But no concrete explanation of the “threshold scheme” in the paper • Gennaro-Lindell’s paper: “choose a large organization as the trusted third party” • But that would fundamentally remove benefits of PAKE
Roadmap • Password-based AKE • Bellare-Pointchevel-RogawayEurocrypt’00 Cited by 833 • Abdalla-Pointcheval RSA’05 Cited by 144 • Katz-Ostrovsky-Yung Eurocrypt’01 Cited by 279 • Jiang-Gong SAC’04 Cited by 37 • Gennaro-Lindell Eurocrypt’03 Cited by 128 • PKI-based AKE • Cannetti-Kcrawczyk Eurocrypt’01 Cited by 668 • LaMacchia-Lauter-Mityagin ProvSec’07 Cited by 170 • Kcrawczyk Crypto’05 Cited by 289 • Multi-factor based AKE • Pointcheval-Zimmer ACNS’08 Cited by 15 * Citation data from Google Scholar (8 July, 2012)
Case study 2: PKI-based AKE • Alice and Bob have authentic public keys of each other (through PKI). • They establish a session key based on their respective private keys. • Menezes-Qu-Vanstone protocol (MQV) is one of the most well-known examples • Widely standardized (e.g., IEEE P1363)
Menezes-Qu-Vanstone (MQV) Alice (ga) Bob (gb) • Two mandatory safeguards in the protocol: • Proof-of-possession during CA registration • Public key validation during key exchange B = gy mod p A = gx mod p A B K = H(…) K = H(…)
However, MQV has no proofs • The original protocol was carefully designed by three prominent cryptographers in 1995 • But still, it contains one flaw (Kaliski, 2001) • Unknown Key Sharing attack if there is no key confirmation
What was wrong with MQV? • Where should user identities be included? • During key exchange • During key confirmation • MQV only include identities in stage 2. • Lessons: • MQV without key confirmation is not secure. • MQV should have included identities in stage 1 (Menezes did exactly this change in Indocrypt’06)
HMQV protocol • A hash variant of MQV (Kcrawczyk, Crypto’05) • Formally proven secure in a variant of CK model, called HMQV model. • Quicklyincluded into IEEE P1362 draft “… the HMQV work represents a prime example of the success of theoretical cryptography …”(Kcrawczyk, AMS’07)
How does HMQV work? • Similar to MQV, except the following changes: • Include identities in key exchange through hashing • Remove the required proof-of-possession during CA registration • Remove the required public key validation during key exchange flows • The last two changes turn out to degrade security significantly (despite formal proofs)
Attacks on HMQV • An attacker can compromise the user’s private key (Menezes-Ustaoglu’06) • Then, HMQV was revised in 2007 (IEEE P1363) • However, the revised HMQV is still vulnerable (Hao, FC’10) • Invalid public key attack (authentication failure) • Wormhole attack (a variant of UKS attack)
The HMQV model • Attacks reflect the deficiencies in the theoretical model in HMQV. • It suggests that the HMQV model is not a “right” model. • However about other formal models?
Canetti-Kcrawczyk (CK) model • One of the most well-known models, due to Canetti-Kcrawczyk at Eurocrypt’01. • As a concrete example, the authors apply the model to prove the SIG-DH protocol is secure.
SIG-DH protocol Alice (ga) Bob (gb) • Basically, digitally sign the exchanged items. B = gy mod p A = gx mod p Sig(A,…) Sig(B,…) K = H(…) K = H(…)
Contradiction “we will want to guarantee that the leakage of information specific to one session (such as the leakage of a session key or ephemeral state information) will have no effects on the security of other sessions ... “ Canetti-Kcrawczyk (Eurocrypt’01) However, if we use DSA, then the leakage of the randomization factor will leak the private key.
Where is the catch? • The model (implicitly) assumes there is a discrete logarithm based signature scheme that is secure even when ephemeral secrets are revealed. • However, the paper doesn’t provide a concrete signature algorithm. • The deficiency in the CK model then motivates defining a new model.
Extended CK (eCK) model • A new model called extended CK (eCK) by LaMacchia, Lauter, Mityagin (2007) • Claims to be stronger than the CK model because it explicitly captures the threat of leaking ephemeral secrets. • Authors also present a NAXOS protocol • They apply the model to formally prove NAXOS is secure.
NAXOS protocol Alice (ga) Bob (gb) • The key part in the design: use H(x, a)instead of x on the exponent • Known as the NAXOS trick. B = gH(y,b) mod p A = gH(x,a) mod p A B K = H(…) K = H(…)
Where is the catch? • NAXOS claims secure if the attacker learns the ephemeral secret: H(x, a) (but not x) • However, that’s challengeable • Both H(x, a) and x are ephemeral secrets • Why attacker can only learn one, not the other? • This is repeating the same deficiency in CK model – excluding valid attacks by assumption
Roadmap • Password-based AKE • Bellare-Pointchevel-RogawayEurocrypt’00 Cited by 833 • Abdalla-Pointcheval RSA’05 Cited by 144 • Katz-Ostrovsky-Yung Eurocrypt’01 Cited by 279 • Jiang-Gong SAC’04 Cited by 37 • Gennaro-Lindell Eurocrypt’03 Cited by 128 • PKI-based AKE • Cannetti-Kcrawczyk Eurocrypt’01 Cited by 668 • LaMacchia-Lauter-Mityagin ProvSec’07 Cited by 170 • Kcrawczyk Crypto’05 Cited by 289 • Multi-factor based AKE • Pointcheval-Zimmer ACNS’08 Cited by 15 * Citation data from Google Scholar (8 July, 2012)
Case study 3: multi-factor based AKE • Alice and Bob perform authenticated key exchange based on multiple factors • Password • Tamper-resistant token • Biometrics • Pointcheval-Zimmer protocol (ACNS’08) • First protocol that combines all three factors • Has a formal model and formal proofs
Attacks • Two attacks on Pointcheval-Zimmer protocol (Hao, Dylan, ACNS’12) • With a stolen password, attacker can further steal biometrics • Based on the above attack, attacker can further steal a private key (similar to Menezes et al’s attack on HMQV in 2006) • Conclusion: the attacker only needs to break one password factor in order to break the entire three-factor scheme.