SUSE Linux Enterprise NSS Cryptographic Module

Certificate

Approved Algorithms (97)

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

flowchart LR
  %% Deterministic review-risk graph for SUSE Linux Enterprise NSS 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/>Status Output<br/>Show status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>IKEV<br/>HTTPS</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 NSS 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/>Status Output<br/>Show status</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/>HTTPS</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C5,C6 clueLow;

Security Policy, page by page

SUSE Linux Enterprise NSS Cryptographic Module version 3.1 Version 1.1 Last update: 2024-06-25 Prepared by: atsec information security corporation

4516 Seton Center Pkwy, Suite 250

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.

2 of 48

© 2024 SUSE, LLC / atsec information security.

3 of 48

This document is the non-proprietary FIPS 140-3 Security Policy for version 3.1 of the SUSE Linux Enterprise NSS 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.

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

Table 1 describes the individual security areas of FIPS 140-3, as well as the security levels of those individual areas. Table 1 - Security Levels © 2024 SUSE, LLC / atsec information security.

4 of 48

The SUSE Linux Enterprise NSS Cryptographic Module (hereafter referred to as “the module”) is a Software multi-chip standalone cryptographic module. It provides a C language application program interface (API) designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSLv3, TLS, IKEv2, PKCS#5, PKCS#7, PKCS#11, PKCS#12, S/MIME, X.509 v3 certificates, and other security standards supporting FIPS 140-3 validated cryptographic algorithms.

The software block diagram below shows the cryptographic boundary of the module, and its interfaces with the operational environment. Figure 1 – Cryptographic Boundary © 2024 SUSE, LLC / atsec information security.

5 of 48

Table 2 lists the software components of the cryptographic module, which defines its cryptographic boundary. Table 2 – Cryptographic Module Components

When the module starts up successfully, after passing all the pre-operational and conditional cryptographic algorithms self-tests (CASTs), the module is operating in the approved mode of operation by default and can only be transitioned into the non-Approved mode by calling one of the non-Approved services listed in Table 11. Please see section 4.1.1 for details on the service indicator provided by the module that identifies when an approved service has been requested.

The module has been tested on the following platforms with the corresponding module variants and configuration options: © 2024 SUSE, LLC / atsec information security.

6 of 48

Table 3 - Tested Operational Environments

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. © 2024 SUSE, LLC / atsec information security.

7 of 48

Table 4 - Vendor-Affirmed Operational Environments

Table 5 lists all security functions of the module, including specific key strengths employed for approved services, and implemented modes of operation. The following are allowed for legacy use only: DSA signature verification with L=1024 and N=224. © 2024 SUSE, LLC / atsec information security.

8 of 48

© 2024 SUSE, LLC / atsec information security.

9 of 48

© 2024 SUSE, LLC / atsec information security.

10 of 48

© 2024 SUSE, LLC / atsec information security.

11 of 48

© 2024 SUSE, LLC / atsec information security.

12 of 48

CAVP Cert A3575, A3584, A3588 A3575

Algorithm and Standard FIPS180-4

Mode / Method SHA-224, SHA- 256 SHA-384, SHA- 512

Description / Key Size(s) / Key Strength(s)

Use / Function

Mode of Operation The module does not implement non-approved algorithms that are allowed in the approved mode of operation.

Mode of Operation with No Security Claimed Table 6 lists the non-approved algorithms that are allowed in the approved mode of operation with no security claimed. These algorithms are used by the approved services listed in Table 10. Table 6 - Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed

Mode of Operation Table 7 lists non-approved algorithms that are not allowed in the approved mode of operation. These algorithms are used by the non-approved services listed in Table 11.

1 These algorithms do not claim any security and are not used to meet FIPS 140-3 requirements. Therefore, SSPs do not

map to these algorithms. © 2024 SUSE, LLC / atsec information security.

13 of 48

© 2024 SUSE, LLC / atsec information security.

14 of 48

Table 7 - Non-Approved Not Allowed in the Approved Mode of Operation © 2024 SUSE, LLC / atsec information security.

15 of 48

As a software-only module, the module does not have physical ports. The operator can only interact with the module through the API provided by the module. Thus, the physical ports are interpreted to be the physical ports of the hardware platform on which the module runs. All data output via data output interface is inhibited when the module is performing preoperational test, conditional cryptographic algorithm self-tests, zeroization, or when the module enters the error state. Table 8 - Ports and Interfaces

2 The control output interface is omitted on purpose because the module does not implement it.

© 2024 SUSE, LLC / atsec information security.

16 of 48

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. No support is provided for multiple concurrent operators or a maintenance role. © 2024 SUSE, LLC / atsec information security.

17 of 48

Table 9 - Roles, Service Commands, Input and Output

The module provides services to the operators that assume the available role. Table 10 lists 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). In addition to the CSPs listed in Table 10, any hash values of passwords and RBG state information are considered to be CSPs. No support of intermediate key generation is provided. The following convention is used to specify access rights to a CSP:

• 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 = Zeroize: The module zeroizes the SSP.
• N/A: the calling application does not access any CSP or key during its operation. The details of the approved cryptographic algorithms including the CAVP certificate numbers can be found in Table 5. The module implements the method NSC_NSSGetFIPSStatus() to indicate whether the last service requested was approved (1). © 2024 SUSE, LLC / atsec information security.

18 of 48

© 2024 SUSE, LLC / atsec information security.

19 of 48

Service Public key verification Random number generation Message digest Message authentication code (MAC) Key wrapping Diffie-Hellman shared secret computation EC Diffie- Hellman shared secret computation Key derivation for TLS Key derivation for IKEv1 and IKEv2 Password- based key derivation Key-based key derivation

Description Verify a public key Generate random bitstrings Compute SHA hashes Compute a MAC tag Perform AES- based key wrapping Perform DH shared secret computation Perform ECDH shared secret computation Perform key derivation for TLS Perform key derivation for IKEv1 and IKEv2 Perform key derivation from a password/pass phrase Perform key derivation from a key

Approved Security Functions EC public key verification DRBG SHA-1, SHA-224, SHA-256, SHA- 384, SHA-512 AES-CMAC HMAC AES-KW AES-KWP KAS-FFC-SSC KAS-ECC-SSC TLS 1.0/1.1 KDF TLS 1.2 KDF KDA HKDF IKE KDF PBKDF KDF SP800-108 KDF with HMAC and CMAC-AES in Counter, Feedback, and Double-pipeline modes

Keys and/or SSPs EC public key Entropy input DRBG seed DRBG internal state None AES key HMAC key AES key Diffie-Hellman private key (owner) Diffie-Hellman public key (peer) Diffie-Hellman shared secret EC private key (owner) EC public key (peer) EC Diffie-Hellman shared secret (EC) Diffie-Hellman shared secret TLS derived secret (EC) Diffie-Hellman shared secret IKE derived secret PBKDF password or passphrase PBKDF derived key Key derivation key KBKDF derived key

Role

Access rights to Keys and/or SSPs W, E W, E G, E G, E N/A W, E W, E W, E W, E G, R W, E W, E G, R W, E G, R W, E G, R W, E G, R W, E G, R

Indicator NSC_NSSGetF IPSStatus= 1 NSC_NSSGetF IPSStatus= 1 NSC_NSSGetF IPSStatus= 1 NSC_NSSGetF IPSStatus= 1 NSC_NSSGetF IPSStatus= 1 NSC_NSSGetF IPSStatus= 1 NSC_NSSGetF IPSStatus= 1 NSC_NSSGetF IPSStatus= 1

© 2024 SUSE, LLC / atsec information security.

20 of 48

Service Cryptographic Services

Description

Algorithms Accessed

Role

Indicator

Table 11 lists the non-approved services. The details of the non-approved cryptographic algorithms available in non-approved mode can be found in Table 7. © 2024 SUSE, LLC / atsec information security.

21 of 48

Table 11 - Non-Approved Services © 2024 SUSE, LLC / atsec information security.

22 of 48

The integrity of the module is verified by performing a DSA signature verification for each component that comprises the module. The module uses DSA signature verification with a 2048bit key and SHA-256. If the DSA signature for any of the components cannot be verified, then the test fails, and the module enters the error state.

