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 –…–… Can we reduce the impact of the exposures? –Security before and after Secret keys are crucial to crypto –Protect our data, privacy, etc.

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 forward security [And97,BM99]- containment –Break up time into periods (e.g., days) –Many secret keys, each computable from the previous 1 year –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 key-insulated security [DKXY02] –Like forward-security, break up time into periods 1 year –Key update requires help from a separate device ( home-base ) 12 –Security for all time periods for which secret key isn’t stolen (up to some limit on the number of thefts)

8 key-insulated model 1 2 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 (SiB IR ) 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 intrusion-resilient model 1 2 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 simultaneously with the current signing key Even in that case, past signatures remain trustworthy

12 A picture > 1,000 words OK time

13 key generation and update Gen : generates PK, SKS 0 and SKB 0 UB(SKB t ) : generates SKB t+1 and SKU t US(SKS t, SKU t ) : generates SKS t+1 SKB t SKS t+1 SKB t+1 SKU t SKS t SKB t+2 SKU t+ 1 SKS t+2 SKS t by itself is useful to adversary only for time period t SKU t & SKB t -- useless to adversary on their own

14 key refresh Keys have second index: “refresh index” RB(SKB t.r ) : generates SKB t.(r+1) and SKR t.r RS(SKS t.r, SKR t.r ) : generates SKS t.(r+1) SKB t.r SKS t.(r+1) SKB t.(r+1) SKR t.r SKS t.r SKB t.(r+2) SKR t.(r+1) SKS t.(r+2) SKR t.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, SKS t.r,) outputs 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.r for 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 compromised if –SKS t.r is exposed for some r; or –both SKS t 1.r and SKB t 1.r are both exposed for t 1 < t A key is exposed if –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 SK t is queried, cannot ask for SK t-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 e t sssigning secret s t ; invariant: s t e t mod n = v - public value s“future” secret s [t+1,T] ; where T= total number of periods SiBIR1 idea: s –Multiplicatively share s [t+1,T] ; Refresh the shares as needed sss –At update: compute shares of s t+1, s [t+2,T] from s [t+1,T] s –Reconstruct s t+1 at the signer

21 Start with forward-secure signature of [IR01] (based on GQ signature scheme) background PK = (n, v), n = p 1 p 2, v  Z n * During each time period t, the secret used to sign is š t = v 1/e t mod n For the future (up to T time periods), need also store š [t+1,T] = v 1/(e t+1 e t+2...e T ) mod n Thus, SK t = (š t, š [t+1,T] ) Update(SK t ): š t+1  (š [t+1,T] ) (e t+2 e t+3...e T ) š [t+2,T]  (š [t+1,T] ) e t+1

22 background: GQ id scheme Key Generation by a prover with parameters k and l : –Select k -bit n = p 1 p 2 ; prime e > 2 l coprime with |Z n * | –Select random š  Z n * and let v = š e mod n –Publish PK = (n, v, e) and keep SK = (n, š, e) y z  Prover with SK = (n, š, e) : Verifier with PK = (n, v, e) : –Select random r  Z n * –Commit y = r e mod n –Respond z = rš  mod n –Check if z e  yv   mod n) –Select random l -bit challenge  To identify himself, the prover will convince the verifier that he knows e -th root of v :

23 y z  Prover with SK = (n, š, e) : Verifier with PK = (n, v, e) : –Select random r  Z n * –Commit y = r e mod n –Respond z = rš  mod n –Check if z e  yv   mod n) –Select random l -bit challenge  Standard Fiat-Shamir transformation from id to signatures Observation: the only reason for the interaction is so that the verifier can provide a random  to the prover Idea [FS86]: To remove interaction and incorporate a message m, replace verifier with a hash function:  =H(y, m) –Challenge  = H(y, m) –Output (z,  ) –Compute y’  z e    v  mod n –Check if  = H(y’, m) z,  Signer of m background: GQ id scheme signature

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

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

26 solving public storage problem Where does the verifier get e 1, e 2,..., e T ? –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, , t, e) But in a forgery for time period t, e may not equal e t ! We do not care if the correct e t is used, as long as e is coprime with e b,..., e T, where b is break-in period –Very simple way to ensure that; details in paper

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

28 making it intrusion-resilient Multiplicatively share š [t+1,T] between signer and base š [t+1,T] = s [t+1,T] b [t+1,T] US (s [t+1,T], b t+1 ) : s t+1  (s [t+1,T] ) (e t+2 e t+3...e T ) š t+1  s t+1 b t+1 s [t+2,T]  (s [t+1,T] ) e t+1 UB (b [t+1,T] ) : b t+1  (b [t+1,T] ) (e t+2 e t+3...e T ) b [t+2,T]  (b [t+1,T] ) e t+1 Use š t+1 to sign during time period t+1, and save s [t+2,T]

