UT-125 FIPS #31 and #41 Cryptographic Module

Certificate

Approved Algorithms (3)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for UT-125 FIPS #31 and #41 Cryptographic Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>Rev1.6</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Firmware Update</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Show Status</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C1 --> I1 --> R1 --> E1
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C1,C2,C3,C6 clue;
  class I1,I2,I3,I6 infer;
  class R1,R2,R3,R6 risk;
  class E1,E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for UT-125 FIPS #31 and #41 Cryptographic Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>Rev1.6</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Firmware Update</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Show Status</i><br/>src: securityPolicy.services"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C1,C2,C3 clueHigh;
  class C6 clueLow;

Security Policy, page by page

UT-125 FIPS #31 and #41 Cryptographic Module Hardware versions 1.2, 1.3, 2.2 and 2.3 Firmware version 1.6 Document Revision 2.7 Icom Inc. 1-1-32, Kamiminami, Hirano-ku Osaka 547-0003 Japan

This document details the security policy for the cryptographic module UT-125 FIPS #31 Hardware revision 1.2 and Hardware revision 1.3, UT-125 FIPS #41 Hardware revision 2.2 and Hardware revision

2.3 implementing firmware version 1.6, herein identified as the optional encryption unit, UT-125 FIPS #31

distributed only in its entirety without revision.

[Number Below] N/A Table 1: Security Levels N/A

Purpose and Use: The UT-125 FIPS #31 and #41 are multi-chip embedded cryptographic modules as defined by FIPS 1403. The cryptographic module can be incorporated into any Icom Inc. radio which requires FIPS 140-3 level 1 Module Type: Hardware Module Embodiment: Multi-chip Embedded

Cryptographic Boundary: The cryptographic boundary consists of the entire printed circuit board, as depicted in Figures 1 and 2. Cryptographic Boundary UT-125 FIPS EEPROM FLASH ROM Digital Signal Processor (DSP) Data Input/Output Control Input Radio’s DSP Figure 1

• Block Diagram

Figure 2 contains representative images of the cryptographic module. Other than the labels, Rev 1.2 and

1.3 of the UT-125 #31 are externally identical. Likewise, Rev 2.2 and 2.3 of UT-125 #41 are also

externally identical. #31 #41 Top Bottom Figure 2

• Representative Images

Tested Module Identification

• Hardware: Table 2: Cryptographic Module Tested Configuration

The cryptographic module does not have any Excluded components.

Modes List and Description: This UT-125 FIPS cryptographic module supports both approved mode and non-approved mode as explained below. Mode Change Instructions and Status: The cryptographic module supports both approved, and non-approved modes depending on the McBSP interface commands being invoked. Approved algorithms output the signal of GPIO port when running. The signal of GPIO9 indicates the module is using an approved security function. The cryptographic module does not support degraded operation.

Approved Algorithms: The module’s CAVP certificates includes algorithms/options that are not utilized by the module in the approved mode. Only the algorithms/options listed in the table below are utilized by the module in the approved mode.

Table 3: Approved Algorithms N/A Vendor-Affirmed Algorithms: This cryptographic module does not have a Vendor-Affirmed Algorithms algorithm. Non-Approved, Allowed Algorithms: This module does not implement any Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed. Non-Approved, Allowed Algorithms with No Security Claimed: This module does not implement any Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed. Non-Approved, Not Allowed Algorithms: Table 4: Non-Approved Algorithms Not Allowed in the Approved Mode of Operation

Table 5: Ports and Interfaces

This module does not support a trusted channel.

This module does not have control output interface.

This module does not support operator authentication.

The UT-125 FIPS #31 and #41 support the roles of Crypto Officer and User. Crypto Officer: Assumption of the Crypto Officer role is implied when any of the services specific to a Crypto Officer are executed. The Crypto Officer role is responsible for the keys and firmware of the UT-125 FIPS #31 and #41. The management of keys, such as loading, reading and writing, is the domain of the Crypto Officer. The main tool for key management utilized by the Crypto Officer is an approved key loading device. The Crypto Officer role will also manage firmware updating and checking procedures. User: Assumption of the User role is implied when any of the services specific to a User are executed. The User role is primarily consists of the services which conduct the encryption and decryption of communication, invoke self-tests, and indicate the status of the UT-125 FIPS #31 and #41.

