All modules
CMVP Validated Module · FIPS 140-3 Security Policy

Astro PDEG Motorola Advanced Crypto Engine (MACE)

Certificate#4870StandardFIPS 140-3Level3TypeHardwareEmbodimentSingle ChipStatusActiveVendorMotorola Solutions, Inc.
High review priority  ·  no TCB surface named  ·  last validated 20 months ago. How this is derived →

Certificate

StandardFIPS 140-3
Overall level3
Module typeHardware
EmbodimentSingle Chip
StatusActive
Sunset date11/6/2026
CaveatInterim Validation. When installed, initialized and configured as specified in Section 11 of the Security Policy. No assurance of the minimum strength of generated SSPs
VendorMotorola Solutions, Inc.

Approved Algorithms (9)

AlgorithmACVP Cert
AES-CBCAES 819
AES-CFB8AES 819
AES-ECBAES 819
AES-GCMAES 1295
AES-KWAES 5358
AES-OFBAES 819
Counter DRBGA2935
RSA SigVer (FIPS186-5)A5253
SHA2-256SHS 817

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;
Underlying clues
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

Page 1

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

Page 2
Table of Contents
#SectionPage
Page 3
List of Tables
ItemPage
Table 1 – Security Levels4
Table 2 – Cryptographic Module Tested Configuration5
Table 3 – Approved Algorithms7
Table 4 – Non-Approved Algorithms Allowed in the Approved Mode of Operation8
.8
Table 6 – Ports and Interfaces10
Table 7 – Roles, Service Commands, Input and Output12
Table 8 – Roles and Authentication14
Table 9 – Approved Services15
Table 10 – Physical Security Inspection Guidelines21
Table 11 – EFP/EFT22
Table 12 – Hardness testing temperature ranges22
Table 13 – SSP Management Methods24
Table 14 – SSPs25
Table 15– Non-Deterministic Random Number Generation Specification27
Table 16 – Error States and Indicators28
Table 17 – Pre-Operational Self-Test28
Table 18 – Conditional Self-Tests29
Table 19 – References32
Table 20 – Acronyms and Definitions33
Figure 1: MACE Chip (Top)5
Figure 2: MACE Chip (Interfaces)5
Figure 3: Cryptographic Boundary6
Page 4
1 General

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

1 General 3

2 Cryptographic Module Specification 3

3 Cryptographic Module Interfaces 3

4 Roles, Services and, Authentication 3

5 Software/Firmware Security 3

6 Operational Environment N/A

7 Physical Security 3

8 Non-Invasive Security N/A

9 Sensitive Security Parameter Management 3

10 Self-Tests 3

11 Life-Cycle Assurance 3

12 Mitigation of Other Attacks N/A

Overall 3 Motorola Solutions Public Material

Page 5
2 Cryptographic Module Specification

The ASTRO PDEG MACE cryptographic module is a single chip hardware cryptographic module. The ASTRO 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-

3 validated overall security level 3.
2.1 Operational Environment

The ASTRO PDEG MACE cryptographic module is tested on the following operational environment. Table 2

2.2 Cryptographic Boundary

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

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

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

2.3 Modes of Operation

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

Page 7
2.3.1 Configuration of the Approved Mode of Operation

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

  1. To configure the module to operate in approved mode, the operator must log in as the CO using the default password and:
  2. Change the default password.
  3. Activate and configure the periodic self-test timer.
  4. 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.
2.3.2 Configuration of the Non-Approved Mode of Operation

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.

2.4 Security Functions

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

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

