Key Management Dr Michael J Ganley mick ganley btopenworld

Key Management Dr Michael J Ganley mick. ganley@btopenworld. com IC 2: Key Management Slide 1 30 November 2005

Generic Business Risks Legal risk Compliance risk People risk IC 2: 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 Management Policies, Standards and Procedures Cryptography Disaster Recovery IC 2: 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. IC 2: 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 IC 2: Key Management Slide 5 30 November 2005

What is Key Management? ANSI X 9. 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. ” IC 2: 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! IC 2: 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 X 3. 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) IC 2: 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. IC 2: Key Management Slide 9 30 November 2005

Key Management Standards There are many international and national standards relating to key management. For example: ANSI X 9. 17 / ISO 8732 ANSI X 9. 24 ETEBACS (France) AS 2805. 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!!! IC 2: Key Management Slide 10 30 November 2005

Key Generation DES keys: • random or pseudo-random • standard (ANSI X 9. 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 IC 2: 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! IC 2: 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). IC 2: 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! IC 2: 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. IC 2: Key Management Slide 15 30 November 2005

Hardware Security Modules • There are companies (such as TNO in Holland 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. IC 2: 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 IC 2: 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 X 9. 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. ” IC 2: 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 X 9 F 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. IC 2: 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. IC 2: 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 X 9. 17 standard! IC 2: Key Management Slide 21 30 November 2005

Theoretical Example Revisited ESMK(v 1)(PIN Key) Export PIN Key ETK(PIN Key) Import PIN Key ESMK(v 2)(PIN Key) ESMK(v 2)(MAC Key) IC 2: 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) Authenticat or (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). IC 2: 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 X 9. 17 / ISO 8732) Hybrid RSA/DES scheme (e. g. ISO 11770 -3 / ANSI X 9. 44) Unique Key per Transaction (e. g. ANSI X 9. 24) Diffie-Hellman key exchange (e. g. ANSI X 9. 42) Quantum Key Distribution (QKD) IC 2: 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: IC 2: 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! IC 2: 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) IC 2: 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). IC 2: 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). IC 2: Key Management Slide 29 30 November 2005

Public Key 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 IC 2: 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”. IC 2: 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. IC 2: 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. IC 2: 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). IC 2: 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. IC 2: 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 IC 2: Key Management 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. IC 2: 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 IC 2: 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. IC 2: Key Management Slide 39 30 November 2005

Diffie-Hellman Key Exchange • Method of exchanging public (i. e. nonsecret) information to obtain a shared secret (which can be used as a key, for example). • Susceptible to “man-in-the-middle” attack; ANSI X 9. 42 standard provides mechanisms to defeat this problem. • Security relies on a hard mathematical problem (Discrete Logarithm Problem). IC 2: Key Management Slide 40 30 November 2005

Basic Form of Diffie-Hellman • System parameters are p (large prime number) and g (base element) Alice Calculate (gb)a mod p IC 2: Key Management Generate e random value b value a ga (mod p) gb (mod p) Shared secret = (ga)b mod p Slide 41 Bob Calculate (ga)b mod p 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. IC 2: 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. IC 2: 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 23 km. 2002 – using optic fibre over 67 km 2002 – free transmission, 2 km. A number of QKD products have recently appeared on the market (effectiveness unknown!). IC 2: Key Management Slide 44 30 November 2005

Example 1: Shared ATM System Bank SWITCH Bank IC 2: 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. IC 2: Key Management Slide 46 30 November 2005

Example 2: Clearing Bank System Stand-alone CA Clearing Centre Bank IC 2: 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. IC 2: Key Management Slide 48 30 November 2005

Example 3: AS 2805 PIN Pad Initialisation Host System PIN Pad PKpp / SKpp PKh / SKh ESKman(PKpp) PKman Manufacturer PKman / SKman IC 2: Key Management Slide 49 30 November 2005

Example 3 (continued) 1 ESKman(PKpp) + PPID + Other data 2 PKh + RN 3 4 ESKpp(EPKh(*KI, PPID, DTS, RN, Other data)) E*KI(*KCA) + Other data Must have: PKman modulus > PKpp modulus > PKh modulus Note: This standard has now been withdrawn! IC 2: 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 IC 2: 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 IC 2: 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 IC 2: Key Management Slide 53 30 November 2005

Chip & PIN: Card Issuance Chip Card Fabricator Raw Materials Unpersonalised Card Chip Manufacturer Card Data Card Issuer Card Personalisation System PIN Mailer IC 2: Key Management Pre. Personalisation Slide 54 30 November 2005 Process (P 3)

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 IC 2: Key Management Acquir er Slide 55 30 November 2005

Chip & PIN: Post Issuance Home PC (via Internet) Issuer Card Management System and P 3 ATM Po. S Terminal Mobile Phone IC 2: Key Management Update card via multiple (insecure) channels Slide 56 30 November 2005

Thank you for listening IC 2: Key Management Slide 57 30 November 2005