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.
As for security goals: are they not the ones I stated in my post? No, ciphertext integrity is not among them, and yes, there are consequences to this. Yes, it's a trade-off for efficiency. But I really don't see how all of that relates to the issue of missing security goals.
What paper by Rogaway are you referencing there? I'm assuming it's not the original XEX paper, and I'm genuinely interested in reading it, this discussion aside. Anyway, I don't understand the "wide-to-narrow block adapter" part. Assuming that the standard group removes the two key "improvement", the only bit that I can see that remains to be proved, is the ciphertext stealing. I admittedly don't know whether proofs for the whole construction exist. A quick search revealed Liskov's review of the XTS draft which gives a sketch, but not the whole proof.
I'm confident about my Evil Maid statement. The essence of (what's commonly referred to as) Evil Maid really is the fact that you cannot trust your own computer. The multiple visits make the attack significantly easier, but are not necessary - you just need a more advanced malware.
As for repeated tampering, I'm still having a hard time imagining a realistic attack. I just don't see how the attacker can get any predictable amount of control of the FDE's inputs, but like I said, people can come up with smart things. The "system drive" in my post was referring to things like weakening the system security by overwriting configuration files with garbage and the like, which are theoretically possible although I don't really see them being practical.
Yes of course you can get better security guarantees if you change the constraints. You're probably correct that it should be feasible to offer a 512 byte sector view to the OS on the one side, and use whatever size on the physical side, if your physical side isn't really physical.
P.S. I didn't really think much of the the scare-quotes retort, seemed like a bit of a cheap jab. If you however have a better idea (or pointers for that matter) about how to refer to a specific part of a blog post I disagree with, I'd be interested to hear.
It's not the XEX paper; it's "Evaluation of Some Block Cipher Modes". Highly recommended.
Efficiency in the sense of "comparing block cipher modes" is not the reason XTS loses integrity and resistance to chosen-ciphertext attacks. Format constraints are the major reason. To wit: there's no good place to stick an auth tag, and for that matter, no good sense of what you'd be authenticating, because you're dealing with fragments of files, not actual files.
Integrity does factor into the security model of XTS. Rogaway points this out when he explains why NIST apparently rejected CBC (the chaining gives attackers a forward bit-flipping capability) and CTR (which was rejected because it's trivially malleable). NIST claimed that some notion of resisting ciphertext tampering was part of the goal, but, as he said, and Ferguson said, and I said repeatedly in this article, nobody really knows what that tamper-resistance is supposed to mean. Attackers can tamper with ciphertext in XTS, and they can probably do it in ways that will create backdoors in binaries!
But lack of integrity checking isn't the only problem with XTS. Another problem is that XTS is for the most part the ECB mode application of XEX. You can't even get a strong definition of confidentiality from this construction, because an attacker observing block offsets into a given sector can collect useful information as those blocks are changed, changed again, changed back, and changed again. This is the attack Ferguson points out in his objection to NIST standardizing XTS, and it's also related to Rogaway's objection that NIST standardized a wide-block-narrow-block construction rather than something that behaved more like a tweakable native wide block construction. The native wide block construction would effectively randomize the whole sector, not 16-byte chunks of sectors. That would also lessen the harm from XTS's malleability, but here we're more concerned with the granularity of the data we leak by encrypting deterministically.
If you want to call the attack I'm talking about something other than "Evil Maid", that's fine by me. I'd also accept "Mary Poppins is a governess and not a maid" as a valid objection. The point is that virtual disks stored on Dropbox are exposed to far more interesting attacks than physical disk media is, because with physical media, attackers don't get an unbounded number of use-tamper-use cycles.
I believe I do understand the constraints under which XTS operates on, and I agree with almost everything you said in the last comment. The only thing I don't agree with is that nobody knows what tamper resistance is supposed to mean - it's non-malleability on the level of a cipher block. Yes this is clearly worse than a sector-level non-malleability, but is also clearly /much/, /much/ better than CBC-style bit-level malleability. But I'll have a look at Rogaway's paper, maybe there's something I'm missing.
I'm still having a hard time conjuring anything resembling a practical attack coming from this. To plant backdoors, you'd have to know the exact location of a binary (feasible and done before, if with pretty strong assumptions), then get the user to change those exact same sectors to something that would be useful to you, and then copy-paste the ciphertext. I just don't see that happening in a real world scenario. Otherwise, taking advantage of the weaker confidentiality notion (deterministic CPA)... still seems quite far fetched, but I accept that I could be proven wrong.
At any rate, I still maintain that this has nothing to do with Evil Maid attacks. Use a CCA2 secure cipher and encrypt the whole disk at once if you want, the Maid still wins.
You only need to know where on the disk the binary is. Once you know that, you attack the binary directly, by randomizing a 16-byte chunk of it. The effectiveness of that attack depends on a lot of factors, but remember that X64 binaries aren't the only thing that XTS needs to protect.
For that matter, you can trigger vulnerabilities in the kernel or even application code, by surreptitiously randomizing offsets into metadata that they depend on.
What's clear to a cryptographer is that no scheme that provides serious non-malleability should have this property, but XTS does. What's maddening, in a theoretical sense, is that you can't really put this into formal terms, because --- as I've been saying --- nobody has provided a clear definition of what security guarantees XTS is supposed to provide.
No amount of use-tamper-use breaks a cipher that resists CCA2 attacks, because every attempt to tamper produces a hard failure. That's what CCA2-resistance means: attackers don't get to adaptively choose ciphertext (or really, choose any ciphertext at all). In practice, cryptosystems resist these attacks by authenticating ciphertext.
For what it's worth, the article we're commenting on is clear that CBC is inferior to XTS for disk encryption. I take no responsibility for readers who read random selections of the article and come to their own conclusions, although if you look elsewhere on this thread that has clearly happened at least once.
I concede the point about the possibility of triggering crashes in say the kernel code. This however a) does not depend on repeated access to the encrypted drive, b) is only slightly less likely to occur with a wide-block mode, c) might be hard to meaningfully exploit, but I'll defer to your expertise on that one.
It also doesn't really seem to rely on multiple access to the ciphertext (you're not gonna brute force 16 bytes). And as I mentioned, you are not that likely to have your system partition on Dropbox, and I'd wager the contents and offsets of your user partition are not that easy to guess.
For a definition of non-malleability applicable to XTS, see "Security Notions for Disk Encryption".
Lastly, you're missing my point about CCA2 encryption - it does not solve the trusted platform problem, and an encryption system based on it is thus as vulnerable to Evil Maid attacks as your poor old XTS. Unless you want to exclude installation of malware from the definition of an Evil Maid attack, but then your usage of the term conflicts with just about everybody else's.
We're in a semantic rut here. Like I said way upthread: I'm not trying to litigate the term "Evil Maid". I'm pointing out that Truecrypt+Dropbox is vulnerable to use-tamper-use attacks in ways that physical disk encryption isn't. Authenticated encryption rules these attacks out, because there is no way to fail anything but completely when modifying ciphertext on the stored image. Call the attack whatever you'd like; I've clearly mentally generalized the Evil Maid idea in a way that you haven't. Maybe I'm giving Joanna Rutkowska too much credit (but I doubt it :)
Regarding "multiple access to the ciphertext" --- you will indeed brute force 16 bytes, but you won't be trying to find a 128 bit needle in the haystack; you'll be looking for 128 bit blocks that happen to have a mix of innocuous bytes --- of which there will be many possibilities --- coupled with the opcode you want, and you'll have the bytes trailing the previous block and the bytes leading the subsequent block to play with as well to narrow your search. The attack will look a little bit like the byte-at-a-time attack on ECB.
I think that attack is significantly more plausible than you think it is. Apparently, so did Ferguson, since he brought it up ("Code modification attacks") in his NIST objection.
My issue with semantics is not that you're generalizing the notion, but rather specializing it. The "tamper" part of use-tamper-use in Evil Maid refers to the entire system, whereas you insist on tampering with only the ciphertext.
I'm still skeptical about code modification. The access the attacker gets is not really an oracle as in your byte-at-a-time scenario (I take it you're referring to the one from your crypto challenges), they can only observe the decryption output in a very indirect fashion. The number of potentially useful "needle" configurations is also hard to tell, you'd need to get alignment right and produce valid opcodes throughout the block etc. And also how many tries would the attacker get in reality? The executable would need to be reloaded for each one of his tries.
But more fundamentally, I find the whole scenario unlikely. To get there in the first place would require the user to sync their system partition with Dropbox. I think it's fair to say that will almost never happen. And if we're talking about a physical repeated-tamper attacker, well the Evil Maid (the original (TM)) is a much easier option for him.
If you store an image with executable code in it on Dropbox via Truecrypt, how many times will you potentially run it out of that image?
Again: we are talking about properties that cryptographically sound systems simply don't have. And if you're using Dropbox as your backing store, and not a physical drive, there is no reason to accept those properties!
If I store a program on Dropbox, I might run it many times. Thousands? Millions to be generous? But if the attacker has to do a brute force search which relies on me executing each different tampered version of the program, that's probably too small of a number.
The reason to accept sub-optimal properties in this case is convenience. Truecrypt is popular and has a nice interface. Using it with Dropbox gives much better security than not using it with Dropbox. It's not perfect, but I still don't think we have any practical attacks against such a scenario.
I agree that having stronger crypto there is however possible and desirable.
Comments
Couple 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.
As for security goals: are they not the ones I stated in my post? No, ciphertext integrity is not among them, and yes, there are consequences to this. Yes, it's a trade-off for efficiency. But I really don't see how all of that relates to the issue of missing security goals.
What paper by Rogaway are you referencing there? I'm assuming it's not the original XEX paper, and I'm genuinely interested in reading it, this discussion aside. Anyway, I don't understand the "wide-to-narrow block adapter" part. Assuming that the standard group removes the two key "improvement", the only bit that I can see that remains to be proved, is the ciphertext stealing. I admittedly don't know whether proofs for the whole construction exist. A quick search revealed Liskov's review of the XTS draft which gives a sketch, but not the whole proof.
I'm confident about my Evil Maid statement. The essence of (what's commonly referred to as) Evil Maid really is the fact that you cannot trust your own computer. The multiple visits make the attack significantly easier, but are not necessary - you just need a more advanced malware.
As for repeated tampering, I'm still having a hard time imagining a realistic attack. I just don't see how the attacker can get any predictable amount of control of the FDE's inputs, but like I said, people can come up with smart things. The "system drive" in my post was referring to things like weakening the system security by overwriting configuration files with garbage and the like, which are theoretically possible although I don't really see them being practical.
Yes of course you can get better security guarantees if you change the constraints. You're probably correct that it should be feasible to offer a 512 byte sector view to the OS on the one side, and use whatever size on the physical side, if your physical side isn't really physical.
P.S. I didn't really think much of the the scare-quotes retort, seemed like a bit of a cheap jab. If you however have a better idea (or pointers for that matter) about how to refer to a specific part of a blog post I disagree with, I'd be interested to hear.
It's not the XEX paper; it's "Evaluation of Some Block Cipher Modes". Highly recommended.
Efficiency in the sense of "comparing block cipher modes" is not the reason XTS loses integrity and resistance to chosen-ciphertext attacks. Format constraints are the major reason. To wit: there's no good place to stick an auth tag, and for that matter, no good sense of what you'd be authenticating, because you're dealing with fragments of files, not actual files.
Integrity does factor into the security model of XTS. Rogaway points this out when he explains why NIST apparently rejected CBC (the chaining gives attackers a forward bit-flipping capability) and CTR (which was rejected because it's trivially malleable). NIST claimed that some notion of resisting ciphertext tampering was part of the goal, but, as he said, and Ferguson said, and I said repeatedly in this article, nobody really knows what that tamper-resistance is supposed to mean. Attackers can tamper with ciphertext in XTS, and they can probably do it in ways that will create backdoors in binaries!
But lack of integrity checking isn't the only problem with XTS. Another problem is that XTS is for the most part the ECB mode application of XEX. You can't even get a strong definition of confidentiality from this construction, because an attacker observing block offsets into a given sector can collect useful information as those blocks are changed, changed again, changed back, and changed again. This is the attack Ferguson points out in his objection to NIST standardizing XTS, and it's also related to Rogaway's objection that NIST standardized a wide-block-narrow-block construction rather than something that behaved more like a tweakable native wide block construction. The native wide block construction would effectively randomize the whole sector, not 16-byte chunks of sectors. That would also lessen the harm from XTS's malleability, but here we're more concerned with the granularity of the data we leak by encrypting deterministically.
If you want to call the attack I'm talking about something other than "Evil Maid", that's fine by me. I'd also accept "Mary Poppins is a governess and not a maid" as a valid objection. The point is that virtual disks stored on Dropbox are exposed to far more interesting attacks than physical disk media is, because with physical media, attackers don't get an unbounded number of use-tamper-use cycles.
Thanks for the paper reference.
I believe I do understand the constraints under which XTS operates on, and I agree with almost everything you said in the last comment. The only thing I don't agree with is that nobody knows what tamper resistance is supposed to mean - it's non-malleability on the level of a cipher block. Yes this is clearly worse than a sector-level non-malleability, but is also clearly /much/, /much/ better than CBC-style bit-level malleability. But I'll have a look at Rogaway's paper, maybe there's something I'm missing.
I'm still having a hard time conjuring anything resembling a practical attack coming from this. To plant backdoors, you'd have to know the exact location of a binary (feasible and done before, if with pretty strong assumptions), then get the user to change those exact same sectors to something that would be useful to you, and then copy-paste the ciphertext. I just don't see that happening in a real world scenario. Otherwise, taking advantage of the weaker confidentiality notion (deterministic CPA)... still seems quite far fetched, but I accept that I could be proven wrong.
At any rate, I still maintain that this has nothing to do with Evil Maid attacks. Use a CCA2 secure cipher and encrypt the whole disk at once if you want, the Maid still wins.
You only need to know where on the disk the binary is. Once you know that, you attack the binary directly, by randomizing a 16-byte chunk of it. The effectiveness of that attack depends on a lot of factors, but remember that X64 binaries aren't the only thing that XTS needs to protect.
For that matter, you can trigger vulnerabilities in the kernel or even application code, by surreptitiously randomizing offsets into metadata that they depend on.
What's clear to a cryptographer is that no scheme that provides serious non-malleability should have this property, but XTS does. What's maddening, in a theoretical sense, is that you can't really put this into formal terms, because --- as I've been saying --- nobody has provided a clear definition of what security guarantees XTS is supposed to provide.
No amount of use-tamper-use breaks a cipher that resists CCA2 attacks, because every attempt to tamper produces a hard failure. That's what CCA2-resistance means: attackers don't get to adaptively choose ciphertext (or really, choose any ciphertext at all). In practice, cryptosystems resist these attacks by authenticating ciphertext.
For what it's worth, the article we're commenting on is clear that CBC is inferior to XTS for disk encryption. I take no responsibility for readers who read random selections of the article and come to their own conclusions, although if you look elsewhere on this thread that has clearly happened at least once.
I concede the point about the possibility of triggering crashes in say the kernel code. This however a) does not depend on repeated access to the encrypted drive, b) is only slightly less likely to occur with a wide-block mode, c) might be hard to meaningfully exploit, but I'll defer to your expertise on that one.
It also doesn't really seem to rely on multiple access to the ciphertext (you're not gonna brute force 16 bytes). And as I mentioned, you are not that likely to have your system partition on Dropbox, and I'd wager the contents and offsets of your user partition are not that easy to guess.
For a definition of non-malleability applicable to XTS, see "Security Notions for Disk Encryption".
Lastly, you're missing my point about CCA2 encryption - it does not solve the trusted platform problem, and an encryption system based on it is thus as vulnerable to Evil Maid attacks as your poor old XTS. Unless you want to exclude installation of malware from the definition of an Evil Maid attack, but then your usage of the term conflicts with just about everybody else's.
We're in a semantic rut here. Like I said way upthread: I'm not trying to litigate the term "Evil Maid". I'm pointing out that Truecrypt+Dropbox is vulnerable to use-tamper-use attacks in ways that physical disk encryption isn't. Authenticated encryption rules these attacks out, because there is no way to fail anything but completely when modifying ciphertext on the stored image. Call the attack whatever you'd like; I've clearly mentally generalized the Evil Maid idea in a way that you haven't. Maybe I'm giving Joanna Rutkowska too much credit (but I doubt it :)
Regarding "multiple access to the ciphertext" --- you will indeed brute force 16 bytes, but you won't be trying to find a 128 bit needle in the haystack; you'll be looking for 128 bit blocks that happen to have a mix of innocuous bytes --- of which there will be many possibilities --- coupled with the opcode you want, and you'll have the bytes trailing the previous block and the bytes leading the subsequent block to play with as well to narrow your search. The attack will look a little bit like the byte-at-a-time attack on ECB.
I think that attack is significantly more plausible than you think it is. Apparently, so did Ferguson, since he brought it up ("Code modification attacks") in his NIST objection.
My issue with semantics is not that you're generalizing the notion, but rather specializing it. The "tamper" part of use-tamper-use in Evil Maid refers to the entire system, whereas you insist on tampering with only the ciphertext.
I'm still skeptical about code modification. The access the attacker gets is not really an oracle as in your byte-at-a-time scenario (I take it you're referring to the one from your crypto challenges), they can only observe the decryption output in a very indirect fashion. The number of potentially useful "needle" configurations is also hard to tell, you'd need to get alignment right and produce valid opcodes throughout the block etc. And also how many tries would the attacker get in reality? The executable would need to be reloaded for each one of his tries.
But more fundamentally, I find the whole scenario unlikely. To get there in the first place would require the user to sync their system partition with Dropbox. I think it's fair to say that will almost never happen. And if we're talking about a physical repeated-tamper attacker, well the Evil Maid (the original (TM)) is a much easier option for him.
If you store an image with executable code in it on Dropbox via Truecrypt, how many times will you potentially run it out of that image?
Again: we are talking about properties that cryptographically sound systems simply don't have. And if you're using Dropbox as your backing store, and not a physical drive, there is no reason to accept those properties!
If I store a program on Dropbox, I might run it many times. Thousands? Millions to be generous? But if the attacker has to do a brute force search which relies on me executing each different tampered version of the program, that's probably too small of a number.
The reason to accept sub-optimal properties in this case is convenience. Truecrypt is popular and has a nice interface. Using it with Dropbox gives much better security than not using it with Dropbox. It's not perfect, but I still don't think we have any practical attacks against such a scenario.
I agree that having stronger crypto there is however possible and desirable.