IPC Cryptographic Module

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for IPC Cryptographic Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth</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>operating system<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I3["Possible only, some<br/>services may process input<br/>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"]
    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"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>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
  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 C3,C5,C6 clue;
  class I3,I5,I6 infer;
  class R3,R5,R6 risk;
  class E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for IPC Cryptographic Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth</i><br/>src: text:keyword"]
    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>operating system<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 C3,C5,C6 clueLow;

Security Policy, page by page

ST Engineering Urban Solutions Ltd. IPC Cryptographic Module This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

Validated is the term given to a module that is documented and tested against the FIPS 140-3 criteria. More information is available on the CMVP website at: https://csrc.nist.gov/projects/cryptographic-module-validation-program. About this Document (hereafter referred to as “the Module”) from ST Engineering Urban Solutions Ltd. It contains specifications of the security rules under which the Module operates, including the security rules derived from the requirements of the FIPS 140-3 standard. This document may be freely reproduced and distributed whole and intact including this The following table lists the level of validation for each area in FIPS 140-3:

The Section 7.7 Physical Security and Section 7.8 Non-Invasive Security from ISO 19790 do not apply to the module.

This document may be freely reproduced and distributed in its entirety without modification.

Purpose and Use: The module is intended to execute within the IPC device and provide cryptographic services. Module Type: Software Module Embodiment: MultiChipStand Cryptographic Boundary: The cryptographic boundary is as depicted in Figure 1. No components are excluded from the cryptographic boundary. The module supports an Approved mode and a non-Approved mode of operation. The module does not support a degraded mode. Tested Operational Environment’s Physical Perimeter (TOEPP): The block diagram of the Module is depicted in Figure 1 (blue outlined). The Tested Operational Environment’s Physical Perimeter (TOEPP) is the underlying host platform i.e. IPC device on which it runs. The operating environment of the module is modifiable since the platform does support modifications to it. This document may be freely reproduced and distributed in its entirety without modification.

Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets): This document may be freely reproduced and distributed in its entirety without modification.

Table 2: Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets) Tested Operational Environments - Software, Firmware, Hybrid: Table 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: No environments have been vendor affirmed.

No components have been excluded. Modes List and Description: Table 4: Modes List and Description

1. The module does not support manual SSP entry.
2. The module inhibits data output during self-test execution, zeroisation, SSP generation and upon entry into the error state. This document may be freely reproduced and distributed in its entirety without modification.

3. In the event of a self-test failure, all calls made to the module to request services from it are rejected by the module. The Module is shipped with the Approved mode pre-enabled as noted in Section
4. No further configuration is required. Mode Change Instructions and Status: The module is in the Approved mode of operation provided the Approved algorithms and NonApproved Algorithms Allowed in the Approved Mode are used. Usage of the non-Approved Algorithms Not Allowed in the Approved Mode causes the module to transition to the nonApproved mode. Degraded Mode Description: A degraded mode of operation is not supported by the module.

Approved Algorithms: This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

Table 5: Approved Algorithms Vendor-Affirmed Algorithms: Table 6: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: This document may be freely reproduced and distributed in its entirety without modification.

Table 7: Non-Approved, Allowed Algorithms Non-Approved, Allowed Algorithms with No Security Claimed: The module does not support any Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed. Non-Approved, Not Allowed Algorithms: C.M 3.e This document may be freely reproduced and distributed in its entirety without modification.

3.e) Table 8: Non-Approved, Not Allowed Algorithms

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

Table 9: Security Function Implementations

