Wave Relay® Kernel Space Crypto Module

Certificate

Approved Algorithms (31)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Wave Relay® Kernel 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["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>SF2</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>IPSEC<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>kernel<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    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["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® Kernel 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["[high] Unauthenticated / self-test / status service surface<br/><i>SF2</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>IPSEC<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>kernel<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,C5,C6 clueLow;
  class C3 clueHigh;

Security Policy, page by page

Persistent Systems, LLC Wave Relay® Kernel Space Crypto Module Document Version: 1.5 Date: January 14, 2026 Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

This document is the non-proprietary FIPS 140-3 Security Policy for version 1.1 of the Persistent Systems LLC Wave Relay® Kernel Space Crypto Module. It contains the security rules under which the Module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for an overall Security Level 2 module.

The FIPS 140-3 security levels for the Module are as follows from Table 1: N/A N/A Table 1: Security Levels Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

FIPS validated connectivity drives mission success. This Persistent Systems LLC Wave Relay® Kernel Space Crypto Module, hereafter denoted as the “module”, is a Software-Hybrid cryptographic module operating on a single-chip device that provides FIPS validated cryptographic algorithms which are used by kernel space system services & protocols (e.g. Wave Relay, 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 heart of the moment. Module Type: Software-hybrid Module Embodiment: SingleChip Cryptographic Boundary: The Module is a single-chip embodiment. Figure 1 below shows a block diagram of the cryptographic boundary. The cryptographic boundary is outlined in red and defined as a combination of the software kernel library (FIPS140.ko) and the hardware crypto IP core within the NXP i.MX 6 Series SoC (System on a Chip). The disjoint hardware component is the hardware-only cryptographic algorithms and entropy source depicted on the left side of Figure 1 under “Crypto Accelerator and Assurance Module (CAAM)”. The software component is the “FIPS Kernel Module” on the right side of Figure 1, which includes the SW Crypto Functions (which may utilize PAA), as well as the FIPS Self-Test implementations and CAAM Driver. The Module supports both hardware (Cryptographic Accelerator and Assurance Module (CAAM)) and software based cryptographic operation. The flow of information between the components and the relation between data and the Module’s interfaces are depicted through arrows. Tested Operational Environment’s Physical Perimeter (TOEPP): Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

The TOEPP of the Module is depicted in Figure 2 below.The TOEPP is the NXP i.MX6 SOC. Figure 1- Cryptographic Boundary Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

There are four physical variants of the chip as shown in Figure 2 below. Figure 2 - Physical Perimeter

Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets): The cryptographic module is tested on the following operational environments: 1.1 Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Module Identification
• Hybrid Disjoint Hardware: The cryptographic module is tested on the following operational environments: Persistent Systems, LLC Public Material
• May be reproduced only in its original entirety (without revision).

Table 3: Tested Module Identification

• Hybrid Disjoint Hardware Tested Operational Environments - Software, Firmware, Hybrid: Wave Relay® Kernel Space Crypto Module cryptographic module is tested on the following operational environments. 2.2 2.2 2.2 2.2 2.2 2.2 2.2 2.2 1.1 1.1 1.1 1.1 1.1 1.1 1.1 1.1 Table 4: Tested Operational Environments - Software, Firmware, Hybrid

No components were excluded from the cryptographic boundary.

Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Modes List and Description: support a degraded mode. NonApproved =1 NonApproved =0 Table 5: 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® Kernel Space Crypto Module (HW) version 1.0 (Cert. #A4588) Wave Relay® Kernel Space Crypto Module (SW) version 1.0 (Cert. #A4589) Validation certificates for each Approved security function are listed in the table below. Version 1.3 Persistent Systems, LLC Public Material
• May be reproduced only in its original entirety (without revision).

Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Table 6: Approved Algorithms Vendor-Affirmed Algorithms: The Module does not support any vendor affirmed cryptographic algorithms. N/A for this module. Non-Approved, Allowed Algorithms: The module does not implement any Non-Approved, but Allowed Algorithms in the Approved Mode of Operation. Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

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 Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

The table below shows the Security Function Implementations that the module implements: Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Table 8: Security Function Implementations Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Below are the documentation requirements for specific algorithms and conditions, as mandated by Implementation Guidance. AES GCM IV Uniqueness FIPS140-3 IG C.H, Option 2 The IV is generated internally at its entirety randomly. The generation uses an Approved DRBG (Cert. #A4589) 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 The XTS algorithm implementation includes a check prior to use to ensure Key_1 ≠ Key_2. SHA-1 The use of SHA-1 by the “Hash” service is only approved for integrity checks and is not approved for use as part of a digital signature.

Table 9: Entropy Certificates The Module uses the following entropy sources: Table 10: Entropy Sources Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Persistent Systems is using a physical free running ring oscillator to generate entropy input for instantiation and reseed of SP 800-90A compliant DRBGs. The entropy source is the True Random Number Generator (TRNG) sub-component of an NXP i.MX 6 SoC chip. The entropy source performs all required health tests of SP 800-90B, which includes continuous, start-up and on-demand health tests. There are no configurations needed by the operator to use the entropy source in accordance with the Public Use Document for ESV Cert. #E82. Whenever a failure is detected during the health testing, entropy data is not returned to the caller; instead, a failure code is returned to enable the caller to determine the reason for the failure. The entropy source then halts and will refuse new requests for entropy. Upon return of the failure, the operator shall reset or reboot the entropy source. The entropy source will continue to operate after being reset and passing all start-up and continuous health tests. The default Approved DRBG used for random number generation is the HMAC_DRBG (Cert A4589) using SHA2-512. In addition, the module also provides HMAC_DRBG, CTR_DRBG and HASH_DRBG using different mechanisms and key sizes. The DRBGs are all internally seeded by using the entropy source (ESV Cert. #E82). The security strength of the DRBG is determined by the internal mechanism selected (i.e., 256-bits security strength for a CTR_DRBG using AES-256). The operator shall select the appropriate DRBG mechanism for the security strength required when using the “Random Bit Generation” service.

The module does not support Key Generation Functions.

Key Agreement Information The module does not support Key Agreement Functions. Key Transport Information The module does not support Key Transport Functions.

The module does not implement any Industry Protocols. Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

The Module’s ports and associated FIPS defined logical interface categories are listed below. N/A N/A N/A N/A N/A N/A Table 11: Ports and Interfaces Note: The module does not support Control Output. Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

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 13: 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:

• 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 (SSP is input).
• E = Execute: The Module uses the SSP in performing a cryptographic operation.
• Z = Zeroize: The Module zeroizes the SSP Version 1.3 Persistent Systems, LLC Public Material
• May be reproduced only in its original entirety (without revision).

Module SelfTest ion, preoperation m selftests. a g E Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

a securitystrength W,E RBGState: W,E RBGState: W,E N/A - DRBGEI: G,R =1 N/A Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Z RBGState: Z RBGState: Z Table 14: Approved Services

All approved services implemented by the Module are listed in the table below: Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Table 15: Non-Approved Services

The module does not support an External Software/Firmware Load capability. Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

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

• Component 1: software cryptographic kernel library - binary Component 2: hardware-implemented cryptographic algorithms 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. Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

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. Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

The design and physical security characteristics of the Wave Relay Kernel Space Crypto module meet the intent of the FIPS 140-3 Level 2 Physical Security Requirements, based on the test results described in the physical security test report. The embodiment of the Module is a single chip, which is opaque and also provides tamper evidence. The module has been subjected to FIPS140-3 Level 2 physical security analysis.

The module has: o o o

• Production grade components with standard passivation (conformal coating/sealing coating) for environmental protection The Module has tamper-evident coating Susceptible to evidence of tampering on the external boundary when attempts to gain physical access External boundary shall be opaque to prevent knowledge of the critical areas of the module N/A for this module. Version 1.3 Persistent Systems, LLC Public Material
• May be reproduced only in its original entirety (without revision).

The Module does not implement any mitigation method against non-invasive attack. Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Table 16: Storage Areas Table 17: SSP Input-Output Methods N/A Table 18: SSP Zeroization Methods Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

All usage of these SSPs by the Module are described in the services detailed in Section 4.3 CTR_DRBGState h d Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

h d Table 19: SSP Table 1 CTR_DRBGState HMAC_DRBGState HASH_DRBGState N/A N/A DRBGEI:Derived DRBGEI:Derived DRBGEI:Derived Table 20: SSP Table 2 Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

The Module performs self-tests to ensure the proper operation of the Module. Per FIPS 140-3 these are categorized as either preoperational 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 HMAC SHA2256 Table 21: Pre-Operational Self-Tests

The Module performs the following conditional self-tests in the table below: Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Table 22: Conditional Self-Tests

Table 23: Pre-Operational Periodic Information Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Table 24: 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. Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

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.

Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

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. 2. 3. 4. 5. 6.

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

The module must be zeroised and returned to the manufacturer.

The Module does not implement any mitigation method against other attacks. Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

Version 1.3 Persistent Systems, LLC Public Material

• May be reproduced only in its original entirety (without revision).

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

• References Persistent Systems, LLC Public Material
• May be reproduced only in its original entirety (without revision).

Table 27

• Acronyms and Definitions Version 1.3 Persistent Systems, LLC Public Material
• May be reproduced only in its original entirety (without revision).