11 Oracle Key Vault Use Case Scenarios

Typical Oracle Key Vault use cases include the upload and download of security objects, the use of an Online Master Key, and TDE-configured Oracle databases.

Note that the term Online Master Key replaces TDE direct connect.

Topics:

11.1 Uploading and Downloading Oracle Wallets

In order to store and share Oracle wallets you must upload them to Key Vault. You can then create a new virtual wallet in Key Vault, and add security objects to it that you want to share. You must grant endpoints access to the virtual wallet before they can download it.

Topics:

11.1.1 About Uploading and Downloading Oracle Wallets

The okvutil utility comes packaged with the endpoint software that you install at the endpoint. You can use the okvutil upload and okvutil download commands to upload and download Oracle wallets between Oracle Key Vault and its endpoints.

The Oracle Key Vault endpoint software can read an Oracle wallet at the granularity level of an individual security object. It therefore uploads the wallet contents as individual items. During download you can recreate the original wallet with the same set of security objects, or create a new wallet with different set of security objects.

You can upload and download both password-based wallets and auto-login wallets. The wallet contents can be downloaded later into a new wallet of either type. For example, an uploaded password-protected wallet can be downloaded as an auto-login wallet, or an uploaded auto-login wallet can be downloaded as a password-protected wallet.

You can use Oracle Key Vault to construct a new virtual wallet containing security objects from previously uploaded Oracle wallets. For example, given a previously uploaded Oracle wallet containing five symmetric keys and three opaque objects, you can create a new virtual wallet consisting of only three of the original five symmetric keys and one of the three original opaque objects. This virtual wallet can be downloaded like the original wallet to provide the endpoint with access to only a subset of the keys. This process does not modify the original wallet.

11.1.2 Uploading Oracle Wallets

Uploading wallets to Key Vault is done with the okvutil upload command. Everything in the Oracle wallet, security objects and their metadata is uploaded to Key Vault, so that the wallet can be reconstructed during the download process. The Oracle wallet typically contains TDE master keys, historical TDE master keys, SSL or TLS certificates and their metadata (stored in Key Vault as opaque objects), wallet metadata, as well as keys that you have explicitly added.

To upload an Oracle wallet:

  1. Ensure that the server containing the Oracle wallet has been enrolled and provisioned as a Key Vault endpoint.
  2. Ensure that the endpoint has access to the virtual wallet that you want to use.

    The endpoint must have Read, Modify, and Manage Wallet access to the virtual wallet in Oracle Key Vault.

  3. Run the okvutil upload command to upload the wallet.

    For example:

    okvutil upload -l "/etc/oracle/wallets" -t wallet -g "HRWallet"
    Enter wallet password (<enter> for auto-login): password
    Enter Oracle Key Vault endpoint password: Key_Vault_endpoint_password
    Upload succeeeded
    

    In this example:

    • -l specifies the directory location of the wallet that you are uploading.

    • -t indicates the type, in this case, an Oracle wallet.

    • -g specifies the Key Vault virtual wallet that was configured in Step 2, so that this wallet can be part of that virtual wallet.

    • Password prompts for the password-protected Oracle wallet, and the endpoint password.

At this point, the upload is complete. You can now share the virtual wallet with other users and endpoints.

11.1.3 Downloading Oracle Wallets

You can use the okvutil download command to download an Oracle wallet from the Oracle Key Vault server to an endpoint.

To download an Oracle wallet:

  1. Ensure that the endpoint has Read access on the virtual wallet that you want to download.
  2. Run the okvutil download command to download the wallet.

    For example:

    okvutil download -l "/etc/oracle/wallets/orcl/" -t WALLET -g HRWallet
    Enter new wallet password(<enter> for auto-login): Oracle_wallet_password
    Confirm new wallet password: Oracle_wallet_password
    Enter Oracle Key Vault endpoint password: Key_Vault_endpoint_password
    

    In this example:

    • -l is the location of the wallet to be created.

    • -t indicates the type, in this case, an Oracle wallet.

    • -g specifies the Oracle Key Vault virtual wallet that was configured in Step 1.

    • Password prompts for the password-protected Oracle wallet, and the endpoint password.

    If the wallet already exists and you did not use the -o parameter to overwrite the existing wallet, then the following actions take place:

    • The existing wallet is renamed to a backup name of the format ewallet.p12.current_timestamp where the timestamp is number of seconds since epoch.

    • The newly downloaded wallet is given the name ewallet.p12.

  3. If the Oracle wallet that you downloaded from Oracle Key Vault is to be used as a TDE wallet, then close the existing wallet before downloading and, if it is password-protected, then reopen it afterward. (Auto-login wallets are automatically opened the next time that they are accessed.)

    Closing and then reopening the wallet loads the wallet contents into the TDE database.

    • For Oracle Database 11g Release 2:

      ALTER SYSTEM SET ENCRYPTION WALLET CLOSE IDENTIFIED BY "Oracle_wallet_password"; 
      
      ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "Oracle_wallet_password"; 
      
    • For Oracle Database 12c:

      ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "Oracle_wallet_password";
      
      ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "Oracle_wallet_password";
      
  4. If you are operating in a shared server configuration such as Oracle RAC, then restart the database.

See Also:

11.1.4 Recommendations for Uploading and Downloading Oracle Wallets

Oracle provides recommendations for when you upload and download Oracle wallets.

  • If there is a change to the content of the original wallet, such as a key rotation or a rekey operation, then upload the wallet again to Oracle Key Vault so that Key Vault has the latest copy of the wallet.

  • The okvutil upload and download commands provide an overwrite (-o) option. Use care if you plan to specify this option because it overwrites data in the virtual wallet that conflicts with the data to be uploaded. Before you use the -o option, you should create a local backup of the wallet file.

  • Do not try to upload the same physical Oracle wallet to more than one virtual wallet on the Oracle Key Vault server. If you want to share an Oracle wallet with multiple endpoints, then create an endpoint group.

11.2 Uploading and Downloading JKS and JCEKS Keystores

You can use the okvutil upload and okvutil download commands to upload and download JKS and JCEKS keystores.

Topics:

