Client Software and module configuration

To find out the ESN and the hash of the K_NETI key for a given IP address, use the anonkneti command-line utility. A manual double‑check is recommended for security.

The IP address could be one of the following:

This utility synchronises the kmdata between a cooperating client and the remote file system it is configured to access. It should be run when a cooperating client is initialised in order 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.

A remote HSM is an HSM that is not connected directly to the host computer but with which the hardserver can communicate. It can be one of the following:

You configure the hardserver’s communications with remote HSMs in the server_remotecomms section of the hardserver configuration file. This section defines the port on which the hardserver listens for communications from remote HSMs. You need to edit this section only if the default port (9004) is not available.

For detailed descriptions of the options in this section, see server_remotecomms.

For information about configuring the Remote Operator feature (Remote Operator slots), as opposed to remote HSMs, see Remote Operator.

You configure the hardserver’s settings in the server_settings section of the configuration file.

This section defines how connections and hardserver logging are handled. These settings can be changed while the hardserver is running.

For detailed descriptions of the options in this section, see server_settings.

You configure the hardserver performance settings in the server_performance section of the configuration file.

This section determines whether multi-threaded performance scaling is enabled or not. By default, scaling is not enabled. Any changes you make to the settings in this section do not take effect until after you restart the hardserver.

For detailed descriptions of the options in this section, see server_performance.

You configure the HSM’s settings in the module_settings section of the configuration file.

This section defines the settings for the HSM that can be changed while the hardserver is running.

For detailed descriptions of the options in this section, see module_settings.

You configure the hardserver’s start‑up settings in the server_startup section of the configuration file.

This section defines the sockets and ports used by the hardserver. You need to change this section only if the default ports for privileged or unprivileged connections (9000 and 9001) are not available.

For detailed descriptions of the options in this section, see server_startup.

You configure the hardserver to load SEE machines on start-up in the load_seemachine section of the configuration file. The SEE Activation feature must be enabled on the HSM, as described in Enabling optional features.

This section defines the SEE machines and optional user data to be loaded, as well any other applications to be run in order to initialize the machine after it is loaded.

For detailed descriptions of the options in this section, see load_seemachine.

For information about SEE machines, see CodeSafe applications.

You configure Remote Operator slots in the slot_imports and slot_exports sections of the configuration file. These sections define the slots that are imported to or exported from the HSM. This applies to the Remote Operator feature only.

For detailed descriptions of the options in these sections, see slot_imports and slot_exports.

The Remote Operator feature must be enabled on the HSM, as described in Enabling optional features.

Each client’s remote file system is defined separately in the remote_file_system section of the configuration file with a list of HSMs that are allowed to access the file system on the given client. For information about setting up client cooperation, see Setting up client cooperation.

As a reference, for detailed descriptions of the options in this section, see remote_file_system.

You configure the hardserver’s audit logging in the auditlog_settings section of the configuration file.

This section defines the host IP address and port used as the destination for the syslog output of the audit logging capability. Optionally, the audit logging messages can be copied to the hardserver’s log file.

For further details see Audit Logging.

Cryptography based on elliptic curves relies on the mathematics of random elliptic curve elements. It offers better performance for an equivalent key length than either RSA or Diffie-Hellman public key systems. Using RSA or Diffie-Hellman to protect 128-bit AES keys requires a key of at least 3072 bits. The equivalent key size for elliptic curves is only 256 bits. Using a smaller key reduces storage and transmission requirements.

Elliptic curve cryptography is endorsed by the US National Security Agency and NIST (the National Institute of Standards and Technology), and by standardization bodies including ANSI, IEEE and ISO.

nShield modules incorporate hardware that supports elliptic curve operations for ECDH (Elliptic curve Diffie‑Hellman) and ECDSA (Elliptic Curve Digital Signature Algorithm) keys.

All nShield HSMs require specific activation to utilize the elliptic curve features. HSMs use an activator smart card to enable this feature. Refer to [EnableFeaturesWithSmartCard] for instructions on how to enable the EC feature. Additionally it is possible to activate the elliptic curve feature without a physical smart card. In this case the certificate details can be provided by email and entered locally. Refer to [EnableFeaturesWithoutSmartCard] Contact Sales if you require an EC activation.

nShield modules with elliptic curve activation support MQV (Menezes-Qu-Vanstone) modes.

The following table details the range of nShield HSMs and the level of elliptic curve support that they offer.

¹Accessed via nCore, PKCS#11 and JCE APIs.

