Astro PDEG Motorola Advanced Crypto Engine (MACE)

Certificate

Approved Algorithms (9)

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

flowchart LR
  %% Deterministic review-risk graph for Astro PDEG 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>Firmware Load<br/>Update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Status Output</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 PDEG 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>Firmware Load<br/>Update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>Status Output</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

Astro PDEG Motorola Advanced Crypto Engine (MACE) Non-Proprietary FIPS 140-3 Security Policy Document Version: 1.2 Date: November 01, 2024 Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

This document defines the Security Policy for the Astro Packet Data Encryption Gateway (PDEG) Motorola Advanced Crypto Engine (MACE), hereafter denoted the ASTRO PDEG MACE or the Module. The ASTRO PDEG MACE 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 PDEG MACE provides secure key management, Over-the-Ethernet-Keying (OTEK), and data encryption for the Motorola Solutions PDEG Encryption Unit. The FIPS 140-3 security levels for the ASTRO PDEG MACE are as follows: Table 1

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

PDEG MACE is used in the Motorola Solutions PDEG Encryption Unit. The ASTRO PDEG MACE cryptographic module is intended for use by US Federal agencies or other markets that require FIPS 140-

The ASTRO PDEG MACE cryptographic module is tested on the following operational environment. Table 2 – Cryptographic Module Tested Configuration

The physical form of the ASTRO PDEG MACE cryptographic module is depicted in Figure 1 and Figure

2. The ASTRO PDEG MACE is a single chip embodiment. The cryptographic boundary of the ASTRO PDEG MACE IC as shown in Figure
3. Figure 1: MACE Chip (Top) Figure 2: MACE Chip (Interfaces) Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Power IRQ/FIQ Clock ASTRO PDEG MACE RAM Interface Reset        Tamper        SSI          Ethernet     RS232         KVL       Front Panel LED Indicators: Alarm, Power, Interface    Interface     Interface    Port         Interface     Interface Ready, Tx Clear, Status Figure 3: Cryptographic Boundary

The ASTRO PDEG MACE can be configured to operate in a an approved mode of operation and a nonapproved mode of operation. CSPs are not shared between approved mode and non-approved mode. The transition from a approved mode to a non- approved mode, and vice-versa, causes all CSPs to be zeroized except hardcoded CSPs. All hardcoded CSPs are unique between approved and non-approved mode and therefore are exclusive between approved and non-approved services and modes of operation. When the module is in approved 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 Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The module can be configured to operate in a FIPS 140-3 Approved mode of operation at overall Security Level

3. To configure the module to operate in approved mode, the operator must log in as the CO using the default password and:
4. Change the default password.
5. Activate and configure the periodic self-test timer.
6. Type the command “fips enable” to configure the Module into Approved mode (level 3). The Approved mode is indicated by using the “Set FIPS Mode” service. The result from this service will display: - Encrypted only Keyfill is Enabled - FIPS mode is Level 3 The operator shall configure the periodic self-tests timer as part of the Module configuration, refer to Section 11 for further details.

To configure the device to a non-Approved mode, the operator as the CO can type the command “fips disable”. The result is indicated by using the “Set FIPS Mode” service. The result from this service will display: - Encrypted on Keyfill is Disabled - FIPS mode is Not FIPS approved The loading of non-validated firmware within the validated cryptographic module invalidates the module’s validation and zeroizes all CSPs.

The MACE implements the Approved and Non-Approved but Allowed cryptographic functions listed in the tables below. Table 3 – Approved Algorithms

1 Per IG C.H Scenario 2, the MACE generates GCM IVs randomly with a length of 96-bits as specified in SP800-38D section 8.2.2

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

AES MAC is used as part of OTAR but is considered obfuscation.

KTS encryption is performed on the OTAR key components and decrypted within the module using

AES KW Cert. #AES 5358

Table 4