a. AES-GCM Usage The AES GCM IV computation must comply with IG C.H and NIST SP 800-38D Scenario 1(a), tested per option (ii) under C.H TLS 1.2 protocol IV generation per RFC7627, Scenario 1(d) SSHv2 per RFC4252, RFC4253 and RFC5647 and Scenario 5 TLS 1.3 per RFC8446. The Module does not implement the TLS 1.3 and SSH protocols itself, however, it provides the cryptographic functions required for implementing these protocols. The module does implement the TLS 1.2 protocol. AES GCM encryption is used in the context of the SSH and TLS protocol versions 1.2 and 1.3 and the IV computed shall only be used within the protocols. The module provides the primitives to support the AES GCM cipher suites per NIST SP800-52r1 Section 3.3.1. The module’s implementation of AES-GCM is used together with an application that runs outside the module’s cryptographic boundary in case of TLS 1.3 and SSH protocols. The application negotiates the protocol session’s keys and the 32-bit nonce value of the IV. When the IV exhausts the maximum number of possible values for a given session key (2^64 - 1), this results in failure in encryption and a handshake to establish a new encryption key will be required. It is the responsibility of the user of the module, i.e., the first party, client or server, to encounter this condition, to trigger this handshake in accordance with the TLS/SSH protocol. The Module also supports internal IV generation using the module’s approved DRBG. The IV is at least 96 bits in length per NIST SP800-38D Section 8.2.2. Per IG C.H Scenario 2 and NIST SP800-38D, the approved DRBG generates outputs such that the (key, IV) pair collision probability is less than 2^-32. For all cases of IV generation, in the event that the module power is lost and restored the user must ensure that the AES GCM encryption/decryption keys are redistributed/re-established in accordance with IG C.H Scenario 3. The module does not support persistent storage of SSPs. This document may be freely reproduced and distributed in its entirety without modification.

The Module also supports importing of GCM IVs when an IV is not generated within the Module. In the approved mode, an IV must not be imported for encryption from outside the cryptographic boundary of the Module as this will result in a non-conformance. This is in accordance with IG 2.4.A: “If the module operator (e.g., calling application) can do things outside of the module’s control/visibility that can take an otherwise approved algorithm and use it in a non-approved way (e.g., use PBKDF and/or AES XTS outside of storage applications), the corresponding module service may still be considered approved (and if so, shall have an approved indicator per AS02.24) and the Security Policy shall clarify how to use the service in an approved manner (per ISO 19790 B.2.2 on Overall security design and the rules of operation).” b. AES-XTS Usage Usage In accordance with NIST SP800-38E, the XTS-AES algorithm shall only be used for confidentiality on storage devices. The Module complies with IG C.I by explicitly checking that Key_1 ≠ Key_2 before using the keys in the XTS-AES algorithm to process data with them. The module implements CKG per NIST SP 800-133r2 Section 6.3. c. Legacy Usage The module supports the following implementations for legacy use/support per NIST SP 800-131Ar2: • FIPS 186-4/5 RSA (modulus 1024 bits), ECDSA (B-163, K-163 and P-192, curves) digital signature verification providing less than 112 bits of security strength. Legacy usage only. These legacy algorithms can only be used on data that was generated prior to the Legacy Date specified in IG C.M. d. Component Validation List (CVL) In accordance with IG 2.4.B, all tested components have been marked with the “CVL” notation in Table 5 and all vendor affirmed algorithms have been listed in Table 6. Also, per IG 2.4.B, the RSASP i.e. RSA SigGen (CVL) shall only be used within the context of a FIPS 186-5 signature generation. e. PBKDF Usage The module is compliant with IG D.N and NIST SP 800-132 Section 5.4 Option 1a. The iteration count values used range from 1 to 10000 per NIST SP 800-132 Section 5.2 whereby the iteration count shall be selected as large as possible, as long as the time required to generate the key using the entered password is acceptable for the users. The derived key must possess a minimum security strength of 112 bits. The module implements CKG per NIST SP 800-133r2 Section 6.2.2. In accordance with NIST SP 800-132 requirements, usage of the derived keys shall be restricted to storage applications alone. The module supports a minimum 1-character long password. The ASCII system comprises of 94 printable characters (letters, digits, punctuation, and symbols). For a 1character password/passphrase chosen from 94 printable ASCII characters, the total combinations are: 94^1. Thus, the probability of guessing the correct password/passphrase on a random attempt is: 1/94^1 ~ 0.01063. This document may be freely reproduced and distributed in its entirety without modification.

