Encryption is a mechanism that converts plaintext data into something unreadable, called ciphertext, to prevent unauthorized access to sensitive data. Decryption is the process in which the ciphertext is converted back to plaintext.

Oracle Unified Directory is a next-generation unified directory solution that integrates storage, synchronization, and proxy functionality to help you manage the critical identity information that drives your business applications. This data might contain sensitive information that should be available only to the intended recipient. Oracle Unified Directory offers mechanisms; such as access control rules, password authentication, and SSL to secure access to your data. Your data might also contain some extremely sensitive information, such as credit card numbers and SSN numbers. For this type of data, standard measures alone are not sufficient to prevent unauthorized access because the information is stored as human readable plaintext within the database. If an invader gains access to your server storage files and uses this information to their advantage, then the loss could present a high security risk.

Oracle Unified Directory provides an attribute encryption feature that enables you to store certain sensitive attributes as ciphertext, which prevents data from being readable while it is stored in underlying database files, backup files, and exported LDIF files. Attribute encryption enables you to encrypt important data before it is written to the disk and to decrypt data when it is read from the disk.

Attributes are not encrypted by default. You configure attribute encryption at the suffix level, which means that an attribute is encrypted at every entry in which it appears in the suffix. Thus, after an attribute is encrypted, every instance of that attribute is encrypted before it is stored in the database files. This in turn implies that all of the on-disk data for that specific attribute is encrypted.

Encryption is always reversible. Encrypted attributes are decrypted when returned through search requests. If you want to encrypt an attribute in an entire directory, then you must enable encryption for that attribute in every suffix or leave the suffix list empty.

Attribute encryption also enables you to export data to another database in an encrypted format. The purpose of attribute encryption is to protect sensitive data only when the data is being stored or exported.

Related Topics

Masking Attributes in the Audit Log

Attributes are not encrypted by default. You need to configure attribute encryption at the suffix level. This indicates that an attribute is encrypted at every entry in which it appears in the suffix.

Oracle Unified Directory allows you to encrypt:

• Specific attribute types defined in a mandatory attribute types list.

  Note:

  You cannot encrypt some operational or internal attributes, such as entryuuid, createTimestamp, virtual attributes, or password attributes. For more information about attributes that are not supported for encryption, see Considerations for Attribute Encryption Usage.

• Only DB Local Backend (user back end).

• Attributes in all suffixes of all available DB Local Backends or, if listed, in some specific suffixes. For example:

  If suffixes are specified, then it should be root suffixes of a DB Local Backend, not a sub suffix. For example, if DB Local Backend has root suffix dc=example,dc=com then you cannot encrypt some attributes only in ou=people,dc=example,dc=com.

Oracle Unified Directory enables you to prevent unauthorized access to attributes of an entry stored on a disk using encryption algorithms.

An encryption algorithm is a set of mathematical rules or functions used for encrypting and decrypting data. These algorithms work in combination with a key to encrypt and decrypt data.

The attribute encryption feature supports a wide range of standard encryption algorithms.

You can configure the server to encrypt attributes using several encrypting schemes. The supported encryption schemes include:

• AES128

• AES256

  Note:

  Download the "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files" if applicable. The download page is https://www.oracle.com/in/java/technologies/javase-jce-all-downloads.html

• Blowfish (128-bit key)

• Triple DES (168-bit key)

• RC4 (128-bit key)

The newly supported encryption schemes include:

• AES-128-GCM
• AES-192-GCM
• AES-256-GCM

An attacker can also access sensitive data directly through index files. Therefore, it is imperative to encrypt the index keys corresponding to the encrypted attributes, to ensure that the attributes are fully protected.

Database encryption is partially compatible with indexing. The content of the index files that are normally derived from attribute values are also encrypted to prevent an attacker from recovering part or all of the encrypted data from an analysis of the indexes.

The server pre-encrypts all index keys before looking up an index for an encrypted attribute. This action has some effect on server performance for searches that use an encrypted index. However, limited performance impact should not prevent you from using an index.

Oracle Unified Directory enables you to use the following index types for an associated encrypted attribute:

• Equality

• Substring

• Approximate

