SUSE Linux Enterprise Kernel Crypto API Cryptographic Module

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for SUSE Linux Enterprise Kernel Crypto API 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>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>IKEV<br/>IPSEC</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."]
    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["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"]
    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 SUSE Linux Enterprise Kernel Crypto API 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"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>IKEV<br/>IPSEC</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,C5,C6 clueLow;

Security Policy, page by page

SUSE LLC SUSE Linux Enterprise Kernel Crypto API Cryptographic Module Prepared by: atsec information security corporation

4516 Seton Center Pkwy, Suite 250

Austin, TX 78759 Document version: 1.1 www.atsec.com Last update: 12-04-2025 © 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

This document is the non-proprietary FIPS 140-3 Security Policy for versions 3.5 and 3.6 the SUSE Linux Enterprise Kernel Crypto API Cryptographic Module. It contains the security rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for an overall Security Level 1 module. intact and including this notice. Other documentation is proprietary to their authors.

In preparing the Security Policy document, the laboratory formatted the vendor-supplied documentation for consolidation without altering the technical statements therein contained. The further refining of the Security Policy document was conducted iteratively throughout the conformance testing, wherein the Security Policy was submitted to the vendor, who would then edit, modify, and add technical contents. The vendor would also supply additional documentation, which the laboratory formatted into the existing Security Policy, and resubmitted to the vendor for their final editing.

Table 1: Security Levels © 2025 SUSE, LLC/atsec information security corporation.

Purpose and Use: The SUSE Linux Enterprise Kernel Crypto API Cryptographic Module (hereafter referred to as “the module”) provides a C language application program interface (API) for use by other (kernel space and user space) processes that require cryptographic functionality. The module operates on a general-purpose computer as part of the Linux kernel. Its cryptographic functionality can be accessed using the Linux Kernel Crypto API. Module Type: Software Module Embodiment: MultiChipStand Cryptographic Boundary: The cryptographic boundary of the module is defined as the kernel binary and the kernel crypto object files, the libkcapi library, and the fipscheck binary, which is used to verify the integrity of the software components. In addition, the cryptographic boundary contains the .hmac files which store the expected integrity values for each of the software components. Tested Operational Environment’s Physical Perimeter (TOEPP): The TOEPP of the module is defined as the general-purpose computer on which the module is installed. It includes software in kernel and user space, as well as the PAA in the CPU. The TOEPP is indicated by the large thin border in Figure 1. Figure 1: Block Diagram © 2025 SUSE, LLC/atsec information security corporation.

Identification Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets): © 2025 SUSE, LLC/atsec information security corporation.

