There is an excellent conversation going on in the PCI Forum about the definition of ‘cardholder data’.  This thread gets into the very gray areas of terminology and definitions.

Cardholder Data most certainly includes the PAN, but what if you begin to alter the pan (along the lines of PCI DSS requirement 3.4)?  We know that and encrypted PAN is still considered cardholder data and in-scope for compliance.

The alternative is that if a server receives only a secure hash of the PAN or the truncated PAN (only first 6 and last 4 digits) then what they receive is not cardholder data.  That server is not in-scope for compliance.

The above thread gets into the gray areas of wording vs. intent.  Companies will need to have in-depth conversations with their QSAs and make risk based decisions to determine exactly what is in-scope for PCI DSS.

Popularity: 21% [?]

One of the topics that always comes up (as it has in the forum) is that of how to satisfy the “strong one-way hash functions” aspect of PCI DSS requirement 3.4.

We discussed the alternative to encryption, secure hashing, earlier this year, but it’s always good to remind everyone of it. If you receive any of the following, you are not receiving “cardholder data”:

• Securely hashed PAN
• Masked PAN (displayed or output to other media)
• Truncated PAN

The reason for this is that you cannot ever get from any of the above (i.e. truncated PAN) back to the original data — at least without significant guess work, at which point you are just generating numbers.

But what about rainbow tables some people ask? Well, if you read the Wiki article it clearly states, “[A] salt is often employed with hashed passwords to avoid this attack.”

It is important that you always salt your hash or else it is not considered “secure”.

Popularity: 32% [?]

Troy emailed to ask:

We have been looking at database encryption as it applies to PCI Compliance in the United States. We have been told that we must encrypt the credit card numbers as they are stored in our SQL Server 2005 database. We developed a method where we used the key in SQL to create a certificate to encrypt and decrypt the data, as outlined in a whitepaper from Microsoft on how to use SQL Server 2005 encryption.

We have now been told that the weakness in this method is key management. Since the key is stored in the database with the credit card data, it is not compliant. Is there a resource that describes the recommended way to use SQL Server 2005 to encrypt credit card data that resolves the key and certificate issues?

I know that Damon has posted a good link to Oracle security relating to PCI, but I have not seen something like this for MS SQL.

Although storing the decryption key in the database itself is a bad idea, I would caution you against trying to map all your processes directly to the controls. Instead, try to view the intent behind requirement 3.4-3.6 and determine if your security controls achieve that goal.

Popularity: 29% [?]

I thought normal spam was bad, but now we get PCI specific spam!  Companies actually try posting press releases into the comment sections of various posts.  Sheesh.

One person emailed asking about how to address audio recordings that could contain credit card data.  This is a very good question!  (Although the salutation they used, “Dear PCI Gods”, we are not but appreciate the gesture.)

If you have done several PCI audits you will catch on to some of the nuances with implementing the standard. There are several locations where cardholder data could reside but to business functions and it rather difficult to remove:

• Customer service audio recordings (”for training purposes”)
• Fax servers (digital images)
• VRU/IVR (voice response unit / integrated voice response)

According to requirement 3.4 this data should be rendered unreadable.  But how do you justify to your CFO the purchase of a $100k hardware encryption device to protect these audio recordings that just may contain a credit card number?

The answer is that you don’t.  PCI mandates in section 12.1 that you take a risk based approach towards compliance.  If you have one data store containing audio recordings and another in an Oracle relational database you know which is more susceptible to attack.  (Answer: the database)

An attacker would probably rather kill themselves than listen to hours and hours of customer service audio recordings on the off chance they will get a few credit card numbers.  As a result many companies will leverage compensating controls or disk based encryption to protect these data stores.

Update: This is not to say that you can ignore requirement 3.4.  You must achieve the requirement, but this can be done via a number of different methods (i.e. disk based encryption or compensating controls.)  The intent here is that the way one addresses the requirement may be different depending on the data being secured.

If a database needs encryption it could use an HSM; individual applications could code encryption into the application; and audio files could use compensating controls or other methods of “rendering unreadable”.

Popularity: 26% [?]

