Key Variable Loader (KVL) 5000 PIKE

Certificate

Approved Algorithms (16)

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

flowchart LR
  %% Deterministic review-risk graph for Key Variable Loader (KVL) 5000 PIKE
  %% 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</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Status Output</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    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?"]
    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"]
    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
  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,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Key Variable Loader (KVL) 5000 PIKE
  %% 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</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"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C6 clueLow;

Security Policy, page by page

Key Variable Loader (KVL) 5000 PIKE Non-Proprietary FIPS 140-3 Security Policy Document Version: 1.2 Date: November 14, 2024 Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

This document defines the Security Policy for the Key Variable Loader (KVL) 5000 PIKE module by Motorola Solutions, Inc., hereafter denoted the Module. The KVL 5000 is a portable key distribution device that consists of the KVL Host Application processor and KVL 5000 PIKE Hardware Security Module (HSM). The PIKE IC is integrated into the HSM. The Module is a single-chip cryptographic module to meet FIPS 140-3 Level 2 physical security requirements as defined by FIPS 140-3. The Module allows the user to generate, transport, and load encryption keys, securely and efficiently into secure communication products thereby enabling secure encrypted communications The FIPS 140-3 security levels for the Module are as follows: Table 1

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

The PIKE cryptographic module is a single chip hardware cryptographic module. The Motorola Solutions Inc. module is used in the KVL 5000 Key Variable Loader product. The Module is intended for use by US Federal agencies or other markets that require FIPS 140-3 validated overall Security Level 2.

The Module is tested on the following operational environment. Table 2

• Cryptographic Module Tested Configuration The Module supports the following approved 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 Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

The KVL 5000 Key Variable Loader (KVL) production diagram is shown in Figure 1. The Motorola PIKE chip is shown in Figure 2 provides the data security services required by the KVL 5000 Key Variable Loader. MOTOROLA PIKE Chip (FIPS validated module sits inside the product as a chip) KVL 5000 Host Application Figure 1: KVL 5000 Key Variable Loader (KVL) Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

Figure 2: Motorola PIKE Chip The FIPS Boundary is drawn around Motorola PIKE chip, as shown in Figure 3. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

FIPS Boundary Internal Flash Power Clock Motorola PIKE Chip RS-232 Port KYLD Port GPIO SPI EBI External Flash KVL 5000 HOST Figure 3: Cryptographic Boundary Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The KVL 5000 Key Variable Loader (KVL) module is originally non-compliant and must be configured to operate in an approved mode of operation. The Crypto Officer shall configure the Module to operate in an approved mode of operation. In order for the Module to operate in the approved mode, the Module must be properly installed, initialized and configured, which includes the creation of the passwords for the Crypto Officer (CO) and User role. Documented below in Section 2.3.1 are the additional configuration settings that are required for the Module to be used in a FIPS 140-3 approved mode of operation at overall Security Level 2. The settings menu of the KVL Host application graphical user interface in the settings menu will be used to determine whether the KVL 5000 is operating in an approved mode. When operating in an approved mode the display will indicate.

• “FIPS mode: Level 2 (Standard)”
• “FIPS Status: Compliant” Use Version and Algorithm List Query 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

In order to configure the Module for an Approved mode at overall Security Level 2, the operator shall use the Configure KVL service to set the following configuration parameters as shown below.

1. Either Clear Key Export or Encrypted Key Export: Enabled
2. For an incorrect login attempt, the CO must configure the module to either lock the device from further login attempts for a specified amount of time (configurable by the CO between 1-30 minutes), or execute the Factory Reset service. The default setting is to lockout the CO/User for

Only Approved algorithms may be loaded into the Module; in particular AES-128 Cert. #C908) and/or AES-256 (Cert. #C909). At a minimum, one of these “drop-in algorithms” must be added from the Module independent of the base firmware via the Program Update service. In addition to the approved algorithms, external entropy must also be supplied to the Module from the host application upon successful authentication of the operator of the Module. The loading of non-validated firmware within the validated cryptographic module invalidates the module’s validation. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

The Module implements the Approved and Non-Approved but Allowed cryptographic functions listed in the tables below. Table 4 – Approved Algorithms Per IG C.H Scenario 2, the Module internally generates a 96-bit GCM IV internally as specified in SP800The entropy for seeding the SP 800-90A DRBG is determined by the host application using the Module and is outside of the module’s physical 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).

Table 5

