Linux Kernel FIPS Object Module (KFOM) Cryptographic Module

Certificate

Approved Algorithms (44)

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

flowchart LR
  %% Deterministic review-risk graph for Linux Kernel FIPS Object Module (KFOM) Cryptographic Module
  %% 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>status output<br/>Show Status<br/>self-test</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</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 Linux Kernel FIPS Object Module (KFOM) Cryptographic Module
  %% 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>status output<br/>Show Status<br/>self-test</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</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

Cisco Systems, Inc. FIPS 140-3 and ISO/IEC 19790 Non-Proprietary Security Policy For Linux Kernel FIPS Object Module Cryptographic Module Last Updated: May 31, 2024, Version 1.1 Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA

Table of Content List of Tables List of Figures

Module Cryptographic Module (hereinafter referred to as KFOM or Module) firmware version 1.0. The following details how this module meets the security requirements of FIPS 140-3, SP The security requirements cover areas related to the design and implementation of a cryptographic module. These areas include cryptographic module specification; cryptographic actual security levels for each area of the cryptographic module. Table 1 - Security Levels The Cisco Linux Kernel FIPS Object Module (KFOM) Cryptographic Module is a firmware hybrid cryptographic library in a multi-chip standalone embodiment that allows for Linux kernel applications to use approved algorithms. It does not implement any security protocols nor create any cryptographic keys. Instead, it only provides Linux kernel applications access to approved algorithms. The module is intended to run on the UCS C220 M5 and MX68W host platforms or any generalpurpose computer, so the physical perimeter of the module is the tested platforms. The cryptographic module comprises the Cisco Linux Kernel FIPS Object Module (KFOM) Cryptographic Module (Firmware Version: 1.0) which is a kernel object file linux_kfom_1_0_0.ko and the processor (Hardware Version: ARMv8 Cortex-A53, Intel Xeon Gold 6138) (only for algorithm acceleration) which only operates in the approved mode of operation which is set at manufacture. The module is validated according to FIPS 140-3 at overall security level 1. Please refer to Table 1 above for the individual areas.

Cisco UCS C220 M5 unifies computing, networking, management, virtualization, and storage access into a single integrated architecture, enabling end-to-end server visibility, management, and control in both bare metal and virtualized environments. The module has been tested on the following Operational Environments. Table 2 - Tested Operational Environments Figure 1 - UCS C220 M5 Front View Figure 2 - UCS C220 M5 Rear View Figure 3 - MX68CW Front View Figure 4 - MX68CW Rear View

Figure 5 - MX68CW Side View Please note that Figures 1-5 are the tested platforms and not the module itself. Figure 6 - Intel Xeon Gold 6138 Figure 7 - ARMv8 Cortex-A53 The following table lists the Vendor affirmed operational environment: Table 3 - Vendor Affirmed Operational Environments

