You can change the password of a TDE wallet when the PDB is in isolated mode.

To change the password of an external keystore, you must use the administrative interface of the external keystore. You cannot perform this operation by using the ADMINISTER KEY MANAGEMENT statement.

• Changing the Password-Protected TDE Wallet Password in Isolated Mode
  To change the password of a password-protected TDE wallet in isolated mode, you must use the ADMINISTER KEY MANAGEMENT statement.
• Changing the Password of an External Keystore in Isolated Mode
  To change the password of an external keystore, you must close the external keystore and then change the password from the external keystore’s management interface.

You can close both software and external keystores in isolated mode, unless the system tablespace is encrypted.

• Closing a TDE Wallet in Isolated Mode
  You can close password-protected TDE wallets, auto-login TDE wallets, and local auto-login TDE wallets in isolated mode.
• Closing an External Keystore in Isolated Mode
  To close an external keystore, you must use the ADMINISTER KEY MANAGEMENT statement with the SET KEYSTORE CLOSE clause.

To create a user-defined TDE master encryption key, use the ADMINISTER KEY MANAGEMENT statement with the SET | CREATE [ENCRYPTION] KEY clause.

1. Connect to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
2. Create the user-defined TDE master encryption key by using the following syntax:

   ADMINISTER KEY MANAGEMENT SET | CREATE [ENCRYPTION] KEY
   'mkid:mk | mk' 
   [USING ALGORITHM 'algorithm'] 
   [FORCE KEYSTORE]
   IDENTIFIED BY [EXTERNAL STORE | keystore_password] 
   [WITH BACKUP [USING 'backup_identifier']];

   In this specification:

   • SET | CREATE : Enter SET if you want to create the master and activate the TDE master encryption key now, or enter CREATE if you want to create the key for later use, without activating it yet.

   • mkid and mk:

     • mkid, the TDE master encryption key ID, is a 16–byte hex-encoded value that you can specify or have Oracle Database generate.

     • mk, the TDE master encryption key, is a hex-encoded value that you can specify or have Oracle Database generate, either 32 bytes (for the for AES256, ARIA256, and GOST256 algorithms) or 16 bytes (for the SEED128 algorithm).

       Note:

       Starting with Oracle Database 23ai, the Transparent Data Encryption (TDE) decryption libraries for the GOST and SEED algorithms are deprecated, and encryption to GOST and SEED are desupported. Starting with Oracle Database 23ai, the Transparent Data Encryption (TDE) encryption libraries for the GOST and SEED algorithms are desupported and removed. The GOST and SEED decryption libraries are deprecated. Both are removed on HP Itanium platforms.

       GOST 28147-89 has been deprecated by the Russian government, and SEED has been deprecated by the South Korean government. If you need South Korean government-approved TDE cryptography, then use ARIA instead. If you are using GOST 28147-89, then you must decrypt and encrypt with another supported TDE algorithm. The decryption algorithms for GOST 28147-89 and SEED are included with Oracle Database 23ai, but are deprecated, and the GOST encryption algorithm is desupported with Oracle Database 23ai. If you are using GOST or SEED for TDE encryption, then Oracle recommends that you perform an online rekey operation before upgrading to Oracle Database 23ai. However, with the exception of the HP Itanium platform, the GOST and SEED decryption libraries are available with Oracle Database 23ai, so you can also decrypt after upgrading.

     If you omit the mkid:mk|mkid clause but include the mk value, then Oracle Database generates the mkid for the mk.

     If you omit the entire mkid:mk|mkid clause, then Oracle Database generates these values for you.

   • USING ALGORITHM: Specify one of the following supported algorithms:

     • AES256

     • ARIA256

     • SEED128 (deprecated)

     • GOST256 (deprecated)

     If you omit the algorithm, then the default, AES256, is used.

   • FORCE KEYSTORE temporarily opens the password-protected TDE wallet for this operation. You must open the TDE wallet for this operation.

   The following example includes a user-created TDE master encryption key but no TDE master encryption key ID, so that the TDE master encryption key ID is generated:

   ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY 
   '3D432109DF88967A541967062A6F4E460E892318E307F017BA048707B402493C' 
   USING ALGORITHM 'ARIA256'
   FORCE KEYSTORE
   IDENTIFIED BY keystore_password WITH BACKUP;

   The next example creates user-defined keys for both the master encryption ID and the TDE master encryption key. It omits the algorithm specification, so the default algorithm AES256 is used.

   ADMINISTER KEY MANAGEMENT CREATE ENCRYPTION KEY 
   '10203040506070801112131415161718:3D432109DF88967A541967062A6F4E460E892318E307F017BA048707B402493C' 
   IDENTIFIED BY keystore_password WITH BACKUP;

