March 2012

For those of you who play along on a daily basis, PCI DSS 2.0 has brought many clarifications and a few changes that merchants and service providers must contend with. And while we don’t see the “relaxing” of requirements very often in PCI, version 2.0 brought a much-needed relaxation in Requirement 3.6.4.

DSS versions prior to 2.0 required a minimum key rotation period of 1 year. So if you had 1 or 100 million records encrypted, you were required by the standard to rotate the key on an annual basis. Version 2.0 requires that you change the keys once they have reached the end of their defined cryptoperiod. And the establishment of this cryptoperiod should be based on industry best practices and cites the NIST Special Publication 800-57.

NIST SP-80057 notes many different factors that should be considered when establishing an appropriate cryptoperiod. Some of these factors may include:

• Volume of information encrypted
• Strength of the cryptographic mechanisms
• Retention period of the data
• Security function (data encrypting, key encrypting)
• Number copies of a key
• Overall architecture or design of the cryptographic solutions in production

In general, as the sensitivity of the data that is being protected by the cryptography increases, the length of the associated cryptoperiod should decrease.

Cryptoperiod: The timespan for which a cryptographic key is authorized for use.

PCI DSS Requirement 3.6.5 notes that cryptographic keys can be “archived” for decryption purposes. This is a very vague, yet important statement. There has never been any clear position taken by the PCI Security Standards Council that specifically states that data re-encryption is required as a part of a key changing process. When merchants or service providers go through a key rotation process they rotate the encrypting key and begin encrypting and decrypting any new data with the new keys.  While moving forward they are encrypting with a new key, but any existing data that is required by the business to be accessed must be decrypted with the old key. Unless all of the data is re-encrypted or otherwise protected, the old key must always be available for decryption as long as there is a business need to access the data up to the end of the retention period for the protected data.

Lets take an example. Say a merchant establishes a two year key rotation cycle for their keys based on risk indicators that are outlined in the NIST special publication. They use key 1 (K₁) to encrypt data for two years. At the end of the second year, they rotate keys to key 2 (K₂). However, as long as there is data that is encrypted with k_1, the key cannot be destroyed. K₁ will have to remain active until there is no longer a business need for the decryption of the data that was encrypted using K₁.

Does this mean that merchants and service providers can continue to rotate encryption keys and never address the topic of legacy keys that are readily available to decrypt legacy data? Let’s look further into that topic…

Key States

There are six different key states that are defined in the NIST SP 800-57 documentation. From pre-activation to compromised and beyond, however, for this post I would like to focus in on three specific key states:

Active Key State: The key may be used to cryptographically protect information or to cryptographically process previously protected information (e.g., decrypt ciphertext or verify a digital signature) or both.

Deactivated Key State: A key whose cryptoperiod has expired but is still needed to perform cryptographic processing is deactivated until it is destroyed. A deactivated key is not used to apply cryptographic protection to information, but in some cases it may be used to process cryptographically protected information. When a key in the deactivated state is no longer required for processing cryptographically protected information, the key is destroyed.

Destroyed Key State: Pretty much self-explanatory.

Table 1: Lifespan of a key

In the above table, we have a current cryptographic process that encrypts data for 2 years. The table indicates that that there is a 9 year data retention policy. Data is encrypted with a specific key for 2 years and then retained for an additional 7 years. As long as there is an immediate need to have access to that data, then the decryption key must still be retained in order to access the encrypted data.

Only when the retained data is no longer needed can we no longer require the decryption key. The true end of a cryptoperiod is not reached until the decryption key can effectively be destroyed.

The NIST special publication 800-57 supplies recommended cryptoperiods for different key types. Cryptoperiods will vary for each organization based upon many different elements that make up the overall risk of the keys and the protected data. But as an example, the document points out that the cryptoperiod is 2 or less years for a symmetric data encrypting and 3 or less years for the data decrypting key. That’s a total cryptoperiod of 3 years. Compare that with our above example of protecting data with a 9 year retention. Something’s got to give!

Data that is required to be maintained longer than the defined cryptoperiod of the keys should be protected with a key that has a new/valid cryptoperiod. That protection could vary depending on the architecture, but could come in the form of re-encryption of all of the data, or the rotation of key encrypting keys for example.

Although the PCI DSS does not require a data re-encryption process for legacy data, I highly recommend that organizations provide the appropriate due diligence in establishing appropriate cryptoperiods. Ensure that your cryptoperiods are in-line with your data retention policies. If you need to retain protected data longer than your cryptoperiod then you should establish a process to protect the retained data with new keys with fresh cryptoperiods. Mileage will vary for different organizations on the most efficient and secure way that you can accomplish this. But as usual, these roads continue to lead us back to the question we should all ask more frequently….”do we really need to keep this data?”