Security Worlds

This chapter describes the Security World infrastructure we have developed for the secure life-cycle management of cryptographic keys. The Security World infrastructure gives you control over the procedures and protocols you need to create, manage, distribute and, in the event of disaster, recover keys.

A Security World provides you with the following features:

  • Security

  • Application independence

  • Platform independence

  • Flexibility

  • Scalability

  • Robustness

  • Audit logging

A Security World comprises:

  • One or more Entrust nShield HSMs (such as the nShield HSM)

  • An Administrator Card Set (ACS)
    A set of Administrator smart cards used to control access to the Security World configuration, as well as in recovery and replacement operations.

  • Optionally, one or more Operator Card Sets (OCSs)
    A set or sets of Operator smart cards used to control access to application keys.

  • Some cryptographic key and certificate data that is encrypted using the Security World key and stored on a host computer or computers

You can add or remove cards, keys, and even hardware security modules at any time. These components are linked by the Security World key, which is unique to each world. To see how these components are related to one another, see the image below.

Distributing the keys used for different tasks within the Security World over different storage media means that the Security World can recover from the loss of any one component. It also increases the difficulties faced by an attacker, who needs to obtain all the components before gaining any information.

Key protection in a Security World

Security

We have designed the Security World technology to ensure that keys remain secure throughout their life cycle. Every key in the Security World is always protected by another key, even during recovery and replacement operations.

Because the Security World is built around nShield key-management modules, keys are only ever available in plain text on secure hardware.

All Security Worlds rely on you using the security features of your operating system to control the users who can access the Security World and, for example, write data to the host.

Smart cards

The Security World uses:

  • An Administrator Card Set (ACS) to control access to recovery and replacement functionality

  • Zero or more Operator Card Sets (OCSs) to control access to application keys

In FIPS 140 Level 3 Security Worlds, you require a card from either the ACS or an OCS to authorize most operations, including the creation of keys and OCSs.

Each card set consists of a number of smart cards, N, of which a smaller number, K, is required to authorize an action. The required number K is known as the quorum.

The value for K should be less than N. We do not recommend creating card sets in which K is equal to N because an error on one card would render the whole card set unusable. If your ACS became unusable through such an error, you would have to replace the Security World and generate new keys. In Common Criteria CMTS Security Worlds the minimum value of K for the ACS is 2.

An ACS is used to authorize several different actions, each of which can require a different value for K. All the card sets are distinct: a smart card can only belong to the ACS or to one OCS.

Each user can access the keys protected by the Security World and the keys protected by their OCS. They cannot access keys that are protected by another OCS.

Operator Cards employ the Security World key to perform a challenge-response protocol with the hardware security module. This means that Operator Cards are only useable by an HSM that belongs to the same Security World.

Remote Operator

The Remote Operator feature is used to load a key protected by an OCS onto a machine to which you do not have physical access (for example, because it is in a secure area).

The Remote Operator feature is not available in Common Criteria CMTS Security Worlds.

The Remote Operator feature enables the secure transmission of the contents of a smart card inserted into the slot of one module (the attended module) to another module (the unattended module). To transmit to a remote module, you must ensure that:

  • The smart card is from a persistent OCS
    See Using persistent Operator Card Sets for more about persistent cards.

  • The attended and unattended modules are in the same Security World

To achieve secure communication channels between the attended and unattended modules, the hardserver uses an impath (an abbreviation of intermodule path), a secure protocol for communication over IP networks. The communication channels between the modules:

  • Are secure against both eavesdroppers and active adversaries

  • Can carry arbitrary user data as well as module-protected secrets, such as share data, that pass directly between modules.

See also Compatibility issues.

Remote Administration

Remote Administration is a collection of features that allow you to configure and operate an HSM or set of HSMs without being physically present at the HSM. This includes creating ACS when creating a Security World and presenting ACS to authorize loading of a Security World. It also includes creating OCS to protect application keys and presenting OCS to authorize the loading of application keys. The OCS may be persistent or non-persistent.

The ACS and/or OCS cards must be nShield Remote Administration smart cards. When presenting a card, a secure channel is formed directly between the Remote Administration smart card and the target HSM before any token shares are read from or written to the smart card. The secure channel is secure against both eavesdroppers and active adversaries.

For more information see Security World Remote Administration

Security World and an nShield HSM

