Introduction

This guide describes how to integrate and use Entrust Security World software and Entrust Security nShield Hardware Security Modules (HSMs) with an Oracle database. The Oracle feature Transparent Data Encryption (TDE) provides data-at-rest encryption for sensitive information held by the Oracle database, while at the same time allowing authorized clients to use the database.

Oracle database software, and Entrust Security World software with nShield HSMs, can be independently installed on the same host server. They can then be configured to interoperate through a single library interface. It is possible to support multiple database instances on the same host server, while each database instance is restricted to access only its own encryption keys. Oracle cluster technology is also supported.

Integrated Oracle and Entrust technology has been tested to support Oracle TDE for tablespace encryption, or column encryption, or concurrently for both. Entrust nShield HSMs are certified to FIPS 140 (level 3) to deliver a high grade of security assurance. Functionality includes protection of sensitive enCONNECT TESTER@DB cryption keys and support for offload of encryption and key management operations.

This guides shows support for non-multitenant and multitenant databases. For Oracle version 21C, only multitenant Oracle database types are supported. Oracle does not support the creation of non-multitenant database types on version 21C. For more information on the multitenant support only by Oracle, see the Oracle multitenant documentation.
If using Oracle 18c or later, the sqlnet.ora file is officially deprecated and you should use the WALLET_ROOT and TDE_CONFIGURATION parameters.

Using this guide

This Integration Guide covers UNIX/Linux based systems. It provides:

  • An overview of how the Oracle database software and Entrust Security World software with HSM work together to enhance security.

  • Configuration and installation instructions.

  • Depending on your current Oracle setup, how to:

    • Migrate encryption from an existing Oracle wallet or keystore to HSM protection.

    • Begin using HSM protection immediately if no Oracle software wallet or keystore already exists.

  • Examples and advice on how the product may be used.

  • Troubleshooting advice.

It is assumed the reader has a good knowledge of Oracle database technology.

Assuming you already have your Oracle database installed, after installing and configuring the Entrust Security World software with the HSM, there is no other software required. However, some minor configuration changes will be needed.

This guide cannot anticipate all configuration requirements a customer may have. Examples shown in this guide are not exhaustive, and may not necessarily show the simplest or most efficient methods of achieving the required results. The examples should be used to guide integration of the Entrust HSM with an Oracle database, and should be adapted to your own circumstances.

Entrust accepts no responsibility for loss of data, or services, incurred by use of examples, or any errors in this guide. For your own reassurance, it is recommended you thoroughly check your own solutions in safe test conditions before committing them to a production environment. If you require additional help in setting up your system, contact Entrust Support.

Entrust accepts no responsibility for information in this guide that is made obsolete by changes or upgrades to the Oracle product.

This guide assumes that you have read the Security World and HSM documentation, and are familiar with the documentation and setup processes for Oracle database TDE.

Product configuration

Entrust has successfully tested nShield HSM integration with the in the following configurations:

OS Version Kernel Oracle Version

Red Hat Enterprise Linux 8.7 (Ootpa)

Linux 4.18.0-240.el8.x86_64

Oracle Database 21c Enterprise Edition - 21.3.0.0.0

Red Hat Enterprise Linux 8.7 (Ootpa)

Linux 4.18.0-425.10.1.el8_7.x86_64

Oracle Database 19c Enterprise Edition - 19.17.0.0.0

Supported nShield hardware and software versions

Entrust has successfully tested with the following nShield hardware and software versions:

Oracle 21C - 21.3.0.0.0

HSM Security World Software Firmware Image OCS Softcard Module FIPS Level 3

Connect XC

12.80.4

12.50.11 (FIPS 140-2 certified)

12.80.4

✓

✓

✓

Connect XC

12.80.4

12.72.1 (FIPS 140-2 certified)

12.80.5

✓

✓

✓

✓

nShield 5

13.2.2

13.2.2

13.2.2

✓

✓

✓

Oracle 19C - 19.17.0.0.0

HSM Security World Software Firmware Image OCS Softcard Module FIPS Level 3

Connect XC

12.80.4

12.50.11 (FIPS 140-2 certified)

12.80.4

✓

✓

✓

Connect XC

12.80.4

12.72.1 (FIPS 140-2 certified)

12.80.5

✓

✓

✓

✓

nShield 5

13.2.2

13.2.2

13.2.2

✓

✓

✓

Conventions used in this document

Multitenant and non-multitenant

Descriptions in this Integration Guide may cover non-multitenant databases and multitenant databases. Keep in mind that creation of non-multitenant databases are not supported anymore from Oracle 21C. This guide will use the terms appropriate to the database type under discussion, as outlined:

  • Non-multitenant databases are on Oracle version 11g or earlier. Multitenant databases start from Oracle version 12c.

  • Non-multitenant database software can only create and use non-multitenant databases. If non-multitenant databases are the subject matter, use the non-multitenant and SQL terminology as shown below.

  • Database software supporting multitenant databases may also optionally support non-multitenant databases (pre-21c). In this case, if a non-multitenant mode is the subject matter, then use the non-multitenant terminology and SQL shown below. If a multitenant mode is the subject matter, then use the multitenant terminology and SQL.

  • Non-Multitenant (non-container)

    1. Terminology for Oracle software based encryption key repository.

      ALTER SYSTEM SET ENCRYPTION …​

  • Multitenant (container)

    1. Terminology for Oracle software based encryption key repository

      Software keystore

    2. SQL preamble for encryption related commands

      ADMINISTER KEY MANAGEMENT, etc

Where such terminology applies equally to a software wallet or software keystore, the default terminology software keystore is used to cover both descriptive instances.

Database connections

You must be a user with correct permissions to access a database, and also have the correct privileges to perform the required operations when connected to that database. Your system administrator should be able to create users and grant suitable permissions and privileges according to your organization’s security policies. Example 2

  • <database-user> is the user identity making the connection.

  • <database-identifier> is the database to make the connection to.

For the purpose of examples in this guide, the following database users and database identifiers should be sufficient.

  • <database-user>. This guide will use one following users for connecting to databases:

    • sysdba, Oracle’s standard sysdba user.

    • system, Oracle’s standard system user.

    • Non-Mutitenant:

      • TESTER, as a local user.

    • Multitenant:

      • C##TESTER, as a common user for container (CDB) and the PDBs it contains.

      • CDB<n>PDB<k>TESTER, as a local user for a PDB<k> within container CDB<n>.

        Where <n> and <k> are distinguishing digits.

  • <database-identifier>. This guide will use one following database identifies during a connection:

    • Non-Multitenant databases:

      • DB, in practice usually the ORACLE_SID of the database. For example:

        CONNECT sysdba@DB
CONNECT TESTER@DB

    • Multitenant databases:

      • CDB<n> indicates a container database where <n> is a distinguishing digit.

      • PDB<k> indicates a pluggable database where <k> is a distinguishing digit.

      Multitenant database identifiers will be:

      • CDB<n>, to connect to the $CDB<n>$ROOT for a particular container CDB<n>.

      • CDB<n>PDB<k>, to connect to PDB<k> within CDB<n>.

      For example:

      CONNECT sysdba@CDB1
CONNECT C##TESTER@CDB1
CONNECT C##TESTER@CDB1PDB2
CONNECT CDB1PDB1TESTER@CDB1PDB1

When you are using a multitenant database, the connection implies that you must alter a session if you are not already connected to the required container. For example:

  • Example 1:

    CONNECT C##TESTER@CDB<n>

    This implies that, if you are not already connected to CDB<n>, then alter the session:

    ALTER SESSION SET CONTAINER = CDB<n>$ROOT;

  • Example 2:

    CONNECT CDB<n>PDB<k>TESTER@CDB<n>PDB<k>

    This implies that, if you are not already connected to CDB<n>PDB<k>, then alter the session:

    ALTER SESSION SET CONTAINER = CDB<n>PDB<k>;

Examples of sqlplus connection syntax for different users:

  • sqlplus / as sysdba

  • sqlplus / as sysdba@CDB1ROOT

  • sqlplus CDB1PDB1TESTER/Tester@//localhost:1521/CDB1PDB1.interop.com

Key migration and legacy keys

Encryption master keys may be migrated from an existing Oracle keystore to an Entrust HSM, or vice versa. In this case, and as used in this document, the term 'key migration' means that the responsibility for holding the master keys is being migrated. The encryption keys themselves are not copied (or imported) between a software keystore and HSM Security World. Fresh master key(s) are created within the software keystore or HSM that is to become the new key protector as a result of the migration. Subsidiary keys that are being protected are re-encrypted using the fresh master key(s). Thereafter, any new master keys are created in the current key protector you have migrated to.

During rekey, the previous master keys, or legacy keys, remain in the software keystore or HSM where they were created. After you have performed a key migration, you can retain access to the legacy keys in the software keystore or HSM you have migrated away from by making its passphrase the same as the current key protector’s. This allows both to be open at the same time allowing access to encryption keys they both contain. If you do not do this, you will only be able to access keys in the current key protector. If you are using both a software keystore and HSM at the same time, whichever is the current key protector is called the primary.

Overview

Transparent Data Encryption (TDE) is used to encrypt an entire database in a way that does not require changes to existing queries and applications. A database encrypted with TDE is automatically decrypted when the database loads it into memory from disk storage, which means that a client can query the database within the server environment without having to perform any decryption operations. The database is encrypted again when saved to disk storage. When using TDE, data is not protected by encryption whilst in memory. The encryption keys that are used to encrypt the database are typically held as part of the database, but these keys are themselves encrypted using a master encryption key in order to protect them. Using an Entrust HSM allows the master encryption keys to be kept physically separate from the database it is protecting, and also provides a hardware protected boundary from which encryption keys can never leave in plaintext. Additionally, the encryption keys are held in a Security World folder which is also encrypted and is useless to anyone who does not possess the authorized means to access them. The Security World folder permits easy back up or transfer to other legitimate clients that may use the authorized mechanisms to access the encryption keys.

Entrust recommends that you allow only unprivileged connections unless you are performing administrative tasks.

Other benefits of using the nShield HSM include:

  • Ability to store keys from all across an enterprise in one place for easy management.

  • Key Retention (rotate keys while keeping the old ones).

  • FIPS and Common Criteria compliance.