Ubuntu 18.04 and TPM2 encrypted system disk

When you encrypt your entire disk, you are required to enter your passphrase every time you boot your computer. The TPM device has a purpose – keeping your secrets secure (available only to your running system), and combined with SecureBoot, which prevents any unknown kernel/disk from booting, and with BIOS password – you should be fully protected against data theft, even when an attacker has a physical access to your computer in the comfort of her home.

It is easier said than done. For the passphrase to work, you need to make sure your initramfs (the initial RAM disk) has the means to extract the passphrase from the TPM, and give it to the encryptFS LUKS mechanism.

I am assuming you are installing an Ubuntu 18 (tested on 18.04) from scratch, you have TPM2 device (Dell Latitude 7490, in my case), and you know your way a bit around Linux. I will not delay on explaining how to edit a file in a restricted location and so on. Also – these steps do not include the hardening of your BIOS settings – passwords and the likes.

Install an Ubuntu 18.04 System

Install an Ubuntu system, and make sure to select ‘encrypt disk’. We aim at full disk encryption. The installer might ask if it should enable SecureBoot – it should, so let it do so. Make sure you remember the passphrases you’ve used in the disk encryption process. We will generate a more complex one later on, but this should do for now. Reboot the system, enter the passphrase, and let’s get to work

Make sure TPM2 works

TPM2 device is /dev/tpm0, in most cases. I did not go into TPM Resource Manager, because it felt overkill for this task. However, you will need to install (using ‘apt’) the package tpm2_tools. Use this opportunity to install ‘perl’.

You can, following that, check that your TPM is working by running the command:

sudo tpm2_nvdefine -x 0x1500016 -a 0x40000001 -s 64 -t 0x2000A -T device

This command will define a 64 byte space at the address 0x1500016, and will not go through the resource manager, but directly to the device.

Generate secret passphrase

To generate your 64bit secret passphrase, you can use the following command (taken from here):

cat /dev/urandom | tr -dc ‘a-zA-Z0-9’ | fold -w 64 | head -n 1 > root.key

Add this key to the LUKS disk

To add this passphrase, you will need to identify the device. Take a look at /etc/crypttab (we will edit it later) and identify the 1nd field – the label, which will relate to the device. Since you have to be in EFI mode, it is most likely /dev/sda3. Note that you will be required to enter the current (and known) passphrase. You can later (when everything’s working fine) remove this passphrase

sudo cryptsetup luksAddKey /dev/sda3 root.key

Save the key inside your TPM slot

Now, we have an additional passphrase, which we will save with the TPM device. Run the following command:

sudo tpm2_nvwrite -x 0x1500016 -a 0x40000001 -f root.key -T device

This will save the key to the slot we have defined earlier. If the command succeeded, remove the root.key file from your system, to prevent easy access to the decryption key.

Create a key recovery script

To read the key from the TPM device, we will need to run a script. The following script would do the trick. Save it to /usr/local/sbin/key and give it execution permissions by root (I used 750, which was excellent, and did not invoke errors later on)

key=$(tpm2_nvread -x 0x1500016 -a 0x40000001 -s 64 -o 0 -T device | tail -n 1)
key=$(echo $key | tr -d ' ')
key=$(echo $key | /usr/bin/perl -ne 's/([0-9a-f]{2})/print chr hex $1/gie')
printf $key

Run the script, and you should get your key printed back, directly from the TPM device.

Adding required commands to initramfs

For the system to be capable of running the script, it needs several commands, and their required libraries and so on. For that, we will use a hook file called /etc/initramfs-tools/hooks/decryptkey

     echo "$PREREQ"
case $1 in
     exit 0
. /usr/share/initramfs-tools/hook-functions
copy_exec /usr/sbin/tpm2_nvread
copy_exec /usr/bin/perl
exit 0

The file has 755 permissions, and is owned by root:root


To combine all of this together, we will need to edit /etc/crypttab and modify the argument (for our relevant LUKS) by appending the directive ‘keyscript=/usr/local/sbin/key’

My file looks like this:

sda3_crypt UUID=d4a5a9a4-a2da-4c2e-a24c-1c1f764a66d2 none luks,discard,keyscript=/usr/local/sbin/key

Of course – make sure to save a copy of this file before changing it.

Combining everything together

We should create a new initramfs file, however, we should make sure we keep the existing one for fault handing, if required to. I suggest you run the following command before anything else, so keep the original initramfs file:

sudo cp /boot/initrd.img-`uname -r` /boot/initrd.img-`uname -r`.orig

If we are required to use the regular mechanism, we should edit our GRUB entry and change the initrd entry, and append ‘.orig’ to its name.