Package or File Name rt/kernel/arch/x86/crypto/*.ko; /usr/lib64/libkcapi.so.0.13.0; /usr/lib64/libkcapi/fipscheck; /usr/lib64/libkcapi/.fipscheck.hmac

Software/ Firmware Version

Features

Integrity Test and 4096-bit key

Table 2: Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets) Tested Operational Environments - Software, Firmware, Hybrid: © 2025 SUSE, LLC/atsec information security corporation.

Table 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: © 2025 SUSE, LLC/atsec information security corporation.

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. The module is considered to maintain compliance with the FIPS 140-3 validation for SUSE products when operating on any general-purpose platform/processor that supports the SUSE the allowance FIPS 140-3 management manual [FIPS140-3_MM] section 7.9.1 bullet 1 a i).

There are no components within the cryptographic boundary excluded from the FIPS 140-3 requirements.

Modes List and Description: Table 5: Modes List and Description © 2025 SUSE, LLC/atsec information security corporation.

After passing all pre-operational self-tests and cryptographic algorithm self-tests executed on start-up, the module automatically transitions to the approved mode. No operator intervention is required to reach this point. Mode Change Instructions and Status: The module automatically switches between the approved and non-approved modes depending on the services requested by the operator. The status indicator of the mode of operation is equivalent to the indicator of the service that was requested.

Approved Algorithms: © 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

Table 6: Approved Algorithms Vendor-Affirmed Algorithms: Table 7: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: © 2025 SUSE, LLC/atsec information security corporation.

Table 8: Non-Approved, Not Allowed Algorithms

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

d Table 9: Security Function Implementations © 2025 SUSE, LLC/atsec information security corporation.

The Crypto Officer shall consider the following requirements and restrictions when using the module. For IPsec, the module offers the AES GCM implementation and uses the context of Scenario

1 of FIPS 140-3 IG C.H. The mechanism for IV generation is compliant with RFC 4106. IVs

generated using this mechanism may only be used in the context of AES GCM encryption within the IPsec protocol. The module does not implement IPsec. The module’s implementation of AES GCM is used together with an application that runs outside the module’s cryptographic boundary. This application must use RFC 7296 compliant IKEv2 to establish the shared secret SKEYSEED from which the AES GCM encryption keys are derived. The design of the IPsec protocol implicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values for a given session key. In the event the module’s power is lost and restored, the consuming application must ensure that a new key for use with the AES GCM key encryption or decryption under this scenario shall be established. The module also provides a non-approved AES GCM encryption service which accepts arbitrary external IVs from the operator. This service can be requested by invoking the crypto_aead_encrypt API function with an AES GCM handle. Any approved use of the AES GCM service is indicated by the crypto_aead_get_flags(tfm) API returning the CRYPTO_TFM_FIPS_COMPLIANCE flag, as described in section 4.3.

The length of a single data unit encrypted or decrypted with AES XTS shall not exceed 220 AES blocks, that is 16MB, of data per XTS instance. An XTS instance is defined in Section 4 of SP 800-38E. To meet the requirement stated in IG C.I, the module implements a check to ensure that the two AES keys used in AES XTS mode are not identical. As the module does not implement symmetric key generation, this check is performed when the keys are input by the operator. Key_1 and Key_2 shall be generated and/or established independently according to the rules for component symmetric keys from NIST SP 800-133r2, Section 6.3. The XTS mode shall only be used for the cryptographic protection of data on storage devices. It shall not be used for other purposes, such as the encryption of data in transit.

For RSA signature verification, the module supports modulus size 4096 bits. The supported modulus size has been CAVP tested.

To comply with the assurances found in Section 5.6.2 of SP 800-56A Rev. 3, the operator must use the Diffie-Hellman and EC Diffie-Hellman shared secret computation algorithms in the context of IETF protocols. Additionally, the module’s approved key pair generation service (see Approved Services table in Section 4.3 Approved Services) must be used to generate ephemeral Diffie-Hellman or EC Diffie-Hellman key pairs, or the key pairs must be obtained from another FIPS-validated module. As part of this service, the module will internally perform the full public key validation of the generated public key. © 2025 SUSE, LLC/atsec information security corporation.

The module’s shared secret computation service will internally perform the full public key validation of the peer public key, complying with Sections 5.6.2.2.1 and 5.6.2.2.2 of SP 80056A Rev. 3.

The module does not establish SSPs using an approved key agreement scheme (KAS). However, it does offer some or all of the underlying KAS cryptographic functionality to be used by an external operator/application as part of an approved KAS.

The module does not establish SSPs using an approved key transport scheme (KTS). However, it does offer approved authenticated algorithms that can be used by an external operator/application as part of an approved KTS.

Digital signature generation using SHA-1 is non-approved and not allowed in approved services.

2.8 RBG and Entropy 1

1 The kernel RT and kernel-default modules are compiled within different binaries. For this reason, two separate ESV

validations were performed. Entropy-related source code between the two versions the kernel is the same. © 2025 SUSE, LLC/atsec information security corporation.

Name Jitter RNG

Type

Operational Environment Server 15 SP6 on Intel® Xeon® Gold 5416S

Sample Size

Entropy per Sample

Conditioning Component

Table 11: Entropy Sources The module implements three different Deterministic Random Bit Generator (DRBG) implementations based on SP 800-90Ar1: CTR_DRBG, Hash_DRBG, and HMAC_DRBG. Each of these DRBG implementations can be instantiated by the operator of the module. When instantiated, these DRBGs can be used to generate random numbers for external usage. Additionally, the module employs a specific HMAC-SHA2-512 DRBG implementation for internal purposes (e.g. to generate initialization vectors). This DRBG is initially seeded with

384 output bits from the entropy source (384 bits of entropy) and reseeded with 256 output

bits from the entropy source (256 bits of entropy). Outputs of multiple GetEntropy() calls are concatenated to receive the entropy input length greater than 256 bits. The output is truncated to get the entropy input string which is not a multiple of 256. E.g. The 384 bits of entropy source output is obtained by calling the GetEntropy() twice, with each call providing 256 bits of output. The second call output is truncated to 128 bits and concatenated to the 256 bit output from the first call. The module complies with the Public Use Document for ESV certificate E205 by reading entropy data from the jent_kcapi_random() function, which corresponds to the GetEntropy() conceptual interface. The operational environment on the ESV certificate is identical to the operating system described in this document. There are no maintenance requirements for the entropy source.

The module implements asymmetric key pair generation compliant with SP 800-133 Rev.

2. When random values are required, they are obtained from the SP 800-90A Rev. 1 approved DRBG, compliant with Section 4 of SP 800-133 Rev. 2 (without XOR): • Safe primes key pair generation: compliant with SP 800-133 Rev. 2, Section 5.2, which maps to SP 800-56A Rev.
3. The method described in Section 5.6.1.1.4 of SP 800-56A Rev. 3 (“Testing Candidates”) is used. • ECC (ECDH and ECDSA) key pair generation: compliant with SP 800-133 Rev. 2, Section 5.1, which maps to FIPS 186-5. The method described in Appendix A.2.2 of FIPS 186-5 (“Rejection Sampling”) is used. Additionally, the module implements the following key derivation methods: • KBKDF: compliant with SP 800-108 Rev.
4. This implementation can be used to generate secret keys from a pre-existing key-derivation-key. Intermediate key generation values are not output from the module and are explicitly zeroized after processing the service.

The module implements shared secret computation as listed in the Security Function Implementations table in 2.6 Security Function Implementations. © 2025 SUSE, LLC/atsec information security corporation.

AES GCM with internal IV generation in the approved mode is compliant with RFC 4106 and shall only be used in conjunction with the IPsec protocol. No parts of this protocol, other than the AES GCM implementation, have been tested by the CAVP and CMVP. © 2025 SUSE, LLC/atsec information security corporation.

Table 12: Ports and Interfaces The logical interfaces are the APIs through which the applications request services. These logical interfaces are logically separated from each other by the API design, AF_ALG type socket that allows the applications running in the user space to request cryptographic services from the module. © 2025 SUSE, LLC/atsec information security corporation.

The module does not implement authentication.

Table 13: Roles No support is provided for multiple concurrent operators.

W,E W,E © 2025 SUSE, LLC/atsec information security corporation.

W,E © 2025 SUSE, LLC/atsec information security corporation.

W,E,Z G,E,Z G,E,Z G,E,Z (V, G,W,E (V, C): G,W,E (V, G,W,E © 2025 SUSE, LLC/atsec information security corporation.

G,R G,R G,R G,E,Z G,R © 2025 SUSE, LLC/atsec information security corporation.

G,R G,E,Z W,E W,E G,R ) © 2025 SUSE, LLC/atsec information security corporation.

n © 2025 SUSE, LLC/atsec information security corporation.

n (V, © 2025 SUSE, LLC/atsec information security corporation.

Name

Descrip tion

Indicator

Input s

Outputs

Security Functio ns

SSP Access (V, C): Z - HMAC_ DRBG Internal state (V, Key): Z - CTR_DR BG seed: Z - Hash_D RBG seed: Z - HMAC_ DRBG seed: Z - Key- derivati on key: Z - Derived key: Z - Interme diate key generati on value: Z - Module- generat ed DH private key: Z - Module- generat ed DH public key: Z - Module- generat

(V, C): Z (V, Z © 2025 SUSE, LLC/atsec information security corporation.

Name

Descrip tion

Indicator

Input s

Outputs

Security Functio ns

SSP Access ed EC private key: Z - Module- generat ed EC public key: Z - DH private key: Z - DH public key: Z - EC private key: Z - EC public key: Z - Shared secret: Z

Z Table 14: Approved Services The table above lists the approved services. The following convention is used to specify access rights to SSPs:

• Generate (G): The module generates or derives the SSP.
• Read (R): The SSP is read from the module (e.g. the SSP is output).
• Write (W): The SSP is updated, imported, or written to the module.
• Execute (E): The module uses the SSP in performing a cryptographic operation.

© 2025 SUSE, LLC/atsec information security corporation.

Table 15: Non-Approved Services

The module does not load external software or firmware. © 2025 SUSE, LLC/atsec information security corporation.

The Linux kernel binary is integrity tested using an HMAC-SHA2-256 calculation performed by the fipscheck application (which utilizes the module’s HMAC and SHA-256 implementations). An HMAC-SHA2-256 calculation is also performed on the fipscheck application and the libkcapi library to verify their integrity. The kernel crypto object files listed in section 2.2 are loaded on start-up by the module and verified using RSA signature verification with PKCS#1 v1.5 padding, SHA-256, and a 4096-bit key. The fipscheck application first executes the HMAC-SHA2-256 self-test. After this self-test is successful, the fipscheck application is used to perform an HMAC calculation of the libkcapi library, the kernel binary, and of its own binary to verify their integrity. After the integrity of these components has been verified, the self-test for the RSA signature verification implementation is run. Upon successful run of this self-test, the RSA signature verification implementation of the kernel is used to verify the integrity of the crypto object files listed in section 2.2 and loaded at start-up.

Integrity tests are performed as part of the pre-operational self-tests, which are executed when the module is initialized. The integrity tests can be invoked on demand by unloading and subsequently re-initializing the module, which will perform (among others) the software integrity tests. © 2025 SUSE, LLC/atsec information security corporation.

Type of Operational Environment: Modifiable How Requirements are Satisfied: The operating system provides process isolation and memory protection mechanisms that ensure appropriate separation for memory access among the processes on the system. Each process has control over its own data and uncontrolled access to the data of other processes is prevented.

The module shall be installed as stated in Section 11.1. Instrumentation tools like the ptrace system call, gdb and strace, as well as other tracing mechanisms offered by the Linux environment such as ftrace or systemtap, shall not be used in the operational environments. The use of any of these tools implies that the cryptographic module is running in a non-validated operational environment. © 2025 SUSE, LLC/atsec information security corporation.

The module is comprised of software only and therefore this section is not applicable. © 2025 SUSE, LLC/atsec information security corporation.

This module does not implement any non-invasive security mechanism and therefore this section is not applicable. © 2025 SUSE, LLC/atsec information security corporation.

Name AF_ALG_typ e sockets (input) AF_ALG_typ e sockets (output) API input parameters (input) API output parameters (output)

From Operator calling application (TOEPP), userspace Cryptographi c module Operator calling application (TOEPP), kernel space Cryptographi c module

To Cryptographi c module Operator calling application (TOEPP), userspace Cryptographi c module Operator calling application (TOEPP), kernel space

Format Type Plaintex t Plaintex t Plaintex t Plaintex t

Distributio n Type Manual Manual Manual Manual

Entry Type Electroni c Electroni c Electroni c Electroni c

SFI or Algorith m

Table 16: Storage Areas The module does not perform persistent storage of SSPs. The SSPs are temporarily stored in the RAM in plaintext form. SSPs are provided to the module by the calling process and are destroyed when released by the appropriate zeroization function calls.

m Table 17: SSP Input-Output Methods © 2025 SUSE, LLC/atsec information security corporation.

Table 18: SSP Zeroization Methods All data output is inhibited during zeroization. h © 2025 SUSE, LLC/atsec information security corporation.

h D.L. D.L. D.L. © 2025 SUSE, LLC/atsec information security corporation.

h D.L. D.L. D.L. D.L. © 2025 SUSE, LLC/atsec information security corporation.

h 5.2) 6, 4, 6, 4, © 2025 SUSE, LLC/atsec information security corporation.

h © 2025 SUSE, LLC/atsec information security corporation.

h Table 19: SSP Table 1 © 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

Table 20: SSP Table 2 © 2025 SUSE, LLC/atsec information security corporation.

The SHA-1 algorithm as implemented by the module will be non-approved for all purposes, starting January 1, 2031. © 2025 SUSE, LLC/atsec information security corporation.

Table 21: Pre-Operational Self-Tests © 2025 SUSE, LLC/atsec information security corporation.

The pre-operational software integrity tests are performed automatically when the module is powered on, before the module transitions into the operational state. The algorithms used for the integrity test (i.e., HMAC-SHA2-256 and RSA SigVer with 4096 bit key) run their CASTs before the integrity test is performed. While the module is executing the self-tests, services are not available, and data output (via the data output interface) is inhibited until the pre-operational software integrity self-tests are successfully completed. The module transitions to the operational state only after the pre-operational self-tests are passed successfully.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

d e © 2025 SUSE, LLC/atsec information security corporation.

Table 22: Conditional Self-Tests The module performs self-tests on all approved cryptographic algorithms as part of the approved services supported in the approved mode of operation, using the tests shown in the table above. Services are not available, and data output (via the data output interface) is inhibited during the conditional self-tests. If any of these tests fails, the module transitions to the Error State.

3.5 3.6 Table 23: Pre-Operational Periodic Information © 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.

© 2025 SUSE, LLC/atsec information security corporation.