Policy-Based Decryption (Lesson 6 transcript from Upgrading to Red Hat Enterprise Linux (RHEL) 8 LiveLessons)
Date: May 20, 2021
In Lesson 6, Sander van Vugt explains policy-based decryption. Read the transcript below.
Lesson 6 Introduction
Hi, welcome to lesson six. In this lesson you'll learn how to work with LUKS encryption. While LUKS encryption itself is not new, the option to enable access to LUKS encrypted devices by authorizing to a network server is new. In this lesson, you'll learn how to work with it.
Setting up LUKS
So, this lesson is about policy-based decryption. Policy-based decryption is used for LUKS. LUKS are encrypted devices. An inconvenience is that in order to use a LUKS-encrypted device, you need to enter a passphrase. And that's why we want to use policy-based decryption. But before you can do that, you need to set up a LUKS device. On the slide I have summarized a procedure and I'm going to demonstrate how to apply this procedure. So, before we can create an encrypted device we need a block device.
So let me start at lsblk to list current block devices. And we can see that there's a disc nvme0n2. I'm going to use that c encrypted device. In order to do so, I'm using cryptsetup luksformat on dev nvme0n2. We can see that this device has been used for something else previously. I don't care, I'm going to override it. So I say, yes.
Next it is asking for a passphrase. This passphrase needs to be reasonable complex and it needs to be used while accessing the encrypted device. At this point I have created the cryptographic layer on top of the LUKS device. So let's first verify that we can open it. In order to do so I'm using cryptsetup luksOpen followed by the name of the device. Followed by the name of an encrypted device that needs to be created. So the secret in here is a new device that will be created, after I have entered the passphrase. And that is exactly what is wrong with this procedure. Encrypted devices are very nice, but if you use them on the server, you don't want manual interaction to enter a passphrase, but for now we don't have any choice. So by using the cryptsetup luksOpen, I have opened the encrypted device. And we should see the results in the dev mapper directory. What I'm looking for is this. Here we can see the secret device that has been created in dev/mapper and that's the opened encrypted device. In order to do something with it I need to put a file system on top. So mkfs.xfs on dev mapper secret will do that for me. And now I must make sure that I can mount it, so let me create the directory and next use mount of dev mapper secret on /secret. And at this point it is working. If I want to automate this and automatically start the encrypted device while booting then I need to create the file etc crypttab. So in etc/crypttab I need to specify the name of the file that needs to be created. That will be secret. Then I need to specify the name of the underlying device, that is nvme0n2.
Next I'm using none. The none indicates that I don't want to feed a passphrase through this configuration file and I need _netdev. _netdev is a mandatory option if you want to automate this procedure later on. So this part will make sure that the encrypted device is opened while booting, but it doesn't mount it. In order to mount it, I also need to edit etc fstab. So what are we going to do in etc fstab, well we are going to use dev mapper secret which is the name of the opened encrypted device we mounted on /secret. We set the file system to xsf and we need the mount option netdev and then we include 00 which is quite common as mount options. That should do it so at this point if I reboot the encrypted device should be initialized. Let's have a look. So this is what happens. You can see that I am prompted to enter the passphrase at this point. And even if that works, that isn't convenient at all and that is why we have policy-based decryption, which we will talk about next.
Understanding Policy-Based Decryption
Before we start configuring Policy-Based Decryption let's try to understand what it is about. Policy-Based Decryption, or PBD is a collection of technologies that enable unlocking encrypted root volumes in an automated way, so that you don't have to enter a pass phrase. In PBD, different unlocking methods can be combined. You can use user passwords or Trusted Platform Modules or PKCS#11 devices like smartcard readers or network servers. And a network server is what we are going to focus in this lesson. Different unlocking mechanisms can be combined in one policy, which makes it possible to unlock the same volume in different ways, depending on the availability of your unlocking methods. Policy-Based Decryption has been introduced in RHEL 8 and in order to work with it, you need the Clevis framework. The Clevis framework is using pins. These pins are really plug-in modules and every pin provides a separate unlocking capability.
There is tang, which allows volumes to be unlocked using a network server. And there is tpm2, which allows volumes to be unlocked using a tpm2 policy. And that's the current state of unlocking mechanisms in RHEL 8. There's also this thing called NDBE, now what is NBDE? That is Network Bound Disc Encryption, it's a subcategory of PBD and it allows binding encrypted volumes to a network server. The current implementation includes a Clevis pin for Tang server and the Tang server itself. And that is what I'm going to demonstrate. Before I'm going to demonstrate, let's try to understand Tang. So Tang is a network server that is used for decrypting LUKS devices. And Clevis is the framework that allows for decrypting LUKS volumes and connects the Tang server to do so. And when provisioning NBDE, the Clevis pin for Tang gets a list of Tang server advertised asymmetric keys. Alternatively, a list of Tang public keys can be distributed out-of-band so that clients don't require direct access to the Tang server. In the next video, I will show you have to set this up.
Managing Policy-Based Decryption
Okay let's have a look at the procedure for setting up policy-based decryption. First you need to set up Tang. That's pretty simple. You install the packet, you run the tangd.socket, and you open the firewall, and that's all.
The Clevis setup is a little bit more complicated. To start it, you need to install some packages. And then you need to register the password at the Tang server. One way of doing that is by echoing the password and piping the results to clevis encrypt tang. Followed by the name of the Tang server that you are using. Next you can test the connectivity with the Tang server. That will be something like curl-f http tangserver.example.com/adv. Which will show you the encrypted passphrase, basically. Then you use clevis luks bind -d followed by the name of your device. Tang followed by the URL to the Tang server, and that'll bind the device. But binding doesn't mean that it's unlocked. That's something we do later. At this point you can use systemctl enable clevis-luks-askpass.path, and if you are using LUKS on an encrypted root volume, you can use dracut -f. And next, you can use clevis luks unlock -d on dev nvme01n1p5 to unlock the device. Check for the availability in the device or in the dev map or directory and reboot to verify that all is working alright. Let me show you.
Okay, to start, you need to make sure that you can reach the Tang server by host name. I've already prepared my etc host where I am going to tang.example.com on its IP address. So let's ssh into that server. So that I can show you what should be happening there. So you need to install the Tang package, and you need to verify the availability of the Tang service. So if you use systemctl status on tangd.socket, now we can see that socket is active and listening. Let's also use firewall cmd -- list all to verify that port 80 tcp is open, and that's exactly what we need, and that's all as far as the Tang server is considered. And now we need to install packages on the client server. The client server is the server that is running the LUKS encrypted devices. So you use yum install clevis clevis luks and clevis dracut to install all of the packages that are required. Already installed, that's even better.
Now the most important part is that we make the password known to the Tang server. So as you can see, I'm using a very secret password and I'm sending that to the Clevis command, which is using clevis encrypt tang, followed by the Tang URL. So the advertisement contains the following signing keys. Do you want to trust these keys? Of course I want to trust them. Now we can test the connectivity with the Tang server. So curl -f on http://tang.example.com/adv, for advertisement, and you can see the payload that is getting back. So far so good. As we have reached this point, we can now use clevis luks bind -d on dev nvme0n2, and we need to bind with Tang. Which again, is going to use the URL. And there we can see the same advertisement again, and do we want to trust this key? Yes we want. So now the LUKS volume is known at the Tang server. So we can use systemctl enable clevis luks askpass.path. That will make sure that after a reboot, it's going to happen automatically. If you would be using LUKS encrypted to root volume, you need direct root -f. I'm not using LUKS encrypted root volume. I'm only using a normal root volume. So I can easily test it using clevis luks unlock -d on dev nvme0n2. And that is going to unlock the device for me. And to verify that the device is available, we can do an ls on dev mapper, and look, the device has been mounted, and that's all. If you want to, you can reboot to verify that the procedure is working alright and fine tune if you want to.