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

If your organization is storing PCI-related data using encryption, those keys must be stored securely, as PCI Requirement 3.6.3 commands, “Secure cryptographic key storage.” If your key storage is securely stored, has the appropriate protections, and access is limited to the fewest number of people and locations as possible, you prevent your organization from being susceptible to an attack. The PCI DSS further explains, “The encryption solution must store keys securely, for example, by encrypting them with a key-encrypting key. Storing keys without proper protection could provide access to attackers, resulting in the decryption and exposure of cardholder data.”

You assessor should test your compliance with PCI Requirement 3.6.3 by examining your organization’s key management program and its procedures and methods to verify that they specifically outline and implement that secure storage of keys.

Once again, if you’re encrypting information, whether this be PII, PHI, PCI-related data, if you have implemented encryption as a part of this methodology, we want to make sure that those keys you’re using are stored securely. We want to make sure that access has been limited to the fewest possible number of individuals. You need to have protections around them so that in the event that somebody should compromise the server, they don’t gain access to the encryption keys or the decryption keys themselves.

So, your assessor is going to be working with you and asking how you’ve gone about doing that. They’re going to be looking at your documented procedures for secure key distribution and secure key storage and how that rolls out. If you have an HSM in a FIPS-compliant device, the controls that are there are pretty much established by the technology. In short, once again, where you are storing these keys, they need to be stored securely.

PCI Requirement 3.6.1 requires, “Generation of strong cryptographic keys.” It also requires that, “The encryption solution must generate strong keys, as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms under “Cryptographic Key Generation.”

The intent of PCI Requirement 3.6.1, according to the PCI DSS, is to “significantly increase the level of security of encrypted cardholder data.” PCI Requirement 3.6.1 is part of the 8 sub-requirements of PCI Requirement 3.6, which is meant to build your organization’s key management program because, the PCI DSS states, “The manner in which cryptographic keys are managed is a critical part of the continued security of the encryption solution. A good key management process, whether it is manual or automated as part of the encryption product, is based on industry standards and addresses all key elements at 3.6.1 through 3.6.8.”

We recommend that you perform a risk assessment around the generation of your cryptographic keys; this way, you can see if your keys become weakened or hold up. Industry standards, like NIST, should be used when determining how to manage and generate keys.

“If you’re using encryption within your environment, you need to use strong encryption. What this effectively means is that you need to generate strong keys. Once again, you need to be using an industry best practice for this. One of the things that I would recommend that you do as part of your risk management program, just like the annual risk assessment that you’re required to do, is that you perform somewhat of a risk assessment around the generation of your keys.

If during the period of time, your encryption keys become deprecated or weakened because of some change to the industry, you must have a process for generating a new key. We’ll be talking about that in a subsequent video. Specific to PCI Requirement 3.6.1, you have to have a process in place where you’re actually generating strong keys. IF you have an HSM, that’s kind of inherent in using the HSM itself. If you have a clear text process where you’re managing or developing these keys, it needs to be done securely. I would recommend that you look at industry best practices like NIST 800-57 for that information. “

PCI Requirement 3.6.2 states, “Secure cryptographic key distribution.” Whether it’s placing tamper-proof or tamper-evident packaging on trackable packages or tracking data that you’ve transmitted electronically, any method that your organization is using to transmit keys needs to be done securely. Whether it’s moving keys from generators into production state or to backup, any method that your organization us using to transmit keys needs to be done securely. To further explain what it means to securely transmit keys, the PCI DSS also states, “The encryption solution must distribute keys securely, meaning the keys are distributed only to custodians identified in 3.5.1, and are never distributed in the clear.”

“When moving the keys from the point of generation into a production state, or perhaps moving these keys to a place of redundancy or backup, the transmission of these keys needs to be done securely. This could be done on Sneakernet, where you physically walk them on a thumb drive. If you’re going to be transmitting them over mail, those particular packages need to be trackable and need to be tramper-proof or have tamper-evident packaging. If you’re going to be emailing them or transmitting them electronically, the data-encrypting key needs to be encrypted with a key-encrypting key that’s equally as strong. In short, 3.6.2 requires that you transmit keys securely, however you’re doing that. “

PCI Requirement 3.6 states, “Fully document and implement all key management processes and procedures for cryptographic keys used for encryption of cardholder data.” PCI Requirement 3.6 and its sub-requirements are meant to build your organization’s key management program because, according to the PCI DSS, “The manner in which cryptographic keys are managed is a critical part of the continued security of the encryption solution. A good key management process, whether it is manual or automated as part of the encryption product, is based on industry standards and addresses all key elements in 3.6.1 through 3.6.8.” NIST is a great industry standard to base your key management program off of.

Assessors want to see that you have controls surrounding the changing of keys, which is why we will look at your environment to see how you rotate and change keys, and how you prevent unauthorized access and substitutions. The 8 sub-requirements under PCI Requirement 3.6 outline what should be included in your organization’s key management program:

• PCI Requirement 3.6.1 requires, “Generation of strong cryptographic keys.”
• PCI Requirement 3.6.2 requires, “Secure cryptographic key distribution.”
• PCI Requirement 3.6.3 requires, “Secure cryptographic key storage.”
• PCI Requirement 3.6.4 requires, “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 (for example, NIST Special Publication 800-57).”
• PCI Requirement 3.6.5 requires, “Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component), or keys are suspected of being compromised.”
• PCI Requirement 3.6.6 requires, “If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.”
• PCI Requirement 3.6.7 requires, “Prevention of unauthorized substitution of cryptographic keys.”
• PCI Requirement 3.6.8 requires, “Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key custodian responsibilities.”

When we look at Requirement 3.6, there’s several sub-requirements underneath that, and we’ll be talking about those in the next set of videos. But effectively, what the PCI DSS requires is that you have a formal key management program. It’s just not enough to create these keys and use them in perpetuity. There’s numerous controls around the changing of these keys, altering them, preventing unauthorized access to them, or preventing unauthorized key substitution. There are several situations where we, as assessors, are going to want to look at your environment and see how you’ve rotated your keys – all of these things are going to be talked about in the next few videos.