Oracle Transparent Data Encryption: nShield HSM Integration Guide

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

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.

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

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.

Other benefits of using the nshield HSM include:

Before installing the software, Entrust recommends that you familiarize yourself with:

Entrust also recommends you have an agreed organizational Certificate Practices Statement and a Security Policy/Procedure in place covering administration of the HSM. In particular, these documents should include the following aspects of HSM administration:

As part of your preparation, Entrust recommends that you read Security Worlds key protection and failure recovery.

This guide assumes that Oracle database software, and (at least) one Oracle database, is already installed on your system. With Oracle database software already installed, ensure that any required patches have been added.

To integrate an Oracle database with an Entrust HSM, the following steps are required:

Details of your installation and configuration will depend on:

The default host server user is oracle unless stated otherwise.

For more information on how to configure your Entrust environment, see the User Guide for your HSM.

For more information on how to configure your Oracle environment, see the Oracle documentation.

For more detail or suggestions on how you may set up your system, see the following Appendixes:

Before proceeding, it is assumed that:

You can use the following instructions to configure your Oracle database software to function using the Entrust HSM and Security World software, in one of the following scenarios:

Before attempting key migration, see Key migration and legacy keys. Oracle 11.1g or earlier versions might not support migration of some key types from a software wallet to an HSM. See the documentation for your Oracle version before attempting key migration.

The SQL commands that will be used later in this document might:

Make sure you use instructions appropriate to whether you are using:

Oracle has a control system that gates access to a software keystore or HSM:

You can open or close a software keystore or HSM with the following SQL statements.

The first time you open a keystore or HSM using a credential for a particular database instance, it activates the credential you are referencing. You should then be able to create master encryption keys, or use (any) existing master encryption keys, that are protected by that credential. You cannot have more than one active credential at the same time for the same instance. You must close the keystore or HSM to deactivate the credential.

You can simultaneously use different credentials for different database instances on the same host server. For a container database only its CDB is a real instance. All PDBs within the same CDB must use the same active credential.

See About the HSM credential if you want to change a credential.

The following procedure applies when the target database is non-multitenant, and you are already using a software wallet with TDE encryption. If your target database is multitenant, see Migrating from software keystore to HSM (multitenant).

Entrust strongly recommends you back up your software wallet as an independent operation before attempting migration to the HSM. Keep the backup folder in a safe place separated from the associated database files. Only users with authorization should be able to access the backup folder.

Repeat the following procedure for each database software wallet from which you want to migrate. Each independent database instance can use its own Entrust key protection method or credential if required.

Once an Entrust key protection method has been activated for a particular database instance, then you must continue to use that same credential for any further keys you want to protect for that instance.

See About the HSM credential if you want to change a credential.

Use the WALLET_ROOT and TDE_CONFIGURATION parameters. It is assumed the WALLET_ROOT parameter has already been set for Oracle keystore use.

The following procedure applies when the target database is multitenant, and you are already using a software wallet with TDE encryption. If your target database is non-multitenant, see Migrating from software wallet to HSM (non-multitenant).

Repeat the following procedure for each software keystore from which you want to migrate. Each container database (CDB) can use its own Entrust key protection method (credential) if required. However, once a Entrust key protection method has been activated for a particular database instance (CDB), then you must continue to use that same credential for any further keys you want to protect for that instance.

See About the HSM credential if you want to change a credential.

Use the WALLET_ROOT and TDE_CONFIGURATION parameters.

The following procedure applies when the target database is non-multitenant, and there is no pre-existing software wallet. If your target database is multitenant, see Create master keys directly in an HSM for multitenant database.

Repeat the following procedure for each database in which you want to create keys. Each database can use its own Entrust key protection method (credential) if required. However, once an Entrust key protection method has been activated for a particular database instance, then you must continue to use that same credential for any further keys you want to protect for that instance.

See About the HSM credential if you want to change a credential.

The following procedure applies when the target database is multitenant, and there is no preexisting software keystore. If your target database is non-multitenant, see Create master keys directly in an HSM for non-multitenant database.

Repeat the following procedure for each database in which you want to create keys. Each database instance can use its own Entrust key protection method (credential) if required. However, once an Entrust key protection method has been activated for a particular database instance (CDB), then you must continue to use that same credential for any further keys you want to protect for that instance.

See About the HSM credential if you want to change a credential.

You must create the container (CDB) master key first. After the CDB master key has been created you have a choice of creating master keys for all the PDBs it contains in one operation, or else for each PDB individually.

After you have established your HSM as the primary protector for your master encryption keys, for security reasons you may want to periodically replace the keys, or rekey. For your particular system, you can do this by following the instructions below.

The following subsections show how to perform a rekey in Oracle multitenant environments. After rekey, the new encryption keys should be immediately available and usable by the client that initiated the rekey.

