IBM® Crypto for C

Certificate

Approved Algorithms (90)

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

flowchart LR
  %% Deterministic review-risk graph for IBM® Crypto for C
  %% 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</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status Output<br/>Self-test</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</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® Crypto for C
  %% 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</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Status Output<br/>Self-test</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<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 C2,C3,C5,C6 clueLow;

Security Policy, page by page

IBM® Crypto for C version 8.8.1.0 Document version: 1.1 Last update: 2024-07-18 Prepared by: atsec information security corporation

4516 Seton Center Parkway, Suite 250

Austin, TX 78759 www.atsec.com © 2024 IBM® Corporation / atsec information security

This document is a non-proprietary FIPS 140-3 Security Policy for the IBM® Crypto for C (ICC) cryptographic module. It contains a specification of the 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 a security level 1 multi-chip standalone The table below shows the security level claimed for each of the twelve sections that comprise the FIPS 140-3 standard. Table 1 - Security Levels © 2024 IBM® Corporation. / atsec information security.

4 of 47

The IBM® Crypto for C cryptographic module is implemented in the C programming language. It is packaged as a dynamic (shared) library usable by applications written in a language that supports C language linking conventions (e.g., C, C++, Java, Assembler, etc.) for use on commercially available operating systems. The ICC allows these applications to access cryptographic functions using an Application Programming Interface (API) provided through an ICC import library and based on the API defined by the OpenSSL group. The software provided to the customer consists of:

• ICC shared library (libicclib84.dll for Windows, libicclib084.so for the rest): shared library (executable code) containing proprietary code needed to meet FIPS and functional requirements not provided by OpenSSL (e.g., entropy source, DRBG, self-tests, startup/shutdown), the OpenSSL cryptographic library and the zlib used for entropy estimation. This shared library constitutes the cryptographic module.
• ICCSIG.txt file: contains the signature file used for integrity tests. The cryptographic module takes advantage of the hardware cryptographic acceleration features supported by the testing platforms that are part of the operational environment, as shown in the following table. The following table presents the operational environments on which version 8.8.1.0 of the cryptographic module was tested and validated. Each operational environment includes the hardware platform, the processor and the operating system. Each row of the table also includes the corresponding version of the module. Table 2 - Tested Operational Environments The module maintains its compliance on other operating systems, provided that:
• the operating system meets the operational environment requirements at the module’s level of validation; © 2024 IBM® Corporation. / atsec information security.

5 of 47

• the module does not require modification to run in the new environment. 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 table below lists all approved algorithms of the module, including specific key strengths employed for approved services, and implemented modes of operation. Each algorithm specifies the CAVP certificate for each of the implementations (whether the module was set or unset to take advantage of the processor algorithm acceleration (PAA) or processor algorithm implementation (PAI) capabilities). The selection of the implementations with and without acceleration can be done using the ICC_CAPABILITY_MASK environment variable. © 2024 IBM® Corporation. / atsec information security.

6 of 47

© 2024 IBM® Corporation. / atsec information security.

7 of 47

© 2024 IBM® Corporation. / atsec information security.

8 of 47

© 2024 IBM® Corporation. / atsec information security.

9 of 47

© 2024 IBM® Corporation. / atsec information security.

10 of 47

© 2024 IBM® Corporation. / atsec information security.

11 of 47

© 2024 IBM® Corporation. / atsec information security.

12 of 47

© 2024 IBM® Corporation. / atsec information security.

13 of 47

© 2024 IBM® Corporation. / atsec information security.

14 of 47

Table 3 - Approved Algorithms The Module contains no non-Approved but Allowed security functions, security claimed or otherwise. The table below lists Non-Approved security functions that are not Allowed in the Approved Mode of Operation. © 2024 IBM® Corporation. / atsec information security.

15 of 47

Table 4 - Non-Approved Not Allowed in the Approved Mode of Operation The relationship between ICC and IBM applications is shown in the following diagram. ICC comprises a static stub linked into the IBM application which binds the API functions with the shared library containing the cryptographic functionality. (Figure 1) below depicts the following information:

• IBM Application - The IBM application using ICC. This contains the application code, and the ICC static stub.
• IBM Application code - The program using ICC to perform cryptographic functions.
• ICC static stub: static library (object code) that is linked into the customer’s application and communicates with the Crypto Module. It includes the C headers (source code) containing the API prototypes and other definitions needed for linking the static library. Linked into the calling application to bind the API with the implementation of the cryptographic services in the shared library. This static library is not part of the cryptographic module.
• ICC shared library - This contains proprietary code needed to meet FIPS requirements and cryptographic services not provided by OpenSSL, a statically linked copy of zlib used by the entropy source for entropy estimation, and a statically linked copy of the OpenSSL cryptographic library.
• The cryptographic boundary of the cryptographic module consists of the ICC shared library bounded by the dashed red line in the figure. The signature used for the integrity check of the ICC during its initialization is contained in the file ICCSIG.txt. This file is considered within the cryptographic boundary.
• The physical perimeter of the operational environment is defined to be the enclosure of the computer that runs the ICC software. © 2024 IBM® Corporation. / atsec information security.

16 of 47

Figure 1 - Logical Block Diagram © 2024 IBM® Corporation. / atsec information security.

17 of 47

The ICC meets the requirements of a multi-chip standalone module. Since the ICC is a software module, its interfaces are defined in terms of the API that it provides. These interfaces are described in the following table1: Note that because the module is a software only module, there are no physical ports. Table 5 - Ports and Interfaces 1The module does not implement a control output interface. © 2024 IBM® Corporation. / atsec information security.

18 of 47

The ICC assumes the Crypto-Officer role only (there is no User or Maintenance Role). The module does not support operator identification or authentication. Only a single operator assuming the Crypto Officer role may operate the module at any particular moment in time as concurrent operation is not supported. The module provides a service indicator that specifies, for a given service, whether the service is approved or non-approved. The module provides the ICC_SetValue() function with the ICC_FIPS_CALLBACK parameter to register a callback function using the following prototype: void service_indicator_function(char *function, int nid, int status) This function is invoked by the module whenever a service is requested, providing the service name (function), the algorithm (nid), and the service indicator (status). A status value of 1 means the service is approved, 0 means non-approved. The module does not identify nor authenticate any user (in any role) that is accessing the module. The Crypto Officer role is implicitly assumed by the services that are requested. The available services are as follows: © 2024 IBM® Corporation. / atsec information security.

19 of 47

Table 6 – Roles and Services The table below lists all approved services that can be used in the approved mode of operation. The abbreviations of the access rights to keys and SSPs have the following interpretation: 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 zeroises the SSP. N/A: The service does not access any SSP during its operation. © 2024 IBM® Corporation. / atsec information security.

20 of 47

© 2024 IBM® Corporation. / atsec information security.

21 of 47

© 2024 IBM® Corporation. / atsec information security.

22 of 47

Table 7 - Approved Services The following table shows the services and algorithms not allowed in the approved of operation. Requesting these services will implicitly put the module in the non-approved mode of operation. © 2024 IBM® Corporation. / atsec information security.

23 of 47

Table 8 - Non-Approved Services © 2024 IBM® Corporation. / atsec information security.

24 of 47

