You can close password-protected keystores, auto-login keystores, and local auto-login software keystores in united mode.

1. Connect to the CDB root as a common user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
   For example:

   CONNECT c##sec_admin AS SYSKM
   Enter password: password

2. Use the ADMINISTER KEY MANAGEMENT statement to close the software keystore.
   • For a password-protected software keystore, use the following syntax if you are in the CDB root:

     ADMINISTER KEY MANAGEMENT SET | FORCE KEYSTORE CLOSE 
     [IDENTIFIED BY [EXTERNAL STORE | software_keystore_password]]
     [CONTAINER = ALL | CURRENT];

     Use the SET clause to close the keystore without force. If there is a dependent keystore that is open (for example, an isolated mode PDB keystore and you are trying to close the CDB root keystore), then an ORA-46692 cannot close wallet error appears. If this happens, then use the FORCE clause instead of SET to temporarily close the dependent keystore during the close operation. The STATUS column of the V$ENCRYPTION_WALLET view shows if a keystore is open.

     If you are in the united mode PDB, then either omit the CONTAINER clause or set it to CURRENT.

   • For an auto-login or local auto-login software keystore, use this syntax if you are in the CDB root:

     ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE
     [CONTAINER =  ALL | CURRENT];

To close an external keystore, you must use the ADMINISTER KEY MANAGEMENT statement with the SET KEYSTORE CLOSE clause.

1. Connect to the CDB root as a common user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
   For example:

   CONNECT c##sec_admin AS SYSKM
   Enter password: password

2. Use the ADMINISTER KEY MANAGEMENT statement to close the external keystore.

   ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE 
   IDENTIFIED BY [EXTERNAL STORE | "external_keystore_credentials"]
   [CONTAINER = ALL | CURRENT];

   For example, for an HSM:

   ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE 
   IDENTIFIED BY "psmith:password"
   CONTAINER = ALL;

   If an ORA-46692 cannot close wallet error appears, then check if any isolated mode keystores are open. To find the status of a keystore, query the STATUS column of the V$ENCRYPTION_WALLET view.

A TDE master encryption key that is outside the database has its own user-generated ID, which tracks the use of the TDE master encryption key.

You can use the ADMINISTER KEY MANAGEMENT to create and set user-defined TDE master encryption key IDs. After you generate the TDE master encryption key, you can bring this key into the database. Optionally, you can specify the TDE master encryption key ID in various ADMINISTER KEY MANAGEMENT statements.

This type of configuration benefits Oracle Fusion SaaS Cloud environments in that it enables you to generate a TDE master encryption key this complies with your site’s requirements. This key that you generate supports the current encryption algorithms and can be used for software keystores.

After you generate the TDE master encryption key ID, you can encrypt your data as you normally would.

The TDE master encryption key and its corresponding ID will not be captured by any auditing logs.

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 CDB root as a common user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
   For example:

   CONNECT c##sec_admin AS SYSKM
   Enter password: password

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]
   [USING TAG 'tag_name']
   IDENTIFIED BY [EXTERNAL STORE | keystore_password] 
   [WITH BACKUP [USING 'backup_identifier']]
   [CONTAINER = CURRENT];

   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 value but include the mk, 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.

   • CONTAINER: If you include this clause, then set it to CURRENT. (CURRENT is the default.)

   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 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
   CONTAINER = CURRENT;

   The next scenario, where TDE master encryption key and key-ID are generated outside of the database, shows how to support separation of duties. A key administrator inserts the key with a key_ID into the wallet by using the ADMINISTER KEY MANAGEMENT CREATE [ENCRYPTION] KEY statement. Then, the key administrator sends the key_ID to the database administrator, who then activates the key by using the ADMINISTER KEY MANAGEMENT USE KEY clause.

   1. Create the key-ID using OpenSSL, converting characters to upper case:

      $ openssl rand 16 | xxd -u -p
      D20765EB721AF44D054B30FE87F8E49A

   2. Create the TDE master encryption key.

      $ openssl rand 32 -hex
      5a089c8ea6ee21cba774f61e58d102665df4a979a34757836b3d066a3eb3db11

   3. Use both strings to insert the new TDE master encryption key, using the default of AES256, into the wallet.

      ADMINISTER KEY MANAGEMENT CREATE ENCRYPTION KEY
      'D20765EB721AF44D054B30FE87F8E49A:5a089c8ea6ee21cba774f61e58d102665df4a979a34757836b3d066a3eb3db11'
      IDENTIFIED BY keystore_password;

   4. Because the database internally stores the key_ID in BASE64 format, the key administrator must convert the HEX key_ID to a BASE64 key-ID, using this syntax:

      $ echo "01hex key_ID followed by 44 zeros" | xxd -r -p | base64"

      For example:

      $ echo "01D20765EB721AF44D054B30FE87F8E49A00000000000000000000000000000000000000000000" 

   5. After the key administrator sent the key_ID to the database administrator, the database administrator then executes the following statement:

      ADMINISTER KEY MANAGEMENT USE ENCRYPTION KEY
      'AdIHZetyGvRNBUsw/of45JoAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
      IDENTIFIED BY keystore_password;

      Alternatively, the database administrator can retrieve the BASE64 key-ID from the database with the following SELECT statement:

      SELECT ' ADMINISTER KEY MANAGEMENT USE KEY '''||KEY_ID||''' 
      FORCE KEYSTORE IDENTIFIED BY KEYSTORE_PASSWORD WITH BACKUP;' 
      AS "USE KEY COMMAND" FROM V$ENCRYPTION_KEYS 
      WHERE CREATOR_PDBNAME = SYS_CONTEXT('USERENV', 'CON_NAME') 
      ORDER BY CREATION_TIME DESC FETCH FIRST 1 ROWS ONLY;

You can move an unused (and safely archived) TDE master encryption key into a new keystore.

Use great caution when you decide to execute ADMINISTER KEY MANAGEMENT MOVE KEYS. Even though this statement will not move an active master encryption key, it can still affect keys that are necessary for a range of database features. If you have deleted a key, then the data that was encrypted by that key is rendered permanently inaccessible (equivalent to deleting the data) for these features to be used. See Related Topics at the end of this topic for more information about features that are affected by deleted keystores.

Therefore, before you move the keystore, it is very important that you safely archive it. Delete the keystore only after a period of time has passed, to ensure that the keystore is no longer really useful.

To move a TDE master encryption key into a new keystore, you use the ADMINISTER KEY MANAGEMENT MOVE KEYS statement. This statement does not move the active TDE master encryption key (that is, the key that is currently in use at the time that ADMINISTER KEY MANAGEMENT MOVE KEYS is issued) because the database is currently using it.

If you mistakenly use the ADMINISTER KEY MANAGEMENT MOVE KEYS statement instead of ADMINISTER KEY MANAGEMENT MERGE KEYSTORE when you are configuring a new TDE keystore (for example, when you are changing the TDE keystore configuration from one where the software keystore is located in the operating system's file system to one where the software keystore is located in Oracle Automatic Storage Management (Oracle ASM)), then the following symptoms may help you to identify the TDE misconfiguration that was introduced by the use of the wrong key management command:

• When you open the TDE keystore that was the target of the earlier ADMINISTER KEY MANAGEMENT MOVE KEYS operation, an ORA-28374: typed master key not found in wallet error is seen, because the active TDE master encryption key was not moved to that keystore.
• The value shown in the STATUS column of the V$ENCRYPTION_WALLET view is OPEN_NO_MASTER_KEY after you open the new keystore. The OPEN_NO_MASTER_KEY status is expected, because the new TDE keystore that was mistakenly populated by means of the ADMINISTER KEY MANAGEMENT MOVE KEYS statement does not contain the active TDE master encryption key.

In united mode, you can move an existing TDE master encryption key into a new keystore from an existing software password keystore.

1. Connect to the CDB root as a common user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
   For example:

   CONNECT c##sec_admin AS SYSKM
   Enter password: password

2. Query the KEY_ID column of the V$ENCRYPTION_KEYS view to find the key identifier of the keystore to which you want to move the keys.
   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_identififier' [, '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;

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.

When you clone a PDB, you must make the master encryption key of the source PDB available to cloned PDB.

This allows a cloned PDB to operate on the encrypted data. To perform the clone, you do not need to export and import the keys because Oracle Database transports the keys for you even if the cloned PDB is in a remote CDB. However, you will need to provide the keystore password of the CDB where you are creating the clone.

If the PDBs have encrypted data, then you can perform remote clone operations on PDBs between CDBs, and relocate PDBs across CDBs.

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

1. Connect to the CDB root as a common user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
   For example:

   CONNECT c##sec_admin AS SYSKM
   Enter password: password

2. Query the STATUS column of the V$ENCRYPTION_WALLET dynamic view to ensure that the keystore is open in the CDB root.
3. Log in to the PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
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. Rekey the master encryption key of the 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 remotely clone a PDB that has encrypted data.

1. Connect to the CDB root as a common user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
   For example:

   CONNECT c##sec_admin AS SYSKM
   Enter password: password

2. Query the STATUS column of the V$ENCRYPTION_WALLET dynamic view to ensure that the keystore is open in the CDB root.
3. In this root container of the target database, create a database link that connects to the root container of the source CDB.

   CREATE DATABASE LINK clone_link 
   CONNECT TO C##REMOTE_CLONE_USER 
   IDENTIFIED BY C##REMOTE_CLONE_USER_PASSWORD 
   USING '//source_ip_address:port/DB_NAME';

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 cbd_1_pdb1@clone_link 
   FILE_NAME_CONVERT=('cdb1_pdb1', 'pdb3/cdb1_pdb3') KEYSTORE 
   KEYSTORE IDENTIFIED BY EXTERNAL STORE|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 a PDB with encrypted data across CDBs.

1. Connect to the CDB root as a common user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
   For example:

   CONNECT c##sec_admin AS SYSKM
   Enter password: password

2. Query the STATUS column of the V$ENCRYPTION_WALLET dynamic view to ensure that the keystore is open in the CDB root.
3. Create a database link for the PDB that you want to clone.
   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 clone the PDB.

   For example:

   CREATE PLUGGABLE DATABASE cdb1_pdb3 
   FROM cdb1_pdb1@clone_link RELOCATE [AVAILABILITY MAX] 
   [FILE_NAME_CONVERT=('cdb1_pdb1', 'pdb3/cdb1_pdb3')] 
   KEYSTORE IDENTIFIED BY EXTERNAL STORE|keystore_password;

   Replace keystore_password with the password of the keystore of the CDB where the cdb1_pdb3 clone is created.

   After you have relocated the PDB, the encrypted data is still accessible because the master encryption key of the source PDB is copied over to the destination PDB. The relocated PDB is a copy of the source PDB, but it will eventually follow its own course and have its own data and security policies. Therefore, you should rekey the master encrytion key of the cloned PDB.
5. Connect to the PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
6. Rekey the master encryption key of the remotely cloned PDB.

   For example:

   ADMINISTER KEY MANAGEMENT SET KEY 
   FORCE KEYSTORE
   IDENTIFIED BY EXTERNAL STORE|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.