using approved DRBG (Cert # A2935). Motorola Solutions Public Material

Page 8

Cert # Algorithm Mode Description Functions/Caveats [133] Section 6.3 (#2) Symmetric Keys Produced by Combining (Multiple) Keys and Other Data Deterministic Random Bit A2935 DRBG [90A] CTR with derivation function AES-256 Generation2 AES 5358 KTS Key Unwrap AES-256 AES KW Cert. #5358 A5253 RSA [186-5] PKCS1_v1.5 2048 SigVer Message Digest Generation, SHS 817 SHS [180] SHA-256 Password Obfuscation Table 4

2.5 Overall Security Design
  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

Page 9
  1. Authentication data is not displayed during entry.
  2. 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.
  3. The Module does not support the output of plaintext or encrypted secret keys.
  4. The Module implements all firmware using a high-level language, except the limited use of low-level languages to enhance performance.
  5. The ASTRO PDEG MACE protects secret keys from unauthorized disclosure, modification and substitution.
  6. 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.
  7. The Module denies access to plaintext secret keys contained within the Module.
  8. The Module provides the capability to zeroize all plaintext cryptographic keys and other unprotected critical security parameters within the Module.
  9. 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.
  10. The Module enters a state that only allows new firmware to be loaded if Firmware Integrity test or Firmware Load test fails.
  11. 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.
  12. The Module does not perform any cryptographic functions while in an error state.
  13. The Module turns on the “Tx Clear” LED when a security association rule allowing bypass data exists.
  14. The Module does not support multiple concurrent operators.
2.6 Rules of Operation

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

Page 10
3 Cryptographic Module Interfaces

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

Page 11

Physical Port Logical Interface Data that passes over port/interface The Status LED output is used to drive the external Status LED green to indicate a good battery, and a Traffic Encryption Key (TEK) has been loaded. The Status LED output is used to drive the external Status LED Status LED output Status Output yellow to indicate a good battery, but no Traffic Encryption Key (TEK) has been loaded. The Status LED output is used to drive the external Status LED red to indicate a low or dead battery. IRQ/FIQ Control Input External interrupts Clock Control Input Clock input NOTE: The module does not have Control Output Motorola Solutions Public Material

Page 12
4 Roles, Services and Authentication
4.1 Assumption of Roles and Related Services

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

Page 13

Role Service Input Output CO User UA Configuration Updated module FIPS mode/Display X − − Set FIPS Mode parameters current FIPS mode Configuration Updated module security association X − − Configure Security Association parameters configuration. Success/failure status. X − − Check Security Association Command In Security association configuration. Configuration Updated OTEK configuration. X − − Configure OTEK parameters Success/failure status. X − − Version Query Command In Show module version info Key is marked for deletion. − X − Delete Key Command In Success/failure status. Keys imported into the MACE. − X − Perform Key Transport Process Command In Success/failure status. Keys imported into the ASTRO PDEG − X − KVL Transfer Key3 Encrypted Keys MACE. Success/failure status. Keys deleted from the ASTRO PDEG − X − KVL Delete Key Command In MACE. Success/failure status. − X − KVL Check Key Command In Show key status − X − KVL Query Algorithm List Command In Show list of supported algorithms X − − Extract Error Log Command In Error logs out. Success/Failure status. Reset Button − − X Reset Crypto Module Reset the MACE press/Cycle power. − − X Erase Crypto Module Erase Button press Zeroize all CSPs

4.2 Authentication Methods

The ASTRO PDEG MACE supports a Crypto-Officer role, and a User role. The Crypto-Officer and User roles are authenticated with passwords. The identification, and authentication policy for each of these roles is detailed in the table below: In Non-Approved Mode of Operation, Keys imported into the ASTRO PDEG MACE using the KVL Transfer Key are in plaintext. Motorola Solutions Public Material

Page 14

Table 8

Page 15
4.3 Services

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:

Page 16

Access Rights Approved Security Keys and/or Service Description Roles to Keys and/or Indicator Functions SSP SSPs Modify the current AES-256, Cert. KPK GEZ password used to #AES 819, KEK Z identify and SHS [180], Cert. Change CO authenticate the CO TEK Z Approved #SHS 817 Password role. CO Password GEZ Mode PWD Hash GEZ UKKPK E PEK E KPK GEZ Modify the current AES-256, Cert. password used to KEK Z Change User #AES 819 Approved identify and TEK User Z Password SHS [180], Cert. Mode authenticate the User Password GEZ User role. #SHS 817 PWD Hash GEZ UKKPK E PEK E KPK GEZ Validate the current AES-256, Cert. # KEK Z password used to AES 819, TEK Z Validate CO Approved identify and CO Password SHS [180], Cert. CO Password Z Mode authenticate the CO role. #SHS 817 User Password Z PWD Hash Z UKKPK E PEK E KPK GEZ Validate the current AES-256, Cert. # KEK Z password used to AES 819 TEK Z Validate User Approved identify and User Password SHS [180], Cert. CO Password Z Mode authenticate the User role. #SHS 817 User Password Z PWD Hash Z UKKPK E Exits command shell Approved Logout CO N/A N/A CO N/A interface Mode PEK E AES [197], Certs. TEK E #AES 819 or #AES KEK E Approved Encrypt Encrypt data. 1295, CKG (VA), User KPK E Mode DRBG [90A] #A2935 DRBG-EI/SEED E DRBG State E PEK User E Motorola Solutions Public Material

Page 17

Access Rights Approved Security Keys and/or Service Description Roles to Keys and/or Indicator Functions SSP SSPs TEK E AES [197], Certs. #AES 819 or #AES KEK E Approved Decrypt Decrypt data. 1295, CKG (VA), KPK E Mode DRBG [90A] # BKK E A2935 IDK E Bypass Bypass Approved encryption/decryptio N/A N/A User N/A Mode n services Provide firmware Approved Module Status version, current FIPS N/A N/A CO N/A Mode status Perform module selftests comprised of cryptographic algorithm tests, firmware integrity Approved Self-Tests test, and critical N/A FW-LD-Pub CO/UA E Mode functions test. Initiated by module reset or transition from power off state to power on state. KPK GEZ KEK Z Set configuration Module parameters used to TEK Z Approved N/A CO Configuration specify module Password WZ Mode behavior. PWD Hash WZ UKKPK E Set FIPS Mode Update module FIPS Approved N/A N/A CO N/A mode. Mode Configure Update module Approved Security security association N/A N/A CO N/A Mode Association configuration. Check Security Display Security Approved Association association N/A N/A CO N/A Mode configuration. Set configuration Configure parameters used for Approved N/A N/A CO N/A OTEK communication with Mode the KMF for OTEK Motorola Solutions Public Material

Page 18

Access Rights Approved Security Keys and/or Service Description Roles to Keys and/or Indicator Functions SSP SSPs Provides module firmware and Approved Version Query N/A N/A CO N/A hardware version Mode numbers Mark key for KPK N/A Approved Delete Key N/A User deletion. Mode Perform Key Perform a key AES KW Key KEK W Approved Transport transport process for Unwrap, AES Cert. User TEK W Mode Process OTEK service. #AES 5358 BKK E Imports keys to the AES KW Key KPK E KVL Transfer Approved ASTRO PDEG MACE Unwrap, AES Cert. User Key KEK W Mode via KVL. #AES 5358 TEK W Zeroize selected key KEK Z Approved KVL Delete Key variables from the N/A User TEK Z Mode ASTRO PDEG MACE. KVL Check Key Obtain status Approved information about a N/A BKK User E Mode specific key/keyset. KVL Query Provides algorithm Approved N/A N/A User E Algorithm List version numbers Mode Extract Error Provide the history of Approved N/A N/A CO N/A Log error events. Mode Reset/power cycle DRBG-EI/SEED Z Reset Crypto Approved the ASTRO PDEG N/A UA Module DRBG-State Z Mode MACE. KPK GZ Zeroize the KPK and all keys and CSPs in KEK Z the key database and TEK Z Erase Crypto Approved causes a new KPK to N/A UA Module Password Z Mode be generated. Resets the password to the PWD Hash Z factory default. UKKPK E Note: All services in Table 9 are available in Non-Approved Mode with the KVL Transfer Key importing keys in plaintext. Motorola Solutions Public Material

Page 19
5 Firmware Security

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

  1. The firmware components are protected with the authentication technique(s) RSA Programmed Signature Key described in Table
  2. 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).
