SUSE Rancher Kubernetes Cryptographic Library

Certificate

Approved Algorithms (28)

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

flowchart LR
  %% Deterministic review-risk graph for SUSE Rancher Kubernetes Cryptographic Library
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    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/>HTTPS<br/>library named: openssl</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    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"]
    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"]
    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
  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 C3,C5,C6 clue;
  class I3,I5,I6 infer;
  class R3,R5,R6 risk;
  class E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for SUSE Rancher Kubernetes Cryptographic Library
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    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/>HTTPS<br/>library named: openssl</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C3,C5,C6 clueLow;

Security Policy, page by page

SUSE LLC. SUSE Rancher Kubernetes Cryptographic Library Software Version: 2.0 Date: March 11, 2026 Prepared by: Corsec Security, Inc.

Fairfax, VA 22033 United States of America Phone: +1 703 267 6050 www.corsec.com Public Material

• May be reproduced only in its original entirety (without revision).

Introduction Federal Information Processing Standards Publication 140-3

• Security Requirements for Cryptographic Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but Unclassified environment. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber Security (CCCS) Cryptographic Module Validation Program (CMVP) run the FIPS 140-3 program. The NVLAP accredits independent testing labs to perform FIPS 140-3 testing; the CMVP validates modules meeting FIPS 140-3 validation. Validated is the term given to a module that is documented and tested against the FIPS 140-

Additional information is available on the CMVP website at: https://csrc.nist.gov/projects/cryptographic-module-validation-program About this Document This non-proprietary Cryptographic Module Security Policy for the SUSE Rancher Kubernetes Cryptographic Library from SUSE LLC. provides an overview of the product and a high-level description of how it meets the overall Level 1 security requirements of FIPS 140-3. The SUSE Rancher Kubernetes Cryptographic Library is also referenced in this document as the “module.” Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. SUSE LLC. shall have no liability for any error or damages of any kind resulting from the use of this document. Notices This document may be freely reproduced and distributed in its entirety without modification. Public Material

• May be reproduced only in its original entirety (without revision).

Contents Public Material

• May be reproduced only in its original entirety (without revision).

1. General This document describes SUSE LLC.’s cryptographic module Security Policy (SP) for the SUSE Rancher Kubernetes Cryptographic Library (Software version: 2.0) cryptographic module (also referred to as the “module” hereafter). It contains specification of the security rules under which the cryptographic module operates, including the security rules derived from the requirements of the FIPS 140-3 standard. The module is a software module and has a Multi-Chip Stand Alone embodiment. The module meets the overall Level 1 security requirements of FIPS 140-3. The following table lists the level of validation for each area in FIPS 140-3: ISO/IEC 24759 FIPS 140-3 Section Title Security Level Section 6.

Table 1 - Security Levels Public Material

• May be reproduced only in its original entirety (without revision).

2. Cryptographic Module Specification The SUSE Rancher Kubernetes Cryptographic Library from SUSE LLC. is an open source software library that contains cryptography to serve SUSE’s Rancher Kubernetes Engine and its ecosystem of supported cloudnative tools written in the Go programming language. The module is intended for use in environments specified in Table 2 below and any general-purpose environment that requires cryptographic primitives. The Tested Operational Environment’s Physical Perimeter (TOEPP) of the module is the physical perimeter of the tested environment, which is listed in Table 2 below. The module is a software module and has a Multi-Chip Stand Alone embodiment. The installation instructions are provided in Section 11 of this document. The boundary of the module is defined as a single object file, bcm.o. The module version is 2.0. The module was tested on the following operational environments: # Operating System Hardware Platform Processor PAA/Acceleration

1 Red Hat Enterprise Ampere Altra Mt Snow Ampere Altra Q80-30 With PAA

Linux 7.6 2U server GIGABYTE R272-P30-JG

2 Red Hat Enterprise Ampere Altra Mt Snow Ampere Altra Q80-30 Without PAA

Linux 7.6 2U server GIGABYTE R272-P30-JG

3 Red Hat Enterprise Dell PowerEdge R440 Intel Xeon Silver 4214R With PAA

4 Red Hat Enterprise Dell PowerEdge R440 Intel Xeon Silver 4214R Without PAA

5 Red Hat Enterprise Ampere Altra Mt Snow Ampere Altra Q80-30 With PAA

Linux 8.8 2U server GIGABYTE R272-P30-JG

6 Red Hat Enterprise Ampere Altra Mt Snow Ampere Altra Q80-30 Without PAA

Linux 8.8 2U server GIGABYTE R272-P30-JG

