PCI DSS and key rotations simplified

The PCI DSS (Payment Card Industry Data Security Standard) specification requires that the data encryption keys must be changed or "rotated" every so often. Here is a snippet from the PCI DSS 3.2 specification and I've highlighted the key sentence below:

Before we jump into details on how to do it, lets look at why this guidance exists.

Why should we rotate encryption keys?

Some would just say "because of PCI compliance" and skip to the next section. That's fine. But if you want to really know why, here are the benefits of key rotations:

• Limits the amount of information, protected by a specific key, available for cryptanalysis
• Limits exposure if a specific key is compromised (maliciously or unknowingly)
• Avoids certain cryptographic catastrophic failures (e.g. AES GCM mode loses protection if more than 64 GB is encrypted on the same key. See NIST SP 800-38D section 5.2.1.1)
• Protects against current or future algorithmic weakness that reduce key lifespan

How often should I rotate my keys?

For data-at-rest, key rotations should be done every few months. You want to do this more often if you

• have high volumes of data
• experience staff turnover
• have data that's high-value
• use a shared environment (e.g. public cloud or shared with other divisions)
• have motivated, capable adversaries that can benefit from the protected information

Organizations typically fail doing key rotation because "it's really painful". What makes it harder, is that if you look at the PCI requirement above (or any other best practice guidelines), you'll see that the keys to be rotated are the keys that produce cipher-text. These keys are called Data Encryption Keys or DEKs. DEKs are encrypted with a "parent key", typically called Key Encryption Keys or KEKs. Some organizations simply rotate the KEK, claim keys were rotated and call it a day. In reality, that is a burden without the security benefits because the underlying DEKs stay the same and continue to process additional data. Quite often, beyond the point of failure.

How does one rotate the keys?

First, realize that it's the actual data-encryption keys (DEKs) that need to be rotated out. Now you have to engineer a system that

• securely stores and distributes a multitude of Data Encryption Keys (DEKs) and their respective Key Encryption Keys (KEKs)
• authorizes decryption via older DEKs (Note: You could have a multitude of older DEKs)
• issues a new DEK that's cryptographically secure. We've seen some folks obsess over this one specific piece. While it's important, it's also the easiest part. So be sure to spend enough time on other aspects of the system.
• ensures that newer data is using only this fresh key, authorized for the current time interval
• tracks the dynamic mapping between every data fragment, it's data encryption key, their key encryption keys and the master encryption keys
  • you can have multiple versions of each of the above
• optionally, decrypt ALL older data and fully re-encrypt it onto the newest encryption key
• Every piece of this dynamic system should have authorization controls and audits in place
• All the above applies to all storage technologies such as SQL Server, Oracle, MySQL, PostgreSQL, NoSQL storages like Mongo, Files, Streams, Objects etc.
  • This is a very complex since each storage technology has it's own limitations and own security model
  • You really don't want to manage a zoo of different architectures; ideally a one-size fits all keep security manageable

This is the 30,000 feet view and as you can imagine, it's extremely intricate, costly and error prone. If you make a mistake, you can experience total data loss due to missing encryption keys.

That's hard. Is there better way?

You're reading this on Crypteron's blog, so you already know the answer :). Yes, there is a better way. A much better way. What if you could replace months and years of engineering and operational maintenance with just one click? Well, if you're using Crypteron to protect your data, you can. You see the "rotate" button below (pointed by the red arrow)? As a security manager, you just log into your Crypteron Dashboard and click that button. That's it - you've completed it! If GUIs aren't your thing, there is also a REST API for that same button. So you could automate your key rollovers each week or month and be done.

Best of all? Crypteron proof-of-concepts should take your team less than 30 minutes. An enterprise application integration is usually just a few hours. Finally, security that aligns CISOs and VPs of Engineering instead of them constantly fighting with each other on schedule and capabilities.

Behind the scenes: powerful orchestration

How can it be just that simple you say? Well, there is a lot of intelligence behind the scenes. The key management system issues a new key behind the scenes and all Crypteron agents powering your application notice this. By default, they will begin encrypting all new data with this new key. In addition, we have a feature, MigrateOnWrite, which will opportunistically migrate small chunks of older data when writing newer data to your databases - be it SQL Server, MySQL, PostgreSQL etc. The most frequently accessed data is migrated first. And all of this happens auto-magically without your developers having to write any additional code or your operations team having to perform an impossible juggling act. And your systems always stay online without any downtime.

Additional consideration

When personnel leave

PCI DSS also mandates that keys be rotated when personnel with access to encryption keys leave or are terminated. This is a nightmare if you're still using a manually driven key management system. With Crypteron, the actual data encryption keys are not exposed to any human operator. The figure below shows the rough separation of responsibilities enforced by Crypteron. Effectively, this means your life is a lot simpler when your staff retires or leaves or when new folks come on board.

Continuous key rotations

Crypteron can also issue a new key for every data fragment, which means the key is rotated upon every use. Our system automatically tracks all these DEKs - potentially millions or even billions of keys without any additional complexity at your end.

Conclusion

We hoped this reduces some confusion on the key rotations and how to solve them quickly and efficiently. If you have more questions, please don't hesitate to contact us -  we're eager to hear your real-world stories.