Fact-checked by Grok 2 weeks ago

Derived unique key per transaction

Derived Unique Key Per Transaction (DUKPT) is a symmetric key management algorithm that derives a unique, one-time-use encryption key for each financial transaction from an initial base derivation key (BDK), ensuring that no single key is reused and thereby limiting the impact of potential compromises.^[1] This scheme is primarily employed in secure cryptographic devices (SCDs) such as point-of-sale (POS) terminals and PIN entry devices to protect sensitive information like personal identification numbers (PINs) and cardholder data during transmission.^[2] By generating transaction-specific keys, DUKPT supports functions including PIN encryption, data encryption, key derivation, and message authentication, making it a cornerstone of retail financial security.^[1] The DUKPT process relies on a key serial number (KSN), an 80-bit value that combines a device-specific identifier with a transaction counter, to deterministically derive keys without requiring real-time key exchange between devices and hosts.^[3] For each transaction, the current encrypting key is computed by iteratively applying encryption operations based on the bits in the KSN's counter portion, after which the key is discarded to prevent reuse.^[3] This derivation begins with an initial PIN encryption key (IPEK) generated from the BDK for each device, allowing independent key generation on both transaction-originating and receiving ends.^[4] Originally standardized using the Triple Data Encryption Algorithm (TDEA) in the late 1990s, DUKPT has evolved to incorporate the Advanced Encryption Standard (AES) for enhanced security against modern threats like brute-force attacks and quantum computing.^[5] The AES variant, detailed in ANSI X9.24-3:2017, supports key lengths of 128, 192, or 256 bits and includes features like CMAC for data integrity verification, enabling a smoother transition from legacy TDEA systems in payment infrastructures.^[1] This update maintains backward compatibility while providing stronger protection, with the counter limited to a maximum of 1,000,000 transactions per device to enforce key rotation.^[3]

Introduction

Overview

Derived Unique Key Per Transaction (DUKPT) is a symmetric key management scheme that generates a unique encryption key for each transaction from a shared base derivation key, utilizing a key serial number (KSN) to ensure both parties can independently compute the same key without direct exchange.^[4]^[3] This method, standardized in ANSI X9.24, employs a hierarchical derivation process based on non-invertible functions, providing forward and backward security such that a compromised transaction key cannot reveal prior or subsequent keys in the sequence.^[6] The primary purpose of DUKPT is to protect sensitive data, such as personal identification numbers (PINs), in untrusted environments by limiting key exposure and enabling one-time use per transaction.^[4] It is widely applied in financial systems, including point-of-sale (POS) terminals, automated teller machines (ATMs), and payment processing networks, where devices encrypt PIN blocks using the derived key before transmission to a secure host.^[4] In these scenarios, the scheme prevents widespread compromise if a device is physically accessed, as only the current key is available, and past keys are erased from memory.^[3] In the basic workflow, the originating device (e.g., a POS terminal) and receiving host share an initial base key; for each transaction, the device increments the transaction counter within the KSN and derives the unique key via iterative encryption steps, then uses it to encrypt data before discarding it.^[4]^[3] The host performs the same derivation using the provided KSN to decrypt. This eliminates the need for real-time key exchange, supports up to $2^{21} transaction slots (approximately 2 million) per initial key, and restricts exposure to a single device lifecycle.^[3] Key benefits include enhanced security through key diversification and automatic rotation, reducing the impact of breaches in distributed systems.^[6] The AES variant of DUKPT supports 128-bit keys for stronger encryption, aligning with modern cryptographic requirements while maintaining compatibility with legacy triple DES implementations.

History

