Kenwood Cryptographic Library

Certificate

Approved Algorithms (6)

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

flowchart LR
  %% Deterministic review-risk graph for Kenwood Cryptographic Library
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status Output<br/>Self-Test<br/>no authentication</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    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"]
    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"]
    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
  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 C3,C6 clue;
  class I3,I6 infer;
  class R3,R6 risk;
  class E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Kenwood Cryptographic Library
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Status Output<br/>Self-Test<br/>no authentication</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C3,C6 clueLow;

Security Policy, page by page

EF Johnson Technologies - Kenwood Cryptographic Library Author: John Tooker Software Version: 4.0 Date: 2/14/2024

TITLE: EF Johnson Technologies - Kenwood Cryptographic Library - FIPS 140-3 Non-Proprietary Security Policy

SOFTWARE VERSION: 4.0 DATE: 2/14/2024

Table of Contents - 2 of 15 -

TITLE: EF Johnson Technologies - Kenwood Cryptographic Library - FIPS 140-3 Non-Proprietary Security Policy

SOFTWARE VERSION: 4.0 DATE: 2/14/2024

describes the security level of each section in this document. Table 1: Security Levels The KCL is a multi-chip standalone FIPS 140-3 module for use on a variety of platforms when a hardware module is unavailable. It provides access to basic cryptographic algorithms with no long-term key storage within the library itself. It is a dynamically linked C++ library compiled for various consumer grade operating environments, see Table 2 below. - 3 of 15 -

TITLE: EF Johnson Technologies - Kenwood Cryptographic Library - FIPS 140-3 Non-Proprietary Security Policy

SOFTWARE VERSION: 4.0 DATE: 2/14/2024

Figure 1 diagrams the KCL’s relationship with an application that may use it. Device TOEPP Process Memory Space Process KCL API KCL Module KCL Loaded into Process Memory Memory Space KCL Module, Hash on File System Figure 1: A diagram showing the KCL loaded from disk into process memory for use The module itself consists of a single library file to be dynamically loaded by a process into its memory space. The library file has a companion hash file to verify its integrity when loaded by a process. Table 2 and Table 3 list the operating environments in which the KCL was tested or affirmed. Table 2: Tested Operational Environments - 4 of 15 -

TITLE: EF Johnson Technologies - Kenwood Cryptographic Library - FIPS 140-3 Non-Proprietary Security Policy

SOFTWARE VERSION: 4.0 DATE: 2/14/2024

Table 3: Vendor Affirmed Operational Environments The overall security rating of this module is Level 1. The module boundary consists of the device on which the KCL is installed with the binary file: “libkcl.so”. If multiple processes load the module, each will have its own, separate instance of the library in its own, separate memory. None of the data passed between the process and the KCL leaves the process’s memory space. The KCL only operates in a single mode of operation. This unnamed mode is entered automatically when the library is loaded. If a failure occurs, the library enters a failure mode which cannot be exited except by unloading and reloading the library. Other than the failure mode, the library does not operate in any degraded modes. Table 4 lists the security functions provided by the KCL. - 5 of 15 -

TITLE: EF Johnson Technologies - Kenwood Cryptographic Library - FIPS 140-3 Non-Proprietary Security Policy

SOFTWARE VERSION: 4.0 DATE: 2/14/2024

Table 4: Approved Algorithms No block diagram is required for understanding other than Figure 1, above. The security design and rules of operation are as follows. The physical interface is provided by the hosting platform, generally consumer-grade hardware and operating systems with a keyboard, monitor, mouse, screen, and/or touch screen as well as network and USB ports. The logical interface of the KCL is provided through the library’s Application Programming Interface (API). All data input, output, control and status are defined by this API. All data contained within the loaded library is erased when the error state is entered, or the library is unloaded. The DRBG must be seeded with a user-provided seed containing at least 384 bits of entropy as specified in scenario 2(b) of IG 9.3.A and there is no assurance of the minimum strength of generated SSPs. If fewer than 384 bits are supplied, the library will enter the error state. The library initializes itself atomically on load, including all self-tests and integrity checks. The only requirement is a file containing the hash of loaded library’s binary file be located next to it with the same name, but a *.hash.* extension. See Section 10 for a description of the self-tests that are run on load.

Table 5 lists the data that passes over the API of the KCL library categorized by logical interface. This encompasses all logical interfaces. There are no physical interfaces for the KCL itself. - 6 of 15 -

TITLE: EF Johnson Technologies - Kenwood Cryptographic Library - FIPS 140-3 Non-Proprietary Security Policy

SOFTWARE VERSION: 4.0 DATE: 2/14/2024

Table 5: Ports and Interfaces The only channel of communication with the library is in-process function calls to the library from the process that loaded it. This channel’s protection is enforced by the operating system and the process that loads the library and is not part of the library itself. If the library goes into the error state, the output interface return values are not available as exceptions will be thrown. - 7 of 15 -

TITLE: EF Johnson Technologies - Kenwood Cryptographic Library - FIPS 140-3 Non-Proprietary Security Policy

SOFTWARE VERSION: 4.0 DATE: 2/14/2024

The KCL modules supports the crypto-officer role only. There is no user or maintenance role. No authentication is required. Table 6: Roles, Service Commands, Input and Output There are no ways to bypass any of these capabilities. There is no self-initiated cryptographic output capability. No external software or firmware may be loaded into the library. When seeding the DRBG, at least 48 bytes of entropy must be provided; otherwise, it will enter the error state. - 8 of 15 -