To enable the secure transmission of data between an nShield HSM and each client, the hardserver uses an impath (see Remote Operator). Any nShield HSM on the network can load a Security World securely over the network, and access its keys, wherever the HSM is installed.

Security World and key data is stored on the file system of the nShield HSM, where it is updated whenever card or key operations are performed on the HSM. The data is also automatically transferred to the remote file system (RFS). If required, you can also share the data with client computers that use the Security World. For more information, see:

You can update the Security World on the host using:

  • The nShield HSM front panel controls

  • The command-line utilities

  • The Cryptographic Service Provider wizard

  • KeySafe.

You can also use these tools to create keys or cards. If you perform such tasks on a client other than the computer on which the RFS is installed, you must transfer the updated files to the RFS before they are available to the HSM.

NIST SP800-131A

When a new Security World is created it will be SP800-131A compliant.

Compatibility issues

In order to comply with the latest encryption standards, Entrust has adopted an enhanced NIST SP800-131A compliant encryption protocol between nShield HSM HSMs and their clients with Security World software installed. In some cases, this change may have an impact on the compatibility of network-attached HSMs in environments with mixed HSM deployments.

In most cases where versions of Security World software of v11.50 or later are deployed in conjunction with v11.40 software or lower, no action is required. However, there are two cases in which communication cannot be established between the HSM and clients or hosts:

  • v11.50 or higher clients communicating with a v11.40 or lower nShield HSM, where the HSM client uses an nToken.

  • v11.50 or higher nShield HSM communicating with a Remote File System (RFS) using v11.40 or lower.

Release version Image versions
nShield HSM		 Security World Software1 v11.40 Security World Software1 v11.50 and later

Up to 11.40

Up to image version 0.3.5.

Supported.

For deployments with nTokens, please upgrade the nShield HSM netimage. As a less preferred option, you can downgrade the client-side software.

11.50 or later

Image 0.3.6 or later.

RFS and client software upgrade required.

Supported.

1 Previously known as nCipher software, or nCSS.

FIPS 140 compliance

All Security Worlds are compliant with the Federal Information Processing Standards (FIPS) 140 specification. The default setting for Security Worlds complies with Level 2 of FIPS 140.

A Security World that complies with the roles and services section of FIPS 140 Level 2 does not require any authorization to create an OCS or an application key.

FIPS 140 Level 3 compliance

When you create a Security World, you can choose whether the Security World is compliant with the roles and services section of either:

  • FIPS 140 at Level 2

  • FIPS 140 at Level 3

The FIPS 140 Level 3 option is included for those customers who have a regulatory requirement for compliance with FIPS 140 at Level 3.

If you choose to create a Security World that complies with FIPS 140 Level 3, the nShield HSM initializes in that mode, conforming with the roles and services, key management, and self-test sections of the FIPS validation certificate.

Before you can create or erase an OCS in a Security World that complies with FIPS 140 Level 3, you must authorize the action with a card from the ACS or an OCS from that Security World.

For more details about FIPS 140, see http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf.

Common Criteria compliance

The nShield XC range of HSMs are Common Criteria certified to Common Criteria v3.1 EAL4+ AVA_VAN.5 and to eIDAS.

To configure and operate the module in its evaluated configuration, the separate Common Criteria guides should be followed. Please contact Entrust nShield Support, https://nshieldsupport.entrust.com.

Platform independence

The Security World is completely platform independent. All key information is stored in a proprietary format that any computer supported by Security World Software can read, regardless of the native format used by that computer. This enables you to:

  • Safely move a Security World between platforms with differing native formats. For example, you can move a Security World between Windows and Linux operating environments.

  • Include hosts running different operating systems in the same Security World.

When copying host data between computers using different operating systems or disk formats, use a mechanism that preserves the original data format and line endings (such as .tar file archives).

Application independence

A Security World can protect keys for any applications correctly integrated with the Security World Software. Each key belongs to a specific application and is only ever used by that application. Keys are stored along with any additional data that is required by the application.

You do not need to specify:

  • Which applications you intend to use. You can add a key for any supported application at any time.

  • How the key is used by an application. A Security World controls the protection for the key; the application determines how it is used.

Although keys belong to a specific application, OCSs do not. You can protect keys for different applications using the same OCS.

Operator Card Sets

