ASTRO CDEM Motorola Advanced Crypto Engine (MACE)

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for ASTRO CDEM Motorola Advanced Crypto Engine (MACE)
  %% 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</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>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."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["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"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for ASTRO CDEM Motorola Advanced Crypto Engine (MACE)
  %% 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</i><br/>src: text:keyword"]
    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>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,C5,C6 clueLow;

Security Policy, page by page

Motorola Solutions, Inc. ASTRO CDEM Motorola Advanced Crypto Engine (MACE) Document Version: R01.00.00 Date: January 16, 2025 Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-

The FIPS 140-3 security levels for the Module are as follows from Table 1: Table 1: Security Levels Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

2 – Cryptographic Module Specification

This document covers the Motorola Solutions ASTRO CDEM MACE module, hereafter denoted as the Module. The Module is implemented as a single-chip cryptographic module to meet FIPS 140-3 level 3 physical security requirements as defined by FIPS 140-3. The ASTRO CDEM MACE provides key storage and generation and performs all crypto processing for the Motorola Solutions ASTRO CDEM product.

Purpose and Use: The Module is intended for use by US Federal agencies or other markets that require FIPS 140-3 validated overall Security Level

3. The Module is intended to be used in ASTRO CDEM unit. Module Type: Hardware Module Embodiment: SingleChip Cryptographic Boundary: The physical form of the Module is depicted in Figure 1 and Figure
4. The Module is a single-chip embedded embodiment. The cryptographic boundary is shown in Figure
5. Figure 1 – ASTRO CDEM MACE IC (Top) Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Figure 2 – ASTRO CDEM MACE IC (Interfaces) Power IRQ/FIQ Clock ASTRO CDEM MACE RAM Interface Reset     Tamper         SSI         Ethernet    RS232         KVL       Front Panel LED Indicators: Alarm, Interface Interface      Interface   Port        Interface     Interface Power, Ready, Tx Clear, Status Figure 3 – Cryptographic Boundary Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Tested Module Identification

• Hardware: The ASTRO CDEM MACE cryptographic module is tested on the following operational environment. Table 2: Tested Module Identification
• Hardware The ASTRO CDEM MACE cryptographic module supports the following approved algorithms which may be installed separately from the MACE base firmware using the program update service. While the installation of AES may be done separately, for the purposes of this validation the MACE includes this Table 3
• Approved Mode Drop-in Algorithms N/A for this module. N/A for this module. N/A for this module. N/A for this module.

The module does not exclude any components from the cryptographic boundary.

Modes List and Description: Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Table 4: Modes List and Description The ASTRO CDEM MACE is originally non-compliant and must be configured to operate in an approved mode of operation. The MACE must be installed, initialized and configured, including a required change of the factory-default password in order to be in an approved mode. Documented below are the additional configuration settings that are required for the MACE to be used in an Approved Mode of operation at overall Security Level

3. The approved mode is indicated by using the “Set FIPS Mode” service. The result from this service will Encrypted only Key fill is Enabled. Module is operating in FIPS 140-3 Level 3 approved mode When the module is in the approved operating mode, the “Module Status” service can be used to verify the firmware version matches an approved version listed on NIST’s website: https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules Mode Change Instructions and Status: The module can be configured to operate in a FIPS 140-3 Approved mode of operation at overall Security Level
4. To configure the module to operate in Approved mode, the operator must log in as the CO using the default password and:
5. Change the default password
6. Activate and configure the periodic self-test timer
7. Type the command “fips enable” to configure the Module into approved mode(Level 3). Additionally, the Module supports a “drop-in algorithm” via the Program Update service. Drop-in algorithms may be added or removed from the Module independent of the base FW. In order to remain in the Approved Mode, only Approved algorithms may be loaded into the Module, in particular AES-256 (Cert. # A5275). The loading and unloading of any firmware within the validated cryptographic module invalidates the Module’s validation and zeroizes all SSPs except those entered at manufacturing. The Module is then in a non-compliant state. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Approved Algorithms: The Module implements the Approved cryptographic algorithms listed in the table below. Table 5: Approved Algorithms ApprovedAlgorithmsTable From Web Cryptik ApprovedAlgorithmsTable Vendor-Affirmed Algorithms: The Module implements the FIPS Vendor Affirmed cryptographic algorithms listed. N/A Table 6: Vendor-Affirmed Algorithms Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: The Module implements the FIPS Non-Approved, Allowed cryptographic Algorithms with No Security Table 7: Non-Approved, Allowed Algorithms with No Security Claimed Non-Approved, Not Allowed Algorithms: N/A for this module. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The following table shows the Security Function Implementations that the module implements: Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Table 8: Security Function Implementations Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The module does not have any algorithm specific information.

Table 9: Entropy Certificates The Module uses the following entropy sources: Table 10: Entropy Sources

For Key Generation methods, see Section 2.6 Security Function Implementations above.

For Key Establishment methods, see Section 2.6 Security Function Implementations above.

The module does not implement any Industry Protocols Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The Module’s ports and associated FIPS defined logical interface categories are listed below. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Table 11: Ports and Interfaces Note: The module does not support Control Output. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

} Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Metho d Name