Page 20
6 Operational Environment

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

Page 21
7 Physical Security

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. The ASTRO PDEG MACE is covered with a hard-opaque epoxy coating that provides evidence of attempts to tamper with the ASTRO PDEG MACE. The security provided from the hardness of the ASTRO PDEG 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 of the ASTRO PDEG MACE while delivering to operators. 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

Page 22

Table 11

1.350 VVDBU

2.034V VDDCORE : A tamper flag is raised, a wake-up reset High Voltage Shutdown 2.292V - VVDBU of the product is triggered. Table 12

Page 23
8 Non-Invasive Security

The ASTRO PDEG MACE does not implement any mitigation method against non-invasive attack. Motorola Solutions Public Material

Page 24
9 Sensitive Security Parameter (SSP) Management

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

Page 25
9.1 Sensitive Security Parameters (SSPs)

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

256 G2 N/A N/A S1 Z2 Key (AES 256) and

State #A2935 derived from DRBGEI/Seed A 256-bit AES CBC key used in the reAES CBC Cert. construction of IDK IDK-ROM 256 G1 N/A N/A S1, S2 Z1, Z2 #AES 819 per SP800-133r2 (Section 6.3 #2) via XOR using IDK Block. A 256-bit AES CBC key used in the reAES CBC Cert. construction of IDK IDK-Block 256 G1 E1 N/A S1, S2 Z1, Z2 #AES 819 per SP800-133r2 (Section 6.3 #2) via XOR using IDK-ROM. AES CBC Cert. A 256-bit AES CBC key IDK 256 #AES 819, RSA G4 N/A N/A S1, S2 Z1, Z2 used to decrypt Cert. #A5253 downloaded images. A 256-bit AES key AES OFB Cert. used for decrypting BKK 256 #AES 819, G1 N/A N/A S1, S2 Z1, Z2 the keys entered into RSA Cert. #A5253 the MACE through KVL interface. AES CBC Cert. A 256-bit AES key #AES 819, AES ECB used for decrypting EDK 256 G1 N/A N/A S1, S2 Z1, Z2 Cert. #AES 819, the external entropy RSA Cert. #A5253 seed AES CFB-8 Cert. 256-bit AES CFB-8 key PEK 256 #AES 819, RSA G1 N/A N/A S1, S2 Z1, Z2 used for decrypting Cert. #A5253 passwords. Motorola Solutions Public Material