Mike Rothman of Security Insight regularly links to our blog so we figure it’s time we return the favor in an article on compensating controls. I should first point out that we have written on PCI compensating controls in several key articles: compliance through compensating controls and the category ‘compensating controls‘.

I disagree with this article’s view of compensating controls as a “loophole”. The reasons is that because compensating controls are sometimes based on subjective information, the process is flawed. To say this would be the equivalent of saying there is a loophole in every compliance program. Let’s just nip this one in the but and say that “security” is subjective.

I like that Mike went into some potential security measures that a company may try to leverage as compensating controls, but the fact of the matter is that compensating controls are (still) situational. There were several ways to take this article. It could have been written from “here are several areas that could use compensating controls” or (as this article did) “here is one requirement and several items that companies leverage as compensating controls.”

From this second perspective the subject of evaluation was encryption and alternatives to implementing it as required. With this requirement I almost always have seen multiple controls used to compensate for the lack of encryption. The article lists the several controls and puts database security as the only one really good enough. I would say that any compensating control for encryption should include several of the security measures listed in the article, not just one.

Another thing the article does not discuss (probable due to space limitations) is that “encryption” is a nebulous area and applies to many different data stores: database, flat file, email, etc. So, when the article says that email encryption is a bad alternative to data encryption one has to ask, where is the data we are trying to protect? If it is being sent via email then, yes, email encryption will actually meet the requirement without a compensating control.

I like that people are writing about examples and case studies, but it’s a little more situational specific.

Update: Any time we reference compensating controls it is important to reference the PCI Security Audit Procedures (SAP), which contains Appendix B - Compensating Controls for requirement 3.4 (encryption) and Appendix C - Compensating Controls Worksheet.

Popularity: 39% [?]

According to Digital Transaction News, Visa USA is ready to introduce account-level processing (ALP).

“Visa claims ALP will allow smoother transitions to new cards for cardholders, and will let merchants, in partnership with issuers, design more effective rewards programs.”

Sounds good so far, but wait there is more.

“The key change is the switch from managing transactions through the six-digit bank identification number (BIN) within a card’s 16-digit number and instead using the full account number.”

Wait a minute, did we read that right? Did they say what we thought they said? Yes they did. To paraphrase, the key change is the switch from using the six-digit BIN (3.3 compliant) and instead using the full PAN. This will just add fuel to the fire over storing the full PAN.

And it just keeps getting better.

“The new process affecting Visa-branded consumer cards will allow a credit cardholder to keep the same account number even if his issuer upgrades his card”

Yes, that is right, not only do we now encourage storing the PAN, but we are going to allow the PAN to remain the same even when the card changes. This just sounds like a way to generate even more replacement card numbers.

Does anyone think that encryption will not be critical to managing this situation? How many organizations are handling encryption properly right now? Some, but not enough. Think this will just make things worse? Probably, at least in the near term. Think the “bad guys” will take advantage of this new capability? Without a doubt.

The article goes on to say that this new approach will likely cause merchants a POS software upgrade headache to support ALP. POS software will have to be able to insert a field code, known as 62.23, in the authorization message. This field code will be a single alphabetic code that indicates the card product that was presented for the transaction.

As of October 2007, Visa will require all acquirers to be able to receive the new field code in the authorization message. Acquirers will use the code to determine the correct interchange, chargeback rights and other characteristics such as loyalty points to be accrued for each individual transaction.

Popularity: 61% [?]

History

HSMs have been around for a number of years, but were not an immediate commercial success. Eracom produced an HSM as early as 1983, about which I can find little detail, but am assured that it was secure, tamper-proof, used DES. And I’ll bet it was really slow and prohibitively expensive. SafeNet bought Eracom back in 2005 to become the biggest HSM producer on the planet. Their HSMs are no longer too expensive or slow.

When SSL started being used as a matter of course for secure communication, administrators found that their webservers slowed to a crawl. In the “simple” key exchange techniques I described yesterday, the server’s decryption of the original message key takes up to 90% of the total processing of an SSL session. Think how long an SSL session takes to set up compared to an ordinary http session in your browser, a fraction longer in most cases. If you have your own webserver, try it out and time it. I did various testing on this (in the previous century!) with a Cacheflow (now Bluecoat) testing kit which ramped up the number of sessions over time. Back then we were seeing around 2000 concurrent session maxing out a webserver, and handling about 100 SSL transactions per second (TPS) as opposed to 800 http setups. I’m sure kit today is capable of a hundred times this, I don’t have the kit available to test it, and I haven’t needed to for a few years now, but the principle is still the same.

