Appendix

Security Worlds, key protection, and failure recovery

This section highlights key considerations when choosing Security World and key-protection options for use with the Entrust Security World. It focuses on recovery of Security World authorization when a system has temporarily failed (for example, after a power outage) and is then returned to operation. It does not cover other failure recovery functions. These considerations apply 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, see 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:

  • Credential authorization.

  • FIPS authorization, if you are using a FIPS 140 Level 3 Security World.

Credential authorization can be granted using either a Softcard or an OCS card, with a passphrase. When using an OCS, a card must always be available in a valid HSM card reader so that reauthorization can be granted after a failure and automatic recovery can take place.

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

If you are using OCS cards through an RA secure channel, and the secure channel is lost, it must be re-established before recovery using the OCS cards can begin. There is no automatic mechanism to re-establish the secure channel: it must 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 must be set up to enable automatic recovery in the event of a temporary failure.

Never use ACS cards for FIPS authorization because they do not support automatic recovery. Softcards or OCS cards must be members of the same Security World.

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

Security World type Protection/Credential Stand-alone system Database cluster

FIPS level 2

Module

Recovers automatically

Recovers automatically

Softcard

Recovers automatically

Recovers automatically

OCS

Use OCS for credential authorization: (1) Use 1/N quorum. Use the same passphrase for all cards. (2) Leave one OCS card in the HSM slot. Recovery is automatic.

Use OCS for credential authorization: (1) Use 1/N quorum. Use the same passphrase for all cards. (2) Leave an OCS card in the slot of every HSM in the cluster. Recovers automatically.

FIPS level 3

Module

Use OCS for FIPS authorization (only): Leave an OCS card in HSM slot. Recovers automatically

Use OCS for FIPS authorization (only): Leave an OCS card in slot of every HSM in cluster. Recovers automatically

Softcard

Use OCS for FIPS authorization (only): Leave an OCS card in HSM slot. Recovers automatically

Use OCS for FIPS authorization (only): Leave an OCS card in slot of every HSM in cluster. Recovers automatically

OCS

Use OCS for both credential and FIPS authorization: (1) Use 1/N quorum. Same passphrase for all cards. (2) Leave an OCS card in HSM slot. Recovers automatically.

Use OCS for both credential and FIPS authorization: (1) Use 1/N quorum. Same passphrase for all cards. (2) Leave an OCS card in slot of every HSM in cluster. Recovers automatically.

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

  • If you are using the OCS for credential authorization, all cards must be members of the same card set for the same credential, and the same passphrase must be assigned to every card in the set.

  • If you are using the OCS for FIPS authorization only, the quorum automatically defaults to 1/N, and any passphrase is ignored.

Authorization acquired through a persistent operator card is not automatically reinstated after a temporary failure.

About the HSM credential

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

  • Module: Encryption keys are protected by an nCipher Security World protecting key in the HSM.

  • Softcard: Encryption keys are protected by a named Softcard (software-based) token key, a passphrase, and the nCipher Security World protecting key in the HSM. You can have many different Softcards, but each one is standalone.

  • OCS: Encryption keys are protected by the presence of a named physical token (an OCS smartcard), an OCS token key, a passphrase, and the nCipher Security World protecting key in the HSM. OCS cards are usually part of a set of several OCS cards (a card set), and any member of the same card set protects the same encryption keys. You can have many different OCS card sets, where each card set may protect different encryption keys.

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

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

Protection Type Credential or <credential>

Module protection

<module-passphrase>. In this case, the passphrase is an access mechanism for Oracle and is not used by the nShield HSM.

Softcard protection

<softcard-passphrase>|<softcard-name>

OCS protection

<OCScard-passphrase>|<OCScard-name>

Oracle SQL uses the separator symbol | or : to divide the <credential-passphrase> and <credential-name>. The total Oracle SQL string for a credential is therefore:

  • Module protection: <passphrase>

  • Softcard or OCS card protection: <credential-passphrase> + <separator> + <credential-name>.

