"Evil Maid" attack against disk encryption
Physical security is important. The "Evil Maid" attack serves as a reminder that briefly allowing a laptop out of your control, even with an encrypted hard disk, means that all security bets are off—the machine should be considered potentially compromised. Obviously different users have different levels of paranoia about their data security, but the Evil Maid attack shows just how simple it can be for others to access your data.
There is nothing particularly new in the proof-of-concept (PoC) attack against TrueCrypt disk encryption software, but the simplicity of the approach should give one pause. Joanna Rutkowska described the attack back in January, but the need for physical computer security goes back much further than that. But, folks are less wary of physical attacks against laptops today because of whole-disk encryption. Rutkowska's PoC, along with last year's report on "cold boot" attacks, should make it clear that encryption—at least without some kind of Trusted Platform Module (TPM) support—is not a complete solution
The basic idea behind Evil Maid is that someone gets access to a laptop for a fairly short period of time (a few minutes), and, in that time, boots it from a USB key. One obvious vector is a hotel maid (or someone acting as one), who enters someone's room while they are out to dinner, which is what gives the attack its name. The USB key contains a payload that hooks the TrueCrypt password prompting code and stores the last password entered. The payload gets added to the Master Boot Record (MBR) of the laptop so that it becomes active on the next boot.
While it has not been implemented in the PoC, there is no reason that the malware couldn't send the password off via the network; currently it just reports it back the next time the Evil Maid USB key is booted. That would require the attacker to access the laptop twice—with its user typing in the encryption key in between—but a multi-day hotel stay would give ample opportunity for that to occur.
As Bruce Schneier points out, this attack is in no way limited to TrueCrypt, as other solutions suffer from the same vulnerabilities. Both Schneier and Rutkowska look at some potential workarounds, but, in the final analysis, physical access allows an attacker too many ways around these security measures. Even Trusted Computing, with appropriate TPM hardware, can succumb to certain kinds of attacks.
Microsoft's BitLocker drive encryption uses the TPM, which provides reasonable assurance that the right code is being booted, but even that can fall prey to Evil Maid-style attacks, as Rutkowska describes:
Rutkowska also describes a "Poor Man's Solution" which calculates hashes of various unencrypted portions of the disk (especially the MBR). The Disk Hasher is a bootable Linux-based USB key that calculates and stores the hashes on the USB key, as well as verifying the correct hashes prior to booting. As she points out, it only protects against disk-based attacks—BIOS reflashing would subvert Disk Hasher.
Requiring a password in the BIOS before booting is another possible workaround, but one that may not provide as much security as it at first seems. BIOS reflashing is one possible attack, but an easier—though more time-consuming than the "standard" Evil Maid attack—method would be to remove the disk, attach it to another laptop and install the necessary code. It also adds complexity to the attack, but the 5-15 minutes needed to swap out a laptop hard disk is not all that difficult to come by in the hotel scenario.
This PoC, along with other attacks against encrypted disks, is very useful to remind users that hard disk encryption is no panacea. You still must consider which kinds of threats you are trying to protect against. Disk encryption is great for preventing accidental disclosure of private information when someone steals a laptop, but is much less useful for an attack that is focused on accessing the data on a particular laptop. Much like internet security, fairly straightforward protection techniques are fine to thwart the random attacker but are probably insufficient for one who is focused on subverting your defenses in particular.
Index entries for this article | |
---|---|
Security | Encryption/Disk |
Security | Physical security |
Posted Oct 29, 2009 6:59 UTC (Thu)
by sitaram (guest, #5959)
[Link] (2 responses)
I've heard people say that these sorts of encryptions do not have too much entropy and/or people use weak or guessable passwords, but it's still a pretty good extra layer of security on top of whatever else you may be doing, and at least it makes it *feasible* (if you're sufficiently paranoid and disciplined) to protect your self.
About the only thing that would cause concern here is a backdoor left in the hard disk, for "technical support" reasons or at the behest of agencies with 3-letter acronyms :-) I wouldn't rule out that possibility.
Posted Oct 29, 2009 22:55 UTC (Thu)
by diederich (subscriber, #26007)
[Link] (1 responses)
Posted Oct 30, 2009 0:30 UTC (Fri)
by sitaram (guest, #5959)
[Link]
Posted Oct 29, 2009 10:47 UTC (Thu)
by epa (subscriber, #39769)
[Link] (2 responses)
Posted Nov 2, 2009 22:04 UTC (Mon)
by roelofs (guest, #2599)
[Link] (1 responses)
(These things work better if you mail them to lwn@, btw.)
Greg
Posted Nov 2, 2009 22:25 UTC (Mon)
by jake (editor, #205)
[Link]
ah yes, i somehow had missed the parent comment ... all fixed, including the one you emailed, Greg.
i should take the grumpy guy's advice and not try to write articles on Wednesday :)
thanks!
jake
Posted Oct 29, 2009 10:53 UTC (Thu)
by ranmachan (guest, #21283)
[Link] (4 responses)
At least the first can be worked around by either password-protecting the harddisk (which modern disks support, but I have no idea if there are BIOSes that can boot from protected disks) or even better to always boot from a usb stick you carry with you at all times and not have the boot code on the system at all. :)
The only thing you can do about 'hardware keylogger' attacks is probably to physically lock away the system in a safe or some other safe place.
Posted Oct 29, 2009 12:12 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (3 responses)
Posted Oct 29, 2009 15:00 UTC (Thu)
by drag (guest, #31333)
[Link] (2 responses)
Posted Oct 29, 2009 15:24 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Not anymore. New platforms (including notebooks) have IOMMU, which separates each device into its own memory protection domain.
"TAKE YOUR BOOTLOADER WITH YOU."
Won't work. 'Evil maid' can infect your BIOS, so your whole Linux will run after 'evil' code is executed. Which can install backdoors into SMM, for example.
In short, TPM is the only real solution. You _need_ to have a hardware you trust as the base of the 'trust chain'.
Posted Oct 29, 2009 20:31 UTC (Thu)
by drag (guest, #31333)
[Link]
Even if your using TPM the hardware can still be subverted if you allow
TPM is useful for detection of problems with malicious software in your
It is not really designed to secure your machine from physical access.
------------------------------------
Really the only solution using current technology is just not to leave your
Posted Oct 29, 2009 14:59 UTC (Thu)
by MegabytePhreak (guest, #60945)
[Link] (4 responses)
Posted Oct 29, 2009 18:57 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (3 responses)
There's simply no way around it: once you give an attacker physical access, you give him the kingdom.
Posted Oct 29, 2009 21:29 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link] (2 responses)
This obviously assumes that the current password can't be used to gain access to a more permanent key. The permanent key could be made so bulky that it can't be stored in the MBR, and that getting it off the system by other means would take a noticeable amount of time. Or you could re-encrypt the entire disk with the new password every time, and not have a permanent key...
You could also make the encryption hardware external to the main system, and never expose the permanent key to the computer itself at all. That eliminates the need to re-encrypt, but the device has to be tamper-proof (or you have to carry it around all the time). Good built-in drive encryption would qualify, but only if you can change the password of an unlocked drive without clearing it.
Posted Oct 30, 2009 2:11 UTC (Fri)
by bronson (subscriber, #4806)
[Link] (1 responses)
If you enter your one-time password on a subverted system, the attacker suddenly has access to all your data. He only needs access once.
> Or you could re-encrypt the entire disk
Not if your system is subverted. Sure, it would appear to you that everything is being re-encrypted, but in reality the back door the maid slipped will be used to copy everything the next time you leave your computer behind. (this is just one scenario, the attacker could also weaken the encryption algo, ship your data out over the network, etc etc)
> You could also make the encryption hardware external to the main system
Perhaps, but this doesn't exist today and sounds awfully expensive to develop.
Posted May 6, 2010 23:18 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link]
All your *current* data, yes; I don't see a way around that. The idea was to protect any future data you may put on the device from a different host PC.
> Not if your system is subverted.
The idea was to remove the USB key and re-encrypt it on a known-clean system, not re-encrypt on the compromised PC. Again, this is to protect against future unauthorized access, not to protect any data which may have already been exposed.
> Perhaps, but this doesn't exist today and sounds awfully expensive to develop.
I don't think it would be all that expensive; it's basically just a TPM chip with some trivial input hardware for the password. Internal hard-disk encryption exists today, though I don't know if it's any good. The drives I know of with that feature require full re-encryption to change the password, if they support it at all, but that wouldn't be hard to fix.
Posted Oct 29, 2009 16:00 UTC (Thu)
by giggls (subscriber, #48434)
[Link] (2 responses)
The system itselfs consists of a LUKS encrypted harddrive without any bootloader installed. To get them running the flash drives are used (I offer booting from our cooperate LAN as an additional feature).
The only thing I would like to get worked out is to add kexec. This way I would be able to make this stuff independent of distributions and kernels of the running system.
Posted Oct 29, 2009 18:59 UTC (Thu)
by bronson (subscriber, #4806)
[Link]
Posted Oct 30, 2009 17:02 UTC (Fri)
by NAR (subscriber, #1313)
[Link]
Posted Oct 29, 2009 17:00 UTC (Thu)
by ikm (guest, #493)
[Link] (1 responses)
Posted Oct 29, 2009 17:35 UTC (Thu)
by zzxtty (guest, #45175)
[Link]
I suspect a lot of this paranoia is directed at people visiting China and the idea of state sponsored industrial espionage. In such a case you cannot trust the hotel room safe, in fact you cannot trust anything.
Take your own hardened case and 50 or so quality padlocks?
Posted Oct 31, 2009 15:42 UTC (Sat)
by wolfgang.oertl (subscriber, #7418)
[Link] (1 responses)
Posted Nov 6, 2009 13:46 UTC (Fri)
by robbe (guest, #16131)
[Link]
Posted Nov 2, 2009 22:33 UTC (Mon)
by jordanb (guest, #45668)
[Link]
Posted Nov 26, 2009 19:07 UTC (Thu)
by mcortese (guest, #52099)
[Link]
For example, keeping the Now, if I correctly understood the aim of the article, it was not to prove that your hardware is prone to attacks if left unattended, but rather how simple and quick these can be. Re-flashing a BIOS is in no way comparable to plugging in a USB drive and pressing the power button!
Before Joanna's article and proof of concept, we were tempted to overestimate the security level that Full Disk Encryption could grant us. Thank her for the enlightenment. Does this mean that FDE is useless? I don't think so. Alone it is not enough, but with appropriate side measures (like removable
"Evil Maid" attack against disk encryption
"Evil Maid" attack against disk encryption
"Evil Maid" attack against disk encryption
Grammar nitpick
One still must consider which kinds of threats you are trying to protect against.
Should be either 'One still must consider which kinds of threats one is trying to protect against.', or 'You still must consider...'
"This PoC ... are very useful" is even more painful. ;-)
Grammar nitpick
Grammar nitpick
"Evil Maid" attack against disk encryption
This leaves the 'hacker physically removes harddisk' and 'hacker adds hardware keylogger' attack vectors.
"Evil Maid" attack against disk encryption
If a normal PC was left on then it makes it even easier to grab passwords.
"Evil Maid" attack against disk encryption
If your using a laptop, for example, any device that you plug into it that
implements DMA access can trivially retrieve your password. Like a firewire
cardbus card or something like that. Plug that in, Linux detects it and
configures it, and the attacker uses a separate PC running Linux to
communicate over the firewire and send DMA requests to systematically shift
through your memory until it finds the encryption key.
Even if you block against autodetecting hardware your RAM is still
removable so that if the attacker is quick they can pull your RAM out of
your machine and then read it before the memory goes all random on them.
And there are other attacks besides that.
Now this is with actual hardware you can actually buy. Theoretically if
you have some sort of physical resistant hardware then that may help. For
example you can currently purchase hardddrives that have self-destruct
mechanisms that get set off if they are tampered with... doing such things
as spraying the drive internals with acid mist to etch the platters. So you
can do all sorts of stuff theoretically if the hardware supports it, but
right now that is not typical consumer hardware most of us can afford.
---------------------------------
Now I can't believe people are avoiding obvious solutions to this
particular attack (were they install a trojaned bootloader):
TAKE YOUR BOOTLOADER WITH YOU.
This is Linux. You don't have to boot off of internal media if you don't
want to. Use a USB stick and boot from that and take that with you.
Or just take the laptop with you were ever you go. If it is a small device
like a "open Linux smartphone" or a netbook that can adequately meet your
needs then you can just keep it on your person.
"Evil Maid" attack against disk encryption
"Evil Maid" attack against disk encryption
physical access to it. TPM does not solve any "evil maid" related issue
that putting the bootloader in removable media won't solve, except maybe
the BIOS thing.
bootloader and kernel. That way you can establish a chain of trust from
initial boot-up to running the OS. This allows you to hash every element
from the BIOS on upwards. This way you can reliably detect things like
rootkits by a simple reboot, which is impossible otherwise. Previously to
TPM you had to use a tool like tripwire or other host-based IDS while the
system was offline (like you were booted up in a live cd) and comparing
that result with last known good hash is the only reliable way to combat
rootkits. TPM can reduce the complexity, expense, and difficulty of that
considerably.
stuff were other people have access to it when your not around.
"Evil Maid" attack against disk encryption
"Evil Maid" attack against disk encryption
"Evil Maid" attack against disk encryption
"Evil Maid" attack against disk encryption
"Evil Maid" attack against disk encryption
My scheme does not seem to be vulnerable
My scheme does not seem to be vulnerable
My scheme does not seem to be vulnerable
"Evil Maid" doesn't care about your passwords -- watch out for the thieves though
"Evil Maid" doesn't care about your passwords -- watch out for the thieves though
"Evil Maid" attack against disk encryption
"Evil Maid" attack against disk encryption
well post your Valuable Secrets to wikileaks once you plugged in your
memory stick containing it.
"Evil Maid" attack against disk encryption
I read the original article, and found the comments particularly interesting. I also think Joanna was a little too severe with those proposing alternative protection schemes against the attack.
"Evil Maid" attack against disk encryption
/boot
partition in a removable media that you carry with you all the time, does help. Nonetheless such proposal was dismissed as ineffective because it still allows for a BIOS infection.
/boot
) it can secure our system to a reasonable level.