Distributed Key Management and Cryptographic Agility Tolga Acar - - PowerPoint PPT Presentation

▶
distributed key management and cryptographic agility
SMART_READER_LITE
LIVE PREVIEW

Distributed Key Management and Cryptographic Agility Tolga Acar - - PowerPoint PPT Presentation

Apr 26, 2023 125 likes •355 views

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

slide-1
SLIDE 1

Tolga Acar

24 Feb. 2011

1

Distributed Key Management and Cryptographic Agility

slide-2
SLIDE 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

2

slide-3
SLIDE 3

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?

slide-4
SLIDE 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
  • perations on at least one replica.
  • Inactive. An initialized key is available for some

cryptographic operations on all replicas (e.g., decrypt,

  • nly).
  • Termination. An initialized key is permanently deleted from

all replicas.

4

slide-5
SLIDE 5

Key State Transitions

5 Initialization Full Distribution Active Inactive Termination Creation

Cryptographic

  • perations

Create and initialize a key

slide-6
SLIDE 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)

6

slide-7
SLIDE 7

DKM Architecture

Untrusted Storage (DKM-protected data) DKM Repository

ACL DKM Group A

Protect Unprotect API S e c u r e c

  • n

n e c t i

  • n

DKM Container

Group B ACL

Client 1 Client 2 Client 3 Protect Unprotect API Protect Unprotect API DKM Group Container KA KB KB KA KA

7

slide-8
SLIDE 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

8

slide-9
SLIDE 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

9

slide-10
SLIDE 10

Walkthrough: DKM in Hosted E-Mail

Hosted E-Mail

Tenant 2 Tenant 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

10

slide-11
SLIDE 11

DKM in Hosted E-Mail

Hosted E-Mail

Tenant 2 Tenant 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

  • f the user

1 2 3

11

slide-12
SLIDE 12

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

slide-13
SLIDE 13

DKM-TPM Key Hierarchy

Keys Storage: External Processing: Memory Protection: TPM Keys Storage: External Processing: TPM Protection: TPM Keys Storage: TPM Processing: TPM Protection: 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

slide-14
SLIDE 14

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
slide-15
SLIDE 15

DKM-TPM Roles

Master

Master PK List Store PK List Node PK List Configuration

Store

DKM Keys Policies Master PK List Store PK List Node PK List Configuration

Node

Master PK List Store PK List Node PK List Configuration

CommServer CommClient CommClient CommClient TPM KM & Crypto Repository TPM KM & Crypto Repository TPM KM & Crypto Repository Node Logic & API Store Logic & API Master Logic & API

slide-16
SLIDE 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

16

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

Random Oracle x y

slide-17
SLIDE 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

17

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

Left-Right Oracle m0, m1 C Guess b?

IND-CPA Game

slide-18
SLIDE 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

18

slide-19
SLIDE 19

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

slide-20
SLIDE 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.

20

F1 F2

K

slide-21
SLIDE 21

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?
slide-22
SLIDE 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>

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)