Entrust nShield User manual

nShield®
Security Manual
12.80
17 Nov 2021

Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê5
1.1. Who should read this document? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê5
1.2. Products covered by this manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê5
1.3. Product security objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê5
1.4. Product selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê6
1.5. Security manual authority and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê6
1.6. Related documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê6
1.7. Reference documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê7
2. Supply and Transportation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê8
2.1. Trusted delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê8
2.2. Tamper inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê8
3. Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê10
3.1. HSM function and architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê10
3.2. HSM environment controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê11
4. Commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê13
4.1. Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê13
4.2. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê13
4.3. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê14
4.4. Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê14
4.5. Date and Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê16
4.6. nShield Connect and client configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê17
4.7. Logging and debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê21
4.8. Configure access control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê24
4.9. Configure Security World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê25
4.10. Remote services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê26
4.11. SEE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê27
5. Access Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê29
5.1. Security World access control architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê29
5.2. Security World access control guidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê31
5.3. Application keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê37
5.4. nShield Connect front panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê38
5.5. Configuring the nShield Connect to use a client . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê38
5.6. Role holder lifecycle guidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê39
6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê42
6.1. Patching policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê42
6.2. Set the RTC time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê42
6.3. Operator Card Set (OCS) quorum configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê42
6.4. NVRAM key storage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê44
nShield® Security Manual 2 of 90

6.5. RFS – configuring auto push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê44
6.6. Security World replacement options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê44
6.7. Host platform and client applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê44
6.8. Preload utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê45
6.9. Discarding keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê46
6.10. Erasing a module from a Security World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê46
6.11. Replacing an OCS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê46
6.12. Replacing the ACS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê46
6.13. Firmware upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê47
6.14. Enabling and disabling remote upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê47
6.15. Migrating keys to a v3 Security World. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê47
7. Key Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê49
7.1. Key management schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê49
7.2. Security World security strengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê49
7.3. Application keys algorithms and key sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê51
7.4. Cryptoperiods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê51
7.5. Generating random numbers and keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê52
7.6. Key backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê52
7.7. Key import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê53
7.8. Key separation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê53
7.9. nShield JCA/JCE CSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê53
7.10. nShield PKCSÊ#11 library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê54
8. Physical Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê56
8.1. nShield Edge physical security controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê56
8.2. nShield Solo+ physical security controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê56
8.3. nShield Solo XC physical security controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê57
8.4. nShield Connect physical security controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê58
8.5. nShield card readers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê63
8.6. Tamper inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê63
9. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê64
9.1. HSM and card reader location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê64
9.2. ACS and OCS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê64
9.3. Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê64
9.4. Audit logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê65
9.5. Audit Logging time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê66
10. Support and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê67
10.1. Security Advisories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê67
10.2. Application and Operating System patching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê67
10.3. Connect fan tray module and PSU maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê67
10.4. Solo XC fan and battery maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê68
nShield® Security Manual 3 of 90

10.5. Maintenance mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê68
10.6. Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê69
10.7. Contacting Entrust nShield Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê69
11. Security Incident and Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê70
11.1. Security incident monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê70
11.2. Security incident management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê70
11.3. Security incident impact and response. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê71
11.4. Deleting a Security World. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê76
11.5. Module failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê77
11.6. Tamper incident. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê77
12. Decommission and Disposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê78
12.1. nShield Connect and nShield Solo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê78
Appendix A: Abbreviations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê80
Appendix B: Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ê82
nShield® Security Manual 4 of 90

1. Introduction
Good security practice requires procedural as well as technical measures to provide a
comprehensive security environment for the protection of your cryptographic keys and
data.
This guide provides advice to you on the secure operation of the product. It identifies
procedural measures that should be deployed to support the secure operation of the
nShield. The guidance should be used in the development of your Security Operating
Procedures for your systems incorporating the nShield.
1.1. Who should read this document?
The guide should be used by the following people:
•Those responsible for the security policy and procedures for your systems
incorporating the nShield
•Those responsible for commissioning the nShield
•Those responsible for administering the nShield
•Those responsible for auditing the nShield.
1.2. Products covered by this manual
The guide covers the following product variants:
•nShield Edge
•nShield Solo+
•nShield Solo XC
•nShield Connect+
•nShield Connect XC.

In this manual, guidance given for nShield Solo applies to both the
Solo+ and Solo XC product variants. Similarly, guidance given for
nShield Connect applies to both the Connect+ and Connect XC product
variants.
1.3. Product security objective
The nShield range of products provide protection against technical and physical attacks
on keys used to protect your data in use, in motion and at rest. This provides
confidentiality, integrity and availability* of user data up to FIPS 140-2 Level 3 and
nShield® Security Manual 5 of 90

