Issue with automatic partition decryption

Ask Fedora
1

I’m new to the Fedora distro, however, have been a RHEL and CentOS admin for many years.

I just installed Fedora 33 Server using the Anaconda installer, booting off a LIve USB to configure and install this system. /dev/sda and /dev/sdb contain my /boot / swap /var and /home partitions and are NVMe drives, partitions are mirrored using mdadmin. /dev/sdc is a 50 TB /files partition (GPT) off an Adaptec RAID card (RAID5), it is encrypted using LUKS. I set this all up using Anaconda. When I boot up a process called plymouth (I think) asks me for the passphrase and my encrypted /files partitions mounts and works properly. None of my other partitions are encrypted, just /files.

I have a TPM2 module installed on the mobo (ASrock Rack) and I want to use this to do auto-decryption of /files, so I ran the following command post-boot (as root):

clevis luks bind -d /dev/sdc1 tpm2 ‘{“pcr_ids”:“0,1,2,3,4,5,6,7”}’

This appears to have worked, because I can successfully test by first umount /files and cryptsetup luksClose /dev/mapper/luks-blahblah, and then run:

clevis luks unlock -d /dev/sdc1

…and mount it manually. So clevis appears to be working, but when I boot or reboot the machine, even with clevis configured this way, plymouth is still prompting to enter a passphrase to decrypt the partition. The system just hangs there until I do so. I would like to run this system headless, so this is a bit of an issue I’d like to resolve.

I have tried different combinations of values for pcr_ids, like just using 0 or 1, but that doesn’t seem to change the behavior. I’m not sure if this is a clevis, plymouth or systemd issue; although I suspect the latter two more so than clevis, currently.

I should mention also, this is my first time using TPM2 and clevis; I have used TPM with trousers before.

I assume I am missing something obvious in my configuration here. For example, in the boot process, how does systemd know to call clevis instead of plymouth prompting for a passphrase?

Any help or guidance would be appreciated.

Thank you!

-Mike

2 Likes
2

search with DuckDuckGo, (hate google) yielded this result.

3

Thanks for the reference, but that’s not entirely related. Fedora already has a method for accomplishing what that article is describing, however, using LUKSv2, TPM2 and clevis. In the case of Fedora 33, it appears that plymouth is prompting for a password even though it doesn’t require one (i.e. the decryption method already exists, and either it’s not being used, or plymouth doesn’t recognize the partition is already decrypted).

4

I got it working following the instructions from the clevis git repo and some other website which recommends to use pcr 7, as it is also used for secure boot.
So for me, it was as simple as running
clevis luks bind -d /dev/sdaX tpm2 '{"pcr_ids":"7"}' to create the clevis keyslot for the luks device and then
dracut -f to regenerate the initramfs.
The following reboot showed a password prompt for my harddrive, BUT when I do not type anything and simply wait for a minute, then my system would suddenly be started up!

So maybe the solution for you is as simple as running dracut -f and waiting some time after the reboot.

5

Current (scanty) documentation shows LUKS binding examples without PCR bindings, or with binding to PCR 7/8/9 only (or either of it).

This is highly insecure!

This is no better than just storing plaintext encryption key in the motherboard’s NVRAM or it TPM NVRAM. It’s suitable only for ‘binding’ LUKS key to that exact TPM/motherboard, to prevent the disk to be decrypted without obtaining the PC, but no more. Anyone with physical access to this PC can extract LUKS encryption key in any OS, by booting from USB for example, in 5 minutes, without any obstacles, hacks or workarounds, just by using standard TPM tools.

Now about PCR 7/8/9: these are not measured by UEFI, but updated by the bootloader (GRUB2). This is as insecure as absence of PCR bindings, but the attacker would need to perform one extra step to obtain decryption key: to measure these values right as GRUB2 would do, these are public and usually are a measures of GRUB commands, kernel and initramfs.

It seems that currently Clevis is not ready for every-day unattended usage for TPM decryption of LUKS partitions. For secure key storage, it should be binded to PCR 0, 2, 4, 5, 8 and 9 at least. The key should be updated to updated PCR values with kernel update or initramfs regeneration, but I found no code/scripts and no documentation entries on where is it performed. Without this key regeneration you’ll get automatic LUKS decryption only until first kernel/initramfs update.
I want to be wrong, but I found this topic after I discovered Fedora IoT website, which states:

