IBM COS Linux Kernel Cryptographic API Cryptographic Module

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for IBM COS Linux Kernel Cryptographic 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 IBM COS Linux Kernel Cryptographic 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

IBM Corporation IBM COS Linux Kernel Cryptographic API Cryptographic Module Document Version 1.1 Last update: 2025-11-10 Prepared by: Prepared for: atsec information security corporation IBM Corporation

4516 Seton Center Parkway, Suite 250 71 S Wacker Dr, 6th Floor

Austin, TX 78759 Chicago, IL 60606 www.atsec.com www.ibm.com © 2025 IBM / atsec information security.

© 2025 IBM / atsec information security.

3 of 71

This document is the non-proprietary FIPS 140-3 Security Policy for version 3 of the IBM COS Linux Kernel Cryptographic 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 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. © 2025 IBM / atsec information security.

6 of 71

Purpose and Use: The IBM COS Linux Kernel Cryptographic 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 Module Characteristics: 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 kcapi-hasher 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. The cryptographic boundary is indicated by the small bold border in Figure

1. 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
2. Figure 1: Block Diagram © 2025 IBM / atsec information security.

7 of 71

and Identification Tested Module Identification

• Hardware: N/A for this module. 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: N/A for this module. Tested Operational Environments - Software, Firmware, Hybrid: The module makes use of hardware acceleration provided by the hardware platform. Namely, AES-NI from the platform listed in the Tested Operational Environments - Software, Firmware, Hybrid table. AES-NI and SHA extensions are considered as PAA. Table 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: © 2025 IBM / atsec information security.

8 of 71

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.

Modes List and Description: Table 5: Modes List and Description Mode Change Instructions and Status: 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. The module automatically switches between the approved and non-approved modes depending on the services requested by the operator. that was requested. Not applicable. © 2025 IBM / atsec information security.

9 of 71

Approved Algorithms: © 2025 IBM / atsec information security.

10 of 71

© 2025 IBM / atsec information security.

11 of 71

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: Table 8: Non-Approved, Not Allowed Algorithms © 2025 IBM / atsec information security.

12 of 71

© 2025 IBM / atsec information security.

13 of 71

© 2025 IBM / atsec information security.

14 of 71

© 2025 IBM / atsec information security.

15 of 71

Name Signature Verification with RSA Legacy Signature Verification with RSA Signature Verification with ECDSA

Type DigSig-SigVer DigSig-SigVer DigSig-SigVer

Description Signature verification Signature verification Signature verification

Properties

Algorithms A6818) HMAC-SHA2-384: (A6801, A6815, A6816, A6817) HMAC-SHA2-512: (A6801, A6815, A6816, A6817) RSA SigVer (FIPS186-5): (A6801) SHA2-224: (A6801, A6815, A6816, A6817, A6818) SHA2-256: (A6801, A6815, A6816, A6818) SHA2-384: (A6801, A6815, A6816, A6817) SHA2-512: (A6801, A6815, A6816, A6817) SHA-1: (A6801, A6815, A6816, A6817, A6818) RSA SigVer (FIPS186-4): (A6801) SHA2-224: (A6801, A6815, A6816, A6817, A6818) SHA2-256: (A6801, A6815, A6816, A6817, A6818) SHA2-384: (A6801, A6815, A6816, A6817) SHA2-512: (A6801, A6815, A6816, A6817) SHA3-256: (A6801) SHA3-384: (A6801) SHA3-512: (A6801) ECDSA SigVer (FIPS186-5): (A6802)

© 2025 IBM / atsec information security.

16 of 71

Name Legacy Signature Verification with ECDSA Key Derivation with KBKDF Key Derivation with KDA OneStep

Type DigSig-SigVer KBKDF KAS-56CKDF

Description Signature verification SP 800-108r1. Key derivation SP 800-56cr2. Key agreement scheme

Properties

Algorithms SHA-1: (A6801, A6815, A6816, A6817, A6818) ECDSA SigVer (FIPS186-4): (A6802) KDF SP800-108: (A6803) KDA OneStep SP800-56Cr2: (A6803)

Table 9: Security Function Implementations

Algorithms designated as “Legacy” can only be used on data that was generated prior to the Legacy Date specified in FIPS 140-3 IG C.M.

For IPsec, the module offers the AES GCM implementation and uses the context of Scenario

1 (b) 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. When this is the case, the API will not set an approved service indicator, as described in the Approved Services table.

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 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. © 2025 IBM / atsec information security.