Now comes the time when we create the new initramfs, and make ourselves ready for the big change. Do not do it if the TPM read script failed! If it failed, your system will not boot using this initramfs, and you will have to use the alternate (.orig) one. You should continue only if your whole work so far has been error-free. Be warned!

sudo mkinitramfs -o /boot/initrd.img-`uname -r` `uname -r`

You are now ready to reboot and to test your new automated key pull.


Things might not work well. There are a few methods to debug.

Boot the system with the original initramfs

If you discover your system cannot boot, and you want to boot your system as-it-were, use your original initramfs file, by changing GRUB during the initial menu (you might need to press on ‘Esc’ key at a critical point) . Change the initrd.img-<your kernel here> to initrd.img-<your kernel here>.orig and boot the system. It should prompt for the passphrase, where you can enter the passphrase used during installation.

Debug the boot process

By editing your GRUB menu and appending the word ‘debug=vc’ (without the quotes) to the kernel line, as well as removing the ‘quiet’, ‘splash’ and ‘$vt_hansoff’ directives, you will be able to view the boot process on-screen. It could help a lot.

Stop the boot process at a certain stage

The initramfs goes through a series of “steps”, and you can stop it wherever you want. The reasonable “step” would be right before ‘premount’ stage, which should be just right for you. Add to the kernel line in GRUB menu the directive ‘break’ without the quotes, and remove the excessive directives as mentioned above. This flag can work with ‘debug’ mentioned above, and might give you a lot of insight into your problems. You can read more here about initramfs and how to debug it.


These directives should work well for you. TPM2 enabled, SecureBoot enabled, fresh Ubuntu installation – you should be just fine. Please let me know how it works for you, and hope it helps!

Tags: , , ,