The module being a software module does not restrict the usage of a password/string used as the password and input to the PBKDF. The onus is on the calling application to provide a password of an appropriate length based on the intended security strength (and size) of the key to be derived. In accordance with NIST SP 800-132, passwords shorter than 10 characters are usually considered to be weak. There are many other properties that may render a password weak. For example, it is not advisable to use sequences of numbers or sequences of letters as passwords. Easily accessed personal information, such as the user’s name, phone number, and date of birth, should not be used directly as a password. Passphrases frequently consist solely of letters, but they make up for their lack of entropy by being much longer than passwords, typically 20 to 30 characters. Passphrases shorter than 20 characters are usually considered weak. f. FIPS 202 Usage Per IG C.C Resolution 2.a., each SHA-3 and SHAKE function has been tested and validated the module’s operational environment. g. RSA Usage

• Per IG C.E and IG C.F, the RSA SigGen and SigVer implementations have been tested for all implemented RSA modulus lengths where CAVP testing is available. The module supports generation of RSA keys with the following untested approved moduli/sizes: 4096 <nlen<= 16384. The module also supports the following untested, approved moduli for the RSA SigGen and SigVer: 4096 <nlen<= 16384.
• Per IG C.F Additional Comment 1.e: The elliptic curves used in the key agreement scheme provide more than 112 bits of security as seen in the KAS entries per Table 10.
• Per IG C.F Additional Comment 2: The KAS-ECC-SSC and KAS-FFC-SSC implementations support Diffie-Hellman based key agreement schemes. h. TLS 1.2 KDF Per IG D.Q, the module is compliant with RFC 7627 and is designed to enforce the usage of the extended master secret in the TLS 1.2 KDF. i. NIST SP 800-108 KDF Usage Per IG D.M, the SP 800-108 KDF is not used to generate asymmetric keys by the module. For keys provided by the calling application, the onus lies on the former to ensure that the keys have been generated using approved methods. The module supports CKG per NIST SP 800-133r2 Section 6.2.3.

The Module complies with IG 9.3.A Scenario 2. b. and relies on the use of a NIST SP800-90B compliant entropy source outside the cryptographic boundary. The onus is on the calling This document may be freely reproduced and distributed in its entirety without modification.

application to ensure the use of an NIST SP800-90B compliant entropy source and of sufficient entropy for the required security strength. The minimum number of bits of entropy, depending on the target security strength of generated SSPs is 128, 192 or 256 bits. If the Counter DRBG implementation without the derivation function enabled is used, ensure full entropy from the entropy source is provided. The following caveat applies to the module: No assurance of the minimum strength of generated SSPs (e.g., keys).

The module contains NIST SP 800-90Ar1 DRBGs and supports the NIST SP 800-133r2 (CKG) sections 4, 5.1, 5.2, 6.1, 6.2 and 6.3.

The module supports key agreement and key transport in the context of the TLS protocol. Apart from this, it also provides cryptographic primitives in support of key agreement and key transport where the onus is on the calling application to ensure that the primitives are used in the correct sequence. The module does not establish SSPs using an approved key transport scheme (KTS). However, it does offer approved authenticated algorithms that can be used by an external operator/application as part of an approved KTS (KTS-1, KTS-2, KTS-3 and KTS-4). In addition to the TLS case, the following applies to the module for SSP agreement: The module does not establish SSPs using an approved key agreement scheme (KAS). However, it does offer some or all of the underlying KAS cryptographic functionality to be used by an external operator/application as part of an approved KAS (KAS-1, KAS-2 and KAS-3). Per IG D.F: The module supports Key Agreement Schemes per NIST SP800-56Ar3 and IG D.F Scenario 2 (path 1) and NIST SP800-56Br2 and IG D.F Scenario 1 (path 1). The KAS-1, KAS-2, KAS-3 in the SFI Table 10 have been documented accordingly. The Approved Algorithm list includes the tested components (KAS-ECC-SSC, KAS-FFC-SSC and KAS-IFC-SSC) as individual entries. The Module obtains the IG D.F required key agreement assurances: NIST SP800-56Ar3 in accordance with Section 5.6.2. NIST SP800-56Br2 in accordance with Section 6.4. The module also supports key agreement in the context of the IETF TLS 1.2 protocol in accordance with IG D.F Scenario 2 (path 2) and the KAS-4 entry corresponds to the same. Per IG D.G: The module supports the Key Transport per NIST SP 800-56Br2 (RSA-OAEP) denoted by KTS-