Description Officer services associated to the Synchronous Interface (SSI) port. It should be noted that after authenticating , this password may be changed at any time.

Security Mechanis m

Strength Each Attempt

Strength per Minute

The Module supports one distinct operator role, the Cryptographic Officer (CO). The authentication method and services available to the CO will depend on the physical port used. The CO may be logged into both ports at the same time. In addition, the Module supports services which do not require authentication (UA). The Roles Table below lists all operator roles supported by the Module. The Module does not support concurrent operators. Table 13: Roles

All approved services implemented by the Module are listed in the table below: The SSPs modes of access shown in the table below are defined as:

Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

• Z = Zeroize: The Module zeroizes the SSP Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

G,E,Z G,E,Z Z Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Z Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

W,Z Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Z Z Z Z Table 14: Approved Services Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

There are no Non-Approved services available while the module is in the approved mode. N/A for this module.

This module supports loading of external firmware via the Program Update service. Execution of the successfully loaded firmware is only effective after the next reset of the security module. Any firmware loaded into the module other than that listed in section 2.2 Tested and Vendor Affirmed Module Version and Identification, is outside the scope of this Security Policy and requires a separate FIPS 140-3 validation. The module validates the integrity of the externally loaded firmware via procedures described in section

Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The Module has a limited modifiable operational environment under the FIPS 140-3 definitions. The Module is composed of the following firmware components:

• Component 1: Executable - binary
• Component 2: Drop in Algorithms - binary The firmware components are protected with the FW-LD-Pub key described in section 9.4 SSPs. The FWLD-Pub key is loaded into the module at manufacturing The operator can initiate the integrity test on demand by power cycling the Module.

The operator can initiate the integrity test on demand by power cycling the Module. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Type of Operational Environment: Limited The ASTRO CDEM MACE has a limited operational environment under the FIPS 140-3 definitions with a Physical Security at Level 3. Therefore, per the FIPS 140-3 Management Manual Section 7.5, partial validations and non-applicable areas in this section are not applicable. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The ASTRO CDEM MACE is a production grade, single-chip cryptographic module with standard passivation over the modules circuitry as defined by FIPS 140-3 and is designed to meet level 3 physical security requirements. The information below is applicable to cryptographic module hardware kit numbers 5185912Y03, 5185912Y05, and 5185912T05, which have identical physical security characteristics.

CDEM MACE's epoxy encapsulate is claimed at the temperature range of -40 to 85 degrees Celsius. No assurance of the epoxy hardness is claimed for this physical security mechanism outside of this range. The ASTRO CDEM MACE does not contain any doors, removable covers, or ventilation holes or slits. No maintenance access interface is available. No special procedures are required to maintain physical Table 15: Mechanisms and Actions Required Table 16: EFP/EFT Information Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Table 17: Hardness Testing Temperatures Notes: The module is hardness tested at the lowest and highest temperatures within the module's intended temperature range of operation. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The Module does not implement any mitigation method against non-invasive attack. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Table 19: SSP Input-Output Methods

Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Table 20: SSP Zeroization Methods Note: For zeroization methods with an asterisk, once zeroization is complete the Module will reboot, indicating successful zeroization. The output status of all other methods of success of zeroization are implicit and any attempt to use previous keys/CSPs will trigger an error. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

