Rajant In-Line Security Module (RiSM)

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Rajant In-Line Security Module (RiSM)
  %% 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>update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Unauthenticated</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>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."]
    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?"]
    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"]
    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
  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,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Rajant In-Line Security Module (RiSM)
  %% 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>update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>Unauthenticated</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 C2,C3,C6 clueLow;

Security Policy, page by page

Rajant Corporation Rajant In-Line Security Module (RiSM) Version: 1.0 Date: September 23, 2025

20 0 C hes t er f i e ld Par k way

• Ma lv er n, PA 1 9 35 5
• t e l ( 4 84) 59 5- 02 33
• fax ( 4 8 4) 5 95 - 0 2 44

w w w . ra j ant . co m © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

© 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Acronym Definition KAT Know Answer Test SSP Sensitive Security Parameter CSP Critical Security Parameter PSP Public Security Parameter NK Network Key (pre-shared master key for an enclave) TEK Traffic Encryption Key TKPK Traffic Key Production Key TKPK-L2 Traffic Key Production Key Level 2 (intermediate key production key) IV Initialization Vector RiSM Rajant In-Line Security Module RiSM-MP Rajant In-Line Security Module Management Protocol POE Power over Ethernet CO Crypto Officer FW Firmware (FW-1 or FW-2 refers to stage 1 boot or stage 2 application firmware) LKEK Local Key Encryption Key PT Plaintext CT Ciphertext APT Automatic Protocol Tunneling (Rajant’s proprietary tunneling protocol for BreadCrumb) FPGA Field Programmable Gate Array SICOC Self-initiated Cryptographic Output Capability EDC Error Detection Code Table 1: Acronyms and Definitions © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

This document defines the Security Policy for the Rajant In-Line Security Module (RiSM), hereafter denoted the Module. The RiSM is an in-line network encryption device capable of very high bandwidth over gigabit Ethernet and utilizes very low POE power. The Module is used to secure layer 2 Ethernet communications over the Rajant’s Kinetic Mesh® wireless mesh networks. The Module is ruggedized and may be used in extreme environments to secure traffic between endpoints, subnets or a combination.

Section Title Security Level

Overall Level 2 Table 2: Security Levels

Purpose and Use: The Module is a Hardware cryptographic module. The Module is intended for use by US Federal agencies or other markets that require FIPS 140-3 validated in-line network encryption devices. The Module is intended to be used with Rajant’s Kinetic Mesh® wireless mesh networks to secure traffic between endpoints and/or subnets. The Module is an in-line network encryption device operating at layer 2 Ethernet. The module has two 10/100/1000 Ethernet interfaces and is powered using POE applied to either Ethernet ports. The plaintext (PT) interface of the Module, labeled POE IN, connects to a device or networking equipment that supports wired Ethernet (laptops, cameras, switches, servers, etc.) for sourcing or terminating unsecured traffic. The ciphertext (CT) interface, labeled POE OUT, connects to the mesh network. An example deployment is shown in Figure 1: RiSM Deployment Example. The Module receives Ethernet traffic from protected device or network on the PT interface, encrypts and authenticates the payload and then transmits it over the CT interface to the mesh network. The Module receives secure traffic on the CT interface, authenticates and decrypts the © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

payload and then transmits it over the PT interface to the protected device or network. The Rajant mesh network is capable of routing the traffic to its destination based solely on the Ethernet header. All RiSM modules on the network that possess the pre-shared master key (NK) are considered part of a secure enclave. When modules in a secure enclave exchange data with one another, the data is authenticated using an authenticated encryption cipher (AES-GCM) on every packet exchanged between the participating modules. The TEK, ultimately derived from the pre-shared NK, is used for the AES-GCM cipher. The module is managed using the management tool and procedures described in the latest version of the RiSM User Guide. Figure 1: RiSM Deployment Example Module Type: Hardware Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: The physical form of the Module is depicted in Figure 2: RiSM-1SPF. The cryptographic boundary is the physical mechanical enclosure outlined in red. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Ethernet Ethernet Status LED Status LED POE POE Unencrypted Encrypted Ethernet Ethernet Zeroize Power/Zeroize Module Button Switch Status LED Figure 2: RiSM-1SPF Tested Operational Environment’s Physical Perimeter (TOEPP): © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

RiSM Module Interface RiSM FIPS Main Board Modul e Board Statu s SOC: Hard Processor System (HPS) LED Zeroize Logic, RTC, Key Storage ARM CPU 1 ARM CPU 2 (NEON Enabled, Stag e 1 FW, Stag e 2 FW HPS0) (Stag e 1 FW, Stag e 2 FW HPS1) ATECC608B ON Zeroize Entropy Source PWR OFF ZEROIZE L2 Cache (HPS RAM) Flash ZERO Switches Power Enable On Chip RAM (OCRAM) (HPS RAM) Power Supply/ Battery Monitor Power Supply Traffic Encrypt/ Decrypt/ Auth Core POE Red PHY Link Status LED Pass-thru Link Status SOC: FPGA Fabric LED (Stage 2 FW FPGA, HPS RAM) POE Black PHY Figure 3: Block Diagram

Tested Module Identification

