PROTECTING DISK ENCRYPTION from “Evil Maid” boot keyloggers

Quick Register
User Name:
Human Verification

Go Back   UNP > UNP Misc > Technology

UNP Register


Old 02-Aug-2013
Arrow PROTECTING DISK ENCRYPTION from “Evil Maid” boot keyloggers

OK, you’ve taken our advice and installed your favorite linux distro on a fully encrypted disk. This not only secures your data, but write-protects the bulk of your system, as you someone burglarizing your home cannot write keyloggers and spyware unless he first decrypts the disk-which requires that those keyloggers already be there-checkin and egg, he loses.

Well, not quite: you cannot encrypt the /boot partition because then “chicken and egg” keeps you from booting, as the BIOS cannot read encryption and could be attacked anyway if it could.

It is possible to replace the files that unlock your disk with a version that saves your passphrase for a later attack in what is called an ‘evil maid” attack, as published in 2600. The name comes from the ability to hire cleaning crew in a hotel to do this by simply booting from a special flash drive in the simplest cases.

There are two ways to stop the “evil maid” attack: keeping your boot partition on a flash drive you carry at all times, or using a checksum value of the boot sector and boot partition to detect it and change you passphrase. The evil maid attack requires access twice, with you unlocking the disk in between and not changing the passphrase and remaking the encrypted volume(in the case of LUKS or other systems where your passphrase encrypted a volume key).

The only totally(as far as we know)secure defense is to copy /boot onto a flash drive, install GRUB on that drive, and debug this until you can boot from the flash drive with the encrypted disk as the root filesytem.

This is very secure, but slows things down if you like to quickly boot a cheap netbook.

Therefore, an DC area activist has developed this boot checking system described below.WARNING-it is possible to defeat this code by a more sophisticated evil maid attack than anything yet published, I’m not going to tell you how to do this

This defense against currently-published “evil maid” attacks requires that you edit your /etc/fstab to exclude your /boot partition from mounting at boot, and you must mount it manually and re-run the update script if you update software affecting booting (kernel or update-initramfs). This is the main disadvantage, but is simpler than keeping /boot on a flash drive. If you detect tampering, you MUST remake the entire encrypted disk, and simple DM-crypt encryption does not support a passphrase change and LUKS encryption uses the passphrase to encrypt a random number volume key that a sophisticated attacker could hide anywhere on the disk.

Here are the scripts for boot checking and boot updating: Use them, hack them, evaluate them, try to beat them if you play with evil maid-then try to fix them to block your attacks, posting your results here.

NOTE: REPLACE (to) with right carrot for shell redirection as that character (above the period key with caps selected) is a prohibited character in this page due to html interaction You can do this with the “replace” function in gedit, the default text editor (not word processor) in Ubuntu and other GNOME desktop distros

#! /bin/bash

xmessage -c -timeout 2 “Checking for boot password keyloggers…”

# Get boot sector hash for 512 B boot sector

mkdir -p /tmp/booted

dd if=/dev/sda of=/tmp/booted/bootsectorimage bs=512 count=1

shasum /tmp/booted/bootsectorimage (to)/tmp/booted/bootsector

rm /tmp/booted/bootsectorimage

#Get hash for boot partition as booted

shasum /dev/sda1(to) /tmp/booted/bootpartition

#Set shell variables for booted hashes

SECTORIMAGE=$(head -c 32 /tmp/booted/bootsector)
PARTITION=$(head -c 32 /tmp/booted/bootpartition)

#Set shell variables for known good hashes

KNOWNSECTORIMAGE=$(head -c 32 /home/luke/.boot_integrity/bootsector)

KNOWNPARTITION=$(head -c 32 /home/luke/.boot_integrity/bootpartition)

# Test Known against booted hashes


xmessage -c “WARNING-BOOT SECTOR HASH MISMATCH-a password logger may be present in boot loader “


xmessage -c -timeout 2 “BOOT SECTOR CHECK OK”




xmessage -c “WARNING-BOOT PARTITION HASH MISMATCH-a password logger may be present in bootloader stages, kernel or initramfs”


xmessage -c -timeout 2 “BOOT PARTITION CHECK OK”


exit 0



#Check boot partition filesystem as it cannot be checked at boot

sudo umount /boot
sudo e2fsck /dev/sda1

#make directory for shasums of boot sector and boot partition

mkdir -p /home/luke/.boot_integrity

#create image of boot partition

sudo dd if=/dev/sda of=/home/luke/.boot_integrity/bootsectorimage bs=512 count=1

#save shasum of boot sector in ~/boot_integrity

sudo shasum /home/luke/.boot_integrity/bootsectorimage (to)/home/luke/.boot_integrity/bootsector

sudo rm /home/luke/.boot_integrity/bootsectorimage

#save shasum of boot partition in ~/boot_integrity

sudo shasum /dev/sda1 (to) /home/luke/.boot_integrity/bootpartition

Post New Thread  Reply

« Android and iPhone security warning: hidden program sending | Setting up secure public computers »