AEM and BadUSB

[Ekleog]

Preamble

I seem to remember having read somewhere that, even for people who do have a TPM, AEM was not necessarily a good idea, because it meant assigning a USB controller to dom0, thus opening way to BadUSB attacks at early boot, that could be used to infect the firmware of some devices that is not checked by the TPM, or of previous BadUSB attacks on the UsbVM that were persisted in the USB controller's firmware and could attack dom0 during early boot.

If this preamble is wrong, then I guess there's no use in reading the following, as it's ideas of solutions for handling this better and get the benefits of both AEM and UsbVM's.

Idea

I just think that it might be a good idea to add a UsbVM to the unencrypted /boot, have some element in the measured boot chain provide its image's hash to the TPM, and have it handle the USB token for AEM (through some Qubes RPC).
Once the disk is unencrypted, the UsbVM can be shutdown and the USB controller transferred to the now-running UsbVM.

This way, there would be the best of both current worlds: the USB connector is never linked to dom0 (as in the current no-AEM scenario), and the boot chain is completely measured (as in the current AEM scenario)

Attacks

I think there are still some attack vectors, like this one: first, compromise UsbVM (via BadUSB) when the machine is running. Use this compromised UsbVM to compromise the USB controller's firmware. Then, on next boot, the compromised USB controller's firmware could recover the AEM secret stored on the USB device.

That said, as far as I can tell, such attacks are already possible when using AEM, and are not even needed when not using AEM, so…

Future works

If this can be and is done, there no longer is any reason for not enabling AEM (that I know of?).

Thus, it means the installer could just detect the presence of a TPM and, when available, put forward AEM availability so that it becomes common Qubes usage.

What do you think about this?

[andrewdavidwong]

I seem to remember having read somewhere that, even for people who do have a TPM, AEM was not necessarily a good idea, because it meant assigning a USB controller to dom0, thus opening way to BadUSB attacks at early boot, that could be used to infect the firmware of some devices that is not checked by the TPM, or of previous BadUSB attacks on the UsbVM that were persisted in the USB controller's firmware and could attack dom0 during early boot.

You might be thinking of this:
https://www.qubes-os.org/doc/anti-evil-maid/#security-considerations

This is related to #1980.

[andrewdavidwong]

I seem to remember having read somewhere that, even for people who do have a TPM, AEM was not necessarily a good idea, because it meant assigning a USB controller to dom0, thus opening way to BadUSB attacks at early boot, that could be used to infect the firmware of some devices that is not checked by the TPM, or of previous BadUSB attacks on the UsbVM that were persisted in the USB controller's firmware and could attack dom0 during early boot.

You might be thinking of this:
https://www.qubes-os.org/doc/anti-evil-maid/#security-considerations

This is related to #1980.

[Ekleog]

Thanks for the link! So I think my suggestion (if I didn't make a mistake in my reasoning) might be a security improvement for AEM on Qubes, enough to enable everyone owning a TPM-containing machine to just turn it on without thinking any longer, as there wouldn't be any downside any longer :)

[Ekleog]

Thanks for the link! So I think my suggestion (if I didn't make a mistake in my reasoning) might be a security improvement for AEM on Qubes, enough to enable everyone owning a TPM-containing machine to just turn it on without thinking any longer, as there wouldn't be any downside any longer :)

[marmarek]

Technically, starting UsbVM from inside initramfs could be implemented, but it's a huge task. To bring up a VM, you need much more than just hypervisor. At least a toolstack (xl, if not the whole libvirt), xenstored and xenconsoled services - which cannot be restarted once started (so need to transition them from initramfs to actual dom0 later), and of course actual VM image itself (kernel, initramfs, hopefully not the whole root fs). This alone would make dom0 initramfs few hundreds MBs.

There are also problems with passing PCI devices around. To do that properly, device needs to support FLR (Function Level Reset), or be on separate bus. (Almost?) none of Intel USB controllers do that.

There is much simpler solution to that: don't use USB for AEM. If you're lucky enough to have a BIOS capable of booting from SD card, that could be a better choice, as suggested by @rustybird. Apparently most Lenovo laptops can't :( But even then, I think something could be done to workaround that problem. For example have minimal bootloader on your hard drive that would hand of execution to bootloader on SD card. And AEM process (including initializing Intel TXT) would start from there.

[marmarek]

