Encryption Support For EXT4

[Luke]

Running machine attacks are often on unattended machines

This is encryption though. In any case, I'm not sure why you think attacks on running computers are so rare. The FBI literally went out of their way to make sure DPR was working on his computer before they took him down (no keyloggers), and cellphones are pretty much never off these days. The usefulness of filesystem-level encryption is pretty obvious, and I'm not sure why anyone would be opposed to it. Probably because they're comparing it to full disk encryption, which isn't the correct threat model as much as local PGP file encryption is.

Forcing someone to enter a password to open a particular file isn't security just limited to one in a million threat vectors, it has applications as simple as preventing remote exploits from opening particular files (e.g. encrypt the directory on your computer where you store your banking information, so that you'd have to have it open and have your computer unpatched at the same time for a remote attacker to access it). If someone were worried about law encforcement though, this would have proved pretty damn crucial for DPR, who could have left far more of his computer encrypted if he'd had this when he was arrested.

Two points: if you have small files of such a nature t that online exfiltration is an issue (think text files containing anything from addresses to credit card numbers), it is good practice to encrypt the files with GPG and keep only the encrypted file within that larger filesystem. As for a physical attack on one of my running systems, I can pull the plug faster than any raid team could climb the stairs. The 2008 raid was timed to miss me and avoid a dangerous confrontation, thus finding that I leave all machines all the way off and unplugged when not in use. Dead cold so no "cold boot" attack. I have faced police harassment while using a laptop, first order of business was to mash the power button, followed by standing my ground and refusing to show ID (I do not carry it). In that incident, the public wifi point I had been using was shut down two days later, it was a "business improvement district" public wifi access point I had been using to post reportbacks from anticapitalist protests. I was able to finish my work as the defeated cops walked away, but the BID folks who no doubt had called them pulled the plug on public wifi on their dime afterwards.

I have given some thought to protecting an encrypted server that must be normally on, and the best I could come up with is a form of booby-trap that cuts power while forcing the raid team to delay, used in a windowless room. Simplest is any pressure plate, tripwire, or other switching device on all entry points, set up to short-circuit the UPS and the mains simultanously when activated, trippingg all the breakers. If they might cut through the wall the triggers could be in a pattern all the way around the machine. A set of photoflash bulbs could be fired as the power is cut and the room plunged into darkness. There would be momentary confusion about just what had happened, and if you build the server with DDR3 RAM, by the time they get up the nerve to go back in the room the memory contents have decayed too much to recover the key.

[tga.d]

Like the paper says, if you have an actual disk carrying sensitive information, encrypt it with DM-crypt or whatever your OS supports. If it were so easy to defeat this on a device that has been kept turned off when not physically in use (and thus under guard), the NSA and MSS would not spend so much money on custom chips to make those inline keyloggers. The FBI would not have been defeated by that corrupt banker whose drives were encrypted with Truecrypt and never cracked. The machine stolen from me in a 2008 police raid would not have defeated their forensics. The UK would not have resorted to key disclosure laws, which anti-vivisection activists have publicly defied. As Edward Snowden says, encryption works-use it.

This is encryption though. In any case, I'm not sure why you think attacks on running computers are so rare. The FBI literally went out of their way to make sure DPR was working on his computer before they took him down (no keyloggers), and cellphones are pretty much never off these days. The usefulness of filesystem-level encryption is pretty obvious, and I'm not sure why anyone would be opposed to it. Probably because they're comparing it to full disk encryption, which isn't the correct threat model as much as local PGP file encryption is.

Forcing someone to enter a password to open a particular file isn't security just limited to one in a million threat vectors, it has applications as simple as preventing remote exploits from opening particular files (e.g. encrypt the directory on your computer where you store your banking information, so that you'd have to have it open and have your computer unpatched at the same time for a remote attacker to access it). If someone were worried about law encforcement though, this would have proved pretty damn crucial for DPR, who could have left far more of his computer encrypted if he'd had this when he was arrested.

[Luke]

Full disk crypto works well for actual block devices

Also full-disk-encryption should be a last-resort method of encrypting your data.

See here: http://sockpuppet.org/blog/2014/04/3...dont-want-xts/

The more the encryption software knows what sort of data is encrypted the more safety can be guaranteed. Filesystem level encryption is a whole layer above block-layer encryption. I wish we would have this already for btrfs. It would even make a lot more practical sense there as encrypting btrfs raid systems is a bit problematic at the moment. Every single drive would have to be encrypted individually which would cause an administrative as well as a performance overhead.

I read that paper, it stated that XTS does a good job of encrypting actual block devices but should be used for nothing ELSE, for instance that a regularly modified encrypted container on Dropbox could be watched over time and data could leak that way. If you have an attacker who can examine your hard drive or SSD for changes over time, you've got bigger problems!

Now here's the kicker: an encrypted cellphone, tablet, or netbook containing a baseband radio is theoretically vulnerable to exactly this attack, but in practice the carrier would probably balk at transmitting say, a copy of a 16GB filesystem every few days when the customer has a 3GB capped plan. If you don't allow a 3G/4G radio on the same bus as your CPU, this attack isn't even a theoretical concern.

