You can change the password of a software keystore 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 Software Keystore Password in Isolated Mode
  To change the password of a password-protected software keystore 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 Software Keystore in Isolated Mode
  You can close password-protected keystores, auto-login keystores, and local auto-login software keystores 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.
   For example:

   CONNECT sec_admin@pdb_name AS SYSKM

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).

     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

     • GOST256

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

   • FORCE KEYSTORE temporarily opens the password-protected keystore for this operation. You must open the keystore 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 'GOST256'
   FORCE KEYSTORE
   IDENTIFIED BY keystore_password;

   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;

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.
   For example:

   CONNECT sec_admin@pdb_name AS SYSKM

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 keystore for this operation. You must open the keystore 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 keystore from an existing software password keystore.

1. Connect to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
   For example:

   CONNECT sec_admin@pdb_name AS SYSKM

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 keystore by using the following syntax:

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

   In this specification:

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

   • keystore1_password is the password for the keystore from which the new keystore is moved.

   • FORCE temporarily opens the keystore for this operation.

   • keystore_password is the password for the keystore 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 keystore_password 
   FROM FORCE KEYSTORE 
   IDENTIFIED BY keystore_password 
   WITH IDENTIFIER IN 
   (SELECT KEY_ID FROM V$ENCRYPTION_KEYS WHERE ROWNUM < 2)
   WITH BACKUP;

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

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

• Migrating from a Password-Protected Software Keystore to an External Keystore in Isolated Mode
  In isolated mode, you can migrate from a password-protected software keystore to an external keystore.
• Migrating from an External Keystore to a Password-Protected Software Keystore in Isolated Mode
  In isolated mode, you can migrate from an external keystore to a password-protected software keystore.

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.
   For example:

   CONNECT sec_admin@pdb_name AS SYSKM

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 keystore for this operation if an auto-login keystore is open (and in use) or if the keystore 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.

In isolated mode, you can automatically move a PDB from one CDB to another (for example, for load balancing or adding new functionality).

1. Connect to the CDB root as a common user who has been granted the SYSDBA privilege.
   For example:

   CONNECT c##sec_admin AS SYDBA
   Enter password: password

2. Move (relocate) the PDB.

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.
   For example:

   CONNECT sec_admin@pdb_name AS SYSKM

2. Ensure that the software keystore 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 software keystore is open.

   For example:

   ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN FORCE KEYSTORE IDENTIFIED BY keystore_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 keystore_password;

   Replace keystore_password with the password of the keystore 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 keystore_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.
   For example:

   CONNECT sec_admin@pdb_name AS SYSKM

2. Query the STATUS column of the V$ENCRYPTION_WALLET view to ensure that the software keystore 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 cdb1_pdb3 
   FROM cdb1_pdb1 
   FILE_NAME_CONVERT=('cdb1_pdb1', 'pdb3/cdb1_pdb3') KEYSTORE 
   IDENTIFIED BY keystore_password;

   Replace keystore_password with the password of the keystore 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 keystore_password 
   WITH BACKUP USING 'emp_key_backup';

   In this example, FORCE KEYSTORE is included because the keystore 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.

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.
   For example:

   CONNECT sec_admin@pdb_name AS SYSKM

2. Query the STATUS column of the V$ENCRYPTION_WALLET view to ensure that the the software keystore 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 or a non-CDB.
4. Use the CREATE PLUGGABLE DATABASE statement with the KEYSTORE IDENTIFIED BY clause to clone the PDB.

   For example:

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

   Replace keystore_password with the password of the keystore 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. Use the ALTER PLUGGABLE DATABASE statement to perform the relocation operation.
   For example:

   ALTER PLUGGABLE DATABASE cdb1_pdb3
   OPEN RELOCATE TO 'need instance name example';

6. Rekey the master encryption key of the remotely cloned PDB.

   For example:

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

   In this example, FORCE KEYSTORE is included because the keystore 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.