Integration with Hardware Security Module (HSM)
Release 12.2 BP12
E75841-17
October 2020
Release 12.2 Bundle Patch 1 introduced Hardware Security Module (HSM) integration with Oracle Key Vault, where the HSM acts as a “Root of Trust” by storing a top-level encryption key for Oracle Key Vault.
Note:
HSM integration is limited to new installations of Oracle Key Vault. This can be a fresh installation of Oracle Key Vault Release 12.2 BP 1 and later. The latest release is the recommended path as it contains the latest enhancements.
If you have an existing Oracle Key Vault installation with HSM and you want to upgrade to a later release of Oracle Key Vault with HSM, you must contact Oracle support.
Oracle Key Vault is a full-stack software appliance that contains an operating system, database, and key-management application to help organizations store and manage their keys and credentials. The configuration that you perform using this guide also establishes a Root-of-Trust (RoT) for Oracle Key Vault in the HSM. When an HSM is deployed with Oracle Key Vault, the Root of Trust (RoT) remains in the HSM. The HSM RoT protects the wallet password, which protects the TDE master key,which in turn protects all the encryption keys, certificates, and other security artifacts managed by the Oracle Key Vault server. Note that the HSM in this RoT usage scenario does not store any customer encryption keys. The customer keys are stored and managed directly by the Oracle Key Vault server.
Using HSM as a RoT is intended to mitigate attempts to recover keys from an Oracle Key Vault server which has been started in an unauthorized environment. Physical loss of an Oracle Key Vault server from a facility is one example of such a scenario. An unauthorized user attempting to run a lost or stolen Oracle Key Vault server, without authorized access to the HSM,would be prevented from recovering the encryption keys stored on the appliance.
Oracle Key Vault employs a hierarchy of security controls including operating system hardening, database encryption, and data access enforcement using Database Vault. These controls are designed to mitigate the risk of users potentially extracting keys and credentials from systems they can physically access. Administrators do not need to access the internal components of the appliance for normal, day-to-day operations. Oracle Key Vault should be deployed in a secure location, and physical and logical access to the appliance should be controlled and monitored.
Enabling HSM in your Oracle Key Vault installation will not disrupt existing features. You can continue to work with Oracle Key Vault features like high availability, backup, and restore in HSM mode.
HSMs contain tamper-resistant, specialized hardware which is harder to access than normal server memory. Oracle Key Vault can use HSMs to generate and store a Root of Trust (RoT) that protects encryption keys used by Oracle Key Vault to safeguard users' keys and credentials. When using Oracle Key Vault with an HSM, keys and credentials can be read if the RoT stored in the HSM is available. Since HSMs are designed to make the RoT very difficult to extract, this significantly mitigates the risk of compromise of users' keys and credentials. In addition, the HSM can be used in FIPS 140-2 Level 2 or Level 3 mode which can help meet certain compliance requirements.
Note:
Oracle Key Vault can function only if the RoT stored in the HSM is available.The HSM vendors currently integrated with Oracle Key Vault are: SafeNet (a Thales company) Luna SA 7000 and nCipher nShield Connect 6000+.
Parent topic: Introduction
You must first install Oracle Key Vault, then install the HSM client software on the Key Vault server. You will need to refer to the HSM documentation from the HSM vendor for more information.
See Also:
Vendor Specific Notes for SafeNet for vendor-specific instructions to enroll Key Vault as a client of the SafeNet Luna SA 7000 HSM
Vendor Specific Notes for nCipher for vendor-specific instructions to enroll Key Vault as a client of the nCipher nShield Connect 6000+ HSM
Parent topic: Introduction
You must enroll Oracle Key Vault as a client of HSM and ensure connectivity between the HSM client and the HSM.
You must refer to your specific HSM documentation to complete enrolling Key Vault as an HSM client.
See Also:
Vendor Specific Notes for SafeNet for more instructions
Vendor Specific Notes for nCipher for more instructions
Parent topic: Introduction
Note:
If you change the HSM credential on the HSM after initialization, you must also update the HSM credential on the Oracle Key Vault server using the Set Credential command.Parent topic: Introduction
In a high availability Oracle Key Vault installation you must enable HSM separately on the servers you mean to designate as primary and standby before pairing them in a high availability configuration.
See Also:
If you are enabling High Availability using an nCipher HSM, see Vendor Specific Notes for nCipher for more instructions.
To enable HSM in a high availability deployment:
Parent topic: Introduction
You can backup and restore Oracle Key Vault with HSM mode enabled.
Backup in HSM Mode
Restore in HSM Mode
HSM
Root of Trust used to take the backup
Parent topic: Introduction
The HSM reverse migrate procedure allows you to disable the HSM and go back to a local wallet protected by the Recovery Passphrase.
The purpose of reverse migrate is to revert back to a local wallet protected by the Recovery Passphrase. This will be necessary if an HSM currently protecting Oracle Key Vault needs to be decommissioned.
Parent topic: Introduction
Parent topic: Reverse Migrating to Local Wallet
Perform the following procedure to reverse migrate a High Availability deployment (Oracle Key Vault 12.2.0.6.0 and later).
Parent topic: Reverse Migrating to Local Wallet
This section covers general troubleshooting help. Vendor-specific troubleshooting is covered in the vendor-specific notes.
Trace Files for Diagnosing Issues
Oracle Key Vault provides trace files so that you can better diagnose issues that may arise.
Use these trace files to more finely diagnose issues when you attempt hardware security module operations. These trace files are located in the /var/okv/log/hsm/
directory on the Oracle Key Vault server. To see the most recently failed operation, you can sort the trace files by their last modified time. For example, ls -ltr /var/okv/log/hsm
lists the most recently modified trace files at the bottom of the list.
HSM Alert
Oracle Key Vault provides an alert mechanism that periodically monitors the HSM configuration to check for Root of Trust key availability and file health.
When an Oracle Key Vault server is HSM-enabled, Oracle Key Vault contacts the HSM every five minutes (or whatever you have set the monitoring interval to) to ensure that the Root of Trust key is available and the TDE wallet password can be decrypted. When an alert has been raised, an error saying HSM configuration error. Please refer to the HSM Alert section in the Oracle Key Vault HSM Integration Guide.
appears.
If this alert appears, then follow these steps:
ssh support@okv_instance_IP_address Enter support user password when prompted. su - root Enter root user password when prompted.
cp /mnt/okvram/cwallet.sso /var/lib/oracle/cwallet_hsm_backup.sso
hsm_initialize: Error Running orapki — Check User
This error occurs when the hsm_initialize command
is run as the wrong OS user. Switch to the oracle
user and re-run the command.
hsm_initialize: Could Not Get Slot for HSM
This error indicates that Key Vault is not properly enrolled as a client of the HSM. Check vendor-specific instructions for more information.
Key Vault Management Console Does Not Start After Restarting HSM-Enabled Key Vault Server
If the management console does not appear after restarting the HSM-enabled Key Vault server, log into the Key Vault server using SSH as user support
and try manually opening the wallet as follows:
$ ssh support@okv_instance <Enter password when prompted> $ su root root# su oracle $ cd /usr/local/okv/hsm/bin $ ./hsmclient open_wallet
If the open_wallet
command succeeds, the database will open and the management console will appear, unless there is another non-HSM problem. If the command does not succeed, check for vendor-specific instructions. Otherwise, copy the output and contact Oracle Support.
High Availability Errors
Check that the files have been transported to the standby server:
Execute the command ls -l
as root on the standby server:
$ ls -l /usr/local/okv/hsm/wallet -rw------- 1 oracle oinstall 324 May 16 22:57 cwallet.sso -rw------- 1 oracle oinstall 176 May 16 22:57 enctdepwd $ ls -l /usr/local/okv/hsm/restore -rw------- 1 oracle oinstall 320 May 16 22:57 ewallet.p12
You must see cwallet.sso
and enctdepwd in
the /usr/local/okv/hsm/wallet
directory and ewallet.p12
in the /usr/local/okv/hsm/restore
directory.
Check that the mode is set to HSM on the standby server:
Open the file okv_security.conf
as root on the standby server:
$ cat /usr/local/okv/etc/okv_security.conf Look for the line: HSM_ENABLED="1"
You must see the number within double quotes.
Check the vendor-specific instructions.
Backup
You must check that the pre_restore
command has been run on the target as follows:
Execute the command ls -l
as root on the standby server:
$ ls -l /usr/local/okv/hsm/wallet -rw------- 1 oracle oinstall 324 May 16 22:57 cwallet.sso
You must see the wallet file cwallet.sso
.
You must also check that you have followed the instructions from the HSM vendor.
Restoring an HSM-Enabled Backup
This procedure must only be used in a restore operation and you must enter the HSM credential correctly. If you enter an incorrect credential or if Oracle Key Vault is unable to connect to the HSM, the credential will not be stored. Ensure that Oracle Key Vault is enrolled as a client of the HSM and then ensure that the correct credential has been entered.
For more information about enrolling Oracle Key Vault as a client of the HSM, see Enroll Oracle Key Vault as a Client of HSM.
Parent topic: Introduction
Release 12.2 BP 1 and higher support Oracle Key Vault integration with SafeNet Luna SA Hardware Security Modules from Thales version 7000. The use of a Host Trust Link (HTL) for SafeNet Luna HSM is unsupported at this time.
The following installation and enrollment instructions apply to the SafeNet Luna SA 7000 HSM.
Install the HSM Client Software on the Key Vault Server
To install the HSM client on Key Vault:
Obtain the SafeNet client software package, version 6.2 for Linux x64. For the purposes of this document, we will refer to this as "safenet.tar".
Transport the SafeNet client software package to the Key Vault machine. Oracle recommends using scp, for example:
scp safenet.tar support@[okv hostname]:/tmp
Install the SafeNet client software on Key Vault.
Log in to the Oracle Key Vault Server through SSH as user support
, and switch user (su
) to root
:
$ ssh support@okv_instance $ su root $ cd /usr/local/okv/hsm $ cp /tmp/safenet.tar /usr/local/okv/hsm $ tar -xvf safenet.tar $ cd 64 $ ./install.sh
Accept the SafeNet license by typing ‘y’ at the prompt.
Install the Luna SA by entering ‘1’, ‘n’, ‘i’ at the successive prompts:
This installs the SafeNet software in the directory /usr/safenet/lunaclient
.
Delete the safenet.tar file from /tmp directory.
$ rm -f /tmp/safenet.tar
HSM Credential
The HSM credential is the SafeNet partition password. You choose a partition with the client assignPartition
command.
Enroll Key Vault as a Client of HSM
To enroll Key Vault as an HSM client:
Set the DNS servers for Key Vault via the management console from System —> System Settings. This step is required for the Luna SA to communicate with Key Vault.
Exchange certificates between Key Vault and the Luna SA:
Log in to the Oracle Key Vault Server through SSH as user support
, and switch user (su
) to root
:
$ ssh support@okv_instance $ su root $ cd /usr/safenet/lunaclient/bin $ scp admin@[hsm hostname]:server.pem . $ ./vtl addServer -n [hsm hostname] -c server.pem $ ./vtl createCert -n [okv hostname] $ scp /usr/safenet/lunaclient/cert/client/[okv hostname].pem admin@[hsm hostname]:
You will need to enter the HSM admin password when using scp with the HSM.
Register Key Vault as a client of the Luna SA. This assumes you have a partition set up on the Luna SA. You can use any client name that is not yet taken. Oracle recommends using a descriptive name that will identify the Key Vault instance.
Access the HSM administrative console by using SSH to admin@[hsm hostname] and providing the admin password:
$ client register -client [client name] -hostname [okv hostname] $ client hostip map -c [client name] -i [okv IP] $ client assignPartition -client [client name] -partition [partition name]
Verify enrollment:
Login to Key Vault as the support user using SSH:
$ su root $ cd /usr/safenet/lunaclient/bin $ ./vtl verify
The following output appears:
The following Luna SA Slots/Partitions were found: Slot Serial # Label ==== ======== ===== 1 [serial #] [partition name]
HSM Provider Value
For Safenet, the provider value is 1. If setting manually for High Availability, set HSM_PROVIDER="1". For more information about enabling HSM in a High Availability deployment, see Enabling HSM in a High Availability Deployment.
HSM Vendor Specific Checks
The instructions in this section apply to the SafeNet (Gemalto) Luna SA 7000 only.
You can verify the connection to the HSM for every Key Vault server as follows:
Login to the Key Vault server as user support
using SSH:
$ ssh support@okv_instance $ su root $ cd /usr/safenet/lunaclient/bin $ ./vtl verify
The following output appears when the HSM is set up properly:
The following Luna SA Slots/Partitions were found: Slot Serial # Label ==== ======== ===== 1 [serial #] [partition name]
If you do not see this output, it means that the HSM is not set up properly. You may diagnose further as follows:
Log into the Luna SA administrative console.
Type the command: client show -client [client name]
Verify that the expected client exists and is assigned a partition.
If it does not exist, register the client with the command:
client register -client [client name]-hostname [hostname]
If no partition is assigned, assign a partition with the command:
client assignPartition -client [client name] -partition [partition name]
Verify that all client IPs are mapped correctly. If entries are missing, run the command:
client hostip map -c [client name] -i [ip]
Troubleshooting
vtl verify
command as follows:
$ su root root# cd /usr/safenet/lunaclient/bin root# ./vtl verify
The following Luna SA Slots/Partitions were found: Slot Serial # Label ==== ======== ===== 1 [serial #] [partition name]If the command fails, it means that the Key Vault server is unable to contact the HSM. Check the vendor’s other troubleshooting sections for instructions to restore
vtl verify
functionality. Contact your HSM administrator and confirm that Key Vault's access to the HSM has not been revoked. If you are unable to resolve the problem, contact Oracle Support.Parent topic: Introduction
Release 12.2 BP 3 and higher support Oracle Key Vault integration with the nCipher HSM. At this time, only the nCipher nShield Connect 6000+ is supported.
The following installation and enrollment instructions apply to the nCipher HSM.
Install the HSM Client Software on the Key Vault Server
The nCipher HSM requires a separate non-HSM computer on the network to use as the Remote File System. You must set up this computer and copy the nCipher software files to it before you start.
To install the nCipher software on the Key Vault server:
$ ssh support$okv_instance <Enter the support user password when prompted>
$ su root
root
directory and create the directories ctls
, hwsp
, and pkcs11
:
root# cd /root root# mkdir ctls root# mkdir hwsp root# mkdir pkcs11
Transfer the nCipher software installation files using the Secure Copy (SCP) protocol as follows:
root# scp <user@remote_file_system_machine>:/<your_source_directory>/ncipher/nfast/ctls/agg.tar ctls root# scp <user@remote_file_system_machine>:/<your_source_directory>/ncipher/nfast/hwsp/agg.tar hwsp root# scp <user@remote_file_system_machine>:/<your_source_directory>/ncipher/nfast/pkcs11/user.tar pkcs11
root# cd / root# tar xvf /root/ctls/agg.tar root# tar xvf /root/hwsp/agg.tar root# tar xvf /root/pkcs11/user.tar root# /opt/nfast/sbin/install
root
perform additional edits on the Key Vault server:
root# usermod -a -G nfast oracle root# cd /etc/rc.d/rc5.d root# mv S50nc_hardserver S40nc_hardserver root# cd /etc/rc.d/rc3.d root# mv S50nc_hardserver S41nc_hardserver
oracle
and verify the installation:
root# su oracle oracle$ PATH=/opt/nfast/bin:$PATH oracle$ export PATH oracle$ enquiryThe state should say “operational” in the output.
Reboot the system for the group change to take effect.
HSM Credential
The HSM credential is the Operator Card Set password.
Enroll Key Vault as a Client of HSM
Enroll Key Vault as an HSM client as follows:
Add the Key Vault server IP address to the client list on the HSM using the front panel. Select privileged on any port.
oracle
:
root# su oracle oracle$ PATH=/opt/nfast/bin:$PATH oracle$ export PATH
oracle$ nethsmenroll <HSM IP address> <HSM ESN> <HSM keyhash>
oracle$ config-serverstartup --enable-tcp --enable-privileged-tcp
oracle$ su root root# /opt/nfast/sbin/init.d-ncipher restart
rfs-setup --gang-client --write-noauth <IP address of your Key Vault server>
oracle
run the commands:
oracle$ rfs-sync --setup --no-authenticate <IP address of Remote File System machine> oracle$ rfs-sync --update
root# /opt/nfast/bin/ckcheckinstA prompt appears listing the module. You can confirm or exit.
/opt/nfast/cknfastrc
as user root
. Write the following lines to the file:
CKNFAST_NO_ACCELERATOR_SLOTS=1 CKNFAST_OVERRIDE_SECURITY_ASSURANCES=explicitness;tokenkeys;longterm
Perform the steps described in Protect the Oracle Key Vault TDE Master Key with the HSM.
oracle
run the command:
oracle$ /opt/nfast/bin/rfs-sync --commit
HSM Provider Value
For nCipher, the provider value is 2. If setting manually for HA, set HSM_PROVIDER="2"
. For more information about enabling HSM in a High Availability deployment, see Enabling HSM in a High Availability Deployment.
Enable HSM Mode
After installing HSM software and enrolling Key Vault as an HSM client, you can enable HSM mode with nCipher from the Key Vault user interface on the management console. Just select Thales from the vendor drop-down list.
Backup and Restore
Install a new Key Vault server.
Install the nCipher HSM software as described in a previous section.
From the Key Vault user interface add the backup destination on the System Backup page, just as you would in non-HSM mode.
Perform a backup as usual from the user interface on the management console.
Go to the Prepare for HSM Restore page from the user interface.
Select Thales from the Vendor drop down list and enter the HSM credential twice as requested.
Click Set Credential .
Log in to the Oracle Key Vault Server through SSH as user support
, switch user (su
) to root
, then switch user (su
) to oracle
.
$ ssh support@okv_instance <Enter password when prompted> $ su root root# su oracle
oracle$ /opt/nfast/bin/rfs-sync --update
Restore via the user interface as usual, as in non-HSM mode.
HSM in a High Availability Oracle Key Vault Installation
This procedure shows you how to pair two Key Vault servers in HSM mode in a high availability configuration. You must enable HSM mode in both primary and standby Key Vault servers before pairing them. To configure the HSM for high availability, please see the vendor documentation.
To configure Oracle Key Vault with nCipher HSM in a high availability installation, do:
Install Oracle Key Vault on two servers that you mean to designate as primary and standby.
Install the nCipher HSM software on each Key Vault server.
On the server you mean to designate as primary server do the following:
support
, switch user (su
) to root
, then switch user (su
) to oracle
:
$ ssh support@okv_primary_instance <Enter password when prompted> $ su root root# su oracle
oracle$ /opt/nfast/bin/rfs-sync --update
From the user interface on the Key Vault management console initialize the intended primary server for HSM mode with nCipher.
On the server you mean to designate as primary server do the following:
support
, switch user (su
) to root
, then switch user (su
) to oracle
:
$ ssh support@okv_primary_instance <Enter password when prompted> $ su root root# su oracle
oracle$ /opt/nfast/bin/rfs-sync --commit
Repeat Step 3 on the intended standby server.
oracle
:
$ ssh support@okv_primary_instance <Enter password when prompted> $ su root root# su oracle oracle$ cd /usr/local/okv/hsm/wallet oracle$ scp cwallet.sso support@standby:/tmp oracle$ scp enctdepwd support@standby:/tmp oracle$ cd /usr/local/okv/hsm/restore oracle$ scp ewallet.p12 support@standby:/tmp
Note:
While performing this procedure on Oracle Key Vault 12.2.0.5.0 and earlier, use the commands in Enabling an HSM in a High Availability Oracle Key Vault Installation.
root
:
$ ssh support@okv_standby_instance <Enter password when prompted> $ su root root# cd /usr/local/okv/hsm/wallet root# mv /tmp/enctdepwd . root# mv /tmp/cwallet.sso . root# chown oracle * root# chgrp oinstall * root# cd /usr/local/okv/hsm/restore root# mv /tmp/ewallet.p12 . root# chown oracle * root# chgrp oinstall *
Note:
While performing this procedure on Oracle Key Vault 12.2.0.5.0 and earlier, use the commands in Enabling an HSM in a High Availability Oracle Key Vault Installation.
root
open the file okv_security.conf
for writing:
root# vi /usr/local/okv/etc/okv_security.conf
Make two updates to the file as follows:
HSM_ENABLED
to 1. If the variable does not exist, add it and set its value to 1.
HSM_ENABLED="1"
HSM_PROVIDER="2"
Then proceed to set up high availability as usual via the user interface on the Key Vault management console.
Parent topic: Introduction
Oracle Key Vault 12.2 BP 3 and higher offer compliance with the Commercial National Security Algorithm (CNSA) for TLS connections to and from the appliance.
The CNSA suite is a list of strong encryption algorithms and key lengths, that offer greater security and relevance into the future. A link to the full CNSA specification is in the See Also section that follows this section.
Note that 12.2 BP3 and higher do not provide complete compliance across every component in the system. You will be able to switch to the CNSA algorithms, where available by means of two scripts that are packaged with the ISO:
The first script /usr/local/okv/bin/okv_cnsa
makes configuration file changes to update as many components as possible to use the enhanced algorithms. It is reversible and will not interfere with existing operations.
The second script /usr/local/okv/bin/okv_cnsa_cert
regenerates CNSA compliant public key pairs and certificates.
Note:
/usr/local/okv/bin/okv_cnsa_cert
is disruptive because it replaces the old key pairs with new ones. This has consequences for the following operations:
Endpoint Enrollment: Enroll endpoints after running this script when possible. If you had endpoints enrolled before running the CNSA script, you must re-enroll them so that fresh CNSA compliant keys are generated using CNSA algorithms.
High Availability: Run the CNSA scripts on both Oracle Key Vault instances before pairing them in a high availability configuration when possible. If you had high availability set up prior to running the CNSA scripts, you must re-configure high availability as follows: unpair the primary and standby servers, run the CNSA scripts individually on each server, then pair them again.
Running the CNSA Scripts
To run the CNSA scripts do the following:
Install Oracle Key Vault and complete the post-installation tasks. The last post-installation task is to set the support user password, which is needed now.
Log into the Key Vault browser-based management console and enable SSH access to the server.
$ ssh support@okv_instance <Enter support user password created during post-installation>
$ su root
root# /usr/local/okv/bin/okv_cnsa root# /usr/local/okv/bin/okv_cnsa_cert
The scripts put data into /usr/local/okv/etc/okv_security.conf
.
The line USE_ENHANCED_ALGORITHMS_ONLY="1"
will be added if the scripts are run.
Backup
After restoring a backup, re-run the first script:/usr/local/okv/bin/okv_cnsa
to update the configuration to use the enhanced CNSA algorithms as follows:
Wait for the system to reboot after the restore operation initiated via the user interface of the Key Vault management console.
$ ssh support@okv_instance <Enter support user password created during post-installation>
$ su root
root# /usr/local/okv/bin/okv_cnsa
Upgrade
You must re-run the first script during the upgrade to ensure CSNA compliance as follows:
root# /usr/bin/ruby/images/upgrade.rb --format
root# /usr/local/okv/bin/okv_cnsa
root# /sbin/reboot
Limitations:
CNSA compliance is not supported for some components in the Oracle Key Vault infrastructure, for example SSH, or for the database encryption via TDE.
The Firefox browser is not supported for use with the Oracle Key Vault management console when CNSA is enabled. This is because the Firefox browser does not support CNSA-approved cipher suites.
Parent topic: Introduction
The following commands are used in Oracle Key Vault 12.2.0.5.0 and earlier:
While performing the procedure “HSM in a High Availability Oracle Key Vault Installation” under Vendor Specific Notes for nCipher on Oracle Key Vault 12.2.0.5.0 and earlier, use the following commands:
Perform the following manual steps on the intended primary as user oracle
:
$ ssh support@okv_primary_instance <Enter password when prompted> $ su root root# su oracle oracle$ cd /usr/local/okv/hsm/wallet oracle$ scp cwallet.sso support@(standby):/tmp oracle$ scp enctdepwd support@(standby):/tmp
Perform the following manual steps on the intended standby as user root
:
$ ssh support@okv_standby_instance <Enter password when prompted> $ su root root# cd /usr/local/okv/hsm/wallet root# mv /tmp/enctdepwd . root# mv /tmp/cwallet.sso . root# chown oracle * root# chgrp oinstall *
Parent topic: Commands Used in Oracle Key Vault 12.2.0.5.0 and Earlier
While performing the procedure Enable HSM in a High Availability Key Vault Installation on Oracle Key Vault 12.2.0.5.0 and earlier, use the following commands.
Perform the following manual steps on the primary node as user oracle:
$ cd /usr/local/okv/hsm/wallet $ scp cwallet.sso support@standby:/tmp $ scp enctdepwd support@standby:/tmp
Enable the HSM_ENABLED
parameter in the okv_security.conf
file:
$ cd /usr/local/okv/hsm/wallet $ mv /tmp/enctdepwd . $ mv /tmp/cwallet.sso . $ chown oracle * $ chgrp oinstall * $ vi /usr/local/okv/etc/okv_security.conf Set HSM_ENABLED="1" Set HSM_PROVIDER="<provider value>"
Save and quit by entering the following sequence of characters in the vi file: :wq!
Parent topic: Commands Used in Oracle Key Vault 12.2.0.5.0 and Earlier
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Access to Oracle Support
Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
Parent topic: Introduction
Oracle Key Vault Integration with Hardware Security Module (HSM), Release 12.2 BP12
E75841-17
Copyright © 2016, 2020, Oracle and/or its affiliates.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract. The terms governing the U.S. Government’s use of Oracle cloud services are defined by the applicable contract for such services. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Inside are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Epyc, and the AMD logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.