The module provides the Self-Test service to perform self-tests on demand which includes the preoperational test (i.e., integrity test) and the cryptographic algorithm self-tests (CASTs). The SelfTests service can be called on demand by invoking the sftk_FIPSRepeatIntegrityCheck() function which will perform integrity tests and the cryptographic algorithms self-tests. Additionally, the Self-Test service can be invoked by powering-off and reloading the module. During the execution of the ondemand self-tests, services are not available, and no data output is possible.

The module consists of executable code in the form of libsoftokn3.so, libnssdbm3.so and libfreeblpriv3.so shared libraries as stated in the Table 2. © 2024 SUSE, LLC / atsec information security.

23 of 48

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 section 7.9.1 bullet 1 a 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, the debugger gdb and strace, as well as other tracing mechanisms offered by the Linux environment (ftrace, systemtap) shall not be used. 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.

24 of 48

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

25 of 48

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

26 of 48

Table 12 summarizes the Sensitive Security Parameters (SSPs) that are used by the cryptographic

3 see Table 5 for the certificate number of each algorithm listed in this column.

© 2024 SUSE, LLC / atsec information security.

27 of 48

© 2024 SUSE, LLC / atsec information security.

28 of 48

© 2024 SUSE, LLC / atsec information security.

29 of 48

© 2024 SUSE, LLC / atsec information security.

30 of 48

© 2024 SUSE, LLC / atsec information security.

31 of 48

Table 12 - SSPs The module employs a Deterministic Random Bit Generator (DRBG) based on [SP800-90Arev1] for the creation of seeds for symmetric keys, asymmetric keys, RSA signature generation and ECDSA signature generation. In addition, the module provides a Random Number Generation service to calling applications. The DRBG supports the Hash_DRBG mechanism using SHA-256 and without prediction resistance. The module uses an SP800-90B-compliant entropy source specified in Table 13. This entropy module. The module obtains 384 bits to seed the DRBG, and 256 bits to reseed it, sufficient to Table 13 - Non-Deterministic Random Number Generation Specification

4 E28 Public Use Document: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-

validation-program/documents/entropy/E28_PublicUse.pdf

5 E29 Public Use Document: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-

validation-program/documents/entropy/E29_PublicUse.pdf © 2024 SUSE, LLC / atsec information security.

32 of 48

In accordance with FIPS 140-3 IG D.H, the cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys.

• For generating RSA and ECDSA keys, the module implements asymmetric cryptographic key generation (CKG) services compliant with [FIPS186-4], providing 112 to 149 bits of key strength for RSA and 128 to 256 bits for ECDSA.
• The public and private keys used in the EC Diffie-Hellman shared secret computation schemes are generated internally by the module using the EC key generation method compliant with [FIPS186-4] and [SP800-56Arev3], providing 128 to 256 bits of key strength.
• The public and private keys used in the Diffie-Hellman shared secret computation scheme are also compliant with [SP800-56Arev3]. The module generates keys using safe primes defined in RFC7919 and RFC3526, providing 112 to 200 bits of key strength as described in the next section. Additionally, for AES and HMAC keys, the module provides key derivation service compliant with section 4 of [SP800-133rev2], providing 128 to 256 bits of key strength for AES and 112-256 bits of key strength for HMAC. Random values used for symmetric and asymmetric key generation are obtained directly from an approved [SP800-90Arev1] 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), in compliance with section 4 of [SP800-133rev2]. The module supports the following key derivation methods:
• KDF for the TLS protocol, used as pseudo-random functions (PRF) for TLSv1.0/1.1 and TLSv1.2, compliant with [SP800-135rev1].
• KDF for the Internet Key Exchange (IKE) versions 1 and 2 protocol, compliant with [SP800135rev1].
• HKDF for the TLS protocol TLSv1.3, compliant with [SP800-56Crev2].
• KBKDF, compliant with [SP800-108rev1]. This implementation can be used to generate secret keys from a pre-existing key-derivation-key.
• PBKDF2, compliant with option 1a of [SP800-132]. This implementation can only be used to derive keys for storage applications.

The module provides Diffie-Hellman (dhEphem) and EC Diffie-Hellman (Ephemeral Unified Scheme) shared secret computation compliant with SP800-56Arev3, in accordance with scenario 2 (1) of IG D.F. For Diffie-Hellman, the module supports the use of safe primes from RFC7919 for domain parameters and key generation.

