nShield Security World Release Notes
Introduction
These release notes apply to version 12.50.4 of Security World Software, CipherTools, and CodeSafe for the nShield family of Hardware Security Modules (HSMs). They contain information specific to this release such as new features, defect fixes, and known issues.
Security World Software is for users of nShield Solo (PCI Express variants), nShield Connect, and nShield Edge. However, this release is only supported on Microsoft Windows and Linux platforms.
The Release Notes may from time to time be updated with issues that have come to light after this release has been made available. Please check https://nshieldsupport.entrust.com for the most up to date version of this document.
Access to the Support Portal is available to customers under maintenance. Please contact nshield.support@entrust.com to request an account.
Document History
Revision | Date | Description |
---|---|---|
1.2 |
2024-03-04 |
PDF branding update, including adding this version history table and updating the support contact information. No content changes to product or the Release Notes. |
1.1 |
2019-05-17 |
Addition of details of the 12.50.4 release. |
1.0 |
2018-10-30 |
Initial revision of document. |
Purpose of this release
Security World version 12.50 introduces enhancements to version v12.40 as described below, and corrects a number of defects that have been identified in earlier releases.
If you are using compatible nShield products covered by a current maintenance contract, you are eligible to upgrade the version of software and firmware that is used with these products.
We recommend you review this document to determine whether you should deploy Security World v12.50.4. If you are using v12.50.1 Preview release you should upgrade unless you are evaluating NTP, see known issue NSE-15822.
Security World v12.50.4
Security World v12.50.4 release addresses an issue affecting the nShield Connect image that caused the nShield Connect HSM to become unresponsive when syslog was enabled to send Connect logs and/or Audit logs off the Connect to a syslog server. The occurrence of this issue is dependent upon the load of the HSM and how many log messages are sent. If this issue occurred, restarting the nShield Connect would return it to an operational state. This issue affected all variants of the nShield Connect hardware and both the FIPS and non-FIPS version.
Changes in v12.50.4
The following changes have been made in the v12.50.4 release:
-
Updated nShield Connect images containing a fix for the syslog issue. This image has the version number 12.50.4.
-
Updated ISOs for all the 12.50 supported operating systems to contain the updated nShield Connect image. The version number of these ISOs is now 12.50.4.
-
Updated installers to contain the updated Connect images. The version number of these installers is now 12.50.4.
Existing nShield Connect deployment with v12.50.2 installed
If you already have v12.50.2 Security World software installed there is no need to uninstall this and install v12.50.4. There are no changes to the host side software.
The installation installs the Connect images into %NFAST_HOME%\nethsm-firmware directory and so a v12.50.2 installation will contain the older connect images.
These can be manually updated by copying the Connect images from the ISO into that directory
|
Installing the updated Connect image
See the Appendix: Upgrading the nShield Connect image file and associated firmware in the nShield Connect User Guide for instructions on updating the Connect image.
The details of the new Connect image are available in Upgrading from previous releases.
Main features of Security World v12.50
This section summarises the main features introduced with Security World v12.50.
Integrated nShield XC support
The v12.40 release introduced common support for the nShield Solo+, Solo XC, Connect+, and Connect XC HSMs on the same Security World release. However, the features supported across the different HSM variants varied. Security World v12.50 introduces a common baseline of features for all nShield HSM platforms.
The table below shows some of the recent HSM features added and the version of Security World that feature was added.
The features added in v12.50 discussed below are present on all HSMs.
Table 1 Features present in the different nShield HSMs
Feature | Solo/Solo+ Connect/Connect+ | Solo XC Connect XC |
---|---|---|
Remote Administration |
v12.00 |
v12.40 |
Pool Mode |
v12.30 |
v12.50 (new) |
SafeSign Cryptographic Module mechanisms |
v12.40 |
v12.40 |
Deterministic DSA |
v12.40 |
v12.50 (new) |
Derive key support for Hyperledger |
v12.40 |
v12.50 (new) |
DeriveKey ACLs |
v12.40 |
v12.50 (new) |
FIPS Certification and required changes
The module firmware has been updated in preparation for recertification against the FIPS 140-2 standard.
If a Security World created on host software prior to v12.50 is loaded onto the updated firmware then there will be no functional change in behaviour. However, if you have a requirement for compliance against FIPS 140-2 level 3 this is not a valid combination and you should continue to use your existing FIPS compliant firmware.
If a new Security World is created on v12.50 host software the functional changes listed below will occur.
Note - A new Security World can only be created in this release using the new-world command. Other methods for creating a Security World have not been updated.
-
The default value for UseStrongPrimes will be on in the default Security World
-
Only one CipherSuite is supported for creating a new Security World
-
Some additional user-selectable cryptographic mechanisms will be restricted in Security Worlds created to be compliant with FIPS 140-2 Level 3. These restrictions are shown in the Cryptographic Algorithms appendix of the User Guide
-
A number of the internal cryptographic mechanisms have been updated to a higher security strength and the previously used mechanisms have been restricted. These internal mechanisms are used in all v12.50 Security Worlds.
-
The Diffie-Hellman (DH) key type and associated mechanisms has been replaced by the DHEX key type
The KLF mechanism has been replaced by KLF2, which means that it will not be possible to request a warrant upgrade for a module that is part of a v12.50 Security World. It is recommended that all warrant upgrades are completed prior to upgrading to Security World v12.50. Should a warrant upgrade be needed on a module that is part of a v12.50 Security World it will be necessary to remove the module from the v12.50 Security World, request the warrant upgrade and then re-indoctrinate the module into the v12.50 Security World.
Audit Logging
Support has been added for users of nShield HSMs in regulated environments where there is a requirement to provably log events. The Audit Logging facility provides the following features:
-
Tamper evident logging of relevant nCore command execution on the HSM
-
Cryptographic key life cycle traceability
-
Authorization for key usage
-
Key loading onto HSM
-
Optional logging of key usage
-
Key destruction
-
Compatibility with syslog and SIEM infrastructures
-
Logs produced in Common Event Format (CEF)
Audit Logging can only be used on new Security Worlds and is enabled when a Security World is created. For further details see the relevant User Guide.
nShield Connect HSM time synchronisation
A standard NTP client has been added to the nShield Connect HSM to support synchronisation of system time on the Connect with one or more NTP servers. Network Time Protocol (NTP) is intended to synchronize all participating computers to within a few milliseconds of Coordinated Universal Time (UTC). System time on the nShield Connect is independent of the Real Time Clock (RTC) in the HSM and is used for log messages and front panel display.
NTP is configured using the new cfg-pushntp utility on a client computer. For further details see the Connect User Guides.
Common Criteria CMTS Mode
Support has been added for creating Security Worlds that meet the requirements of the EN 419 221-5 Protection Profiles for TSP Cryptographic modules - Part 5 Cryptographic Module for Trust Services.
Softcard support in nShield CNG Key Storage Provider
Support has been added in the nShield CNG Key Storage Provider for creating and loading private keys protected by Softcards, in addition to the existing module-protection and Operator Card Set protection options that were already available.
If Softcard or Operator Card Set protection is selected in the CNG Configuration Wizard, a specific Softcard or Operator Card Set must also be selected. This differs from the behaviour in previous releases where the Operator Card Set to be used for protection was not specified explicitly in the wizard, and any Operator Card Set that could be auto-loaded might have been used when generating a key.
If it is required that different CNG keys be generated with different protection options, use the "Allow any protection method to be selected in the GUI when generating". This will then cause a key generation wizard to be displayed when generating the key, enabling module protection or protection with any available Softcard or Operator Card Set to be selected.
Note that the CNG Configuration Wizard options for protection affect the generation of new keys, and don’t affect the loading of existing keys, which continue to be loadable even if they were generated with different protection options.
Operating system support
Support for the Microsoft Windows Server 2016 Core edition has been added.
Microsoft Windows Server 2016 Nano edition is no longer supported. Contact nshield.support@entrust.com if you require further information.
Additional algorithm support
The X25519 ECDH key exchange function and the Ed25519ph variant of the Ed25519 signature scheme (both based on curve25519) are now supported by nCore and the PKCS#11 library.
The following Brainpool curves are now supported as named curves by nCore and the PKCS#11 library:
BrainpoolP160r1
, BrainpoolP160t1
, BrainpoolP192r1
, BrainpoolP192t1
,
BrainpoolP224r1
, BrainpoolP224t1
, BrainpoolP256r1
, BrainpoolP256t1
,
BrainpoolP320r1
, BrainpoolP320t1
, BrainpoolP384r1
, BrainpoolP384t1
,
BrainpoolP512r1
and BrainpoolP512t1
.
Important notes on Security World v12.50
The following section contains important information that should be noted for this v12.50 release:
Security World Creation
It is only possible to create a new Security World on v12.50 module firmware with v12.50 host software. An attempt to use v12.50 host software to create a new Security World on older firmware will result in an error, as will an attempt to load a v12.50 Security World onto HSMs operating with older firmware. Key migration from old worlds to the newly created 12.50 security world is not currently supported.
Security World Types
Security World v12.50 introduces a number of Security World modes, which define how the Security World is set up. The possible modes are:
-
Unrestricted (default)
-
This is similar to default non-strictfips worlds created in pre-v12.50 Security Worlds.
-
-
FIPS-140-2-Level-3
-
This is equivalent to strictfips mode in pre-v12.50 Security Worlds. It creates a Security World compliant with FIPS140-2 Level 3.
-
-
Common-Criteria-CMTS
-
Creates a Security World compliant with Common Criteria PP 419 221-5
-
For this v12.50 release it is recommended that the default unrestricted mode is used. While creating a Security World in one of the other modes is possible, these are still going through certification and so may need to change to be fully compliant. These modes will be fully supported in a future release. Some of the host-side utilities are also not supported in the restricted security world modes.
Loading a previously created Security World onto v12.50 firmware will work as usual, but many of the new features (like Audit Logging) will not be available.
User Interface support
Security World v12.50 continues to ship with a number of different user interfaces for using and managing the product. However, only the command line tool has been updated to support creating new Security Worlds. As such, other UIs (nShield Connect Front Panel, KeySafe and the CAPI wizards) should not be used for creating a new Security World with this release.
Versioning
Security World v12.40 introduced a new versioning scheme for components in the nShield Security World release. Security World v12.50 expands this versioning to all updated components; as such all firmware images, Connect images and host-side software will report 12.50.2 or 12.50.4 as their version number.
Note: Additional information is reported after the v12.50 version number, which is used to identify specific build information. This information should be referenced when seeking support from nshield.support@entrust.com.
Upgrading from previous releases
Installing v12.50 Security World Software
Before installing this release, you must:
-
Confirm that you have a current maintenance contract that licenses you to deploy upgrades on each nShield HSM and corresponding client operating system
-
Uninstall previous releases of Security World software from the client machines
-
For Unix platforms, except Solaris 11, if you have applications built against previous versions of nflibs, in order to maintain backwards compatibility, you must create the file
/etc/nfast.conf
with the entryNFAST_CREATEDEVNFAST=1
. This will create the symlink/dev/nfast
(which points to/opt/nfast/sockets
) during the start-up sequence.
For details of how to install the v12.50 Security World software, refer to the Chapter: Installing the software, in the appropriate Installation Guide.
Upgrading nShield Solo XC Firmware
If the Solo XC HSM is installed with the earlier 3.3.10 firmware it cannot be upgraded directly to the latest firmware and needs to be first upgraded to an intermediate firmware. Please contact support and request the firmware upgrade patch from 3.3.10 to 3.3.20.
If the Solo XC HSM is installed with firmware earlier than 12.50.2, 3.4.2 or 3.3.41 it cannot be upgraded directly to the latest firmware and needs to be first upgraded to an intermediate firmware. Please contact support and request the firmware upgrade patch
Latest v12.50 HSM firmware and nShield Connect image
For details of how to upgrade HSM firmware, refer to Appendix: Upgrading firmware in the nShield Solo and nShield Edge User Guide, or Appendix: Upgrading the nShield Connect image file and associated firmware in the nShield Connect User Guide as appropriate.
The latest firmware is provided on the install media and should be installed on an nShield HSM in accordance with Table 2 and Table 3.
All of the latest 12.50.2 versions of firmware will not be submitted for FIPS certification. A new version of firmware superseding 12.50.2 will be submitted for FIPS certification in the near future. For the latest information on the FIPS status of this firmware please contact nshield.support@entrust.com |
For security reasons, the VSN of the nShield Firmware and nShield Connect image file was increased (see Table 2 and Table 3 below). Increasing the VSN ensures that once the nShield Firmware or the nShield Connect image file from v12.50 has been installed, it is only possible to upgrade or downgrade to firmware or Connect image files with the same or a higher VSN. Contact nshield.support@entrust.com if you require further information |
Table 2 Latest firmware image files provided on v12.50 install media
HSM | Directory location on the install media | VSN |
---|---|---|
nShield Solo, nShield Solo+ |
Monitor: Firmware: |
29 |
nShield Edge |
Monitor: Firmware: |
29 |
nShield Solo XC |
|
37 |
Table 3 Latest nShield Connect image files provided on v12.50 install media
HSM | Directory location on the install media | Firmware version | VSN |
---|---|---|---|
nShield Connect, nShield Connect+ |
|
12.50.2 (VSN = 29) |
31 |
nShield Connect XC |
|
12.50.2 (VSN = 37) |
31 |
FIPS approved firmware and nShield Connect image
In the event that you wish to use Security World v12.50 with FIPS approved firmware the latest FIPS approved firmware is provided on the installation media and can be used with the nShield HSMs as given in Table 4 and Table 5 below.
All of the firmware versions listed below are FIPS certified versions |
Table 4 FIPS approved/pending firmware and image files provided on v12.50 install media
HSM | Directory location on the install media | VSN |
---|---|---|
nShield Solo, nShield Solo+ |
Monitor: Firmware: |
29 |
nShield Edge |
Monitor: Firmware: |
29 |
nShield Solo XC |
|
37 |
Table 5 FIPS Connect image files provided on v12.50 install media
HSM | Directory location on the install media | Firmware version | VSN |
---|---|---|---|
nShield Connect, nShield Connect+ |
|
2.61.2 (VSN = 29) |
31 |
nShield Connect XC |
|
3.4.2 (VSN = 37) |
31 |
Compatibility
Supported hardware
This release is targeted at deployments of any combination of the following nShield HSMs:
-
nShield Solo XC
-
nShield Solo PCI Express (10+, 500, 6000, 500+, and 6000+)
-
nShield Connect (500, 1500, 6000, 500+, 1500+, and 6000+)
-
nShield Connect XC
-
nShield Edge
-
nToken PCI Express "+" (NC2023E-000)
-
nToken PCI Express (NC2021E-000): Microsoft Windows, Linux, and Solaris only
Supported operating systems
This release has been tested for compatibility with the following operating systems:
Table 6 Supported operating systems
Operating System | Solo+ | Solo XC | Connect+ Connect XC | Edge |
---|---|---|---|---|
Microsoft Windows Server 2016 Core x64 |
Y |
Y |
Y |
N |
Microsoft Windows Server 2016 x64 |
Y |
Y |
Y |
Y |
Microsoft Windows Server 2012 R2 x64 |
Y |
Y |
Y |
Y |
Microsoft Windows Server 2008 R2 x64 |
Y |
Y |
Y |
Y |
Microsoft Windows 7 x64 |
Y |
Y |
Y |
Y |
Microsoft Windows 10 x64 |
Y |
Y |
Y |
Y |
Red Hat Enterprise Linux AS/ES 6 x86 |
Y |
N |
Y |
Y |
Red Hat Enterprise Linux AS/ES 6 x64 |
Y |
Y |
Y |
Y |
Red Hat Enterprise Linux AS/ES 7 x64 |
Y |
Y |
Y |
Y |
SUSE Enterprise Linux 11 x64 SP2 |
Y |
Y |
Y |
Y |
SUSE Enterprise Linux 12 x64 |
Y |
Y |
Y |
Y |
Oracle Enterprise Linux 6.8 x64 |
Y |
Y |
Y |
Y |
Oracle Enterprise Linux 7.1 x64 |
Y |
Y |
Y |
Y |
Security World v12.60 Linux support is restricted to x86/x64 architectures. Additional mainstream x86/x64 based Linux distributions other than those listed above may be compatible, however Entrust cannot guarantee this compatibility. |
Supported virtual environments
Table 7 Supported operating systems
Operating System | Solo+ | Solo XC | Connect Connect XC | Edge |
---|---|---|---|---|
Microsoft Hyper-V Server 2012 |
N |
N |
Y |
N |
Microsoft Hyper-V Server 2016 |
N |
Y |
Y |
N |
VMWare ESXi 6.5 |
N |
Y |
Y |
N |
Citrix XenServer 6.5 |
N |
Y |
Y |
N |
Supported compilers for Microsoft Windows C developers
Security World v12.50 C libraries for Windows, built using Visual Studio 2013, have been compiled with the SDL flag. This makes them incompatible with older versions of Visual Studio (i.e. 2010 and earlier).
Microsoft Windows developers using CipherTools or CodeSafe should upgrade to Visual Studio 2013.This applies primarily to static libraries.
HSM firmware compatibility
A Security World release is only tested with the most recent version of FIPS certified firmware together with the latest firmware release if one exists. For details on the range of nShield products, latest firmware version, which firmware was shipped with which versions of Security World, and latest FIPS certified version and associated NIST certificate numbers (where applicable) please contact nshield.support@entrust.com.
Impath protocol compatibility
The Impath protocol is used to secure nShield Connect, RFS (Remote File System) and Remote Operator communication. v12.50 has extended the protocol to include a new CipherSuite DHPrime3072Ex which will be used when both peers are using v12.50 software/firmware.
Backwards compatibility with previous versions is supported except for the datalimit and timelimit configuration options which are now obsolete. The following advice for maximum compatibility between versions applies to both Security World v12.50 and pre-v12.50 configuration files:
-
The
datalimit
andtimelimit
fields should both be set to0
in the hardserver configuration file (/opt/nfast/kmdata/config/config
or%NFAST_KMDATA%\config\config
) and in thehs_clients
section of nShield Connect configuration files. -
Impath resilience should be enabled in Connect configurations (this is the case by default, so unless it has been explicitly disabled no additional configuration is required). Impath resilience is configured with the
enable_impath_resilience
field in thenethsm_settings
section of the nShield Connect configuration file.
CodeSafe
Supported development platforms
In Security World v12.50, CodeSafe development is only supported on:
-
Microsoft Windows
-
Red Hat Enterprise Linux
-
SUSE Enterprise Linux
CodeSafe applications can still be deployed on any OS supported by Security World.
nShield XC Compatibility
The CodeSafe runtime on the nShield XC HSMs provides improved efficiency and significantly greater performance and memory, while maintaining a high degree of backwards compatibility.
CodeSafe Applications, or SEEMachines, built against the SEElib API should be source code compatible with the new environment. However, they will have to be rebuilt for nShield XC HSMs. New Makefiles are supplied with the CodeSafe SDK sample code and can be used as a guide for porting.
CodeSafe Applications built against the BSDLib API should be source code compatible with the new runtime environment on nShield XC HSMs. They will have to be rebuilt against the glibsee API. See the Makefile-examples file within the glibsee examples directory in the CodeSafe SDK for guidance on the new build parameters; and see the CodeSafe Developer Guide and the API documentation for information on any API changes.
Defect Fixes
Defect fixes in client-side software
Table 8 Client-side defects fixed in v12.50.2 & v12.50.4
Reference | Description |
---|---|
NSE-15165 |
When unplugging a nShield Edge from its host a script error may be logged in the edgeHandler.log file. This has now been resolved. |
NSE-15108 |
Fixed an issue on Windows platforms that caused the raserv process with the "-c" or "-L" options to crash. |
NSE-14427 |
generatekey failed to generate PKCS#11 keys if an ACS card was in the slot. This is no longer the case |
NSE-14012 |
Fixed an issue that could cause the hardserver to abort when running CodeSafe applications. |
NSE-14190 |
A successful call to C_GetOperationState failed to set the length pulOperationStateLen, leaving it as the value passed in. This has been corrected. |
NSE-13995 |
Fixed an issue in the GnuPG patch for integrating with nShield hwcrhk which could cause an assertion failure. |
NSE-13590 |
When a badly-formatted ECDSA signature was presented to the nShield JCE provider, an Exception with an incorrect error message was thrown. The 'expected' and 'got' values were reversed. This has now been corrected. |
NSE-13332 |
A number of race conditions were identified in multi-threaded use of nCipherKM. The relevant code is now protected by mutexes. |
NSE-13477 |
Fixed an issue where the Remote Administration Client GUI or raccmd tool could fail due to incorrect processing of network messages. |
NSE-13102 |
Fixed an issue in the nFast Server service that caused Windows machines to wake from sleep mode. |
NSE-13370 |
Fixed an issue in the nShield JCE provider that prevented MGF1 algorithms being usable with Java’s {{keytool}} due to failure to declare the OID for those algorithms. |
NSE-12799 |
Previously, the online help for Cmd_SetNSOPerms did not include NSOPerms_ops_OriginateKey in the list of public permissions that should not be set to fully comply with FIPS 140-2 level 3. This has now been corrected. |
NSE-12747 |
Malformed commands or commands with invalid data could remain on the list of commands awaiting reply indefinitely, impacting performance of programs using nfjava or the nCIpherKM JCE provider. Such commands are now removed from the list when detected. The list has also been reimplemented to reduce the impact of large numbers of waiting commands. |
NSE-12509 |
JCE CSP certificates have been upgraded to RSA 3072-bit with SHA-256. Note that this requires the following patch levels for Java: 9/8u111/7u121/6u131 (October 2016) and later. |
NSE-12556 |
Our PKCS#11 library advertised a limit of 4096 bits for RSA keys despite being capable of handling longer keys. The advertised limit has been raised to 8192 bits. |
NSE-12493 |
Previously, by default the nFast Server service on Windows accepted privileged local connections from any user, unless explicitly restricted with the nt_privpipe_users field in the config file. Now the default has been changed so that only processes with local administrative privilege are allowed to issue privileged connections to nFast Server on Windows by default. The nt_privpipe_users field continues to be available in config to enable a user-specified user or group to be permitted to make privileged connections. See also notes below for outstanding issue NSE-11885. |
NSE-11821 |
Losing communication with a single HSM could cause C_GetSlotList to fail. C_GetSlotList has been made more robust. |
NSE-11669 |
"The incorrect product name was reported for SoloXC and ConnectXC HSMs by enquiry. enquiry now reports: product name nC3025E/nC4035E/nC4335N" |
NSE-11569 |
Strict FIPS mode on SoloXC does not permit the generation of 1024-bit RSA keys. ckcheckinst has been updated to use 2048 bit RSA and DSA keys. |
NSE-11535 |
Fixed an issue in the nShield CNG Key Storage Provider where the NCryptEnumAlgorithms function did not list any algorithms unless an algorithm class was specified. |
NSE-10681 |
NShield JCE CSP signatures now include a timestamp. |
NSE-10632 |
Server permission mismatches were always reported, even when a matching permission was found. Now they are only reported when permission is not granted. |
NSE-10586 |
Fixed an issue that could cause the hardserver service to get stuck in an infinite loop on Windows. |
NSE-10584 |
Fixed an issue that could cause the hardserver to allocate large amounts of memory or abort. |
NSE-10495 |
Fixed an issue where SoloXC devices would not be detected in machines with fast boot-up. |
NSE-10335 |
The implementation of select() in BSDlib library for SEE mishandled errors on non-blocking streams, always returning EWOULDBLOCK in that case. This has been corrected. |
NSE-10184 |
Java 8 made changes to the Sun PKCS11 provider, so that the key generation would fail in our PKCS#11 library, even with JCE Compatibility mode enabled. JCE compatibility mode has been changed to meet the new requirements. |
NSE-9744 |
The generatekey utility now defaults to SHA-256 rather than SHA-1 for certification requests. |
NSE-9745 |
The CodeSafe SEE machine signing tool incorrectly used SHA-1 to identify SEE machines being signed when signing with a stronger hash. It has been fixed to consistently use the same hash for signing and SEE machine identification. |
NSE-9674 |
Fixed an issue that prevented enquiry from reporting connection information for failed nShield Connects. |
NSE-12118 |
Fixed an issue that prevented miniHSM-based nTokens from being recognized automatically on Windows. |
NSE-11943 |
Nethsmadmin now returns a non-zero exit status if an image upgrade operation fails. |
NSE-11909 |
"The deprecated CodeSafe SSL library has been removed. OpenSSL is available to CodeSafe applications using the supplied nShield patch for CodeSafe and is the recommended replacement for CodeSafe SSL." |
NSE-11460 |
Fixed an issue in the CodeSafe developer tools that caused SEE machines to fail on SoloXC and ConnectXC. |
NSE-11242 |
The nCipher MIB has been updated to allow 'softcard' as a valid option for key protection. |
NSE-11053 |
Malformed FTSessionOpen commands were mishandled, potentially causing the hardserver to abort. This mishandling has been corrected. |
NSE-11018 |
Fixed an issue that could cause the hardserver to abort in response to some port scanning tools. |
NSE-10890 |
Corrected symlink configuration for nTokens on Linux to prevent an error being logged. |
NSE-8202 |
Creating a DLf3072s256mRijndael ciphersuite Security World with remote administration sometimes failed with OperationTimeout. The default timeout for card_remove_detect_time_limit has now been increased to address this. |
NSE-8508 |
The OpenSSL patch supplied with the CodeSafe developer kit has been updated to support version 1.0.2o. |
NSE-9393 |
The OpenSSL binaries bundled with nShield have been updated to 1.0.2o. |
NSE-6745 |
Previously, the CNG Key Storage Provider logged failure to find a key with a given name as an error-level message in logs. It is now possible to configure whether such events are considered errors. See the User Guide for more information. |
NSE-5938 |
ckcheckinst attempted to use RSA encryption with PKCS#1 V1.5 padding. This will fail in Security Worlds created with the --disablepkcs1pad option. ckcheckinst has been updated to use OAEP padding instead. |
NSE-3621 |
The Remote Administration Client now attempts to establish an exclusive connection to the nShield Remote Administration Card. If an exclusive connection cannot be established, a shared connection to the card is made and a warning is displayed to the user regarding potential interference with Remote Administration operations from other processes. |
NSE-12830 |
Fixed an issue that could cause the hardserver service to leak small amounts of memory. |
NSE-6804 |
It is now enforced that the file {{/etc/nfast.conf}} is only writable by root if it exists. |
NSE-2485 |
The Impath kx group DHPrime1024 is no longer supported. All Impath communication will now use DHPrime3072 or DHPrime3072Ex. |
NSE-15287 |
Improved the CodeSafe Developer examples. |
NSE-1613 |
Improved the workflow in the CNG wizard workflow as part of the Softcards in CNG feature. |
NSE-6010 |
Corrected an issue with perfcheck reporting results for Mid/High speed Solo XCs. |
NSE-11686 |
The client application can loop infinitely because it fails to clean its command queue when the connection is broken. The fix removes these outstanding commands and marks them as failed. |
NSE-15234 |
Previously nfkmverify incorrectly assumed that a key with a timeout cannot be protected with a non-persistent token or softcard. This has now been corrected. |
NSE-4568 |
The hardserver on Windows was previously binding to all interfaces instead of just loopback for ports 9000/9001 used for local TCP client connections in some cases. TCP connections from external addresses were, however, rejected by the hardserver internally in spite of this. Now the hardserver binds to local loopback only for local TCP client connections. |
NSE-4160 |
If CNG providers were manually uninstalled and then installed using the cnginstall utility whilst the provider DLLs were in use by a process, then the provider DLLs were installed incorrectly on next reboot. This has now been fixed, and the provider DLLs are now copied correctly on reboot. Installation and uninstallation with the cnginstall utility when the provider DLLs were not in use took immediate effect and was not affected by this issue. |
NSE-3827 |
Previously, executables with non-ASCII characters in their path or name failed to connect to the hardserver with the error Status_Malformed. Now, non-ASCII characters in hardserver client paths and executable names are tolerated, but statistics information (e.g. as reported by stattree) will still show only ASCII characters for the process name in hardserver client connections. |
NSE-1934 |
Fixed an issue in the nShield CAPI CSPs that could cause CryptDestroyHash to fail with error 0x57 "The parameter is incorrect". |
NSE-11289 |
Solo XC now correctly returns the stattree MemAllocUser parameter when a SEE app is running (previously would always return 0) |
NSE-10230 |
The Cmd_NVMemAlloc command only used the supplied file name up to the first zero byte, not respecting the length parameter. This has been corrected. |
NSE-14148 |
When changing the MOI settings on a nShield Edge the hardserver sometimes generated an assert and exited. This has now been handled as an error. |
NSE-14882 |
With a CodeSafe application running, HSMs were reporting a very high idle command count (shown via stattree). This has been corrected. |
NSE-15528 |
When using HSP Pool mode, multiple "Notice: Calling transform_reply" messages could appear in the hardserver log. This has been corrected. |
NSE-9064 |
Windows Authenticode timestamps use the SHA-256 digest algorithm in place of SHA-1. |
NSE-12626 |
The deprecated function SEElib_StopTransactListener is no longer supported nShield HSMs. |
Defect fixes in nShield Connect & Connect XC image file
This section contains details of defect fixes specific to the Connect HSM, however if the Connect is using the latest HSM firmware then the defect fixes in section 7.3 below also apply.
Table 9 Connect & Connect XC defects fixed in v12.50.4
Reference | Description |
---|---|
NSE-15289 |
Fixed an issue that prevented the module’s monitor firmware from being updated when expected in nShield Connects. |
NSE-10779 |
NShield Connect firmware upgrades were allowed to start which eventually failed due to VSN downgrade protections on internal components of the Connect. This aborted upgrade left the nShield Connect in an inconsistent but usable state. There is now a "pre-flight-check" to avoid starting nShield Connect firmware upgrades that cannot complete. |
NSE-8920 |
Fixed an issue that prevented remote loading of SEE machines to an nShield Connect XC. |
NSE-3684 |
Changed the way system time and date are set from the nShield Connect front panel so that a reboot is no longer required, avoiding time discrepancies that have been seen occasionally. |
NSE-12006 |
Fixed an issue where an nShield Connect may fail to reboot after 50 upgrades. |
NSE-16075 |
Fixed an issue where enabling audit logging, either explicitly or by creating a Common Criteria CMTS mode Security World, on an nShield Connect HSM could lead to the HSM becoming unresponsive |
Defect fixes in Solo & Solo XC firmware
Table 10 Solo & Solo XC defects fixed in v12.50.2
Reference | Description |
---|---|
NSE-11839 |
The generation of RSA keys has been updated to ensure strict compliance to FIPS 186-4. Prior to this it was theoretically possible to generate a non-compliant key although the probability was so low that it is unlikely that such a key has ever been generated. |
NSE-10522 |
DSA signature generation now performs the check and regeneration of the signature if r or s are equal to zero for compliance with FIPS186-4. |
NSE-9964 |
KLF is no longer allowed in new Security Worlds created in 12.50 and has been replaced by KLF2 |
NSE-9848 |
Diffie-Hellman (DH) keys produced prior to 12.50 were not strictly compliant to SP800-56Arev2. In 12.50 they have been replaced by a new key type, DHEX, that is compliant to SP800-56Arev2. |
NSE-9598 |
A pairwise consistency check has been implemented in the OP_CRYPT operation for generated keys to ensure that the plaintext and ciphertext are different. |
NSE-12031 |
Initiating loading a token from shares (Cmd_LoadLogicalToken) now sets the insertion time of the token to the current time. |
NSE-11158 |
When using many different large RSA or DSA keys on Solo+ under heavy load the HSM may eventually fail. This issue was found with 8kbit keys but may also cause failures with other large key sizes. |
NSE-10576 |
Fixed an issue with generating key pairs in CodeSafe in cases where the command takes more than 100 seconds to complete. |
NSE-11409 |
Limited the memory statistics gathering to once every 30 minutes |
NSE-1457 |
For nShield Solo and Solo+ added a memory-protection scheme to mitigate vector-rewrite attacks. |
NSE-1339 |
Operations using the RIPEMD160 algorithm are now restricted from use when operating in a Security World created to be compliant to FIPS 140-2 level 3. |
NSE-13268 |
Solo XC now records and reports the Max and Min temperature of the HSM (StatID_MaxTempC and StatID_MinTempC in stattree). This matches the behaviour of the Solo+ HSM. |
NSE-13678 |
The Solo XC will no longer process any messages following a tamper event. This matches the behaviour of the Solo+ HSM. |
NSE-13612 |
RSA Key generation performance has been improved on the Solo XC Base. |
NSE-9761 |
KML signatures could use SHA-1 with 3072-bit keys. KML signatures can no longer use SHA-1 with 3072-bit keys |
NSE-10245 |
In environments where an OCS card is left in a smartcard reader to authorise an ongoing operation, the continuous presence of the card may be mistakenly interrupted resulting in the removal of authorisation. This does not affect remote administration slots, or Remote Administration Ready smartcards (whether they are in remote administration slots or not). This does not affect persistent OCS. This defect was introduced in v12 firmware. |
Known Issues
Table 11 Known issues in v12.50.4
Reference | Description |
---|---|
NSE-14406 |
In the Connect config file the remote_sys_log config entry implies multiple entries can be defined but only one remote syslog server can be configured. |
NSE-14978 |
If Cmd_ChannelOpen is called without a key id an audit log message will be generated. This can occur if, for example, if Cmd_Hash is being used to hash a large amount of data. The nShield code translates this to opening a channel in Sign mode without a key. This would normally not be logged unless the key had the logkeyusage permission group flag. However, without a key the necessary checks cannot be performed and the Cmd_ChannelOpen is logged. This can be identified as a log entry without a key hash. |
NSE-14519 |
The enquiry utility in v12.0 client-side incorrectly reports v12.50 Connect modules as Failed. This is a reporting error in this utility only and does not affect other applications. To confirm the module is in fact usable it is possible to send a NoOp command with: nopclearfail -n -m 1 |
NSE-15750 |
NTP reports "Error: ntpd timed out" in syslog 15 minutes after successful start-up - this does not indicate NTP has failed and can be ignored. |
NSE-15826 |
The example audit-log-verifier.py program provided in the <NFAST_HOME>/python/examples folder and documented in the Audit Logging appendix of the user guide currently requires a Security World on the HSM being used to perform the verification whereas the user guide states that this is not required. Either ensure a Security World is present on the HSM being used for audit log verification or perform the following change to the example verifier program. Find the statement where the connection is made "self.conn = connection(needworldinfo=True)" and change the "needworldinfo" parameter to "False". This will be addressed in a future release. |
NSE-14362 |
Type 0 smart cards cannot be used in a v12.50 FIPS level 3 enforced Security World. Contact Support if you need information on moving from type 0 smart cards to supported smart cards. |
NSE-15284 |
With this release of the CodeSafe Developer Kit the build flags required for nShield Solo XC and nShield Connect XC have changed. It is essential that NF_CROSSCC is removed from all XC SEE Machine build configurations. See the examples in the developer kit for further details. |
NSE-15748 |
Running cnglist.exe --list-keys --verbose causes the nShield CNG providers to crash. |
NSE-15762 |
Some instability has been seen in the CNG nShield Service Agent when HSMs report failure after being cleared. |
NSE-15822 |
NTP stops working after upgrading from v12.50.1 Preview release to v12.50.2 or later; the entry "Couldn’t open </config/ntp/nto.server>" appears in the nShield Connect syslog. This will be addressed in a future release. |
NSE-15834 |
After disabling key recovery in a Security World (using killrecov), nfkmverify no longer verifies the Security World, reporting "ACL of NSO not of expected form". The Security World is still usable and key recovery has been disabled. |
NSE-19300 |
Changes were made in 12.50 that mean the nShield Connect no longer prompts for a reboot following a change in time. This can lead to issues with logs no longer being pushed to the RFS. It is therefore recommended that when manually changing the time on the nShield Connect (especially into the past) that the nShield Connect is rebooted. |
NSE-22187 |
CodeSafe applications running on a Solo XC or a Connect XC with high CPU usage can be terminated by the HSM’s supervisory functions. |
NSE-11380 |
Firmware version v12.50 for the nShield Solo XC HSM shows a drop in ECDSA digital signature performance compared to the FIPS 140-2 certified firmware version 3.4.2. Previously ECDSA operations used random numbers generated by the cryptographic accelerator. However as of v12.50 firmware, ECDSA operations use an Entrust-developed DRBG that has been qualified against NIST and German AIS-31 standards. Unfortunately this change results in reduced ECDSA performance. |
Known issues from earlier Security World releases
Table 12 Known issues in previous Security World releases
Reference | Description |
---|---|
NSE-6195 |
Attempting to install a warrant on a SoloXC in pre-maintenance mode returns with an incorrect error. The workaround is to install the warrant while the module is in operational mode. |
NSE-9230 |
The installer on Windows often gives a prompt to find setup.exe during installation. Click 'OK' at the prompt to accept the default location and installation completes successfully. |
NGSOL-2155 /NSE-4583 |
The slotinfo command returns the wrong card type for Unformatted Remote Administrator ready smart cards |
NGSOL-2377 |
RSA Key Generation Fails when executed simultaneously on multiple VMs |
NGSOL-2494 |
Remote mode change does not work from a virtual machine that imports the nShield Solo XC board. Remote mode change should be done on the VM that directly communicates with nShield Solo XC board. |
NGSOL-2744 /NSE-9242 |
If a Solo XC is powered up and the power supply is then removed within 20 seconds the unit may enter a state where the internal back-up battery is being discharged at a higher rate than normal. Similarly, if a Connect XC is powered up and the mains supply is then removed (via the rear rocker switches or removing both mains cables) within 20 seconds the unit may enter a state where the internal back-up battery is being discharged at a higher rate than normal. If left in this condition for an extended period, the Solo XC /Connect XC will enter a failed state, indicated by an SOS-B morse error code on the status LED. To avoid this occurrence, should a Solo XC or Connect XC be turned off under such conditions, power should be reapplied as soon as possible and the unit left powered until it has successfully booted into an operational mode. Note that some electrical safety tests such as leakage current testing may create these conditions, so it is recommended that the unit is booted into an operational mode after any safety testing, as described above. Note: This will not affect Connect XC units with serial number 36-XC0384 and above and Solo XC units with serial number 36-X00527 and above. This issue will be fixed for any units within the affected range in a forthcoming release. |
NSE-10137 |
When upgrading the Solo XC firmware if there is a security processor update then the VM host needs to be hard rebooted. It is not sufficient to just reboot the VM. |
NSE-7618 |
When a SEE (restricted) feature certificate is applied at the front panel of the Connect, it will apply successfully, but will not be reported when running the feature enable tool fet on a client of the Connect. |
NSE-5662 |
NShield Connect can occasional get stuck in POST when powering on, performing a reboot or initiating a front panel/remote upgrade. Work around is to power off/power on nShield Connect using the PSU rocker switches. Note a remote reboot using the netHSMadmin utility will not resolve this issue. |
NSE-11885 |
Hardserver ignores settings for nt_pipe_users/nt_privpipe_users if Java ports (local-loopback TCP) are open. This issue is not present when the hardserver is running in scaling mode. |
NSE-11911 |
Solo and Solo+ behave differently to the SoloXC when restarting the hardserver in pre-maintenance mode. When clearing the modules while in pre-maintenance using nopclearfail -c -m1 they all (Solo, Solo+ and SoloXC) return to operational mode. |
NSE-8463 |
When enrolling an nShield Connect into a security world or creating a new security world you must ensure that the world and module files are propagated to client machines and afterwards ensure that hsc_configurepoolmodule -mN is run on each machine enrolled as a client where N is the newly enrolled module number. |
NSE-7575 |
The user won’t see the max exported modules being updated when running enquiry after remotely enabling the client licenses dynamic feature due to the enquiry cache not being cleared for imported modules. User should restart the client-side hardserver to work around this issue. |
NSE-7456 |
The nShield PKCS#11 client library can only read FIPS Authorization from operator cards, not from Administrator Cards. When used with a Strict FIPS 140-2 Level 3 compliant Security World, an Operator Card Set must be created for the PKCS#11 to be able to present FIPS Authorization to the module(s). |
NSE-6391 |
On Solaris systems, the system path /usr/sbin must be in the PATH environment variable when executing /opt/nfast/sbin/install and /opt/nfast/sbin/init.d-ncipher. Suggested usage: PATH=/usr/bin:/usr/sbin /opt/nfast/sbin/install |
NSE-6610 |
Security World applications which write to log files lock the log files when writing log messages. This includes the hardserver when writing to /opt/nfast/log/hardserver.log. If another application, such as a backup application, holds a lock on the log file for an extended period, the Security World application will be blocked for that time. It is recommended that either log files should not be locked whilst applications are running, or that they be locked only briefly whilst copying the file. |
NSE-2115 |
Log files produced by the Security World software on 32-bit Linux systems are limited to 2 GB. This includes the hardserver log in /opt/nfast/log/hardserver.log. Applications, such as the hardserver, will not start if their log files exceed this size. The user should delete log files periodically (backing up first if required) to avoid this problem. This issue does not affect 64-bit Linux systems. |
NSE-4099 |
Windows Platforms Only If nShield logging is enabled, the file specified by NFLOG_FILE must be writable by the user running the 'nShield Service Agent' or the agent will not be able to process dialogs from a CNG service in Session 0. |
NSE-4094 |
Windows Platforms Only Having run the CNG installation wizard or cngregister, it is necessary to log off and log in to start the nShield Service Agent. The Agent can be started explicitly by executing either nShieldServiceagent.exe or nShieldServiceAgent64.exe from the %NFAST_HOME%\bin folder. |
NSE-2671 |
Codesafe SEELib "nvram" example SEE machine crashes on startup. |
NSE-2899 |
CNG Wizard says "There was an error reading the card" when it means "card not in Authorized Card List". |
MEI-4304 / NSE-3320 |
Nfwarrant claims the module is in pre-initialization mode if the module is uninitialized. Switch to Initialization mode and run initunit, then put the module back in Operational mode, before running nfwarrant. |
MEI-4249 / NSE-3321 |
The Remote Administration Service does not abort associations when a dynamic slot is unavailable due to CrossModule#NetworkError. Break and remake the association from the Remote Administration Client. |
MEI-4463 / NSE-3326 |
Applications that call NFKM_checkconsistency display "nfkmcheck: warning: World kmdata entry E0x199=E409 unexpected" |
MEI-4386 / NSE-3328 |
The [slot_imports] and [slot_exports] sections of the hardserver config file is misleading in stating "This cannot be configured alongside dynamic slots." The restriction is dynamic slots cannot be exported hence cannot be imported. |
MEI-4306 |
Connect UI login using OCS displays UnlistedCard for Remote Administration smart cards if card is already inserted. Removing and reinserting the card is required. |
MEI-3934 |
Running enquiry on an nShield Edge results in hardware status being reported as "unsupported driver." This is normal behaviour; SOS error reporting is not available on an nShield Edge. |
NSE-2857 |
Failed to start nFast service error message seen occasionally after installing on Windows. If services are running error can be ignored. |
MEI-4569 |
Display World Info on nShield Connect front panel may show a valid Remote Administration smart card as 'Unidentified'. Use slotinfo to confirm smart card is valid. |
MEI-2149 / NSE-3246 |
NShield Connect front panel UI appears to run slow after a Connect image upgrade. The workaround is to reboot the Connect after the upgrade after which the front panel will behave correctly. |
MEI-4587 |
If the environment variables NFAST_SERVER_PORT and NFAST_SERVER_PRIVPORT are set to non-standard values, e.g. 9100 and 9101 respectively then the Remote Administration Service will not start. |
MEI-4559 |
'nethsmadmin -reboot option does not time out or return when a module has been marked as failed. You should check your Windows event viewer to check for time outs and then terminate the 'nethsmadmin' application. |
MEI-4572 |
Generatekey ignores slot choices and will use an OCS in any available slot of the chosen module. |
15318 |
It is not possible to recover PKCS #11 keys using the nShield Connect or netHSM unit’s front panel. You must use the rocs client-side utility to do this. |
MEI-3265 |
When upgrading from any previous installation the hardserver configuration file will not be populated with the new remote administration sections, resulting in default behaviours. A new default configuration file can be made by running "cfg-mkdefault -r", remember to back up your existing configuration file before running this operation. |
MEI-4418 |
When creating a Security World on a Windows client host, the new-world utility can fail with TokenMessageError until the module is cleared. If this happens, clear the module (using nopclearfail -c, the clear button on the Edge or the Solo Board, or the menu command on the Connect) before re-attempting to create a Security World. |
NSE-3738 |
Using Remote Operator to import a slot to an HSM running pre-v12.00 firmware from an HSM running v12.00 firmware or later results in getslotinfo and other utilities returning "Malformed". To avoid this issue do not use a mix of pre and post v12.00 HSM firmware with Remote Operator. |
NSE-3743 |
Nfwarrant can fail silently, claiming it has generated a Certificate Signing Request (CSR) file when it has not. A particular instance of this is attempting to generate a CSR for a module that is part of a v12.50 Security World and in this case the module should be removed from the Security World first. |
NSE-11828 |
Using the new-world utility without specifying a module results in it reporting incorrectly that it has generated a Security World on module #0. This can be avoided by specifying the module to use. |
NSE-12095 |
CodeSafe applications on XC HSMs do not terminate when a thread calls ExitThread(456) / pthread_exit(). A workaround is to use the exit() system call. |
NSE-13607 |
Attaching an nShield Edge and nShield Connects to the same Client computer or VM may result in a Connect being hidden from the enquiry utility. We do not recommend using the nShield Edge alongside other nShield HSMs on the same computer or VM. |
NSE-14152 |
The bulkerase utility does not remove card files of Operator Card Sets that are more than 1/1, it only erases the single presented Operator card. |
Known issues in older Remote Admin Client release
Table 13 Know issues in previous Remote Admin Client releases
Reference | Description |
---|---|
NSE-11849 |
Hardware error reporting and MOI changes do not work in HPUX |
MEI-3390 |
When using Ubuntu 12.04 and later then the jpeg compatibility library package libjpeg62 must be installed for the Remote Administration Client. |
NSE-2861 |
Multiple Remote Administration GUI clients on a PC can use the same card reader to connect to multiple dynamic slots, causing one or both to work incorrectly, e.g. reporting UnknownCard. Avoid doing this. |
MEI-2801 MEI-2805 |
You are recommended to not use more than four TVDs or standard card readers on a single Remote Administration Client system as it can run out of resources if an excessive number of card readers are used. |
MEI-2481 |
RSA token card services prevent the Remote Administration Client from working on Microsoft Windows OS (e.g. RAC hangs displaying "reading…"); these need to be disabled in the Windows Task Manager services table to allow Remote Administration smart cards to work with both the TVD and other smart card readers. |
MEI-4480 |
On rare occasions, leaving a Remote Administration smart card in a dynamic slot for a prolonged period can result in SecureChannelFailed. |
NSE-2860 |
Switching to Maintenance mode while an Association with a dynamic slot exists causes an UnknownCommand error |
MEI-3940 |
Remote Administration Support Client Tools Setup can pause for up to 2 minutes with no feedback to user (Windows) |
MEI-4029 |
Running racgui on SUSE 12 shows GTK assertions from wxpy |
MEI-4401 MEI-3383 |
Any previous nShield Security World Software must be uninstalled before installing the Remote Administration Client software. If you want the Remote Administration Client software installed alongside your Security World Software it is available (and installed by default) via the Security World Software installer. |
NSE-6939 |
On OS-X the Tab key does not navigate between controls on the wizard pages and the Return key does not perform the default action. All operations can be accomplished with either a mouse or touchpad. |
NSE-7088 |
Installing the RAC on OS X for the current user will not recognize the TVD. This is due to the TVD driver not being installed in this scenario. It is necessary to install separately the TVD driver for all users to allow the TVD to be recognized. |
Appendix A: Security Information
This appendix contains relevant security information applicable to this release and should be consulted prior to updating to v12.50.
Date and Time
The following sections provide procedural guidance about securely using date and time functions. Please see the User Guides for information on how to operate these functions.
Set the nShield Solo and Connect RTC
Set the Real-Time Clock (RTC) using an accurate trusted local time source as part of the commissioning process. This should be set as early in the commissioning process as possible. The correct time should be set to support hardserver and audit logging.
Note that the backup battery for the RTC on the nShield Solo and Solo+ will only last for two weeks when the module is not powered. The RTC must be reset on power up if the battery has drained.
Set the nShield Connect Date and Time
Set the nShield Connect date and time using an accurate trusted local time source as part of the commissioning process. This should be set as early in the commissioning process as possible. The correct time should be set to support system, hardserver and tamper logging. The nShield Connect supports a Network Time Protocol (NTP) client which if activated will synchronise the nShield Connect time to NTP. It is recommended that multiple NTP sources are requested to mitigate an attack on a single NTP source or failure of that source.
NTP suffers from a number of security vulnerabilities, see https://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html. The activation of NTP within the nShield Connect can increase the threats the nShield Connect is exposed to. Due to the nature of NTP design not all threats can be mitigated. NTP should only be used if your risk analysis identifies suitable controls to mitigate the impact of its operation. This could include
NTP can provide an accurate time source through consensus with multiple input servers. It can also identify which available time servers are inaccurate |
To further mitigate attacks on NTP the synchronised 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.
Logging and Debugging
The following sections provide procedural guidance about securely using logging and debugging functions. Please see the User Guides for information on how to operate these functions.
Set Up Logging
Once the time has been set, your logging requirements should be identified and implemented. Various types of logs are available on nShield platforms:
Table 14 Logs on nShield Platforms - purpose and configuration
Log Type | Purpose | Configuration | NShield nToken | NShield Edge | NShield Solo+ and Solo XC | nShield Connect+ and Connect XC |
---|---|---|---|---|---|---|
Audit Logging |
Operational and key usage activity |
Can only be enabled at Security World initialisation |
N |
Y |
Y |
Y |
Hardserver Log |
Errors and troubleshooting |
Controlled through environment variables. Default is to log nothing. Level of logging can be set. |
Y |
Y |
Y |
Y |
Security World Log used by API libraries and base services |
Errors and troubleshooting |
Controlled through environment variables. Default 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. Level of logging can be set. |
Y |
Y |
Y |
Y |
System Log |
System events on nShield Connect |
Always enabled |
N |
N |
N |
Y |
Tamper Log |
Tamper events on nShield Connect |
Always enabled |
N |
N |
N |
Y |
Netsnmp Daemon Log |
Netsnmp Daemon activity |
Starts with the SNMP service. The SNMP Agent contains a Logfile switch to record warnings and message. |
N |
N |
Y |
Y |
Audit Log
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 SIEM Collectors should be located in a protected environment that limits physical access to the processing platform(s) on which the collector and validation applications are running to authorised Users.
-
The availability of logs delivered to the SIEM Collectors should be maintained through a set of controls including:
-
Configuring multiple SIEM Collectors for each HSM
-
regular backups
-
physical and logical controls.
-
-
A mechanism should be supplied to support the reliable delivery of logging messages to the SIEM Collectors.
-
The network should be configured correctly to help prevent message corruption, congestion, forwarding loops, and incorrect delivery.
-
The Audit Logging Verification process documented in the User Guide should be followed to verify Audit log entries. A process for supporting Audit Log Certification Block validation will be provided in a future release provided by Entrust to support the authenticated supply of a Trusted Root to the customer should be followed.
-
Prior to shutting down the nShield Connect, a delay of at least 17 minutes should be made after the final log messages has been dispatched to the SIEM to ensure that the outstanding integrity verification message for those log messages is dispatched. The receipt of the verification message on the SIEM should be confirmed prior to shut down.
-
In the event of a power failure or SOS on the nShield Connect, the integrity of any log messages that occurred after the last integrity verification message was dispatched cannot be verified. These log messages can potentially be altered or lost.
The Auditor should inspect the logs to:
-
identify missing logs
-
verify the integrity of logs up to the trusted root
-
identify log entries that are a cause for concern
nShield Connect System and Hardserver Logs
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. If the logs are stored within the nShield Connect 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 file system. However, no integrity mechanism is applied to the logs and therefore the customer should implement a trusted delivery and storage mechanism to protect the integrity of these logs if threats may arise in the network and storage environment that could compromise log integrity.
nShield nToken, nShield Edge, and nShield Solo Hardserver Logs
For nShield 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 and logical controls should be applied to the host platform environment to protect the integrity of the logs.
Hardserver and System Log Environment Variables
For Hardserver and System logging, environment variables can be applied to control the amount of logging information. See the nShield Connect or nShield Solo User guides for more information. Your system management policy and security policy will determine the level of logging required.
nShield Connect Tamper Log
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.
Time displayed in Logs
The Date and Time section above provides guidance on safely setting the time for the nShield Connect and RTC clocks. If NTP is enabled then the nShield Connect clock will synchronise to that. Both clock times will appear in the Audit Log and other logs described above. The nShield Connect (if not synchronised to NTP) and RTC are subject to drift and should be regularly set using an accurate trusted local time source.
With regard to the Audit Log we recommend only accepting that the nShield Connect and RTC time stamps represent the actual time if they match each other within a reasonable margin of error.
Debugging options
Debugging information is available for Hardware, Application, APIs, and Operating Systems. Unless required for development debugging for these sources should not be enabled (by default it’s disabled).
Some debug information is provided in command line responses and therefore cannot be disabled.
CodeSafe debugging is disabled by default, but you can choose whether to enable it for all users or whether to make it available only through use of an ACS |
Debugging can leak security information so should not be enabled in production environments.
Key Management
Key management is a critical component of a security product. A risk analysis will determine the strength of cryptographic algorithm and associated key sizes and lifetimes required to protect customer data.
Key Management Schema
Refer to the Security Worlds chapter in the User guide for a description of the Security World infrastructure available for managing the secure life-cycle of cryptographic keys. Refer to the Security World Access Control Architecture section for a description of the different keys available to protect application keys.
Security World Security Strengths
Security strength is represented by a number associated with the amount of work (that is, the number of guesses) that is required to break a cryptographic algorithm or system. The security strength is specified as a number of bits, typically from the set {80, 96, 112, 128, 192, 256}. For example, a security strength of 112 bits would require on average 2112-1 operations to break the security of the algorithm or system by brute force.
Security World modes are selected when creating a Security World. In v12.50 the available modes, associated cipher suites, automatic FIPS mechanism compliance and security strengths are:
Table 15 Modes, ciphersuites, FIPS mechanism conformance and security strengths available in v12.50
Modes | Ciphersuite | Automatic compliance of FIPS mechanisms with NIST SP800-131A Revision 1 algorithm/key sizes | Security Strength |
---|---|---|---|
FIPS 140-2 Level 3 (FIPS approved mode enforced) |
DLf3072s256mAEScSP800131Ar1 |
Y |
128 bits |
Unrestricted (default) |
DLf3072s256mAEScSP800131Ar1 |
N 1 |
128 bits |
Common Criteria CMTS 2 |
DLf3072s256mAEScSP800131Ar1 |
N |
128 bits |
1 In this mode non-approved security functions (e.g. algorithms, primes) that are not compliant with NIST SP800-131A Revision 1 are available and if selected then the customer will be operating outside of a FIPS approved mode of operation (a mode of the cryptographic module that employs only Approved security functions).
2 Common Criteria EN 419 221-5 Protection Profiles for TSP Cryptographic modules - Part 5 Cryptographic Module for Trust Services
Pre v12.50 Security Worlds can be loaded on to a v12.50 nShield Edge, nShield Solo on nShield Connect. The cipher suites, automatic FIPS mechanism compliance and security strengths for these worlds are:
Table 16 Pre-12.50 Security Worlds ciphersuites, FIPS mechanism conformance and security strengths that are available in v12.50
Modes | Ciphersuite | Automatic compliance of FIPS mechanisms with NIST SP800-131A Revision 1 algorithm/key sizes | Security Strength |
---|---|---|---|
Pre v12.50 Security Worlds |
DLf3072s256mRijndael |
N |
128 bits 1 |
DLf1024s160mRijndael |
N |
80 bits |
|
DLf1024s160mDES3 |
N |
80 bits |
1 Whilst the Cipher suite provides 128 bits of security strength some of the underlying, not selectable, cryptographic mechanisms pre v12.50 provide a reduced security strength. This is identified by the 'X' in the Compliance with FIPS mechanisms column.
Security strength is represented by a number associated with the amount of work (that is, the number of guesses) that is required to break a cryptographic algorithm or system. The security strength is specified as a number of bits, typically from the set {80, 96, 112, 128, 192, 256}. For example, a security strength of 112 bits would require on average 2112-1 operations to break the security of the algorithm or system by brute force.
Security World modes are selected when creating a Security World. In v12.50 the available modes, associated cipher suites, automatic FIPS mechanism compliance and security strengths are: Table 15 and Table 16 identify the cipher suites, automatic compliance with NIST SP800-131A Revision 1 and security strengths. The National Institute for Standards and Technology (NIST) have published, over the years, good key management guidance. SP800-131A Revision 1 - 'Transitioning the Use of Cryptographic Algorithms and Key Lengths' is referenced in the table as it provides guidance on suitable cryptographic algorithms and key sizes for protecting sensitive data today. This document, published in November 2015, advises that the minimum security strength for algorithms or keys is now 112 bits. Whilst the immediate audience is U.S. government agencies, NIST standards provide a global benchmark in security standards which many global product vendors adhere to, in order to provide their customers with appropriate levels of security assurance. Therefore, the industry standard minimum security strength is considered to be 112 bits today.
Application Keys, Algorithms, Key Sizes
Depending on the application library used, a range of cryptographic algorithms are available for selection. The algorithm used and key size selected (if applicable) should be sufficient to protect your data (or the data you control) from threats identified in the deployed environment. In terms of security strengths, as described above in the Security World Security Strengths section, the security strengths applied need be no greater than the security strength of the Security World ciphersuite. As advised in the Security World Security Strengths section a minimum security strength of 112 bits is considered the industry standard.
The Cryptographic Algorithms appendix in the User Guide identifies all algorithms and key sizes available (both NIST approved and unapproved). NIST SP 800-57 Part 1 Revision 4 has a section on Comparable Algorithm Strengths which provides guidance on identifying the security strength of different NIST approved algorithms and key sizes. BlueKrypt Cryptographic Key Length Recommendation is a useful reference for determining required key sizes for common cryptographic functions:
-
Symmetric algorithms
-
Asymmetric algorithms, based on the following branches of cryptography:
-
Factoring Modulus, such as RSA.
-
Discrete Logarithm Key/Group, such as DSA, Diffie-Hellman.
-
Elliptic Curve, such as ECDSA.
-
-
Hashes
The General Key Management Guidance section of NIST SP 800-57 Part 1 Revision 4 provides guidance on the risk factors that should be considered when assessing cryptoperiods and the selection of algorithms and keysize.
The nfkmverify
command-line utility can be used to identify algorithms and key sizes (in bits).
See the Cryptographic algorithms appendix in the User Guide for more information.
Cryptoperiods
A cryptoperiod is the time span during which a specific cryptographic key is authorized for use. NIST SP 800-57 Part 1 Revision 4 has sections describing the rationale for cryptoperiods and the risk factors that should be considered when determining cryptoperiods. Setting a cryptoperiod limits, amongst other things, the amount of data exposure if a key is compromised. Customers are advised to perform a threat analysis, considering the sensitivity of their data and what controls they have in place to mitigate compromise, to determine appropriate cryptoperiods for keys protecting that data.
In terms of the Key Management Schema the following cryptoperiod rules must be applied:
-
Application Keys must have a cryptoperiod assigned to them
-
The Security World must have a cryptoperiod, as the Security World Keys (for example, Module Keys) are used to protect Application Keys. The cryptoperiod of the Security World must therefore be greater than or equal to the cryptoperiod of any Application Key.
-
Whenever an Application Key reaches the end of its cryptoperiod it must be revoked. Whenever a Security World reaches the end of its cryptoperiod, a new Security World must be initialised and new Application Keys generated
-
Cryptoperiods can be managed manually by deleting a key when it is no longer compliant with a customer’s cryptoperiod policy. A key time out value can be applied to an Application Key to set its cryptoperiod (see for example the documentation for mkaclx in appendix C of the User Guide). In addition, the usage count can also be set for an Application Key. In a common criteria cmts Security World the maximum key timeout parameter can be used to control the maximum life of any Application Key, and the key usage parameter can be used to control the maximum number of times any Application Key can be used.