CipherTrust Transparent Encryption Cryptographic Module

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for CipherTrust Transparent Encryption 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<br/>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth</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 CipherTrust Transparent Encryption 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<br/>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth</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

Thales CipherTrust Transparent Encryption Cryptographic Module

This document is the non-proprietary FIPS 140-3 Security Policy for the CipherTrust Transparent Encryption Cryptographic Module Version 3.0.1. This Security Policy describes the security services provided by the module and describes how the module meets the requirements of FIPS 140-3 (Federal Information Processing Standards 140-3) for an overall Security Level 1 implementation.

1 1

2 1

3 1

4 1

5 1

6 1

7 1

8 N/A

9 1

Table 1: Security Levels 002-000482-001, Rev M, July 18, 2024

Purpose and Use: The CipherTrust Transparent Encryption Cryptographic Module is a component within the CipherTrust Transparent Encryption solution, which in turn is part of the CipherTrust Data Security Platform solution. This solution provides data protection and access control functionality and is intended to be used as part of the CipherTrust Transparent Encryption solution. The CipherTrust Transparent Encryption Cryptographic Module is a loadable kernel module for Windows, Linux and IBM AIX. It is also loadable in the user space for Linux. The module communicates with the SecFS, a secure layer that sits over the filesystem to secure files and directories and to enforce the access and encryption policy. The policy specifies the key to be used by the cryptographic module when writing data to or reading data from the disk. The CipherTrust Transparent Encryption Cryptographic Library provides the cryptographic algorithms used by the module. Module Type: Software-hybrid Module Embodiment: MultiChipStand Cryptographic Boundary: The CipherTrust Transparent Encryption Cryptographic Module includes the CipherTrust Transparent Encryption Cryptographic Library. Cryptographic keys are provided to the library by other modules or applications and are used within the library. The cryptographic boundary of the module is the software library and CPU as shown in Figure 1. The diagram shows plaintext and ciphertext for encryption and decryption operations, and the request and response for PBKDF requests. Tested Operational Environment’s Physical Perimeter (TOEPP): Figure 1 shows the location of the cryptographic module with respect to the TOEPP. The TOEPP includes the CipherTrust Transparent Encryption application. 002-000482-001, Rev M, July 18, 2024

Operating System

Other CipherTrust Transparent Encryption CipherTrust Transparent Encryption Cryptographic plaintext, key Module ciphertext ciphertext, key Crypto Library SecFS plaintext password, parameters key Legend Encryption Hardware Platform Decryption CPU Memory PBKDF Figure 1: Block Diagram

Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Module Identification
• Hybrid Disjoint Hardware: Table 3: Tested Module Identification
• Hybrid Disjoint Hardware 002-000482-001, Rev M, July 18, 2024

Tested Operational Environments - Software, Firmware, Hybrid: Table 4: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A for this module.

Modes List and Description: Table 5: Modes List and Description The module is acting in an approved mode of operation when the module provides the services described in the Approved Services table. These services use the security functions listed in the Approved Algorithm table in an approved manner. The security service indicator provides confirmation that an approved service has been provided. When a service listed in the Non-Approved Services table is used, the module is not acting in an approved mode of operation. 002-000482-001, Rev M, July 18, 2024

Approved Algorithms: Table 6: Approved Algorithms Vendor-Affirmed Algorithms: N/A for this module. There are no vendor-affirmed algorithms in this module. Non-Approved, Allowed Algorithms: N/A for this module. There are no non-approved, allowed algorithms in this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. There are no non-approved, allowed algorithms with no security claimed in this module. Non-Approved, Not Allowed Algorithms: Table 7: Non-Approved, Not Allowed Algorithms Non-approved algorithms are not used in an approved mode of operation. An approved mode of operation is used when using an approved service (listed in the Approved Services Table with an approved algorithm listed in the Approved Algorithms table). The return code ‘is_fips=1’ indicates that the cryptographic operation has been performed in an approved mode of operation. If the return code is absent, or is ‘is_fips=0’, the service was not performed in an approved mode of operation. 002-000482-001, Rev M, July 18, 2024

Table 8: Security Function Implementations

PBKDF is implemented in accordance with SP 800-132, option 1a. The module includes only the functionality to receive the input to the PBKDF function (password, password length, salt, salt length, iterations, key length) and provide the output (key). The PBKDF function has been tested based on the minimum and maximums noted in the Approved Algorithms table. The minimum recommended password length is 96 bytes. This is consistent with a 96-character password. SP 800-132, Appendix A recommends a minimum password length of 10 characters. This range exceeds the recommendation. Assuming that the password is made up of upper-case letters, lower case letters and numeric characters, the probability of guessing a random 96-character password in a single attempt is one in 6296. The lower bound of 90,000 iterations is deemed sufficient since the derived key never leaves the CipherTrust Transparent Encryption Agent (the Agent). The derived key is used to protect configuration files and keys used by the Agent. Note that in accordance with SP800-132, keys derived from passwords using PBKDF may only be used in storage applications. Although usage of keys resulting from use of the PBKDF function is outside of the scope of this cryptographic module, it should be noted that the Agent in which these keys are used provides data-atrest encryption for storage applications.

N/A for this module. This module does not include an entropy source.

This module does not provide key establishment functions in the approved mode of operation.

Not applicable. 002-000482-001, Rev M, July 18, 2024

Table 9: Ports and Interfaces 002-000482-001, Rev M, July 18, 2024

Table 10: Roles The Crypto Officer role is implicitly assumed by the entity that can access the interfaces to the cryptographic module. This entity accesses the module exclusively via API calls. Each process or thread accessing the module is logically separated by the operating system into independent contexts of execution.