In the image above:

  • Card Set 1 protects multiple keys for use with Application 1 and Application 2

  • Card Set 2 protects a single key for use with Application 2

  • Card Set 3 protects multiple keys for use with Application 2 and Application 3

  • The Security World key protects a single key for use with Application 3.

Flexibility

Within a Security World, you can choose the level of protection for each application key that you create.

When you create a Security World, a cryptographic key is generated that protects the application keys and the OCSs in the Security World.

Using the Security World key: module-protected keys

You can use the Security World key to protect an application key that you must make available to all your users at all times. This key is called a module-protected key. Module-protected keys:

  • Have no passphrase

  • Are usable by any instance of the application for which they were created, provided that this application is running on a server fitted with a hardware security module belonging to the correct Security World.

This level of protection is suitable for high-availability Web servers that you want to recover immediately if the computer resets.

Using Operator Card Sets: OCS-protected keys

An OCS belongs to a specific Security World. Only a hardware security module within the Security World to which the OCS belongs can read or erase the OCS. There is no limit to the number of OCSs that you can create within a Security World.

An OCS stores a number of symmetric keys that are used to protect the application keys. These keys are of the same type as the Security World key.

Each card in an OCS stores only a fragment of the OCS keys. You can only re-create these keys if you have access to enough of their fragments. Because cards sometimes fail or are lost, the number of fragments required to re-create the key (K) are usually less than the total number of fragments (N).

To make your OCS more secure, we recommend that you make the value of K relatively large and the value of N less than twice that of K (for example, the values for K/N being 3/5 or 5/9). This practice ensures that if you have a set of K cards that you can use to recreate the key, then you can be certain that there is no other such card set in existence.

Some applications restrict K to 1.

Using Operator Card Sets to share keys securely

You can use OCSs to enable the same keys for use in a number of different HSMs at the same time.

If you have a non-persistent OCS, you must leave one of the cards in an appropriate card slot of each HSM. This should only be done if it is in accordance with the security policies of your organization.

To use OCS-protected keys across multiple HSMs, set:

  • K to 1

  • N at least equal to the number of the HSMs you want to use.

You can then insert single cards from the OCS into the appropriate card slot of each HSM to authorize the use of that key.

To issue the same OCS-protected key to a set of users, set:

  • K to 1

  • N equal to the number of users.

You can then give each user a single card from the OCS, enabling those users to authorize the use of that key.

If you have created an OCS for extra security (in which K is more than half of N), you can still share the keys it protects simultaneously amongst multiple modules as long you have enough unused cards to form a K/N quorum for the additional hardware security modules. For example, with a 3/5 OCS, you can load keys onto 3 hardware security modules because, after loading the key on the first device, you still have 4 cards left. After loading the key on a second device, you still have 3 cards left. After loading the key onto a third device, you have only 2 cards left, which is not enough to create the quorum required to load the key onto a fourth device.

If a card becomes damaged, you can replace the whole OCS if you have authorization from the ACS belonging to that Security World.

You can only replace OCSs that were created by Security Worlds that have the OCS/softcard replacement option enabled. For more information, see OCS and softcard replacement.

Using Operator Card Sets for high availability

If you cannot risk the failure of a smart card, but some keys must remain accessible at all times, you can create a 1/2 OCS.

Use the first card as the working card and store the second card in a completely secure environment. If the working card fails, retrieve the spare second card from storage, and use it until you re-create a new set of 2 cards (see Replacing an Operator Card Set or recovering keys to softcards).

You can only replace OCSs that were created by Security Worlds that have the OCS/softcard replacement option enabled. For more information, see OCS and softcard replacement.

Using persistent Operator Card Sets

If you create a standard (non-persistent) OCS, you can only use the keys protected by that OCS while the last required card of the quorum remains loaded in the card reader. The keys protected by this card are removed from the memory of the hardware security module as soon as the card is removed from the card reader, which provides added security.

If you create a persistent OCS, the keys protected by a card from that OCS persist after the card is removed from the smart card reader.

This enables:

  • The use of the same smart card in several hardware security modules at the same time

  • Several users to load keys onto the same hardware security module at the same time.

The Security World Software maintains strict separation between the keys loaded by each user, and each user only has access to the keys protected by their OCS.

Keys protected by a persistent card are automatically removed from the hardware security module:

  • When the application that loaded the OCS closes the connection to the hardware security module

  • After a time limit that is specified when the card set is created

  • When an application chooses to remove a key

  • When the HSM is cleared. See Manually removing keys from an HSM for more information

  • If there is a power loss to the module, for example, due to power outage.