17 of 71

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 module offers DH and ECDH shared secret computation services compliant to the SP 800-56Ar3 and meeting IG D.F scenario 2 path (1). To meet the required assurances listed in Section 5.6 of SP 800-56Ar3, the module shall be used together with an application that implements the IPSec protocol and the following steps shall be performed:

1. The entity using the module, must use the module's "Key pair generation" service: the set_secret and generate_public_key API functions, to generate DH/ECDH ephemeral key pairs. This meets the assurances required by key pair owner defined in the section 5.6.2.1 of SP 800-56Ar3.
2. As part of the module's shared secret computation service, the module internally performs the public key validation on the peer's public key passed in as input to the API function. This meets the public key validity assurance required by section

3. The module does not support static keys, therefore the "assurance of peer's possession of private key" is not applicable.

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

The module implements HMAC with SHA3-224, SHA3-256, SHA3-384, SHA3-512. The CAVP certificates have been obtained for the HMAC algorithm as well as for all the SHA3 implementations. The CAVP certificates are listed in the Approved Algorithms table.

The module implements FIPS 186-4 RSA SigVer and FIPS 186-5 RSA SigVer. All RSA modulus lengths (i.e., 2048, 3072, 4096 bits) have been CAVP tested. The CAVP certificates are listed in the Approved Algorithms table.

Table 10: Entropy Certificates © 2025 IBM / atsec information security.

18 of 71

Table 11: Entropy Sources The module implements three different Deterministic Random Bit Generator (DRBG) implementations based on SP 800-90Ar1: Counter DRBG, Hash DRBG, and HMAC DRBG. Each of these DRBG implementations can be instantiated by the operator of the module, using the parameters listed specified in the Security Function Implementations table. When instantiated, these DRBGs can be used to generate random numbers for external usage. Additionally, the module employs a specific HMAC-SHA-512 DRBG implementation for internal purposes (e.g. to generate asymmetric key pairs). The module complies with the Public Use Document for ESV certificate E260 by reading entropy data from the jent_kcapi_random() function, which corresponds to the GetEntropy() conceptual interface. This function outputs 256 bits of full entropy. The HMAC-SHA-512 DRBG is instantiated with a 384-bit entropy input and reseeded with a 256-bits long entropy input. 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. The operational environment on the ESV certificate is identical to the operating system described in this document, and the entropy source is implemented inside the cryptographic boundary. Thus, the module is compliant with scenario 1 of IG 9.3.A. There are no maintenance requirements for the entropy source.

The module implements Cryptographic Key Generation (CKG, vendor affirmed), compliant with SP 800-133r2. When random values are required, they are directly obtained as output from the SP 800-90Ar1 approved DRBG, compliant with Section 4 of SP 800-133r2 (without XOR, as described in Additional Comment 2 of IG D.H). The following methods are implemented:

• Safe Primes key pair generation: compliant with SP 800-133r2, Section 5.2, which maps to SP 800-56Ar3. The method described in Section 5.6.1.1.4 of SP 800-56Ar3 (“Testing Candidates”) is used.
• ECDSA key pair generation: compliant with SP 800-133r2, Section 5.1 and 5.2. The method described in Appendix A.2.2 of FIPS 186-5 (“Rejection Sampling”) is used. Note that this generation method is also used to generated ECDH key pairs. Intermediate key generation values are not output from the module and are explicitly zeroized after processing the service. © 2025 IBM / atsec information security.

19 of 71

The module implements shared secret computation methods as listed in the Security Function Implementations table.

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. The module implements shared secret computation for DH and ECDH following SP 80056Arev3 No other parts of the TLS or IPSec protocols, other than those mentioned above, have been tested by the CAVP and CMVP. © 2025 IBM / atsec information security.

20 of 71

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. The module does not implement a control output interface. © 2025 IBM / atsec information security.

21 of 71

Table 13: Roles The module supports the Crypto Officer role only. This sole role is implicitly and always assumed by the operator of the module. No support is provided for multiple concurrent operators.

© 2025 IBM / atsec information security.

22 of 71

© 2025 IBM / atsec information security.

23 of 71

G,E G,E G,E D.L): G,W,E D.L): G,W,E © 2025 IBM / atsec information security.

24 of 71

D.L): G,W,E G,R © 2025 IBM / atsec information security.

25 of 71

n © 2025 IBM / atsec information security.

26 of 71

Name

Descripti on integrity tests

Indicator

Inputs

Outputs

