I ntrusion- R esilient Signatures

1. Intrusion-Resilient Signatures Moti Yung

2. Model + Signatures • work by: Gene Itkis and Leonid Reyzin

3. Recall Our Context • Problem: keys get lost or stolen • People lose laptops/PDAs/cell phones • Hackers break into computers • … • Secret keys are crucial to crypto • Protect our data, privacy, etc. • Can we reduce the impact of the exposures? • Security before and after

4. how • Split keys • Threshold/proactive • server-assisted,… • Evolve keys • Forward-secure • Both • Key-insulated • Intrusion-Resilient (here)

5. threshold/proactive crypto • Threshold Cryptography [DF89,DDFY94] • Share the secret among multiple parties • Use multi-party computation techniques [Yao86,GMNW87] • Secure as long as fewer than, e.g., 1/2 are corrupted • Proactivization [OY91,HJJKY97] • Periodically refresh the sharing to resist mobile adversary • Secure as long as fewer than, e.g. 1/2 are corrupted at any given time (even if all parties are corrupted at some time) • Drawback: This is risk reduction but • Cooperation needed for every secret-key operation

6. 1 2 3 364 365 1 year forward security [And97,BM99]- containment • Break up time into periods (e.g., days) • Many secret keys, each computable from the previous • Single public key • Time period incorporated into signing/encrypting • If a secret key is stolen, transactions with past time periods are ok • Nothing can be done for the future • Can combine threshold/proactive and forward security [AMN01]

7. 1 2 3 364 365 1 year 2 1 key-insulated security [DKXY02] • Like forward-security, break up time into periods • Key update requires help from a separate device (home-base) • Security for all time periods for which secret key isn’t stolen(up to some limit on the number of thefts)

8. 2 1 key-insulated model • Signing key: only useful to a thief for a short time • Update info: treated as equal to two signing keys • Home-base information: useless by itself • If both signing key & base info are exposed -- scheme broken!!! • so, it might be prudent to revoke (public) key, after one secret is compromised - just in case the other is compromised later

9. desiderata • Convenience of one-party operations • not provided by threshold etc. • Security for both past and future • not provided by forward-secure • Home-base compromises inconsequential,unless simultaneous with signer • similar to proactive, not provided by key-insulated • Forward-security if everything is compromised simultaneously • not provided by key-insulated and most threshold/proactive (in fact an advantage of key insulated from performance perspective)

10. answer: intrusion-resilient model Signer-Base Intrusion-Resilient (SiBIR) signatures • Signer (user): generates all signatures • Base (helper): provides updates • Signing and verifying similar to forward-secure sigs: • Public key does not change • Secret keys evolve • Signature includes time period • Time is input for both signature generation and verification

11. 2 1 intrusion-resilient model • Signer: has info useful only for a short time • Update info: useless by itself • combined with the previous signing key yields next one • Base (helper) info: useless unless exposed simultaneouslywith the current signing key • Even in that case, past signatures remain trustworthy

12. OK OK OK OK OK OK OK OK A picture > 1,000 words time

13. SKBt+1 SKBt+2 SKUt SKUt+1 key generation and update • Gen: generates PK, SKS0 and SKB0 • UB(SKBt): generates SKBt+1 and SKUt • US(SKSt, SKUt): generates SKSt+1 SKBt SKSt SKSt+1 SKSt+2 • SKStby itself is useful to adversary only for time period t • SKUt &SKBt-- useless to adversary on their own

14. SKBt.(r+2) SKBt.(r+1) SKRt.(r+1) SKRt.r key refresh • Keys have second index: “refresh index” • RB(SKBt.r): generates SKBt.(r+1) and SKRt.r • RS(SKSt.r, SKRt.r): generates SKSt.(r+1) SKBt.r SKSt.r SKSt.(r+1) SKSt.(r+2) • SKRt.r is useless to adversary on its own

15. update vs. refresh • Number of updates is limited; number of refreshes is not • Update happens at the end of pre-specified time period; refresh can happen at any time (e.g., when you suspect compromise) • reduces adversary’s chances of simultaneous compromise • Update is visible to the outside world; refresh is not • Updates are necessarily one-way; refreshes aren’t required to be

