distributed key management cryptographic...

Tolga Acar 24 Feb. 2011

1

Distributed Key Management and Cryptographic Agility

Overview

• Distributed Key Lifecycle – Problem statement and status quo – Distributed Key Manager – Typical application scenario and architecture

• Hardware Rooted Key Management – How to use TPMs for key management – TPM Key hierarchy

• Diving into Cryptographic Theory – Security Definitions – Cryptographic Agility

2

Distributed Key Management

3

Node 1 Node 2 Node N

Storage(Replica)

C1=E(K,M1) C2=E(K’,M2) M1=D(K,C1)

Storage(Replica)

Save

ciphertext C1

Read

ciphertext

Encrypt M1 Decrypt C1

Replication Protocol

Where is the correct key? How is it protected?

Key Lifecycle Model

• Creation. A key object is created on at least one replica, but its attributes (e.g., key value) are not set.

• Initialization. The key object has all its core key attributes set on at least one replica.

• Full Distribution. An initialized key is available on all replicas.

• Active. An initialized key is available for cryptographic operations on at least one replica.

• Inactive. An initialized key is available for some cryptographic operations on all replicas (e.g., decrypt, only).

• Termination. An initialized key is permanently deleted from all replicas.

4

Key State Transitions

5

Initialization

Full

Distribution

Active Inactive TerminationCreation

Cryptographic operations Create and

initialize a key

DKM Problem Statement

• No cross-user and cross-machine data protection – Windows Data Protection API (DPAPI) is single-user, single-machine. – KeyCzar and PKCS#11 uses local keys; no distribution mechanism.

• Engineering problem – Ad-hoc key management groups (protection siloes) – Scalability & Availability (10Ks of machines) – Geo-redundancy (multiple data centers) – Key lifecycle management (automation)

• Cryptography problem – Protect arbitrary data (broad applicability) – Use existing algorithms (e.g. AES, HMAC-SHA2) – Automatically update group keys (key rollover) – Crypto agile (algorithm and key length changes)

6

DKM Architecture

Untrusted Storage(DKM-protected data)

DKM Repository ACL

DKM

Group A

ProtectUnprotect

API

Secure connection

DKM Container

Group B ACL

Client 1

Client 2

Client 3

ProtectUnprotect

API

ProtectUnprotect

APIDKM Group Container

KA

KB

KB

KA

KA

7

DKM Approach

• Active Directory Approach – Key storage is straightforward

• Store group keys in AD objects

• Protect keys with AD object ACLs

• AD security groups correspond to principals / groups

– Rely on Active Directory replication for high availability

– Network transport is secure (LDAP with Kerberos)

• DKM provides – Auto key update mechanism

– Multiple groups and multiple keys per group

– Cryptographic policy per domain and per group

– Crypto agility

8

Walkthrough: DKM in Hosted E-Mail

• Scenario:

– Hosting mail for multiple tenants in a datacenter

– Product supports message aggregation from other providers for users with multiple email accounts

• User signs in once

• E-Mail Server fetches and aggregates mail

– Tenant Admins must be able to perform Administrative tasks

• But should NOT be able to read user credentials

9

Walkthrough: DKM in Hosted E-Mail Hosted E-Mail

Tenant 2Tenant 1

Mailbox Stores

User Settings

User’s Mailbox

User’s DKM encrypted ISP

password

DKM Keys

User’s Mailbox


password

User’s ISP

Internet

E-Mail Servers

DKM

ISP Mail Server

(Hotmail, Yahoo, Gmail, etc)

Tenant “2”

Admin 2

User 2

Tenant “1”

User 1

Admin 1 User Settings

Active Directory

Tenant Admin can

administer Exchange

Tenant Admin can NOT

access DKM keys

10

DKM in Hosted E-Mail Hosted E-Mail

Tenant 2Tenant 1

Mailbox Stores

User Settings

User’s Mailbox


password

DKM Keys

User’s Mailbox


password

User’s ISP

Internet

E-Mail Servers

DKM

ISP Mail Server

(Hotmail, Yahoo, Gmail, etc)

Tenant “2”

Admin 2

User 2

Tenant “1”

User 1

Admin 1 User Settings

Active Directory

E-Mail Servers can retrieve

mail from the ISP on behalf

of the user

12

3

11

DKM-TPM Motivation

Secret Protection Technology:

• Approach sits between a pure HSM solution and a full software solution.

Expensive Moderate Inexpensive Cost:

Very Secure More Secure Moderate (OS-Dependent) Security:

Hard Easier Easy Deployment:

HSM Hardware Security Module

TPM-based

Crypto

Software Crypto No Hardware

DKM-TPM Key Hierarchy

KeysStorage: ExternalProcessing: MemoryProtection: TPM

KeysStorage: ExternalProcessing: TPMProtection: TPM

KeysStorage: TPMProcessing: TPMProtection: TPM

EK(Endorsement Key)

SRK(Storage Root Key)

AIK(Attestation Identity Key)

WK(Wrapping Key)

TLSK(TLS Key)

SK(Signing Key)

DKMK(DKM Key)*

* There are one or more DKM Keys.

Seal

DKM-TPM Roles

1. Master (Root of Trust) • Root of Trust for TPM public keys • Role assignment to TPM public keys • Push to Stores

2. Store (Repositories) • DKM repository (keys, policies, and metadata) • DKM Responder • Responds to requests from Masters, Stores, and Nodes

3. Node (Application servers) • Cryptographic operations with DKM keys • Client API • Sends requests to Stores

DKM-TPM Roles

Master

Master PK List Store PK List Node PK List Configuration

Store

DKM Keys Policies


Node


CommServer CommClient CommClient CommClient

TPM

KM & Crypto Repository

TPM


TPM


Node Logic & API Store Logic & API Master Logic & API

Cryptosystem Security Definitions

• Probabilistic Polynomial-Time (PPT) adversaries

– Probabilistic randomized algorithm that gives the correct answer with > ½ probability.

• Random Oracle Model (RO or ROM)

– Black box with a stateful uniform random response

16

y {0, 1}* If (x in A) y Fetch(A,x) Else Store(x,y) in A Return y

Random Oracle

x

y

Attack Game

• Encryption scheme security definitions – IND-R: Indistinguishability from Random – IND-CPA: Indistinguishability under Chosen Plaintext Attack (a.k.a.

semantic security) – IND-CCA: Indistinguishability under Chosen Ciphertext Attack

• IND-CPA ⊂ IND-CCA

17

b {0, 1} C = Enc(K, mb) Return C

Left-Right Oracle m0, m1

C

Guess b?

IND-CPA Game

Ciphertext Attacks

• IND-CCA2: Indistinguishability under adaptive chosen ciphertext attack – Decryption Oracle access (non-trivial)

• Non-adaptive – Query the decryption oracle till the challenge

ciphertext is received

• Adaptive – Continuous queries to the oracle (max q queries)

• IND-CPA ⊂ IND-CCA ⊂ IND-CCA2

18

IND-CCA/CCA2 Game

19

m = Dec(K, C)

Decrypt

m0, m1

C

Queries {m,C}

Responses {C,m}

C = Enc(K, m)

Encrypt

b {0, 1} C = Enc(K, mb)

Left-Right Oracle

C

m

m = Dec(K, C)

Decrypt

Guess b?

Challenge

Adaptive (CCA2) Adversary

Free Oracle Access

Cryptographic Agility • Cryptographic primitives as sets:

– PRF = {F : F is a secure pseudorandom function}

– AE = {F : F is a secure authenticated encryption scheme}

• Assume F1 and F2 have the same key space and length

• Informal Definition: A primitive Π is agile if any F1, F2 ∈ Π can securely use the same key.

20

F1 F2

K

Pseudo Random Function Agility

Facts

• PRF: F is a PRF if no efficient adversary can distinguish F(K,.) from a random function.

• F1(K1,x) and F2(K2,x) are not distinguishable from a pair of random functions.

21

x F1(K,x)

F1 F2

x F2(K,x)

K

• Definition: A set {F1,F2} is agile if F1(K,x) and F2(K,x) are not distinguishable from a pair of random functions.

• Question: Are PRFs agile?

– Yes, if every {F1,F2} is agile.

• Answer: No.

– Example: F2(K,x) = NOT (F1(K,x))

• Now, what?

Agility in Practice • Certain primitives are agile: collision-resistant hash functions

• Strong agility is achievable in practice: Authenticated Encryption – Don’t use the key directly in the encryption algorithm <ae>

– Use a derived subkey in <ae>

22

⊥ (x,F1(K,x))

F1 F2

⊥ (x,F1(K,x))

K • PRF-based security for Authenticated

Encryption: CCM, GCM, etc. – Pick a PRF from a small agile set

• Encryption of M with K, with PRF – Kae = PRF(K,<ae>)

– C = E(Kae, M)

• Decryption – Kae = PRF(K,<ae>)

– M = D(Kae, C)

distributed key management cryptographic...

Documents