Appendix

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 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 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.