Anti Evil Maid not working in subsequent setup attempts

128 views
Skip to first unread message

mic...@schefczyk.net

unread,
Jan 13, 2017, 6:02:01 AM1/13/17
to qubes-users
Dear All,

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.

Rusty Bird

unread,
Jan 14, 2017, 3:04:20 PM1/14/17
to mic...@schefczyk.net, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

mic...@schefczyk.net:
> 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.

The log looks good to me. Have you tried using a .txt file or the
original large .png file again, maybe your new .png is incompatible
somehow?

(You'd have to manually rerun anti-evil-maid-seal, passing the AEM
device suffix as its first argument, e.g.: anti-evil-maid-seal "")

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJYeoQ2XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfmVAP/313P6iTHDQR2c35bvZywl+w
WBGldSGRFwGlRdv0N5ZxEJs/AGCa9enupHbpbEqmRP87in1p9YEJq5+U+UzoAIX0
P616zPGfwKYMoXG0qZc5gvYKQM0y6xJQJQpbuP9u7gNW41u5Zcrj9cX50K9eaIkz
lAe6PbiUlC91fotgI5mBH8YI7EDEkD39+P+adydr2v66r6lLddZRk1bCAg9rHUrc
O+iz/JDEJZVOYw9+gNR5Mv1d9KHXVIbXoukEicqbpp9WDwZ8UdtVym/p0TDUg3d8
MogaZZ+p0Nxdm1uzdsULnAOnkrl3Md67vp2elGbMJLfhh0tpFjyoM6cRmwH6Wa2E
gzELY9oprt+p6IzcbYOCprDviIBVI58O90ZOpXm73gTYwpTROUEUzlHg0NyZd5YJ
+QtyeENdzCg4+OBrnJfn8Q1X9xVfwKEAnfKm48rs/qYFKVLauGPfi60gL/LnM+Pn
NNJujzVIl0YXk12tFsXRb6jafSYPPqL4nvHrC7edMhXlwynYcZ0bD6/3Cd9+kPSN
IfOOarFeXwA7eP5gTEqNukGLMa9ZfBpwCZB7H+ZDMZrgXmlGzU9hGmfa6bMyKBhN
m9eLlMzf7DLmOxhwk/Cwlinpaf+D8h2ESnha5buKAhr9lYZfP1hSRGsFDBDZ51Tn
4VNhYlsh/6aqknqGjWsz
=Ch98
-----END PGP SIGNATURE-----

mic...@schefczyk.net

unread,
Jan 17, 2017, 6:37:49 PM1/17/17
to qubes-users, mic...@schefczyk.net, rust...@openmailbox.org
Dear Rusty,

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

Rusty Bird

unread,
Jan 18, 2017, 7:38:29 AM1/18/17
to mic...@schefczyk.net, qubes-users
mic...@schefczyk.net:
> 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.

Is your TPM password the same as your disk encryption password? That
would defeat the purpose of AEM, and indeed interact weirdly with
cryptsetup: https://github.com/QubesOS/qubes-issues/issues/978

Rusty

mic...@schefczyk.net

unread,
Jan 20, 2017, 3:42:44 PM1/20/17
to qubes-users, mic...@schefczyk.net, rust...@openmailbox.org

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

Reply all
Reply to author
Forward
0 new messages