PCI DSS and Cryptography

PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements for any organization that stores, processes, or transmits payment card data. Cryptography appears throughout the standard — primarily in Requirement 3 (protect stored data) and Requirement 4 (encrypt data in transit). PCI DSS doesn’t prescribe specific algorithms but mandates “strong cryptography” as defined by industry standards (NIST, ISO), proper key management, and documented procedures. Failing a PCI audit on cryptography requirements can result in fines, increased transaction fees, or loss of card processing ability.

Why it matters

• Mandatory for card processing — any organization handling card data (merchants, processors, service providers) must comply. Non-compliance means fines up to $100,000/month and potential loss of processing privileges.
• TLS configuration is audited — assessors check your TLS version, cipher suites, and certificate management. Running TLS 1.0 or weak ciphers is an automatic finding.
• Key management documentation — PCI DSS requires documented key management procedures: key generation, distribution, storage, rotation, retirement, and destruction. “We use AES-256” isn’t enough — you must prove how keys are managed throughout their lifecycle.
• Certificate inventory — Requirement 4.2.1 requires an inventory of trusted keys and certificates. You must know what certificates protect cardholder data flows and ensure they’re properly managed.
• Scope reduction — proper encryption can reduce PCI scope. If cardholder data is encrypted before entering your systems (P2PE/tokenization), those systems may be out of scope for PCI assessment.

How it works

Requirement 3 (Data at Rest):

1. Identify where cardholder data is stored
2. Encrypt with strong algorithms (AES-128+, TDES with proper key management)
3. Document key management procedures (generation, storage, rotation, destruction)
4. Restrict access to cryptographic keys to minimum necessary personnel
5. Store keys separately from encrypted data (or use split knowledge / dual control)
6. Rotate keys at least annually (or per crypto-period defined in key management policy)

Requirement 4 (Data in Transit):

1. Use strong cryptography for all transmission of cardholder data over open/public networks
2. TLS 1.2 or higher required (TLS 1.0, 1.1, SSL all prohibited)
3. Use trusted certificates (not self-signed for production card data flows)
4. Verify TLS certificates are valid and not expired
5. Maintain inventory of trusted keys and certificates

Requirement 12.3.3 (Cryptographic Inventory):

• Maintain a documented inventory of all cryptographic cipher suites and protocols in use
• Include: algorithm, key length, purpose, systems using it, key custodian

In real systems

TLS configuration for PCI compliance:

# PCI DSS 4.0 compliant Nginx configuration
ssl_protocols TLSv1.2 TLSv1.3;  # TLS 1.0/1.1 prohibited
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
# No CBC suites, no RC4, no 3DES, no NULL, no EXPORT
ssl_prefer_server_ciphers on;

# Certificate must be from a trusted CA (not self-signed)
ssl_certificate     /etc/ssl/certs/payment-api.pem;
ssl_certificate_key /etc/ssl/private/payment-api.key;

Key management documentation (what auditors expect):

Key Management Policy must document:
- Key generation: how, where, by whom (HSM? Software? Ceremony?)
- Key storage: where keys are stored, access controls, encryption of keys at rest
- Key distribution: how keys reach systems that need them (secure channel)
- Key rotation: schedule (annual minimum), procedure, who authorizes
- Key retirement/destruction: when keys are decommissioned, how they're destroyed
- Key custodians: named individuals responsible for each key
- Split knowledge: no single person has complete key material

Scanning for PCI compliance (ASV scan):

# Approved Scanning Vendors (ASVs) check:
# - TLS version (must be 1.2+)
# - Cipher suites (no weak ciphers)
# - Certificate validity (not expired, not self-signed)
# - Certificate chain (complete, trusted root)
# - Known vulnerabilities (Heartbleed, POODLE, etc.)

# Self-check with ssllabs-scan or testssl.sh:
testssl.sh --pci payment-api.example.com

Where it breaks

TLS 1.2 with weak cipher suites — the server supports TLS 1.2 (passing the version check) but also enables CBC cipher suites or 3DES. The ASV scan flags these as vulnerabilities. PCI DSS requires not just the right TLS version but also strong cipher suites — AEAD modes only (GCM, ChaCha20-Poly1305). Teams often fix the version but forget to restrict cipher suites.

Key rotation not documented or performed — the organization uses AES-256 for database encryption (technically compliant) but has never rotated the encryption key in 3 years. PCI DSS requires key rotation per the defined crypto-period. The auditor asks for evidence of the last rotation — there is none. This is a finding even though the algorithm is strong, because key management procedures weren’t followed.

Self-signed certificates on internal card data flows — a team argues “it’s internal, not over a public network.” But PCI DSS 4.0 Requirement 4.2.1 applies to all networks where cardholder data is transmitted if those networks could be compromised. Internal networks with self-signed certificates provide encryption but no authentication — a compromised internal host can MITM the connection. Auditors increasingly flag internal self-signed certs for card data flows.

Operational insight

The biggest PCI cryptography gap isn’t algorithm strength — it’s inventory. Requirement 12.3.3 (new in PCI DSS 4.0, mandatory by March 2025) requires a complete inventory of all cryptographic cipher suites, protocols, and algorithms in use across the cardholder data environment. Most organizations can list their web-facing TLS configuration but can’t answer: “What encryption protects the database connection between the payment app and the card data store? What cipher suite does the connection to the payment processor use? What algorithm encrypts the backup tapes?” Building this inventory requires scanning all network connections, database configurations, and storage systems — not just the internet-facing endpoints. Start the inventory before the audit, not during it.

Related topics

• What is a TLS Certificate
• What are Cipher Suites
• NIST SP 800-57 Key Management
• Certificate Monitoring and Alerting
• TLS 1.3 vs TLS 1.2