VMware VMkernel Cryptographic Module 2.0

Certificate

Approved Algorithms (13)

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

flowchart LR
  %% Deterministic review-risk graph for VMware VMkernel Cryptographic Module 2.0
  %% 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/>Show Status</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>kernel<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 VMware VMkernel Cryptographic Module 2.0
  %% 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/>Show Status</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>kernel<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

VMware VMkernel Cryptographic Module 2.0 Document Version: 1.2

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document Table of contents

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document VMkernel Cryptographic Module 2.0 (software version 2.0), herein after referred as the module, the cryptographic module, or the software module, meets overall Security Level 1 requirements. Table 1 below lists the level of validation for each area in the FIPS PUB 140-3. Table 1 –Security Levels

VMware VMkernel Cryptographic Module 2.0

• Security Policy Document Section 2. Cryptographic Module Specification The software module consists of two libraries running in a modifiable operating environment, cryptoLoader and crypto_fips. The software version of the module is 2.0. For validation purposes, the module is tested in the following operational environment: Table 2
• Tested Operational Environments The module, a set of object files/libraries, is intended to provide cryptographic services to Vmware’s ESXi platform. Table 3 below lists all security functions in the module for use in approved services. Vendor Affirmed Operational Environments have not been claimed. Table 3
• Approved Algorithms

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document The module does not implement and use any non-approved algorithms and thus does not support the following: Non-Approved Algorithms Allowed in the Approved Mode of Operation, Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed and Non-Approved Algorithms Not Allowed in the Approved Mode of Operation. The cryptographic module runs only in an Approved mode of operation. The module does not support a non-Approved mode of operation. Below is a block diagram showing the location of the module components with respect to the ESXi operating system and the applications which interact with the module. The diagram includes the cryptographic boundary containing the module components (red dotted outline) and also depicts the physical perimeter of the module (the GPC, i.e. the TOEPP).

VMware VMkernel Cryptographic Module 2.0

• Security Policy Document Figure 1
• Cryptographic Boundary Overall security design and the rules of operation When ESXi boots, the cryptoloader is called. This component self-tests its internal implementation of SHS (FIPS 180-4) and HMAC (FIPS PUB 198-1), which are both used in the pre-operational integrity test. Cryptoloader reads the entire crypto_fips file and performs the preoperational integrity test on it as well. If it passed, cryptoloader calls the ESXi kernel to load crypto_fips as a kernel module. Crypto_fips provides cryptographic services as described in the Approved Services table. Authentication and access to SSPs are controlled by the ESXi operating system. The module supports a single user role, Crypto Officer. This role is assumed implicitly by using the module. The module is operated by calling the API functions and inputting the appropriate parameters. If the module enters the error state, the state is cleared by rebooting the ESXi operating system to reload the module. To unload or shutdown the module, the ESXi operating system must be shutdown. The module also supports internal IV generation using the module’s approved DRBG. The IV is at least 96 bits in length per [SP800-38D] Section 8.2.2 and [FIPS140-3_IG] C.H Scenario 2. In each case, in the event that the Module power is lost and restored the user must ensure that the AES GCM encryption/decryption keys are re-distributed. The module does not support persistent storage of SSPs.

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document The module complies with IG C.I by explicitly checking that Key_1 ≠ Key_2 before using the keys in the XTS-AES algorithm to process data with them.

VMware VMkernel Cryptographic Module 2.0

• Security Policy Document Section 3. Cryptographic Module Interfaces Table 4 below maps the logical interfaces of the module with the ISO/IEC 19790:2012 defined logical interfaces: Table 4
• Ports and Interfaces The physical ports of the cryptographic module are the same as the appliance on which it is executing. The logical interfaces are C-language based Application Program Interfaces (APIs). The Data Input Interface corresponds to the input arguments of the API functions that take data to process cryptographic operations. The operation can be encryption or decryption, hashing, MAC generation or receiving seeding material for the DRBG. Similarly, Data Output interface consists of the output parameter of the API that holds the result of the operation, such as ciphertext, a MAC or a digest value. The Control Input interface is the API arguments that specifies control over input data (ex. Length of plaintext or key length). The Status Output includes the return values. The return values are associated with success or error code underlying appliance on which the module runs.

VMware VMkernel Cryptographic Module 2.0