In the nCipher Security World, Entrust recommends the following restrictions on token names (<credential-name>):

  • Maximum length of 254 characters.

  • ASCII 7-bit characters only, restricted to:

    A-Z, a-z, 0-9, $ - _ (no white space).

In the nCipher Security World, Entrust applies the following restrictions to credential passphrases:

  • Maximum length of 254 characters.

  • ASCII 7-bit characters only:

    A-Z, a-z, 0-9, ! @ # $ % ^ & * - _ + = [ ] { } | \ : ' , . ? / ` ~ " < > ( ) ; (no white space).

The Oracle SQL interface imposes additional restrictions on the characters allowed in the string <credential-passphrase> + <separator> + <credential-name>:

  • The total string length, including separator, can be no more than 30 characters. This leaves 29 characters for the <credential-passphrase> + <credential-name>.

  • The symbols |, :, ", and ' cannot be used within the <credential-passphrase> or <credential-name>.

From the Oracle side, if:

  • N is the length of the credential name, and

  • P is the length of the credential passphrase,

    then 2 ⇐ (N+P) ⇐ 29, where 1 ⇐ N ⇐ 28 and 1 ⇐ P ⇐ 28 (assuming a minimum of one character for each of the passphrase and the name).

    Permitted symbols are:

  • <credential-passphrase>:

    A-Z, a-z, 0-9, ! @ # $ % ^ & * - _ + = [ ] { } \ , . ? / ~ < > ( ) ; (no white space)

  • <credential-name>:

    A-Z, a-z, 0-9, $ - _ (no white space).

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

Oracle Wallet Manager states: "Passwords must have a minimum length of eight characters and contain alphabetic characters combined with numbers or special characters".

When you are using a Softcard or OCS credential, any SQL script that uses the credential must get the <credential-passphrase> and <credential-name> exactly right. If there is a mistake, the entire credential string may be misinterpreted as a <module-passphrase>, and your encryption keys will then be placed under module protection rather than the Softcard or OCS protection you intended. For this reason, after creating encryption keys or rekeying, use the nCipher rocs utility immediately to check that the keys you have just created are under the expected credential or protection method.

In the examples shown in this guide, credentials may be given descriptive names to make their purpose clear, 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 first change the passphrase for the token in the nCipher Security World, and then update the database to use the new passphrase. For module protection, you only need to change the passphrase as seen by the database.

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

  • To change the passphrase of a Softcard, or to create a new Softcard, you need either authorization using ACS cards or an authorizing OCS card.

  • To change the passphrase of an OCS card, or to create a new OCS card, you need authorization using ACS cards.

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

  • Continue using the same protection method and token, but change the associated passphrase. There is no token for module protection, but you can still change the passphrase. In this case, after the passphrase is changed, TDE continues working using the new passphrase, because the protected TDE encryption keys remain the same.

  • Continue using the same protection method, but change the token and passphrase. In this case, you have two options:

    1. If you are not transferring encryption keys from the previous token to the new token, you can no longer continue using TDE as protected by the previous token’s keys. You will only be able to use TDE encryption keys shielded under the newly activated credential.

    2. If you are transferring encryption keys from the previous token to the new token, you can continue using TDE as protected by the previous token’s keys. However, you can only transfer keys between different Softcards, or between different OCS cards. You cannot transfer keys between Softcards and OCS cards.

  • Change the protection method and associated credential with passphrase. In this case, you cannot transfer encryption keys between the different protection methods. You can only use TDE encryption keys shielded under the new protection method and credential.

Change passphrase only

  1. To change a passphrase only, run the following SQL:

    CONNECT sysdba@CDB<n>$ROOT

    -- If the database is not already open
