Payment Crypto Network Glossary

A 3DES or AES key shared between two HSMs (e.g. acquirer and network) used solely to encrypt other working keys during key exchange. Never used directly for data. Also called Inter-Zone Key (IZK).

A working key shared between acquirer and issuer (under ZMK protection) used to encrypt PIN blocks as they transit the network. Each ZPK is unique per bilateral relationship.

A working key used to generate or verify MACs on ISO 8583 messages between network participants. Ensures message integrity across zone boundaries.

A working key used for encrypting sensitive data fields (other than PIN) as they travel between network zones. Analogous to ZPK but for general data.

A 3DES key loaded into a POS terminal or ATM (often via TR-31 or out-of-band ceremony) that is used to protect the exchange of working keys between the terminal and its acquirer host.

A working key loaded under TMK protection into a PIN entry device. Used to encrypt the cardholder PIN into a PIN block format (ISO 9564 Format 0, 1, 3, or 4) before transmission.

A working key loaded under TMK protection into a terminal and used to compute MACs on ISO 8583 messages sent to the acquirer host. Ensures request/response integrity.

A generic term for any key whose sole purpose is to encrypt (wrap) another key. ZMK and TMK are both KEKs in context. TR-31 uses the Key Block Protection Key (KBPK) as its KEK.

The specific key used in TR-31 to derive the Key Block Encryption Key (KBEK) and Key Block Authentication Key (KBAK) via a key derivation function. Replaces the raw KEK concept in modern deployments.

A 3DES or AES master key held by the issuer HSM used to derive card-specific Unique Derived Keys (UDK). The IMK never leaves the HSM. Each transaction application (AC, SM, DN) uses a separate IMK.

A per-card key derived from the Issuer Master Key (IMK) using the PAN and PAN Sequence Number via EMV Option A or Option B diversification. Stored on the chip and in the issuer HSM.

A cryptogram generated by the card chip during a transaction using the UDK and transaction data (amount, unpredictable number, ATC, etc.). The issuer verifies it during online authorization to prove the card is genuine.

A cryptogram generated by the issuer HSM in response to an ARQC. The card verifies ARPC to confirm the issuer is genuine (mutual authentication). Calculated per CVN10 or CVN18 depending on card config.

A cryptogram generated by the card chip after the issuer approves, completing the two-way authentication. Stored for offline dispute evidence. Uses the same key derivation as ARQC.

Cryptogram generated by the card when it declines the transaction offline. Proves the card chip made the decline decision, not a rogue terminal.

A 3DES key pair (CVK-A and CVK-B) used to generate and verify CVV/CVC values on the card magnetic stripe and in chip static data. Stored in the issuer HSM.

A 3DES key used to compute and verify the PIN Verification Value (PVV). The issuer stores the PVV on the card or in a database; at authorization the HSM recomputes it from the PVK and PAN to verify the PIN.

The root 3DES or AES key in the DUKPT (ANSI X9.24) scheme. Stored only in the acquirer HSM. Used to derive IPEKs which are injected into terminals — the BDK itself never leaves the HSM.

A terminal-specific key derived from the BDK and the base portion of the KSN. Injected into a PED at manufacture or key injection. The terminal derives all future transaction keys from this IPEK without ever seeing the BDK.

A 10-byte value in DUKPT comprising the Key Set Identifier (KSI, linking to a BDK) and a transaction counter. Sent in the clear with each transaction so the HSM can rederive the correct future key.

A key management scheme (ANSI X9.24) where each transaction uses a unique encryption key derived from IPEK + KSN. Eliminates the risk of reusing a single terminal key; compromise of one key does not expose others.

A symmetric cipher applying DES three times with 2 or 3 independent 56-bit keys (total effective security ~112 bits). The dominant encryption algorithm in legacy payment HSMs. Being replaced by AES in newer deployments.

A symmetric block cipher operating on 128-bit blocks with 128, 192, or 256-bit keys. Successor to 3DES in modern HSMs and EMV. Used in DUKPT AES (ANSI X9.24 Part 3) and AES-CMAC for MACs.

An asymmetric cipher used in payment systems for key transport (TR-34), certificate signing (EMV CA keys), and secure communication. Key sizes of 2048 or 4096 bits are standard; 1024-bit is deprecated.

An asymmetric signature algorithm based on elliptic curve cryptography. Used in contactless EMV (SDA, DDA, CDA) and increasingly in HSM-to-HSM authentication as a compact alternative to RSA.

A short tag appended to a message proving both integrity (not tampered) and authenticity (from the keyed party). Payment MACs use ISO 9797 Algorithms 1, 2, or 3 (Retail MAC) with 3DES, or AES-CMAC.

An AES-based MAC construction (NIST SP 800-38B). Used in DUKPT AES, EMV session key derivation, and ISO 9797 Algorithm 5. Provides stronger security properties than the legacy Retail MAC.

A MAC built on a hash function (SHA-256, SHA-512). Used in API authentication, webhook signatures, and 3DS 2.x message integrity. Not typically used for PIN or key protection (that domain uses cipher-based MACs).