Some applications automatically remove a key after each use, reloading it only when required. Such applications do not benefit from persistent OCSs. The only way of sharing keys between hardware security modules for such applications is by having multiple smart cards in an OCS.

Although the hardware security module stores the key, the key is only available to the application that loaded it. To use keys protected by this card in another application, you must re-insert the card, and enter its passphrase if it has one. Certain applications only permit one user at a time to log in, in which case any previously loaded persistent OCS used in that application is removed before the user is allowed to log in with a new OCS.

Manually removing keys from an HSM

You can manually remove all keys protected by persistent cards by clearing the hardware security module. For example, you could:

  • Run the command nopclearfail --clear --all

  • Press the Clear button of the hardware security module

  • Turn off power to the hardware security module

Any of these processes removes all keys protected by OCSs from the hardware security module. In such cases, all users of any applications using the hardware security module must log in again.

Persistence is a permanent property of the OCS. You can choose whether or not to make an OCS persistent at the time of its creation, but you cannot change a persistent OCS into a non-persistent OCS, or a non-persistent OCS into a persistent OCS.

A Security World can contain a mix of persistent and non-persistent card sets.

Using passphrases for extra security

You can set individual passphrases for some or all the cards in an OCS.

You can change the passphrase for a card at any time provided that you have access to the card, the existing passphrase, and a hardware security module that belongs to the Security World to which the card belongs. For more information, see Changing card and softcard passphrase.

Some applications do not support the use of passphrases.

Maximum passphrase length

The maximum passphrase length limitation is not applicable to software versions before Security World Software v11.72.

passphrases are limited to a maximum length of 254 characters, when using the following commands:

  • new-world

  • createocs

  • cardpp

  • ppmk

  • racs

Other commands are unaffected.

You can still use and edit existing passphrases that are longer than 254 characters.

Prior to Security World Software v11.72, we set no absolute limit on the length of passphrases, although individual applications may not accept passphrases longer than a specific number of characters. Likewise, the Security World does not impose restrictions on which characters you can use in a passphrase, although some applications may not accept certain characters.

Entrust recommends that your password only contains 7-bit ASCII characters:
A-Z, a-z, 0-9, ! @ # $ % ^ & * - _ + = [ ] { } | \ : ' , . ? / ` ~ " < > ( ) ;

passphrase penalty timer

The HSM maintains a penalty time, measured in seconds and based on the number of failed PINs. Each failed attempt to enter a passphrase adds 4 seconds to the penalty time.

The penalty timer has a 14s penalty threshold, the first 3 failed passphrase verifications do not incur a penalty delay. Before verifying a passphrase, the HSM waits for the current penalty timer to be below 14s. The penalty time decays over time.

A HSM only has a small number of command processing threads, related to the kind of hardware in use (for example, 9 threads on an nShield Solo). Once all of these are waiting for a penalty to expire, any other submitted commands will be forced to wait. This can mean that even if penalty time isn’t large, the total delay experienced by clients may be substantial.

Using softcard-protected keys

If you want to use passphrases to restrict key access but avoid using physical tokens (as required by smart-card protection), you can create a softcard-protected key.

A softcard is a file containing a logical token that you cannot load without a passphrase. You must load the logical token to authorize the loading of any key that is protected by the softcard. Softcard files:

  • Are stored in the /opt/nfast/kmdata/local directory

  • Have names of the form softcard_hash (where hash is the hash of the logical token share).

Softcard-protected keys offer better security than module-protected keys and better availability than OCS-protected keys. However, because softcard-protected keys do not require physical tokens to authorize key-loading, OCS-protected keys offer better security than softcard-protected keys.

The passphrase of a softcard is set when you generate it, and you can use a single softcard to protect multiple keys. Softcards function as persistent 1/1 logical tokens, and after a softcard is loaded, it remains valid for loading its keys until its KeyID is destroyed.

NVRAM key storage

Application keys protected by an nShield HSM are stored in an encrypted format and copied automatically to the remote file system. A hardware security module, such as an nShield HSM, and/or an OCS protects the keys, as described in the preceding sections. You can also store application keys within the nonvolatile memory of a suitable hardware security module.

