Securing Your Data With Actian Vector, Part 6

The previous blog post in this series explained how to change just the passphrase for an encrypted database in Actian Vector. While in most cases this satisfies security requirements, it is also possible to change the “main key.” This causes the metadata for the database to be re-encrypted with a new key.

Managing Encryption Keys for Encryption at Rest

Rotating the Main Key

Instead of only changing the passphrase in Actian Vector, it is also possible to change, i.e. “rotate” the main key.

This operation is performed together with changing the passphrase. The ALTER PASSPHRASE SQL statement is used, where additionally specifying the option WITH NEWKEY changes the main key by generating a new random value for it.  Because the “database key” and other keys are derived from the main key, these keys effectively change as well. In turn, this means that everything encrypted with these keys must be decrypted with the old keys to be re-encrypted with the new keys.

For database encryption, the whole container of the “table keys” is encrypted with the database key rather than just the individual “table keys” in the container. Because this container not only holds the table keys, but also a lot of different metadata for the database, the container can be quite large, and decrypting and re-encrypting all its content therefore can be a slow operation.

Besides, the metadata in the container with the table keys also includes database logging information. The re-encryption of this metadata due to a main key change affects the log rollforward during a database restore: the log rollforward cannot be performed beyond the point of a main key change.

Therefore, performing a new full checkpoint (i.e. database backup) is recommended after changing the main key to ensure that valid database backups are available. In addition, to be able to start a restore from a database backup taken before a passphrase change requires the old passphrase that was in effect at the time the backup was taken.

Changing the Passphrase and Rotate the Main Key

Table keys are not changed when changing the main key and with that, the user data in tables and indexes is not touched. The following SQL statements change the passphrase together with the main key:

SET AUTOCOMMIT ON;
ALTER PASSPHRASE '<old passphrase>' TO '<new passphrase>' WITH NEWKEY;

The DBA has to remember the new passphrase.

The old passphrase is checked for correctness. Then the old main key is decrypted with the old “protection key” derived from the old passphrase. The old database key (still in memory) is used to decrypt the container with the tables keys. A new main key is generated randomly. The new database key is derived from the new main key and used to re-encrypt the container with the unchanged table keys.

The new main key is re-encrypted with the new protection key derived from the new passphrase. The new encrypted main key is then persisted. The new database key and new other keys also derived from the new main key are kept in memory.

The following graphic depicts the effect of changing the main key:

The encryption of the table keys changes as the whole container of the table keys is re-encrypted with the new database key. But the table keys themselves remain unchanged, and with that the encrypted user data in tables and indexes is not touched.

When Should You Rotate the Main Key?

In general, the primary purpose of rotating an encryption key is to reduce the amount of data that is encrypted with a single key. In case of a key compromise, this reduces the amount of leaked material. This applies well to communication encryption where in the stream of communicated data the key rotation, during the communication, changes the encryption of the following data. However, with data at rest, key rotation means that the existing data gets decrypted with the old key and then right away encrypted with the new key–the amount of encrypted data remains the same.

With that, for data at rest encryption the most important case for immediate key rotation is when the key was compromised or is suspected to have been compromised.

Of course, if regular key rotation is required for compliance with external requirements, then there is not much choice other than following the prescribed procedures.

Besides these situations, the individual circumstances should be considered carefully to determine what intervals for key rotation are sensible. These include factors like how often existing data is updated, how much data is added over time, how long it takes to perform the key rotation, what it means for backup and restore handling, etc. A general one-size-fits-all recipe does not exist.

About Martin Fuerderer

Martin Fuerderer is a Principal Software Engineer for HCLSoftware, with 25+ years in database server development. His recent focus has been on security features within database environments, ensuring compliance and robust data protection. Martin has contributed to major product releases and frequently collaborates with peers to refine database security standards. On the Actian blog, Martin shares insights on secure database server development and best practices. Check his latest posts for guidance on safeguarding enterprise data.