14 Understanding Data Encryption in Oracle Unified Directory
14.1 What is Attribute Encryption?
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.
Note:
The attribute encryption feature does not encrypt data that is retrieved over the LDAP protocol. Only data saved on the disk is encrypted.
If an LDAP client reads (searches for) an entry with some encrypted attributes on the disk, then that client receives a decrypted entry and the values of the originally encrypted attributes are immediately readable without any decryption.
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.
Note:
Attribute encryption affects all data and index files associated with a suffix. These attributes are not changed (encrypted) until attribute encryption is activated. Existing attributes will remain unchanged.
To apply encryption to all of the data, you must first make the configuration change, export the contents, and then re-import the contents.
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
14.2 Understanding Attribute Encryption
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=comthen you cannot encrypt some attributes only inou=people,dc=example,dc=com.
14.3 Understanding Encryption Algorithms
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:
For AES256 algorithm, you must install Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files.You must download and install the correct JCE Unlimited Strength Jurisdiction Policy Files according to the Java version.
For Java 7, download "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 7" from the Java SE Downloads page on OTN:
-
Blowfish (128-bit key)
-
Triple DES (168-bit key)
-
RC4 (128-bit key)
14.3.1 Attribute Encryption Key
Oracle Unified Directory uses symmetric key for attribute encryption and decryption. It generates the required symmetric key whenever it is needed. Symmetric key is encrypted and securely stored in cn=admin data backend. This encryption is done using the server's public key. Hence, the stored encrypted symmetric key can only be decrypted using the server's private key.
14.4 Understanding Encryption in Index Keys
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
Note:
You must bear in mind that encryption techniques do not preserve the order of an index. Therefore, ordering indexes are not supported when attributes are encrypted.
Encryption is supported for DB Local Backend indexes only. Keys of the indexes are encrypted for an encrypted attribute.
14.5 Understanding Encryption in Replication Topology
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:
14.5.1 Understanding Encryption in a Replication Server Database (or changelog)
Oracle Unified Directory supports encryption in a replication server database (also known as the changelog) and for cn=changelog (also known as the external changelog or the retro-changelog). Oracle Unified Directory encrypts data on a replication server database the same way it does for a server database. No additional configuration is necessary. Enabling and disabling encryption, defining attributes for encryption, and defining suffixes for encryption is the same for either database.
If you perform an operation on a server that is part of a replicated topology, and if that change is associated with an encrypted attribute, then Oracle Unified Directory encrypts the data in the replication server's database (the changelog, which is readable from cn=changelog) using the same algorithm that is used for encryption in the server.
When Oracle Unified Directory accesses the retro-changelog (cn=changelog), which accesses the changelog, the retro-changelog always returns clear values. Encryption only occurs at rest; that is, on stable storage (hard disk).
14.5.2 Understanding Attribute Encryption Key in Replication Topology
The keys used for encryption are created, stored, and retrieved from cn=admin data. This suffix is replicated on any other server in the topology.
So, any server in the topology can decrypt any encrypted attribute and send it to its LDAP clients. Therefore, keys used for encryption or decryption algorithm are replicated throughout the entire topology because cn=admin data is replicated.
A stored symmetric key used in encryption can only be decrypted by the server using its private key. Hence, while renewing ads-truststore certificate, you must retain the same keys.
Note:
If you are using a gateway from Oracle Directory Server Enterprise Edition, see Using an ODSEE Gateway.
14.5.3 Updating Servers from 11.1.2.2.0
When updating version 11.1.2.2.0 replicated topology of servers to version 11.1.2.3.0, encryption does not occur in every replication server database until after all servers have been updated.
In addition, you must wait for the purge delay to expire to ensure there are no more sensible values in the changelog.
14.5.4 Using an ODSEE Gateway
Learn about using an ODSEE gateway in this topic. Oracle Directory Server Enterprise Edition allows some attributes to be encrypted in the back end, but not in the changelog.
Starting with Oracle Unified Directory version 11.1.2.3.0, if you are using a gateway from Oracle Directory Server Enterprise Edition, then you can configure that gateway like other servers in the Oracle Unified Directory topology.
Then, if changes sent from an Oracle Directory Server Enterprise Edition server through the replication gateway are associated with an encrypted attribute (defined by the configuration as with regular Oracle Unified Directory servers), then Oracle Unified Directory can encrypt that data and store it in the replication server database.
14.6 Considerations for Attribute Encryption Usage
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,
uidis 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,
uidis a multi-valued attribute, therefore you can add a value touidin 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
userPasswordattribute, 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.
-
14.7 Configuring Attribute Encryption
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.
14.7.1 Attribute Encryption Configuration Parameters
Learn about the various attribute encryption configuration parameters, their names, descriptions, allowable values and formats, and rules to perform an action based on the values provided, from the tabular column below.
Table 14-1 describes the configuration parameters to enable attribute encryption.
Table 14-1 Configuration Parameters for Attribute Encryption
| Name | Description | Single/ Multi Valued | Format | Presence Rules |
|---|---|---|---|---|
|
|
Allows you to enable or disable encryption. |
|
String representing a boolean, true or false |
If set to |
|
|
Encrypts every attribute defined here. Encrypt attributes of all the entries of all suffixes or only in the suffixes defined with |
|
String representing a single attribute name or OID |
Defined if |
|
|
Controls how encryption is applied for suffixes.
WARNING: The suffix must be a root suffix defined in the back end, not a descendant. For example, if back end has |
|
String representing a single suffix |
Meaningful if |
|
|
Defines the algorithm to use for encryption. |
|
String representing an encryption algorithm. Possible values are:
|
Meaningful if |
14.7.2 Configuring Attribute Encryption Using the dsconfig Command
You use the dsconfig command to configure attribute encryption.
Consider the scenario, where you plan to encrypt every attribute, postalAddress and mail, with AES-128 algorithm in entries of user DB Local Backend root suffixes, dc=customers,dc=com and dc=partners,dc=com.
To configure attribute encryption using the dsconfig command:
-
Run the following commands sequentially.
To configure attribute encryption for
postalAddressattribute withAES-128algorithm in thedc=customers,dc=comsuffix, run the following command:dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" \ -j /local/password set-data-encryption-prop --set enabled:true \ --set attribute-encryption-include:postalAddress \ --set encryption-algorithm:aes-128 \ --set encrypted-suffix:dc=customers,dc=com
To add attribute encryption for
mailattribute and to add encryption in thedc=partners,dc=comsuffix, run the following command:dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" \ -j /local/password \ set-data-encryption-prop --add attribute-encryption-include:mail \ --add encrypted-suffix:dc=partners,dc=com \
-
Do one of the following:
-
If you want the existing data present in the back end to be configured for encryption, export the data using the LDIF script:
export-ldif -n userRoot -l /data/export.ldif
For more information about exporting to LDIF, see export-ldif.
-
If you only want future modifications to consider the new encryption configuration, go to Step 4.
-
-
Perform the following steps to re-import data, and stop.
-
Stop the server.
stop-ds
-
Import data.
import-ldif -n userRoot -l /data/export.ldif
For more information about importing from command line, see import-ldif.
Note:
Irrespective of the fact whether data is encrypted or not in the imported LDIF file, the
import-ldifcommand saves the data in the back end as stated by the current server configuration. So, the import process allows you to encrypt or decrypt data as needed. For example, importing encrypted data in a server configured with no encryption allows you to store data unencrypted. In addition, if you import a clear LDIF file into a server configured for encryption, then it allows you to store data encrypted.The algorithm of the current configuration is always used. If you import an AES128 encrypted data set into the server with RC4 encryption configured, then data is re-encrypted and stored with RC4 configuration.
-
Start the server.
start-ds
When you import data, then it also builds the indexes. Therefore, there is no need to perform step 4.
-
-
Rebuild indexes.
If the suffix on which you want to configure encryption contains indexes for the impacted attributes, then rebuild those indexes. Run the following commands:
For example, if there are some indexes associated with the
postalAddressattribute, then rebuild index using the following command:rebuild-index -b dc=customers,dc=com -i postalAddress
Similarly, if there are some indexes associated with the
mailattribute, then rebuild index using the following command:rebuild-index -b dc=customers,dc=com -i mail
For more information about rebuilding indexes, see rebuild-index.
14.7.3 Configuring Attribute Encryption Using the dsconfig Interactive Mode
You can configure attribute encryption using the dsconfig command-line interactive mode.
Introduction of a Data Encryption subsection, located under the main Security menu, allows you to modify all of the configuration attributes described in Table 14-1.
Consider the following example to configure attribute encryption using the dsconfig command in interactive mode.
Oracle Unified Directory Configuration Console Main Menu What do you want to configure? 1) Security 6) Schema 2) Local Storage 7) Distribution 3) Miscellaneous Workflow Elements 8) Replication 4) Virtualization 9) Remote Storage 5) General Configuration 10) Load Balancing q) quit Enter choice: 1 Security Management Menu What would you like to do? 1) Access Control Group 5) Key Manager Provider 2) Access Control Handler 6) Root DN 3) Crypto Manager 7) SASL Mechanism Handler 4) Data Encryption 8) Trust Manager Provider b) back q) quit Enter choice [b]: 4 Configure the Properties of Data Encryption Property Value(s) ------------------------------------------------------------------ 1) attribute-encryption-include description, givenname, mobile 2) enabled true 3) encrypted-suffix "dc=example,dc=com" 4) encryption-algorithm aes-128 ?) help f) finish - apply any changes to the Data Encryption c) cancel q) quit Enter choice [f]: ? Component name: Data Encryption Data Encryption allows to configure attribute encryption. Option Types: r -- Property value(s) are readable w -- Property value(s) are writable m -- The property is mandatory s -- The property is single-valued a -- Administrative action is required for changes to take effect Property Options Syntax -------------------------------------------------- attribute-encryption-include rw--- OID enabled rw-s- BOOLEAN encrypted-suffix rw--- DN encryption-algorithm rw-s- ALGORITHM ---------------------------------------------------
14.7.4 Configuring Attribute Encryption Using OUDSM
You can enable, disable, and configure Data Encryption by selecting the General Configuration element on the OUDSM Configuration tab.
For information, see Modifying the General Server Configuration Using OUDSM.
14.7.5 Managing Attribute Encryption
You can enable and disable attribute encryption, and modify and fetch attributes using dsconfig command.
The following topics describe how to enable and disable attribute encryption:
14.7.5.1 Enabling Encryption for Attributes of Specific Suffixes
This section describes a scenario to encrypt every attribute, postalAddress and mail, with 3DES-168 algorithm in entries of user DB Local Backend root suffixes, dc=customers,dc=com and dc=partners,dc=com.
To configure attribute encryption for postalAddress use the following command:
dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" \ -j /local/password \ set-data-encryption-prop --set enabled:true \ --set encryptedsuffix:dc=customers,dc=com \ --set attribute-encryption-include:postalAddress \ --set encryption-algorithm:triple-des-168 \
To configure attribute encryption for mail use the following command:
dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" \ -j /local/password \ set-data-encryption-prop --add attribute-encryption-include:mail \ --add encrypted-suffix:dc=partners,dc=com \
You can configure attributes using the set-data-encryption-prop option of dsconfig command. For more information about the encryption parameters, see dsconfig.
In this example, configure encryption using the preceding two dsconfig commands sequentially. For more information, see Configuring Attribute Encryption Using the dsconfig Command.
14.7.5.2 Disabling Encryption
Use the following dsconfig command to disable encryption:
dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" \ -j /local/password \ set-data-encryption-prop --set enabled:false \
14.7.5.3 Enabling Encryption for a Specific Attribute Using an Algorithm
Use the following command to encrypt the mobile attribute with the AES-128 algorithm:
dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" \ -j /local/password set-data-encryption-prop --set enabled:true \ --set attribute-encryption-include:mobile \ --set encryption-algorithm:aes-128 \
14.7.5.4 Modifying Attributes
You can modify the attributes through the dsconfig command with the set-data-encryption-prop subcommand as follows:
dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" / -j /local/password set-data-encryption-prop --set "enabled:true"
Note:
Run the dsconfig set-data-encryption-prop --help command to explore the set-data-encryption-prop command option. For more information, see dsconfig.
14.7.5.5 Fetching Attributes
You can read the attributes through the dsconfig command with the get-data-encryption-prop subcommand as follows:
dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" / -j /local/password get-data-encryption-prop Property : Value(s) -----------------------------:------------------------------- attribute-encryption-include : description, givenname, mobile enabled : true encrypted-suffix : "dc=example,dc=com" encryption-algorithm : aes-128
14.8 Configuring Attribute Encryption in Replication Enabled Topology
You can initialize OUD topology with attribute encryption. The keys used for encryption are not stored in the keystore instead in cn=admin data suffix. This suffix is replicated across all the servers of the topology. Therefore, any OUD instance can decrypt encrypted attribute prior to sending it back to client application.
Consider an OUD instance running in a replicated topology. In order to secure value of attributes while storing them on disk, you need to define attribute encryption. The attribute data of the newly created entries will be encrypted in the replicated topology, whereas the attribute data of the existing entries will not be stored securely. To apply encryption to all of the entries or the attribute data, you need to export the contents, and then re-import them as explained below.
- Enable Replication for all instances. See Enabling Replication Between Two Servers With dsreplication.
- Configure attribute encryption for all instances using dsconfig. See Configuring Attribute Encryption Using the dsconfig Command and Configuring Attribute Encryption Using the dsconfig Interactive Mode.
- Perform a pre-external-initialization on any one of the instances. See dsreplication.
- Perform an off-line import either on all instances or on one instance, and then perform Binary copy to the other instances or dsreplication initialize. See import-ldif.
- Perform a post-external-initialization on any one of the instances. See dsreplication.