NVRAM-stored keys are encrypted in exactly the same way as application keys that are protected by the unit. The encrypted application key on the unit is replaced by a file containing the name of the NVRAM file that contains the application key. This file allows applications to use NVRAM-stored keys in the same way as keys stored in the remote file system. You can protect an NVRAM-stored key with either the Security World or an OCS.

NVRAM-stored keys differ from standard application keys only in their storage location. They still require protection by the unit or an OCS.

Use of an NVRAM-stored key is the same as for any other key protected by an nShield HSM Security World.

NVRAM key storage:

  • Offers no additional security benefits above those offered by the standard Security World Software mechanisms

  • Is available for only a limited number of keys

  • Reduces a Security World’s ability to offer load-balancing and recovery

  • Requires backup and recovery procedures in addition to any that you implement for data stored on the client computer.

Do not store keys in NVRAM unless you must do so to satisfy regulatory requirements.

NVRAM key storage was introduced only for those users who must store keys within the physical boundary of a hardware security module to comply with regulatory requirements. NVRAM-stored keys provide no additional security benefits and their use exposes your ACS to increased risk. Storing keys in nonvolatile memory also reduces load-balancing and recovery capabilities. Because of these factors, we recommend you always use standard Security World keys unless explicitly required to use NVRAM-stored keys.

Scalability

A Security World is scalable. You can add multiple hardware security modules to a server and share a Security World across multiple servers. You can also add OCSs and application keys at any time. You do not need to make any decisions about the size of the Security World when you create it.

To share a Security World across multiple clients:

  • Ensure each client has at least one hardware security module configured

  • Copy the Security World data to each client

  • Load the Security World onto the hardware security modules for each client.

If you create cards or keys in a Security World from a client rather than on the hardware security module (using the command line or KeySafe), you must transfer the files from the client to the remote file system, unless the client is already on the same computer as a remote file system.

To provide access to the same keys on every server, you must ensure that all changes to the client data are propagated to the remaining servers. If your clients are part of a cluster, then the tools provided by the cluster should synchronize the data.

There is no risk of an attacker obtaining information by snooping on the network, as the data is only ever decrypted inside a hardware security module. Alternatively, you can maintain copies of the data on different clients.

We provide the rfs-sync command-line utility to synchronize the opt/nfast/kmdata/local directory between a cooperating client and the remote file system it is configured to access. Run rfs-sync whenever a cooperating client is initialized, to retrieve data from the remote file system, and also whenever a client needs to update its local copy of the data (or, if the client has write access, to commit changes to the data).

If you want to make cards or keys which are normally created from the client available from the front panel of the hardware security module, we recommend that you use client cooperation to automate the copying of files to the device.

Load-sharing

If you have more than one hardware security module configured with a client, your applications (that have been integrated with the Security World Software) can make use of the load-sharing features in the Security World Software to share the cryptography between them. Two approaches are supported:

  • API specific load-sharing modes

  • HSM Pool mode: a more generic load-sharing approach for module protected keys introduced with module firmware version 2.65.2.

Some applications may not be able to make use of these features.

HSM Pool mode is supported on all major APIs except Java (i.e. nCipherKM JCA/JCE CSP). When HSM Pool mode is enabled for an API, the application sees the HSMs in the Security World as a single resource pool. A significant benefit is that when a failed HSM is restored to the Security World or a new HSM is added to the Security World, it is automatically added to the resource pool making it available for cryptographic operations without restarting the application (i.e. failback support). The pool of HSMs can be viewed as a single resource using the command enquiry --pool.

Module #1: Not Present indicates that there are no HSMs in the pool.

Robustness

Cryptography must work 24 hours a day, 7 days a week, in a production environment. If something does go wrong, you must be able to recover without compromising your security. A Security World offers all of these features.

Backup and recovery

The Security World data stored on the file system and remote file system of the hardware security module is encrypted using the Security World key.

You should regularly back up the data stored in the Key Management Data directory with your normal backup procedures. It would not matter if an attacker obtained this data because it is worthless without the Security World key, stored in your hardware security module, and the Administrator cards for that Security World.

When you create a Security World, it automatically creates recovery data for the Security World key. As with all host data, this is encrypted with the same type of key as the Security World key. The cryptographic keys that protect this data are stored in the ACS. The keys are split among the cards in the ACS using the same K/N mechanism as for an OCS. The ACS protects several keys that are used for different operations.

