Encryption is the last line of defense for stored cardholder data. If every other control fails and an attacker exfiltrates a database full of PANs, strong encryption renders the data worthless. But encryption is only as strong as the key management program that protects the keys. An organization that encrypts PANs with AES-256 but stores the encryption key in the same database row has achieved nothing.
Cryptographic Algorithm Requirements
| Algorithm | PCI DSS Status | Key Length | Use Case |
|---|---|---|---|
| AES (Advanced Encryption Standard) | Accepted — industry standard | 128-bit minimum; 256-bit recommended | Symmetric encryption of stored PANs, data at rest |
| RSA | Accepted with conditions | 2048-bit minimum; 3072-bit recommended | Asymmetric — key exchange, digital signatures |
| ECC (Elliptic Curve Cryptography) | Accepted with conditions | P-256 minimum (256-bit) | Key exchange, digital signatures — TLS, payment tokens |
| HMAC-SHA256 / HMAC-SHA512 | Accepted | 256-bit / 512-bit key | Keyed hashing of PANs for lookup functions |
| SHA-256 / SHA-512 (unkeyed) | Accepted for integrity verification | N/A | NOT sufficient for PAN hashing — brute-forceable |
| 3DES (Triple DES) | Being phased out — not recommended | 112-bit effective | Legacy only; retire from all new implementations |
| DES, RC4, MD5 | Not accepted | N/A | Prohibited in PCI DSS environments |
Key Hierarchy — The Foundation of Key Management
PCI DSS requires a key hierarchy to protect encryption keys. The structure:
- Data Encryption Keys (DEKs): Keys that directly encrypt cardholder data. DEKs must be encrypted under a KEK.
- Key-Encrypting Keys (KEKs): Keys that encrypt DEKs for storage and transport. KEKs must be stored in hardware security (HSM or equivalent).
- Master Keys: Top-level keys that protect KEKs. Must reside in HSM only — never extracted in plaintext.
| KEY IDEA | The requirement to store keys separately from the data they encrypt is not satisfied by simply storing the key in a different database table or a different file on the same server. "Separate storage" means the keys are stored in a system with its own access controls, ideally hardware-based (HSM), that cannot be accessed by the same credentials that access the encrypted data. |
Hardware Security Modules (HSMs)
HSM Types and Selection
HSMs come in three form factors: hardware appliances (Thales Luna, Utimaco, nCipher), cloud HSMs (AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM), and payment HSMs (specifically designed for payment applications — Thales payShield, Utimaco PaymentServer). For Indonesian payment organizations, payment HSMs are relevant for PIN processing and key management in acquiring environments.
| HSM Option | Type | FIPS Level | Best For | Indonesian Availability |
|---|---|---|---|---|
| Thales Luna Network HSM | Hardware appliance | FIPS 140-2 Level 3 | Large on-premise CDEs; high transaction volume | Available through distributors |
| AWS CloudHSM | Cloud HSM service | FIPS 140-2 Level 3 | AWS-hosted CDEs; cloud-native payment platforms | Available in AWS ap-southeast-1 (Singapore) / Jakarta |
| Azure Dedicated HSM | Cloud HSM service | FIPS 140-2 Level 3 | Azure-hosted CDEs | Available in Azure Southeast Asia |
| GCP Cloud HSM | Cloud KMS managed hardware | FIPS 140-2 Level 3 | GCP-hosted CDEs | Available in GCP asia-southeast2 (Jakarta) |
| Thales payShield 10K | Payment HSM | FIPS 140-2 Level 3 / PCI HSM | Acquiring banks, PIN processing, payment gateways | Available through Thales distribution network |
Key Management Lifecycle — Implementation Detail
Key Generation
All cryptographic keys must be generated using a cryptographically secure random number generator. For DEKs and KEKs: generate within the HSM (the HSM's internal RNG provides the highest quality randomness). Document the generation date, algorithm, key length, intended use, and custodian.
Key Distribution
Keys must never be transmitted in plaintext. Use key-wrapping (encrypting a DEK under a KEK before transmission), HSM-to-HSM key injection (for physical HSM setups), or secure API protocols for cloud HSM key operations. Key injection ceremonies for physical HSMs require dual control and split knowledge — the key value is never known to any single individual.
Key Storage
DEKs: stored encrypted under KEKs in the application's key store or HSM. KEKs: stored in HSM only. Master keys: stored in HSM — never extracted. Access to the key store must be restricted to authorized systems and personnel, with all access logged.
Key Rotation
Cryptoperiods define how long a key is used before it must be replaced. PCI DSS requires annual rotation for DEKs (or more frequently based on risk analysis). Implement automated key rotation: generate a new DEK, re-encrypt all PANs under the new DEK, retire the old DEK to archive status, maintain the old DEK for decryption of archived data only.
Key Destruction
When a key is no longer needed (end of cryptoperiod with no archived data, organization offboarding), it must be securely destroyed. For HSM-resident keys: zeroize the key slot (HSM overwrites the key material with zeros). Document key destruction with a destruction certificate recording the key identifier, destruction date, destruction method, and witness.
| IMPORTANT | Key rotation is one of the most commonly deferred key management activities — and one of the most consequential when deferred too long. A key that has encrypted millions of PANs for five years represents a high-value target. If that key is ever compromised, all five years of encrypted data is at risk. Annual rotation limits the exposure window. Build automated key rotation into the cryptographic architecture from the start. |
Key Management Documentation Requirements
QSAs reviewing key management require:
- Key management policy covering all lifecycle stages
- Key inventory listing all active keys, their purpose, algorithm, length, creation date, expiration date, and custodian
- Key generation procedures (step-by-step, referencing HSM)
- Key rotation procedures and rotation schedule
- Dual control and split knowledge procedures for sensitive key operations
- Key destruction procedure and certificates of destruction for retired keys
- HSM configuration documentation (vendor, model, FIPS level, configuration)
| Cloud HSMs (AWS CloudHSM, GCP Cloud HSM, Azure Dedicated HSM) have significantly simplified key management for Indonesian organizations moving to cloud-based payment infrastructure. They provide FIPS 140-2 Level 3 validation without the operational complexity of physical HSM appliances. For Indonesian organizations targeting Jakarta-region cloud deployments, GCP asia-southeast2 and AWS ap-southeast-3 (Jakarta) both offer cloud HSM services. |