ALTER PLUGGABLE DATABASE ALL OPEN;

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "<old-credential>" CONTAINER=ALL;

  2. At this point:

    • If you are using module protection, skip to the next SQL statements.

    • If you are using Softcard protection, see the User Guide for your HSM for instructions on how to change the Softcard passphrase using the ppmk utility.

    • If you are using OCS protection, see the User Guide for your HSM for instructions on how to change the OCS passphrase using the cardpp utility. If you are using OCS cards, all cards within the same (1/N) card set must be updated to share the same passphrase.

  3. Bounce the database.

  4. Run the following SQL:

    CONNECT sysdba@CDB<n>$ROOT

    -- If the database is not already open
ALTER PLUGGABLE DATABASE ALL OPEN;

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "<new-credential>" CONTAINER=ALL;

Change token with associated passphrase but keep the same protection method

This does not apply to module protection.

  1. To change a token with a passphrase for the same protection method, run the following SQL:

    CONNECT sysdba@CDB<n>$ROOT

    -- If the database is not already open
ALTER PLUGGABLE DATABASE ALL OPEN;

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "<old-token-credential>" CONTAINER=ALL;

  2. At this point:

    • If you do not want to transfer TDE encryption keys from the previous token to the new token, skip to the next SQL statements. If you are using an OCS card set (1/N), all OCS cards within the new card set must share the same passphrase.

      If you do want to transfer TDE encryption keys from the previous token to the new token, see the User Guide for your HSM for instructions on how to transfer the keys using the rocs utility.

      Entrust recommends that you back up your Security World data before transferring keys between tokens. See the User Guide for your HSM.

      To transfer keys using the rocs utility, you need your Security World ACS cards to authorize the transfer of keys between tokens. You can only transfer encryption keys between Softcards, or between OCS cards, but not between Softcards and OCS cards. If you are transferring keys to another OCS card set (1/N), all OCS cards within the target card set must share the same passphrase.

  3. Bounce the database.

  4. Run the following SQL:

    CONNECT sysdba@CDB<n>$ROOT

    -- If the database is not already open
ALTER PLUGGABLE DATABASE ALL OPEN;

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "<new-token-credential>" CONTAINER=ALL;

Change protection method

  1. To change the protection method, run the following SQL:

    CONNECT sysdba@CDB<n>$ROOT

    -- If the database is not already open
ALTER PLUGGABLE DATABASE ALL OPEN;
ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "<old-protection-credential>" CONTAINER=ALL;

    If you are using OCS cards, all OCS cards within the same (1/N) card set must share the same passphrase.

  2. Bounce the database.

  3. Run the following SQL:

    CONNECT sysdba@CDB<n>$ROOT

    -- If the database is not already open
ALTER PLUGGABLE DATABASE ALL OPEN;

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "<new-protection-credential>" CONTAINER=ALL;

Latency issues

It is beyond the scope of this guide to deal with specific solutions to latency issues; they are discussed here only 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 the Oracle symmetric keys, which are in turn used for tablespace or table column encryption. The Oracle symmetric keys are stored as part of the database itself, although they are protected by the wrapping key.

In the context of this guide, encrypted data refers to the symmetric keys that are stored as part of an Oracle database as well as the encrypted data itself. Master encryption keys refers to the wrapping keys stored by the nCipher Security World. Latency issues can occur when there is a mismatch between the encrypted data and the correct master encryption keys, due to a time lag in updating either of them. This should only be a problem where multiple clients are 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 to the other clients before they use them. Otherwise, synchronization problems may occur. Note that the client that initiates the changes should not experience synchronization problems.

Typically, these issues are more complex to resolve for a large and geographically distributed database system than for a small or localized system. It is your system administrator’s responsibility to ensure that encrypted data is synchronized with the appropriate master encryption keys at any given time. Furthermore, nCipher software cannot control whether encrypted data matches the correct master encryption keys in the Security World when database updates are delayed.

A time lag in updating master encryption keys in the Security World to match encrypted data may be due to either of the following:

  • A time lag in distributing new or updated master encryption keys to a Security World, or between different copies of the same Security World, after a key rotation or rekey.

  • A lag in making an nCipher hardserver instance recognize the new master keys after they have been successfully distributed to the Security World.

