It's apparently pretty common for people to create virtual Truecrypt volumes and stick them on Dropbox, as a sort of poor-hacker's encrypted Dropbox.
Someone should bone up on the "Evil Maid" attack and do a proof-of-concept of it on a Dropbox-backed volume. Call it "Evil Maid In The Cloud", or "The Mallory Poppins Attack".
My intuition is that the Evil Maid attack is much more powerful vs. Dropbox-backed volumes.
The only reason for block-level encryption in software is because it was too much work to retrofit UFS, ext23456fs, FAT, NTFS, etc. with encryption. The block device provided a convenient bottleneck, and no one cared too much about the downsides you bring up because it seemed better than nothing.
ZFS generally gets this right, using AES-CCM (an AEAD mode as you recommend). It also has proper integration with the deduplication layer so encryption doesn't waste space. These reasons and more show why security needs to be implemented at the filesystem layer.
Another good example people here may be familiar with is Tarsnap. Again, it handles encryption, integrity protection, and deduplication without storing keys on the server side or unnecessarily restricting itself to a block device metaphor.
You're right that TC+DB are not a safe combo. Dropbox needs to be the encrypted Dropbox.
I'm not as confident in the design and implementation of encryption in e.g. ZFS as I am in full disk encryption.
I'm not sure Tarsnap is a great example of doing encryption at a high level either. As I understand it the encryption layer only deals with opaque chunks of data; it doesn't know anything about high-level concepts like files and folders that the Tarsnap application operates on.
it doesn't know anything about high-level concepts like files and folders that the Tarsnap application operates on.
Tarsnap doesn't really operate on high-level concepts like files and folders. It flattens everything into a tar archive, then encrypts and signs that. That does however ensure that data and metadata are kept together, in a way that encrypting individual disk sectors does not.
The article says to "Encrypt things at the highest layer you can.", but you could imagine a backup utility doing encryption at a higher layer than Tarsnap does, with all the complications that would bring. And would it be even better if instead of file system level encryption, every application encrypted it's own files? I don't think so.
So maybe it should just say "Encrypt things at the highest layer that makes sense", which is kind of vacuous.
IMO it would make just as much sense to say "Encrypt things at the level where it's easiest to do.", where block level encryption is a strong contender. It doesn't give you every property you might want, but it's easy to get right.
I understand your point. "Encrypt at the highest layer you can" is an ideal, and achieving the ideal is not always worth the expense. Some lowest-common-denominator crypto in the OS is valuable. But disk block crypto is a pretty crappy lowest common denominator, as this article is at pains to say. What part of it do you disagree with?
I don't have an issue with adding application specific encryption, as long as you also keep doing it at a suitable "lowest-common-denominator" layer.
A more achievable ideal would be for every layer to do strong integrity checking.
I agree that it would be good if the lowest common denominator provided integrity checking, but as we can see with XTS, sector-level encryption makes that hard. Hence the article. :)
Evil Maid attacks that I've heard described before typically involved modifying (unencrypted and unauthenticated) bootloaders or kernels, rather than FDE ciphertext, although I realize that's not part of the definition of the attack.
Assume the attacker can modify plaintext on disk indirectly. This might be viable if e.g. the user's browser cache lives in the TC volume. (Not sure what typical TC-in-Dropbox usage patterns are, so this may or may not be realistic.)
Further assume that the attacker can observe ciphertext changes in Dropbox.
XTS is vulnerable to the same byte-at-a-time plaintext recovery attacks as ECB. This is usually irrelevant, because adaptive chosen plaintext attacks are outside the threat model considered for FDE. But in our scenario, the attacker has at least some degree of plaintext control.
The success of this attack will depend a lot on how fine-grained the attacker's control over his insertion point is, i.e. can he reliably write to the same location over and over again? Any number of components might thwart that control, so I'm not sure how easy it will be to make this work.
Being able to "glitch" someone's truecrypt volumes without even compromising the crypto could lead to fun. Also, OS/file system cruft on the level above, essentially the equivalent of an .htaccess file, could be fun.
However, I've been reminded that a realistic attacker can do much more to an FDE volume than we would first imagine. So, I'm planning to try to play around with this to improve my intuition of how bad the attacks actually are. Thanks for the challenge.
... huh. Actually, suppose the attacker could somehow cause a very large number of file downloads to happen (with known sequence, timing, and contents). The Birthday Paradox gives the attacker a high probability of being able to see a pair of files from two separate sets of files (of different kinds and different origins) land on a particular sector at different times. When that happens, the attacker can then substitute one for the other.
If we think of a computer for some reason downloading and storing a lot of "trusted" files and a lot of "untrusted" files, and that the attacker can see empirically where each file was stored, then when a trusted file gets stored at an offset where an untrusted file was previously stored, the attacker will be able to substitute the contents of the latter for the contents of the former. For this attack to be harmful, the untrusted file that was stored at that location just needs to contain something that it would be harmful for the attacker to be able to replace the corresponding trusted file with.
People do that? encfs/ecryptfs sounds like a much better fit for that use case. Encryption is per file and you can even disable the filename encryption if you want to still be able to navigate your files using their interface. Are there no good similar solutions for Windows/OSX?
In particular: you do not need XTS to get "fast random read and write access".
Taylor's a smart guy. I'm pretty sure he's wrong about this (although maybe he knows something applicable about EncFS that I don't know). If I thought that there was no way any smart person could make the mistake of applying XTS somewhere it didn't belong, there'd be no point to writing the article. :)
It seems like if an attacker wants to compromise (not merely corrupt) a truecrypt volume, they'd need to exploit the target machine itself, not just the data being read by it... unless Truecrypt has an implementation flaw like a buffer overflow, and you're suggesting modifying the volume to take advantage of it?
Storing a Truecrypt volume in Dropbox would completely invalidate your plausible deniability about whether there's a hidden volume on the drive / whether you have access to it, since an attacker can watch changes in the ciphertext and infer whether you're using a hidden volume. But I thought it was impossible for attackers to generate new ciphertext that decrypts to valid plaintext unless they had the keys, at which point they've already won. So it seems like there's no way to modify the truecrypt volume except to corrupt it. Hrm, I'm out of ideas.
Sorry, I just like to learn as much as possible, and what you suggested sounded very interesting. Don't worry about explaining it unless you want to... I imagine my questions are kind of annoying. I'll research it more.
This seems definitely achievable under some applications of FDE and some assumptions about the state of attacker's knowledge, but I don't know if those assumptions are valid in the particular case of TrueCrypt on Dropbox.
It is? That's very interesting! May I ask, what are some of those applications of FDE / assumptions of the attacker's knowledge? This whole thing is quite fascinating.
Then you could flip bits inside of the binaries to convert them into backdoored ones. I have an example in a current presentation that I've been giving where a fencepost error in the OpenSSH server in 2002 (that resulted in a potential privilege escalation attack) was fixed by changing > to >=, which the compiler compiled as JL instead of JLE, which turned a single byte 0x7E into 0x7C. (That is literally the entire effect of the patch!)
If you can find where on the disk that byte is stored and manage to flip that single bit back, you can re-introduce a particular security hole that the user believes was fixed back in 2002. There are probably thousands of such bit-flips that would produce exploitable bugs, typically by modifying or inverting the sense of conditional branches, but maybe in other ways too. (In cracking DRM in Apple II games, people used to replace tests or conditional branches with NOP, and that would still work to affect how security policies are enforced.)
Not all encryption modes will let you do this attack, but I think that relates to tptacek's point originally that encryption software implementers need to be very careful about their selection of cipher modes and understand what kinds of attacks they defend against.
Elsewhere in this thread sdevlin was thinking about how in a non-tweak mode you can copy ciphertext from one block to another, which means if you could cause a particular file to exist on the drive, and then you can modify the ciphertext, you can cause one file to be overwritten by another (if you know the offsets where both are stored, which you might be able to learn if you know exactly when both were created and could monitor the ciphertext sufficiently often). So for example, if you could send somebody an e-mail attachment that they would save to disk, you could later overwrite some other file (like one of their OS binaries?) with the contents of that attachment by copying the ciphertext block that represents the attachment over the ciphertext block that represents the other binary.
This is one of the main reasons that tweak modes exist, specifically to prevent an attacker from recognizing or copying ciphertext blocks between different locations within the overall ciphertext.
(Edit: sdevlin, not rdl.)