The Derived Unique Key Per Transaction (DUKPT) scheme was invented by Visa in 1987 to address vulnerabilities in traditional master/session key management approaches for protecting PINs during electronic funds transfer transactions.^[7] This innovation aimed to provide a more secure method by generating unique keys for each transaction, reducing the risk of key compromise across multiple uses.^[8] DUKPT received its initial formal documentation in the 1990s through ANSI X9.24, which specified an implementation based on the Triple Data Encryption Algorithm (TDEA, also known as 3DES).^[8] During this period, the scheme gained widespread adoption in automated teller machines (ATMs) and point-of-sale (POS) devices, supplanting less secure key management practices that relied on reusable session keys and were prone to interception or replay attacks.^[7] In 2004, ANSI X9.24 was updated to incorporate DUKPT explicitly in Annex A, standardizing its use for symmetric key management in retail financial services. The PCI Security Standards Council endorsed DUKPT in 2007 within its PIN Transaction Security (PTS) POI standards, and later incorporated it as a key component for point-to-point encryption (P2PE) solutions starting in 2012, facilitating secure transmission of sensitive card data from acquisition to processing. The transition to an AES-based variant of DUKPT began with the approval of ANSI X9.24-3 in 2017, driven by the growing deprecation of 3DES due to its computational weaknesses. Verifone achieved the first commercial implementation of AES DUKPT in 2018, marking a significant step in modernizing payment key management amid regulatory pressures to phase out legacy algorithms.^[9] As of 2025, DUKPT remains dominant in legacy payment systems, particularly those still using 3DES, but is actively phasing toward AES implementations to counter emerging quantum computing threats and comply with mandates in PCI DSS v4.0, which emphasizes stronger cryptographic protections, in line with PCI PTS POI v7.0 (as of 2025), which deprecates TDES and mandates 128-bit or stronger cryptography. At the 2025 PCI SSC meeting, POI v7.0 was highlighted for mandating 128-bit or stronger cryptography, fully deprecating TDES in new POI devices to enhance DUKPT's AES adoption.^[10]

Core Concepts

Key Types

The Derived Unique Key Per Transaction (DUKPT) scheme utilizes a hierarchical structure of keys to produce unique symmetric encryption keys for each transaction, ensuring forward and backward compatibility in key usage across devices and receivers. This hierarchy begins with a base key and progresses through intermediate keys to per-transaction keys, with variants supporting either Triple Data Encryption Algorithm (TDEA) or Advanced Encryption Standard (AES) ciphers. The Base Derivation Key (BDK) serves as the root shared secret in the DUKPT system, injected into payment terminals or hardware security modules during manufacturing to enable secure key generation. It is a 128-bit double-length key in TDEA implementations or a 128-, 192-, or 256-bit key in AES implementations, and it is uniquely assigned to batches of devices to limit exposure risks if compromised.^[11]^[12] From the BDK, the Initial PIN Encryption Key (IPEK) is derived using the device's specific Key Serial Number (KSN), acting as the starting point for all subsequent transaction key generation within that device. The IPEK functions as the initial working key, mirroring the BDK's size—128 bits for TDEA or 128/192/256 bits for AES—and is typically loaded into the device alongside precomputed derivatives to initialize the key management process.^[11]^[4] The Future Keys form a set of 21 precomputed intermediate keys derived from the IPEK in the TDEA variant, each tied to a specific slot in the 21-bit transaction counter to support sequential key advancement without real-time computation during transactions. These keys are sized at 128 bits for TDEA variants (treated as two 64-bit halves in derivation contexts). In the AES variant, future keys are derived differently using a 32-bit counter, without a fixed set of 21 precomputed keys. They are 128/192/256 bits for AES and stored in backup registers to enable rapid access for ongoing and anticipated transactions.^[13]^[11] The Transaction Unique Key (TUK) represents the final, one-time-use key for each transaction, derived from the current Future Key combined with non-repeating bits from the KSN to ensure uniqueness. Matching the sizes of the upstream keys—128 bits (double-length) for TDEA or 128/192/256 bits for AES—the TUK is employed for symmetric encryption operations, such as protecting PIN blocks or card data during transmission.^[11]^[4] A representative example of the key hierarchy is: BDK → IPEK → Future Key 0 → TUK for the first transaction, after which the system advances to the next Future Key and updates the KSN accordingly.^[13] TDEA and AES variants of DUKPT differ in key handling, with TDEA employing two 64-bit subkeys in each derivation step for compatibility with legacy DES-based systems, while AES processes keys as a single block for enhanced efficiency and security.^[11]^[12]

Key Derivation Process

