RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 982152 - cryptsetup does not work in FIPS mode
Summary: cryptsetup does not work in FIPS mode
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: cryptsetup
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ondrej Kozina
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-08 09:23 UTC by Michal Toman
Modified: 2021-09-06 15:04 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-09 11:59:24 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Michal Toman 2013-07-08 09:23:17 UTC 
Description of problem:
I'm using RHEL7 with encrypted root and home. Booting into FIPS mode fails when trying to unlock root and drops me into emergency shell. Trying to unlock the device manually using cryptsetup fails with the following error:

# cryptsetup luksOpen /dev/sda2 root
FIPS checksum verification failed.

Version-Release number of selected component (if applicable):
cryptsetup-1.6.1-1.el7.x86_64
dracut-fips-029-1.el7.x86_64
fipscheck-lib-1.3.1-3.el7.x86_64
kernel-3.10.0-0.rc7.64.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Enable FIPS mode in RHEL7
2. Try to unlock an encrypted device

Actual results:
FIPS checksum verification failed.

Expected results:
The device is unlocked and registered to device mapper.
Comment 2 Ondrej Kozina 2013-07-08 11:48:33 UTC 
Please, could you supply output from: ls -l /usr/lib{,64}/fipscheck/libcryptsetup.*
Comment 3 Ondrej Kozina 2013-07-08 11:55:27 UTC 
turn off FIPS mode temporary, in case you have rootfs on encrypted device...
Comment 4 Michal Toman 2013-07-08 12:00:53 UTC 
$ ls -l /usr/lib{,64}/fipscheck/libcryptsetup.*
ls: cannot access /usr/lib/fipscheck/libcryptsetup.*: No such file or directory
-rw-r--r--. 1 root root 65 Apr  4 15:32 /usr/lib64/fipscheck/libcryptsetup.so.4.5.0.hmac
-rw-r--r--. 1 root root 65 Apr  4 15:32 /usr/lib64/fipscheck/libcryptsetup.so.4.hmac
Comment 5 Ondrej Kozina 2013-07-08 14:33:56 UTC 
OK. Maybe we are getting somewhere. I installed a fresh RHEL7 and everything worked as intended in FIPS mode. So far, it looks like you have something wrong with checksum files in initramfs image (provided you have encrypted device with root filesystem and you need to open it before rootfs is mounted)

Could you please unpack your initramfs image and look for libcryptsetup checksum files? It will be at the same location inside the image: <initramfs_image>/usr/lib64/fipscheck/libcryptsetup.so.4.5.0.hmac.

In case the checksum files are missing (there should be also checksum for cryptsetup cmd line binary), try to run dracut -f -M once again, to see which modules are actually included in your initramfs image.

In case both files (cryptsetup.hmac and libcryptsetup...) are present, try to run following command and paste the output here, please:

FIPSCHECK_DEBUG=error fipscheck /usr/lib64/libcryptsetup.so.4; echo $?
FIPSCHECK_DEBUG=error fipscheck /usr/sbin/cryptsetup; echo $?
Comment 6 Ondrej Kozina 2013-07-08 14:39:09 UTC 
Oh! Concerning the last 2 commands: I need the output from an emergency shell, after the failure
Comment 7 Michal Toman 2013-07-09 08:30:04 UTC 
(In reply to Ondrej Kozina from comment #5)
> OK. Maybe we are getting somewhere. I installed a fresh RHEL7 and everything
> worked as intended in FIPS mode. So far, it looks like you have something
> wrong with checksum files in initramfs image (provided you have encrypted
> device with root filesystem and you need to open it before rootfs is mounted)
This is exactly the case

The checksums got pulled into initramfs:
# ls -l /usr/lib64/fipscheck/
total 20
-rw-r--r-- 1 root 0 65 Apr  4 15:32 cryptsetup.hmac
-rw-r--r-- 1 root 0 65 Mar 16 16:59 fipscheck.hmac
-rw-r--r-- 2 root 0 65 Apr  4 15:32 libcryptsetup.so.4.5.0.hmac
-rw-r--r-- 2 root 0 65 Apr  4 15:32 libcryptsetup.so.4.hmac
-rw-r--r-- 1 root 0 65 Mar 16 16:59 libfipscheck.so.1.1.0.hmac
lrwxrwxrwx 1 root 0 26 Jul  8 22:57 libfipscheck.so.1.hmac -> libfipscheck.so.1.1.0.hmac

# FIPSCHECK_DEBUG=error fipscheck /usr/lib64/libcryptsetup.so.4; echo $?
fipscheck: FIPS_mode_set() failed
14

# FIPSCHECK_DEBUG=error fipscheck /usr/sbin/cryptsetup; echo $?
fipscheck: FIPS_mode_set() failed
14
Comment 8 Tomas Mraz 2013-07-09 09:25:10 UTC 
We need also the .hmac files from the openssl-libs package for the fipscheck to work. These are:

/usr/lib64/.libcrypto.so.1.0.1e.hmac
/usr/lib64/.libcrypto.so.10.hmac
/usr/lib64/.libssl.so.1.0.1e.hmac
/usr/lib64/.libssl.so.10.hmac
/usr/lib64/libcrypto.so.1.0.1e
/usr/lib64/libcrypto.so.10
/usr/lib64/libssl.so.1.0.1e
/usr/lib64/libssl.so.10
Comment 9 Michal Toman 2013-07-09 10:03:49 UTC 
These are also present:

# ls -l <the list>
-rw-r--r-- 1 root 0      65 May 10 19:20 /usr/lib64/.libcrypto.so.1.0.1e.hmac
lrwxrwxrwx 1 root 0      25 Jul  9 11:49 /usr/lib64/.libcrypto.so.10.hmac -> .libcrypto.so.1.0.1e.hmac
-rw-r--r-- 1 root 0      65 May 10 19:20 /usr/lib64/.libssl.so.1.0.1e.hmac
lrwxrwxrwx 1 root 0      22 Jul  9 11:49 /usr/lib64/.libssl.so.10.hmac -> .libssl.so.1.0.1e.hmac
-rwxr-xr-x 1 root 0 1960312 May 10 19:20 /usr/lib64/libcrypto.so.1.0.1e
lrwxrwxrwx 1 root 0      19 Jul  9 11:49 /usr/lib64/libcrypto.so.10 -> libcrypto.so.1.0.1e
-rwxr-xr-x 1 root 0  441920 May 10 19:20 /usr/lib64/libssl.so.1.0.1e
lrwxrwxrwx 1 root 0      16 Jul  9 11:49 /usr/lib64/libssl.so.10 -> libssl.so.1.0.1e

Running fipscheck on libssl or libcrypto results into the same behavior as on cryptsetup:

# FIPSCHECK_DEBUG=error fipscheck /usr/lib64/libcrypto.so.1.0.1e; echo $?
fipscheck: FIPS_mode_set() failed
14

# FIPSCHECK_DEBUG=error fipscheck /usr/lib64/libssl.so.1.0.1e; echo $?
fipscheck: FIPS_mode_set() failed
14

Here's the list of modules that dracut pulls:

# dracut -f -M
fips
i18n
drm
plymouth
crypt
dm
kernel-modules
resume
rootfs-block
terminfo
udev-rules
biosdevname
systemd
usrmount
base
fs-lib
shutdown

I have openssl-libs-1.0.1e-8.el7.x86_64 installed.
Comment 10 Michal Toman 2013-07-09 10:19:06 UTC 
One thing that comes to my mind is that all the .hmac files seem to contain 256-bit long hashes. In my initramfs, I can only see /usr/bin/sha512hmac and /usr/lib64/hmaccalc/sha512hmac.hmac
Comment 11 Tomas Mraz 2013-07-09 10:40:21 UTC 
hmaccalc and sha512hmac is not used by fipscheck and cryptsetup.
Comment 12 Tomas Mraz 2013-07-09 10:43:43 UTC 
Are the libcrypto and libssl files exactly the same as in vanilla openssl-libs-1.0.1e-8.el7 package?

Do you have prelink disabled?
Comment 13 Michal Toman 2013-07-09 10:58:52 UTC 
Although I didn't have prelink installed, installing it and unprelinking everything fixed the problem. Thank you for your quick responses and consider this NOTABUG.
Comment 14 Ondrej Kozina 2013-07-09 11:59:24 UTC 
More on that in comment #12 and #13
Comment 15 Ondrej Kozina 2013-07-09 12:44:32 UTC 
For anyone experiencing same chain of errors, please look into:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-Federal_Standards_And_Regulations-Federal_Information_Processing_Standard.html, chapter 7.2.1, item 1:

You have to use prelink -u -a command before creating initramfs image every time unless you are absolutely sure there is no prelinked binary or library in your system.
Note You need to log in before you can comment on or make changes to this bug.