Red Hat Enterprise Linux OpenSSL Cryptographic Module version 7.0 FIPS 140-2 Non-proprietary Security Policy version 1.3 Last Update: 2019-09-19 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy Table of Contents 1. Cryptographic Modules' Specifications.......................................................................................................3 1.1. Description of the Module........................................................................................................................3 1.2. Description of the Approved Modes.........................................................................................................4 1.3. Cryptographic Boundary..........................................................................................................................7 1.3.1. Hardware Block Diagram...........................................................................................................8 1.3.2. Software Block Diagram.............................................................................................................9 2. Cryptographic Modules' Ports and Interfaces...........................................................................................10 3. Roles, Services and Authentication..........................................................................................................11 3.1. Roles..................................................................................................................................................... 11 3.2. Services................................................................................................................................................. 11 3.3. Operator Authentication.........................................................................................................................12 3.4. Mechanism and Strength of Authentication...........................................................................................12 4. Physical Security......................................................................................................................................13 5. Operational Environment..........................................................................................................................14 5.1. Applicability............................................................................................................................................ 14 5.2. Policy..................................................................................................................................................... 14 6. Cryptographic Key Management..............................................................................................................15 6.1. Random Number and Key Generation..................................................................................................15 6.2. Key/Critical Security Parameter (CSP)..................................................................................................15 6.3. Key/CSP Storage..................................................................................................................................16 6.4. Key/CSP Zeroization.............................................................................................................................16 7. Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC).................................................17 7.1. Statement of compliance.......................................................................................................................17 8. Self-Tests.................................................................................................................................................. 18 8.1. Power-Up Tests.....................................................................................................................................18 8.2. Conditional Tests...................................................................................................................................19 9. Guidance.................................................................................................................................................. 20 9.1. Crypto Officer Guidance........................................................................................................................20 9.2. User Guidance......................................................................................................................................21 9.2.1. TLS and Diffie-Hellman............................................................................................................21 9.2.2. AES-XTS Guidance..................................................................................................................21 9.2.3. Random Number Generator.....................................................................................................21 9.2.4. AES-GCM IV............................................................................................................................22 9.2.5. Triple-DES Keys.......................................................................................................................22 9.2.6. RSA and DSA Keys..................................................................................................................22 9.2.7. Handling Self-Test Errors.........................................................................................................22 10. Mitigation of Other Attacks......................................................................................................................24 11. Glossary and Abbreviations....................................................................................................................25 12. References............................................................................................................................................. 26 © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 2 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy 1. Cryptographic Modules' Specifcations This document is the non-proprietary Security Policy for the Red Hat Enterprise Linux OpenSSL Cryptographic Module version 7.0 and was prepared as part of the requirements for conformance to Federal Information Processing Standard (FIPS) 140-2, Level 1. 1.1. Description of the Module The Red Hat Enterprise Linux OpenSSL Cryptographic Module (hereafter referred to as the “Module”) is a software libraries supporting FIPS 140-2 Approved cryptographic algorithms. The code base of the Module is formed in a combination of standard OpenSSL shared library, OpenSSL FIPS Object Module and development work by Red Hat. The Module provides a C language application program interface (API) for use by other processes that require cryptographic functionality. 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 Specifcation 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 Table 1: Security Level of the Module The Red Hat Enterprise Linux OpenSSL Cryptographic Module has been tested on the following multi-chip standalone platforms: Manufact urer Model O/S & Ver. Processor Dell PowerEdge R630 Red Hat Enterprise Linux 7 Intel(R) Xeon(R) CPU E5 Table 2: Test Platform The Module has been tested for the following confgurations: • 32-bit library, x86_64 with and without AES-NI enabled • 64-bit library, x86_64 with and without AES-NI enabled. 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 © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 3 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy 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.) 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 sufcient security strength can be used. • in "non-FIPS mode" (the non-Approved mode of operation) non-approved security functions can also be used. The Module verifes the integrity of the runtime executable using a HMAC-SHA-256 digest computed at build time. If the digests matched, the power-up self-test is then performed. The module enters FIPS mode after power-up tests succeed. Once the module is operational, the mode of operation is implicitly assumed depending on the security function invoked and the security strength of the cryptographic keys. The Red Hat Enterprise Linux OpenSSL Cryptographic Module supports the following FIPS 140- 2 Approved algorithms in FIPS Approved mode: Algorithm Validation Certifcate Standards/Usage Keys/CSPs AES Certs. #C 297, #C 302, #C 303, #C 304, #C 316, #C 321, #C 327, #C 328, #C 329 and #C 336 FIPS 197 (AES) SP 800-38A (ECB, CBC, OFB, CFB1, CFB8, CFB128, CTR) SP 800-38B (CMAC) SP 800-38C (CCM) SP 800-38D (GCM, GMAC) SP 800-38E (XTS) SP 800-38F (KW, KWP)1 Encryption and Decryption AES keys 128 bits, 192 bits (except XTS-AES) and 256 bits Triple-DES Certs. #C 297, #C 302, #C 329 and #C 336 SP 800-67 SP 800-38A (ECB, CBC, OFB, CFB1, CFB64, CTR) SP 800-38B (CMAC) Encryption and Decryption Triple-DES keys 168 bits DSA Certs. #C 297, #C 302, #C 329 and #C 336 FIPS 186-4 Domain Parameters Generation and Verifcation, Key Generation, DSA keys: • L=2048, N=224 • L=2048, N=256 • L=3072, N=256 Note: 1024 bit DSA 1 Not all block chaining modes apply to all CAVS certificates. © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 4 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy Algorithm Validation Certifcate Standards/Usage Keys/CSPs Signature Generation signature verifcation is legacy-use. RSA Certs. #C 297, #C 302, #C 329 and #C 336 FIPS 186-4 Appendix B.3.3 Key Generation RSA keys: • 1024 bits • 2048 bits • 3072 bits Note: 1024 bit RSA signature verifcation is legacy-use. Signature Generation and Verifcation (ANSI X9.31 and PKCS#1 v1.5) ECDSA Certs. #C 297, #C 302, #C 329 and #C 336 FIPS 186-4 Key Pair Generation and Public Key Verifcation ECDSA keys based on P-256, P-384, or P-521 curve FIPS 186-4 Signature Generation FIPS 186-4 Signature Verifcation DRBG Certs. #C 297, #C 302, #C 303, #C 304, #C 316, #C 321, #C 327, #C 328, #C 329 and #C 336 SP 800-90A (Hash_DRBG, HMAC_DRBG, CTR_DRBG) Random Number Generation Entropy input string, seed, V and Key SHS Certs. #C 297, #C 302, #C 303, #C 304, #C 316, #C 321, #C 327, #C 328, #C 329 and #C 336 FIPS 180-4 (SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) Hashing N/A HMAC Certs. #C 297, #C 302, #C 303, #C 304, #C 316, #C 321, #C 327, #C 328, #C 329 and #C 336 FIPS 198-1 (HMAC- SHA-1, HMAC-SHA- 224, HMAC-SHA- 256, HMAC-SHA- 384, HMAC-SHA- 512) Message Integrity At least 112 bits HMAC Key © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 5 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy Algorithm Validation Certifcate Standards/Usage Keys/CSPs SP 800-56A DLC primitive Dife-Hellman (CVL) CVL Certs. #C 297, #C 302, #C 329 and #C 336 SP 800-56A Key Agreement and Establishment Public key size 2048 bits or larger, and private key size 224 bits or 256 bits SP 800-56A DLC primitive EC Dife-Hellman (CVL) NIST curves P-256, P- 384, P-521 SP 800-135 Section 4.2 Key Derivation in TLS v1.0, v1.1 and v1.2 (CVL) CVL Certs. #C 297, #C 302, #C 316, #C 321, #C 329 and #C 336 SP800-135 Key Derivation in TLS None Table 3: Approved Algorithms The Module supports the following non-Approved algorithms but allowed in FIPS Approved mode: Algorithm Usage Keys/CSPs RSA (encrypt, decrypt) with key size equal or larger than 2048 bits Key Wrapping RSA private keys Dife-Hellman with public key size 2048 bits or larger and private key size 224 bits or 256 bits Key Agreement Dife-Hellman private keys EC Dife-Hellman with key sizes according to P-256, P-384 and P-521 NIST curves Key Agreement EC Dife-Hellman private keys MD5 Message Digest used only in TLS N/A NDRNG Seeding the module's DRBG Internal state Table 4: Non-Approved but allowed Algorithms According to Table 2: “Comparable strengths” in NISP SP 800-57 Part1 (dated on March 8, 2007), the key sizes of RSA, Dife-Hellman and EC Dife-Hellman provides the following security strength for the corresponding key establishment method shown below: 1. RSA (key wrapping; key establishment methodology provides 112 or 128 bits of encryption strength; non-compliant less than 112 bits of encryption strength) 2. Dife-Hellman (key agreement; key establishment methodology provides 112 or 128 bits of encryption strength; non-compliant less than 112 bits of encryption strength) 3. EC Dife-Hellman (key agreement; key establishment methodology provides between 128 and 256 bits of encryption strength) However, the size alone does not determine the security strength of the RSA, Dife-Hellman and EC Dife-Hellman keys. Since the seed source for key generation is outside the logical boundary of the module, the following caveat is applicable: © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 6 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy The module generates cryptographic keys whose strengths are modifed by available entropy 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 those Module are ported and executed in an operational environment not listed on the validation certifcate. The Module supports the following non-FIPS 140-2 Approved algorithms, which shall not be used in the FIPS Approved mode. Any use of the non-Approved functions will cause the Module to operate in the non-FIPS mode implicitly: Algorithm Usage Keys/CSPs RSA (encrypt, decrypt) with key size smaller than 2048 bits key wrapping RSA keys RSA with key sizes not listed in Table 3 sign, verify, and key generation RSA keys DSA with key sizes not listed in Table 3 sign, verify, and key generation DSA keys Dife-Hellman with key sizes not listed in Table 4 key agreement and establishment Dife-Hellman keys ANSI X9.31 RNG (with AES-128 core) random number generation PRNG seed value and seed key 128 bits Camellia Encryption/decryption Symmetric key CAST Encryption/decryption Symmetric key DES Encryption/decryption Symmetric key IDEA Encryption/decryption Symmetric key MD2 Hash function N/A MD4 Hash function N/A RC2 Encryption/decryption Symmetric key RC4 Encryption/decryption Symmetric key RC5 Encryption/decryption Symmetric key RIPEMD Hash function N/A Whirlpool Hash function N/A Table 5: Non-Approved Algorithms 1.3. Cryptographic Boundary The Modules' physical boundaries are the surface of the case of the platform (depicted in the hardware block diagram). The Red Hat Enterprise Linux OpenSSL Cryptographic Module logical cryptographic boundary is the shared library fles and their integrity check HMAC fles, which are delivered through Red Hat Package Manager (RPM) as listed below. The openssl-libs-1.0.2k-16.el7_6.1.x86_64.rpm (64 bits) and openssl-libs-1.0.2k- © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 7 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy 16.el7_6.1.i686.rpm (32 bits) fle contains the following fles that are part of the module boundary: • /usr/lib{64,}/.libcrypto.so.1.0.2k.hmac • /usr/lib{64,}/.libssl.so.1.0.2k.hmac • /usr/lib{64,}/libcrypto.so.1.0.2k • /usr/lib{64,}/libssl.so.1.0.2k The OpenSSL RPM package of the Module includes the binary fles, integrity check HMAC fles, Man Pages and the OpenSSL Engines provided by the standard OpenSSL shared library. The OpenSSL Engines and their shared object fles are not part of the Module, and therefore they must not be used. The Module shall be installed and instantiated by the dracut-fps package with the RPM fle version specifed above. The dracut-fps RPM package is only used for the installation and instantiation of the Module. This code is not active when the Module is operational and does not provide any services to users interacting with the Module. Therefore the dracut-fps RPM package is outside the Modules' logical boundary. 1.3.1. Hardware Block Diagram Figure 1: Hardware Block Diagram © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 8 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy 1.3.2. Software Block Diagram Figure 2: Software Block Diagram (the cryptographic boundary includes the HMAC integrity fles) © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 9 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy 2. Cryptographic Modules' 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). 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 Modules' Interfaces Data Input Ethernet ports API input parameters, kernel I/O – network or fles on flesystem Data Output Ethernet ports API output parameters, kernel I/O – network or fles on flesystem Control Input Keyboard, Serial port, Ethernet port, Network API function calls, or confguration fles on flesystem Status Output Serial port, Ethernet port, Network API Power Input PC Power Supply Port N/A Table 6: Ports and Interfaces © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 10 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy 3. Roles, Services and Authentication This section defnes the roles, services, and authentication mechanisms and methods with respect to the applicable FIPS 140-2 requirements. 3.1. Roles There are two users of the Module: • User • Crypto Ofcer The User and Crypto Ofcer roles are implicitly assumed by the entity accessing services implemented by the Module. For User documentation, please refer to the man pages of ssl(3), crypto(3) as an entry into the Modules' API documentation for SSL/TLS and generic crypto support. Installation of the Module is only done by the Crypto Ofcer. 3.2. Services The Module supports services that are available to users in the various roles. All of the services are described in detail in the Modules’ user documentation. The following tables show the services available to the various roles and the access to cryptographic keys and CSPs resulting from services. The following table lists the Approved services available in FIPS Approved mode. Please refer to Table 4 and 5 for the Approval key size of each algorithm used in the services. Service Role CSPs Access Symmetric encryption/decryption User AES and Triple-DES key read/write/execute Asymmetric key generation User RSA, DSA and ECDSA private key read/write/execute Digital signature generation and verifcation User RSA, DSA and ECDSA private key read/write/execute TLS network protocol User AES or Triple-DES key, HMAC Key read/write/execute TLS key agreement User AES or Triple-DES key, RSA, DSA or ECDSA private key, HMAC Key, Premaster Secret, Master Secret, Dife-Hellman Private Components and EC Dife-Hellman Private Components read/write/execute RSA key wrapping User RSA, private key read/write/execute Certifcate Management/ Handling User RSA, DSA or ECDSA private key parts of certifcates read/write/execute Keyed Hash (HMAC) User HMAC Key read/write/execute Keyed Hash (CMAC) User CMAC key read/write/execute Message digest (SHS) User none read/write/execute Random number User Entropy input string and seed (C, K read/write/execute © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 11 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy Service Role CSPs Access generation (SP800-90A DRBG) and V values) Show status User none execute Module initialization User none execute Self-test User none read/execute Zeroize User All aforementioned CSPs read/write/execute Module installation Crypto Ofcer none read/write Table 7: Approved Service Details The following table lists the non-Approved services available in non-FIPS mode. Please refer to Table 6 for the non-Approved key size of each algorithm. Service Role Access Asymmetric encryption/decryption using non-Approved RSA key size User read/write/execute Symmetric encryption/decryption using non-Approved algorithms User read/write/execute Hash operation using non-Approved algorithms User read/write/execute Digital signature generation and verifcation using non-Approved RSA and DSA private key User read/write/execute TLS connection using keys established by Dife-Hellman with non-Approved key sizes User read/write/execute Asymmetric key generation using non-Approved RSA and DSA key size User read/write/execute Random number generation using ANSI X9.31 RNG User read/write/execute Table 8: Non-Approved Service Details Note: The Module does not share CSPs between an Approved mode of operation and a non‐ Approved mode of operation. All cryptographic keys used in the FIPS-Approved mode of operation must be generated in the FIPS-Approved mode or imported while running in the FIPS-Approved mode. If the DRBG is used for key generation for non-Approved services in non- FIPS mode, reseeding the DRBG before and after the key generation is mandatory. More information about the services and their associated APIs can be found in the Man Pages included in the rpm packages. The evp(3) is the starting point of the Man Pages. 3.3. Operator Authentication At security level 1, authentication is neither required nor employed. The role is implicitly assumed on entry. 3.4. Mechanism and Strength of Authentication At security level 1, authentication is not required. © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 12 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy 4. Physical Security The Module is comprised of software only and thus does not claim any physical security. © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 13 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy 5. Operational Environment 5.1. Applicability 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 Atomic Host • 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 modifable operational environment per FIPS 140-2 level 1 specifcations. The module runs on a commercially available general-purpose operating system executing on the hardware specifed in section 1.2. 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 the operational mode, the ptrace(2) system call, the debugger (gdb(1)), and strace(1) shall be not used. © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 14 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy 6. Cryptographic Key Management 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. 6.1. Random Number and Key Generation The Module provides an SP800-90A-compliant Deterministic Random Bit Generator (DRBG) for creation of key components of asymmetric keys, and random number generation. The /dev/urandom from the Operational Environment is used as a source of random numbers for DRBG seeds and entropy input string. The Module performs continuous self-tests on the output of SP800-90A DRBG to ensure that consecutive random numbers do not repeat. Moreover, the module performs the health tests for the SP800-90A DRBG as defned per section 11.3 of SP800-90A. 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]. 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 Dife-Hellman and EC Dife-Hellman KAS are generated internally by the module using the same DSA and ECDSA key generation compliant with [FIPS186-4] which is compliant with [SP800-56A]. The NDRNG provides 256 bits of entropy to the DRBG. 6.2. Key/Critical Security Parameter (CSP) An authorized application as user (i.e., the User role) has access to all key data generated during the operation of the Module. The following table summarizes the Critical Security Parameters (CSPs) that are used by the cryptographic services implemented in the module: Key/CSP Generation Storage Zeroization AES Symmetric Key N/A(passed in as API input parameter) Alternatively, key can be established during a TLS handshake RAM EVP_CIPHER_CTX_cleanup() Triple-DES Symmetric Key HMAC Key HMAC_CTX_cleanup() CMAC Key CMAC_CTX_cleanup() RSA Private Key Generated using FIPS 186-4 RAM RSA_free() © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 15 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy Key/CSP Generation Storage Zeroization key generation method and the random value used in the key generation is generated using SP800-90A DRBG. DSA Private Key DSA_free() ECDSA Private Key EC_GROUP_clear_free() and EC_POINT_clear_free() Dife-Hellman Private Components Generated as specifed in SP800-56A and the random value used in the key generation is generated using SP800-90A DRBG. RAM DH_free() EC Dife-Hellman Private Components EC_GROUP_clear_free() and EC_POINT_clear_free() SP 800-90A DRBG seed and entropy input (C, K, V values) Obtained from NDRNG RAM FIPS_drbg_free() TLS Pre-Master Secret and Master Secret Established during the TLS handshake RAM SSL_free() and SSL_clear() Table 9: Key Life Cycle 6.3. 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 CSPs. 6.4. Key/CSP Zeroization The memory occupied by keys is allocated by regular libc malloc/calloc() calls. The application is responsible for calling the appropriate destruction functions from the OpenSSL API. The destruction functions then overwrite the memory occupied by keys with pre-defned 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. © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 16 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy 7. Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) MARKETING NAME......................…. PowerEdge R630 REGULATORY MODEL................….. E26S REGULATORY TYPE.....................…. E26S001 EFFECTIVE DATE..........................… September 03, 2014 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 afxed 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 verifed 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. © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 17 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy 8. Self-Tests FIPS 140-2 requires that the Module performs self-tests to ensure the integrity of the Module, and the correctness of the cryptographic functionality at start up. In addition, some functions require continuous verifcation of function, such as the Random Number Generator. All of these tests are listed and described in this section. No operator intervention is required during the running of the self-tests. See section 9.3 for descriptions of possible self-test errors and recovery procedures. 8.1. Power-Up Tests The Module performs both power-up self-tests (at module initialization) and continuous conditional tests (during operation). The power-up self test start with the integrity test, where the FIPS_mode_set() function verifes the integrity of the runtime executable using a HMAC SHA-256 digest, which is computed at build time. If this computed HMAC SHA-256 digest matches the stored, known digest, then the rest of the power-up self-test (consisting of the algorithm-specifc Pairwise Consistency and Known Answer Tests) is performed. Input, output, and cryptographic functions cannot be performed while the Module is in a self-test or error state because the Module is single-threaded and will not return to the calling application until the power-up self-tests are complete. After successful completion of the power-up tests, the module is loaded and cryptographic functions are available for use. If the power-up self-tests fail, subsequent calls to the Module will also fail - thus no further cryptographic operations are possible. Algorithm Test AES KAT, encryption and decryption are tested separately Triple-DES KAT, encryption and decryption are tested separately DSA Pairwise consistency test (PCT), sign and verify RSA KAT, signature generation and verifcation are tested separately ECDSA PCT, sign and verify Dife-Hellman Primitive "Z" Computation KAT EC Dife-Hellman Primitive "Z" Computation KAT SP 800-90A CTR_DRBG KAT SP 800-90A Hash_DRBG KAT SP 800-90A DRBG_HMAC KAT HMAC-SHA-1, -244, -256, -384, -512 KAT SHA-1, -224, -256, -384, -512 KAT CMAC KAT Module integrity HMAC-SHA-256 Table 10: Modules' Self-Tests © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 18 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy 8.2. Conditional Tests Algorithm Test DSA PCT: signature generation and verifcation ECDSA PCT: signature generation and verifcation RSA PCT: signature generation and verifcation, encryption and decryption Table 11: Modules' Conditional Tests © 2019 Red Hat/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 19 of 26 Red Hat Enterprise Linux OpenSSL Cryptographic Module FIPS 140-2 Non-proprietary Security Policy 9. Guidance 9.1. Crypto Ofcer Guidance The version of the RPM containing the FIPS validated Module is stated in section 1. 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, yum, rpm, and the RHN remote management tool). The integrity of the RPM is automatically verifed during the installation of the Module and the Crypto Ofcer shall not install the RPM fle if the RPM tool indicates an integrity error. The OpenSSL static libraries libcrypto.a and libssl.a in openssl-static package are not approved to be used. The applications must be dynamically linked to run the OpenSSL. 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, yum, rpm, and the RHN remote management tool).For proper operation of the in-module integrity verifcation, the prelink has to be disabled. 1 Disable the prelink: # sed -i 's/PRELINKING=yes/PRELINKING=no/g' /etc/sysconfig/prelink 2 Run following command to return binaries to a non-prelink state: # /usr/sbin/prelink -ua Crypto ofcer should perform the following for Module initialization: 1. Install the dracut-fps package: # yum install dracut-fips 2. Recreate the INITRAMFS image: # dracut -f After regenerating the initramfs, the Crypto Ofcer has to append the following string to the kernel command line by changing the setting in the boot loader: fips=1 If /boot or /boot/ef resides on a separate partition, the kernel parameter boot=