The key derivation process in Derived Unique Key Per Transaction (DUKPT) begins with initialization, where the Base Derivation Key (BDK) is securely loaded into the device. The Initial PIN Encryption Key (IPEK) is then derived by encrypting fixed constants using the BDK, incorporating the device identifier extracted from the Key Serial Number (KSN).^[1] This step establishes the starting point for subsequent derivations, ensuring each device has a unique initial key tied to its identity.^[14] For each transaction, a unique working key is derived from the current future key stored in the device's registers, combined with the transaction counter represented by the shifted bits of the KSN. This input is processed through a one-way function, typically involving encryption of concatenated values to produce the per-transaction key.^[1] In the Triple Data Encryption Algorithm (TDEA) variant, the derivation is performed separately for each 64-bit half: the current key encrypts (in ECB mode) the 64-bit KSN value with the counter bits masked according to the 21-bit shift register pattern to produce the new double-length key. The AES variant, introduced in the 2017 standard, adapts this for 128-bit block ciphers and supports key lengths of 128, 192, or 256 bits. It uses AES encryption in ECB mode on a 16-byte derivation data block constructed from the KSN's non-counter bits, fixed constants, and zero-padding, ensuring compatibility with varying key strengths while maintaining the derivation's one-way property.^[14] Following derivation, the state is updated to maintain forward secrecy: the pointer shifts to the next future key in the register, the transaction counter increments, and the used key is discarded immediately after application.^[1] The KSN structure guarantees non-repudiation by uniquely identifying each derivation path, supporting up to $2^{21} - 1 transactions (approximately 2 million) in the TDEA variant or up to $2^{32} - 1 in the AES variant before key exhaustion requires reinitialization. This process, detailed in ANSI X9.24-3:2017, highlights key differences in the AES variant, such as explicit support for longer keys and mode-specific handling not emphasized in prior TDEA-focused specifications.^[14]

System Architecture

Registers

In the DUKPT scheme, backup registers maintain the state for key derivation by storing a precomputed chain of future keys starting from the Initial PIN Encryption Key (IPEK). These consist of 21 future key registers, each holding a 128-bit (double-length) future key for Triple Data Encryption Algorithm (TDEA) operations or a 128-bit future key for Advanced Encryption Standard (AES) variants, with TDEA keys represented using 34 hexadecimal digits to include a longitudinal redundancy check (LRC). The encryption counter, a 21-bit register, tracks the number of used transaction slots, ranging from 0 to $2^{21} - 1, but only values with Hamming weight ≤10 are valid, providing 1,048,576 unique slots, and increments with each key derivation to select the next future key from the chain. Temporary registers support the computational aspects of key derivation during a transaction. The current key pointer, approximately 4 hexadecimal digits in length, indicates the index of the active future key within the backup registers. The shift register, 21 bits wide, holds and shifts the bits of the encryption counter to form the input for the derivation process. For TDEA, two crypto registers—each 16 hexadecimal digits (64 bits)—store intermediate results from the left and right halves of the double-length key during encryption operations, while the key register, 32 hexadecimal digits (128 bits), assembles the final derived transaction key. Following a transaction, the update process ensures forward security by copying the next future key into the current key pointer position, incrementing the encryption counter, and regenerating the chain of future keys from the new base key if the counter reaches a point requiring replenishment; this regeneration is non-reversible to prevent backward derivation of prior keys. In AES adaptations of DUKPT, the registers are scaled to accommodate 128-bit blocks and keys while preserving compatibility, with the 21-bit encryption counter remaining unchanged to align with the original TDEA design's transaction capacity.

Key Serial Number

The Key Serial Number (KSN) is an 80-bit (10-byte) value that functions as a nonce in the Derived Unique Key Per Transaction (DUKPT) scheme, enabling the derivation of unique keys for each transaction without the need to transmit base keys.^[11] It is structured to include identifiers for the base derivation key (BDK) variant, the device, and a transaction counter, with a typical allocation of 24 bits for the BDK variant ID (supporting 16,777,216 possibilities), 19 bits for the device ID (supporting up to 524,288 devices per BDK), and 21 bits for the transaction counter (providing 1,048,576 unique slots, limited to values with Hamming weight ≤10). The remaining 16 bits are fixed, often set to 0xFFFF, ensuring compatibility across implementations.^[11] This bit allocation allows for scalable deployment while limiting exposure.^[11] The KSN is transmitted alongside the encrypted data in each transaction.^[4] On the receiving side, the fixed, registered bits (BDK variant ID and device ID) are used to retrieve the corresponding base key and device registration, deriving a shared base state, while the unregistered counter bits introduce uniqueness to generate the transaction unique key (TUK).^[11] This mechanism ensures both parties can independently compute the same TUK for decryption without exchanging sensitive key material.^[4] The originating device generates the KSN by incrementing the transaction counter portion after each use, guaranteeing non-repeating values over the device's operational lifetime.^[15] The counter starts from zero or a low value and rolls over only after exhausting its range, at which point the device may require key reinitialization.^[16] From a security perspective, the KSN design obscures the internal counter progression to thwart prediction attacks, as only the current value is exposed per transaction.^[15] Disclosure of a complete KSN reveals at most the 21 bits of the current derivation state but provides no insight into the base keys or future states, maintaining forward and backward secrecy.^[11] In variants using the Advanced Encryption Standard (AES) for DUKPT, the KSN retains the same 10-byte format as the Triple Data Encryption Algorithm (TDEA) version to support backward compatibility with existing systems.^[16] While AES implementations may extend to 12 bytes for larger counters and identifiers in modern setups, the legacy 10-byte structure is preserved for interoperability.^[16] Furthermore, PCI Point-to-Point Encryption (P2PE) standards incorporate optional extensions, such as DUKPT Update Keys, to prolong device lifetimes beyond the standard counter limits without full reinitialization.^[17]

