Oracle Linux 9 NSS Cryptographic Module

Certificate

Approved Algorithms (49)

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

flowchart LR
  %% Deterministic review-risk graph for Oracle Linux 9 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>Recovery<br/>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>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 Oracle Linux 9 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>Recovery<br/>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>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

Oracle Linux 9 NSS Cryptographic Module FIPS 140-3 Level 1 Validation Software Version: 4.35.0-381552536e763d0c Prepared by: atsec information security corporation

4516 Seton Center Pkwy, Suite 250

Austin, TX 78759 www.atsec.com Document Version 1.1 ©Oracle Corporation

Title: Oracle Linux 9 NSS Cryptographic Module Date: September 6th, 2024 Contributing Authors: Oracle Linux Engineering Security Evaluations – Global Product Security atsec information security Oracle Corporation World Headquarters

Austin, TX 78741 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 www.oracle.com change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. Oracle specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may be reproduced or distributed whole and Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Oracle Linux 9 NSS Cryptographic Module Security Policy i

Oracle Linux 9 NSS Cryptographic Module Security Policy iii

This document is the non-proprietary FIPS 140-3 Security Policy for software version 4.35.0-381552536e763d0c of the Oracle Linux 9 NSS Cryptographic Module. It contains the security rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for Other documentation is proprietary to their authors.

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

Table 1 describes the individual security areas of FIPS 140-3, as well as the security levels of those individual areas. Table 1 - Security Levels Oracle Linux 9 NSS Cryptographic Module Security Policy

Purpose and Use: The Oracle Linux 9 NSS Cryptographic Module (hereafter referred to as “the module”) is defined as a software module in a multi-chip standalone embodiment. 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. It combines a vertical stack of Linux components intended to limit the external interface

each separate component may provide. Module Type: Software Module Embodiment: Multi-chip standalone Module Characteristics: N/A Cryptographic Boundary: Figure 1 shows the cryptographic boundary of the module, its interfaces with the operational environment and the flow of information between the module and operator (depicted through the arrows). Tested Operational Environment’s Physical Perimeter (TOEPP): The TOEPP of the module is defined as the general-purpose computer on which the module is installed. Figure 1 – Block Diagram Oracle Linux 9 NSS Cryptographic Module Security Policy

Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets): Table 2 - Tested Module Identification Table 3 - Tested Operational Environments Vendor Affirmed Operating Environments: Table 4 - Vendor Affirmed Operational Environments Note: the CMVP makes no statement as to the correct operation of the module or the security strengths of the generated SSPs when so ported if the specific operational environment is not listed on the validation certificate.

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

Modes List and Description: Table 5 - Modes List and Description After passing all pre-operational self-tests and conditional cryptographic algorithm self-tests (CASTs) executed on start-up, the module automatically transitions to the approved mode. No operator intervention is required to reach this point. Oracle Linux 9 NSS Cryptographic Module Security Policy

Mode change instructions and status indicators: The module automatically switches between the approved and non-approved modes depending on the services requested by the operator. The status indicator of the mode of operation is equivalent to the indicator of the service that was requested. Degraded Mode Description: The module does not implement a degraded mode of operation. Approved Algorithms: C C C Oracle Linux 9 NSS Cryptographic Module Security Policy

Oracle Linux 9 NSS Cryptographic Module Security Policy

Oracle Linux 9 NSS Cryptographic Module Security Policy

The following are allowed for legacy use only; DSA signature verification with L=1024 and N=224. Oracle Linux 9 NSS Cryptographic Module Security Policy

B.3.3) Vendor Affirmed Algorithms: Table 7 - Vendor Affirmed Algorithms Non-Approved, Allowed Algorithms: The module does not implement non-approved algorithms allowed in the approved mode of operation. Oracle Linux 9 NSS Cryptographic Module Security Policy

Non-Approved, Allowed Algorithms with No Security Claimed: Table 8 - Non-Approved, Allowed Algorithms with No Security Claimed Non-Approved, Not Allowed Algorithms: Table 9 - Non-Approved, Not Allowed Algorithms

2(1) Oracle Linux 9 NSS Cryptographic Module Security Policy

2(1) 8.2.2 Table 10 - Security Function Implementations