11.2.1 About Uploading and Downloading JKS and JCEKS Keystores

You can upload both JKS and JCEKS keystores to Oracle Key Vault for long-term retention, recovery, and sharing, and when you need them, download them to an endpoint.

Similar to wallets, when you upload a JKS or JCEKS keystore, Oracle Key Vault can read each item within the keystore. It uploads the keystore contents as individual items.

11.2.2 Uploading JKS or JCEKS Keystores

You can use the okvutil upload command to upload a Java keystore (JKS) or Java Cryptography Extension keystore (JCEKS) to the Oracle Key Vault server.

To upload a Java keystore:

  1. Ensure that the server containing the Java keystore has been enrolled and provisioned as a Key Vault endpoint.
  2. Ensure that access control has been configured for the endpoint.

    If you are uploading the keystore to a virtual wallet, then ensure that the endpoint has the Read, Modify, and Manage Wallet access to this wallet.

  3. Run the okvutil upload command to upload the keystore.

    The following examples show how to upload the keystore to a virtual wallet:

    This example shows how to upload a JKS keystore:

    okvutil upload -l "/etc/oracle/fin_jks.jks" -t JKS -g "FinanceGrp"
    Enter source Java keystore password: Java_keystore_password
    Enter Oracle Key Vault endpoint password: Key_Vault_endpoint_password
    Upload succeeded
    

    In this example:

    • -l is the location of the Java keystore that is being uploaded.

    • -t is the type of JKS or JCEKS keystore. Ensure that you upload the correct type of Java keystore when you upload and later on, when you download.

    • -g is the virtual wallet in Oracle Key Vault where the Java keystore contents will be uploaded.

    • Password prompts for the keystore and endpoint.

    This example shows how to upload a JCEKS keystore:

    okvutil upload -l "/etc/oracle/hr_jceks.jceks" -t JCEKS -g "HRGrp"
    Enter source Java keystore password: password
    Enter Oracle Key Vault endpoint password: password
    Upload succeeded
    

At this point, the upload is complete. You are now ready to share or download the Java keystore as needed.

See Also:

11.2.3 Downloading JKS or JCEKS Keystores

You can use the okvutil download command to download an uploaded JKS or JCEKS keystore.

To download a Java keystore:

  1. Ensure that the endpoint has the Read access on the virtual wallet that you want to download.
  2. As an endpoint administrator, from the command line, run the okvutil download command to download the Java keystore.

    For example:

    okvutil download -l "/etc/oracle/new_java_files/hr_jceks.jceks" -t JCEKS
    Enter new Java keystore password: password
    Confirm new Java keystore password: password
    Enter Oracle Key Vault endpoint password: Key_Vault_endpoint_password
    

    In this example:

    • -l is the directory to which you want to download the uploaded Java keystore.

    • -t is the type of JKS or JCEKS keystore. Ensure that you download the correct type of Java keystore.

    • Password prompts for keystore and endpoint password.

See Also:

11.2.4 Recommendations for Uploading and Downloading JKS and JCEKS Keystores

Oracle provides recommendations for when you upload and download JKS and JCEKS keystores.

  • If there is a change to the content of the original JKS or JCEKS keystore, then upload the keystore again to Oracle Key Vault so that Key Vault has the latest copy of the keystore.

  • The okvutil upload and download commands provide an overwrite (-o) option. Use care if you plan to specify this option because it overwrites the file. You may want to create backups of the keystores before downloading them.

  • Do not try to upload the same physical JKS or JCEKS keystore to more than one virtual wallet on the Oracle Key Vault server. If you want to share a Java keystore with multiple endpoints, then create an endpoint group.

    See Also:

    "Manage Endpoint Groups" for more instructions to create an endpoint group

11.3 Uploading and Downloading Credential Files

You can use the okvutil upload and okvutil download commands to upload and download credential files.

Topics:

11.3.1 About Uploading and Downloading Credential Files

Credential files are uploaded and stored as opaque objects in Key Vault, which means that Key Vault does not parse the contents of the file like an Oracle wallet or Java keystore. The upload process does not alter the credential file.

Examples of opaque objects are as follows:

  • Files that contain X.509 certificates

  • Kerberos keytabs

  • Files containing passwords

  • Files containing SSH keys

Uploading these credential files provides a central, secure location for long-term retention. After you have uploaded a credential file, you can download it in the same server location or share it with other trusted server locations. Oracle Key Vault supports credential files up to 128 KB in size.

The credential file can be located anywhere in your server infrastructure (which includes database servers and application servers) that is accessible by an Oracle Key Vault endpoint.

11.3.2 Uploading a Credential File

To upload a credential file with okvutil upload:

  1. Ensure that the server that contains the credential file has been enrolled and provisioned as a Key Vault endpoint.
  2. Ensure that access control has been configured for the endpoint.

    If you are uploading the credential file to a virtual wallet, then ensure that the endpoint has Read, Modify, and Manage Wallet access to the wallet.

  3. Run the okvutil upload command.

    For example:

    okvutil upload -l "/etc/oracle/app/creds/hr.keytab" -t kerberos -g HRWallet -d "Kerberos keytab file for HR group, 06_11_14"
    Enter Oracle Key Vault endpoint password: Key_Vault_endpoint_password
    

    In this example:

    • -l is the directory path to the hr.keytab credential file that is being uploaded. Enclose the directory location in double quotation marks.

    • -t specifies the type of credential file, which in this example is a Kerberos keytab file. In addition to KERBEROS, other types that you can specify are as follows:

      • SSH for an SSH key file

      • OTHER for other files that store secrets, such as uploaded or downloaded files

    • -g adds the credential file to the HRWallet group, which already exists. This parameter enables you to upload the credential to a wallet that is specifically for the HR application users' needs, rather than to the default virtual wallet. In this example, HRWallet is the Key Vault virtual wallet to which access control was configured in Step 2.

    • -d is an optional description. As a best practice, include a brief description of what the credential file is used for and the date you performed the upload. This information helps for future reference and tracking of the credential file. You can modify this description later on in the Oracle Key Vault management console if necessary.

    • Password prompts: Enter the endpoint password and confirm it.

    The following output should appear:

    Upload succeeded
    