4 in the SFI Table 10. This notation is in accordance with the IG D.G Additional Comment 4:

“The FIPS 140-3 annotation details for the approved or allowed key transport schemes (KTS) can be found on SP 800-140B: CMVP Security Policy Requirements (see MIS Guidance “KTS”).”. This document may be freely reproduced and distributed in its entirety without modification.

The module also supports the following untested approved moduli for KTS-4: 6144 < nlen <=16384, where nlen denotes the modulus. The RSA modulus sizes and key generation method have been documented in the table as well. The module can also optionally be used in the context of IEFT protocols and provide key transport using any approved AES mode(s) and an approved MAC. The corresponding entries KTS-1, KTS-2 and KTS-3 in the SFI Table 10 have been documented accordingly. All KTS entries have been documented in accordance with Additional Comment 4 in the IG. Finally, KTS-5 corresponds to the key transport (wrapping) supported by the module in the context of the IETF TLS 1.2 protocol supported by it. Per IG D.A and IG D.B: The strengths of the established key have been documented in accordance with IG D.A Additional Comment 4. and per the Resolution in IG D.B.

The module supports cryptographic primitives used in the context of SSH, TLS 1.2 and TLS 1.3. It also supports the TLS 1.2 protocol itself. The module does not support the SSH and TLS 1.3 protocols and thus the following in accordance with Resolution #3 applies to the module: No parts of the SSH and TLS 1.3 protocols, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP.

Table 10: Ports and Interfaces The module does not support control output and thus the Control Output interface is inapplicable.

This document may be freely reproduced and distributed in its entirety without modification.

The Module does not support authentication.

Table 11: Roles The module supports the Crypto Officer (CO) role alone, assumed implicitly by the calling application. The module does not support a maintenance role, a bypass role or any unauthorized operators.

s s G,W,E ,Z G E This document may be freely reproduced and distributed in its entirety without modification.

s s d :R This document may be freely reproduced and distributed in its entirety without modification.

Name

Description