The Crypto Officer shall consider the following requirements and restrictions when using the module. For TLS 1.2, the module offers the AES GCM implementation and uses the context of Scenario 1 of FIPS 140-3 IG C.H. NSS is compliant with SP 800-52r2 Section 3.3.1 and the mechanism for IV generation is compliant with RFC 5288 and 8446. The module does not implement the TLS protocol. The module’s implementation of AES GCM is used together with an application that runs outside the module’s cryptographic boundary. The design of the TLS protocol implicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values for a given session key. In the event the module’s power is lost and restored, the consuming application must ensure that a new key for use with the AES GCM key encryption or decryption under this scenario shall be established. Alternatively, the Crypto Officer can use the module’s API to perform AES GCM encryption using internal IV generation compliant with Scenario 2 of FIPS 140-3 IG C.H. These IVs are always 96 bits and generated using the approved DRBG internal to the module’s boundary. 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 non-repetitive 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. Finally, for TLS 1.3, the AES GCM implementation uses the context of Scenario 5 of FIPS 140-3 IG C.H. The protocol that provides this compliance is TLS 1.3, defined in RFC8446 of August 2018, using the cipher-suites that explicitly select AES GCM as the encryption/decryption cipher (Appendix B.4 of RFC8446). The module supports acceptable AES GCM cipher suites from Section

3.3.1 of SP800-52r2. TLS 1.3 employs separate 64-bit sequence numbers, one for protocol records that are received, and one for

protocol records that are sent to a peer. These sequence numbers are set at zero at the beginning of a TLS 1.3 connection and each time when the AES-GCM key is changed. After reading or writing a record, the respective sequence number is incremented by one. The protocol specification determines that the sequence number should not wrap, and if this condition is observed, then the protocol implementation must either trigger a re-key of the session (i.e., a new key for AES-GCM), or terminate the connection.

The module provides password-based key derivation (PBKDF2), compliant with SP 800-132. The module supports option 1a from Section 5.4 of SP 800-132, in which the Master Key (MK) or a segment of it is used directly as the Data Protection Key (DPK). In accordance with SP 800-132 and FIPS 140-3 IG D.N, the following requirements shall be met: • Derived keys shall only be used in storage applications. The MK shall not be used for other purposes. The length of the MK or DPK shall be of 112 bits or more. Oracle Linux 9 NSS Cryptographic Module Security Policy

• Passwords or passphrases, used as an input for the PBKDF2, shall not be used as cryptographic keys.
• The length of the password or passphrase shall be at least 7 characters, and shall consist of lowercase, uppercase, and numeric characters. In a worst-case scenario where the user selects a password consisting of only digits, the guessing probability is estimated to be 10-7. Combined with the minimum iteration count as described below, this provides an acceptable trade-off between user experience and security against brute-force attacks.
• A portion of the salt, with a length of at least 128 bits, shall be generated randomly using the SP 800-90Ar1 DRBG provided by the module.
• 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 is 1000. The module offers DH and ECDH shared secret computation services compliant to the SP 800-56Ar3 and meeting IG D.F scenario

2 path (1). To meet the required assurances listed in section 5.6 of SP 800-56Ar3, the module shall be used together with an

application that implements the “TLS protocol” and the following steps shall be performed.

• The entity using the module, must use the module's "Key pair generation" service for generating DH/ECDH ephemeral keys. This meets the assurances required by key pair owner defined in the section 5.6.2.1 of SP 800-56Ar3.
• As part of the module's Shared Secret Computation (SSC) service, the module internally performs the public key validation on the peer's public key passed in as input to the SSC function. This meets the public key validity assurance required by the sections 5.6.2.2.1/5.6.2.2.2 of SP 800-56Ar3.
• The module does not support static keys therefore the "assurance of peer's possession of private key" is not applicable. Entropy Information: RNG Information: The module implements a Deterministic Random Bit Generator (Hash_DRBG) implementation compliant with SP 800-90Ar1. This DRBG is used internally by the module (e.g., to generate symmetric keys, seeds for asymmetric key pairs, and random numbers for security functions). It can also be accessed using the specified API functions. The module DRBG implemented is a SHA-256 Hash_DRBG, seeded by the entropy source specified in Table 11. Oracle Linux 9 NSS Cryptographic Module Security Policy