So the first thing that was required commercially was not this super-safe encryption/key protection device, but something which freed up the poor webserver to do its job.

The crypto-accelerators very simply took the cryptographic processing of keys off the server and onto an installed PCI card or attached HSM box. That was it. No securing of keys, no tamper proofing was required, no fancy algorithms being ensured, just plain old dedicated processing power. They sold like hot cakes.

At the same time it was already known that you could protect the keys just by keeping them encrypted on the hardware you were using to take the processing strain off the server. This was a simple task for the HSM makers to achieve. You can either import the keys onto the card/device, or create them in hardware. If you import the keys, you lose FIPS certification because the keys are not known to have always been safe from compromise (more on this to come).

This was one of the first pieces of technology I ever worked with, and it blew me away. I was one of the first 6 qualified engineers for one of the HSM companies in the UK, and it has influenced my career ever since.

All of the HSM companies also created devices which allowed importing of code into tamper resistant hardware in the HSM, to run entire applications securely. This was difficult to sell 6 years ago, because people were still trying to understand how to get things running quicker, theft of private keys wasn’t really the big issue, as alluded to in yesterday’s comments. These new devices with their new functionality did lead to the branching out of HSM functions into more diverse areas however (as also alluded to in the same post): thus time-stamping, digital signing, bulk encryption, bulk creation of symmetric keys, securing CAs and anything else which requiresd the safe keeping of an original key became functions supported by the HSM devices.

The fortunes of the HSM companies grew significantly in this time, but more and more competition got in on the act. There are some fairly bitter rivalries between the different camps, which may have been started in earlier days in what was essentially an unregulated industry.

Standards

Initially the card and device makers ratified their own products, saying how great theirs was compared to all the others. This created an atmosphere not unlike the wild west, apart from the guns and hairy guys in leather chaps. Then in 1994, FIPS 140-1 was released, a Federal Information Processing Standard, by which all cryptography modules had to comply.

In 2001, this was superceded by FIPS 140-2, which is split into 4 levels (again this is condensed from Wikipedia):

• Level 1 the lowest, imposes very limited requirements
• Level 2 adds requirements for physical tamper-evidence and role-based authentication.
• Level 3 adds requirements for physical tamper-resistance and identity-based authentication. It also requires physical or logical separation between the interfaces by which critical security parameters enter and leave the module.
• Level 4 makes the physical security requirements more stringent, and requires robustness against environmental attacks such as pressure and temperature changes.

In 2001 there was only 1 level 4 device in the whole of the UK that I am aware of, kept in a bunker in Greenham Common lest it be disturbed by any change in pressure or temperature and all the keys destroyed. These days the level 4 devices are a bit more sensible, the most recent one I have seen has its own on board power supply which activates the temperature and pressure sensitive controls once it is in place. The earlier ones I saw did not. Every card had to be shipped instead of flown in to avoid pressure changes – maybe this is why there were so few around back then.

HSMs are not only PCI cards of course. There are now whole familys of HSMs which come as appliances that you can import your own code into. Essentially these then become another device on the network which you can run your own secure applications inside. All of these applications have one common factor - the need to secure a key, which if it became public knowledge would compromise the security of said application.

So, this potted history is already long enough. I know some of you will want more explanation of specific HSM applications, but you will need to describe the applications very fully to get feedback, there are as many applications of HSMs as there are people programming them.

We await your input, I’m off to catch a ‘plane, and if there’s a lot of comments in the next week or so, maybe one of us will do another post.

Popularity: 30% [?]

HSMs and PKI are pretty big subjects, and putting every piece of information about them into a blog post would make it fairly unreadable. What follows is therefore a basic primer of information you will need to understand before I go any further with the meat of the issue, which I hope will be expanded on arising from any questions that people may have. If you know this already, great stuff, we’ll pick up on the actual HSMs tomorrow.

Basics of Cryptography

To understand HSMs we must first understand a little about PKI and cryptography.