7 Red Hat Enterprise Dell PowerEdge R440 Intel Xeon Silver 4214R With PAA

8 Red Hat Enterprise Dell PowerEdge R440 Intel Xeon Silver 4214R Without PAA

9 Red Hat Enterprise Ampere Altra Mt Snow Ampere Altra Q80-30 With PAA

Linux 9.0 2U server GIGABYTE R272-P30-JG Public Material

• May be reproduced only in its original entirety (without revision).

# Operating System Hardware Platform Processor PAA/Acceleration

10 Red Hat Enterprise Ampere Altra Mt Snow Ampere Altra Q80-30 Without PAA

Linux 9.0 2U server GIGABYTE R272-P30-JG

11 Red Hat Enterprise Dell PowerEdge R440 Intel Xeon Silver 4214R With PAA

12 Red Hat Enterprise Dell PowerEdge R440 Intel Xeon Silver 4214R Without PAA

13 SUSE SLES 15SP5 Ampere Altra Mt Snow Ampere Altra Q80-30 With PAA

14 SUSE SLES 15SP5 Ampere Altra Mt Snow Ampere Altra Q80-30 Without PAA

15 SUSE SLES 15SP4 Dell PowerEdge R440 Intel Xeon Silver 4214R With PAA

16 SUSE SLES 15SP4 Dell PowerEdge R440 Intel Xeon Silver 4214R Without PAA

17 SLE Micro 5.3 Ampere Altra Mt Snow Ampere Altra Q80-30 With PAA

18 SLE Micro 5.3 Ampere Altra Mt Snow Ampere Altra Q80-30 Without PAA

19 SLE Micro 5.3 Dell PowerEdge R440 Intel Xeon Silver 4214R With PAA

20 SLE Micro 5.3 Dell PowerEdge R440 Intel Xeon Silver 4214R Without PAA

Table 2 - Tested Operational Environments The cryptographic module is also supported on the following operational environments for which operational testing and algorithm testing was not performed. The CMVP makes no statement as to the correct operation of the module on the operational environments for which operational testing was not performed. # Operating System Hardware Platform

ARMv7 architecture ARMv8 architecture Public Material

• May be reproduced only in its original entirety (without revision).

ARMv7 architecture ARMv8 architecture

ARMv7 architecture ARMv8 architecture Table 3 - Vendor Affirmed Operational Environments Table 4 below lists all the approved algorithms implemented in the module: CAVP Cert 1 Algorithm and Mode/Method Description / Key Use / Function Standard Size(s) / Key Strength(s) A6389 AES CBC, ECB, CTR Key sizes: 128, 192, Encryption, Decryption FIPS 197 256 bits; SP800-38A Strength: 128, 192,

A6389 AES GCM Key sizes: 128, Authenticated Encryption, FIPS 197 256 bits; Authenticated Decryption SP800-38D Strength: 128,

A6389 AES CCM Key size: 128 bits; Authenticated Encryption, FIPS 197 Strength: 128 bits Authenticated Decryption SP800-38C A6389 AES, KTS KW, KWP Key sizes: 128, 192, Key Transport per IG D.G Key FIPS 197 256 bits; establishment methodology SP800-38F Strength: 128, 192, provides between 128 and 256

CVL A6389 TLS v1.0/1.1 and v1.2 N/A SHA2-256, SHA2- Key Derivation KDF 2 384, SHA2-512; SP800-135rev1 Strength: 256, 384,

1 There are algorithms that have been CAVP-tested on the same certificate but are not used by any approved service of the

module Only the algorithms, modes/methods, and key lengths/curves/moduli shown in this table are used by an approved service of the module.

2 No parts of this protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and

CMVP. Public Material

• May be reproduced only in its original entirety (without revision).

CAVP Cert 1 Algorithm and Mode/Method Description / Key Use / Function Standard Size(s) / Key Strength(s) Vendor Affirmed CKG SP800-133rev2 Cryptographic Key Key Generation Generation: Symmetric keys and seeds are Section 5: Generation generated as the direct output of Key Pairs for of the DRBG Asymmetric-Key Algorithms, Section 6.1: The “Direct Generation” of Symmetric Keys A6389 DRBG CTR_DRBG AES-256; Random Bit Generation SP800-90Arev1 Key size: 256 bits; Strength: 256 bits A6389 ECDSA FIPS 186-4 Key Pair Generation, P-224, P-256, P-384, Digital Signature Services Signature Generation, P-521; Signature Verification, Strength: 112, 128, Public Key Validation 192, 256 bits A6389 HMAC Generate, Verify HMAC-SHA-1, Generation, Authentication FIPS 198-1 HMAC-SHA2-224, HMAC-SHA2-256, HMAC-SHA2-384, HMAC-SHA2-512; Strength: 128, 192, 256, 384, 512 bits A6389 RSA 3 Key Generation, 1024, 2048, 3072, Digital Signature Services FIPS 186-4 Signature Generation, 4096; Signature Verification Strength: 80, 112, PKCS 1.5 and PSS 128, 152 bits; Note: Key size 1024 should be only used for Signature Verification RSA with SHA-1 is available for legacy use only and can only be used to verify signatures generated prior to 2011. Public Material

