1 / 42

Key-Insulated Public Key Cryptosystems Moti Yung, RSA Labs and Columbia U.

Key-Insulated Public Key Cryptosystems Moti Yung, RSA Labs and Columbia U. Key Exposure Protection. Talk based on papers published in: EC-02 and PKC-03 (Joint work with: Y. Dodis, J. Katz and S. Xu)

alina
Download Presentation

Key-Insulated Public Key Cryptosystems Moti Yung, RSA Labs and Columbia U.

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. Key-Insulated Public Key CryptosystemsMoti Yung, RSA Labs and Columbia U.

  2. Key Exposure Protection • Talk based on papers published in: EC-02 and PKC-03 (Joint work with: Y. Dodis, J. Katz and S. Xu) • Nowadays: assuming a mobile device and a host (e.g., a home computer) is right (everyone will have/has a mobile and a computer). • Thus: we can strengthen crypto based on it! ….and derive other applications in the process…..

  3. Key Exposure • Most cryptosystems rely on possession of small totally secret entity (key) to perform various complex tasks. • What if the key is lost/stolen/exposed? (e.g., mobile device, Internet, snooping)? • One of the most serious ``real-life'' attacks: • often easier to steal the key than to break the underlying “cryptography”. • Can we do anything?

  4. Solution Approaches • Tamper-resistant hardware (smartcards). • Partial Key Exposure (weaker problem) • Secret sharing, Threshold Cryptography. • All-or-Nothing Transforms (AONT), ERF’s. • Key Evolution: change secret key over time such that exposure of “current” key minimizes the overall “damage”. • Forward security (protect past transactions) • Key-Insulated Security (this talk)

  5. good exposed bad (non-exposed) Forward Security • N periods, single public key PK • Initial Secret key SK0 • At period i: • secret key SKi = Upd(i, SKi-1) • “effective” public key PKi = (PK, i) • Public OP done with PKi, secret OP done with SKi • Goal: under exposureof SKi, • Periods 1,…,(i-1) are still secure • Periods i,…,N are necessarilycompletely broken SK0 SK1 … SKi-1 SKi SKi+1 … SKN

  6. SK* helper key . . . good exposed Key-Insulated Security • N periods, single public key PK • Initial Secret key SK0, … • At period i: • secret key SKi = Upd(i, SKi-1, …) • “effective” public key PKi = (PK, i) • Public OP done with PKi, secret OP done with SKi • Goal: under exposureof SKi1,SKi2,…,SKit • Any period i  {i1,…,it} is still secure • Only periods i1,…,it are(necessarily) broken SK0 … SKi1 … SKi2 SKit … SKN

  7. High-Level Idea • Unlike forward security, user U no longer performs key updates by itself: • “Helper” H assists the user • forward-security limitation no longer applies! • All secret OPs are still done by Ualone • Different from threshold/server-aided crypto! • (t,N)-security: exposure of any t secret keys leaves every non-exposed period secure • Strong(t,N)-security: H should not be able to perform any of the secret OPs (untrusted H)

  8. More on the Model • Stronger than forward security guarantee • New: introduction of possibly untrusted H • cheap key updates: one message from H to U • All OPs by U (unlike Threshold) • H can’t compromise U (no “master” key) • Possible formalization: • Setup: (PK, SK0, SK*), U gets SK0, H gets SK* • SKi=Upd(SKi-1, SK*), where H sends SK* • What if Adv compromises key update? • H cannot send SK*! • SKi=Upd(SKi-1, hi), where H sends hi = Help(SK*,i)

  9. Key Updates • Secure Key Updates: • Minimal possible harm under exposure of inter-period key-updating information (the hi’s) • Key update exposure between periods (i-1) and i key exposure at periods (i-1) and i • SKi-1 + hi (+ SKi) SKi-1 + SKi • Random Access Key Updates: • H can help go between SKj and SKi for any i,j • E.g., emergency “future Sig” or “past Dec” • SKi=Upd(SKj, hij), wherehij = Help(SK*, (ji))

  10. The Attacker • Fully adaptive and concurrent • attacks all N periods concurrently • adaptively issues “key exposure” requests (for security against H, replaced by the knowledge of SK*) • succeeds if breaks any one of the non-exposed periods (for signature means forges a “new” message in the given period) • Typically stronger than “real life”

  11. Brief Generic Summary • Any non-exposed period secure • All OPs done without helper • Key Updates: • Secure against inter-period exposure • Cheap and non-interactive • Random access: can go from anyj to anyi • Security against helper • Fully adaptive and concurrent attacker • Achieve all, but often a subset suffices

  12. assume trusted helper Applications • Key Exposure Protection (original) • Limited-Time Delegation • Limited-Time Key Escrow • Identity-based Cryptography • Users identified by “non-crypto” ID(U)=i • One common public key • t users can’t compromise another user • Ideal: t=N-1, but smaller t often enough

  13. Relation to ID-based Crypto • An (N-1,N)-key-insulated signature / encryption scheme is also an ID-based scheme [DKXY02,BP02] • Our approach based on “trapdoor primitives” encompasses all known non-generic constructions of ID-based primitives [S84,BF01,CC03,…] • Also yields new constructions (e.g., signature based on 2t-root/factoring assumption)

  14. Our Results I: Signatures • Strong key-insulated signature schemes • Generic scheme based on any signature scheme • Scheme based on discrete logarithms • Most efficient: scheme based on any “trapdoor signature” scheme (similar approach works for encryption, but only one “trapdoor encryption” scheme is known)

  15. Generic Signature Scheme • Building blocks • Any regular signature scheme • Parameters: • t=N-1, maximal resiliency • Everything constant (equal to 2 or 3) • Pretty much “optimal” uses a “certification idea” • (Like in forward security: sig. Easier than enc.) • Morale: While we do not have full implementation of PKI, we can exploit its ideas…

  16. Optimal Signature Scheme • PK=(VKU,VKH), SK0=SKU, SK*=SKH • SKi= (SKU, ski, SigH(vki,i)) • SigH(vki,i)is “certificate” for (ski, vki) • Update: H sends ski, cert-I=SigH(vki,i) for current-period keys (ski, vki) • Signature of m at period i: (Sigvki(m), SigU(m, i), cert-I=SigH(vki,i)) • Verification: check all sigs (Note: same trick with SKU can make any key insulated signature strong)

  17. Efficiency… • Achieves “optimal” security • (Small) slowdown: • Signing time x2 • Verification time, signature length x3 • Key update = 1 signing operation + 1 key generation (key generation may be costly…)

  18. Idea behind all DL-based schemes • Secret polynomial p(x)=a0+a1x+…+atxt • PK = (ga0, ga1,…, gat) • SK0 = a0 = p(0), SK* = (a1,…,at) • “Effective Keys” at period i: SKi = p(i); PKi = gp(i) = gSKi • Notice: • PKi = ga0 (ga1)i (ga2)i2 … (gat)it = f(PK, i) • SKi= SKj + (SKi - SKj) = SKj + hij, where hij=Help(SK*,(ji)) = p(j) – p(i)

  19. Idea Continued • Take cryptosystem where pk = gsk • E.g., Schnorr signature, ElGamal encryption • Evolve keys as stated (functionality) • Security intuition: • For any t keys p(i1),p(i1),…,p(it), the value p(i) is truly random for i  {i1,…,it} • Helper: w/o a0 any value p(i)is random • Hardness of discrete log ensures that ga0, ga1,…, gat do not “help” the breaker

  20. Security? • Thm: for fixed{i1,…,it}, can’t break security at any period i  {i1,…,it} • Security means: adversary cannot forge a signature in these periods (even when initially can access signing machine, cannot sign on its own a new message)

  21. Security ? • Security againstnon-adaptive adversary only! • Public key is “committing”, so need to know in advance in which period to embed the “unknown discrete log” • This is unrealistic model to limit the adversary to attack at given times!

  22. sk=x; pk=z=gx; Sig(m)=(gr,r-tx), wheret=O(gr,m) Ver((w,a),m) = = [w = zt ga] sk=(x,y); pk=z=gxhy; Sig(m)=(grhs,r-tx,s-ty), wheret=O(grhs,m) Ver((w,a,b),m) = = [w = zt ga hb] ? ? Getting Adaptive Security • Use two random generators g and h! sk = (x,y);pk = z = gx hy • 2-generator Okamoto vs. 1-generator Schnorr

  23. Getting Adaptive Security • Use two random generators g and h! sk = (x,y);pk = z = gx hy • 2-generator Okamoto vs. 1-generator Schnorr • Many legal ways to open the public key • Use p(x) and q(y) to evolve both keys • SKi = (xi=p(i), yi=q(i)), PKi = zi = gxihyi • No longer decide in advance where to put the hardness: know all secret keys, reduce to hardness of computing logg h !

  24. More Details on Key Evolution • Use two generators! • Random p(x) = a0 + a1x + … + atxtandq(x) = b0 + b1x + … + btxt • Now: PK = (ga0hb0, ga1 hb1,…, gat hbt) andSK* = (a1,b1,…,at,bt) • “Effective keys” for period i: SKi = (p(i), q(i)); PKi = gp(i)hq(i)

  25. Efficiency… • Only secure against a given number t of break-ins (public-key size is O(t)) • Efficiency: • Fast key update (no cryptographic ops) • Basic signing (encrypting) time same as Okamoto-Schnorr (two-generator ElGamal) • Has (small) overhead of computing the “period public key”, but can be done once per period– (computing polynomial in the exponent trick)

  26. Using “trapdoor” signatures • Say signature F has sk=x, vk=(y,”f”), where y=f(x) and f satisfies: • f is easy to invert using trapdoor T • Given u, z, easy to verify if f(u)=z using “f” only • Note, sk does not have to include T ! • Examples: • Schemes where f is a trapdoor “permutation” (Guillou-Quisquater, Fiat-Shamir, Ong-Schnorr) • Recent signatures in “gap-DH” groups where DDH is easy and CDH is hard [CC03] (all use f(ga) = gab where “f” = gb and T=b)

  27. Using “trapdoor” signatures • Set global PK=“f”, SK*=T, vki=RO(i) • H sends ski = f-1(vki) (computed using T) to U, who uses(ski, vki) for period i • To get strong security, distribute T and jointly compute ski = f-1(vki) • Easy for most common schemes • Same approach is used in current identity-based schemes[S84,BF01,CC03]

  28. Efficiency • As efficient as the underlying signature (encryption) scheme • Achieves optimal security in RO model • Drawback: only works for specific assumptions

  29. Our Results II: Encryption • Key-insulated public-key encryption • (t,N)-security from any semantically-secure encryption scheme • Can extend to (t,N)-CCA2-security • Efficient (t,N)-security based on DDH • (t,N)-CCA2-security based on DDH • All schemes are strong and have secure key updates /random access key updates • Also: third scheme based on BF01….

  30. Preliminaries • Encryption algorithm takes public key PK, period i, and message M and returns <i, C> <i,C>  EPK(i, M) • Decryption algorithm takes secret key SKi and ciphertext <i, C> and returns M

  31. The Adversary • Intuitively: adversary tries to fail the encryption on any of unexposed key periods • Adversary has access to: • Key exposure oracle – Exp(i) returns SKi • Left-and-right oracle – Given a vector b = (b1, …, bN), oracle LRPK,b(i,M0,M1) returns EPK(i, Mbi)

  32. Definition of Security • Vector b = (b1, …, bN)chosen at random • Adversary gets PK; asks t queries to Exp and poly-many queries to LR concurrently and adaptively • Adversary outputs (i, b’) s.t. Exp(i) not called • (t,N)-secure if| Pr[b’ = bi] – ½ |is negligible

  33. Generic Construction • Building blocks: • Semantically-secure encryption scheme • All-or-nothing transform (AONT) • t-cover free family of sets • Parameters: • |PK| = |SK| = O(t2 log N) • Enc. time and ciphertext length = O(t log N) • Key updating time = O(t log N) • Using the cover-free property, adversary cannot learn keys of other periods for any t corruptions.

  34. Result • A generic scheme that works for N periods, t exposures and requires O(t2 log N) in total, O(t log N) per period. • The proof uses the fact that we use all or nothing and embeds an unknown key (in a guessed position) and breaks it if adversary is successful.

  35. Approach for DL-Based Schemes • Idea: random p(x)=a0 + a1x + … + atxt PK = (ga0, ga1,…, gat); SK0 = a0; SK* = (a1,…,at) • “Effective keys” for period i: SKi = p(i); PKi = gp(i) = gSKi • Notice again: PKi = ga0 (ga1)i (ga2)i2… (gat)it SKi = SKj + (SKi - SKj) = SKj + Help(SK*,(i,j))

  36. Approach, continued… • Now use El Gamal encryption: EPK(i, M) = <i, gr, (PKi)r M> • Intuition: • For any t keys p(i1),p(i1),…,p(it), the value p(i) is truly random for i  {i1,…,it} • Hardness of discrete log ensures that ga0, ga1,…, gat do not “help”

  37. Security? • Again: only non-adaptive case…. • So not secure in the sense we want.

  38. Adaptive Security • Again, we use two generators! …………. • Random p(x) = a0 + a1x + … + atxtandq(x) = b0 + b1x + … + btxt • Now: PK = (ga0hb0, ga1 hb1,…, gat hbt) andSK* = (a1,b1,…,at,bt) • “Effective keys” for period i: SKi = (p(i), q(i)); PKi = gp(i)hq(i)

  39. Adaptive Security cont’d… • Encrypt as:EPK(i,M) = <i, gr, hr, (PKi)r M> • Decrypt via:DSKi(<i, (u, v, z)>) = z/up(i)vq(i) • Thm: Scheme achieves strong (t,N)-security against adaptive adversary • Remark: Modification based on Cramer-Shoup achieves CCA2 (security even when adversary probes the system freely with ciphertexts of its choice.)

  40. Proof Sketch • DDH: given (g,h,u,w) decide if loggu=loghw • Use g and h, choose all secret keys, publish PK. Note: all Exp-queries can be answered! • When Adv asks LR-query (i,m0,m1), choose random b and return (u,w,up(i)wq(i)mb) • If loggu = loghw, perfect simulation • If u,w random, view of Adv is info-theoretically independent of b

  41. Conclusions • Formal definition of “key-insulated” model • Many advantages over previous models • Variety of efficient implementations • Key-insulated paradigm is relevant to many algorithms and protocols • Inspired further research (e.g., intrusion-resilient model); relation to ID-based.. • Applications to delegation, key escrow, ID-based sig. etc.

  42. Conclusions • Cryptography should evolve as technology evolves • Cryptography should be part of a solution, even when the problem does not look “cryptographic • …and sometimes relatively efficient/ simple solutions are found… • Also…better security solution may lead to new functionality!

More Related