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.

  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 Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide.