1 / 35

Self Protecting Cryptosystems

Self Protecting Cryptosystems. Moti Yung Columbia University/ RSA Labs. Key Exposure. The security of most cryptosystems relies crucially on some secret information (keys) What if these keys are lost, stolen, or otherwise exposed?

amara
Télécharger la présentation

Self Protecting Cryptosystems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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: Me mod N. - decryption: M d mod N where d º e-1 mod f (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. Secure exposed insecure (non-exposed) 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 anyt < i SK0 SK1 … SKi-1 SKi SKi+1 … SKN

  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 SK2 SK3 SK* SKN … Server Device 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. secure exposed Security Guarantees • Can achieve stronger security guarantees than in forward-secure systems • If SKi1,SKi2,…,SKitare exposed, only these time periods are (necessarily) “broken” • All other periods t {i1,…,it} remain “secure”! SK0 SK1 … SKi-1 SKi SKi+1 … SKN

  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 SK’1 SK2 SK’2 SK3 SK’3 SKN SK’N … … Server Device time

  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

More Related