In 1976, Whitfield Diffie and Martin Hellman published a paper on Diffie-Hellman (D-H) key exchange (now sometimes called Diffie-Hellman-Merkle key exchange because of Ralph Merkle’s involvement in PKI).

- Key Exchange

This allowed for the creation of a shared encryption key between 2 parties, based on a private key held by each, which never has to leave the originator’s ownership, a public key which could be known by anyone, and a base for modulus calculations. Modulus calculations allow for the public primes to be combined in such a way that each private prime can decrypt, but no other.

The shared key would therefore never be known to anyone except the communicating parties and could be calculated only by them, on any number of occasions. Anyone eavesdropping on the conversation between the 2 parties could only ever pick up the public key and base parts of the calculation, therefore being unable to complete the calculation without making a brute force attack with an ever increasing number of large prime numbers.

D-H has since been varied and built on by many others, Taher ElGamal, and Ron Rivest being the more notable. The most widely used algorithm these days is RSA (Rivest, Shamir and Adleman) due to its incorporation in web browsers, specifically to address the safe transmission of web traffic under SSL/TLS.

When you are asked to choose key lengths in creating certificates, the number of bits you choose is the length of the prime number (public key) used in the key exchange which takes place in any encryption performed by that certificate.

- SSL/TLS

The most common use of key exchange for encryption is in SSL/TLS which can be broken down into 3 main parts, the “hello”, “handshake” and “session”

Alice and Bob want to have a private conversation, they choose 2 large prime numbers each, which they assign as their Public and Private keys. Anything encrypted with Alice’s public key can only be decrypted by her private key, and the same for Bob.

The public keys are digitally signed with other attributes such as the key length and type of algorithm used and made into a digital certificate. The private key is kept safely on each party’s hard drive.

For those who care, the exchange of information looks roughly like this (cut down from Wikipedia, which has a good article on the subject if you need more technical detail):

Hello

• ClientHello - sends details of understood algorithms, possible key lengths, etc.
• ServerHello - agrees highest level of security, key length, etc.
  
• Server sends x.509 Certificate based on levels agreed.
  
• The server MAY also send CertificateRequest to the client
• ServerHelloDone

Handshake

• ClientKeyExchange - swapping of primes as above depending on chosen algorithm and key length.
• The Client and Server then compute a common secret called the “master secret”.
• Client sends ChangeCipherSpec “everything I tell you from now on will be encrypted.”
• Client sends encrypted Finished message
• Server sends ChangeCipherSpec and encrypted Finished message.

Session starts.

You will see at the beginning of the handshake there is an RSA key exchange Somewhere in the middle I made the statement: “The private key is kept safely on each party’s hard drive.”

The eagle-eyed security boffins amogst you will have spotted a problem there. Of course, the hard drive is not secure, and this is why we need HSMs for security.

The reasons behind HSMs becoming popular are not solely because they provide such great security however, we all know that would be too good to be true. It took a far more practical use to make them popular. I will pick this up tomorrow. In the meantime some more feedback about what you want to cover is appreciated.

Popularity: 28% [?]

Although we have discussed encryption and the PCI requirements before, many people still do not understand how to properly implement secure encryption systems. So, this post is aimed to make this as simple to understand as possible by answering the common questions that people ask.

What encryption algorithm should I use?

For someone not used to the field, cryptography presents a confusing array of options. However, the choice is really very simple. Use AES. The old saying of ‘No one ever got fired for buying IBM’ applies to cryptography too; no one is going to get in trouble for using AES. AES is the official encryption algorithm of the US government, and information encrypted with it is considered secure beyond 2030 (see Table 4, page 66).

There are only two excuses for not using AES - either because your system does not support it (which is very unlikely), or you need to use something else for backward compatibility. In this case, try your hardest to use triple DES. However, there are lots of ways to use triple DES badly, and it is just not worth it unless you absolutely can’t use AES.

What key length should I use?

This is easy too. If you are using AES, it doesn’t really matter - any of the key lengths (128, 196, or 256) will keep your data secure to the point where it would be easier to bypass the encryption in some way (eg steal the key). Bear in mind that the NSA has approved AES with a key length of either 196 or 256 bits for securing TOP SECRET data.

