Key Management
Dr Michael J Ganley
mick.ganley@btopenworld.com
IC2: Key Management
Slide 1
30 November 2005
Generic Business Risks
Legal risk
Compliance
risk
People risk
IC2: Key Management
Credit risk
Market risk
Process risk
Slide 2
30 November 2005
Security is Like a Jigsaw Puzzle
• Security Systems include:
–
–
–
–
–
–
–
–
–
Physical Security
Access Control
Auditability
Accountability
Network Security
Security Management
Policies, Standards and Procedures
Cryptography
Disaster Recovery
IC2: Key Management
Slide 3
30 November 2005
Management of Cryptographic Systems
A cryptographic security system is a form of insurance and may cost a considerable
amount to purchase and to operate. Part of this cost is the management of the
system, which includes:
Procedures and Standards
Audit Trail Management
User Management
Token Management (e.g. smart cards)
Key Management
Access Control
Security Violations Investigation
Contingency Planning
Most organisations will have a dedicated Security Department, although all
employees must take security seriously.
IC2: Key Management
Slide 4
30 November 2005
Key Management
“A chain is only as strong as its weakest link”
The security of the system is dependent on the security of the keys regardless of algorithms, a security system without strong management
procedures and processes has no security
IC2: Key Management
Slide 5
30 November 2005
What is Key Management?
ANSI X9.17 (Financial Institutions Key Management –
Wholesale, 1985):
“...this standard establishes methods (including the protocol)
for the generation, exchange, use, storage and destruction of
these secret keys. This standard not only permits
interoperability among financial institutions, but also permits
interoperability between financial institutions and their
wholesale customers.”
IC2: Key Management
Slide 6
30 November 2005
Cryptographic Systems and Choice of Key
Management System
•
Usually determined by a combination of:
 Network topology (e.g. point-to-point, many-to-many)
 Cryptographic services (e.g. confidentiality, non-repudiation)
 Cryptographic mechanisms (e.g. encryption, digital signature)