Security Functions with AES Random Number Generation with HMAC DRBG, Hash DRBG or Counter DRBG Message Authentica tion Code Generation with AES or HMAC Message Authentica tion Code Verificatio n with AES-GMAC Shared Secret Computati on with KAS-FFC- SSC or KAS-ECC- SSC Message Digest with SHA Key Pair Generation with ECDSA or Safe Primes Authentica ted Encryption and Authentica ted Decryption with AES- CCM Authentica ted Encryption and Authentica

SSP Access

© 2025 IBM / atsec information security.

27 of 71

D.L): Z Z Z © 2025 IBM / atsec information security.

28 of 71

Name

Descripti on

Indicator

Inputs

Outputs

Security Functions

SSP Access BG Seed (IG D.L): Z - CTR_DRB G Internal State (V, Key) (IG D.L): Z - Hash_DR BG Internal State (V, C) (IG D.L): Z - HMAC_DR BG Internal State (V, Key) (IG D.L): Z - DH Public Key: Z - DH Private Key: Z - EC Public Key: Z - EC Private Key: Z - Intermedi ate Key Generatio n Value: Z - RSA Public Key: Z - Key- Derivatio n Key: Z - KBKDF Derived Key: Z - KDA OneStep

Z D.L): Z D.L): Z D.L): Z Z © 2025 IBM / atsec information security.

29 of 71

Name

Descripti on

Indicator

Inputs

Outputs

Security Functions

SSP Access Derived Key: Z

Table 14: 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.
• Zeroize (Z): The module zeroizes the SSP.
• N/A: The module does not access any SSP or key during its operation.

Table 15: Non-Approved Services

Not applicable. © 2025 IBM / atsec information security.

30 of 71

The kcapi-hasher binary utilizes the module’s HMAC and SHA-512 implementations and verifies it’s integrity test and the libkcapi library integrity followed by the integrity test on the static kernel binary i.e. vmlinuz. The HMAC key used for this integrity test is stored in libkcapi. The kernel object (.ko) files are verified using RSA signature verification with PKCS#1 v1.5 padding, SHA-512, and a 4096-bit key stored in the kernel.

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 IBM / atsec information security.

31 of 71

Requirements Type of Operational Environment: Modifiable How Requirements are Satisfied: the module executes as part of a general-purpose operating system (ClevOS 3.19), which allows modification, loading, and execution of software that is not part of the validated module. The approved cryptographic algorithms of the module are part of the Linux kernel, which operates in Linux kernel space. This ensures that any SSPs contained within the module are protected by the process isolation and memory separation mechanisms provided by the Linux kernel, and only the module has control over these SSPs. The user space libkcapi and kcapi-hasher components, though not processing any SSPs, are similarly protected by the operating environment.

The module shall be installed as specified 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 environment. The use of any of these tools implies that the cryptographic module is running in a non-validated operational environment. © 2025 IBM / atsec information security.

32 of 71

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

33 of 71

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

34 of 71

Name API input parameters; AF_ALG_type sockets (input) API output parameters; AF_ALG type sockets (output)

From Operator calling application (TOEPP) Cryptographic module

To Cryptographic module Operator calling application (TOEPP)

Format Type Plaintext Plaintext

Distribution Type Manual Manual

Entry Type Electronic Electronic

SFI or Algorithm

Table 16: Storage Areas The module does not perform persistent storage of SSPs. The SSPs are temporarily stored in destroyed when released by the appropriate zeroization function calls. Table 17: SSP Input-Output Methods © 2025 IBM / atsec information security.

35 of 71

Name AES Key HMAC Key Shared Secret

Description AES key used for Encryption; Decryption; Authenticated encryption; Authenticated decryption; Message authenticatio n; HMAC key used for Message authenticatio n code (MAC); Shared secret established during Shared Secret Computation

Size - Strength XTS: 128, 256 bits; ECB, CBC, CTR, CFB128, CBC- CS3, KW, OFB, CCM, GCM, CMAC, GMAC: 128, 192, 256 bits - XTS: 128, 256 bits; ECB, CBC, CTR, CFB128, CBC- CS3, KW, OFB, CCM, GCM, CMAC, GMAC: 128, 192, 256 bits 112-524288 bits - 112-256 bits KAS-FFC- SSC:ffdhe204 8, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192; KAS-ECC-SSC: P-256, P-384 bits - KAS-

Type - Category Symmetric key - CSP Symmetric key - CSP Shared secret - CSP

