Copyright Motorola Solutions, Inc, 2018 Page 1 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
Non‐Proprietary Security Policy:
μMACE
Cryptographic module for the Motorola Solutions CRYPTR Micro which is used in the AME
product line
Version: R01.07.07
Date: April 18, 2018
Copyright Motorola Solutions, Inc, 2018 Page 2 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
Table of Contents
1. INTRODUCTION............................................................................................................................................................... 4
1.1. SCOPE............................................................................................................................................................................. 4
1.2. DEFINITIONS................................................................................................................................................................ 4
1.3. OVERVIEW ................................................................................................................................................................... 4
1.4. µMACE IMPLEMENTATION..................................................................................................................................... 4
1.5. µMACE HARDWARE / FIRMWARE VERSION NUMBERS................................................................................. 5
1.6. µMACE CRYPTOGRAPHIC BOUNDARY ............................................................................................................... 5
THE CRYPTO BOUNDARY IS DRAWN AROUND THE µMACE AS SHOWN BELOW................................................ 6
1.7. PORTS AND INTERFACES......................................................................................................................................... 7
2. FIPS 140-2 SECURITY LEVELS...................................................................................................................................... 8
3. FIPS 140-2 APPROVED OPERATIONAL MODES....................................................................................................... 9
3.1. CONFIGURATION SETTINGS FOR OPERATION AT FIPS 140-2 OVERALL SECURITY LEVEL 3 .......... 9
3.2. NON APPROVED MODE OF OPERATION ........................................................................................................... 10
4. CRYPTO OFFICER AND USER GUIDANCE ............................................................................................................. 11
4.1. ADMINISTRATION OF THE µMACE IN A SECURE MANNER (CO).............................................................. 11
4.2. ASSUMPTIONS REGARDING USER BEHAVIOR (CO)...................................................................................... 11
4.3. APPROVED SECURITY FUNCTIONS, PORTS, AND INTERFACES AVAILABLE TO USERS................... 11
4.4. USER RESPONSIBILITIES NECESSARY FOR SECURE OPERATION........................................................... 11
5. SECURITY RULES.......................................................................................................................................................... 12
5.1. FIPS 140-2 IMPOSED SECURITY RULES.............................................................................................................. 12
6. IDENTIFICATION AND AUTHENTICATION POLICY........................................................................................... 15
7. PHYSICAL SECURITY POLICY .................................................................................................................................. 17
8. AES-256 GCM NON-INTERNAL IV GENERATION PROTOCOL.......................................................................... 18
9. ACCESS CONTROL POLICY........................................................................................................................................ 19
9.1. µMACE SUPPORTED ROLES.................................................................................................................................. 19
9.2. µMACE SERVICES AVAILABLE TO THE USER ROLE VIA SDIO INTERFACE......................................... 19
Copyright Motorola Solutions, Inc, 2018 Page 3 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
9.3. µMACE SERVICES AVAILABLE TO THE USER ROLE VIA KVL INTERFACE.......................................... 20
9.4. µMACE SERVICES AVAILABLE TO THE CRYPTO-OFFICER ROLE........................................................... 20
9.5. µMACE SERVICES AVAILABLE WITHOUT A ROLE. ...................................................................................... 20
9.6. CRITICAL SECURITY PARAMETERS (CSPS) AND PUBLIC KEYS ............................................................... 21
9.7. CSP ACCESS TYPES.................................................................................................................................................. 27
10. MITIGATION OF OTHER ATTACKS POLICY......................................................................................................... 31
Copyright Motorola Solutions, Inc, 2018 Page 4 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
1. Introduction
1.1. Scope
This Security Policy specifies the security rules under which the µMACE must operate. In addition
to the security requirements derived from FIPS 140-2 are those imposed by Motorola Solutions.
These rules, in total, define the interrelationship between the:
 Module Operators,
 Module Services, and
 Critical Security Parameters (CSPs).
1.2. Definitions
CBC Cipher Block Chaining
CFB Cipher Feedback
CSP Critical Security Parameter
DES Data Encryption Standard
DRBG Deterministic Random Bit Generator
ECB Electronic Code Book
ECDH Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
ECMQV Elliptic Curve Menezes-Qu-Vanstone
IKE Internet Key Exchange
IPSec Internet Protocol security
IV Initialization Vector
KLK Key Loss Key
KPK Key Protection Key
KVL Key Variable Loader
LED Light-emitting diode
OTAR Over The Air Rekeying
PEK Password Encryption Key
RAM Random Access Memory
RNG Random Number Generator
1.3. Overview
The µMACE provides secure key management and data encryption for the Motorola Solutions
CRYPTR Micro which is used in the following broadband and LTE Systems:
 ES400 phone
 AME2000 line of secure phones
 MCC7100 Dispatch Console
