Motorola Solutions Advanced Crypto Engine (MACE) HSM – Security Level 3

Certificate

Approved Algorithms (35)

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

flowchart LR
  %% Deterministic review-risk graph for Motorola Solutions Advanced Crypto Engine (MACE) HSM – Security Level 3
  %% 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<br/>Upgrade</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>TLS<br/>IPSEC<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"]
    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 Motorola Solutions Advanced Crypto Engine (MACE) HSM – Security Level 3
  %% 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<br/>Upgrade</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>TLS<br/>IPSEC<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 C2,C3,C5,C6 clueLow;

Security Policy, page by page

Motorola Solutions Advanced Crypto Engine (MACE) HSM

• Security Level 3 Non-Proprietary FIPS 140-3 Security Policy Version: 1.6 Date: May 22, 2025 The Motorola Solutions Advanced Crypto Engine (MACE) HSM is used in the Motorola Solutions Micro HSM product. Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

This document defines the non-propriety Security Policy for the Motorola Solutions Advanced Crypto Engine (MACE) HSM

• Security Level 3, hereafter denoted as the Module. The MACE is a single-chip cryptographic module to meet FIPS 140-3 Level-3 physical security requirements. The Module provides encryption and decryption services for secure key management, and secure voice/data traffic for Motorola Solutions Micro HSM products. The FIPS 140-3 security levels for the Module are as follows: Table 1
• Security Levels ISO/IEC 24759 Section Security Requirement Security Level

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

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

The MACE cryptographic module is a single chip hardware cryptographic module. The Module is used in Motorola Solutions, Inc. Micro HSM products. 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 tested on the following operational environment. Table 2

• Cryptographic Module Tested Configuration Distinguishing Model HW P/N, Version Base Firmware version Features Motorola Solutions Advanced 5185912T05 R04.01.04 Single chip embodiment Crypto Engine (MACE) HSM The Module supports the following Approved Mode algorithms that may be installed separately from the Module’s base firmware using the program update service. While the installation of AES may be done separately, for the purposes of this validation the Module includes this firmware. Table 3
• Approved Mode Drop-in Algorithms Algorithm Algorithm FW Version Base FW Version Cert. # AES128 R01.00.05 R04.01.04 A5274 AES256 R01.00.07 R04.01.04 A5275

Figure 1 and Figure 2 depict the physical form of the MACE cryptographic module. The perimeter of the MACE IC as shown in Figure 3 is the cryptographic boundary. Motorola Solutions Public Material

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

Figure 2: MACE Chip (Interfaces) Figure 1: MACE Chip (Top) The MACE IC has an EBI port, a KVL port when connected to the Motorola Key Variable Loader (KVL), and Power Connections. Cryptographic Boundary KYLD KVLKVL Status Indicator Status MACE 1.8V Power EBI Port Host Figure 3: Cryptographic Boundary

The MACE HSM module is originally non-compliant and must be configured to operate in an approved mode of operation. The Module 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 Module to be used in an Approved Mode of operation at overall security level

3. At any given time, use the Module Info service to determine whether the Module is operating at overall security level
4. Table 4 – Approved Mode Indicator Item ID Value Meaning 0x06 (FIPS) 3 Approved Mode at overall Security Level 3 Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Note that at least one of the AES-128 and AES-256 drop-in algorithms must be loaded into the Module, however if they are loaded, they must match the values in Table 3 to be in the Approved Mode. Use Module Info service to verify that the firmware version matches an approved version listed on NIST’s website: http://csrc.nist.gov/groups/STM/cmvp/validation.html Also, the module status service will output the AES DIA versions installed with a display of APCO AES128 Version: R01.00.05 and/or APCO AES256 Version R01.00.07.

In order to configure the Module for an Approved Mode at overall Security Level 3, the operator shall use the Module Configuration service to set the following configuration parameters as shown below.

