Encryption Support For EXT4

[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.

[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.

[Nille]

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

Performance.

[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.

[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.

[curaga]

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

[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.

[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]

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.