morbitzer / linux-luks-tpm-boot Goto Github PK

Will this clear the windows' (bitlockers) key or prevent windows get key from TPM, after taking the ownership? Is it possible to let the TPM accept multiple OS?

Hi,
It may be that the documentation wasn't clear enough to me, but doesn't this share DRM's defective by design nature? If I understand it correctly, the machine will decrypt itself as long as I don't change the bootloader etc.? Because for one, the key must therefore be there and I'm sure it's technically possible to get it out if you're NSA or so, and if you're not maybe you can somehow get the data after the decryption has happened? Also 100% possible if I understand this correctly, and although it may not be easy, you can also have 100% impossible if you keep the keys somewhere safe (or at least encrypt them with a password...)

I followed your link to "UEFI support of TrustedGRUB2" (Rohde-Schwarz/TrustedGRUB2#15) and found a mention of Matthew's Garrett's fork of grub. What does this patchset mean for linux-luks-tpm-boot? What, if anything, does "vanilla" grub lack for the support of UEFI, TPM, and SecureBoot?

As the title says, fot what TPM version is? Both works very different and that is the main problem of why TPM 2.0 is supported in systemd-crypenroll for example.

Sorry to bother, but I think it's important to clarify.

Thanks.

In this guide, you mention about storing the key in the rootfs partition (by default, mounted and chrooted at /).

From my understanding, as long as the ramfs to boot the system and the root image of the system didn't change, the whole data becomes fully available for use of whatever is running in RAM.

Linux has a recovery mode which allows booting with img mounted at / as rw (not a default option, btw).
Won't the recovery mode allow full unencrypted access to the attacker, including reading the encryption key at /secret.bin and then use that same key to decrypt the whole drive, now, outside the control of the TPM?

If so, I just succeeded that attack in near 10 minutes in one old PC borrowed to me so I'd do the test.
I was never able to boot to the OS (it wouldn't boot without modification) originally stored but I was able to get plain text access to the whole system.

Am I missing something?

I would like to adapt your approach to make it work with TPM 2. Do you think this will be easy? Do you have some ideas to point me in the right direction?

I already noticed that trousers is not working with TPM 1.2, so I will definitely need to find an alternative for that.

I'd like to rip off some of your scripts for my mortar project and wanted to know what license you use for your work here. For files that I base my own on/take heavy inspiration from, I include a comment near the top stating so and including a link to the original file location. Is this sufficient?

No is fine. I can rewrite the functionality if you'd rather keep your work here.

Hi,

I just came across your very extensive guide. I'd happily tried it out, but unfortunately the TrustedGRUB2 team decided to deprecate the project just about three weeks ago. Maybe you're aware of some alternative?

Best,
Simon

I have been following this guide but am having problems right at the end with the script tpm-hook. I keep getting errors expecting "in" Line 7 at the start of the case statement. If I comment out that whole section then I get an error
/usr/sbin/mkinitramfs: 699: /usr/sbin/mkinitramfs: /etc/initramfs-tools/hooks/tpm-hook: not found yet it is there.

Hi, I'm having problems with edits to the boot menu still allowing the machine to boot.

As per the following segment:
"Checking if it works
If you now reboot again, your system shouldn't boot up when you edit for example the boot menu entries. Just give it a try, press E in the TrustedGRUB2 boot menu. Then edit for example one of the echo lines, to output something different. Then press F10 to boot. This should be enough for your TPM to refuse to give out the key!
It works? Perfect, you are ready to go! Enjoy having to type one password less during boot time! :)

The system still boots up, although it shouldn't? Have a look at the next step…

Setting the nvLocked bit
On one of my test systems, I had the problem that the secret stored in the NVRAM could be read even when the PCRs it was sealed to had changed. It took me quite a long time to figure out what went wrong: Apparently, the TPM manufacturer didn't set the nvLocked bit, which means that reading the NVRAM was always possible, no matter if you sealed it to some PCRs or assigned a password to it. Thanks to this discussion at the TrouSers mailing list, I was finally able to figure out what to do:

You'll have to define an area the size 0 at position 0xFFFFFFF in the NVRAM. This will equal setting the nvLocked bit. You can do so with the following command:

sudo tpm_nvdefine -i 0xFFFFFFFF –size=0

This solved the problem for me. Afterwards, my sealed NVRAM areas couldn't be read anymore if the PCRs it was sealed to had changed, and my system was finally save again. "

If I try this (sudo tpm_nvdefine -i 0xFFFFFFFF –size=0) I just get an error that the value needs to be a positive integer.
My next question is regarding this statement "I had the problem that the secret stored in the NVRAM could be read even when the PCRs it was sealed to had changed." The guide doesn't mention how to seal to specific PCR's or have I missed that? Please forgive my lack of knowledge on this subject, it's why I'm referring to a guide.

Got the following error:

/sbin/seal-nvram.sh: line 22: read: `Owner password: ': not a valid identifier

while running:

$ sudo /sbin/seal-nvram.sh -z

I think this is fixed by reordering the parameters:

read -s -r -p "Owner password: " OWNERPW

Instead of:

read -s -p -r "Owner password: " OWNERPW

I think your initramfs hooks could be improved a bit—almost to the point of being able to just package this as a .deb and drop it into place on a system. I say almost because I don't know that tpm and tpm_tis are sufficient as kernel modules go to make sure TPM 1.2 devices are loaded and ready in the initramfs. On both my modern desktop (Ryzen 3700X) and my vintage soon-to-be file server (Ivy Bridge 🤣 surplus Whack-a-Dell mini thing connected to an eSATA enclosure), TPM devices already exist in /dev and the modules are loaded by systemd once it starts.

First, without doing anything:

root@rem:~# lsinitramfs /boot/initrd.img-5.10.0-19-amd64 | grep 'etc/\(passwd\|group\)'
etc/passwd
root@rem:~# lsinitramfs /boot/initrd.img-5.10.0-19-amd64 | grep '\(tcsd\|tpm\)'
root@rem:~# 

Okay, so nothing TPM-related is getting into the initramfs, which means it's all being done by systemd after the fact. But /etc/passwd is getting created in the initrd for some purpose. Created or copied, I could figure that out, but I don't think I need to, since the remedy would be the same regardless. In tpm-hook, I see:

#create etc/passwd
groupid=`id -G tss`
userid=`id -u tss`
echo "root:x:0:0:root:/root:/bin/bash" >  ${DESTDIR}/etc/passwd
echo "tss:x:$userid:$groupid::/var/lib/tpm:/bin/false" >> ${DESTDIR}/etc/passwd

#create etc/hosts
echo "127.0.0.1 localhost\n::1     localhost ip6-localhost ip6-loopback\nff02::1 ip6-allnodes\nff02::2 ip6-allrouters\n" > ${DESTDIR}/etc/hosts

#create etc/group
echo "root:x:0:" > ${DESTDIR}/etc/group
echo "tss:x:$groupid:" >>  ${DESTDIR}/etc/group

Seems like it makes more sense to do something like…

#create etc/passwd entries
for user in root tss; do
    if ! grep -q "^${user}:" ${DESTDIR}/etc/passwd 2>/dev/null; then
        grep "^${user}:" /etc/passwd >> ${DESTDIR}/etc/passwd
    fi
done

#create etc/hosts if not present
if [ ! -e ${DESTDIR}/etc/hosts ]; do
    copy_file hostfile /etc/hosts
fi

#create etc/group entries
for group in root tss; do
    if [ ! grep -q "^${group}:" ${DESTDIR}/etc/passwd 2>/dev/null; then
        grep "^${group}:" /etc/group >> ${DESTDIR}/etc/group
    fi
done
echo "root:x:0:" > ${DESTDIR}/etc/group
echo "tss:x:$groupid:" >>  ${DESTDIR}/etc/group

That seems like it creates all three files if need be.

I started looking into this following a read through Glen Tomkowiak's page for how to set up an old machine's TPM (1.2) to store an unlock key, but his old guide does not describe adding this stuff to an initramfs. When someone asked him about a completely secure boot environment, he recommended this guide. He has a couple of things there you might want to incorporate into this guide. He uses /dev/shm/tmp_tpm.key for the key output, specifies -s 32 for the 32 character pwgen output he uses as an unlock key, zeroes the /dev/shm file out before deleting it to ensure the key doesn't linger in RAM once used, that sort of thing. Useful updates to this guide, I think.

My use of this is that I'm moving four HDs containing an encrypted LVM RAID media vault from my desktop (decrypt_keyctl on boot for all drives) to a dedicated media server. Nobody cares about my music/video/book collection, I could've decrypted the whole thing by now from backup. But this FDE/SecureBoot stuff is poorly understood by most, not well-integrated into Debian at this time, and worth learning about. It just so happens the machine I've got to play with uses TPM 1.2 because it's an Ivy Bridge (🤣) so I can't just throw clevis at it.