Cryptography and Key Mangement
Post on 13-Oct-2015
22 Views
Preview:
DESCRIPTION
Transcript
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
top related