Post on 05-Feb-2016
description
1
Self Protecting Cryptosystems
Moti Yung Columbia University/ RSA Labs
2
Key Exposure
The security of most cryptosystems relies crucially on some secret information (keys)
What if these keys are lost, stolen, or otherwise exposed?
In some application environments, key exposure represents a very serious risk
3
Example: RSA
public: N=pq, secret: primes p, q
- RSA: <N,e> public key
- message=M encryption: M e mod N.
- decryption: M d mod N where d e-1 mod (N)
4
Some Examples…
The threat of key exposure is increased as cryptographic algorithms are deployed on inexpensive, lightweight, and mobile devices PDAs, mobile phones, laptops, … Ad-hoc/sensor networks; “disposable” devices
Key exposure may also occur as a result of poor key management
5
The Threat
Key exposure can be a devastating attack! When secret keys are revealed, all security
guarantees are typically gone Once there are no more secrets, the situation seems
hopeless… In signature schemes, the owner may claim the key
is stolen for “repudiation”…… Can anything be done?
6
Possible Approaches
Avoidance: Tamper-resistant hardware (with no side channel Attacks)
Decreasing likelihood of exposure (spread risk): Secret sharing Threshold cryptography Server-aided cryptography Proactive systems Time-stamping server
Containment of key exposure (self-protection): Key-evolving cryptosystems
7
Different Protections for different Architectures
Distributed Systems: Many units perform the “sign” or “decrypt” – agents acting in a system is changed to a distributed entity
Key Evolving: A single Unit act as Cryptographic Container (e.g., one cellphone)
8
Key-Evolving Cryptosystems
Time is divided into N periods (e.g., days) Secret key stored on a device is dynamically
updated over time Public key (when applicable) remains fixed Exposure of the key at period i affects only a
limited number of other time periods End of period: update– for self protection
9
Different Paradigms
Forward security Key-insulated security Intrusion-resilience
Applicable to essentially any cryptographic functionality (public-/private- key authentication, encryption, signatures, etc.)
10
Forward Security (Anderson ‘97)
Fixed public key PK; initial secret key SK0
At time period i, device locally computes SKi = Upd(SKi-1)
Public-key operation uses PK and i Secret-key operation uses SKi
11
Forward Security…
Note: Exposure of SKi necessarily implies that the system is “broken” for t i This is implied by the model…
What about periods t < i?
12
Goal
If the Upd function is one-way, exposure of SKi does not necessarily reveal SKi-1 (!)
Exploiting this, forward-secure systems guarantee that exposure of SKi does not affect security of the system for any t < i
SK0 SK1 SKi-1 SKi SKN… SKi+1 …exposedSecure insecure (non-exposed)
13
E.g., Forward-Secure Signatures
Signature on a message m is a pair (i, ) where i is the period at which m was signed
Verification uses fixed public key PK; in effect, verifying that m was signed at time i
Even if adversary learns SKi for any i (in addition to signatures on chosen messages), cannot forge signatures for time periods t < i
14
Using Forward-Secure Signatures
If a user learns that key exposure occurred at period i, she simply announces this fact Signatures for time periods subsequent to i are
no longer accepted as valid
Non-repudiation? (it helps limit repudiation as time moves)
15
Secure Constructions (Signatures)
Anderson ‘97 Secret-key size O(N)
Bellare-Miner ‘99 (also, formal definitions) Signing/verifying require O(N) time
Krawczyk ‘00, Abdalla-Reyzin ‘00, Itkis-Reyzin ‘01, Malkin-Micciancio-Miner ‘02 Various tradeoffs; O(log(N)) complexity possible
16
Other Forward-Secure Systems
Forward-secrecy in key exchange protocols (e.g., [Diffie-van Oorschot-Weiner ‘92])
Forward-secure shared-key cryptography [Bellare-Yee ‘03]
Threshold forward-secure signatures [Abdalla-Miner-Namprempre ‘01, Tzeng-Tzeng ‘02]
More recently: forward-secure PKE [Canetti, Halevi Katz ’03]
17
Drawbacks of Forward-Security
Once SKi is exposed, no protection for future time periods Indeed, impossible in this model
Forward-secure schemes are less efficient than “standard” schemes
Can we gain anything by assuming some protected storage?
18
Key-Insulated Security [DKXY02]
“Server” Secure, protected storage; likely immobile Perhaps computationally-limited Not necessarily trusted
“Device” Mobile; inherently vulnerable to key exposure Performs all actual cryptographic operations
19
Key-Insulated Security
Time is divided into N periods and the public key is fixed, as before
Device updates its key by interacting with the server at the beginning of each period
Device itself performs all crypto operations for the remainder of the period --- this is not a threshold scheme (though motivated by threshold proactive systems)
20
SK1
Server
Device SK2 SK3
SK*
SKN…
time
21
Possible Instantiations
E.g.: Server = docking station; device = mobile phone Server = desktop computer; device = laptop Server = base station; device = sensor node Etc. In the mobile world– period based
“delegation” and exchange make sense.
22
Security Guarantees
Can achieve stronger security guarantees than in forward-secure systems
If SKi1,SKi2
,…,SKit are exposed, only these
time periods are (necessarily) “broken” All other periods t {i1,…,it} remain “secure”!
SK0 SK1 SKi-1 SKi SKN… SKi+1 …exposed secure
23
Additional Security Guarantees
Possible to additionally protect against an untrusted server Clearly, in this case the server cannot simply
send SKi
Possible to protect against eavesdropping on server/device communication Clearly, in this case the server cannot simply
send SK*
24
More Formally…
(t, N)-security: Following exposure of up to t (arbitrary) secret keys, all unexposed time periods remain secure
Strong (t, N)-security: Additionally guarantees security against an untrusted server
Secure key updates (informally): Eavesdropping on communication between the device and the server is equivalent to key exposure at adjacent periods
25
Connection with ID-based
ID-based scheme key-insulated scheme achieving (N-1, N)-security View time periods as IDs
However: IBE may be “overkill” Computationally expensive (e.g., compared to
RSA or El Gamal) (t, N)-security (with t << N) may be enough
26
Some Additional Work
Construction of (t, N)-key-insulated PKE from generic PKE [DKXY02]
Further analysis of key-insulated PKE [BP02] Recently– private key Constructions of (N-1, N)-key-insulated signature
schemes [DKXY03] In turn gives new constructions of ID-based
signature schemes
27
Intrusion-Resilience [IR02]
Combines forward-security and key-insulation to give the strongest security model (so far…)
Key-insulation guarantees security only when device keys are compromised In general, compromise of both the server and
the device (at any time) “breaks” the system
28
Intrusion-Resilience
Key concept: secret keys evolve on both the device and the server…
29
SK1
Server
Device
time
SK’1
SK2
SK’2
SK3
SK’3
SKN
SK’N
…
…
30
Security Guarantees
If the keys on the device and the server are exposed for disjoint time periods, scheme achieves key-insulated security
If the keys on the device and the server are exposed for the same time period, scheme achieves forward security
31
To Illustrate…
If the device is compromised for periods i1, …, it and the server is compromised for all other time periods, time periods t {i1,…,it} remain secure
Even if the server alone is compromised for all time periods, all time periods remain secure
If the device and the server are both compromised at time i, time periods t < i remain secure
32
Intrusion-Resilient Schemes
Intrusion-resilient signature schemes [Itkis-Reyzin ‘02, Itkis ‘03]
Intrusion-resilient PKE [DFKMY03]
33
Comparison…
Forward-security Device is self-sufficient; no need for a “server”
Key-insulation If a server is available, provides stronger security
guarantees Schemes designed for this model are currently
the most efficient The only one with random access applications
34
Comparison…
Intrusion-resilience Achieves the strongest level of security But…since intrusion-resilient schemes also
achieve forward-security, such schemes can be no more efficient than forward-secure ones
If the server is trusted/secure, this level of security may be “overkill”
35
The rest
I will cover various schemes in the various models
Will mention briefly distributed schemes Will cover the various key evolving
paradigms