1 / 31

Security Under Key-Dependent Input

Security Under Key-Dependent Input. Shai Halevi Hugo Krawczyk IBM. Encrypting Your Own Key. Ciphertext = Enc s (s) More generally, Enc s ( some-function-of -s) Why would you want to do this? Seems like an abuse of the cryptosystem How can you expect security?

Download Presentation

Security Under Key-Dependent Input

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Security UnderKey-Dependent Input Shai Halevi Hugo Krawczyk IBM

  2. Encrypting Your Own Key • Ciphertext = Encs(s) • More generally, Encs(some-function-of-s) • Why would you want to do this? • Seems like an abuse of the cryptosystem • How can you expect security? • How can you prove it?

  3. Why Look at This? • Accidents Happen • Poorly-designed key-management can result in “self-encryption” (more on that later) • Comes up when comparing “axiomatic security” and “complexity-based security” • Useful in anonymous-credential systems • Used as deterrence against key-delegation

  4. Prior Work Key-Dependent Message • Black, Rogaway & Shrimpton 2002 • Encs(M) = <r, H(s|r)+M> is “KDM-secure”when H is a random oracle • Camenisch & Lysyanskaya 2001 • “Circular-secure” PKE in the random-oracle model, use for anonymous-credentials • Laud & Corin 2003, Adao et al. 2005 • Relations to “axiomatic security” • Concurrent work of Hofheinz, Unruh

  5. KDI is bad enough for randomized encryption, even worse when you don’t have randomness This Work • Extend Black et al., also to deterministic constructions (e.g. PRFs, PRPs,…) • Renamed KDM to KDI (Input instead of Msg) • Many negative examples • Even in the random-oracle/ideal cipher models • Some rather surprising • Some constructions • Even in the standard model

  6. The IEEE 1619 Story IEEE 1619: Standard Architecture for Encrypted Shared Storage Media

  7. Sector-level encryption • Must be length-preserving (=>deterministic) • Use “tweakable ciphers” [LRW02] • y = Ps(t,x), x = Ps-1(t,y) • For each s,t, Ps(t,*) permutation • Adversary with oracles Ps(*,*), Ps-1(*,*) cannot distinguish from a collection of random & independent permutations • Tweak is used as location on disk

  8. The LRW Construction x h(t) • Ps,h(t,x) = Es(xh(t))h(t) • Es is sPRP, h is “xor universal” • Proven secure in [LRW02] • Specifically: Ps,a(t,x) = Es(x(at))(at) • at is multiplication in GF(2n) • In early 2006, IEEE 1619 working group was set to standardize this mode Es y

  9. a(t+1) z =z + a(t+1) =z + at What’s Wrong with LRW? • Fails when “encrypting its own key” • Extract a = y1-y2 a 0 at a(t+1) Es Es y1 y2

  10. Is This a Problem in Practice? • Lively argument in the 1619 mailing list • “No one in their right mind will ever do that” • Turns out that “encrypting own key” can happen in Windows Vista™ • A driver does sector-level encryption • On hibernate, driver itself stored to disk • So a different mode (based on Rogaway’s XEX) was chosen for the standard

  11. Why XEX? • About as efficient as LRW • The attack from before does not apply • How do we know that there isn’t some other attack in this vein? • Can we define/prove security?

  12. Defining KDI Security

  13. q1 g Answer(q1) Answer(g(s)) q2 Answer(q2) Adversary Specifies a Function of Key Slight variations for different security notions s …

  14. Inherent Impossibility 1 • Assume an invertible Ps • Adversary sets g(s)=Ps-1(s) • Ps(g(s)) = Ps(Ps-1(s)) = s • Not every function can be tolerated • A scheme is C-KDI-secure if it is secure when adversary only uses functions from C

  15. Inherent impossibility 2 A-la-[BK03] • Assume a deterministic fs • Adversary sets gi,1(s)=s+2i, gi,2(s)=s2i • fs(gi,1(s))=fs(gi,2(s)) “iff” i’th bit of s is 0 • Cannot tolerate C that is “too rich” • Even if the individual functions in C are simple • Even makes sense to require C-KDI-security only with respect to |C|=1

  16. Results for Randomized Encryption

  17. A Surprising Negative Example • Textbook scheme: Encs(m) = <r, fs(r)m> • Black et al. show that when fs(x) = H(s|x), this is KDI secure in the ROM • So let’s use fs(x) = SHA1-Compression(IV=s, M=x) • Surely this should be safe…

  18. The Davis-Meyer Construction • fs(x) = Ex(s)s, where E is a block cipher • Most contemporary compression functions are built this way (s=IV, x=message-block) • This fs “should be a PRF” • The HMAC proof of security assumes that it is • Can be proven PRF when E is an ideal-cipher • We get Encs(m) = <r, Er(s)sm>

  19. KDI Failure • With respect to g(s)=s • Encs(s) = <r, Er(s)ss> = <r, Er(s)> • Given <r,y>, adversary recovers s = Er-1(y) • Attack works even when E is ideal cipher

  20. A Construction that Works • Encs(m)=<r, fs(r)fs(m)> • f is invertible, Decs(r,y)=fs-1(fs(r)y) • If f is C-KDI-secure then so is Enc • Proof is straightforward • Which is better <r, AESs(r)  m>or <r, AESs(r)  AESs(m)> ? • Both “work” if AES is replaced with ideal cipher • AES “needs only be KDI-secure” for the latter

  21. Results for PRFs Wanted: a PRF which is C-KDI-secure for every |C |=1

  22. Negative Results • A secure PRF need not be KDI-secure even with respect to g(s)=s • Fs(x) = s if x=s fs(x) otherwise • For every Fs there is g such that Fs is not {g}-KDI-secure • For example, g(s)=Fs(0) • Adversary can check if Fs(Fs(0))=Fs(g(s))

  23. Positive Results in Standard Model • A PRF with “salt”, fsr • “Salt” r is public randomness, s is secret seed • For every g(s), fsr is {g}-KDI-secure whp over r • Implies a {g}-KDI-secure PRF for each g • Via a non-constructive argument • A constructive argument when g is “well spread” • say, g(s) has min entropy ≥|s|/2 • For each g, adifferent (g-dependent) salted invertible {g}-KDI-secure PRF

  24. A “Salted” PRF The point: extr(s) is almost uniform even given H(g(s)) • Fsr(x) = fextr(s)(H(x)) • fs’ is a regular PRF • extr(*) is a strong randomness extractor • H is length-decreasing (say, from n to n/2 bits) • Can be collision-resistant hashing • Or even something based on universal hashing • Note: Fsr is not invertible • Can’t be used for randomized encryption as above

  25. Proof of Security Prove that the adversary cannot distinguish this from the “real PRF” • The “Random” world: • f is a random function, s,r are random strings • Adversary sees r, f(g(s)), f(q1), f(q2), … • Hybrid 1: • f is a random function, s,r are random strings • Adversary sees r, f(H(g(s))), f(H(q1)),f(H(q2)),… • Same as Random if no H-collisions

  26. Proof (cont.) • Hybrid 2: • s’, s, r are random strings • Adversary sees r, fs’(Compress(g(s))), fs’(Compress(q1)), fs’(Compress(q2)), … • s’ is independent of s, r • Adversary cannot distinguish Hybrid 1from Hybrid 2 since fs’ is a PRF

  27. Proof (cont.) • The “Real” world: • s, r are random strings, s’=extr(s) • Adversary sees r, fs’(H(g(s))),fs’(H(q1)),fs’(H(q2)),… • Adversary’s view uniquely determined by<r, s’, H(g(s))> • Distribution over <r, s’, H(g(s))> statistically close in Hybrid 2, Real QED

  28. An Invertible KDI-secure PRF? • ??? • For each g, a different (g-dependent) invertible {g}-KDI-secure PRF • Frs(x) = fextr(s)(0) if x=g(s) fextr(s)(1|x) otherwise • Using fs(*) instead of fextr(s)(*) does not work • May be surprising

  29. Other Results • Things are easier in the ideal-cipher model • Fs(x) = Ps(x) is a KDI-secure PRF wrt any function g that is independent of P • Es(t,x) = PP(t)(x) is KDI-secure tweakable cipher wrt any function g that is independent of P • Other construction as well • A KDI-secure-PRF wrt g(s)=s in standard model, using the Blum-Micali PRG • Similar to unpublished construction of Barak s

  30. The Moral • ??? • KDI-security is a fragile property • Well-designed systems should not abuse their cryptography in this way • When KDI security is needed, some schemes may work, others do not • Random-oracle/ideal-cipher analysis may not always tell us which is which

  31. Some Open Problems • KDI-secure encryption in standard model • “Circular-secure” encryption • Invertible KDI-secure PRFs

More Related