Indicat or CBC]; [AES- CBC- CS: AES- 128- CBC- CTS, AES- 192- CBC- CTS, AES- 256- CBC- CTS]; [AES- OFB: AES- 128- OFB, AES- 192- OFB, AES- 256- OFB]; [AES- CFB1: AES- 128- CFB1, AES- 192- CFB1, AES- 256- CFB1]; [AES- CFB8: AES- 128- CFB8, AES- 192- CFB8,

Inputs

Outputs

Security Function s

SSP Acces s

s s This document may be freely reproduced and distributed in its entirety without modification.

Name

Description

Indicat or AES- 256- CFB8]; [AES- CFB12 8: AES- 128- CFB, AES- 192- CFB, AES- 256- CFB]; [AES- CTR: AES- 128- CTR, AES- 192- CTR, AES- 256- CTR]; [AES- CCM: AES- 128- CCM, AES- 192- CCM, AES- 256- CCM]; [AES- GCM: AES- 128- GCM, AES- 192- GCM, AES- 256-

Inputs

Outputs

Security Function s

SSP Acces s

s s This document may be freely reproduced and distributed in its entirety without modification.

s s 6, This document may be freely reproduced and distributed in its entirety without modification.

Name

Description

Indicat or [TLS1- PRF, (SHA2- 256, SHA2- 384, SHA2- 512)]; [TLS13 -KDF, (SHA2- 256, SHA2- 384)]; [X963- KDF, (SHA2- 224, SHA2- 256, SHA2- 384, SHA2- 512)]; [X942K DF- ASNI, (SHA1, SHA2- 224, SHA2- 256, SHA2- 384, SHA2- 512, SHA2- 512/22 4, SHA2- 512/25 6, SHA3- 224, SHA3- 256,

Inputs

Outputs

Security Function s

SSP Acces s

s s 4, 6, This document may be freely reproduced and distributed in its entirety without modification.

Name

Description

Indicat or SHA3- 384, SHA3- 512)]; [NIST SP 800- 108r1 KDF KMAC: KBKDF , (KMAC -128, KMAC- 256)]; [NIST SP 800- 108r1 KDF: KBKDF , MAC: CMAC, Cipher: AES- 128- CBC, AES- 192- CBC, AES- 256- CBC, MAC: HMAC- SHA1, HMAC- SHA2- 224, HMAC- SHA2- 256, HMAC- SHA2- 384,

Inputs

Outputs

Security Function s

SSP Acces s

s s , This document may be freely reproduced and distributed in its entirety without modification.

Name

Description

Indicat or HMAC- SHA2- 256, HMAC- SHA2- 384, HMAC- SHA2- 512, HMAC- SHA2- 512/22 4, HMAC- SHA2- 512/25 6, HMAC- SHA3- 224, HMAC- SHA3- 256, HMAC- SHA3- 384, HMAC- SHA3- 512]; [KDF SSH: SSHKD F, (SHA1, SHA2- 224, SHA2- 256, SHA2- 384, SHA2- 512)]; [OneSt ep KDF: SSKDF

Inputs

Outputs

Security Function s

SSP Acces s

s s 4, 6, F, This document may be freely reproduced and distributed in its entirety without modification.

Name

Description

Indicat or , (SHA1, SHA2- 224, SHA2- 256, SHA2- 384, SHA2- 512, SHA2- 512/22 4, SHA2- 512/25 6, SHA3- 224, SHA3- 256, SHA3- 384, SHA3- 512, HMAC- SHA1, HMAC- SHA2- 224, HMAC- SHA2- 256, HMAC- SHA2- 384, HMAC- SHA2- 512, HMAC- SHA2- 512/22 4, HMAC- SHA2- 512/25 6,

Inputs

Outputs

Security Function s

SSP Acces s

s s , 4, 6, 4, 6, This document may be freely reproduced and distributed in its entirety without modification.

Name

Description

Indicat or SHA3- 224, SHA3- 256, SHA3- 384, SHA3- 512, KMAC- 128, KMAC- 256)]; [TwoSt ep KDF: HKDF, MAC: HMAC, (SHA1, SHA2- 224, SHA2- 256, SHA2- 384, SHA2- 512, SHA2- 512/22 4, SHA2- 512/25 6, SHA3- 224, SHA3- 256, SHA3- 384, SHA3- 512]; [HKDF: HKDF, MAC: HMAC, (SHA1,

Inputs

Outputs

Security Function s

SSP Acces s

s s 4, 6, This document may be freely reproduced and distributed in its entirety without modification.

s s 4, 6, d :G This document may be freely reproduced and distributed in its entirety without modification.

s s A G 4, 6, This document may be freely reproduced and distributed in its entirety without modification.

s s ]; 4, 6, This document may be freely reproduced and distributed in its entirety without modification.

s s - E This document may be freely reproduced and distributed in its entirety without modification.

Name

Description

Indicat or 4, SHA2- 512/25 6)]; [RSA SigVer: RSA, (1024, 2048, 3072, 4096), (SHA1, SHA2- 224, SHA2- 256, SHA2- 384, SHA2- 512, SHA2- 512/22 4, SHA2- 512/25 6)]; [RSA Signatu re Primitiv e: RSA, 2048, hash algorith m: (null)]; [ECDS A SigGen : EC, (SHA2- 224, SHA2- 256, SHA2- 384,

Inputs

Outputs

Security Function s

SSP Acces s

s s 4, 6)]; 4, 6)]; m: A This document may be freely reproduced and distributed in its entirety without modification.

s s A 4, 6)]; A This document may be freely reproduced and distributed in its entirety without modification.

s s Z e d :Z Z Z This document may be freely reproduced and distributed in its entirety without modification.

s s d :Z y Z Z Z r :Z Z A A This document may be freely reproduced and distributed in its entirety without modification.

s s Z Z r :Z Z : G,E,Z This document may be freely reproduced and distributed in its entirety without modification.

s s G,E,Z G,E,Z G,R,E ,Z A G,R,E ,Z A G,E,Z G,R,E ,Z G,E,Z W,E,Z Table 12: Approved Services The following indicate the type of access: G = Generate: The service generates or derives the CSP/Public Key. W = Write/Input: The service inputs the CSP/Public Key. E = Execute: The Module executes using the CSP/Public Key. This document may be freely reproduced and distributed in its entirety without modification.

