12

If the boot partition is encrypted (and the passphrase to unlock the device must be entered in GRUB before the boot sequence starts) is the system considerable safe from an Evil Maid Attack?

TheMoltenJack
  • 121
  • 1
  • 3
  • Depends what the evil maid is after. If they just want the password, replacing the hard drive with a false device which displays the same GRUB prompt and sends whatever is entered to an attacker controlled receiver... You'd discover it easily, but the data would still be accessible... – Matthew Jul 26 '17 at 14:01
  • Well, I wasn't thinking of such a case. Let's suppose that the drive is locked in place and can't be replaced. – TheMoltenJack Jul 26 '17 at 14:05
  • 1
    AFAIK if you encrypt your /boot partition you won't be able to boot your system. That (/boot) is the only partition that should be unencrypted if you want your system to be able to boot. – YoMismo Jul 26 '17 at 14:40
  • 5
    GRUB supports the handling of encrypted boot partition [link](http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/) – TheMoltenJack Jul 26 '17 at 17:02

2 Answers2

13

"Evil maid attack" is a catch-all term for any kind of physical manipulation to a device in the absence of the user.

Encrypting the hard drive would protect you against two of such attacks:

  • Physically cloning the hard drive
  • Starting the device and taking a look at the data on the device

It will not protect you from an attacker installing any other form of surveillance devices, like physical network sniffers, physical keyloggers etc.

And then there is also this form of an evil maid attack:

  1. Attacker starts the device from a boot medium they brought.
  2. Attacker installs a new bootloader which shows a decryption password prompt just like the default one.
  3. Attacker shuts the device down and leaves.
  4. When you enter your password, the bootloader asks for your password, which you will enter because it looks just like it always does. It will then decrypt the hard drive and boot the operating system normally, just like usual. But while it does that, it installs a malware payload on the now unencrypted hard drive and/or sends the password it just sniffed to the attacker.

This attack will work as long as you use a pure software solution, because it will always require an unencrypted bootloader on your hard drive in order to decrypt it. The only solution would be if the hard drive encryption could be implemented on the UEFI level. But I haven't heard of anything like that yet.

Always remember the 3rd Immutable Law of Security:

If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.

Philipp
  • 48,867
  • 8
  • 127
  • 157
  • Technically, they could still physically clone the hard drive, but would need to obtain a password for it to view the data on it. – Matthew Jul 26 '17 at 14:34
  • 1
    I wasn't considering hardware manipulation, the kind of attack I'm interested in is the one with the malicious bootloader. Is there a solution to that attack beside hardware encryption? And and a UEFI system doesn't perform some kind of integrity check when loading the bootloader? – TheMoltenJack Jul 26 '17 at 15:01
  • 1
    Protection against a malicious bootloader on your main drive more or less has to be via secure boot. An alternative though might be to keep your bootloader on a read-only usb device. – mc0e Feb 27 '20 at 23:29
  • @Philipp 2 things: (I am not that well versed tho, so I might be wrong) "This attack will work as long as you use a pure software solution, because it will always require an unencrypted bootloader on your hard drive in order to decrypt it" -> do you mean by this that for instance GRUB on `/boot/efi` (only `/boot/efi` is unencrypted, all other partitions and files including everything else on `/boot` is encrypted) can be replaced, thus an encrypted `/boot` partition will not protect against it? – Balázs Börcsök Apr 08 '22 at 10:27
  • And the other thing: "The only solution would be if the hard drive encryption could be implemented on the UEFI level. But I haven't heard of anything like that yet." -> Isn't UEFI secure boot just that? A solution for instance: https://github.com/kmille/cryptboot – Balázs Börcsök Apr 08 '22 at 10:31
4

Even if you make the system unbootable for any other boot image without making EFI changes, you are vulnerable to things such as hardware key loggers. An evil maid could simply unplug your keyboard, put a hardware key logger on and plug it back in. Next time you unsuspectingly log in, your credentials are captured.

Encryption, by itself, is not complete protection against physical access.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
  • But beside the physical threats, in what ways can EFI mitigate the attacks directed against bootloaders? – TheMoltenJack Jul 27 '17 at 01:16
  • With trusted boot, you can set it up to not allow boot if the signature of the boot-loader has changed without going through EFI (assuming your particular EFI supports it anyway). This way someone would need your EFI password to change the bootloader. – AJ Henderson Jul 27 '17 at 03:15
  • So an EFI firmware password protected can protect effectively from this kind of attack? And if I have a password protected BIOS, how can an attacker change the disk setting if the BIOS doesn't allow him to change the boot order? (without taking the disk off I mean) – TheMoltenJack Jul 28 '17 at 00:36
  • 1
    As well as locking the BIOS setup access (EFI really), You need the TPM device to hold the signature for your bootloader. You may need to maintain that over time, unless for example it's based on the bootloader being signed by microsoft. – mc0e Feb 27 '20 at 23:34
  • And we did not even mention things like Intel ME... The scary thing is that we have no idea exactly how it works and in theory, if Intel (or any other government agency working with them) wanted to, they could have a total, hardware level toolkit to every Intel based computer out there. The only way to not fall into this is to use ARM based or very old computers. – Balázs Börcsök Apr 08 '22 at 10:36
  • @BalázsBörcsök or permanently disable IME which is an option. You can be paranoid that disabling that doesn't work, but for that matter you are assuming that an ARM chip is actually implemented by the manufacturer according to the standard. You don't have a good way to verify any silicon doesn't have a hidden feature unless you crack it open, image it and pull out the opcode that is loaded on it. At a certain point you have to trust the manufacturer on a practical level unless you have a huge amount of resources to dump in to it. – AJ Henderson Apr 12 '22 at 16:51
  • @AJHenderson of course, what you are saying is correct regarding trust. Even standards like SSL is based in trust. Only trustless modells are to be really trusted. – Balázs Börcsök Apr 13 '22 at 17:24