11.3.3 Downloading a Credential File

To download a credential file using okvutil download:

  1. Find the unique ID of the credential file that you must download, by using one of the following methods:
    • Oracle Key Vault management console: Log in as a user who has been granted the Key Administrator role or a user who has the necessary access to the virtual wallet. In the Oracle Key Vault management console, from the Keys & Wallets tab, select All Items to find the uploaded files. Note the unique ID of the uploaded file that you want to download. Credential files are listed as opaque objects.

    • okvutil list command: Run the okvutil list command from an endpoint that has access to the credential file or a virtual wallet that contains the credential file. Locate the unique ID of the credential file that you must download based on the description that you provided when you uploaded the file.

  2. From the command line, run the okvutil download command to download the uploaded credential file.

    For example:

    okvutil download -l "/etc/oracle/app/newcreds/hr.keytab" -t kerberos -i 6ba7b810-9dad-11d1-80b4-00c04fd430c8
    Enter Oracle Key Vault endpoint password: Key_Vault_endpoint_password
    

    In this example:

    • -l is the directory to which you want to download the uploaded credential.

    • -t specifies the type of credential file, which in this example is a Kerberos keytab file. In addition to KERBEROS, other types that you can specify are as follows:

      • SSH for an SSH key file

      • OTHER for other files that store secrets, such as uploaded or downloaded files

    • -i is the unique ID of the credential file.

    Output similar to the following appears:

    Download succeeded
    

11.3.4 Recommendations for Uploading and Downloading Credential Files

Oracle provides recommendations for when you upload and download credential files.

  • After you complete the upload, upload credential file again the next time it is changed. Otherwise, the uploaded (and subsequent downloaded version) file will be outdated. Periodically, you should compare the last modification date of the credential file with the timestamp of the uploaded version.

  • The okvutil upload and download commands provide an overwrite (-o) option. Use care if you plan to specify this option, because it overwrites the uploaded credential file. You may want to create backups of the credential files before beginning the upload and download processes.

  • You can share one credential file among multiple server endpoints. Add the opaque object to a virtual wallet and then ensure that all of the endpoints have access to that virtual wallet. Optionally, define an endpoint group and then make all the server endpoints members of that group. Upload the credential file that you would like to share using this common wallet into Oracle Key Vault as a group, using the -g option of the okvutil upload command. Define a wallet and attach it to the endpoint group. All the members of the group will have access to that wallet.

11.4 Using an Online Master Key with Oracle Key Vault

You can configure Transparent Data Encryption (TDE) to perform a direct connection to an endpoint to centrally manage TDE master keys.

Note that the term Online Master Key replaces TDE direct connect.

Topics:

11.4.1 About Using an Online Master Key with Oracle Key Vault

For Oracle Database 11g Release 2 (11.2) and later, you can use an Online Master Key to centrally manage Transparent Data Encryption (TDE) master keys over a network connection as an alternative to using local Oracle wallet files.

The connection configuration entails using a PKCS#11 library to connect to Oracle Key Vault. After you perform the configuration, all future TDE master keys will be stored and managed in Oracle Key Vault. This section explains two scenarios that you can use:

  • If the database does not yet have TDE wallets.

  • If the database has already been configured for TDE.

TDE key management operates with Oracle Key Vault in the same way that it operates with hardware security modules (HSMs). You must open the wallet before encryption and decryption. After you close the wallet, encrypted data in tables and tablespaces is unavailable to you. You should rotate the TDE master encryption key regularly to remain in compliance with the applicable regulations.

Oracle Key Vault supports the SQL statements that were used to administer earlier TDE releases, specifically the use of the ALTER SYSTEM and ADMINISTER KEY MANAGEMENT SQL statements.

11.4.2 Other Oracle Database Features That Oracle Key Vault Supports

You can deploy TDE in multiple topologies with other database features that move or use clustered deployments.

Data movement and replication are major challenges for Oracle Advanced Security TDE because it must keep the master encryption key synchronized at both endpoints. To help with these challenges, Oracle Key Vault supports common Oracle Database features.

To move data, Oracle Key Vault supports:

  • Oracle Recovery Manager (RMAN) backup and recovery operations

  • Oracle Data Pump

  • Transportable tablespaces (Oracle Database 12c and later)

For clustered deployments, Oracle Key Vault supports:

  • Oracle Active Data Guard

  • Oracle Real Application Clusters (Oracle RAC)

  • Oracle GoldenGate

11.4.3 Configuring a Connection Between Oracle Key Vault and a New TDE-Enabled Database

You can configure a connection between Oracle Key Vault and a database that has not yet been configured for Transparent Data Encryption.

Before you start configuring the connection, ensure that the Oracle Key Vault installation environment is the same as the Database runtime environment. The environment variables ORACLE_HOME, ORACLE_BASE, and ORACLE_SID, if used, must be set to the same values in svrctl and OS environments. This also applies if you are using the Oracle Key Vault RESTful Services utility to enroll endpoints.

