Motorola Solutions Cryptographic Software Module

Certificate

Approved Algorithms (17)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Motorola Solutions Cryptographic Software Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    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"]
    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"]
    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"]
    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
  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 C3,C5,C6 clue;
  class I3,I5,I6 infer;
  class R3,R5,R6 risk;
  class E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Motorola Solutions Cryptographic Software Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    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 C3 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

Motorola Solutions Cryptographic Software Module Software Version: R01.15.00 Running on Intel Core i7-8700 or Intel i5-12600 Document Version: 1.0 Date: October 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-3 program. The NVLAP accredits independent testing labs to perform FIPS 140-3 testing; the CMVP validates modules meeting FIPS 140-3 validation. Validated is the term given to a module that is documented and tested against the FIPS 140-3 criteria. 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 Software 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 Software 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 Software Module (Software version: R01.15.00 running on Intel Core i7-8700 or Intel i5-12600), also referred to as the “module” hereafter. 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 module is a software-hybrid based cryptographic module that runs on a general-purpose computing platform that supports processor algorithm acceleration. The module is classified as a multi-chip standalone module embodiment. The module provides approved cryptographic functionalities via an Application Programming Interface (API) to the application layer. 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 intended for use by the markets that require FIPS 140-3 validated overall Security Level 1. # Table 2 – Tested Operational Environments The module has also been confirmed by Motorola Solutions to be operational on the following OEs shown in Table
3. However, no target testing was performed on this platform for FIPS 140-3 validation with the specific software versions listed in this document. Note: The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys on the operational environments for which operational testing was not performed. # Motorola Solutions, Inc. © 2024 Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

# Table 3

• Vendor Affirmed Operational Environments 2.1 Modes of Operation The module operates in two different modes of operation.
• Approved mode: 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 Approved mode at 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 9. 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. 2.2 Cryptographic Functionality The module’s supported cryptographic functions are listed in the following tables. 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. #A3497), 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).

DRBG [SP80090Ar1] N/A N/A 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 software-hybrid module and multi-chip standalone module embodiment running on a modifiable operating environment. The physical perimeter is the hardware platform (a.k.a. general-purpose computer) on which the module is installed. The TOEPP is listed in the Hardware Platform column in Table 2. The logical perimeter which is also the cryptographic boundary of the module is a shared object file, libALG.dll, that is linked into the application running on a generalpurpose computing platform containing an Intel processor with algorithm acceleration. 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 PAA 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. The module can perform periodic self-tests. An operator can perform periodic self-tests on demand by using the Operator Initiated Self-Test API to run conditional self-tests or module restart to run pre-operational tests.
7. The module does not perform any cryptographic functions while in the uninitialized state.
8. The module returns the results of the pre-operational and integrity self-tests to the operator.
9. The module may be power cycled to zeroize all CSPs.
10. The operator may choose whether the module will run in the Approved mode or non-approved mode using the “Configure Approved Mode” Service.
11. The only operating environment restrictions is that processor algorithm acceleration must be enabled.
12. Cryptographic Module Interfaces The Module’s logical interfaces are described in Table 7; the Module’s physical ports are outside the module boundary. 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 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 N/A W,E,Z N/A N/A N/A N/A Motorola Solutions, Inc. © 2024 Public Material
• May be reproduced only in its original entirety (without revision).

N/A N/A N/A N/A N/A N/A W,E,Z W,E,Z W,E,Z W,E,Z W,E,Z N/A G,W,R N/A Motorola Solutions, Inc. © 2024 Version 1.0 Public Material

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

W,E N/A Z W,E R,G R,E R,E W,G,E,R Table 9

• Approved Services The Zeroize service zeroizes the key in the volatile memory by power cycling the module. As per NIST SP 800-132 and IG D.N, 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 50,000. 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 10 – Non-Approved Services

5. Software/Firmware Security The module is software-hybrid and operates on a general-purpose computing platform that is built with production grade materials. The software components are protected and authenticated using an HMAC hash function using the keyed hash key referenced in Table
6. The operator can initiate the software integrity test on demand by restarting the module. If 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 modifiable operational environment: • General purpose computing 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.
9. Physical Security The module is a multi-chip standalone, software hybrid embodiment module with an Intel CPU that supports Processor Algorithm Acceleration installed within a GPC. The module utilizes a production grade hardware component with standard passivation applied to it.
10. Non-invasive Security Not Applicable. The module does not implement non-invasive security measures. Motorola Solutions, Inc. © 2024 Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

m) N/A N/A N/A Use & related keys Zeroisation N/A Storage Establishment Import/Export SP 80090Ar1 m) Security Cert. Number Strength Sensitive Security Parameter Management Key/SSP Name/Type 9. N/A / / Motorola Solutions, Inc. © 2024 Version 1.0 Public Material

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

m) Use & related keys Zeroisation m) m Storage Establishment Generation Security Function and Cert. Number Strength Key/SSP Name/Type 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).

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

• Non-Deterministic Random Number Generator Specification Motorola Solutions, Inc. © 2024 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

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 a critical error state whereby no cryptographic services will be rendered by the module. A) Pre-Operational Self-Tests o Software integrity test: HMAC-SHA2-384 (HMAC-SHA2-384 CAST done prior to integrity test) B) Conditional Self-Tests

1. Conditional cryptographic algorithm test o SHA2-256 CAST (run before Software Integrity test) o SHA2-512 CAST (run before Software Integrity test) o HMAC-SHA2-384 CAST (run before Software Integrity test) o AES ECB Encrypt CAST (256-bit key) o AES ECB Decrypt CAST (256-bit key) o AES CBC Encrypt CAST (256-bit key) o AES CBC Decrypt CAST (256-bit key) o AES OFB Encrypt CAST (256-bit key) o AES OFB Decrypt CAST (256-bit key) o AES GCM Encrypt CAST (256-bit key) o AES GCM Decrypt CAST (256-bit key) o CTR_DRBG [SP 800-90Ar1] CAST (Instantiate, Generate, and Reseed) o AES-KW [SP 800-38F] Wrap CAST o AES-KW [SP 800-38F] Unwrap CAST 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) o ECDSA Signature Generation CAST o ECDSA Signature Validation CAST
2. Conditional pair-wise consistency test o ECDSA Key Gen PCT (384-bit private key, 384-bit public key)

Conditional self-tests can be user initiated by calling the “Self-Test” service via the LIBALG_API_Run_Self_Tests() API. User 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 Motorola Solutions, Inc. © 2024 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

• • • • • • • • • • • • • • • • • • HMAC-SHA2-384 CAST AES ECB Encrypt CAST (256-bit key) AES ECB Decrypt CAST (256-bit key) AES CBC Encrypt CAST (256-bit key) AES CBC Decrypt CAST (256-bit key) AES OFB Encrypt CAST (256-bit key) AES OFB Decrypt CAST (256-bit key) AES GCM Encrypt CAST (256-bit key) AES GCM Decrypt CAST (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) ECDSA Signature Generation CAST ECDSA Signature Validation CAST 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 dynamically linked to the application at run time. The operator shall configure the module to operate in Approved mode as specified in Section 2.1. After endof-life for the module, the operator shall zeroize all SSPs used by the module by removing power to the device using the module.
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 Table 13

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

Table 14 -Definitions 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