Ubuntu 18.04 and TPM2 encrypted system disk
*** EDIT *** : An updated version of this post can be found here: https://run.tournament.org.il/ubuntu-20-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)
#!/bin/sh
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
#!/bin/sh
PREREQ=""
prereqs()
{
echo "$PREREQ"
}
case $1 in
prereqs)
prereqs
exit 0
;;
esac
. /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
Crypttab
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.
Troubleshooting
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.
Conclusion
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!
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.
You are correct. I have corrected it in the text. Thanks for the heads up!
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.
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.
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
#df
├─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?
Note:
1-I’m using dual boot, windows and ubuntu
2-I have generated 64bit secret passphrase
Thanks in advance!
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.
Etzion
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.
4-lsblk
├─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
Thanks
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.
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.
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?
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).
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?
Maybe you’ve installed snap utility and not dpkg package?
I am having the same issues with tpm2-tools and looking at the github it seems like they have changed their command line parameters a LOT since this was written. I don’t know why they would do that, especially without a major version change, but there you have it. For reference, I am using Ubuntu 20.04 with tpm2-tools 4.1.1. Here is are my notes about what I found and the updated commands. I don’t have time to test the full process, but I try it out next week.
Old command: sudo tpm2_nvdefine -x 0x1500016 -a 0x40000001 -s 64 -t 0x2000A -T device
-x 0x1500016 Index changed to an argument, put on end of command with no -x
-a 0x40000001 hierarchy changed to -C
-s 64 need to change to 63 so tpm2_nvwrite doesn’t complain about the size being 65. I guess it writes the EOF to the TPM?
-t 0x2000A attribute, changed to -a
-T device
New format command: sudo tpm2_nvdefine -C 0x40000001 -s 64 -a 0x2000A -T device 0x1500016
Old command: sudo tpm2_nvwrite -x 0x1500016 -a 0x40000001 -f root.key -T device
-x 0x1500016 Index changed to an argument, put on end of command with no -x
-a 0x40000001 hierarchy changed to -C
-f root.key input file, changed to -i
-T device
New format command: sudo tpm2_nvwrite -C 0x40000001 -i root.key -T device 0x1500016
Old command: tpm2_nvread -x 0x1500016 -a 0x40000001 -s 64 -o 0 -T device
-x 0x1500016 Index changed to an argument, put on end of command with no -x
-a 0x40000001 hierarchy changed to -C
-s 64
-o 0 Offset, changed to –offset but doesn’t seem to be needed
-T device
New format command: tpm2_nvread -C 0x40000001 -s 64 -T device 0x1500016
Heavy! I am planning on reinstalling a laptop with TPM2 soon, and I could test it. Let’s see how it works. If it works well, I will update the document for Ubuntu 20.
Thanks!
Etzion
I spent some time on this today and got a working config going! First I will post some notes and questions for you, then I will post my steps.
I removed a lot of tpm2_* options – it seems to work fine without them so I think it is ok. There may be some special cases where that causes trouble, like if there is both a hardware and virtual TPM, but that should be both rare and only used by a very advanced user anyway.
Is there special signifigance to the 0x1500016 location on the TPM? I don’t know if anything else would ever expect to use that, like bitlocker in a dual boot scenario. That may not even make sense, though, I don’t know if two OSes can both use the same TPM device.
When generating root.key, “head -n 1” was grabbing the EOL put in by “fold -w 64”. That was causing the file size to be 65 bytes, making it too large for the defined area in the TPM, and to have an invisible character. I removed the fold altogether and just told head to get the first 64 bytes of the the stream.
You may also want to check if there is a way you can have your site format the commands differently – it made the single quotes in the tr line into smart quotes. That will cause problems if copied and pasted.
For the key recovery script, there is a lot of output processing that is unneeded with the current version of tpm2-tools. tpm2_nvread output only what is stored an not a single character extra. It wouldn’t hurt to keep the processing in, but I opted for simplicity. I am not familiar with perl so I don’t understand that part of the script, but it looks like it is doing a sed type operationon. If I leave that in, the script outputs un unprintable character and NOT the stored value in the TPM. What is that perl line meant to do?
I kept getting errors in initramfs when running tpm2_* commands saying tss2 couldn’t open the device. It turns out that only some of the libtss2 libraries were in initramfs. I added these lines to the decryptkey initramfs hook file to add them and it started working. There are also mssim libraries for virtual TPM that could be added, but I am not sure it is feasible to boot to a virtual TPM anyway.
copy_exec /usr/lib/x86_64-linux-gnu/libtss2-tcti-device.so.0.0.0
copy_exec /usr/lib/x86_64-linux-gnu/libtss2-tcti-device.so.0
Incidentally, even on a normal boot Ubuntu before doing anything with the TPM it would briefly flash “unable to contact the TPM” or something similar on boot. Adding those libraries seems to have resolved that, too. It seems to be an upstream problem that will hopefully get resolved eventually.
I changed the name of your scripts for clarity only so when I see the files a few years down the line and have forgotten what they were about, I will remember.
Because you added the initramfs hook script, any normal kernel updates down the line should automatically integrate it, correct?
Next steps – Maybe use pcr register hash as the key instead of something random? That should require a specific BIOS configuration and prevent access when booted from a flash drive. Although enough snooping in the initramfs could probably still reveal the parameters of the tpm2 and maybe allow access to the stored key as you discussed in the comments already.
I know this was a lot but it is only because I am so excited to have found a working solution. I have been trying to get LUKS auto-unlocking with TPM2 for a long time and your article is what finally got me there. Thank you so much!!
# Full disk encryption on Linux using LUKS+TPM2
#
# Heavily modified, but based on:
# https://run.tournament.org.il/ubuntu-18-04-and-tpm2-encrypted-system-disk/
#
# Created 2020/07/13
# This assumes a fresh Ubuntu 20.04 install that was configured with full disk LUKS encryption at install so it requires a password to unlock the disk at boot.
# This will create a new 64 character random password, add it to LUKS, store it in the TPM, and modify initramfs to pull it from the TPM automatically at boot.
# Install tpm2-tools
apt install tpm2-tools
# Define the area on the TPM where we will store a 64 character key
sudo tpm2_nvdefine -s 64 0x1500016
# If the previous line generated an error, you may need to run this to clear the area of the TPM we are using, then try the tpm2_nvdefine line again.
# sudo tpm2_nvundefine 0x1500016
# sudo tpm2_nvdefine -s 64 0x1500016
# Generate a 64 char alphanumeric key
cat /dev/urandom | tr -dc ‘a-zA-Z0-9’ | head -c 64 > root.key
# Store the key in the TPM
sudo tpm2_nvwrite -i root.key 0x1500016
# Print the saved key and the one on the TPM for comparison. echo is used to add a newline char to the output
echo Sanity check – these values should match. If they don’t DO NOT PROCEED!
echo root.key file contents: `cat root.key`
echo The value stored in TPM: `tpm2_nvread 0x1500016`
# IF AND ONLY IF the root.key and TPM output are the same, remove the root.key file for extra security
rm root.key
# Add the key to LUKS. Check /etc/crypttab to verify /dev/sda3 is the correct disk in your system!
sudo cryptsetup luksAddKey /dev/sda3 root.key
# Create a key recovery script at /usr/local/sbin/tpm2-getkey with just the following two lines:
#!/bin/sh
tpm2_nvread 0x1500016
# Set the script owner and permissions
sudo chown root: /usr/local/sbin/tpm2-getkey
sudo chmod 750 /usr/local/sbin/tpm2-getkey
# Create /etc/initramfs-tools/hooks/tpm2-decryptkey with the following contents:
#!/bin/sh
PREREQ=””
prereqs()
{
echo “$PREREQ”
}
case $1 in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
copy_exec /usr/sbin/tpm2_nvread
copy_exec /usr/lib/x86_64-linux-gnu/libtss2-tcti-device.so.0.0.0
copy_exec /usr/lib/x86_64-linux-gnu/libtss2-tcti-device.so.0
exit 0
# Set the file owner and permissions
sudo chown root: /etc/initramfs-tools/hooks/tpm2-decryptkey
sudo chmod 755 /etc/initramfs-tools/hooks/tpm2-decryptkey
# Backup /etc/crypttab, then add this to the end of the line for the boot volume: ,keyscript=/usr/local/sbin/tpm2-getkey
# e.g. this line: sda3_crypt UUID=d4a5a9a4-a2da-4c2e-a24c-1c1f764a66d2 none luks,discard
# should become : sda3_crypt UUID=d4a5a9a4-a2da-4c2e-a24c-1c1f764a66d2 none luks,discard,keyscript=/usr/local/sbin/tpm2-getkey
# Copy the current initramfs just in case, then create the new initramfs with auto unlocking
sudo cp /boot/initrd.img-`uname -r` /boot/initrd.img-`uname -r`.orig
sudo mkinitramfs -o /boot/initrd.img-`uname -r` `uname -r`
# If booting fails, press esc at the beginning of the boot to get to the grub menu. Edit the Ubuntu entry and add .orig to end of the initrd line to boot to the original initramfs this one time.
# e.g. initrd /initrd.img-5.4.0-40-generic.orig
Big like! Excellent comment. I will test this procedure in the next few days on a clean Ubuntu 20.04, and maybe, just maybe, I will be able to test the original procedure on 18.04, and then upgrade it to 20.04 and see what and how it works.
Thanks for this info!
2 corrections to the above:
First is easy, I got the order wrong and delete root.key before adding it to LUKS. Clearly those two commands should be swapped around. Luckily you can always get it back with tpm2_nvread 0x1500016 > root.key
The second is more troublesome. in the tpm2-decrypt file it should be:
copy_exec /usr/bin/tpm2_nvread
and NOT /usr/sbin/tmp2_nvread. Unfortunately that one will silently fail until you try and reboot, when you are left unbootable until you set it back to the original initramfs. You can run “which tpm2_nvread” to get the correct path for you system.
Sorry for those errors! Also if copying and pasting from my post, double check all the quotes aren’t smart quotes!
Hi all,
I installed debian today by following this manual. I noticed, that when I add “break=mount” to the grub command, that I will be put to initramfs. And from this point I can just call /usr/local/sbin/key and get the key from tpm. Is there any way to prohibit this?
True. This does not work around the grub security. To get to a complete secured solution, you need to add grub password, to block changing boot options, and BIOS password to prevent overriding boot devices and replacing disks.
Another improvement for you. I was worried about future kernel updates and reverting back to the original initramfs because you would then need to know the version number too. It could be found by booting to a USB drive and looking at /boot, but that seemed less than optimal. It turns out it is pretty easy to just call cryptsetup’s askpass if the TPM is unavailable or has the wrong key. The best way I could think of to account for the key stored in the TPM being wrong was with a tmp file to indicate it was tried but must have failed because the script is running again. (cryptsetup default is to try 3 times to unlock) I may be wrong, but I think it creates it in the initramfs temporary filesystem so it is never written to disk and it doesn’t need to be cleaned up between boots.
I tested this by disabling my TPM in UEFI and it correctly reverted to asking for a passphrase and booted. I re-enabled it and then put the wrong key in it, rebooted and got the prompt again as expected. These script changes should make this solution a lot more robust. Here is the new section for creating tpm2-getkey:
# Create a key recovery script at /usr/local/sbin/tpm2-getkey with just the following 10 lines:
#!/bin/sh
if [ -f “.tpm2-getkey.tmp” ]; then
# tmp file exists, meaning we tried the TPM this boot, but it didn’t work for the drive and this must be the second
# or later pass for the drive. Either the TPM is failed/missing, or has the wrong key stored in it.
/lib/cryptsetup/askpass “Automatic disk unlock via TPM failed for $CRYPTTAB_SOURCE ($CRYPTTAB_NAME) Enter passphrase: ”
exit
fi
# No tmp, so it is the first time trying the script. Create a tmp file and try the TPM
touch .tpm2-getkey.tmp
tpm2_nvread 0x1500016
One more small change and then I will be done on this unless you have specific questions or concerns for me. In tpm2-decryptkey it can be a bit more robust by changing:
copy_exec /usr/bin/tpm2_nvread
-to-
copy_exec `which tpm2_nvread`
That way if the location of tpm2_nvread changes at some point in the future, it will still be picked up automatically.
Tested on Lubuntu 18.04, it only works with the tpm2-tools package from the 20.04 package list, the older version seems rigged, there is no tpm_undefine in it.
sudo nano /etc/apt/sources.list
deb http://cz.archive.ubuntu.com/ubuntu focal main universe
Excellent guide!
It did work well for me with tpm2-tools. I am using version 2.1.0-1build1 on Ubuntu 18.04 at the moment, and I am not inclined to upgrade my Linux just yet…
A test laptop I have have only TPM1, so, since it won’t be the same, I did not move forward with tests on it. Meaningless…
Thanks!
Thanks for this post!
I had an issue with following command:
cat /dev/urandom | tr -dc ‘a-zA-Z0-9’ | fold -w 64 | head -n 1 > root.key
I had to strip the 65th character that it creates (which is a newline) and changed it to:
cat /dev/urandom | tr -dc ‘a-zA-Z0-9’ | fold -w 64 | head -n 1 | tr -d ‘\n’ > root.key
Any comments? Anyone else observing the same issue?
Sorry for the late approval of the comment.
I cannot currently test the updated procedure because my current (working) laptop has TPM2, and my previous one has TPM(1). Thus – I cannot test TMP2 with newer or even current versions of Ubuntu. I had just recently installed a new home-server running OEL8 with modern KVM (and ZFS, and OpenVswitch and stuff), which should support TPM2 virtual device. In this case, I would be able to perform Ubuntu 20.04 TPM2 tests. Just need the time for that.
Etzion
@Jan – I had the same issue, I simplified the command to:
cat /dev/urandom | tr -dc ‘a-zA-Z0-9’ | head -c 64 > root.key
to resolve the issue in my script posted above
@Jan @Kelderek
Confirmed on 18.04 the boilerplate script did infact add \n newline to root.key
Pipe it from TMP before luksAddKey solved my 4 hour headache
Interesting. I did not experience it neither on Ubuntu 20.04 nor on 18.04. Interesting.
Thanks for updating.
Have everything working with /dev/sda3 type of disk but unable to get it to work with /dev/nvme0n1p3. Error is cryptsetup failed, bad password or options? Fails to automatically log in.
Interesting. Unfortunately, I do not have any NVME-based system to run tests on. Did you check /etc/crypttab? There is a specific encryption label (in Ubuntu it defaults to the type-of-the-device_crypt, like sda3_crypt, and you might have missed it, and replaced nvme0n1p3_crypt with sda3_crypt.
Do check it. If you do find any problem and correct it, you need to recreate your initramfs (initrd) for these settings to apply at next reboot.
@Mike
Did you adjust the line in the middle from:
sudo cryptsetup luksAddKey /dev/sda3 root.key
to
sudo cryptsetup luksAddKey /dev/nvme0n1p3 root.key
That is the part where it adds the key to the partition.
Hi, etzion. Thanks for writing this blog. I have a new Ubuntu server 18,04lts computer. After I installed tpm2-tools and perl, I failed to define a nv area by error 0x14. Could you please help me to find out why would this happen? Sorry to bother you.
If you could not define the area, it may mean that your TPM2 is not functioning (not enabled in the BIOS), or that you have TPM (without the “2”), or that you lack the required permissions. Any of these.
Hello Etzion,
Thanks for this great contribution!
I am able to follow the instruction to make this work on 20.04. However, we also have some legacy systems with 16.04. It seems like tpm tools can only be executed while tpm2 resource manager is running on ubuntu 16.04. However, it seems like Ubuntu 16.04 does not allow resource manager to run within initramfs. do you or any other readers have ideas to work this around? I understand in Ubuntu 18.04 tpm2 nvread is able to use -T device to work around this resource manager. But this option seems lacking under system 16.04. any hints will be highly appreciated!
Thanks!
@Su – I spun up a 16.04 and tried some stuff and here are my results:
You might have some luck combing what is on this page with https://unix.stackexchange.com/questions/402167/how-can-i-execute-tpm2-nvread-in-the-initramfs-image-created-by-dracut-for-cento I was unable to make it work, but you might have better luck. Ultimately the problem was that networking wasn’t up for resourcemgr, and I couldn’t get ifup to bring up lo for it. If you can get that working this might be feasible. It does exclude systemd, so that is a whole other can of worms.
I did do one other thing that actually allowed the instructions on this page to work, but it almost certainly a very bad idea. I added the repos for 18.04 (bionic) to apt, then apt update && apt install tpm2-tools, then immediately removed the 18.04 repos. That got the newer version of tpm2-tools and now -T device works. If it were just that, I wouldn’t worry so much about it, but unfortunately it also had to pull in some dependencies that may interact poorly with whatever else is on the system. specifically:
libssl1.1 was installed, and some libc, libc6, and locales packages were upgraded.
I should add that a nice alternative is to download the 18.04 source deb, and then recompile it on 16.04 using dpkg-buildpackage (and the whole process). If you maintain your own version number – you can get an advance package which is newer than what you get on 16.04 (which doesn’t get updates anymore anyhow, so no risk of overwriting your packages there) with your functionality and all. Should work like charm, except for the build dependencies, which you might want to edit inside debian/control file – if you go this way. An alternative is just to manually download the file on Ubuntu 18 (apt-get download tpm2-tools) and install it on your 16.04, and if it works without collision, it’s your lucky day. Seems like the (*ugly hack*) easiest method around.