Common Criteria version 3.1 revision 5 EAL 4+ (platform and version dependent) when
deployed in accordance with the technical and procedural controls identified in the User
Guide and Security Manual.
*Some availability threats can be mitigated by hosting a Security World across multiple
Hardware Security Modules (HSMs).
1.4. Product selection
As part of the security product selection process, you must determine that the
functionality delivered by any candidate product meets your requirements.
In this manual the terms module and HSM are both used to generically
describe the nShield range of products.
1.5. Security manual authority and scope
The guide is advisory and its scope is limited to identifying good procedural practices for
the secure operation of the product within your environment.
If there is any contradiction between the guidance that occurs in this manual and that
found in either the Installation guides or User Guides then the guidance found here takes
precedence.
The scope of this manual is limited to security procedural guidance. The Installation
guides and User Guides documents provide guidance on how to implement the controls
discussed in this Manual.
1.6. Related documents
•nShield Solo, nShield Solo XC and nShield Edge User Guide (specific to the operating
environment: Linux and Windows)
nShield® Security Manual 6 of 90

•nShield Connect User Guide (specific to the operating environment: Linux and
Windows)
•CodeSafe Developer Guide
•nShield Connect Physical Security Checklist
•nShield Connect XC Installation Guide
•nShield Edge Installation Guide
•nShield Connect Installation Guide
•nShield nToken Installation Guide
•nShield Solo and nShield Solo XC Installation Guide.
1.7. Reference documents
•Ecrypt-CSA recommendations
•NIST SP 800-57 Part 1 Revision 5
•NIST SP800-131A Revision 1
•Net-SNMP
•NTP Vulnerabilities.
nShield® Security Manual 7 of 90

2. Supply and Transportation
2.1. Trusted delivery
To help assure the integrity of the product during delivery a trusted courier service
should be used that provides traceable delivery progress reporting and requires signed
acceptance of delivery. Inspect the packaging for signs of tampering e.g. packing tape
appears to have been removed or cut and then resealed. If tamper is detected,
quarantine the package and notify your Security Officer in line with your Security
Incident and Response procedures. Similar methods must be deployed by you for any
further transportation of the product during its lifetime. If you utilize a protective
marking scheme, the relevant protective marking must be deployed during
transportation to provide the required level of integrity.
2.2. Tamper inspection
Upon receipt of the nShield HSM, it must be inspected for signs of tamper:
•nShield Edge: Inspect the USB cable and the nShield Edge before use. The
inspection should cover the cable for signs of tampering, the fascia for signs of
disfigurement and specifically the holographic tamper label in the tamper window
shown below for the appearance of VOID.
The nShield Edge Developer Edition does not have a hologram and
tamper window.
•nShield Solo and nShield Solo XC: Examine the epoxy resin security coating (after
removing the metal lid on nShield Solo XC) of the module for obvious signs of
damage.
•Smart card reader: Examine the smartcard reader for signs of tamper and ensure it is
directly plugged into the module or into the port provided by any appliance in which
the module is integrated and the cable has not been tampered with.
•nShield Connect: The nShield Connect Physical Security Checklist, provided in the
box with an nShield Connect and available in the document folder on the installation
media provides details of the physical security checks required. Further guidance on
nShield® Security Manual 8 of 90

physical security checks can be found in Physical Security. Review the nShield
Connect’s tamper log for tamper alerts.
•See Physical Security for further guidance on the management of physical
mechanisms provided to protect the product.
If a tamper is suspected then the unit must be quarantined to investigate the incident.
The unit must not be deployed on the live system until its integrity can be verified. See
the Security Incident and Response for further guidance.
nShield® Security Manual 9 of 90

3. Environment
3.1. HSM function and architecture
The nShield HSMs perform encryption, digital signing and key management on behalf of
an extensive range of commercial and custom-built applications including Public Key
Infrastructures (PKIs), identity management systems, application-level encryption and
tokenization, SSL/TLS, and code signing.
nShield HSMs provide a hardened, tamper-resistant environment for secure
cryptographic processing, key generation and protection and key, data and application
encryption. They are available in three FIPS 140-2 certified form factors to support a
variety of deployment scenarios.
All nShield HSMs integrate with the nShield Security World architecture. This supports
combinations of different nShield HSM models to build a unified ecosystem that delivers
scalability, seamless failover and load balancing. The nShield Security World architecture
supports a specialized key management framework that spans the nShield HSM range.
nShield HSMs all define the physical FIPS-certified security boundary or HSM Layer
within which Application Keys, Control Keys and Infrastructure Keys are protected. Using
quorums of Administrator Card Set (ACS) cards, Infrastructure Keys can be securely
backed up and shared across multiple HSMs. When this is performed, HSMs that share
the same Infrastructure Keys develop a common Security World that provides an
expanded logical security boundary that extends beyond the physical HSM Layer and
overlaps into the enterprise IT environment or Application Layer. The abstraction of
Application Keys into Application Key Tokens enables these tokens to be stored outside
the physical HSM and within the corporate IT environment.
nShield® Security Manual 10 of 90

