AEM - sudo anti-evil-maid-seal sanity test failing on functional TPM

[adrelanos]

Qubes OS version:

R3.2

Affected TemplateVMs:

dom0

---

Steps to reproduce the behavior:

Add SINIT module.

sudo qubes-dom0-update anti-evil-maid
sudo systemctl enable tcsd
sudo systemctl restart tcsd
sudo tpm_takeownership -y
sudo anti-evil-maid-install /dev/sda1
sudo anti-evil-maid-seal

Expected behavior:

No such error.

Actual behavior:

Error.

General notes:

https://github.com/QubesOS/qubes-antievilmaid/blob/8d8a941f5647b0082a20b4245859986d3ca45c12/anti-evil-maid/sbin/anti-evil-maid-seal#L31

if grep -E "^PCR-(${pcrs//$'\n'/|}):( 00| FF){20}" /sys/devices/*/*/pcrs;

Does not work for me.

+ set -e -o pipefail
+ shopt -s expand_aliases
+ systemctl start tcsd
+ alias 'plymouth_message=plymouth message --text'
+ source anti-evil-maid-lib
++ LABEL_PREFIX=aem
++ AEM_DIR=/var/lib/anti-evil-maid
++ TPM_DIR=/var/lib/tpm
++ TPMS_DIR=/var/lib/tpms
++ CACHE_DIR=/run/anti-evil-maid
++ SRK_PASSWORD_CACHE=/run/anti-evil-maid/srk-password
++ SUFFIX_CACHE=/run/anti-evil-maid/suffix
++ command plymouth --ping
++ alias plymouth=:
++ alias plymouth_active=false
++ alias message=log
+ trap 'rm -rf "$CACHE_DIR"' EXIT
+ source /etc/anti-evil-maid.conf
++ SEAL='--pcr 13 --pcr 17 --pcr 18 --pcr 19'
++ tpm_z_srk
+ log 'detecting whether SRK is password protected'
+ echo 'tpm_z_srk: detecting whether SRK is password protected'
tpm_z_srk: detecting whether SRK is password protected
+ tpm_sealdata -z
Tspi_Key_CreateKey failed: 0x00000001 - layer=tpm, code=0001 (1), Authentication failed
+ log 'yes, SRK is password protected; resetting dictionary attack lock...'
+ echo 'tpm_z_srk: yes, SRK is password protected; resetting dictionary attack lock...'
tpm_z_srk: yes, SRK is password protected; resetting dictionary attack lock...
+ tpm_resetdalock -z
+ Z=
++ cat /run/anti-evil-maid/suffix
cat: /run/anti-evil-maid/suffix: No such file or directory
+ LABEL=aem
+ true
+ DEV=/dev/disk/by-label/aem
++ printf %s '--pcr 13 --pcr 17 --pcr 18 --pcr 19'
++ grep -Eo '\b1[3789]\b'
+ pcrs='13
17
18
19'
+ grep -E '^PCR-(13|17|18|19):( 00| FF){20}' /sys/devices/pnp0/00:06/pcrs
PCR-17: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
PCR-18: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
PCR-19: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+ '[' 0 '!=' 1 ']'
+ log 'PCR sanity check failed!'
+ echo 'anti-evil-maid-seal: PCR sanity check failed!'
anti-evil-maid-seal: PCR sanity check failed!
+ log 'See /usr/share/doc/anti-evil-maid/README for details.'
+ echo 'anti-evil-maid-seal: See /usr/share/doc/anti-evil-maid/README for details.'
anti-evil-maid-seal: See /usr/share/doc/anti-evil-maid/README for details.
+ exit 1
+ rm -rf /run/anti-evil-maid

Commented out the exit 1.

Now it's working.

Working meaning, after adding this hack, and another hack #3296 sudo anti-evil-maid-seal showed no more error and I could view my secret at the next reboot. I don't know if this hack was sane or if that hack together with #3296 actually invalidated the protections by AEM.

"sanity test failing on functional TPM" is just my guess. The tpm_sealdata later on in anti-evil-maid-seal asks my password, and if the correct one is entered, does not show any error.

[phagara]

+ grep -E '^PCR-(13|17|18|19):( 00| FF){20}' /sys/devices/pnp0/00:06/pcrs
PCR-17: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
PCR-18: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
PCR-19: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

This means that the bootloader failed to perform a measured boot (FFs are default values for untouched PCRs). Most likely due to incorrect or no SINIT module loaded. By removing the sanity check and sealing your AEM secret against these uninitialized PCR values, you're defeating the whole point of AEM -- the unseal operation will always succeed even if kernel/Xen binaries get modified by an attacker (as long as your config remains broken).

The sanity check was added to prevent this false sense of security in #2569.

[phagara]

+ grep -E '^PCR-(13|17|18|19):( 00| FF){20}' /sys/devices/pnp0/00:06/pcrs
PCR-17: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
PCR-18: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
PCR-19: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

This means that the bootloader failed to perform a measured boot (FFs are default values for untouched PCRs). Most likely due to incorrect or no SINIT module loaded. By removing the sanity check and sealing your AEM secret against these uninitialized PCR values, you're defeating the whole point of AEM -- the unseal operation will always succeed even if kernel/Xen binaries get modified by an attacker (as long as your config remains broken).

The sanity check was added to prevent this false sense of security in #2569.

[rustybird]

To expand on @phagara's reply: It is intentional that the PCR sanity check is tripped if you manually run anti-evil-maid-seal right after setting up AEM on a new system. (The PCRs are empty because the SINIT module is not active until the first reboot.) The intended workflow is to simply reboot after you've run -install and created your secret(s), and let AEM automatically take care of sealing.

It is only necessary to invoke anti-evil-maid-seal manually if you want to force an immediate reseal after changing an existing, previously sealed secret.

[rustybird]

To expand on @phagara's reply: It is intentional that the PCR sanity check is tripped if you manually run anti-evil-maid-seal right after setting up AEM on a new system. (The PCRs are empty because the SINIT module is not active until the first reboot.) The intended workflow is to simply reboot after you've run -install and created your secret(s), and let AEM automatically take care of sealing.

It is only necessary to invoke anti-evil-maid-seal manually if you want to force an immediate reseal after changing an existing, previously sealed secret.

[adrelanos]

Alright, thank you! So it's a TPM issue on my side, not an AEM issue. Therefore, closing as invalid, not a bug.

[adrelanos]

Alright, thank you! So it's a TPM issue on my side, not an AEM issue. Therefore, closing as invalid, not a bug.