8 ms·
You Don't Want XTS
- tptacek 12y agoIf anyone's interested in a fun project: 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.
- NateLawson 12y agoThe block layer is a poor location to support security, whether access control or encryption. The lack of knowledge of upper layers & the resource constraints of the lower layers (block stealing for metadata) unnecessarily hamper its security and performance. 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.
- helper 12y agoIt's too bad that ZFS encryption is only in Oracle ZFS, not OpenZFS.
- tveita 12y agoKeep in mind that the simpler implementation of block layer encryption also makes it easier to implement and audit. 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.
- cperciva 12y agoAs I understand it the encryption layer only deals with opaque chunks of data Correct. 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.
- tveita 12y agoFrom an end user's perspective Tarsnap certainly deals with files and folders. It outsources most of that work to libarchive, which is kind of my point. 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.
- tptacek 12y agoI think it would be better if applications could provide their own encryption. Applications know better how to cryptographically protect content. For instance: we use GPGMail for our email at Matasano. The operating system could not do a better job of encrypting email messages than GPGMail does. 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?
- schoen 12y agoWhat kind of access are you assuming the attacker has here? Modifying the ciphertext stored with Dropbox? 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.
- rdl 12y agoI guess the question is if you could do bad things to truecrypt itself this way, or if it would be easier to rely on user intervention. There is also "what can be done by Dropbox itself" (potentially via court order) vs what could be done by mitm (not sure what protections Dropbox has against this; if it uses the host ca certs to authenticate vs in app cert pinning (which is obvious and good), etc. 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.
- sillysaurus3 12y agoWould you mind expounding? It sounds very interesting, but I'm having trouble figuring out how an evil maid attack might be employed against Dropbox-based Truecrypt volumes, since people can't boot from those.
- tptacek 12y agoYou need to generalize the attack past boot, to the core concept of "victim interacts with disk, attacker tampers with disk, victim interacts with disk".
- sillysaurus3 12y agoI figured that's what you meant, but I'm having trouble imagining how one would modify a truecrypt volume in a way that would give an adversary any advantage: http://www.truecrypt.org/docs/encryption-scheme http://www.truecrypt.org/docs/encryption-scheme 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.
- schoen 12y agoI'm wondering if tptacek is proposing that an attacker who can modify the TrueCrypt image on Dropbox can get either private key disclosure or remote code execution. (Actually, either of these here is likely to lead to the other.) 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.
- sdevlin 12y agoHere's one possible approach. 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.
- pedrocr 12y ago>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. 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?
- makomk 12y agoencfs uses the same questionable encryption techniques that motivated the creation of XTS in the first place. It's structured almost like full-disk encryption at the file level. I think the same's true of ecryptfs.
- tptacek 12y agoEncFS is a FUSE filesystem. There is no reason for it to use sector-level encryption. It's format-aware. It can do fully randomized encryption and provide strong authentication. However, someone involved in EncFS did propose switching to XTS. Which is actually what prompted me to write this article.
- makomk 12y agoOh. Oh dear. The reason that EncFS were considering switching to XTS is because their last security audit suggested it[1], probably with good reason. Remember that many applications also expect fast sector-level random read and write access to files; add in the potential for power-failure-related data corruption and missing writes, and you can't really do much better than XTS. (At least not whilst relying on a normal filesystem as your backend; ZFS can probably do more.) [1] https://defuse.ca/audits/encfs.htm https://defuse.ca/audits/encfs.htm
- tptacek 12y agoNo, this isn't true at all. If you don't have the physical disk geometry problem, you shouldn't be using XTS. In fact, the whole article is about exactly this point. 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. :)
- schoen 12y agoAfter reading the original article and this whole thread, including some quite useful discussions about the security goals of disk encryption, I'm convinced that this is extremely hard (with XTS) under realistic attack scenarios. 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.
- Tomte 12y agoI don't get the title. The title tells me I don't want XTS. Then the post explains that I don't want FDE, for sundry reasons. Then it tells me, sure, go ahead and use FDE, but be aware of the limitations. At that point it looks like I want XTS, after all. Then it shows how XTS works and where cryptographers are seeing problems. And then... well, there is no "then". The recommendations don't deal with FDE at all. I think the post would be much stronger, if it either had some alternative mode to present or (I'd be more interested in that) it showed other ways to achieve what people usually try to achieve with FDE. And usability is a big one there. Bitlocker is huge. FileVault is huge. People can actually use it. An aside: Has anyone ever seriously used XTS mode for anything but FDE? I've only encountered it in Truecrypt and the part of Boneh's Crypto I where he's talking about FDE. But that doesn't mean much, I admit.
- tptacek 12y agoThe post ends with the takeaways I'm hoping for: 1. Try not to rely on FDE at all. 2. For God's sake don't use XTS for anything other than FDE. There's an encrypted filesystem guy that suggested they were moving to XTS. That's what prompted the post. Usability is great. I think you should turn FDE on. But turning on FDE buys you a lot less than you think it does. There's a pretty good chance that FDE isn't going to do anything for you if your computer is seized by the FBI, because the key will probably resident when they do that. You don't want XTS, in general, because you don't want to turn a simpler problem (safely encrypting your secrets) into a hard problem (simulating hardware encryption).
- zokier 12y agoAuthors recommendations seem bit "handwavy" to me. I understand that this article probably is not intended for end-users, but still it would have been nice to have more concrete advice. Eg dm-crypt is usually used with XTS mode, what would the author (or the good crowd of HN) say to be "better" solution (not necessarily at block layer) for eg. protecting laptop?
- NateLawson 12y agoAs I mentioned above, ZFS is a good example of filesystem encryption without the block device constraints. But between your OS and the hard drive in your laptop, use whatever full disk encryption software that is best supported & most secure. He's not criticizing FDE in general, he's saying "don't constrain yourself to the block device model if you're designing database encryption etc etc."
- zokier 12y ago> ZFS is a good example of filesystem encryption without the block device constraints Would you happen to know if there is anything equivalent planned/done for btrfs (or ext4)?
- midas007 12y agoTL;DR For random-seek block encryption, don't use XTS, use CTR. It's simple. I like simple maths and code, it's less to screw up and less for implementations to screw up. For example, I don't trust EC or GCM, even if some people thinks they're the new hotness, because complexity creates more opportunities for obfuscation and puts the code further out of reach of the already few eyeballs actually (or not) looking at it. Maybe 'cpervica explain why
- tptacek 12y agoWhat? No. Don't do that.
- ronaldx 12y agoThis is why you should never tell people what not to do, without also telling them what they should be doing ;)
- midas007 12y ago? What's wrong with CTR? CTR is basically an OTP. Being OTP, encryption and decryption are basically the same construction (thank you XOR). cipherblockdata = blockcipher(key, nonce . block #) ^ plainblockdata plainblockdata = blockcipher(key, nonce . block #) ^ cipherblockdata If MAC is needed, that can happen after encrypting, before decrypting. (Needed if bytes traverse network, but maybe not for local disk or file encryption unless.) Edit fixed my maths:
- tptacek 12y agoCTR is not a one-time pad. Read the article: it discusses using CTR for disk encryption.
- midas007 12y agoPretty hilariously wrong, and you know it. Supposed OTP constructions are defined as e(i) == E(...) ^ m(i) m(i) == D(...) ^ e(i) where E(...) = D(...) and where ... doesnt contain any of the following e(j) for any j m(k) for any k j and k in same domain as i Then, take a look at CTR... CTR is E(i) = blockcipher(key, nonce . i) and D(i) = E(i) e(i) == blockcipher(key, nonce . i) ^ m(i) m(i) == blockcipher(key, nonce . i) ^ e(i) (i == counter, since it's the same in this example where counter and blocks start at the same number) Therefore CTR is an OTP.
- comex 12y agoSo why can't we authenticate all the sectors? Is the performance really that bad, even with AES-NI and such? Chrome OS and Android devices that use dm-verity already do this (albeit for read only), so that's hard to believe... With SSDs, seek time shouldn't be an issue. You can argue that if an attacker can modify your disk, they can probably run code to steal your password, but this does not apply to Dropbox-stored disk images, and AFAIK you can try to secure a PC against modified code seeing the keys using TXT.
- tptacek 12y agoThis is a good question. Here are some reasons: * If you're working with 512 byte sectors, the cost of individual MAC tags gets high. * No matter what your sector size, reserving space for the MAC tag gets you odd-sized sectors. * Most importantly, what does it mean to have a sector with a bad MAC? How does that get reported back to the filesystem? Filesystems aren't designed to cooperate with the disk to track cryptographic attacks. By the time you solve that last problem, you've already gotten yourself pretty far down the track of just providing crypto in the filesystem layer. Which, because the filesystem layer is format-aware, you might as well just keep going and make a proper cryptographic filesystem.
- schoen 12y agoFor the last question, couldn't a sector with a bad MAC get reported the same way that a hardware failure reading the sector would be? (Maybe that would produce misleading error messages to the user?)
- caf 12y agoIs there anything wrong with reporting a sector with a bad MAC as an unrecoverable read error, just as the hardware would do if the CRC failed? Reserving the space is the real killer - either you end up with non-512-byte sectors (and what is more problematic, sectors that don't divide the system memory page size) or you stash the MACs elsewhere in which case every write to a sector also requires a read-modify-write of the sector that holds the MAC.
- sweis 12y agoI primarily like XTS because it's very fast and can be efficiently pipelined on x86 platforms with AESNI. I can get 215 Gbps throughput on 8 cores of a modern Intel CPU. Also, if XTS is used in a length-preserving fashion, it can encrypt standard block devices without significant changes. However, length-preserving means that it's either not going to be authenticated or you need to keep authentication material elsewhere. In the latter case, I'd rather use GCM.
- tptacek 12y agoThe AES-NI properties that XTS exploit can also be exploited by better wide-block-narrow-block constructions; Rogaway for instance suggests that XTS could have cleaned up the CTS construction by using a better understood Feistel construction. Even better would be a "native" wide-block tweakable cipher, one that created a strong PRP out of the entire sector, rather than chunking the sector into narrow blocks and then ECB'ing those narrow blocks. However you did that, it would also probably involve invocations of the AES block transform, and thus benefit from AES-NI. But you're right: XTS has a convenience advantage for encryption in the standard hardware block device setting. What's sad about that is that simulated hardware block encryption is actually not a particularly strong protection for users.
- pbsd 12y agoHave you checked Rogaway's AEZ? Its core could probably be repurposed to disk encryption, being an AES-based tweakable wide block cipher.
- tptacek 12y agoI remember reading this, but will admit to not having an immediate intuition for what it would look like as a wide-block disk encryption scheme.
- oggy 12y agoI don't want XTS? Yes I do, for the purpose it was designed - block device level encryption. The title is misleading, and potentially dangerously so - I could see somebody switching to some CBC-like mode in TrueCrypt "coz tptacek said so" (even if that's not what he said). And I think several statements are, well, let's say disputable. OK, XTS has the unnecessary complication of two keys, introduced in the standardization process. But the security in storage group (whatever it's called) has apparently seen the light is working on essentially allowing just one again. Furthermore, XTS is denounced for having "unclear security goals", and the post leaves the impression that wide-block schemes are so much better. Yet their goals are essentially exactly the same as those of XTS, just on a sector as opposed to a (cipher) block level. And do correct me if I'm wrong, but I believe they are pretty clear: essentially ECB encryption of every cipher block on the disk, with a different key. In more concrete terms, I believe those translate to security under deterministic chosen-plaintext attacks, and non-malleability. Finally Evil Maid attacks (at least the ones presented so far) have absolutely nothing to do with any cipher mode you're using, and everything to do with the trusted platform problem. Maybe in a Dropbox setting the attacker could benefit from the cut-n-paste abilities, but I'm not sure how realistic/severe those attacks would be (presumably you wouldn't have your system partition on Dropbox). I'm having a hard time imagining them, but then again there exist much smarter people than myself in this world. Not to be only critical of the article, I do believe that the basic messages are sound: be aware of the limitations of FDE and don't use XTS in the contexts outside of FDE (unless you really know what you're doing, I guess). But the rest of it I could do without.
- tptacek 12y agoCouple responses: You scare-quote "unclear security goals", but that's not my objection, that's Phil Rogaway's objection. And his argument (and Ferguson's argument, and Liskov's argument) isn't hard to understand: by adopting disk sectors as the setting for your encryption, you trade transparency (the ability to use encryption on any filesystem) for a whole mess of constraints, which the article you're commenting on lays out in detail. The worst of these constraints is that you lose any real authentication, but the fact that XTS is basically XEX-ECB is another problem. You've also taken the "two keys" issue out of context. The issue isn't that it unnecessarily uses two keys. The issue is that it's hard to derive clean security proofs for XTS, because of all its complications. The way Rogaway puts it: there are three constructions involved in XTS --- the XTS wide-to-narrow block adapter, the "XEX2" two-key XEX construction for full narrow blocks, and the "XEX3" two-key construction for partial narrow blocks. I believe you're also wrong about the Evil Maid scenario. Perhaps you're getting hung up on a detail that I wasn't implicating (for instance, booting from the drive). The issue is that in a normal FDE setting, attackers don't get repeated use-tamper-use cycles. But in a cloud-backed FDE setting, they easily do get that, so more sophisticated versions of the same attack scenario are possible. Think "Evil Maid" here in the same sense as Kenny Patterson used the "BEAST" attack scenario to build a plausible attack on RC4. The problem with XTS is that there are better modes you can use, even for sector-level encryption, if you shake off the constraint that you're working with physical disk geometry. Which, in the real world, a lot of FDE users can in fact do, because they're not working with real disks but rather virtual disks stored on cloud filesystems. If you don't need to comply with physical disk geometry, it is probably feasible to get block-level encryption with strong authentication guarantees, and with a native wide-block PRP that will get rid of the ECB data leak in XTS. Finally, don't use XTS for anything but FDE, even if you know what you're doing. That's a bit of a tautological statement for me to make, because if you know XTS, you also know that it's only meant for FDE --- but I've been getting comments from people who have seen XTS used in application-layer crypto. Bad. Ick.
- zanny 12y agoMan I've been having a run around recently with a notebook I just ordered. First intuition is to just LUKs both disks. Ok, that might work, and then I see the horrible performance degradation from FHDing an SSD. Second intuition is SED, and I got a Crucial m550 to hopefully satisfy that, but then I find out there is no documentation on if the ATA password is stored in the firmware. If it is, I'm just wasting my time, and I kind of just have to hope Crucial does the right thing and doesn't store the AES key anywhere. I also have to hope the marketing "hardware encryption" is true like on my 840 Pro, where I don't see any performance loss. And even userspace level encryption of config files that use plaintext passwords is terrible (and lets be honest, way too many different programs hide credentials in plaintext somewhere for me to find all of them easily with a full desktop - off the top of my head, networkmanager, KDE-PIM, Telepathy, Firefox, and Steam all have their own independent unrelated credential stores). In general I would just want to encrypt all of base ~, /var, and /etc, since that is where personal data can end up (and maybe /opt, because random stuff ends up there) - but then I'm still losing most of the reason of having an SSD, especially one with a hardware AES accelerator that would go unused. And don't get me started on the mechanical drive, which I'm going to have to part bin when I get the thing and see if it has working hardware encryption. At least on that it isn't too bad to use LUKs, because then the overhead isn't as bad - but having overhead at all kind of sucks.
- tbirdz 12y agoAs someone who uses dropbox to store encrypted VirtualBox vdi virtual hard disk files using XTS encryption, can someone tell me what I should be using instead of XTS?