| Standard | FIPS 140-3 |
|---|---|
| Overall level | 1 |
| Module type | Software-hybrid |
| Embodiment | Multi-Chip Stand Alone |
| Status | Active |
| Sunset date | 10/6/2029 |
| Caveat | Interim validation. When operated in approved mode with module SUSE Linux Enterprise OpenSSL Cryptographic Module validated to FIPS 140-3 under Cert. #4725 operating in approved mode. When installed, initialized and configured as specified in Section 11 of the Security Policy |
| Vendor | SUSE, LLC |
flowchart LR
%% Deterministic review-risk graph for SUSE Linux Enterprise Libica 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</i>"]
C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status Output<br/>Show status<br/>Self-Test</i>"]
C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>HTTPS<br/>library named: openssl<br/>library named: nss</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 Libica 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</i><br/>src: text:keyword"]
C3["[low] Self-test / status surface (referenced in text)<br/><i>Status Output<br/>Show status<br/>Self-Test</i><br/>src: text:keyword"]
C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>HTTPS<br/>library named: openssl<br/>library named: nss</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;SUSE Linux Enterprise Libica Cryptographic Module Software version 1.1 Hardware version IBM z15 Version 1.1 Last update: 2024-10-01 Prepared by: atsec information security corporation
Austin, TX 78759 www.atsec.com © 2024 SUSE, LLC / atsec information security.
2.8 Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security
© 2024 SUSE, LLC / atsec information security.
© 2024 SUSE, LLC / atsec information security.
This document is the non-proprietary FIPS 140-3 Security Policy for software version 1.1 and hardware version "IBM z/15" of the SUSE Linux Enterprise Libica Cryptographic Module. It has a one-to-one mapping to the [SP 800-140B] starting with section B.2.1 named “General” that maps to section 1 in this document and ending with section B.2.12 named “Mitigation of other attacks” that maps to section 12 in this document. ISO/IEC 24759 FIPS 140-3 Section Title Security Level Section 6. [Number Below]
1 General 1
2 Cryptographic Module Specification 1
3 Cryptographic Module Interfaces 1
4 Roles, Services, and Authentication 1
5 Software/Firmware Security 1
6 Operational Environment 1
7 Physical Security 1
8 Non-invasive Security N/A
9 Sensitive Security Parameter Management 1
10 Self-tests 1
11 Life-cycle Assurance 1
12 Mitigation of Other Attacks N/A
Table 1
The SUSE Linux Enterprise Libica Cryptographic Module (hereafter referred to as “the module”) is a software-hybrid module that provides general purpose cryptographic algorithms to applications running in the user space of the underlying operating system through a C language application program interface (API). The module is composed by a software library, which provides the API and a subset of the cryptographic algorithms, and the Central Processor Assist for Cryptographic Functions (CPACF), which is part of the z15 processor and provides cryptographic algorithms implemented in hardware. In addition, the module uses the SUSE Linux Enterprise OpenSSL Cryptographic Module as a bound module (also referred to as “the bound OpenSSL module”), which provides additional algorithms not implemented in Libica. The SUSE Linux Enterprise OpenSSL Cryptographic Module has been FIPS 140-3 validated with certificate #4725. For the purpose of the FIPS 140-3 validation, the module is a software-hybrid, multi-chip standalone cryptographic module validated at overall security level 1.
The software block diagram below shows the cryptographic boundary of the module, and its interfaces with the operational environment. Figure 1
Component Version Components Description Type Software 1.1 /usr/lib64/libica.so.4.2.1 Shared library for cryptographic algorithms /usr/lib64/.libica.so.4.2.1.hmac Integrity check HMAC value for the Libica shared library Hardware IBM z15 Coprocessor that implements CPACF is implemented on the z15 the CPACF1, integrated into the processor and provides processor z15 processor. acceleration implementations (PAI) for AES, SHA-1, SHA-2, SHA-3, SHAKE and ECC algorithm implementations. Table 2
The module supports two modes of operation:
The module has been tested on the following platforms with the corresponding module variants and configuration options: # Operating System Hardware Processor PAA/Acceleration Platform
1 SUSE Linux Enterprise Server 15 SP4 IBM z/15 with z15 With CPACF (PAI)
FC3863 Table 3
1 The IBM z/15 hardware must have Feature Code 3863 (FC3863) enabled. This feature code enables processor
acceleration implementations (PAI) for AES, and ECC algorithms. © 2024 SUSE, LLC / atsec information security.
In addition to the platforms listed in Table 3, SUSE has also tested the module on the platforms in Table 4, and claims vendor affirmation on them. Note: the 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. # Operating System Hardware platform Processor PAA/Acceleration
1 SUSE Linux Enterprise Server IBM LinuxONE III LT1 z15 With CPACF (PAI)
2 SUSE Linux Enterprise Micro 5.3 IBM z/15 with FC3863 z15 With CPACF (PAI)
3 SUSE Linux Enterprise Micro 5.3 IBM LinuxONE III LT1 z15 With CPACF (PAI)
4 SUSE Linux Enterprise Base IBM z/15 with FC3863 z15 With CPACF (PAI)
5 SUSE Linux Enterprise Base IBM LinuxONE III LT1 z15 With CPACF (PAI)
Container Image 15SP4 with FC3863 Table 4 - Vendor-Affirmed Operational Environments
Table 5 below lists all security functions of the Libica module, including specific key strengths employed for approved services, and implemented modes of operation. CAVP Cert Algorithm and Mode / Method Description / Key Use / Function Standard Size(s) / Key Strength(s) A3378 AES CBC 128, 192, 256-bit keys Symmetric FIPS197, with 128-256 bits of encryption; SP800-38A security strength Symmetric decryption AES CBC_CS1 128, 192, 256-bit keys Symmetric FIPS197, CBC_CS2 with 128-256 bits of encryption; SP800-38A-add CBC_CS3 security strength Symmetric decryption AES CCM 128, 192, 256-bit keys Authenticated SP800-38C with 128-256 bits of encryption; security strength Authenticated decryption AES CFB8, CFB128 128, 192, 256-bit keys Symmetric FIPS197, with 128-256 bits of encryption; SP800-38A security strength Symmetric decryption © 2024 SUSE, LLC / atsec information security.
CAVP Cert Algorithm and Mode / Method Description / Key Use / Function Standard Size(s) / Key Strength(s) AES CMAC 128, 192, 256-bit keys Message SP800-38B with 128-256 bits of authentication security strength code (MAC) AES CTR 128, 192, 256-bit keys Symmetric FIPS197, with 128-256 bits of encryption; SP800-38A security strength Symmetric decryption AES ECB 128, 192, 256-bit keys Symmetric FIPS197, with 128-256 bits of encryption; SP800-38A security strength Symmetric decryption AES OFB 128, 192, 256-bit keys Symmetric FIPS197, with 128-256 bits of encryption; SP800-38A security strength Symmetric decryption AES XTS 128, 256-bit keys with Symmetric SP800-38E 128 and 256 bit of encryption and security strength symmetric decryption (for data storage) A3377, A3378 AES GCM with 128, 192, 256-bit keys Authenticated FIPS197, internal IV with 128-256 bits of encryption; SP800-38D (section 8.2.2) security strength Authenticated decryption A3377, A3378 AES GMAC 128, 192, 256-bit keys Message FIPS197, with 128-256 bits of authentication SP800-38D security strength code (MAC) A3378 ECDSA SHA2-224, SHA2- P-256, P-384, P-521 Digital signature FIPS186-4 256, SHA2-384, with 128-256 bits of generation SHA2-512 security strength SHA-1, SHA2- P-256, P-384, P-521 Digital signature 224, with 128-256 bits of verification SHA2-256, SHA2- security strength (usage of SHA-1 is 384, SHA2-512 considered Legacy Use) A3378 KAS-ECC-SSC ECC Ephemeral P-256, P-384, P-521 Shared secret SP800-56Arev3 Unified Scheme with 128-256 bits of computation security strength A3378 SHA-3 SHA3-224, SHA3- N/A Message digest FIPS202 256, SHA3-384, SHA3-512, SHAKE-128, SHAKE-256 © 2024 SUSE, LLC / atsec information security.
CAVP Cert Algorithm and Mode / Method Description / Key Use / Function Standard Size(s) / Key Strength(s) A3378 SHS SHA-1, N/A Message digest FIPS180-5 SHA2-224, SHA2-256, SHA2-384, SHA2-512, SHA2-512/224, SHA2-512/256 Table 5
CAVP Cert Algorithm Mode / Description / Key Use / Function and Method Size(s) / Key Standard Strength(s) A3147 SHS SHA2-256 N/A Integrity test FIPS180-5 Table 6
of Operation The module does not implement non-approved algorithms that are allowed in the approved mode of operation.
of Operation with No Security Claimed The module does not implement non-approved algorithms that are allowed in the approved mode of operation.
Mode of Operation Table 7 lists non-approved algorithms implemented in the Libica module that are not allowed in the approved mode of operation. These algorithms are used by the non-approved services listed in Table 11. The Libica mode does not use any non-approved algorithm implemented in the bound OpenSSL module. Algorithm/Functions Use/Function RSA modulus exponentiation primitive. Sign, verify, encrypt, and decrypt primitives. DRBG Random Number Generation service Table 7
The logical interfaces are the API through which applications request services. The ports and interfaces are shown in the following table. All data output via data output interface is inhibited when the module is performing preoperational test or zeroization or when the module enters error state. Logical Physical Port Data that passes over port/interface Interface2 Data Input None API input parameters for data. Data Output None API output parameters for data. Control Input None API function calls, API input parameters for control input, /proc/sys/crypto/fips_enabled control file, ICAPATH environment variable. Status Output None API return codes, API output parameters for status output. Power Input PC Power Supply N/A Port Table 8
2 The control output interface is omitted on purpose because the module does not implement it.
© 2024 SUSE, LLC / atsec information security.
The module supports the Crypto Officer role only. This sole role is implicitly assumed by the operator of the module when performing a service. The module does not support authentication. Role Service Input Output Crypto Symmetric decryption Ciphertext, key Plaintext Officer (CO) Symmetric encryption Plaintext, key Ciphertext Authenticated encryption Plaintext, key Ciphertext, authentication tag Authenticated decryption Ciphertext, authentication Plaintext, return code tag, key (pass/fail) Key pair generation Key size Key pair Digital signature generation Message, hash algorithm, Signature private key Digital signature verification Signature, hash Signature verification result algorithm, public key EC Diffie-Hellman shared Private key, public key Shared secret secret computation from peer Message authentication code Message, key Message authentication code (MAC) generation Message authentication code Message, key, message Return code (pass/fail) (MAC) verification authentication code Message digest Message Message digest On-demand integrity test and None Return codes/log messages self-tests Random number generation Number of bytes Random numbers Show module name and None Module name and version version Module installation and None Log messages configuration Zeroization Context containing SSPs None Table 9
Table 10 lists the approved services. For each service, the table lists the associated cryptographic algorithm(s), the role to perform the service, the cryptographic keys or CSPs involved, and their access type(s). The following convention is used to specify access rights to a CSP:
3 This service is providing using algorithms implemented in the bound OpenSSL module.
© 2024 SUSE, LLC / atsec information security.
Service Description Approved Keys and/or Roles Access Indicator Security SSPs rights to Functions Keys and/or SSPs Generate ECDSA ECDSA, DRBG Module- E, G, R ica_get_fips_ key pairs generated indicator() ECDSA public returns .fips_ approved = 1 key, Modulegenerated ECDSA private key Digital signature Generate ECDSA ECDSA, DRBG, ECDSA private W, E ica_get_fips_ generation signature SHS key indicator() returns .fips_ approved = 1 Digital signature Verify ECDSA ECDSA, SHS ECDSA public W, E ica_get_fips_ verification signature key indicator() returns .fips_ approved = 1 Shared secret EC Diffie-Hellman KAS-ECC-SSC EC Diffie- W, E ica_get_fips_ computation shared secret Hellman private indicator() computation key returns .fips_ approved = 1 EC Diffie- W, E Hellman public key from peer EC Diffie- E, G, R Hellman shared secret Message digest Compute SHA SHA-1, SHA2- None N/A ica_get_fips_ hashes 224, indicator() SHA2-256, returns .fips_ approved = 1 SHA2-384, SHA2-512 SHA3-224, None N/A ica_get_fips_ SHA3-256, indicator() SHA3-384, returns .fips_ approved = 1 SHA3-512, SHAKE-128, SHAKE-256 Message Compute AES- CMAC with AES AES key W, E ica_get_fips_ authentication based CMAC indicator() code (MAC) returns .fips_ approved = 1 generation Compute AES- GMAC with AES AES key ica_get_fips_ based GMAC indicator() returns .fips_ approved = 1 Message Verify AES-based CMAC with AES AES key W, E ica_get_fips_ authentication CMAC indicator() code (MAC) returns .fips_ approved = 1 verification Verify AES-based GMAC with AES AES key ica_get_fips_ GMAC indicator() returns .fips_ approved = 1 © 2024 SUSE, LLC / atsec information security.
Service Description Approved Keys and/or Roles Access Indicator Security SSPs rights to Functions Keys and/or SSPs Other FIPS-related Services Show status Show module N/A None CO N/A Implicit status (always approved) Zeroization Zeroize CSPs N/A All CSPs Z Implicit (always approved) On-demand Perform integrity AES, ECDSA, None N/A Implicit Integrity test test and self-tests DRBG, HMAC, (always and self-tests on-demand RSA, SHS approved) Self-tests Perform self-tests AES, ECDSA, None N/A Implicit DRBG, HMAC, (always RSA, SHS approved) Show module Show module N/A None N/A Implicit name and name and version (always version approved) Module Install and N/A None N/A Implicit installation and configure module (always configuration approved) Table 10 - Approved Services Table 11 lists the non-approved services. The details of the non-approved cryptographic algorithms available in the non-approved mode can be found in Table 7. Service Description Algorithms Accessed Role Cryptographic Services Random Obtain random numbers DRBG SHA2-512 CO Number Generation RSA RSA sign, verify, encrypt and decrypt RSA primitives Table 11 - Non-Approved Services © 2024 SUSE, LLC / atsec information security.
The integrity of the module is verified by comparing an HMAC-SHA2-256 value calculated at run time with the HMAC value stored in the .hmac file that was computed at build time for each software component of the module. If the HMAC values do not match, the test fails and the module enters the error state. The module uses the HMAC-SHA2-256 algorithm provided by the OpenSSL bound module.
Integrity tests are performed as part of the Pre-Operational Self-Tests. The module provides the Self-Test service to perform self-tests on demand which includes the preoperational tests (i.e., integrity test) and cryptographic algorithm self-tests (CASTs). This service can be invoked by using the ica_fips_powerup_tests() API function call. During the execution of the on-demand self-tests, services are not available, and no data output or input is possible. In order to verify whether the self-tests have succeeded and the module is in the Operational state, the calling application may invoke the ica_fips_status(). See section 10.3 for more information about the possible return values.
The module consists of executable code in the form of the Libica file stated in Table 2. © 2024 SUSE, LLC / atsec information security.
This module operates in a modifiable operational environment per the FIPS 140-3 level 1 specifications. The SUSE Linux Enterprise Server operating system is used as the basis of other products. Compliance is maintained for SUSE products whenever the binary is found unchanged per the vendor affirmation from SUSE based on the allowance FIPS 140-3 management manual [FIPS140-3_MM] section 7.9.1 item 1. c) i). Note: The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when supported if the specific operational environment is not listed on the validation certificate.
Instrumentation tools like the ptrace system call, gdb and strace utilities, 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-tested operational environment.
The module shall be installed as stated in section 11. 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. © 2024 SUSE, LLC / atsec information security.
The Libica module inherits the physical characteristics of the host running it; the module has no physical security characteristics of its own. Figure 3 illustrates the IBM System z15 mainframe computer that represents the testing platform, that includes the hardware component of the cryptographic module. Figure 2
Figure 3
This module does not implement any non-invasive security mechanism, and therefore this section is not applicable. © 2024 SUSE, LLC / atsec information security.
Table 12 summarizes the Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module. Key/SS Stren Security Generation Import/Export Establishm Stora Zeroizatio Use & related P gth Function and ent ge n keys Name/ Cert. Number Type AES key 128, AES-CBC, N/A Import: CM N/A RAM Zeroized by Use: 192, AES-CBC-CS1, from TOEPP calling Symmetric
256 AES-CBC-CS2, Path. application. encryption;
AES-CBC-CS3, Passed into the Symmetric AES-CCM, AES- module via API decryption; CFB128, AES- parameters in Authenticated CFB8, AES-CMAC, plaintext (P) encryption; AES-CTR, format. Authenticated AES-ECB, decryption; AES-GCM, Export: N/A Message AES-GMAC, authentication AES-OFB, code (MAC) AES-XTS4 Related A3378 SSPs: N/A AES-GCM, AES-GMAC, A3377 ECDSA 128, ECDSA N/A Import: CM N/A RAM Zeroized by Use: Digital public 192, A3378 from TOEPP calling signature key 256 Path. application. verification Passed into the Related module via API SSPs: ECDSA parameters in private key plaintext (P) format. Export: N/A ECDSA 128, ECDSA N/A Import: CM N/A RAM Zeroized by Use: Digital private 192, A3378 from TOEPP calling signature key 256 Path. application. generation Passed into the Related module via API SSPs: ECDSA parameters in public key plaintext (P) format. Export: N/A EC 128, KAS-ECC-SSC N/A Import: CM N/A RAM Zeroized by Use: EC DiffieDiffie- 192, A3378 from TOEPP calling Hellman Hellman 256 Path. application. shared secret private Passed into the computation key module via API Related parameters in SSPs: N/A plaintext (P) format. Export: N/A
© 2024 SUSE, LLC / atsec information security.
Key/SS Stren Security Generation Import/Export Establishm Stora Zeroizatio Use & related P gth Function and ent ge n keys Name/ Cert. Number Type EC 128, KAS-ECC-SSC N/A Import: CM N/A RAM Zeroized by Use: EC DiffieDiffie- 192, A3378 from TOEPP calling Hellman Hellman 256 Path. application. shared secret public Passed into the computation key module via API Related from parameters in SSPs: N/A peer plaintext (P) format. Export: N/A EC 128, KAS-ECC-SSC N/A Import: N/A Established RAM Zeroized by Use: EC DiffieDiffie- 192, A3378 during the calling Hellman Hellman 256 EC Diffie- application. shared secret shared Export: CM to Hellman computation secret TOEPP Path. shared Related Passed out from secret SSPs: EC the module via computation Diffie-Hellman API output per SP800- public key parameters in 56Arev3. from peer; EC plaintext. Diffie-Hellman private key SSPs used for cryptographic services provided by the bound OpenSSL module Module- 128, ECDSA B.4.2 Import: N/A N/A RAM Zeroized by Use: Key generat 192, A3147 Testing calling generation ed 256 Candidates application. Related ECDSA Export: CM to SSPs: DRBG public Generated TOEPP Path. Internally internal state, key by the Passed out from zeroized Modulebound the module via via generated OpenSSL API parameters EVP_PKEY_ ECDSA private using the in plaintext (P) CTX_free, key FIPS 186-4 format. EVP_PKEY_f random ree, values are OPENSSL_fr obtained ee from the OpenSSL SP80090Arev1 DRBG. Module- 128, ECDSA B.4.2 Import: N/A N/A RAM Zeroized by Use: Key generat 192, A3147 Testing calling generation ed 256 Candidates application. Related ECDSA Export: CM to SSPs: DRBG private Generated TOEPP Path. Internally internal state, key by the Passed out from zeroized Modulebound the module via via generated OpenSSL API parameters EVP_PKEY_ ECDSA public using the in plaintext (P) CTX_free, key FIPS 186-4 format. EVP_PKEY_f random ree, values are OPENSSL_fr obtained ee from the OpenSSL SP80090Arev1 DRBG. © 2024 SUSE, LLC / atsec information security.
Key/SS Stren Security Generation Import/Export Establishm Stora Zeroizatio Use & related P gth Function and ent ge n keys Name/ Cert. Number Type Module- 112, RSA Generated Import: N/A N/A RAM Zeroized by Use: Key generat 128, A3147, by the calling generation ed RSA 149 CTR_DRBG A3150 bound application. Related public OpenSSL Export: CM to SSPs: DRBG key using TOEPP Path. Internally Internal state, method Passed out from zeroized ModuleB.3.3 the module via via generated RSA specified in API parameters RSA_free private key FIPS 186-4; in plaintext (P) random format. values are obtained from the SP80090Arev1 DRBG. Entropy 192 CTR_DRBG A3150 Obtained Import/Export: N/A RAM FIPS_drbg_f Use: Random input to from the N/A; it remains ree number
384 entropy within the generation
IG D.L bits source cryptographic Related complia boundary. SSPs: DRBG nt seed DRBG 192 CTR_DRBG A3150 Generated Import/Export: N/A RAM FIPS_drbg_f Use: Random seed to from the N/A; it remains ree number
384 entropy within the generation
IG D.L bits input as cryptographic Related complia defined in boundary. SSPs: Entropy nt SP800- input, DRBG 90Arev1 Internal state DRBG 128 CTR_DRBG Generated Import/Export: N/A RAM FIPS_drbg_f Use: Random internal to A3150 from the N/A; it remains ree number state 256 DRBG seed within the generation (V, key) bits as defined in cryptographic Related SP800- boundary. SSPs: DRBG IG D.L 90Arev1 seed complia nt Table 12
The Deterministic Random Bit Generator (DRBG) is provided by the bound OpenSSL module. The DRBG is based on [SP800-90Arev1] for the creation of RSA and ECDSA keys in OpenSSL, and for the random generation of the IV used in AES GCM and the k value used in ECDSA signature generation. The use of the DRBG provided by the bound OpenSSL module is only internal. Notice that the Libica module implements a separate DRBG for providing a random generation number service, but this algorithm implementation, as well as the service, are considered non-approved. The DRBG is initialized during initialization of the bounded OpenSSL module; this module loads the DRBG by default using the CTR_DRBG mechanism with AES-256, with derivation function, and without prediction resistance. The bound Open SSL module uses an SP800-90B-compliant entropy source specified in Table 13. This entropy source is located within the physical perimeter, but outside of the cryptographic © 2024 SUSE, LLC / atsec information security.
boundary of the module. The module obtains 384 bits to seed the DRBG, and 256 bits to reseed it, sufficient to provide a DRBG with 256 bits of security strength. Entropy Source Minimum number of Details bits of entropy ESV certs. E28, E29 256 bits of entropy in Standalone Userspace CPU Time Jitter RNG the 256-bit output version 3.4.0 entropy source (with SHA-3 as the vetted conditioning component) is located within the physical perimeter of the operational environment but outside the cryptographic boundary of the bound OpenSSL module. Table 13 - Non-Deterministic Random Number Generation Specification
The bounded OpenSSL module provides an [SP800-90Arev1]-compliant Deterministic Random Bit Generator (DRBG) for the creation of key components of asymmetric keys, and random number generation. For generating RSA, ECDSA keys, the bounded module implements asymmetric key generation services compliant with [FIPS186-4]. A seed (i.e., the random value) used in asymmetric key generation is directly obtained from the [SP800-90Arev1] DRBG. The public and private keys used in EC Diffie-Hellman shared secret computation are generated internally by the bound OpenSSL module using the ECDSA key generation method compliant with [FIPS186-4] and [SP800-56Arev3]. In accordance with FIPS 140-3 IG D.H, the bound cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys as per section 5.1 of SP800-133rev2 (vendor affirmed) by obtaining a random bit string directly from an approved DRBG and that can support the required security strength requested by the caller (without any V, as described in Additional Comments 2 of IG D.H).
The module does not provide key transport mechanisms.
The module provides EC Diffie-Hellman shared secret computation compliant with SP800-56Arev3, in accordance with scenario 2 (1) of IG D.F. According to Table 2: Comparable strengths in [SP800-57rev5], the key sizes of EC Diffie-Hellman provides the following security strength in the approved mode of operation:
The module does not support direct manual SSP entry or intermediate SSP generation output. The SSPs are provided to the module via API input parameters in plaintext form and output via API output parameters in plaintext form within the physical perimeter of the operational environment. This is allowed by [FIPS140-3_IG] 9.5.A, according to the “CM Software to/from App via TOEPP Path” entry on the Key Establishment Table. © 2024 SUSE, LLC / atsec information security.
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.
For those SSPs that are either imported or exported, it is the responsibility of the calling application to zeroize them once they are no longer utilized. Internal values to store SSPs are zeroized automatically before returning the control to the calling application. Zeroization is performed by overwriting the memory with zeroes. For services implemented in the bound OpenSSL module, the Libica module calls internally the appropriate zeroization functions provided by the bound module (e.g. OPENSSL_cleanse) before returning to the calling application. 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 will indicate that a zeroization procedure succeeded. Also, module reset can zeroize all SSPs for both the module and the OpenSSL bound module. © 2024 SUSE, LLC / atsec information security.
The module performs pre-operational tests and CASTs automatically when the module is loaded into memory. Pre-operational tests ensure that the module is not corrupted, and the CASTs ensure that the cryptographic algorithms work as expected. While the module is executing the preoperational tests and CASTs, services are not available, and input and output are inhibited. The module is not available for use by the calling application until the pre-operational tests are completed successfully. After the pre-operational test and the CASTs succeed, the module becomes operational. If any of the pre-operational test or any of the CASTs fail an error message is returned, and the module transitions to the error state.
The module performs the integrity test of the software component using HMAC-SHA2-256. The integrity test uses the HMAC algorithm implemented in the bound OpenSSL module, which tests this algorithm as part of the CASTs when loaded into memory and before Libica performs the preoperational tests. The details of integrity test are provided in section 5.1.
Table 14 specifies the CASTs performed by the Libica module. All CASTs performed are in the form of the Known Answer Tests (KATs) and are run prior to performing the integrity test. A KAT includes the comparison of a calculated output with an expected known answer, hard coded as part of the test vectors used in the test. If the values do not match, the KAT fails. Algorithm Condition Test AES Power on KAT AES ECB mode with 128, 192 and 256 bit keys, encryption and decryption (separately tested). KAT AES CBC mode with 128, 192 and 256 bit keys, encryption and decryption (separately tested). KAT AES CBC_CS mode with 128, 192 and 256 bit keys, encryption and decryption (separately tested). KAT AES CFB mode with 128, 192 and 256 bit keys, encryption and decryption (separately tested). KAT AES OFB mode with 128, 192 and 256 bit keys, encryption and decryption (separately tested). KAT AES CTR mode with 128, 192 and 256 bit keys, encryption and decryption (separately tested). KAT AES CCM mode with 128, 192 and 256 bit keys, encryption and decryption (separately tested). KAT AES GCM mode with 128, 192 and 256 bit keys, encryption and decryption (separately tested). KAT AES XTS mode with 128 and 256 bit keys, encryption and decryption (separately tested). CMAC Power on KAT AES CMAC with 128-bit key, MAC generation. GMAC Power on KAT AES GMAC with 128-bit key, MAC generation. © 2024 SUSE, LLC / atsec information security.
Algorithm Condition Test ECDH Power on KAT ECDH shared secret computation with P-256. ECDSA Power on KAT ECDSA with P-256 and SHA2-256, signature generation and verification (separately tested), SHA-3 Power on KAT SHA3-224, SHA3-256, SHA3-384 and SHA3-512. SHS Power on KAT SHA-1, SHA2-224, SHA2-256, SHA2-384 and SHA2-512. Table 14
The bound OpenSSL module performs the Pair-wise Consistency Tests (PCT) shown in Table
On-Demand self-tests can be invoked by calling the fips_powerup_tests() API function, which causes the module to run the pre-operational tests again. During the execution of the on-demand self-tests, services are not available, and no data output or input is possible. To verify whether the self-tests have succeeded, and the module is in the Operational state, the calling application may invoke the ica_fips_status() API function. See section 10.3 for more information about the possible return values. © 2024 SUSE, LLC / atsec information security.
When the module fails any pre-operational self-test or conditional test, the module will return an error code to indicate the error and will enter the Error state. Any further cryptographic operation is inhibited. The calling application can obtain the module state by calling the ica_fips_status() API function. The function can return one following flags indicating the module is in the error state. Error State Cause of Error Status Indicator (bit flag) Self-test error state Failure of CAST ICA_FIPS_CRYPTOALG Failure of integrity tests ICA_FIPS_INTEGRITY Table 17 - Error States For errors occurred in the bound OpenSSL, any transition to the error state of the bound OpenSSL module puts the Libica module in the error state. © 2024 SUSE, LLC / atsec information security.
The Crypto Officer can install the RPM packages containing the module as listed in Table 19 using the zypper tool as follows. # zypper install libica4 The integrity of the RPM package is automatically verified during the installation, and the Crypto Officer shall not install the RPM package if there is any integrity error.
The module requires to run on a z15 processor that has Feature Code 3863 enabled. This feature enables processor acceleration implementations (PAI) in CPACF for AES and ECC algorithms (SHA1, SHA-2, SHA-3 and SHAKE algorithms are enabled by default in z15 processors). Make sure with your system administrator that the hardware platform meets this requirement. In addition, the operating environment needs to be configured to support the approved mode of operation, so the following steps shall be performed with the root privilege:
environment is not configured to support the approved mode of operation and the module will not operate as a FIPS validated module properly.
Table 18 includes the information on module installation process for the vendor affirmed platforms that are listed in Table 4. Product Link SUSE Linux Enterprise https://documentation.suse.com/sle-micro/5.3/single-html/SLE-MicroMicro 5.3 security/#sec-fips-slemicro-install SUSE Linux Enterprise Base https://documentation.suse.com/smart/linux/html/conceptContainer Image 15SP4 bci/index.html Table 18 - Installation for Vendor Affirmed Platforms Note: Per section 7.9 in the FIPS 140-3 Management Manual [FIPS140-3_MM], the Cryptographic Module Validation Program (CMVP) makes no statement as to the correct operation of the module or the security strengths of the generated keys when this module is ported and executed in an operational environment not listed on the validation certificate.
For secure sanitization of the cryptographic module, the module must first to be powered off, which will zeroize all keys and CSPs in volatile memory. Then, for actual deprecation, the module shall be upgraded to a newer version that is FIPS 140-3 validated. The module does not possess persistent storage of SSPs, so further sanitization steps are not required.
The binaries of the module are contained in the RPM packages for delivery. The Crypto Officer shall follow sections 11.1.1 and 11.1.2 to configure the operational environment and install the module to be operated as a FIPS 140-3 validated module. Table 19 lists the RPM package that contains the FIPS validated module and the OE directory where the components are installed. The "Show module name and version" service is implemented via the following API functions:
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, that is 16MB of data. To meet the requirement stated in IG C.I, the module implements a check that ensures, before performing any cryptographic operation, that the two AES keys used in AES XTS mode are not identical.
The AES GCM IV generation is in compliance with section 8.2.2 of [SP800-38D] and IG C.H scenario
2 [FIPS140-3_IG], in which the GCM IV is generated internally at its entirety randomly. The DRBG
provided by the OpenSSL bound module, compliant with SP800-90A-rev1, is used for generating the IV. The DRBG is fully seeded with entropy provided by the non-physical entropy source that is not within the cryptographic boundary of the module but within its physical perimeter. The GCM IV must be at least 96 bits in length, which is enforced by the module. When a GCM IV is used for decryption, the responsibility for the IV generation lies with the party that performs the AES GCM encryption. © 2024 SUSE, LLC / atsec information security.
The module does not implement any mitigation mechanism. © 2024 SUSE, LLC / atsec information security.
Appendix A. Glossary and Abbreviations AES Advanced Encryption Standard 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 CPACF Central Processor Assist for Cryptographic Function CSP Critical Security Parameter CTR Counter Mode DES Data Encryption Standard DF Derivation Function DRBG Deterministic Random Bit Generator ECB Electronic Code Book ECC Elliptic Curve Cryptography FIPS Federal Information Processing Standards Publication GCM Galois Counter Mode HMAC Hash Message Authentication Code KAS Key Agreement Schema KAT Known Answer Test MAC Message Authentication Code 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 RNG Random Number Generator RSA Rivest, Shamir, Addleman SHA Secure Hash Algorithm SHS Secure Hash Standard XTS XEX-based Tweaked-codebook mode with cipher text Stealing © 2024 SUSE, LLC / atsec information security.
Appendix B. References FIPS140-3 FIPS PUB 140-3 - Security Requirements For Cryptographic Modules March 2019 https://doi.org/10.6028/NIST.FIPS.140-3 FIPS140-3_IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program October 2022 https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validationprogram/documents/fips%20140-3/FIPS%20140-3%20IG.pdf FIPS140-3_MM FIPS 140-3 Cryptographic Module Validation Program Management Manual April 2024 https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validationprogram/documents/fips%20140-3/FIPS-140-3CMVP%20Management%20Manual.pdf FIPS180-4 Secure Hash Standard (SHS) March 2012 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf FIPS186-4 Digital Signature Standard (DSS) July 2013 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf FIPS197 Advanced Encryption Standard November 2001 https://csrc.nist.gov/publications/fips/fips197/fips-197.pdf FIPS198-1 The Keyed Hash Message Authentication Code (HMAC) July 2008 https://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf FIPS202 SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions August 2015 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf OPENSSL-SP SUSE Linux Enterprise Server OpenSSL Cryptographic Module https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validationprogram/documents/security-policies/140sp4725.pdf PKCS#1 Public Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 February 2003 https://www.ietf.org/rfc/rfc3447.txt © 2024 SUSE, LLC / atsec information security.
SP800-38A NIST Special Publication 800-38A - Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication80038a.pdf SP800-38A-add Addendum to NIST Special Publication 800-38A - Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode October 2010 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38aadd.pdf SP800-38B NIST Special Publication 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 SP800-38C NIST Special Publication 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 SP800-38D NIST Special Publication 800-38D - Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC November 2007 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication80038d.pdf SP800-38E NIST Special Publication 800-38E - Recommendation for Block Cipher Modes of Operation: The XTS AES Mode for Confidentiality on Storage Devices January 2010 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication80038e.pdf SP800-56Arev3 NIST Special Publication 800-56A Revision 2 - Recommendation for Pair Wise Key Establishment Schemes Using Discrete Logarithm Cryptography April 2018 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf SP800-57rev5 NIST Special Publication 800-57 Part 1 Revision 5 Recommendation for Key Management Part 1: General May 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.80057pt1r5.pdf © 2024 SUSE, LLC / atsec information security.
SP800-90Arev1 NIST Special Publication 800-90A - Revision 1 - Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf SP800-90B NIST Special Publication 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 SP800-131Arev2 NIST Special Publication 800-131A Revision 2 - Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths March 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800131Ar2.pdf SP800-133rev2 NIST Special Publication 800-133 Revision 2 - Recommendation for Cryptographic Key Generation June 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf SP800-135rev1 NIST Special Publication 800-135 Revision 1 - Recommendation for Existing Application-Specific Key Derivation Functions December 2011 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800135r1.pdf SP800-140B NIST Special Publication 800-140B - CMVP Security Policy Requirements March 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140B.pdf © 2024 SUSE, LLC / atsec information security.