A keystore must be open before you can create a TDE master encryption key for use later on in isolated mode.

1. Connect to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
2. Create the TDE master encryption key by using the following syntax:

   ADMINISTER KEY MANAGEMENT CREATE KEY [USING TAG 'tag']
   [FORCE KEYSTORE]
   IDENTIFIED BY EXTERNAL STORE | keystore_password
   WITH BACKUP [USING 'backup_identifier'];

   In this specification:

   • FORCE KEYSTORE temporarily opens the password-protected TDE wallet for this operation. You must open the TDE wallet for this operation.

   • IDENTIFIED BY is required for the BACKUP KEYSTORE operation on a password-protected keystore because although the backup is simply a copy of the existing keystore, the status of the TDE master encryption key in the password-protected keystore must be set to BACKED UP and for this change the keystore password is required.

   • keystore_location is the path at which the backup keystore is stored. This setting is restricted to the PDB when the PDB lockdown profile EXTERNAL_FILE_ACCESS setting is blocked in the PDB or when the PATH_PREFIX variable was not set when the PDB was created. If you do not specify the keystore_location, then the backup is created in the same directory as the original keystore. Enclose this location in single quotation marks (' ').

   For example:

   ADMINISTER KEY MANAGEMENT CREATE KEY 
   FORCE KEYSTORE 
   IDENTIFIED BY keystore_password
   WITH BACKUP;

3. If necessary, activate the TDE master encryption key.
   1. Find the key ID.

      SELECT KEY_ID FROM V$ENCRYPTION_KEYS; 
      
      KEY_ID
      ----------------------------------------------------
      AWsHwVYC2U+Nv3RVphn/yAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

   2. Use this key ID to activate the key.

      ADMINISTER KEY MANAGEMENT USE KEY 
      'AWsHwVYC2U+Nv3RVphn/yAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' 
      USING TAG 'quarter:second;description:Activate Key on standby' 
      IDENTIFIED BY password 
      WITH BACKUP;

In isolated mode, you can move an existing TDE master encryption key into a new TDE wallet from an existing password TDE wallet.

1. Connect to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
2. Query the CREATION_TIME and KEY_ID columns of the V$ENCRYPTION_KEYS view to find the key identifier of the key that you want to move.
   For example:

   SELECT CREATION_TIME, KEY_ID FROM V$ENCRYPTION_KEYS; 
   
   CREATION TIME
   ----------------------------------------------------
   22-SEP-19 08.55.12.956170 PM +00:00
   
   KEY_ID
   ----------------------------------------------------
   ARaHD762tUkkvyLgPzAi6hMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

3. Move the key into a new TDE wallet by using the following syntax:

   ADMINISTER KEY MANAGEMENT 
   MOVE [ENCRYPTION] KEYS
   TO NEW KEYSTORE 'TDE_wallet_location1'
   IDENTIFIED BY TDE_wallet1_password
   FROM [FORCE] KEYSTORE
   IDENTIFIED BY TDE_wallet2_password
   [WITH IDENTIFIER IN
   { 'key_identifier' [, 'key_identifier' ]... | ( subquery ) }]
   [WITH BACKUP [USING 'backup_identifier'] ];

   In this specification:

   • TDE_wallet_location1 is the path to the wallet directory that will store the new TDE wallet .p12 file. By default, this directory is in $ORACLE_BASE/admin/db_unique_name/wallet.

   • TDE_wallet1_password is the password for the TDE wallet from which the new TDE wallet is moved.

   • FORCE temporarily opens the TDE wallet for this operation.

   • TDE_wallet2_password is the password for the TDE wallet from which the key is moving.

   • subquery can be used to find the exact key identifier that you want.

   • backup_identifier is an optional description of the backup. Enclose backup_identifier in single quotation marks (' ').

   For example:

   ADMINISTER KEY MANAGEMENT MOVE KEYS 
   TO NEW KEYSTORE '$ORACLE_BASE/admin/orcl/wallet' 
   IDENTIFIED BY TDE_wallet1_password 
   FROM FORCE KEYSTORE 
   IDENTIFIED BY TDE_wallet2_password 
   WITH IDENTIFIER IN 
   (SELECT KEY_ID FROM V$ENCRYPTION_KEYS WHERE ROWNUM < 2)
   WITH BACKUP;

   After the keys are moved to the new TDE wallet, they no longer exist in the old TDE wallet.
4. To delete the old TDE wallet, go to the wallet directory and do the following:
   1. Back up the .p12 file containing the TDE wallet that you want to delete.
   2. Manually delete the .p12 file containing the TDE wallet.
   To find the location of the TDE wallet, open the TDE wallet, and then query the WRL_PARAMETER column of the V$ENCRYPTION_WALLET view.

