Red Hat Enterprise Linux 8 libgcrypt Cryptographic Module
version rhel8.20220426
FIPS 140-2 Non-Proprietary Security Policy
Document Version 1.2
Last update: 2023-10-24
Prepared by:
atsec information security corporation
9130 Jollyville Road, Suite 260
Austin, TX 78759
www.atsec.com
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 1 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
Table of Contents
1 Introduction ..........................................................................................................................3
2 Cryptographic Module Specification .....................................................................................4
2.1 Module Overview..........................................................................................................4
2.2 FIPS 140-2 validation....................................................................................................5
2.3 Modes of Operations.....................................................................................................7
3 Cryptographic Module Ports and Interfaces ..........................................................................8
4 Roles, Services and Authentication ......................................................................................9
4.1 Roles.............................................................................................................................9
4.2 Services........................................................................................................................9
4.3 Authentication............................................................................................................14
5 Physical Security ................................................................................................................15
6 Operational Environment ...................................................................................................16
6.1 Applicability................................................................................................................16
6.2 Policy..........................................................................................................................16
7 Cryptographic Key Management ........................................................................................17
7.1 Random Number Generation......................................................................................17
7.2 Key Establishment......................................................................................................17
7.3 Key/Critical Security Parameter (CSP).........................................................................17
7.4 Key / Critical Security Parameter (CSP) Access...........................................................18
7.5 Key / CSP Storage.......................................................................................................19
7.6 Key / CSP Zeroization..................................................................................................19
8 Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) ............................20
8.1 Statement of compliance............................................................................................20
9 Self Tests ............................................................................................................................21
9.1 Power-Up Tests............................................................................................................21
9.1.1 Integrity Tests....................................................................................................21
9.1.2 Cryptographic algorithm tests...........................................................................21
9.2 On-Demand self-tests.................................................................................................22
9.3 Conditional Tests.........................................................................................................22
10 Guidance ..........................................................................................................................23
10.1 Crypto Officer Guidance............................................................................................23
10.1.1 FIPS module installation instructions...............................................................23
10.1.1.1 Recommended method................................................................................23
10.1.1.2 Manual method............................................................................................23
10.2 User Guidance..........................................................................................................24
10.2.1 Three-key Triple-DES.......................................................................................24
10.2.2 AES-XTS Guidance...........................................................................................25
10.2.3 Key derivation using SP800-132 PBKDF...........................................................25
11 Mitigation of Other Attacks ...............................................................................................26
Appendix A Glossary and Abbreviations ................................................................................28
Appendix B References .........................................................................................................29
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 2 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
1 Introduction
This document is the non-proprietary Security Policy for the Red Hat Enterprise Linux 8
libgcrypt Cryptographic Module version rhel8.20220426. It contains the security rules under
which the module must operate and describes how this module meets the requirements as
specified in FIPS PUB 140-2 (Federal Information Processing Standards Publication 140-2) for a
Security Level 1 module.
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 3 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
2 Cryptographic Module Specification
2.1 Module Overview
The Red Hat Enterprise Linux 8 libgcrypt Cryptographic Module (hereafter referred to as “the
module”) is a software library implementing general purpose cryptographic algorithms. The
module provides cryptographic services to applications running in the user space of the
underlying operating system through an application program interface (API).
The module is implemented as a set of shared libraries / binary files; as shown in the diagram
below, the shared library files and the integrity check file used to verify the module's integrity
constitute the logical cryptographic boundary:
Figure 1: Software Block Diagram
The module is aimed to run in a general purpose computer. The physical boundary is the
surface of the case of the target platform, as shown in the diagram below:
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 4 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
libgcrypt Cryptographic Module
Boundary
Kernel
User
System Physical Boundary
FIPS 140-2 Non-Proprietary Security Policy
All components of the module will be in the libgcrypt RPM. The following RPMs files constitute
the module:
• Red Hat Enterprise Linux 8 libgcrypt Cryptographic Module: libgcrypt-1.8.5-
7.el8_6.rpm
When installed on the system, the module comprises the following files:
• /usr/lib64/libgcrypt.so.20.2.5
• /usr/lib64/.libgcrypt.so.20.hmac.
2.2 FIPS 140-2 validation
For the purpose of the FIPS 140-2 validation, the module is a software-only, multi-chip
standalone cryptographic module validated at security level 1. The table below shows the
security level claimed for each of the eleven sections that comprise the FIPS 140-2 standard:
FIPS 140-2 Section Security
Level
1 Cryptographic Module Specification 1
2 Cryptographic Module Ports and Interfaces 1
3 Roles, Services and Authentication 1
4 Finite State Model 1
5 Physical Security N/A
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 5 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
Figure 2: Hardware Block Diagram
FIPS 140-2 Non-Proprietary Security Policy
FIPS 140-2 Section Security
Level
6 Operational Environment 1
7 Cryptographic Key Management 1
8 EMI/EMC 1
9 Self Tests 1
10 Design Assurance 1
11 Mitigation of Other Attacks 1
Table 1: Security Levels
The Red Hat Enterprise Linux 8 libgcrypt Cryptographic Module has been tested on the
following multi-chip standalone platforms:
Manufacturer Model O/S & Ver. Processor
Dell PowerEdge
R440
Red Hat Enterprise
Linux 8
Intel(R) Xeon(R) Silver
4216
IBM IBM 9009-
42A
Red Hat Enterprise
Linux 8 with PowerVM
FW950.00 with VIOS
3.1.2.00
IBM POWER9
IBM IBM 9080-
HEX
Red Hat Enterprise
Linux 8 with PowerVM
FW1010.22 with VIOS
3.1.3.00
IBM POWER10
IBM IBM System
z15
Red Hat Enterprise
Linux 8
IBM z15
Table 2: Tested Platforms
NOTE: This validation is only for the tested platforms listed in Table 2 of this document. It
does not cover other derivatives of the Operating Systems (I.e, CentOS or Fedora).
The Module has been tested for the following configurations:
• 64-bit library, x86_64 with and without PAA (AES-NI) enabled
• 64-bit library, z15
• 64-bit library, POWER9 and POWER10
To operate the Module, the operating system must be restricted to a single operator mode of
operation. (This should not be confused with single user mode which is run level 1 on Red Hat
Enterprise Linux (RHEL). This refers to processes having access to the same cryptographic
instance which RHEL ensures this cannot happen by the memory management hardware.)
The following platform has not been tested as part of the FIPS 140-2 level 1 certification
however Red Hat “vendor affirms” that this platform is equivalent to the tested and validated
platform. Additionally, Red Hat affirms that the module will function the same way and
provide the same security services on any of the systems listed below.
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 6 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
Hardware Platform Processor Operating System
Dell PowerEdge R430 Intel(R) Xeon(R) E5 Red Hat Enterprise Linux 8
Table 2A: Vendor Affirmed Platforms
Per FIPS 140-2 IG G.5, 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.3 Modes of Operations
The module supports two modes of operation: FIPS approved and non-approved modes.
The module turns to the FIPS approved mode after the initialization and the power-on self-
tests have completed successfully.
When libgcrypt is in the FIPS mode of operation, the request of services involving non-FIPS
approved algorithms will be denied. However, the module does not check for approved key
sizes or approved mode of algorithms.
The Approved services available in FIPS mode can be found in section 4.2, Table 4.
The non-Approved but allowed services available in FIPS mode can be found in section 4.2,
Table 5.
The non-Approved and not allowed1
services available in non-FIPS mode can be found in
section 4.2, Table 6.
1 Note: Using a non-Approved key sizes, algorithms or block chaining mode specified in Table
6 will result in the module implicitly entering the non-FIPS mode of operation.
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 7 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
3 Cryptographic Module Ports and Interfaces
As a software-only module, the module does not have physical ports. For the purpose of the
FIPS 140-2 validation, the physical ports are interpreted to be the physical ports of the
hardware platform on which it runs.
The logical interfaces are the application program interface (API) through which applications
request services. The following table summarizes the four logical interfaces:
Logical interface Description
Data input API input parameters for data
Data output API output parameters for data
Control input API function calls, API input parameters,
/proc/sys/crypto/fips_enabled control file
Status output API return codes, API output parameters
Table 3: Logical 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 API function calls and the input parameters used to control the
behavior of the module. The Status Output interface includes the return values of the API
functions and status sent through output parameters.
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 8 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
4 Roles, Services and Authentication
4.1 Roles
The module supports the following roles:
⚫ User role: performs all services, except module installation and configuration.
⚫ Crypto Officer role: performs module installation and configuration and some basic
functions: get status function and performing self-tests.
The User and Crypto Officer roles are implicitly assumed by the entity accessing the module
services.
4.2 Services
The module supports services available to users in the available roles. All services are
described in detail in the user documentation.
The following table shows the available services, the roles allowed (“CO” stands for Crypto
Officer role and “U” stands for User role), the Critical Security Parameters involved and how
they are accessed in the FIPS mode:
Service Algorithm Key
Length
Note / Mode ACVP
Cert.
Role CSPs Access
Symmetric
encryption/
decryption
Triple-DES 168 bits Modes: ECB,
CBC,
CFB8,CFB64,
OFB, CTR,
CMAC
3-key Triple-
DES
encryption/
decryption
Cert.
#A1809
U 168 bits Triple-
DES Key
R, EX
AES 128, 192
and 256
bits
Modes: ECB,
CBC, CFB8,
CFB128, OFB,
CTR, KW,
CCM, CMAC
Cert.
#A1806
#A1807
#A1809
#A1810
U 128/192/256
bits AES Key
R, EX
128 and
256 bits
Mode: XTS Cert.
#A1806
#A1807
#A1809
#A1810
U 128/256 bits
AES Key
R, EX
Get Key
Length
N/A N/A gcry_cipher_
algo_info()
N/A U N/A N/A
Get Block
Length
N/A N/A gcry_cipher_
algo_info()
N/A U N/A N/A
Check
algorithm
availability
N/A N/A gcry_cipher_i
nfo()
N/A U N/A N/A
Secure Hash
Algorithm
(SHS)
SHA-12
,
SHA-224,
SHA-256,
N/A N/A Cert.
#A1806
#A1807
#A1808
U N/A N/A
2 SHA-1 is used in the approved mode for secure hash algorithm, HMAC, DSA Signature
Verification, PBKDF key derivation, Hash DRBG and HMAC DRBG only.
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 9 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
Service Algorithm Key
Length
Note / Mode ACVP
Cert.
Role CSPs Access
SHA-384,
SHA-512
#A1809
#A1810
Secure Hash
Algorithm
(SHA-3)
SHA3-224,
SHA3-256,
SHA3-384,
SHA3-512,
SHAKE-128,
SHAKE-256
#A1808
#A1809
#A1810
HMAC HMAC-SHA-
1, HMAC-
SHA-224,
HMAC-SHA-
256, HMAC-
SHA-384,
HMAC-SHA-
512,
At least
112 bits
KS<BS,
KS=BS,
KS>BS
N/A Cert.
#A1806
#A1807
#A1808
#A1809
#A1810
U MAC key R, EX
HMAC-
SHA3-224,
HMAC-
SHA3-256,
HMAC-
SHA3-384,
HMAC-
SHA3-512
#A1808
#A1809
#A1810
Key pair
generation
RSA 2048,3072,
4096 bits
modulus
FIPS 186-4
RSASSA-PKCS
#1.5
RSASSA-PSS
Cert.
#A1806
#A1807
#A1808
#A1809
#A1810
U RSA private key R, W, EX
ECDSA P-256,
P-384,
P-521
FIPS 186-4 Cert.
#A1806
#A1807
#A1808
#A1809
#A1810
U ECDSA private
key
R, W, EX
DSA L=2048,
N=224;
L=2048,
N=256;
L=3072,
N=256;
FIPS 186-4 Cert.
#A1806
#A1807
#A1808
#A1809
#A1810
U DSA private key R, W, EX
Signature
generation
RSA 2048,3072,
4096 bits
modulus
SHA-224,
SHA-256,
FIPS 186-4
RSASSA-PKCS
#1.5
RSASSA-PSS
Cert.
#A1806
#A1807
#A1808
#A1809
U RSA private key R, EX
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 10 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
Service Algorithm Key
Length
Note / Mode ACVP
Cert.
Role CSPs Access
SHA-384,
SHA-512
#A1810
ECDSA P-224,
P-256,
P-384,
P-521
SHA-224,
SHA-256,
SHA-384,
SHA-512
FIPS 186-4 Cert.
#A1806
#A1807
#A1808
#A1809
#A1810
U ECDSA private
key
R, EX
DSA L=2048,
N=224,
SHA-1;
L=2048,
N=256,
SHA-224,
SHA-256;
L=3072,
N=256,
SHA-224,
SHA-256
FIPS 186-4 Cert.
#A1806
#A1807
#A1808
#A1809
#A1810
U DSA private key R, EX
Signature
verification
RSA 2048,
3072, 4096
bits
modulus
SHA-224,
SHA-256,
SHA- 384,
SHA-512
FIPS 186-4
RSASSA-PKCS
#1.5
RSASSA-PSS
Cert.
#A1806
#A1807
#A1808
#A1809
#A1810
U RSA public key R, EX
ECDSA P-224,
P-256,
P-384,
P-521
SHA-1,
SHA-224,
SHA-256,
SHA- 384,
SHA-512
FIPS 186-4 Cert.
#A1806
#A1807
#A1808
#A1809
#A1810
U ECDSA public
key
R, EX
DSA L=1024,
N=160,
SHA-1;
L=2048,
N=224,
SHA-1;
L=2048,
N=256,
SHA-224,
SHA-256;
L=3072,
N=256,
SHA-1
FIPS 186-4 Cert.
#A1806
#A1807
#A1808
#A1809
#A1810
U DSA public key R, EX
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 11 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
Service Algorithm Key
Length
Note / Mode ACVP
Cert.
Role CSPs Access
L=3072,
N=256,
SHA-224,
SHA-256;
Domain
Parameter
Generation
DSA
PQGGen
L=2048,
N=224,
SHA-224;
L=2048,
N=256,
SHA-256;
L=3072,
N=256,
SHA-256
FIPS 186-4 Cert.
#A1806
#A1807
#A1808
#A1809
#A1810
U N/A N/A
Domain
Parameter
Verification
DSA PQGVer L=2048,
N=224,
SHA-224;
L=2048,
N=256,
SHA-256;
L=3072,
N=256,
SHA-256
FIPS 186-4 Cert.
#A1806
#A1807
#A1808
#A1809
#A1810
U N/A N/A
Key Pair
verification
ECDSA P-256,
P-384,
P-521
FIPS 186-4 Cert.
#A1806
#A1807
#A1808
#A1809
#A1810
U ECDSA private
key
R, EX
Key derivation PBKDF SHA-1,
SHA2-224,
SHA2-256,
SHA2-384,
SHA2-512,
SHA3-224,
SHA3-256,
SHA3-384,
SHA3-512
SP 800-132 Cert.
#A1806
#A1807
#A1808
#A1809
#A1810
U PBKDF Derived
key
PBKDF Password
R, W, EX
Random
number
generation
SP 800-90A
DRBG:
HMAC_DRB
G with SHA-
1/256/512
HASH_DRBG
with SHA-
1/256/512
(with and
without
prediction
resistance)
N/A Fill buffer
with length
random
bytes,
function to
allocate a
memory
block
consisting of
nbytes of
random
bytes,
function to
allocate a
memory
block
consisting of
nbytes fresh
random
bytes using a
random
Cert.
#A1806
#A1807
#A1808
#A1809
#A1810
U Seed, internal
state values and
entropy input
W, R, EX
SP 800-90A
DRBG:
CTR_DRBG
with
derivation
function
AES
Cert.
#A1806
#A1807
#A1809
#A1810
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 12 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
Service Algorithm Key
Length
Note / Mode ACVP
Cert.
Role CSPs Access
128/192/25
6 (with and
without
prediction
resistance)
quality as
defined by
level. This
function
differs from
gcry_randomi
ze() in that
the returned
buffer is
allocated in a
“secure" area
of the
memory
KTS AES 128, 192
and 256
bits
AES-KW Certs.
#A1806,
#A1807,
#A1809
and
#A1810
U 128/192/256
bits AES Key
R, EX
ENT(NP) N/A N/A N/A N/A U N/A N/A
Module
initialization
N/A N/A Powering-up
the module
N/A U N/A N/A
Self-tests N/A N/A Performs
Known
Answer Test
(KAT) and
integrity
check
N/A U N/A N/A
Secure
memory
zeroization
N/A N/A gcry_free() or
gcry_xfree()
functions
N/A U All CSPs stored
in that secure
memory
W, EX
Release all
resources of
context
created by
gcry_cipher_o
pen()
N/A N/A Zeroises all
sensitive
information
associated
with this
cipher handle
N/A U Cipher secret
key
W, EX
Release all
resources of
hash context
created by
gcry_md_open
()
N/A N/A Zeroises all
sensitive
information
associated
with this
hash/md
handle
N/A U N/A N/A
Release the S-
expression
objects SEXP
N/A N/A N/A N/A U RSA/DSA/ECDSA
asymmetric key
pair
R, W, EX
Show Status N/A N/A N/A N/A U N/A N/A
Installation
and
configuration
of the module
N/A N/A N/A N/A CO N/A N/A
Table 4: Cryptographic Module's Approved Services
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 13 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
Service
(involving
algorithm)
Note / Mode Role CSPs Acces
s
RSA
PKCS#v1.5
Encryption/decryption with keys greater than or equal to
2048 bits (key wrapping; key establishment methodology
provides between 112 and 256 bits of encryption strength).
U RSA
Private
Key
R, EX
Table 5: Cryptographic Module's non-Approved but allowed in FIPS mode Services
The following table shows the available services, the roles allowed, the Critical Security
Parameters involved and how they are accessed in the non-FIPS mode:
Service
(involving
algorithm)
Note / Mode Role
Symmetric
encryption/decry
ption
ARC4, Blake2, Blowfish, Camellia, Cast5, ChaCha20, DES, IDEA,
RC2, SEED, Serpent, Twofish, 2-key Triple-DES, Salsa20, GOST
(28147)
U
Cyclic
redundancy code
CRC32 U
Random number
generation
Cryptographically Secure Pseudorandom Number Generator
(CSPRNG)
U
Asymmetric key
pair generation
El Gamal U
RSA (keys < 2048 bits) U
EdDSA U
Asymmetric
encryption/decry
ption
El Gamal, RSA (with keys < 2048 bits) U
Signature
generation
RSA (keys < 2048 bits), El Gamal, EdDSA. U
RSA with SHA-1. U
Signature
verification
RSA (keys < 2048 bits), El Gamal, EdDSA. U
RSA with SHA-1. U
MAC HMAC (Key size < 112 bits), Poly1305 U
Message digest MD4, MD5, RIPEMD160, TIGER, Whirlpool, GOST (R 34.11-94, R
34.11-2012 (Stribog))
U
Key derivation Scrypt KDF, OpenPGP S2K Salted and Iterated/salted (Password
based key derivation compliant with OpenPGP (RFC4880))
U
Key
Establishment
RSA (KTS_IFC)3
U
Table 6: Cryptographic Module's non-Approved Services and Algorithms
3 The RSA (KTS-IFC) is CAVP tested with Certs.#A1806, #A1807, #A1808, #A1809 and #A1810, but the KAT is not
implemented so it is marked non-approved.
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 14 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
4.3 Authentication
The module is a Level 1 software-only cryptographic module and does not implement
authentication. The role is implicitly assumed based on the service requested.
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 15 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
5 Physical Security
The module is comprised of software only and thus does not claim any physical security.
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 16 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
6 Operational Environment
6.1 Applicability
The module operates in a modifiable operational environment per FIPS 140-2
level 1 specifications. The module runs on a commercially available general-
purpose operating system executing on the hardware specified in section 2.2.
The Red Hat Enterprise Linux operating system is used as the basis of other products which
include but are not limited to:
• Red Hat Enterprise Linux CoreOS
• Red Hat Virtualization (RHV)
• Red Hat OpenStack Platform
• OpenShift Container Platform
• Red Hat Gluster Storage
• Red Hat Ceph Storage
• Red Hat CloudForms
• Red Hat Satellite.
Compliance is maintained for these products whenever the binary is found
unchanged.
6.2 Policy
The operating system is restricted to a single operator (concurrent operators are explicitly
excluded). The application that request cryptographic services is the single user of the
module, even when the application is serving multiple clients.
In FIPS Approved mode, the ptrace(2) system call, the debugger (gdb(1)), and strace(1) shall
be not used.
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 17 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
7 Cryptographic Key Management
7.1 Random Number Generation
The Module provides an SP800-90Arev1 compliant Deterministic Random Bit Generator
(DRBG) for creation of key components of asymmetric keys, and random number generation.
The seeding (and automatic reseeding) of the DRBG is done with getrandom().
The module employs the Deterministic Random Bit Generator (DRBG) based on [SP800-
90Arev1] for the random number generation. The module supports the Hash_DRBG,
HMAC_DRBG and CTR_DRBG mechanisms. The module uses CPU jitter as a noise source
provided by the operational environment which is within the module’s physical boundary but
outside of the module’s logical boundary. The source is compliant with [SP 800-90B] and
marked as ENT (NP) on the certificate. The module collects 384 bits of entropy from the
kernel CPU Jitter source, which is provided to an HMAC_DRBG in the kernel, which preserves
the 384-bits of entropy upon output. However, the kernel HMAC_DRBG conditioning
component does not implement prediction resistance. Therefore the caveat, “The module
generates cryptographic keys whose strengths are modified by available entropy” applies.
The Key Generation methods implemented in the module for Approved services in FIPS mode
is compliant with [SP800-133rev2].
For generating RSA, DSA and ECDSA keys the module implements asymmetric key generation
services compliant with [FIPS186-4]. A seed (i.e. the random value) used in asymmetric key
generation is directly obtained from the [SP800-90Arev1] DRBG.
7.2 Key Establishment
The module provides RSA key wrapping (encapsulation) using public key encryption and
private key decryption primitives as allowed by [FIPS140-2_IG] D.9.
RSA provides the following security strengths:
• RSA PKCS#v1.5: key wrapping provides between 112 and 256 bits of encryption
strength.
The module provides approved key transport methods compliant to SP 800-38F according to
IG D.9. The key transport method is provided by AES-KW.
Therefore, the following caveats apply:
◦ KTS (AES Certs. #A1806, #A1807, #A1809 and #A1810; key establishment
methodology provides between 128 and 256 bits of encryption strength)
The module also supports password-based key derivation (PBKDF). The implementation is
compliant with option 1a of [SP 800-132]. Keys derived from passwords or passphrases using
this method can only be used in storage applications.
7.3 Key/Critical Security Parameter (CSP)
Listed below are the CSPs/keys details concerning storage, input, output, generation and
zeroization:
Keys/CSPs Key Generation Key Storage Key Entry/Output Key Zeroization
AES Keys N/A Application's
memory
API input/output
parameters and return
values within the
Automatically
zeroized when
freeing the cipher
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 18 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
physical boundaries of
the module
handler by calling
gcry_free()
Triple-DES
Keys
N/A Application's
memory
API input/output
parameters and return
values within the
physical boundaries of
the module
Automatically
zeroized when
freeing the cipher
handler by calling
gcry_free()
DSA private
keys
Use of the module's
SP 800-90A DRBG
and generated using
FIPS 186-4 key
generation method
Application's
memory
API input/output
parameters and return
values within the
physical boundaries of
the module
Automatically
zeroized when
freeing the cipher
handler by calling
gcry_free()
ECDSA
private keys
Use of the module's
SP 800-90A DRBG
and generated using
FIPS 186-4 key
generation method
Application's
memory
API input/output
parameters and return
values within the
physical boundaries of
the module
Automatically
zeroized when
freeing the cipher
handler by calling
gcry_ecc_curve_free()
RSA private
keys
Use of the module's
SP 800-90A DRBG
and generated using
FIPS 186-4 key
generation method
Application's
memory
API input/output
parameters and return
values within the
physical boundaries of
the module
Automatically
zeroized when
freeing the cipher
handler by calling
gcry_free()
SP 800-90A
DRBG
Entropy
string
The seed data
obtained from
getrandom()
Application's
memory
N/A Automatically
zeroized when
freeing DRBG handler
by calling gcry_free()
SP 800-90A
DRBG Seed
and internal
state values
(C, K and V
values)
Based on entropy
string as defined in
SP 800-90A
Application's
memory
N/A Automatically
zeroized when
freeing DRBG handler
by calling gcry_free()
HMAC Keys N/A Application's
memory
API input/output
parameters and return
values within the
physical boundaries of
the module
Automatically
zeroized when
freeing the cipher
handler by calling
gcry_free()
PBKDF
Derived Key
SP800-132 PBKDF
mechanisms
Application's
memory
API output parameters
and return values
within the physical
boundaries of the
module
Automatically
zeroized when
freeing the cipher
handler by calling
gcry_free()
PBKDF
Password
N/A Application's
memory
API input parameters
and return values
within the physical
boundaries of the
module
Automatically
zeroized when
freeing the cipher
handler by calling
gcry_free()
Table 7: Keys/CSPs
7.4 Key / Critical Security Parameter (CSP) Access
An authorized application as user (the User role) has access to all key data generated during
the operation of the module. Moreover, the module does not support the output of
intermediate key generation values during the key generation process.
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 19 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
7.5 Key / CSP Storage
Public and private keys are provided to the module by the calling process, and are destroyed
when released by the appropriate API function calls. The module does not perform persistent
storage of keys.
7.6 Key / CSP Zeroization
The application that uses the module is responsible for appropriate destruction and
zeroization of the key material. The library provides functions for key allocation and
destruction, which overwrites the memory that is occupied by the key information with
“zeros” before it is deallocated.
The memory occupied by keys is allocated by regular memory allocation operating system
calls. The application is responsible for calling the appropriate destruction functions provided
in the module's API by using the API function gcry_free(). The destruction functions overwrite
the memory occupied by keys with “zeros” and deallocates 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.
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 20 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
8 Electromagnetic Interference/Electromagnetic
Compatibility (EMI/EMC)
MARKETING NAME......................…. PowerEdge R440
REGULATORY MODEL................….. E45S
REGULATORY TYPE.....................…. E45S001
EFFECTIVE DATE..........................… March 01, 2020
EMC EMISSIONS CLASS...............… Class A
MARKETING NAME......................…. IBM z15
REGULATORY MODEL................….. z15
EFFECTIVE DATE..........................… August 21, 2019
EMC EMISSIONS CLASS...............… Class A
MARKETING NAME......................…. IBM Power System
REGULATORY MODEL................….. 9009-42A
EFFECTIVE DATE..........................… June 26, 2020
EMC EMISSIONS CLASS...............… Class A
MARKETING NAME......................…. IBM Power System
REGULATORY MODEL................….. 9080-HEX
EFFECTIVE DATE..........................… October 13, 2021
EMC EMISSIONS CLASS...............… Class A
8.1 Statement of compliance
This product has been determined to be compliant with the applicable standards, regulations,
and directives for the countries where the product is marketed. The product is affixed with
regulatory marking and text as necessary for the country/agency. The validation
environments meet the requirements of 47 CFR FCC PART 15, Subpart B, Class A (Business
use).
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 21 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
9 Self Tests
9.1 Power-Up Tests
The module performs power-up tests at module initialization to ensure that the module is not
corrupted and that the cryptographic algorithms work as expected. The self-tests are
performed without any user intervention.
While the module is performing the power-up tests, services are not available and input or
output is not possible: the module is single-threaded and will not return to the calling
application until the self-tests are completed successfully.
9.1.1 Integrity Tests
The integrity of the module is verified comparing the HMAC-SHA-256 value calculated at run
time with the HMAC value stored in the module that was computed at build time.
9.1.2 Cryptographic algorithm tests
The module performs self-tests on all FIPS-Approved cryptographic algorithms supported in
the approved mode of operation, using the known answer tests (KAT) shown in the following
table:
Algorithm Tests
Triple-DES ECB KAT, encryption and decryption tested separately
Triple-DES-CMAC KAT
AES-CMAC KAT
AES 128 ECB KAT, encryption and decryption tested separately
AES 192 ECB KAT, encryption and decryption tested separately
AES 256 ECB KAT, encryption and decryption tested separately
SHA-1 KAT
SHA-224 KAT
SHA-256 KAT
SHA-384 KAT
SHA-512 KAT
HMAC SHA-1 KAT
HMAC SHA-224 KAT
HMAC SHA-256 KAT
HMAC SHA-384 KAT
HMAC SHA-512 KAT
HMAC-SHA3-224 KAT
HMAC-SHA3-256 KAT
HMAC-SHA3-384 KAT
HMAC-SHA3-512 KAT
DRBG (Hash, HMAC and
CTR-based)
KAT
RSA KAT of signature generation/verification with key size of 2048
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 22 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
Algorithm Tests
DSA KAT of signature generation/verification with L=2048, N=2224 and SHA-
224
ECDSA KAT of signature generation/verification with P-256 curve and SHA-256
PBKDF KAT with SHA-256
Module Integrity test HMAC SHA-256
Table 8: Self-tests
9.2 On-Demand self-tests
The module provides the Self-Test service to perform self-tests on demand. This service
performs the same cryptographic algorithm tests executed during power-up, plus some
extended self-tests, such as testing additional block chaining modes. During the execution of
the on-demand self-tests, services are not available and no data output or input is possible.
To invoke the on-demand self-tests, the user can invoke the gcry_control(GCRYCTL_SELFTEST)
command.
9.3 Conditional Tests
The module only performs conditional tests when asymmetric key pairs are generated:
Algorithm Test
RSA The test will generate a random plaintext, sign it, modify the signature by
incrementing its value by 1, and verify that the signature verification fails.
(cipher/rsa.c:test_keys())
DSA The test uses a random number of the size of the q parameter to create a
signature and then checks that the signature verification is successful. As
a second signing test, the data is modified by incrementing its value and
then is verified against the signature with the expected result that the
verification fails. (cipher/dsa.c:test_keys())
ECDSA The test uses a random number of the size of the nbits parameter to
create a signature and then checks that the signature verification is
successful. As a second signing test, the data is modified by incrementing
its value and then is verified against the signature with the expected result
that the verification fails. (cipher/ecc.c:test_keys())
Table 9: Conditional Tests
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 23 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
10 Guidance
The following guidance items are to be used for assistance in maintaining the module's
validated status while in use.
10.1 Crypto Officer Guidance
The version of the RPMs containing the FIPS validated Module is stated in section 1 above.
The RPM package of the Module can be installed by standard tools recommended for the
installation of RPM packages on a Red Hat Enterprise Linux system (for example, dnf, rpm,
and the RHN remote management tool).
The ciphers listed in Table 6 are not allowed to be used.
10.1.1 FIPS module installation instructions
10.1.1.1 Recommended method
The system-wide cryptographic policies package (crypto-policies) contains a tool that
completes the installation of cryptographic modules and enables self-checks in accordance
with the requirements of Federal Information Processing Standard (FIPS) Publication 140-2.
We call this step “FIPS enablement”. The tool named fips-mode-setup installs and enables or
disables all the validated FIPS modules and it is the recommended method to install and
configure a RHEL-8 system.
1. To switch the system to FIPS eablement in RHEL 8:
# fips-mode-setup --enable
Setting system policy to FIPS
FIPS mode will be enabled.
Please reboot the system for the setting to take effect.
2. Restart your system:
# reboot
3. After the restart, you can check the current state:
# fips-mode-setup --check
FIPS mode is enabled.
Note: As a side effect of the enablement procedure the fips-mode-enable tool also changes
the system-wide cryptographic policy level to a level named “FIPS”, this level helps
applications by changing configuration defaults to approved algorithms.
10.1.1.2 Manual method
The recommended method automatically performs all the necessary steps.
The following steps can be done manually but are not recommended and are not required if
the systems has been installed with the fips-mode-setup tool:
- create a file named /etc/system-fips, the contents of this file are never checked
- ensure to invoke the command ‘fips-finish-install --complete’ on the installed
system.
- ensure that the kernel boot line is configured with the fips=1 parameter set
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 24 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
- Reboot the system
NOTE: If /boot or /boot/efi resides on a separate partition, the kernel parameter
boot=<boot partition> must be supplied. The partition can be identified with the command
"df | grep boot". For example:
$ df |grep boot
/dev/sda1 233191 30454 190296 14% /boot
The partition of the /boot file system is located on /dev/sda1 in this example.
Therefore the parameter boot=/dev/sda1 needs to be appended to the kernel command line
in addition to the parameter fips=1.
Because FIPS 140-2 has certain restrictions on the use of cryptography which are not always
wanted, the Module needs to be put into FIPS Approved mode explicitly: if the file
/proc/sys/crypto/fips_enabled exists and contains a numeric value other than 0, the
Module is put into FIPS Approved mode at initialization time. This is the mechanism
recommended for ordinary use, activated by using the fips-mode-setup –-enable
command, as described above.
If an application that uses the Module for its cryptography is put into a chroot environment,
the Crypto Officer must ensure one of the above methods is available to the Module from
within the chroot environment to ensure entry into FIPS Approved mode. Failure to do so will
not allow the application to properly enter FIPS Approved mode.
Once the Module has been put into FIPS Approved mode, it is not possible to switch back to
standard mode without terminating the process first.
If an application wants to explicitly request and force FIPS mode, it should use the control
command:
gcry_control(GCRYCTL_FORCE_FIPS_MODE).
This must be done prior to any initialization (i.e. before the gcry_check_version() function).
Once libgcrypt has been put into FIPS mode, it is not possible to switch back to standard
mode without terminating the process first. If the logging verbosity level of libgcrypt has been
set to at least 2, the state transitions and the self tests are logged.
10.2 User Guidance
Applications using libgcrypt need to call gcry_control(GCRYCTL_INITIALIZATION_FINISHED,
0) after initialization is done: that ensures that the DRBG is properly seeded, among others.
gcry_control(GCRYCTL_TERM_SECMEM)needs to be called before the process is terminated.
The function gcry_set_allocation_handler()may not be used.
The user must not call malloc/free to create/release space for keys, let libgcrypt manage
space for keys, which will ensure that the key memory is overwritten before it is released.
See the documentation file doc/gcrypt.texi within the source code tree for complete
instructions for use.
The information pages are included within the developer package. The user can find the
documentation at the following location after having installed the developer package:
/usr/share/info/gcrypt.info-1.gz
/usr/share/info/gcrypt.info-2.gz
/usr/share/info/gcrypt.info.gz
10.2.1 Three-key Triple-DES
According to IG A.13, the same Triple-DES key shall not be used to encrypt more than 216
64-
bit blocks of data. It is the user’s responsibility to make sure that the module complies with
this requirement and that the module does not exceed this limit.
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 25 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
10.2.2 AES-XTS Guidance
The length of a single data unit encrypted or decrypted with the XTS-AES shall not exceed 2²⁰
AES blocks that is 16MB of data per AES-XTS instance. An XTS instance is defined in section 4
of SP 800-38E.
The module implements a check to ensure that the two AES keys used in XTS-AES algorithm
are not identical.
The AES-XTS mode shall only be used for the cryptographic protection of data on storage
devices. The AES-XTS shall not be used for other purposes, such as the encryption of data in
transit.
10.2.3 Key derivation using SP800-132 PBKDF
The module provides password-based key derivation (PBKDF), compliant with SP800-132. The
module supports option 1a from section 5.4 of [SP800-132], in which the Master Key (MK) or a
segment of it is used directly as the Data Protection Key (DPK).
In accordance to [SP800-132] and IG D.6, the following requirements shall be met.
• Derived keys shall only be used in storage applications. The Master Key (MK) shall not
be used for other purposes. The length of the MK or DPK shall be of 112 bits or more.
• A portion of the salt, with a length of at least 128 bits, shall be generated randomly
using the SP800-90A DRBG,
• The iteration count shall be selected as large as possible, as long as the time required
to generate the key using the entered password is acceptable for the users. The
minimum value shall be 1000.
• Passwords or passphrases, used as an input for the PBKDF, shall not be used as
cryptographic keys.
• The length of the password or passphrase shall be of at least 20 characters, and shall
consist of lower-case, upper-case and numeric characters. The probability of guessing
the value is estimated to be 1/6220
= 10-36
, which is less than 2-112
.
The calling application shall also observe the rest of the requirements and recommendations
specified in [SP800-132].
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 26 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
11 Mitigation of Other Attacks
libgcrypt uses a blinding technique for RSA decryption to mitigate real world timing attacks
over a network: Instead of using the RSA decryption directly, a blinded value (y = x·re
mod n)
is decrypted and the unblinded value (x' = y'·r-1
mod n) returned. The blinding value “r” is a
random value with the size of the modulus “n” and generated with `GCRY_WEAK_RANDOM'
random level.
Weak Triple-DES keys are detected as follows:
In DES there are 64 known keys which are weak because they produce only one, two, or four
different subkeys in the subkey scheduling process. The keys in this table have all their parity
bits cleared.
static byte weak_keys[64][8] =
{
{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }, /*w*/
{ 0x00, 0x00, 0x1e, 0x1e, 0x00, 0x00, 0x0e, 0x0e },
{ 0x00, 0x00, 0xe0, 0xe0, 0x00, 0x00, 0xf0, 0xf0 },
{ 0x00, 0x00, 0xfe, 0xfe, 0x00, 0x00, 0xfe, 0xfe },
{ 0x00, 0x1e, 0x00, 0x1e, 0x00, 0x0e, 0x00, 0x0e }, /*sw*/
{ 0x00, 0x1e, 0x1e, 0x00, 0x00, 0x0e, 0x0e, 0x00 },
{ 0x00, 0x1e, 0xe0, 0xfe, 0x00, 0x0e, 0xf0, 0xfe },
{ 0x00, 0x1e, 0xfe, 0xe0, 0x00, 0x0e, 0xfe, 0xf0 },
{ 0x00, 0xe0, 0x00, 0xe0, 0x00, 0xf0, 0x00, 0xf0 }, /*sw*/
{ 0x00, 0xe0, 0x1e, 0xfe, 0x00, 0xf0, 0x0e, 0xfe },
{ 0x00, 0xe0, 0xe0, 0x00, 0x00, 0xf0, 0xf0, 0x00 },
{ 0x00, 0xe0, 0xfe, 0x1e, 0x00, 0xf0, 0xfe, 0x0e },
{ 0x00, 0xfe, 0x00, 0xfe, 0x00, 0xfe, 0x00, 0xfe }, /*sw*/
{ 0x00, 0xfe, 0x1e, 0xe0, 0x00, 0xfe, 0x0e, 0xf0 },
{ 0x00, 0xfe, 0xe0, 0x1e, 0x00, 0xfe, 0xf0, 0x0e },
{ 0x00, 0xfe, 0xfe, 0x00, 0x00, 0xfe, 0xfe, 0x00 },
{ 0x1e, 0x00, 0x00, 0x1e, 0x0e, 0x00, 0x00, 0x0e },
{ 0x1e, 0x00, 0x1e, 0x00, 0x0e, 0x00, 0x0e, 0x00 }, /*sw*/
{ 0x1e, 0x00, 0xe0, 0xfe, 0x0e, 0x00, 0xf0, 0xfe },
{ 0x1e, 0x00, 0xfe, 0xe0, 0x0e, 0x00, 0xfe, 0xf0 },
{ 0x1e, 0x1e, 0x00, 0x00, 0x0e, 0x0e, 0x00, 0x00 },
{ 0x1e, 0x1e, 0x1e, 0x1e, 0x0e, 0x0e, 0x0e, 0x0e }, /*w*/
{ 0x1e, 0x1e, 0xe0, 0xe0, 0x0e, 0x0e, 0xf0, 0xf0 },
{ 0x1e, 0x1e, 0xfe, 0xfe, 0x0e, 0x0e, 0xfe, 0xfe },
{ 0x1e, 0xe0, 0x00, 0xfe, 0x0e, 0xf0, 0x00, 0xfe },
{ 0x1e, 0xe0, 0x1e, 0xe0, 0x0e, 0xf0, 0x0e, 0xf0 }, /*sw*/
{ 0x1e, 0xe0, 0xe0, 0x1e, 0x0e, 0xf0, 0xf0, 0x0e },
{ 0x1e, 0xe0, 0xfe, 0x00, 0x0e, 0xf0, 0xfe, 0x00 },
{ 0x1e, 0xfe, 0x00, 0xe0, 0x0e, 0xfe, 0x00, 0xf0 },
{ 0x1e, 0xfe, 0x1e, 0xfe, 0x0e, 0xfe, 0x0e, 0xfe }, /*sw*/
{ 0x1e, 0xfe, 0xe0, 0x00, 0x0e, 0xfe, 0xf0, 0x00 },
{ 0x1e, 0xfe, 0xfe, 0x1e, 0x0e, 0xfe, 0xfe, 0x0e },
{ 0xe0, 0x00, 0x00, 0xe0, 0xf0, 0x00, 0x00, 0xf0 },
{ 0xe0, 0x00, 0x1e, 0xfe, 0xf0, 0x00, 0x0e, 0xfe },
{ 0xe0, 0x00, 0xe0, 0x00, 0xf0, 0x00, 0xf0, 0x00 }, /*sw*/
{ 0xe0, 0x00, 0xfe, 0x1e, 0xf0, 0x00, 0xfe, 0x0e },
{ 0xe0, 0x1e, 0x00, 0xfe, 0xf0, 0x0e, 0x00, 0xfe },
{ 0xe0, 0x1e, 0x1e, 0xe0, 0xf0, 0x0e, 0x0e, 0xf0 },
{ 0xe0, 0x1e, 0xe0, 0x1e, 0xf0, 0x0e, 0xf0, 0x0e }, /*sw*/
{ 0xe0, 0x1e, 0xfe, 0x00, 0xf0, 0x0e, 0xfe, 0x00 },
{ 0xe0, 0xe0, 0x00, 0x00, 0xf0, 0xf0, 0x00, 0x00 },
{ 0xe0, 0xe0, 0x1e, 0x1e, 0xf0, 0xf0, 0x0e, 0x0e },
{ 0xe0, 0xe0, 0xe0, 0xe0, 0xf0, 0xf0, 0xf0, 0xf0 }, /*w*/
{ 0xe0, 0xe0, 0xfe, 0xfe, 0xf0, 0xf0, 0xfe, 0xfe },
{ 0xe0, 0xfe, 0x00, 0x1e, 0xf0, 0xfe, 0x00, 0x0e },
{ 0xe0, 0xfe, 0x1e, 0x00, 0xf0, 0xfe, 0x0e, 0x00 },
{ 0xe0, 0xfe, 0xe0, 0xfe, 0xf0, 0xfe, 0xf0, 0xfe }, /*sw*/
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 27 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
{ 0xe0, 0xfe, 0xfe, 0xe0, 0xf0, 0xfe, 0xfe, 0xf0 },
{ 0xfe, 0x00, 0x00, 0xfe, 0xfe, 0x00, 0x00, 0xfe },
{ 0xfe, 0x00, 0x1e, 0xe0, 0xfe, 0x00, 0x0e, 0xf0 },
{ 0xfe, 0x00, 0xe0, 0x1e, 0xfe, 0x00, 0xf0, 0x0e },
{ 0xfe, 0x00, 0xfe, 0x00, 0xfe, 0x00, 0xfe, 0x00 }, /*sw*/
{ 0xfe, 0x1e, 0x00, 0xe0, 0xfe, 0x0e, 0x00, 0xf0 },
{ 0xfe, 0x1e, 0x1e, 0xfe, 0xfe, 0x0e, 0x0e, 0xfe },
{ 0xfe, 0x1e, 0xe0, 0x00, 0xfe, 0x0e, 0xf0, 0x00 },
{ 0xfe, 0x1e, 0xfe, 0x1e, 0xfe, 0x0e, 0xfe, 0x0e }, /*sw*/
{ 0xfe, 0xe0, 0x00, 0x1e, 0xfe, 0xf0, 0x00, 0x0e },
{ 0xfe, 0xe0, 0x1e, 0x00, 0xfe, 0xf0, 0x0e, 0x00 },
{ 0xfe, 0xe0, 0xe0, 0xfe, 0xfe, 0xf0, 0xf0, 0xfe },
{ 0xfe, 0xe0, 0xfe, 0xe0, 0xfe, 0xf0, 0xfe, 0xf0 }, /*sw*/
{ 0xfe, 0xfe, 0x00, 0x00, 0xfe, 0xfe, 0x00, 0x00 },
{ 0xfe, 0xfe, 0x1e, 0x1e, 0xfe, 0xfe, 0x0e, 0x0e },
{ 0xfe, 0xfe, 0xe0, 0xe0, 0xfe, 0xfe, 0xf0, 0xf0 },
{ 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe } /*w*/ };
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 28 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
Appendix A Glossary and Abbreviations
AES Advanced Encryption Standard
AES-NI Advanced Encryption Standard New Instructions
CAVP Cryptographic Algorithm Validation Program
CBC Cipher Block Chaining
CCM Counter with Cipher Block Chaining Message Authentication Code
CFB Cipher Feedback
CMAC Cipher-based Message Authentication Code
CMVP Cryptographic Module Validation Program
CSP Critical Security Parameter
CTR Counter Mode
DES Data Encryption Standard
DSA Digital Signature Algorithm
DRBG Deterministic Random Bit Generator
ECB Electronic Code Book
FIPS Federal Information Processing Standards Publication
HMAC Hash Message Authentication Code
KAT Known Answer Test
MAC Message Authentication Code
NIST National Institute of Science and Technology
OFB Output Feedback
OS Operating System
PAA Processor Algorithm Acceleration
PSS Probabilistic Signature Scheme
RSA Rivest, Shamir, Addleman
SHA Secure Hash Algorithm
SHS Secure Hash Standard
XTS XEX-based Tweaked-codebook mode with ciphertext Stealing
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 29 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
Appendix B References
FIPS180-4 Secure Hash Standard (SHS)
August 2015
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
FIPS186-4 Digital Signature Standard (DSS)
July 2013
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
FIPS197 Advanced Encryption Standard
November 2001
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf
FIPS198-1 The Keyed Hash Message Authentication Code (HMAC)
July 2008
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf
PKCS#1 Public Key Cryptography Standards (PKCS) #1: RSA Cryptography
Specifications Version 2.1
February 2003
http://www.ietf.org/rfc/rfc3447.txt
RFC3394 Advanced Encryption Standard (AES) Key Wrap Algorithm
September 2002
http://www.ietf.org/rfc/rfc3394.txt
RFC5649 Advanced Encryption Standard (AES) Key Wrap with Padding
Algorithm
September 2009
http://www.ietf.org/rfc/rfc5649.txt
SP800-38A NIST Special Publication 800-38A - Recommendation for Block
Cipher Modes of Operation Methods and Techniques
December 2001
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-
38a.pdf
SP800-38B NIST Special Publication 800-38B - Recommendation for Block
Cipher Modes of Operation: The CMAC Mode for Authentication
May 2005
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38b.pdf
SP800-38C NIST Special Publication 800-38C - Recommendation for Block
Cipher Modes of Operation: the CCM Mode for Authentication and
Confidentiality
July 2007
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-
38c.pdf
SP800-38E NIST Special Publication 800-38E - Recommendation for Block
Cipher Modes of Operation: The XTS AES Mode for Confidentiality on
Storage Devices
January 2010
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-
38e.pdf
SP800-38F NIST Special Publication 800-38F - Recommendation for Block
Cipher Modes of Operation: Methods for Key Wrapping
December 2012
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf
SP800-56A NIST Special Publication 800-56A Revision 3 - Recommendation for
Pair Wise Key Establishment Schemes Using Discrete Logarithm
Cryptography
April 2018
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 30 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.
FIPS 140-2 Non-Proprietary Security Policy
SP800-56C NIST Special Publication 800-56C Revision 1 - Recommendation for
Key Derivation in Key-Establishment Schemes
April 2018
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr1.pdf
SP800-67 NIST Special Publication 800-67 Revision 2 - Recommendation for
the Triple Data Encryption Algorithm (TDEA) Block Cipher
November 2017
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-67r2.pdf
SP800-90A NIST Special Publication 800-90A Revision 1- Recommendation for
Random Number Generation Using Deterministic Random Bit
Generators
June 2015
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf
SP800-90B NIST Special Publication 800-90B - Recommendation for the Entropy
Sources Used for Random Bit Generation
January 2018
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf
SP800-108 NIST Special Publication 800-108 - Recommendation for Key
Derivation Using Pseudorandom Functions
October 2009
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-
108.pdf
SP800-131A NIST Special Publication 800-131A Revision 2 - Transitions:
Recommendation for Transitioning the Use of Cryptographic
Algorithms and Key Lengths
March 2019
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf
© 10/24/23 Red Hat(R), Inc. / atsec information security corporation Page 31 of 31
This document can be reproduced and distributed only whole and intact, including this copyright notice.