Security World infrastructure

The Security World infrastructure provides secure life-cycle management of cryptographic keys. It 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.

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

    Store the ACS in a secure location, separate from the HSMs, when you are not using them to provide authorization for administrative tasks.

  • 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

The Security World technology is designed 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 ACS to control access to recovery and replacement functionality. It can also use one or more 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).

Remote Administration

Remote Administration is a collection of features that allow you to configure and operate HSMs without being physically present, including creating and presenting ACS and OCS cards.

For more information, refer to Remote Administration v13.6.5 User Guide.

Client cooperation

The client cooperation feature allows nShield HSM host computers to automatically update the Security World and key data stored on a remote file system (RFS). For more information, see Client cooperation.

NIST SP800-131A

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

Compatibility issues (network-attached HSMs)

In order to comply with the latest encryption standards, Entrust has adopted an enhanced NIST SP800-131A compliant encryption protocol between nShield network-attached 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 (nShield "XC" HSMs)

The nShield Connect XC and Solo XC 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.

See Security World keys for more information.

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 or servers:

Network-attached HSMs

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

PCIe and USB HSMs

  • Ensure each server has at least one hardware security module fitted

  • Copy the host data to each server, or make it available on a shared disk

  • Use the recovery and replacement data with the ACS to load the required cryptographic keys securely onto every hardware security module.

If you create cards or keys in a Security World from a client rather than on the hardware security module (using the command line, the Microsoft CSP wizard, 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:

  • Network-attached HSMs
    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.

  • PCIe and USB HSMs
    To provide access to the same keys on every server, you must ensure that all changes to the data are propagated to the remaining servers. If your servers are part of a cluster, then the tools provided by the cluster should synchronize the data. If the servers are connected by a network, then they could all access the same copy of 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 (network-attached HSMs) or servers (PCIE and USB HSMs).

You can configure the host computer of an nShield PCIe or USB HSM to:

  • Access a Remote File System (RFS) as used by an nShield HSM.

  • Share Security World and key data stored in /opt/nfast/kmdata/local (Linux) or %NFAST_KMDATA%\local (Windows).

Client hardware security modules that access data in this way are described as cooperating clients. For more information, see Client cooperation.

Use the rfs-sync command-line utility to synchronize opt/nfast/kmdata/local (Linux) or %NFAST_KMDATA%\local (Windows) 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 a network-attached HSM, 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 on your system or 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.

The following 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 in 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 as failback support, that is, without restarting the application. The pool of HSMs can be viewed as a single resource using the command enquiry --pool.

For certain situations, enquiry and nfkminfo fields for modules in the pool have a particular meaning:

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

  • hardware status: network error on a module indicates that the Security World has changed, for example another HSM has been removed from the Security World. Run the same utility (enquiry or nfkminfo) directly on the module to obtain the hardware status for the module.

Audit Logging

The Audit Logging facility can be enabled on nShield HSMs where there is a requirement to provably log events. 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

  • Public key log verification

The format of the audit logs depends on the version of firmware loaded on the HSMs.

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.

In addition to KeySafe, we also supply command-line utilities to manage the Security World; for more information about the supplied utilities, see nShield v13.6.5 Utilities Reference. 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, except for adding, importing and deleting keys, using the front panel controls of the network-attached HSMs.

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

Do not use PKCS #11 to perform any task that requires an Administrator Card. Use the equivalent nShield utilities instead.

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