Client Software and module configuration

This chapter describes software and module configuration tasks that you can choose to perform after the initial installation of Security World Software and hardware. See the Installation Guide for more information about hardware and software installation.

You must determine whether particular configuration options are necessary or appropriate for your installation. The additional configuration options described in this chapter can be performed either before or after the creation of a Security World (as described in Creating a Security World) and an OCS (as described in "Creating Operator Card Sets (OCSs).

About user privileges

Cryptographic security does not depend on controlling user privileges or access but maintaining the integrity of your system from both deliberate or accidental acts can be enhanced by appropriate use of (OS) user privileges.

Setting up client cooperation

You can allow an nShield HSM to automatically access the remote file system (RFS) belonging to another nShield HSM and share the Security World and key data stored in the Key Management Data directory. Client hardware security modules that access data in this way are described as cooperating clients.

To configure client cooperation for hardware security modules that are not nShield HSMs:

  1. Configure the RFS used by your nShield HSM to accept access by cooperating clients.

    • For every authenticated client (with write access and KNETI authorization) that needs to be a client of this remote file system, run the command:

      rfs-setup --gang-client <client_IP_address> <EEEE-SSSS-NNNN> <keyhash>

      In this command:

      • <client_IP_address> is the IP address of the client.

      • <EEEE-SSSS-NNNN> is the ESN of the nToken used by the client when using a nToken KNETI key to authenticate itself. When using software-based authentication, it must be empty (i.e. "") or can be omitted altogether.

      • <keyhash> is the hash of the software or module KNETI key used by the client.

    • For every unauthenticated client (with write access but without KNETI authorization), run the command:

      rfs-setup --gang-client --write-noauth client_IP_address
      The --write-noauth option should be used only if you believe your network is secure. This option allows the client you are configuring to access the RFS without KNETI authorization.

      To limit a gang-client to read-only, use the --readonly flag.

  2. On each client that is to be a cooperating client, you must run the rfs-sync command-line utility with appropriate options:

    • for clients using a software KNETI key to authenticate themselves to the RFS, run the command with the default options:

      rfs-sync --setup <RFS_IP_ADDRESS>

    • for clients using a module KNETI key to authenticate themselves to the RFS, run the command:

      rfs-sync --setup --authenticate --module=<MODULE> <RFS_IP_ADDRESS>

      In this command:

      • <RFS_IP_ADDRESS> is the IP address of the RFS.

      • <MODULE> is the local module to use for authentication.

    • for clients to authenticate the RFS using software-based authentication, use the --rfs-hkneti=HKNETI option to specify the hash of the software KNETI key of the RFS.

    • for clients to authenticate the RFS using nToken authentication, use the --rfs-esn=ESN and --rfs-hkneti=HKNETI options to specify the ESN and hash of the KNETI key of the nToken installed in the RFS.

The rfs-sync utility uses lock files to ensure that updates are made in a consistent fashion. If an rfs-sync --commit operation (the operation that writes data to the remote file system) fails due to a crash or other problem, it is possible for a lock file to be left behind. This would cause all subsequent operations to fail with a lock time-out error.

The rfs-sync utility has options for querying the current state of the lock file, and for deleting the lock file; however, we recommend that you do not use these options unless they are necessary to resolve this problem. Clients without write access cannot delete the lock file.

For more information about the rfs-sync utility, see rfs-sync.

To remove a cooperating client so the RFS no longer recognizes it, you must:

  • Know the IP address of the cooperating client that you want to remove

  • Manually update the remote_file_system section of the hardserver configuration file by removing the following entries for that particular client:

    remote_ip=<client_IP_address>
remote_esn=keyhash=0000000000000000000000000000000000000000
native_path=/opt/nfast/kmdata/local
volume=kmdata-local
allow_read=yes
allow_write=yes
allow_list=yes
is_directory=yes
is_text=no

    and

    remote_ip=<client_IP_address>
remote_esn=keyhash=0000000000000000000000000000000000000000
native_path=/opt/nfast/kmdata/local/sync-store/
volume=kmdata-backup
allow_read=yes
allow_write=yes
allow_list=yes
is_directory=yes
is_text=no

Useful utilities

anonkneti

To find out the ESN and the hash of the KNETI 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:

  • An IPv4 address, for example 123.456.789.123.

  • An IPv6 address, for example fc00::1.

  • A link-local IPv6 address, for example fe80::1%eth0.

  • A hostname.

rfs-sync

This utility synchronises the opt/nfast/kmdata/local folder 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.

Usage
rfs-sync [-U|--update] [-c|--commit] [-s|--show] [--remove] [--setup [setup_options] ip_address]
Options
-U|--update

These options update local key-management data from the remote file system.

If a cooperating client has keys in its kmdata/local directory that are also on the remote file system, if these keys are deleted from the remote file system and then rfs-sync --update is run on the client, these keys remain on the client until manually removed.
-c|--commit

These options commit local key-management data changes to the remote file system, and update the client from the remote file system.

-s|--show

These options display the current synchronisation configuration.

--setup

This option sets up a new synchronisation configuration. Specifics of the configuration can be altered using setup_options as follows:

-a|--authenticate

This set-up option specifies the use of a module KNETI key to authenticate this client to the RFS. By default the software KNETI key is used instead.

-m|--module=module

This option selects the local module to use for authentication. The default is 1. This option can only be used with the --authenticate option.

-p|--port=port

These options specify the port on which to connect to the remote file system. The default is 9004.

--rfs-hkneti=HNETI

This option specifies the hash of the KNETI key to use for nToken or software-based authentication of the RFS.

--rfs-esn=ESN

This options specifes the ESN of the nToken to use for authentication of the RFS.

ip_address

This option specifies the IP address of the remote file system, which could be one of the following:

  • An IPv4 address, for example 123.456.789.123.

  • An IPv6 address, for example fc00::1.

  • A link-local IPv6 address, for example fe80::1%eth0.

  • A hostname.

--remove

This option removes the synchronisation configuration.

A client can use rfs-sync --show to display the current configuration, or rfs-sync --remove to revert to a standalone configuration. Reverting to a standalone configuration leaves the current contents of the Key Management Data directory in place.

The rfs-sync command also has additional administrative options for examining and removing lock files that have been left behind by failed rfs-sync --commit operations. Using the --who-has-lock option displays the task ID of the lock owner. As a last resort, you can use the rfs-sync command-line utility to remove lock files. In such a case, the --kill-lock option forcibly removes the lock file.

The lock file can also be removed via menu item 3-3-2, Remove RFS Lock: this executes the rfs-sync --kill-lock command.

Setting environmental variables

This section describes how to set Security World Software-specific environment variables. You can find detailed information about the environment variables used by Security World Software in Environment variables. Environment variables

You can set Security World Software-specific environment variables in the file /etc/nfast.conf. This file is not created by the installation process: you must create it yourself. /etc/nfast.conf is executed by the start-up scripts of nShield HSM services as the root user. This file should only contain shell commands that can safely be run in this context. /etc/nfast.conf should be created with access permissions that allow only the root user to write to the file.

Ensure that all variables are exported as well as set.

Logging and debugging

The Security World Software generates logging information that is configured through a set of four environment variables:

  • NFLOG_FILE

  • NFLOG_SEVERITY

  • NFLOG_DETAIL

  • NFLOG_CATEGORIES

If none of these logging environment variables are set, the default behavior is to log nothing, unless this is overridden by any individual library. If any of the four logging variables are set, all unset variables are given default values.

Detailed information about controlling logging information by means of these environment variables is supplied in Logging, debugging, and diagnostics.

Some components of the Security World Software generate separate debugging information which you can manage differently. If you are setting up the client to develop software that uses it, you should configure debugging before commencing software development.

Configuring Java support for KeySafe

To use KeySafe, follow the instructions in Using KeySafe.

Configuring the hardserver

The hardserver handles secure transactions between the HSMs connected to the host computer and applications that run on the host computer. In addition, the hardserver, for example:

  • Controls any Remote Operator slots that the HSM uses

  • Loads any SEE (Secure Execution Engine) machines that are to run on the HSM

  • Enables Remote Administration and provides the communication channel between the Remote Administration Service and the HSM

The hardserver can handle transactions for multiple HSMs. This does not require configuration of the hardserver. For more information, see Using multiple modules.

The hardserver must be configured to control:

  • The way the hardserver communicates with remote HSMs

  • The way the hardserver communicates with local HSMs

  • The import and export of Remote Operator slots

  • The loading of SEE machines on to the HSM when the hardserver starts up

  • The number of Dynamic Slots available on the HSM

  • The port used to connect to the Remote Administration Service

  • Whether a Dynamic Slot needs to be exchanged with slot 0 of an HSM

  • Timeout values for nShield Remote Administration Card presence assurance

  • Configuring the audit logging destination.

The hardserver configuration file defines the configuration of the hardserver. By default, it is stored in the [/opt/nfast/kmdata/config/ directory, and a default version of this file is created when the Security World Software is installed. See Overview of hardserver configuration file sections for an overview of the hardserver configuration file, and see "Hardserver configuration files" for detailed information about the various options available through it.

In some previous releases of the Security World Software, hardserver configuration was controlled by environment variables. The use of these variables has been deprecated. If any of these environment variables are still set, they override the settings in the configuration file.

You must load the configuration file for the changes to the configuration to take effect.

To configure the hardserver, follow these steps:

  1. Save a copy of the configuration file /opt/nfast/kmdata/config/ so that the configuration can be restored if necessary.

  2. Edit the configuration file /opt/nfast/kmdata/config/ to contain the required configuration. (See "Hardserver configuration files" for descriptions of the options in the configuration file.)

  3. Run the cfg-reread command-line utility to load the new configuration.

    If you changed the server_startup section of the hardserver configuration file, you must restart the hardserver instead of running cfg-reread. For more information, see Stopping and restarting the hardserver.

  4. Test that the hardserver is configured correctly by running the enquiry command-line utility.

    Check that an HSM with the correct characteristics appears in the output.

  5. Test that the client has access to the Security World data by running the nfkminfo command-line utility.

    Check that an HSM with the correct ESN appears in the output and has the state 0x2 Usable.

Overview of hardserver configuration file sections

Configuring remote HSM connections

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:

  • A network-connected nShield HSM that is configured to use the host computer as a client computer

  • An HSM to which an attended Remote Operator slot is imported for the hardserver’s unattended local HSM

    (Remote Operator feature only).

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.

Hardserver settings

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.

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

HSM settings

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.

Hardserver start-up 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.

SEE machines

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.

Remote Operator slots

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.

Remote file system

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.

The remote_file_system section is updated automatically when the rfs-setup utility is run. Do not edit the remote_file_system section manually.

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

Audit logging

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.

The hardserver needs to be restarted for these settings to take effect.

Using multiple modules

The hardserver can communicate with multiple modules connected to the host. By default, the server accepts requests from applications and submits each request to the first available module. The server can share load across buses, which includes the ability to share load across more than one module.

If your application is multi-threaded, you can add additional modules and expect performance to increase proportionally until you reach the point where cryptography no longer forms a bottleneck in the system.

Identifying modules

Modules are identified in two ways:

  • By serial number

  • By ModuleID.

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

Electronic Serial Number (ESN)

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

ModuleID

The ModuleID is an integer assigned to the module by the server when it starts. The first module it finds is given a ModuleID of 1, the next is given a ModuleID of 2, and this pattern of assigning ModuleID numbers continues for additional modules.

The order in which buses are searched and the order of modules on a bus depends on the exact configuration of the host. If you add or remove a module, this can change the allocation of ModuleIDs to all the modules on your system.

You can use the enquiry command-line utility to identify the PCI bus and slot number associated with a module.

All commands sent to nShield modules require a ModuleID. Many Security World Software commands, including all acceleration-only commands, can be called with a ModuleID of 0. Such a call causes the hardserver to send the command to the first available module. If you purchased a developer kit, you can refer to the developer documentation for information about the commands that are available on nShield modules.

In general, the hardserver determines which modules can perform a given command. If no module contains all the objects that are referred to in a given command, the server returns an error status.

However, some key-management operations must be performed together on the same module. In such cases, your application must specify the ModuleID.

To be able to share OCSs and keys between modules, the modules must be in the same Security World.

Adding a module

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.

  1. Install the module hardware. Refer to the Installation Guide for information on installing nShield hardware.

  1. Run the script /opt/nfast/sbin/install.

  2. Add the module to the Security World. Refer to Adding or restoring an HSM to the Security World.

Module fail-over

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.

Stopping and restarting the hardserver

If necessary, you can stop the hardserver on the client, and where applicable the Remote Administration Service, by running the following command:

/opt/nfast/sbin/init.d-ncipher stop

Similarly, you can start the hardserver on the client, and where applicable the Remote Administration Service, by running the following command

/opt/nfast/sbin/init.d-ncipher start

You can also restart the hardserver on the client, and where applicable the Remote Administration Service, by running the following command:

/opt/nfast/sbin/init.d-ncipher restart