Message in a PCI bottle - preserving message queue integrity

Ben Rothke and David Mundhenk close out their series on achieving PCI compliance when dealing with message queues.

preserving message queue integrity
Credit: iStockphoto

First, a confession. When David and I started writing this series, we envisioned it would be completed after the third part. It appears we were a bit short-sighted. An astute reader challenged us to help address the concepts of preserving queue message data integrity. With that, we welcome you to part 4.

In parts 1, 2 and 3 of this series we wrote at length about the possible compliance and security issues associated with the queueing of cardholder data (CHD) within a PCI compliant cardholder data environment (CDE).

The queuing of CHD in volatile system memory can sometimes be affected by system resource issues due to loading, transaction latencies, intervention by journaling file system processes and more. Under such circumstances, a payment application or operating system may temporarily write CHD to disk. When this happens, and it’s not infrequently, the CHD is often written to disk undetected and unprotected.

Our interested reader of the previous article asked how to ensure the integrity of CHD when it’s transmitted from one queue to another within a given system, or even if such data transmission occurs across a suspect trust boundary such as the internet. What tools or safeguards are available to application developers that could help protect the integrity of the messages being sent? Also, he asked, wouldn’t it be great if there could be some level of assurance that the sender of the message is genuine and can be validated as a trusted entity? This would be especially important if the content of such messages contained payment transaction data including cardholder data, or even other such sensitive data such as personally identifiable information (PII) or other authentication requests.

MAC – meet HMAC

Enter the dragon that is the Message Authentication Code (MAC), and its more secure cousin the hash-based Message Authentication Code (HMAC). A MAC is a minimal piece of information used to authenticate a transmitted message. The HMAC is a specific, albeit special type of message authentication code that couples a cryptographic mathematical hashing function along with pre-shared secret cryptographic keys. HMAC authentication code provides the server and the client with a cryptographic key that helps to protect the integrity of given message while in transit, and also helps substantiate the sender as a trusted entity.

[ MORE FROM THIS SERIES: How to ensure PCI DSS compliance when dealing with message queues ]

For the HMAC, the secret key is known only to the server and specific client system. Using the secret key and a cryptographic hashing function, the client creates a unique mathematical hash to be sent to the server per each message being transmitted. Upon receipt of the message, the server then generates its own HMAC based upon the pre-shared, secret cryptographic key and compares the two values. If the values match, the client has been trusted and there is a high-level of assurance that the message has not been tampered with. If not, the data and the sender are suspect, the message is discarded and the event is hopefully recorded within an event log. Inordinate numbers of discarded messages are often harbinger of an untrusted sender attempting to communicate with a message recipient in an unauthorized fashion.

While authentication and data integrity has been preserved in HMAC use, it should be noted that any sensitive data contained with the message (such as CHD) could still require additional protections. This can be accomplished by encrypting the data prior to transmission using strong cryptographic algorithm, or by using a cryptographically strong, encrypted transmission protocol such as TLS v1.2 or IPsec.

HMAC use is becoming ubiquitous due in part to the prevalence of cloud computing and web services architectures. Entities attempting to connect to Internet exposed web services must have a valid, pre-shared cryptographic key or the messages being transmitted are suspect and ultimately discarded. That using Amazon Web Services can integrate its own messaging architecture called Amazon Simple Queue Service (SQS)


Not only is it quite easy to get queuing working on AWS, they also provide good documentation on how to do it. For anyone using AWS, a good place to start is here. Amazon does a good job of providing the steps on how the HMAC basic authentication process works.

For those who want a more detailed understanding of how Amazon SQS queues work, a great place to see is here.


As stated previously, message queue security is something not enough people think much about. In this, our final installment in this four-part series, we hope you now have a better appreciation of the importance of message queuing, especially for those needing to be PCI compliant or otherwise interested in preserving message data integrity in transit.

This story, "Message in a PCI bottle - preserving message queue integrity" was originally published by CSO.