Kenwood Cryptographic Module

Certificate

Approved Algorithms (8)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Kenwood Cryptographic Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>1.0.0</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Firmware Update</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Allows a user to authenticate with the module<br/>Zeroize the module and set a new username and…</i>"]
    C4["[high] Physical/logical<br/>interfaces (some 'blocked<br/>in firmware')<br/><i>SPI</i>"]
  end
  subgraph Inference["Derived inference"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I4["Interface reachability may<br/>vary by boot stage and<br/>lifecycle state."]
  end
  subgraph Risk["Reviewer question"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    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?"]
    R4["Are interfaces blocked<br/>before the bootloader<br/>runs, or only after<br/>approved mode starts?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E4["lifecycle reachability<br/>matrix · boot-stage<br/>interface timing ·<br/>factory/recovery/error-state<br/>access controls"]
  end
  C1 --> I1 --> R1 --> E1
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C4 --> I4 --> R4 --> E4
  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 C1,C2,C3,C4 clue;
  class I1,I2,I3,I4 infer;
  class R1,R2,R3,R4 risk;
  class E1,E2,E3,E4 evidence;

flowchart LR
  %% Deterministic clue tier for Kenwood Cryptographic Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>1.0.0</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Firmware Update</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Allows a user to authenticate with the module<br/>Zeroize the module and set a new username and…</i><br/>src: securityPolicy.services"]
    C4["[high] Physical/logical interfaces (some 'blocked in firmware')<br/><i>SPI</i><br/>src: securityPolicy.portsAndInterfaces"]
  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 C1,C2,C3,C4 clueHigh;

Security Policy, page by page

Security Policy of the Kenwood Cryptographic Module Author: John Batenhorst Part Number: KWD-AE40 Hardware Version: 1 Firmware Version: 1.0.0 Date: 10/9/2024

1.0.0 This document is a non-proprietary FIPS 140-3 Security Policy for the EF Johnson Technologies’ Kenwood hardware cryptographic module. Table 1 describes the security level of each section in this document. Table 1: Security Levels [Number Below] N/A N/A N/A The KCM is a multi-chip embedded FIPS 140-3 hardware cryptographic module. It provides access to basic cryptographic algorithms with available long-term key storage within the module itself. This module is intended for use cases where the additional security provided by a level 3 module is needed. The KCM has been designed for installation in Kenwood land mobile radio transceivers to provide them with secure storage for encryption keys and the cryptographic services needed for operation on encrypted P25 systems. The cryptographic boundary of the KCM encompasses the entire KCM PCB and all hardware and firmware components contained therein. No components found on the KCM PCB are excluded from the - 3 of 26 -

1.0.0 cryptographic boundary. Any keys stored in the module by a user reside in the boundary. The physical form of the Module is depicted in Figure

1. Top View Top View w/out Shield Bottom View Side View Figure 1: KCM Physical Form The module itself consists of several ICs and discrete components installed on a PCB. An ARM-based microcontroller on the PCB holds the module’s firmware in FLASH memory. Table 2 lists the operating hardware and firmware versions for which the KCM has been tested. Table 2: Cryptographic Module Tested Configuration The overall security rating of this module is Level
2. The KCM only operates in a single mode of operation. This is an approved mode and is entered automatically KCM is powered on or reset. If a failure occurs, the module enters a failure mode which cannot be exited except by power-cycling or resetting the module. Other than the failure mode, the module does not operate in any degraded modes. Table 3 lists the security functions provided by the KCM. - 4 of 26 -

1.0.0 Table 4 Lists the non-approved algorithms supported by the KCM. Table 4: Non-Approved Algorithms Allowed in the Approved Mode of Operation uses AES keys and AES block encryption in a way that will not lead to the disclosure of the encryption keys. The module does not implement any non-approved (not allowed) algorithms. Figure 2 depicts the KCM logical block diagram in an operational context. Figure 2: KCM Block Diagram - 6 of 26 -

1.0.0 The security design and rules of operation are as follows: The module’s circuitry is protected against unauthorized modifications and tampering. A multi-pin connector on the module’s PCB is used to supply the module with power and allow bidirectional communication between the user and the module. This connector is the only interface to the module, allowing data to be passed across the cryptographic boundary. The specifics of the physical and logical interfaces available through the multi-pin connector are detailed in Section 3. After the module is initialized, users are required to assume an authenticated role in order to use cryptographic services and access CSPs. The bulk of user communication with the module is done using a proprietary serial messaging protocol. Data input, output, status, and most control for the module is done using the messaging protocol. When the module detects a critical error, it enters the failure state, and all cryptographic services will be unavailable until the module is power cycled or reset. The module initializes itself atomically on power on or reset, including all self-tests, integrity checks, and DRBG seeding. See Section 10 for a description of the self-tests that are run on load. Table 5 lists the KCM’s ports and associated FIPS logical interfaces. Table 5: Ports and Interfaces - 7 of 26 -

1.0.0 The module does not utilize a trusted channel. Instead, all CSPs sent to or received from the module are encrypted with approved cryptographic algorithms. The module does not input or output plaintext CSPs. Data input and output, some forms of status, and some forms of control input and output are done over SPI using a proprietary serial messaging protocol. The module will not respond to any incoming user requests or output data over SPI until it completes any task currently in progress, including pre-operational selftests, zeroization, firmware load tests, and firmware upgrades. If the module goes into the failure mode, the output interface is disabled with a couple exceptions: User requests over SPI for the module’s status or the contents of the error log will still elicit a response from the module even while the module is in the error state since neither of those requests utilize cryptographic algorithms, and responses will not contain any sensitive information. The SPI messages sent and received by the module are uniquely defined to logically separate the logical interfaces utilizing SPI.

The KCM supports the Crypto Officer role, a User role, and an Unauthenticated User role. There is no maintenance role. Authentication is required for the Crypto Officer and User roles, and the Unauthenticated User role requires no authentication. The module supports only a single operator assuming one of these roles. Table 6 lists the KCM’s Roles and their available services. Table 6: Roles, Service Commands, Input and Output - 8 of 26 -

1.0.0 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Table 7 Lists the KCM’s authorized roles and their associated authentication requirements. - 9 of 26 -

1.0.0 There are no ways to bypass any of these capabilities, and there is no self-initiated cryptographic output capability. The KCM can receive firmware updates, and these can be initiated by the Crypto Officer role any time after the successful completion of the self-tests. More information about the firmware update process can be found in Section

5. The KCM supports only approved services and always operates in an approved mode. Approved services indicate their use by toggling hardware lines and sending serial messages conforming to the proprietary serial messaging protocol. Services indicated through serial messages have message payloads that are uniquely defined based on the service performed. All approved services provided by the KCM are listed in Table
6. Table 8: Approved Services HMAC-SHA2512 W, E W, E W, E E

1.0.0 W, E E E E E E E W, E E E G, W E, R E E E N/A E E N/A N/A Z, G, W Z Z, G, W Z, G, W Z, G, W Z, G, W - 11 of 26 -

1.0.0 N/A N/A N/A N/A N/A N/A N/A N/A HMAC-SHA2512 N/A E Z, W R E Z, W W Z, G, W Z, G, W Z, G, W Z, G, W Z, G, W - 12 of 26 -

1.0.0 N/A N/A Z, G, W N/A Z, G, W Z, G, W Z, G, W Z, G, W N/A N/A *These access rights are defined as follows: (G)enerate, (R)ead, (W)rite, (E)xecute, and (Z)eroise. Installation requires connecting the KCM’s hardware lines to provide power, control, and to communicate A single Crypto Officer is supported by the module and is able perform firmware updates, and that identity and role is authenticated using an approved keyed-hash message authentication code when a firmware update service is accessed. The User is identified and authenticated using a password that can be configured by the Unauthenticated User role. Switching between either of these authenticated roles requires that the operator authenticate as required by that role. The state of the operator’s authentication is held in volatile memory and will be cleared when the module is powered cycled or reset, requiring the operator to reauthenticate the next time they assume an authenticated role. Firmware is authenticated using the HMAC algorithm. The probability of a successful random attempt is 2512, which is less than 1 in 1,000,000. The module is capable of processing no more than 14,000 firmware updates in a one-minute period, so the probability of a successful random attempt in a one minute period is 14,000 in 2512 which is less than 1 in 1,000,000. - 13 of 26 -

1.0.0 A single authenticated User is supported by the module; any time the password is reset, the module is zeroized. If an operator fails to authenticate with a password five times sequentially, the module will be zeroized, and the password will need to be reset for the User role. The password reset service is also used to establish authentication data for the User role on new modules where no authentication data for that role has been set previously. Passwords sent to the module are encrypted using an approved encryption method. The password is a memorized secret but does not adhere to all SP800-63B requirements for authentication assurance level

1. The KCM is designed to interact with another device, not a human user, so protections against compromised or weak ascii passwords are not present in the module. Passwords are 32-digit hexadecimal numbers, chosen by the device utilizing the KCM. A new password is hashed and stored in the KCM’s memory using an approved hash function, and the hashes are used to authenticate users on subsequent authentication requests. Password hashes are not salted since the module has no way to separately store the salt from the hash inside the module’s boundary. Instead, the hashes are protected in the module’s memory by the module’s firmware and the physical security mechanisms described in Section
2. The password length allows for 1632 possible passwords, so the possibility of a successful random attempt is 1 in 1632, which is less than 1 in 1,000,000. Since the module allows for 5 failed password attempts, the probability of a successful random attempt in a one-minute period is 5 in 1632 which is less than 1 in 1,000,000. The KCM automatically performs an integrity check on its executable code when powered on or reset. It computes a hash of the executable code in FLASH and compares it to an expected value that was written when the module’s firmware was installed. If the two match, the integrity check passes. Otherwise, the module enters a failed state, and requests made to the module will either be ignored, or the module will respond with a message indicating an error condition. Any service utilizing a cryptographic algorithm will be unavailable. The operator can initiate this integrity check on demand by power cycling or resetting the module. Firmware updates are provided in the form of an encrypted firmware file and an HMAC. The keys used to encrypt the firmware and calculate the HMAC are known only to the KCM and the firmware author, - 14 of 26 -

1.0.0 EF Johnson. These keys are loaded into the module when an approved firmware is installed. Firmware updates are provided to the module using the proprietary SPI messaging protocol. When the module is provided with a firmware update, the update file is saved into volatile memory where the module decrypts it with its firmware decryption key. Then it performs a firmware load test by calculating an HMAC over the decrypted update file using its firmware HMAC key. If the HMAC calculated by the module matches the HMAC provided by the user, then the test is passed, and the update is understood to be a genuine update provided by EF Johnson. The module then replaces its executable code stored in FLASH with the updated code contained in the firmware file and resets. If the HMAC calculated by the module does not match the one provided by the user, the test is failed. The module will return an error to the user, and the firmware update will not be applied. Any applied firmware update with a version that does not match what appears on the FIPS 140-3 validation certificate is outside the scope of this validation and requires a separate FIPS 140-3 validation. This module is not open source.

The KCM operates in a limited operational environment. The module can receive firmware updates, and firmware versions validated under FIPS 140-3 will appear on a validation certificate. Installing any firmware version not appearing in this Security Policy will result in the KCM operating in a non-compliant state.

Table 9 lays out the KCM’s Physical Security Mechanisms. - 15 of 26 -

1.0.0 The KCM is a multi-chip embedded cryptographic module consisting of production grade components designed to meet Level 3 physical security requirements. All circuitry and components are protected by a hard, opaque epoxy coating that cannot be removed or penetrated without causing serious damage to the module. This coating discourages modifications and will show evidence if any such modifications are attempted. Table 10 lays out the KCM’s environmental failure testing and protections. - 16 of 26 -

1.0.0 Supply voltage and ambient temperature are monitored by the module. Exceeding the acceptable thresholds for either voltage or temperature will result in the module entering the failure state, and all cryptographic services will be unavailable until the module is power cycled or reset after temperature and voltage conditions return to an acceptable level. Table 11 shows the temperatures extremes at which the epoxy coating has been tested for adequate Table 11: Hardness testing temperature Ranges The module does not have any removable doors, covers, maintenance interface, or ventilation holes or slits that can be used to gain information about the module’s construction, components, or SSPs. The module does feature a tamper line that is used to retain a subset of SSPs in volatile memory. Loss of power to this line will result in the loss of any SSPs stored in that volatile memory. It should be noted that this tamper line is not used to meet any physical security requirements for a level 3 multi-chip embedded cryptographic module; those requirements are met by the epoxy coating. No actions are required by users to maintain the module’s physical security mechanisms. - 17 of 26 -

No steps to mitigate non-invasive attacks have been made.

Table 12 lays out the KCM managed sensitive security parameters (SSPs). Table 12: Sensitive Security Parameters (SSPs) AES-CBCMAC N/A N/A N/A - 18 of 26 -

1.0.0 N/A N/A N/A N/A N/A N/A N/A SHA2512 N/A N/A N/A N/A HMACSHA2512 N/A N/A N/A N/A N/A N/A - 19 of 26 -

1.0.0 SP 80090Arev1 N/A N/A SP 80090Arev1 N/A N/A 1. 2. 3. 4. 5. Explicitly zeroized by zeroization service

• a uniquely defined message is sent by the module to indicate successful completion of the zeroize service. Explicitly zeroized by firmware update
• a uniquely defined message is sent by the module to indicate successful Implicitly zeroized when the volatile memory holding the SSP loses power. Explicitly zeroized by Erase Keys of Length service
• a uniquely defined message is sent by the module to indicate successful completion of the service. Explicitly zeroized by Reset Password service
• a uniquely defined message is sent by the module to indicate successful completion of the service. Table 13 lays out the KCM entropy sources. Table 13: Non-Deterministic Random Number Generation Specification

generator provided by the module’s microcontroller. The state of the DRBG exists in volatile memory only and is cleared when the module is powered off or reset. Any generated SSPs are created using unmodified output from this DRBG. AES keys can be generated by the module at the request of the user. - 20 of 26 -

All SSPs imported by the module by a user are sent through the module’s serial messaging protocol and are protected by approved cryptographic methods. For the purpose of input using AES-OFB, the module utilizes manual distribution using electronic entry as per IG 9.5.A.

All SSPs exported by the module by a user are sent through the module’s serial messaging protocol and are protected by approved cryptographic methods.

All SSPs are stored in either volatile (RAM or backup RAM) or non-volatile (FLASH) memory. An AES key can either be stored in volatile or non-volatile memory at the discretion of the user. AES keys stored in volatile memory are cleared when the module is zeroized, powered off, or reset. Keys stored in non-volatile memory are encrypted using the AES key wrapping algorithm with Key Storage Keys (KSKs) generated by the module. KSKs can be stored either in volatile or non-volatile memory at the discretion of the user. Passwords are chosen by users and are not stored by the module. The module does generate a hash of the password using SHA2-512 which is stored in non-volatile memory.

The zeroize service is invoked using the module’s serial messaging protocol. The module is always in approved mode. The zeroize service will erase the KSKs, which will render the AES keys wrapped by them unrecoverable. The password hash and internal state of the DRBG are also erased. A uniquely defined serial message is returned by the module to indicate successful completion of the zeroize service. KSKs stored in volatile memory can also be cleared by a tamper event, which occurs when the module’s tamper line loses power. AES keys stored in volatile memory can also be cleared by resetting the module or removing main power. - 21 of 26 -

1.0.0 The FWDK, FWHK, PWK, and KFK are bound to the module’s firmware and can only be cleared by updating the module’s firmware. The module indicates completion of the firmware update by returning a uniquely defined serial message indicating successful completion of its pre-operational self-tests. SSPs stored in the module are protected by the module’s physical security measures detailed in Section 7 and the user authentication requirements detailed in Section 4. Unauthenticated users do have the ability to zeroize the module using the zeroize service.

The module runs pre-operational and conditional self-tests automatically on power up or reset, and the module operator can initiate these self-tests on demand by power cycling or resetting the module. The module does not have or test any critical functions other than those that are tested as described in the subsections below. If a test fails, the module enters the error state. Subsequent service requests made to the module will either be ignored, or the module will respond with a message indicating an error condition. Any service utilizing a cryptographic algorithm will be unavailable. The module has a single error state that it enters in the event of an error, and it maintains an error log that contains what error event most recently occurred. Authorized roles can retrieve the error log, but roles must be authenticated in order to clear it. Table 14 contains the error codes that may be recorded by the module when an error occurs causing it to enter the error state. - 22 of 26 -

1.0.0 Table 14: Error Code Values The module performs only one pre-operational self-test:

• Firmware Integrity Test - Integrity check using SHA2-512 The integrity check is done by calculating the SHA2-512 hash of all the module’s executable code in FLASH against an expected hash that was written when the module’s firmware was installed. The SHA2-512 - 23 of 26 -

1.0.0 implementation is validated by the HMAC-SHA2-512 KAT. After the test, all temporary values are cleared by overwriting their memory with zeroed bytes.

The module performs the cryptographic algorithm self-tests shown in Table 15: Table 15: Conditional Cryptographic Algorithm Self Tests FaultCAST FaultCAST HMAC-SHA2512 The hardware RBG is initialized and performs a repetition count test (RCT), an adaptive proportion test (APT), and AES CMAC known answer tests (KAT). The RBG completes its initialization when all tests pass. - 24 of 26 -

1.0.0 The AES test performs known answer tests (KAT) with a 128-bit key, one KAT for wrapping a key and another KAT for unwrapping a key, in order to test the AES forward and reverse functions. The Hash DRBG KAT test is also an SP 800-90Arev1, Section 11.3 health test for the instantiate and generate functions. The HMAC test is another KAT that tests the generation of an HMAC using a key and input data. Since the HMAC is implemented with SHA2-512, the HMAC KAT verifies the SHA2-512 capabilities of the module as well. After each test, all temporary values are cleared by overwriting their memory with zeroed bytes.

When new firmware is transferred to the module, the module will validate it using HMAC-SHA2-512. The HMAC-SHA2-512 implementation is validated by the HMAC-SHA2-512 KAT. After the test, all temporary values are cleared by overwriting their memory with zeroed bytes. The firmware is not applied if this test fails.

The hardware RBG continuously runs RCT and APT tests as random bits are generated to ensure the amount of entropy provided remains high. Additionally, the integrity check is run approximately every 30 minutes to detect any modification to the module’s code that may arise during its operation. This test happens in the background between user requests as to not interrupt the user experience; user requests may be briefly delayed by the test, and the test could be briefly delayed by user requests. Lastly, the DRBG continuously keeps track of requests and will put the module into the error state when the number of requests exceeds 248. With the module’s limited performance capabilities, such a condition would take several thousand years to occur even in extreme use cases.

Modules should be physically examined for signs of modifications or tampering, such as damage to the PCB or the epoxy protecting it. Any modules exhibiting such signs should not be put into service. The connections and interfaces needed to operate the KCM are specified in Section 3. - 25 of 26 -

1.0.0 Modules should also have their firmware version checked to ensure that the installed firmware has been validated against FIPS 140-3, updating the firmware to a validated version if necessary. The firmware version is checked by requesting it from the module using the module’s serial messaging protocol. The name, firmware version, and hardware version output by the module should match the information provided in Table 2. Updates to the module’s firmware are also done using its serial messaging protocol. Installing any firmware version not appearing in this Security Policy will result in the KCM operating in a non-compliant state. Modules will require that a user set up password to access approved services requiring authentication. Modules with existing user credentials can be zeroized to erase stored CSPs and allow a new user to establish their own login credentials. If a module is taken out of service or repurposed, it can be zeroized in order to erase all CSPs. The module requires no maintenance, and no administrator or non-administrator guidance is needed outside of the services available through the module’s serial messaging protocol. If users wish to securely destroy a module, it is recommended that the module be shredded into small pieces using an electronics shredder designed to destroy electronic storage mediums such as solid-state drives and hard disk drives.

The KCM is not designed for the mitigation of any attacks outside the scope of FIPS 140-3 Level 3. - 26 of 26 -