CE Crypto Module

Certificate

Approved Algorithms (26)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for CE Crypto 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>5.5.0</i>"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>update</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Self-test<br/>Show Status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    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?"]
    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["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>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"]
    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
  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,C5,C6 clue;
  class I1,I2,I3,I5,I6 infer;
  class R1,R2,R3,R5,R6 risk;
  class E1,E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for CE Crypto 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>5.5.0</i><br/>src: certificate.firmwareVersions"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>update</i><br/>src: text:keyword"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Self-test<br/>Show Status</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>application</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,C3 clueHigh;
  class C2,C5,C6 clueLow;

Security Policy, page by page

Senetas Corporation Ltd., distributed by Thales SA CE Crypto Module Module Version: 5.5.0 Level 1 Validation September 2024 Once released this document may be freely reproduced and distributed whole and intact www.senetas.com

1. General This is a non-proprietary FIPS 140-3 Security Policy for the Senetas Corporation Ltd. CE Crypto Module v.5.5.0. This Security Policy specifies the security rules under which the module operates to meet the FIPS 140-3 Level 1 requirements. The CE Crypto Module is used in a range of Senetas encryption appliances. The vendor distributes under their own Senetas brand, and jointly with their master worldwide distributor, Thales SA. FIPS 140-3 (Federal Information Processing Standards Publication 140-3), Security Requirements for Cryptographic Modules, specifies the security requirements for a cryptographic module utilized within a security system protecting sensitive but unclassified information. Based on four security levels for cryptographic modules, this standard identifies requirements in twelve sections. For more information about the NIST/CCCS Cryptographic Module Validation Program (CMVP) and the FIPS 140-3 standard, visit www.nist.gov/cmvp . This Security Policy, using the terminology contained in the FIPS 140-3 specification, describes how the CE Crypto Module complies with the twelve sections of the standard. In this document, the CE Crypto Module is more generally referred to as “the module”. This Security Policy contains only non-proprietary information. Any other documentation associated with FIPS 1403 conformance testing and validation is proprietary and confidential to Senetas Corporation Ltd. and is releasable only under appropriate non-disclosure agreements. For more information describing the module and associated platforms, visit http://www.senetas.com. Senetas Corp. Ltd. Version 1.01

1.1 References For more information on the FIPS 140-3 standard and validation program please refer to the National Institute of Standards and Technology website at www.nist.gov/cmvp. The following standards from NIST are all available via the URL: www.nist.gov/cmvp . [1] FIPS PUB 140-3: Security Requirements for Cryptographic Modules. [2] NIST Special Publication (SP) 800-140 FIPS 140-3 Derived Test Requirements (DTR). [3] NIST Special Publication (SP) 800-140A CMVP Documentation Requirements. [4] NIST Special Publication (SP) 800-140B CMVP Security Policy Requirements. [5] NIST Special Publication (SP) 800-140Crev2 CMVP Approved Security Functions. [6] NIST Special Publication (SP) 800-140Drev2 CMVP Approved Sensitive Security Parameter Generation and Establishment Methods. [7] NIST Special Publication (SP) 800-140E CMVP Approved Authentication Mechanisms. [8] NIST Special Publication (SP) 800-140F CMVP Approved Non-Invasive Attack Mitigation Test Metrics. [9] ISO/IEC 19790:2012(E), Information technology

• Security techniques
• Security requirements for cryptographic modules. [10] ISO/IEC 24759:2017(E), Information technology
• Security techniques
• Test requirements for cryptographic modules. [11] NIST Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program. [12] Advanced Encryption Standard (AES), Federal Information Processing Standards Publication 197. [13] Digital Signature Standard (DSS), Federal Information Processing Standards Publication 186-4. [14] Secure Hash Standard (SHS), Federal Information Processing Standards Publication 180-4. [15] NIST Special Publication (SP) 800-131Arev2, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths. [16] NIST Special Publication (SP) 800-90Arev1, Recommendation for Random Number Generation Using Deterministic Random Bit Generators. [17] NIST Special Publication (SP) 800-56Arev3 Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography. [18] Digital Signature Standard (DSS), Federal Information Processing Standards Publication 186-4. [19] NIST Special Publication (SP) 800-56Brev2, Recommendation for Pair-Wise Key-Establishment Schemes Using Integer Factorization Cryptography. [20] NIST Special Publication (SP) 800-108rev1 Recommendation for Key Derivation Using Pseudorandom Functions. [21] NIST Special Publication (SP) 800-56Crev2 Recommendation for Key-Derivation Methods in Key Establishment Schemes. [22] NIST Special Publication (SP) 800-90B, Recommendation for the Entropy Sources Used for Random Bit Generation. [23] NIST Special Publication (SP) 800-133rev2, Recommendation for Cryptographic Key Generation. [24] NIST Special Publication (SP) 800-67rev2, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher. [25] NIST Special Publication (SP) 800-135rev1, Recommendation for Existing Application-Specific Key Derivation Functions Senetas Corp. Ltd. Version 1.01