Generate d By

Establishe d By Shared Secret Computatio n with KAS- FFC-SSC or KAS-ECC- SSC

Used By Encryption and Decryption with AES Message Authenticatio n Code Generation with AES or HMAC Message Authenticatio n Code Verification with AES- GMAC Message Authenticatio n Code Generation with AES or HMAC Key Derivation with KDA OneStep

Table 18: SSP Zeroization Methods All data output is inhibited during zeroization. © 2025 IBM / atsec information security.

36 of 71

Name Entropy Input (IG D.L) CTR_DRBG Seed (IG D.L) Hash_DRBG Seed (IG D.L) HMAC_DRB G Seed (IG D.L) CTR_DRBG Internal State (V, Key) (IG D.L)

Description Entropy input used to seed the DRBGs DRBG seed derived from Entropy Input DRBG seed derived from Entropy Input DRBG seed derived from Entropy Input Internal state of Counter DRBG instance

Size - Strength FFC-SSC: 112- 200 bits; KAS- ECC-SSC: 128, 192 bits 128-384 bits - 128-384 bits 256, 320, 384 bits - 128, 192, 256 bits 440, 888 bits - 128, 256 bits 440, 888 bits - 128, 256 bits 256, 320, 384 bits - 128, 192, 256 bits

Type - Category Entropy input - CSP Seed - CSP Seed - CSP Seed - CSP Internal state - CSP

Generate d By Random Number Generatio n with HMAC DRBG, Hash DRBG or Counter DRBG Random Number Generatio n with HMAC DRBG, Hash DRBG or Counter DRBG Random Number Generatio n with HMAC DRBG, Hash DRBG or Counter DRBG Random Number Generatio n with HMAC DRBG, Hash DRBG or Counter DRBG

Establishe d By

Used By Random Number Generation with HMAC DRBG, Hash DRBG or Counter DRBG Random Number Generation with HMAC DRBG, Hash DRBG or Counter DRBG Random Number Generation with HMAC DRBG, Hash DRBG or Counter DRBG Random Number Generation with HMAC DRBG, Hash DRBG or Counter DRBG Random Number Generation with HMAC DRBG, Hash DRBG or Counter DRBG

© 2025 IBM / atsec information security.

37 of 71

Name Hash_DRBG Internal State (V, C) (IG D.L) HMAC_DRB G Internal State (V, Key) (IG D.L) DH Public Key DH Private Key EC Public Key EC Private Key Intermediat e Key Generation Value

Description Internal state of Hash DRBG instance Internal state of HMAC DRBG instance Public key used for KAS- FFC-SSC DH private key used for KAS-FFC-SSC Public key used for KAS- ECC-SSC EC private key used for KAS-ECC-SSC Intermediate value generated during Key Pair Generation

Size - Strength 880, 1776 bits - 128, 256 bits 320, 512, 1024 bits - 128, 256 bits ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192 - 112-200 bits ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192 - 112-200 bits P-256, P-384 - 128, 192 bits P-521, P-384 - 128, 192 bits 192-8192 bits - 112-256 bits

Type - Category Internal state - CSP Internal state - CSP Public key - PSP Private key - CSP Public key - PSP Private key - CSP Intermediat e value - CSP

Generate d By Random Number Generatio n with HMAC DRBG, Hash DRBG or Counter DRBG Random Number Generatio n with HMAC DRBG, Hash DRBG or Counter DRBG Key Pair Generatio n with ECDSA or Safe Primes Key Pair Generatio n with ECDSA or Safe Primes Key Pair Generatio n with ECDSA or Safe Primes Key Pair Generatio n with ECDSA or Safe Primes Key Pair Generatio n with ECDSA or Safe Primes

Establishe d By

Used By Random Number Generation with HMAC DRBG, Hash DRBG or Counter DRBG Random Number Generation with HMAC DRBG, Hash DRBG or Counter DRBG Shared Secret Computation with KAS- FFC-SSC or KAS-ECC-SSC Shared Secret Computation with KAS- FFC-SSC or KAS-ECC-SSC Shared Secret Computation with KAS- FFC-SSC or KAS-ECC-SSC Signature Verification with ECDSA Shared Secret Computation with KAS- FFC-SSC or KAS-ECC-SSC Key Pair Generation with ECDSA or Safe Primes

© 2025 IBM / atsec information security.

38 of 71

Name RSA Public Key Key- Derivation Key KBKDF Derived Key KDA OneStep Derived Key

