Implementation of encryption according to PCI DSS

[Mutt]

Implementing encryption in accordance with the Payment Card Industry Data Security Standard (PCI DSS) is a key element to protect cardholder data (e.g. card number, name, expiration date) at rest and in transit. PCI DSS (version 4.0 as of August 2025) sets strict encryption requirements to minimize the risk of data breaches that can be used for fraudulent activities such as carding. Below, I will describe in detail how to implement encryption in accordance with PCI DSS, including requirements, algorithms, processes, and best practices, for educational purposes.

PCI DSS Encryption Requirements​

PCI DSS includes two key requirements related to encryption, which fall under Objective 2 (Protecting Cardholder Data):

1. Requirement 3: Protecting stored cardholder data:
   • Store only the data that is necessary for your business.
   • Use strong encryption to protect cardholder data (Primary Account Number, PAN, and other sensitive data).
   • It is prohibited to store sensitive authentication data (e.g. CVV, PIN, magnetic stripe data) after authorization.
   • Apply data masking and truncation (e.g. display only the last 4 digits of the PAN).
2. Requirement 4: Encrypt data when transmitted over open or public networks:
   • Use strong encryption protocols (such as TLS 1.2 or higher) to protect card data when transmitted over the Internet or other networks.
   • Ensure secure configuration of cryptographic protocols and certificates.

Steps to Implement Encryption in Compliance with PCI DSS​

To meet the PCI DSS encryption requirements, you must implement the processes and technologies described below. These steps include encryption of data at rest and in transit, as well as key management.

1. Determining the data to be encrypted​

• What to encrypt:
  • PAN (Primary Account Number): The 16-digit card number must be encrypted when stored if retained.
  • Other data (e.g. holder name, expiration date) may not be encrypted if stored separately from the PAN, but its storage should be minimized.
  • Sensitive authentication data (CVV, PIN, magnetic stripe data) should not be stored at all.
• Example: If an online store stores PAN for repeated payments, it should be encrypted. The CVV entered during payment should be deleted after authorization.

2. Selection of cryptographic algorithms​

PCI DSS requires the use of strong cryptography based on recognized standards (e.g. NIST, FIPS). Recommended algorithms:

• To encrypt data at rest:
  • AES (Advanced Encryption Standard): Use keys of 128, 192, or 256 bits. AES-256 is preferred.
  • RSA: For asymmetric encryption (e.g. to protect keys), use keys of at least 2048 bits.
  • Hashing: If data (such as PAN) needs to be stored irreversibly, use SHA-256 or SHA-3 with a salt (a random value to protect against dictionary attacks).
  • Prohibited algorithms: MD5, SHA-1 (for new systems), DES, 3DES (obsolete, allowed only during the transition period until 2024).
• For encryption during transmission:
  • TLS (Transport Layer Security): Use TLS 1.2 or 1.3. TLS 1.0 and SSL are prohibited.
  • IPsec: To protect data in private networks (for example, between a POS terminal and a processing center).
  • SFTP or SCP: For secure transfer of files containing card data.
• Example: The database with PAN should use AES-256 for encryption, and online payments should use TLS 1.3 with a certificate issued by a trusted certificate authority.

3. Data encryption at rest​

• Database encryption:
  • Use column-level or file-level encryption for databases containing PANs.
  • Example: In PostgreSQL or MySQL, enable encryption of PAN columns using AES-256.
• File level encryption:
  • Encrypt files containing card data using tools such as GPG or OpenSSL.
• Masking and truncation:
  • Show only the first 6 and last 4 digits of the PAN (eg 123456******7890).
  • Example: In the user interface of an online store, display only part of the card number.
• Tokenization(optional):
  • Replace the PAN with a token (a random identifier) stored in place of the card number. Tokens do not require encryption unless they can be converted back to a PAN without access to the token store.
  • Example: Use Visa Token Service to replace PAN with a token.

4. Data encryption during transmission​

