pages tagged linuxspwhittonhttps://spwhitton.name//tag/linux/spwhittonikiwiki2018-02-15T04:58:19ZA better defence against the evil maid attack on a laptophttps://spwhitton.name//blog/entry/evilmaid/2018-02-15T04:58:19Z2018-02-14T19:22:07Z
<h1>The attack</h1>
<p>Laptops need full disc encryption. Indeed, my university has
explicitly banned us keeping any information on our students’ grades
on our laptops unless we use FDE. Not even comments on essays,
apparently, as that counts as grade information.</p>
<p>There must, though, exist unencrypted code that tells the computer how
to decrypt everything else. Otherwise you can’t turn your laptop on.
If you’re only trying to protect your data from your laptop being
permanently stolen, it’s fine for this to be in an unencrypted
partition on the laptop’s HDD: when your laptop is stolen, the data
you are trying to protect remains encrypted.</p>
<p>An evil maid attack involves the replacement of this unencrypted code
with something malicious – perhaps it e-mails data from the encrypted
partition to someone who wants it. Of course, if someone has access
to your laptop without your knowledge, they can always work around any
security scheme you might develop. They might add a hardware
keylogger, for example. So why might we want to try to protect
against the evil maid attack – haven’t we already lost if someone is
able to modify the contents of the unencrypted partition of our hard
drive?</p>
<p>Well, the thing about the evil maid attack is that it is very quick
and easy to modify the contents of a laptop’s hard drive, as compared
to other security-bypassing hardware modifications, which take much
longer to perform without detection. Users expect to be able to
easily replace their hard drives, so they are usually accessible with
the removal of just a single screw. It could take less than five
minutes to deploy the evil maid payload.</p>
<p>Laptops are often left unattended for the two or three minutes it
would take to deliver an evil maid payload; they are less often left
for long enough that deeper hardware modifications could be made. So
it is worth taking steps to prevent evil maid attacks.</p>
<h1>The best solution</h1>
<p>UEFI Secure Boot. But</p>
<ul>
<li>Debian does not support this yet; and</li>
<li>my laptop does not have the hardware support anyway.</li>
</ul>
<h1>My current solution</h1>
<p>The standard solution is to put the unencrypted hard drive partition
on a USB key, and keep that on one’s keychain. Then there is no
unencrypted code on the laptop at all; you boot from the USB, which
decrypts the root partition, and then you unmount the USB key.</p>
<h1>Problem with this solution</h1>
<p>The big problem with this is kernel and bootloader upgrades. You have
to ensure your USB key is mounted before your package manager upgrades
the kernel. This effectively rules out using unattended-upgrades to
get security upgrades for the kernel. They must be applied manually.
Further, you probably want a backup USB key with the kernel and
bootloader on it. Now you have to upgrade both, using commands like
<code>apt-get --reinstall</code>.</p>
<p>This is a real maintenance burden and is likely to delay your security
upgrades. And the whole point of putting <code>/boot</code> on a USB key was to
improve security!</p>
<h1>Something better</h1>
<p>Recent GRUB is able to decrypt partitions itself. So <code>/boot</code> can
reside within your encrypted root partition. GRUB’s setup scripts are
smart enough that you can switch over to this in just a few steps:</p>
<ol>
<li>Move contents of <code>/boot</code> from USB drive into root partition.</li>
<li>Remove/comment <code>/boot</code> from <code>/etc/fstab</code>.</li>
<li>Set <code>GRUB_ENABLE_CRYPTODISK=y</code> in <code>/etc/default/grub</code>.</li>
<li><code>grub-install /dev/sda</code></li>
<li><code>update-grub</code></li>
</ol>
<p>It’s still true that there must be unencrypted code that knows how to
decrypt the root partition. Where does that go? <code>grub-install</code> is
the command that installs that code; where does it put it? The
<a href="https://wiki.archlinux.org/index.php/GRUB#GUID_Partition_Table_.28GPT.29_specific_instructions">ArchLinux wiki has the answer</a>. If you’re using EFI, it will go in
the EFI system partition (ESP). Under BIOS, if your drive is
formatted with an MBR, it goes in the “post-MBR gap” between the MBR
and the first partition (on drive partitioned with very old tools,
this post-MBR gap might be too small to accommodate the larger GRUB
image that contains the decryption code; however,
<a href="https://superuser.com/questions/352572/why-does-the-partition-start-on-sector-2048-instead-of-63">drives partitioned with recent tools</a> that “support 1 MiB partition
alignment” (including the Debian stretch installer) will be fine – to
check <code>fdisk -l</code> and look at where your first partition starts).
Under BIOS, if your drive is formatted with a GPT, you have to add a
1MiB BIOS boot partition, and the code goes there.</p>
<p>We’ve resolved the issue of package updates modifying <code>/boot</code>, which
now resides in the encrypted root partition. However, this is not all
of the picture. If we are using EFI, now we have unencrypted code in
the EFI system partition which is subject to the evil maid attack.
And if we respond by moving the EFI system partition onto a USB drive,
the package update problem reoccurs: the EFI system partition will not
always be mounted. If we are using BIOS, the evil maid reoccurs since
it is not that much harder to modify the code in the post-MBR gap or
the BIOS boot partition.</p>
<p>My proposed solution, pending UEFI Secure Boot, is to use BIOS boot
with a MBR partition table, keep <code>/boot</code> in the encrypted root
partition and <code>grub-install</code> to the USB drive. <code>dpkg-reconfigure
grub-pc</code> and tell it to never <code>grub-install</code> to anything. Then set
the laptop’s boot order to never try to boot from the HDD, only from
USB. (There’s no real advantage of GPT with my simple partitioning
setup but I think that would also work fine.)</p>
<p>How does this solve the various issues I’ve raised? Well, the amount
of code on the USB drive is very small (less than 1MiB) so it is much
less likely to require manual updates. Kernel updates will modify
<code>/boot</code>; only bootloader could require me to manually run
<code>grub-install</code> to modify the contents of the post-MBR gap, but these
are very infrequent.</p>
<p>Of course, the BIOS could be cracked such that the laptop will boot
from the HDD no matter what USB I have plugged in, or even only when
some USB is plugged in, but that’s a hardware modification beyond the
evil maid, against which we are not trying to protect.</p>
<p>As a nice bonus, the USB drive’s single FAT32 partition is now usable
for sneakernet.</p>