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 topic introduces the general concepts of keystore 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:

  • The size of the (binary) encryption key
  • The randomness of the encryption keys value
  • The user access controls that limit the encryption keys value to use only by designated individuals

In a practical sense, encryption is only as good as the security of the encryption key storage and its access controls. A keystore 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 keystore is usually its own entity and provides its own user authentication and authorization. Most low-level keystores use simple passphrase access control; mid-level keystores enforce strong passphrase access controls; high-level keystores 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 keystore and its physical storage. The majority of keystore implementations are required to handle several hundred encryption keys and a small number user accounts. Portability is generally a keystore priority as encrypted data is platform neutral and is simply copied from system to system. The keystore must be capable of being transported from system to system, along with the encrypted data, using simple file copy operations. Most keystores rely on the underlying file system for robustness and disaster recovery.

Keystores fall into two general categories: single user and multi-user. Single user keystores store encryption keys for a single entity. A private keystore usually has a single user account that provides all-or-nothing administration and encryption key access privileges. As a personal keystore, it does not have to protect itself from multiple simultaneous processes or thread access. A multi-user keystore 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 keystore 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 keystore 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 keystore 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.

Keystore 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 keystore 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 keystore 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 keystore suffers from the classic "lost password" syndrome. When a keystores data is physically encrypted using a user account password, the keystore is irrevocably lost when the password is lost (and subsequently the data is lost).