Appendix

This section highlights some considerations when choosing security world and key protection options for use with the Entrust nShield Security World software. 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 more information on security worlds and key protection, see the User Guide for your HSM.

In the event of a temporary failure of the 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 security world after a temporary outage.

If you are using an OCS to facilitate automatic recovery of the 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 protection method must be set up within the Entrust HSM before they can be used by an Oracle database. See your HSM User Guide for details. 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>. WSOP only supports softcard protection:

Oracle documentation gives the ordering <credential-name>|<credential-passphrase>. However, tests showed that the ordering <credential-passphrase>|<credential-name>` works.

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 Entrust recommends the following restrictions on token names, or credentialname:

Entrust places the following restrictions on passphrases, or credential- passphrases:

However, the Oracle SQL interface imposes further restrictions on top of the 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.