`
Key Management
The Connection Between Policy and Encryption
Terence Spies
CTO
Voltage Security
Agenda





Encryption as a security mechanism
The emergence of key management
Key management technologies
Key management and encryption is no longer
confined to silos (messaging, storage, networking)
Key management requires understanding overall
access control and business policies

Business and technical leadership must cooperate
*** Confidential and Proprietary ***
Encryption is Inevitable


“Classic” access control protects edges
Outsourcing, partnering, customer data access



All create new, complex edges
Can’t control all of them anymore
Encryption protects without edges
*** Confidential and Proprietary ***
The use of encryption has changed
Encryption Yesterday

Encryption Today
Driver: Secrecy




Sensitive communications
Machine to machine protocols
 Connection encryption
 Static, machine keys
 SSL/VPN
Data encryption

Small user set
 Pre-enrolled users
 S/MIME, etc.
Driver: Compliance, Privacy


HIPAA, PCI, SB1386, SOX
User and group protocols

Document encryption
 Dynamic group & user keys
 App, email, database enc

Data encryption

Large user set
 External, ad hoc users
 New apps and protocols
*** Confidential and Proprietary ***
Policy drives this evolution
Old Model





New Model
“Encrypt this data to a
trusted machine”
Plaintext on the trusted
machine
Defending against untrusted
wires

10s - 100s of keys
Machine authentication




“Encrypt this document to a
trusted group”
No stored plaintext
anywhere
Defending against untrsuted
storage
1000s - 1000000s of keys
User, group, role auth
*** Confidential and Proprietary ***
Key Management



Key Management is the bridge between old and new
Encryption is just a tool
Key Management connects business policy to security
enforcement



What is Key Management
How can Key Management be done?
Key Management as a technology category
*** Confidential and Proprietary ***
Data Encryption is Easy!
Do this 10 times:


Well, it’s at least understood….but not really
But we can ignore the core crypto for now
*** Confidential and Proprietary ***
Encryption is easy, Key Management is hard
How do we make sure both
sides have the right keys?
Encryption
Key
Decryption
Key
*** Confidential and Proprietary ***
What is hard about managing keys?

Enrollment



Key creation, duplicate keys
Distribution
Lookup, Storage and Access


Finding the encryption key of a system
Recovery of decryption keys
•
Content scanning, filtering, audit
• Archiving for compliance, supervision


Synchronizing distributed key stores
Key life cycle


Revoking keys, expiring keys
Backup of keys, disaster recovery
*** Confidential and Proprietary ***
New Model Key Management

SSL/VPN model




Policy based encryption model




One certificate per domain
Costly enrollment process (~$150/cert)
10-100 keys
One key per user or group
Can’t pay $150/directory entry!
1000-1MM keys
Makes a difficult problem a nearly impossible one
*** Confidential and Proprietary ***
How is key management done?

Central server


Certificates


Symmetric key, ie. Kerberos
Public key, ie. Classic “PKI”
Identities

Identity-based Encryption
*** Confidential and Proprietary ***
The Basic Key Management Operations

Actors

The Authority
•

Trusted, can authenticate all participants
Originator
•
Wants to encrypt something to someone
• Might be a group or an individual

Receiver
•
Authorized receiver
*** Confidential and Proprietary ***
The Basic Key Management Operations

Operations




Authority, Originator, Receiver: Initialize
Originator: Get Encryption Key
Receiver: Get Decryption Key
We can compare scalability, efficiency, flexibility on
these operations
*** Confidential and Proprietary ***
Symmetric Key Management
Basic principle: use the same encryption algorithm to manage keys

Initialize:


Receiver, Originator: share a key with the authority
Get Encryption Key
Authority sends K encrypted with originator’s key
 Or, Receiver sends K encrypted with rec key


Get Decryption Key

Originator decrypts K
 Or, originator requests K encrypted with org key
*** Confidential and Proprietary ***
Key Management for Symmetric Keys
Example: 8 devices
Key
Server
Key Store
4
5
3
6
7
2
8
2
5
3
6
4
7
2
3
4
5
6
7
8
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
How many keys total
for 8 people?
1
1
1
*** Confidential and8
Proprietary ***
28 keys
Certificate Based Key Management

Basic principle: use a public key algorithm

Public key in a nutshell:





Encrypt(M, K1) -> C
Decrypt(C, K2) -> M
Symmetric: K1 == K2
Public key: K1 != K2
Allows separation of who can encrypt and decrypt
*** Confidential and Proprietary ***
Certificate Based Key Management

Initialize:

Authority: Generate a signing key
 Receiver: Generate a key pair, E and D. Send E to Authority, who
signs “Receiver” + E together
•


Originator: Get verification key from authority
Get Encryption Key


(this signed object is a certificate)
Originator: Get certificate (somehow…..), verify signature, extract
key
Get Decryption Key

Receiver: Decrypt
*** Confidential and Proprietary ***
Seems simple….

Except that it’s never just A to B

How do you



Recover a key if a receiver disappears?
Distribute the database of certificates?
Make a certificate for a group?
*** Confidential and Proprietary ***
Identity-Based Encryption (IBE) –
Breakthrough in Cryptography

IBE - proposed 20 years ago as next generation encryption


In 1984 Adi Shamir, co-inventor of the RSA Algorithm, challenged
cryptographers to invent IBE
IBE solution is created 2 decades later in 2001



Research funded by DARPA (DoD research)
Boneh-Franklin Algorithm published at Crypto 2001
An award-winning breakthrough in security and usability
•

Industry acceptance



Users no longer need to handle multitudes of passwords, keys,
certificates or complex tools
Over 600 scientific publications on IBE/Pairings
Dan Boneh awarded 2005 RSA Conference Award for Mathematics
Standardization Efforts


IBE being standardized by IEEE 1363.3
Invited by IETF to form new extension to S/MIME
*** Confidential and Proprietary ***
Identity-Based Encryption
Basic Idea: Public-key Encryption where Identities are Public Keys

IBE Public Key:
alice@corp.com

RSA Public Key:
Public exponent=0x10001
Modulus=13506641086599522334960321627880596993888147
560566702752448514385152651060485953383394028715
057190944179820728216447155137368041970396419174
304649658927425623934102086438320211037295872576
235850964311056407350150818751067659462920556368
552947521350085287941637732853390610975054433499
9811150056977236890927563
*** Confidential and Proprietary ***
IBE does not need certificates

Certificates bind Public Keys to Identities



e.g. bob@b.com has key 0x87F6…
Signed by a Certification Authority
In IBE, Identity and Public Key is the same




No certificate needed
No certificate revocation
No certificate servers
No pre-enrollment
*** Confidential and Proprietary ***
How IBE Works in Practice:
Alice Sends a File to Bob
master
secret
public
params
Key
Server
bob@corp.com
bob@corp.com
alice@corp.com
public
params
*** Confidential and Proprietary ***
How IBE Works in Practice:
Alice Sends a File to Bob
master
secret
public
params
Key
Server
Fully off-line - no connection to server required
bob@corp.com
bob@corp.com
alice@corp.com
public
params
*** Confidential and Proprietary ***
Private Key Generation
Master Secret
s =1872361923616378
Key Server
Request Private Key
bob@corp.com


Master Secret is used to generate keys
Each organization has a different secret


Thus different security domains
Server does not need to keep state

No storage associated with server
 Easy load balancing, disaster recovery,
high availability
*** Confidential and Proprietary ***
Authentication

IBE can support any method of authentication


Authentication is not tied to message


Clean separation between encryption and authentication
Can be changed over time
External auth integration


Leverage existing passwords,
directories, portals, etc.
Out of the box support for
ad-hoc, self-provisioning auth
*** Confidential and Proprietary ***
Key
Server
Auth
Service
Extending IBE: Groups and Policies

IBE is not restricted to using identities as keys

Encrypt to a group: “hr@corp.com”

To retrieve the key, the user/application must authenticate as a member
of the HR group
 Leverage existing directory structures (AD, LDAP)
 As group membership in directory changes, key access rights change
dynamically as well

Encrypt to a policy name/classification: “PCI@corp.com”

To retrieve the key, the user/application must meet the policy defined at
the server
 Example: Asking for “PCI” key might query back-end ERP system and
execute business logic

Effectively impossible to do with PKI

Group certificates create major revocation and distribution problems
*** Confidential and Proprietary ***
Policy & IBE
master
secret
Is Bob allowed
to access PCI
data?
AAA
System
public
params
Key
Server
“PCI”
“corp.com”
Portal
bob@yahoo.com
alice@corp.com
public
params
*** Confidential and Proprietary ***
Policy-Based Encryption:

Define canonical privacy policies


Define elements of policy on server


e.g. “HIPAA” requires delegated access, auditing, etc.
Encrypting agents specify privacy policy as part of key


e.g. “HIPAA”, “PCI”, “Confidential”, “Classified”, …
Do not need to understand individual policy elements
Privacy policy enforced by server

Policy can be modified over time
key = “bob@b.com || HIPAA”
key = “HIPAA”
*** Confidential and Proprietary ***
Policy Definition
“HIPAA”
Internal
Auth
via
Directory
External
Auth
via
Strong
Pass
Machine
Must Be
HIPAAApproved
Delegate
Access
for HIPAA
Admins
*** Confidential and Proprietary ***
Log
HIPAA
event
Notify
HIPAA
Officer
Policy Based Key Management
Define HIPAA
enforcement policy on
management server
“HIPAA” =
- US access only
- Auth via SecurID
- Log HIPAA event
Identify & classify:
Determine document
contains HIPAA data
Apply “HIPAA”
privacy policy
*** Confidential and Proprietary ***
Enforce “HIPAA”
privacy policy
Key Management - Public Key Infrastructure
Certificate Server binds Identity to Public Key
Certification
Authority
Certificate
Server
Store
Certificate
CA Signing Key
CA Public Key
Look up
Bob’s Certificate,
Check revocation
Send
Public Key,
Authenticate
Receive
Certificate
Recovery
Server
Store Bob’s
Private Key
CA Public Key
Bob’s Private Key
Bob’s Public Key
alice@a.com
bob@b.com
*** Confidential and Proprietary ***
Key Management - IBE
Binding is done by mathematics
IBE Key Server
Certificate
Server
X
Look up
Bob’s Certificate,
Check revocation
Store
Certificate
Master Secret
Public
Parameters
Send
Identity,
Authenticate
Receive
Private Key
Recovery
Server
X
Store Bob’s
Private Key
Public Parameters
alice@a.com
Bob’s Private Key
bob@b.com
*** Confidential and Proprietary ***
Where do IBE & PKI fit together?

Key management encompasses three areas:

Authentication



Signatures



PKI very applicable in certain scenarios
IBE-based auth architecture makes it easy to leverage certs,
SecurID, etc.
PKI works well for signatures
In fact, IBE architecture effectively uses PKI for signatures
Encryption

Where PKI has never really worked
*** Confidential and Proprietary ***
Key Management Futures

Practically, where is all this going?

IEEE 1619.3
•

Oasis
•

Standardization of key management for storage
TC for key management
IETF
•
Keyprov working group
*** Confidential and Proprietary ***
Key Management Futures


You are going to be exposed to a new category of
product, a central key manager
The underlying crypto mathematics will determine
performance and costs
*** Confidential and Proprietary ***