Payment cryptography workflows built on CyberChef. See exactly what's happening at every step — share a recipe link, inspect intermediate values, and validate without an HSM.
A workflow library for payment cryptography built on CyberChef. Every operation is a step in a pipeline you can inspect, share as a URL, and run entirely in a browser without cloud accounts or hardware.
Covers EMV (ARQC/ARPC, issuer-script MAC, PIN change), PIN blocks (formats, encrypted translation, IBM 3624, VISA PVV), MAC (AES-CMAC, ISO 9797, DUKPT, AS2805), DUKPT key derivation (TDES and AES), card validation data (CVV/CVV2/iCVV), key management, TR-31/TR-34 parsing, and HSM command inspection for Thales payShield and Futurex Excrypt.
Software emulation, not a replacement for an HSM. Operations use clear keys in a browser. Do not use with production keys, real PANs, or live PIN blocks.
cyberchef.jacobmarks.com — all payment operations are under the Payments category. Click any recipe link in this document to open it directly.
The operations are implemented in J8k3/CyberChef. Run the live tool above or self-host with Docker.
📸 CyberChef UI with Payments category expanded, showing operation groups
Many payment HSMs and cloud services expose overlapping cryptographic primitives. The differentiator in integration, migration, and debugging work is visibility into the pipeline.
CyberChef's recipe model is well-suited to payment cryptography because operations chain — you can see the CDOL1 preimage before computing an ARQC, the decrypted PIN block before re-keying it, the exact MAC input before generating a MAC. You can share a recipe URL with a vendor that opens the same operation with the same parameters pre-filled. You can compare an implementation against an inspectable software reference without a second HSM.
CyberChef's breakpoint feature lets you pause between steps and inspect what the data looks like at each stage. For debugging a MAC mismatch or verifying an ARQC implementation before going to the scheme, that's the useful property — not the algorithm itself.
ARQC / ARPC — Transaction Cryptogram Workflows
EMV transaction authentication. Assemble the CDOL1 preimage from named fields, generate or verify the ARQC using the derived session key, then generate the issuer ARPC response.
| Recipe | Link |
|---|---|
| Generate ARQC | open → |
| Generate then verify ARQC (full chain) | open → |
| Generate ARPC issuer response | open → |
Operations: EMV Build ARQC Data, EMV Parse ARQC Data, EMV Generate ARQC, EMV Verify ARQC, EMV Generate ARPC, EMV Build ARPC Data, EMV Parse ARPC Data, EMV Parse TLV
Notes:
- CDOL1 structure is network-agnostic — the same 10-field 33-byte layout applies across Visa, Mastercard, Amex, Discover, and JCB
- ARPC supports Method 1 (Visa/Amex/Discover) and Method 2 (Mastercard) — select the correct method in the args
EMV Parse TLVdecodes BER-TLV encoded EMV data (DE 55, ICC responses, GPO responses)- APC cross-validation note:
verify_auth_request_cryptogramrequires AES-256 E0 keys; AES-128 is rejected by the service - The generate+verify and ARPC recipes use CyberChef's
Registeroperation to capture the generated key as$R0. It can then be referenced by name in downstream operation args — the same random key flows through generate and verify without being hardcoded. The ARPC recipe captures the ARQC output as$R1and passes it intoEMV Build ARPC Datathe same way.
📸 CDOL1 assembly → ARQC generation → ARQC verification, showing each step's output
Issuer-Script MAC and PIN Change
Build issuer-script APDUs, compute the session MAC, and prepare PIN change commands.
| Recipe | Link |
|---|---|
| Generate issuer-script MAC | open → |
| Verify issuer-script MAC | open → |
Operations: EMV Build Script Data, EMV Build PIN Change Script Data, EMV Generate MAC, EMV Verify MAC, EMV Generate MAC (PIN Change)
Notes:
- Padding method selector: Method 2 (ISO 7816-4, default for EMV issuer scripts) vs Method 1 (zero-pad only, required by some host implementations). Both sides of a generate/verify pair must use the same method.
- PIN change flow:
EMV Build PIN Change Script Dataassembles the 5-byte84 24 P1 P2 Lcheader; the encrypted PIN block is appended byEMV Generate MAC (PIN Change)before computing the MAC
PIN Block Formats — Build, Parse, Translate
| Recipe | Link |
|---|---|
| Build ISO Format 0 then parse (full chain) | open → |
| Re-key encrypted PIN block between ZPKs | open → |
| Re-key with JSON inspection output | open → |
Operations: PIN Block Build, PIN Block Parse, PIN Block Translate, PIN Block Translate Encrypted, PIN Data Generate, PIN Data Verify
PIN Block Translate Encrypted is the acquirer's core PIN routing operation: decrypt an encrypted PIN block under an incoming zone key (ZPK/PEK), optionally change format, and re-encrypt under an outgoing zone key.
Supported formats: ISO 9564 Format 0, Format 1, Format 3. PIN Block Translate Encrypted uses TDES-ECB; accepts 2-key (16-byte) or 3-key (24-byte) keys.
📸 Encrypted PIN block re-keying between ZPKs with JSON inspection output showing decrypt → translate → re-encrypt
PIN Verification — IBM 3624 and VISA PVV
Issuer-side PIN verification artifact generation and verification.
| Recipe | Link |
|---|---|
| VISA PVV: generate from clear PIN | open → |
| VISA PVV: generate then verify (full chain) | open → |
| IBM 3624: generate PIN offset | open → |
| IBM 3624: generate then verify (full chain) | open → |
Operations: PIN IBM 3624 Offset Generate, PIN IBM 3624 Verify, VISA PVV Generate, VISA PVV Verify
Message Authentication — AES-CMAC, ISO 9797, HMAC, DUKPT, AS2805
| Recipe | Link |
|---|---|
| Generate AES-CMAC | open → |
| Verify AES-CMAC | open → |
Operations: MAC Generate, MAC Verify
Supported algorithms: HMAC-SHA-224/256/384/512, AES-CMAC, TDES-CMAC, ISO 9797-1 Algorithm 1, ISO 9797-1 Algorithm 3, AS2805-4.1, DUKPT MAC Request CMAC, DUKPT MAC Response CMAC, DUKPT ISO 9797-1 Alg 1, DUKPT ISO 9797-1 Alg 3.
Note: ISO 9797-1 Algorithm 3 is Retail MAC (TDES outer CBC). DUKPT MAC methods expect a clear BDK plus full KSN. EMV MAC operations are in the EMV section above.
Derived Unique Key Per Transaction — TDES and AES
TDES DUKPT
| Recipe | Link |
|---|---|
| TDES DUKPT: derive IPEK from BDK | open → |
| TDES DUKPT: derive PIN session key | open → |
Notes:
- ANSI X9.24-1, 10-byte KSN, IPEK-based. Verified against published X9.24-1 test vector.
- Data encryption variant: CyberChef follows the ANSI X9.24-1 "Data" variant (bytes 5+13 XOR
0xFF). APC uses a different undocumented internal variant for data encryption. DUKPT MAC operations align correctly between the two.
AES DUKPT
| Recipe | Link |
|---|---|
| AES DUKPT: derive IK from BDK | open → |
| AES DUKPT: derive working key — PIN encryption | open → |
| AES DUKPT: derive working key — MAC generation | open → |
Notes:
- ANSI X9.24-3, 12-byte KSN, IK-based, AES-128. Verified against official X9.24-3 §6.3 test vectors.
- JSON output shows the full BDK → IK → transaction key → working key derivation chain.
- AES-192/256 not yet implemented.
Operations: DUKPT Derive TDES Key, DUKPT Derive AES Key
📸 TDES DUKPT key derivation showing BDK → IK → transaction key → working key chain in JSON output
CVV, CVV2, iCVV, PAN
| Recipe | Link |
|---|---|
| Generate CVV2 | open → |
| Verify CVV2 | open → |
| PAN Generate: Visa curated test card | open → |
| PAN Parse: classify by network | open → |
Operations: Card Validation Data Generate, Card Validation Data Verify, PAN Generate, PAN Parse
CVV2 forces service code 000. iCVV forces service code 999. CVV/CVC uses the service code you supply. PAN Parse outputs card type, confidence, major industry identifier, Luhn validity, and network.
Recommended chain for card test setup: PAN Generate → PAN Parse → Card Validation Data Generate
Key Generation, KCV, Component Handling, ECDH, TR-31/TR-34
| Recipe | Link |
|---|---|
| Generate key and compute AES-CMAC KCV | open → |
| TR-31 key block: parse and inspect | open → |
Operations: Key Generate, Payment Calculate KCV, Key Component Split, Key Component Combine, Derive ECDH Key Material, AS2805 Generate KEK Validation, TR-31 Parse Key Block, TR-34 Parse Key Transport
Notes:
Key Component Split/Key Component Combineuse XOR shares — all N components required to reconstruct the key (no threshold/Shamir scheme). For test use; production key ceremonies require a certified HSM.TR-31 Parse Key Blockdecodes all X9.143 header fields with descriptions and PCI compliance flags.TR-34 Parse Key Transporthandles B0–B9 message types, error codes, and peeks at the outer ASN.1 SEQUENCE of the CMS envelope.- ECDH chain:
Derive ECDH Key Material→ optional KDF →AES Key Wrap/AES Key Unwrap. Not a full TR-34 or APCTranslateKeyMaterialimplementation by itself.
Thales payShield and Futurex Excrypt Triage
| Recipe | Link |
|---|---|
| Parse Thales payShield command | open → |
| Parse Futurex Excrypt command | open → |
Operations: HSM Parse Thales Command, HSM Parse Futurex Command
These focus on transport-syntax triage: command identification, header/trailer, delimiter splitting, tag/value structure. Use them to confirm what command family you are looking at before reaching for the semantic payment or EMV operations. Pair with the APC MCP Server for deeper analysis and APC migration mapping.
Coverage: Thales payShield 10K (two-char command codes, configured header length), Futurex Excrypt Enterprise SSP v.2 (bracket-delimited tag/value, AO field as command code).
📸 Raw payShield host message parsed into header, command code, and field split
Full-flow recipes combining multiple operations. Open any link to see the live chain.
| Workflow | Operations | Link |
|---|---|---|
| Brand test card setup | PAN Generate → PAN Parse |
open → |
| EMV ARQC → ARPC end-to-end | Key Generate → EMV Build ARQC Data → EMV Generate ARQC → EMV Build ARPC Data → EMV Generate ARPC |
open → |
| EMV issuer-script MAC | Key Generate → EMV Build Script Data → EMV Generate MAC |
open → |
| Encrypted PIN re-keying between ZPKs | PIN Block Translate Encrypted with JSON inspection |
open → |
| TDES DUKPT: BDK → IPEK → session key | Key Generate → DUKPT Derive TDES Key (IPEK) → DUKPT Derive TDES Key (session key) |
open → |
| AES DUKPT: BDK → IK → working key | Key Generate → DUKPT Derive AES Key |
open → |
| IBM 3624 offset generate → verify | PIN IBM 3624 Offset Generate → PIN IBM 3624 Verify |
open → |
| VISA PVV generate → verify | VISA PVV Generate → VISA PVV Verify |
open → |
| Key generate → KCV cross-check | Key Generate → Payment Calculate KCV |
open → |
| HSM command triage → payment analysis | HSM Parse Thales Command → appropriate payment operation |
open → |
Most payment operations expose a JSON output toggle (last arg). The behavior is consistent by design:
json=false(default): Raw hex output — suitable for piping into a downstream operation viaRegister+$R0.json=true: Structured JSON — suitable for inspection, debugging, and cross-validation. Shows inputs, intermediate values, and the final result.
Generate operations default to json=false so their output can feed directly into a verify step without extraction. Verify operations default to json=true because the terminal result is a "valid": true/false decision that needs context.
DUKPT derive operations in json=true mode show the full derivation chain: KSN, BDK/IK input, IPEK/IK, intermediate keys, and the final derived key.
HSM-style operations were compared against AWS Payment Cryptography (APC) where APC exposed comparable behavior, using fixed test vectors imported as APC managed keys (2026-05-19).
Why APC: APC is a managed cloud HSM service — no physical hardware required, API-accessible, and inexpensive for low-volume test calls. It made structured cross-validation practical without needing a payShield or Futurex in the loop. Where APC behavior differed from CyberChef, the difference is documented below, not silently papered over.
How testing was run: A fixed set of known test vectors (keys, PANs, PINs, plaintexts — documented in the implementation repo's PAYMENT_RECIPES.md) was imported into APC as managed keys. CyberChef operations were run with matching inputs and the outputs were compared directly against APC API responses. Testing used the APC MCP server (apc-agent) to drive API calls interactively, with results recorded here. No automation script; this was a structured manual comparison run in a single session.
| Operation | Status | Notes |
|---|---|---|
| Payment Encrypt / Decrypt (TDES ECB) | ✅ Match | |
| MAC Generate / Verify (ISO 9797-3 Alg 1) | ✅ Match | |
| MAC Generate / Verify (AES-CMAC) | ✅ Match | |
| Card Validation Data (CVV / CVV2) | ✅ Match | |
| VISA PVV Generate / Verify | ✅ Match | APC generate_pin_data blocked by compliance warning; cross-validated via verify_pin_data |
| IBM 3624 Offset Generate / Verify | ✅ Match | Cross-validated via APC verify_pin_data |
| DUKPT TDES Key Derivation | ✅ Verified | Matches published ANSI X9.24-1 test vector |
| DUKPT AES Key Derivation | ✅ Verified | Verified against ANSI X9.24-3 §6.3 official test vectors |
| DUKPT TDES MAC | ✅ Match | APC DukptKeyVariant=REQUEST aligns with CyberChef "MAC Request" |
| EMV Generate MAC | Method 2 (default, EMV standard) differs from Method 1 (zero-pad, APC default). Select the matching method on both sides. | |
| EMV Generate ARQC | ❌ Blocked by APC constraint | APC verify_auth_request_cryptogram requires AES-256 E0; AES-128 rejected. CyberChef AES-CMAC + Option A session-key derivation is standard-compliant. |
| DUKPT TDES Data Encryption | ❌ Variant mismatch | CyberChef: ANSI X9.24-1 "Data" variant. APC uses an undocumented internal variant. MAC operations align correctly. |
| Payment Re-Encrypt | ❌ APC key-mode constraint | D0 keys with NoRestrictions rejected by APC re_encrypt_data. APC constraint, not a CyberChef bug. |
Key findings:
- APC
mac_lengthis in nibbles (hex digits), not bytes — pass16to get an 8-byte MAC - EMV MAC padding: both generate and verify must use the same method (Method 1 or Method 2)
- EMV ARQC on APC requires an AES-256 E0 master key
Operations are covered by a unit test suite in the implementation repo:
tests/operations/tests/Payment.mjs
Test vector sources, by priority:
- Published standard — ANSI X9.24-1 (TDES DUKPT), X9.24-3 §6.3 (AES DUKPT), NIST SP 800-38B (CMAC/KCV)
- APC cross-validated — operations where no public standard vector exists; AWS Payment Cryptography used as the reference implementation (see APC Cross-Validation)
- Internal round-trip — encrypt → decrypt or generate → verify, where neither a standard vector nor an APC path is available
Run the suite:
npm test| Operation | Validation class | Primary source |
|---|---|---|
PIN Block Build / Parse / Translate |
Vendor-aligned | AWS GeneratePinData; ISO 9564 |
PIN Block Translate Encrypted |
Vendor-aligned | AWS TranslatePinData; ISO 9564; PCI PIN Req 3-3 |
Key Component Split / Combine |
Verified | XOR key split — standard PCI key ceremony primitive |
Payment Calculate KCV |
Verified | NIST SP 800-38B |
DUKPT Derive TDES Key |
Externally cross-checked | ANSI X9.24-1 |
DUKPT Derive AES Key |
Externally cross-checked | ANSI X9.24-3 §6.3 official test vectors |
Derive ECDH Key Material |
Verified | RFC 3394; AWS TranslateKeyMaterial |
MAC Generate / Verify (HMAC/CMAC) |
Verified | NIST SP 800-38B |
MAC Generate / Verify (ISO9797/DUKPT/AS2805) |
Vendor-aligned | AWS MAC overview |
EMV Build / Parse ARQC Data |
Verified | CDOL1 per EMV Book 3 §10.1 |
EMV Build / Parse ARPC Data |
Verified | EMV Book 2 §8.2 |
EMV Parse TLV |
Verified | ISO 8825-1 BER-TLV; EMV Books 1–4 |
EMV Generate / Verify ARQC |
Vendor-aligned | AWS VerifyAuthRequestCryptogram |
EMV Generate ARPC |
Vendor-aligned | AWS VerifyAuthRequestCryptogram issuer flow |
EMV Generate / Verify MAC |
Vendor-aligned | AWS EMV MAC use case |
Card Validation Data Generate / Verify |
Vendor-aligned | AWS GenerateCardValidationData |
PIN IBM 3624 / VISA PVV |
Vendor-aligned | AWS IBM 3624 / VISA PIN verification objects |
PAN Generate |
Verified (Luhn/public ranges) | Discover public test-card page; Mastercard AVS scenarios |
PAN Parse |
Verified | Public card numbering rules |
TR-31 Parse Key Block |
Test helper | X9.143 header structure |
TR-34 Parse Key Transport |
Test helper | B0–B9 message types; ASN.1 CMS envelope |
HSM Parse Thales / Futurex Command |
Test helper | Thales payShield / Futurex Excrypt command syntax |
Validation classes:
- Verified — backed by a public standard plus deterministic local vectors
- Vendor-aligned — intentionally shaped to AWS Payment Cryptography or scheme/vendor semantics
- Externally cross-checked — checked against known-good vectors; governing spec not public
- Test helper — useful for testing, parsing, or workflow emulation; not a full standards-faithful implementation
This repo is part of a small ecosystem of payment engineering tools:
| Tool | Role |
|---|---|
| J8k3/CyberChef | Implementation — the fork where payment operations live |
| J8k3/aws-payment-cryptography-mcp | Cloud — APC MCP server for AWS Payment Cryptography automation and analysis |
| J8k3/aws-payment-cryptography-hsm-proxy | Migration — protocol translation layer between legacy HSM command sets and APC |
| J8k3/Payments | Knowledge — shared payment standards reference consumed by the tools above |
This is software emulation. There is no key custody, no tamper resistance, and no HSM boundary. It is not a certified HSM, not a PCI-scoped control, and not affiliated with AWS, Thales, Futurex, or any card scheme.
Production payment systems require certified hardware and proper PCI DSS controls. These tools are for development, testing, and debugging.
- EMV Book 2 v4.4 — Issuer cryptography, ARQC/ARPC, secure messaging
- EMV Book 3 v4.4 — Application specification, CDOL1 layout
- ANSI X9.24-1 — TDES DUKPT
- ANSI X9.24-3 — AES DUKPT
- ISO 9564 — PIN management and security
- ISO 9797-1 — MAC algorithms
- ISO 8825-1 — BER-TLV encoding
- X9.143 / TR-31 — Interoperable secure key block
- TR-34 — Asymmetric key distribution
- NIST SP 800-38B — CMAC
- RFC 3394 — AES Key Wrap
- PCI PIN Security Requirements v3.1