I saw in many places that card informations are kept encrypted even in memory, is that actually required by PCI? I don't see reason behind it, if attacked can get to the values, he can get to encryption key as well, right?

And if it is actually required, does each card require own encryption key? Or one common can be used just with separate IV for each?



Technically, PCI requires card holder data (CHD) to be encrypted both in transit and at rest. This may seem simple at first, but the reality is, it doesn't get very specific about delineating between rest on disk vs. volatile memory. If you want to be pedantic, volatile memory is still data at rest, but according to the FAQs, it's not explicitly required to be encrypted while in memory. Though it's good to point out that this is just the FAQs, not actually in the PCI DSS Standard itself. Here's a good article to read for more info.

Long Answer

The reason for in-memory encryption has to do with the memory-scraping attack vector.

PCI DSS does a good job of making sure credit card data in persistent storage is secure, however, such data in non-persistent storage -- such as files stored temporarily in memory -- can still be vulnerable to compromise, particularly via memory-scraping malware. Learn more about this threat. SOURCE

More info about what PCI requires can be found here. The TL;DR of the long answer is that if you do not encrypt the data at rest (on disk or in memory), make sure you have compensating controls to mitigate the risk of data loss.

If stored cardholder data cannot be encrypted, consult PCI DSS Appendix B: Compensating Controls and Appendix C: Compensating Controls Worksheet.

  • "memory-scraping attack vector" - but what prevents the same attack vector to be used to acquire encryption keys? – graywolf Aug 29 '16 at 19:46
  • @Paladin consider Heartbleed or other memory-based attacks. The malware may not have access to the persistent storage where the keys are kept, especially if it's a web application that has a vulnerability which doesn't lead to full compromise. Overall, I think the spirit of the requirement is to be a good steward of CHD and make prudent choices. – HashHazard Aug 29 '16 at 19:51
  • that's a good point. Do you happen to know anything about second part of my question ? :) – graywolf Aug 29 '16 at 21:09
  • 1
    IIRC, it can be the same encryption key for each card. – HashHazard Aug 29 '16 at 22:24
  • 2
    @Paladin it is better to encrypt memory, the attack on Target's POS devices depended on fetching card information from the memory. forbes.com/sites/anthonykosner/2014/01/17/… – Limit Aug 30 '16 at 1:26

Cardholder data does not need to be encrypted in volatile memory (https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Should-cardholder-data-be-encrypted-while-in-memory) It should be noted that the ability for data written to volatile memory to persist onto disk can and will happen. The encryption of the pagefile or swap file can help prevent this.

Cardholder data must be protected when in transit over open, public networks [PCI DSS Req. 4.1] and when written to disk [PCI DSS Req. 3.4]. The requirements are not the same for each and examples are given within the PCI DSS. The Guidance column on the right of the standard is usually helpful as well.

The most recent version of the PCI DSS can be found here. https://www.pcisecuritystandards.org/document_library


To answer your second question first, ("I don't see reason behind it, if attacked can get to the values, he can get to encryption key as well, right?") the off-the-shelf RAM scraping malware simply knows how to identify track data in memory. It doesn't understand the memory map of your register process. It doesn't know your structures or fields. It doesn't try to find a char* buffer labeled "Track_Data". It just reads all the memory in your process and if it matches a pattern of 15 or 16 digits, it scrapes it up and sends it to the bad guy. The off-the-shelf malware certainly doesn't know what bytes make up an encryption key, so once your data is encrypted, the malware won't see it. (The typical malware is not very sophisticated, and certainly wouldn't recognize XOR or ROT-13 data, much less a block of AES-128 encrypted data.)

Consider the attackers have to be stealthy: if they sent 2GB RAM dumps from every cash register after every transaction, the network people would probably notice. They only send the smallest amount of data they need, and don't try to decrypt anything.

(Note that this is true only for the general purpose RAM scraping malware like Dexter and BlackPOS; if there is malware targeted at a specific application, it may be customized to understand the memory structures and to try to steal keys and/or encrypted data from specific addresses. It all depends on the attackers.)