• TLS (RFC7919)
• ffdhe2048 (ID = 256)
• ffdhe3072 (ID = 257)
• ffdhe4096 (ID = 258)
• ffdhe6144 (ID = 259)
• ffdhe8192 (ID = 260) © 2024 SUSE, LLC / atsec information security.

33 of 48

The module also supports the use of safe primes from RFC3526, which are part of the Modular Exponential (MODP) Diffie-Hellman groups that can be used for Internet Key Exchange (IKE). Note that the module only implements key generation and verification, and shared secret computation using safe primes, but no part of the IKE protocol.

• IKEv2 (RFC3526)
• MODP-2048 (ID=14)
• MODP-3072 (ID=15)
• MODP-4096 (ID=16)
• MODP-6144 (ID=17)
• MODP-8192 (ID=18) For Elliptic Curve Diffie-Hellman, the module supports the NIST-defined P-256, P-384, and P-521 curves. According to Table 2: Comparable strengths in [SP800-57rev5], the key sizes of Diffie-Hellman and EC Diffie-Hellman provides the following security strength in the approved mode of operation:
• Diffie-Hellman shared secret computation provides between 112 and 200 bits of strength.
• EC Diffie-Hellman shared secret computation provides between 128 and 256 bits of strength. The module also provides the following key transport mechanisms in compliance with IG D.G:
• AES key wrapping using AES in KW, KWP modes with 128, 192, or 256 bit keys, providing 128, 192, or 256 bits of strength respectively.
• AES key wrapping using AES in GCM mode (in the context of the TLS protocol) with 128, 192, or 256 bit keys, providing 128, 192, or 256 bits of strength respectively. These algorithms have been CAVP tested and the obtained certificates are listed in Table 5 of this security policy. These algorithms can be used to wrap SSPs with a security strength of 128, 192, or 256 bits, depending on the wrapping key size.

The module does not support manual key entry or intermediate key generation key output. The SSPs has to be provided to the module via API input parameters in encrypted form (using the FC_UnwrapKey function) and output via API output parameters also in encrypted form (using the FC_WrapKey function). The module uses AES with KW/KWP compliant with SP800-38F as the approved key wrapping method. PSPs can be imported and exported in plaintext.

The module employs the cryptographic keys and CSPs in the approved mode of operation as listed in Table 12. The module does not perform persistent storage of keys. Note that the private key database (provided with the files key3.db/key4.db) is outside the cryptographic boundary. Symmetric keys, HMAC keys, public and private keys are provided to the module by the calling application via API input parameters and are destroyed by the module when invoking the appropriate API function calls. 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. © 2024 SUSE, LLC / atsec information security.

34 of 48

The memory occupied by SSPs is allocated by regular memory allocation operating system calls. The application that is acting as the CO is responsible for calling the appropriate zeroization functions provided in the module's API and listed in Table 12.

• The FC_Finalize, FC_CloseSession or FC_CloseAllSession functions overwrite the memory occupied by keys with “zeros” and deallocate the memory with the regular memory deallocation operating system call.
• The FC_DestroyObject function overwrites with "zeros" the area occupied by the secret key in the private key database. © 2024 SUSE, LLC / atsec information security.

35 of 48

The module performs the pre-operational self-test and CASTs automatically when the module is loaded into memory. The pre-operational self-test ensure that the module is not corrupted, and the CASTs ensure that the cryptographic algorithms work as expected. While the module is executing the self-tests, 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 and CASTs 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. In order to verify whether the self-tests have succeeded, the calling application may invoke the FC_Initialize function. The function will return CKR_OK if the module is operational, CKR_DEVICE_ERROR if the module is in the Error state.

The module performs pre-operational tests automatically when the module is powered on. The pre-operational self-tests ensure that the module is not corrupted. The module transitions to the operational state only after the pre-operational self-tests are passed successfully. The types of pre-operational self-tests are described in the next sub-sections.

and SHA-256. The details of integrity test are provided in section 5.1.

Table 14 specifies all the CASTs. The CASTs are performed 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. © 2024 SUSE, LLC / atsec information security.

36 of 48

Table 14 - Conditional Cryptographic Algorithms Self-Tests

