Schneier on Security
A blog covering security and security technology.
« James Bamford on the NSA |
| Friday Squid Blogging: Draw-a-Squid Contest »
October 23, 2009
"Evil Maid" Attacks on Encrypted Hard Drives
Earlier this month, Joanna Rutkowska implemented the "evil maid" attack against TrueCrypt. The same kind of attack should work against any whole-disk encryption, including PGP Disk and BitLocker. Basically, the attack works like this:
Step 1: Attacker gains access to your shut-down computer and boots it from a separate volume. The attacker writes a hacked bootloader onto your system, then shuts it down.
Step 2: You boot your computer using the attacker's hacked bootloader, entering your encryption key. Once the disk is unlocked, the hacked bootloader does its mischief. It might install malware to capture the key and send it over the Internet somewhere, or store it in some location on the disk to be retrieved later, or whatever.
You can see why it's called the "evil maid" attack; a likely scenario is that you leave your encrypted computer in your hotel room when you go out to dinner, and the maid sneaks in and installs the hacked bootloader. The same maid could even sneak back the next night and erase any traces of her actions.
This attack exploits the same basic vulnerability as the "Cold Boot" attack from last year, and the "Stoned Boot" attack from earlier this year, and there's no real defense to this sort of thing. As soon as you give up physical control of your computer, all bets are off.
Similar hardware-based attacks were among the main reasons why Symantec’s CTO Mark Bregman was recently advised by "three-letter agencies in the US Government" to use separate laptop and mobile device when traveling to China, citing potential hardware-based compromise.
PGP sums it up in their blog.
No security product on the market today can protect you if the underlying computer has been compromised by malware with root level administrative privileges. That said, there exists well-understood common sense defenses against "Cold Boot," "Stoned Boot" "Evil Maid," and many other attacks yet to be named and publicized.
The defenses are basically two-factor authentication: a token you don't leave in your hotel room for the maid to find and use. The maid could still corrupt the machine, but it's more work than just storing the password for later use. Putting your data on a thumb drive and taking it with you doesn't work; when you return you're plugging your thumb into a corrupted machine.
The real defense here is trusted boot, something Trusted Computing is supposed to enable. But Trusted Computing has its own problems, which is why we haven't seen anything out of Microsoft in the seven-plus years they have been working on it (I wrote this in 2002 about what they then called Palladium).
In the meantime, people who encrypt their hard drives, or partitions on their hard drives, have to realize that the encryption gives them less protection than they probably believe. It protects against someone confiscating or stealing their computer and then trying to get at the data. It does not protect against an attacker who has access to your computer over a period of time during which you use it, too.
EDITED TO ADD (10/23): A few readers have pointed out that BitLocker, the one thing that has come out of Microsoft's Trusted Computing initiative in the seven-plus years they've been working on it, can prevent these sorts of attacks if the computer has a TPM module, version 1.2 or later, on the motherboard. (Note: Not all computers do.) I actually knew that; I just didn't remember it.
EDITED TO ADD (11/12): Peter Kleissner's Stoned Boot attacks on TrueCrypt.
EDITED TO ADD (12/9): A similar attack is possible against BitLocker with a TPM.
Posted on October 23, 2009 at 6:43 AM
• 180 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
The bootloader could also grab the code from the USB token and the password.
Defense: boot from USB drive and hash the bootloader to make sure it hasn't changed.
Other 'hotel room attacks': hidden camera to capture your password; sound recorder to capture your typing and determine password; once the password is determined, steal the computer.
Stoned boot DIDN'T work that way... (at first)... See slide 25 in: http://www.stoned-vienna.com/downloads/...
Stoned was loaded with a running windows system, and must be done with admin level privs. It wrote to the MBR while windows was running, then lies in wait. Which begs the question... ummm so what? Why not just rootkit the pc if it's running already, I don't think a bootkit is all that impressive from that perspective. Stoned was dumb... but now has a live-CD that does the "evil-maid" attack.
Here is idea how to defeat this attack:
1) In BIOS, disable booting from local hard drive, or, even make local hard drive not bootable.
2) Use (preferably write-protected, or even read-only) USB dongle to boot up computer.
This dongle contains some minimalistic kernel with HDD encryption drivers which completely loads into RAM.
3) The kernel proceeds with loading rest of OS from HDD. At this point, USB dongle may be removed and stored in safe place.
I believe, this procedure can be implemented on Linux. At least, Cooperative Linux (www.colinux.org) boots similarly.
The core problem is that even with "full" disk encryption, a small part (i.e. the bootloader) is unencrypted (and therefore, open to manipulation).
A solution would be to have your bootloader on a thumb drive which you never leave alone.
If the thumb drive does not only contain the bootloader but also some kind of secret, you have two-factor-authentication, too.
Another solution is to have the Important Data encrypted on a hidden partition (in "unallocated" free space on the disk). Better yet, a hidden partition on a USB key or SD card. The card/key is marked "1 GB" but is really 2 GB, with only 1 GB allocated.
One countermeasure they discuss, that doesn't require TPM was (when you return to the room) boot from a USB stick that performs a hash of the bootsector, and other critical parts of the hard drive (e.g. /boot if you're running linux) against the known-good to check for modifications.
Sorry, wiredog. Once your machine is compromised, hidden partitions won't help. You'll still have to type in the password, and that's when the evil program will grab it.
My laptop of a decade ago had a BIOS password. Aside from removing the hard drive and subverting it in a separate computer, it seems a reasonable defense against the whole "boot the same computer off another volume" thing.
And if the hard drive comes out that easily, take it with you.
I understood that FDE was only supposed to be able to protect against theft of the disk outright. Is someone suggesting that it protects more than that? I mean, once you log in, you can be compromised many, many ways.
An even more evil maid will hit you over the head after you log in...
Some laptops sell with hardware protection. Before these do do *anything* after power-up you have to key in a numeric code on a small separate keypad.
I have such a laptop, and I use the feature to frustrate casual thieves in the vain hope that if everyone would use such a feature, they would seek different ware to steal. The feature is very easy to use, and the only problem I had with it was that the code I set did not use one of the four keys, which after a year clearly showed.
However it would also fully protect against evil maids, or at least require them to find a complicated workaround.
@Vasili Bourdo: Puppy Linux is similar. Has a CryptPup derivative.
@casey: LOL. BTW, Even More Evil Maid - another Eve :)
Several posts list ways of beating this one attack, but these posters are missing the bigger picture. The "Evil Maid" attack could also install a hardware keylogger between the laptop keyboard and laptop. This doesn't sound as easy, but I am not sure that installing a reliable custom boot loader is that easy either.
Whole disk encryption protects against simple attacks like theft, or a simple scan by a border agent. Even then there are limits. See the freezing ram attacks. If a dedicated attacker wants access to the data you must maintain positive physical control.
You also need to hope that your physical control is greater then your attackers physical threat. Ultimately all security boils down to who has the most guns.
Change GMT zone when boot up. Check time when power on. Make a shot from webcam when boot.
"Whole disk encryption protects against simple attacks like theft, or a simple scan by a border agent."
If a border agent feels like turning you back when you don't give up your boot password, it doesn't really gain you much.
When you install TrueCrypt, it creates a recovery disk/ISO as part of the installation process. It has an untampered-with copy of the new TrueCrypt boot sector.
If you had to leave your laptop alone somewhere and couldn't be 100% sure that it hadn't been tampered with, it would be prudent to restore the boot sector from the recovery disk first before you boot from the HDD. The recovery disk/data could be installed on a secure bootable USB key which never left your side.
Perhaps those nice people who wrote TrueCrypt could create an easy-to-use installer to make a bootable USB recovery disk.
Ideally, someone out there would invent a relatively inexpensive USB key that could be written to, then, following some software-initiated handshaking sequence (say, using some sort of AES-crypto handshaking based on the USB key's serial number) would literally destroy the write-enabling circuitry. This would/could be the USB equivalent of a closed/finalized CD-ROM - with the TrueCrypt boot sector recovery software installed.
Alternately, the USB's write circuitry could be on a breakable tab, which would be removed and destroyed once the key's contents had been finalized and tested. Yes, serial numbers of the write circuitry and the main USB circuitry would have to match.
@Vasili Bourdo, @Doug :
Countermeasures can certainly be found once a specific attack is considered. The problem is that the average user needs a procedure that :
1. Is relatively easy to setup
2. Is easy and quick to perform on a daily basis
3. Protects against a wide range of attacks
#3 is, more or less, the value of an encrypted hard drive as opposed to, say, an encrypted "My documents" (or /home/user, or whatever) folder. And Rutkowska has shown (one of) the limitations of this strategy.
So I would argue that a better solution would not be an encrypted or hash-checked boot loader; but rather an encrypted usb drive containg *everything* (the OS and the data), that the user can take with him/her.
I set up my computers at home with whole disk encryption (not because I need it, but Because It's There)
Each computer boots from a USB thumbdrive that contains the kernel and initramfs.
The hard drives are set up with a LUKS partition table. If someone tried to install a bootloader on those drives it would actually overwrite the LUKS data and destroy the encryption keys, making the data competely inaccessable.
If I maintain control of the USB sticks my PCs are not vunerable to this attack.
Inserting a hardware keylogger between the keyboard and the computer accomplishes the same thing with less fuss.
Perhaps the most important thing to note about this class of attack is that the perpetrator needs *unobserved* physical access, so he pretty much has to catch you with your guard down, e.g., at home.
I've always thought of an evil maid as the kind who would try to kick you with a poison-tipped shoe.
Installing a boot-loader doesn't quite seem to make the grade. Naughty perhaps, but not evil.
Actually Bitlocker is the only Microsoft product that does support Trusted Computing, and thus (if configured that way) will prevent exactly that attack (different bootloader = TPM won't release the Key).
And what used to be called Palladium is going much further than TPMs, it more corresponds to, for example, Intel Trusted Execution Technology.
@James Bond: No no no, *Naughty* maid is something TOTALLY different...
Reinforces something I've long believed that most people here already know. As usual, it was not the strength of the encryption that failed, it is the implementation that was exploited.
Isn't it fairly straightforward to have a script hash the boot partition on boot and flag changes? Sure, your password is gone but once the evil maid has had physical access she could equally likely have installed an aerial under your bed and be carrying out a TEMPEST attack from the comfort of her own home.
Many people point out specific ways of protecting your boot-loader, but they miss the bigger picture. You can for example also modify the machines BIOS or its hardware.
Without physical control _all_the_time_ you have lost the game.
When you create a TrueCrypt volume, it can optionally fingerprint the bootloader, and install an executable on the TC volume that TC will autorun when mounted, that checks the fingerprint. Since the executable and fingerprint are stored inside the TC volume, they can't be altered by this type of attack, and will detect any bootloader or partition table changes.
Sounds like a great place for a honeypot, or even putting slow-drying superglue on the keys, James. Why, I have this laptop here in the lab that will detonate unless you type in a secret key combination when you open the lid.
James, DON'T TOUCH THAT LAPT..........
The problem, therefore, that your yang sister can do this, no more.
What could help also is to leave your computer on, in screensaver lock: If some evil made rebooted your system, she won't be able to get back your locked screen, since that would require her to login; this should alarm you that someone may have touched your computer (or the power failed).
i suggest using the ATA Security Extension to avoid the easy access to the hard drive. i know it has been broken more or less for most hard drives, but still it offers some more hurdles.
Not to dispute the validity of this attack ... but are people really leaving laptops in hotel rooms? Whether or not I need mine, I don't leave it in a hotel room out in the open. I have left it in the safe, if the safe is big enough. But if I carried that type of dangerous material, encrypted or not, I might not do that either. Common sense still must prevail!
The first and most obvious question is,
1) Why have a hard disk?
Then if you have a sufficiently good reason the next question should be,
2) Why should I boot from it?
Providing you don't need to and there are plenty of ways to quite easily avoid it then you can "fully encrypt it" ie all sectors of all tracks without exception.
This leaves you with the next problem of the flash BIOS. There are ways around this. The first and least practical is to replace the flash chips with pin for pin compatable NV/ROM chips.
However there are other options that "sort of work",
One of which is to write a basic BIOS which only boots a USB or equivalent easily removable device that then contains a boot overlay to a striped down kernel that then checks the BIOS and other semi mutable memory in the system for modifications or changes. If no changes then carry on, any changes then clean it out and re-load the semi mutable memory from the USB device.
Lest you worry you cannot do this there are various projects underway that have done a lot of the work for you.
This leaves the semi mutable memory in the CPU for "micro code update" to deal with and this is not an area that most mortals can do much about due to "code signing" and other issues on the chip.
The easiest solution to this is use a computer with a CPU that does not have this feature.
Hardly worth mentioning. Anyone with half a braincell has figured this out, and find a way to work around it, many years ago.
I've always booted my encrypted system from a USB memory stick (contains a salt, and configures my cryptodevice on top of my harddrive), which switches root from a ramdrive to the encrypted root. No booting occurs from the harddrive. I carry the USB memory stick with me, and I store it separated from the computer whenever I can.
What's more interesting is how to defend against the Evil Cook, who installs a new bios chip.
Why doesn't the hardware dump a hashvalue of the bios code to the screen and ask "do you trust this boot code?" prior to booting? It's a simple thing to implement, and would protect against The Evil Cook attack. (As long as you memorize the hash and really check it every time).
The Sinowal Trojan is prevalent according to McAfee and rewrites the MBR to gain control of the OS. Each time you reboot, it acquires stronger control. A "maid" doesn't even have to touch your computer. It will download one of the stealthiest rootkits around and can inject itself into any running process to steal your password. Once this is done all someone has to do is snatch your machine and the data is theirs.
The TPM option is a nice option. With it you can lock access to your laptop hard drive via a password (i.e. each time your PC boots you are required to enter a password - or biometrics - before the hard drive will be accessible), only after that authentication has been granted is the hardware able to access the data portion of the hard drive.
This also holds true if you take the hard drive out and boot it as a secondary volume. You are first required to enter the password before any system can spin up and read the data on the drive.
@ Jonadab the Unsightly One,
"Inserting a hardware keylogger between the keyboard and the computer accomplishes the same thing with less fuss."
Actually there is a quite simple solution for this that works quite well...
Use one of those rather nice little RF combined keyboards and mouse pads, used for presentations.
A lot of them have the advantage that they will work in parralel with the ordinary keyboard. So you use it to enter your keys and passwords and the ordinary keypad for other activities.
It's not perfect and has some disadvantages but it fools a lot of "wanabe covert operatives" which covers most LEAs and other three letter agencies and their payroll staff (off book staff are a very different breed of animal).
Several obvious and cheap deterrents:
1) leave it turned on with a screen-lock. If anyone tampers with it, it will be obvious.
2) BIOS boot password
3) Tamper-evident seals over the hard disk to detect removal, and DVD tray, and any other bootable media to detect use. If the seals are still in place when you come back you are probably okay.
Yes, these and other countermeasures that don't involve "taking part of it with you" can be defeated by a resourceful opponent but not a run of the mill maid hired to compromise all laptops she encounters.
Personally, I like the idea of a bootloader-dongle mentioned above. It's something that can be made generic and widely and cheaply deployed. Boot with dongle, enter password, decrypt drive bootloader, continue booting. With nothing on the disk unencrypted, and the disk not natively bootable, it cuts security risks of theft or loss of 0wnership way down.
Echo'ing what Scott Lewis said, in a way.
My and my wife's laptops are locked up in our luggage if we have to leave them in a hotel room.
Granted the locks are easy to break, but that would leave physical evidence that bad things happened.
Someone would have to not only break the lock, but replace it with an identical one before compromising our laptops.
This is not a solution, mind you, just another deterrent.
"[...] we haven't seen anything out of Microsoft in the seven-plus years they have been working on it [...]"
You mean, besides BitLocker in TPM mode?
One potential way to get around that (or at least make malice seem more unlikely) is to simulate a power failure. Unplug the laptop but leave the plug lying nearby as though someone needed to use the outlet for something else (say a vacuum cleaner, in keeping with the maid theme). Do what you need to do, then leave it turned on and hope the battery drains before the target gets back.
If their computer happens to be configured to suspend or hibernate then it gets more tricky. What I've don.. err, heard of being done is placing a coat or other random things ontop of the laptop in an inconspicious fasion, then when questioned appologize and insist it must have overheated and shutdown by itself.
All of this is unlikely to work if the target has a reason to be suspicious, but generally it works pretty well against the casual but careful user.
Yes, I understand that what doing all of you, is only joke. Thank you, mr. Schneier, you do my life simplest whenever, thanks to all, who say here in English.
What about just using a lockable laptop case?
Don't put your secrets on a laptop, cellphone, pda or anything else you may be carrying around and can be left unattended or taken for "examination" by the local authorities.
vassili: That's very easy on linux -- the normal boot procedure (that not all distributions use) is to boot from a boot partition. It's normally on the same hd as your root, but that's just for ease of use.
The kernel is a mini-root system in a cpio archive plus the kernel itself -- most features in simplified form are available. That filesystem is loaded in a ramdisk. The real root system is the pivoted over that system. Afterwards, the boot partition is entirely unused. I believe I've pulled usb sticks with the boot partition out after booting with no ill effects.
I find it interesting that so many of Schneiers readers, however, find this a practical threat -- for 99% of the world, this is merely theoretical. The Evil Maid, etc, are only threats to folks who are in conflict with organizations that have specifically targeted them for data thievery, and are willing to invest some real cash and personal risk.
Very few CEOs are even in that category. It's good to be unimportant -- so much less stressful.
You forgot say "don't live"
We are all booting from an SD card we keep in our wallet next to our credit cards and then mounting the encrypted volume - aren't we?
@Jan Danielsson: ... "do you trust this boot code?" ....
display "do you trust this boot code?"
After all, *what* is computing and displaying the hash of the bios code?
Guys, these suggestions all beg the issue...the computer can no longer be trusted once it has been out of your possession. Period. No exception. You can come up with all of the USB flash-drive based "solutions" that you want, and some clever person with adequate resources will find a way to compromise the computer...
I carry a thin removable SSD, my laptop has
huge RAM, processing and programs all through VM's, communication is heavy on cultural allegory and nuance like sports.
The "evil maid" part of this is only an example. This kind of attack could easily be pulled off by family, friends, or roommates. It doesn't take national budgets and international spy plots to make something like this feasible.
@John: The hardware. I.e. a non-reprogrammable chip, soldered onto the motherboard. As long as it's the first item executing code, and as long as it's in a ROM, it's an improvement over jumping into the BIOS boot code immediately.
If someone wants to steal my data, they won't be removing soldered chips on my motherboard (there are much easier ways to get to my data, with much less risk). Replacing BIOS code, on the other hand, is trivial.
I guess it would require changing how PC's boot, but it's a very simple change.
Why not do a simple boot USB that checks the integrity of your MBR before continuing the boot process?
Please...even if you are in Linux camp, you can't omit the biggest feature of BitLocker - it works with TPM to make sure the boot path is intact. Boot path includes BIOS code, MBR, Boot sector up to the BitLocker decryptor.
So unless the maid do a X-Ray Autospy on the TPM chip to reveal/modify the private key or stored checksum inside, which I doubt can be finished in a few hours, there isn't much way to install a mal-bootloader.
Evil Cook (who changes the BIOS - no need to replace the chip) is far more dangerous - they can subvert all these fancy "boot off write-protected USB" tricks, even the "restore the boot record" tricks. The BIOS attack is almost as strong as the hardware keylogger, and harder to detect (if you know the BIOS version the person likely has, which if you know the make and brand isn't hard). If you're fancy enough, it could in theory even transmit the key over the internet/wifi/etc.
Evil cook would also of course duplicate the harddrive while they're at it, so once they have the password they don't need access again.
Evil cook could also leave it so an attacker could remotely trigger a dump, or have it notice the computer is now in a "secure" domain and grab stuff to be dumped later.
The closest we've come to "secure boot" is the XBox 360, if for no other reason than the number of resources and mindpower devoted to breaking it.
To make such attacks more difficult the BIOS should be password protected and refuse to boot from other media. The disk should be password protected and the BIOS unlocks it when booting. Microsoft do this in the XBOX 360 to prevent tampering with the disk by mounting it in another system. ATA disk passwords are described in http://en.wikipedia.org/wiki/...
Would be interesting to see if rather than a removable USB key, one could use the PIV identity or other chip card, provided of course you take it with you when you leave.
Are you really suggesting that it's a good way to keep the most sensitive information you have, your key/passphrase, more secure by *sending it over the air*?!
Yes, it stops the attack that was described, but I think the solution is worse than the problem here.
This attack does not work on a trusted boot path.
Most commercial FDE solution (eg. Utimaco, Safeboot, MS Bitlocker) support TPM and smartcard authentication.
But maybe the point of Rutkowska was to say that TrueCrypt DOES NOT support TPM, and worse explicitly disdain it as "security theatre" per they FAQ.
The method in which Truecrypt WDE works will allow a person to competely eliminate the bootloader from the HDD and use only the recovery disk to boot the system, thus eliminating this scenario and any way to even identifiy that Truecrypt is being used on the system.
"Full disk encryption" - this phrase is used often, but quite often it is used wrong way. You _can't_ just modify bootloader (MBR or whatever) of fully encrypted disk successfully because it is fully encrypted and system is booting from external media (pendrive for example - I think it's easier to keep it safe then whole laptop). None of mentioned software pieces supports out-of-the box full disk encryption with booting. It is partial disk encryption. Discussion about hardware rootkits is futile - we know that it is possible and probably always will be, so all that we can do is watch people doing this. Attack implemented by Joanna doesn't brings nothing new. That's all folks...
Even easier than the "evil maid" is the "free software CD" that you find in the parking lot or is send as a gift to your house.. (or free music, free porn, or free whatever).
Even with Trusted Boot, how does that defend against the following scenario: evil maid swaps out your computer for an identical looking one configured to ask for your password (with identical timing and UI to the way your machine asks for your password), then store it somewhere and put up a phony error message.
The trouble as I see it with Trusted Boot is it doesn't prevent what's essentially a splice attack with another untrusted machine -- Trusted Boot can make an honest machine refuse to boot when it's been tampered with, but that guarantee doesn't extend to other (dishonest) machines, and humans can't tell the difference. (Unless you do key exchange with the bootloader... something humans aren't very good at, but maybe your smartphone could do it.)
@Milo - incorrect in several cases.
@ M (aka Q ;)
"Are you really suggesting that it's a good way to keep the most sensitive information you have, your key/passphrase, more secure by *sending it over the air*?!"
If you use the right kit in the right way, yes it is more secure than using the ordinary keyboard (which does transmit plain text off it's connector cable).
Some of the new "presentation kit" uses bluetooth with encryption and the encryption in some I've looked at is fairly standard block encryption.
"What could help also is to leave your computer on, in screensaver lock"
That might solve one problem but leaves another. You can now detect evil maids but you have allowed anyone with access to your computer and a can of cold spray access to your data.
There is a large group of users that have access to my computer when I am using it: the corporate desktop support team (some located where I work, others off-shore or the outsourced group). Thus, any of these can back-door login (behind the scene support logins), do their dirty business if so inclined, and logoff without a trace (only my activity on the workstation is traced, it seems I can't be trusted).
As such, the corporate move to use full disk encryption is only there to protect the corporation from the SEC or some-such, not really to protect the data.
You keep failing to see the whole picture. The maid has full access to the room. Let's evaluate contents of room at 03 hours: computer, computer BIOS, encrypted hard drive, DRM-ladden usb key device, fingerprint reader, retina scanner, *sleeping you*. Everything needed to get the data is in there.
She can drug you, torture you, sex you up, keylog you, steal your key and computer, get your fingerprints and your eye or a scan thereof.
Accept it, perfect security is not possible. With enough motivation any method where you can still access your data at all can be broken. Period.
The more measures you take the most certain it is that the thing that's going to end up broken is you.
>Tamper-evident seals over the hard disk to detect removal
I think this is best
For those recommending a BIOS password and no booting from external devices, couldn't you simply pull the BIOS battery out and reset the BIOS password? Or are you going to check that your BIOS password is still there every time?
Just one thing to remember.
You don't need to know the key if the hard drive encryption has not been done correctly.
A simple example,
The boot code is usually always in exactly the same place on MS OS's and it realy does not change that much.
Now for simplicity assume the disk has been effectivly "stream encrypted" (or several other simple minded systems).
Your attacker simply produces a file that when XORed with the encrypted tracks from the hard drive will replace the "standard boot code" with the "maid code".
This is effectivly a modified "known plain text" attack.
Looking through the comments, there does seem to be a number of approaches to detect and/or mitigate this kind of attack. FDE in combination with one or more of these still looks pretty good.
Another measure for laptops that can help along is the ability to set a password on the hard disk. I believe it's set right in the controller. If you move the hard disk the password moves with it.
I haven't seen anything recent on how strong this is. But the analysis I'd seen some years back suggested that a *lot* more sophistication and tooling would be need for this than say resetting the bios password. Basically, AFAIK this is not an in the field attack.
Also, many laptops also have a password on the motherboard. I've been told that if you forget it you;ll need to replace the motherboard. A couple of companies I know explicitly won't use this because of the cost implications of forgetting/loosing that pw.
A better "Evil Maid" would be that it steals your keys & passwords (keylogger) and sends them over the internet when you connect. The beauty is, after it has gotten your passwords and keys, it can delete those bits of software. The boot loader is only needed to infect the computer, it too can be removed.
I think it's high time laptops start coming with tamper-evident lid locks, and not just anchors for tether cables, which protect the laptop from being taken but not from being hacked. A lid lock will deter hacking or tampering with the laptop's contents, or at least make it evident that someone did tamper with it.
Submitted by Lark Allen on October 21, 2009 - 18:42.
It's great to see self-encrypting drives gaining mindshare for the benefits that come from hardware encryption versus traditional software FDE. There are significant benefits to SED: No performance degradation; more secure; easier to use; less complex to manage; stronger compliance evidence; and more.
However, our first-hand experience has shown significant enterprise adoption, and factory-installed hardware encryption has proven a strong business case, and we're seeing strong adoption in healthcare, financial, retail, government, and across industries. Every Dell machine that ships with an encrypted drive (Seagate drives, as well as Samsung's new self-encrypting SSDs) includes directly integrated management software from my employer, Wave Systems, and we also provide enterprise central management solutions for SED. So we hear the success stories directly from the end users -- and factory integrated encryption may be an even better solution for the enterprise than for consumers, as both types of user simply want to ‘set it and forget it’ to let their computers manage the encryption.
BTW, self-encrypting drives are immuned to the much publicized Evil Maid USB boot attacks.
Thanks for exploring the latest innovations in hardware-based encryption.
Executive Vice President
Wave Systems Corp. (www.wave.com)
Simple and cheap - use a netbook w/full disk and keep it with you all the time. Less convenient than the USB bootloader but simpler.
Interesting, but color me skeptical.
You're respected security researcher Bruce and yet you wrote that *evil maid* (by the way it's in Jan/Joanna style to came up with stupid name for attack which already have one) will beat BitLocker. Well, that's not true as Trent stated before. BitLocker use TPM so *it will* prevent that silly attack.
I forgot to add: I know that you like to write blog posts, and you like to enlighten people with security BUT please, write about things you DO know because there is one thing worse than lack of information. Disinformation.
A simple fix for this would be to let the user be able to input a text string into the bootloader wich would let him know later on that the loader wasnt messed by someone
Excellent ideas. Alas, the users often super-glue their RF cards to the laptop case and attach their security dongles to the handle to prevent loss. All these solutions require a modicum of security awareness by the user. This is a forlorn hope in the modern, downsized, always re-organizing, and internally-competitive company.
A good solution works without any user awareness: which is what will be the case.
WTF Bruce? As Eward and Trent said, have pointed out, this is just wrong:
> The real defense here is trusted boot,
> something Trusted Computing is
> supposed to enable. But Trusted
> Computing has its own problems, which
> is why we haven't seen anything out of
> Microsoft in the seven-plus years they
> have been working on it (I wrote this in
> 2002 about what they then called
You should update your post to say that bitlocker 100% defends against this hacked bootloader attack. Maybe this is because (as your post said the other day), you're still running XP, an 8 year old operating system, despite Vista's security advances.
This attack changes nothing for my strategies, as it doesn't work against a few of my designs. For high assurance, I always recommend a read-only boot module that get's the main microkernel and drivers going, after hashing them against a built-in value. Then, those essentially boot the system with built-in code-signing. Additionally, most stuff is disabled and powered down by the BIOS until it does the security checks. This scheme defeats most physical security attacks on commodity hardware, even more on dedicated hardware, and can only fall victim to attackers that connect tools to the chips themselves for reprogramming.
Trusted boot, in general, is an issue I've been looking at for a long time. In my designs, most of the key handling, etc. happens on a dedicated coprocessor. The coprocessor is small enough to fit in pocket and be with you all the time. The bootable flash drives are as well. I would generally use a notebook that's easy to disassemble and physically verify, with tamper-evident seals. If evidence of tampering, reflash BIOS, run self-tests and load from trusted media. Restore original state, go from there. I also sometimes use the coprocessor as a firewall, etc. to provide added protection in event main system is sabotaged. That hurts flexibility though. Overall, there exist simple but time-consuming solutions that make these attacks much more difficult for assailants. If any of you are worried, I suggest you use these and other tricks to reduce the risk.
That splice attack is nice and a known weakness of trusted boot. It's easier to do when someone is accessing the machine remotely, as they can't see it. The splice attack is why I include visual inspection and tamper-evidence in my physical protection scheme.
Self-encrypting drives don't solve the general problem: they just require a different attack. Most drive encryption relies on a credential that must be obtained from the user on a system with weaker security than the HD's controller. Trusted path is the solution, but most of *those* "secure" HD's use a short PIN and nothing else. A combination of tamper-resistant hardware, PIN pad and crypto token key like NSA's IME encrypter the way to go. No commercial system comes anywhere close to that standard.
@Clive Robinson: Nice idea with the portable RF keyboard/mouse combo. Another idea is to get one of those flexible rubber USB keyboards and use that to type in the password. If you get a transparent one, it would be very difficult for an adversary to modify that transparent keyboard (e.g. inserting a hardware keylogger in it) without you noticing. Also, they are small enough that you can roll them up and put them in your pocket, always keeping them in your possession and away from attackers. Combined with the never-boot-from-hard-drive techniques described above, this would make many attacks impractical. If they need to compromise it without your knowledge for some reason (like to snoop on your future uses of that computer) then they may need to do it externally to the machine itself, with a laser aimed at a nearby window or something.
Of course, if you have adversaries who don't need to keep the compromise secret from you, then XKCD's advice about the $5 wrench attack still applies. If you secure everything else well enough, then YOU become the weakest link in the security chain, and the easiest one to attack.
Is this not what Apple's EFI etc. boot configuration prevents? I may be wrong, but as far as I know, Undercover uses this fact as part of the protection (you cannot boot an i386 OS X mac from a different volume without a password)?
There's no reason a mobile device needs to be encrypted, or to have sensitive data on it.
Sshfs and encfs gets you secure access to encrypted data in "the cloud" (which could very well be your own system).
If you can remember the password for your full disk encryption, you can remember your sshfs login and encfs password.
Take the laptop, evil maid it, freeze the chips. It contains nothing. Nor should it, if you deal with anything that justifies encryption.
With the plethora of large USB drives out there, why not avoid a disk in the PC and use the USB key? Yeah, performance, but even so, it means that your data is in your possession...and USB stuff is easier to carry than a whole computer.
(Plus it means you can boot with whatever PC is around, which is Not A Bad Thing).
Two factor doesn't really work here either.
If you can't control access to your computer (the whole computer) ... you've lost.
TPM chip + signed bootloader tied to a smartcard two factor credential would be interesting (don't lose it). .... but frankly ... you still lose if someone has physical access. You can't stop them from loading microcode. replacing the bios chip. Even _if_ microcode could not be loaded. _if_ the tpm could not be virtualized.
You have no authetication on any bus ...
You have cpus on nearly every device.
You have god knows how much device driver code no one would sanely expect to act as a security boundry.
I don't believe you could make a system from a commodity PC lacking enough features to be secure-able against this threat, but thats obvious, no?!
Do you really expect the people who wrote a fancy usb webcam driver you use to consider themselves as part of the surface of a TPM container??
Forget about tempest even...
You would need end to end encryption between each device on the bus to secure against physical access and each driver would have to be contained.
The TPM itself isn't safe against detailed extended analysis.
You want security measure would stop the evil
A safe door.
A welded locked case she can't open fast enough (for the whole thing keyboard power cable everything).
Anything else is not serious answer to this threat model.
Think about your threat. Then choose technology.
@meh1963: "With the plethora of large USB drives out there, why not avoid a disk in the PC and use the USB key? Yeah, performance, but even so, it means that your data is in your possession...and USB stuff is easier to carry than a whole computer. "
If I'm understanding this attack correctly, your method still would be vulnerable to this attack. The data and the encryption was not what was attacked, the setup of the computer was exploited. All that would happen in your instance would they would have gotten your key when you went to access the data on the USB.
I mean, there is some possible mitigation in your idea, as the data is no longer machine dependent (however, this could be considered a risk meaning they don't have to exploit any one machine, they can exploit any machine you may use to access your data). And they would still need to get your USB to get that data. But, they would have your key.
Again, I still think your idea leaves one vulnerable since it was never the encryption that was compromised.
I don't see this being a huge risk for most companies, in fact it would take quite a concerted effort to make it happen where I work. But that's why you have a security plan encompassing threats on multiple fronts. Yet you still need to strike a balance so the average user can do their job. Often times articles like this seem to not factor that in to the equation.
@Kurt S: "I don't see this being a huge risk for most companies, in fact it would take quite a concerted effort to make it happen where I work. But that's why you have a security plan encompassing threats on multiple fronts. Yet you still need to strike a balance so the average user can do their job. Often times articles like this seem to not factor that in to the equation."
Fair point. "Is risks worth the burden of protection?" is always a good question to ask.
I think the biggest threat on something like this would be an business insider. An outsider would need to jump through a few more hoops, and/or get lucky, to pull it off. But a disgruntled employee that is technically savy could pull it off.
Would this attack work on McAffee's SafeBoot?
When asked one of my insiders responded with the following:
The SafeBoot File System uses an encrypted boot sector chain to get to the MBR. If that sector chain is modified, the machine will not boot to Windows and the machine will have to be re-imaged. We’ve broken machines this way simply by altering the Windows boot partition with partition magic after SafeBoot was installed. We had to reimage the machine.
"incorrect in several cases."
@Simon: OK, so you are evil maid. you have "cold" machine before yourself. Whole storage is encrypted. it's PC (no EFI thing, just BIOS). how do you want to inject your code to MBR space without hw hacks (swapping BIOS too), or attack while system is running?
Low tech mitigation:
Slip the laptop between the mattress and the boxspring before you leave the room.
Yes, the maid could install a video camera and know that you hid it but in that case she probably has video of you typing your password anyway.
If you really care about protecting the data, take the laptop with you.
@Mace Moneta: "Take the laptop, evil maid it, freeze the chips. It contains nothing. Nor should it, if you deal with anything that justifies encryption."
Well, the machine will eventually contain the password to the sshfs+encfs. If the evil maid installs a simple keylogger, you're lost.
You don't need physical access to the *computer* to do this. Just the
physical environment of the computer.
The evil maid has an over the shoulder view of your password entry via the smoke
detector (etc). (As well as a video
of the bed, should you be worth
blackmailing and blackmailable,
as so many important folks are.)
Who is Sibel Edmonds?
With Linux, at least, it is very easy to boot up from a removeable drive media like a thumb drive.
Just for the sake of bringing Macs into the discussion (since it's centered on the PC), it should be noted that most Mac laptops (probably all, but I don't have the time to verify the claim), support SCSI/Firewire Disk Mode. Which means it can be booted into a special mode that makes it look like an HD to any computer you connect it to (via the Firewire or SCSI port, whichever the system has). Which is very handy for copying/overwriting the contents of the computers HD. It would also make installing a rootkit trivial and you don't even need to tamper with the case/boot order.
Lets not even discuss DMA over Firewire.
@Pedro: According to Apple, you can't go into Disk Mode if you have the Open Firmware password enabled. But you can take the HD out of the computer and pop it into another (which is the dark side of this attack).
"Well, the machine will eventually contain the password to the sshfs+encfs. If the evil maid installs a simple keylogger, you're lost."
Not so. Since no encryption has been used to boot the system, the boot sector hash can be authenticated against a copy stored on a web site (as others have pointed out). The environment can be safely validated, before using sshfs/encfs.
If you're concerned about a software keylogger, use a bootable thumbdrive and no HD in the machine (can't install a keylogger). If you are concerned about a hardware keylogger, use an on-screen keyboard for the password. If you're worried about mouse capture by the keylogger, use a non-qwerty input method, like dasher.
The extent of the methodology is a function of the needed level of security.
'Fair point. "Is risks worth the burden of protection?" is always a good question to ask.'
And it can be a question that is niegh on impossible to answer.
The first difficult part of the question is "risk", which is very difficult to quantify.
For instance data is it's self virtually worthless, it potentialy becomes valuble as information (data+metadata) but only if the context is known or can be reliably guessed.
The question then becomes what is the value to whom and why.
Some information even when in context has little value to some people but immense value to others and further the value has a time element as well.
Then the question becomes what is "value" it may not be possible to directly equate to dollars and cents. It might be a persons reputation or even liberty.
Then of course having got over the risk/value hurdel you then have to consider what the "burden" actually is to each player and why...
It's not a fun game getting it right and quite offten the "burden" can be minimised with a little thought and enforcable user training.
I'm off the opinion the less usable information there is out there the safer people generaly are. However the current business and political trends are to needlessly maximise access to as much information as is possible.
This is something society either has to come to terms with or force a change in practice.
One step in the right direction would be legal in that it should be possible to release information to a third party without lossing control of it.
For instance in the UK if you decide to take up private medical insurance (as the current political idiots want people to do) you actually sign away most of the rights to information about yourself and at the same time grant unrestricted access to any and all information about you the insurance industry feels might be relavent to it at any time now or in the future...
Worse this information is usually sent to an organisation in the US against EU safe harbour regulations. Where the information is then sent for processing to some organisation in Asia where there is no legal control worthy of the name on the marketing of such information.
The hidden problem with information risk assessment is time. For instance the result of a routien medical test shows you have certain relation ships in your body chemistry. The discovery of a new medical relationship could suddenly turn what was information only of value to you and your doctor to being of major value to the insurance industry.
Hardware-based keyloggers aren't foiled by BitLocker+TPM, much like a camera over you shoulder isn't.
There are lots of other tricks to get around most disk encryption without formally "breaking" it. Getting pwned by malware while you use the computer will always work. Your computer might be unlocked for the maid as long as it's in sleep mode, if that's how it's configured. In practice, badguys can probably get many folks' passwords/passphrases without any serious cracking, like if you use it on all Web sites. Two-factor authentication can mitigate the sleep mode and weak passphrase problems.
Still, disk encryption costs nothing compared to the benefits if you handle stuff like medical records or corporate secrets. It gives you peace of mind in the very common situation where a laptop is just lost and none of these other attacks apply. Not using it at all is a much worse mistake than expecting too much of it.
a simple defense, don't compromise physical access to your computer if you store your sensitive documents on it and you are in China!
Ultimately this discussion and many others on this blog boil down to only being able to obtain real security by using an external token in combination with a password, in other words the good old and proven "keep a key in your pocket" approach.
So why are we not seeing common computer hardware, net, web and storage access systems designed on this approach?
My Asus netbook bios has the boot device set as only the TrueCrypted hard drive. And it takes a password to change the bios settings and reverse that. It seems to me that makes it safe up until the point where the maid takes it apart to do something complicated.
Not perfect but I guess that's a start. Probably many laptops can be set that way. I'm surprised it is not recommended more often.
A side-comment, sparked by the Trusted Computing reference:
Perhaps Rupert Murdoch's recent comments about how intermediaries/aggregators/others in the media game should be forced to pay more to big media like News Corp, is a warning shot across various peoples' collective bows that they will start demanding TC-based DRM systems soon?
@ Tom Barry
Yep. This was the logic behind part of my scheme. A BIOS password relies on figuring out the password or a hardware attack on the machine itself. Complicates things for attacker.
Indeed. This is why my scheme uses a mobile computer, cheap netbook in this case. The guy needing privacy can use any access point or network and the computer is disposable and easily replaced if compromised.
A word of caution about BIOS passwords.
How do you think the following happens,
1, Initial load of flash by manufacturer.
2, Re-load of flash bios when it becomes corupted.
3, Re-work of motherboards for "recondition" resale.
The simple fact is that the speed of doing this and the cost of "connectig up" to the programer is unproductively expensive therefore the process has usually been designed to require the minimum of work involved.
And this means using the available "back plane" connectors and a "training sequence" to start the process.
Often it does not involve taking the casing off of the laptop/netbook/PC/etc or for that mater having it powered up in the conventional sense.
This is already known to quite a few people and it is certainly known to some of the larger criminal gangs shiping off to various countries in Africa etc.
When you remember where most of these devices are manufactured and by how few organisations it has reached the point where it is like "unlocking" a mobile phone.
Therefore it is almost certainly known to the "state employers" of business hotels "maids".
And don't forget when you visit certain countries (large ex/comunist) to get a visa you have to inform them where you are staying with documentation supplied by the hotel. And that only certain hotels and agencies can produce the paper work to "the required standard".
Therfore the government of these countries know which hotel room you are staying in, who your employer is and a heck of a load of other interesting tit-bits about you (like credit cards you have, where you live, and in the case of the US how big your mortgage is)
Oh and the same is now true for those going on business to the USA and other countries.
And it is fairly well known that various countries do "state sponsered industrial spying" to maintain a "competative advantage" for their "chosen few" companies. In fact in one particular case the head of a countries state security service actually acknowledged to camera that such behaviour was less expensive than funding R&D...
Oh one last question for you to ask your selves, "self encrypting hard drives" where do they get their "key from" and how much real entropy do you think there is in it?
I don't know the specific answer for all devices, but I do know from past experiance that most engineers software or hardware don't have the first clue about how to get "real entropy".
And I have seen to many "Magic Pixie Dust" solutions (crypto hash etc) where the real entropy is sub 2^20 to have any faith in them.
The reason for this is again manufacturing cost. Entropy takes time to accumulate and time on a high volume production line is very very very expensive.
Design engineers appear to have a blind spot about how the entropy should be obtained.
They usually make the mistake of having the actual individual product items "self produce" the entropy rather than have it "programed in" on the production line (which is actually a much beter solution when done even moderatly well).
What about hiding in the closet and jumping on the evil yelling "Schneierrrrrr" maid as she tries to do her evil ? :) :) :)
@ Nick P,
Is like saying "ATM machine" 8)
Symantic Jokes asside the NSA "Inline Media Encrypter" (KG200/201) is a fairly simple and effective device for in the NSA's own words,
"The IME protects data classified Top Secret and below. Data stored on the hard drive is considered unclassified when encrypted."
(Note "Top Secret and below" is the same rating as AES so not used for all data then ;)
However note the following caveats,
"Protects data-at-rest classified up to TS/SCI"
"Data is secure (stored encrypted) when at rest (unclassified)"
" When separated, the IME and CIK are unclassified"
(Note "at rest" realy means "powered off" not PC/laptop in standby or hiebernation. And the CIK is the equivalent of an "off line adminastrative master key" for data assurance).
And the minor problems,
"The IME provides Type 1 Encryption on a computer's Integrated Device Electronic (IDE) hard drive."
"Crypto-Ignition Key (CIK) is exclusive to the individual IME"
The "Crypto-Ignition Key" is (if I have been told correctly ;) a little different to the CIK's of old. It is a method by which the "Emergency Data Destruction without destroying equipment or losing data" is achived by "Instantaneous key zeroization" (delete the "secret" master key) can be reversed.
I'm assuming that the NSA has got the "Self-Generating Storage Key" for the "Up to 10" "Personal Identification Number (PIN)" protected "user accounts" that "can be assigned to each IME" correct (or better than average ;)
In fact the CIK is not a minor problem at all it is a major major problem. As various organisations have found "Key Managment" of device specific "master keys", is a time consuming activity fraught with complications and non obvious stumbling blocks, pot holes and vast chasms bordering on apparently bottom less pits financialy.
Oh and I think it is probably safe to assume that somewhere the NSA has the equivalent of a "master master key" or "master key list" tucked away for various "data asurance" reasons (spots tend not to change quickly on the fur of "big cats" ;)
Then there is the subtal issue of "Operating system and drive independant". What it realy means is it is "transparent" that is the computer sees it as an IDE drive and the IDE drive sees it as an IDE bus controler.
Which means that there is a known mapping of OS Components to disk blocks.
Which in a lot of similar commercial products defaults to a 1:1 mapping which means you know the coresponding "plain text" for very very large parts of the hard drive.
Does this matter, well yes and no it depends not only on the encryption algorithm used but the mode it is used in as well.
Often to maintain speed and simplicity of design the wrong mode is used irrespective of the algorithm.
Does this matter the answer is unfortunatly yes unless your system designers are aware of the issues and take appropriate steps (which I'm assuming the NSA have).
As an example I mentioned further up the blog page the dangers of "Self-Generating Storage Keys" and low entropy.
Well if you know the plaintext at one or more points on the disk and the encryption mode is linear and unrelated to the data then you can build a rainbow table quite quickly and easily for the low entropy keys.
Even if the mode is non linear (but predictable) or the IVs of data dependent modes (cipher chaining etc) are predictable then raibow table attacks will keep on working.
The issue is realy to do with two things,
1, Random access
2, Speed of access
And it is another example of where "efficiency" is the foe of "security".
And also "speed to market" and "marketing specmanship".
One (very wrong) way to get speed is to use a mode where keys can be "pre-computed" that is there is no dependency on the data being encrypted. In essence you have a "stream cipher".
In the simplest type a stream cipher simply XORs the plaintext with the key stream.
Well if you know what the plaintext is you can simply recover the key stream. Which further means you can then use the recovered key stream to encrypt your own plaintext and replace the original.
So a malware writer just needs to guess the OS and read the appropriate blocks off the drive, to recover the key stream and then encipher the malware and write it back to the disk...
Oh and if you use a "standard system" to store MD5 or other hashes of executables the malware writer can do the same trick to those so your table of MD5 hashes on the drive (without care) are kind of worthless...
So when you boot up the malware is running on your machine potentialy leaking secrets and no knowledge of the keys was required.
Could the malware get the secret keys, well that depends on the security design of the IME device. If it is very good no, if it is not so good yes through sidechannels such as timing attacks and if it is poor then probably directly.
The lower cost and more userfriendly the IME the more likely the security design is likely to be poor, and the differences between a poor design and a very good design are very subtal and both can be produced from the same functional description and be fully interoperable...
For instance for increased speed you might decide to implement AES in a "loop unrolled" fashion which can leave it vulnerable to timing attacks.
A designer with security in mind would opt for a slower non timing dependent AES implementation.
There are things which add complexity to the point where it's easier just to break the victim's legs until they squeal out the password...
Chances are your hotel maid won't pull any of those tricks unless it's _easy_. Once things get too complex you're usually dealing with some sort of agency, corporate espionage or people who'd more readily resort to rubber-hose cryptanalysis.
1. Keep your laptop in a secure case (things like a hard aluminium case with lock or cipher and a Kensington lock to tie the case down won't help you much, but it would make it kind of obvious that someone ripped out your laptop).
2. BIOS password (most laptops come with BIOS and hard disk passwords and / or fingerprint scanners). Makes it hard for the attacker to boot their own media without resetting breaking this first (it would take time and hard to hide).
3. Hash your bootloader and check it as part of a startup script. Shouldn't be too complicated, and the attacker would have a hard time writing all the code for sending the key over wireless / internet / something with just a bootloader attack.
4. Booting the TrueCrypt rescue disk first or booting the decoy operating system to check the integrity of the bootloader.
@ Mihai Criveti,
With regards your 4 points above, the first three have problems when dealing with only minorly trained "evil maids".
"1. Keep your laptop in a secure case (things like a hard aluminium case with lock or cipher and a Kensington lock to tie the case down won't help you much, but it would make it kind of obvious that someone ripped out your laptop)."
Lock picking is a fairly minor skill that most people can learn with a little practice. In general woman are actualy better at it due to smaller hands and more sensitive sense of touch.
Not that this skill is always required you would be surprised just how many "expensive" or "strong" cases have ninges where the pin can be removed without to much trouble, and most people would not think to look at them. Cheaper cases are better in this respect simply because they tend to use rivets...
Almost the first thing a covert operative does before touching anything is take digital photos so they can put things back the way they where.
I was a little bored the other day in a shop that sells laptops and accessories whilst the person who I was with chatted to the sales person about which laptop they where going to buy I noticed that they used "kensington" style four wheel combo locks on their display. I stood there with my back to it and felt the wheels into the correct combination and opened it. When the sales person started getting patronising to my friend I drew his attention to the fact it had been left unlocked, the look on his face was a picture to behold 8)
"2. BIOS password (most laptops come with BIOS and hard disk passwords and / or fingerprint scanners). Makes it hard for the attacker to boot their own media without resetting breaking this first (it would take time and hard to hide)."
As I noted above some makes and models can have their BIOS read out and reflashed without much effort.
"3. Hash your bootloader and check it as part of a startup script. Shouldn't be too complicated, and the attacker would have a hard time writing all the code for sending the key over wireless / internet / something with just a bootloader attack."
Yes get a hash of your boot loader and the critical OS files, but put them and the checking program on write protected media you carry in your wallet. The startup script on the laptop is as vulnerable as any other part of it as are any hashes you've stored on it.
With regard to the hardness of writing a bootloader to "sending the key over wireless / internet / something" you are thinking about it in the wrong way. All they realy need to do is enable a back door at the IO level to send your keystrokes out. Most of the code is already written for them either in the bios code (netboot) or OS driver code. And due to legacy issues there are ways you can get IO code past various OS startups...
This sort of information and abilities are most certainly well within the abilities of current criminal gangs who ship stolen laptops mobile phones and high end motor cars to various "no questions asked" countries in various parts of the world...
@milo - many different ways.
Unplug drive in laptop which uses Bitlocker, at SATA. Plug laptop drive into "other" machine. Spin up and rewrite MBR using other machine, for example write raw physical sectors with CreateFile (to get handle), SetFilePointer (to sector zero), then WriteFile. What you write to the MBR is intended to redirect process flow upon bootup to another area on the drive. Do you need details of latter?
Then replace connections.
Another is to swap drive so laptop starts up exactly like user expects, but it's a dummy. Password pumped out to "other" location. By the time user thinks drive is hosed, password is used at other location to start up original drive.
HW features can prevent scenarios like this, but then attack path can be different.
Do you want to do this remotely without touching the machine?
Ultimately the problem with encrypted drives of all types is that the drive can be removed to another location and there, the attackers can do anything they want and can take all the time they need and can even continue deceiving you to their ends. Worse, you will never know if they succeeded or not. Same thing with using alternative drives to boot with.
Incidentally, an attacker with access to your hardware can also install a hardware keylogger that is completely transparent to software. This device can then collect passwords at its leisure. Getting the collected data requires a second access, which can either again be physical, possibly leaving no traces and never having done anything software can detect or may require system compromise and some signaling to the device, e.g. via the keyboard LEDs.
Advanced versions may even listen to the TPM communication, which may break disk encryption based on it. After all the TPM does not do the disk crypto itself, and the session key for the disk does not change, so it is reasonable to expect it to be given to the host CPU at some time. (I may be mistaken, it has been a long time since I looked at what a TPM does.)
Of course this attack is expensive and likely requires a customized "bug". It is still feasible and cheap enough to qualify as an industrial espionage tool.
Anyways, this example serves to demonstrate that with physical access most bets are off. This is neither new nor surprising.
two factor authentication didn't help at all.
PGP Wholedisk/Truecrypt/etc. is not more secure with Smartcard than without.
Stoned bootkit with minimal enhancements could sniff the master key for HDD decryption (must be in RAM from computer). It's not nessacery to access content or PIN of the smartcard.
PS: This posting wasn't approved at pgp blog ...
A briefcase designed to resist surreptitious entry is a good supplement to whole hard drive encryption. Govements have used them to transport sensitive documents and hardware for years. Perhaps time the commercial sector pays attention?
Buy a powerful and small computer (iPhone). Always keep it with you. Buy an external LCD screen and keyboard that you can connect to your iPhone.
You may leave the external LCD screen and keyboards in your hotel room.
Never type a password on the external keyboard (use the iPhone keyboard).
what would you do if someone kidnapped you and your family and threatened to kill them while torturing you if you did not give them the password? Would you die for your encryption? This is hardly worthy of an article.
What can you do against math, and an antenna picking up the EM signal from your monitor?
The suitcase idea is pretty good, but you're still not 100% secure.
@Elijah: Simple: If your secrets are that important, some TLA (Three Letter Agency) will kill your family in an "accident", so that the situation cannot arise in the first place.
Incidentally, nobody needs 100% security. It just has to be better than the effort the attacker is willing to invest.
Clive, et al,
WRT resetting BIOS passwords.
In my experience, I have seen one laptop computer nearly-bricked because of a BIOS password. After three hours on the phone with the manufacturer's Tech Help, it was revealed that a paper-clip could be used to reset the BIOS to factory standard in 30 seconds.
That is, a knowledgeable person with a paperclip could reset the BIOS password on the laptop in a period of 30 seconds.
This particular event was in the late 1990's, and I do not know if the reset method has changed since then. (My bet is that it hasn't, for most laptops provided by big-name suppliers...paperclip-based methods are too useful to give up for such resets.)
This doesn't alter the indication to the user that something has changed (the BIOS didn't ask for its password), but it does show that BIOS passwords will not stop a knowledgeable person from booting your machine off of boot media of their choice.
Would locks on the USB or Firewire ports help?
@Guy: "Would locks on the USB or Firewire ports help?"
Based on my understanding, no.
It was never the encryption, the ports, the files, or any USB that were attacked. The computer implementation was attacked to basically log as the user typed in the encryption key/password.
The USB issue may keep them from the data, but they still have your key/password, so it depends on their goal.
theoretically there is no new thing in this paper, but practically there is one new thing. If there is no hardware key loggers
you can make a mini cd bootable like BartPE www.nu2.nu/pebuilder/
and run Encrypting Software from inside of it. so you can bypass this EvilMaidUSB Keylogger.
"the manufacturer's Tech Help, it was revealed that a paper-clip could be used to reset the BIOS to factory standard in 30 seconds... ...and I do not know if the reset method has changed since then. (My bet is that it hasn't, for most laptops provided by big-name suppliers...paperclip-based methods are too useful to give up for such resets.)"
As always yes and no.
Thr paperclip method used to be the equivalent of removing the power to the battery backed RAM.
The RAM would lose the "password" and the "checksum" of the password.
When the code runs on next reboot the contents of the password and checksum don't match the software branches to "first time" mode which is what is known as "factory reset" and writes in the blank or known password.
On some machines these days there is a second branch in the factory reset mode. If a certain "hardware signal" is applied it simply does not reset the password and checksum field and enables extended BIOS "test" features.
The reason being for the techs working on repairs etc. It leaves the user password in place (if not corupted) and alows the tech to run diagnostic tests.
Now the important thing to remember is that often the BIOS password is in "plain text" and since the early days of DOS there has been a little "com" program that will read it out and display it on the screen...
Nearly all laptops have some kind of "tech" mode in one form or another even if it is just "PXE Boot". Invariably all of these systems are designed to minimise labour costs or maximise "tech" efficiency so they tend to be quick and simple even on commercial "high security" laptops.
These "factory" and "tech" and "test" modes are a in nearly all hardware in on form or another, including "encrypting HD's".
The "secret" is often the "hardware signal". As has been seen from the mobile phone handset "unlocking" "gold boxes" these signals get out and if there is a market for a device that replicates it (and there is) then it gets made.
It is a well known problem in other areas such as Sat/Cable TV set top boxes.
The classic example being in Europe with "Sky Decoder cards". Where Sky by their own choice did not put in a sufficiently secure system at the start. This was broken, and again Sky by their own choice did not incresse the security sufficiently. Sky went through this loop something like ten times before they finally put in enough security.
The silly thing is that with Sky if they had originaly put in place the level of security they had on the fourth round then it would probably have been sufficient. However by putting in a weaker system and alowing a market place for "cracking" devices to develop they effectivly created a well funded and therefore more capable and determined set of oponents...
We are currently seeing this sort of "arms race" being repeated with the banking industry.
I for one saw the need for two way transaction authentication on "phone banking" (the forerunner of web banking) well over ten years ago and did work on solving the problem. The risks I identified where carried on into web banking, and we saw the build up of a market to exploit the weaknesses.
I liken the process to "mountin climbing". Nobody starts of being a mountin climber they have to develop their skills and get/develop support equipment which forms a "market". This only happens if there is an incentive to do so, or to put it the otherway you get an increasing reward as you move from moorland walking to hills then fells and then cliffs etc.
Sometimes you have to suffer the pain of putting in considerably more security at the start to stop a market developing in order to save yourself signifficant pain and diversion of resources at a later date...
@ Babak Memari,
"you can make a mini cd bootable like BartPE and run Encrypting Software from inside of it. so you can bypass this EvilMaidUSB Keylogger."
Sadly no it does not work with older MS OS's due to backwards compatability issues.
The original PC boot up sequence (POST) allowed hardware IO devices to install their own software into the memory and IO map of the PC. The MS OS's used to "respect" this and level the code in place. The modern equivalent of this is "plug and play" on PCI and above cards and autorun on media detection that you see with GSM etc mobile broadband dongles.
MS have claimed they have finaly fixed this in Win7 by requiring all hardware drivers to be "signed".
However "code signing" suffers from the GIGO effect even after code review. And lets face it with various DMA modes and untrusted code running on the actuall IO CPU that the MS OS cannot see it's a bit of a mute point anyway as there are not the hardware support features built in to make it work securely.
With all this talk of hardware keyloggers, I'm mystified as to why there doesn't seem to be a market for transparent laptops, keyboards and mice, so you can do a visual check for installation of keyloggers.
Nice analysis of IME. I think it came up short in two ways. First, it should support hibernation mode with little to no tweaks. This is because its transparent to OS and hibernation data would be encrypted as well. If encryption done properly, I'm not too worried about known plaintext attacks. The other beef is that my post concerned a device "like" IME: without Type 1 algorithms, master keys, etc. If NSA's IME was an RSA PKI suite, then this IME would be the first PGP. See what I'm saying?
That BIOS attacks could be performed without opening the system was new to me. I was thinking about burning those debugging ports off the board, but I'm naturally concerned about survival of board functions. My scheme included many elements and BIOS security is just an obstacle.
The real security comes from using read-only boot media, cheap (i.e. easily replaced) netbook, tamper-evident seals, and data on external encrypted media. These tools are combined with certain policies about handling the equipment. For instance, if the data is really sensitive and I'm paranoid, I might go outside to random spot and lean against a wall while keying in my password. Or I might travel with a pocket-sized PC (think Fit PC) and just leave a transparent monitor, keyboard and mouse in my hotel room. Maybe I purchase random keyboard every day (relatively cheap). I can activate the PC with a token and enter password with a portable keyboard that stays on me... outside of the hotel room... then bring it back in and connect it to untrusted components. All of this uses commodity equipment and this is anonymously purchasable in the country your traveling to. The schemes have many other possibilities and I choose the specifics based on a risk assessment and likely attack vectors. I never use the same approach twice.
@ Nick P,
Don't get me wrong I like IME's more than I like encrypting hard drives (for various reasons). But would happily use both in a "belt and braces" mode, but in either case the powersupply gets disconected before it leaves my sight.
The real problem with both of them is that they are transparent and therefor have the "keys" on them whilst still powered up after being in use, unless specific steps are taken to remove the keys...
Not having had the chance to play with the NSA IME I've had to work on what I've been told about it's use of the CIK (which may be incorect). Apparently on the old style "transmission" equipment CIK's where designed to be effectivly "pass through" and if pulled from the device it instantly stoped working.
What I have been led to belive is that in the NSA IME due to certain issues the CIK is no longer effectivly "pass through" and if the CIK is pulled the key is not instantly gone from the IME (if this matters and to what extent is unknown to the person who was telling me).
Any way back to the issue of transparancy and more general IME's and the problem of the low power quick start modes of sleep / hibernation / suspend to disk / etc
Depending on the "how" of the mode and the design of the IME, it may end up holding the key whilst in the suspended state, thus it is still transparent when the user leaves it...
Now there are issues to do with "plug-n-pray" devices and U3 USB devices on IBM style PC's and if you remember firewire on Apple kit.
When pluged in they get access to the hardware at a very low level.
One such access mechanisum is Direct Memory Access (DMA) and other Bus Mastering access. Having "signed driver" software in a traditional kernel design is not going to stop the device stomping all over memory if it feels like it, only properly designed and configured hardware can do that and only under some circumstances.
What you may have noticed on some laptops is a little flap on the underneath that hides a long multi contact connector. This "expansion connector" is supposadly for docking stations. However it is often the equivalent of a PCI or AT card slot which means that you could quite easily design a device to suspend the CPU and take over from it and with "transparent" devices like the IME or encrypting hard drives it's game over at that point if they still hold the key...
Which is why the NSA IME spec very clearly talks about "data at rest" when the "Crypto Ignition Key" is seperate from the IME as being the only secure mode.
What I do like is your "imutable boot" solution it was how it used to be in the old days of embedded systems with real ROM chips soldered into the PCB 8)
What it appears to lack from your brief overview is a side channel token system for end to end authentication and checking.
Now I'm not sure but you alude to having an IME with Public Key on it. I had thought about using "oblivious transfer" via a shared secret unique to the IME and external token then it does not matter how much "key logging" or other code is put onto the PC as the malware will learn nothing of the encryption key from watching the "key transfer" from token to IME and it cannot be used for replay attacks either.
Further if Intel or AMD provided a suitable internal encryption device to the CPU then the IME could be used as a "key translator" such that data encrypted on the HD under one key would be be decrypted and re encrypted under the CPU key. Thus only the CPU ever gets to see the plain text data to work on. This sort of behaviour should be possible as part of TPM but as always the devil is in the details.
However this would be one small part of an overall system as I have previously outligned to you what we realy need is an apropriate framework and hyporvisor system ;)
Not impossible to get around (covert channels being what they are) but not the comparative walk in the park it currently is with commodity PC hardware which is designed to be "efficient" and low cost not "secure".
Oddly I have recently been looking at the design of such a high availability system around PC104 cards in a blade type solution for a proposal and realisticaly I think it can be done without resorting to a total custom solution 8)
"This attack exploits the same basic vulnerability as the "Cold Boot" attack from last year, and the "Stoned Boot" attack from earlier this year, and there's no real defense to this sort of thing."
There is a relatively easy defense. Before decrypting your hard drive, the operating system could check to see if anything had been written since your last session. If so, the OS refrains from decrypting the drive and issues a warning. You won't know what was written, but you could take precautions such as disconnecting from a network, deactivating wireless connections, or transferring your drive to a secure computer for examination by a security expert.
@Dr. T: "Before decrypting your hard drive, the operating system could check to see if anything had been written since your last session."
And how exactly would the OS know that?
Or do you think a trojan would be honest enough to update fileaccess-timestamps?
You don't get it - if you are talking about Full Disk Encryption (real one, not parial advertised by some people as FDE) you are unable to rewrite MBR - it's encrypted too. With same effect you can try to owerwrite part of encrypted file. With proper tool (GnuPG, TrueCrypt - you name it) and strong key (yeah, you can always throw random crap there). You are unable to do that in scenario mentioned by me earlier... Using another machine is useless because you have to decrypt disk first. And to do that you must have key (assuming that you don't know any useful software bug). In real life in such disk there will be no MBR, because system isn't booting from FDE disk - it's using external media. I don't care about what you can do with bitlocker or whatever if it isn't encrypting _whole_ disk.
Yes, that is why the NSA made their IKE encrypter inline. So long as the entire drive is encrypted, which inline or onboard devices [should] do, then MBR and even hibernation & page files are indeed protected. For whole disk encryption, the attacker will hit the BIOS, use hardware attack, put in a video camera or software attack on system after its running (real easy). I still recommend whole disk because it reduces risks from laptop thefts, which are quite common.
Glad you like the immutable boot. It's my strongest defense, along with reduction of DMA devices and selecting random suppliers for a given unit. In my red-black link/voice encrypter designs, I use only serial lines to connect the device. It's fast enough for many applications, has no DMA, and has drivers for almost every real-time or secure OS out there. I wish I was more hardware inclined though so i could improve that. What else is non-DMA but faster than serial? And easy to write drivers for?
Yes, I did leave out some things like authentication. I generally have to use very different schemes for different devices. I also try to reduce the use of public-key. For instance, many encryptors use asymetric for both key exchange and to sign messages. My schemes usually create an encryption and authentication key, use asymetric for key exchange, and then use symetric for encryption and authentication. Symetric is easier to get right, is faster and this reduces hardware cost. If I use a read-only, secure ROM, I would have certain public keys hardcoded in it. These would be key-signing keys used for authentication of updates, other devices, etc. In updating, for instance, I hash the new bootable software, sign the hash, and then on boot I just rehash it as its loaded into memory, check the signature and if it matches go with it. This way, firmware never needs updating: it just loads signed code or signs code after validation, using hardcoded public keys. It's kind of a root of trust method like TPM's, but no goofy PCR's and everything happens on the processor.
As for your hypervisor, we already have those: the separation kernels, with modified scheduling algorithms. LynxSecure is a good example, as it strongly relies on Intel's hardware extensions. I think what we really need is trusted, security-oriented CPU's. We already have some, like Rockwell-Collin's AAMP7G, but they aren't cheap or civilian oriented. I would prefer a POWER-based RISC design for easier validation of microcode. As for your HA on the cards, I think LynxOS offers a really low-level HA solution at SBC board level. I'd like to hear more about your design, though, to see what makes it unique.
Is there any same attack for PGP?
Yes. The kinds of attacks that work on one disk encryption program usually work on the next. The attackers usually have to change the implementation, though. This doesn't seem to be a big deal in most cases: the old FireWire and cold boot attacks were used on TrueCrypt and PGP.
@Cassandra: Because the devices are too complicated for this check to be effective? Took my wireless mouse apart once: it's a 3-layer PCB sandwich; even if it were transparent, a device hidden between the PCBs would probably escape visual detection. This holds even stronger for the laptops, where the manufacturer tries to cram as many features as possible into the smallest space - check a netbook's disassembly instructions, even with the covers off, it's an unholy jumble of components. One small chip more or less, who'll notice?
Imho the evil maid is the one who tries to check her mail on your laptop and causes you to spend all of the time and energy restoring your trusted computing environment for nothing...
Change in the MBR (boot), If it's the only thing changed... the TrueCrypt team could make a area to define challenge questions/answers... like "How are you today?" (the user introduces the question) and the TrueCrypt would answer for example: "I'm fine, let's boot today or tomorrow?". The point is, you would define some questions and answers and the loader would give you the answers to your questions... the bad guy will not know your question/answer so you would immediately spot that it is a fake one. And stop introducing the password until you know what has happen to the computer while you were out.
Change to the bios... Gigabyte produces motherboards with dual bios... if some malware or flash operation goes wrong it can recover from the fixed one.
You can protect the bios with password.
In some bios you can disable the upgrade of the bios.
You can put special seals that you can visually inspected when you arrive to your computer... if they have been tampered... some one change something inside your computer... not good!
how can we bypass this attack?
1-should we use a Master Boot Record Checker always?
2-Should we remove the encrypted hard disk always and carry it with ourselves?
3-Should we remove the hard disk and always use an external small portable hard disk?
4-should we use DOS OS?
Reinstalling BIOS or Flashing BIOS does remove it or not?
is it possible to make a backup of MBR in a mini cd bootable like BartPE, and after first boot we can rewrite the backuped MBR on the current MBR , then on the next boot , we can run the original OS or boot from mini cd bootable like BartPE.
what is your ideas?
Please type "laptop pci keylogger" into google and browse the results.
All you have to do is to open laptop, insert this card.
Wait and get 1 minute access to laptop later to retrieve card.
I believe TPM would help here.
All the above boil down to - do not leave your computer where the maid can get it.
At the least, remove important bits of it when you go.
The exact strategy depends on what you care about. But I don't think this is a new attack. Bruces lesson is that FDE is not the protection some people seem to think that it is.
An interesting theme emerging from above though is the variety of options available to you if you do not use a proprietary OS or rely on proprietary security systems.
We have the old distinction between FDE and *whole* disk encryption - where, in the latter, there are no unencrypted parts of the media. In single disk systems, there has to be something unencrypted there or the program which authenticates you cannot run. This leads to the suggestions to take the authentication and boot system with you when you leave the computer. The maid may install a custom bootloader to your computer, but your computer is not using software on the computer to boot so it sits there and does nothing. This is part of the "do not leave the computer alone" solution.
2-factor authentication - something you know and something you have - is debated back and forth. It does not stop the attack finding out your key (what you know) but that does the attacker no good if they don't have the other token (something *you* have) ... which, for some reason is assumed to be a smartcard. It is much more general than that - eg. it could be a physical part of the computer.
But this still wanders off the main point - we are no longer relying on encryption to keep the data secure... remember the lesson?
I think really the most practical protection from this type of attack without the need for a TPM device is this except it doesn't apply to laptops:
1) Use a usb token for two-factor authentication.
2) Make BIOS pw protected and only boot from encrypted drive and nothing else.
3) Put loads of padlocks and locks on your case to prevent it from being turned on and from being opened at all and to prevent the hard drive being taken out to be put in another computer .
This wont help for a laptop but you could always put the laptop in a safe.
4) When going to use your computer instead of booting from encrypted hard drive, boot from a boot cd repair disc, like the one for pgp that lets you check and repaid the MBR if found to be corrupted.
I really dont see how someone could execute this attack if someone did this.
@ Simon Says,
"I really dont see how someone could execute this attack if someone did this."
It depends on which OS you go into from your CD...
It can be done by overwriting the flash in the BIOS or IO devices.
MS OS's for instance used to "respect" code in certain parts of the memory map reserved originaly for loadable IO drivers stored on the IO card.
The PCI spec likwise alows for IO driver software to be loaded as does the "Plug-n-Pray" system.
Also a small device conected to any of the IO devices that use DMA can load executable code into the system main memory bypassing any security.
Oh and have a look at the U3 USB spec it might make your eyes open...
@ Simon Bridge,
"... we are no longer relying on encryption to keep the data secure..."
Actualy the lesson is a little more subtal than that.
'The easiest way around security is via an "end run" around it'
For instance why add a "key logger" to someones system when a 2.4GHz low light miniture CCTV will shoulder surf almost undetectably.
Why put software on a users system when you can wake it up / boot it off of a combind Mobile broadband and memory USB key and slurp the entire HD / RAM contents out over the wirless network using an updated version ot the Coronors Toolkit.
Oh and a whole bunch of other little technical end run tricks.
Then there are the human weakneses to work with such as web browsing as well...
But hey as long as you have an umberella and a portable radio you can stop most non contact end runs.
A funny thing is that the most protected commonly used device against this kind of attack is probably the latest generation of iPhone.
It now has a very cleanly implemented secure boot. Except that finding vulnerabilities inside it is a cat and mouse game, and currently the cat is winning with yet another vulnerability found in the very latest 05.11.07 baseband code.
But Apple just has to update it, and given that the baseband is a small amount of code, they can succeed to release one without any vulnerability, hackers spent monthes thinking they might not find any inside the 05.11.07 version. And on that day you'll just have to hard reset your iPhone after the maid gives it back to you to make it secure again.
It's a plus that it's not easy to open it (but possible).
Just a thought: Wouldn't setting a BIOS level password and disabling boot from other medias like CD, USB prevent someone from planting a malware at boot (ofcourse we could still have encryption)?
Modifying MBR and DOS compatibility region is indeed a potential attack for software full disk encryption (eg using dm-crypt). Imagine that someone has physical access to your laptop (eg you left it at a friend's home for a night).
I know two workarounds for this attack.
1. Make a script to verify, during boot, that MBR + DOS compatibility region is unchanged. You can store it as a file in an encrypted partition, and do a diff.
2. Use hardware encryption (will gradually replace software full disk encryption, or so I hope)
@Piskvor - so make the PCB boards transparent as well as the case. Have a light at the bottom so new shadows are easily noticed.
Mind that a TPM does not support trusted boot, it supports only authenticated boot. A TPM does not prevent the boot process from being altered, it only prevents keys from being released after the TPM became aware of alterations. The claim that BitLocker "100% defends against this hacked bootloader attack" is therefore wrong. You can modify the bootloader of a system with BitLocker, and system will execute the manipulated code, and this may be sufficient for an attacker to get the key. Trusted computing makes such attacks slightly more difficult but does not prevent them.
evil maid can be nominated for pwnie awards...
As far as I know it's only if you encrypt the hard drive that you can become vulnerable using TrueCrypt, virtual containers are still fine though.
I definitely don't recommend using Microsoft's Bitlocker mainly because I just don't trust Microsoft... if I know them well enough then they will have created a backdoor where Law Enforcement can get hold of the encryption keys.
Computer security and crypto is really only for those with access to intelligence agencies, or serviced based "clipper chip" type security.
I fear we have lost the right to be secure in our private papers, now, everything is a negotiation. Heck, the constitution is a joke today, not even worth the amount it it can be printed on.
A new consumer ownership society is coming, for better and for worse.
Googles new efforts at trusted computing, chromium, is coming, and probably will be good enough, and might even solve "Evil Maid" attacks someday.
Custom computer work is going to become an interesting field, with little market left and incentives to specialize.
"Custom computer work is going to become an interesting field, with little market left and incentives to specialize."
Hmm not sure what you mean by "Custom computer work".
But the move to *nix and Jmee etc is most definatly on the up and up.
If you think about it a lot of mobile phones and other "gadgets" now have 32bit micros with VM hardware built in and as the price falls the old 8 and 16 bit micros are effectivly being priced out of all but mass manufacture FMCE. Which means it won't be that long before your "white goods" have more computing power than 1980's mainframes (any one remember the old Internet joke about the King and the toaster with the OO people chucked in the moat? How time makes idiots of us all ;)
An interesting turn up in the market has been work by the likes of Nokia and Google. Steve "barmy" at MS will probably get mega stress every time he sees an MS (blue or orange) worker with an iPhone. Especialy as HTC who supposadly made 80% of Windows Mobile is migrating across to Google's Android and MS's market share has declined by about the same amount as Android has picked up.
As for bespoke bussiness apps, well the one thing we can thank MS for is the Mono Culture of Business systems (and all the "security" employment that has given rise to ;). From a business prospective it has been easier and less costly to "migrate the processess" than get "best fit software" except in the likes of manufacturing and engineering and that's changing as well (LabView etc).
If you think about it there are three classess of computers "old iron" backend high end middle ware servers and clients
With hand held battery powered clients getting as powerfull as early 1990's servers and with what are effectivly "best of breed" OS's available for free with the likes of Java the future for MS is probably going to be somewhat interesting.
Simply because their strong hold has been "desktop" and that is now turning into "thin clients" in peoples pockets (remember the XP pannic with Netbooks).
MS never realy made it into the back end world their server software has never realy scaled up to "big iron" and if the world moves to "cloud and thin client 'chrome'" then MS will be left with "gamers" unless they have a radical re-think about their position. And to be honest I'm not sure Steve "barmy" is the man for that job he's got a "trench warfare" mind set where Steve Jobs and the like have a different focus
So yeah MS programers of business software might see a bleak future but simply altering their skill set is not going to kill (most of) them if they are "engineers" and not "code cutters". It depends on how well they have learnt the fundamentals (which sadly don't feature to much on a lot of higher education curicular these days).
As was said in a movie my son likes "that's evolution baby".
Unfortunately a TPM provides little protection here.
It does not prevent that the laptop boots from a manipulated boot loader. A manipulated boot-loader can ask the user for the password, PIN, or key-file on a USB-drive in order to store this secret on the hard disk or to send it to the attacker over the network, e.g.
We actually demonstrated this for BitLocker with TPM:
My idea would be (do not know if it *really* works or if it gives really more security ;) ) to have the HDD totally *bare* encrypted without any partitions, MBRs, or bootloaders -- but but from a USB-drive/key with the necessary bootloader and password (since I can boot my computer from USB-drives, SD-Cards and similar I would expect that it should be possible to boot a bootloader from one device as a simple USB-drive which starts the rest from the *original* device).
The first/last sectors of the HDD could be hashed and tested before booting if someone tried to mess around.
And when you leave your hotel room you take your usb-drive with you leaving the maids without any password knowledge and without the hardware key.
WEBMASTER: EDITED TO ADD (12/09) instead of (129)? Article is the "Evil Maid" Attacks. :)
Lots of EDITED TO ADDS on older articles. Would be nice if EDITED TO ADD had a similar list like 100 Latest Comments. It is good to see EDITED TO ADDs.
And since that I am spoiled, a wikipedia style blog for some articles/comments might be cool, but I guess wikipedia is for that.
Just ideas, although anybody can come up with ideas, secure solid implementations and rolled out products take a lot of work.
Keep up the good work/blog.
This sort of attack is why the whole prison scene in /Cryptonomicon/ is so silly. They didn't have to go to all that trouble.
Now, of course, if they had gone to all that trouble as misdirection, and had this be the real attack, that would have been sweet :)
Could Jan Steffan or Bruce Schneier answer Chuck.
In principle there is little wrong with Chucks idea, BUT the devil is in the details.
There are many CD/DVD/USB *nix distributions that will run in memory only. Nearly all with a little work can be rebuilt to have "custom software" added to them within the OS code or with much less effort store "userland" files on a USB drive.
Unix alows raw partitions (ie those without recognised file systems etc) and in theory the access can be faster (Oracle used to do this for large DBs where the 32bit file size limit caused problems).
You can effectivly (depending on which *nix) mount the raw disk as a "file" which enables you to develop your own file system and encryption etc within that "file" and access it from a "userland" program.
However the quite chalanging task of developing a userland programe to act as a file system is just the start of what you would need to do.
There are then the problems of what sort of encryption modes to use, how and how many keys/IV's/offsets, how these "keys" are stored and protected.
All of these have subtal gottchas so it is easy to make things not as secure as you would expect.
Which is why it would be best to have a look around for OpenSource solutions that have stood up to examination by others.
I don't why nobody pointed this out, but I think this sort of attack can be prevented , or at be detected in most of the situations where the user leaves his pc unattended for a short time by using hibernation instead of just shutting the pc down, if the FDE software support encryption of a hibernation file (although Truecrypt, the victim of the demonstrated attack, doesn't).
As far as I know, when pc wakes up from hibernation, you cannot boot it from another device. If the attacker decides to turn off the pc, restart it and inject the malicious code (in this case, the "Evil Maid Sniffer") into boot sector from the usb stick he brought with, not only the time of an attack gets longer, he/she must then launch the applications the user was working with and place it exactly where they were relying solely on his/her memory or the photo the attacker has taken right before the pc went to hibernation. Since humans are quite sensitive to the difference of similar (but different) images, it is pretty likely that a reasonably paranoid user would notice the difference if the window of a application is slightly out of place.
Only to make the matter worse, if the user did a fair amount of writing and has not saved it into a file (let's say he/she was using a windows notepad or a wordpad, which has no auto-saving feature) , then the attacker has to type it all over again and in this case he/she cannot rely on his/her memory unless he/she has has eidetic one.
Additional note to my comment above: when I said "he/she must then launch the applications...and place them exactly where they were" I was referring to a scenario where either the malicious code has a script to load and place them automatically after the logon to the os, or the attacker gains a remote access (if the code also has such a function) and run a script to load and place the applications (no, he/she shouldn't manually drag them onto their place unless the attacker wants the user to know that he/she is playing with your pc) , both because the attacker cannot be in front of that pc once the user comes back.
This means it's quite unlikely that this type of an attack would succeed when the pc is in hibernation because the attacker should have a complete list of installed applications (with their versions, too!) and edit the code right after the hibernation takes place for the attacker can only guess and cannot bet which app the user would leave open. Yes, the number of applications a user "usually" opens up is imited, so the attacker will probably get his/her chance if he/she stays around the user long enough(could be a couple of days up to months, depending on the attacker's luck), but again there's the position of the apps' windows which is very likely to vary everytime.
As for typing what the user wrote, I came to realize that the attacker wouldn't type it manually because if he/she took a photo, then the image file of the picture can be read by an OCR software which would then do all the typing for you. Sure, you'd have to review the output because OCR softwares are not 100% accurate (especially if the photo was a tilted/side shot (which would be, in most of the cases since the user is sitting right in front of the monitor)) , but it's much less time consuming.
Interesting to see that with physical access to a computer, the Trusted Platform Module (TPM) can also be overcome.
I find it most interesting how access is gained:
"Using off-the-shelf chemicals, Tarnovsky soaked chips in acid to dissolve their hard outer shells. Then he applied rust remover to help take off layers of mesh wiring, to expose the chips' cores. From there, he had to find the right communication channels to tap into using a very small needle.
The needle allowed him to set up a wiretap and eavesdrop on all the programming instructions as they are sent back and forth between the chip and the computer's memory.
Those instructions hold the secrets to the computer's encryption, and he didn't find them encrypted because he was physically inside the chip. "
Maybe I am missing something but if you are so worried about a keylogger getting installed why not change the boot sequence to not allow booting from USB or CD period. Then password protect the BIOS so it can't be easily changed.
That way they can't boot from the USB and install a keylogger, at least not without going through additional hoops.
Truecrypt's defense that if someone gains physical access to your computer then "all bets are off" begs the question: Why bother with encryption at all then??
Isn't that why people use such software in the first place.. To ensure no one can access sensitive information WHEN WE'RE NOT AROUND???
Does Bootkit Remover from eSage lab (http://blog.alisa.sh/2009/10/02/cleaning-mebroot-and-more/) detect the Evil Maid attack? It is capable of detecting Stoned Bootkit.
Seagate's self-encrypting hard drives protect against this attack.
This attack assumes no mechanism to ensure the integrity of the boot partition is in place. One could automate such a thing using an md5sum of the partition. You'd need to update the md5sum whenever the partition changed, of course. Basically, upon boot, maybe at init level 1, check against md5sum. This may take a while, true, but anyways, if it didn't match, it could be scripted to wipe the boot partition with zeros, then recreate, or at least warn the user.
The attack here (Evil Maid) assumes you log into the machine. If it is simply stolen without knowing the password, it won't do any good.
Granted nothing is 100% secure. If you used a fingerprint reader to grant access they could just chop off the finger you use.
What i would do is to set a bios password and set it to only boot from the hard drive.
The attacker would have to remove the bios password to change to implement this attack no? If so, then this would alert the user because he or she would not be prompt for a password upon turning on the system.
"Maybe I am missing something but if you are so worried about a keylogger getting installed why not change the boot sequence to not allow booting from USB or CD period. Then password protect the BIOS so it can't be easily changed."
Unless you required a BIOS password for power-on, someone could just swap your HD, get access to your BIOS from there, etc.
The childishly simple counter to this (with TrueCrypt especially, but it should work with anything) is to install your bootloader on a read-only media, and carry it with you at all times. TrueCrypt makes a boot CD for recovery purposes that can either boot or decrypt the system when you provide the password. Burn it onto a business-card CD, and scrub the bootloader from the hard drive. If a bootloader shows up on the hard drive, you know somebody's tampered with your machine. Otherwise, boot from the CD and you should be clean.
Yep, what the above poster said. For people who don't know how to do this I'll write out the steps.
1) Make sure your rescue disk / rescue USB (can make bootable usb with unetbootin) works
2) Boot with a Linux live CD. You may need to use sudo for the following commands depending on distribution.
3) In console, type "fdisk-l" to find what your hard disk is called
4) In console, type "dd if=/dev/zero of=/dev/sd* count=63 bs=512" where * is the hard drive letter found by "fdisk -l" -- this will overwrite the Truecrypt boot loader in the master boot record with zeros.
5) Boot from the rescue disk from now on. Inspect the MBR from time to time if you suspect anything. You can do this in linux with "dd if=/dev/sd* count=63 bs=512 | hexdump -C" (assuming you have hexdump) and if you see anything but zeros, it's been tampered with!
In theory it shouldn't matter if it has been tampered with though, as you can always just boot from the rescue disk, bypassing whatever is on the MBR. Unless I'm missing something about how this attack works.
Note there are still attacks against this such as hardware keyloggers. These may be hard to install in a laptop but on desktops they are quite easy and can be virtually impossible to detect. An adversary could for instance put one inside your keyboard, or buy an identical keyboard and alter it elsewhere to avoid risking discovery, then switch out the altered keyboard with yours when you are not home. I suppose you could install hidden cameras to watch your computer 24/7 and review the footage every time before powering on the computer, but that is not realistic for most people.
Oh, by the way, BIOS passwords are practically useless. All it takes to bypass them is to flash the BIOS by CMOS jumper or to remove the battery for a few minutes. I don't know whether laptops have the CMOS jumper but the battery method should work. Granted this adds some time to the Evil Maid attack but who is never away from their computer for more than a couple hours?
I don't know much about password cracking in a BIOS environment but there is probably some way to do this. My computer limits the BIOS password to 6 characters, so if cracking BIOS passwords is computationally similar to cracking UNIX passwords (and I'm not saying it is) it would take less than an hour on a modern computer.
I am wondering...
With encryption... is there a good way to use it that can't be hacked?
I was playing with tru-crypt & forgot a pass to a 40 G file... (LOL oh well)
I know that Bio-Metrics is not reasonable to use... & the thumb version can be fooled (as shown by the mythbusters)
Next thing that you will see in Bio-Metrics is RFID...
Ok guys so if I have all the facts right here in order to fully ensure my laptop or pc is protected I have to mark the keyboard in a unique way, i have to boot from usb and make sure they are read only, i have to have a camera watching the pc 24/7, i have to deploy the bios security options. I have to check for keyloggers, hardware and software, I have to encrypt all my data, and I have to put the pc in a walk-in safe with an armed security guard on the outside and robotic infra-red activated sensors and movement sensors on the inside and i have to do a bugscan on every room in the vicinity
before i log on
@ duncan donut
Ok guys so if I have all the facts right here in orde to fully ensure my laptop or pc is protected I have to... ...and I have to do a bugscan on every room in the vicinity before I log on
I see you are getting the hang of it, BUT that armed guard did you do a thorough background check? and how do you ensure they've not been turned? Did you check to see they are not realy the maid wearing a "rubber face mask"?
Real paranoia comes only with lots of practice ;-)
I know it's not always possible since some of us must use windows for certain tasks at work, home or for gaming but wouldn't a live cd or live usb with the disk encryption program installed on it work 100% of the time against the angry maid with the exception of the hardware logger ?
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT.