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