Storage and distribution of updated master keys

Common storage of master encryption keys

Where possible, Entrust recommends configurations where the Security World data is held in common storage between clients that need to use the same master encryption keys.

If common storage of master encryption keys is used, there may be a short delay before newly created keys are successfully copied to the common store. After this, there may be a further short delay before a client can access the keys from the common store. The period during which a client cannot access the updated keys is likely to be very short, but may grow if the client is geographically distant from the common store and communication delays accumulate. With a common store, master keys are implicitly updated for the use of all clients, and there is no need to trigger any other update mechanism.

Common key storage:

  • Makes key updates implicit and simple, because there is only one store.

  • Keeps time delays short, minimizing problems synchronizing keys with data.

  • Requires the common store to be backed up frequently, because it is otherwise the only copy of the encryption keys.

Local storage of master encryption keys

If each client is using its own local copy of the Security World, then after a master key update is initiated on any client, the updated keys must be distributed in a timely manner to the local Security Worlds of every other client. To achieve this, there must be an explicit update mechanism to recognize when an update is required in the first place, and to then trigger the key distribution process.

If this is done manually, it is likely to be a slow process. If it is done automatically, recognizing when a rekey occurs should not be difficult on the client that initiates it, so triggering the update should not be a problem. Even so, for a configuration that uses dispersed local copies of the Security World, mechanisms to distribute the updated keys are likely to be slower and more difficult to implement than in the common key storage case. This makes timely synchronization of the master keys with the data more challenging.

Entrust provides the utilities rfs-setup and rfs-sync (gang-client) that offer limited facilities to distribute keys between different clients, although you must use an RFS for intermediate key storage. These utilities were originally designed for manual operation, but can be incorporated into automated scripts customized for your particular configuration. Developing these scripts into a fully automated system to distribute your keys without synchronization problems is a task for your system development team. For more information about the nCipher rfs-setup and rfs-sync utilities, see the User Guide for your HSM.

An alternative for key distribution is the UNIX rsync utility. However, it is beyond the scope of this guide to discuss how this may be used.

If you require further assistance with distributed key update arrangements, contact Entrust Support.

Local key storage and distribution:

  • Requires an explicit update mechanism that may be complex to automate.

  • Makes it harder to keep distribution delays short, increasing the chance of problems synchronizing keys with data.

  • Provides multiple copies of the Security World, so the loss of any one copy is less significant than it would be with common storage.

Making a hardserver instance recognize new master keys

In a configuration with multiple clients sharing the same encryption keys, if a rekey is performed, the new keys are immediately available and usable on the client that performed the rekey. However, on other clients, once the new keys are available in the Security World folder, choose one of the following options to make the keys usable by the local hardserver instance (for both shared and local key storage):

  1. In the nCipher cknfastrc file for each client, add:

    CKNFAST_ASSUME_SINGLE_PROCESS=0

    This ensures that the Security World folder is scanned for the latest keys whenever a key is required, and avoids key caching. However, with this option the Security World is scanned every time a key is required, even if no new keys have been added. If there are many keys, this can take significant time, and because it is repeated every time a key is needed, it can slow down overall operations. This option does not require downtime for the key update.

  2. For each client that did not initiate a rekey, reconnect all applications and users that were using encryption keys on the database. A new connection forces a scan of the Security World, which picks up new keys. In this case, however, it is a single scan for that connection and is NOT repeated every time a key is required. If you have many keys, encrypted database operations will be temporarily affected only during the reconnection needed to update master keys. This option may imply temporary downtime while reconnections are made after a key update. However, if you routinely make new connections on your system per transaction, the impact should be barely noticeable.

Other considerations

Even if a client is unable to access the required master keys for a short period, this is not necessarily a serious problem. The Oracle database should be able to recover gracefully if it is unable to obtain the correct master keys. It should be possible to program the database to roll back failed transactions and make several attempts to repeat the transaction, until some expiry point is reached.