²Both Prime and Binary named curves are supported. Refer to Named Curves, below, which lists the most commonly supported elliptic curves.

³Offload acceleration refers to offloading the elliptic curve operation from the main CPU for dedicated EC hardware acceleration.

⁴Binary curves are supported, but are not hardware offload accelerated.

⁵Brainpool curves are supported as named curves via nCore, PKCS#11 and JCE only.

¹Java elliptic curve functionality is fully supported by the nShield security provider, nCipherKM. There is also the option to use the Sun/IBM PKCS #11 Provider with nCipherKM configured to use the nShield PKCS#11 library.

To demonstrate the accelerated performance of elliptic signing and verify operations, run the perfcheck utility. See perfcheck: performance measurement checking tool.

This table lists the supported named curves that are pre-coded in nShield module firmware.

nShield modules also allow the entry of custom elliptic curves which are not pre-coded in firmware. If the curve is Prime, it may benefit from hardware acceleration if supported by the nShield HSM (see nShield software / API support required to use elliptic curve functions, above).

Custom curves are supported by nCore and PKCS #11 APIs.

For more information on how to use elliptic curves, see the following sections:

The SEE is a unique secure execution environment. The SEE features available to you are:

For more information about the SEE, see the CodeSafe Developer Guide.

Many Entrust customers keep critical servers in a physically secure and remote location. The Security World infrastructure, however, often requires the physical presence of an operator to perform tasks such as inserting cards. Remote Operator enables these customers to remotely manage servers running Security World Software using a secure nShield communications protocol over IP networks.

The Remote Operator feature must be enabled on the module installed in the remote server. Remote Operator cannot be enabled remotely on an unattended module.

For more information about using Remote Operator, see Remote Operator.

For v12 and later, Entrust recommends that you use Remote Administration, which is more flexible than the Remote Operator functionality.

ISS, also called Foreign Token Open (FTO) allows data to be read to and written from ISO 7816 compliant smart cards in a manner prescribed by ISO7816-4. ISS allows you to develop and deploy a security system that can make full use of ISO 7816 compliant smart cards from any manufacturer.

This feature enables the following mechanisms:

Utilise a faster alternative for Random Number Generation (RNG) for Elliptic Curve Digital Signature Algorithm (ECDSA). This feature is applicable for Solo XC / Connect XC modules only.

The faster performance, comparable with V12.40 performance, is achieved by the RNG part of ECDSA being done on the NXP C291 Crypto Coprocessor.

This implementation of ECDSA uses an RNG that is not within scope for the Edge certifications and for this reason it will not be used when the HSM is in a fips-140-2-level-3 or common-criteria-cmts Security World (regardless of the feature bit setting).

The Feature Enable Tool can be used to view the status of modules connected to the host or to confirm that a feature has been successfully enabled on all modules connected to the host. To view the status of features, run the tool without a smart card.

When it is launched, the Feature Enable Tool automatically scans the smart card readers of all modules attached to a host computer for any Feature Enabling smart cards present in the smart card readers, including imported Remote Operator slots and Dynamic Slots. However, feature enable smart cards do not work in Dynamic Slots.

To enable a new feature with a Feature Enabling smart card from Entrust:

A message is displayed if the features are enabled successfully. If you do not see this message confirming a successful upgrade, see Enabling features without a smart card.

The Feature Enable Tool can also obtain the Feature Enabling Certificate information supplied by Entrust from a file or from the keyboard.

When you run the Feature Enable Tool without a Feature Enabling smart card in an HSM slot, a message similar to the following is displayed. There is a line for the features on each module, and a list of options.

In this example, only one module (ESN 4748-494A-4B4C) is attached to the host.

Modules are identified in two ways:

You can obtain the ModuleID 's and serial numbers of all your modules by running the enquiry command-line utility.

The serial number is a unique 12-digit number that is permanently encoded into each module. Quote this number in any correspondence with Support.

If you have a module installed, you can add further modules without reinstalling the server software.

However, we recommend that you always upgrade to the latest server software and upgrade the firmware in existing modules to the latest firmware.

The Security World Software supports fail-over: if a module fails, its processing can be transferred automatically to another module provided the necessary keys have been loaded. Depending on the mode of failure, however, the underlying bus and operating system may not be able to recover and continue operating with the remaining devices.

To maximize uptime, we recommend that you fit any additional nShield modules for failover on a bus that is physically separate from that of the primary modules.