The newest version of PCI DSS (4.0) is out, and companies are asking about the new requirements. Some of these requirements apply to PCI DSS encryption, and while there are changes, many of the standards of 3.2.1 are still the lay of the land. 

Learn more about PCI DSS encryption and how it’s shifting in version 4.0.

 

What Is Encryption?

Encryption is the obfuscation of data using codes, ciphers, and other techniques to render that unreadable data outside of authorized or expected users. First invented (as far as historians know) in different forms in both Ancient Egypt and Rome, encryption was a way for military and political leaders to share information in messages such that outside eyes could not view it. 

In later history, an Arab mathematician Al-Kindi discovered how to use statistics and frequency analysis to attempt to crack ciphers. And thus, modern cryptography and countermeasures first became a reality. 

In modern culture, encryption is part of our daily lives. Online commerce, banking, and communications all rely on some sort of encryption. Early military applications of DES encryption were limited to military and international government communications, but industrial lawsuits against the government (both in support of private security and the potential for backdoors in existing encryption) led to the opening up of government-grade encryption for public use. 

These days, we use encryption for nearly every form of communication in some way:

• Most secure websites use Hypertext Transport Protocol Secure (HTTPS) encryption to protect website communications between clients and servers. 
• Email providers almost universally provide Transport Layer Security (TLS) to encrypt email transmissions in transit. 
• Encrypted messaging apps like Signal and Facebook Messenger provide encryption for messages in transit between users.

For modern security practices, encryption is a necessary technology. Unsurprisingly, most security frameworks and regulations include forms of encryption as part of their requirements. PCI DSS is no different.

 

Encryption Standards for PCI DSS version 3.2.1

While PCI DSS 4.0 has been released, it hasn’t yet been fully implemented. That means that the current version (v. 3.2.1) is still the primary standard for PCI DSS compliance (outside of a handful of specific changes that auditors expect in all-new version 4.0 assessments). 

In the PCI standard, encryption generally falls under two of the 12 total requirements:

 

PCI Requirement 3

This requirement dictates that compliant processors must securely store cardholder data if and only if they store it. That is, if the company isn’t storing the plaintext personal information of a cardholder (Primary Account Number or PAN, address, phone number, etc.). 

Some of the primary sub-requirements under Requirement 3 include:

• Storage and Processing Limits: Companies may only store and process cardholder data within the limits of their defined needs for business, legal, and regulatory purposes. Unused data must be purged quarterly. This includes using encryption for data-at-rest.
• No Storage of Authentication Data: Any information used to authenticate a transaction must never be stored unless PCI auditors approve a clear business justification. 
• PAN Display: PANs cannot be displayed more than the first six and last four digits of the card number, notwithstanding additional encryption and security requirements. 
• Key Management: Encryption keys used to secure cardholder data must be stored securely, with document management practices that must also be documented in their execution.

 

PCI Requirement 4

Requirement four dictates that all cardholder data must be encrypted during transmission over public networks. This is slightly more applicable to processors because while some companies may not store credit data, all processors will likely transmit it (if for no other reason than verification). 

Some of the primary sub-requirements under Requirement 4 include:

• Strong Encryption: Companies must use strong encryption to transmit cardholder data across public networks, including wireless and mobile networks. Those networks must also follow strong encryption best practices.
• Transmission of PAN: No PANs may be transmitted via end-user technology like texting/SMS or email. 
• Documentation: All these security policies and procedures must be documented, and knowledge of such practices should be made available to all relevant stakeholders and employees.

In the context of PCI DSS, “strong encryption” includes the following methods:

• Advanced Encryption Standard (AES) 128-bit encryption or higher is a modern standard developed by the National Institute of Standards and Technology (NIST) for public and government use to protect data-at-rest.
  
• Rivest-Shamir-Adleman (RSA) is a form of public-key encryption for end-to-end communication.
• Transport Layer Security (TLS) is a form of encryption used to create encrypted “tunnels” to transmit data and is incorporated in several technologies like email and messaging. PCI DSS requires at least TLS version 1.2, with specific requirements to upgrade from early TLS (1.1 or older). The full switch to TLS 1.2+ was finalized in June 2020. 

Additionally, there are several encryption practices they must implement outside of serial data obfuscating:

• One-Way Hashes: These provide an obfuscated reference to a location in a database such that the reader cannot reverse-engineer the location of information based on reference columns. This can protect against unauthorized access to data.
  
• Truncation: When credit card companies display card information for verification, they hide specific parts of the PAN to avoid disclosure. Truncation is the next step, where PANs are segmented to hide parts and protect their full value so that they aren’t necessarily compromised if they are accessed illegally. 
• Stored Pads: Also known as one-time pads, these methods are one-time encryption techniques where data is coded with a single-use key. 

 

Encryption Standards for PCI DSS version 4.0

The encryption standards for version 4.0 aren’t radically different as of yet, and this isn’t unexpected. As these standards evolve, revisions to 4.0 will introduce new requirements as needed. 

However, there are several new definitions and approaches introduced:

• Expanded Encryption Contexts: In the previous PCI standard, only systems storing or transmitting data must be encrypted. Also, when a processor receives encrypted data, it may be relieved of some PCI DSS security requirements. Under 4.0, encrypting data doesn’t relieve organizations of specific PCI DSS requirements. Instead, it may do so if and only if that organization receives encrypted data it cannot decrypt and does not perform encryption/decryption practices as part of its own business practices. In version 3.2.1, encryption was required for cardholder data, including PANs and cardholder information (alongside specific authentication data). In 4.0, this encryption must include magnetic stripe data, chip data, card verification codes and PINs.

• Definition of Card Data Storage Types: Under 4.0, PAN storage is delimited as Persistent non-volatile and non-persistent volatile storage. The former includes hard disks and removable storage, while the latter includes RAM and other temporary storage media.
• Number Display for Truncation: If companies use truncation, they cannot use hashes to replace truncated portions. Furthermore, the truncated language may include the full business identification number (BIN) portion of the PAN alongside the last four digits, regardless of BIN length.
• Updated Key Management: New controls for protecting cloud-stored encryption keys are implemented, including disallowing the same keys in production and test environments and requiring the use of approved random number generators. 

 

PCI DSS Encryption and Continuum GRC

Managing encryption is relatively straightforward on paper but requires a complete understanding of your PCI DSS exposure. Rather than relying on ad hoc data inventory and encryption implementation, rely on risk and compliance-based platform that can support your comprehensive efforts in meeting PCI DSS encryption requirements. 

Continuum GRC is cloud-based, always available and plugged into our team of experts. We provide risk management and compliance support for every major regulation and compliance framework on the market, including:

• FedRAMP
• StateRAMP
• NIST 800-53
• FARS NIST 800-171
• CMMC
• SOC 1, SOC 2, SOC 3
• HIPAA
• PCI DSS
• IRS 1075
• COSO SOX
• ISO 27000 Series

And more. We are also the only FedRAMP and StateRAMP authorized compliance and risk management solution in the world.

Continuum GRC is a proactive cyber security®, and the only FedRAMP and StateRAMP Authorized cybersecurity audit platform in the world. Call 1-888-896-6207 to discuss your organization’s cybersecurity needs and find out how we can help your organization protect its systems and ensure compliance.

[wpforms id=”43885″]