Transaction Handling

Origination

In the origination phase of a Derived Unique Key Per Transaction (DUKPT) scheme, the sending device, such as a point-of-sale (POS) terminal or PIN entry device, generates a unique encryption key for protecting sensitive transaction data before transmission. This process begins when the device receives the transaction data, typically including a PIN entered by the user, formatted into a standard PIN block according to ANSI X9.8.^[18] To prepare for encryption, the device increments the transaction counter within its current Key Serial Number (KSN), which consists of a fixed device identifier and a 21-bit counter, resulting in an 80-bit or 10-byte KSN for Triple Data Encryption Algorithm (TDEA)-based DUKPT. The device then derives a transaction unique key (TUK), also known as a working key or session key, from the base derivation key (BDK) and the updated KSN using the key derivation function specified in ANSI X9.24. For TDEA-DUKPT, the derived key operates in two-key 3DES mode to encrypt the PIN block, ensuring compatibility with legacy systems. In AES-DUKPT variants, a 128-bit key is derived and applied in Electronic Codebook (ECB) mode for encryption, as outlined in ANSI X9.24-3.^[19]^[16] The encrypted PIN block (ciphertext) is then transmitted along with the current KSN to the receiving party, enabling independent key derivation on the receiver side without key exchange. Following transmission, the sending device updates its local state by further incrementing the transaction counter and shifting internal registers to advance the derivation state, preparing for the next transaction while erasing the current TUK to prevent reuse.^[18]^[19] Error handling is critical for counter management; if the 21-bit transaction counter reaches its maximum effective value of approximately 1,000,000 transactions, the device halts operations to avoid key reuse, necessitating BDK rotation or device replacement, though this is rare given typical device lifetimes.^[20]^[21]

Receiving

In the receiving process, the acquirer host or payment processor receives the encrypted transaction data, such as a PIN block, accompanied by the Key Serial Number (KSN). The KSN's device identifier and registration bits enable the system to locate the appropriate Base Derivation Key (BDK) from its secure key registers. Using the BDK and the initial portion of the KSN, the receiver derives the Initial PIN Encryption Key (IPEK) for the specific device if not previously cached. The transaction counter within the KSN then guides the derivation of the exact Transaction Unique Key (TUK) by applying the key derivation function iteratively from the IPEK. This TUK is subsequently used to decrypt the ciphertext, recovering the original data.^[3]^[18] State advancement occurs post-decryption to maintain synchronization between sender and receiver. The receiver maintains a record of the last known counter value for the device, derived from prior KSNs. If the incoming counter exceeds this value, the system simulates forward derivations by chaining the non-reversible successor function—typically involving encrypt-decrypt operations—for the incremental steps (up to approximately 1,000,000 iterations in the worst case for TDEA). This ensures the computed TUK matches the sender's without storing all possible future keys, updating the receiver's registers to the new counter upon success. The process verifies the counter is strictly greater than the previous to prevent replay attacks.^[22] Synchronization challenges arise when the receiver lags due to out-of-order transactions or network delays, requiring the full chain of derivations from the last synchronized state. This on-demand computation avoids persistent storage of intermediates for security but demands efficient implementation to handle the workload. In practice, the derivation function's one-way nature ensures forward security, as compromised future keys do not expose past ones. The core logic applies similarly to both Triple Data Encryption Algorithm (TDEA) and Advanced Encryption Standard (AES) variants of DUKPT, as defined in ANSI X9.24 standards. However, AES DUKPT uses complete 128-bit block operations in each derivation step, offering greater computational efficiency for long chains compared to TDEA's reliance on multiple 64-bit DES permutations per step. This makes AES preferable for high-counter scenarios without sacrificing security. In high-volume environments, such as payment processors handling millions of transactions daily, optimization techniques like caching recent key states or precomputing short-term chains reduce redundant derivations for sequential counters, minimizing latency while preserving the scheme's stateless ideal.^[4]

