"Evil Maid" Attacks on Encrypted Hard Drives

Before you leave your hotel room, turn off your laptop and store it properly in your suitcase.

Problem solved.

(I'll not comment on software protection (there are several, such as checking the integrity of the MBR, use live CDs for the bootloader ...) We have been thoroughly reviewed when it appeared the Stoned Bootkit and here the method not only uses Windows with admin privileges to be installed, but the technique is the same as the Stoned: install malicious software on the master boot record.)

 

FWIW, most commercial-grade encryption products protect MBR (both their own and original Windows) either via encryption or some other method, so installing a malicious bootloader won't get you anywhere on those.
This might work on TrueCrypt, though.

 

Also, according to Mr. Schneier:

 

Do you have any prove or an article that supports your claim?
Does PGP, for example, have this?

 

I'm sure PGP Whole Disk Encryption does, it would be insane if they didn't. Utimaco (Sophos) SafeGuard Enterprise does for sure, and so did Guardian Edge when I tested it.

 

Ok, then how is the boot code executed if it's encrypted ? The BIOS gives control to a segment of code, usually located on the HDD (in case of HDD boot), and that segment of code can't be encrypted. It is this portion of code that is not possible to protect and that can be exploited by an "evil maid" attack.

 

Clearly the best thing is to keep your laptop with you. With netbooks, it's much easier than before.

Otherwise, all bets are off. The best that can be done to prevent anything like this is to make it obvious you have been compromised. At least then, you know.

Hint: Check out Predator at http://www.montpellier-informatique.com/predator/en/index.php


edit to include link

 

There are, of course, still risks with doing this. There's the cold boot attack, which requires freezing the RAM. Now instead of two steps for a compromise, it only takes one. Extract the key from RAM and have full access to the drive.

The second attack involves DMA (direct memory access) through firewire or other ports capable of this. This probably can't be prevented by this technology. This technique, again, allows the extraction of the key from RAM in one step.

For the average user, it's probably safer to just shut off the computer. There are probably ways to prevent the above attacks, but not much that the average user will be able to do. Some people want perfect security, but there always has to be something unencrypted somewhere to allow you to authenticate yourself. This is the vulnerability. Having near perfect security will probably only be achieved by people willing to do whatever it takes to plug any vulnerability. For the rest of us, there's always some risk.

I personally don't mind TrueCrypt's approach. KISS. TrueCrypt isn't anti-malware, and trying to implement these features will simply add a lot of complexity to the code. Also, from my experience, TrueCrypt's approach is usually all-or-nothing. If they don't have a way to completely plug a vulnerability, they usually won't implement it. I don't know what the commercial vendors do, but it's probably not 100% effective.

 

In a paranoia scenario, then you dont use the bootloader stored in the hard disk to boot the computer, you could use your recovery live CD to boot Truecrypt and permanently delete your hard disk computer bootloader with WinHex.

You would still have to store that live CD in a safe place to avoid someone tampering with it, maybe sign it.

 

Most run a secured version of Linux or OpenBSD and replace (or pad) existing MBR with their own, protected one. So in short, its own protected MBR runs, that in turn, points to original or modified MBR that is normally encrypted, but becomes accessible after preboot authentication is completed, and filter drivers are loaded.
Hope this makes sense.

 

With all due respect, but that's an assumption concerning PGP.

 

Point taken, I have no hands-on experience with their Enterprise suite. But as I said, it would be crazy if they didn't have something similar in place.

 

tpm evil maid

im not computer savvy but i noticed when i was looking at the services on my vista home basic computer that i have this running TPM Base Services and the description is that it protects your keys. So if windows vista has this wouldnt evil maid be ineffective?

 

http://www.truecrypt.org/docs/?s=rescue-disk

Here's a description of how to boot directly from the rescue disk, thus bypassing the TrueCrypt bootloader on the hard drive entirely.

I don't fully understand that. Do you have links to a description of this from one of the commercial vendors?

 

Re: tpm evil maid

I know nothing about Vista, TPM, or bitlocker, by I'm pretty sure it can't protect your bootloader while using anything other than bitlocker. How well it works with bitlocker, I have no idea.

 

According to the PGP Desktop User’s Guide, the boot record is encrypted by the PGP Whole Disk Encryption product. Thus, replacing the boot loader with a malicious counterpart would cause a boot failure and thereby maintain the integrity of a PGP encrypted volume -- correct?

Also, note that PGP Whole Disk Encryption supports Trusted Platform Module (TPM) authentication.

 

Re: tpm evil maid

See Pleonasm's post below (or above my post), as this is exactly what he's talking about and he's 100% correct: replacing PGP's MBR with your own won't get you anywhere, as something needs to authenticate you, load filter driver(s) and decrypt original Windows MBR that has been padded further up the drive and encrypted.
So, in short it works like this:
BIOS->Encryption Vendor MBR->Preboot authentication->Filter Driver(s) loaded->Original (encrypted) MBR executed->OS loads
This is obviously oversimplified, but you get the idea.

 

I stand corrected.

 

Re: tpm evil maid

Why can't some malware be loaded into the area of the hard drive containing the preboot authentication or any unencrypted area of the drive prior to the encrypted MBR? Couldn't malware loaded there in turn do something to the encrypted MBR after it's decrypted?

My point is you're still executing something that's unencrypted prior to the encrypted MBR. So, how do you know this unencrypted code is immune to malware?

 

Another strategy to help ameliorate this “evil maid” threat is the use of a power-on password, supported by some BIOS implementations. It is not foolproof, however, because the setting can be circumvented by manipulating a jumper.

 

Ah, now I see your point.

* * * * * * * * * * * * * * *​

Commentary from PGP on this subject...

In addition...

 

Just like pleonasm posted, most (if not all) full-disk encryption vendors have a way of securing their MBR. You can't just overwrite the OS MBR that has been padded further up the drive, it's encrypted and you will need to be authenticated to preboot before you can make any changes to it that would give you any results.
You can blow away vendor's preboot space and MBR, or replace it with your own trojaned version, but this won't get you anywhere, as decryption mechanism and loading of filter drivers is extremely proprietary and protected by the developer. You'll have your super-sneaky MBR that sits on top of encrypted, inaccessible drive.

 

thats true but if your usb and dvd rom and computer screen is locked how many people are going to know how to bypass such layers? is it that easy?

edit: thats nice preditor keeps logs of activity so you know whats going on with your computer and if anything happened

 

Who are you protecting against? It's not easy, but it's possible. The RAM freezing attack can be performed by anyone who's ever heard of it. You just open the case, freeze the RAM, and stick it in another computer. You image the RAM with the other computer, then that's where the real skill is needed. Extract the key from the RAM.

But, all steps prior to the key extraction are easy, and the key extraction has no time limit. Once you have the image of the RAM, you can give it to an expert to extract any time you want.

A log won't help you in this case. Your key is extracted in one step. You aren't required to come back and enter the password. So, all they do is image the RAM, take your computer (or just the hard drive) with them, then extract the key in the lab and access your encrypted drive.

You won't even have a computer to give you a log.