Changes in This Release for Oracle Database Advanced Security Guide

This preface contains:

Changes in Oracle Database Advanced Security 19c

The following are changes in Oracle Database Advanced Security Guide for Oracle Database 19c.

Improved Key Management Support for Encrypting Oracle-Managed Tablespaces

In this release, closing a TDE keystore is now allowed even when the Oracle-managed tablespaces (SYSTEM, SYSAUX, TEMP, and UNDO tablespaces) are encrypted.

Internal operations on these tablespaces when they are encrypted continue to be unaffected even when the TDE keystore is in the CLOSED state.

Closing the TDE keystore has no effect on queries of an encrypted SYSTEM, SYSAUX, TEMP, or UNDO tablespace, unlike queries of a user-created tablespace, which continue to return an ORA-28365 wallet is not open error when the TDE keystore is closed.

User-initiated operations such as decrypt on any encrypted Oracle-managed tablespace still require the TDE keystore to be in the OPEN state.

Transparent Online Conversion Support for Auto-Renaming in Non-Oracle-Managed Files Mode

Starting with this release, online tablespace encryption no longer requires you to specify the FILE_NAME_CONVERT clause in the ALTER TABLESPACE ENCRYPT SQL statement. The file names will retain their original names.

This enhancement helps to prevent you from having to rename files back to the original name afterward, sometimes missing files.

Support for More Algorithms for Offline Tablespace Encryption

In previous releases, only the AES128 encryption algorithm was supported for offline tablespace encryption. In addition to AES128, this release introduces support for the AES192 and AES256 encryption algorithms, as well as ARIA, GOST, and 3DES encryption algorithms for offline tablespace encryption.

This enhancement benefits scenarios in which you have concerns about auxiliary space usage required by online tablespace encryption.

Changes in Oracle Database Advanced Security 18c

The following are changes in Oracle Database Advanced Security Guide for Oracle Database 18c.

Ability to Create a Keystore for Each Pluggable Database

Each pluggable database (PDB) can now have its own keystore instead of there only being one keystore for the entire container database (CDB).

In previous releases, PDBs shared the keystore with the entire container database (CDB), which included the CDB root and all the PDBs. This keystore stored the master encryption keys for the CDB as well as all the PDBs. In this release, a PDB can either continue to share the same keystore with the entire CDB as before, or have a separate keystore. This design offers greater isolation between PDBs, because each separate keystore can be administered independently. For example, each keystore can be protected by a different password


This feature can only be used in an Oracle Cloud environment, and with engineered systems on premises, including Oracle Exadata, Exadata Cloud at Customer (ExaC@C), as well as Autonomous Database Dedicated on Exadata Cloud at Customer (ADB on ExaC@C).

The additional advantage of this feature is that it enables independent key management operations to be performed by each tenant (PDB) in a multitenant environment rather than having to share a keystore at the CDB root level.

This feature provides the following new functionality:

  • For multitenant environments, the following two modes:

    • United mode, in which the keystores and master encryption keys are primarily managed from the CDB root, and can be accessed from the united mode PDB. Within the PDB, the keystore can be opened and closed just for that PDB. Each PDB has its own set of master encryption keys in the shared keystore.

    • Isolated mode, in which the keystore and encryption keys are managed in an individual PDB. This way, each PDB can configure its own keystore type independently, and create and manage this keystore after configuring it.

    You can mix these two modes. For example, suppose you have 1 CDB and 10 PDBs. You can run 3 of these PDBs in united mode and the remaining 7 in isolated mode. This design offers the highest flexibility depending on your environment and site requirements.

    To accommodate these modes, the ADMINISTER KEY MANAGEMENT SQL statement has been enhanced to behave differently in the two modes.

  • For both non-multitenant and multitenant environments, the following new features:

    • Addition of the WALLET_ROOT static instance initialization parameter, to specify the keystore path. In this guide, WALLET_ROOT refers to the configuration of software keystores or Oracle Key Vault, but this parameter can be used to designate the wallet location for other products as well: Enterprise User Security, Secure Sockets Layer, Oracle XML DB, and Secure External Password Store.

    • Addition of the TDE_CONFIGURATION dynamic instance initialization parameter, to specify the type of keystore to use. You can set this parameter for TDE software keystores, external keystores, and Oracle Key Vault.

    • When the WALLET_ROOT parameter has been set, then WALLET_ROOT overrides SQLNET.ENCRYPTION_WALLET_LOCATION. If WALLET_ROOT has not been set, then SQLNET.ENCRYPTION_WALLET_LOCATION is the default.

Ability to Create a User-Defined Master Encryption Key

This release introduces the ability to create a user-defined master encryption key, also known as “bring your own key.”

Instead of requiring that TDE master encryption keys always be generated in the database, Oracle Database now supports the use of master encryption keys that have been generated outside the database.

To create the user-defined key, you supply your own master key identification value when you create the master encryption key by using the ADMINISTER KEY MANAGEMENT SET [ENCRYPTION] KEY or ADMINISTER KEY MANAGEMENT CREATE [ENCRYPTION] KEY statements. This enhancement applies to master encryption keys that are used in software keystores only, not PKCS#11-compatible key managers. However, Oracle Key Vault introduced "bring your own key" from Oracle Key Vault release, and all database versions starting from Oracle Database release can activate those keys.

Ability to Use Encrypted Passwords for Database Links with Oracle Data Pump

The behavior for handling database link passwords has changed in this release.

Passwords in database links are now encrypted. Oracle Data Pump handles the export and import of these passwords. Import operations from older versions and export operations to older versions can still be used.

The benefit of this feature is that it prevents an intruder from decrypting an encrypted database link password.