2
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
3
Distributed Key Management
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?
4
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.
5
Key State Transitions
Initialization
FullDistribution
Active Inactive TerminationCreation
Cryptographic operationsCreate and
initialize a key
6
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)
7
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
8
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
9
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
10
Walkthrough: DKM in Hosted E-MailHosted E-Mail
Tenant 2Tenant 1
Mailbox Stores
User Settings
User’s Mailbox
User’s DKM encrypted ISP
password
DKM Keys
User’s Mailbox
User’s DKM encrypted ISP
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
11
DKM in Hosted E-MailHosted E-Mail
Tenant 2Tenant 1
Mailbox Stores
User Settings
User’s Mailbox
User’s DKM encrypted ISP
password
DKM Keys
User’s Mailbox
User’s DKM encrypted ISP
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
DKM-TPM MotivationSecret Protection Technology:
• Approach sits between a pure HSM solution and a full software solution.
Expensive Moderate InexpensiveCost:
Very Secure More Secure Moderate (OS-Dependent)Security:
Hard Easier EasyDeployment:
HSMHardware Security Module
TPM-based
CryptoSoftware 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 ListStore PK ListNode PK ListConfiguration
Store
DKM KeysPolicies
Master PK ListStore PK ListNode PK ListConfiguration
Node
Master PK ListStore PK ListNode PK ListConfiguration
CommServerCommClient CommClientCommClient
TPM
KM & CryptoRepository
TPM
KM & CryptoRepository
TPM
KM & CryptoRepository
Node Logic & API Store Logic & API Master Logic & API
16
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
y {0, 1}*If (x in A) y Fetch(A,x)Else Store(x,y) in A
Return y
Random Oraclex
y
17
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⊂
b {0, 1}C = Enc(K, mb)Return C
Left-Right Oraclem0, m1
C
Guess b?
IND-CPA Game
18
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⊂ ⊂
19
IND-CCA/CCA2 Game
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
20
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.
F1 F2
K
21
Pseudo Random Function AgilityFacts• 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.
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?
22
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>
⊥ (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)