Cryptography and Key

Management
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
Xxx
Xxx x xxx x
Xxx xxx x
Xx xxx
%3#
Pz5 !"#&
%!!Fcgew
)#ffeOO
Encryption
Key
Xxx
Xxx x xxx x
Xxx 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 = m
1
m
2
m
3
.... m
n
c
0
= IV
c
i
= E
K
(m
i
c
i-1
)
Decrypt c
0
c
1
c
2
.... c
n
m
i
= D
K
(c
i
) c
i-1
m
1
E
K
c
1

m
2
E
K
c
2

m
n
E
K
c
n

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(n
2
) secret
keys
Secure storage of many keys
Distribution of keys
Replace keys by trusted KDC
Each node shares key with KDC
Requires O(n) keys
K
A
K
B
K
C
Key Distribution Center
A wants to send m privately to B
1. A requests key from KDC
2. KDC generates K
AB
and sends E
KA
(K
AB
) and E
KB
(K
AB
) to A
3. A sends (c1, c2) = (E
KB
(K
AB
), E
KAB
(A, B, m)) to B
4. B decrypts
c1 using K
B
to recover K
AB
c2 using K
AB
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 K
AB
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
Decryption
Xxx
Xxx x xxx x
Xxx xxx x
Xx xxx
Xxx
Xxx x xxx x
Xxx 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)
S
S
3
2
Digital Signature - Validation
M = 1011010011followed by S(h(M)(?)
1
3
h
P
P
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 guards
the guards?
CA1
CA2
Establish public key
of root CA - securely
Self-signed certificate
CA3
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 these
require
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 Modules
What is an HSM
Keys outside
the module
HSM
Master Key (MK)
Keys In clear
K1, K2 etc.
Crypto
functionality
E
MK
(K1),
E
MK
(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 etc
depending on the module.
The Master Key is usually a 3DES key which is
always stored in side the module (also stored on
smart cards or as components for recovery
reasons).
Keys or sensitive data stored outside the module
is 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 Management
EMI/EMC
Self tests
Design Assurance
Mitigation of other attacks
Module specification
Module interface
Roles and Authentication
Finite state model
Physical security
OS 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 4758
IBM 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 4758
CCA 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 been
loaded
exported under certain keys eg.
only the security world key (the
Master Key MK).
nShield from nCipher
nShield from nCipher
Performance 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 modify
functionality (FM functionality
module)
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
CCA PKCS11 PKCS11 Generic 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 the
CP/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 the
Administrator Smart Card Set protecting the secure world
FM on Eracom PSO
A functional module (FM) allows you to add and/or
modify the functionality of the PSO
Code can run inside the module and access the
same functionality as outside the module
(PKCS#11 API).
FM code must be signed (by a RSA key) and the
certificate 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
K
A
K
B
K
C
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 B
1. A requests key from KDC
2. KDC generates K
AB
and sends E
KA
(K
AB
) and E
KB
(K
AB
) to A
3. A sends (c1, c2) = (E
KB
(K
AB
), E
KAB
(A, B, m)) to B
4. B decrypts
c1 using K
B
to recover K
AB
c2 using K
AB
to recover m
Possible implementation of KDC
1. Use SW cryptographic module
2. Use HSM
Operations for generating keys, encrypting under key
3. 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 during
initialisation
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 K
AB
)
Encryption operations
Given K
A
(encrypted) encrypt K
AB
under K
A
Session key K
AB
in RAM!
Client keys stored encrypted in DB
Under master key
Master key stored in HSM
Access requires authentication
Master key generated and exported during
initialisation
Back up /clustering
Access to server gives access to
DB and HSM
S
e
c
u
r
i
t
y
o
f
m
a
s
t
e
r

k
e
y
d
e
p
e
n
d
s
o
n
p
r
o
c
e
d
u
r
e
s
KDC with Programmable HSM
Make special HSM function
gets K
A
and K
B
from DB (encrypted)
outputs E
KA
(K
AB
) and E
KB
(K
AB
)
K
AB
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 modified
S
e
r
v
e
r
,

H
S
M

a
n
d

D
B

i
n

p
r
o
t
e
c
t
e
d
r
o
o
m
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 with
standard API with key always protected
CA key can be used to sign anything!
With programmable HSM the key can be
restricted to sign formatted certificates
This may be sufficient to compromise the system
Cryptography and Key
Management
T. Pedersen, Cryptomathic