Derived Unique Key Per Transaction - Practical Matters (KSN Scheme)

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 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 (the algorithm only specifies that unused bits be 0-padded to a nibble boundary, and then 'f' padded to the 80-bit boundary). Because of this, the entity managing the creation of the DUKPT devices (typically a merchant acquirer) 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 (i.e., which BDK is to be used), the next 5 are the TRSM ID (i.e. a device serial number within the range being initialized via a common BDK), 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 (the number of bits in a hex digit). Consequently, the transaction counter actually consumes one bit of the field that is the TRSM ID (in this example that means that the TRSM ID field can accommodate 2(5*4-1) devices, instead of 2(5*4), or about half a million).

Also, it is common practice in the industry to use only 64-bits of the KSN (probably for reasons pertinent to legacy systems, and DES encryption), which would imply that the full KSN is padded to the left with four ‘f’ hex digits. The remaining 4 hex digits (16-bits) 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.