HSM Architecture of AWS Payment Cryptography - A Deep Dive into PCI DSS Compliant Payment Encryption
AWS Payment Cryptography is a managed HSM service purpose-built for the payment industry, providing PCI DSS compliant encryption and tokenization in a serverless model. This article takes a deep dive into the technical mechanisms of payment encryption, including PIN block generation, DUKPT key management, and how it differs from CloudHSM.
Why the Payment Industry Needs Managed HSMs
Cryptographic processing for credit card payments requires physical security modules known as PCI PTS HSMs. Traditionally, payment processors deployed dedicated HSMs on-premises, bearing annual operational costs in the tens of millions of yen. The operational burden is extremely high, encompassing HSM firmware updates, key rotation, and physical access controls. AWS Payment Cryptography was designed to eliminate these challenges, providing a managed HSM infrastructure that meets PCI DSS Level 1 and PCI PIN Security requirements. Users simply call APIs to perform payment-specific cryptographic operations such as encrypting card numbers (PANs), generating and verifying PIN blocks, and computing MACs (Message Authentication Codes). Because the entire HSM lifecycle from procurement to decommissioning is no longer required, the biggest barrier to migrating payment systems to the cloud is removed. Pricing is pay-per-use based on API calls, starting at $1.00 per month per active key and $1.00 per 10,000 cryptographic operations.
The Cryptographic Mechanics of PIN Block Generation and Verification
PINs entered at ATMs and card terminals are never transmitted in plaintext. A PIN is converted into a format called a PIN block and travels across the network in encrypted form. Among the PIN block formats defined in ISO 9564, Payment Cryptography supports Format 0 (ISO-0), Format 1 (ISO-1), Format 3 (ISO-3), and Format 4 (ISO-4). Format 0 combines the PIN and PAN using an XOR operation and is the most widely adopted. Format 4, on the other hand, is the latest format designed for AES encryption and is seeing increasing adoption as 3DES is phased out. The TranslatePinData API in Payment Cryptography enables secure server-side conversion between different formats. PIN verification uses the VerifyPinData API, where decryption and comparison are completed entirely within the HSM, eliminating the risk of plaintext PINs being exposed in memory. Latency for a single API call is typically under 50 milliseconds, comfortably meeting the requirements of real-time payment processing.
How DUKPT Key Management Underpins Terminal Security
DUKPT (Derived Unique Key Per Transaction) is a key management scheme that derives a unique cryptographic key for each transaction on a per-terminal basis. Only an initial key (IPEK) derived from a BDK (Base Derivation Key) is injected into the terminal; the BDK itself is never stored on the device. For each transaction, a further derived key is generated from the IPEK, so even if a single key is compromised, past and future transactions remain unaffected. Payment Cryptography completes DUKPT key derivation entirely within the HSM. The CreateKey API generates a BDK, and the DeriveKey API derives per-terminal IPEKs. In addition to 3DES-based DUKPT, AES-256-based DUKPT (ANSI X9.24-3) is also supported, enabling parallel operation during the migration period. A single BDK can generate up to approximately one million derived keys, accommodating large-scale terminal networks. In contrast, Azure Payment HSM requires the application to implement DUKPT key derivation on its own, reflecting a fundamentally different design philosophy from Payment Cryptography, which handles it entirely via API.
Implementation Patterns for Tokenization and Card Data Protection
PCI DSS v4.0 requires that stored card numbers (PANs) be protected through encryption or tokenization. A typical tokenization implementation using Payment Cryptography encrypts the PAN with the EncryptData API and stores the ciphertext as a token in DynamoDB. During payment processing, the DecryptData API decrypts the token and sends the PAN to the payment network. In this approach, the plaintext PAN temporarily exists in the application server's memory, so a design that leverages Lambda execution environments to minimize the memory lifetime is recommended. Available encryption algorithms include AES-256-CBC, AES-256-ECB, and 3DES-CBC, which can be selected based on the requirements of the payment network. Using FPE (Format Preserving Encryption), a 16-digit PAN can be encrypted into another 16-digit numeric string, allowing tokenization to be introduced without modifying existing database schemas. The effect of reducing PCI DSS compliance scope is significant, substantially decreasing the number of system components subject to audit.
Choosing Between CloudHSM and Payment Cryptography - The Line Between General-Purpose and Payment-Specific Encryption
AWS offers two HSM services: CloudHSM and Payment Cryptography. CloudHSM is a general-purpose HSM with FIPS 140-2 Level 3 certification that supports arbitrary cryptographic operations through standard interfaces such as PKCS#11, JCE, and OpenSSL. Payment Cryptography, on the other hand, is a payment-specific HSM with PCI PTS HSM certification that provides APIs dedicated to payment operations, including PIN block handling, DUKPT key derivation, and MAC computation. The selection criteria are clear: choose Payment Cryptography if card encryption or PIN verification is the primary goal, and CloudHSM if the goal is general-purpose encryption such as TLS termination or code signing. There is also a cost difference. CloudHSM is billed hourly per cluster, with a minimum configuration costing approximately $1,500 per month, whereas Payment Cryptography is fully pay-per-use, with one million operations per month costing roughly $100. For processors with low payment volumes, the cost advantage is striking. A hybrid architecture that uses both services, separating payment encryption from general-purpose encryption, is also practical.
Design Guidelines for Production Deployment of Payment Cryptography
For production deployment, the first step is to determine a key import strategy. For migration from existing on-premises HSMs, the TR-34 protocol is recommended. TR-34 is an RSA-based asymmetric key exchange method that ensures keys are never exposed in plaintext during migration. The ImportKey API natively supports TR-34. In terms of availability, the service is automatically redundant within a region, but for multi-region configurations, keys must be imported individually into each region, with failover controlled at the application layer. For auditing, all API calls are recorded in CloudTrail, making compliance with PCI DSS Requirement 10 straightforward. A phased migration approach is practical: verify the accuracy of PIN block translation and MAC verification in a test environment, run in parallel, and then cut over to production. Related books (Amazon) are also a useful reference.