3 Upgrade Considerations When Using HSMs in Oracle Key Vault
When you upgrade an Oracle Key Vault deployment that has HSMs, you should consider factors such as the release being upgraded from, nCipher, and tokens.
- Upgrades from Oracle Key Vault Release 12.2
Upgrading from a standalone or a primary-standby Oracle Key Vault release 12.2 environment has special considerations for HSMs. - Upgrade Considerations for nCipher
When you upgrade while HSM-enabled and using an nCipher HSM, you must remake hardserver changes and consider changes to overriding security assurances. - Using a Token Label After Upgrading Oracle Key Vault without Reverse-Migrating
Starting in release 18.4, Oracle Key Vault can use a token label when you choose a slot while connecting to an HSM.
3.1 Upgrades from Oracle Key Vault Release 12.2
Upgrading from a standalone or a primary-standby Oracle Key Vault release 12.2 environment has special considerations for HSMs.
- Upgrading from an Oracle Key Vault Release 12.2 Standalone Deployment
You can upgrade from an Oracle Key Vault standalone deployment by reverse-migrating before the upgrade, and after the upgrade completes, re-HSM-enabling Oracle Key Vault. - Upgrading from an Oracle Key Vault Release 12.2 Primary-Standby Deployment
You can upgrade from an Oracle Key Vault release 12.2 primary-standby deployment by reverse-migrating before the upgrade, and after the upgrade completes, re-HSM-enabling Oracle Key Vault.
3.1.1 Upgrading from an Oracle Key Vault Release 12.2 Standalone Deployment
You can upgrade from an Oracle Key Vault standalone deployment by reverse-migrating before the upgrade, and after the upgrade completes, re-HSM-enabling Oracle Key Vault.
3.2 Upgrade Considerations for nCipher
When you upgrade while HSM-enabled and using an nCipher HSM, you must remake hardserver changes and consider changes to overriding security assurances.
- Remaking Hardserver Changes While Upgrading Oracle Key Vault
Because HSM configurations can vary, it is your responsibility to run test upgrades on non-production environments to ensure that the upgrade will work with your HSM configuration. - Overriding Security Assurances for the Oracle Key Vault Upgrade
You can configure how the Oracle Key Vault security assurance attributes are set for future initialization operations.
3.2.1 Remaking Hardserver Changes While Upgrading Oracle Key Vault
Because HSM configurations can vary, it is your responsibility to run test upgrades on non-production environments to ensure that the upgrade will work with your HSM configuration.
Related Topics
Parent topic: Upgrade Considerations for nCipher
3.2.2 Overriding Security Assurances for the Oracle Key Vault Upgrade
You can configure how the Oracle Key Vault security assurance attributes are set for future initialization operations.
CKA_EXTRACTABLE
attribute set to CK_FALSE
by default. However, in release 18.3.0.0.0 and earlier, CKA_EXTRACTABLE
was set to CK_TRUE
. This meant that the file /opt/nfast/cknfastrc
used to require the following additional line: CKNFAST_OVERRIDE_SECURITY_ASSURANCES=explicitness;tokenkeys;longterm
CKA_EXTRACTABLE
attribute set to CK_FALSE
. If you prefer that future initialize operations continue have CKA_EXTRACTABLE
set to CK_TRUE
in release 18.4.0.0.0 and later, then perform the following steps before initializing.
CKA_EXTRACTABLE
attribute set to CK_TRUE
.
Parent topic: Upgrade Considerations for nCipher
3.3 Using a Token Label After Upgrading Oracle Key Vault without Reverse-Migrating
Starting in release 18.4, Oracle Key Vault can use a token label when you choose a slot while connecting to an HSM.
/var/okv/log/hsm
directory.