In order to do that, I think it's possible to make the password hash dependent on the TPM: that way, an attacker would need to invoke the TPM for every password hash, limiting the speed of password cracking to the speed of the TPM (alternatively, an attacker could attack the TPM itself and try to dump those keys, but let's assume this is not feasible; if it is possible, the password itself is still a protection). This setup seems theoretically possible, but I'm wondering if it is already implemented in **LUKS/GRUB/...** today or if I would need to program it myself. If it is already implemented, please explain how to set up such a system, preferably on **Arch Linux**.

I have been trying to get LUKS disk encryption with TPM2 working on an HP EliteBook 850 G8 running Kali Linux 2022.3. However, I am struggling to get TPM2 disk decryption added to Initramfs. # Steps I have taken so far: * Ensured that TPM2 is enabled and accessible to the OS * Added the TPM as Keystore 1 to the already encrypted hard drive using systemd-cryptenroll --tpm2-device=auto /dev/nvme0n1p3 * Verified the correct LUKS setup by running cryptsetup luksDump /dev/nvme0n1p3 # What fails: Following the steps listed above, I tried to modify the /etc/crypttab to allow unlocking my LUKS2 encrypted disk during boot, similarly to the way Bitlocker works. Therefore, I had changed my crypttab file to the following:

nvme0n1p3_crypt UUID= none luks,discard,tpm2-device=auto

And then tried to rebuild the initramfs using update-initramfs -u -k all, which gives me the following errors:

└─# sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.18.0-kali5-amd64
cryptsetup: WARNING: nvme0n1p3_crypt: ignoring unknown option 'tpm2-device'

What baffles me, is that I thought this option should be present in systemd since version 248 and up. Despite having v251 it does not recognize this option. Can anyone shed some light on what is going on here? Is this something specific to Debian-based systems or am I missing something? Any help or hints are highly appreciated. # System environment: ## OS version:

└─# lsb_release -a
No LSB modules are available.
Distributor ID: Kali
Description:    Kali GNU/Linux Rolling
Release:        2022.3
Codename:       kali-rolling

## Systemd version:

└─# systemd --version
systemd 251 (251.3-1)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

I want to run an Alpine Linux VM and want to connect the host's TPM to the VM. The host is x86_64 based. The command for qemu is

qemu-system-aarch64 \
    -m 1024 -cpu cortex-a57 -M virt \
    -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd \
    -drive file=disk.qcow2,if=virtio,format=qcow2 \
    -cdrom alpine-3.21.3-aarch64.iso \
    -nographic \
    -device virtio-net-device,netdev=n0 \
    -netdev user,id=n0 \
    -tpmdev type=passthrough,id=tpm0,path=/dev/tpmrm0,cancel-path=/dev/tpmrm0 \
    -device tpm-tis-device,tpmdev=tpm0

As for the installation disk alpine-3.21.3-aarch64.iso, I have tried both the "standard" and the "virt" version from here . They both boot fine and also the installation works, but from neither I can access the host's tpm. On the host, the TPM works fine, as I can test for example using tpm2_getrandom 8 --hex and from the fact that /dev/tpm0 and /dev/tpmrm0 exist. On the VM, those two devices do not exist and I cannot get it to work. Here some debugging output from the VM:

$ dmesg | grep -i tpm
[    0.000000] efi: SMBIOS 3.0=0x7fed0000 TPMFinalLog=0x7c3e0000 MEMATTR=0x7e227018 ACPI 2.0=0x7c3d0018 TPMEventLog=0x7c3d9098 INITRD=0x7c3c9b18 MEMRESERVE=0x7c3c9b98 
[    0.000000] ACPI: TPM2 0x000000007C3DE898 00004C (v04 BOCHS  BXPC     00000001 BXPC 00000001)

I had already added the kernel module tpm_tis_spi to /etc/modules. This is why I see:

$ lsmod | grep -i tpm
tpm_tis_spi            20480  0
tpm_tis_core           28672  1 tpm_tis_spi
tpm                   102400  2 tpm_tis_core,tpm_tis_spi
rng_core               20480  1 tpm

There seem to be some drivers available:

$ find /lib/modules/$(uname -r) -name '*tpm*'
/lib/modules/6.12.16-0-lts/kernel/drivers/char/tpm
/lib/modules/6.12.16-0-lts/kernel/drivers/char/tpm/tpm.ko.gz
/lib/modules/6.12.16-0-lts/kernel/drivers/char/tpm/tpm_tis_spi.ko.gz
/lib/modules/6.12.16-0-lts/kernel/drivers/char/tpm/tpm_tis_core.ko.gz
/lib/modules/6.12.16-0-lts/kernel/drivers/char/tpm/tpm_atmel.ko.gz
/lib/modules/6.12.16-0-lts/kernel/drivers/char/tpm/xen-tpmfront.ko.gz
/lib/modules/6.12.16-0-lts/kernel/drivers/char/tpm/tpm_infineon.ko.gz

/sys/class/tpm/ and /sys/class/tpmrm/ exist, but are empty. On the host, from tpm2_getcap properties-fixed I figured out that the TPM is an Infineon SLB9670. On the VM, this only gives an error message (as currently expected):

$ tpm2_getcap properties-fixed
ERROR:tcti:src/tss2-tcti/tcti-device.c:455:Tss2_Tcti_Device_Init() Failed to open specified TCTI device file /dev/tpmrm0: No such file or directory 
ERROR:tcti:src/tss2-tcti/tctildr-dl.c:149:tcti_from_file() Could not initialize TCTI file: device 
ERROR:tcti:src/tss2-tcti/tctildr.c:477:tctildr_init_context_data() Failed to instantiate TCTI 
ERROR: Could not load tcti, got: "(null)"

What am I missing?

