PIN blocks: encrypting a 4-digit number like it's a nuclear launch code

Encrypting "1234" as plain text would leak its length and its digit-only alphabet to anyone who could guess or brute-force short inputs against a known block cipher — a 4-to-12-digit numeric value is an extremely small search space. The payments industry standard (ISO 9564-1) instead packs the PIN into a fixed-width 8-byte structure called a PIN block before any encryption happens, so every PIN — whether 4 digits or 12 — produces a block of the exact same size and shape, and the block's own construction ties it to one specific card.

The most common layout, Format 0 (also called ISO-0), reserves the first nibble for a format control code, the second nibble for the PIN length, the PIN digits themselves, then padding nibbles (0xF) out to 16 hex digits (8 bytes) total.

A PIN block on its own would encrypt identically for every customer who happens to share the same PIN — a real weakness, since short PINs collide often. ISO-0 fixes this by building a second 8-byte block from the customer's own card number (the rightmost 12 digits of the PAN, excluding the check digit, padded with two leading zero nibbles), then XOR-ing the PIN block with this PAN block before encryption. Two customers with an identical PIN now produce completely different ciphertext, because their PANs differ.

ISO-0's fixed 0xF padding is itself a small weakness: an attacker with access to the encryption oracle (not the key) can narrow down candidate PINs faster than pure brute force, because every correct guess produces a block with predictable padding nibbles. Format 3 (ISO-3) closes this by filling the padding nibbles with cryptographically random hex digits instead of a fixed pattern, so no structural property distinguishes a correct guess from an incorrect one before decryption. The PIN field, the PAN XOR step, and the encryption itself are otherwise identical to Format 0 — this is a hardening of the padding, not a different mechanism.

A PIN entered at a merchant's terminal has to travel through an acquirer's network, a card scheme's switch, and finally the issuer's host before it can be verified — and every one of those hops uses its own encryption key (a Zone PIN Key, or ZPK) shared only with its immediate neighbor, never end to end. That means the PIN block has to be decrypted under the incoming link's key and re-encrypted under the outgoing link's key at every single hop, which is the one operation an ordinary server must never be allowed to do in plaintext memory: it's the exact job a payment HSM like a payShield exists for. The HSM decrypts the incoming block, re-encrypts it under the next hop's ZPK, and returns only the new ciphertext — the plaintext PIN exists nowhere but inside the HSM's own protected memory, for microseconds, and is never logged, swapped to disk, or visible to the application calling it.

Even at the issuer, the HSM rarely decrypts the PIN just to compare it against a stored value — storing plaintext PINs anywhere, even encrypted at rest, is exactly what the whole design avoids. Instead, the issuer host holds a PIN Verification Value (PVV) or an IBM 3624 offset computed once, at PIN-set time, from the actual PIN and a PIN Verification Key — a one-way derivation, not an encryption that can be reversed. Verifying a PIN means asking the HSM to compute the same PVV from the just-decrypted PIN block and compare it to the stored value; a match returns a boolean, nothing else leaves the HSM. This is the same underlying idea as password hashing (covered in the key derivation functions module) applied to a 4-digit secret: the host never needs to reconstruct the original PIN to confirm it's correct.