Commissioning

For use with the Remote Administration Client, Entrust supplies and strongly recommends the use of the nShield Trusted Verification Device (TVD). This specialized smart card reader allows the card holder to securely confirm the Electronic Serial Number (ESN) of the HSM to which they want to connect, using the TVD display.

The list of valid ESNs must be provided out-of-band for manual verification of the nShield HSM target. This list must be kept securely and made available only to authorized cardholders.

TVD users must be made aware that:

The mode switch on the back panel controls the mode of the module. See the User Guide for the HSM for more information about checking and changing the mode of an HSM.

You can set the physical mode override jumper switch on the circuit board of the nShield Solo to the ON position, to prevent accidental operation of the Mode switch. If this override jumper switch is on, the nShield Solo ignores the position of the Mode switch.

When setting up your firewall, you should make sure that the port settings are compatible with the HSMs and allow access to the system components you are using. See the Installation Guide for default port numbers. Only open up the ports you require and limit the IP addresses supported on those ports to the ones required.

In the development of the nShield SNMP agent, we have used open-source tools that are part of the NET-SNMP project. More information on SNMP in general, and the data structures used to support SNMP installations, is available from the NET-SNMP project Web site: http://net-snmp.sourceforge.net/.

This site includes some support information and offers access to discussion email lists. You can use the discussion lists to monitor subjects that might affect the operation or security of the nShield SNMP agent or command-line utilities.

You should discuss any enquiries arising from information on the NET-SNMP Web site with Entrust nShield Support before posting potentially sensitive information to the NET-SNMP Web site.

The nShield SNMP Agent allows other computers on the network to connect to it and make requests for information. The nShield agent is based on the NET-SNMP code base, which has been tested but not fully reviewed by Entrust. We strongly recommend that you deploy the nShield SNMP agent only on a private network or a network protected from the global Internet by an appropriate firewall.

The default nShield SNMP installation allows read-only access to the Management Information Base (MIB) with any community string. There is no default write access to any part of the MIB. The few Object Identifiers (OIDs) in the nShield MIB that are writable (should write access be enabled) specify ephemerally how the SNMP agent presents certain information. No software or HSM configuration changes can be made through the SNMP agent.

Every effort has been taken to ensure the confidentiality of cryptographic keys even when the SNMP agent is enabled. The SNMP agent runs as a client application of the HSM, and all the security controls provided and enforced by the HSM are in effect. In particular, the nShield module is designed to prevent the theft of keys even if the security of the host system is compromised, provided that the Administrator Cards are used only with trusted hosts.

We strongly advise that you set up suitable access controls in the snmpd.conf file. It is also recommended that a firewall is used to protect the agent, and the information it can return.

When configuring the nShield SNMP agent, make sure that you protect the configuration files if you are storing sensitive information in them.

Set the RTC using an accurate trusted local time source as part of the commissioning process. This must be set as early in the commissioning process as possible. The correct time must be set to support hardserver and audit logging.

Set the nShield Connect date and time using an accurate trusted local time source as part of the commissioning process. This must be set as early in the commissioning process as possible. The correct time must be set to support system, hardserver and tamper logging.

The nShield Connect supports a Network Time Protocol (NTP) client which if activated will synchronize the nShield Connect time to an NTP enabled time source.

To further mitigate attacks on NTP the synchronized time should be compared against the Solo RTC time (including within the Connect) at regular intervals to ensure that a similar time, within a margin of error, is reported. Significant discrepancies should be investigated.

To identify NTP server failures or attacks, NTP servers should be monitored for availability on the network and an alert generated if the NTP server is unavailable.

Set the host date and time using an accurate trusted local time source as part of the commissioning process. This must be set as early in the commissioning process as possible. The correct time must be set to support hardserver logging.

The nShield Connect has two Ethernet interfaces. Depending on the network configuration guidelines in the customer’s security policy, separated networks can be supported by assigning one interface an internal IP address, and the other an external IP address. When these Ethernet interfaces do not need to be used separately, they can be bonded to provide either redundancy or higher throughput. The Connect Installation Guide provides more information on configuring Ethernet bonding. If an Ethernet interface is not used, disable it.

By default, the hardserver listens on all of its interfaces. However, you can alter the hardserver settings. Altering the hardserver settings would prove necessary if, for example, you wanted to only connect one of the Ethernet interfaces to external hosts

Ensure that you have configured the Ethernet interfaces on the HSM before attempting to configure the hardserver. It is recommended that you do not allow the hardserver to listen on any interface that is connected to the public Internet, as this could expose the HSM to attack from network based attackers.