• Using TLS:
  • Configure web servers (e.g. Apache, Nginx) to use TLS 1.2 or 1.3 with strong ciphers (e.g. ECDHE-RSA-AES256-GCM-SHA384).
  • Use certificates from trusted certificate authorities (e.g. Let's Encrypt, DigiCert).
  • Regularly test your TLS configuration using tools such as Qualys SSL Labs.
• Encryption in private networks:
  • Use IPsec or VPN to protect data transferred between branches or processing centers.
• Disable unencrypted channels:
  • Do not transfer card data via HTTP, FTP or other unsecured protocols.
• Example: A POS terminal must transmit transaction data to a bank via a TLS encrypted channel.

5. Cryptographic Key Management​

PCI DSS (requirement 3.5–3.7) sets strict rules for encryption key management:

• Key generation:
  • Use hardware security modules (HSMs) or certified cryptographic libraries to generate keys.
  • Example: HSMs such as Thales or Gemalto provide secure key generation and storage.
• Key storage:
  • Store keys in a secure environment (e.g. HSM or encrypted storage).
  • Restrict access to keys using the principle of least privilege.
• Key rotation:
  • Update your keys regularly (e.g. once a year or if you suspect they have been compromised).
  • Use automated systems to rotate keys without interrupting operations.
• Destruction of keys:
  • Destroy old or compromised keys in accordance with cryptographic standards.
• Journaling:
  • Keep logs of key access and usage.
• Example: Use AWS Key Management Service (KMS) to manage AES-256 keys in the cloud.

6. Integration with other PCI DSS requirements​

Encryption works in conjunction with other aspects of PCI DSS:

• Access Control (Requirement 7): Restrict access to encrypted data and keys to authorized personnel only.
• Monitoring (Requirement 10): Log attempts to access encrypted data and keys.
• Testing (Requirement 11): Regularly test encryption systems for vulnerabilities using scanning and pentests.

7. Documentation and Policies​

• Develop encryption policies including:
  • List of algorithms used (e.g. AES-256, TLS 1.3).
  • Key management procedures.
  • Procedure for responding to key compromise.
• Document all encryption processes for PCI DSS audit.
• Example: Create a document describing how the database with PAN is encrypted using AES-256 and how the keys are stored in the HSM.

8. Audit and testing​

• Perform regular encryption checks:
  • Check your TLS configuration using tools like SSL Labs.
  • Test your databases for unencrypted card data.
• Complete a Qualified Security Auditor (QSA) audit for Level 1 or complete the SAQ for Levels 2–4.

Recommended tools and technologies​

• To encrypt data:
  • Databases: PostgreSQL (with pgcrypto module), MySQL (with ENCRYPT function).
  • File encryption: GPG, OpenSSL.
  • HSM: Thales nShield, AWS CloudHSM.
• To encrypt the transmission:
  • Web servers: Nginx, Apache with configured TLS.
  • VPN/IPsec: Cisco AnyConnect, OpenVPN.
• For testing:
  • Qualys SSL Labs (for TLS verification).
  • Burp Suite, Nessus (for vulnerability testing).

Carding Protection Link​

PCI DSS encryption prevents carding because:

• Protects stored data: Even if the database is leaked, attackers will not be able to use the encrypted PAN without the key.
• Reduces the value of stolen data: Restricting the storage of CVV and PIN makes stolen data less useful for online carding.
• Ensures secure transmission: TLS prevents data from being intercepted on networks, reducing the risk of phishing or skimming.

Problems and challenges​

• Difficulty in key management: Improper storage or loss of keys can result in data loss.
• Performance: Encryption can slow down the processing of large amounts of data.
• Outdated systems: Using outdated algorithms (e.g. 3DES) or protocols (TLS 1.0) creates vulnerabilities.
• Cost: Implementing HSM or certified solutions requires investment.

Conclusion​

Implementing PCI DSS encryption requires the use of strong algorithms (AES-256, RSA-2048, TLS 1.3), strict key management, and integration with other security measures. This ensures that cardholder data is protected from leaks and reduces the risks of carding. Key steps include choosing the right algorithms, setting up encryption for storage and transmission, managing keys via an HSM, and regular auditing.

If you want to dive deeper into specific aspects, such as setting up TLS on the server, using an HSM for key management, or testing encryption in a legitimate environment (e.g. through simulations on platforms like TryHackMe), let me know and I'll provide the details.