Início / unix / Perguntas / 782761
Accepted
Alex Leach
Asked: 2024-08-30 16:51:04 +0800 CST

Quando os slots TPM falham ao desbloquear partições e como atualizá-los corretamente?

  • 772

Recentemente, instalei o Ubuntu em um SSD antigo, pois queria testar algum software em um sistema operacional diferente. Depois de instalar o Ubuntu (usando debootstrap, arch-chroote apt), a ordem de inicialização da NVRAM do meu EFI ficou bagunçada, e o TPM2 não desbloqueará automaticamente minhas partições raiz e swap do Arch. Sou solicitado a inserir uma chave de recuperação ou senha.

Então, eu sei que preciso atualizar os registros de PCR no TPM. Mas tenho algumas perguntas:

  • Como devo substituir as entradas nos antigos slots TPM2 PCR, em vez de adicionar novas?
  • Alguém pode explicar por que o chip TPM agora não consegue desbloquear minhas partições e o que devo tentar evitar fazer novamente no futuro?

Meu sistema operacional principal é o Arch Linux, configurado seguindo alguns artigos:

systemd-booté usado como bootloader.

Duas partições dm-crypt são desbloqueadas com o TPM na inicialização:

  • root
  • swap(permite suspender e retomar).

Após instalar o Ubuntu, os volumes roote swapnão foram desbloqueados com o TPM.

Como invalidar os Registros TPM PCR

Uma coisa que percebi que fiz incorretamente foi instalar o Ubuntu (em /media/ubuntu) antes de montar /efiem /media/ubuntu/boot/efi. Então, depois de instalar o Ubuntu com debootstrap, executei:

  • mount --bind /efi /media/ubuntu/boot/efi
  • arch-chroot /media/ubuntu
  • apt install grub-efi-amd64(Isso remove grub-pc)
  • grub-install

Então, agora tenho uma /efipartição, uma /bootpartição criptografada para o Arch Linux, e a partição do Ubuntu tem uma /bootpasta. (Há um bootloader do Windows também, então sim, é uma bagunça...)

grub's os-probenão detecta minha instalação do Arch Linux, então tive que voltar pressionando F11no início da inicialização e selecionando Linux Boot Manager. Neste ponto, systemdpede para eu digitar a senha de desbloqueio ou a chave de recuperação para minha partição raiz. (Eu tenho as duas atualmente, então entrar não é um problema, a menos e até que eu reinicie remotamente).

Minha configuração

Coloquei uma longa lista de comandos de diagnóstico, que devem ser muito úteis para qualquer um que esteja diagnosticando algo semelhante no futuro (eu incluso, sem dúvida!)

Atualização: O TPM foi registrado para desbloquear a partição criptografada no PCR 7, assim:

# 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

Minhas tabelas de partição estão bastante ocupadas:

$ 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

O Secure Boot está instalado, mas não habilitado:

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

Meus logs de inicialização mostrando a linha de comando do kernel e entradas relacionadas ao TPM (mostrando que ele foi carregado antecipadamente):

$ 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[1]: 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[1]: Starting TPM PCR Barrier (initrd)...
Aug 30 06:13:19 ryzenbeast systemd[1]: 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[1]: Expecting device /dev/tpm0...
Aug 30 06:13:19 ryzenbeast systemd[1]: Listening on TPM PCR Measurements.
Aug 30 06:13:19 ryzenbeast systemd[1]: Listening on Make TPM PCR Policy.
Aug 30 06:13:19 ryzenbeast systemd[1]: Starting TPM PCR Machine ID Measurement...
Aug 30 06:13:19 ryzenbeast systemd[1]: Starting Early TPM SRK Setup...

Módulos e ganchos do kernel:

# 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)

Slots de chave de cabeçalho LUKS:

$ 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

Arquivos assinados:

$ 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

Medições do Systemd

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

$ sudo /usr/lib/systemd/systemd-measure calculate --current --bank=sha1 --bank=sha256
# PCR[11] Phase <enter-initrd>
11:sha1=<SHA1SUM_2>
11:sha256=<SHA256SUM_2>
# PCR[11] Phase <enter-initrd:leave-initrd>
11:sha1=<SHA1SUM_3>
11:sha256=<SHA256SUM_3>
# PCR[11] Phase <enter-initrd:leave-initrd:sysinit>
11:sha1=<SHA256SUM_4>
11:sha256=<SHA256SUM_4>
# PCR[11] Phase <enter-initrd:leave-initrd:sysinit:ready>
11:sha1=<SHA256SUM_5>
11:sha256=<SHA256SUM_5>

Teste a abertura da partição raiz com TPM

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

Slots PCR atuais

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

Adicionando uma nova entrada TPM

Sei que posso adicionar uma nova entrada TPM e excluir a antiga com o seguinte comando:

# 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
$

Atualização: Lançamentos de diário do sistema

Verifiquei journalctl -u systemd-cryptsetup@rootse conseguia obter mais informações antes e depois da primeira inicialização com falha.

Em uma inicialização bem-sucedida:

Aug 27 09:46:02 archlinux systemd[1]: Starting Cryptography Setup for root...
Aug 27 09:46:02 archlinux systemd-cryptsetup[407]: 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[407]: Automatically discovered security TPM2 token unlocks volume.
Aug 27 09:46:04 archlinux systemd-cryptsetup[407]: Successfully extended PCR index 15 with 'cryptsetup:root:<UUID>' and volume key (banks sha1, sha256).
Aug 27 09:46:04 archlinux systemd[1]: Finished Cryptography Setup for root.

Na próxima inicialização com falha:

Aug 28 08:09:52 archlinux systemd[1]: Starting Cryptography Setup for root...
Aug 28 08:09:52 archlinux systemd-cryptsetup[403]: 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[403]: Automatically discovered security TPM2 token unlocks volume.
Aug 28 08:09:53 archlinux systemd-cryptsetup[403]: Failed to unseal secret using TPM2: Operation not permitted
Aug 28 08:09:53 archlinux systemd-cryptsetup[403]: No valid TPM2 token data found.
Aug 28 08:09:53 archlinux systemd-cryptsetup[403]: 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[403]: 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[403]: Failed to activate with specified passphrase. (Passphrase incorrect?)
Aug 28 08:10:30 archlinux systemd-cryptsetup[403]: 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[403]: Successfully extended PCR index 15 with 'cryptsetup:root:<UUID>' and volume key (banks sha1, sha256).
Aug 28 08:10:33 archlinux systemd[1]: Finished Cryptography Setup for root.

Vendo menção de PCR15 aqui, explicado man systemd-cryptenrollcomo:

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. [email protected](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 in November 2023, 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?
systemd

1 respostas

  1. Best Answer

    So, I know I need to update the PCR registers in the TPM

    It works the opposite way. The boot process updates PCR registers to represent current system state, while your LUKS keyslot (sealed by the TPM, but actually stored within the LUKS header on disk) is bound to a specific "expected" PCR value.

    Secure Boot is installed, but not enabled

    Then binding to PCR 7 doesn't do you any good, as it is the PCR that represents Secure Boot state only, so without SB it doesn't protect you against state changes (e.g. an unsigned kernel remains possible to tamper with).

    The keyslot is still bound to the physical hardware, yes, but that's an inherent property of the TPM sealing operation – you'd get the same effect even without PCR binding.

    What caused the TPM slot value to become incorrect?

    There are two general causes:

    1. The SRK (storage root key) stored in the TPM has been replaced.

    2. The policy that was specified during sealing no longer matches reality, e.g. if the data was sealed to specific raw PCR values, the live PCRs no longer match expected ones.

    Case #1 is, in theory, very unlikely to happen without a full TPM clear, but...I have a vague recollection of certain changes in a very recent systemd version that changed how the EC SRK was generated.

    (TPM2 SRKs are generated deterministically from seed+template, so whereas an RSA SRK is generated once and stored, an EC SRK can be generated on the fly. If I recall correctly, earlier systemd versions used to provide a not-quite-standard template that resulted in a different SRK compared to later versions.)

    Case #2 depends on what PCRs were used. Each PCR is a rolling hash of specific events that the firmware (or bootloader, or sometimes the OS) writes to an in-memory log; functionally like a Git commit log. The event log can be read from Windows or Linux, e.g. using "tcg-log-parser".

    For PCR 7, the only measurements should be 1) whether Secure Boot is enabled at all, 2) the current state of all the Secure Boot variables (PK/KEK/db/dbx), and 3) the specific db entries used to validate every signed file.

    (The latter means that PCR 7 will distinguish Windows and non-Windows boot files, or MS-signed vs custom-signed boot files, so you can actually keep the MS UEFI CA active without it compromising your custom-signed system.)

    It's possible that the Secure Boot state changed by Windows or Linux installing a new dbx list (revoked bootloader signatures) through fwupd or Windows Update. But only traveling back in time and getting a before/after comparison of the full event log would give you a definite answer. (Or, if you boot Windows often, it keeps a stash of event log archives somewhere in C:\Windows.)

    If I update Ubuntu's kernel or initrd, will it happen again?

    Depends on the PCR binding – it should not happen with PCR 7 as long as the Secure Boot configuration doesn't change.

    On the other hand, e.g. using PCR 4 (which contains events recording the exact hashes of the bootloader and vmlinuz) or PCR 11 (which contains a hash of the initrd) would make it break after every kernel update; this is why systemd invented its "signed PCR" feature for example.

    I see systemd introduced a pcrlock tool in November 2023, but (I think) it is still experimental and I don't fully understand it, nor do I know if it would help. Would it?

    As above, depends on the PCR bindings. Pcrlock is supposed to predict future PCR values and do the equivalent of re-sealing the LUKS keyslot against them (but with more indirection), so e.g. if you were using PCR 4+11 for exact kernel hashes, it would need to be run after each upgrade to re-seal against the new kernel.

    (Since the PCRs are hashes of an event log, it's possible to read and "replay" the same log in memory, feeding each event to SHA256() the same way a TPM would – but upon encountering e.g. the "vmlinuz.efi hash" entry, substitute its value with the hash of the new kernel.)

    I've never used systemd-pcrlock (though I've written my own tool that does a similar thing for PCR 4), but it seems like it would help if you did the job of integrating it to your system upgrade process; as with many systemd-related things recently, it's probably slightly over-engineered and very much aimed at distributions making fully-sealed packages, rather than end-users.

    • 3

relate perguntas