Table 12 - Key Generation Oracle Linux 9 NSS Cryptographic Module Security Policy

For DH, the module supports the use of the safe primes defined in RFC 3526 (IKE) and RFC 7919 (TLS) as listed in Table 13. Note that the module only implements domain parameter generation, key pair generation and verification, and shared secret TLS 1.0/1.1 KDF, TLS 1.2 KDF (RFC 7627), IKEv2 implementations shall only be used to generate secret keys in the context of the TLS 1.0/1.1, TLS 1.2, IKE protocols respectively. No parts of this protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. Oracle Linux 9 NSS Cryptographic Module Security Policy

Table 14 - Ports and Interfaces The logical interfaces are the APIs through which the applications request services. These logical interfaces are logically separated from each other by the API design.

The module does not implement a trusted channel. Oracle Linux 9 NSS Cryptographic Module Security Policy

The module does not implement authentication. Table 15 – Roles The module supports the Crypto Officer role only. This sole role is implicitly and always assumed by the operator of the module. No support is provided for multiple concurrent operators.

Oracle Linux 9 NSS Cryptographic Module Security Policy

Name Computation Signature Generation Signature Verification Key Pair Generation Secret Key Generation Key Derivation Key-Based Key Derivation Password-Based Key Derivation Random Number Generation Show Version

Description shared secret Generate a digital signature Verify a digital signature Generate a key pair Generate a secret key Derive a key Derive a key from a key Derive a key from a password Generate random bytes Return the

Indicator CKR_OK None

Inputs DH Public Key EC Private Key, EC Public Key Message, private key Message, public key, signature DH Group Curve Modulus Key size Shared Secret Key-Derivation Key Password Output length N/A

Outputs Secret Signature Pass/fail DH Private Key, DH Public Key EC Private Key, EC Public Key RSA Private Key, RSA Public Key Symmetric Key Derived Key Random bytes Module

Security Functions KAS-ECC-SSC RSA PKCS#1 v1.5 and PSS with SHA-224, SHA-256, SHA- 384, SHA-512, ECDSA with SHA-224, SHA- 256, SHA-384, SHA-512 RSA PKCS#1 v1.5 and PSS with, SHA-224, SHA-256, SHA- 384, SHA-512, ECDSA with SHA-224, SHA- 256, SHA-384, SHA-512 DSA with SHA- 224, SHA-256, SHA-384, SHA- 512 Safe Primes ECDSA RSA CKG (Symmetric Key Generation) HKDF, TLS 1.0/1.1 KDF, TLS 1.2 KDF, IKEv2 KDF KBKDF PBKDF2 Hash_DRBG, N/A

Roles

SSP Access DH Public Key: W, E; Shared Secret: G, R EC Private Key: W, E; EC Public Key: W, E; Shared Secret: G, R RSA Private Key: W, E; ECDSA Private Key: W, E RSA Public Key: W, E; ECDSA Public Key: W, E; DSA Public Key: W, E DH Private Key: G, R; DH Public Key: G, R; Intermediate Key Generation Value: G EC Private Key: G, R; EC Public Key: G, R; Intermediate Key Generation Value: G RSA Private Key: G, R; RSA Public Key: G, R; Intermediate Key Generation Value: G Symmetric Key (AES Key, HMAC Key Key-Derivation Key): G Shared Secret: W, E; Derived Key: G, R Key-Derivation Key: W, E; Derived Key: G, R Password: W, E; Derived Key: G, R Entropy Input: W, E; DRBG Seed: E, G; Internal State (V, C): W, E, G N/A

G G G Oracle Linux 9 NSS Cryptographic Module Security Policy

Name Show Status Self-Test Zeroization

Description module name and version information Return the module status Perform the CASTs and integrity tests Zeroize all SSPs

Indicator None None None

Inputs N/A N/A Any SSP

Outputs name and version Module status Pass/fail N/A

Security Functions N/A SHA-224, SHA- 256, SHA-384, SHA-512 AES-GCM, AES- ECB, AES-CBC, AES-CMAC, HMAC, KBKDF, HKDF, TLS 1.0/1.1 KDF, TLS 1.2 KDF, IKEv2 KDF, PBKDF2, Hash_DRBG, KAS-FFC-SSC, KAS-ECC-SSC, RSA, ECDSA, DSA See Table 24 for specifics N/A

