1

I want to improve the encryption flow used by my application. Today I use the AES cipher while its key and its IvBuffer are hardcoded in the code. I know it is not secured and I want to improve this. I want to create a new AES cipher while its key will be stored in the database. The key will be encrypted by the old AES cipher.

Application will use the new AES cipher:

  • Decrypt the key for the new cipher using the old cipher.
  • Encrypt / decrypt information using the new cipher using the decrypted key.

The flow will allow easier key rotation in the future (I can elaborate it but it is not related to my question).

How the encryption process is secured?

What to do with IvBuffer for the new AES cipher? To store it in the database or to put hardcoded in the code?

Added

I understand from the answer below that the additional hardcoded key does not improve my security. I need store the encryption key in the database (option 7 listed here Where to store a key for encryption?). Unfortunately I can not use external devices for the key storage and therefore I need to use database.

Question if the security of the option when key is stored in the plain text in the database is better that the option when additional hard coded key is used for the same key stored in the database?

Community
  • 1
Michael
  • 1,457
  • 1
  • 18
  • 36
  • In general, don't store keys or IVs in source code. Grab it at runtime from a secure configuration, environment, or similar. – Scovetta Feb 17 '17 at 06:55

1 Answers1

3

If I understood you correctly, you want to continue using the old key, which remains hard-coded, but only use it to encrypt AES keys, which are then used to encrypt and decrypt your data.

This does not improve your security. The vulnerability in your old design is that the key and IV are hard-coded. If you encrypt the new key with the old key, that adds an extra layer of complexity (because you need to handle multiple keys) but it doesn't actually fix the issue you had (hard-coding a key). If you want to do key rotation, as you say, you should replace the old key with the new one after re-encrypting the data you used to encrypt with the old cipher.

As far as the IV goes: from a cryptographic standpoint, as long as IVs are unique per encrypted text, these are public. For example, in CBC mode, the IV is just the first input that you XOR onto the plain text; for all subsequent blocks, the cipher text of the previous block is used for that. What matters is freshness.

Alternatives to hard-coding

Storing your key in a database is better because you at least have the ability to change the key later. If you properly protect the database (i.e., password protection and encryption), that could be a reasonably secure solution. However, it is likely easier to use an existing library that stores your key in a file, protected with a passphrase. That would mean that to access the data, your logic would consist of:

  • get the passphrase
  • extract the key from the file using the passphrase
  • discard the passphrase from memory
  • decrypt the data using the key, encrypt and write any new data
  • discard the key from memory

You can likely get all the passphrase stuff done using a library. I recommend you open a second question if you've got more questions about that topic.

Rens van der Heijden
  • 615
  • 4
  • 8