The module performs the Pair-wise Consistency Tests (PCT) shown in the following table. If at least one of the tests fails, the module returns an error code and enters the Error state. When the module is in the Error state, no data is output, and cryptographic operations are not allowed. Table 15 - Pairwise Consistency Test © 2024 SUSE, LLC / atsec information security.

37 of 48

The module provides the Self-Test service to perform self-tests on demand which includes the preoperational test (i.e., integrity test) and the cryptographic algorithm self-tests (CASTs). The SelfTests service can be called on demand by invoking the sftk_FIPSRepeatIntegrityCheck() function which will perform integrity tests and the cryptographic algorithms self-tests. Additionally, the Self-Test service can be invoked by powering-off and reloading the module. During the execution of the ondemand self-tests, services are not available, and no data output is possible.

operational self-tests or conditional test. In the Error state, all data output is inhibited and no cryptographic operation is allowed. The error can be recovered by powering-off and reloading the module. Table 16 - Error States Self-test errors transition the module into an error state that keeps the module operational but prevents any cryptographic related operations. The module must be restarted and perform the per-operational self-test and the CASTs to recover from these errors. If failures persist, the module must be re-installed. © 2024 SUSE, LLC / atsec information security.

38 of 48

The Netscape Portable Runtime (NSPR) package (mozilla-nspr-4.23-3.9.1.x86_64.rpm) is a prerequisite for the module. The mozilla-nspr package must be installed in the operating environment. The Crypto Officer can install the RPM packages containing the module as listed in Table 18 using the zypper tool. 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 operating environment needs to be configured to support FIPS, so the following steps shall be performed with the root privilege:

1. Install the dracut-fips RPM package: # zypper install dracut-fips
2. Recreate the INITRAMFS image: # dracut -f
3. After regenerating the initrd, the Crypto Officer has to append the following parameter in the /etc/default/grub configuration file in the GRUB_CMDLINE_LINUX_DEFAULT line: fips=1
4. After editing the configuration file, please run the following command to change the setting in the boot loader: # grub2-mkconfig -o /boot/grub2/grub.cfg If /boot or /boot/efi resides on a separate partition, the kernel parameter boot=<partition of /boot or /boot/efi> must be supplied. The partition can be identified with the command "df /boot" or "df /boot/efi" respectively. For example: # df /boot Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 233191 30454 190296 14% /boot The partition of /boot is located on /dev/sda1 in this example. Therefore, the following string needs to be appended in the aforementioned grub file: "boot=/dev/sda1"
5. Reboot to apply these settings. Now, the operating environment is configured to support FIPS operation. The Crypto Officer should check the existence of the file /proc/sys/crypto/fips_enabled, and verify it contains a numeric value “1”. If the file does not exist or does not contain “1”, the operating environment is not configured to support FIPS and the module will not operate as a FIPS validated module properly.

The module may use the Unix syslog function and the audit mechanism provided by the operating system to audit events. Auditing is turned off by default. Auditing capability must be turned on as © 2024 SUSE, LLC / atsec information security.

39 of 48

part of the initialization procedures by setting the environment variable NSS_ENABLE_AUDIT to 1. The Crypto Officer must also configure the operating system's audit mechanism. The module uses the syslog function to audit events, so the audit data are stored in the system log. Only the root user can modify the system log. On some platforms, only the root user can read the system log; on other platforms, all users can read the system log. The system log is usually under the /var/log directory. The exact location of the system log is specified in the /etc/syslog.conf file. The module uses the default user facility and the info, warning, and err severity levels for its log messages. The module can also be configured to use the audit mechanism provided by the operating system to audit events. The audit data would then be stored in the system audit log. Only the root user can read or modify the system audit log. To turn on this capability it is necessary to create a symbolic link from the library file /usr/lib64/libaudit.so.1 to /usr/lib64/libaudit.so.1.0.0.

Table 17 includes the information on module installation process for the vendor affirmed platforms that are listed in Table 4. Table 17 - 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 needs 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 needed. © 2024 SUSE, LLC / atsec information security.

40 of 48