The services provided by the Module to a User are effectively delivered using appropriate API calls. When a client process attempts to load an instance of the Module into memory, the Module runs an integrity test and the cryptographic algorithm self-tests. If all the tests pass successfully, the Module makes a transition to the "Operational" state, where the API calls can be used by the client to obtain desired cryptographic services. Otherwise, the Module enters to “Error” state and returns an error to the calling application. When the Module is in “Error” state, no services are available, and all of data input and data output except the status information are inhibited. The module uses an integrity test which uses a 2048-bit CAVP-validated RSA signature verification (PKCS#1v1.5) and SHA2-256 hashing. This RSA public key is stored inside the shared library.

Integrity tests are performed as part of the Pre-Operational Self-Tests. They are automatically executed at power-on. Integrity tests can also be requested on demand through the API function ICC_IntegrityCheck. © 2024 IBM® Corporation. / atsec information security.

25 of 47

The IBM® Crypto for C operates in a modifiable operational environment per FIPS 140-3 level 1 specifications. It is part of a commercially available general-purpose operating system executing on the hardware specified in section 2.

The following operational rules must be followed by any user of the cryptographic module: 1. Since the ICC runs on a general-purpose processor all main data paths of the computer system will contain cryptographic material. The following items need to apply relative to where the ICC will execute:

• Virtual (paged) memory must be secure (local disk or a secure network)
• The disk drive where ICC is installed must be in a secure environment. The above rules must be always upheld in order to ensure continued system security and FIPS 140-

3 approved mode compliance after initial setup of the validated configuration. If the module is

removed from the above environment, it is assumed not to be operational in the validated mode until such time as it has been returned to the above environment and re-initialized by the user to the validated condition. © 2024 IBM® Corporation. / atsec information security.

26 of 47

The FIPS 140-3 physical security requirements do not apply to the IBM® Crypto for C, since it is a software module. © 2024 IBM® Corporation. / atsec information security.

27 of 47

Currently, the non-invasive security is not required by FIPS 140-3 (see NIST SP 800-140F). The requirements of this area are not applicable to the module. © 2024 IBM® Corporation. / atsec information security.

28 of 47

The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module: © 2024 IBM® Corporation. / atsec information security.

29 of 47

© 2024 IBM® Corporation. / atsec information security.

30 of 47

© 2024 IBM® Corporation. / atsec information security.

31 of 47

© 2024 IBM® Corporation. / atsec information security.

32 of 47

Table 9 – SSPs ICC employs a Deterministic Random Bit Generator (DRBG) based on [SP800-90Arev1] for the creation of asymmetric keys. In addition, the module provides a Random Number Generation service to calling applications. © 2024 IBM® Corporation. / atsec information security.

33 of 47

The default algorithm is Hash_DRBG using SHA2-256 with no prediction resistance, but another algorithm from the Hash_DRBG, HMAC_DRBG and CTR_DRBG algorithms (see Table 3 for the complete list) can be also configured. CPU high-resolution timer. ENT(NP) is compliant with [SP800-90B], and guarantees an entropy rate of 0.5 bits per bit. The DRBG entropy input and nonce to form the seed are of the same length (64 bytes = 512 bits each) and obtained from separate and independent calls to the entropy source. Then, the DRBG is seeded during initialization with the entropy input and nonce containing 512 bits of entropy ((512 + 512) * 0.5 = 512), and with the entropy input containing 256 bits of entropy (512 * 0.5) during reseeding . Therefore, the DRBG supports 256 bits of effective security strength in its output. Table 10 - Non-Deterministic Random Number Generation Specification

The module generates Keys and SSPs in accordance with FIPS 140-3 IG D.H. The cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys as per section 4, example 1, and section 5.1 [SP800-133rev2], compliant with [FIPS186-4] and [SP800-56Arev3]. A seed used for key generation is a direct output from DRBG compliant with [SP800-90A]. The security strength of 256 bits of the DRBG is equal to the security strength of the maximum key size that can be generated by the module. The key generation services for RSA, Diffie-Hellman and EC key pairs as well as the [SP 800-90A] DRBG have been tested under the CAVP with algorithm certificates found in Table 3. The ICC provides the following key derivation services in the approved mode of operation:

• PBKDF Key Derivation
• For PBKDF, the module implements a CAVP compliance tested key derivation function compliant to [SP800-132] and IG D.N. The service returns the key derived from the provided password to the caller.
• HKDF Key Derivation
• The module provides [SP800-135rev1] compliant key derivation function in accordance with [SP800-56Crev1] two-step key derivation, extraction and expansion procedure. The derived keys provide between 112 and 256 bits of security strength.

The ICC uses the following key establishment methodologies in the approved mode of operation:

• Diffie-Hellman (DH) shared secret computation
• The module provides SP800-56Arev3 compliant key agreement schemes according to FIPS 140-3 IG D.F scenario 2 path (1) with DH shared secret computation. The shared secret computation provides between 112 and 200 bits of encryption strength. © 2024 IBM® Corporation. / atsec information security.

34 of 47

• Elliptic Curve Diffie-Hellman (ECDH) shared secret computation
• The module provides SP800-56Arev3 compliant key agreement schemes according to FIPS 140-3 IG D.F scenario 2 path (1) with ECDH shared secret computation. The shared secret computation provides between 112 and 256 bits of encryption strength.
• AES key wrapping
• The module implements a Key Transport Scheme (KTS) using AES-KW and AES-KWP compliant to [SP800-38F] and IG D.G. The SSP establishment methodology provides between 128 and 256 bits of encryption strength.

Keys/SSPs are entered into and output from the ICC module in electronic form through the data input and output interface (i.e. API function parameters). The ICC module does not support manual key entry or intermediate key generation key output. The SSPs are provided to the module via API input parameters in the plaintext form and output via API output parameters in the plaintext form to and from the calling application.

The module does not provide any long-term key storage and no keys are ever stored on the hard disk.

The memory occupied by SSPs is allocated by regular memory allocation operating system calls. The calling application that is acting as the Crypto Officer is responsible for calling the appropriate functions provided in the module's API to zeroize the memory areas allocated by the module. Key zeroization services for cipher contexts are performed via the following API functions.

• ICC_BN_clear_free(): clean up big numbers
• ICC_BN_CTX_free(): clean up memory used by low-level big number arithmetic functions
• ICC_EVP_MD_CTX_cleanup(): clears Message Digest context
• ICC_EVP_CIPHER_CTX_cleanup(): clean up symmetric cipher context
• ICC_RSA_free(): clean up RSA context
• ICC_DSA_free(): clean up DSA context
• ICC_DH_free(): clean up Diffie-Hellman context
• ICC_EVP_PKEY_free(): clean up asymmetric key contexts
• ICC_HMAC_CTX_free(): clean up HMAC context
• ICC_EC_KEY_free(): clean up ECDSA and ECDH contexts
• ICC_CMAC_CTX_free(): clean up CMAC context
• ICC_AES_GCM_CTX_free(): clean up AES-GCM context
• ICC_RNG_CTX_free(): clean up RNG context The zeroization functions overwrite the memory occupied by SSPs with “zeros” and deallocate the memory with the regular memory deallocation operating system call. The completion of a zeroization routine(s) will indicate that a zeroization procedure succeeded. © 2024 IBM® Corporation. / atsec information security.

35 of 47

The ICC module implements a number of self-tests to check proper functioning of the module. This includes pre-operational self-tests and conditional self-tests. Pre-operational integrity test and Cryptographic Algorithm Self-Tests (CASTs) are automatically invoked by the module when the module is powered on from the default entry point (DEP) of the shared library.. When the module is performing self-tests, no API functions are available, and no data output is possible until the self-tests are successfully completed. After the pre-operational self-tests and CASTs are successfully completed, the module turns to approved mode of operation. Requesting any services from Table 8 will implicitly put the module in the non-approved mode of operation. The module performs self-tests automatically when it is loaded. Self-tests can also be requested on demand through the API functions ICC_SelfTest() and ICC_IntegrityCheck(). Whenever the startup tests are initiated the module performs the following; if any of these tests fail, the module enters the error state:

The module performs a pre-operational software integrity test automatically when the module is powered on, before the module transitions into the operational state. The integrity test is performed with a 2048-bit CAVP-validated RSA signature verification (PKCS#1v1.5) and SHA2-256 hashing. This RSA public key is stored inside the shared library. Prior to the invocation of the integrity test, the module runs the conditional Cryptographic Algorithm Self-Test (CAST) for RSA (2048-bit keys with SHA2-256) which verifies the proper functioning of all algorithms used as part of the integrity test.

The following sections describe the conditional tests supported by the IBM® Crypto for C. The IBM® Crypto for C runs all Cryptographic Algorithm Self-Tests during power-up, and consequently before the first operational use of the cryptographic algorithms. These tests are detailed in the following table. © 2024 IBM® Corporation. / atsec information security.

36 of 47

The IBM® Crypto for C does generate asymmetric keys and performs all required pair-wise digital signature. If the digital signature cannot be verified, the test fails. Pair-wise consistency EC Diffie-Hellman is covered by ECDSA PCT as allowed by IG 10.3, additional comment 1. its operation, to detect intermittent and permanent failures in the noise source. The health tests compliant with the requirements of SP800-90B, and the minimum-entropy assessment test, which © 2024 IBM® Corporation. / atsec information security.

37 of 47

analyzes whether the noise source provides the expected entropy rate using the min-entropy calculation formula as specified in section 2.1 of SP800-90B. If the ICC module detects a permanent failure in any of the health tests, the module transitions to the error state and an error message is shown (“Insufficient entropy”).

When errors are detected (e.g., self-test failure) then all security related functions are disabled and no partial data is exposed through the data output interface. The only way to transition from the error state to an operational state is to reinitialize the cryptographic module (from an uninitialized state). The error state can be retrieved via the Show Status service. © 2024 IBM® Corporation. / atsec information security.

38 of 47

The following steps must be performed to install and initialize the module for operating in a FIPS 140-3 compliant manner:

1. The operating system must be configured to operate securely and to prevent remote login. This is accomplished by disabling all services (within the Administrative tools) that provide remote access (e.g., – ftp, telnet, ssh, and server) and disallowing multiple operators to log in at once.
2. Before the module initialization, the user has a choice to configure the default DRBG algorithm to use. This can be set using the environment variable ‘ICC_RANDOM_GENERATOR’.
3. The module is initialized automatically when the shared library is loaded in the calling application process space. The module executes the pre-operational self tests (POST) and, if they are successful, the module enters the approved mode of operation. The calling application must include the following calling sequence to have access to the cryptographic services: • ICC_Init() creates the crypto module context. • ICC_Attach() binds the cryptographic functions with the API entry points.

It is the responsibility of the Crypto-Officer to configure the operating system to operate securely. The services provided by the Module to a User are effectively delivered by using the appropriate API calls. When a client process attempts to load an instance of the Module into memory, the Module runs an integrity test and several of cryptographic functionality self-tests. If all the tests pass successfully, the Module makes a transition to the "Operational" state, where the API calls can be used by the client to obtain desired cryptographic services. Otherwise, the Module enters to “Error” state and returns an error to the calling application. When the Module is in “Error” state, no services are available, and all of data input and data output except the status information are inhibited. The Crypto Officer shall consider the following requirements and restrictions when using the module:

1. The AES algorithm in XTS mode can be only used for the cryptographic protection of data on storage devices, as specified in [SP800-38E]. The length of a single data unit encrypted with the XTS-AES shall not exceed 2²⁰ AES blocks (16MB of data).
2. To meet the requirement in [FIPS140-3-IG] C.I, the module implements a check to ensure that the two AES keys used in the XTS-AES algorithm are not identical.
3. AES-GCM IV is constructed in compliance with IG C.H scenario
4. In case the module’s power is lost and then restored, the keys used for the AES GCM encryption/decryption shall be re-distributed. The GCM is used in the context of TLS version 1.2. The mechanism for IV generation is compliant with RFC 5288 as described in Section 3.3.1 of SP800-52rev2. The design of the TLS protocol implicitly ensures that the nonce_explicit, or counter portion of the IV will not exhaust all its possible values.
5. The module also offers an AES-GCM implementation under the context of Scenario 5 of IG C.H. The protocol that provides this compliance is TLS 1.3, using the ciphersuites that © 2024 IBM® Corporation. / atsec information security.

39 of 47

explicitly select AES-GCM as the encryption/decryption cipher. The module supports acceptable AES-GCM ciphersuites from Section 3.3.1 of SP800-52rev2. The design of the TLS protocol implicitly ensures that the nonce_explicit, or counter portion of the IV will not exhaust all its possible values. In the event the module’s power is lost and restored, the consuming application must ensure that new AESGCM keys encryption or decryption under this scenario are established. TLS 1.3 provides session resumption, but the resumption procedure derives new AES-GCM encryption keys.

5. For PBKDF, the module implements a CAVP compliance tested key derivation function compliant to [SP800-132] and IG D.N. The service returns the key derived from the provided password to the caller. PBKDF is implemented to support the option 1a specified in section 5.4 of [SP800-132]. The keys derived from [SP800-132] map to section 4.1 of [SP800-133rev2] as indirect generation from DRBG. In accordance with [SP800-132], the following requirements shall be met: a. Derived keys shall only be used in storage applications. The Master Key (MK) shall not be used for other purposes. The length of the MK or Data Protection Key (DPK) shall be of 112 bits or more. b. A portion of the salt, with a length of at least 128 bits, shall be generated randomly using the SP800-90A DRBG, c. The iteration count shall be equal or greater than 1000, so as to make the key derivation computationally intensive. d. Passwords or passphrases, used as an input for the PBKDF, shall not be used as cryptographic keys. e. The length of the password or passphrase shall be at least ten characters long, and may consist of lower-case, upper-case, numeric, or special characters. At a minimum length of ten characters, and assuming a worst case scenario where the password uses a combination of only lower case and numbers (36 symbols), the chance of randomly guessing this password is 1 / 3610 = 3.656 10-15.
6. For SHA-3 algorithms, the module implements HMAC with SHA3-224, SHA3-256, SHA3-384, SHA3-512. The CAVP certificates have been obtained for the HMAC and HKDF algorithms as well as for all the SHA-3 implementations. The CAVP certificates are listed in Table 3 in Section 2.
7. The module implements FIPS 186-4 RSA SigGen and SigVer. RSA SigGen is supported with key sizes of 2048, 3072, 4096 bits while RSA SigVer is supported with 1024, 2048, 3072,

4096 bits. All RSA key sizes have been CAVP tested with the certificates listed in Table 3 in

Section 2. 8. For Diffie-Hellman or EC Diffie-Hellman shared secret computation, the module has to comply with the assurances found in Section 5.6.2 of [SP800-56Arev3] and IG D.F. The operator must obtain the ephemeral Diffie-Hellman or EC Diffie-Hellman key pairs on both ends either by using the approved key pair generation service provided by the module, or by using another FIPS-validated module. As part of the key pair generation service, the module internally performs the full key validation of the generated key pair. Similarly, the shared secret computation service internally performs 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 [SP800-56Arev3]. © 2024 IBM® Corporation. / atsec information security.

40 of 47

The module code is a component provided to IBM products, not a product on its own. Typically it is provided as part of IBM’s SSL component and creates packaging with the OS specific install tools. The module’s End-of-Life/sanitization procedure can take one of two forms:

• OS uninstall which removes the package after checking that no currently installed package still depends on it. The module does not possess persistent storage of SSPs. The SSP value only exists in volatile memory and that value vanishes when the module is powered off. The procedure for secure sanitization of the module at the end of life is simply to power it off, which is the action of zeroization of the SSPs . As a result of this sanitization via power-off, the SSP is removed from the module, so that the module may either be distributed to other operators or disposed.
• Alternatively the package may be upgraded and replaced by a newer version. © 2024 IBM® Corporation. / atsec information security.

41 of 47

The cryptographic module is not designed to mitigate any specific attacks. © 2024 IBM® Corporation. / atsec information security.

42 of 47

Appendix A. Glossary and Abbreviations AES                 Advanced Encryption Standard AES-NI              Advanced Encryption Standard New Instructions CAVP                Cryptographic Algorithm Validation Program CBC                 Cipher Block Chaining CCM                 Counter with Cipher Block Chaining-Message Authentication Code CFB                 Cipher Feedback CMAC                Cipher-based Message Authentication Code CMVP                Cryptographic Module Validation Program CSP                 Critical Security Parameter CTR                 Counter Mode DES                 Data Encryption Standard DF                  Derivation Function DSA                 Digital Signature Algorithm DRBG                Deterministic Random Bit Generator ECB                 Electronic Code Book ECC                 Elliptic Curve Cryptography ENT                 NIST SP 800-90B compliant Entropy Source FFC                 Finite Field Cryptography FIPS                Federal Information Processing Standards Publication FSM                 Finite State Model GCM                 Galois Counter Mode HMAC                Hash Message Authentication Code KAS                 Key Agreement Schema KAT                 Known Answer Test KW                  AES Key Wrap KWP                 AES Key Wrap with Padding MAC                 Message Authentication Code NDF                 No Derivation Function NIST                National Institute of Science and Technology OFB                 Output Feedback O/S                 Operating System PAA                 Processor Algorithm Acceleration PAI                 Processor Algorithm Implementation PR                  Prediction Resistance PSS                 Probabilistic Signature Scheme © 2024 IBM® Corporation. / atsec information security.

43 of 47

RNG                 Random Number Generator RSA                 Rivest, Shamir, Addleman SHA                 Secure Hash Algorithm SHS                 Secure Hash Standard SSH                 Secure Shell TDES                Triple-DES XTS                 XEX-based Tweaked-codebook mode with cipher text Stealing © 2024 IBM® Corporation. / atsec information security.

44 of 47

SP800-108 NIST Special Publication 800-108 - Recommendation for Key Derivation Using Pseudorandom Functions (Revised) October 2009 https://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf SP800-131Arev2 Transitioning the Use of Cryptographic Algorithms and Key Lengths March 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf SP800-132 NIST Special Publication 800-132 - Recommendation for PasswordBased Key Derivation - Part 1: Storage Applications December 2010 https://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf SP800-133rev2 Recommendation for Cryptographic Key Generation June 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf © 2024 IBM® Corporation. / atsec information security.

47 of 47