VMware’s Linux Kernel Cryptographic Module

Certificate

Approved Algorithms (37)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for VMware’s Linux Kernel 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>Recovery</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Symmetric<br/>Ciphers<br/>Installation and initialization</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>IPSEC<br/>HTTPS<br/>no library/version identified</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["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    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?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    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["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    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
  C5 --> I5 --> R5 --> E5
  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,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for VMware’s Linux Kernel 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>Recovery</i><br/>src: text:keyword"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Symmetric<br/>Ciphers<br/>Installation and initialization</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>IPSEC<br/>HTTPS<br/>no library/version identified</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,C5,C6 clueLow;
  class C3 clueHigh;

Security Policy, page by page

Broadcom Inc. VMware’s Linux Kernel Cryptographic Module FIPS 140-3 Non-Proprietary Security Policy

This is a non-proprietary Cryptographic Module Security Policy for the VMware's Linux Kernel Cryptographic Module 5.0.0 from Broadcom Inc. This Security Policy describes how the VMware's Linux Kernel Cryptographic Module 5.0.0 meets the security requirements of Federal Information Processing Standards (FIPS) Publication 140-3, which details the U.S. and Canadian Government requirements for cryptographic modules. More information about the FIPS 140-3 standard and validation program is available on the National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security (CCCS), a branch of the Communications Security Establishment (CSE), Cryptographic Module Validation Program (CMVP) website at https://csrc.nist.gov/projects/cryptographic-module-validation-program. This document also describes how to run the module in a secure Approved mode of operation. This policy was prepared as part of the Software Level 1 FIPS 140-3 validation of the module. The VMware's Linux Kernel Cryptographic Module 5.0.0 is also referred to in this document as the “Module.” It also provides instructions to individuals and organizations on how to deploy or operate the product in a secure approved mode. This document has been written for the following audiences:

• The FIPS testing laboratory.
• The Cryptographic Module Validation Program (CMVP).
• Anyone wishing to deploy this Module in a FIPS compliant manner.

The module has been validated at the FIPS 140-3 section levels shown in the table below. Table 1: Security Levels N/A N/A N/A © 2024 Broadcom Inc.

Purpose and Use: The VMware’s Linux Kernel Cryptographic Module is a software cryptographic module with a multiple-chip standalone embodiment. The overall security level of the module is 1. As a software module, the module must rely on the physical characteristics of the host system. The physical perimeter of the cryptographic module is defined by the hard enclosure around the host system on which it runs. The module supports the physical interfaces of the Dell PowerEdge R650 Server. These interfaces include the integrated circuits of the system board, processor, RAM, hard disk, device case, power supply, and fans. See Figure 1 below for a hardware block diagram of the Dell PowerEdge R650 Server. Module Type: Software Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: As a software module, the module must rely on the physical characteristics of the host system. The physical perimeter of the cryptographic module is defined by the hard enclosure around the host system on which it runs. The module supports the physical interfaces of the Dell PowerEdge R650 Server. These interfaces include the integrated circuits of the system board, processor, RAM, hard disk, device case, power supply, and fans. See Figure 1 below for a hardware block diagram of the Dell PowerEdge R650 Server. © 2024 Broadcom Inc.

Tested Module Identification

• Hardware: N/A for this module. Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): 5.0.0 Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Operational Environments - Software, Firmware, Hybrid: © 2024 Broadcom Inc.

4.0 4.0 5.0 5.0 Table 3: Tested Operational Environments - Software, Firmware, Hybrid 8.0 8.0 8.0 8.0 5.0.0 5.0.0 5.0.0 5.0.0 Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: Table 4: Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate.

There are no excluded components. Modes List and Description: NonApproved NonApproved © 2024 Broadcom Inc.

Table 5: Modes List and Description The module supports an FIPS 140-3 Approved mode and non-Approved mode of operation. The module will be in Approved mode when all pre-operational self-tests have completed successfully, and only Approved services are invoked, and the success API return indicator is provided. The module implements non-Approved Algorithms Not Allowed in the Approved Mode of Operation. When a non-Approved security function is invoked, the module will no longer be in the Approved mode of operation. A status indicator in the form of an API return code and log entry indicating the service name and “non-approved” will be provided when the module enters and exits the non-Approved mode of operation.

Approved Algorithms: © 2024 Broadcom Inc.

Table 6: Approved Algorithms The module implements the approved algorithms listed in the table above. Vendor-Affirmed Algorithms: N/A for this module. The module does not implement any vendor-affirmed algorithms. Non-Approved, Allowed Algorithms: N/A for this module. The module does not implement any non-Approved Algorithms Allowed in the Approved Mode of Operation. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. The module does not implement any Non-Approved Allowed in the Approved Mode of Operation with No Security Claimed. Non-Approved, Not Allowed Algorithms: Table 7: Non-Approved, Not Allowed Algorithms The module does implement the non-approved algorithms listed in the table above.