You can perform migration and reverse migration operations between TDE wallets and external keystores in isolated mode.

• Reverse Migrating an Isolated PDB from Oracle Key Vault to a TDE Wallet
  Isolated PDBs have individual keystores (TDE wallets or Oracle Key Vault external keystores), and can individually be migrated from the TDE wallet to Oracle Key Vault, and individually reverse migrated from Oracle Key Vault back to the TDE wallet.
• Migrating from an External Keystore to a Password-Protected TDE Wallet in Isolated Mode
  In isolated mode, you can migrate from an external keystore to a password-protected TDE wallet.

Uniting a PDB keystore moves the TDE master encryption keys from the PDB keystore into the keystore of the CDB root. This enables the administrator of the keystore of the CDB root to manage the keys.

1. Connect to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
2. Unite the PDB keystore, which moves the TDE master encryption keys from the PDB keystore into the keystore of the CDB root, by using the following syntax:

   ADMINISTER KEY MANAGEMENT UNITE KEYSTORE
   IDENTIFIED BY isolated_keystore_password
   WITH ROOT KEYSTORE [FORCE KEYSTORE]
   IDENTIFIED BY 
   [EXTERNAL STORE | keystore_password_of_cdb_root]
   [WITH BACKUP [USING backup_id]];

   In this specification:

   • FORCE KEYSTORE temporarily opens the password-protected TDE wallet for this operation if an auto-login TDE wallet is open (and in use) or if the TDE wallet is closed.

   • united_keystore_password: Knowledge of this password does not enable the user who performs the UNITE KEYSTORE operation privileges to perform ADMINISTER KEY MANAGEMENT UNITE KEYSTORE operations on the PDB.

   When the keystore of a PDB is united with a keystore in the CDB root, all of the previously active (historical) TDE master encryption keys that were associated with the PDB are moved to the keystore of the CDB root. (If an ORA-46694: The keys are already in the root keystore error appears, see below.)
3. Confirm that the isolated mode PDB is now a united mode PDB.

   SELECT KEYSTORE_MODE FROM V$ENCRYPTION_WALLET;

   The output should be UNITED.

ALTER SYSTEM RESET TDE_CONFIGURATION;

When you create a keystore in a PDB that is closed, the new keystore is empty and the PDB is converted to isolated mode.

• About Creating a Keystore When the PDB Is Closed
  Creating a keystore in a PDB that is closed could inadvertently cause problems in rekey operations, but the keystore creation can be reverted.
• Reverting a Keystore Creation Operation When a PDB Is Closed
  If you have inadvertently created a keystore in a PDB (and thereby caused it to become configured in isolated mode), then you should reverse the keystore creation operation.

You can clone or relocate encrypted PDBs within the same container database, or across container databases.

• Clone or relocate the PDB using the following syntax:

  CREATE|RELOCATE PLUGGABLE DATABASE database_name KEYSTORE 
  IDENTIFIED BY EXTERNAL STORE|target_keystore_password [NO REKEY];

The CREATE PLUGGABLE DATABASE statement with the KEYSTORE IDENTIFIED BY clause can clone a PDB that has encrypted data.

1. Connect to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
2. Ensure that the TDE wallet of the PDB that you plan to clone is open.

   You can query the STATUS column of the V$ENCRYPTION_WALLET view to find if the TDE wallet is open.

   For example:

   ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN FORCE KEYSTORE IDENTIFIED BY TDE_wallet_password;

3. Clone the PDB.

   For example:

   CREATE PLUGGABLE DATABASE cdb1_pdb3 FROM cdb1_pdb1 
   FILE_NAME_CONVERT=('cdb1_pdb1', 'pdb3/cdb1_pdb3') KEYSTORE 
   IDENTIFIED BY TDE_wallet_password;

   Replace TDE_wallet_password with the password of the TDE wallet of the CDB where the cdb1_pdb3 clone is created.

   After you create the cloned PDB, encrypted data is still accessible by the clone using the master encryption key of the original PDB. After a PDB is cloned, there may be user data in the encrypted tablespaces. This encrypted data is still accessible because the master encryption key of the source PDB is copied over to the destination PDB. Because the clone is a copy of the source PDB but will eventually follow its own course and have its own data and security policies, you should rekey the master encryption key of the cloned PDB.
