General key store basics

The goal of Transparent Data Encryption is to encrypt selected database objects. To be successful, the encryption must meet certain industry security practice expectations with regards to encryption key storage, access-controls, and administration. This section introduces the general concepts of key store implementations.

The purpose of encrypting data is to bar its access to all but a few designated individuals. This requirement spans both run-time and at-rest storage. Encryption security (strength) is measured by how much time and effort is required for an unauthorized individual to recover the clear-text data. The encryption algorithm used has little effect on cryptography strength because they are all open-source; you can obtain the algorithm and code samples from many sources. Encryption security comes from:

In a practical sense, encryption is only as good as the security of the encryption key storage and its access controls. A key store implementation is successful when an intruder is unable to coerce it into yielding the stored encryption key values and therefore must resort to a brute-force attack on the encrypted data.

A secure key store is usually its own entity and provides its own user authentication and authorization. Most low-level key stores use simple passphrase access control; mid-level key stores enforce strong passphrase access controls; high-level key stores use stronger methods of access control such as LDAP, Kerberos, biometrics, or digital certificates.

There are no fixed rules or guidelines that influence the design of a key store and its physical storage. The majority of key store implementations are required to handle several hundred encryption keys and a small number user accounts. Portability is generally a key store priority as encrypted data is platform neutral and is simply copied from system to system. The key store must be capable of being transported from system to system, along with the encrypted data, using simple file copy operations. Most key stores rely on the underlying file system for robustness and disaster recovery.

Key stores fall into two general categories: single user and multi-user. Single user key stores store encryption keys for a single entity. A private key store usually has a single user account that provides all-or-nothing administration and encryption key access privileges. As a personal key store, it does not have to protect itself from multiple simultaneous processes or thread access. A multi-user key store has multiple user accounts and must survive in an environment where multiple processes and process-threads will compete for simultaneous access. Therefore, a multi-user key store has an administrator account for administration tasks and one or more user accounts for users who need access to encryption keys for their applications. The best practice for a key store is to be open as short a time as possible. The combination of short open times and very infrequent writes requires minimal file locking support, which is typically in the form of exclusive write access.

A key store always has the ability to store multiple encryption keys and provide a basic level of bookkeeping for them. All encryption keys eventually live past a useful lifetime, after which they are retired and replaced by a newer one. Typical bookkeeping includes items such as create and update history and active/retired status.

Key store access control is a high priority. First, encryption is used to protect the encryption keys and user accounts from intruders. Second, user access control grants access to an encryption key value only after a user has successfully entered their user-id and secret (most often a passphrase or equivalent). However, this can be in conflict with a business need to start an application (and access the encryption keys) without human intervention. Various means are used in the industry to provide an application "unattended startup" feature where the application can automatically access the key store and perform encryption. Many industry experts view "unattended startup" as insecure, but the practice remains as in many cases it is a business necessity.

A stored encryption key is simply an array of binary byte values. Encryption operations will not fail when you give it the wrong encryption key, you simply end up with random binary garbage. Therefore it is very important for the key store to provide the application with the ability to ensure that it is accessing the right encryption key. Most times this identification is provided by unique identifiers, but can also take the form of simple "alias" names.

Like any passphrase access controlled entity, a key store suffers from the classic "lost password" syndrome. When a key stores data is physically encrypted using a user account password, the key store is irrevocably lost when the password is lost (and subsequently the data is lost).