Distributed Key Management and Cryptographic Agility
Tolga Acar 24 Feb. 2011
1 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
Encrypt M1 Decrypt C1
C1=E(K,M1) C2=E(K’,M2) M1=D(K,C1)
Read ciphertext
Node 1 Node 2 Node N
Save ciphertext C1 Replication Protocol
Storage Storage (Replica) (Replica) Where is the correct key? How is it protected?
3 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
Initialization
Creation Active Inactive Termination
Full Distribution
Cryptographic Create and operations initialize a key
5 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
API
Protect Secure connection Unprotect DKM Container Client 1 KA
DKM Group API Container DKM Protect Unprotect KB Client 2 KA DKM Repository Group A ACL
API
Protect Unprotect Group B KB ACL Client 3 KA
Untrusted Storage (DKM-protected data)
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
Tenant Admin can Hosted E-Mail User’s ISP Tenant “1” administer Exchange Tenant 1 Tenant 2
Active Directory
Admin 1 User Settings User Settings DKM Keys Tenant Admin can NOT access DKM keys User 1 Mailbox Stores User’s Mailbox User’s Mailbox
User’s DKM User’s DKM Internet encrypted ISP encrypted ISP Tenant “2” password password
Admin 2 ISP Mail Server E-Mail Servers
(Hotmail, Yahoo, Gmail, etc) User 2 DKM
10 DKM in Hosted E-Mail
Hosted E-Mail User’s ISP Tenant “1” Tenant 1 Tenant 2
Active Directory
Admin 1 User Settings User Settings DKM Keys
User 1 Mailbox Stores User’s Mailbox User’s Mailbox
Internet User’s DKM User’s DKM encrypted ISP encrypted ISP Tenant “2” password password
Admin 2 ISP Mail Server 2 1 E-Mail Servers
E-Mail Servers can retrieve (Hotmail, Yahoo, mail from the ISP on behalf Gmail, etc) 3 User 2 of the user DKM
11 DKM-TPM Motivation
Secret Protection Technology:
HSM TPM-based Software Crypto
Hardware Security Module Crypto No Hardware
Cost: Expensive Moderate Inexpensive
Security: Very Secure More Secure Moderate (OS-Dependent)
Deployment: Hard Easier Easy
• Approach sits between a pure HSM solution and a full software solution.
DKM-TPM Key Hierarchy
Keys Storage: TPM EK SRK Processing: TPM (Endorsement Key) (Storage Root Key) Protection: TPM
AIK (Attestation Identity Key) Keys Storage: External Processing: TPM Protection: TPM TLSK SK WK (TLS Key) (Signing Key) (Wrapping Key)
Keys Storage: External DKMK Seal Processing: Memory (DKM Key)* Protection: TPM
* There are one or more DKM Keys. 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
Node Store Master
Node Logic & API Store Logic & API Master Logic & API
CommClient CommClient CommServer CommClient
Repository KM & Crypto Repository KM & Crypto Repository KM & Crypto
TPM TPM TPM
Master PK List Master PK List Master PK List Store PK List Store PK List Store PK List Node PK List DKM Keys Node PK List Node PK List Configuration Policies Configuration Configuration
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
Random Oracle x y {0, 1}* If (x in A) y Fetch(A,x) y Else Store(x,y) in A
Return y
16 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
Left-Right Oracle m0, m1 b {0, 1}
C C = Enc(K, mb) Return C
Guess b?
IND-CPA Game
17 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
Free Oracle Access Encrypt Queries {m,C} C = Enc(K, m)
Responses {C,m} Decrypt m = Dec(K, C)
Challenge m0, m1 Left-Right Oracle b {0, 1} C C = Enc(K, mb)
Adaptive (CCA2) Adversary C Decrypt m m = Dec(K, C) Guess b?
19 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. K
F1 F2
20 Pseudo Random Function Agility
Facts • PRF: F is a PRF if no efficient adversary can distinguish F(K,.) from a random function. • F (K ,x) and F (K ,x) are not distinguishable from a pair of random functions. 1 1 2 2 • 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.
F1 F2 • Question: Are PRFs agile?
– Yes, if every {F1,F2} is agile. • Answer: No.
– Example: F2(K,x) = NOT (F1(K,x)) x F1(K,x) x F2(K,x) • Now, what?
21 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
– Kae = PRF(K,
– Kae = PRF(K,
– M = D(Kae, C)
⊥ (x,F1(K,x)) ⊥ (x,F1(K,x))
22