• Non-Approved but Allowed Cryptographic Functions Table 6
• Non-Approved but Allowed Cryptographic Functions with No Security Claimed The module does not implement any Non-Approved Algorithms not allowed in the Approved Mode of Operation.

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 or logout
4. The Module does not provide any cryptographic services while in critical error state.
5. An operator does not have access to any cryptographic services prior to assuming an authorized role.
6. The Module allows the operator to initiate power-up self-tests by power cycling power or resetting the Module.
7. Power up self-tests do not require any operator action.
8. Data output is inhibited during key generation, self-tests, zeroization, and error states.
9. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise
10. The Module does not support a maintenance interface or role.
11. The Module does not support manual SSP establishment method. Motorola Solutions Public Material – May be reproduced only in its original entirety (without revision).

13. The Module does not output intermediate key values.
14. The Module does not provide bypass services or ports/interfaces.
15. The Module does not support a bypass capability.
16. The Module does not support concurrent operators.

The Module shall be installed in the Motorola KVL 5000 Key Variable Loader product. Prior to the initial use of the Module, the operator is required to set the passwords for the Crypto Officer (CO) and User roles. The Module is not usable until the passwords for both the CO and User are set. The Module shall be operated such that only approved Drop-in algorithms listed in Table 3 are installed and configured as per Section 2.3.1.

The Module’s ports and associated logical interface categories are listed in Table 7. Table 7

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

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

The Module supports two distinct operator roles, User and Cryptographic Officer (CO). Table 8 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 as UA in Table 8. Table 8

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

The Module supports two distinct operator roles (User and Crypto-Officer). The Module uses 30-byte long 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 9

• Roles and Authentication All services implemented by the Module are listed in Table 10. The Module does not allow any nonapproved service while operating in FIPS 140-3 level 2 mode. Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

The SSPs modes of access shown in Table 10 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 10
• Approved Services Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

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

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

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

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

The Module is composed of a base firmware version identified in Table 2, and at least one of the drop-in algorithms listed in Table 3. The firmware components are protected with the authentication technique(s) Firmware Load Public Programmed Signature Key described in Table 16 The Module includes a firmware verification and load service to support necessary updates using ECDSA SigVer (ECDSA Cert. #ECDSA 183). The operator can initiate the firmware integrity test on demand by power cycling the Module. 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 tested operational environment is listed in Table 2. The Module includes a Program Update service to support necessary updates. 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 Module is a production grade, single-chip cryptographic module as defined by FIPS 140-3 and is designed to meet level 2 physical security requirements. with the Module. The security provided from the hardness of the Module's epoxy encapsulate is claimed at ambient temperature (25 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. Table 11

• Physical Security Inspection Guidelines 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 12 below: Table 12

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

Module is described in the services detailed in 4.3. Table 13

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

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

Table 14

• Non-Deterministic Random Number Generation Specification 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. Power-up self–tests are available All Cryptographic Algorithm Self-Tests (CAST) must be completed successfully prior to any other use of cryptographic functionality by the Module. The Module outputs a status indicator via the LED output interface to indicate all self-tests passed or when a critical error state is entered due to a failed self-test. LED status solid green means power-up self-tests passed, flashing amber means self-tests is in progress, condition. The self-tests error states and status indicator are described in Table 15 below: Table 15

• Error States and Indicators The Module performs the following conditional self-tests: Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

Table 17

• Conditional Self-Tests 3 All Conditional Self-Test KATs are executed during the module power-up sequence except the DRBG KAT which is performed during CO/User login. Motorola Solutions Public Material
• May be reproduced only in its original entirety (without revision).

The Module is originally a non-compliant and must be initialized to be in approved mode. There is no non-approved mode. During initialization the operator shall configure the Key Variable Loader (KVL)

1. Upon first access, the operator will use the default passwords (Crypto Officer and User) provided by Motorola in a separate communication.
2. The operator will then change the default passwords (Crypto Officer and User) based on the requirements in Section 2.3 - Modes of Operation
3. The operator will then configure the Module using the Configure KVL service as specified in the section 2.3.1.

The Key Variable Loader (KVL) 5000 PIKE is embedded in Key Variable Loader (KVL). Motorola uses commercially available courier systems such as UPS, FedEx, and DHL with a tracking number and requires a signature at the end by an authorized client.

Use the Key Variable Loader (KVL) 5000 user guide available on the www.motorolasolutions.com website for secure operations.

Use the Key Variable Loader (KVL) 5000 user guide available on the www.motorolasolutions.com website for secure operations.

The Key Variable Loader (KVL) 5000 PIKE does not require any special maintenance.

After the end-of-life, the operator should zeroize all SSPs using the “Zeroize all keys and password“ service listed in the Section 4.3 followed by shredding the Key Variable Loader (KVL) 5000 PIKE 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 following standards are referred to in this Security Policy. Table 18

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

Table 19

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

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