This chapter provides a general introduction to data encryption in Oracle Unified Directory; including basic encryption concepts, supported features, and basic configuration tasks.
This chapter includes the following sections:
Section 14.3, "Supported Algorithms for Attribute Encryption"
Section 14.5, "Support for Encryption in Replication Topology"
Section 14.8, "Configuring Attribute Encryption in Replication Enabled Topology"
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.
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 asentryuuid, createTimestamp,
virtual attributes, or password attributes. For more information about attributes that are not supported for encryption, see Section 14.6, "Attribute Encryption Usage Considerations."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:
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)
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.
Encryption in replication topology refers to encrypting data that is stored in replication server databases.
This section describes how encryption is supported in a replication topology, and it includes the following topics:
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).
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.
Note:
If you are using a gateway from Oracle Directory Server Enterprise Edition, see Section 14.5.3, "Using an ODSEE Gateway."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.
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.
You must consider the following when 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 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 error log file, which prompts you to rebuild the indexes because the configuration has changed. For more information about how to rebuild indexes, see Section A.3.13, "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 Chapter 30, "Managing Password Policies."
This section describes how to configure attribute encryption, and contains the following topics:
Section 14.7.2, "Configuring Attribute Encryption Using the dsconfig
Command"
Section 14.7.3, "Configuring Attribute Encryption Using the dsconfig
Interactive Mode"
Section 14.7.4, "Configuring Attribute Encryption Using ODSM"
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 |
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:
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 Section A.3.5, "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 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 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 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 Data Encryption subsection, located under the main Security menu, allows you to modify all of the configuration attributes described in Table 14-1.
To illustrate, Example 14-1 shows sample output from using the dsconfig
command in interactive mode.
Example 14-1 Using dsconfig
in Interactive Mode to Configure Attribute Encryption
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 ---------------------------------------------------
You can enable, disable, and configure Data Encryption by selecting the General Configuration element on the ODSM Configuration tab. For information, see Section 17.3.8, "Modifying the General Server Configuration."
This section describes scenarios to configure attribute encryption, and includes the following:
Section 14.7.5.1, "Enabling Encryption for Attributes of Specific Suffixes"
Section 14.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 14.7.2, "Configuring Attribute Encryption Using the 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
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 Section 32.2.1, "Enabling Replication Between Two Servers."
Configure attribute encryption for all instances using dsconfig. See Section 14.7.2, "Configuring Attribute Encryption Using the dsconfig
Command" and Section 14.7.3, "Configuring Attribute Encryption Using the dsconfig
Interactive Mode."
Perform a pre-external-initialization on any one of the instances. See Appendix A, "Server Subcommands."
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 Appendix A, "import-ldif."
Perform a post-external-initialization on any one of the instances. See Appendix A, "Server Subcommands."