The cards in the ACS are only used for recovery and replacement operations and for adding extra hardware security modules to a Security World. At all other times, you must store these cards in a secure environment.

In FIPS 140 Level 3 Security Worlds, the ACS or an OCS is needed to control many operations, including the creation of keys and OCSs.

Replacing a hardware security module

If you have a problem with a hardware security module, you can replace it with another hardware security module of the same type by loading the Security World data on the remote file system onto the replacement device. Alternatively, you may be able to erase the Security World from the device that has the problem, return the device to its default state and then reload the Security World on the same device.

If you have more than one hardware security module configured with a client and you use one of the load-sharing modes identified above, then your client application is resilient to the failure of individual hardware security modules. If you use HSM Pool mode, then an nShield HSM can be replaced and returned to the HSM pool without restarting the client application.

For information about replacing a hardware security module, see Adding or restoring an HSM to the Security World.

Replacing the Administrator Card Set

If you lose one of the smart cards from the ACS, or if the card fails, you must immediately create a replacement set using either:

You should also use the front panel controls of the nShield HSM, racs or the KeySafe Replace Administrator Card Set option to migrate the ACS from standard nShield cards to nShield Remote Administration Cards. Authorization needs to take place using the local slot of an HSM.
When using the racs utility, you cannot redefine the quantities in a K of N relationship for an ACS. The K of N relationship defined in the original ACS persists in the new ACS.

A hardware security module does not store recovery data for the ACS. Provided that K is less than N for the ACS, and you have at least K cards available, a hardware security module can re-create all the keys stored on the device even if the information from other cards is missing.

The loss or failure of one of the smart cards in the ACS means that you must replace the ACS. However, you cannot replace the ACS unless you have:

  • The required number of current cards

  • Access to their passphrases.

Although replacing the ACS deletes the copy of the recovery data on your host, you can still use the old ACS with the old host data, which you may have stored on backup tapes and other hosts. To eliminate any risk this may pose, we recommend erasing the old ACS as soon as you create a new ACS.

Replacing an Operator Card Set or recovering keys to softcards

If you lose an Operator Card, you lose all the keys that are protected by that card. To prevent this, you have the option to store a second copy of the working key that the recovery key protects in a Security World. Similarly, you can recover keys protected by one softcard to another softcard.

The ability to replace an OCS is an option that is enabled by default during Security World creation (see OCS and softcard replacement). You can only disable the OCS replacement option during the Security World creation process. You cannot restore the OCS replacement option, or disable this option, after the creation of the Security World.
You can only recover keys protected by an OCS to another OCS, and not to a softcard. Likewise, you can only recover softcard-protected keys to another softcard, and not to an OCS.

To create new copies of the keys protected by the recovery key on an OCS, you can use either:

  • The front panel controls of the nShield HSM

  • The rocs command-line utility.

It is not possible to recover PKCS #11 keys using the front panel controls of the nShield HSM. You must use the rocs command-line utility.

The security of recovery and replacement data

Replacing OCSs and softcards requires authorization. To prevent the duplication of an OCS or a softcard without your knowledge, the recovery keys are protected by the ACS.

However, there is always some extra risk attached to the storage of any key-recovery or OCS and softcard replacement data. An attacker with the ACS and a copy of the recovery and replacement data could re-create your Security World. If you have some keys that are especially important to protect, you may decide:

  • To issue a new key if you lose the OCS that protects the existing key

  • Turn off the recovery and replacement functions for the Security World or the recovery feature for a specific key.

You can only generate recovery and replacement data when you create the Security World or key. If you choose not to create recovery and replacement data at this point, you cannot add this data later. Similarly, if you choose to create recovery and replacement data when you generate the Security World or key, you cannot remove it securely later.

If you have not allowed recovery and replacement functionality for the Security World, then you cannot recover any key in the Security World (regardless of whether the key itself was created as recoverable).

The recovery data for application keys is kept separate from the recovery data for the Security World key. The Security World always creates recovery data for the Security World key. It is only the recovery of application keys that is optional.

Audit Logging

Use of nShield HSMs in regulated environments where there is a requirement to provably log events in the HSMs can make use of the Audit Logging facility. This facility provides the following features:

  • Tamper evident logging of relevant nCore command execution on the HSM

  • Tied to Security World

  • Traceability of cryptographic key lifetime

    • Authorization for key usage

    • Key loading onto HSM

    • Optional logging of key usage

    • Key destruction

  • Compatibility with syslog and SIEM infrastructures

    • Logs produced in Common Event Format (CEF)

  • Public key log verification without need for generating HSM.

