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:

Configure the RFS used by your nShield HSM to accept access by cooperating clients.
- For every authenticated client (with write access and K_NETI 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. This can be an IPv4 or IPv6 address.
  - <EEEE-SSSS-NNNN> is the ESN of the nToken used by the client when using a nToken K_NETI key to authenticate itself. When using software-based authentication, it must be empty (that, is "") or can be omitted altogether.
  - <keyhash> is the hash of the software or module K_NETI key used by the client.
- For every unauthenticated client (with write access but without K_NETI authorization), run the command:
  Linux
  
  rfs-setup --gang-client --write-noauth <client_IP_address>
  
  Windows
  
  rfs-setup.exe --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 K_NETI authorization.
  
  To limit a gang-client to read-only, use the --readonly flag.
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 K_NETI 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 K_NETI 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 K_NETI 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 K_NETI 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:

Linux

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

Windows

remote_ip=client_IP_address
remote_esn=keyhash=0000000000000000000000000000000000000000
native_path=%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=%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 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:

an IPv4 address
an IPv6 address, including a link-local IPv6 address
a hostname

rfs-sync

This utility synchronises the opt/nfast/kmdata/local (Linux) or %NFAST_KMDATA%\local (Windows) 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 K_NETI key to use for nToken or software-based authentication of the RFS.

--rfs-esn=ESN

This option 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
an IPv6 address, including a link-local IPv6 address
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.

Linux

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.

Windows

You can set Security World Software-specific environment variables as follows:

Open the System dialog by clicking System in the control panel menu.
Select the Advanced tab and click the Environment Variables button.
To add a variable, click New. Alternatively, to edit an existing variable select an entry in the System Variables list and click Edit.
In the Variable Name field, type or edit the name of the environment variable (for example, NFAST_HOME).
In the Variable Value field, type or edit the value to use.
Click the OK button to set the value, and then click the OK button to close the dialog.
Open the Administrative Tools dialog by clicking the Administrative Tools icon in the Control Panel
Open the Services console by clicking the Services icon.
From the displayed list of services, select the nFast Server icon, and select Restart the service.

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 /opt/nfast/kmdata/config/ (Linux) or %NFAST_KMDATA%\config (Windows), 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:

Save a copy of the configuration file, /opt/nfast/kmdata/config/ (Linux) or %NFAST_KMDATA%\config\config (Windows), so that the configuration can be restored if necessary.
Edit the configuration file to contain the required configuration. (See "Hardserver configuration files" for descriptions of the options in the configuration file.)

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.

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

Windows only

You should use the nt_privpipe_users option to define the name of the user who is allowed to carry out privileged operations, for example, using the nopclearfail utility. See nt_privpipe_users for more information.

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.

Install the module hardware. Refer to the Installation Guide for information on installing nShield hardware.
(Linux) Run the script /opt/nfast/sbin/install.
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. On Windows, this must be a command window with administrative privileges.

Linux

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

Windows

net stop "nfast server"

If the Remote Administration Service is running, you will be warned and given the option of continuing or not.

Similarly, you can start the hardserver on the client, and where applicable the Remote Administration Service, by running the following command. On Windows, this must be a command window with administrative privileges.

Linux

/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

Windows

net start "nfast server"
net start "nfast Remote Administration Service"

On Windows, you can also stop, start, or restart the hardserver, and where applicable the Remote Administration Service, from the Windows Control Panel:

From the Windows Start menu, open the Windows Control Panel.
Double-click Administrative Tools.
Double-click Services.
Locate nFast Server or nFast Remote Administration Service in the list of services, and from the Action menu, select Stop, Start, or Restart as required.

The nFast Remote Administration Service, where applicable, is dependent on the nFast Server so should be started or restarted after the nFast Server.

Configure the hardserver to export the module for guest VM usage

This feature is not available on nToken models, but works with all other local HSM models. If you previously configured this feature using rserverperm, you may wish to update to using these instructions using the config file to specify the permissions for guest VMs to access the HSMs in a persistent manner.

Configure the host hardserver to permit guest VM hardservers to share access to the module:

Edit the host hardserver config file NFAST_KMDATA/config/config (Linux) or NFAST_KMDATA\config\config (Windows).

Add a new entry in the hs_clients section to contain the details of the client to be added.

If your config file does not already contain a hs_clients section you may add it yourself with a line containing only [hs_clients].

The addr and clientperm fields are required for each client, and keyhash is recommended for authentication: :

[hs_clients]
addr=<client_IP>
clientperm=permission_type
keyhash=software_keyhash

Where:

<client_IP> can be either the IP address of the guest VM or any of 0.0.0.0, ::, or blank if the host hardserver is to accept clients identified by their key hash instead of their IP address.

If you set both the <client_IP> field (the guest VM’s IP address) and the key hash, client connections will be restricted based on both values.

permission_type defines the type of commands the client can issue (unpriv for unprivileged only, priv for privileged or priv_lowport for privileged connections restricted to low port numbers).

software_keyhash is the hash of the software-generated authentication key that the client should authenticate itself with.

If there is more than one client being configured, the fields for each client must be separated by line consisting of one or more hyphens (e.g. ----).

It is recommended that the firewall on the host be configured so that only connections from intended network interfaces can be made to the host hardserver on its Impath port (port 9004 by default).

Load the updated configuration file in the host hardserver. To do this, run the following command:
```
hsc_nethsmexports
```
This command only needs to be run when the config is added or modified. The permissions for guest VMs will be re-applied automatically when the host hardserver is restarted.

Configure the hardserver in the guest VM to enroll to the host hardserver with an IP address using the virtual switch. Enter the following command for each guest hardserver that should have unprivileged access:
```
nethsmenroll <host-hardserver-ip>
```
Run the following command if the guest hardserver should have privileged access for mode change and administration:

Not all administration operations will be permitted from a privileged guest VM, such as firmware updates, which must be carried out from the host.
```
nethsmenroll -p <host-hardserver-ip>
```
You will be asked to confirm your entries. You should then see the following message:
```
OK configuring hardserver's nethsm imports
```
Confirm the connection from the guest VMs by running enquiry.