• Hardware: Model and/or Part Hardware Firmware Version Processors Features Number Version Model: RISM-1SPF 2.0 RISM_FIPS_02_03 ARM Cortex-A53 with NEON P/N: 23-100222-001 Table 3: Tested Module Identification
• Hardware Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): N/A for this module. Tested Module Identification
• Hybrid Disjoint Hardware: N/A for this module. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Tested Operational Environments - Software, Firmware, Hybrid: N/A for this module. Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A for this module.

This section is not applicable.

Modes List and Description: Mode Name Description Type Status Indicator Approved Mode The only supported mode of operation. Approved Module Status LED Table 4: Modes List and Description The Module only operates in Approved mode of operation and is shipped from the factory in this mode. The CO must follow the operational security procedures in this security policy to ensure the module is in Approved mode of operation prior to placing it in service. Approved mode of operation is indicated by a solid yellow, for Approved but un-keyed, or a solid green, for Approved and operational, module status LED after power-up. Data input and output interfaces are only enabled in the Approved and operational mode and no data is processed in any other modes. Verification of the Approved mode of operation: The Approved mode of operation is verified at reception of the Module by the CO role with the following steps.

1. Inspect the module and confirm it is a FIPS validated module by matching the model and hardware version is as specified under the tested and vendor affirmed module version and identification section.
2. Inspect the module and confirm the physical security mechanism are as specified in the physical security section.
3. Connect a POE power source to the module’s PT interface (see Figure 2: RiSM-1SPF). The module status LED will indicate a solid cyan during the boot and FIPS self-test.
4. The module status LED will indicate a solid yellow after boot and successful completion of FIPS self-tests. Note: If the module status LED is a solid green then the module was previously configured for operation and requires a zeroize operation to revert it back to the default state. Perform a zeroize and verify module status LED is solid yellow after boot and successful completion of FIPS self-tests.
5. Establish a connection between the module’s PT interface and a general purpose PC running management tool. Use the management tool to query the module and verify the firmware version is as specified under the tested module identification section. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

The status LED will indicate red for general errors or magenta for self-test and other security failures if the module fails to boot and complete FIPS self-tests successfully. The module will reboot automatically up to three times to automatically recover from errors, after which it will remain in the error state. Contact the manufacturer if it fails to enter Approved mode of operation after multiple power cycle and zeroize attempts. Status Color Description Solid Gray Device is not powered or failed to boot Solid Cyan The module is in the process of booting up. Solid Red The module has encountered an error during its boot process. Solid Magenta The module has encountered a security critical error during its boot process. Solid Yellow The module is running in Approved mode and is not fully configured or keyed. Solid Green The module is running in Approved mode and is fully configured and operational. Solid Blue The module is applying a previously downloaded application FW image. Blinking The module is in a sensitive security parameter (SSP) configuration mode allowing the CO to load Yellow keys. Blinking Blue The module is actively downloading a FW image. Blinking Red The module has encountered an error while running. Blinking The module has encountered a security critical error while running. Magenta Table 5: Module Status Led The module status may also be ascertained using the periodic module status message (UDP port 55580 multicast destination address IPv4 ‘224.0.0.224’ or IPv6 ‘fe90::’) sent every ten seconds over both PT and CT Ethernet interfaces. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Module Serial Message Origin Module Up Time PT Eth Link Status Module Status Number Interface Seconds (3 bytes) (2 bytes) (4 bytes) (1 byte) (4 bytes) Module Status 0x0000 Unkeyed 0x0001 SSP Config (Pending Set Time) 0x0002 SSP Config (Pending CO Pas sword) 0x0003 Reserved 0x0004 SSP Config (Pending Key Fill) 0x0005 SSP Config (Key Filled) 0x0006 FW Download 0x0007 Error (General or Security) 0x0008

• 0x000E Res erved 0x000F Operational Module Status Message Figure 4: Module Status Message The Ethernet link and activity status are indicated by the Ethernet Status Led for each Ethernet port as show below. Status Color Description Solid Gray Device has no Ethernet link Solid Red 10 Link, no activity Solid Yellow 100 Link, no activity Solid Green 1000 Link, no activity Blinking Red 10 activity Blinking Yellow 100 activity Blinking Green 1000 activity Table 6: Ethernet Status LED