Description RSA Public key used for Signature Verification with RSA Used for key derivation Generated by key-based key derivation Generated by OneStep KDA key derivation

Size - Strength 2048-4096 bits - 112-150 bits 112-4096 bits - 112-256 bits 112-4096 bits - 112-256 bits 2048 bits - 112 bits

Type - Category Public key - PSP Symmetric key - CSP Symmetric key - CSP Symmetric key - CSP

Generate d By Key Derivation with KBKDF Key Derivation with KDA OneStep

Establishe d By

Used By Signature Verification with RSA Key Derivation with KBKDF

Table 19: SSP Table 1 © 2025 IBM / atsec information security.

39 of 71

© 2025 IBM / atsec information security.

40 of 71

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

41 of 71

Table 21: Pre-Operational Self-Tests The pre-operational software integrity tests are performed automatically when the module is powered on, before the module transitions into the operational state. While the module is executing the self-tests, services are not available, and data output (via the data output interface) is inhibited until the tests are successfully completed. The module transitions to the operational state only after the pre-operational self-tests are passed successfully.

© 2025 IBM / atsec information security.

42 of 71

© 2025 IBM / atsec information security.

43 of 71

© 2025 IBM / atsec information security.

44 of 71

© 2025 IBM / atsec information security.

45 of 71

© 2025 IBM / atsec information security.

46 of 71

© 2025 IBM / atsec information security.

47 of 71

© 2025 IBM / atsec information security.

48 of 71

© 2025 IBM / atsec information security.

49 of 71

© 2025 IBM / atsec information security.

50 of 71

© 2025 IBM / atsec information security.

51 of 71

© 2025 IBM / atsec information security.

52 of 71

© 2025 IBM / atsec information security.

53 of 71

© 2025 IBM / atsec information security.

54 of 71

© 2025 IBM / atsec information security.

55 of 71

56 of 71

Table 22: Conditional Self-Tests

Table 23: Pre-Operational Periodic Information © 2025 IBM / atsec information security.

57 of 71

© 2025 IBM / atsec information security.

58 of 71

© 2025 IBM / atsec information security.

59 of 71

© 2025 IBM / atsec information security.

60 of 71

© 2025 IBM / atsec information security.

61 of 71

© 2025 IBM / atsec information security.

62 of 71

© 2025 IBM / atsec information security.

63 of 71

Table 24: Conditional Periodic Information

Table 25: Error States In the Error State, the output interface is inhibited, and the module accepts no more inputs or requests (as the module is no longer running). © 2025 IBM / atsec information security.

64 of 71

The software integrity tests, cryptographic algorithm self-tests, and entropy source start-up tests can be invoked on demand by unloading and subsequently re-initializing the module. The pair-wise consistency tests can be invoked on demand by requesting the key pair generation service. © 2025 IBM / atsec information security.

65 of 71

Procedures On the ClevOS 3.19 operational environment, the module is distributed within the clevos3.19.2.F1606-44_fips-accesser-usbiso.iso image. There are no specific steps for installing the module, the module is installed as part of operating system.

The Approved and non-Approved modes of operation are specified in section 2.4. The administrative functions are specified in the Approved Services table. All the physical ports and logical interfaces are specified in section 3.1. The Crypto Officer must execute the Show version service using following commands: $ cat /proc/sys/crypto/fips_name The Crypto Officer must ensure that the proper name is listed in the output as follows: IBM COS Linux Kernel Cryptographic API Then, the Crypto Officer must execute: $ cat /proc/sys/crypto/fips_version This command must output the following version for kernel components: 3.0 Then, the Crypto Officer must execute: $ apt list --installed | grep libkcapi This command must output the following version for libkcapi and kcapi-hasher components: 1.5.0-1 amd64 On the ClevOS 3.19 operational environments, versions of the installed packages can be verified using the following command: $ dpkg-query -W linux-image-6.1.0-32-amd64 libkcapi1 kcapi-tools © 2025 IBM / atsec information security.

66 of 71

The approved and non-approved security functions available to users are listed in section 2, the physical ports, and logical interfaces available to users are specified in section 3.1. The Approved and non-Approved modes of operation are specified in section 2.4. The algorithmspecific information is listed in section 2.7.

As the module does not persistently store SSPs, secure sanitization of the module consists of unloading the module. This will zeroize all SSPs in volatile memory. If desired, the linux-image-6.1.0-32-amd64, libkcapi1, and kcapi-tools deb packages can be uninstalled from the ClevOS 3.19 system. © 2025 IBM / atsec information security.

