Presentation on theme: "1 Hugo Krawczyk IBM Research Asiacrypt’2010. 2 An exciting journey… This talk reflects my personal journey between theory and practice I will focus on."— Presentation transcript:
2 An exciting journey… This talk reflects my personal journey between theory and practice I will focus on the “ influencing practice ” part hence the title “ from theory to practice ”, though it is always a two-way journey (as we ’ ll see) It is laborious but ultimately quite fun and rewarding (most of the time ) I will try to offer some (hopefully useful) lessons for those who want to join the journey … and you are very welcome and encouraged to do so!
3 "In theory, theory and practice are the same. In practice, they are not."
4 In cryptography, theory IS practical We don ’ t have the luxury of most engineering fields: Can ’ t resort to experimental evidence: no testing, no simulations Think of safety systems (airplanes, cars): one can simulate nature forces experimentally or by computer But you cannot model “ human force ” – especially a malicious one (think of designing WTC to withstand an airplane accident vs a 9/11 attack) And you cannot computer-simulate crypto attackers, but you can “ simulate ” them via mathematical models and proofs Math models & proofs as our main source of confidence (even when keeping in mind the imperfection of math models … ) Alternative is to spend “ 1000 PY cryptanalysis ” or pray (or both!)
5 Can you sell this view to practitioners? Not easy.. but it ’ s getting much easier Today if you come with a proposal even the engineers may ask for (mathematical) analyses – an farfetched dream 15 years ago It has one condition though: You need to respect the “ rules of the engineering game ” Simplicity, efficiency, low cost of deployment, … And it has to solve a problem the engineers want to solve Selling a solution is not easy – selling a problem is much harder As we ’ ll see it is all about a challenging balancing act
6 A tough balancing act… Theory Engineering Theory Engineering
7 Theory Engineering A tough balancing act… Engineering Theory Engineering
9 1994: IPsec design underway Goal: Secure the Internet Protocol Authenticate and encrypt IP packets Authentication method: Key-prepend MAC MAC K (P) = Hash(K || P) Can you see the problem? Next: A not too friendly “ dialogue ” with some IPsec leading engineers at the time
10 A 1994 IPsec dialogue Me: This mode is open to extension attacks! They: Aha! But not if P ’ s length is prepended … and IP packets always carry the length in the header! Me: I do not like to use non-cryptographic elements as essential cryptographic elements. What if tomorrow the length is omitted? They: Are you cookoo? IP packets will always carry their length I insisted, though I did not have a truly convincing answer beyond: “ prudent engineering, sound principles ” But guess what? How? The length indeed “disappeared”
11 IP Packet Authentication in IPsec Two modes AH (authentication header): Authentication only ESP (encapsulating security payload): Authentication plus optional encryption
12 Authentication Header (AH*) [~ RFC 2402] IP Header SPI Replay Prevention Sequence Number Payload Padding Pad Length Protocol MAC Value MAC (covers header) Payload Length * approximate description
13 ESP Format [RFC 2403] IP Header SPI Replay Prevention Sequence Number Initial Vector Payload Padding Pad Length Protocol MAC Value MAC Optionally Encrypted Payload MAC does not cover IP header! Payload Length
14 The end of the story? ESP is the most common IPsec mode, the MAC does not cover the header (for some good reasons). So how about the MAC security w/o the length? Eventually, HMAC was (invented and) adopted The prepend-only proposal is a clear example of too much focus on engineering-only considerations It was simple and secure under the specific conditions at the time but too fragile to withstand future changes It required a balancing act…
15 Theory: NMAC NMAC K1,K2 (M)= Hash K1 (Hash K2 (M)) The “ right thing ” : conceptually PRF(UH) & nice proof but requires a variable IV (replaced with the keys) ... and two keys Engineers wanted black-box call to the hash (e.g. h/w implementation) and a single short key Key replaces IV
16 Bridging between Theory and Practice Proof used NMAC K1,K2 (M)= Hash K1 (Hash K2 (M)) Here subscript means replacing hash IV with key The “ compromise ” (black-box call to Hash, single key) HMAC(K, msg) = Hash(K+opad | Hash(K+ipad | M)) As NMAC but with “ built-in ” key derivation K1=Hash(K+opad) K2=Hash(K+ipad) and most important: no change of IV balance regained and the rest is history…
17 Randomized Hashing Story: A Balancing Act [HK’06]
18 The Collisions Crisis Background: The “ hash confidence ” crisis Obvious answer: design, standardize, implement new stronger hash functions (SHA3 competition) But what if new functions broken in 5-10 years? Can we buy insurance against future collisions?? Specifically: Can we build digital signatures without collision resistance? (remain secure even if collisions found) In theory: Yes [NY ’ 89]. Then why are we building signatures that depend on coll. resistance?
19 Randomized Hashing From: Sign(H(M)) (hash-then-sign) To: Sign(H r (M)) where H r = randomized version of H Idea: r chosen by signer at the time of signature; r sent with message and signature Thus, attack on signature starts only after learning r Fundamental shift in attack scenario: Off-line vs. On-line In particular, no use for off-line collisions But can it be built? Can it be proven? Can it be practical?
20 Initial “Randomized Hashing” Proposal [HK06] First proposal: Sign( r | H(M+r)) | concatenation, + blockwise xor, r = repeated random block We proved that off-line collisions on H do not break the signature Attacker has a much harder problem to solve An implementation of the “ target collision resistance ” notion But, would the engineers buy it? No! we broke the hash-then-sign paradigm and with it 1000s of implementations The signature of r in addition to the hash does not work with sign-then-hash
21 Back to the drawing board Find a randomized hashing scheme that provides freedom from collisions but preserves hash-then-sign Enter RMX: Given msg M to sign Signer chooses fresh r Computes σ = Sign( H (RMX(r,M)) ) Sign is any “ hash-then-sign signature scheme ” (RSA, DSS, … ) Note that only the output of H is signed, not r Signature = (σ, r)
22 HASH SIGN r HASH SIGN RMX M =(m 1, …,m L ) (r, m 1 r,, …,m L r( M =(m 1, …,m L ) RMX: Preserving Hash-then-Sign signature( signature, r ) RMX X 1 st proposal
23 Merkle- Damgard. Hash H The RMX Scheme (one-pass blockwise processing) IV h h h h ● ● ● Hash(M) m1m1 m2m2 m L-1 mLmL m1m1 mLmL r r h h h h ● ● ● H(r,M) IV r ~ r
24 Randomized Hashing Lesson To meet the engineers ’ requirement to preserve hash-then-sign we had to re-design RMX We had to change the proof and introduce a new notion: “ enhanced target collision resistance ” (eTCR). Luckily, we could prove eTCR under the same assumptions on underlying compression function. So, were the engineers impressed? Mixed results. NIST standardized the RMX technique and eTCR is an explicit requirement for SHA3. Yet, no real implementations. Why? Partly, because the following principle is missing
25 Randomized Hashing Lesson Current focus is on changing the hash functions -- not on the way we use them Need to convey the message: It ’ s not just about WHAT to use but HOW to use it Many times, the “ how to use ” is more critical than the basic design (using it right can survive a weaker function) I love to use the following ECB vs CBC analogy The “ what ” : Block cipher The “ how ” : ECB vs CBC
26 Analogy from block ciphers: CBC vs ECB ECB encrypts each input block independently CBC randomizes encryption to hide repeated blocks But does CBC adds real security? “ Come on, how bad it is to leak repeated blocks? ” Certainly not too bad for “ random ” (incompressible) plaintext Well..
27 Linux Penguin Encrypted w/CBC Indeed, it’s about how to use it! Note that in this case a strong block cipher (e.g. AES) with ECB is weaker than a weak block cipher (e.g. DES) with CBC ECB vs CBC Encrypted w/ECB! Courtesy of wikipedia “ modes of operation ”
28 Back to Randomized Hashing I don ’ t have an eloquent picture to show the benefits of randomized hashing as with CBC vs ECB But the safety net provided to digital signatures by an RMX-like technique is huge If we were using RMX, today ’ s signatures would be much less at risk from collision attacks Obviously, we need to design the strongest possible hash functions but also use them more prudently
29 Randomized Hashing: Work in Progress The randomized hashing story is not over … we need to make it happen in the real world (and you can help!) Need to update standards to compute RMX and transport r Note: can re-use randomness in randomized signatures (DSA, PSS) Should we rely on random serial # ’ s in certificates? No! Remember the reliance on pre-pended length in IPsec? Today s/n may be random, tomorrow just a sequence number (why not?)
31 Key derivation function (KDF): From an imperfect source of keying material to strong crypto keys Imperfect: non-uniform, side information (partial secrecy) Random Number Gen, system entropy sources, Diffie-Hellman (KE),... Output: one or more keys (e.g., encryption, MAC, etc) A fundamental crypto primitive: Yet common design very ad-hoc-ish Common practice: skm = “ source key material ” info=context info Hash(skm || “ 1 ” || info) ||... || Hash(skm || “ t ” || info) Can it be proven? Only for “ perfect ” hash (random oracle) Can we do better? KDF in Practice
32 To illustrate weakness, consider the “ easy ” case: where skm is a fully random key In this case only need a PRF to convert skm into multiple keys But the above design is not even a good PRF This is the old “ prepend-key ” PRF: PRF K (x)=Hash(k||x) which has been deprecated long ago in favor of better modes ’ KDF is a much more demanding primitive than PRF (needs to work with non-random keys), and yet we are using a design that is weak even as a PRF. And don ’ t rely on “ info ” being of fixed length (multi-purpose KDF) Hash(skm || “ 1 ” || info) ||... || Hash(skm || “ t ” || info)
33 Can we balance the KDF act? HKDF [K’10] Follow the “ extract-then-expand ” paradigm 1. Key Extraction: Derive a first cryptographically strong key from an “ imperfect source of randomness ” 2. Key Expansion: Given a first cryptographically strong key derive more keys (basically a PRF with variable-length output) Generic Extract-then-Expand KDF K prf = Extract(salt, skm) skm= source key material Keys = Expand(K prf, Keys-length, ctxt_info). Binds key to the application “ context ” Optional (random but non-secret)
34 Can we balance the KDF act? HKDF [K’10] How to implement “ extraction ” ? (from imperfect source to single strong PRF key) Can use the theory of randomness extractors (complexity theory) Efficient unconditional constructions exist (e.g. strong univ. f ’ s) But require large salt, do not fulfill all crypto needs (e.g. RO uses, tight gaps, etc), and are not available in crypto libraries Unconditional extractors not likely to be used in practice balance tilted to the theoretical side
35 K prf = HMAC(salt, skm) skm= source key material Keys = HMAC(K prf, Keys-length, ctxt_info) where Keys = K 1 || K 2 || … K i+1 = HMAC(K prf, K i || ctxt_info || i) (HMAC as PRF in “ feedback mode ” ). Regaining Balance: HKDF (HMAC as extractor and PRF) OR
36 HKDF: Balance regained Practice: HMAC already used as PRF, here re-used as extractor. Theory: Detailed analysis [DGHKR ’ 04, CDMP ’ 05,K ’ 10] shows HMAC as a good computational extractor under various models of compression functions Wide range of assumptions depending on use: from purely combinatorial to random-oracle type modeling Not satisfied by plain M-D hash: HMAC much stronger as a property-preserving mode (pseudorandomness and extraction)
37 The Power of Proofs and Proof-driven Design in Cryptographic Protocols Simple example: Asymmetric Key Wrapping and One-pass Key Exchange
38 Key Wrapping Key-wrapping or key encapsulation: server transmits a key (and possibly associated data) to a client Major key management tool: storage, hardware security modules, secure co-processors, ATM machines, etc. Symmetric vs Asymmetric: AES-based, RSA-based Industry is searching for an ECC solution Main candidate: DHIES [ABR ’ 01] CCA-secure encryption, can transmit key and associated data Implicitly authenticates the intended receiver (the only one that can read the key/data)
39 Authenticated Key Wrapping DHIES implicitly authenticates the receiver Only intended receiver can read the key/data But how about sender ’ s authentication? Interestingly: Just adding sender ’ s signature on top of DHIES is weaker than it may look Good news: Can solve the problem even more efficiently than with signatures and with better security Thanks to well-defined (reusable) primitives and models Thanks to designs that can get rid of safety margins Thanks to the power of proofs in well defined models.
40 Authenticated DHIES and One-Pass KE DHIES is an instantiation of the KEM/DEM paradigm: (Y,C,T) Key Encapsulation: Y=g y encapsulates K=H(A y ) (A is receiver ’ s PK) Data Encapsulation: (C,T) CCA-encrypts data under K KEM receiver-authenticated one-pass KE Authenticated DHIES = “ authenticated KEM ” + DEM Authenticated KEM Authenticated One-Pass KE ECC-friendly AKEM implementation [HK ’ 11] : One-Pass HMQV [K,MQV] Reduction to the OP-KE case avoids need for new models and protocols Efficiency: same as DHIES for sender and just ½ expon more for receiver Sender: from A y to A y+be ; Receiver: from Y a to (YB e ) a mutually relation to signcryption [Gorantla et al, Dent]
41 Group G=, hash function H, sym encryption Enc, msg auth Mac DHIES Receiver ’ s PK: A=g a Sender chooses y, sends (Y,C,T) where 1. Y = g y s = A y K = H(s) (2 expon ’ s) 2. K K1, K2 C= Enc K1 (M) T= Mac K2 (C) Decryption: s=Y a, etc (1 expon.) Authenticated DHIES R’s PK: A=g a ; Sender’s PK B=g b Sender chooses y, sends (Y,C,T) where 1. Y = g y s = A y+be e = H ½ (Y,id R ) K = H(s, id S, id R, Y) (2 expon ’ s) 2. K K1, K2 C= Enc K1 (M) T= Mac K2 (C) Decryption: s= (YB e ) a, etc (1.5 expon.) Just extra ½ exp for receiver. Free for sender. No extra communication (true also when considering co-factor expon’n or group-membership tests)
42 See what ½ exponentiation buys us Sender authentication (plus all properties of basic KE security) Sender forward security (disclosure of b does not compromise past keys and messages) y-security : The disclosure of ephemeral y does not compromise any keys or messages Moreover: the disclosure of both y and b reveals the msg sent using y but no other msgs sent by b ’ s owner Note: Just adding a signature (say DSA) on top of DHIES is signifi- cantly more expensive, provides weaker authentication (attacker can learn someone else ’ s M), and does not provides y-security
43 The Power of Proofs (not only in theory but in practice too) Proof maps exact functionality of each element in the protocol What security properties require that element and which do not What the effect of leakage of each secret value is A precise guide to protocol design and to getting rid of safety margins simpler and more efficient protocols Proofs are even excellent cryptanalysis tools for debugging protocols and finding attacks I called this “ Proof-Driven Design ” but this is a topic for another full talk …
45 Crypto: a truly cool field! Amazing ideas, beautiful math, great theory, practical and social relevance. Unusual mix of theory and practice. In crypto theory IS practical! No experimental evidence, no computer-simulations, no testing Only well-defined notions and models * to develop sound analysis ( * it ’ s ok if the models are not perfect; perfect models don ’ t exist; but w/o models and proofs we are left with “ words of gentlemen ” and broken designs) It ’ s amazing how well the theoretical notions and techniques work in practice (pseudo-randomness, simulations, zero knowledge, semantic security, even idealized random oracles and “ ugly assumptions ” such as Gap-DH) Proof-Driven Design: Sound and Practical for the same price
46 Lessons from the field… Only way to get sound crypto used is to interact with the engineers: listen, respect, argue, be persistent Practice-Efficiency-Simplicity-Beauty Timing: Not easy to sell solutions but much harder to sell problems ( see what keeps the engineers awake at night) Sound principles, robustness of design Design by functionality not by implementation (PRF/MAC/extract vs HMAC/SHA1); do not piggyback on non-crypto elements * ; design to last * examples: pre-pended length, relying on random s/n in certs, assuming “ info ” to be of fixed length (actually, adv. chosen) Remember: it ’ s not just about what to use but how to use it