Disk Encryption Tests On Fedora 21

[curaga]

Booting from USB does not actually increase your security. Why? Because the evil maid can simply turn off USB boot and run her malicious code from the local disk, then afterwards invoke whatever you have on the USB key.

How will she install anything to the fully encrypted disk without it being noticed? Or change the boot order of Coreboot that can only be changed by reflashing the bios chip?

Obviously Intel, Thunderbolt, Firewire are off limits for a secure computer.

/why yes, I enjoyed the how to own book series.

[chithanh]

If the only "Evil Maid" attack that was a fast-acting danger was a standard one for common distros, defeating it would be as simple as having your own disk decryption script

But the article recommends turning on the Fedora full-disk encryption which uses a bog-standard (dracut?) initramfs. So an attacker knows what to expect and where to insert tee(1) calls to capture the passphrase.
The standard "checkbox" full-disk encryption does not protect against any "Evil Maid" worth her money.

How will she install anything to the fully encrypted disk without it being noticed?

If the disk is partitioned, then you usually have some unpartitioned space at the beginning and at the end (first and last megabyte) which is ample for that purpose.
If the disk is not partitioned but contains only one big LUKS volume, it gets more difficult: the code would have to replace the LUKS header with its own boot code and overwrite some of the sectors near the end of the disk with the payload (writing there will usually not be noticed unless the disk is almost full). Once the payload becomes active, the LUKS header needs to be restored before invoking whatever the user has on his USB drive.

Or change the boot order of Coreboot that can only be changed by reflashing the bios chip?

The only computers in widespread use that use Coreboot are Chromebooks. Those employ a security scheme which is not full disk encryption and quite different from Fedora's, but it is indeed somewhat hardened against "Evil Maid" attacks.

[curaga]

If the disk is not partitioned but contains only one big LUKS volume, it gets more difficult: the code would have to replace the LUKS header with its own boot code and overwrite some of the sectors near the end of the disk with the payload (writing there will usually not be noticed unless the disk is almost full).

Are you saying LUKS blindly executes code from its own header on disk? I have a hard time believing its designers are that stupid. Remember, the boot code is from the USB, since the entire disk is encrypted in this scenario.

[chithanh]

No. What I am saying is that:

1. Evil Maid turns off USB boot.
2. Evil Maid backs up LUKS header to some place near the end of the disk and replaces it with her own boot code.
3. Evil Maid overwrites parts of the LUKS volume with malicious dracut subverting payload
4. On next boot, the payload is executed, subverts the connected USB drive, restores the LUKS header, turns on USB boot again and kexec()s the kernel on USB.

[curaga]

That would work yes, if she could change the boot order, but it would be noticeable. The boot messages would change, there would be a delay, and there would be HD access when none is expected.

[chithanh]

On an EFI system, temporarily changing the boot order is as easy as running

# efibootmgr --bootnext NNNN

On BIOS systems this can be more tricky, a backup copy of the NVRAM would be necessary (especially if the BIOS setup is password protected, so the password needs to be reset before changing boot order and restored later).

Boot messages won't change much, USB boot is still enabled just at lower priority. Therefore, USB devices will be enumerated during boot still.
There will be a few extra early hard disk accesses during boot, but will an unsuspecting victim notice? LUKS will read from the disk anyway before displaying the passphrase prompt.

[Luke]

A counter to this attack

No. What I am saying is that:

1. Evil Maid turns off USB boot.
2. Evil Maid backs up LUKS header to some place near the end of the disk and replaces it with her own boot code.
3. Evil Maid overwrites parts of the LUKS volume with malicious dracut subverting payload
4. On next boot, the payload is executed, subverts the connected USB drive, restores the LUKS header, turns on USB boot again and kexec()s the kernel on USB.

This can be countered with a custom dracut (or any) initramfs with a non-standard program calling cryptsetup and non-standard prompts which are published nowhere. A published program for this could even ask the user to enter their desired prompts before the initramfs is made, hell they could even encourage users to rotate prompts. Any use of a stock replacement initramfs becomes obvious, any custom tampering becomes time consuming and well beyond the skills of someone hired to just plug in a flash drive and mash the power button. This holds true no matter what the attack. In this case, the main advantage of having /boot on USB is that a skilled opponent is denied a copy of the initramfs and cannot figure out the correct prompt. If he has a local copy he can write down the prompt or just edit the software directly after opening up the initramfs for a little on the spot reverse engineering. Again, that's not something a hired "evil maid" could do, it takes an "evil cook," at which point flashing a custom BIOS may be easier as well as being totally OS-agnostic and getting around this custom prompting trick.

[chithanh]

Yes, there are many ways how to make the life of the Evil Maid harder. I never disputed that.

Custom stuff makes things more obscure and may require a complex bootkit or several rounds of access to the system.
You can enable the ATA password. Now the attacker would need to attack the drive firmware and/or perform hardware modifications which is not always feasible.
You can use a BIOS password for every boot, not just for the setup.

But my entire point was that the Phoronix article's recommendation for Fedora's full-disk encryption is stupid without looking at the actual threats that the user needs to defend against.