• May be reproduced only in its original entirety (without revision).

CAVP Cert 1 Algorithm and Mode/Method Description / Key Use / Function Standard Size(s) / Key Strength(s) A6389 SHA Hashing SHA-1 4, SHA2-224, Digital Signature Generation, FIPS 180-4 SHA2-256, SHA2-384, Digital Signature Verification, SHA2-512, SHA2- Non-Digital Signature 512/256; Applications Strength: 80, 112, 128, 192, 256, 128 bits A6389 KAS-SSC KAS-ECC-SSC ECC: P-224, P-256, P- Key Agreement Scheme Shared SP800-56Arev3 ephemeralUnified 384 and P-521; Secret Computation per Strength: 112, 128, SP800-56Arev3; 192, 256 bits Key establishment methodology provides between 112 and 256 bits of security strength Table 4 - Approved Algorithms Algorithm Caveat Use / Function MD5 As allowed per SP800-135rev1 When used with the TLS (No security claimed) protocol version 1.0 and 1.1 Table 5 - Non-Approved, Allowed Algorithms with No Security Claimed Algorithm/Function Use/Function MD5, MD4 Non-Approved hashing POLYVAL Non-Approved authenticated encryption DES, Triple-DES (non-compliant) Non-Approved encryption/decryption AES-GCM-SIV (non-compliant) Non-Approved encryption/decryption DH (non-compliant) Non-Approved key agreement ECDSA with SHA2-512/256 Performing an ECDSA operation with the SHA512/256 hash algorithm (sign and verify) RSA Primitives (RSADP, RSAEP, RSASP, RSAVP) Perform RSA related primitive operations (decrypt, encrypt, sign, verify) Table 6 - Non-Approved, Not Allowed Algorithms

4 Used for non-digital signature applications or to verify existing digital signatures only

Public Material

• May be reproduced only in its original entirety (without revision).

Physical Perimeter: General Purpose Computer Application (out of validation scope) Calling Function Caller CSPs API invocation System calls SUSE Rancher Kubernetes Cryptographic Library System calls Operating System CPU Memory Storage Ports Figure 1 - Module Boundary

AES GCM encryption and decryption are used in the context of the TLS protocol version 1.2 (compliant to Scenario 1a in FIPS 140-3 IG C.H). The module is compliant with NIST SP 800-52 and the mechanism for IV generation is compliant with RFC 5288. The module ensures that it is strictly increasing and thus cannot repeat. When the IV exhausts the maximum number of possible values for a given session key, the first party (client or server) to encounter this condition may either trigger a handshake to establish a new encryption key in accordance with RFC 5246 or fail. In either case, the module prevents any IV duplication and thus enforces the security property. The module’s IV is generated internally by the module’s Approved DRBG, which is internal to the module’s boundary. The IV is 96 bits in length per NIST SP 800-38D, Section 8.2.2 and FIPS 140-3 IG C.H scenario 2. The selection of the IV construction method is the responsibility of the user of this cryptographic module. In approved mode, users of the module must not utilize GCM with an externally generated IV. Per FIPS 140-

3 IG C.H, in the event module power is lost and restored, the consuming application must ensure that any

of its AES-GCM keys used for encryption or decryption are re-distributed. The module implements the TLS 1.2 KDF and other cryptographic primitives used in TLS 1.2, but does not implement the TLS 1.2 protocol itself.

The module allows the use of 1024-bit RSA keys for legacy purposes including signature generation, which is disallowed in Approved mode as per NIST SP 800-131Arev2. Therefore, cryptographic operations with the Non-Approved key sizes will result in the module operating in Non-Approved mode. Public Material

• May be reproduced only in its original entirety (without revision).

The elliptic curves utilized shall be the validated NIST-recommended curves and shall provide a minimum of

The EVP_Digest_* APIs must be used for ECDSA sign and verify operations.