Table 11: Approved Services 002-000482-001, Rev M, July 18, 2024

Table 12: Non-Approved Services

Not applicable. 002-000482-001, Rev M, July 18, 2024

The module checks the integrity of its object code when it is initialized. The module performs an HMAC-SHA2-

384 of itself when it is loaded into the kernel or user space. Following the HMAC Known Answer Test (KAT), this

HMAC value is compared to the HMAC-SHA2-384 digest generated during build time. If the results are not the same, an error message is written to the output interface, and the module ceases operation. The HMAC key used for this function is embedded in the module in plaintext. At the completion of this test, temporary values are zeroized.

Restarting the CipherTrust Transparent Encryption Agent will cause the integrity check to be rerun. 002-000482-001, Rev M, July 18, 2024

Type of Operational Environment: Modifiable How Requirements are Satisfied: The CipherTrust Transparent Encryption Cryptographic Module exists as software executing in a commercially available operating system. The operating system (Windows, Linux or AIX) provides process isolation and CPU scheduling to ensure that programs do not interfere with each other. This ensures that the cryptographic module has control over its own SSPs while the cryptographic process is in use. Within the cryptographic module, each binary is launched into the address space of a process. Each instance of the module is run strictly inside the process space of the module. All processes spawned by the cryptographic module are owned by the module. The single operator for a given instance of the module is the combined identities associated with the processes containing the module. The operating system and hardware enforce the process isolation including memory isolation, where keys and intermediate key data are temporarily stored. When running in User Space, the writable memory areas of the module are accessible only to the module. Data and stack segments are accessible only to the processes containing the module. When running in Kernel space, access is restricted to only kernel modules. It is the user’s responsibility to allow only trusted modules to be loaded into the kernel. The operating system is responsible for multitasking operations so that other processes cannot access the address space of the processes containing the module. The module does not require a specific configuration of the target operating systems to enforce the controls described above. 002-000482-001, Rev M, July 18, 2024

The module is a software-hybrid module that operates on a multi-chip standalone platform, which conforms to the level 1 requirements for physical security. Figure 2: Cryptographic Hardware for Intel Processor Figure 3: Intel® Xeon® Gold 5318N as found in PowerEdge R750xs Figure 4: Cryptographic Hardware for IBM Processor Figure 5: IBM Power9 Processor as found in IBM Power9 Server 002-000482-001, Rev M, July 18, 2024

Not applicable. The module does not claim Non-Invasive Security. 002-000482-001, Rev M, July 18, 2024

Table 14: SSP Input-Output Methods

Table 15: SSP Zeroization Methods

Table 16: SSP Table 1 002-000482-001, Rev M, July 18, 2024

Keys are obtained from an external FIPS-validated module. No entropy input is claimed for the CipherTrust Transparent Encryption Cryptographic Module. 002-000482-001, Rev M, July 18, 2024

Table 18: Pre-Operational Self-Tests The module performs a pre-operational self-test to verify the integrity of the software. On power-up, the module runs the conditional self-tests (including the KAT for HMAC-SHA2-384) and then runs the HMAC-SHA2-384 Data input/output and any data processing are inhibited while the test is in progress. When all of the preoperational tests have run to completion, one or more messages are written to the log. If all tests pass, a single “FIPS Tests passed” message is written to the log. When all tests pass, the module is capable of being operated in an approved mode of operation.

Table 19: Conditional Self-Tests 002-000482-001, Rev M, July 18, 2024

The module performs conditional self-tests to confirm the proper operation of the cryptographic functions used in the software. These are run at power-up and may be run on demand by restarting the module. The Known Answer Tests (KATs) perform a byte-by-byte comparison of the result with a known answer, and abort on the first mismatch. Keys are destroyed upon completion of the KAT. Data input/output and any data processing are inhibited while the tests are in progress. If any test fails, an error status message is sent to the log and the module ceases operation. When all of the known answer tests and the pre-operational test have run to completion, one or more messages are written to the log. In the case of a failed test, the log will indicate which test failed with a “FIPS <testname> Test failed” message. If all tests pass, a single “FIPS Tests passed” message is written to the log. When all the conditional tests and the software integrity test pass, the module is capable of being operated in an approved mode of operation.

Table 20: Pre-Operational Periodic Information 002-000482-001, Rev M, July 18, 2024

Table 21: Conditional Periodic Information

Table 22: Error States Operation of the module will cease if there is a failure of a KAT. An operator may confirm success or failure of the KATs by viewing the syslog messages and examining the ‘FIPS Tests passed’ or ‘FIPS <testname> Test failed’ message. The log files are found:

• On Linux o in /var/log/messages
• On Windows o in the system event viewer under the Vormetric group
• On AIX o /opt/vormetric/DataSecurityExpert/agent/secfs/tmp/secfs.log 002-000482-001, Rev M, July 18, 2024

The module is started by starting the CipherTrust Transparent Encryption Agent software. A call can be made to the "const char *vds_crypto_version(void);" API. The return string is the version of the cryptographic module software.

Installation of the CTE Agent software is performed in accordance with the appropriate guidance:

In addition to the direct guidance provided in this security policy, CipherTrust Transparent Encryption user guidance is available in an online manual, which can be accessed at www.thalesdocs.com.

The cryptographic module does not provide persistent storage of SSPs. SSPs are held in volatile memory and are zeroized following provision of the requested cryptographic service. It is recommended that the CTE agent application be uninstalled at the end of life of the module. This will result in the uninstallation of the cryptographic module and erasure of the HMAC Key used with the software integrity check. 002-000482-001, Rev M, July 18, 2024

Not applicable. The module does not claim Mitigation of Other Attacks. 002-000482-001, Rev M, July 18, 2024