In my Qubes 3.2 system, I did set up Anti Evil Maid successfully once following:
https://github.com/QubesOS/qubes-antievilmaid/blob/master/anti-evil-maid/README#L51.
I used a picture as a secret which was shown but it was too large, so I tried to delete the setup (first tpm_clear -z, reboot, activate TPM again in BIOS; in subsequent tries also with sudo yum remove anti-evil-maid for a more complete repeated setup). I did copy the picture from another domain and used chmod to set 777 permissions with root ownership.
On subsequent setup attempts, the system would indicate that it was sealing the secret ("Sealed /var/lib/anti-evil-maid/aem/secret.png using
--pcr 13 --pcr 17 --pcr 18 --pcr 19") on the first reboot. However, on the second reboot, the system would no longer be able to show the picture.
At this point, my only temporary fix is to uninstall Anti Evil Maid again. What I would much prefer, however, is to be certain that I am able to repeat the setup whenever required to a point where Anti Evil Maid does work again.
The output of journalctl -u anti-evil-maid-unseal -u anti-evil-maid-seal is enclosed below - two reboots, one during the initial sealing and one where showing the picture fails. I suspect that there might be some issue with the TPM configuration in the subsequent attempts, but that is beyond my understanding, unfortunately.
Can someone please point me to the right direction, please?
Regards,
Michael
-- Reboot --
Jan 13 11:17:47 dom0 systemd[1]: Starting Anti Evil Maid unsealing...
Jan 13 11:17:48 dom0 anti-evil-maid-unseal[505]: anti-evil-maid-unseal: Mounting the aem device...
Jan 13 11:17:48 dom0 anti-evil-maid-unseal[505]: anti-evil-maid-unseal: Initializing TPM...
Jan 13 11:17:48 dom0 anti-evil-maid-unseal[505]: tcsd_changer_identify: identifying TPM
Jan 13 11:17:48 dom0 TCSD[564]: TrouSerS Config file /etc/tcsd.conf not found, using defaults.
Jan 13 11:17:48 dom0 tcsd[564]: TCSD TDDL[564]: TrouSerS ioctl: (25) Inappropriate ioctl for device
Jan 13 11:17:48 dom0 tcsd[564]: TCSD TDDL[564]: TrouSerS Falling back to Read/Write device support.
Jan 13 11:17:48 dom0 TCSD[565]: TrouSerS trousers 0.3.13: TCSD up and running.
Jan 13 11:17:48 dom0 anti-evil-maid-unseal[505]: tpm_id: ignore the first "Tspi_TPM_GetPubEndorsementKey failed"
Jan 13 11:17:48 dom0 anti-evil-maid-unseal[505]: Tspi_TPM_GetPubEndorsementKey failed: 0x00000008 - layer=tpm, code=0008 (8), The TPM target command has been disabled
Jan 13 11:17:48 dom0 anti-evil-maid-unseal[505]: tcsd_changer_identify: TPM identity: 32d24461505c80a82bdc4e31d12d9ae11b91f47cf45aff8cbdcf0634d9015a22
Jan 13 11:17:50 dom0 TCSD[611]: TrouSerS Config file /etc/tcsd.conf not found, using defaults.
Jan 13 11:17:50 dom0 tcsd[611]: TCSD TDDL[611]: TrouSerS ioctl: (25) Inappropriate ioctl for device
Jan 13 11:17:50 dom0 tcsd[611]: TCSD TDDL[611]: TrouSerS Falling back to Read/Write device support.
Jan 13 11:17:51 dom0 TCSD[618]: TrouSerS trousers 0.3.13: TCSD up and running.
Jan 13 11:17:51 dom0 anti-evil-maid-unseal[505]: anti-evil-maid-unseal: Extending PCR 13, value 805c6d64887389fd6e60228bcfea3df8838b4159, device 618a7545-c636-4c96-bc2e-c935468a4c1b...
Jan 13 11:17:51 dom0 anti-evil-maid-unseal[505]: tpm_z_srk: detecting whether SRK is password protected
Jan 13 11:17:51 dom0 anti-evil-maid-unseal[505]: Tspi_Key_CreateKey failed: 0x00000001 - layer=tpm, code=0001 (1), Authentication failed
Jan 13 11:17:51 dom0 anti-evil-maid-unseal[505]: tpm_z_srk: yes, SRK is password protected; resetting dictionary attack lock...
Jan 13 11:17:51 dom0 anti-evil-maid-unseal[505]: anti-evil-maid-unseal: Prompting for SRK password...
Jan 13 11:17:58 dom0 anti-evil-maid-unseal[505]: Enter SRK password: anti-evil-maid-unseal: Correct SRK password
Jan 13 11:17:58 dom0 anti-evil-maid-unseal[505]: anti-evil-maid-unseal: Unsealing the secret...
Jan 13 11:17:59 dom0 anti-evil-maid-unseal[505]: Enter SRK password: Unable to write output file
Jan 13 11:17:59 dom0 anti-evil-maid-unseal[505]: anti-evil-maid-unseal: Unmounting the aem device...
Jan 13 11:17:59 dom0 systemd[1]: Started Anti Evil Maid unsealing.
Jan 13 11:18:01 dom0 systemd[1]: Starting Anti Evil Maid sealing...
Jan 13 11:18:04 dom0 anti-evil-maid-seal[1638]: tpm_z_srk: detecting whether SRK is password protected
Jan 13 11:18:05 dom0 anti-evil-maid-seal[1638]: Tspi_Key_CreateKey failed: 0x00000001 - layer=tpm, code=0001 (1), Authentication failed
Jan 13 11:18:05 dom0 anti-evil-maid-seal[1638]: tpm_z_srk: yes, SRK is password protected; resetting dictionary attack lock...
Jan 13 11:18:07 dom0 anti-evil-maid-seal[1638]: Enter SRK password:
Jan 13 11:18:07 dom0 systemd[1]: Started Anti Evil Maid sealing.
-- Reboot --
Jan 13 11:21:25 dom0 systemd[1]: Starting Anti Evil Maid unsealing...
Jan 13 11:21:26 dom0 anti-evil-maid-unseal[503]: anti-evil-maid-unseal: Mounting the aem device...
Jan 13 11:21:26 dom0 anti-evil-maid-unseal[503]: anti-evil-maid-unseal: Initializing TPM...
Jan 13 11:21:26 dom0 anti-evil-maid-unseal[503]: tcsd_changer_identify: identifying TPM
Jan 13 11:21:26 dom0 TCSD[567]: TrouSerS Config file /etc/tcsd.conf not found, using defaults.
Jan 13 11:21:26 dom0 tcsd[567]: TCSD TDDL[567]: TrouSerS ioctl: (25) Inappropriate ioctl for device
Jan 13 11:21:26 dom0 tcsd[567]: TCSD TDDL[567]: TrouSerS Falling back to Read/Write device support.
Jan 13 11:21:26 dom0 TCSD[568]: TrouSerS trousers 0.3.13: TCSD up and running.
Jan 13 11:21:26 dom0 anti-evil-maid-unseal[503]: tpm_id: ignore the first "Tspi_TPM_GetPubEndorsementKey failed"
Jan 13 11:21:26 dom0 anti-evil-maid-unseal[503]: Tspi_TPM_GetPubEndorsementKey failed: 0x00000008 - layer=tpm, code=0008 (8), The TPM target command has been disabled
Jan 13 11:21:26 dom0 anti-evil-maid-unseal[503]: tcsd_changer_identify: TPM identity: 32d24461505c80a82bdc4e31d12d9ae11b91f47cf45aff8cbdcf0634d9015a22
Jan 13 11:21:28 dom0 TCSD[620]: TrouSerS Config file /etc/tcsd.conf not found, using defaults.
Jan 13 11:21:28 dom0 tcsd[620]: TCSD TDDL[620]: TrouSerS ioctl: (25) Inappropriate ioctl for device
Jan 13 11:21:28 dom0 tcsd[620]: TCSD TDDL[620]: TrouSerS Falling back to Read/Write device support.
Jan 13 11:21:29 dom0 TCSD[621]: TrouSerS trousers 0.3.13: TCSD up and running.
Jan 13 11:21:29 dom0 anti-evil-maid-unseal[503]: anti-evil-maid-unseal: Extending PCR 13, value 805c6d64887389fd6e60228bcfea3df8838b4159, device 618a7545-c636-4c96-bc2e-c935468a4c1b...
Jan 13 11:21:29 dom0 anti-evil-maid-unseal[503]: tpm_z_srk: detecting whether SRK is password protected
Jan 13 11:21:29 dom0 anti-evil-maid-unseal[503]: Tspi_Key_CreateKey failed: 0x00000001 - layer=tpm, code=0001 (1), Authentication failed
Jan 13 11:21:29 dom0 anti-evil-maid-unseal[503]: tpm_z_srk: yes, SRK is password protected; resetting dictionary attack lock...
Jan 13 11:21:29 dom0 anti-evil-maid-unseal[503]: anti-evil-maid-unseal: Prompting for SRK password...
Jan 13 11:22:58 dom0 anti-evil-maid-unseal[503]: Enter SRK password: anti-evil-maid-unseal: Correct SRK password
Jan 13 11:22:58 dom0 anti-evil-maid-unseal[503]: anti-evil-maid-unseal: Unsealing the secret...
Jan 13 11:23:00 dom0 anti-evil-maid-unseal[503]: Enter SRK password: anti-evil-maid-unseal: Unmounting the aem device...
Jan 13 11:23:00 dom0 systemd[1]: Started Anti Evil Maid unsealing.
Jan 13 11:23:02 dom0 systemd[1]: Started Anti Evil Maid sealing.
Thank you very much! I did try the text secret, however without success.
What I did notice is, that there might be interference with cryptsetup. As long as I have AEM on, the system does ask for the TPM password, does not show the secret and does NOT ask for the disk password before starting up anyway.
As soon as I do yum remove anti-evil-maid, things do seem to be correct again, i. e., one can and one must type the correct disk password. I am not certain how this can depend on having other software installed.
Maybe, I did install AEM in the wrong directory, but /dev/sda1 does seem to be the boot device.
Would you please share ideas on relaxing this problem?
Regards,
Michael
Dear Rusty,
Yes - that was the problem. For such basic but important steps, I usually install things once, tear them down and install again to gain confidence. In this case, I did use real passwords for the first attempt but trivial and equal ones for the next attempts. Everything did work after going back to strong and different passwords.
Certainly, one would never use the same password for both purposes in production. Nevertheless, this pattern is not good: The password seems to be stored and tried in other fields as well. That should not happen in security software, I would suspect.
Thank you very much!
Regards,
Michael