Motorola Solutions, Inc. © 2024 Version 1.0 Page 1 of 19
Public Material – May be reproduced only in its original entirety (without revision).
FIPS 140-3 Non-Proprietary Security Policy
Motorola Solutions Cryptographic
Firmware Module
Firmware Version: R01.13.00
Document Version: 1.0
Date: July 16, 2024
Prepared by:
www.acumensecurity.net
Motorola Solutions, Inc. © 2024 Version 1.0 Page 2 of 19
Public Material – May be reproduced only in its original entirety (without revision).
Introduction
Federal Information Processing Standards Publication 140-3 — Security Requirements for Cryptographic
Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but Unclassified
environment. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber
Security (CCCS) Cryptographic Module Validation Program (CMVP) run the FIPS 140 program. The NVLAP
accredits independent testing labs to perform FIPS 140 testing; the CMVP validates modules meeting FIPS
140 validation. Validated is the term given to a module that is documented and tested against the FIPS
140 criteria.
More information is available on the CMVP website at:
https://csrc.nist.gov/projects/cryptographic-module-validation-program
About this Document
This non-proprietary Cryptographic Module Security Policy for the Motorola Solutions Cryptographic
Firmware Module provides an overview of the product and a high-level description of how it meets the
overall Level 1 security requirements of FIPS 140-3.
The Motorola Solutions Cryptographic Firmware Module may also be referred to as the “module” in this
document.
Disclaimer
The contents of this document are subject to revision without notice due to continued progress in
methodology, design, and manufacturing. Motorola Solutions, Inc. shall have no liability for any error or
damages of any kind resulting from the use of this document.
Notices
This document may be freely reproduced and distributed in its entirety without modification.
Motorola Solutions, Inc. © 2024 Version 1.0 Page 3 of 19
Public Material – May be reproduced only in its original entirety (without revision).
Table of Contents
Introduction................................................................................................................................................ 2
Disclaimer ................................................................................................................................................... 2
Notices........................................................................................................................................................ 2
1. General ............................................................................................................................................... 4
2. Cryptographic Module Specification................................................................................................... 5
2.1 Modes of Operation.................................................................................................................... 5
2.2 Cryptographic Functionality........................................................................................................ 6
2.3 Module Description and Cryptographic Boundary...................................................................... 7
2.4 Security Rules and Guidance....................................................................................................... 8
3. Cryptographic Module Interfaces ....................................................................................................... 8
4. Roles, Services, and Authentication.................................................................................................... 9
5. Software/Firmware Security ............................................................................................................. 12
6. Operational Environment ................................................................................................................. 12
7. Physical Security ............................................................................................................................... 12
8. Non-invasive Security........................................................................................................................ 13
9. Sensitive Security Parameters Management .................................................................................... 13
10. Self-Tests........................................................................................................................................... 15
10.1 Automatic Self-Test................................................................................................................... 15
10.2 Operator Initiated Self-Test....................................................................................................... 16
11. Life-Cycle Assurance ......................................................................................................................... 16
12. Mitigation of Other Attacks .............................................................................................................. 17
References and Definitions....................................................................................................................... 18
List of Tables
Table 1 – Security Levels............................................................................................................................. 4
Table 2 – Tested Operational Environments............................................................................................... 5
Table 3 – Vendor Affirmed Operational Environments............................................................................... 5
Table 4 – Approved Algorithms................................................................................................................... 7
Table 5 – Non-Approved Algorithms Allowed in the Approved Mode of Operation................................... 7
Table 6 – Non-Approved Algorithms Not Allowed in the Approved Mode of Operation............................ 7
Table 7 – Ports and Interfaces .................................................................................................................... 9
Table 8 – Roles, Service Commands, Input and Output ............................................................................ 10
Table 9 – Approved Services..................................................................................................................... 12
Table 10 – Non-Approved Services ........................................................................................................... 12
Table 11 – SSP’s ........................................................................................................................................ 15
Table 12 – Non-Deterministic Random Number Generator Specification ................................................ 15
List of Figures
Figure 1 – Logical cryptographic boundary and physical boundary ............................................................ 8
Motorola Solutions, Inc. © 2024 Version 1.0 Page 4 of 19
Public Material – May be reproduced only in its original entirety (without revision).
1. General
This document defines the cryptographic module security policy for the Motorola Solutions Cryptographic
Firmware Module (Firmware version: R01.13.00), also referred to as the “module” hereafter. The module
is a multichip standalone embodiment. It contains specification of the security rules, under which the
cryptographic module operates, including the security rules derived from the requirements of the FIPS
140-3 standard.
The following table lists the level of validation for each area in FIPS 140-3:
ISO/IEC 24759
Section 6.
FIPS 140-3 Section Title Security Level
1 General 1
2 Cryptographic Module Specification 1
3 Cryptographic Module Interfaces 1
4 Roles, Services, and Authentication 1
5 Software/Firmware Security 1
6 Operational Environment 1
7 Physical Security 1
8 Non-invasive Security N/A
9 Sensitive Security Parameter Management 1
10 Self-Tests 1
11 Life-Cycle Assurance 1
12 Mitigation of Other Attacks N/A
Table 1 – Security Levels
Motorola Solutions, Inc. © 2024 Version 1.0 Page 5 of 19
Public Material – May be reproduced only in its original entirety (without revision).
2. Cryptographic Module Specification
The module is a firmware-based cryptographic module that runs on a Motorola Solutions, Inc. radio
hardware platform. The module provides FIPS 140-3 approved cryptographic functionalities via an
Application Programming Interface (API) to the application layer running in Motorola Solutions, Inc. radio
products supporting the APCO Project 25 standard.
The module is intended for use by the markets that require FIPS 140-3 validated overall Security Level 1.
A unique binary is generated for each operating system. The following operating environments have been
tested for this validation:
# Operating
System
Hardware
Platform
Processor PAA/Acceleration
1 Mentor Graphics
Nucleus 3.0
(version 2013.08.1)
Texas Instrument
(TI) OMAP-L138
C6000 DSP+ARM
ARM926EJ-S N/A
2 Texas Instrument
(TI) DSP/BIOS
(version 5.41.04.18)
Texas Instrument
(TI) OMAP-L138
C6000 DSP+ARM
TMS320C674x N/A
Table 2 – Tested Operational Environments
The module has also been confirmed by Motorola Solutions, Inc. to be operational on the following OE
shown in Table 3. However, no target testing was performed on this platform for the FIPS 140-3 validation
with the specific firmware version listed in this document. Note: The CMVP makes no statement as to the
correct operation of the module on the operational environments for which operational testing was not
performed.
# Operating System Hardware Platform
1 Enea OSE, Version 5.8 Motorola Solutions GRV 8000
Comparator, NXP QorIQ P1021
Table 3 – Vendor Affirmed Operational Environments
2.1 Modes of Operation
The module operates in two different modes of operation.
• Approved mode: DES Encrypt/Decrypt are blocked. All services listed in Table 9 are available
when the module is operating in Approved mode.
• non-Approved mode: All services listed in Table 9 and Table 10 are available when the module
is operating in non-Approved mode.
The module defaults to the Approved mode at the initial power-up and will transition between Approved
Mode and non-Approved mode by using the “Configure Approved Mode” service. The operator can
configure the mode of the module by using the “Configure Approved Mode” Service listed in Table 9. The
“Configure Approved Mode” services sets an Approved mode flag via the API. The Approved mode flag is
“fips_mode = 1” in the Approved mode and the non-Approved mode flag is “fips_mode = 0”. The operator
shall zeroize all CSPs by power cycling the module when transitioning between Approved and non-
Approved modes. The operator must retain control of the module while zeroization is in process.
Motorola Solutions, Inc. © 2024 Version 1.0 Page 6 of 19
Public Material – May be reproduced only in its original entirety (without revision).
2.2 Cryptographic Functionality
The module’s supported cryptographic functions are listed in the following tables:
CAVP
Cert #
Algorithm and
Standard
Mode/Method Description /
Key Size(s) /
Key Strength(s)
Use / Function
A2228
AES [FIPS 197]
CBC [SP 800-38A] Key Size: 256 Encrypt, Decrypt
ECB [SP 800-38A] Key Size: 256 Encrypt, Decrypt
GCM [SP 800-38D]1
Key Size: 256 Encrypt, Decrypt
KW [SP 800-38F] Key Size: 256 Encrypt, Decrypt
OFB [SP 800-38A] Key Size: 256 Encrypt, Decrypt
DRBG [SP800-90Ar1] CTR AES-256
Deterministic Random
Bit Generation
ECDSA [FIPS 186-4] P-384
Key Generation,
Supported only on OE
#1.
HMAC [FIPS 198-1] HMAC-SHA2-384
(1024 bit)
Message
authentication, Code
Integrity tests
KAS-ECC [SP 800-
56Ar3]
ECC (Initiator,
Responder), Key
pair generation,
Partial public key
validation, One-
step key derivation
P-384 with SHA2-
256
Key Establishment
provides 192 bits of
encryption strength,
Supported only on
OE#1
P-384 with SHA2-
384
P-384 with SHA2-
512
KTS [IG D.G] AES-KW Key Size: 256
Key Wrap provides 256
bits of encryption
strength
KTS [IG D.G] GCM Key Size: 256
Key Wrap provides 256
bits of encryption
strength
PBKDF [SP 800-132]
Option 1a
Option 2a (using
HMAC)
sLen = 16 – 512
bytes
C = 1 – 5000
SHA2-256, SHA2-
384, SHA2-512
Password-Based Key
Derivation. Supported
only on OE #1.
SHS [FIPS 180-4]
SHA2-256
SHA2-384
SHA2-512
N/A
Message Digest
Generation, Password
Obfuscation
Vendor
Affirmed
CKG CTR_DRBG N/A
Symmetric key and
asymmetric key seed
1
Per IG C.H option 2, the module generates 96-bit GCM IVs randomly as specified in SP800-38D section 8.2.2 using
an approved DRBG (Cert. #A2228), that is internal to the module’s boundary.
Motorola Solutions, Inc. © 2024 Version 1.0 Page 7 of 19
Public Material – May be reproduced only in its original entirety (without revision).
CAVP
Cert #
Algorithm and
Standard
Mode/Method Description /
Key Size(s) /
Key Strength(s)
Use / Function
generation in
accordance with SP
800-133rev2 sections
5.2, 6.1 and 6.2 and IG
D.H with B=U.2
Table 4 – Approved Algorithms
Algorithm Caveat Use / Function
AES MAC3
[IG D.C] AES MAC for Project 25
APCO OTAR (Cert. #A2228)
Table 5 – Non-Approved Algorithms Allowed in the Approved Mode of Operation
Algorithm/Function Use/Function
DES DES Encryption/Decryption – ECB, OFB and CBC
Mode.
Table 6 – Non-Approved Algorithms Not Allowed in the Approved Mode of Operation
The module does not support Non-Approved Allowed Algorithms with No Security Claimed.
2.3 Module Description and Cryptographic Boundary
The module is classified by FIPS 140-3 as a firmware module, with a multi-chip standalone module
embodiment. The physical perimeter is the Motorola Solutions, Inc. Radio Platform on which the module
is installed. The logical perimeter and cryptographic boundary of the module is the static linked library
that is linked into the application running on Motorola Solutions, Inc. radio products.
2
PBKDF salt, GCM IV, and ECDH private key
3
AES-CBC-MAC is allowed for use within OTAR until November 1, 2023.
Motorola Solutions, Inc. © 2024 Version 1.0 Page 8 of 19
Public Material – May be reproduced only in its original entirety (without revision).
Figure 1 – Logical cryptographic boundary and physical boundary
2.4 Security Rules and Guidance
The module enforces the following security rules:
1. The module does not support any operator authentication.
2. The module is available to perform services only after successfully completing the pre-operational
self-tests.
3. Data output is inhibited during pre-operational self-tests, zeroization, and while in an error state.
4. The module shall not support concurrent operators.
5. The module enters the uninitialized state if any pre-operational self-test fail. The uninitialized
state can be exited by restarting the module allowing the module to attempt to re-initialize itself.
6. If the module enters a soft error state, the error condition may be cleared by executing the
Operator Initiated Self-Test service documented in Section 11.2 or power cycling the module.
7. The module can perform periodic self-tests. An operator can perform periodic self-tests on
demand by using the Operator Initiated Self-Test API or power cycle.
8. The module does not perform any cryptographic functions while in the uninitialized state.
9. The module returns the results of the pre-operational self-tests to the operator.
10. The module may be power cycled to zeroize all CSPs.
11. The module is to be installed on Motorola Solutions radio products.
12. The operator may choose whether the module will run in the Approved mode or non-Approved
mode using the “Configure Approved Mode” Service.
3. Cryptographic Module Interfaces
The Module’s logical interfaces are described in Table 7:
Logical Perimeter
Motorola Solutions, Inc. © 2024 Version 1.0 Page 9 of 19
Public Material – May be reproduced only in its original entirety (without revision).
Physical Port Logical interface Data that passes over port/interface
1 Data input API entry point data input stack parameters
2 Data output API entry point data output stack parameters
3 Control input API entry point and corresponding stack parameters
4 Status output API entry point return values and status stack
parameters
Table 7 – Ports and Interfaces
The module does not support a control output interface.
4. Roles, Services, and Authentication
The module supports the Cryptographic Officer (CO) role and does not support authentication. An
operator is considered the owner of the thread that instantiates the module and, therefore, only one
concurrent operator is allowed.
Role Service Input Output
CO
Self-Test
Power-up/Run Self-Test
command
Status: Success/Error
CO Load Entropy Entropy Input String N/A
CO
Get Module Status
Get module status
command
Module initialization
status, Approved mode
status
CO
Get Module Version
Get module version
command
“libALG Library R01.13.00 –
Copyright 2021 Motorola
Solutions, Inc.”
CO
Configure Approved
Mode
Approved mode
enabled/Approved mode
disabled
Enable/Disable
CO
Utility
Module query for
algorithm/key status
Algorithm/key status
information
CO Encrypt Encryption key, plaintext Ciphertext or error status
CO Decrypt Decryption key, ciphertext Plaintext or error status
CO AES Key Wrapping Encryption key, input data Wrapped key
CO AES Key Unwrapping Decryption key, input data Unwrapped data
CO Generate OTAR MAC Input data MAC Key
CO DRBG Entropy input data Pseudo-random number
CO Hashing Hash algorithm, input data Hashed output
CO HMAC-SHA Hash Key, input data digest
CO Zeroize N/A N/A
CO
PBKDF
Password, iteration count,
salt, hash algorithm
Derived key
Motorola Solutions, Inc. © 2024 Version 1.0 Page 10 of 19
Public Material – May be reproduced only in its original entirety (without revision).
Role Service Input Output
CO ECDSA Key Gen Private key Private key/Public key
CO KAS-ECC Private key, Public Key of
Remote Party (Host B)
ECDH Shared Secret/KDF
Derived Key
Table 8 – Roles, Service Commands, Input and Output
The SSPs modes of access shown in Table 9, are defined as:
• G = Generate: The Module generates or derives the SSP.
• R = Read: The SSP is read from the Module (e.g. the SSP is output).
• W = Write: The SSP is updated, imported, or written to the Module.
• E = Execute: The Module uses the SSP in performing a cryptographic operation.
• Z = Zeroize: The Module zeroizes the SSP
Service Description Approved
Security
Functions
Keys and/or
SSPs
Roles Access rights
to Keys and/or
SSPs
Indicator
Self-Test
Automatic: See
section 10.1
N/A N/A CO N/A ”fips_mode = 1”
Operator
Initiated: See
section 10.2
Load
Entropy
Load external
entropy to seed
the DRBG
N/A Entropy
Input string
CO W,E,Z ”fips_mode = 1”
Get Module
Status
Show the module
status
N/A N/A CO N/A ”fips_mode = 1”
Get Module
Version
Get module
version number
N/A N/A CO N/A ”fips_mode = 1”
Configure
Approved
Mode
Set/Unset module
to Approved
mode
N/A N/A CO N/A ”fips_mode = 1”
Utility
Key check and
other services
N/A N/A CO N/A ”fips_mode = 1”
Encrypt
Encryption of
voice and data
AES AES-256 Key CO W,E,Z ”fips_mode = 1”
Decrypt
Decryption of
voice and data
AES AES-256 Key CO W,E,Z ”fips_mode = 1”
AES Key
Wrapping
Used for the
encryption of
keys.
KTS (AES-
KW or AES-
GCM)
AES-256 Key
Wrap Key
CO W,E,Z ”fips_mode = 1”
AES Key
Unwrapping
Used for the
decryption of
keys.
KTS (AES-
KW or AES-
GCM)
AES-256 Key
Wrap Key
CO W,E,Z ”fips_mode = 1”
Motorola Solutions, Inc. © 2024 Version 1.0 Page 11 of 19
Public Material – May be reproduced only in its original entirety (without revision).
Service Description Approved
Security
Functions
Keys and/or
SSPs
Roles Access rights
to Keys and/or
SSPs
Indicator
Generate
OTAR MAC
Used to generate
MAC (Message
Authentication
Code) as defined
in [OTAR].
AES MAC OTAR MAC
Key
CO W,E,Z ”fips_mode = 1”
DRBG
Used for random
number, IV and
key generation
using DRBG [SP
800-90Ar1].
DRBG
(output
directly
used for
CKG)
CKG
Entropy
Input string/
SP 800-
90Ar1 Seed/
SP 800-
90Ar1
Internal
State (“V”
and “Key”)
CO G,R,W ”fips_mode = 1”
Hashing
Used to generate
SHA2-
256/384/512
message digest.
SHS N/A CO N/A ”fips_mode = 1”
HMAC-SHA
Used to calculate
data integrity
codes with HMAC.
HMAC Keyed Hash
Key
CO W,E ”fips_mode = 1”
Zeroize4 Zeroize all SSPs N/A All CO Z ”fips_mode = 1”
PBKDF5
Used to generate
keys using PBKDF
[SP 800-132]
PBKDF PBKDF
Secret Value
DPK
CO W,E
G,R
”fips_mode = 1”
ECDSA Key
Gen
Used for
generating
asymmetric key
pair
ECDSA ECDSA
Private Key,
ECDSA
Public Key
CO G,R ”fips_mode = 1”
KAS-ECC Used for key
agreement
process using
ECDH
KAS-ECC ECDH
Shared
Secret, KDF
Derived Key,
ECDH
Private Key,
ECDH Public
CO G,R,W,E ”fips_mode = 1”
4
The Zeroize service zeroizes the key in the volatile memory by power cycling the module.
5
As per NIST SP 800-132, keys generated by the module shall be used as recommend in Section 5.4 of [132]. Any
other use of the approved PBKDF is non‐conformant. In approved mode the operator shall enter a password no less
than 8 hexadecimal digits in length. The probability of guessing the password will be equal to 1:168
. Due to the
computational limitations of this embedded operational environment, the iteration count associated with the PBKDF
should not exceed 5000. The minimum iteration count is 1, however it shall be selected as large as possible. Keys
derived from passwords may only be used in storage applications.
Motorola Solutions, Inc. © 2024 Version 1.0 Page 12 of 19
Public Material – May be reproduced only in its original entirety (without revision).
Service Description Approved
Security
Functions
Keys and/or
SSPs
Roles Access rights
to Keys and/or
SSPs
Indicator
Key, ECDH
Remote
Party Public
Key
Table 9 – Approved Services
Service Description Algorithms
Accessed
Role Indicator
Encrypt Encryption of
voice and data
DES CO ”fips_mode = 0”
Decrypt Decryption of
voice and data
DES CO ”fips_mode = 0”
Table 10 – Non-Approved Services
5. Software/Firmware Security
The module consists of firmware in the form of a statically linked library. The firmware components are
protected and authenticated using an HMAC hash function using the keyed hash key referenced in Table
11. The operator can initiate the firmware integrity test (HMAC-SHA2-384) on demand by power cycling
the radio. If the integrity test fails, the module will not initialize and no security functions will be provided
by the module.
6. Operational Environment
The module operates and was tested on the following non-modifiable operational environment:
Motorola Solutions, Inc. Radio using hardware platform as specified in Table 2.
As per ISO/IEC 19790:2012 7.6.3:
• The cryptographic module has control over its own SSPs.
• The operational environment provides the capability to separate individual application processes
from each other to prevent uncontrolled access to CSPs and uncontrolled modifications of SSPs,
regardless if this data is in the process memory or stored on persistent storage within the
operational environment. This ensures that direct access to CSPs and SSPs is restricted to the
cryptographic module and the trusted parts of the operational environment.
• The module operates in a non-modifiable operational environment, therefore no restrictions or
modifications to the configuration of the operational environment are possible.
• Processes that are spawned by the cryptographic module are owned by the module and are not
owned by external processes/operators.
7. Physical Security
The module is a firmware module and operates in a Motorola Solutions, In. radio that is built with
production grade materials that include standard passivation techniques. For the purposes of FIPS 140-
Motorola Solutions, Inc. © 2024 Version 1.0 Page 13 of 19
Public Material – May be reproduced only in its original entirety (without revision).
3, the embodiment is defined as multiple-chip standalone and is designed to meet Level 1 security
requirements.
8. Non-invasive Security
Not Applicable. The module does not implement non-invasive security measures.
9. Sensitive Security Parameters Management
Key/SSP
Name/Type
Strength
Security
Function
and
Cert.
Number
Generation
Import/Export
Establishment
Storage
Zeroisation
Use
&
related
keys
Entropy
Input
string
Variable
(384-bit
minimum)
N/A External Import
(electr
onic)
Input via
API in
plaintext
Volatile
memory
(plaintext)
Power
Cycle/Reset
Used to
derived SP
800-90Ar1
seed
SP 800-
90Ar1
Seed
384-bit DRBG
(A2228)
Internal N/A N/A Volatile
memory
(plaintext)
Power
Cycle/Reset
Derived
from the
Entropy
Input
string.
Used in
AES IV,
ECDSA
Private
Key, and
ECDH
Private Key
generation
SP 800-
90Ar1
Internal
State
(“V” and
“Key”)
N/A DRBG
(A2228)
CKG
Internal N/A N/A Volatile
memory
(plaintext)
Power
Cycle/Reset
CTR_DRBG
state
Keyed
Hash
Key
Variable
(192-bit
minimum)
HMAC
(A2228)
External Import
(electr
onic)
Input via
API in
plaintext
Volatile
memory
(plaintext)
Power
Cycle/Reset
Used in
HMAC
function
AES-256
Key
256-bit AES
(A2228)
External Import
(electr
onic)
Input via
API in
plaintext
Volatile
memory
(plaintext)
Power
Cycle/Reset
/End of
data
processing
Used in
data
encryption
/
decryption
Motorola Solutions, Inc. © 2024 Version 1.0 Page 14 of 19
Public Material – May be reproduced only in its original entirety (without revision).
Key/SSP
Name/Type
Strength
Security
Function
and
Cert.
Number
Generation
Import/Export
Establishment
Storage
Zeroisation
Use
&
related
keys
AES-256
Key
Wrap
Key
256-bit KTS
(A2228)
External Import
(electr
onic)
Input via
API in
plaintext
Volatile
memory
(plaintext)
Power
Cycle/Reset
/End of
data
processing
Used in key
encryption
/
decryption
PBKDF
Secret
Value
Variable
(64-bit
minimum
)
PBKDF
(A2228)
External
6
Import
(electr
onic)
Input via
API in
plaintext
Volatile
memory
(plaintext)
Power
Cycle/Reset
Used in
Key
Derivation
DPK 128-bit
minimum
PBKDF
(A2228)
Internal Export
(electr
onic)
Internally
computed
Volatile
memory
(plaintext)
Power
Cycle/Reset
Derived by
the PBKDF
using the
PBKDF
Secret
Value
OTAR
MAC
Key
256-bit AES
MAC
External Import
(electr
onic)
Input via
API in
plaintext
Volatile
memory
(plaintext)
Power
Cycle/Reset
Used for
AES MAC
ECDH
Private
Key
192-bit KAS-
ECC
(A2228)
External
or
Internal
Import
(electr
onic)
Input via
API in
plaintext
Volatile
memory
(plaintext)
Power
Cycle/Reset
Used to
generate
ECDH
Public Key
ECDH
Shared
Secret
192-bit KAS-
ECC
(A2228)
Internal Export
(electr
onic)
Internally
computed
Volatile
memory
(plaintext)
Power
Cycle/Reset
Used to
generate
KDF
derived
key
ECDSA
Private
Key
192-bit ECDSA
(A2228)
External
or
Internal
Import
or
Export
(electr
onic)
Input via
API in
plaintext
Volatile
memory
(plaintext)
Power
Cycle/Reset
Used for
ECDSA
KDF
Derived
Key
Variable
(128-bit
minimum)
KAS-
ECC
(A2228)
Internal Export
(electr
onic)
Internally
computed
Volatile
memory
(plaintext)
Power
Cycle/Reset
Used in
KAS-ECC
ECDH
Public
Key
192-bit KAS-
ECC
(A2228)
Internal Export
(electr
onic)
Internally
computed
Volatile
memory
(plaintext)
Power
Cycle/Reset
Used in key
exchange
6
Password generated externally. Salt may be generated externally or internally according to SP 800-133.
Motorola Solutions, Inc. © 2024 Version 1.0 Page 15 of 19
Public Material – May be reproduced only in its original entirety (without revision).
Key/SSP
Name/Type
Strength
Security
Function
and
Cert.
Number
Generation
Import/Export
Establishment
Storage
Zeroisation
Use
&
related
keys
ECDH
Remote
Party
Public
Key
192-bit KAS-
ECC
(A2228)
External Import
(electr
onic)
Input via
API in
plaintext
Volatile
memory
(plaintext)
Power
Cycle/Reset
Used in key
exchange
ECDSA
Public
Key
192-bit ECDSA
(A2228)
Internal Export
(electr
onic)
Internally
computed
Volatile
memory
(plaintext)
Power
Cycle/Reset
Used for
ECDSA
Table 11 – SSPs
Entropy sources Minimum number of bits of
entropy
Details
Entropy Input String 384 (minimum seed length
for AES-256 CTR_DRBG)
The entropy for seeding the SP 800-90Ar1
DRBG is determined by the user operator of
the module which is outside of the module’s
cryptographic boundary. To be compliant, the
target application shall supply at least 384 bits
of entropy in order to meet the security
strength required for the random number
generation mechanism as shown in [SP 800-
90Ar1] Table 3 (CTR_DRBG) and set required
bits into the module by calling module defined
API function. Since entropy is loaded passively
into the module, there is no assurance of the
minimum strength of generated keys.
Table 12 – Non-Deterministic Random Number Generator Specification
10. Self-Tests
10.1 Automatic Self-Test
The module automatically performs pre-operational self-tests and conditional cryptographic algorithm
self-tests. Automatic pre-operational self-tests are initiated upon module power-up and must pass in
order for the module to initialize and render any security services. A failure of any pre-operational self-
test will prevent the module from initializing. Automatic conditional cryptographic algorithm self-tests
(CAST) will run prior to the first use of a security service using an approved cryptographic algorithm after
module initialization. Failure of a conditional CAST will cause the module to enter the soft error state and
return an error to the operator of the module.
a) Pre-Operational Self-Tests
o Firmware integrity test: HMAC-SHA2-384 (HMAC-SHA2-384 CAST done prior to integrity test)
Motorola Solutions, Inc. © 2024 Version 1.0 Page 16 of 19
Public Material – May be reproduced only in its original entirety (without revision).
b) Conditional Self-Tests
1) Conditional cryptographic algorithm test
o SHA2-256 CAST
o SHA2-512 CAST
o HMAC-SHA2-384 CAST
o AES ECB Encrypt CASTs (256-bit key)
o AES ECB Decrypt CASTs (256-bit key)
o AES GCM Encrypt CASTs (256-bit key)
o AES GCM Decrypt CASTs (256-bit key)
o CTR_DRBG [SP 800-90Ar1] CAST (Instantiate, Generate, and Reseed)
o AES-KW [SP 800-38F] Wrap/Unwrap CASTs
o KAS ECC [SP 800-56ar3] CAST
o KDF [SP 800-56Arev3] CAST (SHA2-256, SHA2-384, SHA2-512)
o PBKDF [SP 800-132] CAST (128-bit key, 128-bit salt, 2 iterations)
2) Conditional pair-wise consistency test
o ECDSA Key Gen PCT (384-bit private key, 384-bit public key)
10.2 Operator Initiated Self-Test
Self-tests can also be initiated by calling the “Self-Test” service via the API. Operator initiated self-tests via
the API can only be invoked after the module has initialized. When initiating self-test via API call, the
following tests are performed:
• SHA2-256 CAST
• SHA2-512 CAST
• HMAC-SHA2-384 CAST
• AES ECB Encrypt CASTs (256-bit key)
• AES ECB Decrypt CASTs (256-bit key)
• AES GCM Encrypt CASTs (256-bit key)
• AES GCM Decrypt CASTs (256-bit key)
• CTR_DRBG [SP 800-90Ar1] CAST (Instantiate, Generate, and Reseed)
• AES-KW [SP 800-38F] Wrap CAST
• AES-KW [SP 800-38F] Unwrap CAST
• KAS ECC [SP 800-56ar3] CAST
• KDF [SP 800-56Arev3] CAST (SHA2-256, SHA2-384, SHA2-512)
• PBKDF [SP 800-132] CAST (128-bit key, 128-bit salt, 2 iterations)
• ECDSA Key Gen PCT (384-bit private key, 384-bit public key)
Failure of any of the self-test initiated by calling the “Self-Test” service via the API will render the module
inoperable.
11. Life-Cycle Assurance
The cryptographic module is not installed, but it is a static library linked to the application at
compile time. The operator shall configure the module to operate in approved mode as specified
in Section 2.1. After end-of-life for the module, the operator shall zeroize all SSPs used by the
module by removing power to the radio using the module.
Motorola Solutions, Inc. © 2024 Version 1.0 Page 17 of 19
Public Material – May be reproduced only in its original entirety (without revision).
12. Mitigation of Other Attacks
Not Applicable. The Module does not implement mitigations of other attacks outside the scope of FIPS
140-3.
Motorola Solutions, Inc. © 2024 Version 1.0 Page 18 of 19
Public Material – May be reproduced only in its original entirety (without revision).
References and Definitions
Abbreviation Full Specification Name
[FIPS 140-3] Security Requirements for Cryptographic Modules, March 2019
[IG] Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation
Program, November 2021.
[SP 800-132] NIST Special Publication 800-132, Recommendation for Password-Based Key Derivation,
Part 1: Storage Applications, December 2010
[FIPS 186-4] National Institute of Standards and Technology, Digital Signature Standard (DSS),
Federal Information Processing Standards Publication 186-4, July 2013.
[FIPS 197] National Institute of Standards and Technology, Advanced Encryption Standard (AES),
Federal Information Processing Standards Publication 197, November 2001
[FIPS 198-1] National Institute of Standards and Technology, The Keyed-Hash Message
Authentication Code (HMAC), Federal Information Processing Standards Publication 198-
1, July 2008
[FIPS 180-4] National Institute of Standards and Technology, Secure Hash Standard, Federal
Information Processing Standards Publication 180-4, August 2015
[SP 800-38A] National Institute of Standards and Technology, Recommendation for Block Cipher
Modes of Operation, Methods and Techniques, Special Publication 800-38A, December
2001
[SP 800-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
[SP 800-38F] National Institute of Standards and Technology, Recommendation for Block Cipher
Modes of Operation: Methods for Key Wrapping, Special Publication 800-38F, December
2012
[SP 800-56Ar3] NIST Special Publication 800-56A Revision 3, Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography, April 2018
[SP 800-56Cr2] NIST Special Publication 800-56C Revision 2, Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography, August 2020
[SP 800-90Ar1] 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 [TIA-
102.AACA-A], September 2014
Acronym Definition
AES Advanced Encryption Standard
APCO Association of Public-Safety Communications Officials
CBC Cipher Block Chaining
CKG Cryptographic Key Generation
CSP Critical Security Parameter
DRBG Deterministic Random Bit Generator
ECB Electronic Code Book
ECDH Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Diffie-Hellman
Motorola Solutions, Inc. © 2024 Version 1.0 Page 19 of 19
Public Material – May be reproduced only in its original entirety (without revision).
FIPS Federal Information Processing Standards
GCM Galois/Counter Mode
HMAC Hash-based Message Authentication Code
IV Initialization Vector
KAT Known Answer Test
KDA Key Derivation Algorithm
MAC Message Authentication Code
OFB Output Feedback
OTAR Over The Air Rekeying
PBKDF Password-Based Key Derivation Function
PCT Pairwise Consistency Test
SSP Sensitive Security Parameter