1.4. µMACE Implementation
The µMACE is implemented as a single chip cryptographic module as defined by FIPS 140-2.
Copyright Motorola Solutions, Inc, 2018 Page 5 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
1.5. µMACE Hardware / Firmware Version Numbers
The µMACE has the following FIPS validated hardware and firmware version numbers:
Table 1: FIPS Validated Version Numbers
FIPS Validated Cryptographic
Module Hardware Kit
Numbers
FIPS Validated Cryptographic
Module Firmware Version
Numbers
AT58Z04 R01.07.01, R01.07.05
1.6. µMACE Cryptographic Boundary
The µMACE in the block diagram below provides data security services required by the CRYPTR
Micro product. The module is a single µMACE processor with the set of interfaces shown in the
diagram below.
Figure 1: µMACE Block Diagram
Copyright Motorola Solutions, Inc, 2018 Page 6 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
The Crypto Boundary is the µMACE chip as shown below.
Figure 2: µMACE
Copyright Motorola Solutions, Inc, 2018 Page 7 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
1.7. Ports and Interfaces
The µMACE provides the following physical ports and logical interfaces:
Table 3: Ports and Interfaces
Physical
Port
Qty
Logical interface
definition
Description
Power 1 Power Input
This interface powers all circuitry.
This interface does not support input / output of CSP’s.
Clock 1 Control Input
Clock Input.
This interface does not support input / output of CSP’s.
Tamper 1 Control Input
Tamper Input.
This interface does not support input / output of CSP’s.
Self-test
Status
Indicator
1 Status Output
This interface provides status output to indicate all power-up self-tests
completed successfully.
Reset 1 Control Input This interface forces a reset of the module.
SDIO
Interface
1
Control Input
Status Output
Data Output
Data Input
Provides an interface for factory programming and execution of SDIO
commands. All CSPs exchanged over this interface are always
encrypted when operating in FIPS approved mode.
Key Variable
Loader (KVL)
Interface
1
Control Input
Status Output
Data Output
Data Input
Provides an interface to the Key Variable Loader. The KEKs and TEKs
are entered in encrypted form over the KVL interface. All CSPs
exchanged over this interface are always encrypted when in FIPS
approved mode.
Copyright Motorola Solutions, Inc, 2018 Page 8 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
2. FIPS 140-2 Security Levels
The µMACE can be configured to operate at FIPS 140-2 overall Security Level 3. The table below
shows the FIPS 140-2 Level of security met for each of the eleven areas specified within the FIPS
140-2 security requirements.
Table 4: µMACE Security Levels
FIPS 140-2 Security Requirements
Section
Validated Level at
overall Security
Level 3
Cryptographic Module Specification 3
Module Ports and Interfaces 3
Roles, Services, and Authentication 3
Finite State Model 3
Physical Security 3
Operational Environment N/A
Cryptographic Key Management 3
EMI / EMC 3
Self-Tests 3
Design Assurance 3
Mitigation of Other Attacks N/A
Copyright Motorola Solutions, Inc, 2018 Page 9 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
3. FIPS 140-2 Approved Operational Modes
The µMACE can be configured to operate in a FIPS 140-2 Approved mode of operation and a non-
FIPS Approved mode of operation. CSPs are not shared between FIPS Approved mode and non-
FIPS Approved mode. The transition from a FIPS Approved mode to a non-FIPS Approved mode
causes all CSPs to be zeroized. In response to the Version Query service request the module will
return the following data which can be used to determine whether the module is operating at
overall Security Level 3 or in a non-FIPS Approved mode.
FIPS Status Information Item ID 0x06
FIPS Status Information Item Length 0x01
FIPS Status Information Item Data 1 byte indicating the FIPS operating status of the
module. The possible values are:
- 0x00 – Not operating in a FIPS approved
mode
- 0x03 – Operating in a FIPS 140 Level 3
approved mode
The Version Query service can also be used to verify the firmware version matches an approved
version listed on NIST’s website: http://csrc.nist.gov/groups/STM/cmvp/validation.html
3.1. Configuration Settings for operation at FIPS 140-2 overall Security Level 3
Documented below are the actions and configuration settings required for the module to be used
in a FIPS 140-2 Approved mode of operation at overall Security Level 3.
1. Disable Clear Key Import. The Module Configuration service is used to configure this
parameter in the module. When this configuration setting is disabled, clear key import will
be disallowed.
2. Disable Clear Key Export. The Module Configuration service is used to configure this
parameter in the module. When this configuration setting is disabled, clear key export will
be disallowed.
3. Disable Key Loss Key (KLK). The Module Configuration service is used to configure this
parameter in the module.
4. Disable Red Keyloading. The Module Configuration service is used to configure this
parameter in the module. When this configuration setting is disabled, red key loading via
the KVL interface will be disallowed.
5. Only Approved and Allowed algorithms installed. The module supports the following
Approved algorithms:
 AES-256 8-bit CFB (Cert. #1876) – used for symmetric encryption / decryption of
keys and parameters stored in the internal database
 AES-256 ECB (Cert. #1876) - for use with key wrap
 AES-256 CBC (Cert. #1876) - for firmware upgrades
 AES-256 CTR (Cert. #2146)
 AES-256 OFB (Cert. #2146)
 AES-256 GCM (Cert. #2146)
Copyright Motorola Solutions, Inc, 2018 Page 10 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
 AES-128 ECB (Cert. #3089)
 AES-128 CBC (Cert. #3089)
 AES-128 OFB (Cert. #3089)
 AES-128 CTR (Cert. #3089)
 AES-128/256 KW (Cert. #5360, key wrapping; key establishment methodology
provides between 128 and 256 bits of encryption strength) – used for key encryption
 SHA-384 (Cert. #1619) – used for digital signature verification during firmware
integrity test and firmware load test. Used for password hashing for internal
password storage.
 HMAC SHA-384 (Cert. #1313)
 SP800-56A KAS (Cert. #28) – (key agreement; key establishment methodology
provides 192 bits of encryption strength)
 ECDSA P-384 (Cert. #263) – used for digital signature verification during firmware
integrity test and firmware load test, and for key generation and signature generation.
The module supports the following allowed algorithms:
 AES MAC (Cert. #1876) – Used to provide authentication within APCO OTAR. AES
MAC as used within APCO OTAR has been vendor affirmed and is approved when
used for Project 25 APCO OTAR.
The following non-Approved algorithms and protocols are allowed within the Approved
mode of operation:
 Non-deterministic Hardware Random Number Generator – used for IV and key
generation. This NDRNG is NSA approved.
3.2. Non Approved Mode of Operation
A non-FIPS Approved mode of operation is transitioned to when any of the following is true:
1. Clear Key Import is enabled.
2. Clear Key Export is enabled.
3. KLK generation is enabled.
4. Red Keyloading is enabled.
It should be noted that The FIPS mode status is a persistent parameter; the module will maintain
its FIPS mode (indicating this mode to the operator upon request), until the above parameters are
changed.
Copyright Motorola Solutions, Inc, 2018 Page 11 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
4. Crypto Officer and User Guidance
4.1. Administration of the µMACE in a secure manner (CO)
The µMACE requires no special administration for secure use after it is set up for use in a FIPS
Approved manner. To do this, configure the module as described in Section 3 of this document.
Note that all keys will be zeroized after the Program Update service has completed.
4.2. Assumptions regarding User Behavior (CO)
The µMACE has been designed in such a way that no special assumptions regarding User
Behavior have been made that are relevant to the secure operation of the unit.
4.3. Approved Security Functions, Ports, and Interfaces available to Users
µMACE services available to the User role are listed in section 8.2.
No Physical Ports or Logical Interfaces are directly available to the µMACE User, only indirectly
through the host product in which the µMACE is installed.
4.4. User Responsibilities necessary for Secure Operation
To ensure the secure operation of the µMACE the operator should periodically check the module
for evidence of tamper. It is recommended that the µMACE be checked for evidence of tamper
every 6 months.
Copyright Motorola Solutions, Inc, 2018 Page 12 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
5. Security Rules
The µMACE enforces the following security rules.
5.1. FIPS 140-2 Imposed Security Rules
1. The µMACE inhibits all data output via the data output interface whenever an error state
exists and during self-tests.
2. The µMACE logically disconnects the output data path from the circuitry and processes
when performing key generation or key zeroization.
3. Authentication data (e.g., passwords) are entered in encrypted form. Authentication data
is not output during entry.
4. Secret and private cryptographic keys are entered in encrypted form.
5. The µMACE does not support manual key entry.
6. The µMACE enforces Identity-Based authentication.
7. The µMACE supports a User role (SDIO interface and KVL interface), and a Crypto-Officer
role. The module will verify the authorization of the operator to assume each role.
8. The µMACE does not support concurrent operators.
9. The µMACE re-authenticates an operator when it is powered-up after being powered-off.
10. The µMACE implements all firmware using a high-level language, except the limited use of
low-level languages to enhance performance.
11. The µMACE protects secret keys and private keys from unauthorized disclosure,
modification, and substitution.
12. The µMACE 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. Each key in
the µMACE is entered encrypted and stored with the following information:
 Key Identifier – 16 bit identifier
 Algorithm Identifier – 8 bit identifier
 Key Type – Traffic Encryption Key or Key Encryption Key
 Physical ID – Identifier indicating storage locations.
Along with the encrypted key data, this information is stored in a key record that includes a
CRC over all fields to protect against data corruption.
13. The µMACE denies access to plaintext secret and private keys contained within the
module.
14. The Program Update service can be used to zeroize all plaintext cryptographic keys and
other unprotected critical security parameters within the module.
15. The µMACE conforms to FCC 47 Code of Federal Regulations, Part 15, Subpart B,
Unintentional Radiators, Digital Devices, Class B requirements.
16. The µMACE performs the following self-tests. Powering the module off then on will initiate
the power up self-tests.
 Power up and on-demand tests
- Cryptographic algorithm test: A cryptographic algorithm test using a known answer is
conducted for all cryptographic functions (e.g., encryption, decryption,
authentication, and hashing.) for each Approved algorithm listed below. The test
passes if the final data matches the known data, otherwise it fails.
- AES-256 encrypt / decrypt known-answer tests for 8-bit CFB, ECB, and CBC
Copyright Motorola Solutions, Inc, 2018 Page 13 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
modes (Cert. #1876)
- AES-256 encrypt / decrypt known-answer tests for OFB, GCM, and CTR
modes (Cert. #2146)
- AES-128 encrypt /decrypt known-answer tests for ECB, CBC, OFB, and CTR
modes (Cert #3089)
- SHA-384 known answer test (Cert. #1619)
- HMAC SHA-384 known answer test (Cert. #1313)
- SP800-56A KAS (ECDH and ECMQV) known answer test (Cert. #28)
- ECDSA P-384: signature generation/verification known answer test (Cert.
#263)
- ECDSA P-384: key generation known answer test (Cert. #263)
- Firmware integrity test: A digital signature is generated over the code when it is built
using SHA-384 and ECDSA P-384 and is stored with the code upon download into
the module. When the module is powered up the digital signature is verified. If the
digital signature matches, then the test passes, otherwise it fails.
- Critical functions test:
- -the module performs a read/write test of the internal RAM at each power up.
-Random Number Generator entropy test. This test runs two RNG statistical
tests: a FIPS monobit test, and a FIPS “runs” test
-
 Conditional tests
- Firmware load test: A digital signature is generated over the code when it is built
using SHA-384 and ECDSA P-384. Upon download into the module, the digital
signature is verified. If the digital signature matches, then the test passes,
otherwise it fails.
- Continuous Random Number Generator test: The continuous random number
generator test is performed on all RNGs supported by the module (NDRNG). An
initial value is generated and stored upon power up. This value is not used for
anything other than to initialize comparison data. A successive call to any one of
the RNGs generates a new set of data, which is compared to the comparison data.
If a match is detected, this test fails; otherwise the new data is stored as the
comparison data and returned to the caller. This testing is done for each 4 byte
RNG data block, generated by the NDRNG.
- Pair-wise consistency test (for public and private keys used to perform the
calculation and verification of digital signatures): The ECDSA Public and Private
Generated Signature Key pair is tested by the calculation and verification of a
digital signature. If the digital signature cannot be verified, the test fails.
17. The µMACE toggles the Self-test Indicator interface within 2 seconds of power-up to
indicate the Firmware Integrity Test, Firmware Load Test, Cryptographic Algorithm Test,
and Critical Functions Test have completed successfully. The µMACE enters the Critical
Error state and does not toggle the Self-test Indicator interface if the Firmware Integrity
Test, Firmware Load Test, Cryptographic Algorithm Test, or Critical Functions Test fails.
The Critical Error state may be exited by powering the module off then on.
18. The µMACE enters the Critical Error state and outputs a message over the SDIO interface
to indicate the Continuous Random Number Generator Test and Pair-wise Consistency
Copyright Motorola Solutions, Inc, 2018 Page 14 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
tests have failed. The Critical Error state may be exited by powering the module off then
on.
19. The µMACE does not perform any cryptographic functions while in an error state.
Copyright Motorola Solutions, Inc, 2018 Page 15 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
6. Identification and Authentication Policy
The µMACE supports a User role and a Crypto-Officer role.
The Crypto-Officer and User roles are authenticated with passwords. The Crypto-Officer and
User passwords are initialized to a default value during manufacturing and are sent in encrypted
form to the module for authentication. After authenticating, the Crypto-Officer and User
passwords may be changed at any time.
The User role is also authenticated by the KVL-BKK for OTAR and Store & Forward services.
Table 5: Roles and Authentication
Role Authenticati
on Type
Authentication
Mechanism
Strength of Authentication
Crypto-
Officer
Identity-
Based
Identity: a 4-byte
identifier is used to
identify the identity
and role. The
µMACE supports a
single identity.
Crypto-Officer
Password: a 14-32
character ASCII
password is
authenticated to gain
access to all Crypto-
Officer services.
Since the minimum password length is 14
ASCII printable characters and there are
95 ASCII printable characters, the
probability of a successful random
attempt is 1 in 95 ^ 14 or 1 in
4,876,749,791,155,298,590,087,890,625.
The module limits the number of
authentication attempts in one minute to
15. The probability of a successful
random attempt during a one-minute
period is 15 in 95 ^ 14 or 1 in
3.25117e+26.
User
(SDIO
Interface)
Identity-
Based
Identity: a 4-byte
identifier is used to
identify the identity
and role. The
µMACE supports a
single identity.
User Password: a 14-
32 character ASCII
password is
authenticated to gain
access to all User
services.
Since the minimum password length is 14
ASCII printable characters and there are
95 ASCII printable characters, the
probability of a successful random
attempt is 1 in 95 ^ 14 or 1 in
4,876,749,791,155,298,590,087,890,625.
The module limits the number of
authentication attempts in one minute to
15. The probability of a successful
random attempt during a one-minute
period is 15 in 95 ^ 14 or 1 in
3.25117e+26.
User (KVL
Interface)
Identity-
Based
Identity: a 1-byte
identifier is used to
identify the identity
The probability of a successful random
attempt is 1 in 2 ^ 256 which is less than
1 in 1,000,000.
Copyright Motorola Solutions, Inc, 2018 Page 16 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
Role Authenticati
on Type
Authentication
Mechanism
Strength of Authentication
and role. The
µMACE supports a
single identity.
KVL-BKK: a 256-bit
AES key is
authenticated to gain
access to the
services performed
over the KVL
interface.
The maximum number of authentication
attempts that can be performed over the
KVL interface with the KVL-BKK in one
minute is 745. Therefore the probability
of a successful random attempt during a
one-minute period is 745 in 2 ^ 256 or 1
in 1.55425e+74.
Copyright Motorola Solutions, Inc, 2018 Page 17 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
7. Physical Security Policy
The µMACE is a production grade, single-chip cryptographic module as defined by FIPS 140-2
and is designed to meet Level 3 Physical Security.
The µMACE is covered with a hard opaque metallic coating that provides evidence of attempts to
tamper with the module. Tampering with the module will cause it to enter a lock-up state in which
no crypto services will be available.
No maintenance access interface is available.
Copyright Motorola Solutions, Inc, 2018 Page 18 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
8. AES-256 GCM Non-Internal IV Generation Protocol
In the case when the final IV value is not generated inside the module, but is generated using an
internally-generated random value (salt) as described in the RFG (“GCM Key/IV Pair Uniqueness
and Existing Protocols”), the following protocols shall be used:
 For TLS with AES GCM as defined in RFC 5288, the IV (defined in section 3) consists of a
salt that is generated internally to the module and a nonce_explicit that is passed in as it may
be the sequence number.
 For SRTP with AES GCM as defined in draft-ietf-avtcore-srtp-aes-gcm-10, the IV (defined in
section 9.1) consists of a salt that is generated internally to the module and the
Synchronization Source identifier, Rollover Counter, and sequence number are passed as
parameters to the module.
 For SRTCP with AES GCM as defined in draft-ietf-avtcore-srtp-aes-gcm-10, the IV defined in
(section 10.1) consists of a salt that is generated internally to the module and the
Syncronization Source identifier and the SRTCP index are passed as parameters to the
module.
The protocols mentioned above are being designed to be used with AES GCM and to prevent key
and IV reuse as required by SP 800-38D. There are several documents that have been
standardized or in the process of becoming standard for these protocols to use AES GCM. To
generate the IV internally to minimize influencing the generation of IVs for these high level
protocols, external parameters need to be passed in.
Copyright Motorola Solutions, Inc, 2018 Page 19 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
9. Access Control Policy
9.1. µMACE Supported Roles
The µMACE supports the following roles:
 User Role
o SDIO Interface
o KVL Interface
 Crypto-Officer Role
9.2. µMACE Services Available to the User Role via SDIO Interface.
 Validate User Password: Validate the current User password used to identify and authenticate
the User role via the SDIO interface. Successful authentication will allow access to crypto
services allowed for the User. Available in both FIPS and non-FIPS mode.
 Change User Password: Modify the current password used to identify and authenticate the
User Role via the SDIO interface. Available in both FIPS and non-FIPS mode.
 Algorithm List Query: Provides a list of algorithms over the SDIO interface. Available in both
FIPS and non-FIPS mode.
 Logout User Role: Logs out the User. Available in both FIPS and non-FIPS mode.
 Export Key Variable: Transfer encrypted key variables (KEKs, TEKs) out of the module over
the SDIO interface. Available in both FIPS and non-FIPS mode.
 Import Key Variable: Receive encrypted key variables (KEKs, TEKs, and ECMQV Private
Static Key) over the SDIO interface. Available in both FIPS and non-FIPS mode.
 Generate Key Variable: Auto-generate KEKs, TEKs, ECDH Public and Private Values, Public
and Private Generated Signature Keys, ECMQV Public Static Key, ECMQV Public and Private
Generated Ephemeral Keys, ECDH Shared Secret, and the KPK within the module. Available
in both FIPS and non-FIPS mode.
 Delete Key Variable: Delete KEKs, TEKs, ECDH Public and Private Values, ECDH Public and
Private Generated Signature Keys, ECMQV Public and Private Static Keys, ECMQV Public
and Private Generated Ephemeral Keys, and ECDH Shared Secret. Available in both FIPS
and non-FIPS mode.
 Edit Key Variable: Edit KEKs and TEKs managed by the module. Available in both FIPS and
non-FIPS mode.
 Key Check: Validate the correctness of a Key based on algorithm properties. Available in
both FIPS and non-FIPS mode.
 Encrypt: Encrypt plaintext data to be transferred over the SDIO interface. Available in both
FIPS and non-FIPS mode.
 Decrypt: Decrypt ciphertext data received over the SDIO interface. Available in both FIPS and
non-FIPS mode.
 Transfer Key Variable: Internally transfer key variables (KEKs, TEKs) between volatile and
non-volatile memory. Available in both FIPS and non-FIPS mode.
 Generate Signature: Generate a Signature and output result over SDIO interface. Available in
both FIPS and non-FIPS mode.
 Generate Hash: Generate a hash and output result over SDIO interface. Available in both
FIPS and non-FIPS mode.
Copyright Motorola Solutions, Inc, 2018 Page 20 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
 Generate MAC: This service generates a Message Authentication Code of a block of data to
provide data integrity using a shared symmetric key
 Perform Key Agreement Process: Perform a key agreement process to create a key in volatile
memory. Available in both FIPS and non-FIPS mode.
 Generate Random Number: Generate random data using the Non-deterministic Hardware
Random Number Generator and output result over SDIO interface. Available in both FIPS
and non-FIPS mode.
 Key Query: Retrieve the metadata for a given key present in the module. Available in both
FIPS and non-FIPS mode.
 OTAR: Modify and query the KEKs and TEKs stored internally via the SDIO interface.
9.3. µMACE Services Available to the User Role via KVL Interface.
 Store & Forward: Modify and query the KEKs and TEKs stored internally via the KVL
interface.
 Zeroize Keys via KVL interface: Zeroize KEKs and TEKs via the KVL interface.
 Import Key Variable: Load encrypted KEKs and TEKs via the KVL interface.
9.4. µMACE Services Available to the Crypto-Officer Role.
 Program Update: Update the module firmware via the SDIO interface. All keys (stored in
RAM and non-volatile memory) and CSPs are zeroized during a Program Update. Available
in both FIPS and non-FIPS mode.
 Validate Crypto-Officer password: Validate the current Crypto-Officer password used to
identify and authenticate the Crypto-Officer role via the SDIO interface. Successful
authentication will allow access to services allowed for the Crypto Officer. Available in both
FIPS and non-FIPS mode.
 Change Crypto-Officer password: Modify the current password used to identify and
authenticate the Crypto-Officer Role via SDIO interface. Available in both FIPS and non-FIPS
mode.
 Extract Action Log: Exports a history of actions over the SDIO interface. Available in both
FIPS and non-FIPS mode.
 Logout Crypto-Officer Role: Logs out the Crypto-Officer. Available in both FIPS and non-FIPS
mode.
 Configure Module via SDIO interface: Perform configuration of the module (e.g. time
configuration, enable/disable clear key import, enable/disable red keyfill, etc.) via the SDIO
interface. Available in both FIPS and non-FIPS mode.
9.5. µMACE Services Available without a Role.
 Perform Self-Tests: Performs module self-tests comprised of cryptographic algorithms test and
firmware test. Initiated by a transition from power off state to power on state. Available in both
FIPS and non-FIPS mode.
 Version Query: Provides module firmware version number and FIPS status over the SDIO
interface. Available in both FIPS and non-FIPS mode.
 Configure Module via KVL interface: Perform configuration of the module (e.g. OTAR
configuration) via the KVL interface.
Copyright Motorola Solutions, Inc, 2018 Page 21 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
9.6. Critical Security Parameters (CSPs) and Public Keys
Table 6: CSP Definition
CSP Identifier Description
Key Protection Key (KPK) This is a 256-bit AES key used to encrypt all other keys stored
in non volatile memory. Generated internally using the Non-
deterministic Hardware Random Number Generator. Stored
encrypted with the UKPPK in non volatile memory (AES256-
OFB). The KPK is not entered into or output from the module.
Entry - n/a
Output - n/a
Storage – encrypted with the UKPPK (AES256-OFB) in
non-volatile memory
Zeroization - on Program Update service request
Generation - Non-deterministic Hardware Random
Number Generator
UKPPK (Universal Key
Protection Protection Key)
This is a 256 bit AES Key used for encrypting the KPK. Stored
unencrypted in RAM while in use; stored in plaintext in non-
volatile memory and zeroized through the Program Update
service. The UKPPK is entered using the Program Update
service (encrypted using AES-CBC) and is not output from the
module.
Entry – on Program Update service request
Output – n/a
Storage – in plaintext in non volatile memory
Zeroized – on Program Update service request
Generation – n/a
Key Variable Loader Black
Keyloading Key (KVL-BKK)
This is a 256 bit AES Key used for encrypting keys that are
input into the module and output from the module via the KVL
interface. Stored unencrypted in RAM while in use; stored in
plaintext in non-volatile memory and zeroized through the
Program Update service. The KVL-BKK is entered using the
Program Update service (encrypted using AES-CBC) and is
not output from the module.
Entry - on Program Update service request
Output - n/a
Storage - in plaintext in non volatile memory
Zeroized - on Program Update service request
Generation - n/a
Black Keyloading Key
(BKK)
This is a 256-bit AES Key used for encrypting keys that are
input into the module and output from the module via the SDIO
interface. Stored unencrypted in RAM while in use; stored in
plaintext in non-volatile memory and zeroized through the
Copyright Motorola Solutions, Inc, 2018 Page 22 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
CSP Identifier Description
Program Update service. Also stored encrypted on the KPK in
non volatile memory. The BKK is entered using the Program
Update service (encrypted using AES-CBC) and is not output
from the module.
Entry - on Program Update service request
Output - n/a
Storage - in plaintext in non volatile memory and
encrypted on KPK in non volatile memory
Zeroization - on Program Update service request
Generation - n/a
Image Decryption Key
(IDK)
A 256-bit AES key used to decrypt downloaded images. The
IDK is not output from the module.
Entry - on Program Update service request
Output - n/a
Storage - in plaintext in non volatile memory
Zeroization - on Program Update service request
Generation - n/a
Traffic Encryption Keys
(TEKs)
128 and 256-bit AES Keys used for enabling secure
communication with target devices. TEKs are entered in
encrypted form via the SDIO or KVL interface (AES Key
Wrapping). TEKs entered through the SDIO interface are
encrypted with the BKK. TEKs entered through the KVL
interface are encrypted with the KVL-BKK or KEKs. The TEKS
are stored encrypted on the KPK (AES256-CFB8) in non
volatile memory. TEKs are stored in plaintext in RAM only as
long as needed. TEKs are output from the module on the
SDIO interface encrypted using KEKs (AES Key Wrapping). .
Entry – input encrypted with AES Key Wrap over the
SDIO Interface or KVL interface
Output – output encrypted with AES Key Wrap over the
SDIO Interface
Storage – stored encrypted on KPK with AES256-CFB8
in non volatile memory
Zeroization - on Delete Key Variable and Program
Update service requests
Generation – internally derived through key agreement
Key Encryption Keys
(KEKs)
128 and 256-bit AES Keys used for enabling secure
communication with target devices. KEKs are entered in
encrypted form via the SDIO or KVL interface (AES Key
Wrapping). KEKs entered through the KVL interface are
encrypted with the KVL-BKK or other KEKs. KEKs entered
through the SDIO interface are encrypted with other KEKs.
The KEKS are stored encrypted on the KPK (AES256-CFB8) in
non volatile memory. KEKs are stored in plaintext in RAM only
as long as needed. KEKS are not output from the module.
Entry – input encrypted with AES Key Wrap over the
SDIO or KVL Interface
Copyright Motorola Solutions, Inc, 2018 Page 23 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
CSP Identifier Description
Output - n/a
Storage – stored encrypted on KPK with AES256-CFB8
in non volatile memory
Zeroization - on Delete Key Variable and Program
Update service requests
Generation - n/a
User Password The User Password is entered encrypted on the PEK (AES256-
CFB8). The User Password is not stored in the module or
output from the module.
Entry – entered encrypted on the PEK with AES256-
CFB8
Output - n/a
Storage – a hash of the User Password is stored in non-
volatile memory
Zeroization – on Program Update service request
Generation - n/a
Crypto-Officer Password The Crypto Officer password is entered encrypted on the PEK
(AES256-CFB8). After decryption the plaintext password is not
stored but temporarily exists in volatile memory. The SHA-384
hash value of the plaintext password is stored encrypted on the
PEK in non volatile memory. The SHA-384 hash of the
decrypted password is compared with the SHA-384 hash value
stored in non-volatile memory during password validation.
Entry - entered encrypted on the PEK with AES256-
CFB8
Output - n/a
Storage - SHA-384 hash of the plaintext password is
encrypted on the PEK in non volatile memory
Zeroization – on Program Update service requests
Generation - n/a
Password Encryption Key
(PEK)
This is a 256-bit AES Key used for decrypting passwords
during password validation. Loaded via the Program Update
service. Stored in plaintext in non-volatile memory and
zeroized through the Program Update service. Also stored
encrypted on the KPK in non volatile memory. The PEK is not
output from the module.
Entry - on Program Update service request
Output - n/a
Storage - in plaintext in non volatile memory; encrypted
on the KPK in non volatile memory
Zeroization - on Program Update service request
Generation - n/a
Copyright Motorola Solutions, Inc, 2018 Page 24 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
CSP Identifier Description
Elliptic Curve Diffie-
Hellman Private value
Randomly generated internally by a Generate Key Variable
service request using Non-deterministic Hardware Random
Number Generator. Used to establish a shared secret over an
insecure channel. Stored in plaintext in volatile memory. The
Elliptic Curve Diffie-Hellman Private value is not entered into or
output from the module.
Entry - n/a
Output - n/a
Storage – in plaintext in volatile memory
Zeroization - on Delete Key Variable or Program Update
service requests and on power off
Generation - on Generate Key Variable service request
ECDSA Private Generated
Signature Key (PGSK)
Randomly generated internally by the Generate Key Variable
service request using Non-deterministic Hardware Random
Number Generator. Stored in non volatile memory encrypted
on KPK; when in use it is in plaintext in RAM. The Private
Generated Signature Key is not output from the module.
Entry - n/a
Output - n/a
Storage – encrypted on KPK in non volatile memory
Zeroization - on Delete Key Variable and Program
Update service requests
Generation - on Generate Key Variable service request
ECMQV Private Static Key The ECMQV Private Static Key is entered over the SDIO
Interface encrypted on the BKK (AES Key Wrapping). Used to
establish a shared secret over an insecure channel. Stored
encrypted with KPK in non volatile memory. The ECMQV
Private Static Key is not output from the module.
Entry – entered encrypted on the BKK with AES Key
Wrap over the SDIO Interface
Output - n/a
Storage - encrypted on KPK in non volatile memory
Zeroization - on Delete Key Variable and Program
Update service requests
Generation - n/a
ECMQV Private Generated
Ephemeral Key (PGEK)
Randomly generated internally by the Generate Key Variable
service request using Non-deterministic Hardware Random
Number Generator. Used to establish a shared secret over an
insecure channel. When in use it is in plaintext in RAM. The
ECMQV Private Generated Ephemeral Key is not entered into
or output from the module.
Entry - n/a
Output - n/a
Storage - n/a
Zeroization - on power off or Program Update service
request
Generation - Non-deterministic Hardware Random
Number Generator
Copyright Motorola Solutions, Inc, 2018 Page 25 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
CSP Identifier Description
Elliptic Curve Diffie-
Hellman Shared Secret
Generated internally by the Elliptic Curve Diffie-Hellman
Algorithm. The Elliptic Curve Diffie-Hellman Shared Secret is
output encrypted on a KEK (AES Key Wrapping) as part of the
Diffie-Hellman key agreement protocol.
Entry - n/a
Output – output encrypted on a KEK with AES Key
Wrap over the SDIO interface
Storage – in plaintext in volatile memory
Zeroization - on power off or Program Update
service request
Generation - internally by the Elliptic Curve Diffie-
Hellman Algorithm
Table 7: Public Keys
Key Description
ECDSA Public
Programmed Signature Key
A 384-bit ECDSA public key used to validate the signature of
the firmware image being loaded before it is allowed to be
executed. Stored in non volatile memory. Loaded during
manufacturing and as part of the boot image during a Program
Update service. The Public Programmed Signature Key is not
output from the module.
Entry - on Program Update service request
Output - n/a
Storage - in plaintext in non volatile memory
Zeroization - on Program Update service request
Generation - n/a
Copyright Motorola Solutions, Inc, 2018 Page 26 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
Elliptic Curve Diffie-Hellman
Public value
Generated internally by the Generate Key Variable service
request. Used to establish a shared secret over an insecure
channel. Stored in plaintext in volatile memory. The Elliptic
Curve Diffie-Hellman Public value is generated internally and is
output as part of the Diffie-Hellman key agreement protocol.
Entry - n/a
Output - in plaintext over the SDIO interface
Storage - in plaintext in volatile memory
Zeroization - on Delete Key Variable and Program
Update service requests and on power off
Generation - on Generate Key Variable service request
ECDSA Public Generated
Signature Key
Generated internally by the Generate Key Variable service
request. A 384-bit ECDSA key used to validate signatures.
Stored in plaintext in non volatile memory. The ECDSA Public
Generated Signature Key is output from the module in plaintext
over the SDIO interface.
Entry - n/a
Output - in plaintext over the SDIO interface
Storage - in plaintext in non volatile memory
Zeroization - on Delete Key Variable and Program
Update service requests
Generation - on Generate Key Variable service request
ECMQV Public Static Key The ECMQV Public Static Key is generated internally by the
Generate Key Variable service request. Used to establish a
shared secret over an insecure channel. Stored in plaintext in
non volatile memory. The ECMQV Public Static Key is output
in plaintext from the module over the SDIO interface.
Entry - n/a
Output - SDIO Interface in plaintext
Storage - in plaintext in non volatile memory
Zeroization - on Delete Key Variable and Program
Update service requests
Generation – on Generate Key Variable service request
ECMQV Public Generated
Ephemeral Key
Generated internally by the Generate Key Variable service
request. Used to establish a shared secret over an insecure
channel. Stored in plaintext in non volatile memory. The
ECMQV Public Generated Ephemeral Key is output from the
module in plaintext over the SDIO interface.
Entry - n/a
Output - SDIO Interface in plaintext
Storage - n/a
Zeroization - on power off or Program Update service
request
Generation - on Generate Key Variable service request
Remote Party Diffie-
Hellman Ephemeral Public
Key
Input in plaintext over the SDIO interface. Used to establish a
shared secret over an insecure channel. Stored in plaintext in
volatile memory.
Entry – in plaintext over SDIO interface
Output – n/a
Storage - in plaintext in volatile memory
Copyright Motorola Solutions, Inc, 2018 Page 27 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
Zeroization - on Delete Key Variable and Program
Update service requests and on power off
Generation – n/a
Remote Party ECMQV
Ephemeral Public Key
Input in plaintext over the SDIO interface. Used to establish a
shared secret over an insecure channel. Stored in plaintext in
volatile memory.
Entry – in plaintext over SDIO interface
Output – n/a
Storage - in plaintext in volatile memory
Zeroization - on Delete Key Variable and Program
Update service requests and on power off
Generation – n/a
Remote Party ECMQV
Static Public Key
Input in plaintext over the SDIO interface. Used to establish a
shared secret over an insecure channel. Stored in plaintext in
volatile memory.
Entry – in plaintext over SDIO interface
Output – n/a
Storage - in plaintext in volatile memory
Zeroization - on Delete Key Variable and Program
Update service requests and on power off
Generation – n/a
9.7. CSP Access Types
Table 8: CSP Access Types
CSP Access Type Description
C – Check CSP Checks status of the CSP.
D – Decrypt CSP Decrypts entered KEKs and TEKs using the BKK during CSP
entry over the SDIO interface. Decrypts entered KEKs and
TEKs using the KVL-BKK during CSP entry over the KVL
interface.
Decrypts entered passwords using the PEK during entry over
the SDIO interface.
E – Encrypt CSP Encrypts KEKs and TEKs prior to output over the SDIO interface
using a KEK or BKK.
G – Generate CSP Generates KPK, Elliptic Curve Diffie-Hellman private key or
ECMQV private key.
S – Store CSP Stores KPK in plaintext in non volatile memory.
Stores plaintext BKK, PEK, or IDK in volatile and non-volatile
memory (encrypted except IDK).
Stores SHA-384 Hash of the Crypto-Officer password in non
volatile memory (encrypted on PEK).
Copyright Motorola Solutions, Inc, 2018 Page 28 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
CSP Access Type Description
U – Use CSP Uses CSP internally for encryption / decryption services.
Z – Zeroize CSP Zeroizes CSP.
Copyright Motorola Solutions, Inc, 2018 Page 29 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
Table 9: CSP versus CSP Access
Service CSP Role
PEK
TEKs
KEKs
KPK
KVL-BKK
BKK
IDK
User
Password
Crypto-Officer
Password
ECDH
Private
Value
ECDSA
PGSK
ECMQV
Private
Static
Key
ECMQV
PGEK
ECDH
Shared
Secret
UKPPK
User
Role
SDIO
Interface
User
Role
KVL
Interface
Crypto-Officer
Role
No
Role
Required
1. Program Update z, s z z z z, s z, s
u, z,
s
z z z z z z
z
z
√
2. Validate Crypto-Officer Password u
d, u,
z
√
3. Change Crypto-Officer Password u
d,u,
z, s
√
4. Validate User Password u d
d, u,
z
g √
5. Change User Password u
d, s,
e,g
d, u,
z
g √
6. Extract Action Log √
7. Version Query √
8. Algorithm List Query √
9. Logout User Role z z √
10. Logout Crypto-Officer Role √
11. Export Key Variable
d, e,
u
d, e,
u
u u u
d, e,
u
√
12. Import Key Variable
d,e,
s, u
d,e,
s, u
u u u u u
d,e,
s, u u √
√
13. Generate Key Variable e, g,
s
e, g,
s
u
e, g,
s
e, g,
s
e, g,
s
u √
14. Delete Key Variable z z z z z z
z √
15. Edit Key Variable
d,e,
u, s
d,e,
u, s
u d, s d, s d, s d √
16. Key Check c c u c c c c √
17. Encrypt u u u u √
18. Decrypt u u u u u u u u u √
19. Perform Self-Tests √
20. Transfer Key Variable
d,e,
u, s
d,e,
u, s
u
d,e,
u, s
d,e,
u, s
d,e,
u, s
√
21. Generate Signature u d, u √
22. Generate HASH √
Copyright Motorola Solutions, Inc, 2018 Page 30 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
Service CSP Role
PEK
TEKs
KEKs
KPK
KVL-BKK
BKK
IDK
User
Password
Crypto-Officer
Password
ECDH
Private
Value
ECDSA
PGSK
ECMQV
Private
Static
Key
ECMQV
PGEK
ECDH
Shared
Secret
UKPPK
User
Role
SDIO
Interface
User
Role
KVL
Interface
Crypto-Officer
Role
No
Role
Required
23. Generate MAC d, u u √
24. Perform Key Agreement u d, u d, u d, u d, u u √
25. Configure Module via SDIO
interface
√
26. Random number generation √
27. Key Query d d u d d d d √
28. Configure Module via KVL interface √
29. Zeroize Keys via KVL interface z z √
30. OTAR
d, u,
e, z,
s
d, u,
e, z,
s
√
31. Store & Forward
d, u,
e, z,
s
d, u,
e, z,
s
√
Copyright Motorola Solutions, Inc, 2018 Page 31 of 31
Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).
10. Mitigation of Other Attacks Policy
The µMACE is not designed to mitigate any specific attacks outside of those required by
FIPS 140-2.