Key-Dependent Input Security in Cryptography: Insights and Implications
This paper delves into the complexities of key-dependent input (KDI) security in cryptography, discussing its applications, challenges, and potential pitfalls. It explores concepts such as “self-encryption” and the nuances of key management, alongside notable prior work in the field. The standardization efforts of IEEE 1619 are highlighted, examining their security considerations and practical implications, particularly in the context of sector-level encryption. The paper critiques existing models and proposes insights for enhancing security in key-dependent systems.
Key-Dependent Input Security in Cryptography: Insights and Implications
E N D
Presentation Transcript
Security UnderKey-Dependent Input Shai Halevi Hugo Krawczyk IBM
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?
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
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
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
The IEEE 1619 Story IEEE 1619: Standard Architecture for Encrypted Shared Storage Media
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
The LRW Construction x h(t) • Ps,h(t,x) = Es(xh(t))h(t) • Es is sPRP, h is “xor universal” • Proven secure in [LRW02] • Specifically: Ps,a(t,x) = Es(x(at))(at) • at is multiplication in GF(2n) • In early 2006, IEEE 1619 working group was set to standardize this mode Es y
a(t+1) z =z + a(t+1) =z + at What’s Wrong with LRW? • Fails when “encrypting its own key” • Extract a = y1-y2 a 0 at a(t+1) Es Es y1 y2
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
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?
q1 g Answer(q1) Answer(g(s)) q2 Answer(q2) Adversary Specifies a Function of Key Slight variations for different security notions s …
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
Inherent impossibility 2 A-la-[BK03] • Assume a deterministic fs • Adversary sets gi,1(s)=s+2i, gi,2(s)=s2i • 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
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…
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)sm>
KDI Failure • With respect to g(s)=s • Encs(s) = <r, Er(s)ss> = <r, Er(s)> • Given <r,y>, adversary recovers s = Er-1(y) • Attack works even when E is ideal cipher
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
Results for PRFs Wanted: a PRF which is C-KDI-secure for every |C |=1
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))
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
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
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
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
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
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
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
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
Some Open Problems • KDI-secure encryption in standard model • “Circular-secure” encryption • Invertible KDI-secure PRFs