Learning to SKI Again: The Renaissance of Symmetric Key Infrastructures

Burt Kaliski,RSA, The Security Division of EMC,

02/06/07 – DEV-208

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

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

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

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?

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!

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?

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

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

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?

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

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

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”

4. 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

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 …

9. Trusted software execution can help provide assurances required for security modules – as well as non-repudiation.

10.Side channel attacks continue to be a threat. Short-lived keys are a valuable countermeasure.

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?

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

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)

--

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)

--

… 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

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

Questions?

•Questions?

Contact Information

•Burt KaliskiRSA Laboratoriesburt@rsa.comkaliski_burt@emc.comhttp://www.rsasecurity.com/rsalabs