Linux OpenSSL FIPS Provider

Certificate

Approved Algorithms (76)

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

flowchart LR
  %% Deterministic review-risk graph for Linux OpenSSL FIPS Provider
  %% 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>Firmware Load<br/>Recovery</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/>SSH<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 Linux OpenSSL FIPS Provider
  %% 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>Firmware Load<br/>Recovery</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/>SSH<br/>HTTPS</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>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

Linux OpenSSL FIPS Provider v3.1 Non-Proprietary Cryptographic Module FIPS 140-3 Security Policy FIPS 140-3 Security Level: 1 Document version: 1.3 Date: June 29, 2024

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD. Table of Contents

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD. List of Tables List of Figures

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

This is a non-proprietary Cryptographic Module Security Policy for the Linux OpenSSL FIPS Provider from KAYTUS SYSTEM PTE. LTD.. This Security Policy describes how the Linux OpenSSL FIPS Provider meets the security requirements of Federal Information Processing Standards (FIPS) Publication 140-3, which details the U.S. and Canadian Government requirements for cryptographic modules. More information about the FIPS 140-3 standard and validation program is available on the National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security (CCCS) Cryptographic Module Validation Program (CMVP) website at https://csrc.nist.gov/projects/cryptographic-module-validation-program. This document also describes how to run the Linux OpenSSL FIPS Provider in a secure Approved mode of operation. This policy was prepared as part of the Level 1 FIPS 140-3 validation. The Linux OpenSSL FIPS Provider is referred to in this document as the provider, cryptographic module, or the module.

