Introduction

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

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

The integrated Oracle and Entrust solution has been tested with Oracle TDE for tablespace encryption, column encryption, or both concurrently. Entrust nShield HSMs are certified to FIPS 140 Level 3, delivering a high-grade level of security assurance. They protect sensitive encryption keys and offload encryption and key management operations from the database server.

Using this guide

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

  • An overview of how the Oracle database software and the Entrust Security World software with HSMs 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 can be used.

  • Troubleshooting advice.

This guide assumes that:

  • You have a good working knowledge of Oracle database technology.

  • You have read the Security World and HSM documentation, and are familiar with the documentation and setup process for Oracle database TDE.

  • You already have an Oracle database installed.

After the Entrust Security World software and HSM are installed and configured, no additional software is required; only minor configuration changes are needed.

This guide cannot anticipate every configuration requirement. The examples provided are not exhaustive and do not necessarily show the simplest or most efficient way to achieve a given result. Use them as a starting point for integrating the Entrust HSM with an Oracle database, and adapt them to your own circumstances.

Entrust strongly recommends that you thoroughly validate your solutions in a safe test environment before committing them to production. If you require additional help in setting up your system, contact Entrust Support.

Entrust accepts no responsibility for:

  • Loss of data or services incurred through use of the examples in this guide, or through errors in this guide.

  • Information in this guide that becomes obsolete due to changes or upgrades to Oracle products.

Product configuration

Entrust has successfully tested nShield HSM integration in the following configuration:

OS Version Kernel Oracle Version

Red Hat Enterprise Linux 8

4.18.0-553.125.1.el8_10.x86_64

Oracle Database 19c - 19.31.0.0.0

Supported nShield hardware and software versions

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

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

nShield Connect

13.6.16

12.72.4 (FIPS 140-2 certified)

13.6.16

✓

✓

✓

✓

nShield 5c

13.6.16

13.4.5 (FIPS 140-3 certified)

13.6.16

✓

✓

✓

✓

Conventions used in this document

Multitenant and non-multitenant

This Integration Guide covers both non-multitenant and multitenant databases, and uses the terms appropriate to the database type under discussion:

  • Non-multitenant databases run on Oracle version 11g or earlier. Multitenant databases were introduced in Oracle version 12c.

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

  • Database software that supports multitenant databases may also support non-multitenant databases (pre-21c). In this case, when a non-multitenant mode is the subject matter, the non-multitenant terminology and SQL shown below applies. When a multitenant mode is the subject matter, the multitenant terminology and SQL applies.

The following terminology is used:

  • Non-multitenant (non-container):

    • Oracle software-based encryption key repository: ALTER SYSTEM SET ENCRYPTION …​

  • Multitenant (container):

    • Oracle software-based encryption key repository: software keystore.

    • SQL preamble for encryption-related commands: ADMINISTER KEY MANAGEMENT, and so on.

Where terminology applies equally to a software wallet or keystore, this guide uses software keystore as the default term for both.

Database connections

To access a database, you must be a user with the correct permissions, and you must also have the privileges required to perform the operations you intend to carry out while connected. Your system administrator can create users and grant suitable permissions and privileges according to your organization’s security policies.

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

  • <database-identifier> is the database to connect to.

The following database users and database identifiers are used in the examples in this guide.

  • <database-user>. This guide uses one of the following users to connect to databases:

    • sysdba: Oracle’s standard sysdba user.

    • system: Oracle’s standard system user.

    • Non-multitenant:

      • TESTER, as a local user.

    • Multitenant:

      • C##TESTER, as a common user for the 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 uses one of the following database identifiers when connecting:

    • 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 are:

      • CDB<n>, to connect to 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, a connection implies that you must alter the session if you are not already connected to the required container. For example:

  • Example 1:

    CONNECT C##TESTER@CDB<n>

    If you are not already connected to CDB<n>, alter the session:

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

  • Example 2:

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

    If you are not already connected to CDB<n>PDB<k>, 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@CDB1$ROOT

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

Key migration and legacy keys

Encryption master keys can be migrated from an existing Oracle keystore to an Entrust HSM, or vice versa. In this guide, the term key migration means that the responsibility for holding the master keys is being transferred between key protectors. The encryption keys themselves are not copied or imported between a software keystore and the HSM Security World. Instead, fresh master keys are created within the software keystore or HSM that is to become the new key protector, and any subsidiary keys being protected are re-encrypted using the new master keys. From that point on, any new master keys are created in the current key protector you have migrated to.

During rekey, the previous master keys (the legacy keys) remain in the software keystore or HSM where they were created. After a key migration, you can retain access to the legacy keys in the software keystore or HSM you have migrated away from by setting its passphrase to the same value as the current key protector’s. This allows both to be open at the same time, providing access to the encryption keys they each contain. If you do not do this, you can only access keys in the current key protector. When you are using both a software keystore and an HSM at the same time, the current key protector is referred to as the primary.

Overview

Transparent Data Encryption (TDE) encrypts an entire database without requiring changes to existing queries and applications. A database encrypted with TDE is automatically decrypted when it is loaded from disk storage into memory, so clients can query the database within the server environment without having to perform any decryption operations themselves. The database is re-encrypted when it is written back to disk. Note that with TDE, data is not protected by encryption while it is in memory.

The encryption keys used to encrypt the database are typically held as part of the database, but they are themselves encrypted with a master encryption key. Using an Entrust HSM allows the master encryption keys to be kept physically separate from the database they protect, and provides a hardware-protected boundary that encryption keys can never leave in plaintext. The encryption keys are stored in a Security World folder that is also encrypted, making it useless to anyone without the authorized means to access them. The Security World folder can be easily backed up or transferred to other legitimate clients that 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:

  • Centralized storage of keys from across the enterprise, for easier management.

  • Key retention: rotate keys while keeping the previous ones.

  • FIPS and Common Criteria compliance.