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

1 2 3 364 365

– 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

1 2 3 364 365

– Key update requires help from a separate device (home-base)

1 2– 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 modelSigner-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

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 OK OK OK OK OK OK OK

time

13

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+1

SKBt+1

SKUtSKSt

SKBt+2

SKUt+1 SKSt+2

• SKSt by itself is useful to adversary only for time period t

• SKUt & SKBt -- useless to adversary on their own

14

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+1)

SKBt.(r+1)

SKRt.rSKSt.r

SKBt.(r+2)

SKRt.(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 verifyingMuch 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.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 SKSt1.r and SKBt1.r are both exposed for t1 < 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 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 sst ; invariant: sst e

t mod n =v - public value

• “future” secret ss[t+1,T] ; whereT= total number of periods

• SiBIR1 idea:

– Multiplicatively share ss[t+1,T] ; Refresh the shares as needed

– At update: compute shares of sst+1 , ss[t+2,T] from ss[t+1,T]

– Reconstruct sst+1 at the signer

22

background: GQ id scheme Key Generation by a prover with parameters k and l :

– Select k-bit n = p1 p2; prime e > 2l coprime with |Zn*|

– Select random šZn* 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 rZn

*

– Commit y = re mod n

– Respond z = ršmod n– Check if ze yvmod 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 rZn

*

– Commit y = re mod n

– Respond z = ršmod n– Check if ze yvmod 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’ zevmod 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 findingthe 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 e1 has nothing to do with finding a root of v of degree e2 as long as (e1, e2) = 1

ei

• Use GQ scheme with T different exponents:e1, e2 ,..., eT, pairwise coprime (and coprime with |Zn

*|)

• Have T secrets: š1, š2 ,..., šT : ši vmod 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

26

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, , 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

27

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

• During key update compute št+1 (š[t+1,T])(et+2 et+3 ...eT)

š[t+2,T] (š[t+1,T])et+1

• Now only 2 secret values!• Security does not change

• Instead, store “superoots”: let š[t,T] be root of degree et...eT

(š[t,T])(et et+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

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 storinglg 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

PK0,certPK(PK0)PK1,certPK(PK1)

PK01,certPK0(PK01

)

PK010,certPK01(PK010)

today

-Keep secret key

-Secret key deletedtoday 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

111

0 1

00 111001

000 001 010 011 100 101 110

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 101-111

0 1

00 111001

000 001 010 011 100 101 110

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={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

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 Itkisitkis@bu.edu

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 = p1 p2; prime e > 2l coprime with |Zn*|

– Select random šZn* 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 rZn

*

– Commit y = re mod n

– Respond z = ršmod n– Check if ze yvmod 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 rZn

*

– Commit y = re mod n

– Respond z = ršmod n– Check if ze yvmod 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’ zevmod 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 findingthe 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 e1 has nothing to do with finding a root of v of degree e2 as long as (e1, e2) = 1

ei

• Use GQ scheme with T different exponents:e1, e2 ,..., eT, pairwise coprime (and coprime with |Zn

*|)

• Have T secrets: š1, š2 ,..., šT : ši vmod 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

53

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, , 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

54

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

• During key update compute št+1 (š[t+1,T])(et+2 et+3 ...eT)

š[t+2,T] (š[t+1,T])et+1

• Now only 2 secret values!• Security does not change

• Instead, store “superoots”: let š[t,T] be root of degree et...eT

(š[t,T])(et et+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