• Non-Approved Algorithms Allowed in the Approved Mode of Operation Table 5
• Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed Note: All Security Functions are available in Approved and Non-Approved mode. Note: The module does not implement any Non-Approved Algorithms and Not Allowed Cryptographic Functions in the Approved Mode of Operation.

1. The Module provides identity based authentication.
2. The Module inhibits all data output via the data output interface whenever an error state exists, zeroization, firmware loading, key generation and during self-tests.
3. The Module logically disconnects the output data path from the circuitry and processes when performing key generation, or key zeroization.
4. Authentication data (e.g., passwords) are entered in encrypted form.
5. Secret cryptographic keys are entered in encrypted form over a physically separate port.
6. The Module supports a Cryptographic Officer role and User role. Authenticated operators are authorized to assume either supported role.
7. The module supports alternating bypass.

2 The entropy for seeding the SP 800-90A DRBG is determined by the operator of the MACE which is outside of the module’s

physical and logical boundary. The operator shall use entropy sources that meet the security strength required for the random Number generation mechanism as shown in [SP 800-90A] Table 3 (CTR_DRBG) and set required bits into the module by using Load Entropy service listed in section 4.3. Since entropy is loaded passively into the module, there is no assurance of the minimum strength of generated keys. The MACE will not operate in an approved mode if the module is not seeded by the external entropy. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

8. Authentication data is not displayed during entry.
9. After a sufficient number of consecutive unsuccessful attempts (10 for Crypto Officer, 15 for User), the module will zeroize all CSP’s stored in non-volatile storage, except the User password.
10. The Module does not support the output of plaintext or encrypted secret keys.
11. The Module implements all firmware using a high-level language, except the limited use of low-level languages to enhance performance.
12. The ASTRO PDEG MACE protects secret keys from unauthorized disclosure, modification and substitution.
13. The Module provides a means to ensure that a key entered into or stored within the Module is associated with the correct entities to which the key is assigned.
14. The Module denies access to plaintext secret keys contained within the Module.
15. The Module provides the capability to zeroize all plaintext cryptographic keys and other unprotected critical security parameters within the Module.
16. The Module enters an error state if the Cryptographic Algorithm Test, Continuous Random Number Generator Test, or DRBG KAT fails. This error state may be excited by powering the module off then on.
17. The Module enters a state that only allows new firmware to be loaded if Firmware Integrity test or Firmware Load test fails.
18. The Module outputs an error indicator by turning the Alarm LED output red whenever an error state is entered due to a failed self-test.
19. The Module does not perform any cryptographic functions while in an error state.
20. The Module turns on the “Tx Clear” LED when a security association rule allowing bypass data exists.
21. The Module does not support multiple concurrent operators.

The ASTRO PDEG MACE shall operate within a Motorola Solutions PDEG Encryption Unit. After authentication with the default password, the operator shall change the default password for User role. The ASTRO PDEG MACE is not usable until the factory default password is changed for the User role. Likewise, before any CO operations can be performed, the CO password must be changed from the factory default upon first login of the CO. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The MACE’s ports and associated defined logical interface categories are listed in Table 6. Table 6

• Ports and Interfaces Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

NOTE: The module does not have Control Output Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The ASTRO PDEG MACE supports two distinct operator roles, Cryptographic Officer (CO) and User. Table

7 lists all operator roles supported by the ASTRO PDEG MACE and their related services. In addition, the

ASTRO PDEG MACE supports services which do not require to be authenticated, listed as “UA” in Table 7. The ASTRO PDEG MACE does not support a maintenance role. Table 7

• Roles, Service Commands, Input and Output Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

are authenticated with passwords. The identification, and authentication policy for each of these roles is detailed in the table below: Key are in plaintext. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Table 8

• Roles and Authentication Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

All services implemented by the ASTRO PDEG MACE are listed in Table 9. The ASTRO PDEG MACE does not allow any non-approved services while operating in FIPS 140-3 level 3 mode. The Note that all services listed in Table 9 below are available in both the approved and non-approved mode. The SSPs modes of access shown in Table 9 are defined as:

