Cryptography and Key Mangement

Cryptography and KeyManagement

T. Pedersen, Cryptomathic

Agenda

Basic cryptography Need for key management

Cryptographic Modules Security requirements Types of modules

Key management systems Example using symmetric keys Public key infrastructure

CA Key server Time-Stamping

Basic Cryptography

Symmetric Cryptography

A B

XxxXxx x xxx xXxx xxx x

Xx xxx

%3#Pz5 !"#&%!!Fcgew)#ffeOO

Encryption

Key

XxxXxx x xxx xXxx xxx x

Xx xxx

Decryption

Block ciphers Stream ciphers

Block ciphers Today

DES Data Encryption Standard 56 bits key / 64 bits block

3DES Triple-DES 112/168 bits has two or three keys 64 bits blocks

AES Advanced Encryption Standard E.g., 128 bits key and 128 bits block Also larger key sizes (192/256)

Mode of use

Example CBC Encrypto m = m1m2m3 .... mn

c0 = IV ci = EK(mi ci-1)

Decrypt c0c1c2 .... cn mi = DK(ci) ci-1

m1 EK c1

m2 EK c2

mn EK cn

IV

Can also be used to construct MAC

Symmetric Encryption Summary

Developed over hundreds of years High performance Solid standards Accounts for 99,? % of all data

encryption

Can be used for message authentication

But.

Key Distribution Center

Network with n nodes requires O(n2) secretkeys Secure storage of many keys Distribution of keys

Replace keys by trusted KDC Each node shares key with KDC Requires O(n) keys

KA

KB KC

Key Distribution Center

A wants to send m privately to B1. A requests key from KDC2. KDC generates KAB and sends EKA(KAB) and EKB(KAB) to A3. A sends (c1, c2) = (EKB(KAB), EKAB(A, B, m)) to B4. B decrypts

c1 using KB to recover KAB c2 using KAB to recover m

Many variants If A wants to send m to B and C Format of messages Protocol where B is on-line with KDC

Problem: Only A and B may know KAB

Asymmetric Cryptography

Aka. Public Key Cryptography No common secret key, but:

One private secret key One public key Bound together by a difficult mathematical problem Difficult to compute private key from public

Asymmetric Encryption/Decryption

A B

DecryptionXxxXxx x xxx xXxx xxx x

Xx xxx

XxxXxx x xxx xXxx xxx x

Xx xxx

%3#Pz5 !"#&%!!Fcgew)#ffeOO

Encryption

Bs Public Key Bs Private Key

Cryptographic Hash Functions

Short fingerprint of long message SHA-1 (160 bit) MD5 (128 bit) recently more broken

Cryptographic requirements: One way function: with a given hash value it is

practically impossible to find the message with this hash value

Collision-free: Impossible to find two different messages with the same hash value.

Digital Signature Generation

M = 1011010011followed by S(h(M))1

4

h

h(M) = 10010110..1 (fixed length, e.g. 128 bits)

SS32

Digital Signature - Validation

