Derived Unique Key Per Transaction - Overview

Overview

DUKPT was first invented in the late 1980s at Visa, but it didn’t receive much acceptance until the 1990s. It was during this later period that the industry practices shifted towards recommending (and later requiring) that each device have a distinct encryption key. The scheme that was state-of-the-art at the time—known as “Master/Session”—would require that every PIN encrypting device be initialized with a unique master key. In consequence, processors would require a table of encryption keys as large as the number of devices deployed, when handling transactions originating from devices using Master/Session key management, given the need for unique keys per device. This table could become quite large for a major merchant acquirer. DUKPT solves this problem because—although each device is still initialized with a distinct key—this device initialization key is derived from a different key which an entire family of devices may share. Hence, the recipient of encrypted messages needs only to store one key to support a large number of devices in the field, while simultaneously meeting the unique-key-per-device requirement.

This single key was called the “super-secret key” in the original description of the algorithm, but was later renamed to the more official-sounding “Base Derivation Key” (or BDK). 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 recipient of the encrypted messages (typically a merchant acquirer), and the party which initializes the encryption devices (typically the manufacturer of the device). Further, there are pains taken to ensure that this key does not exist in plaintext outside of any tamper-resistant security module (TRSM, or HSM), and in fact is not the key that is used to initialize the encryption device that will participate in DUKPT operations. Rather, a different key is irreversibly derived from the BDK (and within a TRSM), known as the “Initial PIN Encryption Key” (IPEK). This is the key that is actually injected into the device, and a compromise of that key will not compromise the BDK (though the device itself would be considered compromised, and will need to have a new key injected). Even then, the IPEK is used internally by the device to create yet another set of keys irreversibly derived from it (called the “Future Keys”), and the IPEK is then immediately discarded.

On the originating (encrypting) 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”, that is used to encrypt the message, creating a cryptogram.
3. The pair of the cryptogram and an identifier known as the “Key Serial Number” (KSN) is returned from the encrypting device. The KSN is formed from the device’s unique identifier, and an internal transaction counter.
4. The (cryptogram, KSN) pair is forwarded on to the intended recipient, typically the merchant acquirer, where it is decrypted and processed further.
5. Internally, the device increments the transaction counter, invalidates the key just used, and possibly generates more future keys if needed.

On the receiving (decrypting) end, the system works as follows:

1. The (cryptogram, KSN) pair are received.
2. The appropriate BDK (if the system has more than one) 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 session key). The Key Serial Number (KSN) 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 (doing a “translate”), but for certain closed-loop operations may involve directly processing the data, such as verifying the PIN.

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 (a large number of devices may be serviced while only storing one key). It also provides some additional security with respect to the originator (PIN capture devices are often deployed in security-averse environments; the security parameters in the devices are ‘distant’ from the sensitive BDK, and if the device is compromised, other devices are not implicitly compromised).