The cryptographic module maintains validation compliance when operating on the operating system/mode specified in Table 2 above and on the validation certificate as well as for those specified in Table 3 above (vendor affirmed). For the latter, the CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when ported to an operational environment which is not listed on the validation certificate. Cryptographic Boundary The KFOM cryptographic module (red box) is a non-modifiable, multi-chip standalone firmware hybrid cryptographic module providing cryptographic support to the Kernel which takes data in and out from the host application via the API (libkcapi) feeding into the kernel. All processing is done on the listed processors in Table 2 above. The KFOM performs no communications other than with the consuming application. The block diagram below shows the Tested Operational Environment’s Physical Perimeter (TOEPP) being defined as the physical perimeter of the tested platform enclosure around which everything runs. The cryptographic boundary is the KFOM (red box) and the processors (ARMv8 Cortex-A53, Intel Xeon Gold 6138) with PAA. Tested Platform TOEPP Host Platform libkcapi Application Data/Control Data/Control/Status Input Output Kernel Space KFOM Data/Control Input Kernel Static kernel API (Firmware Components component interfaces) Data/Control/Status Registers (Hardware Output component interfaces Processor (PAA) Figure 8 - Block Diagram Firmware component interfaces include: Data Input, Data Output, Control Input and Status Output interfaces.

Hardware component interfaces include: Input, Output, Control Input and Status registers. By design, the module is only able to support approved mode of operation. Once the module is configured in the approved mode of operation by following the steps in Section 11 of this document, the module will be ready for approved mode of operation. The module doesn’t claim Approved security functions:

Table 4 - Approved Algorithms Notes:

• Algorithm Cert. #A1182 was tested for the OE with PAA
• Algorithm Cert. #A1185 was tested for the OE with PAA
• There are some algorithm modes that were tested but not implemented by the module. Only the algorithms, modes, and key sizes that are implemented by the module are shown in this table.
• Use of external IV with GCM is exclusively permitted for decryption operations or where the GCM is used to support the protocol specific implementation used to protect connections to the calling applications. The GCM IV is generated per FIPS 140-3 IG C.H technique #3. The counter portion of the IV is set by the module within its cryptographic boundary. When the IV exhausts the maximum number of possible values for a given session key, the first party, client or server, to encounter this condition will trigger a handshake to establish a new encryption key. In case the module’s power is lost and then restored, a new key for use with the AES GCM encryption/decryption shall be established.

• The check for Key_1 ≠ Key_2 is done before using the keys in the XTS-AES algorithm to process data and is in accordance with IG C.I requirements. The module’s physical perimeter encompasses the case of the tested platform mentioned in Table 2. The module provides its logical interfaces via Application Programming Interface (API) calls. The logical interfaces provided by the module are mapped onto the FIPS 140-3 interfaces (data

Table 5 - Ports and Interfaces Please note that the module does not support control output interface and is not applicable for this module.

The module supports Crypto Officer (CO) role. The cryptographic module does not provide any authentication methods. The module does not allow concurrent operators. The Crypto Officer is implicitly assumed based on the service requested. The module provides the following services Table 6 - Roles, Service Commands, Input and Output The table below lists all approved services that can be used in the approved mode of operation. The abbreviations of the access rights to keys and SSPs have the following interpretation: 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 = Zeroise: The module zeroises the SSP. N/A = The service does not access any SSP during its operation.

$?` $?` $?` $?` If `echo $?` returns 0, the approved service executed successfully. Any other value = not successful.

Integrity Technique The Module is provided in the form of binary executable code. To ensure firmware security, the Module is protected by HMAC-SHA2-512 (HMAC Certs. #A1182 or #A1185) algorithm. At Module’s initialization, the integrity of the runtime executable is verified using a HMAC-SHA2-

512 digest which is compared to a value computed at build time. If at the load time the MAC

does not match the stored, known MAC value, the Module would enter an Error state with all crypto functionality inhibited. Integrity Test On-Demand The integrity test is performed as part of the Pre-Operational Self-Tests. It is automatically executed at power-on. The operator can initiate the integrity test on demand by power cycling the host platform. The module is a kernel object file linux_kfom_1_0_0.ko

The module is operated in a non-modifiable operational environment per FIPS 140-3 level 1 specifications. The module is installed within the product for use with the kernel, and the linux kernel cannot be modified. The operating systems and tested platforms can be found in Table 2. application is serving multiple clients. The module’s firmware version running on each tested

Per ISO/IEC 19790 and FIPS 140-3 classification, this is a multi-chip standalone cryptographic module. KFOM 1.0 is a firmware hybrid module and runs on a production grade chassis.

This section is not applicable as the cryptographic module does not implement any non-invasive attack mitigation techniques.

The following table summarizes the Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module.

Table 8 - SSPs Even though the module does implement an approved random number generator, it is not used by the module for the generation of the cryptographic keys. All Cryptographic keys are externally generated and imported to the working space assigned by the kernel. The module uses approved DRBG for the generation of random strings and passes them to the calling application only upon their request. The cryptographic module is passed a pointer to the cryptographic keys as API parameters, associated by memory location. The application calling the cryptographic module passes keys in plaintext within the physical perimeter. The module does not perform storage of keys. All SSPs can be zeroized by power cycling the host.

Table 9 - Non-Deterministic Random Number Generation Specification

When the Linux kernel is setup properly the self-test solution is that only the kernel module, which has been signed and verified can load in cryptographic algorithms. Once the KFOM is loaded, first the self-test for the algorithm used in the firmware integrity test is run and then the actual firmware integrity test of the module runs for the KFOM, then all the self-tests for the algorithms are run. If a self-test fails, the result from the Linux Crypto Test Manager is a failure. This means the algorithm will not have the self-test flag set. The presence of self-test flag allows the Linux Crypto Framework to utilize the algorithm. A successful log message is provided by the module after the successful completion of the selftests. If an error occurs to a valid approved algorithm during the self-test, the module enters hard error state, and the Linux kernel will print an error message to the console and data output from the data output interface is inhibited. This results in the system shutting down.

Pre-Operational Self-tests

• Pre-operational firmware integrity test
• Firmware Integrity Test (HMAC SHA2-512) The Module conducts HMAC-SHA2-512 KAT self-test before the integrity test is performed. Conditional Self-Test
• Conditional Cryptographic Algorithm Self-Tests (CASTs)
• AES CBC 128-bit Encrypt KAT
• AES CBC 192-bit Encrypt KAT
• AES CBC 256-bit Encrypt KAT
• AES CBC 128-bit Decrypt KAT
• AES CBC 192-bit Decrypt KAT
• AES CBC 256-bit Decrypt KAT
• AES CTR 128-bit Encrypt KAT
• AES CTR 192-bit Encrypt KAT
• AES CTR 256-bit Encrypt KAT
• AES CTR 128-bit Decrypt KAT
• AES CTR 192-bit Decrypt KAT
• AES CTR 256-bit Decrypt KAT
• AES ECB 128-bit Encrypt KAT
• AES ECB 192-bit Encrypt KAT
• AES ECB 256-bit Encrypt KAT
• AES ECB 128-bit Decrypt KAT
• AES ECB 192-bit Decrypt KAT
• AES ECB 256-bit Decrypt KAT
• AES CCM 128-bit Encrypt KAT
• AES CCM 192-bit Encrypt KAT
• AES CCM 256-bit Encrypt KAT
• AES CCM 128-bit Decrypt KAT
• AES CCM 192-bit Decrypt KAT
• AES CCM 256-bit Decrypt KAT
• AES XTS 128-bit Encrypt KAT
• AES XTS 256-bit Encrypt KAT
• AES XTS 128-bit Decrypt KAT
• AES XTS 256-bit Decrypt KAT
• AES CBC CS 128-bit Encrypt KAT
• AES CBC CS 128-bit Decrypt KAT
• AES GCM 128-bit Encrypt KAT
• AES GCM 192-bit Encrypt KAT
• AES GCM 256-bit Encrypt KAT
• AES GCM 128-bit Decrypt KAT
• AES GCM 192-bit Decrypt KAT
• AES GCM 256-bit Decrypt KAT
• AES CMAC 128-bit Encrypt KAT
• AES CMAC 128-bit Decrypt KAT
• DRBG AES CTR 128-bit KAT (Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG AES CTR 192-bit KAT(Health Tests: Generate, Reseed, Instantiate functions

per Section 11.3 of SP 800-90Arev1)

• DRBG AES CTR 256-bit KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG HMAC SHA-1 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG HMAC SHA2-256 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG HMAC SHA2-384 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG HMAC SHA2-512 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG Hash SHA-1 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG Hash SHA2-256 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG Hash SHA2-384 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• DRBG Hash SHA2-512 KAT(Health Tests: Generate, Reseed, Instantiate functions per Section 11.3 of SP 800-90Arev1)
• HMAC-SHA-1 KAT
• HMAC-SHA2-224 KAT
• HMAC-SHA2-256 KAT
• HMAC-SHA2-384 KAT
• HMAC-SHA2-512 KAT
• SHA-1 KAT
• SHA2-224 KAT
• SHA2-256 KAT
• SHA2-384 KAT
• SHA2-512 KAT Periodic/On-Demand Self-Tests The module performs on-demand self-tests initiated by the operator, by powering off and powering the module back on through power cycling the host. The full suite of self-tests is then executed. The same procedure may be employed by the operator to perform periodic self-tests. Self-Test Failure Handling KFOM reaches the critical error state when any self-test fails. This failure results in kernel panic. Upon test failure, the module will set an internal flag and enter a critical error state, and a message will be logged to dmesg. In this state, the module will no longer perform cryptographic services or output data over the data output interface. To recover, the module must be re-instantiated by the calling application (through power cycling the host platform). If the pre-operational self-tests complete successfully, then the module can resume normal operations. If the module continues to experience self-test failures after reinitializing, then the module will not be able to resume normal operation.

Secure Operations The tested operating systems segregate user processes into separate process spaces. Each process space is an independent virtual memory area that is logically separated from all other processes by the operating system firmware and hardware. The module functions entirely within the process space of the process that invokes it, and thus the module runs on a single user mode of operation. The module is copied into the tested operational environments prior to shipping. The operator needs to load the module per the instructions below, and power cycle the platform. At this point, the pre-operational tests are run, followed by the conditional cryptographic algorithm self-tests. Now KFOM will be in approved mode. KFOM Loading: insmod linux_kfom_1_0_0.ko config_file=kfom_priorities ko_file=linux_kfom_1_0_0.ko The operator can verify that the module is in approved mode by executing the “Show Status” service command. If the module outputs name and version, it can be considered that the module is running in approved mode. The guidance document – readme.rtf version 1.0, can be obtained by contacting the vendor using the contact information (posted on the validation certificate).

The requirements under INCITS+ISO+IEC 19790+2012[2014], section 7.12 “Mitigation of other attacks”, are not applicable to the module since the module currently doesn’t support any mitigation of other attacks services.