The nethsm_settings section in the client host hardserver config file defines settings for Impath resilience that are specific to the nShield Connect. By default Impath resilience is turned on with a timeout of 3,600 seconds (one hour). This enables clients to reconnect in the event of network errors. An associated time-out can be configured to state when an Impath resilience session will expire after which all previously loaded objects must be reloaded. Your threat analysis of your environment, and knowledge of the reliability of your network, will determine if Impath resilience needs to be enabled, and what timeout should be set (e.g. a 5 minute Impath resilience timeout could give a reasonable trade-off between security and resilience to transient network issues).

The RFS contains the master copy of the Security World data for backup purposes. You should regularly back up the entire contents of the RFS as it is required to restore an nShield Connect or its replacement, to the current state in the case of failure.

To setup, the RFS requires certain information about the nShield Connect:

Even with a trusted network, it is recommended that the ESN and KNETI reported by anonkneti be checked independently using the nShield Connect front panel, or from the serial console. If the network is untrusted, obtaining the ESN and KNETI information directly from the nShield Connect front panel is essential. This information is then used in the rfs-setup command to create the RFS. Specifically the --write-noauth option should not be used with the rfs-setup command over insecure networks as this does not authenticate the RFS which could give rise to a masquerade attack.

It is strongly recommended that secure authentication is enabled to the RFS. This will either be a Front Panel or serial console option. To enable this option, the ESN and KNETI hash of the RFS must be obtained. Enabling 'secure authentication' to the RFS is described in section Configuring the Remote File System (RFS) in the nShield Connect User Guide or in the nShield 5c User Guide.

The module (hardserver) configuration file can be used to enable:

A utility – nethsmenroll is used to edit the configuration file of the client hardserver to add an nShield Connect. It is strongly recommended that the utility is used with the ESN and HKNETI options filled in. This content must be obtained from the nShield Connect’s front panel. An alternative method for using nethsmenroll is to omit the ESN and HKNETI parameters. In this situation, nethsmenroll will attempt to recover ESN and HKNETI parameters from the nShield Connect and then prompts the client for confirmation that the values are correct. Confirmation is achieved by verifying the ESN and HKNETI displayed on the front panel of the nShield Connect are the same values as those recovered by nesthsmenroll. This step must be completed when enrolling clients over a network to verify that the client is communicating with the valid, identified nShield Connect. Once the values are confirmed they are automatically written to the configuration file.

The nethsmenroll option –no-hkneti-confirmation actions an associated utility – anonkneti to recover the ESN and HKNETI of an nShield Connect without confirmation. The utility anonkneti can also be used on its own. Unless deployed on a local, completely secure network, this option/utility should not be used as it could not mitigate the threat of an attacker inserting a rogue device without being noticed.

If an nToken is installed in a client, it can be used to both generate and protect a key that is then used for the Impath communication between the nShield Connect and the client. A dedicated hardware protected key is used at both ends of the Impath as a result. The nToken mitigates threats occurring in the client environment including vulnerabilities arising in generic software and operating systems.

When configuring an nShield Connect to use a client containing an nToken, you must obtain the nToken key hash from the client and then view the client’s configuration from the front panel of the nShield Connect and verify that the nToken key hash displayed there matches the nToken key hash obtained from the client. This makes sure that the correct nToken will be enrolled.

The serial console on the nShield Connect is enabled by default and can be disabled from the front panel. Regardless of the serial console being enabled or disabled, factory resetting an nShield Connect will re-enable the serial console. Disable the serial console if serial console connectivity is not required to prevent unauthorized access attempts. This is important as the serial console is shipped with a known default password that could allow an unauthorized access if the serial console is enabled and the default password is not changed.

The Serial Console requires a serial cable connection to a serial port aggregator which in turn is connected to an Administrator console via a communication channel. The administrator must ensure that a secure channel is correctly setup between their console and an authenticated serial port aggregator. Physical access controls should be deployed to protect the following from unauthorized access attempts:

Logical access controls should be deployed to protect the following from unauthorized access attempts:

All passwords should be protected from unauthorized access or viewing.

The username for accessing the serial console is cli and the default password is admin. On first login you will be prompted to change the password for the cli user. The minimum length of the new password is 5 characters. The functionality does not enforce strong passwords therefore these should be manually implemented – see the relevant password guidance contained in Access Control Chapter sections:

Equipment that supports the serial console connection must be maintained with the latest software and patches e.g. serial port aggregator, administrator console.

Once the time has been set, your logging requirements should be identified and implemented.

Logs are available on nShield platforms:

¹ The netsnmp daemon log is produced by the client.

