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 someone from the cleaning crew in a hotel to do this by simply booting from a special flash drive in the simplest cases. Truecrypt is easier to write the attack software for, but this can be done against Linux encryption as well with additional effort. The BIOS can also be reflashed, but this requires someone who knows how to reflash the BIOS on the exact machine in question and is considerably more difficult. This is known as the “evil cook” attack due to the requirement for a skilled operative to carry it out.
UPDATE 12-29-2013: To this date the “evil maid” attack has NOT been detected in operational use as opposed to hackers playing games on oneanother. Instead, the Chinese MSS has been caught taking laptops apart to insert hardware keyloggers, a more reliable but more time consuming process. The FBI is believed to do the same. If you must leave an encrypted laptop unattended, consider gluing down the keyboard to prevent this. On desktops, watch for any “adapters” added where the keyboard plugs into the back. Machines handling material that any government would classify “Top Secret” should be bought with cash, never be connected to any network, and never have Windows activated. It is known that computers ordered by foreign governments and embassies from US manufacturers have had bugged hardware substituted, and there are those who suspect the NSA of planting firmware or hardware routines in motherboards that can be remotely turned on but must never be admitted to in any courtroom for fear of harming the computer industry. I consider that attack unlikely, but the Guardian folks handling the Snowden take used a randomly-purchased, never-networked machine for decrypting the take. Assume they knew what they were doing at this level.
None the less, the “evil maid” attack as well as the malicious BIOS reflash known as an “evil cook” attack remain theoretical possiblities that may appear in the field as defenses against hardware keyloggers proliferate. The “evil maid” attack does NOT require advance knowledge of the hardware used nor any additional hardware, and only plugging a hardware keylogger into a desktop keyboard cable is easier for an untrained hired party to do.
Defenses against the “Evil Maid” software keylogger
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 auto 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 with new keys, as a passphrase change protects only against simple attacks to log the passphrase and not more sophisticated attacks like modifying the Cryptsetup binary to log the LUKS decryption key as well as the passphrase.
The Evil Maid Detection Software
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. These scripts assume you are using only one disk, or that /dev/sda is the disk containing your root filesystem or at least the /boot partition. Edit them to reflect the difference if you have /boot on something else.
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
#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/$USER/.boot_integrity/bootsector)
KNOWNPARTITION=$(head -c 32 /home/$USER/.boot_integrity/bootpartition)
# Test Known against booted hashes
if test $SECTORIMAGE != $KNOWNSECTORIMAGE ; then
xmessage -c “WARNING-BOOT SECTOR HASH MISMATCH-a password logger may be present in boot loader ”
xmessage -c -timeout 2 “BOOT SECTOR CHECK OK”
if test $PARTITION != $KNOWNPARTITION;
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”
#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/$USER/.boot_integrity
#create image of boot partition
sudo dd if=/dev/sda of=/home/$USER/.boot_integrity/bootsectorimage bs=512 count=1
#save shasum of boot sector in ~/boot_integrity
sudo shasum /home/$USER/.boot_integrity/bootsectorimage (to)/home/luke/.boot_integrity/bootsector
sudo rm /home/$USER/.boot_integrity/bootsectorimage
#save shasum of boot partition in ~/boot_integrity
sudo shasum /dev/sda1 (to) /home/$USER/.boot_integrity/bootpartition