Configure the connection as follows:

  1. Ensure that the ORACLE_BASE environment variable is set before you start the oracle process manually. This is very important.

    If the ORACLE_BASE environment variable is not present, create a soft link from the:

    $ORACLE_BASE/okv/$ORACLE_SID/okvclient.ora file

    to the:

    key_vault_endpoint_installation_dir/conf/okvclient.ora file.

    In an Oracle Real Application Clusters environment, perform this step on all database instances.

    Note:

    To learn more about using environment variables in SQLNET.ORA please see the See Also section at the end of this procedure.

  2. Ensure that the COMPATIBILITY initialization parameter is set to 11.2.0.0 or later.

  3. Enroll and provision the endpoint for the TDE-enabled database that contains the TDE data.

    When you initially enroll the endpoint, select Oracle Database as the endpoint type for integration with TDE.

  4. Ensure that the endpoint has access to the virtual wallet that you want to use.

    The endpoint must have the Read, Modify, and Manage Wallet access.

  5. Configure the sqlnet.ora file on this database to point to Oracle Key Vault as follows:

    ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=HSM))
    

    Transparent Data Encryption uses HSM as the parameter value for all external key management systems, including Oracle Key Vault. Therefore the configuration settings and administrative commands are similar to those used for an HSM.

    By default, the sqlnet.ora file is located in the ORACLE_HOME/network/admin directory or in the location set by the TNS_ADMIN environment variable. Endpoints use the PKCS#11 library support to manage TDE master encryption keys.

    Note:

    At this stage, Oracle Key Vault can use TDE and all the TDE-related SQL statements are available. For all TDE commands and statements, use the Key Vault endpoint password that was specified during the endpoint enrollment process.

  6. Reconnect to the database if you are in SQL*Plus.

    The changes will appear after you log out of the current SQL*Plus session and then reconnect again.

  7. Query the V$ENCRYPTION_WALLET dynamic view to ensure that the METHOD_DATA setting in the sqlnet.ora file changed.

    The output of the query should now show HSM.

    SELECT * FROM V$ENCRYPTION_WALLET;
    
  8. Configure TDE to integrate with Key Vault, so that Key Vault can directly manage the TDE master keys as follows:

    1. On UNIX platforms, run the root.sh script as the root user to copy the liborapkcs.so file (located in the lib directory) to the /opt/oracle/extapi/64/hsm/oracle/1.0.0 directory.

      The persistent master key cache feature is implemented in the Oracle Key Vault PKCS#11 library and improves the availability of the database during intermittent network disruptions or Oracle Key Vault upgrade.

      By default, the PKCS#11 library is located in the $OKV_HOME/bin/liborapkcs.so file. Copy it to the following location on a UNIX system:

      /opt/oracle/extapi/64/hsm/oracle/1.0.0
      

      On Windows platforms, run the root.bat script as the root user to copy the liborapkcs.dll file (located in the lib directory) to the C:\oracle\extapi\64\hsm\1.0.0 directory. Provide the database version when prompted.

    2. For password-protected wallets on the database, open the wallet. (Auto-login wallets are automatically opened.)

      For Oracle Database 11g Release 2, as a user who has been granted the ALTER SYSTEM system privilege:

      ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "Key_Vault_endpoint_password"; 
      

      For Oracle Database 12c, as a user who has been granted the SYSKM administrative privilege:

      ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "Key_Vault_endpoint_password"; 
      
    3. Set the master encryption key.

      For Oracle Database 11g Release 2:

      ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "Key_Vault_endpoint_password"; 
      

      For Oracle Database 12c:

      ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY "Key_Vault_endpoint_password";
      

The TDE configuration is complete at this stage. You can now encrypt tables or create encrypted tablespaces in the database.

If you have configured the sqlnet.ora file correctly along with the rest of the TDE configuration, a TDE master key is created in Oracle Key Vault when you set the encryption key using one of the following commands:

  • ALTER SYSTEM SET ENCRYPTION KEY

  • OR

  • ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY

Limitations to TDE Endpoint Integration

The limitations to TDE endpoint integration are as follows:

  • All endpoints on the same machine must use the same version of the Oracle Key Vault library. There is only one location per machine for the liborapkcs.so file, which is:

    /opt/oracle/expapi/64/hsm/oracle/1.0.0/liborapkcs.so
    
  • On the same machine it is best to use the same external key manager for Oracle Database, either Oracle Key Vault or HSM. Using Oracle Key Vault for one Oracle Database and HSM for another Oracle Database can cause the wrong PKCS#11 library to be loaded, because Oracle Database picks up the first PKCS#11 library while traversing the subtree:

     /opt/oracle/expapi/64/hsm/
    

Caution:

Oracle strongly recommends NEVER to remove keys from a wallet or the wallet itself after TDE is setup. Loss of keys will result in the loss of encrypted data and hamper the normal functioning of the database. This is true even:
  • If there is no encrypted data in the system

  • If all of the encrypted data has been decrypted

  • If you have migrated your keys and wallets to a hardware security module

See Also:

11.4.4 Migrating Existing TDE Wallets to Oracle Key Vault

You can migrate an existing TDE wallet to Oracle Key Vault, and if necessary, restore the database contents that were previously encrypted by TDE, by using an Oracle wallet.

Topics:

11.4.4.1 About Migrating Existing TDE Wallets to Oracle Key Vault

When the TDE wallets already exist, you must modify the sqlnet.ora file to recognize Oracle Key Vault before you can migrate the existing TDE wallets to Key Vault.

Along with the current TDE master key, Oracle wallets maintain historical TDE master keys that are replaced by each rekey operation that rotates the TDE master key. These historical TDE master keys help to restore Oracle Database backups that were previously made using one of the historical TDE master keys. During the TDE migration from an Oracle wallet file to Oracle Key Vault, Key Vault generates new master keys. After this master key generation, Oracle Key Vault maintains all new keys.

Oracle recommends that you upload the Oracle wallet to Key Vault, before you perform the migration. This enables you to keep a backup of the wallet with all of the historical key information, before you begin the migration. When the migration is complete, manually delete the old wallet on the client system.

If you are operating in a shared server or an Oracle RAC configuration, then you must restart the database so that the new TDE master key is updated to all the endpoint database nodes in the shared server configuration.

11.4.4.2 Migrating an Existing TDE Wallet to Oracle Key Vault