• E = Execute: The ASTRO PDEG MACE uses the SSP in performing a cryptographic operation. 2.4.C. Table 9
• Approved Services 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).

Note: All services in Table 9 are available in Non-Approved Mode with the KVL Transfer Key importing Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The ASTRO PDEG MACE is composed of base firmware version identified in Table

2. The firmware components are protected with the authentication technique(s) RSA Programmed Signature Key described in Table
3. The Module includes a firmware verification and load service to support necessary updates. The operator can initiate the firmware integrity test on demand by power cycling the ASTRO PDEG MACE. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The ASTRO PDEG MACE has a limited operational environment under the FIPS 140-3 definitions with a Physical Security at Level 3 therefore this section in not applicable. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The ASTRO PDEG MACE is a production grade, single-chip cryptographic module 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. MACE's epoxy encapsulate is claimed at ambient temperature (-40 to 85 degrees Celsius) only. No assurance of the epoxy hardness is claimed for this physical security mechanism outside of this range. The ASTRO PDEG 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 security There are two voltage powers that power the MACE. VDDCORE voltage powers all MACE chip functions while VDDBU voltage powers the MACE chip battery. VDDCORE and VDDBU voltages enter the cryptographic boundary of the module separately; and therefore, were tested separately to verify that they both cause the MACE chip to zeroize SSPs Table 10

• Physical Security Inspection Guidelines Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

Table 11

• EFP/EFT Table 12
• Hardness testing temperature ranges Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

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

The SSPs access methods are described in Table 13 below: Table 13

• SSP Management Methods NOTE: Zeroization is implicit and is considered complete either after the boot sequence is complete or when CO initiates zeroization via Erase Crypto Module service and the module provides success/fail status. Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

All SSPs (CSPs and PSPs) used by the ASTRO PDEG MACE are described in this section. All usage of these CSPs by the ASTRO PDEG MACE is described in the services detailed in 4.3. Table 14

• SSPs 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 15– Non-Deterministic Random Number Generation Specification Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The ASTRO PDEG MACE performs self-tests to ensure the proper operation. Per FIPS 140-3 these are categorized as either pre-operational self-tests or conditional self-tests. Conditional self–tests are periodically performed by the MACE as configured by the operator during module configuration as shown in Section 11.1.1. The 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 MACE at the end of periodic self-test when the I/O buffer is emptied. The MACE will reset if any self-tests fail, otherwise it will continue to operate normally. The MACE logs the most recent self-test errors to the internal flash; the operator (UA) can extract the error logs using Extract Error Log service list in section 4.3. The self-tests error states and status indicator are described in table below: Table 16

• Error States and Indicators Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

The MACE performs the following conditional self-tests: Table 18

• Conditional Self-Tests Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

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 MACE from the instructions below:

1. Upon first access, the operator will use the default password provided by Motorola in a separate communication.
2. The operator will then change the default password based on the requirements in Table 8 – Roles and Authentication
3. The operator will then configure the MACE using the Module configuration service as specified in the section 2.3.1.
4. Finally, 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 minute and maximum value = 712,800 minutes (495 days). Note: the default minimum = 0* but must be changed to a minimum of 1. * periodic self-tests will not perform if minimum = 0

The MACE is embedded in multiple Motorola Solutions, Inc. radios (aka, subscribers). Motorola uses commercially available courier systems such as UPS, FedEx, and DHL with a tracking number and requires a signature at the end by an authorized client.

Use radio specific user guide available on the www.motorolasolutions.com website for secure operations.

Use radio specific user guide available on the www.motorolasolutions.com website for secure operations.

The MACE does not require any special maintenance.

After the end-of-life, the operator should zeroize all SSPs using the “Zeroize all keys and password“ service listed in the Section 4.3 followed by shredding the MACE chip. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

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

The following standards are referred to in this Security Policy. Table 19

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

Table 20

• Acronyms and Definitions Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).