Roles

SSP Access N/A N/A All SSPs: Z

Table 16 – Approved Services Table 16 lists the approved services. The following convention is used to specify access rights to SSPs: • Generate (G): The module generates or derives the SSP. • Read (R): The SSP is read from the module (e.g. the SSP is output). • Write (W): The SSP is updated, imported, or written to the module. • Execute (E): The module uses the SSP in performing a cryptographic operation. To interact with the module, a calling application must use the FIPS token APIs provided by Softoken. The FIPS token API layer can be used to retrieve the approved service indicator for the module. This indicator consists of four independent service indicators.

1. The session indicator, which must be used for all cryptographic services except the key derivation service. It can be accessed by invoking the NSC_NSSGetFIPSStatus function with the CKT_NSS_SESSION_LAST_CHECK parameter. If the output parameter is set to CKS_NSS_FIPS_OK (1), the service was approved.
2. The object indicator, which must be used for the key derivation service. It can be accessed by invoking the NSC_NSSGetFIPSStatus function with the CKT_NSS_OBJECT_CHECK parameter and the output derived key. If the output parameter is set to CKS_NSS_FIPS_OK (1), the service was approved.
3. The DRBG service indicator, which must be used for the DRBG service. It can be accessed by invoking the C_SeedRandom or C_GenerateRandom functions. If any of these functions returns CKR_OK, the service was approved. Oracle Linux 9 NSS Cryptographic Module Security Policy

Table 17 - Non-Approved Services

The module does not load external software or firmware.

The module does not implement a bypass capability.

The module does not implement a self-initiated cryptographic output capability. Oracle Linux 9 NSS Cryptographic Module Security Policy

The integrity of the module is verified by comparing a HMAC-SHA-256 value calculated at run time with the HMAC-SHA-256 value embedded in the module that was computed at build time. If the integrity test fails, the module enters the Power-On Error state.

Integrity tests are performed as part of the pre-operational self-tests, which are executed when the module is initialized. The integrity test may be invoked on-demand by unloading and subsequently re-initializing the module. Oracle Linux 9 NSS Cryptographic Module Security Policy

Type of Operating Environment: modifiable: the module executes on a general-purpose operating system (Oracle Linux 9), which allows modification, loading, and execution of software that is not part of the validated module. How Requirements are Satisfied: The operating system provides process isolation and memory protection mechanisms that ensure appropriate separation for memory access among the processes on the system. Each process has control over its own data and uncontrolled access to the data of other processes is prevented.

The module shall be installed as stated in Section 11.1. There are no concurrent operators. The module does not have the capability of loading software or firmware from an external source. Instrumentation tools like the ptrace system call, gdb and strace, userspace live patching, as well as other tracing mechanisms offered by the Linux environment such as ftrace or systemtap, shall not be used in the operational environment. The use of any of these tools implies that the cryptographic module is running in a non-validated operational environment. Oracle Linux 9 NSS Cryptographic Module Security Policy

The module is comprised of software only and therefore this section is not applicable. Oracle Linux 9 NSS Cryptographic Module Security Policy

This module does not implement any non-invasive security mechanism and therefore this section is not applicable. Oracle Linux 9 NSS Cryptographic Module Security Policy

Table 18 – Storage Areas Table 20 - SSP Zeroization Methods All data output is inhibited during zeroization. Oracle Linux 9 NSS Cryptographic Module Security Policy

Oracle Linux 9 NSS Cryptographic Module Security Policy

Table 21 – SSP Information First Oracle Linux 9 NSS Cryptographic Module Security Policy

Name Key-Derivation Key Shared Secret Password Derived Key Entropy Input DRBG Seed IG D.L compliant Internal State (V, C) IG D.L compliant DH Public Key DH Private Key EC Public Key EC Private Key RSA Public Key

Used By Message Authentication Verification Key-Based Key Derivation Shared Secret Computation, Key Derivation Password-Based Key Derivation Key Derivation, Key-Based Key Derivation, Password-Based Key Derivation Random Number Generation Shared Secret Computation, Key Pair Generation Shared Secret Computation, Signature Verification Shared Secret Computation, Signature Generation Signature Verification