AsymKeyPairKeyGen AsymKeyPairKeyVer © 2024 Broadcom Inc.

Table 8: Security Function Implementations The module implements the security functions listed in the table above.

IG Compliance:

• Per IG C.C, all FIPS 202 functions are CAVP tested in all operating environments - see cert. #A4971. Per IG C.F, for RSA Signature and key generation, all 2048, 3072, and 4096 modulus sizes are CAVP tested in all operating environments - see cert. #A4971. Per IG C.H, GCM IVs Construct the IV in compliance with the provisions of a peer-topeer industry standard protocol whose mechanism for generating the IVs for AES-GCM has been reviewed and deemed acceptable. GCM IV internally generated used by the IPsec-v3 protocol, as described in RFC 4106 following scenario 1 b. The AES GCM is generated internally using SP800-38D section 8.2.1. Per IG C.H scenario 1, AES GCM with internal IV generation in Approved mode is in compliance with RFC 4106 and shall only be used in conjunction with the IPsec stack of the kernel. Per IG C.I, AES-XTS keys are generated by the calling application. Additionally, the module implements a conditional AES-XTS duplicate key test which checks that Key_1 ≠ Key_2. Per IG D.R, Hash DRBG and HMAC DRBG use hash function SHA2-256 and SHA2-512 excluding SHA2-224 and SHA2-384.

The following entropy sources are available to the module and have been tested to NIST SP800-90B. 256 bits of entropy input are provided to the module's DRBG from the CPU Jitter entropy source certified by ESV #E115. The VMware CPU Jitter implementation generates an output that is considered to have full entropy. A request for 256 bits of entropy results in 256 bits of entropy per output sample, or full entropy. Table 9: Entropy Certificates

NonPhysical Table 10: Entropy Sources

The module implements asymmetric key generation using ECDSA as per FIPS 186-4. The module does perform key agreement primitives on behalf of the calling process but does not establish keys into the module.

The module does not implement any industry protocols.

Table 11: Ports and Interfaces © 2024 Broadcom Inc.

The table above lists the module's physical ports and logical interfaces.

N/A for this module. The module does not support an authentication mechanism.

Table 12: Roles There are two roles in the module that operators may assume: a Cryptographic Officer (CO) role and a User role. Roles are assumed implicitly through the execution of either a CO or User service. The module does not support an authentication mechanism. Each role and their corresponding services are detailed in the sections below. The CO and User roles share many services, including encryption, decryption, and random number generation services. The CO performs installation and initialization, show status, selftests on demand, and key zeroization services. Table 7 below describes the Approved CO and User roles.

Perform preoperational r N/A N/A © 2024 Broadcom Inc.

r G,R G,R W W,E W,E W,E Table 13: Approved Services The table above lists the approved services available to module operators. Access rights are indicated using the following notation:

• 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 14: Non-Approved Services The module implements the non-approved services listed in the table above.

The module does not implement external software loading.

The integrity of the module’s cryptographic boundary is verified by a hash generated by HMACSHA2-256 digest. The software integrity test is performed by VMware’s Linux Kernel Cryptographic Module. The module automatically invokes separate KATs for the HMAC and SHA2-256 algorithms then the module will invoke the HMAC-SHA2-256 integrity test preoperationally during the boot sequence.

An operator can initiate the integrity test on-demand by rebooting the OS. If an integrity test fails, the module will enter the critical error state.

Type of Operational Environment: Modifiable How Requirements are Satisfied: The VMware’s Linux Kernel Cryptographic Module 5.0.0 comprises a software cryptographic library that executes in a modifiable operational environment. The cryptographic module has control over its own SSPs. The process and memory management functionality of the host © 2024 Broadcom Inc.

device’s OS prevents unauthorized access to plaintext, private and secret keys, intermediate key generation values and other SSPs by external processes during module execution. The module only allows access to SSPs through its well-defined API. The operational environments provide the capability to separate individual application processes from each other by preventing uncontrolled access to CSPs and uncontrolled modifications of SSPs regardless of whether this data is in the process memory or stored on persistent storage within the operational environment. Processes that are spawned by the module are owned by the module and are not owned by external processes/operators.

The cryptographic module is a software module and does not include physical security mechanisms. Therefore, per ISO/IEC 19790:2021 section 7.7.1, requirements for physical security are not applicable.

This section is not applicable. There are currently no approved non-invasive mitigation metrics defined at the time of writing. (Ref: ISO/IEC 19790:2012 Annex F).

Table 15: Storage Areas All SSPs are only stored in memory.

Table 16: SSP Input-Output Methods All SSPs are passed to the module via a well-defined API.