R = Read/Output: The service outputs the CSP/Public Key. CSP are always protected with the approved KTS. Z = Zeroise: The Module zeroizes the CSP/Public Key after usage. A zeroised CSP is not retrievable or reusable. The module provides service indicators in accordance with the FIPS 140-3 IG 2.4.C example 3. All CSPs are zeroised when they are no longer needed: - Temporary CSPs are zeroised within the relevant function calls per service. - The DRBG state is zeroised on Module instantiation - The temporary underlying hash value generated as part of the RSA Signature Verification in the context of the integrity test performed, is zeroised prior to exiting the integrity test function. - TLS 1.2 SSPs are zeroised upon TLS 1.2 session termination.

This document may be freely reproduced and distributed in its entirety without modification.

Table 13: Non-Approved Services

The module does not support loading software from an external source.

The module does not support bypass.

The module supports self-initiated cryptographic output over the TLS 1.2 IETF protocol. Two internal actions are performed, i.e. software flags are checked within the module prior to allowing output over TLS 1.2. The TLS 1.2 i.e. self-initiated cryptographic output capability is inherently active per the module’s design. The Crypto Officer must only power on the underlying platform, i.e., IPC device. Successful negotiation of the TLS 1.2 session indicates that the selfinitiated cryptographic output capability is active.

The Module uses RSA 2048 SHA2-256 as the approved integrity technique. The pre-calculated value of the approved digital signature is included within the module. The integrity test covers the entirety of the module software. If the value calculated at boot for the approved digital signature does not match the pre-calculated, stored value, the test fails. This document may be freely reproduced and distributed in its entirety without modification.

The RSA 2048 SHA2-256 CAST is performed prior to the software integrity test in accordance with the IG 10.2.A. The Module is provided in the executable form (.exe). The software integrity RSA mod 2048 public key used for signature verification is considered non-SSP and stored within the module.

An operator of the module can perform the integrity test on demand by reloading the module. If the integrity test fails, module enters an error state. The module does not support loading any additional software from an external source.

Type of Operational Environment: Modifiable How Requirements are Satisfied: The module is a Level 1 multi-chip standalone software module with a modifiable operational environment.

There are no restrictions on the operational environment of the module.

The Module is a software module thus the requirements per this section do not apply.

The Module is a software module thus the requirements per this section do not apply.

This document may be freely reproduced and distributed in its entirety without modification.

Name API input API output Stored at manufactur e - 1 Input during TLS 1.2 negotiation Output during TLS 1.2 negotiation

From Calling application Module Manufacture r TLS 1.2 peer/external endpoint RAM

To Module Calling application Stored in the module binary RAM TLS 1.2 peer/externa l endpoint

Format Type Plaintex t Plaintex t Plaintex t Plaintex t Plaintex t

Distributio n Type Manual Manual N/A Automated Automated

Entry Type Electroni c Electroni c N/A Electroni c Electroni c

SFI or Algorith m

m Table 15: SSP Input-Output Methods The module is compliant with IG 9.5.A MD/EE (CM Software to/from App via TOEPP Path) and with AD/EE in the context of the TLS 1.2 protocol.

This document may be freely reproduced and distributed in its entirety without modification.

Table 16: SSP Zeroization Methods

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

2, 6, 4, This document may be freely reproduced and distributed in its entirety without modification.

2, 6, 4, This document may be freely reproduced and distributed in its entirety without modification.

8, 2, 6, 4, This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

Table 17: SSP Table 1 n n n n This document may be freely reproduced and distributed in its entirety without modification.

n n n n This document may be freely reproduced and distributed in its entirety without modification.

n n n n n n This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

