HP-UX Directory Server Administrator Guide HP-UX Directory Server Version 8.1 (5900-3098, May 2013)

2.3.3 Database encryption
The Directory Server offers a number of mechanisms to secure access to sensitive data, such as
access control rules to prevent unauthorized users from reading certain entries or attributes within
entries and SSL to protect data from eavesdropping and tampering on untrusted networks. However,
if a copy of the server's database files should fall into the hands of an unauthorized person, they
could potentially extract sensitive information from those files. Because information in a database
is stored in plain text, some sensitive information, such as government identification numbers or
passwords, may not be protected enough by standard access control measures.
For highly sensitive information, this potential for information loss could present a significant security
risk. In order to remove that security risk, Directory Server allows portions of its database to be
encrypted. After encryption, the data are safe even in the event that an attacker has a copy of the
server's database files.
Database encryption allows attributes to be encrypted in the database. Both encryption and the
encryption cipher are configurable per attribute per back-end. When configured, every instance
of a particular attribute, even index data, is encrypted for every entry stored in that database.
NOTE:
To enable database encryption on an attribute with existing stored data, export the database to
LDIF first, then make the configuration change, then re-import the data to the database. The server
does not enforce consistency between encryption configuration and stored data; therefore, pay
careful attention that all existing data are exported before enabling or disabling encryption.
Indexed attributes may be encrypted, and database encryption is fully compatible with indexing.
The contents of the index files that are normally derived from attribute values are also encrypted
to prevent an attacker from recovering part or all the encrypted data from an analysis of the indexes.
Because the server pre-encrypts all index keys before looking up an index for an encrypted attribute,
there is some effect on server performance for searches that make use of an encrypted index, but
the effect is not serious enough that it is no longer worthwhile to use an index.
2.3.3.1 Encryption keys
In order to use database encryption, the server must be configured for SSL and have SSL enabled
because database encryption uses the server's SSL encryption key and the same PIN input methods
as SSL. The PIN must either be entered manually upon server startup or a PIN file must be used.
Randomly generated symmetric cipher keys are used to encrypt and decrypt attribute data. A
separate key is used for each configured cipher. These keys are wrapped using the public key
from the server's SSL certificate, and the resulting wrapped key is stored within the server's
configuration files. The effective strength of the database encryption is never higher than the strength
of the server's SSL key used for wrapping. Without access to the server's private key, it is not
possible to recover the symmetric keys from the wrapped copies.
CAUTION:
There is no mechanism for recovering a lost key. Therefore, it is especially important to back up
the server's certificate database safely. If the server's certificate were lost, it would not be possible
to decrypt any encrypted data stored in its database.
CAUTION:
If the SSL certificate is expiring and needs to be renewed, export the encrypted back-end instance
before the renewal. Update the certificate, then re-import the exported LDIF file.
2.3 Creating and Maintaining Databases 47