Inputs/Outputs (encrypted); API output parameters (encrypted) API input parameters (encrypted); API output parameters (encrypted) API input parameters (encrypted); API output parameters (encrypted) API input parameters (plaintext); No output No input; API output parameters (encrypted) No input; No output API input parameters (encrypted); API output parameters (encrypted) API input parameters (encrypted); API output parameters (encrypted) API input parameters

Storage

Storage Duration From generation until DRBG Seed is created While the DRBG is instantiated While the module is operational For the duration of the service

Zeroization Automatic, remove power from the module Remove power from the module Destroy object, remove power from the module

Type PSP CSP PSP CSP PSP

Related SSPs Used for deriving a key (i.e., Derived Key) Established using DH public, DH Private Key, EC Public Key, EC Private Key, Derived Key Used for deriving a key (i.e., Derived Key) Derived from Key-Derivation Key, Shared Secret or Password Used for deriving DRBG Seed Derived from Entropy Input; used for the generation of Internal State (V, C) Generated from DRBG Seed Paired with DH Private Key; used for establishing Shared Secret Paired with DH Public Key, used for establishing Shared Secret Paired with EC Private Key; used for establishing Shared Secret Paired with EC Public Key; used for establishing Shared Secret Paired with RSA Private Key

C) Oracle Linux 9 NSS Cryptographic Module Security Policy

Name RSA Private Key DSA Public Key Intermediate Key Generation Value

Used By Signature Generation Signature Verification Key Pair Generation

Inputs/Outputs (encrypted); API output parameters (encrypted) API input parameters (encrypted); No output N/A

Storage

Storage Duration

Zeroization Automatically

Type CSP PSP CSP

Related SSPs Paired with RSA Public Key N/A Generated during the generation of RSA Public Key, RSA Private Key, DH Public Key, DH Private Key, EC Public Key, EC Private Key

Table 22 – SSP Information Second

The SHA-1 algorithm as implemented by the module will be non-approved for all purposes, starting January 1, 2031. The RSA, ECDSA algorithm as implemented by the module conforms to FIPS 186-4, which has been superseded by FIPS 186-5. FIPS 186-4 will be withdrawn on February 3, 2024. Oracle Linux 9 NSS Cryptographic Module Security Policy

Table 23 - Pre-Operational Self-Tests The pre-operational software integrity test is performed automatically, after the CASTs, when the module is powered on before the module transitions into the operational state. While the module is executing the self-tests, services are not available, and data output (via the data output interface) is inhibited until the tests are successfully completed. The module transitions to the operational state only after the pre-operational self-test has passed successfully. If the pre-operational self-test fails, the module transitions to the error (i.e., Power-On Error) state.

Oracle Linux 9 NSS Cryptographic Module Security Policy

Algorithm PBKDF2 Hash_DRBG KAS-FFC-SSC KAS-ECC-SSC RSA DSA ECDSA Safe Primes ECDH RSA ECDSA

Implementation

Test Properties SHA-512 80, 128, 144-bit input secret SHA-256 14-character password 128-bit salt Iteration count: 5 SHA-256 without prediction resistance 2048-bit key P-256 PKCS#1 v1.5 with SHA-256, SHA-384, SHA-512 2048-bit key 1024-bit key SHA-256 P-256 N/A PKCS#1 v1.5 with SHA-256 SHA-256

Test Method PCT

Type Conditional Pairwise Consistency Self-Test

Indicator Key Pair Generation is successful

Details Instantiate Generate Reseed Generate (compliant with SP 800- 90A Section 11.3) Shared Secret Computation Signature Generation Signature Verification Signature Verification Signature Generation Signature Verification SP 800-56Ar3 Section 5.6.2.1.4 Signature Generation & Signature Verification

Conditions Freebl initialization Softoken initialization Freebl initialization Freebl initialization Key Pair Generation

The module performs self-tests on all approved cryptographic algorithms as part of the approved services supported in the approved mode of operation, using the tests shown in Table 24. Data output through the data output interface is inhibited during the self-tests. If any of these tests fails, the module transitions to the Power-On Error state. Upon generation of a DH, EC or RSA key pair, the module will perform a pair-wise consistency test (PCT) as shown in Table 24, which provides some assurance that the generated key pair is well formed. The test for DH and ECDH consists of the PCT and verification using the generated key pairs. Services are not available, and data output (via the data output interface) is inhibited during execution of the PCT. If a PCT test fails, the module transitions to the PCT Error state.