Page 26

Key/SSP Strength Security Gener- Import (I) Establish- ZeroizaName/ Storage Use/Related SSPs (in bits) Function/Cert. ation /Export (E) ment tion Type 256-bit AES CFB-8 key AES CFB-8 Cert. Z2, Z4, used to encrypt all KPK 256 #AES 819, DRBG G3 N/A N/A S1, S3 Z5, Z7 TEKs and KEKs stored Cert. #A2935 in the flash. AES CBC Cert #AES819, AES 256-bit AES Key used UKKPK 256 CFB8 Cert G1 N/A N/A S1, S2 Z1, Z2 for encrypting the #AES819, RSA Cert KPK in flash #A5253 KEK 256 AES KW Cert. #AES N/A E2, E5 N/A S1, S3 Z2, Z3, 256-bit AES Keys used 5358, AES OFB Z4, Z5, for decrypting keys in Cert. #AES 819 Z7, Z8, Z9 the OTEK service. TEK 256 AES KW #AES N/A E2, E5 N/A S1, S3 Z2, Z3, 256-bit AES key used 5358, AES OFB Z4, Z5, for data encryption. Cert. #AES 819, Z7, Z8, Z9 AES GCM #AES 1295 15-16-digit ASCII CO AES CFB-8 Cert. Z2, Z5, N/A N/A E3 N/A S1 (printable) characters Password #AES 819 Z6, Z7 password. 10-digit hexadecimal User AES CFB-8 Cert. Z2, Z5, number user N/A N/A E3 N/A S1 Password #AES 819 Z6, Z7 authentication password. 256-bit password SHS [180] Cert. Z2, Z5, PWD Hash 128 G1 N/A N/A S1, S2 hash stored in the #SHS 817 Z6, Z7 non-volatile memory. PSPs FW Load: 2048-bit RSA key used to AES CBC Cert. validate the signature FW-LD-

112 #AES 819, RSA G1 N/A N/A S1, S2 Z1, Z2 of the firmware

Pub Cert. #A5253 image before it is allowed to be executed. Motorola Solutions Public Material

Page 27

Table 15– Non-Deterministic Random Number Generation Specification Entropy Minimum number of Details Sources bits of entropy The entropy for seeding the SP 800-90A DRBG is determined by the host application using the Module and is outside of the module’s physical. The operator shall use entropy sources that meet the security strength required for the random number generation External 384 bits of entropy 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. Motorola Solutions Public Material

Page 28
10 Self-Tests

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. Pre-operational and Conditional self-tests are available on demand by power cycling the MACE. 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

Page 29

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

Page 30
11 Life-Cycle Assurance
11.1 Installation, Initialization, and Startup Procedures
11.1.1 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 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
11.1.2 Delivery

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.

11.2 Administrator Guidance

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

11.3 Non-Administrator Guidance

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

11.4 Maintenance Requirements

The MACE does not require any special maintenance.

11.5 End of Life

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

Page 31
12 Mitigation of Other Attacks

The ASTRO PDEG MACE does not implement any mitigation method against other attacks. Motorola Solutions Public Material

Page 32
13 References and Definitions

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

Page 33

Table 20