16. signing and verifying Much like in forward-secure schemes: • Sign (m, t, SKSt.r,) outputs <sig,t> • Ver (m, PK, t, sig) outputs “valid”/ “invalid” • Signatures will only verify if correct time period is input (part of security requirements)

17. adversary • adaptive-chosen-message • get any msgs signed for any time periods • adaptively expose SK[S/B/U/R]t.rfor arbitrary t,r • wins if manages to forge a signature on a new (m,t) for an uncompromised time period t • Time period t is compromisedif • SKSt.ris exposed for some r; or • both SKSt1.r and SKBt1.r areboth exposed for t1< t • A key isexposedif • it is queried by the adversary; or • the previous key and update/refresh info are exposed

18. adversary power • Fully adaptive (as in K.I.) • No restrictions on order of queries • Can query keys from the past (which were erased!) • First scheme was not shown secure, second is. • Partially synchronous • Cannot expose secrets from the past • After SKt is queried, cannot ask for SKt-d - key already erased • In other words: • Adversary cannot go back in time too far • Once a key is erased it cannot be queried • First scheme secure wrt this adversay

19. Scheme 1

20. SiBIR1 outline • Starting point: forward secure scheme of [IR01] • Based on GQ signatures • Each time period t uses • exponent et • signing secret st; invariant: stetmod n =v - public value • “future” secret s[t+1,T] ; whereT= total number of periods • SiBIR1 idea: • Multiplicatively share s[t+1,T] ; Refresh the shares as needed • At update: compute shares of st+1 , s[t+2,T] from s[t+1,T] • Reconstructst+1 at the signer

21. Prover with SK =(n, š, e): Verifier withPK = (n, v, e): • Select random rZn* y • Commity = re mod n s z background: GQ id scheme Key Generation by a prover with parameters k and l : • Select k-bitn = p1 p2; prime e > 2lcoprime with|Zn*| • Select random šZn* and let v = še mod n • Publish PK =(n, v, e) and keep SK =(n, š, e) To identify himself, the prover will convince the verifier that he knows e-th root of v: • Select random l-bit challenges • Respondz = ršs mod n • Check if zeºyvs (mod n)

22. Prover with SK =(n, š, e): Verifier withPK = (n, v, e): z, s • Select random rZn* y • Commity = re mod n s z signature background: GQ id scheme • Standard Fiat-Shamir transformation from id to signatures • Observation: the only reason for the interaction is so that the verifier can provide a random s to the prover • Idea [FS86]: To remove interaction and incorporate a message m, replace verifier with a hash function: s=H(y, m) Signer of m • Compute y’=ze/vs mod n • Check if s= H(y’, m) • Select random l-bit challenges • Challenge s= H(y, m) • Respondz = ršs mod n • Check if zeºyvs (mod n) • Output (z, s)

23. security of GQ scheme • In the random oracle model, forging GQ signatures is provably as hard as findingthe e-th root of v modulo n(All other non-black-box forward-secure schemes are also in the random oracle model)

24. Use GQ scheme with T different exponents:e1, e2 ,..., eT, pairwise coprime (and coprime with |Zn*|) • Have T secrets: š1, š2 ,..., šT : ši ºv(mod n) • Even if an adversary breaks-in and learns šb,..., šT , itwill not be able to forge signatures for time period t<b: • that would require knowledge of an “independent” root of v ei main idea for forward security • [Shamir83]: Roots of co-prime degrees are “independent” • In other words,knowing a root of v of degree e1 has nothing to do with finding a root of v of degree e2 as long as (e1, e2) = 1

25. solving public storage problem • Where does the verifier get e1, e2 ,..., eT? • Putting them in the public key is too expensive • The verifier can recompute them, but that takes time • Solution: add a value e to the signature (z, s, t, e) • But in a forgery for time period t,e may not equal et! • We do not care if the correct et is used, as long ase is coprime with eb, ..., eT , where b is break-in period • Very simple way to ensure that; details in paper