A family of one-way hash functions. SHA-1 (deprecated), SHA-256, and SHA-512 are used in payment: HMAC computation, certificate fingerprinting, and key derivation functions within EMV and TR-31.

An ANSI standard for secure key exchange between HSMs. A key block wraps the key value with a clear-text header (algorithm, usage, mode, exportability) and an authentication MAC — preventing key misuse even if decrypted.

An ANSI standard for distributing symmetric keys between a Key Distribution Host (KDH) and a Key Receiving Device (KRD) using asymmetric RSA. Replaces manual key ceremonies. Uses CMS (PKCS#7) as the token format.

The standard format for public key certificates used to bind an identity to an RSA or ECC public key. Required in TR-34 (to authenticate KDH/KRD), EMV chip data verification (CA, Issuer, ICC certificates), and 3DS 2.x.

The ecosystem of certificate authorities, registration authorities, certificate revocation lists, and policies governing issuance and trust of X.509 certificates. Visa, Mastercard, and Amex each run scheme-level CAs for EMV.

A tamper-evident, FIPS 140-2 Level 3 (or PCI HSM) certified hardware device that generates, stores, and processes cryptographic keys in a physically secure boundary. No key ever exits the HSM in the clear.

The first 3 bytes of encrypting an all-zero block with a symmetric key (using 3DES or AES). Used to verify a key was loaded correctly without revealing the key value. Two parties compare KCVs after a key exchange.

A formatted binary block encoding the cardholder PIN and (for Format 0, 3) the PAN, before encryption. ISO 9564 defines formats 0–4. Format 0 (ANSI) is most common; Format 4 (AES) is the modern equivalent.

A tamper-resistant, PCI PTS-certified hardware device accepting PIN input. PED hardware zeroizes keys on tamper detection. Stores TPK or IPEK for PIN encryption.

A monotonically increasing counter stored on the EMV chip, incremented with every transaction attempt. Included in ARQC computation — prevents replay attacks by making each cryptogram unique.

A 4-byte random number generated by the terminal and included in ARQC computation to provide freshness/liveness guarantee. Prevents pre-computed cryptogram attacks.

The root RSA public key for a payment scheme (Visa, Mastercard, Amex). Distributed to terminals via the scheme and used to verify the Issuer Public Key Certificate on each card. Identified by a 1-byte RID + Index.

The simplest EMV authentication method. The card stores a scheme-signed static data record. The terminal verifies the signature using the CA and Issuer public keys. Vulnerable to cloning (card data can be copied unchanged).

EMV authentication where the card uses its own ICC Private Key to sign dynamic transaction data (including the terminal's Unpredictable Number). Each signature is unique; prevents card cloning used against SDA.

Combines DDA signature and ARQC generation into a single command (GENERATE AC). The signed data includes the cryptogram itself, proving both card authenticity and transaction binding in one step.

The umbrella term for SDA, DDA and CDA. Lets the terminal cryptographically verify the card without going online to the issuer.

How the cardholder is verified during a transaction: offline PIN, online PIN, signature, on-device (CDCVM), or no CVM. The card's CVM List (tag 8E) ranks the methods to try.

The chip embedded in an EMV card. "ICC" is used throughout the EMV specs to mean the chip together with its data and keys.

Tag 82 — a 2-byte bitmap returned in the GPO response stating which functions the card supports: SDA, DDA, CDA, cardholder verification, terminal risk management and issuer authentication.

Tag 95 — a 5-byte bitfield in which the terminal records the outcome of every risk and verification check performed during the transaction.

Tag 9B — a 2-byte bitfield indicating which functions the terminal actually performed (offline data authentication, cardholder verification, risk management, issuer authentication, script processing).

Tag 9F10 — issuer- and application-specific data the card returns with the cryptogram. Its layout depends on the CVN (e.g. Visa CVN10/18, Mastercard M/Chip).

The EMV command that begins transaction processing. The card returns the AIP and the AFL (the list of records the terminal must read).

Tag 97 — a card-supplied list naming the data the terminal must concatenate and hash to build the TC Hash used in the Transaction Certificate.

Tag 9F49 — a card-supplied list naming the data the terminal must pass to the card (typically the Unpredictable Number) for Dynamic Data Authentication.

A legacy contactless mode that reproduces magnetic-stripe track data over the contactless interface instead of performing full EMV chip processing. Being phased out.

Visa's full EMV chip application, used for contact transactions and full-EMV-mode contactless.

Visa's streamlined contactless profile (Tap to Pay). The card returns everything needed to authorise in a single tap, using fDDA for authentication.

The contactless form of DDA used by Visa qVSDC. The card signs dynamic data (including the terminal's Unpredictable Number) in one step during the tap.

Tag 9F66 — a 4-byte bitmap the Visa contactless reader places in the PDOL to tell the card what it supports and requires (MSD/qVSDC, online PIN, CVM, and more).

Tag 9F6C — a 2-byte bitmap the card returns to instruct the terminal on its requirements, e.g. online PIN, signature, or the conditions under which to go online.

Cardholder verification performed on the consumer's own device (phone/watch biometrics or passcode) rather than at the terminal. Used by mobile wallets such as Apple Pay and Google Pay.