1. System Overview
The DUKPT (Derived Unique Key Per Transaction) system manages payment terminal encryption through a three-tier key hierarchy. The Base Derivation Key (BDK) is the foundation—held securely in an HSM at the acquirer/processor. From this, unique Initial PIN Encryption Keys (IPEKs) are derived for each terminal. These IPEKs are then used to generate up to 21 Future Keys stored in the terminal, which finally produce unique session keys for each transaction.
Scope: BDK (HSM Only)
- Never leaves HSM
- Shared across fleet
- Multiple BDKs possible
- Identified by BDK-ID (6 hex digits)
Scope: IPEK (Terminal Only)
- Generated once per terminal
- Injected into terminal securely
- Discarded after generating Future Keys
- Derived from BDK + unique KSN
2. KSN (Key Serial Number) Structure
The KSN is a 10-byte (20 hex-digit) value that encodes terminal identity and transaction state:
| Field | Bits/Hex Digits | Purpose | Example |
|---|---|---|---|
| BDK-ID | 24 bits (6 hex) | Identifies which BDK to use for derivation | 0003E9 |
| Terminal ID | 19 bits (5 hex) | Semi-unique identifier for the terminal | 00001 |
| Transaction Counter | 21 bits (5 hex) | Increments with each transaction/derivation | 00001 |
Example: KSN =
BDK-ID: 0003E9 | Terminal ID: 00001 | Counter: 00001
0003E900000100000001
BDK-ID: 0003E9 | Terminal ID: 00001 | Counter: 00001
3. IPEK Derivation from BDK & KSN
The IPEK is derived using Triple-DES encryption in a specific sequence:
1
Prepare KSN for IPEK Derivation
Pad KSN to left with 'F' to 20 hex chars. Clear rightmost 21 bits (set transaction counter to 0). Result is the "Initial KSN" (IKSN).
2
Extract and Prepare Data
Take leftmost 16 hex chars (8 bytes) of the IKSN. This will be encrypted to form the IPEK.
3
Generate Left Half of IPEK
Triple-DES encrypt the 8-byte data with the 16-byte BDK using key structure [BDK(1-8), BDK(9-16), BDK(1-8)] (EDE3). Result is 8 bytes.
4
Generate Right Half of IPEK
Create modified BDK by XORing both halves with 0xC0C0C0C0. Triple-DES encrypt the same 8-byte data with modified BDK. Result is 8 bytes.
5
Concatenate into IPEK
Left half (8 bytes) + Right half (8 bytes) = complete 16-byte IPEK (32 hex digits).
Worked Example:
Input:
BDK = 0123456789ABCDEF FEDCBA9876543210
KSN = 0123456789A00001
Step 1: Pad and clear counter
KSN → IKSN = FFFF0123456789A00000
Step 2: Extract 8 bytes
Data = FFFF0123456789A0
Step 3: Left half
TDES_EDE3(Data, BDK[1-8]+BDK[9-16]+BDK[1-8]) = 78DF942D65A2ECE6
Step 4: Right half
ModBDK = 0123...XOR C0C0C0C0...etc
TDES_EDE3(Data, ModBDK) = [8 more bytes]
Step 5: IPEK Result
IPEK = 78DF942D65A2ECE6[8 more bytes] (16 bytes total)
4. Terminal Key Injection Process
Keys are injected into terminals securely using TR-34 or TR-31 key blocks during a Key Injection Facility (KIF) session:
A
Pre-Injection Setup (at KIF)
Terminal generates unique device nonce and certificate. HSM uses terminal's BDK-ID to select correct BDK. Serial number and load-counter are established for this terminal.
B
Build Initial KSN (iKSN)
Assemble iKSN from BDK-ID (6 hex) + Terminal Serial (4-5 hex) + Load Counter (4-5 hex). Counter bits initially set to 0. Example: 0003E900000100000000
C
Derive IPEK in HSM
HSM computes IPEK = Derive(BDK, iKSN) using Triple-DES algorithm. IPEK is generated in HSM only, never exposed in clear outside HSM.
D
Create TR-34 or TR-31 Key Block
TR-34 (Asymmetric): HSM encrypts IPEK with terminal's public key, signs with private key.
TR-31 (Symmetric):strong> IPEK wrapped with temporary KEK, MAC applied, KCV calculated.
TR-31 (Symmetric):strong> IPEK wrapped with temporary KEK, MAC applied, KCV calculated.
E
Transport to Terminal
Encrypted key block (with iKSN and KCV) sent to terminal via secure channel. Terminal verifies integrity and decrypts using its private key.
F
Generate & Store Future Keys
Terminal uses IPEK to derive 21 Future Keys for counter values that are powers of 2 (2^0, 2^1, ... 2^20). These are stored in FK registers.
G
Discard IPEK, Store iKSN
IPEK is erased from terminal memory after Future Keys are generated. iKSN is retained for transaction processing and regenerating Future Keys as needed.
5. Future Keys & Session Key Generation (In Terminal)
After IPEK is discarded, the terminal uses Future Keys to derive unique session keys for each transaction:
| Phase | Location | Key Used | Purpose | Result |
|---|---|---|---|---|
| Injection Time | Terminal | IPEK (derived, then discarded) | Generate 21 Future Keys for counter powers of 2 | 21 Future Keys in FK registers |
| Transaction 1 | Terminal | FK21 (for counter 2^0=1) | Derive session key, encrypt PIN/data | FK21 erased, session key used once |
| Transaction 2 | Terminal | FK20 (for counter 2^1=2) | Derive session key, re-generate FK21 for counter 3 | FK20 erased, FK21 regenerated |
| Subsequent | Terminal | FK registers dynamically used/regenerated | Each transaction uses unique derived key | Supports ~1M transactions before re-injection |
6. KSN Binding to Transactions
The KSN is transmitted with encrypted data so the acquirer can regenerate the same session key for decryption:
Binding Process:
- Terminal maintains transaction counter in KSN's rightmost 21 bits
- For each transaction, counter is incremented and set in active KSN
- Working KSN (transaction-specific) is derived from iKSN by updating counter bits
- Working KSN + encrypted data transmitted to acquirer
- Acquirer recovers working KSN from transmitted data, uses with BDK to regenerate session key
Terminal State (Transaction N):
iKSN = 0003E900000100000000 (stored, unchanged)
Transaction Counter = 5
Working KSN = 0003E900000100000005 ← counter updated
Derivation Process (at acquirer, receiving KSN):
1. BDK (known) + Working KSN (from terminal) → Derive Future Key
2. Future Key + variant → Session Key for this transaction
3. Session Key → Decrypt transaction data
7. Complete Injection & Derivation Summary
| Stage | Input | Process | Output | Storage |
|---|---|---|---|---|
| Pre-Injection | Terminal identity info | Establish iKSN, terminal nonce | iKSN value | KIF records |
| Key Derivation | BDK (in HSM) + iKSN | Triple-DES: Left & Right halves | 16-byte IPEK (unique per terminal) | HSM (temporary) |
| Key Protection | IPEK + Terminal Cert (TR-34) or KEK (TR-31) | RSA/AES encryption + signature/MAC | TR-34/TR-31 key block (safe for transmission) | In-transit (encrypted) |
| Terminal Injection | Encrypted key block + iKSN | Terminal decrypts, verifies KCV | IPEK loaded into terminal (plaintext, secure enclave) | Terminal RAM |
| Future Key Gen | IPEK + counter powers of 2 | 21 derivation cycles using IPEK | 21 Future Keys (FK registers) | Terminal secure memory |
| Post-Injection | iKSN (retained) | IPEK erased; iKSN + FK registers ready | Terminal ready for transactions | iKSN & FK in terminal; BDK in HSM |
8. Security Properties
Why This Design?
- Scalability: One BDK serves entire terminal fleet
- Uniqueness: Each terminal gets unique IPEK from iKSN
- Isolation: Compromised terminal IPEK doesn't expose BDK
- Transaction Keys: Every transaction uses different derived key
Attack Resistance
- BDK never enters terminal or network
- IPEK discarded after Future Key generation
- Session keys are one-time use (or limited use)
- KCV validates key integrity
- TR-34 adds asymmetric signatures for authenticity