26. During key update compute št+1(š[t+1,T])(et+2et+3...eT)š[t+2,T]  (š[t+1,T])et+1 • Now only 2 secret values! • Security does not change solving secret storage problem • Need T different roots of v: š1 ,..., šT of degrees e1 ,..., eT • Too much secret storage: at time period t, store št,..., šT • Instead, store “superoots”: let š[t,T] be root of degree et...eT (š[t,T])(etet+1...eT) = v • Can compute st,...,sT from š[t,T] (and vice versa) • Then need only store š[t+1,T] , for the next time period t+1

27. result • SiBIR1 is provably secure in the random oracle model under strong RSA assumption semi-synch adversary • Performance • Signing and verifying are as good as GQ: • 2 modular exponentiations, each with short exponent • Refresh: a single multiplication • Update: O(T) exponentiations • Storage: each stores 2-3 values modulo n • Message sizes: 1 value modulo n

28. improvements • Pebbling trick of [IR01] reduces the cost of update to lg T exponentiations at the expense of storinglg Tvalues modulo n • Same possible here, but: • Both parties have to pay this storage penalty • Cost of refresh goes up to lg Tmultiplications • Messages sizes go up to lg T values modulo n • Recent work: • Solving above problem and reducing further computation and communication for the signer: particularly suited for mobile/weak signers [IR02]

29. Scheme 2- generic

30. Tree schemes • Previous tree schemes • Forward secure signatures [BM, K, MMM] • Pseudo-random functions [GGM], Merkle trees • Our contributions • Generalize/improve infinite tree construction of [MMM] • Intrusion-resilient tree construction for signatures

31. Tree schemes [BM, K, MMM; this] PK PK1,certPK(PK1) PK0,certPK(PK0) PK01,certPK0(PK01) PK010,certPK01(PK010) -Keep secret key today today today -Secret key deleted

32. Tree schemes: times & nodes • Labels • Secret keys correspond to nodes • Leaves → signing/time period; internal nodes → “CA”s • Nodev→ all nodes/leaves/time-periods with v as a prefix • E.g.  is a prefix for all ’s secret key can authorize all times 0 1  01 00 11 10 111 101 110 010 100 011 000 001

33. Previous tree schemes • Fixed length certification chains • Forward secure [BM,K] • Intrusion-resilient [this work] • Two-level • Forward-secure [MMM] • Really: a “very large” fixed length • All the above use simple prefixless strings • Leaves  prefixless • Better prefixless codes exist!!! • One contribution of this work • Applies to both forward-secure & intrusion-resilient tree schemes • details in the paper 0 T-1 …

34. 0 1  01 00 11 10 101 110 010 100 011 000 001 IR tree-scheme • Goal: make tree-scheme IR • Challenge: maintain and use secrets for the future • E.g. going from 011 to 100 must use 1’s secret • Potential problem 1 can also create sigs for 101-111 111

35. Approach • Use one-time signatures for certs • “one-time” is enough; secrets shared as usual • one-time sigs allow targeted decommitment • decommit only part of the secret • only one msg can be signed with decommitted part • e.g. SK={si,b: i=1 to k; b=0,1}; PK={ti,b=f(si,b)}decommit only si,b s.t. mi=b • Details • Scheduling issues, etc. • Subtle sharing and re-sharing • Skipped here for now • Secure against fully adaptive adversary

36. conclusions • new model: Intrusion Resilient [Crypto’02] • Enhances security for digital signatures: • Exposing a secret, compromises security for only a short time •  no need to revoke key – restoring security easier than revocation • Need not trust home base • Minimum communication • Efficient schemes • Scheme 1 (Crypto’02), scheme 2 (SCN’02)-- generic • New tree-schemes (scheme 2) • Prefixless codes → more efficient unbounded time period • Both: forward-secure and intrusion-resilient

37. End

