Let’s quickly recap the Evil Maid Attack. The scenario we consider is when somebody left an encrypted laptop e.g. in a hotel room. Let’s assume the laptop uses full disk encryption like e.g. this provided by TrueCrypt or PGP Whole Disk Encryption.
Many people believe, including some well known security experts, that it is advisable to fully power down your laptop when you use full disk encryption in order to prevent attacks via FireWire/PCMCIA or ”Coldboot” attacks.
So, let’s assume we have a reasonably paranoid user, that uses full disk encryption on his or her laptop, and also powers it down every time they leave it alone in a hotel room, or somewhere else.
Now, this is where our Evil Maid stick comes into play. All the attacker needs to do is to sneak into the user’s hotel room and boot the laptop from the Evil Maid USB Stick. After some 1-2 minutes, the target laptop’s gets infected with Evil Maid Sniffer that will record the disk encryption passphrase when the user enters it next time. As any smart user might have guessed already, this part is ideally suited to be performed by hotel maids, or people pretending to be them.
So, after our victim gets back to the hotel room and powers up his or her laptop, the passphrase will be recorded and e.g. stored somewhere on the disk, or maybe transmitted over the network (not implemented in current version).
Now we can safely steal/confiscate the user’s laptop, as we know how to decrypt it. End of story.
Download the USB image here. In order to “burn” the Evil Maid use the following commands on Linux (you need to be root to do dd):
dd if=evilmaidusb.img of=/dev/sdX
/dev/sdXshould be replaced with the device representing your USB stick, e.g.
/dev/sdb. Please be careful, as choosing a wrong device might result in damaging your hard disk or other media! Also, make sure to use the device representing the whole disk (e.g.
/dev/sdb), rather than a disk partition (e.g.
On Windows you would need to get a dd-like program, e.g. this one, and the command would look more or less like this one (depending on the actual dd implementation you use):
dd if=evilmaidusb.img of=\\?\Device\HarddiskX\Partition0 bs=1M
HarddiskXshould be replaced with the actual device the represents your stick.
After preparing the Evil Maid USB stick, you’re ready to test it against some TrueCrypt-encrypted laptop (more technically: a laptop that uses TrueCrypt system disk encryption). Just boot the laptop from the stick, confirm you want to run the tool (press ‘E’) and the TrueCrypt loader on your laptop should be infected.
Now, Evil Maid will be logging the passphrases provided during the boot time. To retrieve the recorded passphrase just boot again from the Evil Maid USB -- it should detect that the target is already infected and display the sniffed password.
The current implementation of Evil Maid always stores the last passphrase entered, assuming this is the correct one, in case the user entered the passphrase incorrectly at earlier attempts.
NOTE: It’s probably illegal to use Evil Maid to obtain password from other people without their consent. You should always obtain permission from other people before testing Evil Maid against their laptops!
CAUTION: The provided USB image and source code should be considered proof-of-concept only. Use this code at your own risk, and never run it against a production system. Invisible Things Lab cannot be held responsible for any potential damages this code or its derivates might cause.
How the Evil Maid USB works
The provided implementation is extremely simple. It first reads the first 63 sectors of the primary disk (
/dev/sda) and checks (looking at the first sector) if the code there looks like a valid TrueCrypt loader. If it does, the rest of the code is unpacked (using gzip) and hooked. Evil Maid hooks the TC’s function that asks user for the passphrase, so that the hook records whatever passphrase is provided to this function. We also take care about adjusting some fields in the MBR, like the boot loader size and its checksum. After the hooking is done, the loader is packed again and written back to the disk.
You can get the source code for the Evil Maid infector here.
So, how should we protect against such Evil Maid attacks? There are a few approaches...
1. Protect your laptop when you leave it alone
Several months ago I had a discussion with one of the TrueCrypt developers about possible means of preventing the Evil Maid Attack, perhaps using TPM (see below). Our dialog went like this (reproduced here with permission from the TrueCrypt developer):
TrueCrypt Developer: We generally disregard "janitor" attacks since they inherently make the machine untrusted. We never consider the feasibility of hardware attacks; we simply have to assume the worst. After an attacker has "worked" with your hardware, you have to stop using it for sensitive data. It is impossible for TPM to prevent hardware attacks (for example, using hardware key loggers, which are readily available to average Joe users in computer shops, etc.)
Joanna Rutkowska: And how can you determine that the attacker have or have not "worked" with your hardware? Do you carry your laptop with you all the time?
TrueCrypt Developer: Given the scope of our product, how the user ensures physical security is not our problem. Anyway, to answer your question (as a side note), you could use e.g. a proper safety case with a proper lock (or, when you cannot have it with you, store it in a good strongbox).
Joanna Rutkowska: If I could arrange for a proper lock or an impenetrable strongbox, then why in the world should I need encryption?
TrueCrypt Developer: Your question was: "And how can you determine that the attacker has or has not worked with your hardware?" My answer was a good safety case or strongbox with a good lock. If you use it, then you will notice that the attacker has accessed your notebook inside (as the case or strongbox will be damaged and it cannot be replaced because you had the correct key with you). If the safety case or strongbox can be opened without getting damaged & unusable, then it's not a good safety case or strongbox. ;-)
That's a fair point, but this means that for the security of our data we must relay on the infeasibility to open our strongbox lock in a "clean" way, i.e. without visually damaging it. Plus it means we need to carry a good strongbox with us to any travel we go. I think we need a better solution...
Note that TrueCrypt authors do mention the possibility of physical attacks in the documentation:
If an attacker can physically access the computer hardware and you use it after the attacker has physically accessed it, then TrueCrypt may become unable to secure data on the computer. This is because the attacker may modify the hardware or attach a malicious hardware component to it (such as a hardware keystroke logger) that will capture the password or encryption key (e.g. when you mount a TrueCrypt volume) or otherwise compromise the security of the computer.However, they do not explicitly warn users of a possibility of something as simple and cheap as the Evil Maid Attack. Sure, they write "or otherwise compromise the security of the computer", which does indeed cover e.g. the Evil Maid Attack, but my bet is that very few users would realize what it really means. The examples of physical attacks given in the documentation, e.g. modifying the hardware or attaching a malicious hardware, is something that most users would disregard as too expensive an attack to be afraid of. But note that our Evil Maid attack is an example of a “physical” attack, that doesn’t require any hardware modification and is extremely cheap.
Of course it is a valid point, that if we allow a possibility of a physical attack, then the attacker can e.g. install a hardware keylogger. But doing that is really not so easy as we discuss in the next paragraph. On the other hand, spending two minutes to boot the machine from an Evil Maid USB stick is just trivial and is very cheap (the price of the USB stick, plus the tip for the maid).
2. The Trusted Computing Approach
As explained a few months ago on this blog, a reasonably good solution against Evil Maid attack seems to be to take advantage of either static or dynamic root of trust offered by TPM. The first approach (SRTM) is what has been implemented in Vista Bitlocker. However Bitlocker doesn’t try to authenticate to the user (e.g. via displaying a custom picture shot by the user, with the picture decrypted using a key unsealed from a TPM), so it’s still possible to create a similar attack against Bitlocker, but with a bit different user experience. Namely the Evil Maid for Bitlocker would have to display a fake Bitlocker prompt (that could be identical to the real Bitlocker prompt), but after obtaining a correct password from the user Evil Maid would not be able to pass the execution to the real Bitlocker code, as the SRTM chain will be broken. Instead, Evil Maid would have to pretend that the password was wrong, uninstall itself, and then reboot the platform. Thus, a Bitlocker user that is confident that he or she entered the correct password, but the OS didn’t boot correctly, should destroy the laptop.
The dynamic root of trust approach (DRTM) is possible thanks to Intel TXT technology, but currently there is no full disk encryption software that would make use of it. One can try to implement it using Intel’s tboot and some Linux disk encryption, e.g. LUKS.
Please also note that even if we assume somebody “cracked” the TPM chip (e.g. using an electron microscope, or NSA backdoor), that doesn’t mean this person can automatically get access to the encrypted disk contents. This is not the case, as the TPM is used only for ensuring trusted boot. After cracking the TPM, the attacker would still have to mount an Evil Maid attack in order to obtain the passphrase or key. Without TPM this attack is always possible.
Are those trusted computing-based approaches 100% foolproof? Of course not. As signalized in the previous paragraph, if an attacker was able to mount a hardware-based keylogger into your laptop (which is non-trivial, but possible), then the attacker would be able to capture your passphrase regardless of the trusted boot. A user can prevent such an attack by using two-factor authentication (RSA challenge-response implemented in a USB token) or e.g. one-time passwords, so that there is no benefit for the attacker to capture the keystrokes. But the attacker might go to the extreme and e.g. replace the DRAM, or even the CPU with malicious DRAM or CPU that would sniff and store the decryption key for later access. We’re talking here about attack that very few entities can probably afford (think NSA), but nevertheless they are theoretically possible. (Note that an attack with inserting a malicious PCI device that would try to sniff the key using DMA can be prevented using TXT+VT-d technology).
However, just because the NSA can theoretically replace your CPU with a malicious one, doesn’t mean TPM-based solutions are useless. As for the great majority of other people that do not happen to be on the Terrorist Top 10, these represent a reasonable solution that could prevent Evil Maid attacks, and, when combined with a proper two-factor authentication, also simple hardware based attacks, e.g. keylogger, cameras, remote keystroke sniffing using laser, etc. I really cannot think of a more reasonable solution here.
3. The Poor Man’s Solution
Personally I would love to see TrueCrypt implementing TPM-based trusted boot for its loader, but, well, what can I do? Keep bothering TrueCrypt developers with Evil Maid attacks and hope they will eventually consider implementing TPM support...
So, in the meantime we have come up with a temporary poor man’s solution that we use at our lab. We call it Disk Hasher. It’s a bootable Linux-based USB stick that can be configured in quite a flexible way to calculate hashes of selected disk sectors and partitions. The correct hashes are stored also on the stick (of course everything is encrypted with a custom laptop-specific passphrase). We use this stick to verify the unencrypted portions of our laptops (typically the first 63 sectors of sda, and also the whole /boot partition in case of Linux-based laptops where we use LUKS/dm-crypt).
Of course there are many problems with such a solution. E.g. somebody who can get access to my Disk Hasher USB (e.g. when I’m in a swimming pool), can infect it in such a way that it would report correct hashes, even though the disk of my laptop would be “evilmaided”...
Another problem with Disk Hasher solution is that it only looks at the disk, but cannot validate e.g. the BIOS. So if the attacker found a way to bypass the BIOS reflashing protection on my laptop, then he or she can install a rootkit there that would sniff my passphrase or the decryption key (in case I used one time passwords).
Nevertheless, our Disk Hasher stick seems like a reasonable solution and we use it often internally at ITL to validate our laptops. In fact this is the most we can do, if we want to use TrueCrypt, PGP WDE, or LUKS/dm-crypt.
Q: Is this Evil Maid Attack some l33t new h4ck?
Nope, the concept behind the Evil Maid Attack is neither new, nor l33t in any way.
Q: So, why did you write it?
Because we believe it demonstrates an important problem, and we would like more attention to be paid in the industry to solving it.
Q: I’m using two-factor authentication, am I protected against EM?
While a two-factor authentication or one time passwords are generally a good idea (e.g. they can prevent various keylogger attacks), they alone do not provide protection from Evil Maid-like attacks, because the attacker might modify his or her sniffer to look for the final decryption key (that would be calculated after the 2-factor authentication completes).
Q: How is Evil Maid different from Stoned-Bootkit?
The Stoned Bootkit, released a few months ago by an individual describing himself as “Software Dev. Guru in Vienna”, is also claimed to be capable of "bypassing TrueCrypt", which we take to mean a capability to sniff TC's passphrases or keys. Still, the biggest difference between Stoned Bootkit and Evil Maid USB is that in case of our attack you don’t need to start the victim's OS in order to install Evil Maid, all you need to do is to boot from a USB stick, wait about 1 minute for the minimal Linux to start, and then press ‘E’, wait some 2 more seconds, and you’re done. With the Stoned Bootkit, according to the author’s description, you need to get admin access to the target OS in order to install it, so you either need to know the Windows admin password first, or use some exploit to get the installer executing on the target OS. Alternatively, you can install it from a bootable Windows CD, but this, according to the author, works only against unencrypted volumes, so no use in case of TrueCrypt compromise.
Q: I've disabled boot from USB in BIOS and my BIOS is password protected, am I protected against EM?
No. Taking out your HDD, hooking it up to a USB enclosure case and later installing it back to your laptop increases the attack time by some 5-15 minutes at most. A maid has to carry her own laptop to do this though.
Q: What about using a HDD with built-in hardware-based encryption?
We haven’t tested such encryption systems, so we don’t know. There are many open questions here: how is the passphrase obtained from the user? Using software stored on the disk or in the BIOS? If on the disk, is this portion of disk made read-only? If so, does it mean it is non-updatable? Even if it is truly read-only, if the attacker can reflash the BIOS, then he or she can install a passphrase sniffer there in the BIOS. Of course that would make the attack non-trivial and much more expensive than the original Evil Maid USB we presented here.
Q: Which TrueCrypt versions are supported by the current Evil Maid USB?
We have tested our Evil Maid USB against TrueCrypt versions 6.0a - 6.2a (the latest version currently available). Of course, if the “shape” of the TrueCrypt loader changed dramatically in the future, then Evil Maid USB would require updating.
Q: Why did you choose TrueCrypt and not some other product?
Because we believe TrueCrypt is a great product, we use it often in our lab, and we would love to see it getting some better protection against such attacks.
Q: Why there is no TPM support in TrueCrypt?
The TrueCrypt Foundation published official generalized response to TPM-related feature requests here.
Thanks to the email@example.com for all the polemics we had which allowed me to better gather my thoughts on the topic. The same thanks to Alex and Rafal, for all the polemics I have had with them (it's customary for ITL to spend a lot of time finding bugs in each other's reasoning).
Great proof Joanna! I throw my vote in for TC to get TPM capability soon!
Do you ever sleep? I love your research and you poke in all of the deep dark corners bringing to light all kinds of evilness.... how can you sleep knowing that this is all out there???
keep up the good work... hopefully others (including me) can learn something from it.
Nice work, Joanna! I'm sure that maids everywhere are preparing their USB drives as we speak. :)
Maybe this tool will give TrueCrypt further incentive to implement TPM support.
Very interesting post. I never really thought about this aspect of attack against full disk encryption, but it makes sense. Would it also follow then that a modification of the Evil Maid Infecter could install a backdoor password into the TC loader that records the password and enters it whenever said backdoor password is entered? It seems for non-laptop toting Evil Maids that this would be an easier approach than merely displaying a password that for a reasonably paranoid person would be unreasonably long.
I agree that developers of TrueCrypt is not responsible for user's password security.
In fact, I think, it doesn't matter how maid will get passphrase - buy keylogging or buy reading it on a shit of paper attached to laptop :)
Thanks for the interesting reading.
it's a problem of trust.
Don't trust the user until they enter a pass phrase, so hackers log the pass phrase, using whatever tech knowledge. Then the hackers are trusted.
Zimmerman showed the way, always require a 2 key approach.
Don't trust the user ever, make the authentication process hardware to hardware over a quantum entanglement link, negating echelon.
Another poor-man's alternative would be to put the TrueCrypt loader on a bootable business-card CD, that you carry around with you in your wallet (or even on a chain on around your neck...). Might be a good idea to sign the label side in your own hand, too.
You could even take the CD into the pool :)
Oh yes, and for another level of assurance, when the OS boots up it should verify the CD to make sure it hasn't been tampered with (against a hash stored within the encrypted partition itself) before ejecting it, so that you don't forget to take it out.
Good article, but you win the award for most inappropriate/overuse of "e.g."
@Wolven: yes, it's certainly possible.
@Vladimir: the problem here is not a careless user who writes his or her password on a yellow sticker attached to the laptop! The problem here is that, with most full disk encryption programs, an average user cannot really protect his or her passphrase, even if he or she is reasonably careful. Evil Maid is not about exploiting carelessness of the user! It's about exploiting lack of integrity verification in a bootloader.
@Anonymous: As I explained it in the article the 2-way authentication would *not* prevent Evil Maid attack, as the attacker can always sniff the final key.
@caf: yes, that's another approach, still having the same problems as our Disk Hasher approach, e.g. not possible to ensure BIOS integrity.
Yes, I understand that.
I meant that TrueCrypt is not a 'complex security tool', so it's not about to secure all system from all sides.
Of course I agree that integrity checking would be a nice feature, but it's a high priority task for them.
May be someone of them will implement it at spare time on Saturday evening :)
Offtopic: did you get my letter?
in my previous post there's a typo: must be "NOT a high priority task for them"...
Q: What about using a HDD with built-in hardware-based encryption.
Some time ago I've checked this type of encryption on HPs' laptops, and changing the hdd to another laptop (hp one too, with disabled password) didn't help. It didn't rocognize the hdd at all.
Joanna, thanks for an interesting post.
Can/have you made your disk hasher available? I like that solution.
@Think Secure: that's probably something called "HDD lock". Never had a chance to study this, but apparently there is a way for the OEM to bind (pair) given HDD with a given SATA controller. Not sure how "breakable" this is, but still relaying on this means you relay on the security of your BIOS (BIOS password and reflash protection). Of course this make the Evil Maid more difficult, but still I would prefer to have a good SRTM or DRTM trusted boot instead. I just think it's harder to break that, then a BIOS ;)
Joanna, you are making my data tremble with fear with your research :(
Or they could install a camera which records you typing your password, or....
Great to see someone finally implement this and release publicly. One method I personally use with LUKS on linux is to carry my kernel on USB drive and always boot from that. It falls to other attacks such as malicious BIOS, but deals with the most common cases I'm worried about.
@sham: just carrying your kernel on a USB is not a good solution, as it doesn't prevent even the basic Evil Maid attack.
Now if the user is really smart, the important things (that may be on his or her laptop) will be encrypted again with TrueCrypt or stored offsite for access later. :) Then alll that work just went to waste!
Hello, I would like to ask you about your comment to @sham, that he's carrying kernel on USB stick.
I use it also this way, I have my ery small USB stick that I ALWAYS! take with me anywhere. On this usb stick i have linux kernel and specialy crafted initrd. On my HDD there's only dm-crypt/luks encrypted partition, no /boot partiotion etc.
Could you provide me more info why this is wrong solution?
I've always assumed that I have to prevent anyone from access to mys usb stick and I'll be safe...
Good stuff. Means what you should always remember: physical security is important.
First, with TrueCrypt you can have hidden volume inside encrypted volume. So being paranoid you could have hidden (encrypted) volume inside encrypted file-based volume on encrypted system drive. Should make life more complicated for everyone :)
Second, what do you think of generating password using scheme like [static part of password][add all digits in date+current hour]? It should beat keylogger for a moment, esp. if you replace non-static part with something more complicated (I am thinking generated one-time password).
Now if the user is really smart, the important things (that may be on his or her laptop) will be encrypted again with TrueCrypt or stored offsite for access later. :) Then alll that work just went to waste!
If that was such a great solution why would anybody need full disk encryption at all? Not to mention that the passprases/keys for your TC containers can be also sniffed by a modified Evil Maid (resident keylogger).
You cannot let any code to execute from HDD, even MBR, if you want to prevent the Evil Maid attack. So, if you use GRUB/lilo and it is installed on your /dev/sda, then no matter if it uses kernel/initrd located on some USB key -- the Evil Maid can be started from the MBR. Of course this time it would have to be a slightly more complicated keylogger rather then a simple patcher. The proper solution would be to *boot* from the USB key, i.e. have GRUB/lilo installed there. Of course there is still a problem of a potential e.g. BIOS compromise.
@anonymous-B: hidden volumes do *not* make the Evil Maid attack any more difficult. The password generation scheme you propose is nothing else like a special case (a very poor one) of one-time password scheme, and I already explained in the article why it does *not* prevent Evil Maid-like attacks.
"Not to mention that the passprases/keys for your TC containers can be also sniffed by a modified Evil Maid (resident keylogger)."
On the response to the other user, what if the user was running in a VM and using keyfiles? Would keyfiles assist at all with protecting from such or not?
This makes me miss when Trucrypt originally made it so if you modified the MBR in anyway and messed up TrueCrypt's bootloader your system would not start. At least then you would know your machine was messed with.
Does something like KeyScrambler Premium (http://www.qfxsoftware.com/index.html#premium) help with protecting from your Evil-Maid "sniffing" keystrokes? Or is it useless since your Evil-Maid has already patched the MBR? Just curious. :)
This works against Truecrypt on both 32bit and 64bit systems correct?
@Jeffrey: Nope. A VM is *not* (and cannot be with present technology) protected from a potentially compromised VMM.
@Anonymous #1: No, software-enforced MBR integrity protection would not help. Think: the Evil Maid could be implemented as e.g. Blue Pill Boot.
@Anonymous #2: No, such tricky software (gee, what people will not come up with!) will not protect you. Evil Maid can always go directly after your e.g. AES key (rather then a passphrase).
@Anonymous #3: Yes.
Data Locker looks very interesting indeed. We might consider moving our DiskHasher onto such device.
But... Hey, it has upgradeable firmware:
Now: how is the firmware update authenticated? Can the update mechanism be circumvented? Some guys did it recently with Intel vPro BIOS via BMP integer overflow ;)
Still, it looks like a very cool thing.
I suggest another poor man solution: The "immutable" MBR. This would have to be implemented in the disk firmware, which shifts the attack level to the disk firmware and it has to be immutable as well. Hm... Unfortunately this also won't protect against BIOS changes.
Thanks for sharing
@Anonymous: The "Immutable MBR" solution would not work, because all FDE loaders take more then just one sector.
Do you think it will worked against other HDD encryption solution such as Mcafee Safeboot? This seemed to be a very strong solution and often use by enterprise and maybe some government agencies.
Does it mean we need to understand the function call used by Safeboot for the passphrase during preboot in order to modify Evil Maid to hook to it?
For all who speak German: in his blog Michael Ritter came up with a rather simple interim-solution (until the stubbern TC-developers do something about it): he wrote a batch file checking the first 63 sectors of the boot drive for manipulation at every logon. If you see a manipulation, re-write the bootloader, re-encrypt your drive (new master key) and Bob's your uncle. I like it!
As of "poor man's solutions" section you've mentioned protecting BIOS and in comments I see points to password protected (read locked) hard disks.
Locking HDD with password will prevent plug-it-in-another-system case. I've previously played with this protection and there`s really no easy software based way to bypass it. Considering you have enough time, changing HDD chipset board with an unlocked (& same brand/model) one is a solution but it`s not always possible in hotel situations & also not working for all brands.
@Vincent: unless McAffe uses some hardware-based supported integrity checking technology, e.g. TPM-supported trusted boot, then it is vulnerable. We don't necessarily need to understand the FDE's loader code in order to implement Evil Maid-like sniffer. Instead, we can implemented the sniffer as a resident keylogger, e.g. using interrupt hooking, or in a more modern way, using Blue Pill Boot approach.
@Hamid: keep in mind that BIOSes have long history of "admin" or "support" password backdoors... Relaying on BIOS to secure your laptop is a bit of a stretch to me...
I think this (http://www.digisafe.com/products/products_DiskCryptMobile.htm)maybe a better product as compared to Datalocker.
DiskCrypt store its keys in the smartcard instead of in the device itself such as Datalocker.
@Vincent: Digisafe looks interesting indeed.
@Think Secure & @Joanna,
"HDD Lock" or simply ATA Password is very easy crackable on 97% of HDDs. The mechanism of this in laptops is that BIOS stores a correct ATA password for a given HDD. When you swap disks, BIOS-stored password and HDD password will not match. Some RAID controllers will also setup vendor-default password on any connected HDD.
You can use ATA terminal to exploit flaws in HDDs firmware and recover the password. On some HDDs you can use standard 0x20/0x21 ATA commands, but you have to send special 'unlocking' command first (for example, 57 44 43 00 00 a0 8a). So - don't think ATA password is some kind of security. It's an ilusion of security.
Run TrueCrypt on the backend server and then RDP into it. It will foil Joanna's attack, unless the hotel maid can sneak into the data center server. In our POC of deploying TrueCrypt on Microsoft Presentation Virtualization (Present-V), the keyfile is stored in the user smart token (in user's possession) while the process is always on 24x7 at the backend terminal server (i.e no boot-up process).
See my blog: http://networkerslog.blogspot.com/2009/10/truecrypt-on-present-v.html
@Samyee: Your setup would not prevent compromise of the laptop (think e.g. Blue Pill Boot, instead of simple Evil Maid). This means the Maid can still infect your laptop and get access to any resource you will be accessing from your compromised laptop, no matter what authentication is used between the laptop and the other resource.
There is something similar to attack Sophos' Utimaco, you can read the paper here: http://www.mentat-solutions.com/whitepapers/57-utimacosafeguardeasy45xuserpasswordlogging
If I have enabled 2-factor using smartcard with TC, does that make it safer since the evil maid need my smartcard to unlock my encrypted HDD?
I don't get what all the fuss is about.
The maid could just replace your computer with an identical-looking model (or swap drives, or set the bios to netboot, or whatever) that had a bogus password entry program.
@Vincent: Ignoring for the while the fact that TC doesn't support smart cards, or even keyfiles, for system disk encryption, still the problem with using a smartcard is that in most cases the decryption will be carried by the CPU and not by the smarcard for the performance reasons. Evil Maid can always catch the key if it gets to system DRAM.
@Anonymous-smartass: the big deal here is about how cheap, fast, and simple this attack is.
Great article! There are however two counter-measures that I don't see mentioned that are quite simple, yet effective:
1. Install Windows on a SATA-stick, e.g. from OCZ, and always keep it in personal custody (except perhaps while in the pool). Only use the built-in HDD as a volume-encrypted secondary drive, if at all.
2. Store the laptop in a sealed envelope when left unattended, e.g. in a hotel room. Easy to use sealings are available in many qualities, e.g. postal security tape, depending on your level of paranoia.
In addition, of course also use the onboard TPM with all static measurements, enable BIOS admin & boot passwords, HDD ATA passwords (on secondary drives), etc, and never leave the computer unattended with Windows still in RAM.
@Anonymous: unfortunately things like swimming pool activities, which might seem strange to many computer geeks, are examples of things that normal people actually do, and cannot be simply ignored. Plus this doesn't protect you against BIOS/firmware compromise.
Good point about the sealed envelope though, it seems certainly better then carrying a strongbox. Although, personally, I still believe it is more difficult to break TPM, then it is to open a sealed envelope in a clear way (any "research" done in this area?).
FYI, the fake Bitlocker prompt has been implemented by my colleagues, see their paper if you're interested.
See you in Hamburg next week.
@Joanna "it is more difficult to break TPM, then it is to open a sealed envelope in a clear way"
There is a very long history/study of breaking sealed envelopes; for example water vapor led to special glues and heat-sensitive ink...and so on. The problem for envelopes becomes control strength is inversely related to the number of times you can use one so you then must carefully maintain an inventory.
A general note to the last 30 or so people whose comments were rejected by the cruel moderator: RTFA (and other comments too), before posting. Also, keep in mind it's a technically-oriented blog, and let's keep it that way.
I also expect the Evil Maid to copy the whole HDD when s/he infects the bootloader. That way she only needs to retrieve the password from the machine, not the whole HDD. This could be done via wifi, bluetooth, etc.
Joanna, another user asked this, but I didn't see a reply:
Any chance of getting Disk Hasher from you folks?
@Anonymous: right now we're not planning on making our DiskHasher freely available.
I know this may be a little moot, but much along the lines of the USB Hasher, I've used the USB Bootloader (a Linux formatted USB stick) with a copy of the TC Recovery ISO boot image installed on it. Once I have suggessfully built that, I remove the TC bootloader from my laptop (thus replacing the TC BL with the original MBR), which BTW, you then have to reinsert the header data back onto the volume (which you do all of this with the rescue CD), and voila, you have a laptop with a non-booting HD, no TC bootloader, and a USB stick that you keep with you at all times for security. Yes, yes, I know, it follows the same risks as having the Hasher key stolen, so I also have a toughbook with a quickrelease HD.. :-)
Like @Sham and @Anonymous-MK, I too have started booting from a USB key containing my kernel. In fact, I have no MBR or LUKS header on my internal HDD at all, just encrypted data. Click my name for details.
The other nice thing this gives you is plausible deniability that there's even encrypted data present. Of course, if someone looks at the drive, you'll have to re-encrypt to prevent them from detecting only certain sectors have changed...
Previously, I was hashing my /boot partition once I was booted, but that would have only detected tampering after the fact. I like your pre-boot method better, but if I'm going to boot off of USB, I might as well boot right into my OS.
Brilliant proof of inherent insecurity - the TrueCrypt guy's answers were somewhat doofish though - if I have to carry a strongbox around with me, why pay for his product?
The point of using an encrypted disk of course is to prevent infiltration - if it's just a minor inconvenience it might block a petty thief (so would the strongbox) but clearly an orchestrated effort yields results - and if you've got something valuable enough on your notebook, someone will orchestrate an attempt - although, with cheap teraflop parallel GPUs, evolving quantum algorithms, etc. if it's really valuable enough someone might put together enough horsepower to brute force and render the encryption on your disk meaningless anyway (with or without skimming your passphrase).
Post a Comment