This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-3 cryptographic module security policy. More information is available on the module from the following sources: • The search page on the CMVP website (https://csrc.nist.gov/Projects/cryptographic-modulevalidation-program/Validated-Modules/Search) can be used to locate and obtain vendor contact information for technical or sales-related questions about the module.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

This document is the non-proprietary FIPS 140-3 Security Policy of the Linux OpenSSL FIPS Provider cryptographic module. For the purpose of the FIPS 140-3 validation, the module is a software cryptographic module validated at overall security level 1. The following table shows the claimed security level for each of the twelve sections that comprise the FIPS 140-3 standard.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Linux OpenSSL FIPS Provider is a software library that provides a C-language Application Program Interface (API) for use by application that require cryptographic functionality. In the OpenSSL, providers are containers for algorithm implementations. Whenever a cryptographic algorithm is used via the OpenSSL high level APIs a provider is selected. It is that provider implementation that actually does the required work. Based on the OpenSSL new approach, the Linux OpenSSL FIPS Provider is a provider that can be used with any OpenSSL version from 3.0.4. The cryptographic boundary of the Module is the provider itself, a dynamically loadable library. The module performs no communication other than with the calling application via APIs that are invoked by the module. Based on that, the cryptographic boundary consists of the following shared library and the integrity check file used for the integrity test. The following table enumerates the files that comprise the module (surrounded with red lines in Figure 1

• Cryptographic Boundary). Table 2
• Cryptographic Module Components The image below illustrates the high-level software architecture of the module. The block diagram below shows the module and the delimitation of the cryptographic module boundary (dotted red line).

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD. Figure 1

• Cryptographic Boundary The module is aimed to run on a general-purpose computer (GPC); the physical perimeter of the module is the tested platforms. Figure 2 shows the major components of a GPC. Figure 2
• Cryptographic Module Physical Perimeter The module has been tested on the following platforms:

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD. Table 3 – Software Tested Operational Environments Note: The operational environments include OpenSSL version 3.0.4. There is no additional vendor affirmed operating environments.

The module supports the following Approved Algorithms listed in Table 4 below: Table 4 – Approved Algorithms

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD. NOTE: Per [IG] 9.3.A, scenario 2b, no assurances of minimum strength of generated SSP are declared. The minimum entropy strength expected is 112 bits. Note: The PBKDF algorithm is only used for internal pins and keys storage according FIPS SP 800-132. The module includes the following vendor-affirmed security method in the next table: Table 5

• Vendor Affirmed Approved Algorithms provided by Linux OpenSSL FIPS Provider N/A The module does not implement either non-approved allowed algorithms (with or without security claimed) or non-approved and not allowed algorithms in the Approved mode of operation. Table 6
• Security Functions Implementation

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

The module supports only one mode of operation: Approved. The module will be in Approved mode when all pre-operational self-tests have been completed successfully, and only Approved security functions can be invoked (see Table 4 and Table 5 above). The module does not support degraded operation.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

As a software module, the provider does not have physical ports. For the purpose of the FIPS 140-3 validation, the module interfaces are defined as Software or Firmware Module Interfaces (SMFI), and the physical ports are interpreted to be the physical ports of the hardware platform on which the module runs. The logical interface is a C language Application Program Interface (API) through which calling application request services. In addition, data output interface is inhibited when the module is performing pre-operational and conditional tests, zeroisation or when the module is in the error state. The following table summarizes the FIPS 140-3 logical interfaces: Table 7 – Ports and Interfaces The module does not implement either control output interface or power interface (it is not required since the cryptographic module is a software module).

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

The sections below describe the module's authorized roles, services, and operator authentication method employed.

The module supports the following roles: Crypto Officer role, which performs the module installation and configuration; and User role, which performs all services with the exception of module installation and configuration. Table 8 – Roles The module does not support authentication mechanisms. The operator implicitly assumes the set of roles consisting of the CO and User when accessing the module services. The module does not support concurrent operators.

All services implemented by the module are listed in tables below. The approved services are shown in Table 9. Please note that the Sensitive Security Parameters (SSPs) listed below indicate the type of access required using the following notation:

• G - Generate: The SSP is generated or derived.
• R
• Read: The SSP is read from the module.
• W
• Write: The SSP is updated, imported or written to the module.
• X
• Execute: The SSP is used within an Approved security function.
• Z
• Zeroize: The SSP is zeroized.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD. Table 9 – Approved Services

Symmetric Encryption/Decryption

User

Encrypt/Decrypt plaintext/ciphertext using supplied key

API call parameters: key, IV, plaintext/ciphertext

Status, ciphertext/plaintext

AES ECB key

• W, X AES CBC Key
• W, X AES CBC IV
• W, X AES CBC-CS1 Key
• W, X AES CBC-CS1 IV
• W, X AES CBC-CS2 Key
• W, X AES CBC-CS2 IV
• W, X AES CBC-CS3 Key
• W, X AES CBC-CS3 IV
• W, X AES OFB Key
• W, X AES OFB IV– W, X AES CFB 1 Key
• W, X AES CFB 1 IV– W, X AES CFB 8 Key
• W, X AES CFB 8 IV– W, X AES CFB 128 Key
• W, X AES CFB 128 IV– W, X AES CCM key
• W, X AES CCM IV- W, X AES GCM key
• W, X AES GCM IV –W, X AES XTS key
• W, X AES XTS IV
• W, X AES CTR key
• W, X

Symmetric Encryption and Decryption

Return code from function call

Linux OpenSSL FIPS Provider v3.1 Cryptographic Module KAYTUS SYSTEM PTE. LTD. W, X X W, X X W, X X W, X X

Linux OpenSSL FIPS Provider v3.1 Cryptographic Module KAYTUS SYSTEM PTE. LTD.

Linux OpenSSL FIPS Provider v3.1 Cryptographic Module KAYTUS SYSTEM PTE. LTD. R, X W, X

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

The cryptographic module is composed of a software shared library as well as file where the a precomputed HMAC-SHA-256 signature is stored. The integrity of the software module is achieved by comparing the pre-computed HMAC value to the one calculated at run time. The module also provides on-demand integrity test. The integrity test is performed by the Self-Test On demand service by invoking the SELF_TEST_post() function or rebooting the cryptographic module. This test is performed as part of the pre-operational self-tests as well.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

The module operates in a modifiable operational environment per FIPS 140-3 level 1 specifications. The module runs on a commercially available general-purpose operating system. The operating system is restricted to a single operator. Concurrent operators are explicitly excluded. The application that requests cryptographic services is the single user of the module. All SSPs are under the control of the OS, which protects its CSPs against unauthorized disclosure, modification, and substitution and PSPs against unauthorized modification and substitution. Additionally, the OS provides dedicated process space to each executing process, and the module operates entirely within the calling application’s process space. The module only allows access to SSPs through its well-defined API. The module does not have the ability of spawning new processes.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

The module is a software module and this section does not apply.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

The module does not implement any non-invasive attack mitigation technique to protect itself and the module’s unprotected SSPs from non-invasive attacks.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

The following section includes all the information related to the Sensitive Security Parameters (SSPs) and its management. Table 10 below identifies all the SSPs handled by the cryptographic module as well as its purpose, generation method, input and output method, where they are stored and how they are zeroized. Table 10 – Sensitive Security Parameters Definition

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Entropy input string

For CTR_DRBG: 128, 256-bits for AES-128 DF 256, 384, 512- bits for AES- 192/256 DF 256-bits for AES-128 NODF 320-bits for AES-192 NODF 384-bits for AES-256 NODF For HASH DRBG: 128, 192, 256- bits for SHA-1 192, 256-bits for SHA-224 256, 320-bits for SHA-256, SHA-384, SHA- 512, SHA- 512/224, SHA- 512/256 For HMAC DRBG: 160-256 bits in increment of 32 bits for HMAC-SHA-1 192, 256-bits for HMAC-SHA- 224

A4198

External

Plaintext / Never exits the module

N/A

Not persistently stored

Power cycle or OPENSSL_cleanse()

Entropy material for HASH DRBG/HMAC DRBG/CTR DRBG

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Key

Strength 256, 384, 448, 512-bits for HMAC-SHA- 256 384, 448, 512- bits for HMAC- SHA-384 512-1024-bits in increment of 64 bits for HMAC-SHA- 512

Security Function Cert Number

Generation

Import/Export

Establishment

Storage

Zeroization

Use & Related Keys

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

The module employs a Deterministic Random Bit Generator (DRBG) for the creation cryptographic key material. The module contains the following Deterministic Random Bit Generator (DRBG) compliant with the [SP 800-90Arev1]: - HMAC-DRBG - HASH-DRBG - CTR-DRBG The module does not implement Non-Determinist Random Bit Generator or entropy source. A minimum of 112-bits of entropy must be supplied. This entropy is supplied by means of callback functions. Those functions must return an error if the minimum entropy strength cannot be met.

For generation of RSA, DSA and ECDSA key pairs, the module implements approved key generation services compliant with [FIPS 186-4] where the key material is directly obtained from approved [SP 80090Arev1] DRBGs according to the [SP 800-133rev2]. The public and private key pairs used in the Diffie-Hellman and EC Diffie-Hellman KAS are generated internally. They are compliant with NIST [SP 800-56Arev3]. Cryptographic Key Generation: the module uses an Approved Hash, CTR or/and HMAC DRBG specified in NIST SP 800-90Arev1 to generate random cryptographic material. The resulting generated material are unmodified outputs from the DRBG. According to FIPS 140-3 Implementation Guidance D.H. a component key generation (CKG) using the unmodified output of an approved DRBG can be used to generate cryptographic material for:

• Direct Generation of symmetric keys per section 6.1 of the SP 800-133rev2.
• Derivation of symmetric keys per section 6.2 of the SP 800-133rev2. During the SSP generation, services are not available, and input and output are inhibited.

The module provides Diffie-Hellman, EC Diffie-Hellman and RSA key agreement shared secret computation to obtain “shared secret” values. The security strength of the preceding algorithms is as follows:

1. Diffie-Hellman key agreement provides between 112 and 200 bits of encryption strength.
2. EC Diffie-Hellman key agreement provides between 112 and 256 bits of encryption strength.
3. RSA key agreement provides between 112 bits and 200 bits of encryption strength. The Diffie-Hellman and EC Diffie-Hellman are under scenario 2 of [IG] D.F, and the RSA key agreement method is under scenario 1 of the same [IG]. Moreover, the module provides SSP derivation and SSP transport methods which are described in the following sections.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

The module provides the following SSP Derivation methods: - Key-Based Key Derivation (KDKDF algorithm) - Password-Based Key Derivation (PBKDF2 algorithm) - Protocol-Suite Key Derivation: TLS 1.2 KDF, TLS 1.3 KDF, ANSI X9.42, ANSI X9.63 and SSHv2 KDF as key derivation functions. - Key Derivation based on SP 800-56Crev2: HKDF and KDA.

The module provides approved key transport methods according to [IG] D.G. The key transport methods are provided either by:

1. Key wrapping. The module implements three different options: a. Using an approved key wrapping algorithm (e.g., AES in KW/KWP mode). b. An approved authenticated symmetric encryption mode (for example, AES GCM, AES CCM). c. An approved symmetric encryption mode (e.g., AES ECB/CBC ...) together with an approved authentication method (e.g., HMAC or AES CMAC).
2. Key Encapsulation: For this method, the module implements an approved RSA-based key transport scheme (KTS-RSA based on SP 800-56Brev2). According to Table 2: Comparable strengths in [SP 800-57 Part 1 Rev5], the key sizes of AES and RSA provides the following security strength: • AES key wrapping provides between 128 and 256 bits of encryption strength. • Approved authenticated encryption mode (AES-GCM, AES-CCM) provides between 128 and 256 bits of encryption strength. • Combination of any approved AES encryption mode with HMAC/AES CMAC authentication provides between 128 and 256 bits of encryption strength. • RSA key encapsulation provides between 112 and 176 bits of encryption strength.

The keys and SSPs to be entered or exited are provided to the module via API input/output parameters in plaintext form and output via API output parameters in plaintext form. This is allowed per section 7.9.5 of the ISO/IEC 19790:2012 since all CSPs or key components are maintained within the environment and the requirements from section 7.6.3 are met. The module does not support either manual key entry or intermediate key generation values. The module does not output intermediate key generation values. Additionally, the module implements two independent internal actions in order to prevent the inadvertent output of any plaintext SSPs. The mechanism implemented by the module is described below:

1. Memory allocation of the necessary context to request the service.
2. Process the service request which outputs CSPs using the created context.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD. When these two actions are completed without errors, the Key/SSP exits the module in plaintext. Information for the input and output for each SSP, if applicable, is provided under columns "Input" and "Output" of Table 10.

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. No physical storage is offered within the cryptographic boundary, and therefore the module does not store any SSPs persistently beyond the lifetime of the API call. Any persistent key storage occurs outside the module’s cryptographic boundary but within the physical perimeter and the management of these keys is responsibility of the calling application. Table 11 - Storage Areas Information for storage of each SSP, is provided under column "Storage" of Table 10.

SSP zeroisation functions are implemented in the fips.so library, and they depend on the SSP to be zeroized. Information for zeroising each SSP is provided under column “Zeroization” of Table 10. The zeroization functions overwrite the memory occupied by SSP with ‘zeros’ and deallocate the memory with the regular memory deallocation operating system call. In case of abnormal termination, or swap in/out of a physical memory page of a process, the keys in physical memory are overwritten by the Linux kernel before the physical memory is allocated to another process. The zeroization of the SSPs starts just after the invocation of the zeroization command. Once invoked, these techniques take effect immediately and do not allow sufficient time to compromise any plaintext secret, private keys and CSPs. During the zeroization process, services are not available and input and output are inhibited.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

FIPS 140-3 requires that the module performs a set of self-test in order to provide the operator assurance that faults have not been introduced that would prevent the module's correct operation. The module performs the pre-operational self-test and conditional cryptographic algorithms self-tests during the initialization of the module. In addition, some functions require continuous testing of the cryptographic functionality, such as the asymmetric key generation. The following sections list the self-tests performed by the module, their expected error status and error resolutions.

The module executes the following pre-operational self-tests when it is loaded into memory, without operator intervention. These pre-operational self-tests ensure that the module is not corrupted: • Integrity test: Using a HMAC-SHA2-256 for fips.so library, as it is described in section 5. The following cryptographic algorithms are self-tested as part of the pre-operational self-tests: Table 12 - Pre-operational Self-Tests During compilation, the module compiles the HMAC key into fips.so. Once compiled, during the installation, the module calculates the HMAC-SHA2-256 for fips.so and stores in fipsmodule.cnf file. At runtime and prior to using HMAC-SHA-256, a Conditional Cryptographic Algorithm Self-Test (CAST) is performed. If the CAST of the HMAC-SHA-256 is successful, the module computes the HMAC of fips.so. This value is compared with the one stored in fipsmodule.cnf file, and if they are the same value, the test is passed. Otherwise, the test fails and the module enters in Critical Error state. In this state, an internal flag is set to prevent subsequent invocation of any cryptographic calls. While the module is executing the pre-operational 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 are completed successfully. The verify_integrity() API function is in charge of performing the pre-operational self-tests. This API function is called from the SELF_TEST_post() API function, which also performs the KAT tests for each algorithm. The API function returns a ‘1’ if all pre-operational and KAT self-tests succeed, and a ‘0’ otherwise.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Conditional self-tests are performed by the cryptographic module when conditions specified for the following tests occur: Cryptographic Algorithm Self-Test, Pair-Wise Consistency Test and Critical Function Tests. The module does not implement any functions requiring a Software/Firmware Load Test, Manual Entry Tests nor Conditional Bypass Test; therefore, these tests are not performed by the module. While the module is executing the conditional self-tests, services are not available, and input and output are inhibited. The module is not available for use by the calling application until these tests are completed successfully. If any of this tests fails, the module enters in Critical Error state.

In addition to the pre-operational self-tests, the module also performs the Conditional Cryptographic Algorithm Self-Tests (CASTs) for all cryptographic functions of each approved cryptographic algorithm implemented by the module during the module initialization. Therefore, all CASTs are performed prior to the first operational use of the cryptographic algorithm. These tests are detailed in the table below: Table 13 - Conditional Cryptographic Algorithm Self-Tests

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD. The SELF_TEST_kats() API function is in charge of performing all the KAT self-tests for each algorithm prior to their first use, without any operator intervention. This function is called from the SELF_TEST_post() API function, called during the initialization of the module. The API function returns a ‘1’ if all pre-operational and KAT self-tests succeed, and a ‘0’ otherwise.

The Pairwise Conditional Self-tests are run when an asymmetric key pair is generated. In case of failure the module enters in Critical Error state and needs to be reloaded to clear the error.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD. Table 14 - Conditional Pair-wise Consistency Tests

The module obtains the following assurances per SP 800-56Arev3 and SP 800-56Brev2: Table 15 - Assurances The module performs the following DRBG health checks when initializing the DRBG for the first time during the power-up of the module:

• DRBG Instantiate Test
• DRBG Generate Test
• DRBG Reseed Test If any of these DRBG health checks fails, the module will enter in a critical error state.

Pre-operational self-tests and Conditional Cryptographic Algorithms self-test performed by the module during its initialization, are available on demand by resetting the module or by calling the SELF_TEST_post() API function. During the execution of the on-demand self-tests, services are not available and no data output or input is possible.

If any of the self-tests described in sections 10.1, 10.2 and 10.3 fails, the module enters in Critical Error state and needs to be reloaded to exercise any cryptographic service. In the Critical Error State, no cryptographic services are provided, and data output is prohibited. In this state, an internal flag is set to prevent subsequent invocation of any cryptographic calls. The only method to recover from the Critical Error state is to power cycle the device which results in the module being reloaded into memory and performing the pre-operational software integrity test and the

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD. Conditional CASTs. The module will only enter the operational state after successfully passing the preoperational software integrity test and the Conditional CASTs. In addition, if the AES XTS check fails during the CSP entry, the module will flow to Soft Error state, not allowing any cryptographic service and no data output or input is allowed, until the error is cleared. The table below shows the different causes that lead to the error states and the status indicators reported. Table 16 – Error Codes

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

The module is delivered already compiled and in the binary form for the following operational environments:

• Hardware Platform: KR2280V2 Rack Server, Operating System: Linux 5.4.85 with OpenSSL version => 3.0.4
• Hardware Platform: KR2280V2 Rack Server, Operating System: Linux 5.15.50 with OpenSSL version => 3.0.4 For installation, the operator shall follow the Crypto Officer guidance below described.

Crypto Officer The Crypto Officer shall run the following command in order to generate the fipsmodule.cnf file: $ openssl fipsinstall –out fipsmodule.cnf -module fips.so -self_test_onload After this step, the module is ready to use. In order to check that the installation has been successfully performed, the Crypto Officer can execute the following command: $ openssl list –providers And the Linux provider should be indicated. User Guidance The module only supports one mode of operation: Approved. The module will be in Approved mode when all pre-operational self-tests have been completed successfully, and only Approved security functions are invoked. There are no additional installation, configuration, or usage instructions for operators intending to use the Linux OpenSSL FIPS Module. For ensure the correct SSP Zeroization, the user shall ensure that all the contexts that use that SSP shall also be zeroized.

The operator shall follow the Crypto Officer instructions in section 11.2.

The module does not implement the TLS protocol itself, however, it provides the cryptographic functions required for implementing the protocol. AES GCM encryption is used in the context of the TLS protocol versions 1.2 and 1.3 (per Scenario 1 and Scenario 5 in [IG] C.H, respectively). For TLS v1.2, the mechanism for IV generation is compliant with RFC 5288. The counter portion of the IV is strictly increasing. When the IV exhausts the maximum number of possible values for a given session key, this results in a failure in

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD. encryption and a handshake to establish a new encryption key will be required. It is the responsibility of the user of the module i.e., the first party, client or server, to encounter this condition, to trigger this handshake in accordance with RFC 5246. For TLS v1.3, the mechanism for IV generation is compliant with RFC 8446. The module also supports internal IV generation using the module’s Approved DRBG. The IV is at least 96bits in length per NIST SP 800-38D, Section 8.2.1. Per [IG] C.H Scenario 2 and NIST SP 800-38D, the approved DRBG generates outputs such that the (key, IV) pair collision probability is less than 2-32. In the event that the module power is lost and restored, the user must ensure that the AES-GCM encryption/decryption keys are re-distributed.

The AES algorithm in XTS mode can be 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 AES-XTS shall not exceed

The module implements a check to ensure that the two AES keys used in AES-XTS algorithm are not identical. Based on the previous information, the module AES XTS implementation is compliant with FIPS 140-3 IG C.I.

The module is compliant to the FIPS 140-3 IG C.C regarding the SHA-3 family algorithms. All the SHA-3 and SHAKE functions have been tested and validated with the CAVP tool (#A4198), as it is indicated in Table 4. In addition, every higher-level algorithm that uses a SHA-3 family algorithm, are also validated with the CAVP, together in the same CAVP certificate (#A4198).

The module provides different algorithms for digital signature. Among them is the RSA FIPS 186-4, which is compliant with FIPS 140-3 IG C.F. RSA digital signature generation can be performed with 2048-, 3072- or 4096-bits modulus length. As it is indicated in Table 4, all the RSA signature algorithm implementations are tested with the CAVP (#A4198). In the CAVP Certificate, it is indicated that the modulus used by the RSA signature generation are 2048,

3072 and 4096. Therefore, all different modulus length used by the RSA signature generation are tested

by the CAVP. Regarding the Miller-Rabin tests round, the module performs 128 rounds when the modulus is higher than 2048 bits. For the signature verification, the module has tested and validated all the different RSA modulus length implemented by the module: 1024, 2048, 3072 and 4096. This is also indicated in CAVP Cert. #A4198.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Regarding PBKDF, in line with the requirements for SP 800-132, keys generated using the approved PBKDF must only be used for storage applications. Any other use of the approved PBKDF is non-conformant. As the module is a general purpose software module, it is not possible to anticipate all the levels of use for the PBKDF, however a user of the module should also note that a password should at least contain enough security strength to be unguessable and also contain enough strength to reflect the security strength required for the key being generated. The password length should be between 8 and 128 bytes with an increment of 8 bytes. For the iteration count, as the functionality of the module relies on the usage that a user performs with the module, it is recommended a minimum of 1.000 bits. In addition, users are referred to Appendix A, “Security Considerations” in SP 800-132 for further information on password, salt, and iteration count selection.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

The module implements two mitigations against timing-based side-channel attacks, namely Constanttime Implementations and Blinding. Constant-time Implementations protect cryptographic implementations in the Module against timing analysis since such attacks exploit differences in execution time depending on the cryptographic operation, and constant-time implementations ensure that the variations in execution time cannot be traced back to the key, CSP or secret data. Numeric Blinding protects the RSA, DSA and ECDSA algorithms from timing attacks. These algorithms are vulnerable to such attacks since attackers can measure the time of signature operations or RSA decryption. To mitigate this the Module generates a random blinding factor which is provided as an input to the decryption/signature operation and is discarded once the operation has completed and resulted in an output. This makes it difficult for attackers to attempt timing attacks on such operations without the knowledge of the blinding factor and therefore the execution time cannot be correlated to the RSA/DSA/ECDSA key.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

The module implements TLS versions 1.2 and 1.3. The AES GCM supported ciphersuites for each version are listed below: Supported AES GCM ciphersuites for TLS v1.2: •   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 •   TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 •   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 •   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 •   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 •   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 •   TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 •   TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 Supported AES GCM ciphersuites for TLS v1.3: •   TLS_AES_128_GCM_SHA256 •   TLS_AES_256_GCM_SHA384

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.

Linux OpenSSL FIPS Provider v3.1 KAYTUS SYSTEM PTE. LTD.