As asked, the first part of your question almost describes a race condition: at what point is the track data considered "at rest"? Is it only when it lands on a hard disk, or can it be considered at rest while in memory waiting to be encrypted?

But now you have to keep going, and get more detailed. Is it at rest when it lands in the USB device driver's buffers? Is it resting when a Windows message is posted to notify your process that new track data has been input? Is it resting when the buffer is sent to the encryption algorithm? Is it at rest when the application parses the track to recover the cardholder name, service code, PAN, CVV, and expiration date? Is it at rest when it strips the last 4 digits for the receipt? Is it at rest if the application is processing the account number in any way prior to encrypting; perhaps validating a check digit, or determining if it's a Visa or other type of credit card? Is it at rest when the authorization message is being constructed? None of those activities seem like the data is resting very much, and many of those activities are common functions in POS systems. In total, all that processing can take a few milliseconds or more to execute.

Now let's consider the real-world attackers. The malware used in some of the biggest-name breaches was RAM scraping malware, and it is extremely aggressive. It can sweep through the register's memory hundreds of times per second, and trigger on the briefest glimpse of PAN or track data. It can capture track data arriving in the USB buffers, in the windows message buffers before the application is notified, while being taken apart in the parsing routines, or even as the encryption routines are being invoked. Even if you perfectly comply with the letter of the PCI-DSS laws and encrypt it as soon as your application sees it, you're still vulnerable to a breach if some member of this family of malware makes it onto your cash registers.

Instead of focusing on the exact interpretation of the PCI-DSS, it's better to avoid the situation entirely by removing as many systems as possible from PCI scope. If you can, get the track data out of the cash register, and into a separate payment terminal that can encrypt the data before sending it to your cash register.

If you move encryption to a separate device located outside of the cash register environment, then the register never needs to receive cleartext PAN or track data. Any malware that finds its way onto your registers will find no track data to scrape. And a payment terminal will have a much smaller attack surface than a full-blown Windows-based cash register application.


I am not quite so familiar with the encryption methods used in PCI, but there is good reason why one would want this. Hardware operations often bypass the CPU and have direct memory access (DMA) to increase performance and ignore unnecessary CPU cycles. Great power comes with great responsibility, and direct memory IO can lead to creative exploits.

To give you an example, virtual machines, jails and containers separate environments between host and guests. Other than explicitly allowed, never should a guest be able to reach the host or other guests in circuital segments. If this does happen, we speak of a jailbreak. Any hardware device which allows DMA can be exploited to carry malware. There have been numerous papers published on PCI-passthough exploits, exposing the host to guests.

Vulnerability analysis of GPU computing, 2013:

[31] mentions the possibility of attacking a system by taking advantage of Direct Memory Access (DMA) to access memory that otherwise would be protected. While not specifically mentioned in this paper, the extension of this idea to GPUs represents a large vulnerability. DMA allows the GPU to access system memory independently of the CPU. Since the CPU does all the memory protection, this DMA would bypass any type of memory security and allow unlimited access to system memory. [12] describes how this type of attack has been successfully implemented in the past using a network card. However, our research in this area suggests that it is currently impossible to use a GPU to perform such an attack. This is due to the way that DMA is implemented in CUDA. In order to use DMA, certain asynchronous copy functions are used. The CPU is still responsible for allocating host memory, and this pinned memory is passed to the GPU for use in DMA. This prevents the vulnerability, since the CPU still controls the memory access and the protections are still in place. The GPU can only use DMA to access the memory that was already given to it by the CPU, not any of the system protected memory. It’s possible that in the future the GPU will have more control over its DMA, but at the moment this type of attack is not possible.

  • How does this answer OP's question? – HashHazard Aug 29 '16 at 19:44
  • "but there is good reason why one would want this". I point at some risks which answers quite well the "is that actually required by PCI?" – Yorick de Wid Aug 29 '16 at 19:46
  • 1
    Your answer doesn't contain anything that looks like "Yes, it's required." or "No, it's not required". Pointing out that some malware can attack in-memory data seems a bit obvious IMHO. – HashHazard Aug 29 '16 at 19:53
  • Are you thinking of the other PCI instead of the PCI the question refers to? – ilkkachu Aug 30 '16 at 13:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.