PCI v4 Now Mandates Application-layer Encryption

Understanding the Data Security Changes Since v3

PCI-DSS is the security standard that the credit card industry mandates. Anyone who issues credit cards, processes credit cards, etc., is contractually obligated to adhere to this standard to keep credit card information safe. The latest revision, v4, is now about two years old, but this month marks two changes: 1) it’s no longer acceptable to use v3, and 2) many of the requirements in v4 were best practice suggestions become obligatory this month.

So now seems like a good time to review some of the changes between v3 and v4. Overall they run the gamut and include things like two-factor authentication, but in this post, we’ll look specifically at the data security requirements.

Requirement 3: Protect Stored Account Data

The overview for this requirement doesn’t use the term “application-layer encryption,” but it includes a statement that serves as a succinct definition for it:

If an intruder circumvents other security controls and gains access to encrypted account data, the data is unreadable without the proper cryptographic keys and is unusable to that intruder.

If we think about the intruder gaining access to a running database, for example, then to keep the data unreadable, it must be encrypted when it’s fetched, which implies that it is encrypted and decrypted outside of the database. Because the encryption is handled by a program that calls the data store, we typically call this the “application layer.”

But the requirement here in the overview does not necessitate encryption. The standard allows other ways to protect the data and render it unusable by an intruder with access to the data store. For example, truncation, masking, and hashing are all noted as acceptable alternate approaches to protect the data in addition to strong encryption. New to v4 is the stipulation that all hashes must be cryptographically keyed hashes, aka HMACs. Also in v4, they strongly encourage minimization of the data by mandating retention policies and suggesting that, when feasible, account data is not even stored in the first place.

Components of Credit Card Related Data

The overview gives guidance and suggests application-layer encryption (or application-layer hashing, masking, etc.), but the requirement specifics are more nuanced and less stringent. Before we can get into those nuances, we need to define “account data” and the other acronyms that PCI uses to talk about the data it wants companies to protect.

CID

The card’s verification code, aka CVC, CAV2, CID, CVC2, CVN2, CW2

SAD

Sensitive Authentication Data are the “secret” parts of the credit card that no one is ever supposed to store such as the CID, PIN, and chip contents.

PAN

Primary Account Number, which is the credit or debit card number.

Cardholder Data

PAN, Cardholder name, expiration date, service code

Account Data

Cardholder Data + SAD (basically all of the above)

Handling of Primary Account Numbers (PAN)

PAN has long had a requirement under PCI to be encrypted, but the wording was loose, so not everyone used application-layer encryption (ALE) for PAN. Instead, people would use infrastructure-level encryption like transparent database encryption or filesystem encryption. But these approaches don’t protect the PAN from an intruder who gains access to the database or filesystem.

In v4.0, the standard was tweaked to make ALE a full requirement with exceptions only for removable media. Here are the relevant excerpts:

3.5.1: PAN is rendered unreadable anywhere it is stored by using any of the following approaches:

• One-way hashes based on strong cryptography of the entire PAN.
• Truncation (hashing cannot be used to replace the truncated segment of PAN).
  • If hashed and truncated versions of the same PAN, or different truncation formats of the same PAN, are present in an environment, additional controls are in place such that the different versions cannot be correlated to reconstruct the original PAN.
• Index tokens.
• Strong cryptography with associated key-management processes and procedures.

Customized Approach Objective: Cleartext PAN cannot be read [in understandable format] from storage media

Applicability Notes: This requirement applies to PANs stored in primary storage (databases, or flat files such as text files spreadsheets) as well as non-primary storage (backup, audit logs, exception, or troubleshooting logs).

The key phrase there is “rendered unreadable anywhere it is stored,” which, if it’s reversible, means ALE. Here are the bits that make an exception for removable media, where transparent disk encryption makes mores sense, though it remains useless for as long as that media is connected to a computer:

3.5.1.2: If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable, it is implemented only as follows:

• On removable electronic media OR
• If used for non-removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1.

And finally, the applicability notes tell us that it’s okay to have both ALE and transparent encryption, and that removable drives in servers are not considered removable media for purposes of this section:

While disk or partition encryption may still be present on these types of devices, it cannot be the only mechanism used to protect PAN stored on those systems. … Media that is part of a data center architecture (for example, hot-swappable drives, bulk tape-backups) is considered non-removable electronic media to which Requirement 3.5.1 applies.

This is a great step forward for protecting the PAN, and hopefully most companies were already doing this.

Handling of Sensitive Authentication Data (SAD)

