Derived unique key per transaction


In cryptography, Derived Unique Key Per Transaction is a key management scheme in which for every transaction, a unique key is used which is derived from a fixed key. Therefore, if a derived key is compromised, future and past transaction data are still protected since the next or prior keys cannot be determined easily. DUKPT is specified in ANSI X9.24 part 1.

Overview

DUKPT allows the processing of the encryption to be moved away from the devices that hold the shared secret. The encryption is done with a derived key, which is not re-used after the transaction. DUKPT is used to encrypt electronic commerce transactions. While it can be used to protect information between two companies or banks, it is typically used to encrypt PIN information acquired by Point-Of-Sale devices.
DUKPT is not itself an encryption standard; rather it is a key management technique. The features of the DUKPT scheme are:
DUKPT was invented in the late 1980s at Visa but didn’t receive much acceptance until the 1990s, when industry practices shifted towards recommending, and later requiring, that each device have a distinct encryption key.
Before DUKPT, state of the art was known as Master/Session, which required every PIN-encrypting device to be initialized with a unique master key. In handling transactions originating from devices using Master/Session key management, an unwanted side effect was the need for a table of encryption keys as numerous as the devices deployed. At a major merchant acquirer the table could become quite large indeed. DUKPT resolved this. In DUKPT each device is still initialized with a distinct key, but all of the initialization keys of an entire family of devices are derived from a single key, the base derivation key. To decrypt encrypted messages from devices in the field, the recipient need only store the BDK.

Keys

As stated above, the algorithm needs an initial single key which in the original description of the algorithm was called the super-secret key, but was later renamed to—in a more official-sounding way—Base Derivation Key. The original name perhaps conveys better the true nature of this key, because if it is compromised then all devices and all transactions are similarly compromised.
This is mitigated by the fact that there are only two parties that know the BDK:
The BDK is usually stored inside a tamper-resistant security module, or hardware security module. It must remain clear that this key is not the one used to initialize the encryption device that will participate in DUKPT operations. See below for the actual encryption key generation process.
Upon detection of compromise the device itself a new is derived inside the and the Derived Key Generation Process

Communication

Origination

On the originating end, the system works as follows:
  1. A transaction is initiated which involves data to be encrypted. The typical case is a customer's PIN.
  2. A key is retrieved from the set of “Future Keys”
  3. This is used to encrypt the message, creating a cryptogram.
  4. An identifier known as the “Key Serial Number” is returned from the encrypting device, along with the cryptogram. The KSN is formed from the device’s unique identifier, and an internal transaction counter.
  5. The pair is forwarded on to the intended recipient, typically the merchant acquirer, where it is decrypted and processed further.
  6. Internally, the device does the following:
  7. # Increments the transaction count
  8. # Invalidates the key just used, and
  9. # If necessary generates more future keys

    Receiving

On the receiving end, the system works as follows:
  1. The pair are received.
  2. The appropriate BDK is located.
  3. The receiving system first regenerates the IPEK, and then goes through a process similar to that used on the originating system to arrive at the same encrypting key that was used. The Key Serial Number provides the information needed to do this.
  4. The cryptogram is decrypted with session key.
  5. Any further processing is done. For merchant acquirers, this usually means encrypting under another key to forward on to a switch, but for certain closed-loop operations may involve directly processing the data, such as verifying the PIN.

    Session Keys

The method for arriving at session keys is somewhat different on the originating side as it is on the receiving side. On the originating side, there is considerable state information retained between transactions, including a transaction counter, a serial number, and an array of up to 21 “Future Keys”. On the receiving side there is no state information retained; only the BDK is persistent across processing operations. This arrangement provides convenience to the receiver. It also provides some additional security with respect to the originator.

Registers Usage

Backup Registers

The following storage areas relating to key management are maintained from the time of the "Load Initial Key" command for the life of the PIN Entry Device:

Initial Key Serial Number Register (59 bits)

Holds the left-most 59 bits of the key serial number, that was initially injected into the PIN Entry Device along with the initial PIN encryption key during the "Load Initial Key" command. The contents of this register remain fixed for the service-life of the PIN Entry Device or until another "Load Initial Key" command.

Encryption Counter (21 bits)

A counter of the number of PIN encryptions that have occurred since the PIN Entry Device was first initialized. Certain counter values are skipped, so that over 1 million PIN encryption operations are possible. Note: The concatenation of the Initial Key Serial Number Register and the Encryption Counter form the 80-bit Key Serial Number Register.

Future Key Registers (21 registers of 34 hexadecimal digits each)

A set of 21 registers, numbered #1 to #21, used to store future PIN encryption keys. Each register includes a 2 hexadecimal digit longitudinal redundancy check or a 2 hexadecimal digit cyclical redundancy check.

Temporary Registers

The following storage areas relating to key management are required on a temporary basis and may be used for other purposes by other PIN processing routines:

Current Key Pointer (approximately 4 hexadecimal digits)

Contains the address of that Future Key Register whose contents are being used in the current cryptographic operation. It identifies the contents of that Future Key Register whose address is contained in the Current Key Pointer.

Shift Register (21 bits)

A 21-bit register, whose bits are numbered left to right as #1 to #21. This register normally contains 20 "zero" bits and a single "one" bit. One use of this register is to select one of the Future Key Registers. The Future Key
Register to be selected is the one numbered identically to the bit in the Shift Register containing the single "one".

Crypto Register-1 (16 hexadecimal digits)

A register used in performing cryptographic operations.

Crypto Register-2 (16 hexadecimal digits)

A second register used in performing cryptographic operations.

Key Register (32 hexadecimal digits)

A register used to hold a cryptographic key.

Practical Matters (KSN scheme)

In practical applications, one would have several BDKs on record, possibly for different customers, or to contain the scope of key compromise. When processing transactions, it is important for the receiver to know which BDK was used to initialize the originating device. To achieve this, the 80-bit KSN is structured into three parts: as Key Set ID, a TRSM ID, and the transaction counter. The algorithm specifies that the transaction counter is 21-bits, but treats the remaining 59 bits opaquely. Because of this, the entity managing the creation of the DUKPT devices is free to subdivide the 59 bits according to their preference.
The industry practice is to designate the partitioning as a series of three digits, indicating the number of hex digits used in each part: the Key Set ID, the TRSM ID, and the transaction counter. A common choice is '6-5-5', meaning that the first 6 hex digits of the KSN indicate the Key Set ID, the next 5 are the TRSM ID, and the last 5 are the transaction counter.
This notational scheme is not strictly accurate, because the transaction counter is 21 bits, which is not an even multiple of 4. Consequently, the transaction counter actually consumes one bit of the field that is the TRSM ID devices, instead of 2.
Also, it is common practice in the industry to use only 64-bits of the KSN, which would imply that the full KSN is padded to the left with four ‘f’ hex digits. The remaining 4 hex digits are available, nonetheless, to systems which can accommodate them.
The 6-5-5 scheme mentioned above would permit about 16 million BDKs, 500,000 devices per BDK, and 1 million transactions per device.