Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Message in a PCI bottle - preserving message queue integrity

Ben Rothke | June 29, 2016
Ben Rothke and David Mundhenk close out their series on achieving PCI compliance when dealing with message queues.

preserving message queue integrity

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 12 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.

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.


1  2  Next Page 

Sign up for CIO Asia eNewsletters.