1.2 Acronyms and Abbreviations AES Advanced Encryption Standard AES-NI Advanced Encryption Standard New Instructions API Application Programming Interface CBC Cipher Block Chaining CCCS Canadian Centre for Cyber Security CFB Cipher Feedback CAVP Cryptographic Algorithm Validation Program CMVP Cryptographic Module Validation Program CNF Cloud Network Function CSP Critical Security Parameter CTR Counter Mode DH Diffie-Hellman DRBG Deterministic Random Bit Generator ECC Elliptic Curve Cryptography ECDH Elliptic Curve Diffie-Hellman ECDSA Elliptic Curve Digital Signature Algorithm ESV(NP) Non-Physical Entropy Source ESV Entropy Source Validation FIPS Federal Information Processing Standard GCM Galois Counter Mode HMAC Keyed-Hash Message Authentication Code IV Initialisation Vector KAS-ECC Elliptic Curve Key Agreement Scheme (ECDH) KAS-FCC Finite Field Key Agreement Scheme (DH) KAT Known Answer Test KDF Key Derivation Function NIST National Institute of Standards and Technology NVLAP National Voluntary Laboratory Accreditation Program OAEP Optimal Asymmetric Encryption Padding PAA Processor Algorithm Accelerator PKCS Public Key Cryptography Standards PSP Public Security Parameter PUB Publication RAM Random Access Memory RNG Random Number Generator RSA Rivest Shamir and Adleman Public Key Algorithm SP Special Publication SHA Secure Hash Algorithm SSP Sensitive Security Parameter TOEPP Tested Operational Environment Physical Perimeter VNF Virtual Network Function Senetas Corp. Ltd. Version 1.01

1.3 Security Levels The module meets the overall Security Level 1 requirements for FIPS 140-3. See Table 1 below, which indicates the security level of each of the twelve sections of the FIPS 140-3 standard. Table 1 Security Levels [Number Below] N/A N/A Senetas Corp. Ltd. Version 1.01

2. Cryptographic Module Specification The CE Crypto Module version 5.5.0 is a firmware cryptographic module running on a multi-chip standalone general-purpose compute platform. The module provides low-level cryptographic primitives to the overall platform and its functions. The Module exists as a number of shared libraries and is linked against various encryption applications to supply all cryptographic operations as required by those applications. Operational Environment 2.1 The module has been tested by the certification lab, Lightship Security, Inc. on the following platform with and without PAA: Table 2 Tested Operational Environments # In addition to the platforms listed in Table 2 above, Senetas Corporation has also tested the module on the following platforms and claims vendor affirmation on them: Table 3 Vendor Affirmed Operational Environments # Note: The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when ported onto an Operating Environment that is not listed on the validation certificate. 2.2 Modes of Operation The module only supports an approved mode of operation. Senetas Corp. Ltd. Version 1.01

2.3 Cryptographic Algorithms Approved Algorithms Table 4 lists the approved security functions of the module in the approved mode of operation. There are algorithms, modes, and key/moduli sizes that have been CAVP-tested but are 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. Table 4 Approved Algorithms Senetas Corp. Ltd. Version 1.01

Note 1: AES-ECB Is only validated as part of the AES-CTR validation. The mode is not actively used by the module. Note 2: The seeds used in the asymmetric key generation are from the unmodified output from the Approved NIST SP 800-90A DRBG. The module does not implement:

• Non-Approved Algorithms Allowed in the Approved Mode of Operation.
• Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed.
• Non-Approved Algorithms Not Allowed in the Approved Mode of Operation.

Whilst the module does not provide the TLS protocol (this protocol has not been reviewed or tested by the CAVP and CMVP) itself, it does supply the underlying cryptographic functionality required by TLS including AES-GCM. IG C.H Scenario 1a applies:

• The module conforms to TLSv1.2 GCM cipher suites as specified in SP 800-52rev2, Section 3.3.1. When the nonce_explicit part of the IV exhausts the maximum number of possible values for a given session key, the module will trigger a handshake to establish a new encryption key according to RFC 5246. In case the module’s power is lost and then restored, a new key for use with the AES-GCM encryption/decryption shall be established. Senetas Corp. Ltd. Version 1.01

2.4 Cryptographic Boundary The CE Crypto Module is a firmware library, providing user space based cryptographic primitives for use by the wider system. The cryptographic boundary is depicted in the diagram below. TOEPP Figure 1 Cryptographic Boundary Block Diagram Senetas Corp. Ltd. Version 1.01

3. Cryptographic Module Interfaces As a firmware only module, the module does not have any physical ports. Any reference to physical ports refers to that hardware on which the module is operating and outside of the cryptographic boundary. With regard to logical interfaces, the cryptographic API (C programming language) delineates the module interfaces. Table 5 Ports and Interfaces Senetas Corp. Ltd. Version 1.01