Technically, starting UsbVM from inside initramfs could be implemented, but it's a huge task. To bring up a VM, you need much more than just hypervisor. At least a toolstack (xl, if not the whole libvirt), xenstored and xenconsoled services - which cannot be restarted once started (so need to transition them from initramfs to actual dom0 later), and of course actual VM image itself (kernel, initramfs, hopefully not the whole root fs). This alone would make dom0 initramfs few hundreds MBs.

There are also problems with passing PCI devices around. To do that properly, device needs to support FLR (Function Level Reset), or be on separate bus. (Almost?) none of Intel USB controllers do that.

There is much simpler solution to that: don't use USB for AEM. If you're lucky enough to have a BIOS capable of booting from SD card, that could be a better choice, as suggested by @rustybird. Apparently most Lenovo laptops can't :( But even then, I think something could be done to workaround that problem. For example have minimal bootloader on your hard drive that would hand of execution to bootloader on SD card. And AEM process (including initializing Intel TXT) would start from there.

[Ekleog]

Oh. Coming from the qemu/KVM world spawning a VM sounded like a simple action (just have a kernel and an initramfs with the AEM commands inside ready and it's a single command away from running), but I guess it's harder with Xen (or with more stringent security standards than I had when toying around with qemu/KVM), then…

Another solution, if wanting to still use USB, could be to not do full-disk encryption, but full-disk measurement and partial-disk encryption. That is do not encrypt where the toolchain is stored and leave one separate storage for the UsbVM. This could be enabled by the new things from R4 (IIRC): a separate storage location for the UsbVM, and boot the UsbVM as a DispVM so that no information is leaked by leaving the UsbVM template unencrypted.

(actually, just from an optimization point of view, it'd be possible to encrypt them all with an AE algorithm and a stored-on-disk key, and to just measure the key, but that's not relevant to the security discussion)

That said it'd be a pretty big departure from the convenient “just encrypt everything” stance, and I'm not sure it would really make sense. But it would allow for “safe” usage of USB devices.

This being said, the SD card idea sounds great! Just to be sure I understood it correctly, the boot process would then be:

1. The non-reflashable BIOS measures the reflashable BIOS and jumps on it
2. The reflashable BIOS measures the on-disk bootloader and jumps on it
3. The on-disk bootloader loads from the SD card and jumps on it (no measurement at this step?)
4. The SD-card-bootloader measures Xen, dom0 etc. from the card and jumps to there

I'm a bit unsure about step 3, wouldn't it be possible to just extend the TPM with the SD-card-bootloader hash at this point? This sounds a bit better than running sinit at the SD card bootloader time to me, though I don't have a threat model in mind, it'd mean the whole boot chain would be measured and Intel TXT wouldn't by design be required.

[Ekleog]

Oh. Coming from the qemu/KVM world spawning a VM sounded like a simple action (just have a kernel and an initramfs with the AEM commands inside ready and it's a single command away from running), but I guess it's harder with Xen (or with more stringent security standards than I had when toying around with qemu/KVM), then…

Another solution, if wanting to still use USB, could be to not do full-disk encryption, but full-disk measurement and partial-disk encryption. That is do not encrypt where the toolchain is stored and leave one separate storage for the UsbVM. This could be enabled by the new things from R4 (IIRC): a separate storage location for the UsbVM, and boot the UsbVM as a DispVM so that no information is leaked by leaving the UsbVM template unencrypted.

(actually, just from an optimization point of view, it'd be possible to encrypt them all with an AE algorithm and a stored-on-disk key, and to just measure the key, but that's not relevant to the security discussion)

That said it'd be a pretty big departure from the convenient “just encrypt everything” stance, and I'm not sure it would really make sense. But it would allow for “safe” usage of USB devices.

This being said, the SD card idea sounds great! Just to be sure I understood it correctly, the boot process would then be:

1. The non-reflashable BIOS measures the reflashable BIOS and jumps on it
2. The reflashable BIOS measures the on-disk bootloader and jumps on it
3. The on-disk bootloader loads from the SD card and jumps on it (no measurement at this step?)
4. The SD-card-bootloader measures Xen, dom0 etc. from the card and jumps to there

I'm a bit unsure about step 3, wouldn't it be possible to just extend the TPM with the SD-card-bootloader hash at this point? This sounds a bit better than running sinit at the SD card bootloader time to me, though I don't have a threat model in mind, it'd mean the whole boot chain would be measured and Intel TXT wouldn't by design be required.