1. 1 Self Protecting Cryptosystems Moti Yung Columbia University/ RSA Labs

2. 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. 3 Example: RSA public: N=pq, secret: primes p, q - RSA: public key - message= M encryption: M e mod N. - decryption: M d mod N where d  e -1 mod  (N)

4. 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. 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. 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. 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. 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. 9 Different Paradigms  Forward security  Key-insulated security  Intrusion-resilience  Applicable to essentially any cryptographic functionality (public-/private- key authentication, encryption, signatures, etc.)

10. 10 Forward Security (Anderson ‘97)  Fixed public key PK; initial secret key SK 0  At time period i, device locally computes SK i = Upd(SK i-1 )  Public-key operation uses PK and i  Secret-key operation uses SK i

11. 11 Forward Security…  Note: Exposure of SK i necessarily implies that the system is “broken” for t  i This is implied by the model…  What about periods t < i?

12. 12 Goal  If the Upd function is one-way, exposure of SK i does not necessarily reveal SK i-1 (!)  Exploiting this, forward-secure systems guarantee that exposure of SK i does not affect security of the system for any t < i SK 0 SK 1 SK i-1 SK i SK N … SK i+1 … exposed Secure insecure (non-exposed)

13. 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 SK i for any i (in addition to signatures on chosen messages), cannot forge signatures for time periods t < i

14. 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. 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. 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. 17 Drawbacks of Forward-Security  Once SK i 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. 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. 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. 20 SK 1 Server Device SK 2 SK 3 SK * SK N … time

21. 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. 22 Security Guarantees  Can achieve stronger security guarantees than in forward-secure systems  If SK i 1,SK i 2,…,SK i t are exposed, only these time periods are (necessarily) “broken” All other periods t  {i 1,…,i t } remain “secure”! SK 0 SK 1 SK i-1 SK i SK N … SK i+1 … exposed secure

23. 23 Additional Security Guarantees  Possible to additionally protect against an untrusted server Clearly, in this case the server cannot simply send SK i  Possible to protect against eavesdropping on server/device communication Clearly, in this case the server cannot simply send SK *

24. 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. 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. 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. 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. 28 Intrusion-Resilience  Key concept: secret keys evolve on both the device and the server…

29. 29 SK 1 Server Device time SK’ 1 SK 2 SK’ 2 SK 3 SK’ 3 SK N SK’ N … …

30. 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. 31 To Illustrate…  If the device is compromised for periods i 1, …, i t and the server is compromised for all other time periods, time periods t  {i 1,…,i t } 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. 32 Intrusion-Resilient Schemes  Intrusion-resilient signature schemes [Itkis- Reyzin ‘02, Itkis ‘03]  Intrusion-resilient PKE [DFKMY03]

33. 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. 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. 35 The rest  I will cover various schemes in the various models  Will mention briefly distributed schemes  Will cover the various key evolving paradigms