1. Clear Key Import: Disabled
2. Clear Key Export: Disabled
3. Key Loss Key (KLK): Disabled
4. Red Keyloading: Disabled
5. FIPS Security Level 3 compliant key transport: Enabled The Module will operate in Approved Mode only if it receives external entropy from the operator. Additionally, the Module supports “drop-in algorithms” 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-128 (Cert. #A5274) and/ or 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.

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

• Approved Algorithms Description/ Key Cert # Algorithm Mode Size(s) / Key Use/Functions Strength(s) ECB [38A] Key Sizes: 256 Encrypt, Decrypt CFB8 [38A] Key Sizes: 256 Encrypt, Decrypt CBC [38A] Key Sizes: 256 Encrypt, Decrypt OFB [38A] Key Sizes: 256 Encrypt, Decrypt A5273 AES [197] Authenticated Encrypt, Authenticated GCM/GMAC [38D] Key Sizes: 256 Decrypt, Message Authentication Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

Description/ Key Cert # Algorithm Mode Size(s) / Key Use/Functions Strength(s) ECB [38A] Key Sizes: 128 Encrypt, Decrypt CBC [38A] Key Sizes: 128 Encrypt, Decrypt OFB [38A] Key Sizes: 128 Encrypt, Decrypt CTR [38A] Key Sizes: 128 Encrypt, Decrypt A5274 AES [197] Authenticated Encrypt, Authenticated GCM/GMAC [38D] Key Sizes: 128 Decrypt, Message Authentication ECB [38A] Key Sizes: 256 Encrypt, Decrypt CBC [38A] Key Sizes: 256 Encrypt, Decrypt OFB [38A] Key Sizes: 256 Encrypt, Decrypt CTR [38A] Key Sizes: 256 Encrypt, Decrypt A5275 AES [197] Authenticated Encrypt, Authenticated GCM/GMAC [38D] Key Sizes: 256 Decrypt, Message Authentication Authenticated Forward Encrypt, A2527 AES [197] KW [38F] Key Sizes: 128, 256 Authenticated Decrypt for KTS Forward Authenticated A2528 AES [197] KW [38F] Key Sizes: 256 Decrypt for KTS [133] Section 5.1 Asymmetric signature key CKG [IG D.H] Key Generation generation using unmodified DRBG output [133] Section 5.2 Asymmetric key establishment key generation using VA unmodified DRBG output [133] Section 6.1 Direct symmetric key generation using unmodified DRBG output [133] Section 6.3 Symmetric Keys Produced by Combining (Multiple) Keys and Other Data A2534 KDF SRTP [135] AES-128, AES-256 A2535 KDF TLS [135] v1.2, v1.3 SHA2(384) Motorola Solutions Public Material

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

Description/ Key Cert # Algorithm Mode Size(s) / Key Use/Functions Strength(s) Deterministic Use_df A2529 DRBG [90A] CTR Random Bit AES-256 Generation1 P-384 KeyGen A2532 ECDSA [186-4] P-384 SHA2(384) SigGen P-384 SHA2(384) SigVer Key Sizes: 32 bytes Message A2531 HMAC [198] HMAC-SHA2-384 λ = 48 bytes Authentication Ephemeral Unified, Key Agreement (Initiator, Responder), Scheme provides KAS-ECC KPG, Partial, oneStepKdf P-384 A2533 192 bits of [56Arev3] (SP800-56Cr1) SHA2-384 encryption strength IG D.F Scenario 2 path 2

AES-KW keys used for encryption of keys in key transport operation and for enabling secure communication A2527 KTS [38F] KW AES Cert. #A2527 with target devices. Key establishment methodology provides 128 or

encryption strength 256-bit AES KW (SP AES KW Cert. 800-38F) key used A2528 KTS [38F] KW #2528 to decrypt the external seed. The entropy for seeding the SP 800-90A DRBG is determined by the operator of the Module that 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. Motorola Solutions Public Material

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

Description/ Key Cert # Algorithm Mode Size(s) / Key Use/Functions Strength(s) Key establishment methodology provides 256 bits strength A5253 RSA [186-5] PKCS1_v1.5 2048 SigVer Message Digest Generation, SHS 817 SHA2-256 SHA2 Password Obfuscation Message Digest SHA2-256, SHA2 Generation, A2530 SHA2-384 Password Obfuscation Note: No parts of SRTP and TLS, other than the KDF, have been tested by the CAVP and CMVP. Table 6

• Non-Approved Algorithms Allowed in the Approved Mode of Operation Algorithm Caveat Use/Function [IG D.G] Key establishment methodology AES CBC Cert. #A5273 (unwrapping KTS provides 256 bits strength. only); Table 7
• Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed Algorithm2 Caveat Use/Function [IG 2.4.A] P25 AES OTAR. No Security Claimed. AES MAC is used as part of OTAR but is AES MAC N/A considered obfuscation. KTS encryption is performed on the OTAR key components using AES KW Cert. #A2527. These algorithms do not claim any security and are not used to meet FIPS 140-3 requirements. Therefore, SSPs do not map to these algorithms. Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

1. The Module provides two distinct operator roles: User and Cryptographic Officer.
2. The Module provides identity-based authentication.
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. Power up self-tests do not require any operator action.
7. Data output are 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. The Module does not support manual SSP establishment method.
10. The Module does not have any proprietary external input/output devices used for entry/output of data.
11. The Module does not enter or output plaintext CSPs.
12. The Module does not output intermediate key values.
13. The Module does not provide bypass services for ports/interfaces.
14. The Module does not support a maintenance role and/or bypass capability.

The Module shall be installed in the Motorola Solutions Micro HSM products. After authentication with the default password, the operator shall change the default passwords for Crypto Officer (CO) and User role. The Module is not usable until the factory default passwords are changed. The Module shall be operated such that only approved Drop-in algorithms listed in the Table 3 are installed including section 11 secure installation, initialization, startup and operation of the Module.

The Module’s ports and associated FIPS defined logical interface categories are listed in Table 8. Table 8

• Ports and Interfaces Physical Port Logical Interface Data that passes over port/interface Data Input External Bus Data Output The main physical port provided by the Module. It provides access to Interface (EBI) Control Input the majority of the supported interfaces. Status Output Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

Physical Port Logical Interface Data that passes over port/interface Self-test This interface provides status output to indicate all power-up selfIndicator Status Output tests completed successfully. Power Power Input This interface powers all circuitry. Note: The module does not have Control Output. Motorola Solutions Public Material

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

The Module supports two distinct operator roles, User and Cryptographic Officer (CO). Table 9 lists all operator roles supported by the Module and their related services. In addition, the Module supports services which do not require to be authenticated, listed UA in Table 9. Table 9– Roles, Service Commands, Input and Output Role CO User UA Service Input Output X X − Program Update Firmware image The Module is upgraded to new firmware. X X − Extract Error Logs Command In Error logs. Success/failure status. X − − Extract Action Logs Command In Action logs. Success/failure status. Configuration The Module is configured as requested. Success/Failure X − − Configure Module parameters status. Change CO X − − Password Updated the CO password. Success/failure status. Password X − − Logout CO Command In Logout CO role. DRBG seed The DRBG is seeded and initialized. Success/failure − X − Load Entropy status. Change User − X − Password Updated the user password. Success/failure status. Password − X − Logout User Command In Logout the User role. Algorithm List List of Drop-In Algorithms (DIAs) available in the − X − Command In Query Module. − X − Export Key Command In Transfer keys out of the Module. Success/failure status. − X − Import Key Encrypted keys Imports keys into the Module. Success/failure status. Generate symmetric [135] keys within the Module. − X − Generate Key Command In Success/failure status. − X − Delete Key Command In Key is marked for deletion. Success/failure status. − X − Encrypt Plaintext Ciphertext. Success/failure status. − X − Decrypt Ciphertext Plaintext. Success/failure status. Generate − X − Command In Generated signature. Success/failure status. Signature − X − Verify Signature Signature Success/failure status. − X − Generate Hash Data Hash output. Success/failure status. − X − Generate MAC Data Generated MAC. Success/failure status. Motorola Solutions Public Material

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

Role CO User UA Service Input Output Perform Key − X − Agreement Command In Keys imported into the MACE. Success/failure status. Process Generate Random − X − Command In Generated random numbers. Success/failure status. Number Metadata for a given key present in the Module. − X − Key Query Command In Success/failure status. Validate User Successful authentication will allow access to the − − X Password Password services allowed for User role. Validate CO Successful authentication will allow access to the − − X Password Password services allowed for CO role. − − X Perform Self-Tests Command In Success/Reset. Module HW version, version information, and FIPS − − X Module Info Command In status.

The Module supports two distinct operator roles (User and Crypto-Officer). The Module uses a minimum

8 ASCII printable characters password to authenticate the User and CO roles. The Module enforces the

separation of roles using login credentials and re-authentication is enforced when changing roles. The module ensures that there is no visible display of the authentication data Table 10– Roles and Authentication Role Authentication Authentication Strength Method CO Identity-based. The password requires a minimum of 1 Upper case, 1 Lower case, 1 Numerical and 1 8-32 character special character. Since the minimum password length is 8 ASCII printable characters and ASCII password. there are 95 ASCII printable characters, the probability of a successful random attempt is

The Module has a default setting of 15 consecutive failed attempts. The module will have to be reinitialized after the 15 consecutive failed attempts. Within a one minute period a successful random attempt is 15 in 17,619,399,200,000 Motorola Solutions Public Material

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

Role Authentication Authentication Strength Method User Identity-based. The password requires a minimum of 1 Upper case, 1 Lower case, 1 Numerical and 1 8-32 character special character. Since the minimum password length is 8 ASCII printable characters and ASCII password. there are 95 ASCII printable characters, the probability of a successful random attempt is

The Module has a default setting of 15 consecutive failed attempts. The module will have to be reinitialized after the 15 consecutive failed attempts. Within a one minute period a successful random attempt is 15 in 17,619,399,200,000.

All services implemented by the Module are listed in Table 11. The Module does not allow any nonapproved service while operating in FIPS 140-3 level 3 mode. The SSPs modes of access shown in Table 11 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. Table 11– Approved Services Approved Security Keys and/or Roles Access Indicator Service Description Functions SSPs Rights FW-LD-Pub WZ DSEK Z BKK Z IDK-ROM E IDK-Block EZ Upgrade firmware IDK Z Program RSA [186-5], Cert. CO, Approved and perform PEK Z Update #A5253 User Mode zeroization KPK Z KEK Z TEK Z CO PWD Z User PWD Z PWD Hash Z Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

Approved Security Keys and/or Roles Access Indicator Service Description Functions SSPs Rights SRTP-MK Z SRTP-MS Z TLS-MS Z KDF-DK Z DH-Priv Z DH-SS Z ECDSA-PRIV Z ECDSA-PUB Z DH-Pub Z DH-CLI-Pub Z Extract Extract the error logs CO, Approved N/A N/A N/A Error Logs from the module. User Mode Extract Exports the history of Approved Action actions performed by N/A N/A CO N/A Mode Logs the operators. KPK Z Approved Mode KEK Z TEK Z CO PWD Z User PWD Z PWD Hash Z SRTP-MK Z Perform Configure configuration of the N/A SRTP-MS CO Z Module Module. TLS-MS Z KDF-DK Z DH-Priv Z DH-SS Z ECDSA-PRIV Z ECDSA-PUB Z DH-Pub Z PEK E Approved AES-256, Cert. Mode Validate Validate the current #A5273 KPK GEZ CO password for CO UA Password role. SHS [180], Cert. KEK Z #A2530 TEK Z Motorola Solutions Public Material

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

Approved Security Keys and/or Roles Access Indicator Service Description Functions SSPs Rights CO PWD Z User PWD Z PWD Hash Z SRTP-MK Z SRTP-MS Z TLS-MS Z KDF-DK Z DH-Priv Z DH-SS Z ECDSA-PRIV Z ECDSA-PUB Z DH-Pub Z AES-256, Cert. PEK EZ Approved Change #A5273 Mode Modify the current CO CO Password CO GEZ CO password. SHS [180], Cert. Password #A2530 PWD Hash GEZ Approved Logout CO Logs out CO role. N/A N/A CO N/A Mode PEK E Approved Mode KPK GEZ KEK Z TEK Z CO PWD Z User PWD Z PWD Hash Z AES-256, Cert. Validate Validate the current #A5273 SRTP-MK Z User password for User UA Password role. SHS [180], Cert. SRTP-MS Z #A2530 TLS-MS Z KDF-DK Z DH-Priv Z DH-SS Z ECDSA-PRIV Z ECDSA-PUB Z DH-Pub Z Motorola Solutions Public Material

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

Approved Security Keys and/or Roles Access Indicator Service Description Functions SSPs Rights PEK E Approved CKG, AES-256, Change Mode Modify the current Cert. #A5273 User GEZ User User User password. SHS [180], Cert. Password Password #A2530 PWD Hash GEZ Logout Logs out User role. Approved N/A N/A User N/A User Mode DSEK WE Approved Load external AES KW #A2528, Mode Load DRBGentropy used to seed DRBG [90A] User G Entropy EI/Seed the DRBG. #A2529 DRBG-State G Provides a list of Approved Algorithm drop-in algorithms Mode N/A N/A User N/A List Query available in the Module. KEK R Approved Mode TEK R Export Transfer keys out of SRTP-MK R AES KW #A2527 User Key the Module. SRTP-MS R TLS-MS R KDF-DK R KEK W Approved Mode TEK W Import Imports keys into the AES KW #A2527 SRTP-MK User W Key Module encrypted. SRTP-MS W TLS-MS W SRTP-MK E Approved Mode SRTP-MS E TLS-MS E Generate symmetric CKG, TLS (#A2535) KDF-DK GW Generate [135] keys within the and SRTP [135] User Key IDK-ROM EZ Module. KDF (#A2534) IDK-Block EZ IDK GZ KPK GZ Delete Mark key for Approved N/A N/A User Z Key deletion. Mode Motorola Solutions Public Material

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

Approved Security Keys and/or Roles Access Indicator Service Description Functions SSPs Rights AES [197] #A5273, KEK E Approved AES [197] #A5275, Mode KPK E AES [197] #A5274, TEK E Encrypt plaintext CKG (VA) Encrypt TLS (#A2535) and KDF-DK User E data. SRTP [135] KDFs DRBG(#A2534) E EI/Seed DRBG [90A] #A2529 DRBG-State E AES [197] #A5273, KEK E Approved AES [197] #A5275, Mode AES [197] #A5274, KPK E Decrypt ciphertext Decrypt CKG (VA), User data. TEK E TLS (#A2535) and SRTP [135] KDFs KDF-DK E (#A2534) DRBG- Approved E ECDSA [186-4] EI/Seed Mode Generate Generate a #A2532, DRBG-State E User Signature signature. DRBG [90A] ECDSA-PRIV GW #A2529 ECDSA-Pub GWR Verify ECDSA [186-4] Approved Verify a signature. ECDSA-Pub User E Signature #A2532 Mode Generate Generate a hash of a Approved SHS [180] #A2530 N/A User N/A Hash block of data. Mode Generate MAC of a KEK E Approved block of data to Mode TEK E Generate provide data HMAC [198] Cert. User MAC integrity using a #A2531 shared symmetric KDF-DK E key. KEK W Approved Mode TEK W SRTP-MK W Perform CKG, DRBG [90A] Key Perform a key #A2529, SRTP-MS W User Agreemen agreement process. KAS-ECC [56Ar3], TLS-MS W t Process Cert. #A2533 KDF-DK W DH-Priv GE DH-Pub GRE Motorola Solutions Public Material

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

Approved Security Keys and/or Roles Access Indicator Service Description Functions SSPs Rights DH-SS GE DH-CLI-Pub WE DRBG-State GE Generate DRBG- Approved Generated random DRBG [90A] Cert. E Random EI/Seed User Mode numbers. #A2529 Number DRBG-State E Retrieve the Approved metadata for a given Mode Key Query N/A N/A User N/A key present in the Module. Performs Approved Perform cryptographic N/A N/A UA N/A Mode Self-Tests algorithms self-tests. Module HW version, Approved Module Firmware version, N/A N/A UA N/A Mode Info and FIPS status. Note: The module does not implement any Non-Approved Services and only provides an Approved mode of operation. Motorola Solutions Public Material

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

The Module has a limited operational environment under the FIPS 140-3 definitions. The Module is composed of base firmware version identified in Table

2. On top of that, customer shall load at least one of the Drop-in algorithms listed in Table
3. The firmware components are protected with the authentication technique(s) RSA Programmed Signature Key described in Table
4. The Module includes a firmware verification and load service to support necessary updates for the base firmware. The operator can initiate the firmware integrity test on demand by power cycling the Module. The Module is composed of the following firmware component(s): ● non-modifiable operating system - binary Firmware versions validated through the FIPS 140-3 CMVP will be explicitly identified on a validation certificate. Any firmware not identified in this Security Policy does not constitute the Module defined by this Security Policy or covered by this validation. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The 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 Module 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 Module is covered with a hard-opaque epoxy coating that provides evidence of attempts to tamper with the Module. The security provided from the hardness of the Module'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 Module 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 Module 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 12

• Physical Security Inspection Guidelines Recommended Frequency Physical Security Mechanism Inspection/Test Guidance Details of Inspection/Test Covered with a hard-opaque epoxy Look for signs of tampering. Remove coating that provides evidence of Periodically from service if tampering found. attempts to tamper with the MACE. Table 13
• Environmental Failure Protection Temperature or Voltage Specify EFP or Results Measurement EFT Shutdown - A tamper flag is raised, a wakeLow Temperature -38.1°C EFP up reset of the product is triggered. Shutdown - A tamper flag is raised, a wakeHigh Temperature 101.4°C EFP up reset of the product is triggered. 1.65V VDDCORE : Shutdown - A general reset of the chip is Low Voltage EFP

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

• Coating testing Hardness tested temperature measurement Low Temperature -40°C High Temperature 85°C 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).

