0
$\begingroup$

From Wikipedia:

XTS mode is susceptible to data manipulation and tampering, and applications must employ measures to detect modifications of data if manipulation and tampering is a concern: "...since there are no authentication tags then any ciphertext (original or modified by attacker) will be decrypted as some plaintext and there is no built-in mechanism to detect alterations. The best that can be done is to ensure that any alteration of the ciphertext will completely randomize the plaintext, and rely on the application that uses this transform to include sufficient redundancy in its plaintext to detect and discard such random plaintexts."

I am researching secure ways of backing up data on a regular basis (using deduplication or versioning).

The backup would be stored in low security location (meaning an attacker could have access to the data over long amounts of time and over multiple backup cycles).

Should I be worried about XTS tampering when encrypting backups using VeraCrypt?

$\endgroup$
7
  • $\begingroup$ Access == edit? What about a rollback attack? What about deletion? $\endgroup$
    – kelalaka
    Sep 6 '20 at 13:52
  • $\begingroup$ @kelalaka Access to the encrypted data which includes tampering. I am not worried about deletion in this use case, just tampering. $\endgroup$
    – sunknudsen
    Sep 6 '20 at 13:58
  • $\begingroup$ You can edit your question to clarify that. $\endgroup$
    – kelalaka
    Sep 6 '20 at 14:38
  • $\begingroup$ Well, actually the quoted text includes. Since XTS doesn't include any integrity, you need to do yourself. If the attackers know the position of any data (that is really depend on the stored data) the result can be catastrophic. Your solution is to store the backups with incremental HMAC that is a keyed MAC. $\endgroup$
    – kelalaka
    Sep 6 '20 at 14:58
  • $\begingroup$ @kelalaka How could an attacker know the position of any data? Also, would computing a SHA256 hash of the encrypted volume file be enough to confirm integrity? $\endgroup$
    – sunknudsen
    Sep 7 '20 at 0:33
1
$\begingroup$

With XTS mode encryption data can be "tampered with" with the caveat that any changes to the data are random and unpredictable to an attacker. Since encryption acts as a pseudo-random function for any secure encryption you end up with a secure scheme:

Note that for each block there is a unique 128-bit block id according to XTS mode. This ID needs not be random.

XTS mode takes ENC(block XOR block_id) XOR block_id

  1. If XTS was only ENC(block XOR block_id) an attacker can control the value block XOR block_id used to encrypt. This can be potentially useful if the attacker wants to convert it to ECB mode encryption allowing them to run other attacks; but only works in a chosen-plaintext case. This assumes the attacker knows the block id.
  2. If XTS was only ENC(block) XOR block_id an attacker can XOR the block ID manually from the ciphertext to reveal ECB-mode encryption. This assumes the attacker knows the block id. This works in a ciphertext-only attack.
  3. If the attacker can perform #2 they can extend that to ENC(block XOR block_id) XOR block_id. This yields an attack where they combine attacks #1 and #2.

... Or can they?

If an attacker tries the composite attack they'll be restricted by their knowledge of the block id. But in XTS mode the block id is kept secret by encrypting another key, and using that to create the block id. If the attacker knew the block ids used, they could use the outlined composite attack.

  • If the scheme was ENC(block) XOR block_id the attacker could find the block ids used via the same cryptanalysis that breaks ECB mode, if they knew the pattern between block ids; effectively yielding an obfuscated ECB mode encryption in any case there the block ids are predictable (eg. each block id is the previous id + 1).

  • If the scheme was ENC(block XOR block_id) the attacker would be unable to recover the block ids, since they would be unable to determine from the ciphertext which ids are likely to be correct.

  • In the actual XTS mode, since it combines both of those simplified cases the attacker is SOL. Plus, you may have noticed neither of those cases allow an attacker to intelligently modify the plaintext from the ciphertext.

Those attacks can reveal patterns in the information but neither allows (intelligent) data tampering.

  • CBC mode allows tampering because each block is XORd with the ciphertext of the previous block (the block id is known simply by looking at the ciphertext).
    • The attacker can modify the ciphertext of the previous block to change the data in a specified block.
    • The previous block, after tampering, becomes meaningless; but the block the attacker wanted to change is intelligently modified.
  • In CTR mode tampering is possible because the plaintext/ciphertext isn't passed through the encryption function, at all; it's simply XORd with a random stream (the random stream is generated by the encryption function).

In a secure block cipher, any change to the ciphertext yields random and meaningless plaintext once passed through the encryption function. Therefore, any attempt at tampering would yield that result.

In short,

XTS mode does allow tampering in a certain sense, but the attacker cannot know or predict what the data will become. They can only say "F**k you, your data is meaningless!"

$\endgroup$
8
  • $\begingroup$ Thanks! Did you mean XTS is that last paragraph? $\endgroup$
    – sunknudsen
    Sep 7 '20 at 0:26
  • $\begingroup$ Good catch... I updated the answer. $\endgroup$
    – Serpent27
    Sep 7 '20 at 0:27
  • $\begingroup$ What do you think of sockpuppet.org/blog/2014/04/30/you-dont-want-xts? I am evaluating the pros and cons of using Borg for deduplication and encryption+authentication vs using Borg for deduplication and VeraCrypt for encryption (without authentication). I am having a hard time wrapping my head around if and why authentication is important. If XTS is tamper resistant, I don’t see why authentication is a big deal, yet many cryptographers recommend not using XTS when possible. $\endgroup$
    – sunknudsen
    Sep 7 '20 at 0:45
  • $\begingroup$ The reason it says that is different than you may be thinking... XTS is good for making sure attackers can't intelligently tamper with your data, but provides no means of knowing that it's been tampered with until you read the block of data and have no idea what it says. If an attacker wanted to, say, remove a block of data without you knowing anything changed they could make a certain block "disappear" and you'd have no knowledge until you found a random block of garbage. $\endgroup$
    – Serpent27
    Sep 7 '20 at 0:48
  • $\begingroup$ For that reason, you should always authenticate the data using some form of actual authentication scheme. FDE avoids using an authentication scheme merely because it's impractical - you'd have to recalculate the hash of 100GB+ (for a small hard drive) every time you power on your computer, just to verify integrity. $\endgroup$
    – Serpent27
    Sep 7 '20 at 0:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.