67 of 71

The module does not offer mitigation of other attacks and therefore this section is not applicable. © 2025 IBM / atsec information security.

68 of 71

Appendix A. Glossary and Abbreviations AES                Advanced Encryption Standard API                Application Programming Interface CAST               Cryptographic Algorithm Self-Test CAVP               Cryptographic Algorithm Validation Program CBC                Cipher Block Chaining CCM                Counter with Cipher Block Chaining-Message Authentication Code CFB                Cipher Feedback CKG                Cryptographic Key Generation CMAC               Cipher-based Message Authentication Code CMVP               Cryptographic Module Validation Program CSP                Critical Security Parameter CTR                Counter CTS                Ciphertext Stealing DRBG               Deterministic Random Bit Generator ECB                Electronic Code Book ECC                Elliptic Curve Cryptography ECDH               Elliptic Curve Diffie-Hellman ECDSA              Elliptic Curve Digital Signature Algorithm FFC                Finite Field Cryptography FIPS               Federal Information Processing Standards GCM                Galois Counter Mode GMAC               Galois Counter Mode Message Authentication Code HKDF               HMAC-based Key Derivation Function HMAC               Keyed-Hash Message Authentication Code IPsec              Internet Protocol Security KAS                Key Agreement Scheme KAT                Known Answer Test KBKDF              Key-based Key Derivation Function KW                 Key Wrap MAC                Message Authentication Code NIST               National Institute of Science and Technology OFB                Output Feedback PAA                Processor Algorithm Acceleration PAI                Processor Algorithm Implementation PCT                Pair-wise Consistency Test PBKDF2             Password-based Key Derivation Function v2 PKCS               Public-Key Cryptography Standards RSA                Rivest, Shamir, Addleman SHA                Secure Hash Algorithm SSC                Shared Secret Computation SSP                Sensitive Security Parameter XTS                XEX-based Tweaked-codebook mode with cipher text Stealing © 2025 IBM / atsec information security.

69 of 71

Appendix B. References FIPS 140-3 FIPS PUB 140-3 - Security Requirements For Cryptographic Modules March 2019 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf FIPS 140-3 IG Implementation Guidance for FIPS PUB 140-3 and the (Last Update: Cryptographic Module Validation Program April 18, 2025) https://csrc.nist.gov/Projects/cryptographic-module-validationprogram/fips-140-3-ig-announcements FIPS 180-4 Secure Hash Standard (SHS) March 2012 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf FIPS 186-4 Digital Signature Standard (DSS) July 2013 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf FIPS 186-5 Digital Signature Standard (DSS) February 2023 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf FIPS 197 Advanced Encryption Standard May 9, 2023 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197-upd1.pdf FIPS 198-1 The Keyed Hash Message Authentication Code (HMAC) July 2008 https://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf FIPS 202 SHA-3 Standard: Permutation-Based Hash and ExtendableOutput Functions August 2015 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf PKCS#1 Public Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 February 2003 https://www.ietf.org/rfc/rfc3447.txt RFC 3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) May 2003 https://www.ietf.org/rfc/rfc3526.txt RFC 4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) June 2005 https://datatracker.ietf.org/doc/html/rfc4106 RFC 7296 Internet Key Exchange Protocol Version 2 (IKEv2) October 2014 https://datatracker.ietf.org/doc/html/rfc7296 SP 800-38A Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 https://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf © 2025 IBM / atsec information security.

70 of 71

SP 800-38A Recommendation for Block Cipher Modes of Operation: Three Addendum Variants of Ciphertext Stealing for CBC Mode October 2010 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication80038a-add.pdf SP 800-38B Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication May 2005 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38B.pdf SP 800-38C Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality May 2004 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication80038c.pdf SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC November 2007 https://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf SP 800-38E Recommendation for Block Cipher Modes of Operation: The XTS AES Mode for Confidentiality on Storage Devices January 2010 https://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf SP 800-38F Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping December 2012 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf SP 800-56Ar3 Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography April 2018 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.80056Ar3.pdf SP 800-90Ar1 Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.80090Ar1.pdf SP 800-90B Recommendation for the Entropy Sources Used for Random Bit Generation January 2018 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf SP 800-133r2 Recommendation for Cryptographic Key Generation June 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800133r2.pdf SP 800-140Br1 CMVP Security Policy Requirements March 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800140Br1.pdf © 2025 IBM / atsec information security.

71 of 71