Burt Kaliski RSA conference 2007

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
How valid are these points in your
deployments?

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
Which fits better in your
organization or product?

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

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
How do you see the “SKI
renaissance” playing out?

11. Some Lessons to Consider
1. 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
2. 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

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
3. 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”
3. Keys are security objects, not just sensitive data.
• Encrypt at security module layer, not (only) application layer
• i.e., key wrapping and SSL
5. 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
6. Key classification should be driven by data classification and
policy. More than just encryption vs. signature.
7. Key access control should model “need to know”: more often
groups of applications than single principals.
8. Algorithm agility is essential.
• Not just DES and triple-DES anymore …
6. Trusted software execution can help provide assurances
required for security modules – as well as non-repudiation.
7. 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
Is anybody seriously thinking
about this?

16. Typical Cryptographic Security Services Today
User
Authentication
Passwords / OTPs + PKI encryption
PKI tokens
Encryption Symmetric algorithms
Non-Repudiation PKI signatures
Symmetric algorithms w/trusted verifier
Key
Establishment
(online case)
PKI encryption
Symmetric algorithms w/TTP
Key
Establishment
(offline case)
PKI encryption

17. The Picture without Today’s PK Encryption …
User
Authentication
--
--
Encryption Symmetric algorithms
Non-Repudiation --
Symmetric algorithms w/trusted verifier
Key
Establishment
(online case)
--
Symmetric algorithms w/TTP
Key
Establishment
(offline case)
--

18. Next, with a Renaissance of SKI
User
Authentication
Password/OTP + trusted client w/symmetric crypto
Symmetric crypto tokens
Encryption Symmetric algorithms
Non-Repudiation --
Symmetric algorithms w/trusted verifier
Key
Establishment
(online case)
--
Symmetric algorithms w/TTP
Key
Establishment
(offline case)
--

19. … and Some Other Technologies (Old & New)
User
Authentication
Password/OTP + trusted client w/symmetric crypto
Symmetric crypto tokens
Encryption Symmetric algorithms
Non-Repudiation Merkle hash signatures
Symmetric algorithms w/trusted verifier
Key
Establishment
(online case)
--
Symmetric algorithms w/TTP
Key
Establishment
(offline case)
Near-Field Communication

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 Kaliski
RSA Laboratories
burt@rsa.com
kaliski_burt@emc.com
http://www.rsasecurity.com/rsalabs