Advanced Features

Session Keys

In the Derived Unique Key Per Transaction (DUKPT) scheme, the term "session key" typically refers to the Transaction Unique Key (TUK), a unique, one-time-use key derived for each transaction. This key is used to encrypt sensitive data, such as PINs or cardholder information, during the transaction session, which may involve multiple related messages (e.g., in EMV-compliant environments for offline authentication or contactless payments).^[4]^[23] The TUK is generated from the Base Derivation Key (BDK) using the Key Serial Number (KSN), ensuring uniqueness per transaction without requiring real-time key exchange. Upon completion of the transaction, the key is discarded to prevent reuse, maintaining DUKPT's core security principles. This approach supports secure multi-packet data exchanges in payment systems, enhancing confidentiality and integrity for fragmented transmissions.^[3] Session keys inherit the one-time-use restriction of the TUK and are not regenerable for cross-session use. In the AES variant of DUKPT (ANSI X9.24-3:2017), session keys can be 256 bits long, offering stronger protection against brute-force attacks compared to legacy 3DES implementations.^[1]

Security Properties

DUKPT provides forward secrecy, ensuring that a compromised Transaction Unique Key (TUK) reveals no information about future keys generated in the derivation chain, as the process employs one-way functions that prevent reversal to subsequent states.^[6] This property stems from the irreversible advancement of the key state using the transaction counter within the Key Serial Number (KSN), protecting ongoing and future transactions even if a single device key is exposed.^[24] Backward secrecy is similarly inherent in DUKPT, as the receiving system only derives keys by advancing forward through the chain based on the increasing transaction counter, rendering past keys irretrievable from current or future states.^[3] The receiver verifies the KSN's counter to ensure it exceeds prior values, discarding any attempt to revert, which safeguards historical transaction data from compromise of later keys.^[20] The scheme resists common attacks through its design, where KSN leakage exposes only the limited 21-bit transaction counter state, constraining attackers to at most 2^21 potential keys per Base Derivation Key (BDK) before rotation is required.^[3] Brute-force attacks on the BDK remain infeasible, requiring 2^128 operations for AES variants due to the key's length and the one-way derivation.^[25] The 3DES variant of DUKPT inherits vulnerabilities from the underlying cipher, including susceptibility to meet-in-the-middle attacks that reduce effective security to approximately 112 bits despite a 168-bit key.^[26] However, the key derivation process mitigates some risks by diversifying usage across the chain, though AES implementations offer stronger resistance with no known practical breaks when using proper initialization vectors.^[5] A single TUK compromise impacts only the associated transaction, as each key is unique and non-reusable, limiting exposure without affecting the BDK or other devices.^[24] With a maximum of 2^21 keys derivable per BDK—corresponding to the 21-bit counter—periodic rotation of the BDK further bounds potential damage from any breach.^[3] In the context of quantum computing, DUKPT's reliance on symmetric ciphers like AES faces reduced resistance via Grover's algorithm, which quadratically accelerates brute-force searches and effectively halves key strength (e.g., AES-128 to 64 bits).^[27] For sustained security, migration to AES-256 or emerging post-quantum symmetric enhancements is recommended to restore equivalent classical strength against such threats.^[28]

Standards and Applications

Governing Standards

