Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide

Encrypting Attribute Values

Attribute encryption protects sensitive data while it is stored in the directory. Attribute encryption allows you to specify that certain attributes of an entry are stored in an encrypted format. This prevents data from being readable while stored in database files, backup files, and exported LDIF files.

With this feature, attribute values are encrypted before they are stored in the Directory Server database, and decrypted back to their original value before being returned to the client. You must use access controls to prevent clients from accessing such attributes without permission, and SSL to encrypt the attribute values when in transit between the client and Directory Server. For an architectural overview of data security in general and attribute encryption in particular, see Sun Java System Directory Server Enterprise Edition 6.3 Reference.

Attribute encryption is active only when SSL is configured and enabled on the server. However, no attributes are encrypted by default. Attribute encryption is configured at the suffix level, which means that an attribute is encrypted in every entry in which it appears in the suffix. If you want to encrypt an attribute in an entire directory, you must enable encryption for that attribute in every suffix.

Caution – Caution –

Attribute encryption affects all data and index files associated with a suffix. If you modify the encryption configuration of an existing suffix, you must first export its contents, make the configuration change, and then re-import the contents. DSCC can help you perform these steps. For more information about using DSCC, see Directory Service Control Center Interface.

For additional security, when turning on encryption for any attribute, you should manually delete the database cache files and database log file that might still contain unencrypted values. The procedure for deleting these files is described in To Configure Attribute Encryption.

You should enable any encrypted attributes before loading or creating data in a new suffix.

If you choose to encrypt an attribute that some entries use as a naming attribute, values that appear in the DN will not be encrypted. Values that are stored in the entry will be encrypted.

Even though you can select the userPassword attribute for encryption, no real security benefit is realized unless the password needs to be stored in the clear. Such is the case for DIGEST-MD5 SASL authentication. If the password already has an encryption mechanism defined in the password policy, further encryption provides little additional security, but, it will impact the performance of every bind operation.

When in storage, encrypted attributes are prefaced with a cipher tag that indicates the encryption algorithm used. An encrypted attribute using the DES encryption algorithm would appear as follows:


When importing data online with a view to encrypting it, you will already have provided the key database password to authenticate to the server and will not be prompted a second time. If you are importing data offline, Directory Server will prompt you for the password before it allows you to encrypt the data you are importing. When decrypting data (a more security-sensitive operation), Directory Server automatically prompts you for the key database password, regardless of whether the export operation is online or offline. This provides an additional security layer.

Note –

As long as the certificate or private key does not change, the server will continue to generate the same key. Thus, data can be transported (exported then imported) from one server instance to another, provided both server instances have used the same certificate.

Attribute Encryption and Performance

While attribute encryption offers increased data security, it does impact system performance. Think carefully about which attributes require encryption, and encrypt only those attributes that you consider to be particularly sensitive.

Because sensitive data can be accessed directly through index files, the index keys that correspond to the encrypted attributes must be encrypted to ensure that the attributes are fully protected. Given that indexing already has an impact on Directory Server performance (without the added cost of encrypting index keys), configure attribute encryption before data is imported or added to the database for the first time. This procedure will ensure that encrypted attributes are indexed as such from the outset.

Attribute Encryption Usage Considerations

Consider the following when implementing the attribute encryption feature:

ProcedureTo Configure Attribute Encryption

You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.

  1. If the suffix on which you want to configure attribute encryption contains any entries whatsoever, you must first export the contents of that suffix to an LDIF file.

    If the suffix contains encrypted attributes and you plan to re-initialize the suffix using the exported LDIF file, you can leave the attributes encrypted in the exported LDIF .

  2. To enable encryption for an attribute, use this command:

    $ dsconf create-encrypted-attr -h host -p port suffix-DN attr-name cipher-name

    where cipher-name is one of the following:

    • des - DES block cipher

    • des3 - Triple-DES block cipher

    • rc2 - RC2 block cipher

    • rc4 - RC4 stream cipher

    For example:

    $ dsconf create-encrypted-attr -h host1 -p 1389 dc=example,dc=com uid rc4
  3. To return an encrypted attribute to its original state, use this command:

    $ dsconf delete-encrypted-attr -h host -p port suffix-DN attr-name
  4. If you have changed the configuration to encrypt one or more attributes, and these attributes had values before the import operation, clear the database cache and remove the log.

    Any unencrypted values will not be visible in the database cache and database log.

    Note –

    If you delete these files, you will lose some tracking information. In addition, after you delete these files, the server will be in recovery mode, and might take a long time to restart.

    To clear the database cache and remove the log:

    1. Stop Directory Server as described in Starting, Stopping, and Restarting a Directory Server Instance.

    2. As root or a user with administrator privileges, delete the database cache files from your file system.

      # rm instance-path/db/__db.*
    3. Delete the database log file from your file system.

      # rm instance-path/db/log.0000000001
    4. Restart Directory Server.

      The server will automatically create new database cache files. Performance of operations in this suffix might be slightly impacted until the cache is filled again.

  5. Initialize the suffix with an LDIF file as described in Initializing a Suffix.

    As the file is loaded and the corresponding indexes are created, all values of the specified attributes will be encrypted.