Non-Approved cryptographic algorithms shall not share the same key or CSP as an approved algorithm. As such, Approved algorithms shall not use the keys generated by the module’s Non-Approved key generation methods or the converse.

The module supports two modes of operation: Approved and Non-approved. The module will be in approved mode when all self-tests have completed successfully, and only Approved algorithms are invoked. Section 10 provides details on error messages if a self-test fails. The self-tests have passed if no error state occurs. See Table 4 above for a list of the supported Approved algorithms. The non-Approved mode is entered when a non-Approved algorithm is invoked. See Table 6 for a list of non-Approved algorithms. Public Material

• May be reproduced only in its original entirety (without revision).

3. Cryptographic Module Interfaces The Data Input interface consists of the input parameters of the API functions. The Data Output interface consists of the output parameters of the API functions. The Control Input interface consists of the actual API input parameters. The Status Output interface includes the return values of the API functions. Logical interface Data that passes over port/interface Data Input API input parameters Data Output API output parameters and return values Control Input API input parameters Status Output API return values Table 7 - Ports and Interfaces The module does not implement a power input interface or a control output interface. As a software module, control of the physical ports is outside the module scope. However, when the module is performing self-tests, or is in an error state, all output on the module’s logical data output interfaces is inhibited. Public Material

• May be reproduced only in its original entirety (without revision).

4. Roles, Services, and Authentication

The cryptographic module only implements a Crypto Officer (CO) role. The CO role is implicitly assumed by the entity accessing services implemented by the module. An operator is considered the owner of the thread that instantiates the module and, therefore, only one operator is allowed, and no concurrent operators are allowed.

The module does not support operator authentication.

The Approved services supported by the module and access rights within services accessible over the module’s public interface are listed in Table 8 below. Role Service Input Output CO Symmetric Encryption Plaintext, encryption key Return code, ciphertext CO Symmetric Decryption Ciphertext, decryption key Return code, plaintext CO Keyed Hashing Message, key Return code, Message Authentication Code CO Hashing Message Return code, hash CO Random Bit Generation API call parameters Return code, random bits CO Signature Generation Message, signing key Return code, signature CO Signature Verification Signature, verification key Return code CO Key Transport API call parameters, wrapping Return code, wrapped key key or unwrapped key CO Key Agreement API call parameters Return code, shared secret CO TLS Key Derivation API call parameters, TLS pre- Return code, TLS Key master secret CO Key Generation API call parameters Return code, key pair CO Key Verification API call parameters, key pair Return code CO On-Demand Self-Test N/A N/A CO Additional On-Demand Self- N/A Return code Tests CO Zeroization N/A N/A CO Show versioning API function selection Module name or module information version CO Show Status API call parameters Return code, status Table 8 - Roles, Service Commands, Input and Output Public Material

• May be reproduced only in its original entirety (without revision).

Approved services are listed in Table 9. The SSPs listed in the table indicate the access required using below notation: 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. Unless otherwise specified, the indicator value is the difference in return values from the API functions FIPS_service_indicator_before_call() and FIPS_service_indicator_after_call(), where the first is called immediately prior to using the service and the second is called immediately after using the service. Public Material

• May be reproduced only in its original entirety (without revision).