29 making it intrusion-resilient (cont.) Refresh: Base divides b [t+1,T] by a random r, and signer multiplies s [t+1,T] by the same r Signing and verifying: same as in [IR01] Security proof: simulate the view of the adversary –easy when don’t have simultaneous exposure of b [t+1,T] and s [t+1,T], because they can be inconsistent ( b [t+1,T] s [t+1,T] = 1 ) –Problem: update message has to equal either b t+1 or s t+1 /š t+1 –Simulator doesn’t know which one of these adversary will expose after adversary queries the update message –Guess and rewind if necessary –Crucial that adversary can’t query erased information

30 making it intrusion-resilient Multiplicatively share š [t+1,T] between signer and base š [t+1,T] = s [t+1,T] b [t+1,T] US (s [t+1,T], b t+1 ) : s t+1  (s [t+1,T] ) (e t+2 e t+3...e T ) š t+1  s t+1 b t+1 s [t+2,T]  (s [t+1,T] ) e t+1 UB (b [t+1,T] ) : b t+1  (b [t+1,T] ) (e t+2 e t+3...e T ) b [t+2,T]  (b [t+1,T] ) e t+1 Use š t+1 to sign during time period t+1, and save s [t+2,T]

31 making it intrusion-resilient (cont.) Refresh: Base divides b [t+1,T] by a random r, and signer multiplies s [t+1,T] by the same r Signing and verifying: same as in [IR01] Security proof: simulate the view of the adversary –easy when don’t have simultaneous exposure of b [t+1,T] and s [t+1,T], because they can be inconsistent ( b [t+1,T] s [t+1,T] = 1 ) –Problem: update message has to equal either b t+1 or s t+1 /š t+1 –Simulator doesn’t know which one of these adversary will expose after adversary queries the update message –Guess and rewind if necessary –Crucial that adversary can’t query erased information

32 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

33 improvements Pebbling trick of [IR01] reduces the cost of update to lg T exponentiations at the expense of storing lg T values modulo n Same possible here, but: – Both parties have to pay this storage penalty –Cost of refresh goes up to lg T multiplications –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]

34 Scheme 2- generic

35 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

36 Tree schemes [BM, K, MMM; this ] PK PK 0, cert PK (PK 0 ) PK 1, cert PK (PK 1 ) PK 01, cert PK 0 (PK 01 ) PK 010, cert PK 01 (PK 010 ) today -Keep secret key -Secret key deleted today

37 Tree schemes: times & nodes Labels Secret keys correspond to nodes Leaves → signing/time period; internal nodes → “CA”s –Node v → all nodes/leaves/time-periods with v as a prefix E.g.  is a prefix for all   ’s secret key can authorize all times 

38 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

39 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  111

40 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={s i,b : i=1 to k; b=0,1}; PK={t i,b =f(s i,b )} decommit only s i,b s.t. m i =b Details –Scheduling issues, etc. –Subtle sharing and re-sharing –Skipped here for now –Secure against fully adaptive adversary

41 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

42 End

43 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

44 gSiBIR : generic Signer-Base Intrusion-Resilient Signatures Gene Itkis Boston University

45 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

46 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

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

48

49 background: GQ id scheme Key Generation by a prover with parameters k and l : –Select k -bit n = p 1 p 2 ; prime e > 2 l coprime with |Z n * | –Select random š  Z n * and let v = š e mod n –Publish PK = (n, v, e) and keep SK = (n, š, e) y z  Prover with SK = (n, š, e) : Verifier with PK = (n, v, e) : –Select random r  Z n * –Commit y = r e mod n –Respond z = rš  mod n –Check if z e  yv   mod n) –Select random l -bit challenge  To identify himself, the prover will convince the verifier that he knows e -th root of v :

50 y z  Prover with SK = (n, š, e) : Verifier with PK = (n, v, e) : –Select random r  Z n * –Commit y = r e mod n –Respond z = rš  mod n –Check if z e  yv   mod n) –Select random l -bit challenge  Standard Fiat-Shamir transformation from id to signatures Observation: the only reason for the interaction is so that the verifier can provide a random  to the prover Idea [FS86]: To remove interaction and incorporate a message m, replace verifier with a hash function:  =H(y, m) –Challenge  = H(y, m) –Output (z,  ) –Compute y’  z e    v  mod n –Check if  = H(y’, m) z,  Signer of m background: GQ id scheme signature

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

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

53 solving public storage problem Where does the verifier get e 1, e 2,..., e T ? –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, , t, e) But in a forgery for time period t, e may not equal e t ! We do not care if the correct e t is used, as long as e is coprime with e b,..., e T, where b is break-in period –Very simple way to ensure that; details in paper

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