38. future work & open problems • IR Signatures • One module “light” • “light” signer [IR02] • “light” base - OPEN • IR Encryption • Not possible before forward-secure encryption [CHK02] • Intrusion-resilient encryption [DKY02] • Other crypto primitives made IR • OPEN • Applications • OPEN

39. gSiBIR: generic Signer-Base Intrusion-Resilient Signatures Gene Itkis itkis@bu.edu Boston University

40. conclusions • New model: Intrusion Resilient • there is a demo!!! • Enhances security for digital signatures: • Exposing a secret, compromises security for only a short time • Therefore, no need to revoke your key if you lose it -- by the time you revoke, security will be restored, anyway • Need not trust home base • Minimum communication • Efficient scheme, based on already-deployed signatures

41. future work & open problems • IR Signatures • Generic SiBIR scheme [I02] • One module “light” • “light” signer [IR02] • “light” base - OPEN • IR Encryption • Not possible before forward-secure encryption [CHK02] • Intrusion-resilient encryption [DKY02] • Other crypto primitives made IR • OPEN • Applications • OPEN

42. SiBIR: Signer-Base Intrusion-Resilient Signatures Gene Itkis and Leonid Reyzin Boston University

44. Prover with SK =(n, š, e): Verifier withPK = (n, v, e): • Select random rZn* y • Commity = re mod n s z background: GQ id scheme Key Generation by a prover with parameters k and l : • Select k-bitn = p1 p2; prime e > 2lcoprime with|Zn*| • Select random šZn* and let v = še mod n • Publish PK =(n, v, e) and keep SK =(n, š, e) To identify himself, the prover will convince the verifier that he knows e-th root of v: • Select random l-bit challenges • Respondz = ršs mod n • Check if zeºyvs (mod n)

45. Prover with SK =(n, š, e): Verifier withPK = (n, v, e): z, s • Select random rZn* y • Commity = re mod n s z signature background: GQ id scheme • Standard Fiat-Shamir transformation from id to signatures • Observation: the only reason for the interaction is so that the verifier can provide a random s to the prover • Idea [FS86]: To remove interaction and incorporate a message m, replace verifier with a hash function: s=H(y, m) Signer of m • Compute y’=ze/vs mod n • Check if s= H(y’, m) • Select random l-bit challenges • Challenge s= H(y, m) • Respondz = ršs mod n • Check if zeºyvs (mod n) • Output (z, s)

46. security of GQ scheme • In the random oracle model, forging GQ signatures is provably as hard as findingthe e-th root of v modulo n(All other non-black-box forward-secure schemes are also in the random oracle model)

47. Use GQ scheme with T different exponents:e1, e2 ,..., eT, pairwise coprime (and coprime with |Zn*|) • Have T secrets: š1, š2 ,..., šT : ši ºv(mod n) • Even if an adversary breaks-in and learns šb,..., šT , itwill not be able to forge signatures for time period t<b: • that would require knowledge of an “independent” root of v ei main idea for forward security • [Shamir83]: Roots of co-prime degrees are “independent” • In other words,knowing a root of v of degree e1 has nothing to do with finding a root of v of degree e2 as long as (e1, e2) = 1

48. solving public storage problem • Where does the verifier get e1, e2 ,..., eT? • Putting them in the public key is too expensive • The verifier can recompute them, but that takes time • Solution: add a value e to the signature (z, s, t, e) • But in a forgery for time period t,e may not equal et! • We do not care if the correct et is used, as long ase is coprime with eb, ..., eT , where b is break-in period • Very simple way to ensure that; details in paper

49. During key update compute št+1(š[t+1,T])(et+2et+3...eT)š[t+2,T]  (š[t+1,T])et+1 • Now only 2 secret values! • Security does not change solving secret storage problem • Need T different roots of v: š1 ,..., šT of degrees e1 ,..., eT • Too much secret storage: at time period t, store št,..., šT • Instead, store “superoots”: let š[t,T] be root of degree et...eT (š[t,T])(etet+1...eT) = v • Can compute st,...,sT from š[t,T] (and vice versa) • Then need only store š[t+1,T] , for the next time period t+1