Security in mind
Security is important for IoT devices especially since they likely don’t have the security of a data center. With support for TPM2, SecureBoot, and automated storage decryption with Clevis, Fedora IoT is built with a focus on security.

I have my own set of dirty scripts to unlock LUKS partitions with TPM key (not Clevis, my laptop has TPM 1.2 which is not supported by that proejct), and Fedora GRUB2 configuration scripts modify Grub environment variables (grubenv file) which creates additional complexity to measured boot. I’ve commented all that long time ago, but remembered that I recently seen on the IoT website and decided to check what did they done as a workaround for mentioned issue.
I’ve downloaded Fedora IoT raw disk image, to find that it doesn’t even support UEFI mode booting, which means it doesn’t support Secure Boot either. After that I’ve downloaded an ISO file, which has UEFI (and Secure Boot) support. I’ve unpacked it to find that there’s no Clevis installed inside. No Clevis or Measured Boot documentation could be found for Fedora IoT.

Given all that, I assume that the claims on Fedora IoT website are mostly false (you can’t do proper automatic and secure storage decryption using TPM without measured boot and automatic recomputing of PCR values, which I did not find anywhere), and currently Clevis is not ready to be used with LUKS+TPM.

I hope I’m wrong and just missed something. I’ll ask Fedora IoT developers to clarify this question.

UPD: it seems that Clevis TPM2 module treat model is to protect the system from remote attacker only.

The Clevis security model relies in the fact that an attacker will not be able to access both the encrypted data and the decryption key.
The tpm2 pin is different in this regard, since a key is wrapped by a TPM2 chip that is always present in the machine. This does not mean that there are not use cases for this pin, but it is important to understand the fact that an attacker that has access to both the encrypted data and the local TPM2 chip will be able to decrypt the data.

This is either by design intentionally, or Clevis developers are not savvy enough with TPM to implement it properly. I’m puzzled of the fact that Fedora IoT mentions Clevis on the website: IoT device are physically present in potential attacker hands.

6

That is very good information thank you.

As of yet, I’ve still been unable to get clevis to auto-decrypt, so I was still using the passphrase at boot.

However, since then I’ve had to remove LUKS encryption as I get constant SCSI errors on the RAID controller:

kernel: sd 12:0:0:0: [sdc] tag#827 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s
kernel: sd 12:0:0:0: [sdc] tag#827 Sense Key : Hardware Error [current]
kernel: sd 12:0:0:0: [sdc] tag#827 Add. Sense: Internal target failure
kernel: sd 12:0:0:0: [sdc] tag#827 CDB: Read(16) 88 00 00 00 00 00 00 00 11 00 00 00 00 01 00 00
kernel: blk_update_request: critical target error, dev sdc, sector 34816 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Somewhere in there I loose the partition and all data (but not LUKS)

However, w/o LUKS encryption…no problems.

7

Well, clevis does not only work with tpm2, but you can also use it with tang and a combination thereof.
One use case where clevis does protect my data in an iot device is a device at home which may easily be stolen, but cannot be started outside of my network because of tang. So the iot device is in the hands of the potential attacker, but the data is safe, assuming he does not have the time to use my network while stealing the device.

Besides, using clevis with tpm has another use case: portable data storage. Let’s say I want to transfer data between my work place and my home. I have (and need) a powerful workstation at both places, so I cannot simply use a laptop to work both at home and at work. Transferring data between work place and home over the internet is infeasible due to huge amount of data. The solution is to carry with me a usb-ssd. I want to encrypt this portable ssd, so any thief who steals my bag on my way home cannot get the data. At home and at work my workstations are physically secure, so when my ssd is connected to either of these machines clevis can unlock the data.
Granted, this scenario could be fixed by a plain text password laying around on both workstations, but clevis allows for easy multi factor setup via secret sharing, so that in addition to the correct TPM2 I also need to enter the correct password. And insert my smartcard. And have the tang server available on my network.

8

Sure, Clevis with Tang is a valid and intelligible use case: you have a server with key storage, once the server is not available, it won’t work.

However, TPM usage in Clevis is underdocumented and creates a false impression that it is secure by default and protects against physical attacker. At least that’s what I have expected from Fedora IoT website and some CoreOS documentation.

9

I agree, the documentation could be improved. The clevis github repo does not even mention how to use different PCR. Maybe someday somebody will come along and expand the documentation.

Minor clarification about Tang: Tang is not a key storage, it never gets a client key. The mechanism Tang uses is quite interesting, as it is quite simple yet powerful.