Securing Your Data With Actian Vector, Part 3

Following up on my second blog post about Actian Vector’s functional encryption capabilities, this next blog post in the series on data security explains the different encryption keys and how they are used in Actian Vector.

Understanding Different Encryption Keys

The encryption method generally used in Actian Vector is the 256-bit variant of the Advanced Encryption Standard (AES). AES requires an encryption key, and for 256-bit AES, this key is 256 bits long. A longer key means better security. Currently, 256-bit AES is considered “secure enough” and 256 bits is the maximum key length defined for AES.

In Actian Vector, database encryption is a major use case of encryption. As described earlier, its implementation uses different encryption keys for different pieces of data. Besides database encryption, there are also other uses for encryption in the database server, and therefore, still different keys are used for these. And all these encryption keys must be secured.

To provide sufficient security, encryption keys must not be easy to guess. Therefore, encryption keys are usually randomly generated. This makes them secure, but difficult to remember (few people can easily remember a sequence of 32 random bytes). A common solution is to protect encryption keys with a passphrase, where a prudently chosen passphrase can be sufficiently secure but still easy enough to remember.

Still, it would not be safe to use a passphrase directly as an encryption key. Instead, an encryption key gets derived from the passphrase, and advanced algorithms exist for this derivation process to make sure that a secure enough key is the result.

Actian Vector uses Password-Based Key Derivation Function 2 (PBKDF2) for this purpose. PBKDF2 is part of the RSA Laboratories’ Public-Key Cryptography Standards series. This illustration shows the process:

How Keys are Generated, Secured, and Used for Database Encryption 

An individual “main key” is randomly generated for each database. To store the main key securely, it is encrypted with the “protection key.” This protection key results from the passphrase being processed by the PBKDF2 algorithm. The protection key does not need to be stored anywhere because its derivation from the passphrase can be repeated whenever the protection key is needed.

The “database key” for the database encryption is then derived from the main key. Because the main key is already randomly generated, an internal method that is based on a Secure Hash Algorithm (SHA) derives a sufficiently random database key without the need for the more complex PBKDF2 algorithm.

Likewise, other keys for different purposes are derived from the main key. These derived keys are not persisted, but they are kept in memory only. On the other hand, the encrypted main key is persisted, but the decrypted main key is only needed to derive the database key and other keys. Afterwards the decrypted main key is removed from memory.

The database key is used to encrypt and decrypt the container of the individual “table keys.” These table keys are randomly generated for each table and used to (finally) encrypt and decrypt the user data in tables and indexes. Because the table keys are randomly generated, they also need to be persisted and with that, secured by encrypting them with the database key. The container where the table keys are stored also contains other meta data for the database, and therefore it is also secured by encrypting the whole container, rather than individually encrypting just the table keys.

The database administrator can change the passphrase for a database, as well as rotate the main key or individual table keys. I’ll share more on this in later blog posts on key management.

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.