You can use the okvutil upload command to migrate an existing TDE wallet to Oracle Key Vault. It is very important that you close the software wallet and open the HSM wallet before migrating the wallet in the same SQLPLUS session, as outlined in steps 7 and 8 below:

  1. Back up the database that contains the data that you want to migrate.

  2. Complete the enrollment of the endpoint.

  3. If you have not done so already, then upload the existing Oracle wallet to Key Vault, by using the okvutil upload command.

    This step ensures that Oracle Key Vault has a copy of the wallet that contains all of the historical TDE master keys.

  4. Configure the Oracle Database sqlnet.ora file for the HSM as follows:

    ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=HSM)(METHOD_DATA=(DIRECTORY=wallet_location)))
    

    By default, the sqlnet.ora file is located in the ORACLE_HOME/network/admin directory or in the location set by the TNS_ADMIN environment variable.

  5. Reconnect to the database if you are in SQL*Plus.

    The changes do not appear until you restart the database session.

  6. Query the V$ENCRYPTION_WALLET dynamic view to ensure that the METHOD_DATA setting in the sqlnet.ora file changed. The output of the query should now show METHOD=HSM.

    SELECT * FROM V$ENCRYPTION_WALLET;
    
  7. If the endpoint is a Release 11gR2 Oracle database, then close the local Oracle wallet and open the HSM wallet as follows:

    1. Close the local Oracle wallet using these steps:

      1. If the auto-login wallet is open, execute the following commands:

        oracle$ cd <wallet location>
        oracle$ mv cwallet.sso cwallet.sso.bak
        sqlplus> alter system set wallet close;
        
      2. If the password-protected wallet is open, execute the following command:

        sqlplus> alter system set wallet close identified by "<wallet password>";
        
    2. Open the HSM wallet:

      sqlplus> alter system set wallet open identified by "<HSM connect string>";
      
  8. Migrate from TDE wallets to Oracle Key Vault.

    • For Oracle Database 11g Release 2:

      If you entered a password for the wallet while installing the endpoint client software, then execute this command:

      sqlplus> alter system set encryption key identified by "<endpoint password>" migrate using "<wallet password>"; 
      

      If you chose the auto-login option while installing the endpoint client software, then execute this command:

      sqlplus> alter system set encryption key identified by "null" migrate using  "<wallet password>";
      
    • For Oracle Database 12c, as a user who has been granted the SYSKM administrative privilege:

      sqlplus> administer key management set encryption key identified by "<endpoint password>" MIGRATE USING "<wallet password>" with backup; 
      

      Note:

      While the with backup clause is required for the administer key management command, it is ignored by TDE in Oracle Key Vault

  9. Open the wallet. If the endpoint requires a password to connect to Oracle Key Vault, then enter the password.

    • For Oracle Database 11g Release 2:

      ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "Key_Vault_endpoint_password"; 
      
    • For Oracle Database 12c:

      ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "Key_Vault_endpoint_password";
      
  10. After you complete the migration, if you are using an auto-login wallet, then re-enable it by renaming the cwallet.sso.bak file to cwallet.sso.

11.4.4.3 Restoring Database Contents Previously Encrypted by TDE Using an Oracle Wallet

When an Oracle database endpoint is converted from a local Oracle wallet file to using Oracle Key Vault, there may be a subsequent need to restore backups that were encrypted using a key from this local wallet file.

In this case, you must download the necessary key from Oracle Key Vault to a local wallet file to be used when you decrypt the backup during the restore process. For example, suppose that the Finance_DB database had recently migrated to use an Online Master Key to Oracle Key Vault after you have uploaded the premigration wallet. If a system failure forces you to restore from a database backup taken before the migration to Oracle Key Vault, you can still restore the contents of the database by using an Oracle wallet downloaded from the Oracle virtual wallet that contains the Finance_DB wallet data that you had uploaded earlier.

To restore previously TDE-encrypted database contents using an Oracle wallet:

  1. Download this Oracle wallet from Oracle Key Vault by using the okvutil download command.
  2. On the endpoint where you downloaded the Oracle wallet, add the following settings to the sqlnet.ora file.
    METHOD_DATA=wallet_file_path
    
    METHOD=FILE
    ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=wallet_file_path)))
    

    Put the ENCRYPTION_WALLET_LOCATION setting on one line.

  3. If you created a password-protected wallet in Step 1, then open the wallet using the password you specified.
    • For Oracle Database 11g Release 2, as a user who has been granted the ALTER SYSTEM system privilege:

      ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "wallet_password"; 
      
    • For Oracle Database 12c, as a user who has been granted the SYSKM administrative privilege:

      ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "wallet_password";
      

    Opening the wallet enables the server to read the contents of the updated sqlnet.ora file. At this point, the endpoint server has been restored to a state where it now can run with the original version of the wallet.

11.4.5 Persistent Master Key Cache

The persistent master key cache feature enables databases to be operational when the Key Vault server is unavailable for any reason. The TDE master key is cached in the persistent cache in addition to the in-memory cache, so it works across database processes. It eliminates the need for databases to contact the Key Vault server for every new process, redo log switch, or database startup. Implemented in the Oracle Key Vault PKCS#11 library it additionally eliminates the need for database patching for previous database releases.

Topics:

About Persistent Master Key Cache

11.4.5.1 About Persistent Master Key Cache

The goal of persistent master key cache is to increase availability of TDE master keys by reducing dependence on the state of the Oracle Key Vault server.

Increased availability of TDE master keys offers the following benefits:

  • Continuous operation of endpoints during upgrade, high availability configuration, switchover, failover, and other procedures that require database restarts .

  • Overload prevention of the Key Vault server from multiple sessions of a single database requesting the same master key.

  • Improved scalability of Key Vault.

About Oracle Key Vault Persistent Cache Architecture

The Oracle Key Vault persistent cache is implemented in the Oracle Key Vault’s PKCS#11 library. If persistent cache is configured, it will be created by the PKCS#11 library when the master key is retrieved from Oracle Key Vault.

Physically, the persistent cache is an auto-login wallet or a password-based wallet. If the Key Vault endpoint software was installed with a password, then the persistent cache is a password-based wallet. If the endpoint software was installed without a password, the persistent cache is an auto-login wallet.

PKCS#11 in-memory and persistent caches are independent of each other. They can be enabled and disabled separately.

Persistent Master Key Cache Operations in Oracle Key Vault

When the master key is first fetched from the Oracle Key Vault server, or created in the Oracle Key Vault server, the master key is stored in the persistent cache. If the persistent cache is available, it will be used. If the persistent cache is not available, it will be created. When the master key is deleted from the Oracle Key Vault server, it will be removed from the cache. Once the key is fetched and stored in the cache, all future sessions will retrieve it from the persistent cache.

Persistent Cache Timeout Parameter

PKCS11_PERSISTENT_CACHE_TIMEOUT is the parameter that determines how long a master key can be cached. It is specified in minutes. After this interval, a master key in the cache expires and will not be used.

