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 [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
5
forward security [And97,BM99]- 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 [AMN01]
6
key-insulated security [DKXY02]
– 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 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)
9
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
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
OK
OK
OK
OK
OK
OK
time
12
key generation and update
• Gen: generates PK, SKS0 and SKB0
• UB(SKBt): generates SKBt+1 and SKUt
• US(SKSt, SKUt ): generates SKSt+1
SKBt
SKBt+1
SKSt SKUt
SKSt+1 SKUt+
SKBt+2
SKSt+2
• SKSt by itself is useful to adversary1only 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 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
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
SiBIR1 outline
• Starting point: forward secure scheme of [IR01]
– 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] ; 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]
– 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 = 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)
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 [FS86]: 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 =sH(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 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
• Use GQ scheme with T different exponents:
e1, e2 ,..., eT, 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 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 as
e is coprime with eb, ..., eT , 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 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])(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
• 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
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
32
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]
33
Scheme 2generic
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
PK1,certPK(PK1)
PK0,certPK(PK0)
PK01,certPK0(PK01)
PK010,certPK01(PK010)
today today
-Keep secret key
today
-Secret key deleted
36
Tree schemes: times & nodes
0
01
00
000
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
000
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 [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
43
gSiBIR: 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 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
46
SiBIR: 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 = 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)
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 [FS86]: 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 =sH(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 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
• Use GQ scheme with T different exponents:
e1, e2 ,..., eT, 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 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 as
e is coprime with eb, ..., eT , 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 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])(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
• 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
54