Rotating encryption keys - how does it work?
In layman's terms, rotating an encryption key implies:
- Generate new key(s)
- Re-encrypt all data that was encrypted using the old key, using new key(s)
- Delete old encrypted data and old encrypted key
Key rotation generally applies to data that is encrypted at rest, as opposed to something like TLS, because it reflects the need to deal with all the old stuff that's still encrypted with the old key.
The meaning of rotate is going to depend on your data owner’s security policy.
It may help to understand how keys are often managed in a key-management system using a key lifecycle state chart. A typical key lifecycle looks like this:
- Generated (new, not to be used yet)
- Active (encrypt/decrypt)
- Inactive (decrypt-only)
- Retired (key irrevocably destroyed)
According to this example, the starting state for all new keys is Generated. When it’s ready for use (perhaps once you’ve configured other systems to use it), you execute an Activate state change to promote it to Active. The key will be available for encryption and decryption.
Let’s say your data owner wants keys rotated annually. You would schedule a Deactivation event for one year after the key is activated, and when the time comes, the event fires and the key is transitioned into the Inactive state. Your system will probably also generate a new key at the same time, and activate it. That’s a key rotation. While a key is inactive, your system can still use it to decrypt old data, but it can’t be used to encrypt anymore — only the new key can be used for that.
Finally, when you want the data destroyed, you have a Retirement event, and the key is transitioned to Retired state, and the bits are wiped. Data recovery becomes very difficult, depending entirely on your ability to restore keys from backups, etc. And once your key manager executes a rotation on its internal Key Encrypting Key, it’s all over - the old keys are gone, and the old backups are useless.
This isn’t the only path, of course. Additional states can be defined for keys that are “suspect”, “lost”, and/or “compromised”. All kinds of rules regarding state transitions can be created.
Rules are defined regarding how and when a key will transition from one state to another, which transitions are legal, and when. You’ll also see a rule that if a key is compromised it will require all the data to be re-encrypted with a new key (among many other disaster recovery tasks.)
In some organizations a key rotation will require a rotated key to be changed to an inactive state, and a new version of the key will need to be generated for encrypting new data. When the new key is made active, the old key is made inactive. The old data remains encrypted with its same old key until the key is retired, and then the old key is destroyed. This way, the old data doesn’t have to be decrypted and then re-encrypted with the new key. The application consuming the data has to use the same version of the key that was used when the data was encrypted.
Other organizations may have no inactive state, and a key rotation will require the old key to be retired and all previously encrypted data to be re-encrypted.