Firstly, greetings and I hope you the reader is doing well. I have spent the last five days barely sleeping. I have been doing search engine research on many IT sites including Stack Exchange and also using ChatGPT and Gemini chatbots to guide me through this task, and I have so far been unsuccessful in resolving the issue. What am I trying to resolve, you might ask me? I installed Debian on this particular machine... I did a plain, unencrypted install. There are three disks in this server: - 1x NVMe drive, 1TB capacity, for /EFI /boot and / partitions, as well as swap space - 2x WD Red Pro 16TB drives, which are mirrored in a RAID1 LVM, where the /home partition resides, this was until recently also unencrypted Then, one of the 16TB Red Pro HDDs failed, causing the RAID1 array to degrade. I got the drive RMAd, received the replacement, placed it in the machine, and re-added to the RAID, it took a couple of days to sync but it did. Now the status is healthy. I was running Debian 12. I decided to wipe the NVMe and recreate the Server based on Ubuntu instead (I know it's a derivative). Before I added the replacement disk to sync, I encrypted the original disk with LUKS using the following command:

cryptsetup reencrypt --encrypt /dev/mapper/RAID-Home --reduce-device-size 32M --cipher aes-xts-plain64 --key-size 512

I also made sure to slightly shrink the partition size to fit the LUKS header. The process completed, disk 1 of 2 in the RAID is encrypted. Once the other disk was added and synced, I now have two encrypted disks, presumable 1:1 replica so the LUKS header and keys will be the same. Output of lsblk -fs:

Luks-33d0787e-jjjjj-jjjj-jjjj-jjjjjjjjjjj btrfs                                                       76f96749-7254-xxxxx-xxxx-xxxxxxx                  
└─RAID-Home                               crypto_LUKS       2                                         33d0787e-079e-yyyy-yyyy-yyyyyyyyyyyyu                  
  └─md0                                   LVM2_member       LVM2 001                                  O7T2lP-kQqv-zzzzz-zzzz-zzzz-zzzz-zzzzzz                
    ├─sda                                 linux_raid_member 1.2              ubuntu:raid_home         e9a3119b-e8b7-qqqq-qqqq-qqqqqqqqq                  
    └─sdb                                 linux_raid_member 1.2              ubuntu:raid_home         e9a3119b-e8b7-bbbbbb-bbbb-bbbbbbbbbbb                  
nvme0n1p1                                 vfat              FAT32                                     aaaa-aaaa                               479.9M     1% /boot/efi
└─nvme0n1                                                                                                                                                   
nvme0n1p2                                                                                                                                                   
└─nvme0n1                                                                                                                                                   
nvme0n1p3                                 swap              1                                         6b700b82-cccc-cccc-cccc-cccccccc                  [SWAP]
└─nvme0n1                                                                                                                                                   
nvme0n1p4                                 ext4              1.0                                       e7180d61-dddd-ddddd-dddd-dddddddd    791.3G     5% /var/snap/firefox/common/host-hunspell
│                                                                                                                                                           /
└─nvme0n1

My /etc/crypttab is:

#HomeDecrypted /dev/mapper/RAID-Home tpm2-device=auto,none,luks,discard
luks-33d0787e-jjjjj-jjjj-jjjj-jjjjjjjjjjj UUID=33d0787e-jjjjj-jjjj-jjjj-jjjjjjjjjjj tpm2-device=auto,none,luks,discard

And /etc/fstab:

#Home folder
# before encryption UUID=76f96749-nnnn-nnnn-nnnn-nnnnnnnnnnn  /home           btrfs    defaults        0       2
#after encryption:
/dev/mapper/HomeDecrypted   /home   btrfs   defaults,x-systemd.requires=systemd-cryptsetup@HomeDecrypted.service,x-systemd.after=systemd-cryptsetup@HomeDecrypted.service   0   0

This above is only the "latest" iteration of my attempts. I have tried all sorts of approaches recommended on the web and ChatGPT/Gemini with varying degrees of failure. I am literaly exhausted at this point. I want to learn where I'm going wrong and how to fix it. My goal: leave the system partitions (/EFI, /boot, /, and swap) in the NVMe drive untouched, while automatically mounting the /home partition with TPM upon reboot, because if there is a power cut that lasts longer than the UPS can maintain the system running, then it's set in the BIOS to automatically power on after power loss, this means the services would resume even if I am not presently able to type the LUKS passphrase manually on the boot screen. Please teach me how to fix, with instructions on whatever I need to do, but also explanation as to why and what it does. Thanks! I desperately need to sleep and I have no more energy :( I really need help to resolve this. PS-should be clear that obfuscated some data like partition IDs, for privacy reasons. PS2-if you require further information from my system (such as specific apt packages) then please tell me which commands I need to run and I'll edit this question and provide the output accordingly. Thanks in advance for your help!

Wanting to play around with [Trusted Platform Module](https://en.wikipedia.org/wiki/Trusted_Platform_Module) stuff, I installed [TrouSerS](http://trousers.sourceforge.net/) and tried to start [tcsd](https://linux.die.net/man/8/tcsd) , but I got this error: TCSD TDDL ERROR: Could not find a device to open! However, my kernel has multiple TPM modules loaded: # lsmod | grep tpm tpm_crb 16384 0 tpm_tis 16384 0 tpm_tis_core 20480 1 tpm_tis tpm 40960 3 tpm_tis,tpm_crb,tpm_tis_core So, how do I determine if my computer is lacking TPM vs TrouSerS having a bug? Neither [dmidecode](https://linux.die.net/man/8/dmidecode) nor [cpuid](https://linux.die.net/man/1/cpuid) output anything about "tpm" or "trust". Looking in /var/log/messages, on the one hand I see rngd: /dev/tpm0: No such file or directory, but on the other hand I see kernel: Initialise system trusted keyrings and according to [this kernel doc](https://www.kernel.org/doc/Documentation/security/keys-trusted-encrypted.txt) trusted keys use TPM. **EDIT**: My computer's BIOS setup menus mention nothing about TPM. Also, looking at /proc/keys: # cat /proc/keys ******** I--Q--- 1 perm 1f3f0000 0 65534 keyring _uid_ses.0: 1 ******** I--Q--- 7 perm 3f030000 0 0 keyring _ses: 1 ******** I--Q--- 3 perm 1f3f0000 0 65534 keyring _uid.0: empty ******** I------ 2 perm 1f0b0000 0 0 keyring .builtin_trusted_keys: 1 ******** I------ 1 perm 1f0b0000 0 0 keyring .system_blacklist_keyring: empty ******** I------ 1 perm 1f0f0000 0 0 keyring .secondary_trusted_keys: 1 ******** I------ 1 perm 1f030000 0 0 asymmetri Fedora kernel signing key: 34ae686b57a59c0bf2b8c27b98287634b0f81bf8: X509.rsa b0f81bf8 []

On Debian, how can I instruct clevis/initramfs to unlock **two** LUKS devices before booting? I currently have both devices configured to be unlocked through TPM2, which is correctly configured as I can regenerate the bindings without having to provide the volume password.

~# clevis luks regen -d /dev/nvme0n1 -s 1
Regenerating binding (device /dev/nvme0n1, slot 1):
Pin: tpm2, Config: '{"hash":"sha256","key":"ecc","pcr_bank":"sha256","pcr_ids":"REDACTED"}'
Do you want to proceed? [ynYN] y
Binding regenerated successfully
~# clevis luks regen -d /dev/nvme1n1p3 -s 0
Regenerating binding (device /dev/nvme1n1p3, slot 0):
Pin: tpm2, Config: '{"hash":"sha256","key":"ecc","pcr_bank":"sha256","pcr_ids":"REDACTED"}'
Do you want to proceed? [ynYN] y
Binding regenerated successfully

Within the /etc/crypttab, both devices are listed and the UUID matches the crypto_LUKS devices in blkid. Using update-initramfs -u does not complain about missing references.

nvme0n1_crypt UUID=REDACTED none luks,discard
nvme1n1p3_crypt UUID=REDACTED  none luks,discard

However, whenever I boot only the second device nvme1n1p3_crypt is automatically decrypted without the first device being mentioned at all. After a while, the boot fails with the following message.

Please unlock disk nvme1n1p3_crypt:
cryptsetup: nvme1n1p3_crypt: set up successfully
Gave up waiting for suspend/resume device
Gave up waiting for root file system device. Common problems:
   ...

(initramfs)

From there, I have to manually open the second device before proceeding.

(initramfs) cryuptsetup luksOpen /dev/nvme0n1 nvme0n1_crypt
Enter passphrase for /dev/nvme0n1: # Provided passphrase
(initramfs) exit
/dev/mapper/lab--vg-root: clean, REDACTED files, REDACTED blocks

The devices are set up as follow:

~# lsblk
NAME                                MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
nvme0n1                             259:0    0 -----  0 disk  
└─nvme0n1_crypt                     252:1    0 -----  0 crypt 
  ├─lab--vg-data_tmeta              252:4    0 -----  0 lvm   
  │ └─lab--vg-data-tpool            252:6    0 -----  0 lvm   
  │   ├─lab--vg-data                252:7    0 -----  1 lvm    
  │   └─...                         252:22   0 -----  0 lvm   
  └─lab--vg-data_tdata              252:5    0 -----  0 lvm   
    └─lab--vg-data-tpool            252:6    0 -----  0 lvm   
      ├─lab--vg-data                252:7    0 -----  1 lvm   
      └─...                         252:22   0 -----  0 lvm   
nvme1n1                             259:1    0 -----  0 disk  
├─nvme1n1p1                         259:2    0 -----  0 part  /boot/efi
├─nvme1n1p2                         259:3    0 -----  0 part  /boot
└─nvme1n1p3                         259:4    0 -----  0 part  
  └─nvme1n1p3_crypt                 252:0    0 -----  0 crypt 
    ├─lab--vg-root                  252:2    0 -----  0 lvm   /
    ├─lab--vg-swap_1                252:3    0 -----  0 lvm   [SWAP]
    ├─lab--vg-data_tmeta            252:4    0 -----  0 lvm   
    │ └─lab--vg-data-tpool          252:6    0 -----  0 lvm   
    │   ├─lab--vg-data              252:7    0 -----  1 lvm   
    │   └─...                       252:22   0 -----  0 lvm   
    └─lab--vg-data_tdata            252:5    0 -----  0 lvm   
      └─lab--vg-data-tpool          252:6    0 -----  0 lvm   
        ├─lab--vg-data              252:7    0 -----  1 lvm  
        └─...                       252:22   0 -----  0 lvm

~# uname -a
Linux lab 6.8.12-4-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-4 (2024-11-06T15:04Z) x86_64 GNU/Linux

I recently installed Ubuntu on an old SSD, as I wanted to test out some software on a different OS. After installing Ubuntu (using debootstrap, arch-chroot and apt), my EFI's NVRAM boot order got messed up, and the TPM2 will not now automatically unlock my Arch root and swap partitions. I am prompted to enter a recovery key or password. So, I know I need to update the PCR registers in the TPM. But I have a couple of questions: - How should I replace the entries in the old TPM2 PCR slots, instead of adding new ones? - Can someone explain why the TPM chip now fails to unlock my partitions, and what I should try and avoid doing again in future? My primary OS is Arch Linux, set up following a couple of articles: - [LUKS on a partition with TPM2 and Secure Boot](https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#LUKS_on_a_partition_with_TPM2_and_Secure_Boot) . - [Installing Archlinux with LUKS, SecureBoot, TPM](https://jpetazzo.github.io/2024/02/23/archlinux-luks-tpm-secureboot-install/) systemd-boot is used as bootloader. Two dm-crypt partitions are unlocked with the TPM at boot: - root - swap (allows for suspend and resume). After installing Ubuntu, both the root and swap volumes would not unlock with the TPM. ---- # How to invalidate the TPM PCR Registers # One thing I realised that I'd done incorrectly done was to install Ubuntu (into /media/ubuntu) before mounting /efi onto /media/ubuntu/boot/efi. So, after first installing Ubuntu with debootstrap, I then ran: - mount --bind /efi /media/ubuntu/boot/efi - arch-chroot /media/ubuntu - apt install grub-efi-amd64 (This removes grub-pc) - grub-install So, I now have one /efi partition, an encrypted /boot partition for Arch Linux, and the Ubuntu partition has a /boot folder. (There's a Windows bootloader too, so yeah, it's a mess...) grub's os-probe doesn't detect my Arch Linux install, so I had to get back in by pressing F11 at early boot and selecting Linux Boot Manager. At this point, systemd asks me to enter the unlock password or recovery key for my root partition. (I have both currently, so getting in isn't an issue, unless and until I reboot remotely). # My setup # _I've put down quite a lengthy list of diagnostic commands, which should be pretty helpful for anyone diagnosing something similar in future (me included, no doubt!)_ **Update:** The TPM was enrolled to unlock the encrypted partition on PCR 7, like so:

# Install the TPM tools
pacman -S tpm2-tools

# Check the name of the kernel module for our TPM
systemd-cryptenroll --tpm2-device=list

# Generate a recovery key (not mandatory but strongly recommended)
systemd-cryptenroll --recovery-key /dev/gpt-auto-root-luks

# Generate a key in the TPM2 and add it to a key slot in the LUKS device
systemd-cryptenroll --tpm2-device=auto /dev/gpt-auto-root-luks --tpm2-pcrs=7

# This is the command to use later, to remove the (insecure) initial password
#systemd-cryptenroll /dev/gpt-auto-root-luks --wipe-slot=password

My partition tables are quite busy:

$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sdb           8:16   0 238.5G  0 disk  
├─sdb1        8:17   0   128G  0 part  /media/ubuntu
├─sdb2        8:18   0   110G  0 part  
└─sdb3        8:19   0   527M  0 part  
nvme0n1     259:0    0 931.5G  0 disk  
├─nvme0n1p1 259:1    0   100M  0 part  
├─nvme0n1p2 259:2    0    16M  0 part  
├─nvme0n1p3 259:3    0 165.4G  0 part  
├─nvme0n1p4 259:4    0   507M  0 part  
├─nvme0n1p5 259:5    0     1G  0 part  
├─nvme0n1p6 259:6    0    32G  0 part  
│ └─swap    254:1    0    32G  0 crypt [SWAP]
├─nvme0n1p7 259:7    0   227G  0 part  
│ └─root    254:0    0   227G  0 crypt /
└─nvme0n1p8 259:8    0 505.5G  0 part  
  └─data    254:3    0 505.5G  0 crypt /var/lib/docker
                                       /media/data

$ sudo fdisk -l /dev/nvme0n1 /dev/sdb
Disk /dev/nvme0n1: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 980 PRO 1TB                 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt

Device             Start        End    Sectors   Size Type
/dev/nvme0n1p1      2048     206847     204800   100M EFI System (/efi)
/dev/nvme0n1p2    206848     239615      32768    16M Microsoft reserved
/dev/nvme0n1p3    239616  347119443  346879828 165.4G Microsoft basic data (Win 10)
/dev/nvme0n1p4 347119616  348157951    1038336   507M Windows recovery environment
/dev/nvme0n1p5 348157952  350255103    2097152     1G Linux extended boot (/boot)
/dev/nvme0n1p6 350255104  417363967   67108864    32G Linux swap
/dev/nvme0n1p7 417363968  893417471  476053504   227G Linux root (x86-64) (/)
/dev/nvme0n1p8 893417472 1953523711 1060106240 505.5G Linux filesystem (/media/data)

Disk /dev/sdb: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: M4-CT256M4SSD2  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sdb1            2048 268437503 268435456  128G 83 Linux (/media/ubuntu)
/dev/sdb2  *    268437504 499035680 230598177  110G  7 HPFS/NTFS/exFAT
/dev/sdb3       499036160 500115455   1079296  527M 27 Hidden NTFS WinRE

Secure Boot is installed, but not enabled:

$ sbctl status
Installed:	✓ sbctl is installed
Owner GUID:	1fd4cb4a-55ff-42f6-8dbb-285bfedf56de
Setup Mode:	✓ Disabled
Secure Boot:	✗ Disabled
Vendor Keys:	microsoft

My boot logs showing kernel command line and TPM related entries (showing it's loaded early):

$ sudo journalctl -k --grep='Command line|tpm|TPM'
Aug 30 06:10:03 archlinux kernel: Command line: initcall_blacklist=acpi_cpufreq_init amd_pstate=passive nvidia_drm.modeset=1 nvidia_drm.fbdev=1 ip=:::::eth0:dhcp
Aug 30 06:10:03 archlinux kernel: efi: ACPI=0xbd440000 ACPI 2.0=0xbd440014 TPMFinalLog=0xbd40a000 SMBIOS=0xbde22000 SMBIOS 3.0=0xbde21000 MEMATTR=0xb7f14018 ESRT=0xb7f14898 RNG=0xbcd38f18 INITRD=0xb6d12f18 TPMEvent>
Aug 30 06:10:03 archlinux kernel: ACPI: TPM2 0x00000000BCD50000 00004C (v04 ALASKA A M I    00000001 AMI  00000000)
Aug 30 06:10:03 archlinux kernel: ACPI: Reserving TPM2 table memory at [mem 0xbcd50000-0xbcd5004b]
Aug 30 06:10:03 archlinux kernel: tpm_crb MSFT0101:00: Disabling hwrng
Aug 30 06:10:03 archlinux systemd: systemd 256.5-1-arch running in system mode (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +K>
Aug 30 06:10:03 archlinux systemd: Starting TPM PCR Barrier (initrd)...
Aug 30 06:13:19 ryzenbeast systemd: systemd 256.5-1-arch running in system mode (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +>
Aug 30 06:13:19 ryzenbeast systemd: Expecting device /dev/tpm0...
Aug 30 06:13:19 ryzenbeast systemd: Listening on TPM PCR Measurements.
Aug 30 06:13:19 ryzenbeast systemd: Listening on Make TPM PCR Policy.
Aug 30 06:13:19 ryzenbeast systemd: Starting TPM PCR Machine ID Measurement...
Aug 30 06:13:19 ryzenbeast systemd: Starting Early TPM SRK Setup...

Kernel Modules and Hooks:

# mkinitcpio.conf
MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)
HOOKS=(base systemd autodetect microcode modconf keyboard keymap consolefont sd-vconsole block sd-tinyssh encryptssh sd-encrypt filesystems resume fsck)

LUKS header key slots:

$ sudo systemd-cryptenroll /dev/disk/by-partlabel/archlinux
SLOT TYPE    
   0 password
   1 recovery
   2 tpm2
$ sudo systemd-cryptenroll /dev/disk/by-partlabel/swap
SLOT TYPE    
   0 password
   1 tpm2

Signed files:

$ sbctl verify
Verifying file database and EFI images in /efi...
✓ /boot/EFI/Linux/arch-linux-fallback.efi is signed
✓ /boot/EFI/Linux/arch-linux.efi is signed
✗ /efi/EFI/Boot/bootx64.efi is not signed (this became signed after running bootctl install)
✓ /efi/EFI/systemd/systemd-bootx64.efi is signed
✓ /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed is signed
✗ /efi/EFI/GRUB/grubx64.efi is not signed
✗ /efi/EFI/Manjaro/grubx64.efi is not signed
✗ /efi/EFI/Microsoft/Boot/Resources/bootres.dll is not signed
✗ /efi/EFI/Microsoft/Boot/Resources/en-US/bootres.dll.mui is not signed
✗ /efi/EFI/Microsoft/Boot/bg-BG/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/bg-BG/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/bootmgfw.efi is not signed
✗ /efi/EFI/Microsoft/Boot/bootmgr.efi is not signed
✗ /efi/EFI/Microsoft/Boot/cs-CZ/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/cs-CZ/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/cs-CZ/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/da-DK/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/da-DK/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/da-DK/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/de-DE/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/de-DE/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/de-DE/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/el-GR/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/el-GR/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/el-GR/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/en-GB/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/en-GB/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/en-US/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/en-US/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/en-US/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/es-ES/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/es-ES/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/es-ES/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/es-MX/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/es-MX/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/et-EE/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/et-EE/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fi-FI/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fi-FI/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fi-FI/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fr-CA/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fr-CA/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fr-FR/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fr-FR/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/fr-FR/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/hr-HR/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/hr-HR/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/hu-HU/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/hu-HU/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/hu-HU/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/it-IT/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/it-IT/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/it-IT/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ja-JP/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ja-JP/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ja-JP/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_10df.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_10ec.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_1137.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_14e4.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_15b3.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_1969.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_19a2.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_1af4.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_02_8086.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_07_1415.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kd_0C_8086.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kdnet_uart16550.dll is not signed
✗ /efi/EFI/Microsoft/Boot/kdstub.dll is not signed
✗ /efi/EFI/Microsoft/Boot/ko-KR/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ko-KR/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ko-KR/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/lt-LT/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/lt-LT/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/lv-LV/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/lv-LV/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/memtest.efi is not signed
✗ /efi/EFI/Microsoft/Boot/nb-NO/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/nb-NO/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/nb-NO/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/nl-NL/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/nl-NL/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/nl-NL/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pl-PL/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pl-PL/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pl-PL/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pt-BR/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pt-BR/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pt-BR/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pt-PT/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pt-PT/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/pt-PT/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/qps-ploc/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ro-RO/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ro-RO/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ru-RU/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ru-RU/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/ru-RU/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sk-SK/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sk-SK/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sl-SI/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sl-SI/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sr-Latn-RS/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sr-Latn-RS/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sv-SE/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sv-SE/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/sv-SE/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/tr-TR/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/tr-TR/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/tr-TR/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/uk-UA/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/uk-UA/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/zh-CN/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/zh-CN/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/zh-CN/memtest.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/zh-TW/bootmgfw.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/zh-TW/bootmgr.efi.mui is not signed
✗ /efi/EFI/Microsoft/Boot/zh-TW/memtest.efi.mui is not signed
✗ /efi/EFI/ubuntu/grubx64.efi is not signed

Systemd measurements

$ sudo /usr/lib/systemd/systemd-measure status
# PCR kernel-boot
11:sha1=
11:sha256=
# PCR kernel-config (NOT SET!)
12:sha1=0000000000000000000000000000000000000000
12:sha256=0000000000000000000000000000000000000000000000000000000000000000
# PCR sysexts (NOT SET!)
13:sha1=0000000000000000000000000000000000000000
13:sha256=0000000000000000000000000000000000000000000000000000000000000000

$ sudo /usr/lib/systemd/systemd-measure calculate --current --bank=sha1 --bank=sha256
# PCR Phase 
11:sha1=
11:sha256=
# PCR Phase 
11:sha1=
11:sha256=
# PCR Phase 
11:sha1=
11:sha256=
# PCR Phase 
11:sha1=
11:sha256=

Test opening the root partition with TPM

$ sudo cryptsetup open --test-passphrase /dev/nvme0n1p7
Failed to unseal secret using TPM2: Operation not permitted
Enter passphrase for /dev/nvme0n1p7:

Current PCR slots

$ systemd-analyze pcrs
NR NAME                SHA256                                                          
 0 platform-code       
 1 platform-config     
 2 external-code       
 3 external-config     
 4 boot-loader-code    
 5 boot-loader-config  
 6 host-platform       
 7 secure-boot-policy  
 8 -                   0000000000000000000000000000000000000000000000000000000000000000
 9 kernel-initrd       
10 ima                 0000000000000000000000000000000000000000000000000000000000000000
11 kernel-boot         
12 kernel-config       0000000000000000000000000000000000000000000000000000000000000000
13 sysexts             0000000000000000000000000000000000000000000000000000000000000000
14 shim-policy         0000000000000000000000000000000000000000000000000000000000000000
15 system-identity     
16 debug               0000000000000000000000000000000000000000000000000000000000000000
17 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
18 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
19 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
20 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
21 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
22 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
23 application-support 0000000000000000000000000000000000000000000000000000000000000000

# Adding a new TPM entry # I know I can add a new TPM entry and delete the old one with the following command:

# Enroll TPM (again).
$ sudo systemd-cryptenroll --tpm2-device=auto /dev/nvme0n1p7`
🔐 Please enter current passphrase for disk /dev/nvme0n1p7:
New TPM2 token enrolled as key slot 3.

# List LUKS unlock slots on my root partition.
$ sudo systemd-cryptenroll /dev/nvme0n1p7 
SLOT TYPE    
   0 password
   1 recovery
   2 tpm2
   3 tpm2

# Wipe the old tpm2 entry
$ sudo systemd-cryptenroll /dev/nvme0n1p7 --wipe-slot=2
Wiped slot 2.

# Test I can open it
$ sudo cryptsetup open --test-passphrase /dev/nvme0n1p7
$

# Update: System Journal Entries # I checked journalctl -u systemd-cryptsetup@root to see if I can hunt down some more info before and after the first failed boot. On a successful boot:

Aug 27 09:46:02 archlinux systemd: Starting Cryptography Setup for root...
Aug 27 09:46:02 archlinux systemd-cryptsetup: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/gpt-auto-root-luks.
Aug 27 09:46:02 archlinux systemd-cryptsetup: Automatically discovered security TPM2 token unlocks volume.
Aug 27 09:46:04 archlinux systemd-cryptsetup: Successfully extended PCR index 15 with 'cryptsetup:root:' and volume key (banks sha1, sha256).
Aug 27 09:46:04 archlinux systemd: Finished Cryptography Setup for root.

On the next, failed boot:

Aug 28 08:09:52 archlinux systemd: Starting Cryptography Setup for root...
Aug 28 08:09:52 archlinux systemd-cryptsetup: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/gpt-auto-root-luks.
Aug 28 08:09:52 archlinux systemd-cryptsetup: Automatically discovered security TPM2 token unlocks volume.
Aug 28 08:09:53 archlinux systemd-cryptsetup: Failed to unseal secret using TPM2: Operation not permitted
Aug 28 08:09:53 archlinux systemd-cryptsetup: No valid TPM2 token data found.
Aug 28 08:09:53 archlinux systemd-cryptsetup: No TPM2 metadata matching the current system state found in LUKS2 header, falling back to traditional unlocking.
Aug 28 08:10:21 archlinux systemd-cryptsetup: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/gpt-auto-root-luks.
Aug 28 08:10:24 archlinux systemd-cryptsetup: Failed to activate with specified passphrase. (Passphrase incorrect?)
Aug 28 08:10:30 archlinux systemd-cryptsetup: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/gpt-auto-root-luks.
Aug 28 08:10:33 archlinux systemd-cryptsetup: Successfully extended PCR index 15 with 'cryptsetup:root:' and volume key (banks sha1, sha256).
Aug 28 08:10:33 archlinux systemd: Finished Cryptography Setup for root.

Seeing mention of PCR15 here, explained in man systemd-cryptenroll as: > systemd-cryptsetup(8) optionally measures the volume key of activated > LUKS volumes into this PCR. systemd-pcrmachine.service(8) measures > the machine-id(5) into this PCR. systemd-pcrfs@.service(8) measures > mount points, file system UUIDs, labels, partition UUIDs of the > root and /var/ filesystems into this PCR. It would appear that these measurements would have changed by (re-)formatting a partition and would be enough to corrupt this PCR register... # Overhanging Questions # Now I've looked into fixing this and effectively have done, I have questions! - What caused the TPM slot value to become incorrect? - If I update Ubuntu's kernel or initrd, will it happen again? - How to prevent this from happening again? - I see systemd introduced a [pcrlock tool](https://www.freedesktop.org/software/systemd/man/latest/systemd-pcrlock.html) in [November 2023](https://github.com/systemd/systemd/pull/28891) , but (I think) it is still experimental and I don't fully understand it, nor do I know if it would help. Would it? - **Update:** How should I update PCR 15 after formatting a partition?

Currently, I try to understand how a measured boot is working and what components log what in which pcr of a tpm2. I have a test-setup with uefi-secure boot enabled and a tpm2 attached in a kvm virtualized machine. I compiled my own kernel with tpm support etc. tpm2_pcrread gives reasonable output. Now I want to look inside the events of the tpm. But there is no /sys/kernel/security/tpm0 and therefore no binary_bios_measurement. If I live boot from the ubuntu 23.10 iso, the file is present and can be read by tpm2_eventlog. So i take the kernel from ubuntu and booted the system with it, but also here, there is no /sys/kernel/security/tpm0. No my guess is, that i miss kernel module that exposes this. Or systemd in ubuntu creates this path. I do not find any documentation about this. I do not know how to find out where and who creates this path/file. Does someone know how to expose the binary_bios_measurement? PS. on my own linux I am using OpenRc and not systemd.

When following instructions on how to import a GPG key to a TPM, I get the following error: gpg: error from TPM: Card error.

bash
$ gpg --edit-key 
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.



gpg> keytotpm
Really move the primary key? (y/N) y
gpg: error from TPM: Card error

The man page for tpm2_load has the following example: > To load an object you first must create an object under a primary object. So the first step is to create the primary object. > > tpm2_createprimary -c primary.ctx > > > Step 2 is to create an object under the primary object. > > tpm2_create -C primary.ctx -u key.pub -r key.priv What exactly is the primary.ctx file that is created by tpm2_createprimary and used by tpm2_create? The man page for tpm2_createprimary calls it the "object context": > -c, --key-context=FILE: > > The file path to save the object context of the generated primary object. And I can get some information about the file's contents with tpm2_print -t TPMS_CONTEXT primary.ctx:

version: 1
hierarchy: owner
handle: 0x80000000 (2147483648)
sequence: 128
contextBlob:
        size: 1506

But I still don't understand what I'm looking at. What is this "object context" file and why is it necessary?

Is there any command to check if TPM2.0 is owned (i.e., ownership is taken) and if TPM is enabled on Ubuntu 16.04? For TPM1.2 this was possible with

cat /sys/class/tpm/tpm0/device/owned

We are using TPM2.0, Intel TXT, Ubuntu 16.04 and DL380Gen10 server

TPMs are supposed to solve a chicken and egg problem of where to store unencrypted disk encryption keys such that someone can't simply pop another hard drive in the machine, boot a different OS and read the keys right off the disk / flash / BIOS / ... AFAIK TPMs basically do this by checking what software booted and, if that software doesn't match a preset hash, it will remain locked and refuse to give out the disk encryption keys. I've read numerous articles pointing to the fact that systemd can help embed my LUKS keys in a TPM with systemd-cryptenroll . But these only speak of embedding the key in the TPM, and not preventing attackers reading those keys. Where I'm stuck is figuring out how to ensure there's a solid chain of trust from BIOS firmware to login ensuring that if the OS is tampered with it will either not boot, or the TPM will refuse to hand over the encryption key. For example there's not much use in encrypting my hard drive if someone at the terminal could simply press E at the grub prompt and boot linux with init=/bin/bash to give themselves a root login without needing a password. Encryption would be utterly pointless in that situation. I'm stuck on two fairly specific points: - What does a typical systemd based distribution (Debian or Ubuntu) do to lock the TPM in the first place. What files does this protect from tampering? - What other things in the boot sequence must I harden from tampering? - eg: grub EFI binary, grub.cfg in EFI, grub passwordles editing boot entries, initramfs, ...

I have been investigating using the TPM2.0 for secure persistence of secrets using the tpm2-tools . It seems sealing objects are the way to go for this kind of thing. I am hoping someone here might be able to better explain how sealing objects are related to the parent 'primary objects' that they are created and loaded under, especially when password auth values are involved. I've been a bit confused by some examples I've put together (below) that allow various operations without supplying the passwords I would have thought were required. --- *(note: many of the examples below in practice require calls to tpm2_flushcontext -t to clear out space for intermediate object loading, but I have excluded them for brevity)* As part of my evaluation I have learnt that sealing objects must always be created underneath some other 'primary object'/primary key that must be created first. # make a new primary key $ tpm2_createprimary -C o -c testprim.ctx # make a new sealing object under this primary key $ tpm2_create -u testseal.pub -r testseal.priv -i hunter2.txt -C testprim.ctx These primary objects can optionally be created with password auth values on them. As you'd expect, trying to create a sealing object via a password-protected primary object without supplying its password doesn't work: $ tpm2_createprimary -C o -p str:testpwd -c testprim-wauth.ctx $ tpm2_create -u testseal-wpauth.pub -r testseal-wpauth.priv -i hunter2.txt -C testprim-wauth.ctx WARNING:esys:src/tss2-esys/api/Esys_Create.c:398:Esys_Create_Finish() Received TPM Error ERROR:esys:src/tss2-esys/api/Esys_Create.c:134:Esys_Create() Esys Finish ErrorCode (0x0000098e) ERROR: Esys_Create(0x98E) - tpm:session(1):the authorization HMAC check failed and DA counter incremented ERROR: Unable to run tpm2_create $ tpm2_create -u testseal-wpauth.pub -r testseal-wpauth.priv -i hunter2.txt -C testprim-wauth.ctx -P str:testpwd # OK What confuses me a bit is that loading and unsealing one of these created-under-the-auth-protected-primary-key objects works fine if the loading is done under a different *non-authed* primary key: # no password required here $ tpm2_load -C testprim.ctx -u testseal-wpauth.pub -r testseal-wpauth.priv -n testseal-loadedwnopauth.name -c testseal-loadedwnopauth.ctx $ tpm2_unseal -c testseal-loadedwnopauth.ctx hunter2 However, if loading under the auth-value-protected primary key, the password is required as expected for the loading... # Try load without password $ tpm2_load -C testprim-wauth.ctx -u testseal-wpauth.pub -r testseal-wpauth.priv -n testseal-loadedwpauth.name -c testseal-loadedwpauth.ctx WARNING:esys:src/tss2-esys/api/Esys_Load.c:324:Esys_Load_Finish() Received TPM Error ERROR:esys:src/tss2-esys/api/Esys_Load.c:112:Esys_Load() Esys Finish ErrorCode (0x0000098e) ERROR: Eys_Load(0x98E) - tpm:session(1):the authorization HMAC check failed and DA counter incremented ERROR: Unable to run tpm2_load # with password: $ tpm2_load -C testprim-wauth.ctx -u testseal-wpauth.pub -r testseal-wpauth.priv -n testseal-loadedwpauth.name -c testseal-loadedwpauth.ctx -P str:testpwd # OK ...but the unsealing still works without a password too. $ tpm2_unseal -c testseal-loadedwpauth.ctx hunter2 However, I'm assuming this is because the sealing object itself has no password on it. If the sealing object itself is given a password auth value (-p flag in tpm2_create) then it can never be unsealed without that password, which is expected behaviour, so that at least works fine. I am just confused as to why things created under password-protected primary keys can still be seemingly used later without needing that password. Is the password purely for the ability to create subsequent child objects under the primary key? Am I missing something here?

I'm experiencing system freezes and looking in the journal I see kernel (4.14.15-1-MANJARO) errors such as: kernel: tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buffer. [mem 0xfed40000-0xfed4087f flags 0x201] vs fed40080 f80 kernel: tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buffer. [mem 0xfed40000-0xfed4087f flags 0x201] vs fed40080 f80 (Yes the message is repeated, with exactly the same timestamp) A bit later, I get: tpm tpm0: A TPM error (379) occurred attempting get random I'm running the latest version of firmware (v3.05) for my Asus UX330. My kernel is: 4.16.0-1-MANJARO #1 SMP PREEMPT Wed Mar 21 09:02:49 UTC 2018 x86_64 GNU/Linux Is there any workaround besides praying for an updated UEFI / BIOS firmware from Asus?

**System: Fedora 37, Gnome 43** I enabled LUKS encryption on setup and enabled auto-decrypt via TPM 2 with following an article from Fedora Magazine. Auto-decrypt works but while it decrypts, it shows the passphrase screen until system boots. How can I hide this screen?

I cannot figure out how to get clevis to auto-decrypt my root partition on boot. # What I want I want to use the TPM2 chip on my kali PC to have an encrypted disk that self-decrypt on boot. The main purpose is to prevent the data leak in case of stolen drive/computer. # What I did I first encrypted in luks1 my / partition (/dev/sda2) from a bootable drive using cryptsetup-reencrypt I edited grub config, fstab and crypttab, ran update-grub and update-initramfs. This allowed me to boot on the encrypted root partition, and asks me for luks password twice I then installed clevis and binded luks to the TPM using : sudo clevis luks bind -d /dev/sda2 tpm2 '{"pcr_bank":"sha256","pcr_ids":"7"}' I can see that it used a new keyslot on luks header. I activated the service 'clevis-luks-askpass.path, updated grub and initramfs again. But on reboot, I'm still prompted for a password. I tried waiting a few minutes but nothing happens. Am I missing something ? # What I Have Partitions : I have everything in the same partition (including /boot). The only other partition is the efi **Filesystem**

$ lsblk -fs     
                    
NAME    FSTYPE      FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda1    vfat        FAT32       08C3-0099                             510,8M     0% /boot/efi
└─sda                                                                               
root    ext4        1.0         55d30c15-a2a5-4721-b679-0e8746c54768  183,6G    16% /
└─sda2  crypto_LUKS 1           49e3950a-b1a9-449e-aeec-757bba148a84                
  └─sda

**Grub**

$ cat /etc/default/grub

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=lsb_release -i -s 2> /dev/null || echo Debian
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
GRUB_ENABLE_CRYPTODISK=y
GRUB_PRELOAD_MODULES="luks cryptodisk"

**Fstab**

$ cat /etc/fstab

# /boot/efi was on /dev/sda1 during installation
UUID=08C3-0099  /boot/efi       vfat    umask=0077      0       1
# swap was on /dev/sda3 during installation
/swapfile       none            swap    sw              0       0

# new root
UUID=49e3950a-b1a9-449e-aeec-757bba148a84 / ext4 errors=remount-ro 0 1

**Crypttab**

$ cat /etc/crypttab
#                 
root UUID=49e3950a-b1a9-449e-aeec-757bba148a84 none luks

**Clevis packages**

$ apt list --installed | grep clevis

clevis-initramfs/kali-rolling,now 18-2+b1 amd64  [installed]
clevis-luks/kali-rolling,now 18-2+b1 amd64  [installed]
clevis-systemd/kali-rolling,now 18-2+b1 amd64  [installed]
clevis-tpm2/kali-rolling,now 18-2+b1 amd64  [installed]
clevis/kali-rolling,now 18-2+b1 amd64  [installed]

**clevis-luks-askpass.path**

$ sudo systemctl status clevis-luks-askpass.path

● clevis-luks-askpass.path - Forward Password Requests to Clevis Directory Watch
     Loaded: loaded (/lib/systemd/system/clevis-luks-askpass.path; enabled; vendor preset: enabled)
     Active: active (waiting) since Wed 2022-07-06 14:10:04 CEST; 1h 16min ago
      Until: Wed 2022-07-06 14:10:04 CEST; 1h 16min ago
   Triggers: ● clevis-luks-askpass.service
       Docs: man:clevis-luks-unlockers(7)

Notice: journal has been rotated since unit was started, output may be incomplete.

**lsb_release**

$ lsb_release -a

No LSB modules are available.
Distributor ID:	Kali
Description:	Kali GNU/Linux Rolling
Release:	2022.2
Codename:	kali-rolling

I have an Ubuntu 20.04 machine setup that I am trying to configure for disk encryption. I am trying to setup auto unlock, but my configuration has not worked so far, and I am always prompted for a password. To do this I followed the following steps: 1. sudo apt-get update and sudo apt-get install cryptsetup 2. Check /dev/nvme0n1p3 -> sudo cryptsetup luksDump /dev/nvme0n1p3 -> No Tokens or Keyslots 3. Install clevis, clevis-luks, clevis-dracut, clevis-udisks2, clevis-systemd, clevis-tpm2 4. sudo clevis luks list -d /dev/nvme0n1p3 -> Empty 5. echo | sudo clevis luks bind -d /dev/nvme0n1p3 tpm2 '{ "pcr_bank":"sha256", "pcr_ids": "7,11" }' 6. sudo dracut -fv --regenerate-all 7. Check sudo clevis luks list -d /dev/nvme0n1p3 -> 1: tpm2 '{"hash":"sha256","key":"ecc","pcr_bank":"sha256","pcr_ids":"7,11"}' 8. lsblk -o NAME,UUID,MOUNTPOINT ->

├─nvme0n1p1                                               /boot/efi
├─nvme0n1p2                    /boot
└─nvme0n1p3                    
  └─dm_crypt-0               
    └─ubuntu--vg-ubuntu--lv    /

9. cat /etc/crypttab -> dm_crypt-0 UUID= none luks When booting I do not notice any errors for cryptsetup, luks, tpm2. Googling around and checking others questions, I have also verified tried: 1. sudo systemctl enable clevis-luks-askpass.path 2. update-initramfs -c -k all -> Runs successfully My fstab file doesn't actually list the encrypted partition: cat /etc/fstab ->

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#                
# / was on /dev/ubuntu-vg/ubuntu-lv during curtin installation
/dev/disk/by-id/ / ext4 defaults 0 1
# /boot was on /dev/nvme0n1p2 during curtin installation
/dev/disk/by-uuid/ /boot ext4 defaults 0 1
# /boot/efi was on /dev/nvme0n1p1 during curtin installation
/dev/disk/by-uuid/ /boot/efi vfat defaults 0 1
/swap.img	none	swap	sw	0	0

I've also tried manually adding in the partition to fstab but did not work. No matter what I try, it always asks for password on boot. What could I do to fix this?

I am currently aware of two recent methods to bind a LUKS encrypted root partition to a TPM2: systemd-cryptenroll and clevis. Both of them seem to release the encryption key after successfully checking the PCRs the key was sealed against. But I don't like the idea of the volume being decrypted without user interaction. I'd rather have a solution like it is offered by BitLocker for Windows: Either TPM and an additional PIN or a recovery key. Even though I searched the web quite exhaustively I was not able to find any hints in this direction. Is anybody aware of a solution? EDIT: There is a --recovery-key option for systemd-cryptenroll. I'm only concerned with the question how to get an additional PIN requirement when using the TPM.

**Situation:** I'm learning how to use some of the basic commands in the tpm2-tools software package because I have to develop some high-level test cases to verify a TPM is handling keys per customer requirements. The computer I'm using to demo test methods is a Dell 7510 laptop with a TPM 2.0 chip and Ubuntu 22.04 LTS. Since I'm entirely unfamiliar with this technology and how to use it, I'm starting by following the examples in the help documentation . For now, I'm focused on understanding the tpm2_load command and the example documented in its help page . (I wrote out the process in the next section.) What I don't understand is why the key generated as a result of the tpm2_load command (

.ctx

in my process section) is stored on the hard drive of my computer. Shouldn't it be stored on the TPM? And how can I inspect the memory of the TPM to manually verify that the key is loaded on it? **Process:** Below is the sequence of commands I executed, which seem to have successful: $ sudo tpm2_createprimary -c key_prim.ctx $ sudo tpm2_create -C key_prim.ctx -u key.pub -r key.priv $ sudo tpm2_load -C key_prim.ctx -u key.pub -r key.priv -c key_load.ctx I can encrypt/decrypt messages using these keys, and I can seemingly certify that

.ctx

is valid using

(by seemingly, I mean that I can execute the command and it doesn't return an error message). Everything appears to be working normally, but I'm still baffled by the fact that the key I supposedly loaded also exists on my hard drive.

Hopefully, this is a simple question regarding hardware I'm just now learning how to use: the TPM. My laptop has a TPM 2.0, and I need to become familiar with some basic functionality offered by the tpm2-tools package. To start, I confirmed that the tpm2-abrmd (the daemon) service is active. Then I ran

sudo tpm2_selftest -V

and was expecting a verbose output in the terminal. However, nothing is output in the terminal when I execute the command. The manual describes the messages sent by the TPM but not *where* they are sent/logged. I checked /var/log/syslog but found nothing. Does anyone know where the messaging data is stored? Or if it *is* stored, for that matter?