IntrusionResilient Signatures Moti Yung 1 Model Signatures work

Intrusion-Resilient Signatures Moti Yung 1

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

Recall Our Context • Secret keys are crucial to crypto – Protect our data, privacy, etc. • 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 3

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

threshold/proactive crypto • Threshold Cryptography [DF 89, DDFY 94] – Share the secret among multiple parties – Use multi-party computation techniques [Yao 86, GMNW 87] – Secure as long as fewer than, e. g. , 1/2 are corrupted • Proactivization [OY 91, HJJKY 97] – 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 5

forward security [And 97, BM 99]- containment – Break up time into periods (e. g. , days) – Many secret keys, each computable from the previous 1 2 – Single public key – – 3 364 365 1 year 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 [AMN 01] 6

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

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 8

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

answer: intrusion-resilient model Signer-Base Intrusion-Resilient (Si. BIR) 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 10

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 11

A picture > 1, 000 words OK OK time 12

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

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 SKBt. (r+1) SKBt. (r+2) SKSt. r SKRt. r SKSt. (r+1) SKRt. (r+1) SKSt. (r+2) • SKRt. r is useless to adversary on its own 14

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 15

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) 16

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 – SKSt. r is exposed for some r; or – both SKSt 1. r and SKBt 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 17

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 18

Scheme 1 19

Si. BIR 1 outline • Starting point: forward secure scheme of [IR 01] – Based on GQ signatures – Each time period t uses • exponent et • signing secret st ; invariant: st et mod n =v - public value • “future” secret s[t+1, T] ; where. T= total number of periods • Si. BIR 1 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] – Reconstruct st+1 at the signer 20

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 |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: Prover with SK = (n, š, e): – Select random r Zn* y – Commit y = re mod n s – Respond z = ršs mod n z Verifier with PK = (n, v, e): – Select random l-bit challenge s – Check if ze º yvs (mod n) 22

background: GQ signature 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 [FS 86]: To remove interaction and incorporate a message m, replace verifier with a hash function: s =H(y, m) Signer of m with SK = (n, š, e): Verifier with PK = (n, v, e): Prover z, s – Select random r Zn* y e / vs mod n – Commit y = re mod n – Compute y’ = z – Select random l-bit s – Check – Challenge s = H(y, m) challenge if s =s. H(y’, m) – Respond z = ršs mod n z – 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 finding the e-th root of v modulo n (All other non-black-box forward-secure schemes are also in the random oracle model) 24

main idea forward security • [Shamir 83]: 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 • Use GQ scheme with T different exponents: e 1, e 2 , . . . , e. T, pairwise coprime (and coprime with |Zn*|) • Have T secrets: š 1, š 2 , . . . , šT : šiei º 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 25

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, 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 as e is coprime with eb, . . . , e. T , where b is break-in period – Very simple way to ensure that; details in paper 26

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 • Instead, store “superoots”: let š[t, T] be root of degree et. . . e. T (š[t, T])(et et+1. . . e. T) = v • Can compute st, . . . , s. T from š[t, T] (and vice versa) • Then need only store š[t+1, T] , for the next time period t+1 • During key update compute št+1 (š[t+1, T])(et+2 et+3. . . e. T) š[t+2, T] (š[t+1, T])et+1 • Now only 2 secret values! • Security does not change 27

result • Si. BIR 1 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 32

improvements • Pebbling trick of [IR 01] 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 [IR 02] 33

Scheme 2 generic 34

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 35

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

Tree schemes: times & nodes 0 01 00 001 1 010 11 10 011 100 101 110 111 • 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 37

Previous tree schemes • Fixed length certification chains – Forward secure [BM, K] – Intrusion-resilient [this work] 0 T-1 • 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 38

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 0 01 00 001 1 010 11 10 011 100 101 110 111 39

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 40

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 41

• End 42

future work & open problems • IR Signatures – One module “light” • “light” signer [IR 02] • “light” base - OPEN • IR Encryption – Not possible before forward-secure encryption [CHK 02] – Intrusion-resilient encryption [DKY 02] • Other crypto primitives made IR – OPEN • Applications – OPEN 43

g. Si. BIR: generic Signer-Base Intrusion-Resilient Signatures Gene Itkis itkis@bu. edu Boston University 44

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 45

future work & open problems • IR Signatures – Generic Si. BIR scheme [I 02] – One module “light” • “light” signer [IR 02] • “light” base - OPEN • IR Encryption – Not possible before forward-secure encryption [CHK 02] – Intrusion-resilient encryption [DKY 02] • Other crypto primitives made IR – OPEN • Applications – OPEN 46

Si. BIR: Signer-Base Intrusion-Resilient Signatures Gene Itkis and Leonid Reyzin Boston University 47

48

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 |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: Prover with SK = (n, š, e): – Select random r Zn* y – Commit y = re mod n s – Respond z = ršs mod n z Verifier with PK = (n, v, e): – Select random l-bit challenge s – Check if ze º yvs (mod n) 49

background: GQ signature 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 [FS 86]: To remove interaction and incorporate a message m, replace verifier with a hash function: s =H(y, m) Signer of m with SK = (n, š, e): Verifier with PK = (n, v, e): Prover z, s – Select random r Zn* y e / vs mod n – Commit y = re mod n – Compute y’ = z – Select random l-bit s – Check – Challenge s = H(y, m) challenge if s =s. H(y’, m) – Respond z = ršs mod n z – Check if ze º yvs (mod n) – Output (z, s) 50

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) 51

main idea forward security • [Shamir 83]: 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 • Use GQ scheme with T different exponents: e 1, e 2 , . . . , e. T, pairwise coprime (and coprime with |Zn*|) • Have T secrets: š 1, š 2 , . . . , šT : šiei º 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 52

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, 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 as e is coprime with eb, . . . , e. T , where b is break-in period – Very simple way to ensure that; details in paper 53

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 • Instead, store “superoots”: let š[t, T] be root of degree et. . . e. T (š[t, T])(et et+1. . . e. T) = v • Can compute st, . . . , s. T from š[t, T] (and vice versa) • Then need only store š[t+1, T] , for the next time period t+1 • During key update compute št+1 (š[t+1, T])(et+2 et+3. . . e. T) š[t+2, T] (š[t+1, T])et+1 • Now only 2 secret values! • Security does not change 54