Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module v2.0 FIPS 140-2 Security Policy Version 1.4 Last Update: 2013-04-03 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy Contents 1 Cryptographic Module Specification......................................................................................................................3 1.1 Description of Module ..................................................................................................................................3 1.2 Description of Modes of Operations..............................................................................................................4 1.3 Cryptographic Module Boundary.................................................................................................................5 1.3.1 Hardware Block Diagram .........................................................................................................................6 1.3.2 Software Block Diagram............................................................................................................................7 1.4 Red Hat Enterprise Linux 6.2 Cryptographic Modules and FIPS 140-2 Certification...................................7 1.4.1 Platforms...................................................................................................................................................8 1.4.2 FIPS Approved Mode................................................................................................................................8 2 Cryptographic Module 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 Key Life Cycle Table...................................................................................................................................15 6.2 Key Zeroization...........................................................................................................................................15 6.3 Random Number Generation .....................................................................................................................15 7 Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) .........................................................16 8 Self Tests ............................................................................................................................................................17 8.1 Power-Up Tests...........................................................................................................................................17 8.1.1 Software Integrity Test.............................................................................................................................17 9 Guidance.............................................................................................................................................................18 9.1 Cryptographic Officer Guidance..................................................................................................................18 9.2 User Guidance............................................................................................................................................19 9.3 Handling Self Test Errors ...........................................................................................................................19 10 Mitigation of Other Attacks...............................................................................................................................20 10.1 NSS...........................................................................................................................................................20 11 Glossary and Abbreviations.............................................................................................................................21 12 References........................................................................................................................................................23 © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 2 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy 1 Cryptographic Module Specification This document is the non-proprietary security policy for the Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module, and was prepared as part of the requirements for conformance to Federal Information Processing Standard (FIPS) 140-2, Level 1. The following section describes the module and how it complies with the FIPS 140-2 standard in each of the required areas. 1.1 Description of Module The Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module is a software only cryptographic module that provides disk management and transparent partial or full disk encryption. Partial disk encryption encrypts only one or more partitions, leaving at least one partition as plaintext. Full disk encryption ensures that the entire disk is encrypted, including any Swap partition, but excluding /boot. The following table shows the overview of the security level for each of the eleven sections of the validation. Security Component 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 Table 1: Security Levels The module has been tested on the following multi-chip standalone platforms: Manufacturer Model O/S & Ver. HP Proliant DL585 Red Hat Enterprise Linux 6.2 (In Single User Mode) IBM HS22 Red Hat Enterprise Linux 6.2 (In Single User Mode) Table 2: Tested Platforms The files that make up the module are: the contents of cryptsetup-luks-libs RPM package (version 1.2.0-6.el6) • the contents of the fipscheck RPM package (version 1.2.0-7.el6) • © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 3 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy the contents of the fipscheck-lib RPM package (version 1.2.0-7.el6) • kernel module /lib/modules/$(uname -r)/kernel/drivers/md/dm-crypt.ko • the dracut-fips package with the version of the RPM file of 004-284.el6_3.1. This RPM version is • provided with RHBA:2012-1318 accessible on the Red Hat Network. the OpenSSL FIPS 140-2 module with the certificate #1758 (bound module) • the NSS FIPS 140-2 module with the certificate #1837 (bound module) • the libgcrypt FIPS 140-2 module defined with the certificate #1757 (bound module) • the kernel crypto API FIPS 140-2 module defined with the certificate #1901 (bound module) • The installer uses LVM (logical volume manager) to provide transparent storage space management. LVM is implemented using device mapper enabling setup of the following basic configurations: 1. disk | dm-crypt | <- (application) 2. disk | LVM PV | LVM LVs | dm-crypt | <- (application) 3. disk | dm-crypt | LVM PV | LVM LVs| <- (application) In configuration 1, the installer supports encryption on a disk partition without using LVM. In configuration 2, the installer supports encryption on a LV (logical volume) in LVM. In this case, only part of the LVM is encrypted. For example, the root partition is unencrypted, but the homes volume is encrypted. In configuration 3, the installer supports encryption on a disk partition, which is a PV (physical volume) for LVM. In this case, the encryption is under LVM, everything is encrypted and LVM just allocates space over some encrypted device. The module is a FIPS 140-2 security level 1 multichip standalone module. The Linux platform is configured in single user mode. 1.2 Description of Modes of Operations The module must always be configured as outlined in section 9.1. The module can be operated in FIPS mode or non-FIPS mode depending on what cryptographic functions are invoked. The table outlines the approved and non-approved functions provided by the specified components (for specific algorithm modes supported please see the Security Policy for the external FIPS 140-2 modules referenced). © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 4 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy Component Approved functions Non-approved functions Kernel Crypto API AES encrypt / decrypt 128,192, 256 bit CTR mode (internal counter source) Cryptographic Module (Certs. #1968, #1969, #1970, #1971 and CBC encryption mode without the performing the encryption #1972) use of ESSIV IV handling and decryption of file mechanism SHA1, SHA224, SHA384, SHA512 (Certs. system data and integrity check. DES #1725 and #1726) XTS using AES192; although Triple-DES encrypt / decrypt (Certs #1278 (FIPS 140-2 Cert# 1901) technically usable, CAVS currently and #1279) does not provide a means to test it DSA (Certs #628 and #629) Libgcrypt Cryptographic HMAC-SHA-1, HMAC-SHA224, HMAC- N/A Module supporting the SHA256, HMAC-SHA384, HMAC-SHA512 libcryptsetup LUKS volume (Certs. #1128, #1131, #1132 and #1133) key management, key SHA1, SHA224, SHA256, SHA384, generation, and integrity SHA512 (Certs. #1657, #1660, #1661 and check. #1662) (FIPS 140-2 Cert# 1757) RNG (X9.31) (Certs. #988, #991, #992 and #993) OpenSSL Cryptographic HMAC-SHA256 (Certs. #1129, #1130, N/A Module supporting the #1134 and #1135) integrity check of SHA256 (Certs. #1658, #1659, #1663 and libcryptsetup. #1664) (FIPS 140-2 Cert# 1758) NSS Cryptographic Module HMAC-SHA512 (Certs. #1199 and #1200) N/A used by sha512hmac DSA (Certs. #634 and #635) performing its own integrity SHA512 (Certs. #1741 and #1742) check and the integrity check of the static kernel binary. (FIPS 140-2 Cert# 1837) libcryptsetup performing the PBKDF as specified in SP800-132 section basic (plain) dm-crypt mappings without using the LUKS extensions volume key management 5.3 protecting the volume key according to operations using the LUKS SP800-132 section 5.4 Option 2a format The non-approved functions shall not be used in FIPS approved mode. The following list references the documents where the list of all non-approved algorithms beyond those callable via the Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module are specified: Kernel Crypto API: see Security Policy of Kernel Crypto API • © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 5 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy Ligcrypt: see API documentation provided with libgcrypt • OpenSSL: see man page API documentation provided with libgcrypt • NSS: see Security Policy of NSS • 1.3 Cryptographic Module Boundary The Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module physical boundary is defined by the surface of the case of the test platform. The logical module boundary is depicted in the software block diagram. 1.3.1 Hardware Block Diagram This figure illustrates the various data, status and control paths through the cryptographic module. The physical boundary consists of the opaque enclosure surrounding the COTS PC system. The module consists of standard integrated circuits, including processors, and memory. The module does not include any security-relevant, semi- or custom integrated circuits or other active electronic circuit elements. The physical module includes power inputs and outputs, and internal power supplies. The cryptographic boundary contains only the security-relevant software elements that comprise the module. Figure 1: Hardware Block Diagram Figure 2: Hardware Block Diagram © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 6 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy 1.3.2 Software Block Diagram Figure 2:Software Block Diagram 1.4 Red Hat Enterprise Linux 6.2 Cryptographic Modules and FIPS 140-2 Certification A set of kernel cryptographic libraries, services and user level cryptographic applications are certified at FIPS 140-2 level 1, providing a secure foundation for vendor use in developing dependent services, applications, and © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 7 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy even purpose built appliances that may be FIPS 140-2 certified. The certification is performed at FIPS 140-2 level 1, a software only certification that does not make any claims about the hardware enclosure. This allows vendors to develop their own higher level FIPS 140-2-certified modules using cryptographic modules. The following cryptographic modules are included in the RHEL6.2 certification: 1 Kernel Crypto API - a software only cryptographic module that provides general-purpose cryptographic services to the remainder of the Linux kernel 2 Disk Volume Encryption - provides disk management and transparent partial or full disk encryption; Partial disk encryption encrypts only one or more partitions, leaving at least one partition as plaintext. 3 Libgcrypt- supplies general cryptographic support for the Red Hat Enterprise Linux user space 4 OpenSSL - a software library supporting cryptographic algorithms for general use by vendors 5 OpenSSH-Server - supplies cryptographic support for the SSH protocol 6 OpenSSH-Client - supplies cryptographic support for the SSH protocol 7 Openswan - provides the IKE protocol version 1 key agreement services required for IPSec 1.4.1 Platforms The certification was performed on a 64-bit system, which are capable of executing both 32 and 64-bit code concurrently. Vendors can "transfer" the FIPS 140-2 certificate to the other similar platforms, provided the binary is only recompiled without changing the code. This is called a vendor assertion. 1.4.2 FIPS Approved Mode Any vendor-provided FIPS certified cryptographic modules and services that use the RHEL6.2 underlying services to provide cryptographic functionality must use the RHEL6.2 services in their approved mode. Only operating in the approved mode ensures that FIPS 140-2 required self tests are executed and that ciphers are restricted to those that have been FIPS 140-2 certified by independent testing. This section is given as guidance to developers to ensure the use cases are conformant with the initialization of the module. Although the modules always operate in FIPS mode when following the guidance, the initialization of the FIPS 140-2 module may consist of several phases which may be preempted by developers, but not administrators or users. The following explanation describes the initialization phase to ensure the FIPS 140-2 module initializes correctly. If dm-crypt is used to encrypt a disk or partition, particularly when other modules may store cryptographic keys or other CSPs (critical security parameters) there, it must be in FIPS approved mode as described in dm-crypt Security Policy. Since the kernel is in the approved mode, the remaining RHEL6.2 FIPS services (Crypto API, OpenSSL, Openswan, OpenSSH) start up in the approved mode by default. (Note that Openswan uses NSS for its cryptographic operations and NSS must explicitly be put into the approved mode with the modutil command.) The approved mode for a module becomes effective as soon as the module power on self tests complete successfully and the module loads into memory. Self tests and integrity tests triggered in RHEL6.2 at startup or on the first invocation of the crypto module: kernel: during boot, before dm-crypt becomes available via dracut • user space: before the user space module is available to the caller (i.e. for libraries during the • initialization call, for applications: at load time) © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 8 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy See each module security policy for descriptions of self tests performed by each module and descriptions of how self test errors are reported for each module. © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 9 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy 2 Cryptographic Module Ports and Interfaces Function Port Command In Libcryptsetup API, /proc/sys/crypto/fips_enabled, kernel command line option of “fips” Status Out Libcryptsetup API Data In Kernel system calls for file system write-like requests for devices protected by dm-crypt. Data Out Kernel system calls for file system read-like requests for devices protected by dm-crypt. Table 3: Ports and Interfaces © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 10 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 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 Role Services User Kernel system calls on file system objects stored on devices protected by • dm-crypt Crypto Officer Installation • Generation and protection of volume key • Setup dm-crypt mapping, obtaining and insertion of volume key into kernel • Protect volume key with one or more passphrases • Self Tests • Show Status • Deconfigure dm-crypt mapping and zeroization of volume key • Table 4: Roles 3.2 Services Table 5 shows services that use or affect stored cryptographic keys or CSPs. For each service, the key or CSP is indicated along with the type of access. This table only covers the approved services. R- The item is read or referenced by the service W- The item is written or updated by the service Z- The item is zeroized by the service Service Category Function Role Cryptographic Keys Access Type and CSPs Accessed (RWZ) Kernel system Symmetric Kernel system User, crypto Volume key R calls on file Cipher, hash calls operating officer system objects on file system stored on objects devices protected by dm- crypt Generation and RNG Libcryptsetup Crypto officer Passphrase RZ protection of PBKDF API call volume key Volume key RWZ Setup dm-crypt PBKDF Libcryptsetup Crypto officer Passphrase RZ mapping, API call obtaining and Volume key RZ insertion of volume key into © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 11 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy Service Category Function Role Cryptographic Keys Access Type and CSPs Accessed (RWZ) kernel Protect volume PBKDF Libcryptsetup Crypto officer Passphrase RZ key with one or API call more Volume key RWZ passphrases Self Tests Self Test Invoked by Crypto officer Software integrity Key R (includes restarting the Integrity and module known answer tests) Show Status Status Libcryptsetup Crypto officer None N/A API call Deconfigure dm- None Libcryptsetup Crypto officer Volume key Z crypt mapping API call and zeroization of volume key Installation None None Crypto officer None N/A Table 5: Services For additional services provided by the cryptographic module components that are FIPS 140-2 modules in their own right, please see the respective Security Policies. 3.3 Operator Authentication There is no operator authentication. The assumption of a role is implicit by the action taken. 3.4 Mechanism and Strength of Authentication At security level 1, authentication is not required. © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 12 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy 4 Physical Security The Module is comprised of software only and thus does not claim any physical security. © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 13 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy 5 Operational Environment 5.1 Applicability This module will operate in a modifiable operational environment per the FIPS 140-2 specifications. 5.2 Policy The operating system shall be restricted to a single operator mode of operation (i.e., concurrent operators are explicitly excluded). The application that makes calls to the cryptographic module is the single user of the cryptographic module, even when the application is serving multiple clients. The ptrace(2) system call, debugger(gdb(1)), and strace(1) shall not be used. In addition, other tracing mechanisms offered by the Linux environment, such as ftrace or systemtap shall not be used. © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 14 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy 6 Cryptographic Key Management The following table identifies the Cryptographic Keys and Critical Security Parameters (CSPs) used within the module. Cryptographic keys and CSPs are never output from the module in plaintext. An Approved key generation method is used to generate keys that are generated on the module. 6.1 Key Life Cycle Table Key Type Generation Establishm Access by Entry and Storage Zeroization or Source ent Role/Servic Output of Input e Method Server Side Cryptographic Keys and CSPs Volume Key AES 128, libgcrypt N/A Data N/A Stored in Zeroized on 192, or 256- RNG encryption - encrypted a zeroize bits decryption form command TDES 168 (PBKDF) bits Software DSA 2048- Generated N/A Software N/A Stored in Zeroized on Integrity Key bit off the integrity test plaintext a zeroize HMAC SHA- module (POST) form command 256 HMAC SHA- 512 Table 7: Cryptographic Keys and CSPs Notes: The module ships without containing any keys and CSPs. When the module is configured, the crypto officer generates a volume key per dm-crypt mapping. Each volume key is stored in the first blocks of the disk device hosting the respective dm-crypt mapping. 6.2 Key Zeroization For volatile memory, memset is included in deallocation operations. There are no restrictions when zeroizing any cryptographic keys and CSPs. 6.3 Random Number Generation Libcryptsetup uses the random number generator provided by libgcrypt for generating the volume key. Please see the Security Policy of libgcrypt for details on the random number generation and the seeding of of the random number. © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 15 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy 7 Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) Product Name and Model: HP ProLiant Server DL585 Series Regulatory Model Number: HSTNS-1025 Product Options: All EMC: Class A Product Name and Model: IBM BladeCenter HS22 Series Regulatory Model Number: 09-EMCRTP-0008 Product Options: All EMC: Class A © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 16 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy 8 Self Tests 8.1 Power-Up Tests The module performs a power-on self test (POST) consisting of the software integrity test (using fipscheck) to verify the integrity of libcryptsetup. If the module fails the integrity test the module halts operation. Cryptographic algorithms and critical security functions are provided by the cryptographic components constituting FIPS 140-2 modules in their own right that are listed in section 1.1. All algorithms and critical security functions are tested during initialization of those modules. 8.1.1 Software Integrity Test The integrity check is implemented separately for validating the kernel space and the user space components. The integrity check of all components provided with the kernel is described in the kernel crypto API Security Policy. The integrity check of the user space components of the module is performed by the application fipscheck invoked during the startup of libcryptsetup when requesting cryptographic operations. When the module starts, it exercises the software integrity test. The user space integrity verification is performed as follows: 1. The libcryptsetup library links with the library libfipscheck.so which is intended to execute fipscheck to verify the integrity of the calling library file using HMAC SHA-256. Upon calling the FIPSCHECK_verify() function provided with libfipscheck.so, the fipscheck application is loaded and executed. 2. fipscheck loads and initializes the OpenSSL library which performs the integrity check of the OpenSSL library files using HMAC SHA-256. 3. The application fipscheck performs the integrity check of its application file as well as the libfipscheck.so library file using HMAC SHA-256 with the cipher provided by OpenSSL. 4. The fipscheck application performs the integrity check of the calling library. The fipscheck computes the HMAC SHA-256 checksum of the file and compares the computed value to the value stored inside the /path/to/library/..hmac checksum file. The fipscheck application returns the appropriate exit value based on the comparison result (zero if the checksum is OK – which is enforced by the libfipscheck.so library). © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 17 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy 9 Guidance This section provides guidance for the Cryptographic Officer and the User to maintain proper use of the module per FIPS 140-2 requirements. 9.1 Cryptographic Officer Guidance The version of the RPM containing the validated module is stated in section 1.1 above. The integrity of the RPM is automatically verified during the installation and the crypto officer shall not install the RPM file if the RPM tool indicates an integrity error. 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 verification, the prelink has to be disabled. This can be done by setting PRELINKING=no in the /etc/sysconfig/prelink configuration file. Existing prelinking, if any, should be undone on all the system files using the 'prelink -u -a' command. To bring the module into FIPS approved mode, perform the following: Install the dracut-fips package: # yum install dracut-fips Recreate the INITRAMFS image: # dracut -f After regenerating the initrd, the crypto officer 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/efi resides on a separate partition, the kernel parameter boot= must be supplied. The partition can be identified with the command "df /boot" or "df /boot/efi" respectively. For example: $ df /boot Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 233191 30454 190296 14% /boot The partition of /boot is located on /dev/sda1 in this example. Therefore, the following string needs to be appended to the kernel command line: "boot=/dev/sda1" Reboot to apply these settings. FIPS 140-2 and AES-NI support According to the kernel crypto API FIPS 140-2 security policy, the kernel crypto API module supports the AES-NI Intel processor instruction set as an approved cipher. The AES-NI instruction set is used by the kernel module. In case you configured a full disk encryption using AES, you may use the AES-NI support for a higher performance compared to the software-only implementation. © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 18 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy To utilize the AES-NI support, the mentioned kernel module must be loaded during boot time by installing a plugin. Before you install the plugin, you MUST verify that your processor offers the AES-NI instruction set by calling the following command: cat /proc/cpuinfo | grep aes If the command returns a list of properties, including the I string, your CPU provides the AES-NI instruction set. If the command returns nothing, AES-NI is not supported. You MUST NOT install the following plugin if your CPU does not support AES-NI because the kernel will panic during boot. The support for the AES-NI instruction set during boot time is enabled by installing the following plugin (make sure that the version of the plugin RPM matches the version of the installed RPMs!): # install the dracut-fips-aesni package rpm -Uhv dracut-fips-aesni-*.noarch.rpm # recreate the initramfs image dracut -f The changes come into effect during the next reboot. Configuration Changes and FIPS Approved Mode Use care whenever making configuration changes that could potentially prevent access to the fips_enabled flag (fips=1) in the file /proc/sys/crypto/fips_enabled. If the module does not detect this flag during initialization, it does not enable the FIPS approved mode. All user space modules depend on this file for transitioning into FIPS 140-2 approved mode. 9.2 User Guidance See the header file lib/libcryptsetup.h provided with the cryptsetup SRPM for developer information about the API. See the cryptsetup(8) man page for general usage documentation for cryptsetup and LUKS extensions. Except for the cryptographic officer accessing the volume key using cryptsetup, no other users shall access the volume key. Besides cryptsetup, no other application may be used to manage dm-crypt module (either through libcryptsetup, libdevmapper,or using direct kernel dm-ioctl interface). 9.3 Handling Self Test Errors OpenSSL, Kernel Crypto API, and libgcrypt self test failures may prevent dm-crypt from operating. See the Guidance section in those Security Policies for instructions on handling self test failures. The dm-crypt self test consists of the software integrity test. If the integrity test fails, dm-crypt enters an error state. The only recovery from this type of failure is to reinstall the dm-crypt module including the kernel. If you downloaded the software, verify the package hash to confirm a proper download. © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 19 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy 10 Mitigation of Other Attacks 10.1 NSS The following is taken from the FIPS 140-2 Security Policy documents of the NSS module: Other Attacks Mitigation Mechanism Specific Limitations Cache-timing attacks on the Cache invariant modular This mechanism requires intimate modular exponentiation operation exponentiation knowledge of the cache line sizes of used in DSA the processor. The mechanism may This is a variant of a modular be ineffective when the module exponentiation implementation that is running on a processor whose Colin Percival [4] showed to defend cache line sizes are unknown. against cache-timing attacks. © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 20 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy 11 Glossary and Abbreviations AES Advanced Encryption Specification CAVP Cryptographic Algorithm Validation Program CBC Cypher Block Chaining CCM Counter with Cipher Block Chaining-Message Authentication Code CC Common Criteria CMVP Cryptographic Module Validation Program COTS Commercial Off-the-Shelf CSP Critical Security Parameter CVT Component Verification Testing DES Data Encryption Standard DSA Digital Signature Algorithm EAL Evaluation Assurance Level EMC Electromagnetic Compatibility EMI Electromagnetic Interference ESSIV Encrypted Salt Sector for IV FSM Finite State Model HMAC Hash Message Authentication Code LV Logical Volume LVM Logical Volume Manager NIST National Institute of Science and Technology NVLAP National Voluntary Laboratory Accreditation Program O/S Operating System POST Power-on Self Test PP Protection Profile PV Physical Volume RNG Random Number Generator RSA Rivest, Shamir, Addleman SAP Service Access Points SHA Secure Hash Algorithm SHS Secure Hash Standard SLA Service Level Agreement SOF Strength of Function © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 21 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy SHS Secure Hash Standard SVT Scenario Verification Testing TDES Triple-DES TOE Target of Evaluation UI User Interface Table 8: Abbreviations © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 22 of 23 Red Hat Enterprise Linux 6.2 dm-crypt Cryptographic Module Version 2.0 FIPS 140-2 Security Policy 12 References The following references are available on the CMVP website at http://csrc.nist.gov/groups/STM/cmvp/standards.html#02: [1] National Institute of Standards and Technology, FIPS PUB 140-2: Security Requirements for Cryptographic Modules [2] National Institute of Standards and Technology, FIPS 140-2 Annex A: Approved Security Functions [3] National Institute of Standards and Technology, FIPS 140-2 Annex B: Approved Protection Profiles [4] National Institute of Standards and Technology, FIPS 140-2 Annex C: Approved Random Number Generators [5] National Institute of Standards and Technology, FIPS 140-2 Annex D: Approved Key Establishment Techniques [6] National Institute of Standards and Technology and Communications Security Establishment, Derived Test Requirements (DTR) for FIPS PUB 140-2, Security Requirements for Cryptographic Modules [7] National Institute of Standards and Technology, Data Encryption Standard (DES), Federal Information Processing Standards Publication 46-3 [8] National Institute of Standards and Technology, DES Modes of Operation, Federal Information Processing Standards Publication 81 [9] National Institute of Standards and Technology, Digital Signature Standard (DSS), Federal Information Processing Standards Publication 186-2 [10] National Institute of Standards and Technology, Secure Hash Standard (SHS), Federal Information Processing Standards Publication 180-1 © 2013 Red Hat / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 23 of 23