The future of Anti Evil Maid, if any

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

There's a couple of Anti Evil Maid improvements[0] that might hit
current-testing soon. The most interesting of these:

1. Automated resealing

Basically, you save your text secret to
/var/lib/anti-evil-maid/aem/secret.txt and/or your graphical secret to
/var/lib/anti-evil-maid/aem/secret.png. Then the init scripts will
take care of resealing if necessary, using the recommended PCRs as
configured in /etc/anti-evil-maid.conf[1].

"aem" above actually refers to your device label, so you can manage
multiple devices: See the new anti-evil-maid-install usage message[2].

2. Prevention of another attack

External AEM devices (not within physical reach of an attacker) have the
advantage that we don't need to mount an untrusted filesystem containing
the sealed secrets in dom0. But the unseal script didn't actually check
that only one fs with an AEM label was present: Similarly to QSB #21[3],
an attacker could create their own malicious fs (e.g. on the main
storage drive), use a hypothetical exploit against some Linux fs driver
to gain code execution, mount the real AEM fs, and finally continue
unsealing just fine. This has been fixed[4].

3. Compatibility with portable installations

Your TPM's identity (its public endorsement key) is queried and the
trousers data files and sealed secrets are bound to it.

4. No more $GRUB_CMDLINE_AEM_FLAGS needed

rd.antievilmaid.asksrkpass, rd.antievilmaid.png_secret, and
rd.antievilmaid.dontforcestickremoval are all gone, detected
automatically.


In other news: Everything's horrible, SMM rootkits are on Github now[5].
But it might take a few months for these to trickle down to the lowest
of adversaries, maybe? In this interregnum where AEM can't really do
a whole lot anymore, but nothing better is available yet, why not
collect some best practices against casual physical attacks:

- - It's getting pretty damn realistic for an attacker able to run
privileged code, e.g. by booting from a custom medium, to backdoor your
BIOS without tripping Intel TXT, so you should probably set a per-boot
BIOS password (not only a supervisor BIOS password). And never boot an
OS trusted less than Qubes...

- - microSD cards make nice AEM devices (if you're lucky enough to have
a system which can boot from them) because they're tiny and compatible
with rd.qubes.hide_all_usb. Or, even better: Always take your whole
SSD drive with you, to also prevent attacks against dom0 partition
table parsers.

- - <your idea here>


Rusty


[0]
https://github.com/QubesOS/qubes-antievilmaid/pull/9

[1]
https://github.com/rustybird/qubes-antievilmaid/blob/ponies/anti-evil-maid/etc/anti-evil-maid.conf

[2]
https://github.com/rustybird/qubes-antievilmaid/blob/ponies/anti-evil-maid/sbin/anti-evil-maid-install#L12-L44

[3]
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-021-2015.txt

[4]
https://github.com/rustybird/qubes-antievilmaid/blob/ponies/anti-evil-maid/90anti-evil-maid/anti-evil-maid-unseal#L27-L35

[5]
https://github.com/Cr4sh/SmmBackdoor
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJV4Zm4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfGaAP/j0xj7z2NLXHpvU5L3hncmaM
P3q3ggx/XgMq/bscgXqusStFd1zMhKGfdpxKzOynpJh76ZDovGqoms/DxO7msGmP
RUw8nGU8reAyBTjKVSjADxUDUnk0KkbmLhImCWtM4bQmWWMKBiRqkv0I9X/BG2Ud
mFFIRtJDY1g8kZpqESGrw/K0zs0NF0++WRO+L+OIQw2CQKGdlO/r/0EkBzSOdHI3
SCl3gbAhjzN8s2gMiQgyEbYKNvqyGtwDfH5sHQU0pLJSyc7mMHOPhvh8o9jlhfIE
6/i3rXY90gVVy21A6lPTNRcS9hlJ4JLYCAoRZej7dsLmifZlHRs8ud7Dov+71pz7
CBZ3TWsxK7kx4TDnj05uby4WxVIvjdZnltsrIL+xScGkXk7ZeTYB7qsJ7M87Gra/
cpxj+LGTkge28b2UaG9+1Mz3dQFgKdwL7mfZBcufJL4VxBOdJqqZSzOrKCEdHoyI
SpLbcT8Feq1ITPltNtbvSgUEIBkr56Ej23gVJUGW/lm/STA6Ft+GeXsCEmapEb40
GdQGRzy7VH98xL4pkoSnhE/vVVsuVXfymMHp6wg0DaeKYWB9GOUNg1jNJ9QtkPU6
3bYSnedBLmvlZkmvAVTn/1/ea966JN8FtxCMa7hEqIBu+CpUBknTJ+DsAZdMB0oy
syrdPUcOc2bEZ8HMvwrJ
=3PYG
-----END PGP SIGNATURE-----

[7v5w7go9ub0o]

DANG!

Thank you for this!!

Sorry; no ideas from me; but I enthusiastically await the dialogue!! :-)

[cprise]

On 08/29/2015 07:38 AM, Rusty Bird wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi,
>
> There's a couple of Anti Evil Maid improvements[0] that might hit
> current-testing soon. The most interesting of these:
>
> 1. Automated resealing
>
> Basically, you save your text secret to
> /var/lib/anti-evil-maid/aem/secret.txt and/or your graphical secret to
> /var/lib/anti-evil-maid/aem/secret.png. Then the init scripts will
> take care of resealing if necessary, using the recommended PCRs as
> configured in /etc/anti-evil-maid.conf[1].
>
> "aem" above actually refers to your device label, so you can manage
> multiple devices: See the new anti-evil-maid-install usage message[2].
>

Very nice! And all I asked for was an alert from the update process
telling me I needed to re-seal.

> 2. Prevention of another attack
>
> External AEM devices (not within physical reach of an attacker) have the
> advantage that we don't need to mount an untrusted filesystem containing
> the sealed secrets in dom0. But the unseal script didn't actually check
> that only one fs with an AEM label was present: Similarly to QSB #21[3],
> an attacker could create their own malicious fs (e.g. on the main
> storage drive), use a hypothetical exploit against some Linux fs driver
> to gain code execution, mount the real AEM fs, and finally continue
> unsealing just fine. This has been fixed[4].
>

Also welcome. Tighter = better, esp. if there is no compromise in
function or efficiency.

> 3. Compatibility with portable installations
>
> Your TPM's identity (its public endorsement key) is queried and the
> trousers data files and sealed secrets are bound to it.
>
> 4. No more $GRUB_CMDLINE_AEM_FLAGS needed
>
> rd.antievilmaid.asksrkpass, rd.antievilmaid.png_secret, and
> rd.antievilmaid.dontforcestickremoval are all gone, detected
> automatically.
>

One thing I would like is automatic handling of extra tboot flags (see
step 4-f in the AEM Readme for the manual invocation). The auto-re-seal
won't work for me unless this is also automated. Adding the assignment
to /etc/defalt/grub has no effect.

>
> In other news: Everything's horrible, SMM rootkits are on Github now[5].
> But it might take a few months for these to trickle down to the lowest
> of adversaries, maybe? In this interregnum where AEM can't really do
> a whole lot anymore, but nothing better is available yet, why not
> collect some best practices against casual physical attacks:
>
> - - It's getting pretty damn realistic for an attacker able to run
> privileged code, e.g. by booting from a custom medium, to backdoor your
> BIOS without tripping Intel TXT, so you should probably set a per-boot
> BIOS password (not only a supervisor BIOS password). And never boot an
> OS trusted less than Qubes...

Thanks for the advice. Is there a way to have the AEM secret unlock the
LUKS volume?? That way, people using the SRK passphrase wouldn't need to
enter /THREE/ passcodes in total to boot their machine.

>
> - - microSD cards make nice AEM devices (if you're lucky enough to have
> a system which can boot from them) because they're tiny and compatible
> with rd.qubes.hide_all_usb. Or, even better: Always take your whole
> SSD drive with you, to also prevent attacks against dom0 partition
> table parsers.

Don't SD cards have corruptible firmware also? And some of us have SD
slots that are really Expresscard slots, and we would rather keep that
disabled in the BIOS.

[jonbrown...@gmail.com]

Thank you for enhancing AEM you are doing the lords work. Anything we can do to harden physical security is a big plus.

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi cprise,

