Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module
version rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
Document version 1.0
Last Update: September 28, 2022
Prepared by:
atsec information security corporation
9130 Jollyville Road, Suite 260
Austin, TX 78759
www.atsec.com
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice.
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
Table of Contents
1. Cryptographic Module Specification .................................................................................... 3
1.1. Description of the Module ................................................................................................ 3
1.2. Description of the Approved Modes ................................................................................. 4
1.3. Cryptographic Boundary ................................................................................................ 10
1.3.1. Hardware Block Diagram ............................................................................................. 11
1.3.2. Software Block Diagram .............................................................................................. 11
2. Cryptographic Module Ports and Interfaces ....................................................................... 13
3. Roles, Services and Authentication ................................................................................... 14
3.1. Roles .............................................................................................................................. 14
3.2. Services ......................................................................................................................... 14
3.3. Operator Authentication ................................................................................................. 18
4. Physical Security ............................................................................................................... 19
5. Operational Environment .................................................................................................. 20
5.1. Applicability ................................................................................................................... 20
5.2. Policy ............................................................................................................................. 20
6. Cryptographic Key Management ....................................................................................... 21
6.1. Random Number Generation .......................................................................................... 23
6.2. Key Generation .............................................................................................................. 24
6.3. Key Establishment/Key Derivation .................................................................................. 24
6.4. Key Entry and Output ..................................................................................................... 25
6.5. Key/CSP Storage ............................................................................................................ 26
6.6. Key/CSP Zeroization ....................................................................................................... 26
7. Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) ........................... 27
7.1. Statement of compliance ............................................................................................... 27
8. Self-Tests ........................................................................................................................... 28
8.1. Power-Up Tests ............................................................................................................... 28
8.1.1. Integrity Tests ............................................................................................................. 28
8.1.2. Cryptographic Algorithm Test ...................................................................................... 28
8.2. On-Demand Self-Tests .................................................................................................... 29
8.3. Conditional Tests ............................................................................................................ 29
9. Guidance ........................................................................................................................... 31
9.1. Crypto Officer Guidance ................................................................................................. 31
FIPS module installation instructions: .................................................................................... 31
10. Recommended method ................................................................................................... 31
Manual method ..................................................................................................................... 32
10.1. User Guidance .............................................................................................................. 32
10.1.1. TLS and Diffie-Hellman .............................................................................................. 32
10.1.2. AES-GCM ................................................................................................................... 33
10.1.3. RSA and DSA Keys .................................................................................................... 33
10.1.4. Triple-DES .................................................................................................................. 33
10.1.5. Key derivation using SP800-132 PBKDF .................................................................... 33
10.2. Handling Self-Test Errors ............................................................................................... 34
11. Mitigation of Other Attacks ............................................................................................. 36
12. Glossary and Abbreviations ............................................................................................. 37
13. References ...................................................................................................................... 39
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 2 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
1. Cryptographic Module Specification
This document is the non-proprietary security policy for the Red Hat Enterprise Linux 8 GnuTLS
Cryptographic Module version rhel8.20210628, and was prepared as part of the requirements for
conformance to Federal Information Processing Standard (FIPS) 140-2, Level 1 Software Module.
1.1. Description of the Module
The Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module (hereafter referred to as the
“module”) is a set of libraries implementing general purpose cryptographic algorithms and
network protocols. The module supports the Transport Layer Security (TLS) Protocol defined in
[RFC5246] and the Datagram Transport Layer Security (DTLS) Protocol defined in [RFC4347]. The
module provides a C language Application Program Interface (API) for use by other calling
applications that require cryptographic functionality or TLS/DTLS network protocols.
The components of the cryptographic module are specified in the following table:
Component Description
libgnutls This library provides the main interface which allows the calling applications to
request cryptographic services. The Approved cryptographic algorithm
implementations provided by this library include the TLS protocol, DRBG, RSA
Key Generation, Diffie-Hellman and EC Diffie-Hellman.
libnettle This library provides the cryptographic algorithm implementations, including
AES, Triple-DES, SHA, HMAC, RSA Digital Signature, DSA and ECDSA.
libhogweed This library includes the primitives used by libgnutls and libnettle to support the
asymmetric cryptographic operations.
libgmp This library provides the big number arithmetic operations to support the
asymmetric cryptographic operations.
*.hmac The .hmac files contain the HMAC-SHA-256 values of its associated library for
integrity check during the power-up.
Table 1: Cryptographic Module Components
The module has been tested on the following multi-chip standalone platforms:
Manufacturer Model Test Configurations Processor
Dell PowerEdge R440 Red Hat Enterprise Linux 8
with/without AES-NI
Intel(R) Xeon(R) Silver
4216
Table 2: Tested Platform
NOTE: This validation is only for the tested platform listed in Table 2 of this document. It does not
cover other derivatives of the Operating Systems (I.e, Centos or Fedora).
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 3 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
The following platform have 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.
Hardware Platform Processor Operating System
Dell PowerEdge R430 Intel(R) Xeon(R) E5 Red Hat Enterprise Linux 8
Table 2A: Vendor Affirmed Platforms
Note: 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 this module is ported and executed
in an operational environment not listed on the validation certificate.
The following table shows the security level for each of the eleven sections of the validation:
Security Component FIPS 140-2 Security 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
EMI/EMC 1
Self-Tests 1
Design Assurance 1
Mitigation of Other Attacks 1
Overall level 1
Table 3: Security Level of the Module
1.2. Description of the Approved Modes
The module supports two modes of operation:
• In "FIPS mode" (the FIPS Approved mode of operation) only approved or allowed security
functions with sufficient security strength can be used.
• In "non-FIPS mode" (the non-Approved mode of operation) only non-approved security
functions can be used.
When the module is powered up, the module executes the power-up tests and obtains the HMAC
value of the module for integrity check from the .hmac file for each software libraries within the
module's logical boundary. The module enters FIPS mode automatically after power-up tests
succeed. If the module fails any power-up tests, the module will return an error code and enter the
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 4 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
error state to prohibit any further cryptographic operations. The operator should follow the
guidance in section 10.2 for descriptions of possible self-test errors and recovery procedures.
Once the module completes power-up tests successfully and enters FIPS mode by default, the
module is available to provide cryptographic services. The mode of operation is implicitly assumed
depending on the security function invoked and the security strength of the cryptographic keys.
Critical security parameters used or stored in FIPS mode are not used in non-FIPS mode, and vice
versa.
The module supports the following FIPS 140-2 Approved algorithms in FIPS mode:
Algorithm CAVP Certificates Standards Keys/CSPs
AES Cert. #A1830 (CBC,
CMAC, GCM, GMAC)
FIPS 197 AES
SP 800-38A
SP 800-38D GCM
AES keys 128 bits, 192
bits and 256 bits (ECB,
CBC, CFB8)
AES keys 128 bits and
256 bits (CCM, CMAC,
GCM, GMAC, XTS)
Cert. #A1824 (CBC,
CCM, CMAC, GCM)
Cert. #A1825 (CBC,
CMAC, GCM)
Certs. #A1827,
#A1828 and
#A1833 (CFB8)
SP 800-38A
Cert. #A1831 (XTS) SP 800-38E
3-key Triple-DES with the
following mode:
• CBC
Cert. #A1830 SP 800-67
SP 800-38A
Triple-DES keys 192 bits
DRBG using AES-256
CTR_DRBG where AES
encryption is provided by the
nettle library
Note: CTR_DRBG without
Derivation Function, without
Prediction Resistance and
Reseeding implementation
Cert. #A1830
Dependent AES
Cert. #A1804 (AES-
ECB from Nettle)
SP 800-90A Entropy input string,
seed, V and Key
ENT(NP) N/A SP 800-90B N/A
SHA:
• SHA-1
• SHA-224
• SHA-256
• SHA-384
• SHA-512
Certs. #A1825 and
#A1830
FIPS 180-4 N/A
SHA3:
• SHA3-224
• SHA3-256
• SHA3-384
• SHA3-512
Certs. #A1826 and
#A1832
FIPS 202 N/A
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 5 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
Algorithm CAVP Certificates Standards Keys/CSPs
HMAC:
• SHA-1
• SHA-224
• SHA-256
• SHA-384
• SHA-512
Certs. #A1825 and
#A1830
FIPS 198-1 At least 112 bits HMAC
Key
DSA Domain Parameters
Generation and Verification
Cert. #A1830 FIPS 186-4 L=2048, N=224 (with
SHA-384)
L=2048, N=256 (with
SHA-384)
L=3072, N=256 (with
SHA-384)
DSA Key Generation
DSA Signature Generation L=2048, N=224 (with
SHA-224, SHA-256, SHA-
384, SHA-512)
L=2048, N=256 (with
SHA-256, SHA-384, SHA-
512)
L=3072, N=256 (with
SHA-256, SHA-384, SHA-
512)
DSA Signature Verification L=2048, N=224 (with
SHA-1, SHA-224, SHA-
256, SHA-384, SHA-512)
L=2048, N=256 (with
SHA-1, SHA-256, SHA-
384, SHA-512)
L=3072, N=256 (with
SHA-1, SHA-256, SHA-
384, SHA-512)
RSA Key Generation (B.3.2) Cert. #A1830 FIPS 186-4 RSA keys (2048, 3072,
40961
bits)
RSA (PKCS#1 v1.5) Signature
Generation
(with SHA-224, SHA-256,
SHA-384, SHA-512)
RSA PSS Signature
Generation
(with SHA-256, SHA-384,
SHA-512)
1 The modulus size of 4096 is CAVP validated but it is blocked from use in the validated module.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 6 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
Algorithm CAVP Certificates Standards Keys/CSPs
RSA (PKCS#1 v1.5) Signature
Verification
(with SHA-224, SHA-256,
SHA-384, SHA-512)
RSA PSS Signature
Verification
(with SHA-256, SHA-384,
SHA-512)
ECDSA Key Pair Generation
and Public Key Verification
Cert. #A1830 FIPS 186-4 ECDSA keys based on P-
256, P-384, or P-521
curve
ECDSA Signature Generation
(with SHA-224, SHA-256,
SHA-384, SHA-512)
ECDSA Signature Verification
(with SHA-224, SHA-256,
SHA-384, SHA-512)
KAS-ECC-SSC Cert. #A18302
SP 800-56Arev3 EC Diffie-Hellman private
key (P-256, P-384, P-521)
shared secret
KAS-FFC-SSC with safe prime
groups
Cert. #A1830 SP 800-56Arev3 Diffie-Hellman private key
(ffdhe2048, ffdhe3072,
ffdhe4096, ffdhe6144,
ffdhe8192,
MODP-2048, MODP-3072,
MODP-4096, MODP-6144,
MODP-8192)
shared secret
Diffie-Hellman
Safe Primes Key Generation
Cert. #A1830 SP 800-56Arev3 Safe Prime Groups:
(ffdhe2048, ffdhe3072,
ffdhe4096, ffdhe6144,
ffdhe8192,
MODP-2048, MODP-3072,
MODP-4096, MODP-6144,
MODP-81923
)
2 KAS-FFC-SSC and KAS-ECC-SSC components which are not SP 800-56ARev3, although tested by
CAVP, are not used by the module and only the SP 800-56ARev3 compliant are used.
3 Only ffdhe groups are used by GnuTLS since MODP groups are used for IKE only, and GnuTLS
does not implement IKE.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 7 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
Algorithm CAVP Certificates Standards Keys/CSPs
KDA HKDF Cert. #A1829 SP800-56Crev1
Key Derivation in
TLS 1.3
Shared secret, derived
key
Key Derivation Function in
TLS v1.0, v1.1 and v1.2
(with MD5/SHA1 for v1.0 and
SHA-256 and SHA-384 for
v1.1/1.2)
CVL Cert. #A1830 SP800-135 rev1
Section 4.2
Shared secret, derived
key
PBKDF – Key Derivation
(with HMAC-
SHA1/224/256/384/512)
Cert. #A1830 SP 800-132 Password, derived key
KTS Certs. #A1824,
#A1825 and
#A1830
SP800-38F
AES-GCM
AES-CCM
AES keys 128 and 256
bits
AES Certs. #A1824,
#A1825 and
#A1830
HMAC Certs.
#A1825 and
#A1830
SP800-38F
AES CBC with
HMAC
AES keys 128 and 256
bits
Triple-DES Certs.
#A1830
HMAC Certs.
#A1825 and
#A1830
SP800-38F
Triple-DES CBC
with HMAC
Triple-DES keys 168 bits
Table 4: Validated Cryptographic Algorithms
Note: The TLS and DTLS network protocols have not been reviewed or tested by the CAVP and
CMVP.
Note: There are algorithms, modes, and keys that have been CAVP tested but not used by the
module in FIPS approved mode. Only the algorithms, modes/methods, and key
lengths/curves/moduli shown in Table 4 and Table 5 are used by the module in FIPS approved
mode.
The module supports different AES and SHA implementations based on the underlying platform's
capability. The module supports the use of AES-NI and SSSE3 when it is operated in an Intel® x86-
64 architecture environment. When the AES-NI is enabled in the operating environment, the
module performs the AES operations using the support from the AES-NI instructions; when the
AES-NI is disabled in the operating environment, the module performs the AES operations using
the supports from the Supplemental Streaming SIMD Extensions 3 (SSSE3). The module also
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 8 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
performs SHA operations using the supports from the SSSE3. The SSSE3 cannot be disabled on the
test platform that runs in the Intel® x86 architecture environment. The AES and SHA
implementations that uses the AES-NI and SSSE3 supports and their related algorithms have been
CAVP tested and functionally tested. Although the module implements different implementations
for AES and SHA, only one implementation for one algorithm will ever be available for AES SHA
and HMAC cryptographic services at run-time.
The module implements the following non-Approved algorithms which are allowed in FIPS mode:
Algorithm Usage Key/CSP sizes
RSA PKCS#1 v1.5 key wrapping Key size between 2048 bits and
16384 bits or more
MD5 Used in TLS PRF only N/A
Table 5: Non-Approved but allowed algorithms
The module implements the following non-Approved algorithms only available in non-FIPS mode:
• AES GCM usage outside of TLSv1.2 context
• AES with counter mode (CTR)
• AES-SIV
• Blowfish
• Camellia
• ChaCha20
• CAST 128
• DES
• Diffie-Hellman KAS with smaller than 2048 bits domain parameters size
• Diffie-Hellman with keys generated with domain parameters other than safe primes
• FIPS 186-2 RSA Key Generation
• FIPS 186-4 RSA Key Generation, Signature Generation with modulus size smaller than 2048
bits and larger than 3072 bits
• RSA Key wrapping using modulus size smaller than 2048
• FIPS 186-4 RSA, DSA, ECDSA Signature Generation/Verification with non-Approved Message
Digest algorithms not listed in Table 4
• FIPS 186-4 DSA key generation, signature generation, signature verification with smaller
than 2048 bits public key size or larger than 3072 bits
• GOST (symmetric key encrypt/decrypt, message digest)
• MD2
• MD4
• MD5
• RC2
• RC4
• RIPEMD-160
• Salsa20
• Serpent
• Twofish
• UMAC
• Streebog 256 and 512
• Poly1305
• Ed25519 curve.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 9 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
• EdDSA.
Regarding the available services in FIPS mode of operation and non-FIPS mode of operation, please
refer to Table 7: Services Available in FIPS mode and Table 8. Services Available in non-FIPS mode
in section 3.2 Services.
1.3. Cryptographic Boundary
The module's physical boundary is the physical boundary of the test platform. The embodiment
type of the module is defined as multi-chip standalone.
The module's logical boundary is the shared library files and their integrity check HMAC files,
which are delivered through Red Hat Package Manager (RPM) listed in section 9.1. The binary files
and the HMAC files within the module's logical boundary are listed below:
• libgnutls library:
◦ /usr/lib64/libgnutls.so.30.28.0
◦ /usr/lib64/.libgnutls.so.30.28.0.hmac
• libnettle library:
◦ /usr/lib64/libnettle.so.6.5
◦ /usr/lib64/.libnettle.so.6.5.hmac
• libhogweed library:
◦ /usr/lib64/libhogweed.so.4.5
◦ /usr/lib64/.libhogweed.so.4.5.hmac
• libgmp library:
◦ /usr/lib64/libgmp.so.10.3.2
◦ /usr/lib64/fipscheck/libgmp.so.10.3.2.hmac
1.3.1. Hardware Block Diagram
The physical boundary of the module is the physical boundary of the test platform which is a
General Purpose Computer (GPC). The following block diagram shows the hardware components of
a GPC:
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 10 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
Figure 1. Hardware Block Diagram
1.3.2. Software Block Diagram
The block diagrams below shows the module's logical boundary, its interface with the operational
environment and the delimitation of its logical boundary which are included in BLUE box:
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 11 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
Figure 2. Software Block Diagram
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 12 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
2. Cryptographic Module Ports and Interfaces
The physical ports of the module are the same as the computer system on which it executes. The
logical interface is a C-language Application Program Interface (API) through libgnutls library.
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 functions. The Status Output interface includes the return values of the
API functions. The ports and interfaces are shown in the following table.
FIPS Interface Physical Port Module Interface
Data Input Ethernet ports API input parameters, kernel I/O –
network or files on file system, TLS
protocol
Data Output Ethernet ports API output parameters, kernel I/O –
network or files on file system, TLS
protocol
Control Input Keyboard, Serial port, Ethernet
port, Network
API function calls, TLS protocol
Status Output Serial port, Ethernet port,
Network
API return codes, TLS protocol
Power Input PC Power Supply Port N/A
Table 6: Ports and Interfaces
Note: The module is an implementation to support the TLS protocol defined in [RFC5246] and TLS
is a port networking interface to provide secure channel between entities. When the calling
application sends the data to the module, the module packages the data according to the TLS
standard and sends it to other entity confidentially and integrity. The module is considered a user
interface to use the TLS protocol to communicate with other remote entities securely through the
network.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 13 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
3. Roles, Services and Authentication
This section defines the roles, services, and authentication mechanisms and methods with respect
to the applicable FIPS 140-2 requirements.
3.1. Roles
The module supports the following roles:
• User role: performs all services (in both FIPS mode and non-FIPS mode of operation),
except module installation, configuration and initialization.
• Crypto Officer role: performs module installation, configuration and initialization.
The User and Crypto Officer roles are implicitly assumed by the entity accessing services
implemented by the module.
3.2. Services
The module provides services to users that assume one of the available roles. All services are
described in detail in the user documentation.
The following table lists the Approved services and the non-Approved but allowed services in FIPS
mode of operation, the roles that can request the service, the Critical Security Parameters (CSP)
involved and how they are accessed:
Service Role Keys/CSPs Access
Cryptographic Library Services
Symmetric Encryption and Decryption User AES 128, 192 or 256 bit key Read
3-key Triple-DES 192 bit key
Asymmetric Key Generation in X509
Certificate
User RSA public-private keys with 2048
and 3072 bits of modulus size
Create
DSA public-private keys with 2048
and 3072 bits of public key size
ECDSA public-private keys with P-
256, P-384 or P-521 curve
Digital Signature Generation in X509
Certificate
User RSA public-private keys with 2048
and 3072 bits of modulus size
Read
DSA public-private keys with 2048
and 3072 bits of public key size
ECDSA public-private keys with P-
256, P-384 or P-521 curve
Digital Signature Verification in X509
Certificate
User RSA public-private keys with 2048
and 3072 bits of modulus size
Read
DSA public-private keys with 1024,
2048 and 3072 bits public key size
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 14 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
Service Role Keys/CSPs Access
ECDSA public-private keys with P-
256, P-384 or P-521 curve
Public Key Verification User ECDSA public-private keys with P-
256, P-384 or P-521 curve
Read
DSA domain parameter
generation/verification
User None None
Shared secret computation User Shared secret, (EC) Diffie-Hellman
private key
Create,
Read,
Write
Diffie-Hellman Parameters Generation
using safe primes
User Diffie-Hellman domain parameters Create,
Read,
Write
Import and Export Public Key User RSA, DSA or ECDSA public key Read,
Write
Import and Export Private Key User RSA, DSA or ECDSA private key Read,
Write
Keyed Hash (HMAC) User At least 112 bits HMAC Key Read
Message Digest (SHA) User None None
Random Number Generation (SP800-
90A DRBG)
User Entropy input string, seed, internal
state (V and key)
Read,
Write
Symmetric key generation User AES or Triple-DES or HMAC key Create
Key Wrapping according to SP 800-38F4
User AES, Triple-DES and HMAC keys Read
SP 800-132 Password-based Key
Derivation Function (PBKDF)
User PBKDF Password, PBKDF derived
key
Read,
Create
SP800-56Crev1
Key Derivation Function (HKDF)
User HKDF derived key
shared secret
Read,
Create
Network Protocols Services
(Note: The underlying algorithms are the same as the algorithm implementations provided in the
Cryptographic Library Services.)
TLS or DTLS Handshaking Initialization User None None
TLS Alert Protocol User None None
TLS Record Protocol User AES or Triple-DES key, HMAC key Read
TLS Handshaking using X509
Certificates Authentication method
with:
• Diffie-Hellman KAS
• EC Diffie-Hellman KAS
• RSA-based PKCSv1.5 Key
Wrapping
User AES or Triple-DES key, RSA, DSA or
ECDSA public-private key, HMAC
Key, pre-master secret, TLS Master
secret, Diffie-Hellman public-
private keys and EC Diffie-Hellman
EC public-private keys
Create,
Read
4 The module claims SP 800-38F compliant key wrapping see section 6.3 for details.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 15 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
Service Role Keys/CSPs Access
TLS Handshaking using Anonymous
Authentication method with:
• Diffie-Hellman KAS
• EC Diffie-Hellman KAS
User AES or Triple-DES key, DSA or
ECDSA public-private key, HMAC
Key, pre-master secret, TLS Master
secret, Diffie-Hellman public-
private keys and EC Diffie-Hellman
EC public-private keys
Create,
Read
TLS Handshaking using Pre-Shared Key
(PSK) Authentication method with:
• Diffie-Hellman KAS
• EC Diffie-Hellman KAS
• RSA-based PKCSv1.5 Key
Wrapping
User AES or Triple-DES key, RSA, DSA or
ECDSA public-private key, HMAC
Key, pre-master secret, TLS Master
secret, Diffie-Hellman public-
private keys and EC Diffie-Hellman
EC public-private keys
Create,
Read
TLS X.509 Certificate Handling,
including digital signature,
key/certificate import and export, and
support the following format:
• PKCS#7
• PKCS#12
• Binary (DER) encoding
• ASCII (PEM) encoding
User RSA, DSA or ECDSA public-private
key
Read,
Write
TLS Extensions User RSA, DSA or ECDSA private key Read
Other FIPS-related Services
Show status User None None
Self-test User None None
Zeroize User All aforementioned CSPs Zeroize
Module Installation Crypto
Officer
None None
Module Initialization Crypto
Officer
None None
Module configuration Crypto
Officer
None None
Table 7: Services Available in FIPS mode
The following table lists the services only available in non-FIPS mode of operation.
Service Role Keys Access
FIPS 186-4 RSA Key Generation,
Signature Generation/Verification with
modulus size smaller than 2048 bits or
greater than 3072 bits
User RSA private key Create,
Read
FIPS 186-2 RSA Key Generation User RSA private key Create
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 16 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
Service Role Keys Access
FIPS 186-4 RSA, DSA, ECDSA Signature
Generation/Verification with non-
Approved Message Digest algorithms
User RSA private key
DSA private key
ECDSA private key
Read
RSA Key Wrapping as part of the TLS
key exchange with modulus size
smaller than 2048 bits
User RSA private key Read
DSA key generation, signature
generation, signature verification with
public key size smaller than 2048 bits
and larger than 3072 bits
User DSA private key Create,
Read
Diffie-Hellman KAS with key sizes
smaller than 2048 bits
User Diffie-Hellman public-private keys Read
Diffie-Hellman with keys generated
with domain parameters other than
safe primes
User Diffie-Hellman public-private keys Read
Symmetric encryption and decryption
using AES GCM usage outside of
TLSv1.2 context, AES CTR, AES-SIV,
Blowfish, Camellia, ChaCha20, CAST
128, DES, Gost, RC2, RC4, Salsa20,
Serpent, or Twofish
User 8 to 2048 bits key Read
Message digest using GOST, MD2,
MD4, MD5, RIPEMD-160 or Streebog
256 and 512
User None None
MAC generation using UMAC, Poly1305 User MAC key Read
Asymmetric signature
generation/verification using Ed25519
curve, EdDSA
User EC private key Read
Support to use DANE Certificate User RSA, DSA and ECDSA private keys Read
Support to use OpenPGP Certificate User RSA, DSA and ECDSA private keys Read
Support to use PKCS#11 Certificate User RSA, DSA and ECDSA private keys Read
Support to use the Secure RTP (SRTP)
defined in RFC5764
User AES and HMAC keys Read
Support to use Trusted Platform Module
(TPM)
User RSA, DSA and ECDSA private keys Create,
Read
Table 8. Services Available in non-FIPS mode
Note: The module does not share CSPs between FIPS mode of operation and a non‐FIPS mode of
operation. All cryptographic keys used in the FIPS mode of operation must be generated in the
FIPS mode or imported while running in the FIPS mode. The DRBG shall not be used for key
generation for non-Approved services in non-FIPS mode.
More information about the services listed in Table 7: Services Available in FIPS mode can be found
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 17 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
in the manpages from the module.
3.3. Operator Authentication
The module does not implement authentication. The role is implicitly assumed based on the
service requested.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 18 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
4. Physical Security
The module comprises of software only and thus does not claim any physical security.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 19 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
5. Operational Environment
This module operates in a modifiable operational environment per the FIPS 140-2 definition.
5.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.
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 1.1.
5.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.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 20 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
6. Cryptographic Key Management
The following table summarizes the Keys and Critical Security Parameters (CSPs) that are used by
the cryptographic services implemented in the module in FIPS mode:
Keys/CSPs Generation Entry and Output Zeroization
128, 192 or
256 bits AES
key (used by
symmetric
encryption/dec
ryption
service)
N/A The key is passed into the
module via API input
parameters.
No output mechanism
provided.
Call
gnutls_cipher_deinit()
to zeroize the key.
128, 192 or
256 bits AES
key (used by
symmetric key
generation
service)
The key can be generated
by the SP 800-90A DRBG.
Key is output to caller in the
form of API output
parameter.
Call
gnutls_cipher_deinit()
to zeroize the key.
192 bits Triple-
DES key (used
by symmetric
encryption/dec
ryption
service)
N/A The key is passed into the
module via API input
parameters.
No output mechanism
provided.
Call
gnutls_cipher_deinit()
to zeroize the key.
192 bits Triple-
DES key (used
by symmetric
key generation
service)
The key can be generated
by the SP 800-90A DRBG.
Key is output to caller in the
form of API output
parameter.
Call
gnutls_cipher_deinit()
to zeroize the key.
At least 112
bits HMAC key
(used by
symmetric
encryption/dec
ryption
service)
N/A. The key is passed into the
module via API input
parameters.
No output mechanism
provided.
Call
gnutls_hmac_deinit()
to zeroize the key.
At least 112
bits HMAC key
(used by
symmetric key
generation
service)
The key can be generated
by the SP 800-90A DRBG.
Key is output to caller in the
form of API output
parameter.
Call
gnutls_hmac_deinit()
to zeroize the key.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 21 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
RSA public-
private key
The RSA public-private keys
with the modulus size of
2048 and 3072 bits are
generated using FIPS 186-4
RSA Key Generation
method and the random
value used in key
generation is generated
using SP 800-90A DRBG.
The key is passed into the
module via API input
parameters, or imported via
service calls.
The public-private keys can
be exported via service
calls, and the public key can
exit the module via TLS
protocol.
Call
gnutls_rsa_params_dei
nit(),
gnutls_privkey_deinit()
or
gnutls_x509_privkey_d
einit() to zeroize the
key.
DSA public-
private key
The DSA public-private keys
with the public key size of
2048 and 3072 bits are
generated using FIPS 186-4
DSA Key Generation
method and the random
value used in key
generation is generated
using SP 800-90A DRBG.
The key is passed into the
module via API input
parameters, or imported via
service calls.
The public-private keys can
be exported via service
calls and the public key can
exit the module via TLS
protocol.
Call
gnutls_privkey_deinit()
or
gnutls_x509_privkey_d
einit() to zeroize the
key.
ECDSA public-
private key
where the key
associated
with P-256, P-
384 or P-521
curve
The ECDSA public-private
keys are generated using
FIPS 186-4 ECDSA Key
Generation method and the
random value used in key
generation is generated
using SP 800-90A DRBG.
The key is passed into the
module via API input
parameters, or imported via
service calls.
The public-private keys can
be exported via service
calls and the public key can
exit the module via TLS
protocol.
Call
gnutls_privkey_deinit()
or
gnutls_x509_privkey_d
einit() to zeroize the
key.
Diffie-Hellman
public and
private keys
The domain parameters
used in Diffie-Hellman is
generated using SP 800-
90A DRBG, SP800-56Arev3.
The domain parameters are
passed into the module via
API input parameters, or
imported via service calls.
The domain parameters can
be exported via service
calls, and the generated
public key can exit the
module via TLS protocol.
Call or gnutls_deinit()
or
gnutls_dh_params_dei
nit() to zeroize the
Diffie-Hellman domain
parameters.
EC Diffie-
Hellman public
and private
keys
The components to
generate the public-private
keys used in EC Diffie-
Hellman is generated using
SP 800-90A DRBG, SP800-
56Arev3 and FIPS186-4.
The key is passed into the
module via API input
parameters.
The public key can exist the
module via TLS protocol.
Call gnutls_deinit() to
zeroize the EC public-
private keys.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 22 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
Shared Secret The shared secret is
generated by the module in
the Diffie-Hellman or EC
Diffie-Hellman shared
secret computation.
The module does not import
or export this CSP.
Call gnutls_deinit() to
zeroize the shared
secret.
Entropy Input
String
Obtained from CPU Jitter
source outside of the
module’s logical boundary
within the module's
physical boundary
The module does not import
or export the key or CSP.
Call
gnutls_global_deinit()
to zeroize the internal
state of the DRBG.
DRBG seed,
internal state
(V and Key)
Generated internally in the
DRBG
The module does not import
or export the key or CSP.
Call
gnutls_global_deinit()
to zeroize the internal
state of the DRBG.
TLS Pre-Master
Secret
Generated during the key
agreement when using
Diffie-Hellman or EC Diffie-
Hellman key exchange.
Generated by TLS client as
output from DRBG when
using RSA key exchange.
Entry: if received by module
as TLS server, wrapped with
server's public RSA key;
otherwise no entry. Output:
if generated by module as
TLS client, wrapped with
server's public RSA key;
otherwise, no output.
Call gnutls_deinit() to
zeroize the pre-master
secret
TLS Master
Secret
Derived from pre-master
secret using SP 800-135
KDF
Generated by the module.
No output.
Call gnutls_deinit() to
zeroize the master
secret
TLS-KDF
derived key
Derived
AES/Triple-DES/HMAC key
from SP800-135 TLS KDF
mechanisms
No output mechanism
provided.
Internal state is
zeroized automatically
when function returns
PBKDF
password
N/A The password is passed into
the module via API input
parameters.
Internal PBKDF state is
zeroized automatically
when function returns
PBKDF derived
key
Derived by SP800-132
PBKDF
The resulting key is output
through output parameters.
Internal PBKDF state is
zeroized automatically
when function returns
HKDF-KDF
Derived key
Derived SP800-56Crev1
HKDF KDF mechanisms
No output mechanism
provided.
Internal state is
zeroized automatically
when function returns
Table 9: Keys/CSPs
6.1. Random Number Generation
The module employs a Deterministic Random Bit Generator (DRBG) based on [SP800-90A] for the
creation of key components of asymmetric keys, symmetric keys, and random number generation.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 23 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
The module implements the CTR_DRBG with AES-256 without derivation function and without
prediction resistance. The CTR_DRBG is implemented in the libgnutls library and provides at least
128 bits of output data per each request.
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. This 384-bits of
entropy is the initial seed during initialization of the CTR_DRBG, and reseeding internally which
occurs less than 248
times of DRBG services request. The module obtains at least 384 bits of
entropy from the CPU Jitter source per each call. The caveat, “The module generates cryptographic
keys whose strengths are modified by available entropy” applies.
The module performs the DRBG health tests as defined in section 11.3 of [SP800-90A].
6.2. Key Generation
The Key Generation methods implemented in the module for Approved services in FIPS mode is
compliant with [SP800-133].
For generating RSA, DSA and ECDSA keys the module implements asymmetric key generation
services compliant with [FIPS186-4] and [SP800-90A]. A seed (i.e. the random value) used in
asymmetric key generation is directly obtained from the [SP800-90A] DRBG.
The public and private key pairs used in the Diffie-Hellman and EC Diffie-Hellman KAS are
generated internally by the module using key generation compliant with [SP800-56Arev3].
The module supports the generation of symmetric keys. Either gnutls_key_generate() or
gnutls_rnd() can be used to generate symmetric keys. Each will call the DRBG compliant to
[SP800-90A] to generate the key for symmetric keys or HMAC keys. Therefore, CKG (vendor
affirmed) is mentioned on the draft certificate.
6.3. Key Establishment/Key Derivation
The module provides Diffie-Hellman and EC Diffie-Hellman shared secret computation compliant
with SP800-56Arev3, in accordance with scenario X1 (1) of IG D.8. Diffie-Hellman shall use at least-
2048 bits key size and EC Diffie-Hellman shall use curves P-256, P-384 or P-521 curve in FIPS
mode. The Diffie-Hellman with less than 2048 bits key size is only available in non-FIPS mode.
The module provides Diffie-Hellman and EC Diffie-Hellman key agreement schemes compliant with
SP800-56rev3 and used as part of the TLS protocol key exchange in accordance with scenario X1
(2) of IG D.8; that is, the shared secret computation (KAS-FFC-SSC and KAS-ECC-SSC) followed by
the derivation of the keying material using SP800-135 KDF.
For Diffie-Hellman, the module supports the use of safe primes from RFC7919 for domain
parameters and key generation, which are used in the TLS key agreement implemented by the
module.
• TLS (RFC7919)
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 24 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
◦ ffdhe2048 (ID = 256)
◦ ffdhe3072 (ID = 257)
◦ ffdhe4096 (ID = 258)
◦ ffdhe6144 (ID = 259)
◦ ffdhe8192 (ID = 260).
The module also supports RSA key wrapping using encryption and decryption primitives with the
modulus size of at least 2048 bits in FIPS mode. The modulus size of 1024 bits is only available in
non-FIPS mode.
According to Table 2: Comparable strengths in NIST SP 800-57 Part1Rev5 (dated on May, 2020),
the key sizes of RSA, Diffie-Hellman and EC Diffie-Hellman provides the following security strength
for the corresponding key establishment method shown below:
• RSA key wrapping provides between 112 and 256 bits of encryption strength;
• Diffie-Hellman key agreement provides between 112 and 200 bits of encryption strength;
• Diffie-Hellman shared secret computation provides between 112 and 200 bits of encryption
strength;
• EC Diffie-Hellman key agreement provides between 128 and 256 bits of encryption
strength;
• EC Diffie-Hellman shared secret computation provides between 128 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-GCM and AES-CCM
• AES-CBC with HMAC used within the TLS protocol
• Triple-DES-CBC with HMAC used within the TLS protocol.
Therefore, the following caveats apply:
◦ KTS (AES Certs. #A1824, #A1825 and #A1830; key establishment methodology
provides 128 or 256 bits of encryption strength)
◦ KTS (AES Certs. #A1824, #A1825 and #A1830 and HMAC Certs. #A1825 and #A1830;
key establishment methodology provides 128 or 256 bits of encryption strength)
◦ KTS (Triple-DES Cert. #A1830 and HMAC Certs. #A1825 and #A1830; key establishment
methodology provides 112 bits of encryption strength)
Note: As the module supports the RSA key pair with 16384 bits or more modulus size, the
encryption strength 256 bits is claimed for RSA key wrapping.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 25 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
The module supports the following key derivation methods according to [SP800-135]:
• KDF for the TLS protocol, used as pseudo-random functions (PRF) for TLSv1.0/1.1 and
TLSv1.2.
The module supports the following key derivation methods according to [SP800-56C1]:
• HKDF for the TLS protocol TLSv1.3.
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.
6.4. Key Entry and Output
The module does not support manual key entry or intermediate key generation key output.
For symmetric algorithms or for HMAC, the keys are provided to the module via API input
parameters for the cryptographic operations. For asymmetric algorithms, the keys are also
provided to the module via API input parameters. The module also provides the services to import
and export public and private keys within the physical boundary of the module.
6.5. Key/CSP Storage
The module does not support persistent key storage. The keys and CSPs are stored as plaintext in
the RAM.
The symmetric keys and HMAC keys are provided to the module via API input parameters, and are
destroyed by the module using appropriate API function calls before they are released in the
memory.
Asymmetric public and private keys are provided to the module via API input parameters, and are
destroyed by the module using appropriate API function calls before they are released in the
memory.
The HMAC pre-computed value used for the integrity test is stored in the .hmac file and relies on
the operating system for protection. The HMAC key used to the integrity test is stored in the
module’s binary.
6.6. Key/CSP Zeroization
The memory occupied by keys is allocated by regular libc malloc/calloc() calls. The application that
uses the module is responsible for calling the appropriate destruction functions from the GnuTLS
API to zeroize the keys or keying material. The destruction functions then overwrite the memory
occupied by keys with pre-defined values and deallocates the memory with the free() 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.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 26 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
7. 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
7.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. Generally, Information Technology
Equipment (ITE) product compliance is based on IEC and CISPR standards and their national
equivalent such as Product Safety, IEC 60950-1 and European Norm EN 60950-1 or EMC, CISPR
22/CISPR 24 and EN 55022/55024. Dell products have been verified to comply with the EU RoHS
Directive 2011/65/EU. Dell products do not contain any of the restricted substances in
concentrations and applications not permitted by the RoHS Directive.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 27 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
8. Self-Tests
FIPS 140-2 requires that the module perform power-up tests to ensure the integrity of the module
and the correctness of the cryptographic functionality at start up. In addition, some functions
require continuous testing of the cryptographic functionality, such as the asymmetric key
generation. If any self-test fails, the module returns an error code and enters the error state. No
data output or cryptographic operations are allowed in error state.
See section 10.2 for descriptions of possible self-test errors and recovery procedures.
8.1. Power-Up Tests
The module performs power-up self-tests automatically when the module is loaded into memory;
power-up tests ensure that the module is not corrupted and that the cryptographic algorithms
work as expected. Input, output, and cryptographic functions cannot be performed while the
module is in a self-test state because the module is single-threaded and will not return to the
calling application until the power-up self-tests are completed. If any power-up self-test fails, the
module returns the error code listed in section 10.2 and displays “Error in GnuTLS initialization”
with the specific error message associated with the returned error code, and then enters the error
state. The subsequent calls to the module will also fail - thus no further cryptographic operations
are possible. If the power-up self-tests complete successfully, the module will return 0 and accepts
cryptographic operation services request.
8.1.1. Integrity Tests
The integrity of the module is verified by comparing an HMAC-SHA-256 value calculated at run
time with the HMAC value stored in the .hmac file that was computed at build time for each
component of the module. If the HMAC values do not match, the test fails and the module enters
the error state.
8.1.2. Cryptographic Algorithm Test
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 Power-Up Tests
AES • KAT AES-CBC/GCM/CCM/CMAC encryption
• KAT AES-CBC/GCM/CCM/CMAC decryption
Triple-DES • KAT Triple-DES-CBC encryption
• KAT Triple-DES-CBC decryption
HMAC • KAT HMAC-SHA-1
• KAT HMAC-SHA-224
• KAT HMAC-SHA-256
• KAT HMAC-SHA-384
• KAT HMAC-SHA-512
SHS • KATs for SHA2 are covered in the KATs for HMAC as allowed with IG
9.1
• SHA3-224, SHA3-256, SHA3-384, SHA3-512
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 28 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
Algorithm Power-Up Tests
DSA • KAT DSA 2048-bit key with SHA-256 signature generation
• KAT DSA 2048-bit key with SHA-256 signature verification
RSA • KAT RSA 2048-bit key with SHA-256 signature generation
• KAT RSA 2048-bit key with SHA-256 signature verification
ECDSA • KAT ECDSA (NIST P-256, P-384 and P-521) signature generation
• KAT ECDSA (NIST P-256, P-384 and P-521) signature verification
Diffie-Hellman Primitive "Z" Computation KAT
EC Diffie-Hellman Primitive "Z" Computation KAT with P-256 curve
DRBG KAT CTR_DRBG with AES-256 bit
DRBG DRBG health tests as specified in section 11.3 of NIST SP 800-90Ar1
PBKDF KAT
TLSv1.2 KDF KAT
HKDF KAT
Table 10: Power-Up Self-Tests
For the KAT, the module calculates the result and compares it with the known value. If the answer
does not match the known answer, the KAT is failed and the module returns the error code and
enters the error state.
As described in section 1.2, only one AES or SHA implementation from libnettle library written in C
language or using the support from AES-NI or SSSE3 instructions is available at run-time. The KATs
cover different implementations dependent on the implementations availability in the operating
environment.
8.2. On-Demand Self-Tests
The on-demand self-tests is invoked by powering-off and reloading the module which causes the
module to run the power-up tests again. During the execution of the on-demand self-tests,
services are not available and no data output or input is possible.
8.3. Conditional Tests
The module performs conditional tests on the cryptographic algorithms, using the pair-wise
consistency test (PCT), shown in the following table:
Algorithm Conditional Tests
DSA key generation Pairwise consistency test: signature
generation and verification using SHA-
256
ECDSA key generation Pairwise consistency test: signature
generation and verification using SHA-
256
RSA key generation Pairwise consistency test: signature
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 29 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
Algorithm Conditional Tests
generation and verification using SHA-
256.
Pairwise consistency test: encryption and
decryption
Table 11: Module Conditional Tests
For the PCT, if the signature generation or verification fails, the module returns the error code and
enters the error state.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 30 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
9. Guidance
9.1. Crypto Officer Guidance
The binaries of the module are delivered via Red Hat Package Manager (RPM) packages. The
Crypto Officer shall follow this Security Policy to configure the operational environment and install
the module to be operated as FIPS 140-2 validated module.
The following version of the RPM packages containing the FIPS validated module and the operating
environment settings:
Processor Architecture RPM packages
x86_64 gnutls-3.6.16-4.el8.x86_64.rpm
gmp-6.1.2-10.el8.x86_64.rpm
nettle-3.4.1-7.el8.x86_64.rpm
Table 12: RPM packages
The RPM packages 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, yum, rpm, and
the RHN remote management tool).
FIPS module installation instructions:
10. 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 enablement 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.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 31 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
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.
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
- 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.
Once the operating environment has been configured to support FIPS, it is not possible to switch
back to standard mode without terminating the module first.
Module Installations:
The Crypto Officer can install the RPM packages contains the module listed in Table 12: RPM
packages based on the processor architecture. The integrity of the RPM is automatically verified
during the installation of the module and the Crypto Officer shall not install the RPM file if the RPM
tool indicates an integrity error.
10.1. User Guidance
The applications must be linked dynamically to run the module. Only the services listed in Table 7:
Services Available in FIPS mode are allowed to be used in FIPS mode.
The libraries of GMP and Nettle provides the support of cryptographic operations to the GnuTLS
library. The operator shall use the API provided by the GnuTLS library for the services. Invoking the
APIs provided by the supporting libraries are forbidden.
10.1.1. TLS and Diffie-Hellman
The TLS protocol implementation provides both, the server and the client sides. As required by
SP800-131A, For Diffie-Hellman only the safe prime groups listed in RFC7919 are approved to be
used in FIPS mode. The TLS protocol cannot enforce the support of FIPS Approved Diffie-Hellman
key sizes. To ensure full support for all TLS protocol versions, the TLS client implementation of the
cryptographic module must accept Diffie-Hellman key sizes smaller than 2048 bits offered by the
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 32 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
TLS server.
The TLS server implementation of the cryptographic Module allows the application to set the Diffie-
Hellman key size. The server side must always set the DH parameters with the API call of:
SSL_CTX_set_tmp_dh(ctx, dh)
Alternatively it is possible to use SSL_CTX_set_dh_auto(ctx, 1); function call that makes GnuTLS
use built-in 2048 bit parameters when the server RSA certificate is at least 2048 bits and 3072 bit
DH parameters with RSA certificate of 3072 bits.
To comply with the FIPS 140-2 standard the requirement to not allow Diffie-Hellman key sizes
smaller than 2048 bits must be met, to do this the Crypto Officer must ensure that:
• in case the Module is used as TLS server, the Diffie-Hellman parameters (dh argument) of
the aforementioned API call must be 2048 bits or larger;
• in case the Module is used as TLS client, the TLS server must be configured to only offer
Diffie-Hellman keys of 2048 bits or larger.
Using DH parameters and keys smaller than 2048 bits will implicitly place the module into non-
FIPS mode, as specified in section 1.2 of the Security Policy.
10.1.2. AES-GCM
In case the module’s power is lost and then restored, a new key for use with the AES GCM
encryption/decryption shall be established (as defined in IG A.5 scenario 3 option 3 for IV
restoration conditions).
The AES GCM IV generation is in compliance with the [RFC5288] and shall only be used for the TLS
protocol version 1.2 to be compliant with [FIPS140-2_IG] IG A.5. Any use of AES GCM outside of
TLSv1.2 context is considered non-approved; thus, the module is compliant with [SP800-52Rev2
section 3.3.1]
If the nonce_explicit part of the IV exhausts, GnuTLS will mark the TLS session as invalid and the
IV will need to be renegotiated.
10.1.3. RSA and DSA Keys
The module allows the use of 1024 bit RSA and DSA keys for legacy purposes, including signature
generation.
As per SP800-131A, RSA and DSA must be used at least 2048 bit keys in FIPS mode. To comply
with the requirements of [FIPS140-2], the operator must therefore only use keys with at least 2048
bits in FIPS mode.
10.1.4. Triple-DES
According to IG A.13, it’s the user’s responsibility to make sure that the same Triple-DES key shall
not be used to encrypt more than 216 64- bit blocks of data.
10.1.5. Key derivation using SP800-132 PBKDF
The module provides password-based key derivation (PBKDF), compliant with SP800-132. The
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 33 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
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], 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.2. Handling Self-Test Errors
When the module fails any self-test, it will return an error code to indicate the error and enters
error state that any further cryptographic operations is inhibited. Here is the list of error codes
when the module fails any self-test or in error state:
Error Events Error Codes Error Messages
When the integrity test,
KAT or PCT fails at the
power-up
GNUTLS_E_SELF_TEST_ERROR
(-400)
“Error while performing self
checks.”
When the KAT of DRBG fails
at the power-up
GNUTLS_E_RANDOM_FAILED
(-206)
“Failed to acquire random
data.”
When the new generated
RSA, DSA or ECDSA key
pair fails the PCT
GNUTLS_E_PK_GENERATION_ERROR
(-403)
“Error in public key
generation.”
When the module is in error
state and caller requests
cryptographic operations
GNUTLS_E_LIB_IN_ERROR_STATE
(-402)
"An error has been detected in
the library and cannot
continue operations."
Table 13: Error Events, Error Codes and Error Messages
Self-test errors transition the module into an error state that keeps the module operational but
prevents any cryptographic related operations. The module must be restarted and perform power-
up self-test to recover from these errors. If failures persist, the module must be re-installed. When
downloading the module, the Crypto Officer shall confirm from the RPM tool that the module was
downloaded properly.
A completed list of the error codes can be found in Appendix C “Error Codes and Descriptions” in
the gnutls.pdf provided with the module's code.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 34 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
11. Mitigation of Other Attacks
RSA is vulnerable to timing attacks. In a setup where attackers can measure the time of RSA
decryption or signature operations, blinding is always used to protect the RSA operation from that
attack.
The internal API function of rsa_blind() and rsa_unblind() are called by the module for RSA
signature generation and RSA decryption operations. The module generates a random blinding
factor and include this random value in the RSA operations to prevent RSA timing attacks.
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 35 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
12. Glossary and Abbreviations
AES Advanced Encryption Specification
AES-NI Advanced Encryption Standard New Instructions
API Application Program Interface
CAVP Cryptographic Algorithm Validation Program
CBC Cypher Block Chaining
CMVP Cryptographic Module Validation Program
CSP Critical Security Parameter
CTR Counter Mode
CVL Component Validation List
DES Data Encryption Standard
DRBG Deterministic Random Bit Generator
DSA Digital Signature Algorithm
DTLS Datagram Transport Layer Security
ECC Elliptic Curve Cryptography
FFC Finite Field Cryptography
FIPS Federal Information Processing Standards Publication
GCM Galois Counter Mode
GPC General Purpose Computer
HMAC Hash Message Authentication Code
IG Implementation Guidance
KAS Key Agreement Schema
KAT Known Answer Test
MAC Message Authentication Code
NIST National Institute of Science and Technology
O/S Operating System
PCT Pair-wise Consistency Test
RHEL Red Hat Enterprise Linux
RPM Red Hat Package Manager
RSA Rivest, Shamir, Addleman
SHA Secure Hash Algorithm
SSSE3 Supplemental Streaming SIMD Extensions 3
TLS Transport Layer Security
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 36 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
13. References
FIPS140-2 FIPS PUB 140-2 - Security Requirements For Cryptographic Modules
December 2002
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf
FIPS140-2_IG Implementation Guidance for FIPS PUB 140-2 and the Cryptographic
Module Validation Program
December 2019
https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Module-Validation-
Program/documents/fips140-2/FIPS1402IG.pdf
FIPS180-4 Secure Hash Standard (SHS)
August 2015
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf
FIPS186-4 Digital Signature Standard (DSS)
July 2013
http://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
RFC4347 Datagram Transport Layer Security
April 2006
https://tools.ietf.org/html/rfc4347.txt
RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2
August 2008
https://tools.ietf.org/html/rfc5246.txt
RFC5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS
August 2008
https://tools.ietf.org/html/rfc5288.txt
RFC6520 Transport Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) Heartbeat Extension
February 2012
https://tools.ietf.org/html/rfc6520.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
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 37 of 38
Red Hat Enterprise Linux 8 GnuTLS Cryptographic Module rhel8.20210628
FIPS 140-2 Non-proprietary Security Policy
SP800-52 NIST Special Publication 800-52 Revision 2 - Guidelines for the
Selection, Configuration, and Use of Transport Layer Security (TLS)
Implementations
August 2019
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.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
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
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf
SP800-135 NIST Special Publication 800-135 Revision 1 - Recommendation for
Existing Application-Specific Key Derivation Functions
December 2011
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-135r1.pdf
© 9/28/22 Red Hat®, Inc./atsec information security. This document can be reproduced and distributed only
whole and intact, including this copyright notice. 38 of 38