Table 17: SSP Zeroization Methods There is no mechanism within the module boundary for the persistent storage of keys and CSPs. Maintenance, including protection and zeroization, of any keys and CSPs that exist outside the module’s boundary are the responsibility of the end-user. For the zeroization of keys in volatile memory, module operators can reboot the OS.

n SHA2256,SHA2512 n n © 2024 Broadcom Inc.

n Table 18: SSP Table 1 © 2024 Broadcom Inc.

Table 19: SSP Table 2 The module manages the SSPs, and keys listed in the table above.

The Module performs both pre-operational and conditional self-tests. Once invoked, the Module will not perform functions or services until the self-test(s) has been completed. The following sections list the self-tests performed by the Module, their expected error status, and any error resolutions.

Table 20: Pre-Operational Self-Tests If any of the pre-operational self-tests fail, the module enters the critical error state, and an error message is logged. In this state, cryptographic operations are halted, and the module inhibits all data output from the module as the API interface is disabled. In order to attempt to exit the error state, the module must be restarted by rebooting the OS. If the error persists, the module must be reinitialized. Pre-operational self-tests are automatically performed by the module at module initialization or when the module powers on. The list of pre-operational self-tests that follows may also be run on-demand when the CO reboots the Operating System. The Module performs the required HMAC and SHS Cryptographic Algorithm Self-Tests (CASTs) that are required for the subsequent software integrity tests. During the execution of self-tests, cryptographic functions and data output from the module are inhibited. The VMware’s Linux Kernel Cryptographic Module performs a software integrity check (HMAC with SHA2-256 Integrity Test) preoperationally.

AES-CBCCS3 AESCFB128 © 2024 Broadcom Inc.

KAS-ECCSSC Sp80056Ar3 KAS-ECCSSC Sp80056Ar3 SP800Hash_DRBG, Table 21: Conditional Self-Tests Conditional self-tests are performed by the Module during operation when specific conditions occur. The Module performs the conditional self-tests listed in the table above. Table 22: Pre-Operational Periodic Information © 2024 Broadcom Inc.

Table 23: Conditional Periodic Information Periodic Self-Tests can be executed by rebooting the OS.

Table 24: Error States If any of the power-up self-tests fail, the module enters the critical error state, and an error message is logged. In this state, cryptographic operations are halted, and the module inhibits all data output from the module as the API interface is disabled. In order to attempt to exit the error state, the module must be restarted by rebooting OS. If the error persists, the module must be reinitialized.

Operator initiated Self-Tests can be executed by rebooting the OS.

Prior to the secure installation of Photon OS, the CO shall prepare the virtual environment required to securely operate it. This includes installing VMware vSphere Hypervisor (ESXi) 8.0 (see vSphere Installation and Setup). Both virtual environments require the Dell PowerEdge R650 server to run the installation. The tar archive containing VMware's Linux Kernel Cryptographic Module prior to build time, contains the HMAC-SHA2-256 digest:

• ea4629447ae187005ca7a12a75220f283cde801c160aa6bfc74f63e9f9409119 The CO will then install Photon OS as the guest OS in the virtual machine and verify the full canister version as “5.0.0.” © 2024 Broadcom Inc.

The cryptographic functionality of VMware’s Linux Kernel Cryptographic Module comes installed with Photon OS and cannot be “unloaded”. To run Photon OS kernel in an Approved mode, the Crypto Officer shall perform following actions using root access on kernel command line interface:

1. Edit the “/boot/photon.cfg” kernel file and append ‘fips=1’ to the “photon_cmdline” line
2. Reboot the OS using the “reboot” command.
3. To check the Approved mode, run “cat /proc/sys/crypto/fips_enabled”, which will show ‘1’ when Approved mode is enabled or ‘0’ when Approved mode is not enabled.
4. To verify that the OS is running certified version of VMware’s Linux Kernel Cryptographic Module run command “dmesg | grep canister”. It should print following output: • FIPS (fips_integrity_init): canister 5.0.0 found (based on 6.1.75-2.ph5-secure) • FIPS canister HMAC: o • ea4629447ae187005ca7a12a75220f283cde801c160aa6bfc74f63e9f9409119 FIPS canister verification passed!

Installation and operation of the VMware’s Linux Kernel Cryptographic Module requires the proper installation of Photon OS. There are no additional steps that must be performed to use the module correctly. There are no known CVEs with this module. The CO should ensure that the operating environment is patched and updated in a timely fashion to reduce exposure to security vulnerabilities.

There is no additional guidance for non-administrators.

This section is not applicable. The module does not claim to mitigate any attacks beyond the FIPS 140-3 Level 1 requirements for this validation. © 2024 Broadcom Inc.

Referenced URLs

• https://csrc.nist.gov/projects/cryptographic-module-validation-program