Persistent cache timeout is set per master key. The time a key is cached (cache time) is noted and stored along with the key. If the time interval from the time of caching exceeds the value set in PKCS11_PERSISTENT_CACHE_TIMEOUT , the key will expire and not be used. Expired master keys are not deleted from the persistent cache. Two different master keys cached at different times, will expire at different times. Note that the time a master key is cached is reset each time the key is refreshed.

The default value for PKCS11_PERSISTENT_CACHE_TIMEOUT is 1440 (minutes).

The persistent cache can be disabled by setting the PKCS11_PERSISTENT_CACHE_TIMEOUT to zero.

Note:

In releases prior to Release 12.2.0.4.0, customers were unaware of the PKCS11_PERSISTENT_CACHE_TIMEOUT parameter as it was absent from okvclient.ora. The parameter PKCS11_PERSISTENT_CACHE_TIMEOUT and its value has been explicitly added to okvclient.ora.
Location on Disk

The persistent cache is stored in the same location as the configuration file okvclient.ora. The default location for the okvclient.ora file is the directory: $OKV_HOME/conf.

If the environment variable ORACLE_BASE is set, the persistent cache will be created in $ORACLE_HOME/okv/$ORACLE_SID.

If ORACLE_BASE is not set, and ORACLE_HOME is set, the persistent cache will be created in $ORACLE_HOME/okv/$ORACLE_SID.

If neither ORACLE_BASE nor ORACLE_HOME is set, and OKV_HOME is set, then the persistent cache will be created in OKV_HOME.

If none of the following environment variables is set:

  • ORACLE_BASE

  • ORACLE_HOME

  • OKV_HOME

The persistent cache will be created in the current working directory of the process, which for databases processes is the data-file directory.

Database Restart

A database that is configured with an auto-login Oracle Key Vault, will automatically login into Oracle Key Vault on restart. If Oracle Key Vault is not available when the database (configured with an auto-login wallet) restarts, the database will use the keys from the persistent cache and continue with database operations, as long as the keys are active.

The persistent cache's credentials are the same as the Oracle Key Vault endpoint wallet credentials. These need to be kept in sync. The persistent cache needs to be deleted each time the endpoint wallet credentials are modified.

PKCS#11 persistent and in-memory caches are completely independent of each other. They can be enabled and disabled separately.

The PKCS#11 will first look up the master key in the in-memory cache. If it does not find it there, it looks up the master key in the persistent cache. If the master key is not found in the in-memory cache or the persistent cache, then it is retrieved from the Oracle Key Vault server.

Using Persistent Cache in a RAC Database

Each RAC node is a different end point of the database, and has its own individual persistent cache. For RAC databases, a query should be initiated from each RAC node to cache the latest master key in each RAC node for uninterrupted operations.

Using Persistent Cache in Active DataGuard

A REKEY on the primary database will cache the master key in its own persistent cache. When the new REDO logs from the primary are applied on the standby, only then will the standby fetch the new key from the Oracle Key Vault server and cache it in the persistent cache of the standby. This means that there is a time lag between the caching of the key in primary and the caching of the key in standby. It is recommended that the primary and the standby be synced up as soon as possible after the REKEY.

11.5 Using a TDE-Configured Oracle Database in an Oracle RAC Environment

In a TDE-configured Oracle database, if you upload Oracle wallets in an Oracle Real Application Cluster (Oracle RAC) environment, then the nodes within the cluster must share a virtual wallet.

You can enable the cluster to share the virtual wallet by using either of the following approaches:

  • Define a virtual wallet as a shared default wallet for all of the nodes in the cluster.

  • If each node in the cluster has a separate default wallet, then grant each node access to every other node's default wallet to have the same effect. An endpoint group may be used to simplify the process of granting each node access to the default wallets of the other nodes.

    The advantage of this approach over the first is that if you had several nodes that already had default wallets and you wanted them to share wallets, then you would not have to reassign their default wallets. This is particularly important because in the first approach, in order to reassign an endpoint's default wallet, you must reenroll the endpoint. An endpoint group can be used to simplify the process of granting each node access to the default virtual wallets of the other nodes.

As with single-instance database environments, after you download a password-protected wallet, you must manually open it. If you have one wallet on the primary node and then download the wallet to the other nodes, you must explicitly open the wallets on each of these nodes.

Each RAC node is a different end point of the database and has its own individual persistent cache. For RAC databases, a query should be initiated from each RAC node to cache the latest master key in the RAC node for uninterrupted operations

11.6 Using a TDE-Configured Oracle Database in an Oracle GoldenGate Environment

You can migrate Oracle wallets that contain Oracle GoldenGate shared secrets and TDE master keys to the Oracle Key Vault server.

Topics:

11.6.1 About Uploading Oracle Wallets in an Oracle GoldenGate Environment

In an environment where Oracle Key Vault is not used and an Oracle TDE-enabled database is configured with an Oracle wallet with Oracle GoldenGate, this database (called the source database) stores an Oracle GoldenGate shared secret in the same Oracle wallet where master keys are stored.

This means that when you configure the source database as an Oracle Key Vault endpoint, the Oracle GoldenGate shared secret is stored in Oracle Key Vault in the same virtual wallet where the master keys are stored for the TDE-enabled source database.

When you migrate an Oracle wallet that contains an Oracle GoldenGate shared secret and TDE master keys to Oracle Key Vault using the okvutil command-line utility, the default wallet for the TDE-enabled source database now stores the entire Oracle wallet migrated with shared secret and master keys.

In addition, if the configured target database is an Oracle database, then you must ensure that this target database is TDE-enabled so that all the TDE commands can be replicated. Note that the two Oracle TDE-enabled databases, source and target, do not need to have the same master key in the Oracle wallet. If you configure this target database as a new Key Vault endpoint, then you can upload and download wallets to and from Oracle Key Vault as you normally would with any independent Key Vault endpoint. No additional configuration is necessary.

11.6.2 Using an Online Master Key in an Oracle GoldenGate Deployment

Note, that the term Online Master Key replaces the term TDE direct connect.

There are two configuration steps to using the Online Master Key in an Oracle GoldenGate deployment:

  1. Configure a connection between the source database in the GoldenGate deployment and Oracle Key Vault.
  2. Configure the storage of Oracle GoldenGate secrets in the Oracle wallet on the source database.