•
A key management system may be chosen for emotional reasons.
•
Government restrictions may need to be taken into account.
•
Royalty and license payments may also be relevant.
•
There is usually no “right” answer!
IC2: Key Management
Slide 7
30 November 2005
Cryptographic Algorithms
For the purposes of this talk, we will generally consider just
two different block ciphers (a typical symmetric and a typical
asymmetric algorithm):
DATA ENCRYPTION ALGORITHM (DEA or DES)
symmetric
ANSI X3.92
56-bit key
can use with double or triple length key
RIVEST, SHAMIR, ADLEMAN (RSA)
asymmetric (public key)
variable modulus size (usually > 512 bits)
IC2: Key Management
Slide 8
30 November 2005
Cryptographic Algorithms
• The main requirement for the management
of keys used with symmetric algorithms is
that the keys remain secret.
• The main requirement for the management
of keys used with public key algorithms is
that the private key remains secret and the
public key is authentic.
IC2: Key Management
Slide 9
30 November 2005
Key Management Standards
There are many international and national standards relating to key
management. For example:
ANSI X9.17 / ISO 8732
ANSI X9.24
ETEBACS (France)
AS2805.6.xx (Australia)
APACS 40 & APACS 70 (UK)
ISO 11166
ISO 11568
In addition, there are many proprietary key management systems,
some closely related to standards, some loosely related to
standards and others completely non-standard.
NOTE: adherence to standards does not guarantee security!!!
IC2: Key Management
Slide 10
30 November 2005
Key Generation
DES keys:
• random or pseudo-random
• standard (ANSI X9.17) way to generate pseudo-random
DES keys
• exclude weak and semi-weak keys
• some keys may need to be in component form
RSA keys:
• generate strong primes (is this really necessary?)
• random or pseudo-random seed values
• may take some time to generate key set
• generate own key set (may not be practical)
• probabilistic methods usually preferred
IC2: Key Management
Slide 11
30 November 2005
Cryptoperiods
How often should a key be changed?
•
•
•
Single length DES key - frequently?
Double or triple length DES key - occasionally/never?
RSA key - ? (note that a 640 bit RSA key was cracked recently)
NOTE: Using the best available factoring algorithms:
RSA modulus (bits)
512
1024
2048
3072
Exhaustive Key Search (bits)
56
80
112
128
The “strength” of a key should be commensurate with the lifetime and
importance of the information that is being protected. In practice, this
requirement may be impossible to achieve!
IC2: Key Management
Slide 12
30 November 2005
Key Storage
Secret keys need to be stored securely.
For instance:
• inside a tamper-resistant hardware security module
• on a smart card or other token
• encrypted with another key and stored on a database
Notes:
• The third method above simply transfers the problem to the
encrypting key.
•
Storing plaintext keys in software is usually regarded as
providing a lower level of security than storing them in
tamper-protected hardware.
•
Keys may need to be archived for long periods of time (e.g.
7 years in the case of the London Stock Exchange).
IC2: Key Management
Slide 13
30 November 2005
Hardware Security Modules
• Secure key storage usually requires the use of a tamper-resistant
hardware security device, such as a host security module or PC
security module.
• Usually some form of local master key (LMK) is stored inside the
device and other keys, encrypted under the LMK, can be held
outside the device, but submitted to the module when required to be
used.
• In some cases, all the keys may be held inside the security module.
• The tamper-resistant features mean that all keys held inside the
module will be deleted from memory in the event of an attack on the
device.
• Back-up procedures for all keys held inside the security module
must be in place!
IC2: Key Management
Slide 14
30 November 2005
Hardware Security Modules
• Tamper-resistant features that may be used include:
Micro-switches
Electronic mesh
Potting sensitive components in resin
Temperature detectors
Light-sensitive diodes
Movement / tilt detectors
Voltage / current detectors
Secure components (“security chips”)
• Note that many security modules are in physically secure
environments (such as a computer centre) and so some of the
above features may be regarded as unnecessary. However,
devices (say) in a retail environment may need a high level of
protection.
IC2: Key Management
Slide 15
30 November 2005
Hardware Security Modules
• There are companies (such as TNO in Holland and T-Systems
in Germany) that carry out evaluations of the physical
protection offered by security modules.
• The ITSEC scheme (a joint initiative to evaluate security
products) has not really taken off - it is expensive and timeconsuming to get a product evaluated.
• The FIPS 140-2 standard provides four levels of approval for
security devices, including physical security - level 4 is
extremely hard to achieve.
Remark:
A paper published by Bond and Clayton (Cambridge) in 2002 showed how to
extract keys from a FIPS level 4 certified device (an IBM 4758 security module),
but this was really an attack on the device API rather than a physical attack on
the module.
IC2: Key Management
Slide 16
30 November 2005
Key Change
• In all cryptographic systems there should be the facility to change
keys. For instance:
• regular updates (planned)
• key compromise (unplanned)
• Many systems are designed so that it is extremely difficult and
expensive to change certain keys. In the case of compromise of
such a key, losses may include:
•
•
•
•
•
cost of distributing new key
cost of distributing new cards
cost of investigation into the compromise
cost of changing system and procedures
non-quantifiable costs
• e.g. damage to reputation, loss of customer confidence
IC2: Key Management
Slide 17
30 November 2005
Key Destruction
Keys, when no longer needed, must be destroyed in a
secure manner. Simply deleting a key file is not
sufficient.
ANSI X9.17 (Section 3.6.1):
“Paper-based keying materials shall be destroyed by
crosscut, shredding, burning or pulping. Keying material
stored on other media shall be destroyed so that it is
impossible to recover by physical or electronic means.”
IC2: Key Management
Slide 18
30 November 2005
Key Usage and Separation
Keys must only be used for their intended purpose. Separation of keys is
therefore required. Separation is enforced using a hardware security
module. For example:
• Storage
-
store key under a specified variant
of a Master Key
• Distribution -
use variant of key or variant of key
encrypting key for encryption
Other techniques:
• IBM Control Vectors
• Tagging of DES keys (uses the parity bits)
There is an initiative by the ANSI X9F committee to come up with a new
standard for a “secure key block” (TR-31 standard, currently at final draft).
Note: No universally accepted standards to achieve key separation.
IC2: Key Management
Slide 19
30 November 2005
(Theoretical) Example of Key Misuse
Function 1: Generate a 4 digit PIN by encrypting the account
number with a PIN Key, scanning the output for
the PIN and return the resulting PIN in encrypted
form.
Function 2: Generate an 8-character MAC using a MAC Key and
return the resultant value.
Misuse:
Use Function 2 to generate a MAC over the account
number, using the PIN Key. The result is an 8
character MAC, which will, with a probability of
about 0.9, yield the PIN.
Solution:
Prevent a PIN Key from masquerading as a MAC key.
IC2: Key Management
Slide 20
30 November 2005
Example of Key Masquerade
• In many systems different key types are stored encrypted under
different variants of a Storage Master Key (SMK), which (in theory)
prevents a key from being misused.
• Such systems also tend to have export and import functions, to
permit a key to be exported (encrypted under a Transport Key
(TK)) to another system or imported (encrypted under a TK) from
another system.
• In order to allow interoperability between different vendors’
solutions, variants are not usually applied to the TK.
• Hence, the “bad guy” can simply export a key of one type from
encryption under a variant of the SMK to encryption under the TK
and then import the same key from encryption under the TK to
encryption under a different SMK variant.
• This situation is permitted by the ANSI X9.17 standard!
IC2: Key Management
Slide 21
30 November 2005
Theoretical Example Revisited
ESMK(v1)(PIN Key)
Export PIN Key
Import PIN Key
ETK(PIN Key)
ESMK(v2)(PIN Key)
ESMK(v2)(MAC Key)
IC2: Key Management
PIN Key now masquerading as a
MAC key
Slide 22
30 November 2005
TR-31 Key Block
• As mentioned, an ANSI sub-committee is currently defining a new
key block, to ensure that a key can only be used for its intended
purpose.
• The key block should be usable for either key storage or key
distribution.
Header
(clear)
Optional
Header (clear)
Key
(encrypted)
Authenticator
(MAC)
Notes:
•
Header includes key usage, mode of use, exportability, algorithm.
•
Key encrypted using a variant of the storage or distribution key, in CBC mode.
•
Authenticator calculated using a different variant of the storage/distribution key.
•
Currently, only 3-DES supported (but extensions planned).
IC2: Key Management
Slide 23
30 November 2005
Key Distribution and Update
Keys need to be exchanged between communicating parties. This
usually involves a combination of manual and electronic means. One of
the main aims is to minimise the manual involvement. Key distribution
in large networks has, traditionally, been a major headache and a
potential source of weakness.
We consider five types of key distribution scheme:
1.
2.
3.
4.
5.
Master/Session Key (e.g. ANSI X9.17 / ISO 8732)
Hybrid RSA/DES scheme (e.g. ISO 11770-3 / ANSI X9.44)
Unique Key per Transaction (e.g. ANSI X9.24)
Diffie-Hellman key exchange (e.g. ANSI X9.42)
Quantum Key Distribution (QKD)
IC2: Key Management
Slide 24
30 November 2005
Master/Session Key Scheme (I)
Master Key Encrypting Key (KKM)
Key Encrypting Key (KK)
Data Key (KD)
KKM:
KK:
KD:
IC2: Key Management
double length DES key
manual exchange, in component form
infrequent change
used to encrypt KK(s) or KD(s) (but not both)
optional key
electronic distribution
double length DES key
used to encrypt KD(s)
cryptoperiod?
single or double length DES key
“working key” - e.g. Encryption, MACing, etc.
frequent change
electronic distribution
Slide 25
30 November 2005
Master/Session Key Scheme (2)
• For a simple point-to-point system, the Master/Session key
scheme is fine, but becomes unmanageable for large manyto-many systems.
• In such cases a Key Distribution Centre or Key Translation
Centre may be used, so that each party only has a permanent
keying relation with the Centre and yet can still communicate
with other parties.
The Centre must be trusted!
IC2: Key Management
Slide 26
30 November 2005
Master/Session Key Scheme (3)
Key Translation:
A
KKMAC
Centre
KKMBC
B
EKKMAC(KD)
Translate
EKKMBC(KD)
Key Distribution:
A
KKMAC
EKKMAC(KD)
EKKMBC(KD)
IC2: Key Management
Centre
KKMBC
B
Generate KD
EKKMBC(KD)
Slide 27
30 November 2005
Hybrid RSA/DES Scheme
RSA Key
Use RSA key for
encrypting a DES
KK or KD
KK (optional)
KD
• Particularly useful for many-to-many systems (e.g. SSL).
• Only RSA Public Keys need to be distributed - no need for
secrecy, but integrity is required. This is provided via the
use of a Public Key Certification Authority (CA).
IC2: Key Management
Slide 28
30 November 2005
Certification Authority (CA)
• A CA is a trusted third party, whose main purpose is to certify
public keys generated by users of the system.
• A certificate is a data structure containing information about
the owner of the key, algorithm details, key validity dates and
the public key in question. The data is hashed and then
signed using the CA private key.
• Certificates can be validated by any party with access to the
CA public key.
• The most common certificate format is defined in the CCITT
X.509 standard (version 3), but other formats exist (e.g. EMV).
IC2: Key Management
Slide 29
30 November 2005
Public Key Certificate
Public Key Certificate
Certificate
Core
Public Key
Extensions
General Information
about the user
User’s Public Key
Specific information
to the application
Standard formatting
(X.509 version 3)
Signature by a
Trusted third party
IC2: Key Management
Slide 30
30 November 2005
Certification Authority (CA)
• Care (and procedures) must be in place to ensure that only
genuine public keys are accepted for certification. This is
especially important in the case of on-line access to a CA.
• CA public keys may be unprotected by a certificate and so users
need to be assured of the authenticity of the CA public key. This
key must be stored securely.
• In more complex systems, there may be a hierarchy of CAs, with
each CA public key certified by the CA above it in the hierarchy.
Only the “Root” key cannot be protected in this way.
• Cross-certification of CAs is another option. Either way, each
certificate is part of a “certificate chain”.
IC2: Key Management
Slide 31
30 November 2005
Certification Authority (CA)
• Technical problems relating to CAs are relatively easy to
solve. The really difficult issues include:
•
•
•
•
•
Licensing of CAs
Who runs a CA and how do they make money out of it?
Trust - what is trust and who do we trust?
Liability
Legal status of digital signatures
• Many countries (including the UK) now have digital signature
legislation on the statute books, so the legal status of such
signatures is becoming more clear.
• Similarly, there is a European Union Directive on digital
signatures.
IC2: Key Management
Slide 32
30 November 2005
Trusted Third Parties (TTPs)
• What is a Trusted Third Party?
• A CA is an example of a TTP, but what other services might be
offered by a TTP? For example:
• Key generation
• Time-stamping
• Key recovery (key escrow?)
• Governments have a genuine concern regarding the widespread
use of strong encryption and would like (under strict conditions)
to obtain encryption keys from a TTP.
• Some companies may genuinely require a key recovery service.
IC2: Key Management
Slide 33
30 November 2005
Regulation of Investigatory Powers Act
• The Act (RIP Act, 2000) introduces a general power of the
Home Secretary to authorise an interception, if it is
• Requested by a competent authority
• Necessary
• Reasonable
• Proportionate
• Time-limited
• Part III of the Act talks about the disclosure of information that
is “protected by encryption”.
• May disclose plaintext only
• May be required to disclose keys
• Signature keys are specifically excluded
• Failure to comply with an order may lead to severe penalties
(fines and/or up to 2 years imprisonment).
IC2: Key Management
Slide 34
30 November 2005
Unique Key Per Transaction (I)
• A number of schemes exist which provide
automatic update of keys with every transaction.
• Thus, there are no static keys in the system.
• Particularly useful in the retail environment, where
insecure terminals may be used.
• Possible recovery or resynchronisation problems.
IC2: Key Management
Slide 35
30 November 2005
Unique Key Per Transaction (2)
Example: Racal Transaction Key Scheme (APACS 40/70)
• Based on single length DES (APACS 40) or double length DES
(APACS 70).
• Terminal and Host have a key register, which is updated with each
transaction.
• The transaction key(s) are derived from key register value and
card data.
• New key register value
= f (old register value, card data, transaction data)
• Uses MAC Residues
MAC
MAC
IC2: Key Management
MAC Residue
MAC Residue
Slide 36
30 November 2005
Unique Key Per Transaction (3)
Racal Transaction Key Scheme
Terminal
Host
1.
2.
Generate transaction keys
from register and card data
MAC Request Message
and retain MAC Residue
Request Message + MAC
3.
IC2: Key Management
Generate transaction keys from
register and card data
Slide 37
30 November 2005
Unique Key Per Transaction (4)
Racal Transaction Key Scheme (continued)
4.
5.
6.
Validate Request Message MAC
and retain MAC Residue
Generate Response Message MAC
and retain MAC Residue
Update register using MAC Residues
Request Message + MAC
7.
8.
Validate Response Message
MAC and retain MAC Residue
Update register using
MAC Residues
IC2: Key Management
Slide 38
30 November 2005
Unique Key Per Transaction (5)
Derived Unique Key per Transaction (DUKPT) Scheme
• This is a scheme used in the retail environment, supported by
Visa, amongst others.
• The fundamental idea is that there is a base derivation key,
from which transaction keys are generated (in an irreversible
way) using the terminal ID and a transaction counter.
• The host only needs to maintain a copy of the base derivation
key - the clever bit is for the host to be able to calculate
quickly the transaction key for a particular terminal.
• The terminal need only keep a copy of its last transaction key,
from which it can easily derive the next key.
IC2: Key Management
Slide 39
30 November 2005
Diffie-Hellman Key Exchange
• Method of exchanging public (i.e. non-secret)
information to obtain a shared secret (which can be
used as a key, for example).
• Susceptible to “man-in-the-middle” attack; ANSI
X9.42 standard provides mechanisms to defeat this
problem.
• Security relies on a hard mathematical problem
(Discrete Logarithm Problem).
IC2: Key Management
Slide 40
30 November 2005
Basic Form of Diffie-Hellman
• System parameters are p (large prime number) and g (base element)
Generate
random
value a
Alice
(gb)a
Calculate
mod p
IC2: Key Management
Generate
random
value b
ga (mod p)
Bob
gb (mod p)
Calculate (ga)b
mod p
Shared secret = (ga)b mod p
Slide 41
30 November 2005
Quantum Key Distribution (1)
• The laws of quantum physics can be used to create an unbreakable
key distribution system (Quantum Key Distribution – QKD). It is
based on the polarisation of light photons (effectively 4 states) and
polarisation filters.
• A separate insecure channel is used convey information about the
states of the photons that were sent. Incorrect “guesses” about the
state are discarded.
• An eavesdropper can only guess at each state, but an incorrect guess
cannot be later corrected.
• Eavesdropping can be detected with a high degree of probability (the
act of eavesdropping may alter the state – Heisenberg’s Uncertainty
Principle).
• The result is a “random” bit sequence – used as a one-time pad.
IC2: Key Management
Slide 42
30 November 2005
Quantum Key Distribution (2)
The following description is taken from Simon Singh’s book “The Code Book”:
1. Alice sends Bob a series of photons and Bob measures them.
2. Alice tells Bob on which occasions he measured them the correct way
(i.e. using a rectilinear or diagonal filter), but not the actual value sent.
3. Alice and Bob discard the incorrect measurements and concentrate only
on the correct measurements to form the one-time pad.
4. Alice and Bob check the integrity of their one-time pad by checking a
few of the bits (which are then discarded). This process will detect
whether eavesdropping has occurred (with high probability).
Neils Bohr: Anyone who can contemplate quantum
mechanics without getting dizzy hasn’t understood it.
IC2: Key Management
Slide 43
30 November 2005
Reality!
•
Quantum computers don’t yet exist, so “classical” cryptography
is safe for the moment! Some experts reckon that it will be
another 30-50 years before a practical machine can be built.
•
QKD is a reality, but is not yet a practical proposition except in
highly controlled environments.
•
•
•
•
•
1988 – first demonstration (over distance of 30 cm).
1995 – using optic fibre over 23km.
2002 – using optic fibre over 67km
2002 – free transmission, 2km.
A number of QKD products have recently appeared on the
market (effectiveness unknown!).
IC2: Key Management
Slide 44
30 November 2005
Example 1: Shared ATM System
Bank
SWITCH
Bank
Bank
Bank
Bank
IC2: Key Management
Slide 45
30 November 2005
Example 1 (continued)
• Some 40 Banks acquire ATM transactions for each other.
• On-line PIN verification at Issuer Bank.
• Central SWITCH (translates PINs, not keys).
• Each Bank has a keying relation with SWITCH and its own
ATMs.
• Master/Session Key scheme on Bank-SWITCH links.
• Unique Key per Transaction scheme on Bank-ATM links.
• All Bank-SWITCH messages are MACed.
IC2: Key Management
Slide 46
30 November 2005
Example 2: Clearing Bank System
Stand-alone CA
Clearing Centre
Bank
Bank
Bank
IC2: Key Management
Slide 47
30 November 2005
Example 2 (continued)
• Requirement is for all transactions to have a digital signature.
No encryption required.
• Banks and Centre generate own keys.
• CA certifies all public keys.
• Smart cards used for transportation of RSA public keys and
storage of RSA private keys.
• In the early days of this system, clearing could take up to 10
days, so problems with out-of-date Certificates.
IC2: Key Management
Slide 48
30 November 2005
Example 3: AS2805 PIN Pad Initialisation
Host System
PIN Pad
PKpp / SKpp
PKh / SKh
ESKman(PKpp)
PKman
Manufacturer
PKman / SKman
IC2: Key Management
Slide 49
30 November 2005
Example 3 (continued)
1
ESKman(PKpp) + PPID + Other data
2
PKh + RN
3
ESKpp(EPKh(*KI, PPID, DTS, RN, Other data))
4
E*KI(*KCA) + Other data
Must have:
PKman modulus > PKpp modulus > PKh modulus
Note: This standard has now been withdrawn!
IC2: Key Management
Slide 50
30 November 2005
Example 4: Chip & PIN
•
Security Requirements
– card authentication to terminal
–
Static or Dynamic Data Authentication (SDA, DDA)
– transaction integrity
–
application cryptogram (MAC)
– secure messaging
–
confidentiality (encryption) and integrity (MAC)
– PIN encryption at point of entry (optional)
– cryptographic isolation of cards
IC2: Key Management
Slide 51
30 November 2005
Chip & PIN: Algorithms and Mechanisms
•
Algorithms
– 3-DES, RSA, SHA-1
– possibly new algorithms in the future (e.g. ECDSA)
•
Mechanisms
– RSA digital signatures and public key certificates
–
EMV format certificates
– card unique 3-DES keys, derived from Master Keys
– unique session keys for encryption and MAC
IC2: Key Management
Slide 52
30 November 2005
Chip & PIN: Smart Card Lifecycle
•
There are essentially three aspects to a chip card
lifecycle in a typical payment system, such as Chip &
PIN:
– Card Issuance
– Chip manufacture, card fabrication
– Public Key Infrastructure (in some cases)
– Data generation (some secret, e.g. cryptographic keys and
PINs), personalisation and issuance
– PIN mailer
– Card Usage
– Transaction (Cardholder, Retailer, Acquirer and Issuer)
– Post Issuance (Card Management System)
– Lost or stolen card, forgotten PIN (etc)
– Load new applications, update or delete existing applications
IC2: Key Management
Slide 53
30 November 2005
Chip & PIN: Card Issuance
Card Fabricator
Chip
Raw Materials
Unpersonalised Card
Chip Manufacturer
Card Issuer
Card Data
Card
Personalisation System
PIN Mailer
IC2: Key Management
Pre-Personalisation
Process (P3)
Slide 54
30 November 2005
Chip & PIN: Card Usage
Card Issuer
Security of overall
transaction is between
the card and the Card
Issuer, using card and
transaction unique
session keys
Static or
Dynamic Data
Authentication
between card
and terminal
Terminal
IC2: Key Management
Acquirer
Slide 55
30 November 2005
Chip & PIN: Post Issuance
Home PC (via
Internet)
Issuer Card
Management
System and P3
ATM
PoS Terminal
Mobile Phone
IC2: Key Management
Update card via multiple
(insecure) channels
Slide 56
30 November 2005
Thank you for listening
IC2: Key Management
Slide 57
30 November 2005