Disk Encryption Tests On Fedora 21

[Kano]

There are several ways to protect a system:

a) firmware password - could only get rid by replacing the chip or spi flash (desktop systems in a 2nd visit: easy, laptops: very time consuming), often simpler: usb adapter for hdd. for extreme good hackers: modifiy uefi...

b) hdd password - if the implemention is right pretty save, maybe attackable in case of suspend as the firmware needs to be able to send it back to drive. very fast way to secure self encrypting ssds

c) hdd encryption, this can be done the "normal" way with uncrypted boot or with just grub unencrypted, like:

http://kanotix.com/files/fix/crypto/lvm/crypto-install-lvm.txt

if you don't store the key onto the encrypted drive you have to enter it twice, but the most secure way. with uefi you need an extra boot partition or you use a small bootloader like gummiboot and store the linux kernel+initrd on the efi partition. would be as insecure as a normal boot partition because you can modify the initrd and place your own code in it. if you are able to replace the cryptsetup file you can do anything you want later like send the pw to you or store it in the boot partition. basically you could add a check script that validates the kernel+initrd after boot to show if the system got compromised. I saw example codes for that, better don't follow those instructions and be creative, but then you should exchange the pw really fast and reinstall, you lost if somebody is waiting outside for this to happen.

Btw. don't forget you can modify keyboards, record wireless keyboard data and lots of other things...

[ChrisIrwin]

The point is, of course, that you gain no security by encrypting things that are absolutely freely available, like all the things in /lib[64] or /usr. Such things tend to include all the programs you run, that can take a significant bit of I/O to load up.

True, there's no added security for encrypting the OS itself. But I think simplicity of having only one LVM PV (not to mention the benefit if you ever need to resize anything) outweighs the disadvantages of having / encrypted.

Anecdotal evidence (so yeah, feel free to disregard), but I've never had concern about IO on my encrypted system (everything but /boot). Granted, I do have my OS and /home on an SSD. I've been running this way for years, both with and without Intel AES. Performance didn't seem to be effected enough for me to be bothered to compare.

[curaga]

For instance, full disk encryption will not protect against "Evil Maid" style attacks, where the attacker installs a rigged initramfs which exposes the secret key/passphrase to him.

It's not "full disk" if /boot is unencrypted :P