Approved Algorithms: Algorithm CAVP Cert Properties Reference AES-GCM A4095 Direction - Decrypt, Encrypt SP 800-38D IV Generation - External Key Length - 256 AES-GCM A4096 Direction - Decrypt, Encrypt SP 800-38D IV Generation - External Key Length - 256 AES-KWP A4096 Direction - Decrypt, Encrypt SP 800-38F Key Length - 256 © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Algorithm CAVP Cert Properties Reference ECDSA KeyGen (FIPS186- A4096 Curve - P-384, P-521 FIPS 186-5

5. Secret Generation Mode - extra bits ECDSA KeyVer (FIPS186- A4096 Curve - P-384, P-521 FIPS 186-5
6. ECDSA SigVer (FIPS186- A4096 Curve - P-384 FIPS 186-5
7. Hash Algorithm - SHA2-384 Hash DRBG A4096 Prediction Resistance - Yes SP 800-90A Rev. Mode - SHA2-512 1 HMAC-SHA2-384 A4096 Key Length - Key Length: 8-65536 Increment 8 FIPS 198-1 KAS-ECC-SSC Sp800- A4096 Domain Parameter Generation Methods - P-521 SP 800-56A Rev. 56Ar3 Scheme - 3 ephemeralUnified KAS Role - responder KDA TwoStep Sp800- A4096 Derived Key Length - 256 SP 800-56C Rev. 56Cr1 Shared Secret Length - Shared Secret Length: 256 2 KDF SP800-108 A4096 KDF Mode - Feedback SP 800-108 Rev. Supported Lengths - Supported Lengths: 8-4096 1 Increment 8 SHA2-384 A4096 Message Length - Message Length: 8-65536 Increment FIPS 180-4 SHA2-512 A4096 Message Length - Message Length: 8-65536 Increment FIPS 180-4 Table 7: Approved Algorithms The Module implements the approved cryptographic algorithms listed in the table above. Vendor-Affirmed Algorithms: Name Properties Implementation Reference CKG symmetric:KDF SP800-108 Rajant RISM Crypto Library Key Generation per 133R2 Section 4 asymmetric:KAS-ECC-SSC Sp800-56Ar3 Table 8: Vendor-Affirmed Algorithms The Module implements the vendor affirmed cryptographic algorithms listed in the table above. Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: Name Caveat Use and Function AES-CTR Obfuscate stage 1 FW per IG 2.4a Scenario 1 Decryption of stage 1 FW image by boot rom SHA2-256 Redundant stage 1 FW signature verification per IG 2.4a Signature verification of stage 1 FW image by Scenario 2 boot rom ECDSA P- Redundant stage 1 FW signature verification per IG 2.4a Signature verification of stage 1 FW image by

384 Scenario 2 boot rom

Table 9: Non-Approved, Allowed Algorithms with No Security Claimed The Module implements the non-approved but allowed cryptographic algorithms with no security claimed listed in the table above. Non-Approved, Not Allowed Algorithms: N/A for this module. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Name Type Description Properties Algorithms AES GCM BC-Auth Encrypt/Decrypt RISM AES-GCM: (A4096) MP message, FW AES-ECB: (A4096) download and FW storage AES KWP BC-Auth Encrypt/Decrypt CSPs AES-KWP: (A4096) AES-ECB: (A4096) AES GCM FPGA BC-Auth Encrypt/Decrypt data AES-GCM: (A4095) traffic AES-ECB: (A4095) DRBG DRBG Random bit generator Hash DRBG: (A4096) for keys and other SHA2-512: (A4096) random data ECDSA Sig Ver DigSig-SigVer Firmware signature ECDSA SigVer verification (FIPS186-5): (A4096) SHA2-384: (A4096) KAS-SSC KAS-SSC Secure session key ECDSA KeyVer agreement shared (FIPS186-5): (A4096) secret computation ECDSA KeyGen (FIPS186-5): (A4096) KAS-ECC-SSC Sp80056Ar3: (A4096) KAS-KDF KAS-56CKDF Secure session key KDA TwoStep Sp800derivation algorithm 56Cr1: (A4096) HMAC-SHA2-384: (A4096) KDF SP800-108: (A4096) SHA2-384: (A4096) SHA2-384 SHA Hash the password SHA2-384: (A4096) KBKDF KBKDF Derive traffic keys KDF SP800-108: (A4096) HMAC-SHA2-384: (A4096) Table 10: Security Function Implementations The Module implements the security functions listed in the table above.

AES-GCM: Data Traffic Service deterministic IV generation and restoration: The data traffic IV consists of a 32-bit fixed field, unique to the module, and a 64-bit invocation field, incremented by 1 after each use. The invocation field wraps after 2^64 increments. However, the module is not capable of reaching this limit as the key duration is 24 hours. The module can at most process 103,846,147,200 Ethernet frames at 1 gigabit link rate in a 24-hour period. The service does not error on wrap around as the 64-bit invocation field space is sufficiently large to ensure an IV cannot wrap around. The upper 32-bit value of the invocation field is incremented and stored in flash every time the lower 32-bit value wraps. The stored value in flash is used to initialize the upper 32-bits of the invocation field on reset, eliminating the possibility of replicating a previously used invocation field upon restoration. Secure Session Service deterministic IV generation and restoration: © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

The secure session IV consists of a 72-bit fixed field, generated randomly each time a new key session key is established and a 24-bit invocation field, incremented by 1 after each use. The invocation field wraps after 2^24 increments after which the secure session is terminated. A new secure session is established in the case of power loss or reset.

Cert Vendor Name Number E46 Microchip Technology Inc Table 11: Entropy Certificates Name Type Operational Sample Entropy Conditioning Environment Size per Component Sample ECC608 NRBG Entropy Source Physical ATECC608B 1 0.5071 None Table 12: Entropy Sources

The module generates symmetric keys in compliance with NIST SP 800-133r2, sections 4, 6.2.1 and 6.2.2, using a NIST SP 800-90A Hash DRBG for random number generation and NIST SP 800-90B entropy source (see section 2.8 RBG and Entropy). Asymmetric keys are generated in compliance with NIST SP 800-133r2, sections 5.1 and 5.2 and FIPS 140-3 IG D.H.

Key establishment is performed in compliance with NIST SP 800-56Arev3 section 6.1.2.2 and NIST SP 800-56CRev2 section 5. No key confirmation is supported. Key transport is performed in compliance with FIPS 140-3 IG D.G using AES GCM algorithm. See AES-GCM in section 2.7.

The section is not applicable.

The module implements a proprietary protocol for configuration and management secured with approved cryptographic algorithms. The Rajant In-Line Security Module Management Protocol (RiSM-MP) establishes a logical UDP based authenticated and encrypted control channel over the PT or CT network interface. It utilizes 56Ar3 Ephemeral Unified ECC CDH key agreement scheme to establish a session key to encrypt all sensitive data with AES GCM 256 encryption. The CO role is also authenticated as part of establishing the secure channel. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Physical Port Logical Data That Passes Interface(s) OFF/ON/Zeroize Control Input None Switch Zeroize Button Control Input None Module Status LED Status Color coded module state Output PT Eth Status LED Status Link speed and activity Output CT Eth Status LED Status Link speed and activity Output PT Eth/POE IN (M12) Data Input POE power, PT network traffic, module configuration and management, network control Data Output protocols, module status message Control Input Status Output Power CT Eth/POE OUT Data Input POE power, CT network traffic, module configuration and management, network control (M12) Data Output protocols, module status message Control Input Status Output Power Table 13: Ports and Interfaces The Module’s ports and associated FIPS defined logical interface categories are listed in the above table.

Method Description Security Strength Strength Name Mechanism Each per Attempt Minute Password Memorized secret used to authenticate an operator. SHA2-384 1/95^8 30/95^8 Table 14: Authentication Methods Password: The password authentication method is used for role based authentication for operators accessing the module over RiSM-MP secure session. The minimum passphrase length is eight bytes. The passphrase character set consists of the 95 printable characters of A-Z, a-z, 0-9, space, and the 32 special characters (! @ # $ % ^ & * ( ) _ + - = [ ] { } ; ' : “ , . / < > ? \ | ` ~) . The Module will reject all operator authentication attempts after 30 consecutive failed attempts for a period of one-minute beginning with the time of first failed attempt. Thus no more than 30 © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

failed authentication attempts are allowed per minute. The probability of a successful passphrase guess in a single attempt using the character set described above is 1/95^8, which is lower than the required 1/1,000,000. The probability of a successful guess using multiple attempts in a one-minute period using the rate limit described above is 30/95^8, which is lower than the required 1/100,000.

Name Type Operator Type Authentication Methods CO Role Crypto Officer Password Table 15: Roles The module supports a single distinct authenticated operator role, Cryptographic Officer (CO). The cryptographic module enforces separation of roles by utilizing role based access control for authenticated services. The above table lists all roles supported by the module. The Module does not support a maintenance role. The Module does not support bypass capability. The Module does not support concurrent operators. The CO role is authenticated using a password. The module has a default CO password which must be changed during initialization of the module. The CO password is transmitted to the module encrypted using approved algorithms. The CO role authentication is cleared upon reset as well as after 120 seconds of inactivity and it must be re-established by the operator. Prior authentications are cleared any time a role is authenticated.

Name Description Indicator Inputs Outputs Security SSP Access Functions Version Retrieve version Version data Version request Version AES GCM CO Information information (Show including model, message response - RISM-MP-SK: Version) overall FW message E version, FW component versions, serial number and HW version. Status Retrieve module Module status, Request Response AES GCM CO Information status, HW status, HW status data, message for message with AES KWP - RISM-MP-SK: LED status, key LED status, key module status, module status, E status and network status and HW status, LED HW temp and - LKEK-S2: E statistics (Show network statistics status, key voltages data, - LKEK: G,E,Z Status) data status, or LED status, key - NK: E network status, or Unauthenticated statistics network - LKEK-S2: E statistics data - LKEK: G,E,Z - NK: E Audit Log Retrieve binary Binary audit data Audit request Audit response AES GCM CO audit log file messages messages with - RISM-MP-SK: audit data E Configuration Retrieve and Configuration Request Response AES GCM CO configure SSPs success or message to get message with AES KWP - RISM-MP-SK: and other module failure response, time, set time, current time, E parameters Configuration set IP, get MTU, set time - LKEK-S2: E value response set MTU, success or - LKEK: G,E,Z enable/disable failure, set IP - NK: W anti-replay, set success or - Password: W © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Name Description Indicator Inputs Outputs Security SSP Access Functions network key, set failure, current CO password, MTU, current enable/disable MTU, antiLEDs, or replay enabled enter/exit config setting, set network key result, set CO password success or failure, current LEDs enabled setting or current module state Secure Start and stop an Session Start session Start session DRBG CO Session encrypted and response message with response KAS-SSC - RISM-MP-DH: authenticated message with session message with KAS-KDF G,E,Z session session parameters, end session AES KWP - RISM-MP-DHparameters session parameters, SHA2-384 Pub: G,R,E,Z message end session - RISM-MPresponse Secret: G,E,Z message - RISM-MP-SK: G,Z - LKEK-S2: E - LKEK: G,E,Z - NK: E - DRBG-EI: E - Password: E - DRBG-State V: E - DRBG-State C: E - 108-KDF Feedback State: G,E,Z - 56Cr1-TwoStep KDA State: G,E,Z - Module Challenge Response: G,R,Z - CO Auth Token: G,W,E,Z - RISM-MP-DHPub Peer: W,E,Z Firmware Download Module status FW update FW update AES GCM CO Update firmware image FW Download, request response ECDSA - RISM-MP-SK: and verify automatic messages, FW message with Sig Ver E signature, reset to module reset and update data result - FW-2-Updateapply update zeroize on message Pub: E success - FW-1-UpdatePub: E Module Module reset, self- Self-test initiated Self-test request Self-test AES GCM CO reset/Self- test and response, message response - RISM-MP-SK: test initialization. automatic reset message E of module - FW-1-LoadPub: E Data traffic Encrypt/Decrypt Module status Plaintext, Ciphertext, AES GCM Unauthenticated network packets OPERATIONAL Ciphertext data plaintext data FPGA - TEK: G,E,Z between other KBKDF - TKPK: G,E,Z modules in the - TKPK-L2: enclave. This G,E,Z service is enabled - NK: E as a result of self- - LKEK: E initiated cryptographic © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Name Description Indicator Inputs Outputs Security SSP Access Functions output capability configured by the CO using the Configuration service. Zeroize Zeroize the Zeroize initiated Zeroize request Zeroize AES GCM CO specified SSPs. response, message, response - RISM-MP-SK: module status Manual zeroize message E,Z STANDBY after with toggle - DRBG-EI: Z automatic reset switch and - Password: Z zeroize button - LKEK: Z - LKEK-S2: Z - NK: Z - TKPK: Z - TKPK-L2: Z - TEK: Z - RISM-MP-DH: Z - RISM-MPSecret: Z - DRBG-State V: Z - DRBG-State C: Z Table 16: Approved Services

A module running in Approved mode of operation is capable of receiving a firmware update. The firmware update is a partial image replacement, either stage 1 or the stage 2 FW. The firmware update is performed by the CO as follows. See section 6.2 for additional FW loading requirements.

1. Ensure the FW update file is received directly from Rajant. A FW update file from Rajant is signed and encrypted by Rajant. Any other file will fail integrity validation and the FW will not be updated.
2. Perform the FW update using the management tool. Note that the module will be in SSP config state and not encrypt or decrypt data traffic during FW update.
3. The module will perform a ECDSA signature verification FW load test on the downloaded FW.
4. The module will reset automatically after downloading the FW and passing the FW load test to apply the new FW and perform self-tests.
5. Read the module FW version using the management tool and ensure it is matches the new FW version.

The module supports SICOC initiated by the CO using the module’s Configuration service. The initiation process is described in the section 11.1, under Module Initialization. The module will © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

automatically enter the operational state after boot and show status output of OPERATIONAL, indicating SICOC is active, enabling the Data Traffic service.

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

• Stage 1 firmware: executable binary stored encrypted in flash
• Stage 2 firmware: executable binary and FPGA image stored encrypted in flash Stage 1 firmware authenticates its stored flash image using ECDSA P-384. Stage 2 firmware stored flash image integrity is verified using 128-bit EDC.

The operator can initiate the integrity test on demand by performing a module reset or power cycle.

Type of Operational Environment: Limited

The Module has a limited operational environment under the FIPS 140-3 definitions. The Module includes a firmware update service to support necessary updates. Firmware versions validated by CMVP for FIPS 140-3 will be explicitly identified on a validation certificate. Any firmware not identified in this Security Policy does not constitute the Module defined by this Security Policy or covered by this validation.

Mechanism Inspection Inspection Guidance Frequency Tamper Evident Seal 90 days Verify there are no cracks in or crumbling of the applied Cyanoacrylate material Table 17: Mechanisms and Actions Required The Module is a monolithic mechanical enclosure secured with four screws on the bottom. There are no openings to give visual or physical access to the internal components. The Module must be located in a controlled access area. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

The tamper evidence is provided by the use of a cyanoacrylate material (Loctite® 425, mfg. Part no. 42540, available from Rajant) covering selected chassis access screws. Screws requiring application are indicated in figure below. It is recommended that the CO perform regular inspections of the Module while in operation. The recommended tamper inspection period for the Module is once every 90 days. Any attempt to open the Module will be visible as cracks in the Cyanoacrylate material or crumbling of the material. Zeroize and remove module from service upon tamper detection and contact manufacturer. Physical Security Mechanism Recommended Frequency of Inspection/Test Guidance Details Inspection/Test Tamper Evident Seal 90 days Verify there are no cracks in or crumbling of the applied Cyanoacrylate material. Table 18: Physical Security Inspection Guidelines The Module will be shipped from the manufacturer with tamper-evident coatings pre-applied, as shown below. Tamper Seal 2 Mounting Holes Pressure Valve Tamper Seal 1 Figure 5: Module Seal Application Locations (Bottom) Label ID Placement Tamper Seal 1 The drive of the screw near pressure relief valve Tamper Seal 2 The drive of the screw diagonal from pressure relief valve and Tamper Seal 1 Table 19: Tamper-Evident Seal Locations Guidance © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

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

Storage Description Persistence Area Name Type Flash Flash memory Static HPS RAM RAM incorporated in the HPS and FPGA Dynamic Key Storage Battery backed RAM of security chip Dynamic Table 20: Storage Areas

Name From To Format Distribution Entry SFI or Type Type Type Algorithm CO Authentication Management Tool Module Plaintext Automated Electronic SHA2-384 Module Authentication Module Management Tool Plaintext Automated Electronic SHA2-384 Config Management Tool Module Encrypted Automated Electronic AES GCM FW Update Manufacturer Module Encrypted Automated Electronic AES GCM Pre-loaded Manufacturer Module Encrypted N/A N/A AES GCM Table 21: SSP Input-Output Methods

Zeroization Description Rationale Operator Initiation Method Overwrite Overwrite SSP with all zeros or An overwritten or erased memory Zeroize command issued remotely, perform an erase operation in location in RAM or flash is manual zeroize using physical switch flash, and then write new value. unrecoverable by hardware design. and button or a FW update operation. Table 22: SSP Zeroization Methods

© 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Name Description Size - Type - Category Generated By Established Used By Strength By DRBG-EI Entropy input 888 - 256 Entropy - CSP ECC608 NRBG DRBG Entropy Source DRBG-State V DRBG Internal state 888 - 256 Entropy - CSP DRBG DRBG DRBG-State C DRBG Internal state 888 - 256 Entropy - CSP DRBG DRBG 108-KDF 108 KDF Feedback 384 - 192 Derivation HMAC-SHA2-384 KBKDF Feedback internal state material - CSP (A4096) State 56Cr1-Two- 56Cr1 Two-Step KDA 384 - 192 Derivation HMAC-SHA2-384 KAS-KDF Step KDA internal state material - CSP (A4096) State Password CO authentication 64 - Authentication - SHA2password 1/95^8 CSP 384 CO Auth CO password hash 384 - 192 Authentication - SHA2-384 Token CSP Module Module authentication 384 - 192 Authentication - SHA2-384 Challenge hash CSP Response LKEK SSP encryption key 256 - 256 Symmetric - CSP KBKDF AES KWP LKEK-S2 LKEK derivation key 256 - 256 Symmetric - CSP DRBG KBKDF NK TKPK derivation key 256 - 256 Symmetric - CSP KBKDF TKPK TKPK-L2 derivation key 256 - 256 Symmetric - CSP KBKDF KBKDF TKPK-L2 TEK derivation key 256 - 256 Symmetric - CSP KBKDF KBKDF TEK Traffic encryption key 256 - 256 Symmetric - CSP KBKDF AES GCM FPGA RISM-MP-SK CO session encryption 256 - 256 Symmetric - CSP KAS-KDF AES GCM key RISM-MP-DH CO session private key P-521 - Private - CSP DRBG KAS-SSC RISM-MP- CO session 56Ar3 P-521 - Derivation KAS-SSC KAS-KDF Secret generated secret 256 material - CSP RISM-MP-DH- CO session module P-521 - Public - PSP ECDSA KeyGen KAS-SSC Pub public key 256 (FIPS186-5) (A4096) RISM-MP-DH- CO session peer public P-521 - Public - PSP KAS-SSC Pub Peer key 256 FW-2-Update- Stage 2 FW integrity 384 - 192 Not an SSP - ECDSA Pub public key used to verify Neither Sig Ver new image FW-1-Update- Stage 1 FW integrity 384 - 192 Not an SSP - ECDSA Pub public key used to verify Neither Sig Ver new image FW-1-Load- Stage 1 FW integrity 384 - 192 Not an SSP - ECDSA Pub public key used on boot Neither Sig Ver Table 23: SSP Table 1 Name Input - Output Storage Storage Zeroization Related SSPs Duration DRBG-EI HPS RAM:Plaintext While in Overwrite use DRBG-State V HPS RAM:Plaintext Until Overwrite zeroized DRBG-State C HPS RAM:Plaintext Until Overwrite zeroized 108-KDF Feedback HPS RAM:Plaintext While in Overwrite State use 56Cr1-Two-Step HPS RAM:Plaintext While in Overwrite KDA State use Password Config HPS RAM:Plaintext While in Overwrite LKEK:Wrapped by Flash:Encrypted use CO Auth Token:Hash input for CO Auth Token CO Authentication HPS RAM:Plaintext While in Overwrite Password:Hash digest of use NK:Hash digest of Module Challenge Module HPS RAM:Plaintext While in Overwrite Response Authentication use © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Name Input - Output Storage Storage Zeroization Related SSPs Duration LKEK HPS RAM:Plaintext While in Overwrite Password:Wraps use NK:Wraps LKEK-S2:Derived from LKEK-S2 Key Until Overwrite LKEK:Derives Storage:Plaintext zeroized NK Config HPS RAM:Plaintext While in Overwrite LKEK:Wrapped by HPS use TKPK:Derives RAM:Encrypted CO Auth Token:Hash input Flash:Encrypted for TKPK HPS RAM:Plaintext While in Overwrite NK:Derived from HPS use TKPK-L2:Derives RAM:Encrypted LKEK:Wrapped by TKPK-L2 HPS RAM:Plaintext While in Overwrite TKPK:Derived from HPS use TEK:Derives RAM:Encrypted LKEK:Wrapped by TEK HPS RAM:Plaintext While in Overwrite TKPK-L2:Derived from HPS use LKEK:Wrapped by RAM:Encrypted RISM-MP-SK HPS RAM:Plaintext While in Overwrite RISM-MP-Secret:Derived use from RISM-MP-DH HPS RAM:Plaintext While in Overwrite RISM-MP-Secret:Derives use RISM-MP-DH-Pub:Paired With RISM-MP-Secret HPS RAM:Plaintext While in Overwrite RISM-MP-DH:Derived from use RISM-MP-DH-Pub Peer:Derived from RISM-MP-SK:Derives RISM-MP-DH-Pub CO Authentication HPS RAM:Plaintext While in Overwrite RISM-MP-DH:Paired With use RISM-MP-DH-Pub CO Authentication HPS RAM:Plaintext While in Overwrite RISM-MP-Secret:Derives Peer use FW-2-Update-Pub Pre-loaded HPS RAM:Plaintext Until Overwrite FW Update Flash:Encrypted zeroized FW-1-Update-Pub Pre-loaded HPS RAM:Plaintext Until Overwrite FW Update Flash:Encrypted zeroized FW-1-Load-Pub Pre-loaded HPS RAM:Plaintext Until Overwrite FW Update Flash:Plaintext zeroized Table 24: SSP Table 2

Algorithm Test Test Test Type Indicator Details or Test Properties Method RAM Test N/A Critical status OPERATIONAL or Write and verify data pattern in RAM Function STANDBY FW-1 P-384 SW/FW status OPERATIONAL or Verify stage 1 FW signature Integrity curve Integrity STANDBY FW-2 128-bit SW/FW status OPERATIONAL or Verify stage 2 FW using EDC method Integrity EDC Integrity STANDBY Control N/A Critical status OPERATIONAL or Performs a control path packet injection Path Function STANDBY test from PT to CT and CT to PT interfaces Table 25: Pre-Operational Self-Tests

© 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Algorithm or Test Properties Test Test Indicator Details Conditions Test Method Type SHA2 384 N/A KAT CAST status Digest Boot, FW OPERATIONAL or Download STANDBY SHA2 512 n/A KAT CAST status Digest Boot OPERATIONAL or STANDBY ECDSA Key P-521 curve KAT CAST status Generate public Boot Gen OPERATIONAL or key STANDBY ECDSA Key P-521 curve KAT CAST status Verify public key Boot Ver OPERATIONAL or STANDBY ECDSA Sig P-384 curve KAT CAST status Verify signature Boot, FW Ver OPERATIONAL or Download STANDBY AES GCM 256 bit key, 96 bit IV, KAT CAST status Encrypt Boot Encrypt 128 bit tag OPERATIONAL or STANDBY AES GCM 256 bit key, 96 bit IV, KAT CAST status Decrypt Boot Decrypt 128 bit tag OPERATIONAL or STANDBY AES KWP 256 bit key KAT CAST status Wrap Boot Wrap OPERATIONAL or STANDBY AES KWP 256 bit key KAT CAST status Unwrap Boot Unwrap OPERATIONAL or STANDBY KAS SSC P-521 curve KAT CAST status Generate shared Boot OPERATIONAL or secret STANDBY KDA Two- 256 bit key, SHA-384, KAT CAST status Derive key Boot Step 68 bytes fixed data OPERATIONAL or STANDBY DRBG 888 bits entropy, 128 KAT CAST status Generate C and V Boot Instantiate bit nonce OPERATIONAL or STANDBY DRBG 128 bytes of random KAT CAST status Generate random Boot Generate data OPERATIONAL or data STANDBY DRBG 888 bits reseed KAT CAST status Update C and V Boot Reseed entropy OPERATIONAL or STANDB KDF 384 bit key, 384 bit IV, KAT CAST status Derive key Boot Feedback 2400 bit output key, 51 OPERATIONAL or bytes fixed data STANDBY HMAC SHA2-384 KAT CAST status Generate MAC Boot OPERATIONAL or STANDBY Entropy N/A RCT, CAST status Perform entropy DRBG request Health Test APT OPERATIONAL or source health STANDBY tests AES GCM 256 bit key, 96 bit IV, KAT CAST status Encrypt Boot FPGA Encrypt 128 bit tag OPERATIONAL or STANDBY AES GCM 256 bit key, 96 bit IV, KAT CAST status Decrypt Boot FPGA 128 bit tag OPERATIONAL or Decrypt STANDBY KAS P-521 Curve PCT PCT CO Authenticated Verify ephemeral CO Ephemeral key pair per Authentication Key PCT 56Ar3 FW-1 Update ECDSA P-384 Sig Ver SW/FW module reboot Verify signature of FW Download Load downloaded image FW-2 Update ECDSA P-384 Sig Ver SW/FW module reboot Verify signature of FW Download Load downloaded image Table 26: Conditional Self-Tests © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Algorithm or Test Test Method Test Type Period Periodic Method RAM Test Critical Function FW-1 Integrity SW/FW Integrity FW-2 Integrity SW/FW Integrity Control Path Critical Function Table 27: Pre-Operational Periodic Information Algorithm or Test Test Method Test Type Period Periodic Method SHA2 384 KAT CAST SHA2 512 KAT CAST ECDSA Key Gen KAT CAST ECDSA Key Ver KAT CAST ECDSA Sig Ver KAT CAST AES GCM Encrypt KAT CAST AES GCM Decrypt KAT CAST AES KWP Wrap KAT CAST AES KWP Unwrap KAT CAST KAS SSC KAT CAST KDA Two-Step KAT CAST DRBG Instantiate KAT CAST DRBG Generate KAT CAST DRBG Reseed KAT CAST KDF Feedback KAT CAST HMAC KAT CAST Entropy Health Test RCT, APT CAST AES GCM FPGA KAT CAST Encrypt AES GCM FPGA KAT CAST Decrypt KAS Ephemeral Key PCT PCT PCT FW-1 Update Sig Ver SW/FW Load FW-2 Update Sig Ver SW/FW Load Table 28: Conditional Periodic Information

Name Description Conditions Recovery Method Indicator ES1 Boot Error Bootrom fails to load Power cycle, contact The module status LED will be off stage 1 FW manufacturer ES2 Stage 1 FW Any self-test failure in Power cycle, contact The module status LED will be solid red for Error stage 1 FW manufacturer general error, solid magenta for security error Processor exception in stage 1 FW Unrecoverable error in stage 1 FW ES3 Stage 2 FW Any self-test failure in Power cycle, contact The module status LED will be flashing red for Error stage 2 FW manufacturer general error, flashing magenta for security error Processor exception in stage 2 FW Unrecoverable error in stage 2 FW Table 29: Error States

© 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

The Module allows the operator to initiate power-up self-tests by manually power cycling the power or remotely resetting the Module using the self-test service.

The CO must perform the following steps to securely deploy modules in Approved mode of operation. Deployment:

1. Verify module is ready for Approved mode of operation by following steps in section 2.4.
2. Establish a connection between the module and a general purpose PC running management tool. The module may be installed in the network prior to initialization. However, a direct network connection is recommended for module initialization and then subsequently deploy the initialized module to the network. Module Initialization: A module running in Approved mode of operation is ready to be initialized by the CO to provide the data encryption and decryption service between modules in the enclave. It supports selfinitiated cryptographic output capability after being initialized by the crypto officer. Use the management tool to initialize the module.
3. Generate an enclave configuration file, if one is not available. CO is responsible for protecting the enclave configuration file. ‘rismtool addkey <enclave file name>’
4. Initialize module using the enclave configuration file and default CO password. ‘rismtool init <default IP address> <enclave file name> This step will configure the current date and time, update the default CO password and load network key for the enclave.
5. Verify module status led is green indicating module is operational. An initialized module will automatically enter operational state on subsequent boot based on a valid network key being present and non-default CO password.

This section is not applicable.

This section is not applicable. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

Overall security design:

1. The Module provides role-based authentication with a single distinct operator role: Cryptographic Officer.
2. The Module also has self-initiated cryptographic output capability in order to participate in a secure network enclave with other Modules. Enclave packets are authenticated using AES GCM encryption with pre-shared key on a per packet basis.
3. The Module clears previous role authentications on power cycle, upon a new authentication and after a two-minute timeout.
4. The Module does not support concurrent authenticated operators.
5. An operator does not have access to any cryptographic services prior to assuming an authorized role.
6. The Module allows the operator to initiate power-up self-tests by power cycling power or resetting the Module. Power up self-tests do not require any operator action.
7. Data output are inhibited during key establishment, boot up and self-tests, FW update, 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. All SSPs, except as noted in the security policy, are zeroized and the module is restored to factory default state after zeroization. The CO will need to re-initialize the module per section 11.1 and 2.4.
10. The Module does not support a maintenance interface or role.
11. The Module does not support manual SSP establishment methods.
12. The Module does support entering plaintext CSPs. These CSPs and SSPs are initially entered by the CO over an AES-GCM encrypted network link using management tool running on a general purpose computer. This is covered under the “CO Authentication” method in table 21.
13. The Module does not store any plaintext CSPs outside of RAM.
14. The Module does not output intermediate key values.
15. The Module does not provide bypass services or ports/interfaces. Rules of operation: The module must be operated in accordance with the following rules.
16. The Module must be initialized and operated in accordance with Verification of Approved Mode of operation and Life-Cycle Assurance sections.
17. Regularly inspect Module for damage and tampering (see Physical Security section).
18. Regularly verify the installed firmware version is approved using the management tool.
19. Only update module firmware with approved versions.
20. Regularly verify the operational status of the module using the management tool and promptly address any error status. Remove module from service if error status is not resolved by a reboot.
21. The module enforces an 8-byte minimum length for CO password. It is recommended to establish a strong CO passphrase policy and change passphrases on a regular basis.
22. The module supports configuration two network keys at a time for seamless key rollover for the data service. It enforces a maximum network key period of one year and will © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.

inhibit data service when no network keys are configured. It is recommended to check and configure a new network key as the active key expires.

8. Use a trusted general purpose PC to run the management tool.
9. Ensure the protection of network key is only entrusted to COs.
10. Zeroize modules when not in operation or returning to manufacturer.

Operation:

1. The network key period must not exceed one year. CO must update network key prior to expiration for seamless operation.
2. CO must periodically verify and update module time to compensate for clock drift so that data encryption keys remain synchronized across the secure network enclave. Firmware Update: A module running in Approved mode of operation is capable of receiving a firmware update. The CO performs a firmware update when Rajant releases new firmware using the process described in external software/firmware loaded section. See section 6.2 for additional FW loading requirements.

Decommission: The module must be zeroized prior to decommissioning or re-deployment.

Anti-Replay: The Module is designed to reject replayed encrypted packets received on the ciphertext interface. Any encrypted packet received on the ciphertext interface that is determined to be replayed is dropped and not forwarded to the plaintext interface. The anti-replay mechanism only applies to encrypted packets on the ciphertext interface. © 2025 Rajant Corporation Rajant Public Material - May be reproduced and distributed only in its original entirety without revision.