This section highlights some considerations when choosing Security World and key protection options for use with the Entrust Security World. It focuses on recovery of Security World authorization where a system has temporarily failed (for instance after a power outage) and is then returned to operation. This does not apply to other failure recovery functions. These considerations are applicable to Security Worlds, key protection and failure recovery for both standalone systems and database clusters. For a fuller explanation of Security Worlds and key protection, refer to the User Guide for your HSM.

In the event of a temporary failure of the Entrust Security World, there may be a consequent loss of:

A credential authorization can be granted using either a Softcard or an OCS card, with passphrase. In the case of an OCS, a card must be always available in a valid HSM card reader in order to grant reauthorization after a failure, and permit automatic recovery.

Where FIPS authorization is required, this can be granted either by using an OCS card specifically for this purpose, or through an OCS card that is also used for credential authorization. A card from the OCS must be always available in a valid HSM card reader in order to grant reauthorization after a failure, and permit automatic recovery.

If you are using OCS cards through a RA secure channel, then if the secure channel is lost it must be reestablished before recovery using the OCS cards can begin. There is no automatic mechanism to reestablish the secure channel, which would have to be re-established manually, or through a user-defined script. For this reason, Entrust recommends that RA is not used for systems requiring automatic recovery.

Oracle auto-login facilities need to be set up to implement automatic recovery in the event of a temporary failure.

The following table describes the authorization recovery behavior of the nCipher Security World after a temporary outage.

If you are using an OCS to facilitate automatic recovery of the Entrust Security World:

Authorization acquired through a persistent operator card does not automatically reinstate itself after loss due to a temporary failure.

The protection methods available with the Entrust HSM are, in order of enhanced authentication:

The Softcard and OCS protection methods must be set up within the Entrust HSM before they can be used by an Oracle database. See your HSM User Guide for details. The module protection method can be used directly without any set up (other than the normal Entrust configuration). Setting up the Softcard or OCS includes creating and naming the token(s), with a passphrase (see the User Guide for your HSM).

Within SQL scripts as used by Oracle, identify the protection method using a <credential>. Choose the protection method you want to use for <credential> from the table below.

Oracle SQL uses the separator symbol | or : to divide the <credential-passphrase> and <credentialname>. Hence the total Oracle SQL string for a credential comprises:

In the nCipher Security World, Entrust recommends the following restrictions on token names, or credentialname:

In the nCipher Security World, Entrust places the following restrictions on passphrases, or credential- passphrases:

However, the Oracle SQL interface imposes further restrictions on top of the nCipher restrictions for what can comprise the string <credential-passphrase> + <separator> + <credential-name>, as follows:

From the Oracle side, if:

Use a passphrase of sufficient length to meet your current security requirements.

In the examples shown in this guide, credentials may be given descriptive names to make it clear what they are used for, such as <keystore-credential>. In practice, replace the descriptive names with the actual credential passphrases and names you are using. If you want to change the passphrase for Softcards or OCS cards, you must change the passphrase for the token in the nCipher Security World first, followed by updating the change to the database. For module protection you need only change the passphrase as seen by the database.

If you are using a FIPS 140-2 Level 3 Security World:

You can change the protection method or credential in one of the following ways:

This does not apply to module protection.

It is beyond the scope of this guide to deal with specific solutions to latency issues, and these will only be discussed in general terms.

When you are using an Oracle database, the nCipher Security World provides and protects the master encryption keys (wrapping keys) that are used to wrap Oracle symmetric keys that are in turn used for tablespace or table column encryption. The Oracle symmetric keys are stored as part of the database itself, although protected by the wrapping key.

In the context of this guide, encrypted data will be taken to include the symmetric key(s) that are stored as part of an Oracle database, as well as the encrypted data itself. Master encryption keys will be taken to be the (wrapping) keys stored by the nCipher Security World. Latency issues may occur when there is a mismatch between the encrypted data and the (correct) master encryption keys, due to a time lag in an update of either. This should only be a problem where there are multiple clients using the same database and encryption keys. In this case, when data or master encryption keys are updated on one client, the changes must be distributed before use by the other clients. Otherwise synchronization problems may occur. Note that the client that initiates the changes should suffer no synchronization problems.

Typically, these issues are more complex to resolve for a large and geographically distributed database system, rather than a small or localized system. It is the job of the system administration to ensure that encrypted data is synchronized with the appropriate master encryption keys at any particular time. Furthermore, is not within the control of the nCipher software if encrypted data does not match (the correct) master encryption keys in the Security World because of a time lag in updating the database.

Where there may be a time lag in updating master encryption keys in the Security World to match encrypted data, this may be due to the following:

Before using the Entrust HSM, either a new Security World must be created using the HSM, or a previously created Security World must be loaded onto the HSM. For more information, see the User Guide for your HSM.

