The Derived Unique key per Transaction (DUKPT) Scheme is used in a point-of-sale (POS) environment. As its name indicates, Derived Unique Key per Transaction generates a new key for each transaction.
This technique involves the use of Base Derivation Key (BDK) and Key Serial Number (KSN). On each transaction, the PIN pad generates a new encryption keys that are derived from a secret BDK and a non-secret KSN. It encrypts the PIN with this key, and then forwards both the encrypted PIN and the key serial number to the acquirer.
The benefit of DUKPT is that if one of these one-time encryption key is discovered, only one transaction will be compromised, none of the others transactions from the same POS device would be able to be decrypted with that key.
Note that the ANSI X9.24-1:2009 method for DUKPT PIN key derivation is used.

Base Derivation Key

Acquirer host has the responsibility for maintaining the Base Derivation Key. In HSM, the one-time encryption key generated by the PIN-entry is “derived”, using the original Base Derivation Key and the Key Serial Number supplied by the PIN-entry.
In practical applications, acquirer host would have several BDKs, possibly for different PIN-entry devices. When processing transactions, it is important for the acquirer to know which BDK was used to initialize or injected into the originating PIN-entry device. To achieve this, Base Derivation Key identifier is embedded in Key Serial Number string.

For each transaction, acquirer host will extract from internal storage the appropriate encrypted base derivation key identified by the BDK ID of the KSN string. Acquirer host must find a match within BDK cryptogram list (BDK profile maintained in acquirer host). If a match is not found in the database, the transaction will be rejected.

KSN Descriptor “605”
The ‘rules’ for a 16-position KSN construction are as follows (reading from left to right in the KSN):

Base Derivation Key Identifier, which is a mandatory and five to nine position in length

Sub-Key Identifier, which is optional but in practice is reserved for future use and therefore always set to zero

Device Identifier, which is a mandatory and two to five position in length

Transaction Counter, which is mandatory and the remaining position of KSN

The industry practice (Thales/RACAL implementation) is to designate KSN descriptor as a series of three digits, indicating the number of hex digits make-up of the KSN.
A common choice is ‘605’, meaning that the 16-digit KSN consists of:

a 6-position BDK ID

a 0-position Sub-key

a 5-position Device ID

the remaining 5-position Transaction Counter
For example, a typical KSN might be 123456000A8001D4 where:

123456 is the BDK ID

000A8 is the Device ID

001D4 is the transaction counter
The KSN implementation must be in sync between the PIN-entry devices and Acquirer host. All PIN-entry devices must use the same KSN rules.

 Acquirer Processing
PIN-enabled transactions sent in from an acquirer’s point-of-sales location, acquirer host must perform a PIN translation, typically transforming an incoming DUKPT PIN block from the POS device-initiated request into an outgoing Triple DES-encrypted PIN block that makes use of an established ZONE PIN key shared with Issuer or switch.
The ISO 8583 POS message data field 52 contains encrypted PIN block whereas the data field 53 contains Key Serial Number. The PIN block is in the ANSI X9.8 format 0 i.e. Format 01.
Below is the additional POS data field required to support DUKPT key scheme:


Filed NoAttributeBytesDescription
53Binary 648DUKPT Key Serial Number, conform to KSN descriptor “605” i.e. 16-digit KSN consists of a 6-position BDK ID, a 0-position Sub-key, a 5-position Device ID and the remaining 5-position Transaction Counter.


Please take note that CardLinK host only require 8 bytes KSN in Field 53.