N/A N/A O/U N/A N/A N/A N/A O/U N/A N/A N/A N/A O/U N/A N/A N/A O Z N/A Table 7: Approved Services O = Crypto Officer U = User G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g. the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. Table 8: Non-Approved Services O/U N/A O/U N/A O/U N/A

The firmware update is performed via the Firmware Update service, which executes the firmware load test.

This module does not support a bypass capability.

This module does not support a self-initiated cryptographic output capability.

The module’s firmware is provided as the 3059C3_16.MOT (boot and application firmware) or 3059C3_16(F).MOT (just application firmware) binary images.

The module uses CRC-32 as EDC method for the integrity testing.

The software/firmware integrity test is performed every time the module is started / rebooted.

Type of Operational Environment: Limited How Requirements are Satisfied: As shown in Table 1 this cryptographic module operates at security level 1. The module maintains control of its own SSPs retained within the module. The module’s operational environment consists of firmware with access to SSPs managed wholly by the module itself. Please see Section 9 for SSP details.

This module is a hardware module with a limited operational environment. Cryptographic module stores firmware to flash ROM within cryptographic boundary. .

This is multi-chip embedded cryptographic module. The circuitry uses standard passivation techniques and meets Security Level 1. This plug-in module is contained within a production grade radio enclosure and uses commercially available IC chips.

The cryptographic module does not have the non-invasive mitigation techniques.

Table 11: SSP Zeroization Methods h N/A er preloaded N/A Table 12: SSPs

*Key Fill Device (Key Loader)

The cryptographic module is not subject to transitions.

Keys/SSPs used in the approved mode shall not be used in the non-approved mode and vice-versa. The cryptographic module does not support manual key entry. Please note that Zeroise command from McBSP interface is used for changing the key data in DSP RAM. Then, those updated key data will be written to EEPROM.

Pre-Operational self-tests: Pre-Operational software/firmware integrity test; Firmware Integrity Test (CRC-32)

Conditional self-tests: Cryptographic Algorithm Self-Tests AES-ECB Encrypt Known Answer Test (256-bit key)* AES-ECB Decrypt Known Answer Test (256-bit key)* AES-CBC Encrypt Known Answer Test (256-bit key)* AES-CBC Decrypt Known Answer Test (256-bit key)* AES-OFB Encrypt Known Answer Test (256-bit key) AES-OFB Decrypt Known Answer Test (256-bit key) HMAC-SHA-1 Known Answer Test *Algorithm only used for self-tests in approved mode. Conditional software/firmware load test; Firmware load test (HMAC-SHA1 w/ 512-bit key) Conditional Critical Functions Test 32-bit CRC check on Electronically Entered keys

The module does not perform periodic self-tests.

Table 13: Error Indicators Table 14: Error Status

The module’s pre-operational self-tests and conditional CASTs can be performed on demand by power cycling the module.

Install For the cryptographic module installation, refer the radio service manual. Secure Initialization Proper keys must be loaded into the module. Key Loading Instructions Crypto-Officer may load keys into the modules using the key loader devices. The radio hardware communicates with the module through the defined ports. Each key loaded into the module has an associated key ID which is used to associate the key with a given radio channel. Operation of the module The cryptographic module contains non-approved security functions. Only services which utilize approved security functions are indicated as such by the module.

Please refer to the McBSP command guidance.

Please refer to the McBSP command guidance.

The security rules presented below are a combination of those required by FIPS140-3 for Level 1 secure use and the security rules separately implemented by Icom Inc. FIPS 140-3 Security Rules: Only approved algorithms can be used, and the use of RNG, DES is not allowed in the approved mode of operation.

The cryptographic module is composed of production grade components which do not require any maintenance or inspection by the user to ensure security.

When distributing or discarding the cryptographic module to other operators, send the McBSP command "All Key Zeroise" ($ 77) to initialize and sanitize all cryptographic keys (SSPs). (Since the cryptographic module does not perform Operator Authentication, it does not retain authentication data.)

This module does not support other attack mitigation.