At this stage, the configuration is complete. If you have configured the sqlnet.ora file correctly and completed the other configuration required for TDE on the source database, then when you set the encryption key (using either ALTER SYSTEM SET ENCRYPTION KEY or ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY), a TDE master key is created in Oracle Key Vault. You can encrypt tables or create encrypted tablespaces in the database. The encrypted data created in the source database continues to be replicated on the target database after this procedure is performed. The other Oracle GoldenGate shared secrets are stored in Oracle Key Vault.

See Also:

11.6.3 Migrating TDE Wallets on an Oracle GoldenGate Deployment to Oracle Key Vault

In an Oracle GoldenGate environment with a TDE-configured database, an Oracle wallet contains both the TDE master keys and the Oracle GoldenGate shared secret.

Note that target databases (if they are Oracle TDE-enabled databases) that are used in this Oracle GoldenGate environment can also be configured to use Oracle Key Vault or continue to use Oracle wallet. You should treat these databases as you would any standalone TDE database endpoint.

After you complete this migration, the configuration is complete. If you have configured the sqlnet.ora file correctly and completed the other configuration required for TDE, then when you set the encryption key (using either ALTER SYSTEM SET ENCRYPTION KEY or ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY), a TDE master key is created in Oracle Key Vault. You can continue to create and use encrypted tables or tablespaces in the database. The encrypted data created in the source database continues to be replicated on the target database after this procedure is performed.

See Also:

"Migrating Existing TDE Wallets to Oracle Key Vault" to migrate the Oracle wallet to Key Vault

11.7 Using a TDE-Configured Oracle Database in an Oracle Active Data Guard Environment

You can perform the following activities in an Oracle Active Data Guard environment: upload Oracle wallets to an Oracle Key Vault server, use Online Master Keys, migrate wallets between endpoints, and migrate and check TDE wallets for a logical standby database.

Topics:

11.7.1 About Uploading Oracle Wallets in an Oracle Active Data Guard Environment

In an Oracle Active Data Guard environment with a TDE-enabled primary and a standby database using an Oracle wallet, you must physically copy the Oracle wallet file from the primary database to the standby after the initial TDE configuration and later, whenever you rekey the master key on the primary database.

Whereas, when using Oracle Key Vault with a TDE-enabled Active Data Guard database, the primary and standby databases must be registered in Oracle Key Vault as endpoints. You must ensure that the endpoints that are registered for both the primary and standby databases have same default virtual wallet in Oracle Key Vault.

This way, the two databases can achieve centralized key and wallet management without the need of a manual copy of the wallet file from the primary database to the standby database.

Persistent Cache in an Active Data Guard Environment

A REKEY on the primary database will cache the Master Key in its own persistent cache. When the new REDO logs from the primary are applied on the standby, only then will the standby fetch the new key from the OKV and cache it in the persistent cache of the standby. There is a time lag between the caching of the key in primary and the caching of the key in standby. It is recommended that the primary and standby be synchronized as soon as possible after the REKEY.

11.7.2 Uploading Oracle Wallets in an Oracle Active Data Guard Environment

You can upload an Oracle wallet to an Active Data Guard environment as follows:

  1. Register one endpoint each for the primary and standby databases.
  2. Download the okvclient.jar file for each endpoint on the respective databases.
  3. Ensure that the endpoint password is the same as the TDE wallet password if you must perform a migration or a reverse migration.
  4. Ensure that both the primary and standby database endpoints use the same default virtual wallet.

11.7.3 Performing an Online Master Key Connection in an Oracle Active Data Guard Environment

The procedure for performing a TDE direct connection in an Oracle Active Data Guard environment is the same as in a standard Oracle Database environment.

11.7.4 Migrating Oracle Wallets in an Oracle Active Data Guard Environment

You can migrate an Oracle wallet in an Oracle Active Data Guard environment as follows:

  1. Use the okvutil upload command to upload the contents of the local Oracle wallet that is on the primary database to Oracle Key Vault.
  2. Perform the steps to migrate the wallet.
  3. Close the existing Oracle wallet on the standby database.
    • For Oracle Database 11g Release 2, as a user who has been granted the ALTER SYSTEM system privilege:

      ALTER SYSTEM SET ENCRYPTION WALLET CLOSE IDENTIFIED BY "Key_Vault_endpoint_password"; 
      
    • For Oracle Database 12c, as a user who has been granted the SYSKM administrative privilege:

      ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "Key_Vault_endpoint_password";
      
  4. Shut down the standby database.

    For example:

    SHUTDOWN IMMEDIATE
    
  5. Restart the standby database.

    For example:

    STARTUP
    
  6. Open the Oracle wallet.
    • For Oracle Database 11g Release 2, as a user who has been granted the ALTER SYSTEM system privilege:

      ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "Key_Vault_endpoint_password"; 
      
    • For Oracle Database 12c, as a user who has been granted the SYSKM administrative privilege:

      ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "Key_Vault_endpoint_password";
      
  7. Start the apply process on the standby database.

See Also:

11.7.5 Reverse Migrating Oracle Wallets in an Active Data Guard Environment

To reverse migrate an Oracle wallet in an Active Data Guard environment:

  1. Use the okvutil download command to download the Oracle wallet keys onto the primary database from Oracle Key Vault. Download these keys to a local keystore.
  2. Perform a reverse migration.

    See Oracle Database Advanced Security Guide for more information about performing reverse migrations.

  3. Close the existing Oracle wallet on the standby database.
    • For Oracle Database 11gR2:

      ALTER SYSTEM SET ENCRYPTION WALLET CLOSE IDENTIFIED BY "Key_Vault_endpoint_password"; 
      
    • For Oracle Database 12c:

      ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "Key_Vault_endpoint_password";
      
  4. Copy the Oracle wallet from the primary database to the standby database.

    See Oracle Database Advanced Security Guide for more information.

  5. Open the Oracle wallet on the standby database.
    • For Oracle Database 11gR2:

      ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "Key_Vault_endpoint_password"; 
      
    • For Oracle Database 12c:

      ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "Key_Vault_endpoint_password";
      
  6. Start the apply process on the standby database.

    See Oracle Data Guard Concepts and Administration for information about starting the apply process on the standby database.

