Learning to SKI Again: The Renaissance of Symmetric Key Infrastructures

1. Learning to SKI Again: The Renaissance of Symmetric Key Infrastructures Burt Kaliski,RSA, The Security Division of EMC,02/06/07 � DEV-208

2. Learning to Ski � Again Around 1980, I first learned to ski downhill at the McIntyre Ski Area in Manchester, NH Over 20 years later, I started skiing again with my family Skiing has changed a lot in two decades: Shaped skis offer easier turns Snowboards provide a single-board alternative Still, skiing is just as much fun

3. Symmetric Key Infrastructure A symmetric key infrastructure or SKI is a coordinated set of components and services for managing symmetric keys Symmetric keys include: Data encryption and integrity-protection keys Key encryption keys Device authentication keys Passwords can also be considered a type of symmetric key �Managing� includes full key lifecycle

4. Why Symmetric Key Management? As information becomes more valuable, data protection also grows in importance Encryption �safe harbor� in breach notification legislation is a significant driver But data is stored and processed in many different layers, locations Databases, files, disks, tapes, virtual images � Encrypting data is the (relatively) easy part Managing all the decryption keys is the hard part Symmetric keys are needed for many other purposes as well

5. Why SKI? Typical key management solutions are application-specific Enterprise IT managers need policy, auditing across the solutions Keys sometimes have to be shared among multiple applications A common key management infrastructure enables IT managers to focus on policy, and applications to focus on security integration SKI = an infrastructure of key managers � not a single server

6. SKI Functions Application interface (illustrative): Get Key (keyID) ? key, attributes Get Key (attributes) ? key, keyID -- lookup, or generate as needed Set Key (keyID, attributes, key) Administrative operations Policy management Key lifecycle: create, distribute, archive, retrieve, revoke, destroy Built on a foundation of identity & access management A role for PKI within the SKI!

7. Uber versus Meta Key Managers �ber key manager stores the keys for other key managers Meta key manager coordinates policies and placement Probably need some of each

8. SKI vs. PKI Similarities: Policy and lifecycle administration Application interfaces e.g., PKI GetKey (issuer / serial) ? public key / certificate PKI SetKey ~= local generation + certificate registration Differences in key secrecy, availability: PKI public keys: Public, available to everyone PKI private keys: Secret, available to one principal SKI keys: Secret, available to a group of principals typically associated with one data classification

9. SKI over the Years Even before public-key encryption and PKI, there have always been symmetric keys to manage � Data Encryption Standard published in 1976 IBM�s work leading to Common Cryptographic Architecture dates back to 1978 X9.17 - Financial Institution Key Management (Wholesale), introduced in 1985 for the banking industry. Kerberos, released in 1987, manages keys for user authentication Conditional access systems have long delivered symmetric keys for cable and satellite TV Branstad-Smid developed Key Notarization Facility for NBS, c. 1983 X9.17 defines: Triple-DES Three-level symmetric key hierarchy (master, key-encrypting, data)Branstad-Smid developed Key Notarization Facility for NBS, c. 1983 X9.17 defines: Triple-DES Three-level symmetric key hierarchy (master, key-encrypting, data)

10. Towards a Renaissance In a sense, PKI has been the �dark ages� of SKI SKIs have continued, but have been out of focus for the last decade Risks of renewal without reflection: Trying to use an existing SKI as is Trying to make a new SKI fit the PKI mold Forgetting about lessons learned from both SKI and PKI Better: Apply the experiences of three decades from both areas

11. Some Lessons to Consider Key hierarchies reduce compromise risk. Master Key / Key Encrypting Key / Data Encrypting Key Lower-levels keys wrapped with (next) higher-level key Time- and context-limited keys PKI trust hierarchies are similar, but for certification, not secrecy Key derivation gives more flexibility and reduces risk, without additional key distribution. Key2 = KDF (Key1, parameters) Benefits: key separation; forward security; �subscription� models PKI counterparts: forward-secure signatures, ID-based encryption Key derivation needs more explicit support in key management infrastructure, e.g., a way of recording the associations between derived keys and other keys so that it�s not necessary to do a lookup Key derivation needs more explicit support in key management infrastructure, e.g., a way of recording the associations between derived keys and other keys so that it�s not necessary to do a lookup

12. Key Derivation: Example Verifier-specific keys for one-time password tokens: KTV = KDF (KT, IDV) Key manager stores token key KT, distributes KTV to verifier V Token stores KT, derives KTV given IDV Token can authenticate to verifier via KTV; verifiers don�t have to share keys Another example: KB = KDF (KA, time) � parties can �subscribe� to supply of keys for a given time interval (Micali �94 for key escrow) Also: KB = KDF (KA, �next�) � KA remains secret if KB compromised ? forward security for non-repudiation

13. Some Lessons to Consider Key wrapping is more than just encryption. AES-KeyWrap encrypts & integrity-protects key, and can associate with attributes (usage, etc.) Various public-key encryption schemes also offer �associated data� Keys are security objects, not just sensitive data. Encrypt at security module layer, not (only) application layer i.e., key wrapping and SSL Key usage restrictions provide better control. Encryption vs. authentication vs. key transport vs. � MAC generation separate from verification, though same key

14. Some Lessons to Consider Key classification should be driven by data classification and policy. More than just encryption vs. signature. Key access control should model �need to know�: more often groups of applications than single principals. Algorithm agility is essential. Not just DES and triple-DES anymore � Trusted software execution can help provide assurances required for security modules � as well as non-repudiation. Side channel attacks continue to be a threat. Short-lived keys are a valuable countermeasure.

15. Final Thought: What if There Were No PKI? More accurately: What if there were no PK encryption? Related question: What if PK encryption hadn�t been invented? Quantum computing makes this a realistic possibility over a 30-year timeframe

16. Typical Cryptographic Security Services Today PKI assumes certificates, i.e., a signature algorithm, for identity and attribute managementPKI assumes certificates, i.e., a signature algorithm, for identity and attribute management

17. The Picture without Today�s PK Encryption � PKI assumes certificates, i.e., a signature algorithm, for identity and attribute managementPKI assumes certificates, i.e., a signature algorithm, for identity and attribute management

18. Next, with a Renaissance of SKI PKI assumes certificates, i.e., a signature algorithm, for identity and attribute managementPKI assumes certificates, i.e., a signature algorithm, for identity and attribute management

19. � and Some Other Technologies (Old & New) PKI assumes certificates, i.e., a signature algorithm, for identity and attribute managementPKI assumes certificates, i.e., a signature algorithm, for identity and attribute management

20. Conclusions Symmetric Key Infrastructures are seeing a renaissance, thanks to increased interest in data protection PKI was perhaps the �dark ages� for SKI Lessons learned from SKI past as well as PKI present can be applied to SKI future

21. Questions? Questions?

22. Contact Information Burt KaliskiRSA Laboratoriesburt@rsa.comkaliski_burt@emc.comhttp://www.rsasecurity.com/rsalabs