The Security World technology makes sure that keys remain secure throughout their life
cycle. Every key in the Security World is always protected by another key, even during
recovery and replacement operations. Because the Security World is built around nShield
key-management modules, keys are only ever available in plain text on secure hardware.
nShield Connect and nShield Solo HSMs also provide a secure environment for running
sensitive applications. The CodeSafe option lets you execute code within nShield
boundaries, protecting your applications and the data they process. The CodeSafe area
occurs outside of the module area that is FIPS 140-2 Level 2 and 3 approved.
The nShield HSM is used to protect sensitive keys, data and optionally applications. It can
only operate securely if its environment provides the procedural security that it requires
and if its security enforcing functions are utilized appropriately.
When configured correctly the nShield HSM provides encryption, digital signing and key
management services in support of confidentiality and integrity requirements for your
data. The nShield HSM is not designed to be completely resistant to denial of service
attacks - these can be addressed by other aspects of the system design if warranted by
the threat and impact assessments.
3.2. HSM environment controls
You must exercise due diligence to ensure that the environment within which the nShield
HSMs are deployed is configured properly and is regularly examined as part of a
comprehensive risk mitigation program to assess both logical and physical threats. The
nShield® Security Manual 11 of 90

client’s application and its environment must be protected from malware as they access
the HSMs cryptographic services. Adequate logical and physical controls should be in
place to ensure that malware is detected.
Your Security Procedures should identify the measures required to ensure the physical
security (and counter any threats of theft or attack) of the nShield HSM, and associated
host/client/Remote File System (RFS) platforms, backup data, Security Information and
Event Management (SIEM) collectors and card readers.
Access to the nShield HSM, and associated host/client/RFS platforms, backup data, SIEM
collectors and card readers secure areas must:
•Only be provided to authorized individuals
•Only be provided when necessary
•Subject to audit control.
The nShield HSM and any card readers integrate with your infrastructure/network.
Therefore, any Security Policy requirements for the infrastructure/network must cover
the nShield HSM and card readers as well when operating within that
infrastructure/network.
The nShield HSM must be subject to protection against excessive processing demands.
The nShield HSM and any card readers must be subject to protection against
electromagnetic emissions if this is deemed to be a threat in the deployed environment.
Temperature range restrictions apply to the nShield Solo+, nShield Solo XC, nShield
Connect+ and nShield Connect XC when in operation. The HSMs must be located in well
ventilated locations (hosts or comms racks).
Voltage range restrictions apply to the nShield Solo XC and nShield Connect XC when in
operation. The HSMs must be protected with surge protection equipment.
To keep track of the nShield HSM and any card readers in your environment and aid any
investigation in the event of loss, an asset id should be assigned to the product and a
record of the nShield HSM and any card readers description, serial number and location
be entered against the asset id in an asset register.
nShield® Security Manual 12 of 90

4. Commissioning
The commissioning process covers installing and configuring an nShield HSM for live
operation. The commissioning process must be conducted by authorized individuals in a
secure environment as described in HSM environment controls.
4.1. Preparation
Prior to commissioning:
•Perform a threat analysis of your deployment environment or use an existing threat
analysis.
•Review the guidance in this Security Manual and determine the procedures and
configuration required for your systems to meet the threats identified in your threat
analysis. The requirements should be identified in a Security Policy so that all users
understand the controls that are necessary to operate the system securely.
•Any host operating systems should be a current, supported version with the latest
patches applied.
•It is recommended that anti-virus software is installed on the host system and
maintained with automatic updates.
•If KeySafe or a java-based client application is deployed then a version of Java as
advised in the Installation Guide with any available patches should be installed.
4.2. Installation
Entrust supplies standard component bundles that contain many of the necessary
components for your installation and, in addition, individual components for use with
supported applications. To be sure that all component dependencies are satisfied, you
can install either:
•All the software components supplied
•Only the software components you require.
During the installation process, you will be asked to choose which bundles and
components to install.
Your choice depends on a number of considerations, including:
•The types of application that are to use the module
•The amount of disc space available for the installation
•Your policy on installing software. While it may be simpler to choose all software
components, you may have a policy of not installing any software that is not required
nShield® Security Manual 13 of 90

to reduce the threat level for vulnerabilities arising in software (even if unused).
The integrity of the software CDs have SHA256 checksums applied to them. If you have
concerns over the integrity of a received software CD then the file checksums should be
verified with Support.
4.3. Hardware
4.3.1. Trusted Verification Device
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 nShield Trusted
Verification Device display.
4.3.2. Mode switch and jumper switches (nShield Solo only)
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.