13 Responses to “Ubuntu 18.04 and TPM2 encrypted system disk”

  1. Paul Greeff Says:

    Awesome writeup. I love it when people get to the point without the fluff.

    One correction, on my machine with Ubuntu 18.04 I had to use
    sudo mkinitramfs -o /boot/initrd.img-`uname -r` `uname -r`

    Note the ‘-o’ to indicate the output file which was omitted in your guide.

  2. etzion Says:

    You are correct. I have corrected it in the text. Thanks for the heads up!

  3. Paul Greeff Says:

    Having experimented with this somewhat I discovered something which should have been obvious to me. Any application running as root can get the key out of the TPM, including root on a live disk. I tested this with a live disk and could read the key. This means any attacker just needs to know where in the TPM to read, or experiment a bit to extract the key before then being able to decrypt the partition. I might be missing something important though. If you have any thoughts on this do send me an email.

  4. etzion Says:

    You are correct. There are a few methods of closing this gap. One of them includes using the TPM as a certificate store, with which you can unlock your LUKS, but cannot read from – a method I did not do. Another (which I prefer) is to use a self-signed certificate to sign the EFI grub, and make sure it is called using SecureBoot which will accept only your signed executables, and no other file. Combine that with grub-standalone and GPG for the kernel and initramfs, and you should have a system to which no one can boot, unless they are using your specifically signed GRUB and kernel. It requires some work, I will post something about it at a future time.

    Your insight is accurate and it brings up a very solid issue.

  5. suresh Says:

    Can I use above method to decrypt the / partition? If yes can you help me with the below doubts?

    1-I have give 128 byte space as below
    sudo tpm2_nvdefine -x 0x1500016 -a 0x40000001 -s 128 -t 0x2000A -T device


    ├─nvme0n1p4 259:4 0 572M 0 part /boot
    ├─nvme0n1p5 259:5 0 149,5G 0 part
    │ └─nvme0n1p5_crypt 253:0 0 149,5G 0 crypt /

    2- What should I use to encrypt my / partition, nvme0n1p5_crypt or nvme0n1p5 or /dev/mapper/nvme0n1p5_crypt?

    When I use below commands I have an error after reboot like “Cryptsetup failed and bad password” and it can’t boot anymore.
    #sudo cryptsetup luksAddKey /dev/nvme0n1p5 root.key
    #sudo cryptsetup luksAddKey /dev/mapper/nvme0n1p5_crypt root.key

    3- When I use “#sudo cryptsetup luksAddKey /dev/nvme0n1p5_crypt root.key” it says “umount: /: umount failed: Operation not permitted”.

    What is the problem? I can’t identify. Any suggestions how to fix it?

    1-I’m using dual boot, windows and ubuntu
    2-I have generated 64bit secret passphrase

    Thanks in advance!

  6. etzion Says:

    I don’t get why you have nvme0n1p5_crypt partition. What is it? It’s not just a name, but it is supposed to hold something there. Or did you name the VG nvme0n1p5 and the LV ‘crypt’. Please elaborate.


  7. Suresh Says:

    1-I’m not using LVM
    2- During installation I have selected an option called “Something else’ where we can create or resize partition our-self
    3- After resizing the partition I want to install OS in / which is nvme0n1p5 before encryption. Now to encrypt nvme0n1p5 which is / I manually selected an option “Physical volume for encryption”, so Ubuntu by default created “nvme0n1p5_crypt” and I installed OS in it.

    ├─nvme0n1p4 259:4 0 572M 0 part /boot
    ├─nvme0n1p5 259:5 0 149,5G 0 part
    │ └─nvme0n1p5_crypt 253:0 0 149,5G 0 crypt /

    5-If I give 64 byte space to allocate at the address 0x1500016, I have an error as below when I’m saving key inside TPM slot with tpm2_nvwrite command

    31 72 5a 45 65 8a 12 45 89 56 22 33 55 46 99 87 25 36 ………………………….. 0a
    ERROR: Failed to write NV area at index 0x1500016 (22020118) offset 0x0. Error:0x146

    But if I allocate 128 byte space at address 0x1500016, I don’t have an error with tpm2_nvwrite command as above

    6-I generated 64bit secret passphrase

    7- As you mentioned above I have identified the partition from /etc/crypttab which is nvme0n1p5_crypt for me to add keys to the LUKS disk

    #sudo cryptsetup luksAddKey /dev/mapper/nvme0n1p5_crypt root.key

    but I have an error as “umount: /: umount failed: Operation not permitted”.

    So I have tried to do as follows by adding keys as follows
    (i)- #sudo cryptsetup luksAddKey /dev/mapper/nvme0n1p5_crypt root.key

    but after reboot it cannot boot anymore and has an error like “Cryptsetup failed bad password or options” then I added keys as follows

    (ii)- #sudo cryptsetup luksAddKey /dev/nvme0n1p5 root.key and still has the same error as above and cannot boot anymore.

    8-I have written scripts as you said and changed permissions and followed everything clearly


  8. etzion Says:

    I am not sure about some things there. The main thing I am not sure about is the length of your key. If you’ve allocated 128bit space, and placed only 64bit passphrase, it might be that the TPM returns zeros for the remaining space. So I would attempt to create a 128bit passphrase which will fit into the allocated TPM space.
    Debugging initramfs is quite nasty, and you might want to look at the ‘Debug the boot process” or “Stop the boot process at a certain stage” sections of this post and attempt to manually decrypt the LUKS. See if your key (save it, for now, in /boot) is read correctly and is actually working, and check if manually reading from the NVRam of the TPM2 works just as well. If both work, your initramfs script might require debugging (maybe some missing components of a typo). This would have been how I would have troubleshooted this.

  9. Andy Oxenreider Says:

    I had Suresh’s problem. Here’s what I find is the issue….

    An EOL or other character can sneak in. If you get the 0x146 error, it’s ‘too big’. Go in, remove a character, then try it. It should work.

    By the same token, this can happen when stuffing the key into LUKS. What I would recommend is to get the key recovery script *before* putting the key into LUKS, then do ‘/usr/local/sbin/key > key.out’. This will get you the key, as stored, as the key recovery script will read it out. In essence, just use the pipeline that the boot sequence will use to reduce errors. This method worked for me when having Suresh’s problem.

  10. Christopher Says:

    Thank you for the detailed tutorial. But when I followed these steps on my Debian 10, every time I boot the system there is a “segmentation fault” when running the /usr/loca/sbin/key script. It seems that the tpm2_nvread cannot access the /dev/tpm0 device as expected. What may cause this problem?

  11. etzion Says:

    There are two possible causes – the first is that the device file is not there. You need to see how the initramfs flow creates or fails to create the file. You might want to add to your script a pre-command loading the module and creating the device file (mknod command). The other option is that Debian is doing something weird with module loading and device file handling (usually udev stage). The change I’ve suggested should work here as well, loading the driver and then creating the device file manually (if it’s not there already).

  12. merkzia Says:

    I am using Debian, and installed the latest 4.2.1 tpm2-tools from their repository.
    And I am not able to run a single tpm2_* command.
    -x, -a, -t all flags are said to be undefined, and I can’t find any equivalent in either man pages, or the wiki of tpm2-tools.
    Is anybody else facing this problem?

  13. etzion Says:

    Maybe you’ve installed snap utility and not dpkg package?

Leave a Reply