Post on 25-Dec-2015
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