Quantum Xchange Phio TX

Certificate

Vendor resources (verify with the vendor)

Approved Algorithms (19)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Quantum Xchange Phio TX
  %% 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>3.2.3</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>CLI: User management.</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>CLI: Run CASTs.</i>"]
    C4["[high] Physical/logical<br/>interfaces (some 'blocked<br/>in firmware')<br/><i>Serial console (qty. 1): RJ-45 connector.<br/>USB (qty. 2): USB 3.0 ports.</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>application</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 Quantum Xchange Phio TX
  %% 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>3.2.3</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>CLI: User management.</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>CLI: Run CASTs.</i><br/>src: securityPolicy.services"]
    C4["[high] Physical/logical interfaces (some 'blocked in firmware')<br/><i>Serial console (qty. 1): RJ-45 connector.<br/>USB (qty. 2): USB 3.0 ports.</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>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,C2,C3,C4 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

Phio TX Document Version 1.7 October 16, 2024 Prepared for: Prepared by: Quantum Xchange

Bethesda, MD 20814 info@quantumxc.com KeyPair Consulting Inc.

San Luis Obispo, CA 93401 keypair.us +1 805.316.5024

Quantum Xchange Phio TX FIPS 140-3 Security Policy Table of Contents List of Tables List of Figures

Quantum Xchange This document defines the Security Policy for the Quantum Xchange Phio TX, hereafter denoted the Module. The Module is a of type hardware, with a multi-chip standalone embodiment and is validated to FIPS 140-3 overall Level

Table 1: Security Levels [Number Below] N/A N/A N/A The Phio TX has a multi-chip standalone embodiment in [FIPS140-3] terminology. The Phio TX provides network and secure communications functionality to facilitate propagation of keys between Phio TX nodes and endpoint clients in a Phio Hive (a dynamic peer network). The tested configurations are specified in Table 2 below. Table 2: Cryptographic Module Tested Configuration [Part Number and Version] 3.2.3 3.2.3 The optional QRNG is a quantum entropy source, with output used as additional entropy input that is not credited in the DRBG seeding strength rationale. As the QRNG is an optional feature, the Phio TX does not rely on it for assurance of key generation security strength in the [FIPS140-3] process. See the SSP section below for additional information.

Quantum Xchange 2.1 Phio TX FIPS 140-3 Security Policy Cryptographic Boundary The physical form of the Module is depicted below. The cryptographic boundary is the metal chassis shown in Figure 1 and Figure 2; as such the Phio TX is validated as a hardware module in [FIPS140-3] terms. The figures represent both hardware versions listed in Table 2. Figure 1: Module Cryptographic Boundary

• Top/Front/Left Side View Figure 2: Module Cryptographic Boundary
• Bottom/Back/Right Side View Figure 3: Front Panel Figure 4: Rear Panel

Quantum Xchange Phio TX FIPS 140-3 Security Policy The Module logical functionality (outlined in red) is shown below. All Module firmware is contained within the boundary. Figure 5: Module High Level Block Diagram The following hardware/firmware components are excluded from the cryptographic boundary and thus the FIPS 140-3 requirements: - TPM (use is optional): used to measure and track Module configuration. - Whole disk encryption (use is optional): not security relevant, similar to [FIPS 140-3_IG] 2.4.A Scenario 2. - PQC (use is optional): used for redundant communications channel obfuscation. - QRNG (hardware option): used for redundant entropy input. - Password hash: not security relevant, similar to [FIPS 140-3_IG] 2.4.A Scenario

1. None of the excluded components listed above are necessary to meet FIPS 140-3 requirements. 2.2 Modes of Operation, Security Rules and Guidance Configuration of the Module for conformance to this Security Policy requires installation of a valid Phio TX License with locked Approved mode enforcement, prior to doing so the Module is in a non-complaint state. Once configured for Approved operation, the Module does not require operator actions to operate in the approved mode and provides only Approved services and enforces the security rules listed next. The Module does not support a non-Approved or a degraded mode of operation.
2. No additional interface or service is implemented by the Module which would provide access to CSPs.
3. Data output is inhibited during key generation, self-tests, zeroisation, and error states.
4. All CSPs are zeroised by the zeroisation service (tx_reset command) with the exception of the FWIK, which can be destroyed if required by the secure sanitization process.
5. The Module does not support manual key entry.

Quantum Xchange 5. 6. 7. 8. 9. Phio TX FIPS 140-3 Security Policy The Module does not output plaintext CSPs or intermediate key values. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the Module. The Module can use only algorithms that have passed self-tests. The Module prohibits changing to the Crypto Officer state from any other role other than the Crypto Officer. The Module does not support multiple concurrent operators (over the serial console), a maintenance role, or a bypass capability. The Module design corresponds to the Module security rules. Initialization and installation requirements of the Module have been specified in Section 11 of this document. AES GCM is used to support TLS and SSH secure communications and adheres to the [FIPS140-3_IG] C.H Resolution 1a TLS

AES-GCM IVs shall be used in compliance with [FIPS140-3_IG] C.H scenario 1a (TLS/DTLS 1.2, per [RFC5288]) and 1d (SSHv2, per [RFC5647]). The Module is compatible with TLS/DTLS 1.2 protocol and provides the primitives to support the AES GCM ciphersuites from [SP800-52r1] Section 3.3.1. The Module’s implementation of AES-GCM is used together with one or more applications outside the Module’s cryptographic boundary that implement the specified protocols; Per [FIPS1403_IG] D.C, no parts of these protocols, other than the approved cryptographic algorithms and KDF, have been reviewed or tested by the CAVP and CMVP. In each of the protocols, if the Module’s power is lost and then restored, the key used for the AES GCM encryption/decryption shall be re-distributed. This condition is not enforced by the Module but is met implicitly. The Module does not retain any state across reset or power-cycles: AES-GCM key/IVs are not stored in non-volatile persistent memory (i.e., disk), hence no re-connection can occur without a fresh key establishment operation and the associated SSPs. The Module explicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values of 264-1 for a given session key. Connections are monitored, with a maximum lifetime of two hours or a maximum transaction count that is established to be less than the number of transactions prior to IV “rollover”.

Quantum Xchange 2.3 Phio TX FIPS 140-3 Security Policy Approved and Allowed Cryptographic Functionality The Module implements the Approved cryptographic functions listed in Table 3. Equivalent strength in bits is given for each key or algorithm type (as some algorithms do not use or produce keys). The term s is used throughout to indicate security strength, following the notation used in the majority of the sources (refer to the notes below Table 3). This table is referenced by Table 9 (SSPs). All references to the algorithm standards cited throughout this document can be found in the References section. Table 3: Approved Algorithms N/A. §4, §5.2, §6.2.1: N/A

1 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.

Quantum Xchange Phio TX FIPS 140-3 Security Policy N/A.

Quantum Xchange Phio TX FIPS 140-3 Security Policy Note 1: Preimage resistance strength applies to hash algorithms used in DRBG, KDFs. Described also in [SP800-57P1r5] Table

3. Note 2: Elliptic curve strengths are annotated as approximate (i.e., s ~=) since [SP800-186] Table 1 provides approximate security strengths. Note 3: Approved elliptic curves for ECC key agreement are given in [SP800-56Ar3] Table
4. Note 4: In Digital Signature applications, security strength is primarily associated with the asymmetric key pair specification. The hash function used must have equivalent strength equal to or greater than the security strength of the associated key pair. Note 5: Approved key types for FFC key agreement are given in [SP800-56Ar3] Tables 25,
5. The group notation of Table 26 is used for consistency with CAVP algorithm listings and ACVP capability registration. Note 6: Security strength for L=2048/N=256 is determined in accordance with [FIPS140-3_IG] D.B Strength of SSP Establishment Methods as y = min(x, N/2), where x is 112 and therefore y = min(112, 128) = 112. Note 7: Estimated security strengths of common RSA moduli are given in [SP800-56Br2] Table
6. IFC key types approved for Digital Signature Generation and Verification are given in [SP800-57P1r5] Table
7. Equivalent strengths are annotated as approximate (i.e., s ~=) since [SP800-56Br2] Table 4 provides approximate security strengths. Reference sources for the strengths provided in Table 3 are as follows: • • • • • AES (AES-128, AES-192, AES-256): [SP800-57P1r5] Table
8. ECC (P-256, P-384): [SP800-186] Table
9. FFC (L=2048/N=256, L=3072/N=256): [SP800-57P1r5] Table
10. FFC (FB, ffdhe2048, ffdhe3072): [SP800-56Ar3] Tables 1 and
11. IFC (k=2048, k=3072): [SP800-56Br2] Table
12. The Module does not implement the following: • • • 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. The Module supports the following ciphersuites for use with Module TLS v1.2 primitives2: • • TLS_DH_RSA_WITH_AES_256_CBC_SHA256 [RFC5246] (Hex Enum: 0x00,0x69) o KEx: DHE o Signature: RSA o PRF: HMAC-SHA2-256 o Cipher: AES-256 o Authentication: HMAC TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 [RFC5246] (Hex Enum: 0x00,0x6B) o KEx: DHE o Signature: RSA o PRF: HMAC-SHA2-256 o Cipher: AES-256 o Authentication: HMAC

Quantum Xchange Phio TX FIPS 140-3 Security Policy

• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 [RFC5288] (Hex Enum: 0x00,0x9F)
• KEx: DHE
• Signature: RSA
• PRF: HMAC-SHA2-384
• Cipher: AES-256
• Authentication: GCM
• TLS_DH_RSA_WITH_AES_256_GCM_SHA384 [RFC5288] (Hex Enum: 0x00,0xA1)
• KEx: DH
• Signature: RSA
• PRF: HMAC-SHA2-384
• Cipher: AES-256
• Authentication: GCM
• TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 [RFC5289] (Hex Enum: 0xC0,0x26)
• KEx: ECDH
• Signature: ECDSA
• PRF: HMAC-SHA2-384
• Cipher: AES-256
• Authentication: HMAC
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 [RFC5289] (Hex Enum: 0xC0,0x28)
• KEx: ECDHE
• Signature: RSA
• PRF: HMAC-SHA2-384
• Cipher: AES-256
• Authentication: HMAC
• TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 [RFC5289] (Hex Enum: 0xC0,0x2A)
• KEx: ECDH
• Signature: RSA
• PRF: HMAC-SHA2-384
• Cipher: AES-256
• Authentication: HMAC
• TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 [RFC5289] (Hex Enum: 0xC0,0x2E)
• KEx: ECDH
• Signature: ECDSA
• PRF: HMAC-SHA2-384
• Cipher: AES-256
• Authentication: GCM
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 [RFC5289] (Hex Enum: 0xC0,0x30)
• KEx: ECDHE
• Signature: RSA
• PRF: HMAC-SHA2-384
• Cipher: AES-256
• Authentication: GCM

Quantum Xchange Phio TX FIPS 140-3 Security Policy

• TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 [RFC5289] (Hex Enum: 0xC0,0x32)
• KEx: ECDH
• Signature: RSA
• PRF: HMAC-SHA2-384
• Cipher: AES-256
• Authentication: GCM
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 [RFC5289] (Hex Enum: 0xC0,0x2C)
• KEx: ECDHE
• Signature: ECDSA
• PRF: HMAC-SHA2-384
• Cipher: AES-256
• Authentication: GCM
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 [RFC5289] (Hex Enum: 0xC0,0x24)
• KEx: ECDHE
• Signature: ECDSA
• PRF: HMAC-SHA2-384
• Cipher: AES-256
• Authentication: HMAC
• TLS_PSK_WITH_AES_256_CBC_SHA [RFC4279] (Hex Enum: 0x00,0x8D)
• KEx: PSK
• Signature: N/A
• PRF: HMAC-SHA-1
• Cipher: AES-256
• Authentication: HMAC
• TLS_PSK_WITH_AES_256_GCM_SHA384 [RFC5487] (Hex Enum: 0x00,0xA9)
• KEx: PSK
• Signature: N/A
• PRF: HMAC-SHA2-384
• Cipher: AES-256
• Authentication: GCM
• TLS_PSK_WITH_AES_256_CBC_SHA384 [RFC5487] (Hex Enum: 0x00,0xAF)
• KEx: PSK
• Signature: N/A
• PRF: HMAC-SHA2-384
• Cipher: AES-256
• Authentication: HMAC The Module supports the following SSH parameters for use with Module SSH primitives (the SSH protocol allows any combination): Key Exchange
• ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 Client Authentication
• ecdsa‐sha2‐nistp256 ecdsa-sha2-nistp384

Quantum Xchange

• Phio TX FIPS 140-3 Security Policy ecdsa-sha2-nistp521 rsa-sha2-256 rsa-sha2-512 Cipher
• aes128-cbc aes192-cbc aes256-cbc aes128-gcm aes256-gcm MAC
• hmac‐sha2‐256 hmac-sha2-384

Quantum Xchange Phio TX FIPS 140-3 Security Policy Cryptographic Module Interfaces The Module supports the physical ports shown in Error! Reference source not found. and Error! Reference source not fo und. in Section 2 of this document. The ports and corresponding logical interfaces are described in Table 4. Table 4: Ports and Interfaces N/A. N/A. N/A. interfaces, and as such are marked as N/A in the logical interface and data columns.

Quantum Xchange Phio TX FIPS 140-3 Security Policy The Module supports three roles using role-based authentication: the Cryptographic Officer (CO) role, a limited privilege Admin role (abbreviated as ‘A’ in tables below) and the User role. Each role is implicitly identified by the service requested, with authentication as shown in Table 6. The Status service may be used to determine the current status of the Module, as well as provide the CMVP listing information for the Module (identifiers and version). Table 5: Roles, Service Commands, Input and Output Commands corresponding to [FIPS140-3] required services are italicized: tx_status (output module identifier and version, Table 6: Roles and Authentication For an operator in the CO or Admin role, connected via the console or SSH (Debian login (memorized secret)):

• The 8-character minimum password length is enforced by the following setting in /etc/pam.d/common-password: password [success=2 default=ignore] pam_unix.so obscure sha512 minlen=8
• The one-time strength of this authentication method (assuming the 95 printable characters) is 958 = 6.6E+15.
• The one-minute security strength (based on a minimum 1 µsec authentication time) is 958/(60*1E+6) = 1.1E+08.
• The use of SSH during the process of authentication is permitted per [FIPS140-3_IG] 4.1.A Resolution d. For an operator in the CO or Admin role using Web GUI [RFC7519]: providing 192 bits of security strength or 2192 = 6.3E+57.
• The one-minute security strength (based on a minimum 1 µsec authentication time) is 2192/(60*1E+6) = 1.0E+50. For an operator in the User role via REST API:
• TLS client authentication using RSA signature verification (as the minimum strength ciphersuite option), providing

Quantum Xchange

• 4.1 Phio TX FIPS 140-3 Security Policy The one-minute security strength (based on a minimum 1 µsec authentication time) is 2112/(60*1E+6) = 8.7E+25. Table 7 describes all Module services and service access to SSPs. The ‘>’ character in the Indicator column refers to updates in indication depending on outcome. The CLI indication in the Service column indicates a command line interface interaction via either the Console connection or an SSH connection. The SSH† row entry applies to all services marked with SSH†. The TLS‡ row entry applies to all services marked with TLS‡. Access column 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 for a cryptographic operation. Z = Zeroise: The Module zeroises the SSP. Indicator column LCD-NR: Front panel LCD “NOT running”. LCD-R: Front panel LCD “Running”. LCD-STR: Front panel LCD “Selftest Running”. LCD-IF: Integrity Fail. LCD-CF: CAST Fail. SH-LOGIN: Phio TX shell login, prompt, and response text. SH-STAT: tx_status command response. SH-CAST: txfips command response. SH-FWIT: txscan command response. SH-RST: tx_reset command response. Table 7: Approved Services N/A. E A E N/A. N/A A N/A A W W N/A. A A

Quantum Xchange Phio TX FIPS 140-3 Security Policy N/A. N/A A N/A A N/A A N/A N/A. A Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z Z A W E A

Quantum Xchange Phio TX FIPS 140-3 Security Policy The Module supports self-initiated cryptographic output capability in the context of the TLS v1.2 protocol. The following two actions are performed prior to activation of the self-initiated cryptographic output capability: Action 1: installation of credentials (PKIs), using tx_generate_tx_csr followed by tx_install_tx_crt. Action 2: registration of the peer in the config file, specifying name (matching the peer CN) and optionally IP address. For self-initiated cryptography to function, both actions are required on each peer (both sides of the connection). The Module supports a partial firmware load from an external source and this functionality is limited to the Crypto Officer role thus ensuring that unauthorised access to and use of the Module is not feasible. The firmware load test using HMAC-SHA2-384 performed prior to installation of the loaded firmware ensures an isolation of code. Software/Firmware Security The Module uses HMAC-SHA2-384 performed over all Module firmware as the integrity technique. The operator can initiate the integrity test on demand via the txscan command.The Phio TX application is delivered in a single executable binary, as a self-extracting installation package which can be installed on any system on which the base OS has been installed. The Module supports firmware loading (partial update). HMAC-SHA2-384 with (256-bit HMAC key) is performed on updated components. Operational Environment The Module is classified in [FIPS140-3] terms as a limited operational environment. Physical Security The Phio TX is a hardware Module (multichip standalone embodiment) packaged in a metal chassis as shown in Figure 1 and Figure 2. The enclosure is protected by four (4) tamper-evident seals as shown in Figure 6, is production grade and opaque in the visible spectrum. The Crypto Officer role is responsible for securing and having control at all times of any unused seals, and the direct control and observation of any changes to the Module such as reconfigurations where the

Quantum Xchange Phio TX FIPS 140-3 Security Policy tamper evident seals or security appliances are removed or installed to ensure the security of the Module is maintained during such changes and the Module is returned to the Approved state. Rear right tamper seal Rear left tamper seal Left front tamper seal Right front tamper seal Figure 6: Module Seal Application Locations Non-Invasive Security The Module does not implement non-invasive security measures. Sensitive Security Parameters Management Table 9 summarizes the SSPs implemented by the Module. System keys handled by the Phio TX are not classified as SSPs as they are not used by the Phio TX. All such data crosses the boundary via TLS connections, such that system secrets are TLS protected. Generation, inclusive of derivation (Key-entity association) G1: Generated by on-chip [SP800-90B] ENT (NP) (memory map). G2: Derived using [SP800-90Ar1] with Block_cipher_df (memory map). G3: FFC (DSA) or ECC (ECDSA) or RSA (memory map). Storage (associated to entity by memory mapping) S1: Stored in plaintext in RAM, dynamic storage. S2: Stored in PEM format in hard drive media, static storage. IE1: Provided in plaintext to the Module (message parameter). IE2: Imported and exported in ciphertext (positional parameter). IE3: Established in Quantum Xchange manufacturing facility.

Quantum Xchange Phio TX FIPS 140-3 Security Policy Import/Export Establishment Storage Zeroisation Table 9: SSPs ---------------------------

3 Strength is provided in bits. Please refer to Table 3 and the notes below it for the strength provenance (traceability to applicable standards and

Quantum Xchange Phio TX FIPS 140-3 Security Policy ------------ = not applicable. The firmware integrity key (FWIK, formally not a SSP) is a 256-bit HMAC key used with HMAC-SHA2-384. Table 10: Non-Deterministic Random Number Generation Specification

Quantum Xchange Phio TX FIPS 140-3 Security Policy

The Module automatically invokes all tests listed below on each power-on or reset. The FW integrity test is run periodically as a scheduled system service (nominally every eight hours) and may also be run on demand by running txscan on an SSH or Console connection. The complete set of ACVP tests used to achieve the CAVP listings are run at power-on (as listed under Conditional Selftests below), are also run periodically as a scheduled system service (nominally every eight hours) and may also be run on demand by running txfips on an SSH or Console connection. All cryptographic algorithm self-tests (CASTs) must complete successfully prior to any other use of cryptography by the Module. If the firmware integrity test fails, the Module enters the ERR_TXSCAN state (indicated by LCD-IF, see Table 7). If one of the CASTs fails, the Module enters the ERR_TXFIPS state (indicated by LCD-CF, see Table 7). The ERR_TXFIPS and ERR_TXSCAN error states are persistent, cleared by successful completion of txfips or txscan, respectively. When in an error state, only self-test and status services are available. All attempts to use the Module’s services result in the return of the error state indicator (Failed TXFIPS or Failed TXSCAN). Pre-operational Self-tests

• Pre-operational firmware integrity test: HMAC-SHA2-384 with (256-bit HMAC key) digest verification performed over all Module firmware. Conditional Self-tests
• txfips Conditional Cryptographic Algorithm tests:
• AES-ECB, AES-CBC #A2983: CASTs - complete set of AES ECB and CBC ACVP test vectors.
• AES-CBC-128 encrypt KAT.
• AES-CBC-128 decrypt KAT.
• AES-CBC-192 encrypt KAT.
• AES-CBC-192 decrypt KAT.
• AES-CBC-256 encrypt KAT.
• AES-CBC-256 decrypt KAT.
• AES-GCM #A2983: CASTs - complete set of AES GCM ACVP test vectors.
• AES-GCM-128 encrypt KAT.
• AES-GCM-128 decrypt KAT.
• AES-GCM-192 encrypt KAT.
• AES-GCM-192 decrypt KAT.
• AES-GCM-256 encrypt KAT.
• AES-GCM-256 decrypt KAT.
• Counter DRBG #A2983: CASTs - complete set of DRBG ACVP test vectors. Instantiate, Generate and Reseed functions (per Section 11.3 of [SP800-90Ar1]) for AES-256 Counter DRBG with derivation function.
• ECDSA SigGen #A2983: CASTs - complete set of ECDSA ACVP test vectors.
• ECDSA SigGen KAT using P-256 and SHA2-256.
• ECDSA SigGen KAT using P-256 and SHA2-384.
• ECDSA SigGen KAT using P-384 and SHA2-256.
• ECDSA SigGen KAT using P-384 and SHA2-384.
• ECDSA SigVer #A2983: CASTs - complete set of ECDSA ACVP test vectors.
• ECDSA SigVer KAT using P-256 and SHA2-256.
• ECDSA SigVer KAT using P-256 and SHA2-384.
• ECDSA SigVer KAT using P-384 and SHA2-256.

Quantum Xchange Phio TX FIPS 140-3 Security Policy

• ECDSA SigVer KAT using P-384 and SHA2-384.
• HMAC-SHA-1 #A2983: Complete set of HMAC-SHA-1 ACVP test vectors.HMAC-SHA2 #A2983: Complete set of HMAC-SHA2-256 and HMAC-SHA2-384 ACVP test vectors (performed prior to FW Integrity).
• HMAC-SHA2-256 KAT.
• HMAC-SHA2-384 KAT.
• KAS-ECC-SSC #A2983: CAST - complete set of KAS-ECC-SSC ACVP test vectors.
• [SP800-56Ar3] Section 6 Ephemeral Unified Shared Secret (Z) Computation using P-256.
• [SP800-56Ar3] Section 6 Ephemeral Unified Shared Secret (Z) Computation using P-384.
• KAS-FFC-SSC #A2983: CAST - complete set of KAS-FFC-SSC ACVP test vectors.
• [SP800-56Ar3] Section 6 dhEphem Shared Secret (Z) Computation using L=2048/N=256.
• [SP800-56Ar3] Section 6 dhEphem Shared Secret (Z) Computation using L=3072/N=256.
• KDF SSH #A2983: CAST - complete set of SSH KDF ACVP test vectors.
• RSA SigGen #A2983: CASTs - complete set of RSA ACVP test vectors.
• PSS SigGen KAT using k=2048, SHA2-256.
• PSS SigGen KAT using k=2048, SHA2-384.
• PSS SigGen KAT using k=3072, SHA2-256.
• PSS SigGen KAT using k=3072, SHA2-384.
• RSA SigVer #A2983: CASTs - complete set of RSA ACVP test vectors.
• PSS SigVer KAT using k=2048, SHA2-256.
• PSS SigVer KAT using k=2048, SHA2-384.
• PSS SigVer KAT using k=3072, SHA2-256.
• PSS SigVer KAT using k=3072, SHA2-384.
• SHA2 #A2983: CAST - complete set of SHS (SHA2) ACVP test vectors.
• SHA2-256 KAT.
• SHA2-384 KAT.
• SHA2-512 KAT.
• TLS v1.2 KDF [RFC7627] #A2983: CAST - complete set of TLS KDF ACVP test vectors.
• ENT (NP) NIST SP 800-90B Health Tests Conditional pair-wise consistency tests:
• DSA PCT (key agreement): Per [SP800-56Ar3] §5.6.2.1.4, the Phio TX generates the static and ephemeral key pairs for use in TLS.
• ECDSA PCT (key agreement): Per [SP800-56Ar3] §5.6.2.1.4, the Phio TX generates the static and ephemeral key pairs for use in TLS and SSH.
• ECDSA PCT (digital signature): The Phio TX performs a sign-verify PCT on every key pair generated. Conditional software/firmware load test: HMAC-SHA2-384 with (256-bit HMAC key) test performed on updated components.

Installation, initialization, configuration, and provisioning are managed using Quantum Xchange provided scripts as well as the administrative tools of the Phio TX shell available via SSH or the console. This involves installation of a valid Phio TX License with locked Approved mode enforcement. Once configured, the Approved mode of operation persists. Quantum Xchange recommends the use of the tx_reset command to reset the Phio TX to factory defaults.

Quantum Xchange Phio TX FIPS 140-3 Security Policy The Module Guidance Documentation [GD] provides detailed procedures for secure installation, initialization, configuration, provisioning, decommissioning, and sanitization of the Module. No maintenance requirements are defined for the Phio TX. The Phio TX application is delivered as a single executable binary. The binary must be run with the root account to install the upgrade. The firmware load test and integrity tests implemented ensure protection of the firmware during delivery.

The Module does not implement mitigations of other attacks outside the scope of [FIPS140-3].

Quantum Xchange Phio TX FIPS 140-3 Security Policy References

• [FIPS140-3]: FIPS 140-3, Security Requirements for Cryptographic Modules, 22-Mar-2019
• [SP800-140_DTR]: NIST SP 800-140, FIPS 140-3 Derived Test Requirements (DTR): CMVP Validation Authority Updates to ISO/IEC 24759, 20-Mar-2020
• [SP800-140A]: NIST SP 800-140A, CMVP Documentation Requirements: CMVP Validation Authority Updates to ISO/IEC 24759, 20-Mar-2020
• [SP800-140B]: NIST SP 800-140B, CMVP Security Policy Requirements: CMVP Validation Authority Updates to ISO/IEC 24759 and ISO/IEC 19790 Annex B, 20-Mar-2020
• [SP800-140Cr2]: NIST SP 800-140C Rev. 2, Cryptographic Module Validation Program (CMVP)-Approved Security Functions: CMVP Validation Authority Updates to ISO/IEC 24759, 25-Jul-2023
• Supplemental Information: SP 800-140C: Approved Security Functions, 25-Jul-2023
• [SP800-140Dr2]: NIST SP 800-140D Rev. 2, Cryptographic Module Validation Program (CMVP)-Approved Sensitive Security Parameter Generation and Establishment Methods: CMVP Validation Authority Updates to ISO/IEC 24759, 25-Jul-2023
• Supplemental Information: SP 800-140D: Approved SSP Generation and Establishment Methods, 25-Jul-2023
• [SP800-140E]: NIST SP 800-140E, CMVP Approved Authentication Mechanisms: CMVP Validation Authority Requirements for ISO/IEC 19790 Annex E and ISO/IEC 24579 Section 6.17, 20-Mar-2020
• [SP800-140F]: NIST SP 800-140F, CMVP Approved Non-Invasive Attack Mitigation Test Metrics: CMVP Validation Authority Updates to ISO/IEC 24759, 20-Mar-2020
• [FIPS140-3_IG]: Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program, 1-Aug-2023
• [I19790]: ISO/IEC 19790:2012 Information technology -- Security techniques -- Security requirements for cryptographic modules, 1-Nov-2015
• [I24759]: ISO/IEC 24759:2017 Information technology -- Security techniques -- Test requirements for cryptographic modules, 1-Mar-2017
• [FIPS180-4]: FIPS 180-4, Secure Hash Standard (SHS), 4-Aug-2015
• [FIPS186-4]: FIPS 186-4, Digital Signature Standard (DSS), 19-Jul-2013
• [FIPS197]: FIPS 197, Advanced Encryption Standard (AES), 9-May-2023
• [FIPS198-1]: FIPS 198-1, The Keyed Hash Message Authentication Code (HMAC), 16-Jul-2008
• [SP800-38A]: NIST SP 800-38A, Recommendation for Block Cipher Modes of Operation: Methods and Techniques, 1-Dec-2001
• [SP800-38D]: NIST SP 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, 28-Nov-2007
• [SP800-52r2]: NIST SP 800-52 Rev. 2, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, 29-Aug-2019
• [SP800-56Ar3]: NIST SP 800-56A Rev. 3, Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography, 16-Apr-2018
• [SP800-56Br2]: NIST SP 800-56B Rev. 2, Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography, 21-Mar-2019

Quantum Xchange Phio TX FIPS 140-3 Security Policy

• [SP800-57P1r5]: NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1
• General, 4-May-2020
• [SP800-90Ar1]: NIST SP 800-90A Rev. 1, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, 24-Jun-2015
• [SP800-90B]: NIST SP 800-90B, Recommendation for the Entropy Sources Used for Random Bit Generation, 10-Jan-2018
• [SP800-133r2]: NIST SP 800-133 Rev. 2, Recommendation for Cryptographic Key Generation, 4-Jun-2020
• [SP800-135r1]: NIST SP 800-135 Rev. 1, Recommendation for Existing Application-Specific Key Derivation Functions, 23-Dec-2011
• [SP800-186]: NIST SP 800-186, Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters, 3-Feb-2023
• [RFC4279]: RFC 4279, Pre-Shared Key Ciphersuites for Transport Layer Security (TLS), Dec-2005
• [RFC5246]: RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2, Aug-2008
• [RFC5288]: RFC 5288, AES Galois Counter Mode (GCM) Cipher Suites for TLS, Aug-2008
• [RFC5289]: RFC 5289, TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM), Aug-2008
• [RFC5487]: RFC 5487, Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode, Mar-2009
• [RFC7519]: RFC 7519, JSON Web Token (JWT), May-2015
• [RFC7627]: RFC 7627, Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension, Sept2015
• [GD]: Quantum Xchange Phio TX FIPS 140-3 Guidance Documentation, 1-Sep-2022 Acronyms and Definitions
• ACVP: Automated Cryptographic Validation Program
• ACVT: Automated Cryptographic Validation Testing
• AES: Advanced Encryption Standard, see [FIPS197]
• API: Application Programming Interface
• CAST: Cryptographic Algorithm Self-Test
• CKG: Cryptographic Key Generation
• CMVP: Cryptographic Module Validation Program
• CO: Cryptographic Officer
• CSP: Critical Security Parameter, see [FIPS140-3]
• CPU: Central Processing Unit
• CRC: Cyclic Redundancy Check
• CCCS: Canadian Centre of Cybersecurity
• CVL: Component Validation List
• DRAM: Dynamic Random-Access Memory

Quantum Xchange

• DRBG: Deterministic Random Number Generator, see [SP800-90Ar1]
• DSA: Digital Signature Algorithm, see [FIPS186-4]
• DTR: Derived Test Requirements
• ECB: Electronic Code Book
• ECC: Elliptic Curve Cryptography
• ECDSA: Elliptic Curve Digital Signature Algorithm, see [FIPS186-4]
• EMS: Extended Master Secret
• ETSI: European Telecommunications Standards Institute
• FFC: Finite Field Cryptography
• FIPS: Federal Information Processing Standard
• GCM: Galois/Counter Mode
• HMAC: Keyed-Hash Message Authentication Code, see [FIPS198-1]
• IG: Implementation Guidance, see [FIPS140-3_IG]
• IV: Initialization Vector
• KAS: Key Agreement Scheme
• KDF: Key Derivation Function
• MAC: Message Authentication Code
• NIST: National Institute of Standards and Technology
• OE: Operating Environment
• PKI: Public Key Infrastructure
• PRF: Pseudo-Random Function
• PSK: Pre-Shared Key
• PSP: Public Security Parameter
• QKD: Quantum Key Distribution
• RSA: Rivest, Shamir and Adleman algorithm, see [FIPS186-4]
• SHA/SHS: Secure Hash Algorithm/Standard, see [FIPS180-4]
• SKIP: Secure Key Integration Protocol, Cisco
• SP: NIST Special Publication
• SSC: Shared Secret Computation
• SSP: Sensitive Security Parameter
• TX: Trusted Exchange (Phio TX) Phio TX FIPS 140-3 Security Policy