• Security Policy Document Section 4. Roles, Services, and Authentication The VMware VMkernel Cryptographic Module 2.0 meets all FIPS 140-3 level 1 requirements for Roles, Services, and Authentication. The module implements only the Crypto Officer (CO) role. The CO is responsible for initializing and running the module. Table 5 lists the services offered to the CO role. Table 5
• Roles, Service Commands, Input and Output The module is a level 1 software module and does not implement any authentication. The calling application implicitly assumes the Crypto Officer role when the ESXi operating system allows access to the module. 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 9eroizes the SSP.

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document The module does not implement any non-approved services.

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document Section 5. Software/Firmware Security For the purposes of a FIPS 140-3 level 1 validation, the cryptographic module consists of two object files, cryptoloader and crypto_fips. The module performs no communications other than with the consuming host application (the process that invokes the module services via the module’s API), which can be considered as the host for the module. The module runs a HMAC-SHA2-256 integrity verification during initialization by the host application. The module also runs the Known Answer Test (KAT) for HMAC-SHA2-256 prior to running the integrity check. The CO can reload the module to run the integrity test on demand. The module does not support software loading.

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document Section 6. Operational Environment VMware VMkernel Cryptographic Module 2.0, a software module, runs on the VMware ESXi operating system and the Dell EMC PowerEdge R650 with Intel Xeon Gold 6330 2.00GHz, which is classified as a modifiable OE. The requirements under ISO/IEC 19790, section 7.6 “Operational environment”, are met by the module.

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document Section 7. Physical Security Per ISO/IEC 19790:2012 classification, this is a multi-chip standalone cryptographic module. The appliance the software module runs on has a production grade chassis.

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document Section 8. Non-invasive Security The module does not implement any non-invasive security mitigations and thus the requirements per this section do not apply to the module.

VMware VMkernel Cryptographic Module 2.0

• Security Policy Document Section 9. Sensitive Security Parameters Management The following table lists the Sensitive Security Parameters (SSP) that exist when the module runs in the Approved mode of operation. Table 7
• SSPs

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document The module also comprises of the following non-SSP: Software Integrity Key: HMAC key; 256-bits; Hardcoded in the module at manufacture and never zeroised. Verifies the integrity of the module upon initialization. The module contains an AES-CTR based DRBG for random bit generation. The module does not implement a non-approved DRBG. memory and are never stored on persistent memory. The module zeroises SSPs by overwriting them with zeros. There are API functions that will zeroise any SSPs related to a specific cryptographic operation. Successful completion of the cryptographic operation/service is the implicit indicator of successful zeroisation in

VMware VMkernel Cryptographic Module 2.0

• Security Policy Document this case. When the underlying host platform is shutdown any remaining SSPs will be zeroised. A successful power-cycle of the underlying host platform is the implicit indicator of successful zeroisation. Unauthorized access to the module’s unprotected SSPs is prevented by the ESXi operating system. Table 8
• Non-Deterministic Random Number Generation Specification (b)

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document Section 10. Self-tests When the module is loaded, all self-tests are run automatically before the module becomes operational. If any of the self-tests fail, the module enters the error state. While in the error state, the module cannot perform any cryptographic operations. When the module enters the error state due to a failing self-test, the name of the self-test is shown/printed in the log. To clear the error, the module must be reloaded. Below is the list of self-tests performed by the cryptographic module. The module performs an HMAC-SHA2-256 KAT prior to performing the software integrity test. Pre-operational Self-Tests (POSTs): •    Software Integrity Test (HMAC-SHA2-256) Conditional Self-Tests: •    Cryptographic Algorithm Self-Tests (CASTs): •    AES KATs o   AES CBC 128-bit Encrypt KAT o   AES CBC 128-bit Decrypt KAT o   AES CTR 128-bit Encrypt KAT o   AES CTR 128-bit Decrypt KAT o   AES CBC-CS 128-bit Encrypt KAT o   AES CBC-CS 128-bit Decrypt KAT o   AES ECB 128-bit Encrypt KAT o   AES ECB 128-bit Decrypt KAT o   AES GCM 256-bit Encrypt KAT o   AES GCM 256-bit Decrypt KAT o   AES XTS 256-bit Encrypt KAT o   AES XTS 256-bit Decrypt KAT •    HMAC KATs o   HMAC-SHA1 KAT o   HMAC-SHA2-256 KAT o   HMAC-SHA2-512 KAT •    NIST SP800-90Ar1 CTR_DRBG KAT •    ENT (P) NIST SP 800-90B Health Tests •    Critical Functions Test: Performed for the DRBG, as per SP800-90A, Section 11: •    Instantiation Test •    Generation Test •    Reseed Test •    Uninstantiate Test

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document Section 11. Life-cycle Assurance Distribution and Installation VMware VMkernel Cryptographic Module 2.0 is distributed internal to VMware, it is not available to VMware customers. The operator of the module, the Crypto Officer, does not install the module. It is shipped pre-installed by the manufacturer, VMware as part of the VMware ESXi. Configuration The module does not require any configuration for operating in the Approved mode. Initialization and startup When the ESXi operating system starts, the module is automatically loaded and initialized. Verification of the module The module name and version is printed in the log upon successful initialization. The log message contains: “VmkCrypto version 2.0 successfully initialized.” Destruction and Zeroisation The module will remain on the ESXi operating system until the operating system is removed or replaced. When the ESXi operating system is removed or replaced, the module will be erased along with the operating system. Any SSPs in the module will be zeroised at that time.

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document Section 12. Mitigation of Other Attacks The module does not implement mitigation of other attacks and thus the requirements per this section do not apply to it.

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document Acronyms

VMware VMkernel Cryptographic Module 2.0 – Security Policy Document

END OF DOCUMENT VMware and the VMware logo are registered trademarks or trademarks of VMware, Inc. and its subsidiaries in the United States and other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. VMware products are covered by one or more patents listed at vmware.com/go/patents. Item No: vmw-wp-tech-temp-uslet-word-2021 8/21