nShield 5s Hardware Security Module

Certificate

Approved Algorithms (55)

Security Levels (Table 1)

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for nShield 5s Hardware Security Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>uboot-version 1.1.0 and uboot-version 1.4.1</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>updater receive<br/>updater load<br/>receive</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>nCoreAPI Show Status<br/>getlog<br/>python- zeroconf</i>"]
    C4["[high] Physical/logical<br/>interfaces (some 'blocked<br/>in firmware')<br/><i>PCIe bus<br/>Smartcard reader serial port</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>linux<br/>uboot<br/>bootloader</i>"]
  end
  subgraph Inference["Derived inference"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I4["Interface reachability may<br/>vary by boot stage and<br/>lifecycle state."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R4["Are interfaces blocked<br/>before the bootloader<br/>runs, or only after<br/>approved mode starts?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E4["lifecycle reachability<br/>matrix · boot-stage<br/>interface timing ·<br/>factory/recovery/error-state<br/>access controls"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C1 --> I1 --> R1 --> E1
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C4 --> I4 --> R4 --> E4
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C1,C2,C3,C4,C5,C6 clue;
  class I1,I2,I3,I4,I5,I6 infer;
  class R1,R2,R3,R4,R5,R6 risk;
  class E1,E2,E3,E4,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for nShield 5s Hardware Security Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>uboot-version 1.1.0 and uboot-version 1.4.1</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>updater receive<br/>updater load<br/>receive</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>nCoreAPI Show Status<br/>getlog<br/>python- zeroconf</i><br/>src: securityPolicy.services"]
    C4["[high] Physical/logical interfaces (some 'blocked in firmware')<br/><i>PCIe bus<br/>Smartcard reader serial port</i><br/>src: securityPolicy.portsAndInterfaces"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>linux<br/>uboot<br/>bootloader</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C1,C2,C3,C4 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

nShield 5s Hardware Security Module ``

Version: 1.0.5 Date: 08/01/2025 not been removed or altered. Words and logos marked with ® or ™ are trademarks of nCipher Security Limited or its affiliates in the EU and other countries. Mac and OS X are trademarks of Apple Inc., registered in the U.S. and other countries. Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries. Information in this document is subject to change without notice. nCipher Security Limited makes no warranty of any kind with regard to this information, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. nCipher Security Limited shall not be liable for errors contained herein or for incidental or consequential damages concerned with the furnishing, performance or use of this material. Where translations have been made in this document English is the canonical language. nCipher Security Limited Registered Office: One Station Square, Cambridge, CB1 2GA, United Kingdom Registered in England No. 11673268 nCipher is an Entrust company. Entrust, Datacard, and the Hexagon Logo are trademarks, registered trademarks, and/or service marks of Entrust Corporation in the U.S. and/or other countries. All other brand or product names are the property of their respective owners. Because we are continuously improving our products and services, Entrust Corporation reserves the right to change specifications without prior notice. Entrust is an equal opportunity employer.

nShield 5s Hardware Security Module

Contents nShield 5s Hardware Security Module

Security Module, i.e. the Cryptographic Module, to meet with the security requirements in FIPS 1403 and ISO/IEC 19790. The Cryptographic Module meets overall FIPS 140-3 Security Level 3. The following table specifies the security level in detail. N/A N/A N/A [Number Below] Table 1 Security levels

nShield 5s Hardware Security Module

The following product hardware variants and firmware version(s) are in scope of this Security Policy. PCA10005HSMi Table 2 Cryptographic Module Tested Configuration

The nShield 5s Hardware Security Module (HSM) is a multi-chip embedded hardware Cryptographic Module as defined in FIPS 140-3, which comes in a PCI express board form factor protected by a tamper resistant enclosure, and performs 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. The nShield 5s HSM is also embedded inside the nShield 5c or the nShield HSMi, which are networkattached appliances delivering cryptographic services as a shared network resource for distributed applications and virtual machines, giving organizations a highly secure solution for establishing physical and logical controls for server-based systems. The table below shows the nShield 5s HSM (left, representative of the two hardware variants nC5536E,

Figure 1 nShield 5s (left) and nShield 5c (right) The cryptographic boundary is delimited in red in the images in the table below. It is delimited by the heat sink and the outer edge of the potting material on the top and bottom of the PCB. Figure 2 Cryptographic module physical boundary The module enforces that only approved services are available and plaintext import/export of secret or private keys is not allowed. Refer to Approved mode of operation.

This section describes the cryptographic mechanisms and security functions provided and used by the cryptographic module. 2.3.1 Approved algorithms The following tables describe the approved cryptographic algorithms supported by the Cryptographic Module. Note: All AES symmetric key sizes have equivalent strength. 2.3.1.1 nCore crypto

nShield 5s Hardware Security Module

n/a n/a n/a n/a n/a n/a nShield 5s Hardware Security Module

nShield 5s Hardware Security Module

Table 3 nCore - Approved Algorithms Note: For AES GCM, the 96-bit IV is internally generated using the approved DRBG as per IG C.H. Note: ECDSA SigVer with P-192 has been CAVP-tested but is not used by any approved service of the module. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in this table are used by an approved service of the module. 2.3.1.2 Bootloader crypto n/a Table 4 Bootloader - Approved Algorithms nShield 5s Hardware Security Module

2.3.1.3 SSH crypto 800symmetric keys n/a n/a n/a n/a 80056Arev3] Table 5 SSH - Approved Algorithms Note: As per IG D.C., no parts of this protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. Note: For AES GCM, the module is compliant with RFCs 4252, 4253 and 5647, and the IV is generated according to the SSHv2 protocol IV generation, as per IG C.H. In case the module’s power is lost and then restored, a new key for use with the AES-GCM encryption/decryption is established.

nShield 5s Hardware Security Module

2.3.2 Allowed algorithms The following table describes the allowed cryptographic algorithms supported by the Cryptographic Module. 2.3.2.1 nCore crypto

• Table 6 nCore - Non-Approved Algorithms Allowed in the Approved Mode of Operation 2.3.3 Non-approved algorithms Only approved and non-approved but allowed cryptographic algorithms are supported. nShield 5s Hardware Security Module

The Cryptographic Module provides the following physical ports:

• Battery (including external backup battery power supply) The following table maps the FIPS logical interfaces and physical ports to the module´s services n/a n/a n/a n/a Table 7 Ports and Interfaces Note: Control output is omitted because the module does not implement it. The following figure shows the module’s physical ports: Figure 3 Physical ports

nShield 5s Hardware Security Module

The Cryptographic Module supports the following roles:

• Platform Crypto Officer (PCO)
• nShield Security Officer (NSO)
• User Client (UC) Platform Crypto Officer (PCO) This role is responsible of administration tasks of the HSM platform. To assume this role, an operator needs to open a session with the SSHAdmin, Updater, Setup or Monitor services, using its SSH private key for each service. When the module is in factory state, the SSHAdmin client SSH keys are set to a default value. These keys must be changed with the SSHAdmin set service before the module can be initialized and used. nShield Security Officer (NSO) This role is represented by Administrator Card holders, which have access to KNSO and are responsible for the overall management of a Security World. To assume this role, an operator or group of operators need to present a quorum m of N of smartcards, and the KNSO Key Blob. Each operator is identified by its individual smartcard, which contains a unique logical token share. NSO smartcard sets are initialized at Security World creation User Client (UC) This role is authorised to use the general purpose cryptographic services offered by the cryptographic module. To assume this role, a client application needs to open a session with the nCoreAPI service, using its SSH private key. The client application’s SSH public key must have been previously loaded into the module by the PCO using the SSHAdmin service. nShield 5s Hardware Security Module

nShield 5s Hardware Security Module

nShield 5s Hardware Security Module

Table 8 Roles, Service Commands, Input and Output

nShield 5s Hardware Security Module

The following table describes the services provided by the Cryptographic Module and the access policy. The Access column presents the access level given to the SSP G = Generate: The module generates or derives the SSP. E = Execute: The module uses the SSP in performing a cryptographic operation. 4.2.1 / / nShield 5s Hardware Security Module Z E G

/ / Table 10 Approved Services as they only use approved mechanisms. 4.2.2 E E R R E Table 11 Approved Services

nShield 5s Hardware Security Module

as they only use approved mechanisms. 4.2.3 Updater service E E E E E Table 12 Approved Services as they only use approved mechanisms. 4.2.4 Monitor service Table 13 Approved Services as they only use approved mechanisms. nShield 5s Hardware Security Module

4.2.5 Discovery service pythonzeroconf Table 14 Approved Services as they only use approved mechanisms. 4.2.6 nCoreAPI service R E E R Z

nShield 5s Hardware Security Module

R E E E E nShield 5s Hardware Security Module

nShield 5s Hardware Security Module

Z, G G, E G nShield 5s Hardware Security Module W R, W

R R, E R, E G, E E nShield 5s Hardware Security Module Z

W W E E E Table 15 Approved Services Non-approved services will fail with a return an error code indicator "StrictFIPS140".

nShield 5s Hardware Security Module

All nCore API services are sent through the SSH channel, performing security functions Data encryption/decryption, MAC generation / verification and access E (execute) of the session keys KSESSION - SSH. nShield 5s Hardware Security Module

The nShield 5s cryptographic module's executable code is delivered by Entrust as a single signed firmware package (.npkg file). The bootloader and firmware integrity is verified at start up using RSA with 4096 bit key and SHA2-256. The Library Partition is an internal storage area that contains a number of auxiliary files required for operation of the module. The integrity of the Library Partition is verified using ECDSA with curve P-521 and SHA2-512. Operators can initiate the integrity tests on demand by restarting the module.

nShield 5s Hardware Security Module

Not applicable. The module has a limited operational environment, it is designed to accept only controlled firmware changes that successfully pass the software/firmware load test. nShield 5s Hardware Security Module

The product is a multi-chip embedded Cryptographic Module, as defined in FIPS 140-3. It is enclosed 3. The cryptographic module implements Environmental Failure Protections (EFP) which detect out of Table 16 Physical Security Inspection Guidelines 0ºC a Table 17 EFP/EFT 0ºC Table 18 Hardness testing temperature ranges

nShield 5s Hardware Security Module

Not applicable. nShield 5s Hardware Security Module

This section defines the Sensitive Security Parameters (SSPs) managed by the cryptographic module. 9.1.1 Platform SSPs n/a n/a

nShield 5s Hardware Security Module

n/a n/a n/a n/a n/a n/a > nShield 5s Hardware Security Module

n/a n/a Table 19 Platform SSP table 9.1.1.1 Service SSPs The following SSPs are related to the nCore API service. & n/a n/a Table 20 nCoreAPI SSP table

nShield 5s Hardware Security Module

9.1.1.2 Security World SSPs The following SSPs are related to the Security World in which the cryptographic module is enrolled into. e h t t y

• nShield 5s Hardware Security Module y ≥ y
• .

e h t t n/a n/a 80090Arev1 n/a n/a 80090Arev1. Table 21 Security World SSP table As per IG 9.7.B, the zeroisation of SSPs is explicitly indicated by the successful return code of the setup factorystate command. Temporary SSPs are zeroised implicitly. nShield 5s Hardware Security Module

Zeroization of all unprotected SSPs keys occurs immediately when the module is reset to the factory state with the setup factorystate command. The cryptographic module has a hardware based true random number generator used to seed the DRBGs.

The Cryptographic Module performs pre-operational, conditional and periodic self-tests. It also supports pre-operational self-tests on demand by resetting the module. In the event of a self-test failure, the module enters the error state. While in this state, the module does not process any commands, and will indicate the error on the status LED and the error log, which can be retrieved with the command monitor getlog.

At start up, the following integrity tests are performed:

• #A6385), using NSBIK public key.
• #A6385), using NFIK public key.
• The library partition integrity is verified using ECDSA with curve P-521 and SHA2-512 (Cert. #A2513), using NLIK public key.

The following cryptographic algorithm self tests (CASTs) are run before the first use of any cryptographic mechanism. nShield 5s Hardware Security Module

At start up, the SP 800-90B Adaptive Proportion Test and Repetition Count Test are run on the output bits of the entropy source. These tests are also run continuously during operation of the entropy source.

The module performs a pair-wise consistency test when RSA (Cert. #A2513), DSA (Cert. #A2513), generated.

Prior to updating the firmware, the cryptographic module validates the integrity and authenticity of the image update package. The module performs the following actions before replacing the current image:

nShield 5s Hardware Security Module

• Code signature verification with NPSK pub. The signature algorithm is ECDSA with SHA2-512 using the P-521 curve (Cert. #A2513).
• Verification that the Version Security Number (VSN) of the new image is not less than the VSN of the current image. This check is done for roll-back protection. Note: A firmware image version loaded into this module that is not shown on the module certificate is out of the scope of this validation and requires a separate FIPS 140-3 validation.

The following self tests are run periodically every 24 hours:

• nCore crypto (Cert. #A2513) and SSH crypto (Cert. #A2512) self tests
• SP 800-90B health tests As per IG 10.3E Resolution #3 c), the bootloader is designed exclusively to launch the main firmware for the module. In this architecture, as the module isn’t complete until the main firmware is launched (replacing the bootloader in executable memory), it is redundant that the bootloader itself implement a mechanism to run periodic tests. nShield 5s Hardware Security Module

This section provides specific FIPS-related guidance to Administrators and Operators. This guidance is aimed to complement the product user and installation guides which are delivered with the cryptographic module.

The nShield cryptographic module is sent to the customers using a standard carrier service. After accepting the delivery of the module, a physical inspection of the module shall be performed (refer to Physical Security section). This inspection is done to ensure that the module has not been tampered with during transit. If the inspection results indicate that the module has not been tampered with, the Administrator can then proceed with installation and configuration of the module. The cryptographic module supports firmware upgrades in the field, which are provided by Entrust as a single signed firmware package (.npkg file).

This section provides instructions to inspect the cryptographic module´s fw and hw version information and ensure they correspond with the FIPS 140-3 validated versions.

The cryptographic module provides the service updater info which provides firmware version information in JSON format. Entrust provides the hsmadmin status command-line utility which calls the service updater info internally. hsmadmin status --json { "D5DE-E1F8-D6E7": { "succeeded": true, "data": { "mode": "primary", "uboot-version": "1.1.0-1245-b9bedfa" } } } The following fields in the output must be checked:

nShield 5s Hardware Security Module

The cryptographic module provides the command Cmd_NewEnquiry which reports hardware version information. Entrust provides the enquiry command-line utility which calls Cmd_NewEnquiry internally. The following fields in the output must be checked: Alternatively, the cryptographic module also provides the service setup info which provides hardware version information in JSON format. Entrust provides the hsmadmin info command-line utility which calls the service setup info internally. hsmadmin info --json { "15C8-4387-C748": { "eeprom": { ... , "buildpart": , "buildrev": { "value": "03", "crc": xxxxx } ... } } The following fields in the output must be checked: nShield 5s Hardware Security Module

To configure the cryptographic module in approved mode, the following steps are performed:

1. When the cryptographic module is in factory state, it first needs to be initialized with the Entrust supplied utility hsmadmin enroll.
2. Create a FIPS 140-3 level 3 compliant Security World using the Entrust supplied utility newworld, setting the mode to fips-140-level-3, e.g. new-world --mode=fips-140-level-3 An operator can verify that the module is configured in approved mode with the command line utility enquiry, which reports the following active modes: active modes StrictSP80056Ar3 UseFIPSApprovedInternalMechanisms FIPSLevel3Enforcedv2 Once a FIPS 140-3 level 3 Security World is created, it is not possible to switch into a non-compliant mode without first zeroising the unprotected SSPs.

Per FIPS 140-3 section 7.11.8, in the event that the module is no longer deployed or intended for further use, the Crypto Officer shall zeroize and destroy the module. The module shall be taken to an electronics recycling facility that offers (and assures) the physical destruction of e-waste.

nShield 5s Hardware Security Module

Not applicable. nShield 5s Hardware Security Module

Contact Us Web site https://www.entrust.com Support https://nshieldsupport.entrust.com Email Support nShield.support@entrust.com Online documentation: Available from the Support site listed above. You can also contact our Support teams by telephone, using the following numbers: Europe, Middle East, and Africa United Kingdom: +44 1223 622 444 One Station Square Cambridge CB1 2GA UK Americas Toll Free: +1 833 425 1990 Fort Lauderdale: +1 954 953 5229 Sawgrass Commerce Center

• A Suite 130,

Sunrise FL 33323 USA Asia Pacific Australia: +61 9126 9070 World Trade Centre Northbank Wharf Siddeley St Melbourne VIC 3005 Australia Japan: +81 50 3196 4994 Hong Kong: +852 3008 4994 31/F, Hysan Place

Causeway Bay Hong Kong

nShield 5s Hardware Security Module

To get help with Entrust nShield HSMs nShield.support@entrust.com nshieldsupport.entrust.com ABOUT ENTRUST CORPORATION Entrust keeps the world moving safely by enabling trusted identities, payments and data protection. Today more than ever, people demand seamless, secure experiences, whether they’re crossing borders, making a purchase, accessing egovernment services or logging into corporate networks. Entrust offers an unmatched breadth of digital security and credential issuance solutions at the very heart of all these interactions. With more than 2,500 colleagues, a network of global partners, and customers in over 150 countries, it’s no wonder the world’s most entrusted organizations trust us.

Referenced URLs

• https://www.entrust.com
• https://nshieldsupport.entrust.com