For further information, see Audit Logging.

KeySafe and Security Worlds

KeySafe provides an intuitive and easy-to-use graphical interface for managing Security Worlds. KeySafe manages the Security World and the keys protected by it. For more information about using KeySafe, see Using KeySafe.

Most applications store only their long-term keys in the Security World. Session keys are short term keys generated by the application which are not normally loaded into the Security World.

When you use KeySafe to create cards or keys, the data is written to the Key Management Data directory on the computer on which you run KeySafe. An nShield HSM can only use this data when it is transferred to the remote file system (if it is on a different computer), from where it is loaded automatically onto the unit. For this reason, you may find it most convenient to run KeySafe on the same computer as the remote file system.

Although you may use KeySafe to generate keys, it is your chosen application that actually uses them. You do not need KeySafe to make use of the keys that are protected by the Security World. For example, if you share a Security World across several hardware security modules, you do not need to install KeySafe on every computer. To manage the Security World from a single computer, you can install KeySafe on just that one computer even though you are using the Security World data on other computers.

KeySafe enables you to:

  • Create OCSs

  • List the OCSs in the current Security World

  • Change the passphrase on an Operator Card

  • Remove a lost OCS from a Security World

  • Replace OCSs

  • Erase an Operator Card

  • Add a new key to a Security World

  • Import a key into a Security World

  • List the keys in the current Security World

  • Delete a key from a Security World.

KeySafe does not provide tools to back up and restore the host data or update hardware security module firmware, nor does KeySafe provide tools to synchronize host data between servers. These functions can be performed with your standard system utilities.

In addition to KeySafe, we also supply command-line utilities to manage the Security World; for more information about the supplied utilities, see Supplied utilities. Current versions of these tools can be used interchangeably with the current version of KeySafe.

You can also perform all the tasks available from KeySafe using the front panel controls of the unit, except for adding, importing and deleting keys.

Applications and Security Worlds

A Security World can protect keys for a range of industry standard applications. For details of the applications that are currently supported, visit https://nshieldsupport.entrust.com.

We have produced Integration Guides for many supported applications. The Integration Guides describe how to install and configure an application so that it works with Entrust hardware security modules and Security Worlds.

For more information about the Entrust range of Integration Guides:

The nShield PKCS #11 library and Security Worlds

Many applications use a PKCS (Public Key Cryptography Standard) #11 library to generate and manage cryptographic keys. We have produced an nShield version of the PKCS #11 library that uses the Security World to protect keys.

Enabling a PKCS #11 based application to use nShield hardware key protection involves configuring the application to use the nShield PKCS #11 library.

The nShield PKCS #11 library treats a smart card from an OCS in the current Security World as a PKCS #11 token. The current PKCS #11 standard only supports tokens that are part of a 1-of-N card set, however the nShield PKCS #11 library has vendor specific extensions that support K/N card sets, see nShield PKCS #11 library with the preload utility.

A Security World does not make any distinction between different applications that use the nShield PKCS #11 library. Therefore, you can create a key in one PKCS #11 compliant application and make use of it in a different PKCS #11 compliant application.

Risks

Even the best-designed tools cannot offer security against every risk. Although a Security World can control which user has access to which keys, it cannot prevent a user from using a key fraudulently. For example, although a Security World can determine if a user is authorized to use a particular key, it cannot determine whether the message that is sent with that key is accurate.

A Security World can only manage keys that were created inside the Security World. Keys created outside a Security World, even if they are imported into the Security World, may remain exposed to a security risk.

Most failures of security systems are not the result of inherent flaws in the system, but result from user error. The following basic rules apply to any security system:

  • Keep your smart cards safe.

  • Always obtain smart cards from a trusted source: from Entrust or directly from the smart card manufacturer.

nShield Remote Administration Cards can only be supplied by Entrust.

  • Never insert a smart card used with key management products into a smart card reader you do not trust.

  • Never insert a smart card reader you do not trust into your hardware security module.

  • Never tell anyone your passphrase.

  • Never write down your passphrase.

  • Never use a passphrase that is easy to guess.

If you have any doubts about the security of a key and/or Security World, replace that key and/or Security World with a newly generated one.