Motorola Solutions Cryptographic Firmware Module

Certificate

Approved Algorithms (13)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Motorola Solutions Cryptographic Firmware 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>R01.13.00</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Self-Test</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</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"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    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"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    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"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    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
  C1 --> I1 --> R1 --> E1
  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 C1,C3,C5,C6 clue;
  class I1,I3,I5,I6 infer;
  class R1,R3,R5,R6 risk;
  class E1,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Motorola Solutions Cryptographic Firmware 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>R01.13.00</i><br/>src: certificate.firmwareVersions"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Self-Test</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>HTTPS<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/>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,C3 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

Motorola Solutions Cryptographic Firmware Module Firmware Version: R01.13.00 Document Version: 1.0 Date: July 16, 2024 Prepared by: www.acumensecurity.net Motorola Solutions, Inc. © 2024 Version 1.0 Public Material

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

Introduction Federal Information Processing Standards Publication 140-3

• Security Requirements for Cryptographic Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but Unclassified environment. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber Security (CCCS) Cryptographic Module Validation Program (CMVP) run the FIPS 140 program. The NVLAP accredits independent testing labs to perform FIPS 140 testing; the CMVP validates modules meeting FIPS

140 validation. Validated is the term given to a module that is documented and tested against the FIPS

More information is available on the CMVP website at: https://csrc.nist.gov/projects/cryptographic-module-validation-program About this Document This non-proprietary Cryptographic Module Security Policy for the Motorola Solutions Cryptographic Firmware Module provides an overview of the product and a high-level description of how it meets the overall Level 1 security requirements of FIPS 140-3. The Motorola Solutions Cryptographic Firmware Module may also be referred to as the “module” in this document. Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. Motorola Solutions, Inc. shall have no liability for any error or damages of any kind resulting from the use of this document. Notices This document may be freely reproduced and distributed in its entirety without modification. Motorola Solutions, Inc. © 2024 Version 1.0 Public Material

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

1. This document defines the cryptographic module security policy for the Motorola Solutions Cryptographic Firmware Module (Firmware version: R01.13.00), also referred to as the “module” hereafter. The module is a multichip standalone embodiment. It contains specification of the security rules, under which the cryptographic module operates, including the security rules derived from the requirements of the FIPS 140-3 standard. The following table lists the level of validation for each area in FIPS 140-3: N/A N/A Table 1

• Security Levels Motorola Solutions, Inc. © 2024 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

2. Cryptographic Module Specification The module is a firmware-based cryptographic module that runs on a Motorola Solutions, Inc. radio hardware platform. The module provides FIPS 140-3 approved cryptographic functionalities via an Application Programming Interface (API) to the application layer running in Motorola Solutions, Inc. radio products supporting the APCO Project 25 standard. The module is intended for use by the markets that require FIPS 140-3 validated overall Security Level
3. A unique binary is generated for each operating system. The following operating environments have been tested for this validation: # N/A N/A Table 2 – Tested Operational Environments The module has also been confirmed by Motorola Solutions, Inc. to be operational on the following OE shown in Table
4. However, no target testing was performed on this platform for the FIPS 140-3 validation with the specific firmware version listed in this document. Note: The CMVP makes no statement as to the correct operation of the module on the operational environments for which operational testing was not performed. # Table 3 – Vendor Affirmed Operational Environments 2.1 Modes of Operation The module operates in two different modes of operation. • • Approved mode: DES Encrypt/Decrypt are blocked. All services listed in Table 9 are available when the module is operating in Approved mode. non-Approved mode: All services listed in Table 9 and Table 10 are available when the module is operating in non-Approved mode. The module defaults to the Approved mode at the initial power-up and will transition between Approved Mode and non-Approved mode by using the “Configure Approved Mode” service. The operator can configure the mode of the module by using the “Configure Approved Mode” Service listed in Table
5. The “Configure Approved Mode” services sets an Approved mode flag via the API. The Approved mode flag is “fips_mode = 1” in the Approved mode and the non-Approved mode flag is “fips_mode = 0”. The operator shall zeroize all CSPs by power cycling the module when transitioning between Approved and nonApproved modes. The operator must retain control of the module while zeroization is in process. Motorola Solutions, Inc. © 2024 Public Material – May be reproduced only in its original entirety (without revision).

2.2 Cryptographic Functionality The module’s supported cryptographic functions are listed in the following tables: N/A N/A #1. Per IG C.H option 2, the module generates 96-bit GCM IVs randomly as specified in SP800-38D section 8.2.2 using an approved DRBG (Cert. #A2228), that is internal to the module’s boundary. Motorola Solutions, Inc. © 2024 Version 1.0 Public Material

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

Table 4

• Approved Algorithms Table 5
• Non-Approved Algorithms Allowed in the Approved Mode of Operation Table 6
• Non-Approved Algorithms Not Allowed in the Approved Mode of Operation The module does not support Non-Approved Allowed Algorithms with No Security Claimed. 2.3 Module Description and Cryptographic Boundary The module is classified by FIPS 140-3 as a firmware module, with a multi-chip standalone module embodiment. The physical perimeter is the Motorola Solutions, Inc. Radio Platform on which the module is installed. The logical perimeter and cryptographic boundary of the module is the static linked library that is linked into the application running on Motorola Solutions, Inc. radio products. PBKDF salt, GCM IV, and ECDH private key AES-CBC-MAC is allowed for use within OTAR until November 1, 2023. Motorola Solutions, Inc. © 2024 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

Logical Perimeter Figure 1 – Logical cryptographic boundary and physical boundary 2.4 Security Rules and Guidance The module enforces the following security rules:

1. The module does not support any operator authentication.
2. The module is available to perform services only after successfully completing the pre-operational self-tests.
3. Data output is inhibited during pre-operational self-tests, zeroization, and while in an error state.
4. The module shall not support concurrent operators.
5. The module enters the uninitialized state if any pre-operational self-test fail. The uninitialized state can be exited by restarting the module allowing the module to attempt to re-initialize itself.
6. If the module enters a soft error state, the error condition may be cleared by executing the Operator Initiated Self-Test service documented in Section 11.2 or power cycling the module.
7. The module can perform periodic self-tests. An operator can perform periodic self-tests on demand by using the Operator Initiated Self-Test API or power cycle.
8. The module does not perform any cryptographic functions while in the uninitialized state.
9. The module returns the results of the pre-operational self-tests to the operator.
10. The module may be power cycled to zeroize all CSPs.
11. The module is to be installed on Motorola Solutions radio products.
12. The operator may choose whether the module will run in the Approved mode or non-Approved mode using the “Configure Approved Mode” Service.
13. Cryptographic Module Interfaces The Module’s logical interfaces are described in Table 7: Motorola Solutions, Inc. © 2024 Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

Table 7

• Ports and Interfaces The module does not support a control output interface. 4. Roles, Services, and Authentication The module supports the Cryptographic Officer (CO) role and does not support authentication. An operator is considered the owner of the thread that instantiates the module and, therefore, only one concurrent operator is allowed. N/A N/A N/A Public Material
• May be reproduced only in its original entirety (without revision).

The SSPs modes of access shown in Table 9, 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. E = Execute: The Module uses the SSP in performing a cryptographic operation. Z = Zeroize: The Module zeroizes the SSP N/A N/A N/A N/A W,E,Z N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A W,E,Z W,E,Z KTS (AESKW or AESGCM) KTS (AESKW or AESGCM) W,E,Z W,E,Z Motorola Solutions, Inc. © 2024 Public Material
• May be reproduced only in its original entirety (without revision).

W,E,Z SP 80090Ar1 N/A G,R,W N/A W,E N/A Z W,E G,R G,R G,R,W,E The Zeroize service zeroizes the key in the volatile memory by power cycling the module. As per NIST SP 800-132, keys generated by the module shall be used as recommend in Section 5.4 of [132]. Any other use of the approved PBKDF is non‐conformant. In approved mode the operator shall enter a password no less than 8 hexadecimal digits in length. The probability of guessing the password will be equal to 1:168. Due to the computational limitations of this embedded operational environment, the iteration count associated with the PBKDF should not exceed 5000. The minimum iteration count is 1, however it shall be selected as large as possible. Keys derived from passwords may only be used in storage applications. Motorola Solutions, Inc. © 2024 Version 1.0 Public Material

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

Table 9 – Approved Services Table 10 – Non-Approved Services

5. Software/Firmware Security The module consists of firmware in the form of a statically linked library. The firmware components are protected and authenticated using an HMAC hash function using the keyed hash key referenced in Table
6. The operator can initiate the firmware integrity test (HMAC-SHA2-384) on demand by power cycling the radio. If the integrity test fails, the module will not initialize and no security functions will be provided by the module.
7. Operational Environment The module operates and was tested on the following non-modifiable operational environment: Motorola Solutions, Inc. Radio using hardware platform as specified in Table
8. As per ISO/IEC 19790:2012 7.6.3: • The cryptographic module has control over its own SSPs. • The operational environment provides the capability to separate individual application processes from each other to prevent uncontrolled access to CSPs and uncontrolled modifications of SSPs, regardless if this data is in the process memory or stored on persistent storage within the operational environment. This ensures that direct access to CSPs and SSPs is restricted to the cryptographic module and the trusted parts of the operational environment. • The module operates in a non-modifiable operational environment, therefore no restrictions or modifications to the configuration of the operational environment are possible. • Processes that are spawned by the cryptographic module are owned by the module and are not owned by external processes/operators.
9. Physical Security The module is a firmware module and operates in a Motorola Solutions, In. radio that is built with production grade materials that include standard passivation techniques. For the purposes of FIPS 140Motorola Solutions, Inc. © 2024 Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

3, the embodiment is defined as multiple-chip standalone and is designed to meet Level 1 security requirements. 8. Non-invasive Security Not Applicable. The module does not implement non-invasive security measures. N/A N/A N/A N/A / Strength SP 80090Ar1 SP 80090Ar1 N/A Motorola Solutions, Inc. © 2024 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision). Use & related keys Storage N/A Zeroisation Establishment Security Cert. Number Import/Export Sensitive Security Parameters Management Key/SSP Name/Type 9.

/ KASExternal KASInternal KASInternal Use & related keys ) Zeroisation Establishment Storage Generation Security Function and Cert. Number Strength Key/SSP Name/Type KASInternal Password generated externally. Salt may be generated externally or internally according to SP 800-133. Motorola Solutions, Inc. © 2024 Version 1.0 Public Material

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

Storage Use & related Establishment Zeroisation KASExternal Cert. Number Key/SSP Name/Type Table 11

• SSPs Table 12
• Non-Deterministic Random Number Generator Specification 10. Self-Tests

The module automatically performs pre-operational self-tests and conditional cryptographic algorithm self-tests. Automatic pre-operational self-tests are initiated upon module power-up and must pass in order for the module to initialize and render any security services. A failure of any pre-operational selftest will prevent the module from initializing. Automatic conditional cryptographic algorithm self-tests (CAST) will run prior to the first use of a security service using an approved cryptographic algorithm after module initialization. Failure of a conditional CAST will cause the module to enter the soft error state and a) Pre-Operational Self-Tests

• Firmware integrity test: HMAC-SHA2-384 (HMAC-SHA2-384 CAST done prior to integrity test) Motorola Solutions, Inc. © 2024 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

b) Conditional Self-Tests

1. Conditional cryptographic algorithm test o SHA2-256 CAST o SHA2-512 CAST o HMAC-SHA2-384 CAST o AES ECB Encrypt CASTs (256-bit key) o AES ECB Decrypt CASTs (256-bit key) o AES GCM Encrypt CASTs (256-bit key) o AES GCM Decrypt CASTs (256-bit key) o CTR_DRBG [SP 800-90Ar1] CAST (Instantiate, Generate, and Reseed) o AES-KW [SP 800-38F] Wrap/Unwrap CASTs o KAS ECC [SP 800-56ar3] CAST o KDF [SP 800-56Arev3] CAST (SHA2-256, SHA2-384, SHA2-512) o PBKDF [SP 800-132] CAST (128-bit key, 128-bit salt, 2 iterations)
2. Conditional pair-wise consistency test o ECDSA Key Gen PCT (384-bit private key, 384-bit public key)

Self-tests can also be initiated by calling the “Self-Test” service via the API. Operator initiated self-tests via the API can only be invoked after the module has initialized. When initiating self-test via API call, the following tests are performed:

• SHA2-256 CAST
• SHA2-512 CAST
• HMAC-SHA2-384 CAST
• AES ECB Encrypt CASTs (256-bit key)
• AES ECB Decrypt CASTs (256-bit key)
• AES GCM Encrypt CASTs (256-bit key)
• AES GCM Decrypt CASTs (256-bit key)
• CTR_DRBG [SP 800-90Ar1] CAST (Instantiate, Generate, and Reseed)
• AES-KW [SP 800-38F] Wrap CAST
• AES-KW [SP 800-38F] Unwrap CAST
• KAS ECC [SP 800-56ar3] CAST
• KDF [SP 800-56Arev3] CAST (SHA2-256, SHA2-384, SHA2-512)
• PBKDF [SP 800-132] CAST (128-bit key, 128-bit salt, 2 iterations)
• ECDSA Key Gen PCT (384-bit private key, 384-bit public key) Failure of any of the self-test initiated by calling the “Self-Test” service via the API will render the module inoperable. 11. Life-Cycle Assurance The cryptographic module is not installed, but it is a static library linked to the application at compile time. The operator shall configure the module to operate in approved mode as specified in Section 2.1. After end-of-life for the module, the operator shall zeroize all SSPs used by the module by removing power to the radio using the module. Motorola Solutions, Inc. © 2024 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

12. Mitigation of Other Attacks Not Applicable. The Module does not implement mitigations of other attacks outside the scope of FIPS 140-3. Motorola Solutions, Inc. © 2024 Version 1.0 Public Material

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

References and Definitions Motorola Solutions, Inc. © 2024 Version 1.0 Public Material

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

Motorola Solutions, Inc. © 2024 Version 1.0 Public Material

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

Referenced URLs

• www.acumensecurity.net
• https://csrc.nist.gov/projects/cryptographic-module-validation-program