I'm currently using AES 256 for the encryption of my web application and the security policy context specifies that the encryption key must be replaced once every few months.

When that happens what handling needs to be done in particular? What I read online suggests that I'll need to decrypt the existing encrypted data with the old key and then encrypt the decrypted again with the new key. This approach may not be an ideal solution for me as my web application may have to deal with big amount of data and the process above would take quite some time. Is there a better solution around this?

Thanks

  • What do you consider to be a "big amount of data"? – RoraΖ Sep 23 '14 at 18:43
  • Ranging from few to hundreds of GBs. Basically my concern here more towards the resiliency of the system if I were to use the decrypt-encrypt data approach (eg: what happens if the system fails in the middle of decryption?) – user1928346 Sep 23 '14 at 18:48
  • 3
    What exactly does the security policy say about replacing encryption keys? This is not a common requirement, and I don't see the security rationale: it smacks of security theater unless there are additional considerations. – Gilles Sep 23 '14 at 20:01

Encryption keys can have a cryptoperiod after which those keys shouldn't continue to be used for encryption. This may be due to security policies, due to an individual who knows a key component leaving the business, due to suspicion of an encryption key compromise etc.

Often, a business will use an encryption key (let's call this keyA) for encryption for X period of time. Following that period of time a new encryption key (let's call this keyB) will be generated and used for encryption. The encrypted data will be stored with a reference to the key it was encrypted with so the application knows what key to use for decryption. Using our naming above, keyA could be considered invalid for the encryption of new data but could be used for the decryption of data encrypted using that key. KeyB may currently be valid for both encrypting and decrypting data.

As your data is probably stored according to defined data retention periods, once legacy data is purged, older keys may also be removed as they are no longer required for the decryption of data.

Per your post, decrypting and re-encrypting large volumes of data can be time consuming and process expensive.

Why you do not do the decryption encryption on demand?

Not sure if that work for your case, but here is my thoughts. The data originally come to your web application as plain data right? Then you encrypt the data and store it. Let us assume the following scenario

  1. Today I upload file "My_Data1.txt" to your server you encrypt it using an AES key named "X1"
  2. "X1" will expire after 90 days from today, set 80 days from today as the recycling time of "X1"
  3. After 20 days I upload a new file "My_Data2.txt", again you encrypt it using "X1"
  4. After 80 days I wanted to access "My_Data1.txt", you decrypt it using "X1"
  5. I made some changes to "My_Data1.txt" when I request to store the file again on your server you will encrypt "My_Data1.txt" using a new key "X2"
  6. "X2" will expire 90 after the "X1" expired.
  7. Any user access to the encrypted data after the recycling point of the current encryption key trigger your decrypt with current key and encrypt with new key.

This will avoid the need to execute a huge encrypt/decrypt process for all the stored data at concurrently.

another options

  1. Dedicate another server to preform the encryption/decryption job, or
  2. Do the encryption at the client side (require a very caution design)

Finally, what is the security requirement behind this request. We may be able to suggest a better solution to avoid intensive decryption/encryption

You would go through the relatively arduous task of decrypting and re-encrypting data for only one reason: you believe the crypto key has been compromised, but the data have not, or the reverse.

If both data and key were compromised. you're toast. No amount of key-changing will save you.

If one of key or data were compromised, it might make sense to change the key and re-encrypt the data in case an attacker might get the other half of the puzzle somehow. However, this smells like "change your password every 30 days, Just In Case.)

You mentioned one risk of decrypting and re-encrypting, namely a failure partway through the process. You mitigate that risk by encrypting to new media. But, of course, the old media remain, encrypted with the old key. You have to destroy both the old data and the old key with acid, fire, and strong magnets when the process is completed, or you haven't really mitigated any risk. If this is an online system, there will be downtime or a read-only period during the re-encryption process. There may be other risks.

If you somehow rotate crypto keys so that at any moment some part of the data are encrypted with an older key and some with a newer key, as suggested in another answer, then some of the data are exposed in the event of a compromise.

As Gilles has already written, this smacks of security theatre. Whoever is responsible for the policy should describe the risks that will be mitigated through implementing it. You can then examine the costs and the new risks introduced and make an informed decision.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.