Wave Relay® User Space Crypto Module

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Wave Relay® User Space Crypto Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Firmware Load<br/>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>status output<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/>IKEV</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"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    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"]
    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"]
    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["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
  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 C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Wave Relay® User Space Crypto Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Firmware Load<br/>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>status output<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/>IKEV</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 C2,C3,C5,C6 clueLow;

Security Policy, page by page

Persistent Systems, LLC Wave Relay® User Space Crypto Module Document Version: 1.2 Date: September 29, 2025

Table 1: Security Levels FIPS validated connectivity drives mission success. This Persistent Systems LLC Wave Relay® User Space Crypto Module, hereafter denoted as the “module”, is a Software cryptographic module embedded in the Wave Relay® System that provides FIPS validated cryptographic algorithms which are used by user space system services & protocols (e.g., TLS, IPsec, etc.) The Wave Relay® System is a peer-to-peer wireless MANET networking solution in which there is no master node. If any device fails, the rest of the devices continue to communicate using any remaining connectivity. By eliminating master nodes, gateways, access points, and central coordinators from the design, Wave Relay® delivers high levels of fault tolerance regardless of which nodes might fail.

Purpose and Use: The module is intended for use by US Federal agencies or other markets that require FIPS 140-3 validated cryptography. The module is intended to be used in various products within the vendor’s portfolio of solutions. Built to create powerful, secure networks anywhere, the module is used to unite all critical data sources in real time giving you and your team the confidence to make difficult decisions in the heat of the moment. Module Embodiment: SingleChip

Module Characteristics: Cryptographic Boundary: The TOEPP of the module is depicted in Figure 1. The Module is a single-chip embodiment. The cryptographic boundary is outlined in red and is defined as a dynamic software library (fips.so). The following block diagram details the module’s boundaries: Figure 1 Logical Cryptographic Boundary and Physical Perimeter

N/A for this module. Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets): The cryptographic module is tested on the following operational environments:

Table 2: Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets)

Tested Operational Environments - Software, Firmware, Hybrid: Wave Relay® User Space Crypto Module cryptographic module is tested on the following operational environments. Table 3: Tested Operational Environments - Software, Firmware, Hybrid N/A for this module.

No components were excluded from the cryptographic boundary.

Modes List and Description: The Module supports an Approved mode and Non-Approved mode of operation. The module does not support a degraded mode. The Module’s status output will include a “FIPS Indicator” line. If this line explicitly states “not-approved”, then the Module is in the Non-Approved state; otherwise, the line will be blank, indicating the Approved state.

Table 4: Modes List and Description Mode Change Instructions and Status : The module provides a service level indicator. All Approved services will indicate they are Approved services, and all non-Approved services will indicate they are non-Approved. No additional configuration or initialization is required.