4. Rekey the master encryption key of the cloned PDB.

   For example:

   ADMINISTER KEY MANAGEMENT SET KEY 
   IDENTIFIED BY TDE_wallet_password 
   WITH BACKUP USING 'emp_key_backup';

   Before you rekey the master encryption key of the cloned PDB, the clone can still use master encryption keys that belong to the original PDB. However, these master encryption keys do not appear in the cloned PDB V$ dynamic views. Rekeying the master encryption key ensures that the cloned PDB uses its own unique keys, which will be viewable in the V$ views.

The CREATE PLUGGABLE DATABASE statement with the KEYSTORE IDENTIFIED BY clause can remotely clone a PDB that has encrypted data.

1. Connect to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
2. Query the STATUS column of the V$ENCRYPTION_WALLET view to ensure that the TDE wallet of the PDB that you plan to clone is open.
3. Create a database link for the PDB that you want to clone remotely.
   Use the CREATE DATABASE LINK SQL statement to create the database link. You must create the database link by following the database link prerequisites that are required for cloning a remote PDB.
4. Use the CREATE PLUGGABLE DATABASE statement with the KEYSTORE IDENTIFIED BY clause to perform the clone of the PDB.

   For example:

   CREATE PLUGGABLE DATABASE target_pdb
   FROM source_pdb@clone_link KEYSTORE
   IDENTIFIED BY TDE_wallet_password;

   The TDE_wallet_password is the password of a new TDE wallet that will be created in WALLET_ROOT/target_pdb_guid/tde for the incoming PDB.

   After you create the cloned PDB, encrypted data is still accessible because the master encryption key of the source PDB is copied over to the destination PDB. Because it will eventually follow its own course and have its own data and security policies, you should rekey the master encryption key of the cloned PDB.
5. Rekey the master encryption key of the remotely cloned PDB.

   Run the following SQL statement to create an administer key management command with a TAG:

   SELECT ' ADMINISTER KEY MANAGEMENT SET KEY 
   USING TAG '''||SYS_CONTEXT('USERENV', 'CON_NAME')||' '||TO_CHAR (SYSDATE, 'YYYY-MM-DD HH24:MI:SS')||''' 
   IDENTIFIED BY KEYSTORE_PASSWORD WITH BACKUP;' 
   AS "SET KEY COMMAND" FROM DUAL;

   ADMINISTER KEY MANAGEMENT SET KEY USING TAG 'PDB_NAME DATE TIME' 
   IDENTIFIED BY KEYSTORE_PASSWORD WITH BACKUP;

   Before you rekey the master encryption key of the cloned PDB, the clone can still use master encryption keys that belong to the original PDB. However, these master encryption keys do not appear in the cloned PDB V$ dynamic views. Rekeying the master encryption key ensures that the cloned PDB uses its own unique keys, which will be viewable in the V$ views.

The CREATE PLUGGABLE DATABASE statement with the KEYSTORE IDENTIFIED BY clause can relocate across CDBs a cloned PDB that has encrypted data.

1. Connect to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
2. Query the STATUS column of the V$ENCRYPTION_WALLET view to ensure that the TDE wallet of the PDB that you want to relocate is open.
3. Create a database link for the PDB that you want to relocate.
   Use the CREATE DATABASE LINK SQL statement to create the database link. You must create the database link by following the database link prerequisites that are required for relocating a remote PDB or a non-CDB.
4. Use the CREATE PLUGGABLE DATABASE statement with the KEYSTORE IDENTIFIED BY clause to relocate the PDB.

   For example:

   CREATE PLUGGABLE DATABASE target_pdb_name 
   FROM src_pdb_name@dblink RELOCATE  
   KEYSTORE IDENTIFIED BY TDE_wallet_password;

   Replace TDE_wallet_password with the password of the TDE wallet of the CDB where the cdb1_pdb3 clone is created.

   After you create the cloned PDB, encrypted data is still accessible by the clone using the master encryption key of the original PDB. After a PDB is cloned, there may be user data in the encrypted tablespaces. This encrypted data is still accessible because the master encryption key of the source PDB is copied over to the destination PDB. Because the clone is a copy of the source PDB but will eventually follow its own course and have its own data and security policies, you should rekey the master encrytion key of the cloned PDB.
5. Rekey the master encryption key of the remotely cloned PDB.

   For example:

   ADMINISTER KEY MANAGEMENT SET KEY 
   FORCE KEYSTORE
   IDENTIFIED BY TDE_wallet_password 
   WITH BACKUP USING 'emp_key_backup';

   In this example, FORCE KEYSTORE is included because the TDE wallet must be open during the rekey operation.

   Before you rekey the master encryption key of the cloned PDB, the clone can still use master encryption keys that belong to the original PDB. However, these master encryption keys do not appear in the cloned PDB V$ dynamic views. Rekeying the master encryption key ensures that the cloned PDB uses its own unique keys, which will be viewable in the V$ views.