Copyright © 2024 SUSE LLC
This non-proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.
SUSE Rancher Kubernetes Cryptographic Library
FIPS 140-2 Non-Proprietary Security Policy
Document Version 1.0
March 28, 2024
Prepared for: Prepared by:
SUSE LLC
1221 S Valley Grove Way
Suite 500
Pleasant Grove, UT 84062
suse.com
Corsec Security, Inc.
13921 Park Center Road
Suite 460
Herndon, VA 20171
corsec.com
+1 703.276.6050
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 2 of 18
Table of Contents
1 Introduction ..............................................................................................................................4
2 FIPS 140-2 Security Levels ..........................................................................................................4
3 Cryptographic Module Specification...........................................................................................5
3.1 Cryptographic Boundary.............................................................................................................................5
4 Modes of Operation ..................................................................................................................6
5 Cryptographic Module Ports and Interfaces ...............................................................................6
6 Roles, Authentication and Services ............................................................................................7
7 Physical Security........................................................................................................................8
8 Operational Environment ..........................................................................................................8
9 Cryptographic Algorithms & Key Management...........................................................................9
9.1 Approved Cryptographic Algorithms..........................................................................................................9
9.2 Allowed Cryptographic Algorithms...........................................................................................................10
9.3 Non-Approved Cryptographic Algorithms................................................................................................10
9.4 Cryptographic Key Management..............................................................................................................11
9.5 Public Keys................................................................................................................................................11
9.6 Key Generation.........................................................................................................................................12
9.7 Key Storage...............................................................................................................................................12
9.8 Key Zeroization.........................................................................................................................................12
10 Self-Tests.................................................................................................................................13
10.1 Power-On Self-Tests .................................................................................................................................13
10.2 Conditional Self-Tests...............................................................................................................................13
11 Mitigation of Other Attacks .....................................................................................................14
12 Guidance and Secure Operation...............................................................................................15
12.1 Installation Instructions............................................................................................................................15
12.2 Secure Operation......................................................................................................................................16
12.2.1 Initialization.....................................................................................................................................................16
12.2.2 Usage of AES OFB, CFB and CFB8 ....................................................................................................................16
12.2.3 Usage of AES-GCM...........................................................................................................................................16
12.2.4 Usage of Triple-DES .........................................................................................................................................16
12.2.5 Usage of RSA and ECDSA .................................................................................................................................16
13 References and Standards........................................................................................................17
14 Acronyms and Definitions........................................................................................................17
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 3 of 18
List of Tables
Table 1 - Tested Operational Environments...............................................................................................................4
Table 2 - Validation Level by FIPS 140-2 Section........................................................................................................4
Table 3 - Ports and Interfaces.....................................................................................................................................6
Table 4 - Approved Services, Roles and Access Rights ...............................................................................................7
Table 5 - Non-Approved or Non-Security Relevant Services......................................................................................7
Table 6 - Non-Security Relevant Services...................................................................................................................7
Table 7 - Approved Algorithms and CAVP Certificates...............................................................................................9
Table 8 - Allowed Algorithms .................................................................................................................................. 10
Table 9 - Non-Approved Algorithms........................................................................................................................ 10
Table 10 - Keys and CSPs Supported ....................................................................................................................... 11
Table 11 - Public Keys Supported............................................................................................................................ 11
Table 12 - Power-On Self-Tests ............................................................................................................................... 13
Table 13 - Conditional Self-Tests............................................................................................................................. 13
Table 14 - References and Standards...................................................................................................................... 17
Table 15 - Acronyms and Definitions....................................................................................................................... 17
List of Figures
Figure 1 - Logical Boundary ........................................................................................................................................5
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 4 of 18
1 Introduction
The SUSE Rancher Kubernetes Cryptographic Library (hereafter referred to as the “module”) is an open-source,
general-purpose cryptographic library which provides FIPS 140-2 approved cryptographic algorithms to serve
BoringSSL and other user-space applications. The validated version of the library is:
853ca1ea1168dff08011e5d42d94609cc0ca2e27.
For the purposes of the FIPS 140-2 validation, its embodiment type is defined as multi-chip standalone.
The cryptographic module was tested on the following operational environments on the general-purpose
computer (GPC) platforms detailed below:
Table 1 - Tested Operational Environments
# Operational Environment Processor Family
1 SUSE Liberty Linux 7.9 on Dell PowerEdge R440 Intel® Xeon® Silver 4214R with PAA
2 SUSE Liberty Linux 7.9 on Dell PowerEdge R440 Intel® Xeon® Silver 4214R without PAA
3 SUSE Liberty Linux 8.8 on Dell PowerEdge R440 Intel® Xeon® Silver 4214R with PAA
4 SUSE Liberty Linux 8.8 on Dell PowerEdge R440 Intel® Xeon® Silver 4214R without PAA
5 Red Hat Enterprise Linux 7.9 on Dell PowerEdge R440 Intel® Xeon® Silver 4214R with PAA
6 Red Hat Enterprise Linux 7.9 on Dell PowerEdge R440 Intel® Xeon® Silver 4214R without PAA
7 Red Hat Enterprise Linux 8.8 on Dell PowerEdge R440 Intel® Xeon® Silver 4214R with PAA
8 Red Hat Enterprise Linux 8.8 on Dell PowerEdge R440 Intel® Xeon® Silver 4214R without PAA
The GPCs used during testing met Federal Communications Commission (FCC) Electromagnetic Interference (EMI)
and Electromagnetic Compatibility (EMC) requirements for business use as defined by 47 Code of Federal
Regulations, Part 15, Subpart B. FIPS 140-2 validation compliance is maintained when the module is operated on
other versions of the GPOS running in single user mode, assuming that the requirements outlined in FIPS 140-2 IG
G.5 are met.
The CMVP makes no statement as to the correct operation of the module or the security strengths of the
generated keys when so ported if the specific operational environment is not listed on the validation certificate.
2 FIPS 140-2 Security Levels
The following table lists the level of validation for each area in FIPS 140-2:
Table 2 - Validation Level by FIPS 140-2 Section
FIPS 140-2 Section Title Validation Level
Cryptographic Module Specification 1
Cryptographic Module Ports and Interfaces 1
Roles, Services, and Authentication 1
Finite State Model 1
Physical Security N/A
Operational Environment 1
Cryptographic Key Management 1
Electromagnetic Interference / Electromagnetic Compatibility 1
Self-Tests 1
Design Assurance 1
Mitigation of Other Attacks N/A
Overall Level 1
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 5 of 18
3 Cryptographic Module Specification
3.1 Cryptographic Boundary
The module is a software library providing a C-language Application Program Interface (API) for use by other
processes that require cryptographic functionality. All operations of the module occur via calls from host
applications and their respective internal daemons/processes. As such there are no untrusted services calling the
services of the module.
The physical cryptographic boundary is the general-purpose computer on which the module is installed. The
logical cryptographic boundary of the module is a single object file named “bcm.o” which is linked into the
libcrypto.so shared library. The module performs no communications other than with the calling application (the
process that invokes the module services) and the host operating system.
Figure 1 shows the logical relationship of the cryptographic module to the other software and hardware
components of the computer.
Figure 1 - Logical Boundary
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 6 of 18
4 Modes of Operation
The module supports two modes of operation: Approved and Non-Approved. The module will be in FIPS-approved
mode when all power up self-tests have completed successfully, and only Approved or allowed algorithms are
invoked. See Table 7 for a list of the supported Approved algorithms and Table 8 for allowed algorithms. The non-
Approved mode is entered when a non-Approved algorithm is invoked. See Table 9 for a list of non-Approved
algorithms.
5 Cryptographic Module Ports and 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.
Table 3 - Ports and Interfaces
FIPS Interface Physical Ports Logical Interfaces
Data Input Physical ports of the tested platforms API input parameters
Data Output Physical ports of the tested platforms API output parameters and return values
Control Input Physical ports of the tested platforms API input parameters
Status Output Physical ports of the tested platforms API return values
Power Input Physical ports of the tested platforms N/A
As a software module, control of the physical ports is outside 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.
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 7 of 18
6 Roles, Authentication and Services
The cryptographic module implements both User and Crypto Officer (CO) roles. The module does not support user
authentication. The User and CO roles are implicitly assumed by the entity accessing services implemented by the
module. A user is considered the owner of the thread that instantiates the module and, therefore, only one
concurrent user is allowed.
The Approved services supported by the module and access rights within services accessible over the module’s
public interface are listed in the table below.
Table 4 - Approved Services, Roles and Access Rights
Service Approved Security
Functions
Keys and/or CSPs Roles Access Rights to
Keys and/or CSPs
Module Initialization N/A N/A CO N/A
Symmetric Encryption/Decryption AES, Triple-DES AES, Triple-DES symmetric
keys
User, CO Execute
Keyed Hashing HMAC-SHA HMAC key User, CO Execute
Hashing SHS None User, CO N/A
Random Bit Generation CTR_DRBG DRBG seed, internal state
V and Key values
User, CO Write/Execute
Signature Generation/Verification CTR_DRBG, RSA, ECDSA RSA, ECDSA private key User, CO Write/Execute
Key Transport RSA RSA private key User, CO Write/Execute
Key Agreement KAS ECC EC DH private key User, CO Write/Execute
Key Generation CTR_DRBG, RSA, ECDSA RSA, ECDSA private key User, CO Write/Execute
On-demand Self-test N/A N/A User, CO Execute
Zeroization N/A All keys User, CO Write/Execute
Show Status N/A N/A User, CO N/A
The module provides the following non-Approved services which utilize algorithms listed in Table 9:
Table 5 - Non-Approved or Non-Security Relevant Services
Service Non-Approved Functions Roles Keys and/or CSPs
Symmetric Encryption/Decryption AES (non-compliant), DES, Triple-DES (non-compliant) User, CO N/A
Hashing MD4, MD5, POLYVAL, GHASH User, CO N/A
Signature Generation/Verification RSA (non-compliant), ECDSA (non-compliant) User, CO N/A
Key Transport RSA (non-compliant) User, CO N/A
Key Generation RSA (non-compliant), ECDSA (non-compliant) User, CO N/A
The module also provides the following non-Approved or non-security relevant services over a non-public
interface:
Table 6 - Non-Security Relevant Services
Service Approved Security Functions Roles Access Rights to
Keys and/or CSPs
Large integer operations None User, CO N/A
Disable automatic generation of
CTR_DRBG "additional_input"
parameter
CTR_DRBG User, CO N/A
Wegman-Carter hashing with
POLYVAL
None User, CO N/A
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 8 of 18
7 Physical Security
The cryptographic module is comprised of software only and thus does not claim any physical security.
8 Operational Environment
The module runs on a GPC or Server running one of the operating systems specified in Table 1. 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.
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 9 of 18
9 Cryptographic Algorithms & Key Management
9.1 Approved Cryptographic Algorithms
The module implements the following FIPS 140-2 Approved algorithms:
Table 7 - Approved Algorithms and CAVP Certificates
CAVP
Cert. #
Algorithm Standard Mode/Method/Size Use
A5181 AES FIPS 197
SP 800-38A
128, 192, 256 CBC, ECB, CTR Encryption, Decryption
A5181 AES SP 800-38C 128 CCM Authenticated Encryption,
Authenticated Decryption
A5181 AES SP 800-38D 128, 192, 256 GCM/GMAC Authenticated Encryption,
Authenticated Decryption
A5181 CVL SP 800-135rev1 TLS 1.0/1.1 and 1.2 KDF1
Key Derivation
A5181 DRBG SP 800-90Arev1 AES-256 CTR_DRBG Random Bit Generation
A5181 ECDSA FIPS 186-4 Signature Generation Component,
Key Pair Generation,
Signature Generation,
Signature Verification,
Public Key Validation
P-224, P-256, P-384, P-521
Digital Signature Services
A5181 HMAC FIPS 198-1 HMAC-SHA-1, HMAC-SHA-224,
HMAC-SHA-256, HMAC-SHA-384,
HMAC-SHA-512
Generation, Authentication
A5181 KAS SP 800-56rev3
SP 800-135rev1
EC Diffie-Hellman P-224, P-256, P-384, P-521
Diffie-Hellman FB, FC
with TLS 1.0/1.1 or 1.2 KDF
Key Agreement Scheme per
SP 800-56Arev3 with Key
Derivation per SP 800-135
A5181 KAS-SSC SP 800-56rev3 EC Diffie-Hellman P-224, P-256, P-384, P-521
Diffie-Hellman FB, FC
Key Agreement Scheme Shared
Secret Computation (KAS-SSC)
per SP 800-56Arev3
A5181 KTS SP 800-38F 128, 192, 256 KW, KWP Key Wrapping, Key Unwrapping
A5181 RSA FIPS 186-4 Key Generation2
,
Signature Generation,
Signature Verification
(1024, 2048, 3072, 4096-bit)3
Digital Signature Services
A5181 SHS FIPS 180-4 SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
and SHA-512/256
Digital Signature Generation,
Digital Signature Verification,
non-Digital Signature
Applications
A5181 Triple-DES SP 800-67
SP 800-38A
Three Key TCBC, TECB
(provides 112 bits of security strength)
Encryption4
, Decryption
1
The module supports FIPS 140-2 approved/allowed cryptographic algorithms for TLS 1.0, 1.1 and 1.2.
2
SHA-1 shall only be utilized for digital signature and general hashing operations.
3
1024 Key Size is only used for Signature Verification.
4
After December 31st
, 2023, three-key TDEA is disallowed for encryption unless specifically allowed by other NIST guidance.
Decryption using three-key TDEA is allowed for legacy use.
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 10 of 18
9.2 Allowed Cryptographic Algorithms
The module supports the following non-FIPS 140-2 Approved but allowed algorithms that may be used in the
Approved mode of operation.
Table 8 - Allowed Algorithms
Algorithm Use
RSA Key Transport Key establishment methodology using PKCS#1-v1.5 per section 8.1 of RFC 2313 provides between
112 and 256 bits of encryption strength
MD5
(No Security Claimed)
When used with the TLS protocol version 1.0 and 1.1
9.3 Non-Approved Cryptographic Algorithms
The module employs the methods listed in Table 9, which are not allowed for use in a FIPS-Approved mode. Their
use will result in the module operating in a non-Approved mode.
Table 9 - Non-Approved Algorithms
Algorithm
MD5, MD4 AES-GCM (non-compliant) DES
POLYVAL AES (non-compliant) Triple-DES (non-compliant)
GHASH (non-compliant) RSA (non-compliant) ECDSA (non-compliant)
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 11 of 18
9.4 Cryptographic Key Management
The table below provides a complete list of Private Keys and CSPs used by the module:
Table 10 - Keys and CSPs Supported
Key/CSP Name Key Description Generated/Input Output
AES Key AES (128/192/256)
encrypt/decrypt key
Input via API in plaintext Output via API in plaintext
AES-GCM Key AES (128/192/256)
encrypt/decrypt/generate/verify
key
Input via API in plaintext Output via API in plaintext
AES Wrapping Key AES (128/192/256) key wrapping
key
Input via API in plaintext Output via API in plaintext
Triple-DES Key Triple-DES (3-Key) encrypt/decrypt
key
Input via API in plaintext Output via API in plaintext
ECDSA Signing Key ECDSA (P-224/P-256/P-384/P-521)
signature generation key
Internally generated or
input via API in plaintext
Output via API in plaintext
EC DH Private Key EC DH (P-224/P-256/P-384/P-521)
private key
Internally generated or
input via API in plaintext
Output via API in plaintext
HMAC Key Keyed hash key
(160/224/256/384/512)
Input via API in plaintext Output via API in plaintext
RSA Key (Key Transport) RSA (2048 to 16384 bits) key
decryption (private key transport)
key
Internally generated or
input via API in plaintext
Output via API in plaintext
RSA Signature Generation
Key
RSA (2048 to 16384 bits) signature
generation key
Internally generated or
input via API in plaintext
Output via API in plaintext
TLS Pre-Master Secret Shared Secret; 48 bytes of
pseudorandom data
Internally Generated Output via API in plaintext
TLS Master Secret Shared Secret; 48 bytes of
pseudorandom data
Internally derived via key
derivation function defined
in SP 800-135 KDF (TLS)
Output via API in plaintext
CTR_DRBG V (Seed) 128 bits Internally generated Does not exit the module
CTR_DRBG Key 256 bits Internally generated Does not exit the module
CTR_DRBG Entropy Input 384 bits Input via API in plaintext Does not exit the module
9.5 Public Keys
The table below provides a complete list of the Public keys used by the module:
Table 11 - Public Keys Supported
Public Key Name Key Description
ECDSA Verification Key ECDSA (P-224/P-256/P-384/P-521) signature verification key
EC DH Public Key EC DH (P-224/P-256/P-384/P-521) public key
RSA Key (Key Transport) RSA (2048 to 16384 bits) key encryption (public key transport) key
RSA Signature Verification
Key
RSA (1024 to 16384 bits) signature verification public key
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 12 of 18
9.6 Key Generation
The module supports generation of ECDSA, EC Diffie-Hellman and RSA key pairs as specified in Section 5 of NIST
SP 800-133. The module employs a NIST SP 800-90A random bit generator for creation of the seed for asymmetric
key generation. The module receives entropy passively, and a minimum of 112 bits of entropy must be supplied.
The output data path is provided by the data interfaces and is logically disconnected from processes performing
key generation or zeroization. No key information will be output through the data output interface when the
module zeroizes keys.
9.7 Key Storage
The cryptographic module does not perform persistent storage of keys. Keys and CSPs are passed to the module
by the calling application. The keys and CSPs are stored in memory in plaintext. Keys and CSPs residing in internally
allocated data structures (during the lifetime of an API call) can only be accessed using the module defined API.
The operating system protects memory and process space from unauthorized access.
9.8 Key Zeroization
The module is passed keys as part of a function call from a calling application and does not store keys persistently.
The calling application is responsible for parameters passed in and out of the module. The Operating System and
the calling application are responsible to clean up temporary or ephemeral keys.
All CSPs can be zeroized by power cycling or by rebooting the host test platform.
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 13 of 18
10 Self-Tests
FIPS 140-2 requires the module to perform self-tests to ensure the integrity of the module and the correctness of
the cryptographic functionality at start up. Some functions require conditional tests during normal operation of
the module. The supported tests are listed and described in this section.
10.1 Power-On Self-Tests
Power-on self-tests are run upon the initialization of the module and do not require operator intervention to run.
If any of the tests fail, the module will not initialize. The module will enter an error state and no services can be
accessed.
The module implements the following power-on self-tests:
Table 12 - Power-On Self-Tests
Type Test
Integrity Test HMAC-SHA-256
Known Answer
Test
AES KAT (encryption and decryption. Key size: 128-bits)
AES-GCM KAT (encryption and decryption. Key size: 128-bits)
Triple-DES KAT (encryption and decryption. Key size: 168-bits)
ECDSA KAT (signature generation/signature verification. Curve: P-256)
HMAC KAT (HMAC-SHA-1, HMAC-SHA-512)
SP 800-90A CTR_DRBG KAT (Key size: 256-bits)
RSA KAT (signature generation/signature verification and encryption/decryption. Key size: 2048-bit)
TLS v1.2 KDF KAT
Primitive “Z” Computation KAT
KAS-ECC KAT (Curve: P-256)
KAS-FFC KAT (2048-bit)
SHA KAT (SHA-1, SHA-256, SHA-512)
By default, all power up self-tests are executed at module initialization. The module can be configured to only run
the integrity test on subsequent instantiations by setting the environmental variable
BORINGSSL_FIPS_SELF_TEST_FLAG_FILE, as allowed by FIPS 140-2 IG 9.11. If configured, after the self-tests have
passed, the module creates a temporary file named after the module’s HMAC-SHA-256 integrity value (this value
does not persist across power cycles). This file is checked for existence whenever subsequent instantiations of the
module are initialized. If it exists, only the integrity test is run. If the environmental variable is not set, the file does
not exist, or the file cannot be accessed for any reason, the entire set of power-on self-tests (KATs and integrity
test) are run. The power-on self-tests must be passed before a User/Crypto Officer can perform services. The
Power-on self-tests can be run on demand by power-cycling the host platform.
10.2 Conditional Self-Tests
Conditional self-tests are run during operation of the module. If any of these tests fail, the module will enter an
error state, where no services can be accessed by the operators. The module can be reinitialized to clear the error
and resume FIPS mode of operation. Each module performs the following conditional self-tests:
Table 13 - Conditional Self-Tests
Type Test
Pair-wise Consistency Test ECDSA Key Pair generation, RSA Key Pair generation
DRBG Health Tests Performed on DRBG, per SP 800‐90A Section 11.3. Required per IG C.1. Also includes a
continuous test.
Pairwise consistency tests are performed for both possible modes of use, e.g. Sign/Verify and Encrypt/Decrypt.
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 14 of 18
11 Mitigation of Other Attacks
The module is not designed to mitigate against attacks which are outside of the scope of FIPS 140-2.
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 15 of 18
12 Guidance and Secure Operation
12.1 Installation Instructions
The following steps shall be performed to build, compile and statically link the Module to BoringSSL on the tested
Operational Environments.
The below tools are required in order to build and compile the module:
• Clang compiler version 12.0.0 (http://releases.llvm.org/download.html)
• Go programming language version 1.16.5 (https://golang.org/dl/)
• Ninja build system version 1.10.2 (https://github.com/ninja-build/ninja/releases)
• CMake version 3.20.1 (https://cmake.org/download/)
Once the above tools have been obtained, issue the following command to create a CMake toolchain file to specify
the use of Clang:
• printf "set(CMAKE_C_COMPILER \"clang\")\nset(CMAKE_CXX_COMPILER \"clang++\")\n" >
${HOME}/toolchain
The FIPS 140-2 validated release of the module can be obtained by downloading the tarball containing the source
code at the following location:
https://commondatastorage.googleapis.com/chromium-boringssl-
fips/boringssl853ca1ea1168dff08011e5d42d94609cc0ca2e27.tar.xz
or by issuing the following command:
wget https://commondatastorage.googleapis.com/chromium-boringssl-
fips/boringssl853ca1ea1168dff08011e5d42d94609cc0ca2e27.tar.xz
The set of files specified in the archive constitutes the complete set of source files of the validated module. There
shall be no additions, deletions, or alterations of this set as used during module build.
The downloaded tarball file can be verified using the below SHA-256 digest value:
a4d069ccef6f3c7bc0c68de82b91414f05cb817494cd1ab483dcf3368883c7c2
By issuing the following command:
• sha256sum boringssl-853ca1ea1168dff08011e5d42d94609cc0ca2e27.tar.xz
After the tarball has been extracted, the following commands will compile the module:
1. cd boringssl
2. mkdir build && cd build && cmake -GNinja -DCMAKE_TOOLCHAIN_FILE=${HOME}/toolchain - DFIPS=1 -
DCMAKE_BUILD_TYPE=Release ..
3. ninja
Upon completion of the build process the compilation can be validated by running the following command and
observing that no tests fail:
• ./crypto/crypto_test
The module’s status can be verified by issuing:
• ./tool/bssl isfips
The module will print “1” if it is in a FIPS 140-2 validated mode of operation.
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 16 of 18
12.2 Secure Operation
12.2.1 Initialization
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. The
module is designed with a default entry point (DEP) which ensures that the power-up tests are initiated
automatically when the module is loaded.
12.2.2 Usage of AES OFB, CFB and CFB8
In approved mode, users of the module must not utilize AES OFB, CFB and CFB8.
12.2.3 Usage of AES-GCM
In the case of AES-GCM, the IV generation method is user selectable based on API parameters and the value can
be computed in more than one manner.
AES GCM encryption and decryption are used in the context of the TLS protocol version 1.2 (compliant to Scenario
1 in FIPS 140-2 IG A.5). 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 an 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-2 IG A.5 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 IG A.5, 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.
12.2.4 Usage of Triple-DES
In accordance with CMVP IG A.13, when operating in a FIPS approved mode of operation, the same Triple-DES key
shall not be used to encrypt more than 220
or 216
64-bit data blocks.
The TLS protocol governs the generation of the respective Triple-DES keys. Please refer to IETF RFC 5246 (TLS) for
details relevant to the generation of the individual Triple-DES encryption keys. The user is responsible for ensuring
that the module limits the number of encrypted blocks with the same key to no more than 220
when utilized as
part of a recognized IETF protocol.
For all other uses of Triple-DES, the user is responsible for ensuring that the module limits the number of
encrypted blocks with the same key to no more than 216
.
12.2.5 Usage of RSA and ECDSA
The module allows the use of 1024 bits RSA keys for legacy purposes including signature generation, which is
disallowed to be used in FIPS Approved mode as per NIST SP 800-131A. Therefore, the cryptographic operations
with the non-approved key sizes will result in the module operating in non-Approved mode implicitly.
The elliptic curves utilized shall be the validated NIST-recommended curves and shall provide a minimum of 112
bits of encryption strength.
SHA-1 shall only be utilized for digital signature verification and non-digital signature applications per NIST SP 800-
131Ar2.
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.
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 17 of 18
13 References and Standards
The following Standards are referred to in this Security Policy.
Table 14 - References and Standards
Abbreviation Full Specification Name
FIPS 140-2 Security Requirements for Cryptographic modules, May 25 2001
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-2 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-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-56Ar3 Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography
SP 800-67 Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher
SP 800-90A Recommendation for Random Number Generation Using Deterministic Random Bit Generators
SP 800-131Ar2 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
14 Acronyms and Definitions
Table 15 - Acronyms and Definitions
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 Cryptographic Module Validation Program
CO Cryptographic Officer
CPU Central Processing Unit
CSP Critical Security Parameter
CTR Counter-mode
CVL Component Validation List
DEP Default Entry Point
DES Data Encryption Standard
DH Diffie-Hellman
DRBG Deterministic Random Number Generator
DSS Digital Signature Standard
EC Elliptic Curve
ECB Electronic Code Book
FIPS 140-2 Security Policy SUSE Rancher Kubernetes Cryptographic Library
Page 18 of 18
Acronym Definition
ECC Elliptic Curve Cryptography
EC DH Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
EMC Electromagnetic Compatibility
EMI Electromagnetic Interference
FCC Federal Communications Commission
FIPS Federal Information Processing Standard
GCM Galois/Counter Mode
GMAC Galois Message Authentication Code
GPC General Purpose Computer
GPOS General Purpose Operating System
HMAC Keyed-Hash Message Authentication Code
IETF Internet Engineering Task Force
IG Implementation Guidance
IV Initialization Vector
KAS Key Agreement Scheme
KAT Known Answer Test
KDF Key Derivation Function
KTS Key Transport Scheme
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
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
TCBC Triple-DES Cipher-Block Chaining
TDEA Triple Data Encryption Algorithm
TECB Triple-DES Electronic Code Book
TLS Transport Layer Security
Triple-DES Triple Data Encryption Standard