Approved Algorithms: The Module implements cryptographic algorithms in the following providers: • Wave Relay® User Space Crypto Module version 1.0 (Cert. #A5177) Validation certificates for each Approved security function are listed in the table below.

Table 5: Approved Algorithms ApprovedAlgorithmsTable From Web Cryptik ApprovedAlgorithmsTable Vendor-Affirmed Algorithms: The Module supports SP800-133rev2, CKG, as the sole vendor affirmed cryptographic

• Cryptographic key generation
• In compliance with Sections 4 NIST SP 800-133rev2, the module uses its Approved DRBG to generate symmetric keys and the seed used for asymmetric keys without any post-processing.

Table 6: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: The module does not support any Non-Approved but Allowed Algorithms in the Approved Mode of Operation. N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: The module does not implement any Non-Approved, Algorithms Allowed with No Security Claimed in the Approved Mode of Operation. N/A for this module. Non-Approved, Not Allowed Algorithms: The Module implements the Non-Approved, Not Allowed cryptographic algorithms listed in the table below. Table 7: Non-Approved, Not Allowed Algorithms

The table below shows the Security Function Implementations that the module implements:

Table 8: Security Function Implementations

Below are the documentation requirements for specific algorithms and conditions, as mandated by Implementation Guidance. FIPS140-3 IG C.H, Option 2: AES GCM IV Uniqueness The IV is generated internally at its entirety randomly. The generation uses an Approved DRBG (Cert. #A5177) that is internal to the module’s boundary. The IV length is fixed at 96 bits (per SP 800-38D). FIPS140-3 IG C.I: XTS-AES Requirements The XTS algorithm implementation includes a check prior to use to ensure Key_1 ≠ Key_2. FIPS 140-3 IG D.N: PBKDF Requirements The module conforms to IG D.N, Option 1a. The password length is 8 – 128 bytes. The password may be selected from a set of 94 characters. So the total combinations for an 8-character password are 94^8. Thus, the probability of guessing the correct password on a random attempt is 1/94^8. The iteration count is 1 - 10,000, as determined by the operator. Keys derived from passwords per SP800-132 may only be used in storage applications. SHA-1 Usage Per SP800-131Ar2, the use of SHA-1 is disallowed for digital signature generation, but is permitted for digital signature verification (legacy use) and all non-digital signature applications. KAS and KTS 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. 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.

The Module uses an entropy source from within the TOEPP, but outside of the cryptographic boundary. The module exercises no control over the source of entropy per IG 9.3.A, Scenario 2B. The size of the entropy provided to the DRBG varies depending on the DRBG mechanism (i.e., HASH, CTR, HMAC) and desired security strength. No assurance of the minimum strength of generated SSPs (e.g., keys). N/A for this module.

The module generates both symmetric and asymmetric cryptographic keys using the internal DRBG (CAVP Cert. #A5177). The module implements key generation methods according to SP 800-133r2 Section 4, Example 1, without the use of V. The key generation methods are specified in the Vendor Affirmed Algorithms table and the Security Function Implementations table. Additionally, the module implements key derivation methods according to Section 6.2 of SP 800-133r2. The key derivation methods are specified in the Security Function Implementations table.

The module does not establish SSPs using an approved key agreement scheme (KAS) or key transport scheme (KTS). However, it does offer some or all of the underlying KAS cryptographic functionality and approved authenticated algorithms that can be used by an external operator/application as part of an approved KAS or KTS. The module supports KAS-ECC-SSC, KAS-FFC-SSC, KAS-IFC-SSC, AES-KW, AES-KWP, and KTS-IFC. KAS-IFC SSC [56Br2] - Per [IG] D.F Scenario 1 path (1), compliant the derivation of a shared secret Z in one of the schemes in Sections 8.2 and 8.3 of SP 800-56Brev2. KAS-SSC [56Ar3] - Per [IG] D.F Scenario 2 path (2), compliant with the derivation of a shared secret Z in one or more of the key agreement schemes in Section 6 of SP 800-56Arev3. Testing is split into (i) testing the computation of the shared secret and (ii) testing the key derivation function used in deriving the keying material comply to IG 2.4.B. KAS-SSC as a service: 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.

The module does not implement any Industry Protocols. The module is a cryptographic toolkit that may be used in support for Industry Protocols but does not itself implement the protocol.

The Module’s ports and associated FIPS defined logical interface categories are listed below. Table 9: Ports and Interfaces Note: The module does not support Control Output.

The Module supports one distinct operator role, Crypto Officer (CO). One authentication is allowed per Module reset. The Module does not support concurrent operators. The Cryptographic Officer’s authentication public key is protected by the physical and logical design of the module; it is stored as part of the module binary itself. The Roles Table below lists all operator roles supported by the Module. Table 11: Roles

All approved services implemented by the Module are listed in the table below: The SSPs modes of access shown in the table below are defined as:

All approved services implemented by the Module are listed in the table below: Table 13: Non-Approved Services

The module does not support an External Software/Firmware Load capability.

The Module is composed of the following component(s):

• Component 1: software cryptographic library
• binary (fips.so)

The software component is protected with the authentication technique, HMAC-SHA2-256, as described in Table 16.

The operator can initiate the integrity test on demand by power cycling the hardware.

Type of Operational Environment: Modifiable The Module has a modifiable operational environment under the FIPS 140-3 definitions. The tested operational environments are listed in Section 2.1. The Operating Environment is modifiable and allows the operator to load and execute software. How Requirements are Satisfied : The module supports a modifiable operational environment. The operator may load and execute software that was not included in the original evaluation as the underlying Wave Relay OS 2.2 operational environment is modifiable. Each instance of a cryptographic module controls its own SSPs and are not owned or controlled by external processes/operators. This requirement is not enforced by administrative documentation and procedures but by the cryptographic module itself. The operational environment provides the capability to separate individual application processes from each other in order to prevent uncontrolled access to CSPs and uncontrolled modification of SSPs.

All cryptographic software, SPPs and control/status information is under the control of an operating system that implements mandatory access control. The Operating system protects against unauthorized execution, unauthorized modification, and unauthorized reading of SSPs and status data. Processes that are spawned by the cryptographic module are owned by the module and are not owned by external processes/operators. The Operating System provides an audit mechanism with the date and time of each audited event.

The module is software and as such, physical security requirements do not apply. N/A for this module.

The Module does not implement any mitigation method against non-invasive attack.

Table 15: SSP Input-Output Methods Table 16: SSP Zeroization Methods

All usage of these SSPs by the Module are described in the services detailed in Section 4.3.

Name

Input - Output Output wrapped (IO6)

Storage

Storage Duration

Zeroization

Related SSPs AES Key:Derived From MAC Key:Derived From

The Module performs self-tests to ensure the proper operation of the Module. Per FIPS 140-3 these are categorized as either pre-operational self-tests or conditional self-tests. Pre-operational self–tests are available on demand by power cycling the Module. The operator may invoke periodic self-tests by power cycling the module. It is recommended that periodic self-testing be performed weekly. Please note that HMAC-SHA2-256 is self-tested prior to execution of the Software Integrity Test. The Module performs the following pre-operational self-tests in table below. Table 19: Pre-Operational Self-Tests

The Module performs the following conditional self-tests in the table below.

Table 20: Conditional Self-Tests

Table 21: Pre-Operational Periodic Information

Table 22: Conditional Periodic Information The operator may invoke periodic self-tests by power cycling the module. It is recommended that periodic self-testing be performed weekly.

Self-tests may be initiated on demand by power cycling the module.

No end user action is required to startup the module in an approved mode for operation. The module is built into the Wave Relay® OS and delivered in Persistent Systems’ Wave Relay® Solutions. There is no standalone delivery of the module as a software hybrid module. Persistent Systems’ internal development process guarantees that the correct version of the module is installed within its intended device OS version. Installation and Initialization: The module is pre-installed within the Persistent Systems Solutions, which include the MPU5, Embedded Module, Embedded Module lite, GVR5, or Integrated Antenna Series. No further initialization of the module is required. Upon powering on the hardware platform, the module will automatically perform pre-operational and conditional self-tests in accordance with FIPS 140-3 requirements. Delivery: The module is pre-installed within the Persistent Systems product offerings. The Persistent Systems products are distributed using a trusted courier and packaging must be inspected upon delivery.

There are no specific management activities required of the Crypto Officer Role to ensure that the module runs securely. However, if any irregular activity is noticed or the module is consistently reporting errors, then Persistent Systems Support should be contacted.

There are no specific management activities required of the Crypto Officer Role to ensure that the module runs securely. However, if any irregular activity is noticed or the module is consistently reporting errors, then Persistent Systems Support should be contacted.

Rules of Operation

1. The Module provides one distinct operator roles: Cryptographic Officer.
2. The Module provides identity-based authentication.
3. The Module clears previous authentications on power cycle.
4. An operator does not have access to any cryptographic services prior to assuming an authorized role.
5. The Module allows the operator to initiate power-up self-tests by power cycling the Module.
6. All self-tests do not require any operator action.
7. Data output is inhibited during self-tests, zeroization, and error states.
8. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the Module.
9. There are no restrictions on which keys or SSPs are zeroized after use.
10. The Module does not support concurrent operators.
11. The Module does not support a maintenance interface or role.
12. The Module does not support manual SSP establishment method.
13. The Module does not have any proprietary external input/output devices used for entry/output of data.
14. The Module does not store any plaintext CSPs.
15. The Module does not output intermediate key values.
16. The Module does not provide bypass services for ports/interfaces.

The module must be zeroized and returned to the manufacturer.

The Module does not implement any mitigation method against other attacks.

References and Definitions The following standards are referred to in this Security Policy. Table 24

• References Table 25
• Acronyms and Definitions