M = 1011010011followed by S(h(M)(?)1

3

hPP

2 4

h(M) = 10010110..1 ? = Output

Asymmetric Cryptography Today

RSA Rivest Shamir Adleman 768-4096 bit

DSA Digital Signature Algorithm

Diffie-Hellman ECC

Elliptic Curves Cryptography

Asym. Cryptography Summary

Invented in mid 1970s Low performance because of huge

keys

Primarily used for Key exchange for symmetric encryption Digital signatures

Public Key Infrastructure

So, we all need to know Alices public key

Public key distribution Authenticated distribution of keys

if Alices key is valid if Alices key has expired if Alices has been revoked to what extent she can legally committed ..... .....

The key: Certificates

A party, we all trust - A Trusted Third Party - issues Certificates: Contains the Id of Alice, and her public key Validity period Issued under a certificate policy

Digitally signed by the TTP, called a Certification Authority (CA) CA follows rules in CPS Replaces KDC in the symmetric world

Certificate Formats

X.509v1 asn.1 syntax

X.509v2 almost useless

X.509v3 extensions for various purposes

Others EMV EDIFACT

Hierarchical structure: ROOT CA

Root Who guardsthe guards?

CA1 CA2

Establish public keyof root CA - securely

Self-signed certificateCA3

Key Management Players

An LRA (Local Registration Authority) identifies and registers end-users, service providers and other independent TTPs securely connected to a CA

A CA issues certificates A Directory Authority makes a list of all certificates and

their status available Blacklists (Revocation lists) must be distributed

this is the weak link!

The World seen with the eyes of the user

User

CA

DIR

User

LRA

Business Transactions

Support services

Registration Certification Key generation Directory services Certificate Status Time Stamping Filing

Many of theserequire

digital signatures

Independent Time Stamping

Necessary for non-repudiation Prove that signature was made when key was valid

Time stamp on signature Third party signs hash value - does not

have to see entire message

Cryptographic Modules

Cryptographic Modules

Security depends on keys Key management

generation storage distribution use deletion/destruction

Cryptographic modules software module (e.g., CSP) smart cards tokens hardware security modules (HSM)

Annex III: Directive 1999/93/CE

Secure signature-creation devices must ensure: uniqueness and secrecy of the key used for

signature generation; unpredictability and integrity of the key; keys used for signature generation can be reliably

protected by the legitimate signatory against the use of others.

must not alter the data to be signed or prevent such data from being presented to the signatory prior to the signature process.

Protection by hardware

Hardware ModulesWhat is an HSM

Keys outsidethe module

HSM

Master Key (MK)

Keys In clearK1, K2 etc.

Cryptofunctionality

EMK(K1),EMK(K2)

etc.

Protection of key material

Hardware Modules

Most HSMs protect keys under a Master Key.

When a module is initialised a Master Key is created using smart cards, components etcdepending on the module.

The Master Key is usually a 3DES key which is always stored in side the module (also stored onsmart cards or as components for recoveryreasons).

Keys or sensitive data stored outside the moduleis protected by the Master Key.

Hardware Modules

Security classification Common Criteria (or ITSEC) FIPS 140-2

Defines security metric for cryptographic modules 4 levels are defined

Security level defined in terms of 11 requirements

Key ManagementEMI/EMCSelf testsDesign AssuranceMitigation of other attacks

Module specificationModule interfaceRoles and AuthenticationFinite state modelPhysical securityOS Security

Hardware Modules

Module interface Secure API Level 3 and 4 requires separate ports for data and keys

Physical security Depends on model (standalone, embedded) Level 2: tamper-evident mechanisms Level 3: tamper detection/response for removable covers Level 4:

tamper detection/response for complete module environmental failure protection/testing

temperature: -100 to 200 Celsius Voltage flutuations

NIST: useful in unprotected environments

Tamper-response Zeroization of keys

Hardware Modules

Key Management Key generation (RNG/PRNG) Key exchange Key entry/output

Level 1&2: encrypted keys for electronically distr. keys Level 3&4:

Manual distribution: components (trusted path or directly) Secret sharing techniques

Key storage/destruction

Self-tests Known-answer Sign/verify or Encrypt/decrypt Statistical tests Level 3: called on demand Level 4: power-up

Hardware Modules

Mitigation of other attacks Power analysis Timing analysis Fault induction TEMPEST

analysis based on detection of electronic magnetic signals

Hardware Modules

Examples Smart cards

Datakey300 (FIPS 140-2, level 2) RSA, DSA, DH DES & 3DES SHA-1

HSMs IBM4758 Eracom ProtectServer Orange (PSO) nCipher

IBM 4758

From outside

Version 1: FIPS 140-1 Level 3 or 4 (DES data keys only)

Version 2: FIPS 140-1 Level 3 or 4 (3DES data keys and faster than Version 1)

IBM 4758

... and inside

IBM 4758

Master Key (MK) The Master key can be created using components

(enables recovery) Randomly generated (recovery only possible by cloning

the module)

Roles and Profiles on IBM4758: Each command in the IBM4758 has its own privilege A Role can have any number of privileges assigned A Profile (a user profile) has a Role assigned In order for a user to use the module the user has to log

on the the module using his profile and password Roles and Profiles can have an expiry date Limit the use of the module to specific points in time

IBM 4758IBM Common Cryptographic Architecture (CCA) API:

DES, and triple-DES data confidentiality

DES message authentication and RSA digital signatures

SHA-1, MD5, RIPEMD160, and MDC-2 and MDC-4 hashing

DES and RSA (up to 2048) key management

SET Secure Electronic Transaction services

Finance industry specific operations

Custom extensions using the UDX toolkit

Supported on

PCs with OS/2, Windows 2000 and Windows NT

IBM pSeries (RS/6000) systems with AIX

IBM 4758CCA Performance data (ibm4758 API used):

Test parameters (1024 bit Chinese Remainder):

Key generation (16 threads, 10 keys in each):

Public exponent 3: 6.40 sec/key (0.16 keys/sec)

Public exponent 3: 3.83 sec/key (0.26 keys/sec)

Signature generation (16 threads, 1000 signatures in each)

129 sig/sec

nShield from nCipher

Based on ARM-processors (2-8 depending on the module)

ACL on Keys:

The key can be restricted only to be

used for certain commands. used if another key is present, operator smart cards has beenloaded

exported under certain keys eg. only the security world key (theMaster Key MK).

nShield from nCipher

nShield from nCipherPerformance data on nShield with speed index 392:

Key generation (16 threads, 10 keys in each):

Public exponent 3: 1.97 RSA keys/sec

Signature generation (16 threads, 1000 signatures in each)

356 sig/sec

Faster than IBM also more expensive

Eracom - Protect Server Orange

Eracom PSO features

FIPS 140-1 Level 3 API: PKCS#1, Java JCA/JCE and

Microsoft Crypto API

Proprietary (non standard PKCS#11) mechanism for offloading of keys

Possibility to add and modifyfunctionality (FM functionalitymodule)

Eracom PSO features

Tamper-detection mechanisms for stored keys and sensitive data

Secure, battery backed memory for key storage On board Real Time Clock Hardware based true random number generator Smart card based authentication and secure key

export/ import Direct connection of smart card reader and PIN

pad to cryptographic hardware

Available libraries

IBM4758 nShield

CCAPKCS11 PKCS11Generic Stub

IBM modules

nCipher modules

Cryptomathic SW modules

Eracom

MHSM

PKCS11

Eracom modules

UDX on IBM 4758

Extension to the CCA API A CCA function is actually an UDX function

delveloped by IBM

UDX functions have access to the same functionallity as the CCA functions

UDX functions are developed directly on top of theCP/Q++ embedded operating system

A RSA key pair with the public key signed by IBM is necessary to develop UDX functionality.

SEE on nShield

Secure Execution Environment enabled in the nShield module. :

Additional SEE functionality (Written in ANSI-C).

SEE code can access the same functionality as outside the module.

The code is signed with SEE signing key (unique for secure world)

The code can be encrypted using SEE encryption key

The ACL on keys extended to allow certificate of the SEE signing ke Can only be used by code signed with SEE signing key.

NVRAM (nonvolatile memory) available for the SEE code. Allocated memory handled as keys (the has an ACL). Can be used to eg. store counters in a secure way.

The SEE signing and encryption key is protected by theAdministrator Smart Card Set protecting the secure world

FM on Eracom PSO

A functional module (FM) allows you to add and/ormodify the functionality of the PSO

Code can run inside the module and access thesame functionality as outside the module(PKCS#11 API).

FM code must be signed (by a RSA key) and thecertificate must have a trusted state in the HSM (controlled by HSM administrator).

FM code is written in ANSI-C.

Key Managements Systems

Central key mgmt. for many appl. Key mgmt. for specific application Use KDC as example

Generate sessions keys Export session keys Requirements:

High load if many users Small response time Sessions keys not known by

KDC operators

KA

KB KC

Architecture - Example

Server

CM

CM

DB

Load bal.

Server

CM

CM

Front

Adm.client

Architecture - Coming

Server

Load bal.

Server

Adm.client

Front

Network attached HSM

DB

Funtionality

A wants to send m privately to B1. A requests key from KDC2. KDC generates KAB and sends EKA(KAB) and EKB(KAB) to A3. A sends (c1, c2) = (EKB(KAB), EKAB(A, B, m)) to B4. B decrypts

c1 using KB to recover KAB c2 using KAB to recover m

Possible implementation of KDC1. Use SW cryptographic module2. Use HSM

Operations for generating keys, encrypting under key3. Use programmable HSM

KDS with SW Module

Client keys stored encrypted in DB Under master key (RAM) How is master key stored

File storage imples copy and off-line attack How is master key activated during start up

Master key generated and exported duringinitialisation Back up / clustering

Access to server gives Access to master key Access to client keys and sessions keys

Administrators will still have access Dual control

Server in locked room

KDS with HSM Using standard API

Allows key generation (generate KAB) Encryption operations

Given KA (encrypted) encrypt KAB under KA Session key KAB in RAM!

Client keys stored encrypted in DB Under master key Master key stored in HSM

Access requires authentication

Master key generated and exported duringinitialisation Back up /clustering Access to server gives access to DB and HSM

Secu

rity

ofm

aste

r

key

depe

nds

on

proc

edur

es

KDC with Programmable HSM Make special HSM function

gets KA and KB from DB (encrypted) outputs EKA(KAB) and EKB(KAB)

KAB does not occur in clear outside HSM Client keys stored encrypted in DB

Under master key (RAM) Master key stored in HSM

Access requires authentication

Master key exported during initialisation Back up /clustering

Access to server gives access to DB and HSM Procedure for loading SW in HSM

Security Policy

Options Choice of cryptographic module Use of locked room

Server, DB and HSM in locked room Preferred that daily operations can be done outside locked room

Convenience Operator does not have to be physically close to server

SW + locked room is weaker than programmable HSM

Who has access to server Which access is required for

Daily operations Special circumstances

Which operations are possible Changing code on the server Executing code on the server

Access to HSM and DB Loading SW in HSM, changing/managing DB

Security Policy

Protection of HSM Authentication necessary for using HSM Automatically restart of server often required, but

Where is the authentication information How is master key managed

Who has access Does key components occur in server

Normally keys are off-loaded in DB If many keys Clustering

Protection of DB Change of DB may compromise system with programmable

HSM Daily operations (roll back /recovery) Malicious changes

Example - CA

Consider a CA issuing certificate given Information in DB (previous registration) Certificate request from end user

Requirements CA signing key must not be compromised

Only authorised certificates must be signed Need for cluster

Performance Reliability/availability

SW cryptographic module is insufficient Only server must access signing key With SW (encrypted) key may be copied

Information in DB must not be modifiedServ

er, H

SM a

nd D

B

in p

rote

cted

room

Example - CA Do we need programmable HSM?

Programmable HSM is not always more secure Certification does not cover HSM code

The procedure CA gets certificate request CA looks up registration in DB CA issues certificate if request and registration are ok and

consistent

CA can sign certificate using HSM withstandard API with key always protected CA key can be used to sign anything!

With programmable HSM the key can berestricted to sign formatted certificates This may be sufficient to compromise the system

Cryptography and KeyManagement

T. Pedersen, Cryptomathic

Cryptography and Key ManagementAgendaBasic CryptographySymmetric CryptographyBlock ciphers TodayMode of useSymmetric Encryption SummaryKey Distribution CenterKey Distribution CenterAsymmetric CryptographyAsymmetric Encryption/DecryptionCryptographic Hash FunctionsDigital Signature GenerationDigital Signature - ValidationAsymmetric Cryptography TodayAsym. Cryptography SummaryPublic Key InfrastructureThe key: CertificatesCertificate FormatsHierarchical structure: ROOT CAKey Management PlayersThe World seen with the eyes of the userSupport servicesIndependent Time StampingCryptographic ModulesCryptographic ModulesAnnex III: Directive 1999/93/CEHardware ModulesHardware ModulesHardware ModulesHardware ModulesHardware ModulesHardware ModulesHardware ModulesIBM 4758IBM 4758nShield from nCipherEracom - Protect Server OrangeEracom PSO featuresEracom PSO featuresAvailable librariesUDX on IBM 4758SEE on nShieldFM on Eracom PSOKey Managements SystemsArchitecture - ExampleArchitecture - ComingFuntionalityKDS with SW ModuleKDS with HSMKDC with Programmable HSMSecurity PolicySecurity PolicyExample - CAExample - CACryptography and Key Management