The module does not implement any periodic self-tests.

Oracle Linux 9 NSS Cryptographic Module Security Policy

Table 25 - Error States In any error state, the output interface is inhibited, and the module accepts no more inputs or requests (as the module is no longer running).

The software integrity tests and CASTs can be invoked on demand by unloading and subsequently re-initializing the module. The PCTs can be invoked on demand by requesting the key pair generation service. Oracle Linux 9 NSS Cryptographic Module Security Policy

The module is distributed as part of the Oracle Linux 9 (OL9) RPM package in the form of nss-softokn-3.90.0-3.0.1.el9_2_fips and nss-softokn-freebl-3.90.0-3.0.1.el9_2_fips RPM packages that are located in the “Oracle Linux 9 Security Validation (Update 3)” yum repository (ol9_u3_security_validation). The module can achieve the FIPS validated configuration by:

• For installation add the fips=1 option to the kernel command line during the system installation. During the software selection stage, do not install any third-party software.
• Switching the system into the approved mode configuration after the installation. Execute the fips-mode-setup --enable command. Restart the system. In both cases, the Crypto Officer must verify the Oracle Linux 9 system operates in the approved mode by executing the fipsmode-setup --check command, which should output “FIPS mode is enabled.” For more information on Oracle Linux 9 system approved mode, please see Oracle Linux 9 product documentation. After installation of the nss-softokn-3.90.0-3.0.1.el9_2_fips and nss-softokn-freebl-3.90.0-3.0.1.el9_2_fips RPM packages, the Crypto Officer must execute the “Show Version” service by accessing the CKA_NSS_VALIDATION_MODULE_ID attribute of the CKO_NSS_VALIDATION object in the default slot. The object attribute must contain the value: Oracle Linux 9 NSS Cryptographic Module 4.35.0-381552536e763d0c Alternatively, the /usr/lib64/nss/unsupported-tools/validation tool is provided as a convenience by the nss-tools-3.90.03.0.1.el9_2 RPM package. This tool performs the same steps, and outputs the FIPS module identifier as above. The cryptographic boundary consists only of the Softoken and Freebl libraries along with their associated integrity check values as listed in Table 2. If any other NSS API outside of these two libraries is invoked, the user is not interacting with the module specified in this Security Policy.

See section 2.7 for algorithm-specific information.

There is no non-administrator guidance.

There are no maintenance requirements.

As the module does not persistently store SSPs, secure sanitization of the module consists of unloading the module. This will zeroize all SSPs in volatile memory. Then, if desired, the nss-softokn-3.90.0-3.0.1.el9_2_fips and nss-softokn-freebl-3.90.03.0.1.el9_2_fips RPM packages can be uninstalled from the Oracle Linux 9 system. Oracle Linux 9 NSS Cryptographic Module Security Policy

Timing attacks on RSA: RSA blinding: Timing attack on RSA was first demonstrated by Paul Kocher in 1996, who contributed the mitigation code to our module. Most recently Boneh and Brumley showed that RSA blinding is an effective defense against timing attacks on RSA. Specific Limit: None Cache-timing attacks on the modular exponentiation operation used in RSA: Cache invariant modular exponentiation: This is a variant of a modular exponentiation implementation that Colin Percival showed to defend against cache-timing attacks. Specific Limit: This mechanism requires intimate knowledge of the cache line sizes of the processor. The mechanism may be ineffective when the module is running on a processor whose cache line sizes are unknown. Arithmetic errors in RSA signatures: Double-checking RSA signatures: Arithmetic errors in RSA signatures might leak the private key. Ferguson and Schneier recommend that every RSA signature generation should verify the signature just generated. Specific Limit: None Oracle Linux 9 NSS Cryptographic Module Security Policy

Oracle Linux 9 NSS Cryptographic Module Security Policy

Oracle Linux 9 NSS Cryptographic Module Security Policy

Oracle Linux 9 NSS Cryptographic Module Security Policy