Release notes

Microsoft Windows Server 2019 x64

Microsoft Windows Server 2022 x64

nShield Solo 500+ F3 for TSOP

nShield Solo XC Base F3 for TSOP

This release only supports the operating systems detailed in Introduction.

Before attempting to create a Security World, it is necessary to install the SEE Activation (Restricted) feature certificate, otherwise the keys will not be created correctly for the SEE machine. Similarly, the Elliptic Curve algorithms feature certificate should be installed to allow the generation of ECDSA-based TSA keys.

When using new-world to generate a Security World, ensure that the dseeall feature is specified. On completion of world generation, it will be necessary to perform SEE delegation - see Creating and managing Security Worlds in the TSOP v8.1.0 Install and User Guide.

Before upgrading an existing TSOP deployment, ensure that the files within %NFAST_HOME%\dse200\UserFiles are backed up.

If you require the ability to back up and restore a TSA key, you must use OCS protection. See Configuring the TSS in the TSOP v8.1.0 Install and User Guide.

When performing a firmware upgrade on an existing TSOP deployment, or attempting to replace the HSM, much of the TSOP configuration will be lost and will have to be set-up again through the TSOP web interface. Specifically, please note that:

If you do not wish to reconfigure your TSOP deployment, or if your TSA keys are not protected using an operator cardset, you should not upgrade your firmware or replace your HSM.

This release of TSOP has been tested with the firmware versions detailed in Introduction only.

If a TSA reports TAC_Invalid, and the clock status for that TSA shows as being Disabled, it might be necessary to re-set the module clock. This can be confirmed by consulting the board log and looking for entries such as exceeded 4 seconds per day. See the Enabling or disabling the clock section of the TSOP Install and User Guide for further information.

Support for the Time Source Master Clock (TSMC), and upper clocks, will be removed in a future release.

If the Board Log shows DSNTP signature was invalid, it might be necessary to remove the localaudit file. This can be confirmed by checking the expiry of the appropriate localaudit certificate within %NFAST_KMDATA%\local. If the certificate has expired, it will be necessary to remove %NFAST_KMDATA%\local\localaudit and restart the DSE200 service. This will generate a new localaudit file and corresponding certificate.

If the SEE Delegation is not set up correctly, this can result in errors whose cause is not obvious. If you are getting unexplained errors and the board log includes messages about NVRam failure, RTC failure, or Key Generation failure, these are likely to have been caused by a DSEDelegation error.

Fatal Error: Java Failure, com.ncipher.km.nfkm.SecurityWorld object initialization failure is displayed if nonpriv_port and priv_port are not set within the hardserver’s config file. These ports can be set by running: config-serverstartup.exe --port 9000 --privport 9001 or by editing the file (located at %NFAST_KMDATA%\config\config) and setting nonpriv_port=9000 and priv_port=9001 (substituting the port numbers as appropriate). It is then necessary to restart the hardserver (which, in turn, will restart the DSE200 service).

If the TSS is very busy responding to time-stamp requests during a DSNTP audit, the DSNTP audit will likely fail with a large communication delay.

If using v12.70.2 or v12.80.2 firmware, when in a FIPS 140-2 Level 3 Security World, both DSE200 service start up time and individual audit requests will take longer due to additional key generation checks being performed on clock audit.

When a DSNTP port is entered for a TSA, the TSS does not verify if that port is already in use by another process.

If using a version of Java impacted by JDK-8191040, it will be necessary to either move to a different version or to apply the documented workaround, see https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8191040 for more information.