(why not boot from a specifically prepared USB drive that you always carry with yourself, that refuses to work in other computers, and won't do anything unless given the proper passcodes?)

[Kano]

You can just carry around a grub stick/disk which you can always recreate if lost if you encrypt /boot too. If you need to recreate /boot you need the kernel - if it is not available anymore you have to install a new kernel. You definitely need to chroot to the rootfs if you want to be able to boot again in case you lose your /boot key.

[pal666]

when did this site become a fedora marketing front ?

it's linux news site and in this universe all linux news are coming from fedora

[duby229]

it's linux news site and in this universe all linux news are coming from fedora

Really? I thought it has been nice to hear about stuff other than Ubuntu and Canonical news.

[Luke]

Limitations of /boot on flash, other vectors of attack

It's not "full disk" if /boot is unencrypted :P

(why not boot from a specifically prepared USB drive that you always carry with yourself, that refuses to work in other computers, and won't do anything unless given the proper passcodes?)

This approach works, but quickly gets hard to manage if you are dealing with multiple encrypted systems. I've done it myself during high-security events but I now consider hardware keyloggers the bigger threat. I do use a hash check to post-boot verify my /boot partition, changing the hash program via an evil maid's init could prevent decryption and give away the game. This CAN be beat, but doing so becomes a complex attack fast. It's not enough to stop the Evil Maid attack, as it has shaken out to be the least likely attack you will face.

There are seven major ways to get the passphrase that I have studied and some minor ones. Not one of these is available to the crackhead who steals your laptop from your car, and most of them are not available to a cow town police department either:

1: The dictionary attack. This is what you do when you capture an opponent's encrypted system cold and without prior knowledge. Will open almost all disks encrypted with the sort of "passwords" people normally use on office and home computer logins. Always try Admin, Default, God, the user's name, and 123456 first if doing this by hand, otherwise any computer can try every word in the dictionary in seconds. This attack can take months or years if a string of words not making a sentence found in any book is used, and is defeated utterly by random character passphrases.

2: The Cold Boot and Fireware attacks against an encrypted system captured while in operation. Encryption is of little value on systems that must run unattended. A custom forensic live disk can be used for a sudden reboot, sometimes after cooling the RAM modules with a Freon type substance. The key remains valid in RAM a few minutes and can be copied. Defense is to keep systems turned off when not in use, and pull the plug/battery if attacked while using the machine. Microsoft's sells forensic tools to cops to allow extracting keys from running Bitlocker encrypted systems without rebooting, and without being dependent on Firewire, which also allows extracting arbitrary data from RAM while running.

3: "Rubber hose decryption": get it out of the target with torture or legal threats. Does not work when the legal consequences of decryption exceed the penalty for defying the key disclosure law, or "stop snitching" ethics apply.

4: Point a camera at the keyboard. This requires guessing where the keyboard will be, the camera needs to be almost directly above the keyboard. This seem,s like a big library/coffeehouse threat, but according to my tests is mostly a danger where cameras covertly installed to watch a fixed location workstation are a threat. I tested this with a camera on a tripod and a dummy passphrase. If the camera was elevated but off to one side to match the viewing angles of common public space security cameras, half the passphrase characters were blocked by my arms and hands, Camera behind is blocked by the users's back or head, unless the screen is so shiny as to permit reading reflections. Camera in front is blocked by the screen. Never sit directly under a security camera, it's the only way they are going to read most or all of what you type. If it really counts, you can always boot in the toilet, nobody will admit to a camera there.

5: The MSS favorite and probably NSA favorite too: a hardware keylogger in the conection between the keyboard and computer, or a special cable retrofitted to a desktop keyboard. Like I said, the MSS (China) has been directly caught doing this, and the NSA is known to stock a chip that can be added to common keyboard cables by taking the keyboard apart and adding it there. Glue these together or use odd models they can't replace with a lookalike. Yes, I've had keyboards apart for work and for inspection. Intercepting wireless keyboard signals is a related form of attack and is a near-distance remote attack at that.

6: The evil maid software keylogger. This is really easy against Truecrypt but get complex fast on Linux systems where you cannot guess the kernel or initramfs format in advance. I could write code to do this on my own system in seconds, but on a random system I would be in that room an hour doing custom work, not booting from a simple prefabbed flash drive OS and clicking an "install" button. For Linux users, this is more of an "evil cook" than an "evil maid" style attack. Known to have been deployed in hacker's dorm rooms against other hackers, not seen in the wild by any security researcher willing to admit it.

7: The "evil cook" attack itself. This is to replace the BIOS with one containing a keylogger. Even more complex than evil maid against a random system, but well suited to use against mulitple similar machines known about in advance. The NSA is known to intercept shipments of computers going to high value targets like the Chinese military for custom BIOS work. Fears of factory-installed keyloggers were why the Guardian journalists handling the Snowden take handled the encrypted stuff on a non-networked machine that had never been networked and no doubt never activated Windows, etc. Surely this machine was bought randomly with cash, making it impossible to predict which machine they would get, and with no network no way to turn on a keylogger after the fact. If ALL machines phoned home, every Wireshark user would see it.

[halo9en]

Why not simply encrypt home (that's where settings, cache, etc. are) with ecryptfs and mount var on tmpfs, and of course enable the ssd/hdd password? That's what I do, much less performance impact than full-disk encryption.

[chithanh]

The reason for encrypted everything is mostly to prevent files in places like /var/tmp from being recoverable, and prevent system logs from identifying your peripherals used.

If you store secrets outside home (like some of your programs writing to /tmp or /var/tmp, password hashes in /etc/shadow or whatever) then of course those need to be encrypted too. At some point it may become easier to just use full disk encryption, I agree. But for "normal" users who just want to keep their files secret and do not run any special software? No.

The "evil maid" software keylogger has not been reported in the wild, probably has only been used in hacker's dorm rooms. That's because to really do a premade evil maid USB drive that a non-hacker can use, you have to know in advance what encryption system (DM-crypt vs Truecrypt, etc) and what OS you are attacking.

It's pretty easy to have one "Evil Maid" attack prepared for most standard distros. Also you don't need to log everything, just modify the initramfs to exfiltrate the key or passphrase once the user has entered it.

Unfortunately, there is nothing that Fedora can do to prevent evil maid attacks. If that is a serious concern, you're not basing decisions on by reading benchmarks, or trusting the "encrypt my disk" checkbox in an installer. You've done serious homework, and assembled your own hardened system. You're also probably not even running on commodity hardware with expresscard, firewire, thunderbolt, etc. You're well outside the target audience for install-time encryption via checkbox.

I don't say that Fedora needs to prevent "Evil Maid" attacks. It is just the uninformed blanket recommendation to turn on full disk encryption in the Phoronix article that I am complaining about.

Fedora actually encrypts an entire lvm pv, then makes volumes for /, /home, /whatever volumes together. Not encrypting your root would actually be more effort and less flexible.

Ubuntu uses eCryptFS for that purpose which encrypts the user's /home directory. I'd say that eCryptFS is actually easier and more flexible, plus it doesn't have the disadvantage of encrypting stuff that needs no encryption. And it protects against pretty much the same threats as Fedora's implementation of full disk encryption.

It's not "full disk" if /boot is unencrypted :P

(why not boot from a specifically prepared USB drive that you always carry with yourself, that refuses to work in other computers, and won't do anything unless given the proper passcodes?)

Booting from USB does not actually increase your security. Why? Because the evil maid can simply turn off USB boot and run her malicious code from the local disk, then afterwards invoke whatever you have on the USB key.

Also the threat of low-level attacks on EFI or Intel AMT/MEI is quite real.

You may want to have a look at Patrick Stewin's 30C3 talk on how to implement a DMA based keylogger in Intel AMT. You know, that secondary processor in all modern Intel systems which has its own operating system and has read/write access to arbitrary memory regions.
Or 31C3's talk by Rafal Wojtczuk and Corey Kallenberg on how to use SMP race conditions in order to defeat protection mechanisms against overwriting your UEFI flash.
Oh by the way, does your computer have Thunderbolt? Then every time it boots, it will unconditionally load and execute a piece of code in a so-called PCI Option ROM from every connected Thunderbolt device. Trammell Hudson talked about this on 31C3 too.

All talks have a recording that can be watched here: http://media.ccc.de/browse/congress/

[Luke]

A "stadard distro" Evil Maid is easily countered

It's pretty easy to have one "Evil Maid" attack prepared for most standard distros. Also you don't need to log everything, just modify the initramfs to exfiltrate the key or passphrase once the user has entered it.

If the only "Evil Maid" attack that was a fast-acting danger was a standard one for common distros, defeating it would be as simple as having your own disk decryption script that runs first or creates visible errors if installed alongside cryptsetup, and with differences in the prompt that would reveal a replaced initramfs. ANY software keylogger can be detected by hash checking all of /boot, countering is possible but complicates the attack beyond the range of a simple standard script. Still, there are so many other and more common attacks that this is false security unless you face an adversary known to favor the evil main and use non-hackers to deploy it.

This kind of hacking is like Judo or MMA, there is a counter for every move and a counter to the counter as well. The best way to secure an encrypted machine against boot-time passphrase logging is to maintain control of the space it is in. Let's go back to that corporate traveller in China and the hotel room: keeping that laptop in a bag he always carries makes covert physical access by the MSS totally impossible.

Here in the US, the place a social actvist would most likely encounter an evil maid, a BIOS keylogger, or a hardware keylogger in a laptop/tablet would be in a device returned by police after an arrest or raid. I would treat such electronics as presumed malicious and not permit them in my house. If you know an opponent has had an opportunity to interact with an encrypted system, you must never boot it again, at least not with any form of encryption or sensitive information. Neutral-site forensic analysis, on the other hand, could provide valuble insight into your opponent's hacking tactics. Perhaps social activists should allow police to capture some old junk so the FBI's perferred attacks can be captured and published? The MSS could be targetted the same way, with laptops left temptingly on hotel room tables that are used only as honeypots.