Only the Audit Log originates in the nShield Solo HSM (including the nShield Solo HSM installed in every nShield Connect). It uses a cryptographic mechanism to assure the integrity of the audit log distributed to third party SIEM Collectors.

The nShield Connect’s Tamper Log is located within the nShield Connect and protected by the nShield Connect’s tamper mechanisms. It cannot be erased.

The nShield Connect’s System and Hardserver Logs can be stored within the nShield Connect’s tamper response boundary or pushed out to the RFS or a remote syslog server. If the logs are stored locally then they will be protected by the tamper response boundary but will be lost if the nShield Connect is rebooted. Logging stops when the file system is full.

Alternatively, the logs can be pushed to a remote syslog server (which is not the RFS). However, in this situation no integrity mechanism is applied to the logs: if threats can arise in the network and storage environment that could compromise log integrity, the customer should implement a trusted delivery and storage mechanism to protect the integrity of these logs.

For nToken, nShield Edge and nShield Solo products the hardserver logs are stored in the associated host platform and do not have an integrity mechanism applied to the logs. Therefore, physical, procedural and technical controls should be applied to the host platform environment to protect the integrity of the logs.

For Hardserver and System logging, environment variables can be applied to control the amount of logging information. See the nShield Connect User Guide or nShield Solo User Guide for more information. Your system management policy and security policy will determine the level of logging required.

Debugging information is available for hardware, application, Application Programming Interfaces (APIs) and operating systems. Unless required for development debugging for these sources should not be enabled (it is disabled by default).

Some debug information is provided in command line responses and therefore cannot be disabled.

Debugging can leak potentially useful information to an attacker so should not be enabled in production environments.

For guidance on access control mechanisms available to protect application keys in a Security World see Access Control.

Decide what kind of Security World you need before you create it. Depending on the kind of Security World you need, you can choose different options at the time of creation. For convenience, Security World options can be divided into the following groups:

Security World options are highly configurable at the time of creation but, so that they will remain secure, not afterwards. For this reason, we recommend that you familiarize yourself with Security World options, especially those required by your particular situation, before you begin to create a Security World.

A Security World can protect keys for any applications correctly integrated with the Security World software. A wide range of application interfaces are supported. The application interfaces have many configuration settings. These should be reviewed to identify that only the required settings are activated and that all others are set to off.

Application keys can be stored in the module’s NVRAM instead of in the Key Management Data directory of the host computer. However, the space in NVRAM is limited and does not provide greater security than storing keys in the Key Management Data directory of the host. Therefore, it is recommended that encrypted key blobs are stored in the Key Management Data directory where space is limited only by the capacity of the host computer.

Before initialising a Security World on an HSM after a firmware upgrade, it is recommended that the ACS card holder quorum check that the version of the firmware is correct. This will mitigate the possibility of rollback/downgrade attack.

To use Remote Administration with nShield Connects, the RAS must be installed on a client, which may also be the RFS. The client must allow privileged connections.

To use Remote Administration with nShield Solo(s), the RAS must be installed on the host where the hardserver and nShield Solo(s) reside. If you have multiple nShield Solo hosts in a Security World, the RAS must be installed on each one.

The remote access solution that your organization normally uses, such as Secure Shell (SSH) or a remote desktop application, is also required.

A secure private communications channel, such as Virtual Private Network (VPN), must always be used for the connection between the Remote Administration Client (RAC) and the RAS if they are on separate computers.

You must use nShield Remote Administration Cards with Remote Administration. These are smart cards that are capable of negotiating cryptographically secure connections with an HSM, using warrants as the root of trust.

Dynamic slot timeouts are available to define timeout values for expected smartcard responsiveness and round trip latency for all HSMs that are using the Remote Administration. Expected network delays need to be taken into account when setting this. The timeouts provide control over the period of time a smart card will remain responsive in the system that is experiencing unreasonable latency (where the system’s non-performance could be a consequence of an attack).

If Remote Administration is not required then set the dynamic slots to 0 to disable Remote Administration.

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

By default, modules are initialized into Security Worlds with remote card set reading enabled. Disable the Remote Operator feature if there is no requirement for it.

You must configure SEE options if you are using the nShield SEE. If you do not have SEE installed, the SEE options are not applicable.

RTC options are relevant if you have purchased and installed the CodeSafe Developer kit. If so, by default, Security Worlds are created with access to RTC operations enabled. However, in FIPS Level 2 and Level 3 Security Worlds an option is available during Security World initialization to control access to RTC operations by means of an ACS. A threat analysis can determine if access to the RTC requires ACS authorization.