EMV, DUKPT and the payment HSM

Mental model

In the previous lesson you saw EMV’s transaction cryptogram (symmetric, no PQC needed) in the group of 6 and EMV 3DS (asymmetric, PQC needed) in the group of 4. This lesson goes deeper into that duality within EMV itself, shows the real mechanism of DUKPT, and adds a third, payments-specific layer (PCI PTS HSM) to the CAVP/CMVP discipline you saw in M9.

EMV’s two layers: the cryptogram (symmetric) versus offline authentication (asymmetric)

Two separate cryptographic mechanisms run in an EMV transaction, and mixing them up is a common mistake. The transaction cryptogram (such as the ARQC, an authorization request, or the TC, transaction completion) is produced by deriving a transaction-specific session key from the card’s own master key; it is entirely symmetric and conceptually similar to DUKPT (deriving a transaction-specific key from a card-specific key). A separate feature, Offline Data Authentication (ODA) (SDA, DDA, CDA), lets the terminal authenticate the card offline (without contacting the issuer); this is asymmetric: EMV historically used RSA (1024/2048 bit), and DEPLOYED2022-01-01 since the EMV Contact Chip v4.4 and Contactless Kernel specifications it also supports ECC (such as P-256). The PQC transition affects the second mechanism (ODA), not the first (the transaction cryptogram). When answering an architect’s question “are our EMV cards secure”, make clear which mechanism you are talking about.

DUKPT: BDK, KSN and a per-transaction key

DUKPT (Derived Unique Key Per Transaction) is a symmetric key management scheme defined by ANSI X9.24. During production, a POS terminal is loaded with an initial key derived from a BDK (Base Derivation Key, a master key held centrally in an HSM) and a KSN (Key Serial Number: device identity + a counter). In each transaction the terminal uses the KSN’s current value to derive, with a function ANSI X9.24 defines, a single-use working key specific to that transaction; the key is discarded when the transaction ends, the KSN’s counter advances for the next transaction, and a new key is derived. This mechanism is symmetric from start to finish (AES or TDES); there is no asymmetric operation at any point, so, as you saw in the previous lesson, it is structurally not affected by PQC.

The payment HSM: a layer beyond the general-purpose HSM

In M9 you saw the distinction between CAVP (algorithm validation) and CMVP (module validation, FIPS 140-3). In the payments world a third layer is added: PCI PTS HSM (the PCI Security Standards Council’s own HSM certification), covering payments-specific functions such as PIN processing, card verification, card production and ATM interconnection. A payment HSM (for example Thales’s payShield family) usually carries both FIPS 140-3 (general-purpose module validation) and PCI PTS HSM (payments-specific validation) certificates; these are separate processes on separate timelines. When verifying a bank’s claim that “our payment HSM supports PQC”, apply M9’s CAVP/CMVP discipline here too, with one more layer: check separately whether both the FIPS 140-3 and the PCI PTS HSM certificates, and both the CAVP and CMVP stages, really cover PQC algorithms.