You can set the remote mode override jumper switch on the circuit
board of the nShield Solo to the ON position to prevent mode change
using the nopclearfail command. This should be done if, for example, a
threat analysis determines that it may be possible for a remote
malicious or negligent user to interrupt operational service. In this
instance the security policies of your organization should require that
the physical mode switch must be used to authorize mode changes.
For example a trusted role holder has to be locally present to authorize
the change.
4.4. Network configuration
4.4.1. Firewall settings
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
nShield® Security Manual 14 of 90

and limit the IP addresses supported on those ports to the ones required.
4.4.2. Simple Network Management Protocol (SNMP)
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.
nShield® Security Manual 15 of 90

4.5. 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.
4.5.1. Set the nShield Solo and nShield Connect Real-Time Clock (RTC)
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.

The backup battery for the RTC on the nShield Solo and nShield Solo+
will only last for two weeks when the module is not powered. The RTC
must be reset on power up in such circumstances (i.e. RTC battery
exhaustion). See the nShield Solo and nShield Edge User Guide for
more information about resetting the clock.
4.5.2. 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 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.

NTP has featured many security vulnerabilities:
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:
•Using only NTP servers that are under the control of the customer,
i.e. within the customer’s enterprise
•Using multiple NTP sources to mitigate an attack on a single NTP
source or failure of that source. 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 synchronized time should be compared against
nShield® Security Manual 16 of 90

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.
4.5.3. Set the Host date and time (nShield Solo only)
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.
4.6. nShield Connect and client configuration
4.6.1. Configuring the Ethernet interfaces - IPv4 and IPv6
Dual Ethernet interfaces are supplied to support separate external and internal IP
address allocation if required by the security pollicy for the network configuration. They
cannot be bonded or otherwise used for redundancy. The second Ethernet port must be
disabled if not required (this is the default setting).
4.6.1.1. IPv6 Compliance
A sub-menu in the nShield Connect front panel menu permits you to select an IPv6
compliance mode for an nShield Connect. Compliance with USGv6 or IPv6 ready can be
selected.
Both these modes change the settings for the nShield Connect firewall so that it will
pass-through packets which are discarded in the normal default mode. This behaviour is
required for compliance testing but is not recommended for normal use since allowing
packets with invalid fields or parameters through the firewall increases the attack
surface. It is recommended that the IPv6 compliance mode is set to Default for all normal
operations.
4.6.2. Optionally configure hardserver interfaces
By default, the hardserver listens on all interfaces. However, you can alter the hardserver
settings. Altering the hardserver settings would prove necessary if, for example, you
wanted to 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. For security reasons, do not allow the hardserver to listen on
nShield® Security Manual 17 of 90

any interface that is connected to the public Internet.
4.6.3. Impath resilience
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 1 week. 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).
4.6.4. Configuring the RFS
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:
•IP Address
•ESN
•The hash of the KNETI.
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 Command Line Interface. 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 and the --setup --no
-authenticate option should not be used with the rfs-sync commands over insecure
networks as this does not authenticate the RFS which could give rise to a masquerade
attack.
If the cooperating clients that are required to access an RFS have either an nToken fitted,
or Software Key for secure authentication available, then the nToken’s or Software Key’s
KNETI (respectively) should be used to authenticate themselves over insecure networks.
4.6.5. Remote configuration
The module (hardserver) configuration file can be used to enable:
nShield® Security Manual 18 of 90

•Remote reboot
•Remote mode changes
•Remote upgrade. If this functionality is not required then it must be disabled.
4.6.6. Configuring a client to communicate with an nShield Connect
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. As an alternative mechanism nethsmenroll can be used without the ESN and
HKNETI parameters specified. nethsmenroll will attempt to recover them from the nShield
Connect and prompts for confirmation that they 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 the client recovered values. 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.
4.6.7. Configuring a client to communicate through an nToken
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.
nShield® Security Manual 19 of 90


If an nToken isn’t installed, then it is recommended to use software-
based authentication. If neither an nToken nor software-based
authentication is available for secure authentication, the client
connection relies solely on the nShield Connect validating the client’s IP
address against the configured value to authenticate the client. In this
instance the 'credentials' used by the nShield Connect to authenticate
the client are weaker than the 'credentials' used by the client to
authenticate nShield Connect. The method for authenticating the client
may be vulnerable to its IP address being spoofed by an attacker.
4.6.8. Configuring the serial console
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:
•Serial cable
•Serial port aggregator
•Administrator console
Logical access controls should be deployed to protect the following from unauthorized
access attempts:
•Serial console
•Serial port aggregator
•Administrator console
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
nShield® Security Manual 20 of 90