Note:

If the endpoint password and the local TDE wallet password are different, then use the auto-login HSM feature. See Oracle Database Advanced Security Guide for more information about configuring auto-login wallets.

11.7.6 Migrating an Oracle TDE Wallet to Oracle Key Vault for a Logical Standby Database

If you have a logical standby database configured and are using Oracle Database Release 12c, then you can migrate a TDE wallet to Oracle Key Vault as follows:

  1. Register the primary and standby endpoints to have the same default virtual wallet.
  2. If necessary, download and install the okvclient.jar file to each endpoint.
  3. Perform the migration on the primary database.
  4. Complete the SQL Apply process on the logical standby and then restart the standby database.
  5. To check that the status the that migration was successful, query the V$ENCRYPTION_WALLET dynamic view.

11.7.7 Checking the Oracle TDE Wallet Migration for a Logical Standby Database

In an Oracle Database Release 12c environment, after you have migrated an Oracle TDE wallet in a logical standby configuration, you can check the configuration by querying the WRL_TYPE and WALLET_ORDER columns of the V$ENCRYPTION_WALLET dynamic view.

By querying the V$ENCRYPTION_WALLET view, you can track the primary keystore. If you have only a single wallet configured, then the WALLET_ORDER column is set to SINGLE. In a two-wallet or mixed configuration, the column is set to PRIMARY or SECONDARY, depending on where the active master key is located. Consider the following queries.

In the following query, only a single wallet is configured:

SELECT WRL_TYPE, WALLET_ORDER FROM V$ENCRYPTION_WALLET;

WRL_TYPE             WALLET_OR
-------------------- ---------
FILE                 SINGLE

In this query in a logical standby configuration, the active master key has been migrated to an Oracle Key Vault virtual wallet:

SELECT WRL_TYPE, WALLET_ORDER FROM V$ENCRYPTION_WALLET;
 
WRL_TYPE             WALLET_OR
-------------------- ---------
FILE                 SECONDARY
HSM                  PRIMARY

This query should show the HSM as the PRIMARY wallet in both the primary and standby database for the logical configuration.

11.8 MySQL Integration with Oracle Key Vault

Oracle Key Vault supports integration with MySQL from Release 12.2 onwards.

Note:

MySQL Windows databases are not supported.

Oracle Key Vault 12.2 and above can manage MySQL TDE encryption keys. This integration is documented at the following MySQL documentation links:

The following link covers additional MySQL functions to leverage Oracle Key Vault beyond managing the MySQL Master Key:

11.9 Upload a Keystore from Automatic Storage Management to Oracle Key Vault

You can copy a keystore from Automatic Storage Management (ASM) to Oracle Key Vault and vice versa in a two-step process, which is described here.

Uploading a keystore from ASM to Oracle Key Vault is a two step process:
  1. Copy the keystore from ASM to the file sytem.

  2. Upload the keystore from the file system to Oracle Key Vault.

Copying a keystore from ASM to the file system or vice versa requires the keystore merge operation that merges one software keystore to an existing key store. Therefore, in order to copy a keystore from a source path to a target path, a keystore must exist at the target path.
You can use the ADMINISTER KEY MANAGEMENT statement to move a software keystore out of Automatic Storage Management (ASM) as follows:
  1. Initialize a target keystore on the file system with the following command:
    ADMINISTER KEY MANAGEMENT CREATE KEYSTORE targetKeystorePath IDENTIFIED BY targetKeystorePassword;
    

    In this specification:

    • targetKeystorePath is the directory path to the target keystore on the file system.

    • targetKeystorePassword is a password that you create for the keystore.

    For example:

    ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/etc/ORACLE/KEYSTORE/DB1/' IDENTIFIED BY "destination_password"; 
    

    Where '/etc/ORACLE/KEYSTORE/DB1/' is the path to the target keystore in the file system and “destination_password” is the keystore password.

    The keystore from ASM can now be copied to the target keystore.
  2. Copy the keystore from ASM to the target keystore that you just created.

    This step requires that you merge the keystore from ASM to the file system as follows:

    ADMINISTER KEY MANAGEMENT MERGE KEYSTORE srcKeystorePath IDENTIFIED BY srcKeystorePassword INTO EXISTING KEYSTORE targetKeystorePath IDENTIFIED BY targetKeystorePassword WITH BACKUP USING backupIdentifier;
    

    In this specification:

    • srcKeystorePath is the directory path to the source keystore.

    • srcKeystorePassword is the source keystore password.

    • targetKeystorePath is the path to the target keystore.

    • targetKeystorePassword is the target keystore password.

    • backupIdentifier is the backup identifier to be added to the backup file name.

    For example:

    ADMINISTER KEY MANAGEMENT MERGE KEYSTORE '+DATAFILE' IDENTIFIED BY "srcPassword" INTO EXISTING KEYSTORE '/etc/ORACLE/KEYSTORE/DB1/' IDENTIFIED BY "destination_password" WITH BACKUP USING "bkup";
    
    The keystore is copied to the file system and can now be uploaded to Oracle Key Vault.
  3. Upload keystore from file system to Oracle Key Vault using the okvutil upload command.
    $  okvutil upload -l location -t type
    

    Where:

    • location is the path to the target keystore in the file system

    • type is wallet

    For example:

    $ okvutil upload -l etc/ORACLE/KEYSTORE/DB1 -t wallet
    
The keystore is now copied from ASM to Oracle Key Vault.

To copy a keystore from Oracle Key Vault to ASM you would reverse the steps:

  1. Initialize a target keystore on the file system, if it does not exist. If it exists, skip this step.

  2. Copy the keystore from Key Vault to the target keystore on the file system using the okvutil download command.

    $  okvutil download -l location -t type
    

    Where:

    • location is the path to the target keystore in the file system

    • type is wallet

    For example:

    $ okvutil download -l etc/ORACLE/KEYSTORE/DB1 -t wallet
    
  3. Copy the keystore from the target keystore to ASM.