HSM basics continued

From jPOS.org

1.1 Cryptographic Keys

Cryptographic Keys are strings of bits that are used during the encryption and/or decryption process, according to the protocol being employed. Keys are measured in length of bits; the longer the keys, the better security they provide. These keys are analogous to the keys that secure a lock on a door. Compromising these keys can have significant consequences on any cryptosystem. These keys are usually stored in a Host Security Module, or as cryptograms (encrypted keys) in a Host’s database.

1.1.1 Master File Key (MFK)

This is a symmetric key, also known as Local Master Key (LMK), and is used to encrypt other cryptographic keys which are to be stored outside of the Hardware Security Module (‘HSM’). This is perhaps the most significant key in the organization as it secures every key in the cryptosystem. For this reason, it is recommended that it be created of triple length to ensure the best strength and durability. This is the first key created and entered into the HSM. The Key Custodian method must be used but on only at the local organization level. For management purposes, if using redundant HSMs, it is recommended that the same MFK be loaded into all of them. This will ensure interchangeability between the hardware devices. Typically the designated Key Custodians for this key type are people close to the IT and/or information security departments. These are people that are closely related to the HSM. The reason is that HSMs are hardware modules that can fail like any other hardware device, and so the Key Custodians must be readily available to re-create the MFK in the case of an emergency so as to limit the impact to the production.

1.1.2 Key Encryption Key (KEK)

This key is used for the secure transport and storage of other cryptographic keys. These key is used as a wrapper to ensure that keys are not compromised during the transport process from one party to another. This is a shared key that is exchanged between to parties using the Key Custodian method. Once this key is successfully exchanged, it will be used for exchanging new keys securely in an automated fashion.

1.1.3 Base Derivation Key (BDK)

Some encryption protocols, like the one employed in DUKPT, generate new keys dynamically. In DUKPT, a new key is generated for every transaction, making it virtually impossible for anyone to attempt to decipher the information in transit, or even break the key. Some protocols allow for a new key to be generated every (n) transaction, but the new key must be exchanged securely with the other party before it can be used. This exchange process may take a few seconds to complete, and therefore is not suitable for a one key per transaction protocol like DUKPT. To remove the need for a key exchange procedure, DUKPT not only generates a new key for every transaction, but also allows for the recipient of the data to re-generate the same key using transaction data and a previously shared key (BDK); this method is called key derivation. In key derivation protocols, the BDK must be shared either via the Key Custodian method, or in the case of PIN Pad devices, it must be injected into the device prior to being deployed. On the recipient’s side, this BDK must also be installed in order for the derivation procedure to work.

1.1.4 PIN Verification Key (PVK)

In order to calculate a ‘PIN offset,’ a ‘natural PIN’ must be derived and associated with each valid card number. The natural PIN is the result of encrypting the last 12 positions of the Primary Account Number (‘PAN’) under a key. This specific key is known as the PVK. The PVK is static so that for any given PAN, the same natural PIN will always be calculated. The HSM calculates the difference between the customer’s selected PIN and the card’s natural PIN. This difference – known as the PIN offset – is placed on your card database for subsequent PIN checks.

1.1.5 PIN Block

A PIN Block is a cryptogram of a customer-entered PIN during the transaction initiation process, whether it was entered at an ATM or at a POS device using a PIN Pad. In this method, using some protocol rules and standards, the customer selected PIN is formatted, according to the standard being employed, then it is encrypted using the DES algorithm. This formatting and encrypting of the PIN produces a 64 bit block of data. This PIN block travels with the transaction and must be verified by the issuing host in order to continue with the transaction authorization process.

1.1.6 Key Cryptogram

A key cryptogram is the result of encrypting a clear key value, in other words, producing a ciphertext block. For example, the result of entering keys into an HSM using the Key Custodian method is a key cryptogram. This key cryptogram can be stored in the HSM or on the Host. Storing these cryptograms on the Host provides for a much more flexible key management process in that if the HSM is ever replaced, the new HSM can be installed and only the MFK is to be entered. All other key cryptograms remain usable. If the key cryptograms are stored in the HSM itself, replacing the HSM will cause the entire key set to be re-entered using the Key Custodian method.

1.2 DES

Data Encryption Algorithm is a standard used for encrypting data, in which a private key is shared between one or more parties. This key is used, according to the protocol, to encrypt and decrypt the information being exchanged. The process of sharing the keys is called key exchange, and must be performed in a very secure manner to prevent key compromise. This method is described in the sections below.

1.3 DUKPT

DUKPT (Derived Unique Key Per Transaction) is an encryption standard that is recognized as the new and secure way of performing debit transactions. In the DUKPT protocol, the DES algorithm is also employed, which means that a secret key is also used. The difference is that in DUKPT, even though a secret key exchange does takes place between the interested parties, a new key is generated on every transaction by the sender. The recipient of the ciphertext is responsible to re-generate the same key used to encrypt the information received, from a combination of transaction data and the pre-exchanged secret key.

1.4 Key Exchange

A key exchange is the process of two parties exchanging keys in a secure manner. The idea is that 1) the same keys are used by both parties in order to enable them to understand the ciphertext being exchanged, and 2) that the keys remain secret during the exchange process. Many methods can be employed to securely exchange secret keys between parties. One of the most common methods is the key custodian method, in which one person in each of the organizations is tasked with generating (or entering) the secret key into the HSM. The issue with that is that now two persons, on separate organizations know the entire key. A variation of this method is that two or more key parts are generated (typically three parts), and distributed to two or more key custodians on both organizations. This method has proven to be the most secure method, although managing these key parts can become a formidable task. In the case of the two-key custodian method, two parts are generated by one organization. These two key parts must be combined at both organizations by their respective key custodians in order to make up the one secret key required by the cryptosystem. The process would go as follows:

a. Key Custodian 1 for organization A, generates key part 1 using an HSM and records it. It is recommended that at least a double-length key is generated.

b. Key Custodian 2 for organization A, generates key part 2 using the same HSM and records it.

c. Key Custodian 1 for organization A now sends a copy of key part 1 (via Floppy or letter) to Key Custodian 1 in organization B. Using the floppy disk or a letter are the preferred methods, as they can be sent in a tamper resistant container using certified mail.

d. Key Custodian 2 for organization A now sends a copy of key part 2 (via floppy or letter) to Key Custodian 2 in organization B.

e. In an audited key entering ceremony, Key Custodian 1 in organization A enters the HSM room, and enters Part 1 of the key. It is recommended that Key Custodians 1 and 2 should never enter the HSM room at the same time. Key Custodian 1 should record the check digits returned by the HSM.

f. In the same audited key entering ceremony, Key Custodian 2, in organization A enters the HSM room, and enters Part 2 of the key. Key Custodian 2 should record the check digits returned by the HSM for his/her key part. At this point, the HSM will return an ‘overall’ check digit value which should also be record by Key Custodian 2.

g. In a similar ceremony, Key Custodians 1 and 2 in organization B should perform the same procedures.

h. At the end of the ceremony, the Key Custodians 2 should compare the overall check digits to ensure that all key parts were entered correctly. If the overall check digits do not match, this is an indication that one or more parts were mis-keyed while entering them in the HSM. If this is the case, the key custodians should compare the check digits for their respective keys to identify where the problem might be.