Encryption is a mechanism which 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.
This chapter describes how to encrypt sensitive information in Oracle Unified Directory, and includes the following topics:
Section 15.3, "Supported Algorithms for Attribute Encryption"
Section 15.5, "Support for Encryption in Replication Topology"
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. That data might contain some sensitive information that should be available only to the intended recipient. Oracle Unified Directory offers a number of mechanisms to secure access to sensitive data, such as access control rules, password authentication, and SSL. However, some information might be very sensitive, for example attributes, credit card numbers, SSN number, and so on. In such a scenario, standard measures alone are not sufficient to prevent unauthorized access, because the information is stored as human readable plaintext within the database. Therefore, an invader might gain access to servers storage files and use this information to their advantage. This information loss could present a high security risk.
The attribute encryption feature prevents this information loss by encrypting sensitive information while it is stored in the underlying database files. Attribute encryption allows you to store certain sensitive attributes of an entry in an encrypted form. This prevents data from being readable while stored in database files, backup files, and exported LDIF files.
You must keep in mind that the attribute encryption feature does not encrypt data that is retrieved over LDAP protocol. Only data saved on the disk is encrypted.
Attributes are not 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. Thus, after an attribute is encrypted, then every instance of that attribute is encrypted before it is stored in the database files. This in turn implies that all 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. Only those 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 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.
Oracle Unified Directory allows you to encrypt:
Specific attributes types defined in a mandatory attribute types list.
You cannot encrypt some operational or internal attributes, for example entryuuid, createTimestamp, virtual attributes, and password attributes. For more information about attributes not supported for encryption, see Section 15.6, "Attribute Encryption Usage Considerations."
Only DB Local Backend (user backend).
Attributes in all suffixes of all available DB Local Backend 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 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:
For AES256 algorithm, you need to 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 6:
http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html
For Java 7:
http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html
Blowfish (128-bit key)
Triple DES (168-bit key)
RC4 (128-bit key)
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 has some effect on server performance for searches that make use of an encrypted index. However, limited performance impact should not prevent you from using an index.
Oracle Unified Directory allows 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.
Encryption in replication topology refers to encrypting data that is stored in replication server databases.
The replication subsystem is not subject to encryption. Encryption is neither supported for replication database, also known as changelog and nor for cn=changelog also known as external changelog. Derived limitation is that encryption is insured in backends, but not for the last set of modifications kept during the purge delay.
When you perform an operation on the server that is part of a replicated topology, and if that change is associated with an encrypted attribute, then data in the backend is encrypted. However, the data in the changelog is not encrypted. When the changelog purges the modified data, then there is no unencrypted data for this change. The data now is fully secured within the topology. In a replicated topology, you must ensure that the data encryption configuration is enabled in every server that is part of the topology. This is required to achieve attribute encryption throughout the topology. The data encryption configuration per server is not replicated.
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. Therefore, 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.
You must consider the following when implementing the attribute encryption feature:
Attribute encryption offers increased data security. However, it does has an impact on system performance. Therefore, you must consider encryption for most sensitive attributes only.
When you modify the attribute encryption configuration, you should export your data, make the configuration changes, and then import the newly configured data. This ensures that all configuration changes are taken into account without any information loss. If you fail to do so, then the data already present in the backend 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 you rebuild the index associated with the encrypted attribute. This in turn impacts the performance. For more information about rebuilding indexes, see Section A.3.13, "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 errors log file, which prompts you to rebuild the indexes because the configuration has changed. For more information about how to rebuild index, see Section A.3.13, "rebuild-index."
If you choose to configure an attribute of RDN to be encrypted, then the values that appear in the DN are not encrypted. Only values that are stored in the entry are encrypted.
For instance, 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.
The following attributes are not supported, 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
Password attributes defined in password policy is not supported for data encryption. For instance, userPassword defined in default password policy is not supported. Password encryption or hashing is handled differently. For more information about password policies and password storage scheme, see Chapter 27, "Managing Password Policies."
This section discusses how to configure attribute encryption, and contains the following topics:
Section 15.7.2, "Configuring Attribute Encryption Using dsconfig Command"
Section 15.7.3, "Configuring Attribute Encryption Using the dsconfig Interactive Mode"
Section 15.7.4, "Configuring Attribute Encryption Using ODSM"
Table 15-1 describes the configuration parameters to enable attribute encryption.
Table 15-1 Configuration Parameters for Attribute Encryption
| Name | Description | Single Valued/Multi Valued | Format | Presence Rules |
|---|---|---|---|---|
|
|
Allows you to enable or disable encryption. |
|
String representing a boolean, true or false |
If set to |
|
|
Encrypt 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 |
Should be defined if |
|
|
If not present, encryption happens on suffixes stored in DB Local Backend. If present, defines the list of user DB Local Backend suffixes in which the encryption happens. Other suffixes are not encrypted. WARNING: The suffix must be a root suffix defined in the backend, not a descendant. For instance, if backend 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 |
dsconfig CommandThis section describes how to configure attribute encryption using the dsconfig command.
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 postalAddress attribute with AES-128 algorithm in the dc=customers,dc=com suffix, 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 mail attribute and to add encryption in the dc=partners,dc=com suffix, 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:
Export the data using the LDIF script, if you want the existing data present in the backend to be configured for encryption.
export-ldif -n userRoot -l /data/export.ldif
For more information about exporting to LDIF, see Section A.3.5, "export-ldif."
Go to Step 4, if you only need the future modifications to take into account the new encryption configuration.
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 Section A.3.6, "import-ldif."
Note:
Irrespective of the fact whether data is encrypted or not in the imported LDIF file, theimport-ldif command saves the data in the backend as stated by the current server configuration. So, the import process allows you to encrypt or decrypt data on the fly. For instance, 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 postalAddress attribute, 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 mail attribute, then rebuild index using the following command:
rebuild-index -b dc=customers,dc=com -i mail
For more information about rebuilding indexes, see Section A.3.13, "rebuild-index."
dsconfig Interactive ModeYou can configure attribute encryption using the dsconfig command-line interactive mode.
Introduction of a subsection Data Encryption under the main Security menu allows you to modify all configuration attributes described in Table 15-1
The following example displays the output of 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
---------------------------------------------------
For more information about configuring attribute encryption using ODSM, see Section 17.2.8, "Modify the General Server Configuration."
This section describes scenarios to configure attribute encryption, and includes the following:
Section 15.7.5.1, "Enabling Encryption for Attributes of Specific Suffixes"
Section 15.7.5.3, "Enabling Encryption for a Specific Attribute Using an Algorithm"
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 Section A.2.4, "dsconfig."
In this example, configure encryption using the preceding two dsconfig commands sequentially. For more information, see Section 15.7.2, "Configuring Attribute Encryption Using dsconfig Command."
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 \
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 \
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 thedsconfig set-data-encryption-prop --help command to explore the set-data-encryption-prop command option. For more information, see Section A.2.4, "dsconfig."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