PCI Requirement 3.6.4 – Cryptographic Key Changes at Cryptoperiod Completion

by Randy Bartels / July 28th, 2017

Encryption keys have a lifespan. PCI Requirement 3.6.4 states, “Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher-text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines.”

Cryptoperiods are a major topic when discussing key management. So, what exactly is a cryptoperiod? A cryptoperiod is not a period of time, like a month, week, or year. Rather, a cryptoperiod represents the number of transactions that a key is valid for. There are multiple factors that define a cryptoperiod. For example, key length, key strength, algorithms, and exposure – all of these elements factor in. The result of these factors is the cryptoperiod. If a key is not rotated at the end of its lifespan, it becomes weak and vulnerable.

It is not the assessor’s job to define your cryptoperiod, but it is up to the assessor to determine if your organization knows the reason behind your defined cryptoperiod. If you tell an assessor that your defined cryptoperiod is a year, they want to hear more than that. They want to hear why it’s a year. For example, let’s say your key is valid for one thousand transactions and your organization does one thousand transactions in a year. That means the reason your cryptoperiod is a year because you do one thousand transactions per year. Let’s say your key is valid for one million transactions, but you do two million transactions per year. This means that your cryptoperiod is six months, so the key should be rotated twice a year. Assessors aren’t just looking for what the defined cryptoperiod is; they want to hear the why as well.

“When developing these keys and put them into production, understand that the encryption keys that you’re using have a given lifespan. When we specifically look at the requirements within 3.6, it states that you must rotate the keys at the end of their defined cryptoperiod. So if you’re using encryption in your environment, your assessor should be asking what your defined cryptoperiod is. Once again, it’s not up to us as assessors to define what your cryptoperiod is, but it is up to us to determine if you’ve done your due diligence around the time period that you use your key.

If I come in to assess your organization and I say, “Hey Johnny, what is your cryptoperiod?” and you say, “Well Jeff, our cryptoperiod is every year and we rotate the key then,” I might say then, “Fine, that’s great. How did you define your cryptoperiod to be a year?” If you answer, “Just because that’s what’s done,” or “That’s the way it’s always been done,” isn’t typically enough. Understand that a cryptoperiod does not necessarily define a period of length. A cryptoperiod is not a month, a week, a year, three years, six years, whatever. A cryptoperiod is typically a number of transactions that a key is good for. So as to give an example, you need to take in multiple factor.

I would recommend that you do some Google-searching on defining a cryptoperiod. But effectively what we’re going is we’re taking the key strength, the key length, the encryption algorithm that we’re using, the exposure to the key – there’s multiple variables that go into defining what a cryptoperiod is. So, we kind of take all of these numbers and we crunch them and the output of that is not a month, a year – it’s a number of transactions. The output of your numbers might say, “This encryption algorithm key that we have is good for a thousand transactions,” or it might be good for one transaction, or it might be good for a million transactions. So now that we have the number of transactions that the key is good for, then we have to look at how many transactions you process in a year. If your key is good for a million transactions and you do a million transactions a year, then you can rotate that key out every year because the cryptoperiod is a year.

But let’s say the defined cryptoperiod is a million transactions, however you do two million transactions per year. After that one millionth and one transaction, that key has become weakened and we would expect you to rotate the key out at that point. In that scenario, that cryptoperiod is really six months rather than a year. So as assessors, what we’re looking for is not just that you have defined a cryptoperiod. We really want to get our hands around what you’ve done to define that cryptoperiod. So, after that has been defined, then we’re going to ask you for evidence that you key has been rotated. This evidence can be a change control or some artifact that shows you’ve rotated the key. At no point ever should your assessor ask to see what you encryption key is, see what the old one is, or see what the new one is. They should just be looking for evidence that they key has actually been rotated. “