TITLE: EF Johnson Technologies - Kenwood Cryptographic Library - FIPS 140-3 Non-Proprietary Security Policy

SOFTWARE VERSION: 4.0 DATE: 2/14/2024

The list of security services and their approved security functions can be found in Table 7. Access rights legend: 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. For API return code indicators, the successful completion of a service is an implicit indicator for the use of an approved service. If the service does not complete successfully, an exception is thrown, and the module enters an error state. - 9 of 15 -

TITLE: EF Johnson Technologies - Kenwood Cryptographic Library - FIPS 140-3 Non-Proprietary Security Policy

SOFTWARE VERSION: 4.0 DATE: 2/14/2024

Table 7: Approved Services - 10 of 15 -

TITLE: EF Johnson Technologies - Kenwood Cryptographic Library - FIPS 140-3 Non-Proprietary Security Policy

SOFTWARE VERSION: 4.0 DATE: 2/14/2024

The installation of the module simply requires placing it and its corresponding hash file on the file system and loading the library in a compiled C++ program. There is no authentication mechanism. The module itself contains no data when not loaded (no data is persisted when the module unloads). The KCL automatically performs an integrity check on itself when it is loaded. It looks for a file next to the library file that contains the SHA2-512 hash of the library file itself. It then computes the SHA2-512 hash of itself. If the two match, the integrity check passes. Otherwise, the library enters a failed state and any calls made to the library will not return normally but throw an exception. The operator can initiate this integrity check on demand by loading the library. The library comes in the form of a single binary file. The filename is libkcl.so on Linux (including Android). This module is not open source.

The KCL operates in a modifiable environment. The operating system is in charge of guarding the memory of the KCL while it is loaded. No special rules, settings or restrictions are needed of the operational environment. This is how Level 1 security is satisfied. The library stores no keys/SSPs when unloaded. The operating systems and tested platforms can be found in Table 2 above.

The KCL is implemented completely in software such that physical security is provided solely by the host platform. Therefore, the physical security section of FIPS 140-3 is not applicable. No steps to mitigate non-invasive attacks have been made. - 11 of 15 -

TITLE: EF Johnson Technologies - Kenwood Cryptographic Library - FIPS 140-3 Non-Proprietary Security Policy

SOFTWARE VERSION: 4.0 DATE: 2/14/2024

The sensitive security parameters (SSPs) managed by the KCL are enumerated in Table 8. Table 8: Sensitive Security Parameters (SSPs) - 12 of 15 -

TITLE: EF Johnson Technologies - Kenwood Cryptographic Library - FIPS 140-3 Non-Proprietary Security Policy

SOFTWARE VERSION: 4.0 DATE: 2/14/2024

The approved random bit generator is a SHA-512 DRBG using certification A2280. The source of entropy is provided by the operator external to the KCL module. The state of the DRBG exists in volatile memory only and is cleared when the module is unloaded or zeroized. An AES key is stored in volatile memory only and are cleared when the module is unloaded or zeroized. This AES key cannot be directly generated internal to the module, but the DRBG may be used to generate them. If the DRGB is used to generate an AES key, then the key must be the unmodified output of the DRBG. This AES key cannot be exported, only loaded for use. The zeroize function is invoked using the API. When invoked, all keys and sensitive security parameters are cleared from memory. As the module is implemented in C++, cleared memory is released back to the OS, which takes responsibility for clearing the data so other processes cannot observe it (just as it protects that memory from being accessed by other processes while it is in use by the library). The module is always in approved mode. Keys stored in memory are not protected within the module and rely on the operating system’s process memory protection. Unloading the library will zeroize all SSPs; this procedural zeroization method is under the control of the operator. - 13 of 15 -

TITLE: EF Johnson Technologies - Kenwood Cryptographic Library - FIPS 140-3 Non-Proprietary Security Policy

SOFTWARE VERSION: 4.0 DATE: 2/14/2024

The module runs self-tests automatically on load. The following tests are performed in the order listed in Table 9. Certain tests rely on and therefore test certain services. Table 9: Self-Tests Performed by the KCL AES test performs known answer tests (KAT). The DRBG test is also a KAT. Finally, the integrity check is done by calculating the SHA-512 hash of the library itself on disk against a file with the expected hash. After each test, all temporary values are cleared. There is no condition where these tests are repeated once the module is loaded. If a test fails, the module enters an error state. Subsequent function calls into the module will not return normally, rather, an exception is thrown. The module operator cannot initiate self-tests other than (re)loading the module. The DRBG continuously keeps track of requests and will put the library into the error state when the number of requests exceeds 248.

TITLE: EF Johnson Technologies - Kenwood Cryptographic Library - FIPS 140-3 Non-Proprietary Security Policy

SOFTWARE VERSION: 4.0 DATE: 2/14/2024

There is only a single error state, it is entered when a self-test fails or the reseed counter is triggered in the DRBG. The two status indicators are: 1) calling the Get Status service, which will return a Boolean indicating the error state, and 2) calling any other service will throw an exception if we are in the error state rather than returning a normal value.

The module’s life cycle starts when it is loaded into memory by a process, and it ends when the module is unloaded. There are no maintenance requirements or administrator or non-administration guidance other than the module’s API itself.

The KCL is not designed for the mitigation of any attacks outside the scope of FIPS 140-3 Level 1. - 15 of 15 -