` Key Management The Connection Between Policy and Encryption Terence Spies CTO Voltage Security.

`

Key ManagementThe Connection Between Policy and Encryption

Terence SpiesCTOVoltage Security

*** Confidential and Proprietary ***

AgendaAgenda

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


Encryption is InevitableEncryption 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


The use of encryption has changedThe use of encryption has changed

Encryption Yesterday

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.

Encryption Today

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


Policy drives this evolutionPolicy drives this evolution

Old Model “Encrypt this data to a

trusted machine” Plaintext on the trusted

machine Defending against untrusted

wires

10s - 100s of keys Machine authentication

New Model “Encrypt this document to a

trusted group” No stored plaintext

anywhere Defending against untrsuted

storage

1000s - 1000000s of keys User, group, role auth


Key ManagementKey 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


Data Encryption is Easy!Data Encryption is Easy!

Well, it’s at least understood….but not really But we can ignore the core crypto for now

Do this 10 times:


Encryption is easy, Key Management is hardEncryption is easy, Key Management is hard

EncryptionKey

DecryptionKey

How do we make sure both sides have the right keys?


What is hard about managing keys?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


New Model Key ManagementNew Model Key Management

SSL/VPN model One certificate per domain Costly enrollment process (~$150/cert) 10-100 keys

Policy based encryption model One key per user or group Can’t pay $150/directory entry! 1000-1MM keys

Makes a difficult problem a nearly impossible one


How is key management done?How is key management done?

Central server Symmetric key, ie. Kerberos

Certificates Public key, ie. Classic “PKI”

Identities Identity-based Encryption


The Basic Key Management OperationsThe 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


The Basic Key Management OperationsThe 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


Symmetric Key ManagementSymmetric 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


Key Management for Symmetric KeysExample: 8 devicesKey Management for Symmetric KeysExample: 8 devices

Key Store

28 keys

4

3

2

5

6

7

11 2 3 4

5 6 7

1 2 3

4 5 6

7 8 ..

.. .. ..

.. .. ..

.. .. ..

.. .. ..

.. .. ..

.. .. ..

..

8

8

How many keys totalfor 8 people?

KeyServer


Certificate Based Key ManagementCertificate 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


Certificate Based Key ManagementCertificate 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• (this signed object is a certificate)

Originator: Get verification key from authority

Get Encryption Key Originator: Get certificate (somehow…..), verify signature, extract

key

Get Decryption Key Receiver: Decrypt


Seems simple….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?


Identity-Based Encryption (IBE) – Breakthrough in CryptographyIdentity-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

• Users no longer need to handle multitudes of passwords, keys, certificates or complex tools

Industry acceptance 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


Identity-Based EncryptionIdentity-Based Encryption

Basic Idea: Public-key Encryption where Identities are Public Keys

IBE Public Key:

[email protected] RSA Public Key:

Public exponent=0x10001Modulus=135066410865995223349603216278805969938881475605667027524485143851526510604859533833940287150571909441798207282164471551373680419703964191743046496589274256239341020864383202110372958725762358509643110564073501508187510676594629205563685529475213500852879416377328533906109750544334999811150056977236890927563


IBE does not need certificatesIBE does not need certificates

Certificates bind Public Keys to Identities e.g. [email protected] 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 X


How IBE Works in Practice:Alice Sends a File to BobHow IBE Works in Practice:Alice Sends a File to Bob

KeyServer

master secret

publicparams

[email protected]@corp.compublic

params

[email protected]

key request +

authenticate


How IBE Works in Practice:Alice Sends a File to BobHow IBE Works in Practice:Alice Sends a File to Bob

KeyServer

master secret

publicparams


params

[email protected]

Fully off-line - no connection to server requiredFully off-line - no connection to server required


Private Key GenerationPrivate Key Generation

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

Key Server

Master Secrets =

Request Private Key

18723619236163781872361923616378

[email protected]@corp.com


IBE can support any method of authentication Clean separation between encryption and authentication

Authentication is not tied to message 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

AuthenticationAuthentication

KeyServer

AuthService


Extending IBE: Groups and PoliciesExtending IBE: Groups and Policies

IBE is not restricted to using identities as keys

Encrypt to a group: “[email protected]” 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: “[email protected]” 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


Policy & IBEPolicy & IBE

KeyServer

master secret

publicparams


params

key request +

authenticate

Portal

“PCI”

“corp.com”

AAASystem

Is Bob allowed to access PCI

data?


Policy-Based Encryption:Policy-Based Encryption:

Define canonical privacy policies e.g. “HIPAA”, “PCI”, “Confidential”, “Classified”, …

Define elements of policy on server e.g. “HIPAA” requires delegated access, auditing, etc.

Encrypting agents specify privacy policy as part of key Do not need to understand individual policy elements

Privacy policy enforced by server Policy can be modified over time

key = “[email protected] || HIPAA”key = “HIPAA”


Policy DefinitionPolicy Definition

“HIPAA”

NotifyHIPAAOfficer

MachineMust Be HIPAA-

Approved

DelegateAccess

for HIPAA Admins

External Auth

via Strong Pass

Internal Authvia

Directory

Log HIPAA event


Policy Based Key ManagementPolicy Based Key Management

“HIPAA” = - US access only- Auth via SecurID- Log HIPAA event

Define HIPAA enforcement policy on management server

Identify & classify: Determine document contains HIPAA data

Apply “HIPAA” privacy policy

Enforce “HIPAA” privacy policy


Key Management - Public Key InfrastructureCertificate Server binds Identity to Public KeyKey Management - Public Key InfrastructureCertificate Server binds Identity to Public Key

[email protected]@a.com

Send Public Key,

Authenticate

ReceiveCertificate

CA Signing Key

CertificationAuthority

CA Public Key

Certificate Server

StoreCertificate

Look up Bob’s Certificate,Check revocation

CA Public Key Bob’s Private KeyBob’s Public Key

RecoveryServer

Store Bob’s Private Key


Key Management - IBEBinding is done by mathematicsKey Management - IBEBinding is done by mathematics

[email protected]

IBE Key Server

[email protected]

Master Secret

SendIdentity,

Authenticate

ReceivePrivate Key

Public Parameters

Public Parameters Bob’s Private Key

Certificate Server

StoreCertificate

Look up Bob’s Certificate,Check revocation

X RecoveryServer

Store Bob’s Private KeyX


Where do IBE & PKI fit together?Where do IBE & PKI fit together?

Key management encompasses three areas:

Authentication PKI very applicable in certain scenarios IBE-based auth architecture makes it easy to leverage certs,

SecurID, etc. Signatures

PKI works well for signatures In fact, IBE architecture effectively uses PKI for signatures

Encryption Where PKI has never really worked


Key Management FuturesKey Management Futures

Practically, where is all this going? IEEE 1619.3

• Standardization of key management for storage Oasis

• TC for key management IETF

• Keyprov working group


Key Management FuturesKey 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

` Key Management The Connection Between Policy and Encryption Terence Spies CTO Voltage Security.

Documents

encryption key receiver

encryption key originator

encryption key authority

key pair

rec key

verification key

extract key

originators key