The secrets needed to get an authorization for a credit card or debit card (the SAD) are never supposed to be persisted to disk. But then they say that there are times when that can happen, provided the SAD doesn’t stick around past the transaction completing. In that scenario, the SAD needs to be treated like the PAN, with ALE protecting it.

3.3.2 SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography

Note: strong cryptography is a reference to generally accepted global standards for algorithms and key sizes; it does not imply application-layer encryption. What does imply ALE are the earlier requirements forbidding SAD from hitting logs, trace files, crash dump files, etc., and the earlier context from the overview.

What About Cardholder Name, Expiration, etc.?

There are no specific requirements to encrypt these data elements using ALE, but the overview of section 3.5 seems to strongly recommend an ALE-level of protection for all account holder data, including names. While it’s unlikely anyone would fail their PCIv4 audit by not encrypting names at the moment, the wording here seems to indicate that it’s considered a best practice and may become a full requirement in future versions.

Special Requirements for Multi-tenant Service Providers (ie, SaaS Companies): Likely Must Use Application-layer Encryption

Hidden under Appendix A1 are a whole other set of requirements just for “multi-tenant service providers,” which references SaaS companies that want to get PCI certified because they handle credit card info or manage transactions.

Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers Multi-tenant service providers are a type of third-party service provider that offers various shared services to merchants and other service providers, where customers share system resources (such as physical or virtual servers), infrastructure, applications (including Software as a Service (SaaS)), and/or databases. Services may include, but are not limited to, hosting multiple entities on a single shared server, providing e-commerce and/or “shopping cart” services, web- based hosting services, payment applications, various cloud applications and services, and payment gateway and processor services offered in a shared environment.

There are a number of requirements in this section covering things like prompt forensic investigations, audit trails, pen tests, etc., but the novel ones are in creating logical separations between customers. This could be done by provisioning separate infrastructure for each customer and then blocking access between these separate infrastructures, but then the service wouldn’t exactly be multi-tenant.

Creating the level of isolation needed may be tricky for these service providers who need to meet these various requirements. Separately encrypting the data of different tenants under different keys and ensuring that a database couldn’t successfully return unencrypted data spanning more than one tenant are measures that would provide the required separation. That’s the level of logical isolation that’s provided by ALE.

Here are some key requirement excerpts:

A1.1.1 Customers cannot access the provider’s environment. The provider cannot access its customers’ environments without authorization.

A1.1.2 Controls are implemented such that each customer only has permission to access its own cardholder data and CDE. … Customers cannot access other customers’ environments.

A1.1.3 Controls are implemented such that each customer can only access resources allocated to them.

These requirements can be met without ALE, but ALE brings logical separation of data as well as protections against both service provider employees viewing customer information and customers accidentally, through some application flaw, seeing data belonging to other customers. Meeting these requirements is trivial with ALE, but both trickier and less effective without it.

Note that when ALE is done right, it can also allow customers to hold their own keys and have even more control over their data (including even backup copies).

Conclusion

PCIv4 requires strong protection of all account data and specifically requires application-layer encryption for credit card numbers and any temporarily stored secrets related to them. In addition, the overview specifies that all account data should be rendered unreadable to an intruder who gains access to the database (or other data store) – which means disk encryption is not enough. And for SaaS companies and other multi-tenant service providers, measures need to be taken to prevent employees from viewing customer data and to prevent application bugs from allowing one tenant to view the data of another tenant.

Obviously anyone who needs to comply with PCI now needs application-layer encryption for the card numbers. But also, it clearly makes sense to use ALE to encrypt all account data including even names and expiration dates if that information is going to be stored and kept usable. For SaaS companies, the case is even stronger, as the proper ALE patterns can prevent employees from viewing customer data and make it impossible for customers to see the data of other customers.

The main worry that engineers have when asked to implement ALE is that the data can’t be looked up, filtered and sorted as normal. For example, they point out that you can’t look someone up using their email address if you encrypt that address. But this is one of many misconceptions around ALE that were true ten years ago, but which are now solved problems. ALE data can be used with techniques like encrypted search, which keep the data encrypted while allowing lookup and filtering.

Building your own ALE is notoriously difficult, but when using a platform that handles everything for you, it’s surprisingly simple. IronCore’s [SaaS Shield] platform and related product-line are a fantastic place to start. No data flows through IronCore – you store it, you encrypt and decrypt it, you run IronCore’s Docker container(s) and keep control. And the keys can live anywhere, making compliance with PCI requirements 3 and A1 easy. Let us know if you want to talk.