The primary standard governing Derived Unique Key Per Transaction (DUKPT) is ANSI X9.24, which specifies symmetric key management techniques for retail financial services.^[29] The 2004 version of ANSI X9.24 incorporates the TDEA-based DUKPT method in Annex A, defining the derivation process for generating unique transaction keys from a base derivation key using the Triple Data Encryption Algorithm (TDEA).^[29] In this specification, TDEA employs a two-key 3DES variant for key derivation and encryption operations, ensuring compatibility with legacy payment systems while maintaining forward and backward compatibility in key generation.^[29] An update to the standard, ANSI X9.24-3-2017, introduces support for AES-based DUKPT, specifying algorithms for AES-128 and AES-256 key lengths to derive unique per-transaction keys from an initial base key. Approved in October 2017 by the Accredited Standards Committee X9 (ASC X9), this part uses Cipher Block Chaining (CBC) mode with a zero initialization vector (IV) for the derivation process, enhancing security against known attacks on shorter-key algorithms. Both TDEA and AES variants include provisions for key check values (KCVs), computed as the first few bytes of an encryption operation on a fixed plaintext (typically zero), to verify key integrity during loading and distribution without exposing the full key. Related standards integrate DUKPT for compliance in payment ecosystems. PCI Data Security Standard (PCI DSS) version 3.2, released in 2016, supports the use of point-to-point encryption (P2PE) solutions, which commonly employ DUKPT to protect cardholder data from the point of capture through decryption. EMVCo Level 1 and Level 2 certifications for payment terminals and software require implementations to comply with ANSI X9.24 key management protocols, including DUKPT where symmetric derivation is applied for PIN and data encryption. As of 2025, PCI P2PE v3.2 and PTS POI v7.0 maintain support for both TDEA and AES variants while prioritizing migration to AES for enhanced security.^[30] Regarding deprecation, the National Institute of Standards and Technology (NIST) has scheduled the sunset of 3DES (TDEA) for encryption operations by the end of 2023, disallowing its use in new or updated systems except for legacy decryption, due to vulnerabilities like Sweet32 attacks.^[31] Consequently, AES-based DUKPT is recommended and increasingly required for new deployments in standards-compliant environments, such as PCI PTS POI modules, following the NIST deprecation of 3DES for encryption after 2023, to align with modern cryptographic strength requirements.

Practical Implementation

In practical deployments of Derived Unique Key Per Transaction (DUKPT), key injection begins during device manufacturing, where the Base Derivation Key (BDK) is securely loaded into the device using a hardware security module (HSM) to minimize exposure of the sensitive key material. This process ensures that the BDK never leaves the protected environment of the HSM, and the Initial PIN Encryption Key (IPEK) is then derived from the BDK and the device's unique Key Serial Number (KSN) either within the HSM or verified on-site post-manufacturing.^[32] Such secure injection is critical for point-of-sale (POS) terminals and automated teller machines (ATMs), where devices are produced in high volumes and must comply with PCI standards from the outset.^[33] The KSN structure, an 80-bit value, typically consists of 24 bits for the Key Set ID, 19 bits for the device ID, 21 bits for the transaction counter, and 16 bits reserved, often represented in 10 hexadecimal digits.^[11] This configuration supports up to approximately 16 million BDKs, 500,000 devices per BDK, and 2 million transactions per device before exhaustion, allowing for billions of secure operations across large networks without immediate rekeying.^[11] Upon reaching key exhaustion—when the transaction counter in the KSN is fully utilized—devices enter a lifecycle phase requiring physical or remote re-injection of a new IPEK, often coordinated through certified key loading equipment to maintain uninterrupted service.^[34] Integration of DUKPT occurs directly within POS and ATM firmware, where the sending device derives a unique transaction key from its IPEK and increments the KSN counter for each operation.^[24] On the receiving end, HSMs such as those from Thales or Futurex perform key derivation and decryption by processing the provided KSN against the shared BDK, ensuring synchronization without storing intermediate keys.^[35] These HSMs handle advancement of the key state securely, supporting high-volume transaction processing in acquiring environments.^[36] Deployment challenges include computational overhead on receiving HSMs when handling large lags in KSN counters, as the derivation process requires simulating the key evolution path, which can involve multiple cryptographic operations per transaction.^[34] Additionally, migrating from Triple DES (3DES) to Advanced Encryption Standard (AES) DUKPT necessitates firmware updates across device fleets, involving compatibility testing, phased rollouts, and re-certification to avoid disrupting legacy systems.^[5]^[37] Beyond PIN encryption, DUKPT extends to point-to-point encryption (P2PE) for protecting cardholder data such as primary account numbers (PANs) and supports EMV contactless transactions by deriving unique keys for each interaction.^[38] Terminals from manufacturers like Verifone and MagTek integrate DUKPT in their P2PE-validated solutions, enabling secure data flow from reader to processor while reducing PCI compliance scope.^[39]^[40]

References

