4

I`m trying to implement key rotation in my system due to policy. In my system, the encrypted data is never deleted and has no expiration date.

I have encoutered 2 solutions:

  1. Generate new key, decrypt all data with the old key and then encrypt it with the new key.
  2. Encrypt master key with another key called 'A'(for example) and when I need to encrypt/decrypt data I use the master key, but for key rotation I only have to decrypt/encrypt the master key.

Solution number one is messy and with a lot of data it can be problematic and solution number two looking promising but if the master key never changes and I still encrypt the same master key, did I really do "key rotation"? or maybe didn`t I fully understand this solution?

Ofek
  • 41
  • 1
  • 2

2 Answers2

2

Key rotation policies can be... complex and bureaucratic, and the specific wording may dictate the method of rotation you must use, and how often it is done.

Method 1 is not just messy and computationally expensive, but it requires decryption of all data, increasing risk of exposure.

Method 2 is substantially more common, however you should be using more than 1 master key based on age. As old master keys expire, you reencrypt the subkeys using that master key with a new one. That way there is a not a period in time that requires you to change ALL keys at the same time, possibly within a specific timeframe dictated by policy that is now impossible to meet.

My terminology defines the subkey as the one which encrypts data, and the master key as the one which encrypts subkeys. This type of key rotation may meet the policy requirement.

Since encrypted data does not expire, I assume the data set grows over time. You should determine how many master keys can be reasonably managed, and if there will ever be a point where there are not enough for their subkeys to be reencrypted in a reasonable period of time before the next master key needs to be changed. If you are maxing out a CPU 24/7 to change keys you have a problem.

If policy dictates you must change the data key, the key rotation period may be different than that for a master key, and using both types of key rotation will save a lot of compute resources if the data key period is longer.

If you or someone else has the power to creatively interpret policy, you can use layered encryption and last-access-times to manipulate key rotation schedules. For example, a master key rotation period may start the first time it is accessed for decryption of a subkey.

If you are actually looking to increase security through key rotation rather than just meeting a policy requirement, they master keys should all be secured through hardware encryption in a way where they are never directly exposed, and access should be tightly controlled and logged. Sloppy key rotation only adds more opportunity for data to be exposed.

Richie Frame
  • 13,278
  • 1
  • 26
  • 42
0

The primary purpose of the key rotation is limit amount of data encrypted using the same key. Re-encrypting all the content (or data keys) would actually nullify the whole purpose of the key rotation.

You could search how cloud providers (aws, azure, ibm, google,..) manage the key rotations.

Each encrypted content as well contains key id (and version) used to encrypt the data. Key rotation means creating a new key version, while keeping the old key material to decrypt the older (existing) ciphertext.

gusto2
  • 1,194
  • 7
  • 14