4. Roles, Services and Authentication The cryptographic module supports a single role of Crypto Officer. No authentication mechanism is provided, this aligns with the requirements for a FIPS 140-3 Level 1 module. The Crypto Officer has access to all approved services. The “Roles and Authentication” table listed in SP 800-140B is not applicable. 4.1 Supported Roles The supported role and services are summarized in Table 6 Table 6 Roles, Service Commands, Input and Output N/A Senetas Corp. Ltd. Version 1.01

4.2 The CE Crypto Module supports the Crypto Officer services listed in the following table. Legend for access rights column in Table 7: G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g. the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. N/A - Not Applicable. Approved Services The module supports the approved services listed in Table 7. Table 7 Approved Services W, E G, R, E W, E G, R, E W, E G, R, W, E G, R, W, E N/A W, E Senetas Corp. Ltd. Version 1.01

G, R, E G, R, W, E Unencapsulati W, E W, E Run selftests N/A N/A N/A N/A Z Senetas Corp. Ltd. Version 1.01

5. Software/Firmware Security 5.1 Software/Firmware Integrity Test The approved SHA-256 algorithm implemented in the module is used to verify the integrity of the module. If this integrity test fails, the module is prevented from providing any cryptographic services and the module is effectively disabled. Refer to Section 10.1 for more detail. On Demand Software/Firmware Integrity Test On demand testing can be initiated by rebooting the module’s host platform. Senetas Corp. Ltd. Version 1.01

6. Operational Environment The module is designed to operate as a component of a larger general-purpose operating system. The operational environment is non-modifiable. Senetas Corp. Ltd. Version 1.01

7. Physical Security The module is a firmware module with a multi-chip standalone cryptographic embodiment. The module's host platform provides production-grade components and chassis, using standard passivation. Senetas Corp. Ltd. Version 1.01

8. Non-Invasive Security The requirements in this section are Not Applicable. Senetas Corp. Ltd. Version 1.01

9. Sensitive Security Parameter Management 9.1 Cryptographic Keys and SSPs The following table identifies the Cryptographic Keys and Sensitive Security Parameters (SSPs) employed within the module. Table 8 SSPs N/A N/A N/A N/A N/A N/A Senetas Corp. Ltd. Version 1.01

N/A N/A N/A N/A Senetas Corp. Ltd. Version 1.01

N/A N/A N/A N/A N/A N/A N/A N/A N/A Senetas Corp. Ltd. Version 1.01

9.2 Random Number Generation/Entropy An approved NIST [SP800-90A] deterministic random bit generator using a hash based DRBG (SHA-256) is used. The DRBG is seeded via a Linux Inter Process Communication (IPC) pipe (/tmp/sp80090bd), which in turn is filled via a user space daemon that utilises the software-based CPU jitter library (https://www.chronox.de/jent.html). The user space daemon ensures a watermark entropy pool is maintained for seeding the DRBG. Based on testing and analysis, the estimated minimum amount of entropy per output bit is 1.0 bits. The overall amount of generated entropy meets the required security strength of 256 bits based on the entropy per bit and the amount of entropy requested by the module. Table 9 Non-Deterministic Random Number Generation Specification Senetas CPU Jitter Entropy Source

The module employs a software based random bit generator ESV E49 Senetas Corp. Ltd. Version 1.01

The module performs pre-operational self-tests and conditional self-tests to assure that faults have not been introduced that would prevent the module’s correct operation. 10.1 10.2 The module performs a set of Conditional Cryptographic Algorithm Self-Tests. These Conditional Cryptographic Algorithm Self-Tests run in the pre-operational state. The cryptographic algorithm used to perform the approved integrity technique for the Pre-Operational Software/Firmware Integrity Test (listed in Table 10, below), is tested using a Cryptographic Algorithm Self-Test A Conditional Pair-wise Consistency Test is performed on asymmetric key pairs generated by the module (refer to Table 10 below). 10.3 On-Demand and Periodic Self-tests The Crypto Officer can initiate the Pre-Operational Self-Test and Conditional Cryptographic Algorithm Self-Tests on-demand and for periodic testing of the module by issuing a reboot of the module’s host operating system.

Failure of the Pre-Operational Self-Test or any of the Conditional Cryptographic Algorithm Self-Tests will cause the module to remain in the pre-operational state (or error state). Once all of the self-tests have passed the preoperational flag is removed and the module will transition to the operational state. The self-tests are detailed in Table 10. Table 10 Self-Tests Cryptographic Algorithm Self-Tests Senetas Corp. Ltd. Version 1.01

Senetas Corp. Ltd. Version 1.01

11. Life-cycle Assurance The module is part of a larger Senetas encryption platform distributed on a range of comparable compute devices as a complete Linux distribution and set of services, and as such is installed as part of the encompassing Senetas encryption application. The development and operational processes around which the module is supported are strictly controlled across the complete development life cycle and supply chain and externally audited for correctness. Senetas Corp. Ltd. Version 1.01

12. Mitigation of Other Attacks The requirements in this section are Not Applicable. Senetas Corp. Ltd. Version 1.01

Referenced URLs

• www.senetas.com
• www.nist.gov/cmvp
• https://www.chronox.de/jent.html