The SSPs access methods are described in Table 15 below: Table 15– SSP Management Methods Method Description G1 Generated external to the Module and installed during manufacturing. G2 Derived from the DRBG input per SP800-90Ar1. G3 FIPS 186-4 compliant ECDSA key generation, using the internal CAVP validated DRBG. G4 CKG - Symmetric key generated by internal CAVP validated DRBG. G5 EC Diffie-Hellman shared secret generation using the internal CAVP validated 56Arev3 protocol. G6 SP 800-135 compliant KDF generated key. G7 Generated per SP800-133r2 (Section 6.3 #2) via XOR of 2 other keys (IDK-ROM and IDK-Block) S1 Stored in the volatile memory (RAM). S2 Stored in the flash in plaintext, associated by memory location (pointer). S3 Stored in the flash in encrypted, associated by memory location (pointer). E2 Input electronically using SP800-38F AES key transport by the DSEK using AES KW Cert. # A2528. E3 Input electronically AES-256 CFB-8 encrypted on the PEK using AES KTS Cert. #A5273. E4 Input or output electronically using SP800-38F AES key transport on the KEK or TEK using AES KW Cert. #A2527. E5 Input electronically in plaintext as part of protocol. E6 Output electronically in plaintext public key. Z1 Zeroized by the “Program Update” service by overwriting with a fixed pattern 0s.* Z2 Zeroized by module power cycle or hard reset by overwriting with a fixed pattern 0s.* Z3 Zeroized by the “Configure Module” service by overwriting with a fixed pattern of 0s. Z4 Zeroized by the “Change CO Password” service by overwriting with a fixed pattern of 0s. Z5 Zeroized by the “Validate CO Password” service by overwriting with a fixed pattern of 0s. Z6 Zeroized by the “Change User Password” service by overwriting with a fixed pattern of 0s. Z7 Zeroized by the “Validate User Password” service by overwriting with a fixed pattern of 0s. NOTE: Change and Validate Password services zeroizes when 15 attempts have failed, and the module is reset to factory settings. 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 SSPs (CSPs and PSPs) used by the Module are described in this section. All usage of the CSPs by the Module is described in the services detailed in 4.3. Table 16– SSPs Key/SSP Strength Security Gene- Import Establish- Storage Zeroiza- Use / Related SSPs Name/ (in bits) Function / ration /Export ment tion Type Cert. CSPs DRBG- N/A N/A N/A E2 N/A S1 Z2 Externally generated, EI/Seed a minimum of 48 bytes are passively entered into the Module by the User. DRBG- 256 DRBG G2 N/A N/A S1 Z2 CTR_DRBG internal State #A2529 state: V (128 bits) and Key (AES 256). DSEK 256 AES KW G1 N/A N/A S1, S2 Z1 256-bit AES KW (SP Cert. 800-38F) key used to #A2528 decrypt the external seed. BKK 256 AES CBC G1 N/A N/A S1, S2 Z1 A 256-bit AES key Cert. used for decrypting #A5273, Load entropy into RSA Cert. the MACE. #A5253 IDK-ROM 256 AES CBC G1 N/A N/A S1, S2 Z1, Z2 A 256-bit AES CBC Cert. key used in the re#A5273 constructed of IDK per SP800-133r2 (Section 6.3 #2) via XOR using IDK-Block IDK-Block 256 AES CBC G1 N/A N/A S1, S2 Z1, Z2 A 256-bit AES CBC Cert. key used in the re#A2264 construction of IDK per SP800-133r2 (Section 6.3 #2) via XOR using IDK-ROM IDK 256 AES CBC G7 N/A N/A S1 Z2 A 256-bit AES CBC Cert. key used to decrypt #A5273, downloaded RSA Cert. firmware images. #A5253 PEK 256 AES CBC G1 N/A N/A S1, S2 Z1, Z2 256-bit AES-CFB8 key #A5273, used for decrypting passwords during password validation. Motorola Solutions Public Material

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

Key/SSP Strength Security Gene- Import Establish- Storage Zeroiza- Use / Related SSPs Name/ (in bits) Function / ration /Export ment tion Type Cert. KPK 256 AES CFB-8 G4 N/A N/A S1, S2 Z1, Z2, 256-bit AES CFB-8 Cert. Z3, Z4, key used to encrypt #A5273, Z5, Z6, all TEKs and KEKs DRBG Cert. Z7 stored in the flash. #A2529 KEK 128, 256 AES KW N/A E4 N/A S1, S3 Z1, Z2, 128 and 256-bit AES#A2527 Z8 KW keys used for encryption of keys in key transport operation. TEK 128, 256 AES KW N/A E4 N/A S1, S3 Z1, Z2, 128 and 256-bit AES Cert. Z8 keys used for #A2527, enabling secure communication with target devices. CO PWD 256 AES CFB-8 N/A E3 N/A S1, S3 Z1, Z2, 8-32 ASCII characters Cert. Z3, Z4, CO password. #A5273 Z5, Z6, Z7 User PWD 256 AES CFB-8 N/A E3 N/A S1, S3 Z1, Z2, 8-32 ASCII characters Cert. Z3, Z4, User password. #A5273 Z5, Z6, Z7 PWD Hash 192 SHS [180] G1 N/A N/A S1, S3 Z1, Z2, 384-bit password Cert. Z3, Z4, hash stored in the #A2530 Z5, Z6, non-volatile Z7 memory. SRTP-MK 128, 256 CVL SRTP G4 E4 N/A S1, S3 Z1, Z2, SRTP/SRTCP Master KDF Cert. Z3, Z4, Key. 128 or 256-bit #A2534 Z5, Z6, key used in SRTP Z7 KDF. SRTP-MS 96, 112 CVL SRTP G4 E4 N/A S1, S3 Z1, Z2, SRTP/SRTCP Master KDF Cert. Z3, Z4, Salt. 112-bit key used #A2534 Z5, Z6, in SRTP KDF, or 96Z7 bit key to generate IV internally for AES GCM encryption operation. TLS-MS 384 CVL TLS KDF G4 E4 N/A S1, S3 Z1, Z2, TLS KDF Master Cert. Z3, Z4, Secret. 384-bit secret #A2535 Z5, Z6, key material. Z7 Motorola Solutions Public Material

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

Key/SSP Strength Security Gene- Import Establish- Storage Zeroiza- Use / Related SSPs Name/ (in bits) Function / ration /Export ment tion Type Cert. KDF-DK 128, 256 CVL TLS KDF G6 E4 N/A S1 Z1, Z2, KDF Derived Key. Cert. (export Z3, Z4, Keys derived using #A2535 or only) Z5, Z6, TLS or SRTP KDFs. CVL SRTP Z7 KDF Cert. #A2534, AES-GCM Cert. #A5275 and #A5274 DH-Priv 192 KAS Cert. G3 N/A N/A S1 Z1, Z2, The Elliptic Curve #A2533 Z3, Z4, Diffie-Hellman (DH) DRBG Cert. Z5, Z6, private key used for Z7 establishing a shared #A2529 secret over an insecure channel. DH-SS 192 KAS Cert. N/A N/A G5 S1 Z1, Z2, The Elliptic Diffie#A2533 Z3, Z4, Hellman (DH) Shared Z5, Z6, Secret (SS) is Z7 established as a part of DH key agreement scheme. ECDSA- 192 ECDSA Cert. G3 N/A N/A S1 Z1, Z2, 384-bit ECDSA PRIV #A2532, Z3, Z4, Private Key used to DRBG Cert. Z5, Z6, generate the #A2529 Z7 signature of the input data from the Generate Signature service request. PSPs FW-LD-Pub 112 AES CBC G1 N/A N/A S1, S2 Z1, Z2 2048-bit RSA key Cert. used to validate the #A5273, FW Loading before it RSA #A5253 is allowed to be executed. Note - FW-LD-Pub is also used during FW integrity to validate the signature of the firmware image DH-Pub 192 KAS Cert. G3 E6 N/A S1 Z1, Z2, The Elliptic Curve #A2533 Z3, Z4, (EC) Diffie-Hellman Z5, Z6, (DH) public key, used Z7 for establishing a Motorola Solutions Public Material

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

Key/SSP Strength Security Gene- Import Establish- Storage Zeroiza- Use / Related SSPs Name/ (in bits) Function / ration /Export ment tion Type Cert. shared secret over an insecure channel. DH-CLI-Pub 192 KAS Cert. N/A E5 N/A S1 Z1, Z2, The Elliptic Curve #A2533 Z3, Z4, (EC) Diffie-Hellman Z5, Z6, (DH) public key for Z7 the other party, used for establishing a shared secret over an insecure channel. ECDSA- 192 ECDSA Cert. G3 E6 N/A S1 Z1, Z2, ECDSA Public key PUB #A2532 Z3, Z4, used to validate the Z5, Z6, signature of the Z7 input data from a service request. Table 17

• Non-Deterministic Random Number Generation Specification Entropy Minimum number of Details Sources bits of entropy The Load Entropy service provides the security strength required for the random number generation mechanism External 384 bits of entropy Per IG 9.3.A, Example 2A, there is no assurance of the minimum strength of generated SSPs. Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

The Module performs self-tests to ensure the proper operation of the Module. Per FIPS 140-3 these are categorized as either pre-operational self-tests or conditional self-tests. Pre-operational self–tests are available on demand by power cycling the Module. Pre-operational Cryptographic Algorithm Self-Tests (CAST) are periodically performed by the Module in every X3 minutes, where X is configured by the operator during module configuration. The Module 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 Module at the end of periodic self-test when the I/O buffer is emptied. The periodic self-test process should take no more than 2-3 minutes. The Module will reset if any selftests fails, otherwise it will continue to operate normally. The Module 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 18– Error states and indicators Error state Description Indicator ES1 The Module fails a KAT. The Module enters the critical error state. In this state, the Module stores the status into the internal flash memory and then halts all further operation by entering an infinite loop. The operator may correct this state by power cycling the Module. ES2 The Module fails a firmware The Module enters the firmware loading during program upgrade signature validation failure state. and/or firmware integrity pre- In this state, the Module halts all operational self-test. further operations by entering the flash programming mode. The operator may correct the issue by power cycle and/or reflashing a new image. ES3 The MACE fails an ECDSA PCT. The MACE enters a temporary error state. The generated key is not used, and the Module returns an error code (0x1) to the operator. The key is discarded, and the process abandoned. The operator can configure the periodic self-tests interval to any value between 1 to 712800 minutes. Motorola Solutions Public Material

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

The Module performs the following pre-operational self-tests: Table 19– Pre-Operational Self-Test Security Method Description Error Function state Firmware RSA (Cert. A digital signature is generated over the Boot Block, Base ES2 integrity #A5253), SHA2- firmware and all Drop-in algorithms code when it is built using

stored with the code upon download into the MACE. When the MACE is powered up, the digital signature is verified. If the digital signature matches, then the test passes, otherwise it fails. The Module performs the following conditional self-tests: Table 20– Conditional Self-Tests Security Function Method Description Error state AES256

• CFB8, CBC, ECB, KAT AES-256 encryption KAT. ES1 OFB, and GCM (Cert. #A5273) AES256
• CFB8, CBC, ECB, KAT AES-256 decryption KAT. ES1 OFB, and GCM (Cert. #A5273) AES256
• CBC, CTR, ECB, KAT AES-256 encryption KAT. ES1 OFB, and GCM (Cert. #A5275) AES256
• CBC, CTR, ECB, KAT AES-256 encryption KAT. ES1 OFB, and GCM (Cert. #A5275) AES128
• CBC, CTR, ECB, KAT AES-128 encryption KAT. ES1 OFB, and GCM (Cert. #A5274) AES128
• CBC, CTR, ECB, KAT AES-128 decryption KAT. ES1 OFB, and GCM (Cert. #A5274) AES KW KAT AES-256 key wrap and key unwrap KAT. ES1 (Cert. #A2527) AES KW KAT AES-256 key unwrap KAT. ES1 (Cert. #A2528) DRBG KAT AES-256 CTR_DRBG instantiation, generate, and ES1 (Cert. #A2529) reseed KATs performed before the first random data generation. Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

Security Function Method Description Error state KAS-ECC Sp800-56Ar3 KAT Per IG D.F, separately tested KAS Shared Secret ES1 (Cert. #A2533) generation with P-384 and SP 800-56Cr2 one-step KDA ECDSA (Cert. #A2532) KAT ECDSA P-384 SigGen KATs. ES1 ECDSA (Cert. #A2532) KAT ECDSA P-384 SigVer KATs. ES1 HMAC KAT HMAC-SHA2-384 KAT. ES1 SHS (Cert. #A2530) KAT SHA2-256, SHA2-384 KAT. ES1 SRTP KDF [135] (Cert. KAT SRTP KDF KAT. ES1 #2534) TLS 1.2 and TLS 1.3 KDF KAT TLS 1.2 and TLS 1.3 KDF KAT. ES1 [135] (Cert. #A2535) RSA SigVer (Cert. #A5253) KAT RSA-2048 SigVer, performed before Pre-Operational ES2 FW integrity tests. SHS 256-bit (Cert. #817) KAT SHA2-256 KAT, performed before Pre-Operational ES2 FW integrity tests. ECDSA Key Generation PWCT ECDSA P-384 Pair-wise Consistency Test. ES3 (Cert. #A2532) Firmware Load RSA (Cert. A digital signature is generated over the code when it ES2 #A5253), is built using SHA2-256 and RSA-2048. The digital SHA2-256 signature is verified upon download into the Module. (Cert. #817) 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 (CO) will use the default password provided by Motorola in a separate communication.
2. The CO will then change the default passwords (user and CO) based on the requirements in the Roles and Authentication table.
3. The CO will then configure the MACE using the Module configuration service as specified in the section 2.3.1.
4. Finally, the CO 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. During manufacturing, all of the firmware modules are signed by the RSA private Programmed Signature Key and the module is loaded with the RSA public Programmed Signature (FW-LD-Pub) key. The signature of the firmware is verified to ensure the integrity of the module when it is delivered to authorized operators. The module is embedded into Motorola radio products, and it's put into the radio circuitry during Manufacturing. Hence, the module is directly shipped from the Motorola factory to the end customers through sales and distribution channels.

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. Motorola Solutions Public Material

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

After the end-of-life, the operator should zeroize all SSPs, except those SSPs entered at manufacturing, using the “Configure Module“ 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 Module does not implement any mitigation method against other attacks. Motorola Solutions Public Material

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

The Module generates GCM IVs deterministically as specified in SP800-38D Section 8.2.1 using the following protocols: ● TLS 1.2: The Module is compliant with TLS v1.2 and SP800-52 Rev2, Section 3.3.1 in accordance with RFC 5246 for TLS key establishment which implies compliance with TLS v1.2 and SP800-52 Rev2, Section 3.3.1. The AES GCM IV generation is in compliance with RFC 5288 and shall only be used for the TLS protocol version 1.2 to be compliant with FIPS140-3 IG C.H, Option

1. The fixed field consists of a 32-bit salt that is generated internally to the Module and the invocation field consists of a 64-bit nonce_explicit passed into the Module as an input parameter. o When the nonce_explicit (counter) part of the IV exhausts the maximum number of possible values for a given session key this condition triggers a handshake to establish a new encryption key per RFC 5246. o During operational testing, the Module was tested against an independent version of TLS1.2 and found to behave correctly. ● TLS 1.3: The AES GCM IV is in compliance with RFC 8446 section 5.3. Section 8.1 IV construction and shall only be used for the TLS1.3 protocol to be compliant with FIPS140-3 IG C.H, Option
2. It is generated by XORing the lower 64-bit of 96-bit TLS 1.3 HKDF derived data (internal/static IV) and 64-bit SSL sequence numbers. o During operational testing, the Module was tested against an independent version of TLS1.3 and found to behave correctly. ● SRTP: The AES GCM IV generation is in compliance with RFC 7714, Section 8.1 IV construction and shall only be used for the SRTP protocol to be compliant with FIPS140-3 IG C.H, Option
3. The fixed field consists of a 32-bit Synchronization Source identifier and 16-bits of zeroes, and the invocation field consists of a 16-bit Sequence Number and 32-bit Rollover Counter. Both the fixed field and invocation field are passed into the Module as input parameters and XORed with a 96bit random salt imported or generated internally. Note that the XOR operation does not have an impact on SP 800-38D requirements because the salt is not regenerated until a key is reestablished and therefore acts as a constant within an individual key’s lifecycle. o During operational testing, the Module was tested against an independent version of SRTP and found to behave correctly. ● SRTCP: The AES GCM IV generation is in compliance with RFC 7714, Section 9.1 IV construction and shall only be used for the SRTCP protocol to be compliant with FIPS140-3 IG C.H, Option
4. The fixed field consists of 16 bits of zeroes, a 32-bit Synchronization Source, 17 bits of zeroes, and the invocation field which consists of a 31-bit SRTCP Index. Both the fixed field and invocation field are passed into the Module as input parameters and XORed with a 96-bit random salt imported or generated internally. Note that the XOR operation does not have an impact on SP 800-38D requirements because the salt is not regenerated until a key is re-established and therefore acts as a constant within an individual key’s lifecycle. o During operational testing, the Module was tested against an independent version of SRTP and found to behave correctly. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

If the Module's power is lost and restored for any of the protocols listed above, a new GCM key will be established. The invocation field is incremented externally and input to the Module; if the new invocation field is not greater than the last value then the Module will transition to an error state. Following an overflow of the invocation field, the Module will transition to an error state.

The Module generates GCM IVs randomly as specified in SP800-38D section 8.2.2 using approved DRBG (Cert #A2529) and is to be compliant with FIPS140-3 IG C.H, Option 2 and the IV length is 96 bits. 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 21– References Abbreviation Full Specification Name [FIPS140-3] Security Requirements for Cryptographic Modules, March 22, 2019 [ISO19790] International Standard, ISO/IEC 19790, Information technology

• Security techniques
• Test requirements for cryptographic modules, Third edition, March 2017 [ISO24759] International Standard, ISO/IEC 24759, Information technology
• Security techniques
• Test requirements for cryptographic modules, Second and Corrected version, 15 December 2015 [IG] Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program, May 16, 2022. [131A] Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, Revision 2, March 2019 [133] NIST Special Publication 800-133, Recommendation for Cryptographic Key Generation, Revision 2, June 2020 [135] National Institute of Standards and Technology, Recommendation for Existing ApplicationSpecific Key Derivation Functions, Special Publication 800-135rev1, December 2011. [186] National Institute of Standards and Technology, Digital Signature Standard (DSS), Federal Information Processing Standards Publication 186-, February 3, 2023. [197] National Institute of Standards and Technology, Advanced Encryption Standard (AES), Federal Information Processing Standards Publication 197, November 26, 2001 [198] National Institute of Standards and Technology, The Keyed-Hash Message Authentication Code (HMAC), Federal Information Processing Standards Publication 198-1, July, 2008 [180] National Institute of Standards and Technology, Secure Hash Standard, Federal Information Processing Standards Publication 180-4, August, 2015 [38A] National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation, Methods and Techniques, Special Publication 800-38A, December 2001 [38D] National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, Special Publication 800-38D, November 2007 [38F] National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping, Special Publication 800-38F, December 2012 [56Ar3] NIST Special Publication 800-56A Revision 3, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, April 2018 [56Cr2] NIST Special Publication 800-56C Revision 2, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, August 2020 Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

Abbreviation Full Specification Name [90A] National Institute of Standards and Technology, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, Special Publication 800-90A, Revision 1, June 2015. [OTAR] Project 25

• Digital Radio Over-The-Air-Rekeying (OTAR) Messages and Procedures [TIA102.AACA-A], September 2014 [RFC3686] Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP), January 2004 [RFC3711] The Secure Real-time Transport Protocol (SRTP), March 2004 [RFC5288] AES Galois Counter Mode (GCM) Cipher Suites for TLS, August 2008 [RFC5869] HMAC-based Extract-and-Expand Key Derivation Function (HKDF), May 2010 [RFC5246] The Transport Layer Security (TLS) Protocol, August 2008 [RFC6188] The Use of AES-192 and AES-256 in Secure RTP, March 2011 [RFC7714] AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP), December 2015 [RFC8446] The Transport Layer Security (TLS) Protocol Version 1.3, August 2018 Table 22– Acronyms and Definitions Acronym Definition AES Advanced Encryption Standard BKK Black Keyloading Key CAST Cryptographic Algorithm Self-Tests CBC Cipher Block Chaining CFB Cipher Feedback CKG Cryptographic Key Generation CO Crypto-Officer CO PWD Crypto-Officer Password CSP Critical Security Parameter DH-CLI-Pub Diffie-Hellman Client Public Key DH-Priv Diffie-Hellman Private Key DH-Pub Diffie-Hellman Public Key DH-SS Diffie-Hellman Shared Secret DRBG Deterministic Random Bit Generator Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

Acronym Definition DRBG- DRNG Entropy Input EI/Seed DSEK DRBG Seed Encryption Key EBI External Bus Interface ECB Electronic Code Book ECDH Elliptic Curve Diffie-Hellman ECDSA Elliptic Curve Digital Signature ECDSA-PUB ECDSA Public Key FIPS Federal Information Processing Standards FW Firmware FW-LD-Pub Firmware Load Public Key GCM Galois/Counter Mode GMAC Galois Message Authentication Code HSM Hardware Security Module IDK Image Decryption Key IV Initialization Vector KAT Known Answer Test KDA Key Derivation Algorithm KDF Key Derivation Function KDF-DK KDF Derived Key KEK Key Encryption Key KPK Key Protection Key TEK Key Encryption Key KYLD Keyload KVL Key Variable Loader MAC Message Authentication Code MACE Motorola Advanced Crypto Engine OFB Output Feedback OTAR Over The Air Rekeying PWD Hash Password Hash PEK Password Encryption Key Motorola Solutions Public Material

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

Acronym Definition PWCT Pair-Wise Consistency Test ECDSA-PRIV ECDSA Private Key SRTP Secure Real-time Transport Protocol SRTP-MK SRTP/SRTCP Master Key SRTP-MS SRTP/SRTCP Master Salt RSA Rivest–Shamir–Adleman SSP Sensitive Security Parameter TEK Traffic Encryption Key TLS Transport Layer Security TLS-MS TLS Pre-Shared Master Secret UA Unauthenticated Service User PWD User Password Motorola Solutions Public Material

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