Securing Your Data With Actian Vector, Part 5

The previous blog posts in this series explained the concepts of “Encryption at Rest” and the different encryption keys used for it. With all of these various keys at play, the question is, “How  can and should these keys be managed?” Fortunately, in Actian Vector, many parts of this task are performed automatically by the database server, and the administrator is mainly concerned only with the passphrase.

Managing Encryption Keys for Encryption at Rest

Changing only the passphrase

The most frequently performed task of all key management is changing the passphrase for a database. Regularly changing the passphrase can well be considered good practice because a compromised passphrase would allow unauthorized access to the database after it was locked.

However, chances are much less that a compromised database passphrase also causes the keys that it protects to be compromised. The keys are stored internally in the database server and their storage location is not accessible with the database passphrase alone.

Access to the machine running the database server as well as appropriate file access rights also would be required to get to the encrypted keys, which then could be decrypted using the passphrase. Therefore, most of the time changing only the passphrase should provide sufficient security. Situations that also require changing the keys can occur but should happen rarely.

From Actian Vector 7.0 onwards, every database has a “main key” and therefore also a passphrase to protect the main key. In previous versions, only encrypted databases have a passphrase to directly protect the “database key.” To keep the behavior compatible with previous versions of Actian Vector, Actian Vector 7.0 handles the passphrase differently for encrypted versus non encrypted databases:

For encrypted databases:

• When creating an encrypted database, the passphrase for the database is required from the user.
• The creator of the database has to remember the provided passphrase to be able to lock and unlock the database later.
• After creation, the database remains unlocked until it gets actively locked with the passphrase, or until shutdown of the database server.
• After a restart of the database server the database is locked and needs to be unlocked with the passphrase to make it accessible. This is because the database key derived from the main key is stored only in memory and is “lost” when the database server is shut down. Upon startup, the passphrase is needed to decrypt the encrypted main key so that the database key again can be derived from the main key.
• The database can be locked manually with the passphrase.

Non encrypted databases:

• When creating a non encrypted database, no passphrase is required from the user. Instead, a random passphrase is generated internally, obfuscated, and stored. This is also referred to as “stashing” of the passphrase.
• The creator of the database does not know the passphrase and therefore does not need to remember it.
• The database does not need unlocking because it remains always unlocked, even after a database server restart. This is because the database server internally uses the stashed passphrase.
• It is not possible to lock the database manually.

This non encryption is the default behavior in Actian Vector 7.0, which from a user’s perspective is compatible with earlier versions. In Actian Vector 7.0 this default behavior can be changed by enabling or disabling the stashing of the passphrase. More on this will be shared in a later blog post on “Stashing the passphrase.”

How to change the passphrase for an encrypted database

With the default behavior it is possible to change the passphrase for an encrypted database. The minimum length for a passphrase is eight characters, and the maximum is 512 characters. To change the passphrase, the DBA connects to the unlocked database and issues the following SQL commands:

SET AUTOCOMMIT ON;

ALTER PASSPHRASE ‘<old passphrase>’ TO ‘<new passphrase>’;

The DBA has to remember the new passphrase. The old passphrase is needed when restoring a database backup that was taken before the passphrase change.

Autocommit must be switched on as a prerequisite for the ALTER PASSPHRASE statement. The ALTER PASSPHRASE statement checks whether the old passphrase is correct. If so, the old “protection key” is derived from the old passphrase and the encrypted main key is decrypted with it. The new protection key is derived from the new passphrase, then the main key is encrypted with the new protection key and then stored again. The main key itself is not changed. It is only protected with a new protection key. As only the main key needs to be decrypted and re-encrypted, just changing the passphrase is a quick operation. This is depicted in the following graph:

The changed elements are shown in red. Because  the main key itself is not changed, also the database key and other keys derived from the main key are not changed. And with that, there is no need to decrypt and re-encrypt the data protected by these keys.

Passphrase Security You Can Trust

Changing a database passphrase in Actian Vector is both straightforward and secure. Because the underlying main key remains unchanged, DBAs can refresh protection without introducing unnecessary complexity or risk. This balance of strong encryption with operational simplicity helps organizations maintain best practices in data security while keeping day-to-day management efficient.

As always, keeping passphrases up to date is a critical part of a layered security strategy. With Actian Vector, DBAs have the flexibility to adapt passphrase policies to their organization’s needs, without disrupting performance or access.

In the next installment of this series, we’ll look more closely at rotating the main key in Actian Vector 7.0 and how it can simplify administration while maintaining robust security.

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.