Conformance to FIPS 186-5 is mandatory as of February 4, 2024. The module claims conformance to FIPS 186-4 as allowed per the FIPS 140-3 IG C.K Additional Comment #2. Per the NIST SP 800-133Ar2/3 and the programmatic transitions defined by the CMVP, the following algorithm transitions apply to the module, and the algorithms have been designated allowed/non-approved accordingly in Section 2.5: a. SHA-1 for SigVer (per IG C.M 3.e) and SHA-1 used for SigGen is a non-approved, not allowed algorithm. Usage of SHA-1 for all other SigVer is allowed for legacy use only until 2030. Thereafter, all usage of SHA-1 will be considered a non-approved, not allowed algorithm. b. FIPS 186-2 RSA KeyGen and SigGen modes are non-approved, not allowed algorithms. c. RSA-based key transport schemes that only use PKCS#1-v1.5 padding are nonapproved, not allowed algorithms. d. FIPS 186-4 DSA Key Gen, Sig Gen, or PQG Gen; FIPS 186-4 X9.31 RSA Key Gen, RSA Sig Gen are non-approved, not allowed algorithms. e. Usage of FIPS 186-4 RSA SigVer X9.31 is allowed only for legacy use. f. Triple-DES decryption is allowed for legacy use only. g. Triple-DES encryption is non-approved, not allowed algorithm. h. Key agreement schemes that are not compliant with any version of SP 800-56A (X448, X25519) are non-approved, not allowed algorithms. i. Until January 1, 2031, the following algorithms will be considered deprecated: a. SHA-1, SHA-224 hash functions b. Hash_DRBG and HMAC_DRBG using SHA-1, SHA-224 hash functions c. Hash function and HMAC using SHA-1, SHA-224 hash functions d. Use of a security strength less than 128-bits but greater than 112 bits for HMAC Generation j. As of January 1, 2031, the following algorithms will be considered deprecated/disallowed (i.e. non-approved, not allowed)/legacy use: a. SHA-1, SHA2-224 hash functions (disallowed) b. Use of the 112-bit security strength for classical digital signature and keyestablishment mechanisms (deprecated) c. Use of the 112-bit security strength for block ciphers (disallowed) d. Use of a security strength less than 128-bits but greater than 112 bits for ECDA KeyGen and RSA KeyGen (PKCS #1 v1.5 & PSS) (deprecated) e. Hash_DRBG and HMAC_DRBG using SHA-1, SHA-224 hash functions (disallowed) f. Hash function and HMAC using SHA-1, SHA-224 hash functions (legacy use) g. Use of a security strength less than 128-bits but greater than 112 bits for HMAC Generation (disallowed) h. Use of a security strength less than 128-bits but greater than 112 bits for HMAC Verification (legacy use)

This document may be freely reproduced and distributed in its entirety without modification.

Table 19: Pre-Operational Self-Tests The pre-operational self-tests can be run on demand by reloading the module.

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

Table 20: Conditional Self-Tests The conditional cryptographic algorithm self-tests can be run on demand by reloading the

Table 21: Pre-Operational Periodic Information This document may be freely reproduced and distributed in its entirety without modification.

This document may be freely reproduced and distributed in its entirety without modification.

Table 22: Conditional Periodic Information This document may be freely reproduced and distributed in its entirety without modification.

e y Table 23: Error States On instantiation, the Module performs the self-tests described in Table 22 and all CASTs. All KATs must complete successfully prior to any other use of cryptography by the Module. If one of

The module can be reloaded on demand for running the Cryptographic Algorithm Self-tests

The module is shipped pre-installed in the Approved mode of operation with the IPC device. The operator must power on the appliance upon delivery to cause it to automatically execute the pre-operational integrity tests and CASTs on all algorithms. Once the self-tests have completed successfully, the module is ready for use. The operator can verify the software version (V9FIPS.1.0) returned via an API call to the module and the module identifier (the string “IPC” printed in the boot logs). This document may be freely reproduced and distributed in its entirety without modification.

No additional guidance applies for the operation of the module apart from that specified in Section 2 and other subsections under this section.

No additional guidance applies for the operation of the module apart from that specified in Section 2 and other subsections under this section.

Azure is used as the Configuration Management System. The module’s software is implemented using high-level language and designed to avoid use of code, parameters or symbols that are not necessary for the module’s functionality and execution.

No maintenance requirements apply. The module’s software is protected from tampering as it is delivered securely within the IPC device.

The module can be uninstalled to end-of-life the module. The module can be securely sanitized by zeroising it.

The Module implements mitigations for some types of attacks using constant implementation and blinding. This document may be freely reproduced and distributed in its entirety without modification.