The binaries of the module are contained in the RPM packages for delivery. The Crypto Officer shall follow section 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 18 lists the RPM packages that contain the FIPS validated module. The "Show module name and version" is implemented by accessing the CKA_NSS_VALIDATION_MODULE_ID attribute of the CKO_NSS_VALIDATION object in the default slot. The object attribute contains the value “SUSE Linux Enterprise NSS 3.79.4-150400.3.29.1”, which matches the service output and the version information provided in the RPM packages where the module is distributed, and map to version 3.1 of the cryptographic module. Table 18 - RPM packages

In order to run in in the approved mode, the module must be operated using the approved services, with their corresponding approved and allowed cryptographic algorithms provided in this Security Policy (see section 2). In addition, key sizes must comply with [SP800-131Arev2]. The following module initialization steps must be followed before starting to use the NSS module:

• Set the environment variable NSS_ENABLE_AUDIT to 1 before using the module.
• Use the FC_GetFunctionList function to obtain pointer references to the API. The function returns a CK_FUNCTION_LIST structure containing function pointers named as the API functions but with the "C_" prefix (e.g. C_Initialize and C_Finalize). The function pointers reference the "FC_" prefixed functions. © 2024 SUSE, LLC / atsec information security.

41 of 48

• Use FC_Initialize (function pointer C_Initialize) to initialize the module. Ensure that the function returns CKR_OK, which means that the module was properly configured and the power-on self-tests were successful. If the function returns a different code, the module must be reset and initialized again. The module can be configured to use different private key database formats: key3.db or key4.db. “key3.db” format is based on the Berkeley DataBase engine and should not be used by more than one process concurrently. “key4.db” format is based on SQL DataBase engine and can be used concurrently by multiple processes. Both databases are considered outside the cryptographic boundary and all data stored in these databases are considered stored in plaintext. The interface code of the NSS cryptographic module that accesses data stored in the database is considered part of the cryptographic boundary. Secret and private keys, plaintext passwords, and other security-relevant data items are maintained under the control of the cryptographic module. Secret and private keys must be entered to the module from the calling application and output from the module to the calling application in encrypted form using the FC_WrapKey and FC_UnwrapKey functions, respectively. The cryptographic algorithms allowed for this purpose in the approved mode of operation are AES in KW mode. All cryptographic keys used in the approved mode of operation must be generated in the approved mode or imported while running in the approved mode.

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 module

uses the DRBG that is compliant with SP800-90A-rev1, for generating the IV. The DRBG is fully seeded with entropy provided by the SP800-90B compliant 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. The module also implements AES GCM for being used in the TLS v1.2 and v1.3 protocols. AES GCM IV generation is in compliance with [FIPS140-3_IG] IG C.H for both protocols as follows:

• For TLS v1.2, IV generation is in compliance with scenario 1.a of IG C.H and [RFC5288]. The module supports acceptable AES-GCM cipher suites from section 3.3.1 of [SP800-52rev2].
• For TLS v1.3, IV generation is in compliance with scenario 5 of IG C.H and [RFC8446]. The module supports acceptable AES-GCM cipher suites from section 3.3.1 of [SP800-52rev2]. Additionally, the module offers an internal deterministic IV generation mode compliant with Scenario 3 of FIPS 140-3 IG C.H. The size of the fixed (name) field used by this IV generation mode is at least 32 bits. The module then internally generates a 32 bit or longer deterministic nonrepetitive counter. The module explicitly ensures that this counter is monotonically increasing at each invocation of the AES-GCM for the same encryption key, and that this counter does not exhaust all its possible values. The generated GCM IV is at least 96 bits in length. The IV generated in both scenarios is only used within the context of the TLS protocol. The design of the TLS protocol implicitly ensures that the nonce_explicit, or counter portion of the IV will not exhaust all of its possible values. In case the module's power is lost and then restored, the key used for the AES GCM encryption or decryption shall be redistributed. © 2024 SUSE, LLC / atsec information security.

42 of 48

The module provides password-based key derivation (PBKDF), compliant with SP800-132. The module supports option 1a from section 5.4 of [SP800-132], in which the Master Key (MK) or a segment of it is used directly as the Data Protection Key (DPK). In accordance with [SP800-132] and IG D.N, the following requirements shall be met.