The Security World is stored in a folder on your host server(s) and holds the database encryption keys, and associated credential files, that are to be protected. All data in the Security World folder is automatically encrypted and is useless to anyone without the authorized access and decryption mechanisms. When encryption keys are to be used, they are loaded into the physically protected environment of the HSM where they may be securely decrypted for use. Encryption keys protected by an HSM are never available in plaintext outside the boundary of the HSM. Legitimate use of the encryption keys is authorized and protected as described below.

If you are creating a new Security World, you must create an Administrator Card Set (ACS). An ACS is a set of physical smartcard(s) that must be used to create a Security World. When the Security World has been created, the ACS is used to secure the higher administrative functions of the Security World. Without a quorum of ACS cards, you cannot create or load a Security World onto an HSM, or alter it. Each ACS card can be issued with a unique passphrase and is specific to the Security World. When the Security World is created, you must stipulate a minimum number of cards, known as a quorum, required to load the Security World onto an HSM at any later time. However, the number of cards in the set should exceed the quorum, so that spares are available in case of failures or loss of card. An encrypted copy of the created Security World is stored in a folder on the host server(s).

If you are loading an existing Security World onto an HSM, you need access to a folder holding the Security World, and a quorum of the same ACS cards, and associated passphrase(s), that were used to create the Security World.

After the Security World has been created or loaded onto the HSM, a suitable HSM protection method may be prepared, or resumed if it was already present in an existing Security World. The protection method enables authorized access to the encryption keys assigned to it. The following protection methods are available, in order of increasing authentication requirements:

For instructions to set up these protection methods, see the User Guide for your HSM.

If you have loaded an existing Security World onto the HSM and will be using an OCS card set that it already contains, you must use the same physical OCS cards and associated passphrase(s) that were originally created in that Security World. Similarly, for Softcard or module protection, you will need the original passphrase(s).

In this Integration Guide, the word credential is used for a passphrase, or the combination of a passphrase and a named token (OCS or Softcard). Before an Oracle database can make use of the facilities offered by the nshield HSM, it must have access to the nCipher library file libcknfast.so which is installed as described in this guide. This is vital, as without access to the nCipher library file, the Oracle database and nshield HSM or nCipher software cannot communicate. Once successful communication is established between the Oracle database and nshield HSM, the Oracle database can gain access to the HSM by use of a credential incorporated into an SQL script. When it is set up with a credential, the Oracle database can proceed to create and assign encryption keys to that credential if no encryption keys yet exist, and encrypt or decrypt data using the encryption keys protected by that credential.

A protection method or credential is uniquely associated with the Security World where it was created and cannot be used with any other Security World. It should also be uniquely associated with the encrypted database(s) it is protecting. An encrypted database cannot be decrypted without access to the same master keys that protect it (likely to be an asymmetric pair). If you use OCS protection, the Oracle database must use the correct OCS card name and associated passphrase in its SQL scripts to access the encryption keys assigned to the OCS. Likewise, if you use a Softcard, the Oracle database must use the correct Softcard name and associated passphrase in its SQL scripts to access the encryption keys assigned to the Softcard.

If you use module protection, a passphrase is required for the Oracle database access mechanisms only. The Oracle module protection passphrase does not have a reference or counterpart in the nshield HSM. This means that a user who is able to access keys directly in the HSM is able to access module protected keys for any database without requiring the Oracle passphrase. This does not apply for Softcard or OCS protection.

Use of the HSM credentials and associated SQL scripts that open up access to the encrypted data should be strictly limited to authorized persons. However, the system can be set up so that approved clients can retrieve the encrypted data that is automatically decrypted when it leaves the database. Approved database users do not need the HSM credentials and associated SQL scripts to do this. They can continue to use the database as normal. Encryption should be invisible to them in most circumstances.

If you first use an Oracle software keystore to protect the master encryption keys, but later want to switch to an HSM, the encryption facilities can be migrated to the HSM. Also, encryption facilities can be migrated from an HSM back to an Oracle software keystore. During migration, fresh master key(s) are created in the HSM or software keystore, and the subsidiary keys that are being protected are re-encrypted with the new master key(s). Legacy keys remain in the software keystore or HSM where they were created, and should be (securely) retained in case they were used for past backups or other legacy data. For more information on key migration, see the Oracle documentation.

For loading or failover, you can use more than one HSM in the same system. The HSMs must share the Security World, and operate together to provide the same functions as a single HSM.

All nshield HSMs are FIPS certified to 140-2 Level 3, meaning that they are tamper evident and tamper resistant. nshield Connects are also tamper responsive, if an attempt to open the nshield Connect body is detected, all stored HSM encryption key data is deleted.

The encryption facilities described in this document are designed only to protect data at rest. TDE encrypts data while stored on disk, but once the data is retrieved to working memory, it is in plaintext and can be read by anyone able to access it. Decrypted data in transit between a database server and client should be independently encrypted to ensure security during data transfer. Security World data is inherently encrypted. There should be minimal security risk in transmitting this data over open networks. Similarly, encrypted database contents should be minimally at risk if transmitted over open networks.