If the delay in updating the master keys is short, repeated attempts at the transaction should eventually succeed when the master key update is complete. If it is not possible to do this within the Oracle database itself, you should be able to do something similar in the application code that uses the database.

If you are using common shared storage, any lag in updating the master keys is expected to be short enough that either:

  • The Oracle database is not affected.

  • The Oracle database copes gracefully and subsequently recovers automatically, as described above, when the update completes.

If delays in updating the master keys exceed the limits of what the Oracle database or application can cope with gracefully, it may be necessary to halt encryption transactions temporarily while a master key rotation is performed.

Entrust strongly recommends that you test your solutions in a safe environment before transferring them to a production environment.

How Oracle works with the Entrust HSM

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 servers 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 can 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 smartcards that must be used to create a Security World. Once 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 a Security World, load it 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 (a quorum) required to load the Security World onto an HSM at a later time. The number of cards in the set should exceed the quorum, so that spares are available in case of card failure or loss. An encrypted copy of the created Security World is stored in a folder on the host servers.

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, with their associated passphrases, 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 can 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:

  • Module protection: Oracle master encryption keys are protected by a Security World protecting key.

  • Softcard protection: Oracle master encryption keys are protected by a named software token key (a single Softcard), a passphrase, and the Security World protecting key.

  • Operator Card Set (OCS) protection: Oracle master encryption keys are protected by the presence of a set of named physical tokens (smartcards), an OCS token key, and the Security World protecting key. An OCS smartcard set is similar to the ACS card set in that it stipulates a quorum of cards required to authorize use of its protection. The number of cards in the set should exceed the number of HSMs that may share the same Security World, so that spares are available in case of failure. The card set should have a unique name that covers all cards in the set. In typical use with Oracle, all OCS cards in the same set should have the same passphrase, and the quorum is one.

For instructions on setting up these protection methods, see the User Guide for your HSM.

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

In this Integration Guide, the word credential is used for a passphrase, or for the combination of a passphrase and a named token (OCS or Softcard). Before an Oracle database can use 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: without access to the nCipher library file, the Oracle database and nShield HSM (or nCipher software) cannot communicate. Once communication is established between the Oracle database and the nShield HSM, the Oracle database can gain access to the HSM through a credential incorporated into an SQL script. When it is set up with a credential, the Oracle database can create and assign encryption keys to that credential if no encryption keys yet exist, and can encrypt or decrypt data using the encryption keys protected by that credential.

A protection method or credential is uniquely associated with the Security World in which it was created, and cannot be used with any other Security World. It should also be uniquely associated with the encrypted databases it protects. 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 only for the Oracle database access mechanisms. The Oracle module protection passphrase does not have a reference or counterpart in the nShield HSM. This means that a user who can access keys directly in the HSM can access module-protected keys for any database without needing the Oracle passphrase. This does not apply to Softcard or OCS protection.

Use of HSM credentials and the associated SQL scripts that open up access to 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, which is automatically decrypted when it leaves the database. Approved database users do not need the HSM credentials or 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. Encryption facilities can also be migrated from an HSM back to an Oracle software keystore. During migration, fresh master keys are created in the HSM or software keystore, and the subsidiary keys being protected are re-encrypted with the new master keys. 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 load balancing 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.

There is some performance degradation when Transparent Data Encryption (TDE) is used. The impact depends on the types of transactions you typically perform. Using the Security World software and the HSM usually has a negligible impact on TDE performance. You should test your Oracle and HSM configuration in a realistic test environment before committing to a production environment.

All nShield HSMs are certified to FIPS 140 Level 3, meaning that they are tamper-evident and tamper-resistant. nShield Connect units 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 it is stored on disk, but once the data is retrieved into 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, so there should be minimal security risk in transmitting it over open networks. Similarly, encrypted database contents should be at minimal risk if transmitted over open networks.