[1]
ANSI X9.24-3-2017 - Retail Financial Services Symmetric Key Management - Part 3: Derived Unique Key Per Transaction
### Summary of ANSI X9.24-3-2017 on DUKPT
[2]
X9.24 Part 3 - Test Vectors - Accredited Standards Committee X9
AES DUKPT is used to derive transaction key(s) from an initial terminal DUKPT key based on the transaction number. Keys that can be derived include symmetric ...
[3]
Deriving an ANS X9.24 DUKPT key - IBM
The ANS X9.24 algorithm uses a derivation key and the current-key serial number (CKSN) as inputs. The calculation method consists of the following steps.<|control11|><|separator|>
[4]
Derived Unique Key Per Transaction (DUKPT) - Futurex
Derived Unique Key Per Transaction (DUKPT) is a type of encryption key management used for PIN encryption and safeguarding cardholder data.
[5]
[PDF] The Critical Path from 3DES/TDEA DUKPT to AES DUKPT Encryption
(Reference: ANSI X9.24-3) The AES DUKPT standards provide a pathway to improved security features that are significantly stronger and more resistant to brute- ...<|control11|><|separator|>
[6]
A Forward-Secure Symmetric-Key Derivation Protocol - ResearchGate
Aug 7, 2025 · In this article, we study an interesting and very practical key management problem. A server shares a symmetric key with a client, ...
[7]
"Key" to Secure Data - P2PE - Derived Unique Key Per Transaction ...
Nov 30, 2015 · DUKPT means Derived Unique Key Per Transaction and means that every transaction is protected using a different encryption key such that ...Missing: forward | Show results with:forward
[8]
[PDF] MagneSafe Encryption and Decryption - MagTek
Dec 10, 2014 · DUKPT is specified in ANSI X9.24 part 1. • DUKPT allows the processing of the encryption to be moved away from the devices that hold the shared.
[9]
[PDF] Verifone Makes History with Payment Industry's First AES DUKPT ...
Apr 17, 2018 · Co-designed by Verifone, AES DUKPT is a new security key management standard that was approved as an American national standard in October ...Missing: properties backward
[10]
Insights from the 2025 PCI Security Standards Council Meeting | UHY
Nov 3, 2025 · PCI DSS 4.0 shifts compliance toward continuous, risk-based security management. ... This accelerates cryptographic deprecation across the ...
[11]
Industry terminology - AWS Payment Cryptography
It uses a CVK key. DUKPT. Derived Unique Key Per Transaction (DUKPT) is a key management standard typically used to define the use of one-time use encryption ...
[12]
AES-DUKPT allowed derived working key sizes - IBM
ANSI X9.24 specifies that working keys shall be the same strength or weaker than the key from which they are derived. The following table shows allowed ...
[13]
None
### Summary of DUKPT Key Types, Sizes, Hierarchy, BDK, IPEK, Future Keys, TUK, TDEA vs AES
[14]
[PDF] Supplement to ANSI X9.24-3-2017 Test Vectors
This supplement provides test vectors for validating the AES DUKPT algorithm, used to derive transaction keys, and includes internal calculation traces.Missing: 1990s | Show results with:1990s
[15]
What is transaction capacity of a POS using 3DES DUKPT?
Apr 22, 2016 · In practice usually only 64 bits is used, and it is divided 6-5-5, giving 16 million key sets, 500k devices per key set, and 1 million ...
[16]
Understanding Key Serial Numbers (KSN) in Derived Unique Key ...
Jul 1, 2015 · Understanding Key Serial Numbers (KSN) in Derived Unique Key Per Transaction (DUKPT) · KSNs are 8 - 10 bytes long. · KSNs have 3 components: a 21 ...Missing: TDEA formula
[17]
Encryption and MAC'ing - Overview
AES DUKPT (Derived Unique Key Per Transaction) ECB algorithm, as specified in ANSI X9.24-3-2017 Annex A, With key length of 128 bits. Not supported yet: This ...
[18]
[PDF] PCI-P2PE-v3_1-Standard.pdf
Sep 1, 2021 · This document, Point-to-Point Encryption: Security Requirements and Testing Procedures, defines both security requirements and testing.Missing: endorsement | Show results with:endorsement
[19]
None
### Summary of DUKPT Key Derivation Process
[20]
Unique Key Derive (CSNBUKD and CSNEUKD) - IBM
The DUKPT key derivation process that is defined in the ANSI X9.24 standard describes the use of the derived keys in terms of a terminal, which sends requests, ...Missing: origination | Show results with:origination
[21]
DUKPT - how does the receiver verify the transaction counter?
Jul 5, 2011 · In the chapter "Method: DUKPT (Derived Unique Key Per Transaction)", page 41, it says, that the receiver should verify that the originator's ...Missing: TDEA | Show results with:TDEA
[22]
Questions about future and session key generation in DUKPT process
Nov 22, 2017 · IPEK is injected to device and 21 future keys are generated; first future key + KSN is used to encrypt 1th transaction and KSN was increased. do ...What is transaction capacity of a POS using 3DES DUKPT?DUKPT MAC Variant key [closed] - Cryptography Stack ExchangeMore results from crypto.stackexchange.comMissing: precomputed | Show results with:precomputed
[23]
https://arthurvandermerwe.com/2015/05/30/dukpt-explained-with-examples/
[24]
How Does DUKPT Work Within a Point of Sale Environment? - Futurex
POS devices safeguard card data using an encryption key generation method called DUKPT, or Derived unique key per transaction. Here's how it works.Missing: origination | Show results with:origination
[25]
Cryptographic Calculator – Payments menu - EFTlab
DUKPT MAC screen takes BDK, KSN and Data fields and outputs ANSI X9.24-2004 MAC with filling option 1. All input fields are expected to be in a hexadecimal ...
[26]
Can DUKPT BDK be 192 bits? - Information Security Stack Exchange
Jun 4, 2015 · Some implementations of triple-DES aka TDEA aka DESede (possibly including yours) require you always represent the key in full-length 192-bit or 24-octet form.Are there any DUKPT / AES standards or recommendations?What is the point to the IPEK in DUKPT?More results from security.stackexchange.comMissing: IPEK | Show results with:IPEK
[27]
Understanding Shor's and Grover's Algorithms | Fortinet
Learn how Shor's and Grover's algorithms can break RSA and ECC and explore emerging quantum-resistant security solutions. 2025 THREAT LANDSCAPE REPORT · FL.Missing: DUKPT | Show results with:DUKPT
[28]
[PDF] On the practical cost of Grover for AES key recovery
Mar 22, 2024 · In most cases, the best-known quantum key recovery attack uses Grover's algorithm [14] which provides a generic square-root speed-up over ...
[29]
ANSI Webstore Error
**Summary of ANSI X9.24-1:2004 Content**
[30]
[PDF] Transitioning the Use of Cryptographic Algorithms and Key Lengths
Mar 2, 2019 · After December 31, 2023, three-key TDEA is disallowed for encryption unless specifically allowed by other NIST guidance. Decryption using three- ...
[31]
KeyBRIDGE POI - Utimaco
KeyBRIDGE POI provides a complete key injection solution consisting of an HSM and an integrated central key storage platform. The PCI-certified HSM, based on ...<|separator|>
[32]
System and method for securing a base derivation key for use in ...
Jun 16, 2009 · A system that secures a Base Derivation Key (BDK) in a facility for injecting Derived Unique Key Per Transaction (DUKPT) devices uses software for securing the ...Missing: allocation scale
[33]
[PDF] Reducing HSM Reliance in Payments through Proxy Re-Encryption
Jan 25, 2021 · The update or migration of any large-scale system is always a challenging task. Within the financial industry this is no different with many ...
[34]
CKM_DES2_DUKPT_MAC - Thales Docs
Sep 25, 2025 · The CKM_DES2_DUKPT family of key derive mechanisms create keys used to protect EFTPOS terminal sessions. The mechanisms implement the algorithm ...
[35]
Acquiring - HSM Integration Guides
Acquiring focuses on the steps carried out between merchants and banks for processing credit and debit transactions, either through traditional card-based ...Missing: Thales | Show results with:Thales
[36]
The AES Dilemma: Why Payments Security Faces Growing Pains
DUKPT (Derived Unique Key Per Transaction) is widely used in payment transactions because it provides a dynamic and secure method for key management. Every ...Missing: TDEA | Show results with:TDEA
[37]
[PDF] Case Studies Point-to-Point Encryption - Conexxus
Nov 1, 2021 · The solution is not currently a. PCI-validated P2PE solution, but a PCI validate-able AES DUKPT P2PE solution is planned in a later phase.
[38]
Point to Point Encryption (P2PE) - Verifone
We deliver advance P2PE security solutions to retailers across Europe, which protect payments in any environment – including self-service kiosks.Missing: DUKPT EMV MagTek
[39]
DynaPro Go - Mobile PIN Entry Device with secure magstripe, EMV ...
Industry standard 3DES encryption, DUKPT key management, and the MagneSafe® Security Architecture make it more secure than PCI requires.Missing: beyond Verifone