Much more likely that law enforcement malware would take the form it always has: a keylogger. This would most likely by implanted by carrier controlled parts of the device, and is why the Tor Project says only a device not containing a cellular radio can ever be considered safe.

Real world is this: if you have a device that has not been on the radar of law enforcement or some other attacker and it is suddenly stolen in a raid while turned off, they are NOT getting in unless you used a weak passphrase that a dictionary attack can break. There are no known court cases of even an "evil maid" attack being used to recover data later used in court. Even the NSA is known to prefer physical keylogger devices added to keyboard cables to the uncertainty of software based attacks.

Like the paper says, if you have an actual disk carrying sensitive information, encrypt it with DM-crypt or whatever your OS supports. If it were so easy to defeat this on a device that has been kept turned off when not physically in use (and thus under guard), the NSA and MSS would not spend so much money on custom chips to make those inline keyloggers. The FBI would not have been defeated by that corrupt banker whose drives were encrypted with Truecrypt and never cracked. The machine stolen from me in a 2008 police raid would not have defeated their forensics. The UK would not have resorted to key disclosure laws, which anti-vivisection activists have publicly defied. As Edward Snowden says, encryption works-use it.

[curaga]

That's quite an optimistic view. Anything starting from freezing the RAM sticks can happen at that point.

[droidhacker]

Also full-disk-encryption should be a last-resort method of encrypting your data.

See here: http://sockpuppet.org/blog/2014/04/3...dont-want-xts/

The more the encryption software knows what sort of data is encrypted the more safety can be guaranteed. Filesystem level encryption is a whole layer above block-layer encryption. I wish we would have this already for btrfs. It would even make a lot more practical sense there as encrypting btrfs raid systems is a bit problematic at the moment. Every single drive would have to be encrypted individually which would cause an administrative as well as a performance overhead.

An idling system is not necessarily accessible. It is still protected through software such as lockscreen. If you can't guess the passcode, you can't unlock it. If you can't unlock it, then you can't access the data. The more likely scenario is that whoever is trying to access the data faces impenetrable lockscreen and is forced to reboot in order to gain access to raw hardware storage. Finds raw hardware storage encrypted and is now finished with their assault.

[Dorsai!]

Performance.

Also full-disk-encryption should be a last-resort method of encrypting your data.

See here: http://sockpuppet.org/blog/2014/04/3...dont-want-xts/

The more the encryption software knows what sort of data is encrypted the more safety can be guaranteed. Filesystem level encryption is a whole layer above block-layer encryption. I wish we would have this already for btrfs. It would even make a lot more practical sense there as encrypting btrfs raid systems is a bit problematic at the moment. Every single drive would have to be encrypted individually which would cause an administrative as well as a performance overhead.

[Nille]

Given that makes me wonder why would anyone want to use it when there is LUKS with everything encrypted.

Performance.

[TheBlackCat]

The only scenario where user might want to have only some folders encrypted on phone is to stash some stuff that is not used often. But then again encrypted file container is just fine and this ext4 encryption would be over-engineering. So its still useless.

It is considerably easier to just be able to right-click on a file or directory and say "encrypt this". Yeah, there are other ways you could currently implement this, but none as simple and seamless for the user.

[TheBlackCat]

I wonder how specific it really is to EXT4. Couldn't it be made generic at the VFS and/or block layers?

From the first email:

Currently all of the changes are in fs/ext4 but I've been talking to Jaegeuk about adopting the same same interfaces (which is essentially just two ioctl's to set the encryption policy and to get the per-file-system 'salt' for passwords) for f2fs.

[stiiixy]

The front page of the Washington Post today had cops and FBI whining about not being able to get into locked iPhones and proposing key escrow. The Post speculated that the Snowden case would make key escrow legislation impossible to pass. They also suggested key disclosure laws (rubber hose decryption), though those have run into constitutional issued in US courts. It looks like the FBI's strategy is to have a key escrow proposal waiting to go and then wait for any serious crime or terrorism incident they can plausably blame on encryption, then press for the bill. We need to beat them to the punch.

The best insurance against key esroiw in the futue is to have installable Android images with default high security encryption circulating over the Internet as soon as possible and reaching servers out of the reach of governments that might want to regulate encryption. I speak as someone who has sucessfully used disk encryption on a desktop to defeat a police search warrant aimed at protesters. I do not at this time use any smartphone as I do not trust the carriers not to do things like deploy keyloggers against encryption. This could be prevented by having an image that cuts power to the baseband radio until after the encrypted disks are unlocked and blocking all carrier-pushed updates to anything.

Needless to say, I would refuse to comply with a key disclosure law, following the example of British anti-vivisection protesters who defied a key disclosure (UK law allows these) and got away with it. One of the most important reasons for encryption is to lock out police seeking to muzzle political dissent and "plumbers" sent by politicians to punish whisteblowers.

As always, it's a pleasure to see someone out there 'somehwere' with good technical input. I've been havoig some conversations with a fellow who's got security people in his family, and try to outdo each other with the 'crazy' security talks stuff, and how much and how low the NSA, GCHQ etc can go. Scared him a bit with the multitude of firmware's in phone's.