Service Description Approved Security Keys and/or SSPs Roles Access Rights to Indicator Functions Keys and/or SSPs Symmetric Encryption Perform symmetric AES CBC, ECB, CTR, AES Key, AES-GCM Key CO W, E 1 encryption operations GCM CCM (Cert. #A6389) CKG Symmetric Decryption Perform symmetric AES CBC, ECB, CTR, AES Key, AES-GCM Key, CO W, E 1 decryption operations GCM, CCM AES-GCM IV (Cert. #A6389) CKG Keyed Hashing Perform keyed hashing HMAC-SHA-1, HMAC Key CO W, E 1 operations HMAC-SHA2-224, HMAC-SHA2-256, HMAC-SHA2-384, HMAC-SHA2-512 (Cert. #A6389) Hashing Perform hashing operations SHA-1, SHA2-224, N/A CO N/A 1 SHA2-256, SHA2384, SHA2-512, SHA2-512/256 (Cert. #A6389) Random Bit Generation Generate random numbers CTR_DRBG DRBG Seed, CTR_DRBG V, CO G, E 1 (Cert. #A6389) CTR_DRBG Key CKG DRBG output CO G, R CTR_DRBG CO W, E Entropy Input Public Material

• May be reproduced only in its original entirety (without revision).

Service Description Approved Security Keys and/or SSPs Roles Access Rights to Indicator Functions Keys and/or SSPs Signature Generation Perform signing operations CTR_DRBG, RSA Signature CO G, W, E 1 RSA SigGen, Generation Key, ECDSA SigGen ECDSA Signing Key (Cert. #A6389) Signature Verification Perform verification RSA SigVer, RSA Signature Verification CO G, W, E 1 operations ECDSA SigVer Key, (Cert. #A6389) ECDSA Verification Key Key Transport Perform key encryption, AES KW, KWP AES Wrapping Key CO W, E 1 decryption operations; KTS (Cert. #A6389) using AES-KW, AES-KWP per CKG IG D.G Key Agreement Perform key agreement KAS-ECC-SSC (Cert. EC DH Private Key, EC DH CO G, W, E 1 operations #A6389) Public Key Shared Secret G TLS Key Derivation Perform key derivation TLS KDF TLS Pre-Master Secret CO W, E 1 operations (Cert. #A6389) TLS Master Secret G, E Key Generation Perform generation CTR_DRBG, RSA Signature CO G, W, E 1 operations RSA KeyGen, Generation Key, ECDSA KeyGen ECDSA Signing Key (Cert. #A6389) CKG Key Verification Perform key pair ECDSA KeyVer (Cert. ECDSA Signing Key, CO G, W, E 1 verification operations #A6389) ECDSA Verification Key Public Material

• May be reproduced only in its original entirety (without revision).

Service Description Approved Security Keys and/or SSPs Roles Access Rights to Indicator Functions Keys and/or SSPs On-Demand Self-Test Execute self-tests on N/A N/A CO N/A N/A demand Zeroization Zeroize all SSPs N/A All SSPs CO Z Successful host platform restart Show Status Obtain the module status N/A N/A CO N/A N/A information Show versioning Obtain the module N/A N/A CO N/A N/A information versioning information Additional On-Demand Execute self-tests through N/A N/A CO N/A 1 Self-Tests API call Table 9 - Approved Services Public Material

• May be reproduced only in its original entirety (without revision).

Non-Approved Services are listed in the Table 10 below: Service Description Algorithms Accessed Role Indicator Hashing (as allowed per Perform hashing operations when used with MD5 CO 0 SP800-135rev1) the TLS protocol version 1.0 and 1.1 Hashing Perform hashing operations MD4 CO 0 Hashing Used as part of AES-GCM-SIV POLYVAL CO 0 Symmetric Perform symmetric encryption and/or DES CO 0 encryption/decryption decryption operations Triple-DES AES Key Generation Perform generation operations DH CO 0 RSA Primitives (RSADP, Perform RSA related primitive operations RSA CO 0 RSAEP, RSASP, RSAVP) (decrypt, encrypt, sign, verify) Digital signature generation Performing an ECDSA operation with the ECDSA with SHA- CO 0 and verification (ECDSA SHA-512/256 hash algorithm (sign and verify) 512/256 with SHA-512/256) Table 10 - Non-Approved Services Public Material

• May be reproduced only in its original entirety (without revision).

5. Software/Firmware Security The pre-operational integrity test is performed using HMAC-SHA2-256. The integrity test can be executed on demand by power-cycling the host platform and reloading the module. The module does not support software loading. Please refer to Section 11.1 for instructions on compiling the source code into executable.

The form of the module is a single object file, bcm.o.

6. Operational Environment The module runs on a GPC, which is a modifiable operational environment, running one of the operating systems specified in Table
7. Each approved operating system manages processes and threads in a logically separated manner. The module’s user is considered the owner of the calling application that instantiates the module. No specific security rules, settings or restrictions to the configuration of the operational environment applies to the module. The module is designed to ensure that all the self-tests are initiated automatically when the module is loaded.
8. Physical Security As a software module, the physical security requirements are not applicable.
9. Non-invasive Security The module does not claim any non-invasive security measures. Public Material – May be reproduced only in its original entirety (without revision).

9. Sensitive Security Parameter Management All the SSPs are zeroized implicitly when host platform is restarted. The various SSPs used by the module are listed in Table 11 below. Key/SSP Strength Security Generation Import/ Export Establishment Storage Zeroisation Use & Related Keys Name/Type Function and Cert. Number AES Key 128/192/256 bits AES-CBC, ECB, External Input via API in N/A Plaintext in Power-cycle AES encrypt / decrypt (CSP) CTR, CCM plaintext RAM host A6389 (Electronic Entry) AES-GCM Key 128/256 bits AES-GCM A6389 External Input via API in N/A Plaintext in Power-cycle AES decrypt / verify (CSP) plaintext RAM host (Electronic Entry) AES-GCM IV 5 96 bits AES-GCM A6389 External Input via API in N/A Plaintext in Power-cycle AES decrypt / verify (CSP) plaintext RAM host (Electronic Entry) AES Wrapping or 128/192/256 bits AES-KW, External Input via API in N/A Plaintext in Power-cycle AES key wrapping or Unwrapping AES-KWP plaintext RAM Host unwrapping Key A6389 (Electronic (CSP) Entry)

5 As specified in Section 2.1.1, usage of externally generated IV is only allowed for AES-GCM decryption in the approved mode of operation.

Public Material

• May be reproduced only in its original entirety (without revision).

Key/SSP Strength Security Generation Import/ Export Establishment Storage Zeroisation Use & Related Keys Name/Type Function and Cert. Number ECDSA Signing 112/128/192/256 ECDSA SigGen Internally Input via API in N/A Plaintext in Power-cycle ECDSA signature Key bits A6389 Generated plaintext RAM host generation (CSP) (Electronic Entry); Output via API in plaintext (Electronic Entry) ECDSA 112/128/192/256 ECDSA SigVer Internally Input via API in N/A Plaintext in Power-cycle ECDSA signature Verification Key bits A6389 Generated plaintext RAM Host verification (PSP) (Electronic Entry); Output via API in plaintext (Electronic Entry) EC DH 112/128/192/256 ECDSA KeyGen Internally Input via API in N/A Plaintext in Power-cycle Key Agreement Private Key bits A6389 Generated plaintext RAM host (CSP) (Electronic Entry); Output via API in plaintext (Electronic Entry) Public Material

• May be reproduced only in its original entirety (without revision).

Key/SSP Strength Security Generation Import/ Export Establishment Storage Zeroisation Use & Related Keys Name/Type Function and Cert. Number EC DH Public 112/128/192/256 ECDSA KeyGen Internally Input via API in N/A Plaintext in Power-cycle Key Agreement Key bits A6389 Generated plaintext RAM host (PSP) (Electronic Entry); Output via API in plaintext (Electronic Entry) HMAC Key 128/192/256/384 HMAC-SHA-1, External Input via API in N/A Plaintext in Power-cycle Keyed hashing (CSP) /512 bits HMAC-SHA2- plaintext RAM host 224, HMAC- (Electronic SHA2-256, Entry) HMAC-SHA2384, HMACSHA2-512 A6389 Shared Secret 112/128/192/256 KAS-ECC-SSC Internally N/A SP800- Plaintext in Power-cycle Key Agreement (CSP) bits A6389 Generated 56Arev3 RAM host RSA 112, 128, 152 bits RSA SigGen Internally Input via API in N/A Plaintext in Power-cycle RSA signature Signature A6389 Generated plaintext RAM host generation Generation Key (Electronic (CSP) Entry); Output via API in plaintext (Electronic Entry) Public Material

• May be reproduced only in its original entirety (without revision).

Key/SSP Strength Security Generation Import/ Export Establishment Storage Zeroisation Use & Related Keys Name/Type Function and Cert. Number RSA 80, 112, 128, 152 RSA SigVer A6389 Internally Input via API in N/A Plaintext in Power-cycle RSA signature Signature bits Generated plaintext RAM host verification Verification (Electronic Key Entry); (PSP) Output via API in plaintext (Electronic Entry) TLS Master 384 bits TLS KDF A6389 Internally N/A N/A Plaintext in Power-cycle TLS key derivation Secret Derived via RAM host (CSP) key derivation function defined in SP800135rev1 KDF (TLS) TLS Pre-Master 112-256 bits TLS KDF A6389 External Input via API in N/A Plaintext in Power-cycle TLS key derivation Secret plaintext RAM host (CSP) (Electronic Entry) DRBG Seed (CSP) 384 bits CTR_DRBG A6389 Internally N/A N/A Plaintext in Power-cycle DRBG Seeding Generated RAM host material CTR_DRBG V 128 bits CTR_DRBG A6389 Internally N/A N/A Plaintext in Power-cycle DRBG internal state (CSP) Generated RAM host Public Material

• May be reproduced only in its original entirety (without revision).

Key/SSP Strength Security Generation Import/ Export Establishment Storage Zeroisation Use & Related Keys Name/Type Function and Cert. Number CTR_DRBG 256 bits CTR_DRBG A6389 Internally N/A N/A Plaintext in Power-cycle DRBG internal state Key Generated RAM host (CSP) CTR_DRBG 384 bits used as CTR_DRBG A6389 External Input via API inN/A Plaintext in Power- DRBG entropy Entropy Input seed, quality of plaintext RAM cycle host (CSP) entropy at least (Electronic

DRBG output 2048 bits CTR_DRBG A6389 Internally N/A N/A Plaintext in Power- Random bits provided Generated RAM cycle host for the calling application Table 11 - SSPs Public Material

• May be reproduced only in its original entirety (without revision).

Entropy sources Minimum number of bits of Details entropy Passive Entropy 112 bits and above Use of a [SP800-90B] compliant entropy source with at least 256 bits of security strength. Entropy is supplied to the Module via callback functions. The callback functions shall return an error if the minimum entropy strength cannot be met. The caveat “No assurance of the minimum strength of generated SSPs (e.g., keys)” is applicable Table 12 - Non-Deterministic Random Number Generation Specification 10. Self-Tests ISO/IEC 19790 requires the module to perform self-tests to ensure the integrity of the module and the correctness of the cryptographic functionality. Some functions also require conditional tests during normal operation of the module. All Conditional Cryptographic Algorithm Self-Tests (CAST) except the RSA sign and verify KAT, ECDSA sign and verify KAT, and SP 800-56Arev3 KAS-ECC KAT can be requested on demand by power cycling the host platform. The command BORINGSSL_self_test() can be used to run all CASTs. The module has two error states: the main error state and a PCT error state. The main error state is entered upon failure of a pre-operational self-test or a CAST (Cryptographic Algorithm Self-Test). The module indicates this error state by providing the output status “FIPS integrity test failed” or “*** KAT failed” where *** is the algorithm name (example: ECDSA-sign KAT failed). The module can be recovered by terminating execution of the host program and reclamation by the host operating system, then re-instantiating the module. The supported tests are listed and described in this section. If the self-test error does not clear with re-instantiation, then the user should contact SUSE support for assistance at https://scc.suse.com/. Upon failure of a conditional PCT transitions to the PCT error state described in Section 10.2.

Pre-operational self-tests are run upon the initialization of the module and further reboots of the host platform. The CAST (Cryptographic Algorithm Self-Test) for HMAC-SHA2-256 is performed before the integrity test. Self-tests do not require operator intervention to run. If any of the tests fail, the module will not initialize and enter an error state where no services can be accessed. The module implements the following pre-operational self-tests:

• Software Integrity Test (HMAC-SHA2-256) Public Material
• May be reproduced only in its original entirety (without revision).

CASTs are run prior to the first use of the cryptographic algorithm. CASTs do not require operator intervention to run. If any of the tests fail, the module will enter an error state, and no services can be accessed. The module implements the following CASTs:

• Run during start-up:
• AES CBC Encryption KAT (128 bits)
• AES CBC Decryption KAT (128 bits)
• AES-GCM Encryption KAT (128 bits)
• AES-GCM Decryption KAT (128 bits)
• CAST, performed on DRBG, per NIST SP800-90Arev1 Section 11.3 (Instantiate, Generate, Reseed)
• TLS v1.2 KDF KAT
• SHA-1 KAT
• SHA2-256 KAT
• SHA2-512 KAT
• HMAC-SHA2-256 KAT
• Run conditionally
• ECDSA Signature Generation KAT (P-256)
• ECSDA Signature Verification KAT (P-256)
• RSA Signature Generation KAT (2048 bits, PKCSv1.5)
• RSA Signature Verification KAT (2048 bits, PKCSv1.5
• SP900-56Arev3 KAS-ECC KAT (P-256) Conditional self-tests are run during the module’s operation. If any of these tests fail, the module will enter an error state, where no services can be accessed by the operators. The module must be re- initialized to clear the error and resume approved mode of operation. The module implements the following conditional pairwise consistency tests. The below PCTs are executed whenever a new key pair is generated:
• ECDSA Pairwise Consistency Test
• EC DH Pairwise Consistency Test
• RSA Pairwise Consistency Test Upon failure of a conditional PCT, the module will write an error message to a message queue maintained in RAM. Error messages is:
• For RSA PCT o “14061464:error:04000069:RSA routines:OPENSSL_internal: BAD_SIGNATURE:{path to rsa code}:634” where the {path to rsa code} is the path to the module code for rsa.c. This indicates an incomplete certificate chain. o “14061464:error:04000044:RSA routines:OPENSSL_internal: internal error:{path to rsa code}:634” where the {path to rsa code} is the path to the module code for rsa.c. This indicates an error in the RSA algorithm or padding.
• For EC PCT “PUBLIC_KEY_VALIDATION_FAILED” Public Material
• May be reproduced only in its original entirety (without revision).

Once the error message is written, the error state is automatically cleared, and the module continues normal operations. The module is single-threaded and therefore can only perform function calls one at a time. While the error message is being written to RAM, no other calls can be processed, thus inhibiting data output and cryptographic operations. 11. Life-Cycle Assurance The cryptographic module is initialized by loading the module before any cryptographic functionality is available. In User Space, the operating system is responsible for the initialization process and loading of the library. There are no maintenance requirements applicable. General guidance about the module can be found at https://boringssl.googlesource.com/boringssl. This includes information about the APIs, building and specific information related to FIPS can be found at https://boringssl.googlesource.com/boringssl.git/+/refs/heads/fips-20220613/crypto/fipsmodule/FIPS.md (note this still mentions 140-2, but the information there is the same).

During the manufacturing process, SUSE executes the build and installation instructions for the module as a part of SUSE Rancher Kubernetes on the Red Hat Enterprise, SUSE SLE, and SUSE Micro environments. The Module is pre-installed and configured in supported SUSE solutions. The approved mode is enabled by default. There are no additional installation, configuration, or usage instructions for operators intending to use the Module.

The following methods will provide the module name and versions:

• FIPS_module_name()
• BoringCrypto (correlating to “SUSE Rancher Kubernetes Cryptographic Library” on the validation certificate)
• FIPS_version()
• 2022061300 (correlating to “2.0” on the validation certificate) Public Material
• May be reproduced only in its original entirety (without revision).

12. Mitigation of Other Attacks The module is not designed to mitigate attacks which are outside of the scope of FIPS 140-3. Public Material

• May be reproduced only in its original entirety (without revision).

References and Standards The following Standards are referenced in this Security Policy: Abbreviation Full Specification Name FIPS 140-3 Security Requirements for Cryptographic modules FIPS 180-4 Secure Hash Standard (SHS) FIPS 186-4 Digital Signature Standard (DSS) FIPS 197 Advanced Encryption Standard FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC) IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program SP 800-38A Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode SP 800-38C Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC SP 800-38F Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping SP 800-52 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations SP 800-56A Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography SP 800-90A Recommendation for Random Number Generation Using Deterministic Random Bit Generators SP 800-131A Transitioning the Use of Cryptographic Algorithms and Key Lengths SP 800-133 Recommendation for Cryptographic Key Generation SP 800-135 Recommendation for Existing Application-Specific Key Derivation Functions Public Material

• May be reproduced only in its original entirety (without revision).

Acronyms Acronym Definition AES Advanced Encryption Standard API Application Programming Interface CAVP Cryptographic Algorithm Validation Program CBC Cipher-Block Chaining CCCS Canadian Centre for Cyber Security CFB Cipher Feedback CKG Cooperative Key Generation CMVP Crypto Module Validation Program CO Cryptographic Officer CRNGT Continuous Random Number Generator Test CSP Critical Security Parameter CTR Counter-mode DES Data Encryption Standard DH Diffie-Hellman DRBG Deterministic Random Bit Generator DSS Digital Signature Standard EC Elliptic Curve ECB Electronic Code Book ECC Elliptic Curve Cryptography EC DH Elliptic Curve Diffie-Hellman ECDSA Elliptic Curve Digital Signature Authority FIPS Federal Information Processing Standards GCM Galois/Counter Mode GMAC Galois Message Authentication Code GPC General Purpose Computer HMAC Key-Hashed Message Authentication Code IG Implementation Guidance IV Initialization Vector KAS Key Agreement Scheme KAT Known Answer Test KDF Key Derivation Function KW Key Wrap KWP Key Wrap with Padding LLC Limited Liability Company MAC Message Authentication Code MD4 Message Digest algorithm MD4 MD5 Message Digest algorithm MD5 N/A Not-Applicable NIST National Institute of Standards and Technology NVLAP National Voluntary Lab Accreditation Program Public Material

• May be reproduced only in its original entirety (without revision).

OFB Output Feedback PAA Processor Algorithm Accelerator RAM Random Access Memory RFC Request For Comment RSA Rivest Shamir Adleman SHA Secure Hash Algorithm SHS Secure Hash Standard SP Special Publication SSL Secure Socket Layer TLS Transport Layer Security Triple-DES Triple Data Encryption Standard Public Material

• May be reproduced only in its original entirety (without revision).