> One thing I would like is automatic handling of extra tboot flags
> (see step 4-f in the AEM Readme for the manual invocation). The
> auto-re-seal won't work for me unless this is also automated.
> Adding the assignment to /etc/defalt/grub has no effect.

Try grepping for GRUB_CMDLINE_TBOOT in /etc/grub.d/19_linux_xen_tboot,
maybe you have a stale file?

> Is there a way to have the AEM secret unlock the LUKS volume??

Not yet, but that's definitely a consideration in the new design. It
should be easy now to add a secret.luks in addition to secret.txt and
secret.png.

> That way, people using the SRK passphrase wouldn't need to enter
> /THREE/ passcodes in total to boot their machine.

Four if you count the login password...

>> - - microSD cards make nice AEM devices (if you're lucky enough
>> to have a system which can boot from them) because they're tiny
>> and compatible with rd.qubes.hide_all_usb. Or, even better:
>> Always take your whole SSD drive with you, to also prevent
>> attacks against dom0 partition table parsers.
>
> Don't SD cards have corruptible firmware also?

I'm not quite as worried though about an SD card infecting an SD card
controller. Their protocol should be simpler than USB at least?

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

iQJ8BAEBCgBmBQJV4qsiXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf+XcQAJnXvrlw+nOBxUkFnf3djU3e
zi9F4mZdK6kvJRi7iNFWfooyAPHt6/AjFfrM8eG/v4DOJODCm1DMfDrD81psRf7l
vOe1YKsVbE20Sy9OxCF0P6SbHPpynpHBIw16L9kWgRn7ZedFjopZWIDqtEZ0Wv4h
ZZbVtQhR4xq3fNm71ztKDnwmKK2qdNTlz4APyVW32Cvl1lV3U4nmr3kGyA8+PUMj
jVfmT1sBS99LQq4Us+iTsXa+osOHUzrXwXMGR/ENw8YqSP8qe5fhUkQNpSB0ZKUy
o4gDAwVzJpbZZLWiVu0Ig3P6TZf8tA+XDkrEux324dpUxszjb0ewEt876K8imY9q
AwjRG/j2oZBF4oo1OZ8q1kkmzdANILHz56E0aiFvYlyma1u5nMxRq/qzAJQi/OfP
dMWgtsmA7zUHy3CqaOzcJRh1nngHQLkRCVY9ps0b3IyXBbCcj/4+rO6Shpivt8Ad
arfYL9eleztjlmQBAHUAaKE69i2XjxkIZpFVyn7lw7pyz4IVAJ+MT9Mi86xc9mfJ
ZIibbIn6UzwmZqaofuJN+8O7yMOuCBiuM2E5ukq9yKsBcG7ED8kWDek0zlA01rgd
uOlXT5ZIei6ivhwnjymTz5WYn3HGEHkPMI/pG78DINuB+ZXxIWBD5xncZBwfCQPC
xsot7hDanhltnNsfY4UO
=mRrN
-----END PGP SIGNATURE-----

[cprise]

On 08/30/2015 03:05 AM, Rusty Bird wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi cprise,
>
>> One thing I would like is automatic handling of extra tboot flags
>> (see step 4-f in the AEM Readme for the manual invocation). The
>> auto-re-seal won't work for me unless this is also automated.
>> Adding the assignment to /etc/defalt/grub has no effect.
>
> Try grepping for GRUB_CMDLINE_TBOOT in /etc/grub.d/19_linux_xen_tboot,
> maybe you have a stale file?

Already did that; its there once as a variable on the only line that
sets up 'multiboot'.

To clarify - Manually setting the var before 'antievilmaid_install'
works. I'm not sure about grub2-mkconfig (without aem install). But
adding the var to /etc/default/grub just doesn't have any effect.

>
>> Is there a way to have the AEM secret unlock the LUKS volume??
>
> Not yet, but that's definitely a consideration in the new design. It
> should be easy now to add a secret.luks in addition to secret.txt and
> secret.png.

Hopefully it will be possible to encrypt a disk passphrase already known
by the user, instead of using a randomly-generated one. This allows
manual recovery of the root volume from the user's memory without having
to rely on accessing a physical backup of the LUKS key.

Re: SD, I thought that was one of the more proprietary storage standards?

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

cprise:

>>> One thing I would like is automatic handling of extra tboot
>>> flags (see step 4-f in the AEM Readme for the manual
>>> invocation). The auto-re-seal won't work for me unless this is
>>> also automated. Adding the assignment to /etc/defalt/grub has
>>> no effect.
>>
>> Try grepping for GRUB_CMDLINE_TBOOT in
>> /etc/grub.d/19_linux_xen_tboot, maybe you have a stale file?
>
> Already did that; its there once as a variable on the only line
> that sets up 'multiboot'.
>
> To clarify - Manually setting the var before
> 'antievilmaid_install' works. I'm not sure about grub2-mkconfig
> (without aem install). But adding the var to /etc/default/grub just
> doesn't have any effect.

Maybe the "export " is missing before GRUB_CMDLINE_TBOOT in
/etc/default/grub?

If not, you could try "sh -x grub2-mkconfig 2>&1" (without arguments)
and search for "/etc/default/grub" in the output to see what's going on.

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

iQJ8BAEBCgBmBQJV4tWDXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfiJwP/3VPk01uHvYN4wEGfLAYstdu
Jh9XKRE6opg2ozSQsrnoEp0NbHVQLJ3G4FfX6G5iVi+27Ac7gvaiBGX3dTXoA81C
q1F0pxWrFa2Kcf2RdRrkygIKExVcUtNMbIiXHMSoQde8jRMgpTCvTnwYdLp5OXPR
3x4kVBO5RxXaQjYYQ5FeDFCrnvcKfpQnfmWJabiHJoYloRjlvRFOUA20yqqEjfV8
uOfZnEuO+cRXJtGKvYhj3cC3QRZ75+FgrsiefL9rRAJIGQ421GzIsebHg8fUgl8b
bfFaUWLF+G+erPr86Reoxvl37onuPt42phTKli2Ei/j4ABYyUQEGq7haG1Hdt46q
n6B+ClX+63peqyM3Bo54nqbAy9hNzv1pBgVI9mkcVGnu5ryotM79wpLOVXyIM6k9
DLQpyNYqYdDvGDPumDM/2Xeun5kQSBghL0P8wlfFtyJqFFcHYX01gugQ2BQ/b+MD
MeNLTsWCFN4RZqDvsuURNnf3u9Ww9n6GXffxKPAL9VMEiGZ/6As67ghari+Z5r4F
fVuCTtcYPQawbzIzbLLy6stIKwtg1eiMDRsDLZ2oHw0fLykj/MQsiuCHn6yL27BB
9ZZXyIbSEKg+q6APkfm947b7PuV9rnm0U3XYBsR4sdCQg/gvtMZ03l63r9z7rjfq
vX90aJsr6dUYGkxTGvwG
=kxMh
-----END PGP SIGNATURE-----

[cprise]

On 08/30/2015 06:05 AM, Rusty Bird wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> cprise:
>>>> One thing I would like is automatic handling of extra tboot
>>>> flags (see step 4-f in the AEM Readme for the manual
>>>> invocation). The auto-re-seal won't work for me unless this is
>>>> also automated. Adding the assignment to /etc/defalt/grub has
>>>> no effect.
>>>
>>> Try grepping for GRUB_CMDLINE_TBOOT in
>>> /etc/grub.d/19_linux_xen_tboot, maybe you have a stale file?
>>
>> Already did that; its there once as a variable on the only line
>> that sets up 'multiboot'.
>>
>> To clarify - Manually setting the var before
>> 'antievilmaid_install' works. I'm not sure about grub2-mkconfig
>> (without aem install). But adding the var to /etc/default/grub just
>> doesn't have any effect.
>
> Maybe the "export " is missing before GRUB_CMDLINE_TBOOT in
> /etc/default/grub?

Well, it /is/ missing like it is for all the other assignments in that file.

>
> If not, you could try "sh -x grub2-mkconfig 2>&1" (without arguments)
> and search for "/etc/default/grub" in the output to see what's going on.

Yeah, its getting sourced-in to the script fairly early and the tboot
assignment happens along with the others, but that doesn't result in the
parameter getting added to the grub.cfg output.

However, I just added 'export ' to that one line in /etc/default/grub as
you suggested and now it works. :-)


>
> Rusty