• Presence

Encryption is supported for DB Local Backend indexes only. Keys of the indexes are encrypted for an encrypted attribute.

Encryption in replication topology refers to encrypting data that is stored in replication server databases.

Learn about how encryption is supported in a replication topology from the following topics:

• Understanding Encryption in a Replication Server Database (or changelog)

• Understanding Attribute Encryption Key in Replication Topology

• Updating Servers from 11.1.2.2.0

• Using an ODSEE Gateway

Learn about the usage of Attribute Encryption, what happens when the attribute encryption configuration is modified and what needs to be done for encrypted attributes that are indexed.

Consider the following points below while implementing the attribute encryption feature:

• Attribute encryption provides increased data security, but it does have an impact on system performance. Consider using encryption only for the most sensitive attributes.

• When modifying the attribute encryption configuration, you must export your data, make the configuration changes, and then import the newly configured data to ensure that all configuration changes are taken into account without any information loss. If you fail to do so, then data that is already present in the back end on which no change occurred after the data encryption configuration change remains in clear or encrypted format as configured with the initial algorithm.

• Algorithm changes are supported. Modifying encryption on an indexed attribute requires that you rebuild the index associated with the encrypted attribute. This in turn impacts the performance. For more information about rebuilding indexes, see rebuild-index.

• For encrypted attributes that are indexed, it is required to maintain the consistency between indexes and the data encryption configuration. If you modify or update the configuration for encrypted attributes, then you must rebuild the indexes associated with the encrypted attribute. Failing to do so will log an error message in the error log file, which prompts you to rebuild the indexes because the configuration has changed. For more information about how to rebuild indexes, see rebuild-index.

• If you configure an attribute of RDN to be encrypted, then the values that appear in the DN will not be encrypted. Only values that are stored in the entry are encrypted.

  For example, consider the following entry:

  dn: uid=foo,dc=example,dc=com
  objectclass: inetorgperson
  objectclass: organizationalperson
  objectclass: person
  objectclass: top
  uid=foo
  cn=bar
  sn=joe
  

  Here, uid is an attribute that is:

  • Part of the DN of the entry and is its RDN.

  • Also part of the attributes of the entry. You must keep in mind that this is always the case, because RDN is always present as an attribute in the entry.

  However, uid is a multi-valued attribute, therefore you can add a value to uid in the entry as follows:

  dn: uid=foo,dc=example,dc=com
  objectclass: inetorgperson
  objectclass: organizationalperson
  objectclass: person
  objectclass: top
  uid=foo
  uid=secondValue
  cn=bar
  sn=joe
  

  Now, if you encrypt uid, then the new value that you have added is encrypted and not the initial value, foo. The value that is in the RDN is not encrypted.

• You cannot configure encryption for the following attributes because they are used internally by the server:

  Operational Attributes

  • objectclass

  • entryUUID

  • creatorsName

  • createTimestamp

  • modifiersName

  • modifyTimestamp

  Virtual Attributes

  You cannot configure a virtual attribute for encryption.

  Password Attributes

  Because passwords are already hashed or encrypted, you cannot use the attribute encryption feature to modify the existing behavior of, or configure encryption for, any password attributes that are defined in a password policy. For example, the userPassword attribute, which is defined in the default password policy is not supported.

  Password encryption or hashing is handled differently. For information about password policies and the password storage scheme, see Managing Password Policies.

You must configure different parameters to enable attribute encryption.

The following sections describe the configuration parameters to enable attribute encryption and the different methods to configure attribute encryption.

• Attribute Encryption Configuration Parameters

• Attribute Encryption Advanced Configuration Parameters

• Configuring Attribute Encryption Using the dsconfig Command

• Configuring Attribute Encryption Using the dsconfig Interactive Mode

• Managing Attribute Encryption

In the existing environment, when attribute encryption is newly enabled or any existing attribute encryption related configuration such as the encryption algorithm changes, then encryption of the existing data present in the backend as per new encryption configuration needs to be performed.

You may have some replicated topology which may impact if attribute encryption is used, especially when certain releases of OUD contain newer encryption schemes. Consider the use case scenarios as follows:

.