All usage of these SSPs by the Module are described in the services detailed in Section 4.3 Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Table 21: SSP Table 1 Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Table 22: SSP Table 2 Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The ASTRO CDEM MACE performs self-tests to ensure the proper operation. Per FIPS 140-3 these are categorized as either pre-operational selftests or conditional self-tests. Pre-operational self–tests are available on demand by power cycling the ASTRO CDEM MACE. In addition, pre-operational self–tests are periodically performed by the ASTRO CDEM MACE as configured by the operator during the module configuration as shown in section 11.1 Installation, Initialization, and Startup Procedures The ASTRO CDEM MACE will not accept any commands when a periodic self-test is required; the commands still in the I/O buffer will be processed by the ASTRO CDEM MACE after periodic self-test ends and will execute when the I/O buffer is emptied. The ASTRO CDEM MACE logs the most recent self-test errors to the internal flash; the operator (CO) can extract the error logs using Extract Error Log service. The Module performs the following pre-operational self-tests in table below Table 23: Pre-Operational Self-Tests

The Module performs the following conditional self-tests in the table below Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Algorithm or Test

Test Properties

Test Method

Test Type

Indicator

Details The digital signature is verified upon download into the ASTRO CDEM MACE.

Conditions

Table 24: Conditional Self-Tests

Table 25: Pre-Operational Periodic Information Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Table 26: Conditional Periodic Information Conditional self–tests are periodically performed by the ASTRO CDEM MACE every X hours, where X is configured by the operator during module configuration (1 hour to 720 hours). The ASTRO CDEM MACE will not accept any commands when a periodic self-test is required; the commands still in the I/O buffer will be processed by the ASTRO CDEM MACE end the periodic self-test executed when the I/O buffer is emptied. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Table 27: Error States Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Installation and Initialization: The Module is originally a non-compliant module and must be initialized to be in Approved mode. There is no non-Approved mode. During initialization the operator shall configure the Module from the instructions below:

1. Upon first access, the operator will use the default passwords provided by Motorola in a separate communication.
2. The operator will then change the default passwords based on the requirements in the Roles and Authentication table.
3. The operator will set the periodic self-tests timer as part of the Module configuration in every X minutes, where X is a minimum value = 1 hour and maximum value = 720 hours. Note: the default minimum = 0* but must be changed to a minimum of 1.
4. The operator will then complete Module configuration using the Module Configuration and Configure OTEK services.
5. Finally, the operator will set the Module to the Approved mode using the Set FIPS Mode service. * periodic self-tests will not perform if minimum = 0 Delivery: The Module is used in multiple Motorola Solutions, Inc. products. Motorola uses commercially available courier systems such as UPS, FedEx, and DHL with a tracking number and requires a signature at the end from an authorized client.

Use vendor provided product specific user guide for secure operations.

Rules of Operation

1. The Module provides one distinct operator role: Cryptographic Officer.
2. The Module provides identity-based authentication. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

3. The Module clears previous authentications on power cycle.
4. An operator does not have access to any cryptographic services prior to assuming an authorized role.
5. The Module allows the operator to initiate power-up self-tests by power cycling power or resetting the Module.
6. All self-tests do not require any operator action.
7. Data output is inhibited during key generation, self-tests, 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. There are no restrictions on which keys or SSPs are zeroized by the zeroization service.
10. The Module does not support concurrent operators.
11. The Module does not support a maintenance interface or role.
12. The Module does not support manual SSP establishment method.
13. The Module does not have any proprietary external input/output devices used for entry/output of data.
14. The Module does not enter or output plaintext CSPs.
15. The Module does store some CSPs in plaintext.
16. The Module does not output intermediate key values. The Module does not provide bypass services or ports/interfaces.

After the end-of-life, the operator should zeroize all SSPs using “Erase Crypto Module“ service followed by shredding the ASTRO CDEM MACE chip.

The Module does not implement any mitigation method against other attacks. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

References and Definitions The following standards are referred to in this Security Policy. Table 28 References Table 29 Acronyms and Definitions Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).