If you are forced to use triple DES, use a key length of 128 bits (actually only 112 bits are key material, but let’s not get too confusing). Store and handle this as a single key. DO NOT split it up. DO NOT think of them as two separate single DES keys. If this is too hard, beat up your vendors and throw away legacy systems and use AES.

How do I generate keys?

Randomly. DO NOT generate keys from passwords/passphrases. DO NOT get people to ‘think up’ key values.

Openssl is one way to do it if you don’t have access to a HSM or other hardware random number generator - “Openssl rand -out rand.bin 16″ will generate 16 bytes of random data and place it in the file “rand.bin”. Open this in a hex editor (or view it with xxd in linux) and you have your key. Use a linux liveCD distro so that there are no remnants of the data when you turn off the PC. If you want split knowledge (*cough* requirement 3.6.6 *cough*) get two (or more) people to generate random data and XOR it together to create the key. Each set of random data used in the XOR is called a “key component”.

How do I backup my keys?

Either encrypt them with another key of at least the same length, or split them up into key components. If you are using components, store the components on separate pieces of paper, smartcards, or some other media. Lock the different media in separate lock boxes, and store them in the company safe.

If your key is encrypted with another key (which is well managed), you can write it on the outside wall of the corporate headquaters, and put it on your business cards.

Do I have to use a HSM?

Ahhh, the controversy. For the uninitiated, a HSM is a Hardware Security Module - a box that goes into a computer, or sits on your network, or plugs into a USB port - that stores keys and does the encryption for you. The world of credit card data would undoubtedly be a more secure place if everyone used a HSM. If you can afford one, or if you think you cannot afford one but are handling a large number of transactions, use a HSM. It will probably pay for itself by just making compliance that much easier. However, it is not necessary to use a HSM.

Having said that, I strongly recommend that you calculate the cost of not having one before you dismiss it - especially if you’re going to have a competent QSA picking their way through your systems.

That’s my take on PCI DSS encryption for Dummies. I sincerly hope that this helps someone out there, and if you take away anything from this please, please, please, use AES.

Popularity: 33% [?]

The new sites have been awash this week with reports (here, there, and everywhere) on how the TJ Maxx credit card compromise is shaping up to be the worst ever - just tipping the scales on the CardSystems compromise from a few years ago.

The SEC filing that has inspired these articles has some interesting information on the compromise. Searching for “COMPUTER INTRUSION” will get you to the section that talks about the events prior, during, and subsequent to the event. Quotes that stand out to me (all emphasis is mine):

“We do not believe that customer personal identification numbers (PINs) were compromised, because, before storage on the Framingham system, they are separately encrypted in U.S., Puerto Rican and Canadian stores at the PIN pad“

“For transactions after April 7, 2004 our Framingham system also generally began encrypting (meaning substituted characters for the actual characters using an encryption algorithm provided by our software vendor) all payment card and check transaction information.”

“Further, we believe that the Intruder had access to the decryption tool for the encryption software utilized by TJX.”

“Losses that we may incur as a result of the Computer Intrusion include losses arising out of claims by payment card associations and banks, customers, shareholders, governmental entities and others; technical, legal, computer systems and other expenses; and other potential liabilities, costs and expenses. Such losses could be material to our results of operation and financial condition.“

What does all this mean? It means that the PIN Pads are using banking system encryption (almost certainly 3DES) and key management and the intruders have not been able to compromise this. Therefore, the PIN blocks are safe.

However, the comments imply that the POS system was using custom encryption - or at the very least bad key management - which has been compromised. Remember - PCI DSS requires you to use dual control and split knowledge and proper key management practices to manage your keys, and it also requires you to use good cryptography. Never use custom crypto.

The final comment is for all of you who think that PCI DSS compliance is not worth the cost. TJ Maxx is facing losses that “… could be material to our results of operation and financial condition. ” Is not complying with the PCI DSS requirements worth risking your entire business for?

Update: Ambersail reports it’s all over the BBC as well. This story has hit all corners of the globe, and merchants everywhere should be addressing PCI.

Further Update: Cambridge security labs LightBlueTouchPaper blog has some more news from a British perspective.

Popularity: 52% [?]