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.

The only data that is saved on the disk is encrypted. Not all the data that is displayed under the Entry Management panel of the console or as an output of the ldapsearch command, is encrypted.

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 all exchanges between the client and Directory Server. For an architectural overview of data security in general and attribute encryption in particular, see Oracle Fusion Middleware Reference for Oracle Directory Server Enterprise Edition.

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.

Attribute encryption affects all data and index files associated with a suffix. The only attributes are encrypted that are changed after the attribute encryption is activated. Existing attributes will remain unchanged.

To apply encryption to all the data, 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:

{CKM_DES_CBC}3hakc&jla+=snda%

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.

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:

• As a general best practice when modifying attribute encryption configuration, you should export your data, make the configuration changes, and then import the newly configured data.

  This will ensure that all configuration changes are taken into account in their entirety, without any loss in functionality. Failing to do so could result in some functionality loss and thus compromise the security of your data.

• Modifying attribute encryption configuration on an existing database can have a significant impact on system performance.

  For example, imagine that you have a database instance with existing data. The database contains previously stored entries with an attribute called mySensitiveAttribute. The value of this attribute is stored in the database and in the index files in clear text, . If you later decide to encrypt the mySensitiveAttribute attribute, all the data in the database instance must be exported and re-imported into the database to ensure that the server updates the database and index files with the attribute encryption configuration. The resulting performance impact could have been avoided had the attribute been encrypted from the beginning.

• When exporting data in decrypted format, the export is refused if an incorrect password is used.

  To be able to use the dsconf command with the -y or -–decrypt-attr option, set the set password prompt mode on and choose a certificate database password as described in Configuring the Certificate Database Password.

  As a security measure, the server prompts users for passwords if they want to export data in decrypted format. Should users provide an incorrect password, the server refuses the decrypted export operation. Passwords can be entered directly or by providing the path to a file that contains the password. Note that this file has the same syntax as the SSL password file. See Configuring the Certificate Database Password.

• Algorithm changes are supported, but the result can be lost indexing functionality if they are not made correctly.

  To change the algorithm used to encrypt data, export the data, modify the attribute encryption configuration, and then import the data. If you do not follow this procedure, the indexes that were created on the basis of the initial encryption algorithm will no longer function.

  Because the encrypted attributes are prefaced with a cipher tag that indicates the encryption algorithm used, the internal server operations take care of importing the data. Directory Server therefore enables you to export data in encrypted form before making the algorithm change.

• Changing the server’s SSL certificate results in your not being able to decrypt encrypted data.

  The server’s SSL certificate is used by the attribute encryption feature to generate its own key, which is then used to perform the encryption and decryption operations. Thus, the SSL certificate is required to decrypt encrypted data. If you change the certificate without decrypting the data beforehand, you cannot decrypt the data. To avoid this, export your data in decrypted format, change the certificate, and then re-import the data.

• To transport data in encrypted format, that is, to export and import it from one server instance to another, both server instances must use the same certificate.

  For information, see “Encrypting Attribute Values” in the Oracle Fusion Middleware Administration Guide for Oracle Directory Server Enterprise Edition.

To 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. Initialize the suffix with an LDIF file as described in Initializing a Suffix.

   ---

   Note –

   If you are importing the LDIF file using the dsadm import command, you must use the -y option. The dsconf import command does not require to use the -y option.

   ---

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