For many people, cryptography is akin to biblical Gnosticism -- there are a few who intimately know cryptography and its s-boxes, permutations, salts, and other magic1 -- and then there are the rest of us whose eyes glaze over when the topic arises. This is partially because cryptography by design was once known only to the denizens of the National Security Agency and a few academics. Until 1996, it was illegal under federal law to export strong cryptography from the United States, which may have discouraged others from learning the art.
Fast forward to 2006, and the Payment Card Industry Data Security Standard (PCI DSS) requires merchants (and others) to encrypt certain cardholder information. At last count, nearly three dozen states have laws that require merchants to announce when they have disclosed personal financial information that was not encrypted. Visa and MasterCard can levy fines of up to $500,000 for breaches in which the merchant failed to implement security measures. In my experience, these fines are larger and generally occur more often in situations where the merchant failed to use encryption.
Encryption of cardholder data is one of the most effective means of preventing cardholder information disclosure and the resultant potential for fraud. Cryptography technology is mature and well proven. As I've written elsewhere and tell anyone who will listen, there is simply no excuse for not encrypting sensitive data.
Of course, your choice of encryption scheme -- symmetric, asymmetric public-private key, hashing and digesting -- is critical in deploying a secure, effective and reasonable control. For example, password files, secret question responses, and other sensitive information should normall...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
y be stored as a hash value, and the result of user input then hashed and compared. Symmetric cryptography -- with the attendant key management overhead and security issues-- is typically appropriate for data transport due to speed, with some form of the computationally slower (but considered to be more secure) asymmetric public-private key system used to encrypt the transport session key or for information that must be shared.
The PCI Data Security Standard requires card holder data be protected. Requirement 3.4 stats that merchants must render [the Primary Account Number], at minimum, unreadable anywhere it is stored (including data on portable digital media, backup media, in logs, and data received from or stored by wireless networks) by using any of the following approaches:
- Strong one-way hash functions (hashed indexes)
- Truncation
- Index tokens and pads (pads must be securely stored)
- Strong cryptography with associated key management processes and procedures
A typical merchant might swipe a customer's credit card at the point of sale and capture at a minimum the Primary Account Number (PAN) from the track data. Prior to the PCI Data Security Standard requirements, many merchants simply stored the PAN (and in many cases all the track data) in a database or log file without any encryption. This allowed the merchant to easily verify purchases and process refunds as a normal part of customer service. This practice, however, also made it easy for criminals to steal a large number of card numbers and other data, and will now earn the merchant a large fine.
As seen in requirement 3.4, the PCI Data Security Standard requires one of four methods2. Let's focus here on the advantages and use of the hash function. Hashing is a special cryptographic method that takes a block of data (the PAN, for example) and passes it through a one-way process to produce a block of encrypted data. The resulting block of data cannot be reversed to recover the original data. The major advantage of hashing is the lack of keys, which effectively eliminates the risks involved in managing and keeping keys secure. If a criminal were to acquire the hash values, they are for all intents and purposes useless and would not likely lead to a fine or trigger a public disclosure. Customer service processes and applications continue to work by simply comparing a freshly computed hash of the PAN given by a customer against the previously stored hash value. The hash function is readily available to programmers as this is the normal way passwords are stored and used in modern operating systems.
In closing, merchants and payment-application vendors should use only well-known and accepted algorithms and products that have met the test of time. The single largest failure in deploying encryption is attempting to create an ad-hoc cryptographic implementation.
About the Author:
Roger Nebel, CISSP, CISA, works with FTI Consulting, specializing in forensic and litigation consulting. He is based in Washington DC where he leads the Strategic Security practice. Nebel also teaches at the University of Virginia in the graduate information security program. He can be reached at roger.nebel@fticonsulting.com. The views expressed in the article are held by the author and are not necessarily representative of FTI Consulting.
Footnotes:
1 "Any sufficiently advanced technology is indistinguishable from magic." Arthur C. Clarke, 1961.
2 Compensating controls are allowed if they meet the intent and rigor of the original control. For most merchants the expense and complexity of an effective compensating control would far exceed the cost of implementing crypto.
