Key management the connection between policy and encryption
This presentation is the property of its rightful owner.
Sponsored Links
1 / 35

Key Management The Connection Between Policy and Encryption PowerPoint PPT Presentation


  • 54 Views
  • Uploaded on
  • Presentation posted in: General

`. Key Management The Connection Between Policy and Encryption. Terence Spies CTO Voltage Security. Agenda. Encryption as a security mechanism The emergence of key management Key management technologies

Download Presentation

Key Management The Connection Between Policy and Encryption

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


`

Key ManagementThe Connection Between Policy and Encryption

Terence Spies

CTO

Voltage Security


Agenda

  • 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

*** Confidential and Proprietary ***


Encryption 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

*** Confidential and Proprietary ***


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

The use of encryption has changed

*** Confidential and Proprietary ***


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

Policy drives this evolution

*** Confidential and Proprietary ***


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

Key Management

*** Confidential and Proprietary ***


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:

*** Confidential and Proprietary ***


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

Encryption is easy, Key Management is hard

Encryption

Key

Decryption

Key

*** Confidential and Proprietary ***


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

*** Confidential and Proprietary ***


New 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

*** Confidential and Proprietary ***


How is key management done?

  • Central server

    • Symmetric key, ie. Kerberos

  • Certificates

    • Public key, ie. Classic “PKI”

  • Identities

    • Identity-based Encryption

*** Confidential and Proprietary ***


The 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

*** Confidential and Proprietary ***


The 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

*** Confidential and Proprietary ***


Symmetric 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

*** Confidential and Proprietary ***


7

8

8

3

2

5

6

7

3

1

2

3

4

5

6

7

1

1

2

5

4

6

8

..

..

..

4

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

..

Key Management for Symmetric KeysExample: 8 devices

Key

Server

Key Store

How many keys totalfor 8 people?

28 keys

*** Confidential and Proprietary ***


Certificate 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

*** Confidential and Proprietary ***


Certificate 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

*** Confidential and Proprietary ***


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?

*** Confidential and Proprietary ***


Identity-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

*** Confidential and Proprietary ***


Identity-Based Encryption

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

  • IBE Public Key:

    [email protected]

  • RSA Public Key:

    Public exponent=0x10001

    Modulus=135066410865995223349603216278805969938881475605667027524485143851526510604859533833940287150571909441798207282164471551373680419703964191743046496589274256239341020864383202110372958725762358509643110564073501508187510676594629205563685529475213500852879416377328533906109750544334999811150056977236890927563

*** Confidential and Proprietary ***


IBE 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

*** Confidential and Proprietary ***


publicparams

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

master secret

KeyServer

key request +

authenticate

[email protected]

[email protected]

[email protected]

publicparams

*** Confidential and Proprietary ***


publicparams

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

master secret

KeyServer

Fully off-line - no connection to server required

[email protected]

[email protected]

[email protected]

publicparams

*** Confidential and Proprietary ***


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

Private Key Generation

Master Secret

s =

1872361923616378

1872361923616378

Key Server

Request Private Key

[email protected]

[email protected]

*** Confidential and Proprietary ***


Authentication

  • 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

Auth

Service

Key

Server

*** Confidential and Proprietary ***


Extending 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

*** Confidential and Proprietary ***


publicparams

Policy & IBE

master secret

Is Bob allowed to access PCI data?

AAA

System

KeyServer

key request +

authenticate

“PCI”

“corp.com”

Portal

[email protected]

[email protected]

publicparams

*** Confidential and Proprietary ***


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”

*** Confidential and Proprietary ***


Policy Definition

“HIPAA”

Internal Authvia Directory

External Authvia Strong Pass

Machine

Must Be HIPAA-Approved

DelegateAccess for HIPAA Admins

Log HIPAA event

Notify

HIPAA

Officer

*** Confidential and Proprietary ***


Policy 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

*** Confidential and Proprietary ***


Certification

Authority

Certificate Server

StoreCertificate

CA Signing Key

CA Public Key

RecoveryServer

Send Public Key,

Authenticate

ReceiveCertificate

Look up Bob’s Certificate,

Check revocation

Store Bob’s Private Key

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

CA Public Key

Bob’s Private Key

Bob’s Public Key

[email protected]

[email protected]

*** Confidential and Proprietary ***


X

Certificate Server

StoreCertificate

X

RecoveryServer

Look up Bob’s Certificate,

Check revocation

Store Bob’s Private Key

Key Management - IBEBinding is done by mathematics

IBE Key Server

Master Secret

Public Parameters

SendIdentity,

Authenticate

ReceivePrivate Key

Public Parameters

Bob’s Private Key

[email protected]

[email protected]

*** Confidential and Proprietary ***


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

*** Confidential and Proprietary ***


Key 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

*** Confidential and Proprietary ***


Key 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

*** Confidential and Proprietary ***


  • Login