• 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 DPK shall be of 112 bits or more (this is verified by the module to determine the service is approved).
• A portion of the salt, with a length of at least 128 bits (this is verified by the module to determine the service is approved), shall be generated randomly using the SP800-90Arev1 DRBG,
• The iteration count shall be selected as large as possible, as long as the time required to generate the key using the entered password is acceptable for the users. The minimum value shall be 1000 (this is verified by the module to determine the service is approved).
• Passwords or passphrases, used as an input for the PBKDF, shall not be used as cryptographic keys.
• The length of the password or passphrase shall be of at least 20 characters (this is verified by the module to determine the service is approved), and shall consist of lower-case, uppercase and numeric characters. The probability of guessing the value is estimated to be 1/6220 = 10-36, which is less than 2-112. In a worst-case scenario where the user selects a password consisting of only digits, the guessing probability is estimated to be 10-20. The calling application shall also observe the rest of the requirements and recommendations specified in [SP800-132].

To comply with the assurances found in Section 5.6.2 of SP 800-56Ar3, the operator must use the module together with an application that implements the TLS protocol. Additionally, the module’s approved Key Pair Generation service (see Section 4.1.1) must be used to generate ephemeral Diffie-Hellman or EC Diffie-Hellman key pairs, or the key pairs must be obtained from another FIPSvalidated module. As part of this service, the module will internally perform the full public key validation of the generated public key.

All of the RSA modulus sizes used by the cryptographic module have been CAVP tested and the certificates are listed in Table 5 of this security policy. There are no untested RSA modulus sizes used by the cryptographic module. © 2024 SUSE, LLC / atsec information security.

43 of 48

RSA is vulnerable to timing attacks. In a setup where attackers can measure the time of RSA decryption or signature operations, blinding must be used to protect the RSA operation from that attack. The module uses the following blinding technique: instead of using the RSA decryption directly, a blinded value y = x re mod n is decrypted and the unblinded value x' = y' r−1 mod n returned. The blinding value r is a random value with the size of the modulus n.

Modular exponentiation used in DSA and RSA is vulnerable to cache-timing attacks. The module implements a variant of the modular exponentiation proposed by Colin Percival to defend against these attacks.

Arithmetic errors in RSA signatures might leak the private key. The module verifies the RSA signature generated after the cryptographic operation is performed. © 2024 SUSE, LLC / atsec information security.

44 of 48

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 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 DSA                 Digital Signature Algorithm DRBG                Deterministic Random Bit Generator ECB                 Electronic Code Book ECC                 Elliptic Curve Cryptography FFC                 Finite Field Cryptography FIPS                Federal Information Processing Standards Publication 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 NIST                National Institute of Science and Technology 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 © 2024 SUSE, LLC / atsec information security.

45 of 48

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 March 2024 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 (Draft) 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) August 2015 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 PKCS#1 Public Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 February 2003 https://www.ietf.org/rfc/rfc3447.txt RFC5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS August 2008 https://datatracker.ietf.org/doc/html/rfc5288 RFC8446 The Transport Layer Security (TLS) Protocol Version 1.3 August 2018 https://datatracker.ietf.org/doc/html/rfc8446 © 2024 SUSE, LLC / atsec information security.

46 of 48

SP800-38A NIST Special Publication 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 SP800-38A- NIST Special Publication 800-38A-Addendum - Recommendation Addendum for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode October 2010 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication80038a-add.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-38D NIST Special Publication 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 SP800-38F NIST Special Publication 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 SP800-52rev2 NIST Special Publication 800-52 Revision 2 - Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations August 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.80052r2.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.80056Ar3.pdf SP800-56Crev2 NIST Special Publication 800-56C Revision 2 - Recommendation for Key Derivation through Extraction-then-Expansion August 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.80056Cr2.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.

47 of 48

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.80090Ar1.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-108rev1 NIST Special Publication 800-108 Revision 1 - Recommendation for Key Derivation Using Pseudorandom Functions (Revised) August 2022 https://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf SP800-131Arev2 NIST Special Publication 800-131A Revision 1- 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-132 NIST Special Publication 800-132 - Recommendation for Password-Based Key Derivation - Part 1: Storage Applications December 2010 https://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.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.800133r2.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.800140B.pdf © 2024 SUSE, LLC / atsec information security.

48 of 48