Encryption for PCI Compliance
May 1st, 2007 by pinsecurity Posted in Encryption, PCI DSS
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.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
30 Responses to “Encryption for PCI Compliance”
By E.K. on May 1, 2007
“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.”
Sorry, could you explain that a bit more clearly.
By pinsecurity on May 1, 2007
For E.K.
Data encrypted under AES is secure, as long as you use good key management. It cannot be decrypted without the key, and if the best way for the bad guys to figure out the value of the key is to run through all possible values, then it is secure well into the future. It just cannot be done - a 196 or 256 bit AES key is even secure against current algorithms using (theoretical) quantum computers.
So, if you encrypt your data key (lets call it a DEK) with another key (lets call it a KEK), using AES and a randomly generating the KEK, then your encrypted KEK is _secure_. You can tell the encrypted value to anyone and everyone, post it on hacker forums, and it will _still_ be secure. As long as the KEK is random, it is ‘computationally infeasible’ to determine its value.
Rather than trying to figure out the value of the key, it would be cheaper and easier for the bad guys to hire a mercenary army to fly into your corporate headquaters in stolen stealth planes, pump sleeping gas through the air-conditioning to knock everyone out, and then blow up the compay safe to get your key components, then restore everything back to exactly the way it was so that no-one knows what’s happened.
By Michael Dahn on May 1, 2007
I’m very happy to see this post because I think people do not understand the details of the encryption requirement.
The QSA assessor must decide the efficacy of each algorithm and key length, which of course should be based on ‘industry best practices’. I’m happy we now have some guidance for QSAs on what they should be looking for.
Question: If you were to make a suggestion for updating the standard, which location would you put for QSAs to find such information. (i.e. requirement 2.2 was updated to mention CIS, SANS, NIST, etc.) Would you point people to the NIST website for a list of acceptable algorithms and key-length?
By pinsecurity on May 1, 2007
NIST SP 800 57 referenced in the above post is a good source of information, if the ciphers secure to 2010 are used. To summarize the information the ciphers that are OK are:
Cipher Key length
AES 128,196,256
3DES 128,196
Diffie Hellman L = 1024
N = 160
RSA 1024
ECC 160
3DES key length includes parity bits
For D-H; L = public key, N = private key
RSA key length refers to the modulus
ECC key length refers to the order of the base point G
I would also add RC4 _only_ if it is used in SSL3 or TLS, simply because it is there and being used. It should not be a preferred algorithm.
For hashing, use SHA-1 or one of the SHA-2 variants. Do not use MD5 for new systems, and try as hard as you can to phase it out of old systems.
By Pat on May 2, 2007
I’m worried about the ‘well managed’ KEK aspect. The KEK has to be stored somewhere too so how do you make that secure (use a KEKK:)?
I’m thinking of using a passphrase to generate the KEK; would that be compliant?
By pinsecurity on May 2, 2007
Pat:
Avoid generating keys with passphrases. This includes KEKs. If someone can get hold of the encrypted DEK, they can just brute force the passphrase to get the KEK. Once they’ve got the KEK, they can decrypt the DEK, and then all your data are belong to them. Generate components and store those components in a physically secure way - eg in separate lock boxes in the company safe.
By Pat on May 3, 2007
Unfortunately I need this to be automated, one process will encrypt a PAN into a DB and another will decrypt it into a bank file. My plan isn’t quite a human entered pass phrase:
A service will provide encryption to a couple of applications, when an application is registered with the service it will be given an identifier (which could be the KEK itself) which the service must be able to change into a KEK (I was thinking of hashing the identifier).
Anyone with knowledge of the identifier will be able to ask the service to decrypt a PAN the service has encrypted and the KEK which keeps the DEKs safe in the file system is, I think, going to have to be stored or be possible to generate from something that is stored in plain text.
This doesn’t stirke me as so differrent to an HSM where, from looking at the PKCS API, a PIN gives access to a key - the intention is to provide a common interface to the encyption that could be implemented using an HSM or TPM as well as the software version I’m writing at the moment.
Does this sound like a reasonable plan or can you give some advice on how to make it a secure software system?
Thanks,
Pat
By E.K. on May 3, 2007
Pat,
What you described sounds like you want an HSM. With an HSM, nobody ever knows what the KEK is (unless there is a really bad hardware failure). Your key custodians enter the key components into the HSM once, when it is initialized. The HSM generates the KEK from the components and uses it to encrypt and decrypt the DEK and possibly the data itself.
You can generate a separate DEK for each record and store the encrypted DEK with the data or in the HSM. This depends on your application design.
Your challenge now becomes verifying that the HSM is only decrypting data for authorized entities.
Pinsecurity is right about not using passphrases to enter the KEK. A simple pseudo-random-number-generator can be used to create the key components for the KEK. Since the components only need to be entered once, the custodians don’t actually have to remember their compoents. They write them down, put the paper in an envelope, and stick the envenlope in a safe.
To be really secure, the custodians should not actually have access to the safe without having to sign for what they get. And if you have 2 safes that work this way, nobody ever has access to both components at the same time.
By pablo1b on May 3, 2007
Pat,
Of course, it depends on what HSM you are talking about. But a good HSM box will never display the master key (the top level KEK of KEKs) in clear form. The PIN would allow you administration of the keys (activation, generation, destruction, extraction in components) but not displaying. A god HSM has very good physical and logical controls over the keys.
A really secure HSM, say, a FIPS 140-2 level 4 compliant box, would even protect you from EK’s mercenary army with stealth planes.
(a 140-2 level 4 is a standard for a military grade box that will destroy all keys in case of intrusion, having motion, radiation and temperature sensors).
Of course, most of us don’t need a lv4, but even a low grade HSM would be more secure than a software service running on a regular server where the tech support guy can steal the keys on a USB flashdrive.
Also, HSMs will take processing load from your CPUs, which depending on what you encrypt can be a lot.
Of course I don’t sell HSMs, but I think it makes sense for certain businesses to use them.
Regards,
Pablo
By pinsecurity on May 3, 2007
@ Pablo1b:
A good HSM _will_ never reveal any key it stores, manages, or uses regardless of its physical security. It will probably give out a KVC value of that key, but that’s about it. Most HSM products are pretty good these days in this regard.
FIPS140-2 level 4 certification is hard. Very hard. There are literally only a handful of products that have attained this level; most exist somewhere between level 3 and level 4 - this is often colloquially referred to as level 3.5.
I might do a post on HSMs and what alternatives exist, what the standards mean, and what potential purchasers should be looking for when buying, if there is a general interest in such a post.
@ Pat:
I’ll have a think about your situation and provide some feedback soon. What you are proposing sounds mostly fine, but there are probably some areas where it can be easily improved a bit. Give me some time to have a think about it.
By DAG on May 3, 2007
The problems:
1. Crypto is both tricky and dangerous at the same time. Mistakes are hard to detect and can be fatal if the wrong folks figure it out. Think insider job or leak.
2. Crypto protocols are even harder to get right than basic crypto. WEP is a great example. Smart developers. Good building blocks. Big oops. Think of a building failing because the bolts were inadequate.
3. Hashing is not nearly as well understood as basic crypto.
4. Random number generator (rng)s are generally freighteningly non-random. Most people don’t understand the different requirements for an rng and a cryptographically strong rng. The net is littered with the graves of home rolled rng based session ids.
The challenge for assessors and their clients is that anything that doesn’t use AES, or 3DES, and an HSM takes additional time to assess. Plus there is additional risk that you may get it wrong. Think of the old adage about “no one ever got fired for buying IBM”.
Home rolled is really scary. Woud you want to live in a neighbourhood with a home made nuclear reactor? (Okay EK might)
So your client has something else. Now what do you do?
They better have it well documented. You are almost certainly into compensating controls for parts of 3.6. Is there enough to:
- Satisfy you that the keys and the encrypted data can’t be lifted together.
- Ensure that they can answer all of the key management questions.
- By way of best practice, they should have a formal threat risk analysis that takes into account all of the PCI encryption and key management requirements.
- If they implemented their own version of AES/3DES, how did they validate it? If they use a library, are they tracking vulnerabilities against it?
- If it is in software it may be very hard to meet dual custody and split knowledge with preventive controls. Detective controls may be needed.
If you see weirdness, question it! By example, a vendor I knew was proposing a solution using a Rackoff Luby cipher (this isn’t one algorith but a family of ciphers. Additionally, there doesn’t appear to be recent research on it). I asked, why do this? Almost no one will recognize it. No brand recognition. A pain to justify. A competitve disadvantage.
If you see something other than an AES/3DES/etc. then you will need to do some research. Things like, any of the AES final candiates such as Twofish, or RC6. Blowfish and IDEA are probably OK. However, there is also the question of licensing. But the main issue is if there has been adequate public analytical testing.
Finally, if you’re rolliing your own. Consider the TCO. You must develop it, prove it, document it, maintain it, and defend it to your assessor every year. An HSM will be less risky and may have a lower TCO.
By pablo1b on May 3, 2007
EK,
I think a post on HSMs would be appreciated by many readers. How keys are managed using HSMs is a subject I think that can be matter of discussion (backing up signing keys used for non-repudiation, non exportable PrivK in PKI systems, stuff like that).
By the way, I’ve been following your posts for a few weeks now… good work!
Regards,
Pablo
By Pat on May 4, 2007
Thanks for all the input Guys.
To give you a bit more detail this isn’t an either or situatuion. The intention is to develop two encryption services with the same interface, one that uses software and one an HSM that our card processing software can interface to without caring about the underlying implementation.
Please note that 3.6 is promarily concerned with the DEKs. In the sw the DEKs will be randomly generated by a strong rng and stored in a file encrypted with a KEK and NEVER sent out from the service. This KEK is causing the problems. I’m now thinking I may need to input the KEK manually (under split control etc) and keep it in memory rather than storing it - a pain if a server needs rebooting but prehpas the only way…
I’d also be interested in a post about HSMs - from limited knowledge I don’t think they’re a golden bullet solution; if a hacker can access your system and read your DB I’d guess he could also run some software that will take the encrypted PAN and ask the HSM to decrypt it for him before downloading it to his own machine. All he’d need is to find out the PIN that allows you to use a cryptographic token which, to me, equates closely with the KEK I’m talking about.
By E.K. on May 4, 2007
Pablo and Pat,
You’re right that would make one or two good posts. The long answer is probably worth a post to the blog. The short answer is that Wikipedia is reasonably accurate on HSMs and PKI:
http://en.wikipedia.org/wiki/Hardware_Security_Module
http://en.wikipedia.org/wiki/Public_key_infrastructure
By Dimitar Misev on May 7, 2007
One question: If i use an additional key to encode/decode the main key (say 128bit) using AES, the additional key will obviously be shorter… Is this not downgrading security, as someone might break the shorter key and then get access to everything else? To me this algorithm has the same problem 3DES/DES/Blowfish have. The private key is its weak spot.
By pablo1b on May 7, 2007
Dimitar,
Why would it be shorter? The encryption of any key should be at least as strong as the encryption the key provides.
For example, you shouldn’t encrypt a 196bit AES key with a 64bit DES key.
When you say private key, you mean you’ll be using an asymmetric algorithm?
(some people use private for asymmetric and secret for symmetric).
By pinsecurity on May 7, 2007
@ Dimitar:
Using symmetric block encryption (eg AES, 3DES), then the ‘additional key’ (KEK) can be exactly the same length as the key you are encrypting, as Pablo1b has mentioned. Using asymmetric encryption (eg RSA), then the thing you are encrypting needs to be smaller than the modulus - but this is not a problem when encrypting symmetricy keys as they will always be much shorter than this.
@ Pat:
I’ve thought a bit about your situation:
Don’t send keys across the network, and don’t derive keys from passphrases. Instead, authenticate each application server using a channel response system. The idea here would be to ensure that someone just sniffing the traffic between the application and encrypting server would not be able to ask for PAN data to be decrypted. ‘Steal’ an existing (non-patented) challenge response protocol rather than invent your own.
Another way to do this would be to use a mutually authenticated SSL session between the application and encrypting server to exchange information. This would prevent sniffing, and the exchange of certificates would ensure authentication of each end. (Thinking about it, I like this system better).
Both of these systems are above and beyond the requirements of the PCI DSS, but if you’re developing something, you may as well get it secure. My rule of thumb based on a number of years of looking at other peoples stuff is that security is generally easy to build in, but damn hard to bolt on.
By Pat on May 8, 2007
Thanks Mr. Pinsecurity
By NickB on May 8, 2007
I would be interested in a HSM Post. Plus if there are any other otpions than using HSM’s. Do you need FIPS for PCI compliance? It doesn’t say anywhere in the standard.
By Rob Newby on May 10, 2007
A post about HSMs would be great, but it’s quite a broad subject. If we can get some more specific requirements then it will be easier to write something.
Briefly speaking, HSMs are there to protect the private key used in asymmetric crypto operations. The idea is that the key is created inside and never leaves the HSM (certainly in FIPS compliant ones anyway).
Erm, I could get lost writing more detail, so will post a brief history and explanation in a couple of posts this week… please let me know if it gets anywhere near what you are looking for! If not, one of us will go into more detail. I volunteer Mike.
By Psilocybeing on Mar 5, 2008
Many thanks for the brilliant post. The company I work for have recently had the need to become PCI compliant, due to moving away from ‘gateway’ payment systems, in favour of processing the payments ourselves. This of course calls for encryption on retained sensitive data.
After reading this post, I’m now happy knowing what kind of encryption I should be using, and the best practices in which to manage said key.
By Karthik on Oct 5, 2008
Does Vista Bitlocker encryption which uses AES is PCI Compliant?
Thanks in advance for the replies.
By Michael Dahn on Oct 10, 2008
@Karthik, I’m going to leave that question up to someone who better understands Vista Bitlocker.
One thing I will mention is that with the release of the latest PCI DSS requirements (v1.2) there are new specifications on acceptable encryption with an emphasis on “strong cryptography”.
By Pat on Oct 11, 2008
@ Karthik: I believe you need to document your key management processes. I’d be surprised if MS publish how keys are managed and if they don’t you’re going to have a hard time proving to the auditor the keys are managed securely.
By Jay Way on Oct 23, 2008
Folks, would the following be considered a ’split knowledge?’
You have the DEK that is managed by user1 who knows how to access sensitive info but needs DEK to do so. The DEK is then handed off to user2 who puts it into a system unbeknownst to user1 and locks it away with say, TrueCrypt. So, in this way, user2 has the key but won’t know what to do with it and user1 needs the DEK but won’t know where the DEK is except asking for it from user2? Of course, there’s going to be a backup user3 who knows how to get to the DEK, but I’m just trying to simplify the scenario.
By BKP on Oct 24, 2008
3.6.4 Verify that key management procedures require periodic key changes. Verify that key change procedures are carried out at least annually —- Does the annual key maintenance apply to SSL Certificates that get applied at a server level or is it specifics to keys that are used in encryption specifically of sensitive payment information?
By Cassandra on Nov 5, 2008
If the DEK is encrypted with a KEK, is dual control still required by PCI. In this instance the KEK is generated using a passphrase in conjunction with a value that is stored in the key management program’s executable (binary) files.
By Michael Dahn on Nov 6, 2008
@Cassandra I recommend you read the post on Split Knowledge and Dual Control: http://pcianswers.com/2006/09/03/dual-control-split-knowledge/
By Dobes Vandermeer on Feb 13, 2009
My main question about this is not answered by your post:
Where can I store the key that is used to encrypt/decrypt PANs?
For example, if I have a web application that charges credit cards, and I may restart this web application from time to time, can I store the encryption key on disk with the web server (say, the same location as my SSL private key) or is this disallowed by PCI?
Sorry if this is a dumb question …