Let us assume that I have two partitions on my hard disk, and unencrypted one and an encrypted one. Let us also assume that I shut down the computer when sleeping or away, and an attacker has physical access to my computer. In fact, the attacker takes a copy of the disk image every day without me knowing it. Obviously, the attacker does not know the passphrase of the encrypted disk partition, so the attacker can only observe changes in ciphertext (let's assume now that the attacker doesn't know that keyloggers exist or doesn't want to take the risk of me noticing it).

Now, there's a particular 100 MB file that is a copyright and trade secret violation. I don't want to delete it, but I'm becoming slightly suspicious that my computer is used without my permission, so I store it into the encrypted partition, deleting it from the unencrypted partition.

Now, the attacker will observe that 100 MB of the ciphertext of the encrypted partition differs from the old ciphertext. In fact, from the daily disk images, the attacker sees that the amount of changes in the encrypted disk is usually zero, and this was practically the only exception for that. The attacker will also observe that the 100 MB file was deleted from the unencrypted partition. Thus, the attacker concludes that I still have the file.

My question is: does this kind of attack against full disk encryption have a name? Do any full disk encryption schemes offer resistance against this kind of attack, e.g. by randomly rewriting blocks with a new per-block key even if no plaintext block actually changed?

  • $\begingroup$ I would call this traffic analysis. While it is sometimes possible to defend against traffic analysis, it is usually expensive. $\endgroup$ – K.G. Feb 27 '17 at 11:25
  • $\begingroup$ Note that if a file is exactly 22MB plus 50 bytes, and it's floating around the internet, then you can guess that is what it is; based on the length alone. $\endgroup$ – Rob Mar 29 '17 at 2:25

I'm not sure about a formal name but I can comment on your other questions. A lot depends on the level at which you do the encryption. There are three main approaches I'm aware of:

  1. The disk data itself is encrypted,
  2. The file system encrypts data stored in it but is itself stored in plain text on the disk (e.g. CryFS),
  3. Individual files are encrypted but directory structure and file system level meta data (size, timestamps, etc) is not (e.g. EncFS). This is basically what ransomware does.

Generally speaking, none of these approaches encrypt an entire disk worth of data as one long cipher text. They break it down to some degree, whether by sector (in the case of 1), by file (in the case of 3) or arbitrary chunks (in the case of 3). There's a practical reason for this: all the cipher text within an encryption unit (block, sector, chunk, file, etc.) should change if any part of it is changed. If your entire disk were one encryption block then simply viewing a file (modifying the access time) could result in the entire disk being rewritten.

You can generally assume that an OS will put some metadata onto a disk as soon as it's mounted (and maybe even periodically) so the cipher text will change from day to day. However, it won't be the entire disk that changes, just certain portions that become predictable to a diligent observer after a while.

Now...the disappearance of 100MB of clear text coinciding with the appearance of 100+MB (a sane disk encryption system will have data authentication overhead) of ciphertext is a pretty strong indicator that you encrypted the sensitive file. There are things that will complicate this depending on the exact scheme used. First, the amount of change on the encrypted partition will be rounded to the smallest encryption unit (which can be quite large). Second, if a scheme does not store your new file contiguously (is fragmented, intentionally or unintentionally) then significantly more than 100MB of new ciphertext will be created/changed. The last factor can make it much more doubtful whether the sensitive file has just been encrypted but does not apply at all to scheme #3.

Of course, if the attacker is aware of the scheme you're using and are only missing the key then they'll know with high confidence that you simply moved the file. The only way I can think of that would make it doubtful whether you still have the file is if you were able to store the file in a different form by:

  • compressing it to reduce the written size
  • padding it arbitrarily to increase the size

You would still have the timing signal though. That is more an operational issue than anything. You have to avoid unlikely coincidences like that if you are to be able to meaningfully use the encrypted partition in a hostile environment. Even if the file weren't on the other partition, the release of a controversial file online coinciding with the appearance of a similar amount of cipher text on your partition is quite revealing.

You could have a script randomly creating, deleting and touching files, rotating encryption IVs, moving data across block boundaries, etc so you end up with a few hundred MB of changed ciphertext daily without anything really happening from your perspective. If you're clever enough you could have this system gradually create an opening for your sensitive file through various blank hidden files and then slowly "garbage collect" this back into one contiguous file again over time. You'd have to be exceedingly clever to have this process not become a side channel for information about the clear text of the partition though.

P.S.: If someone has a way of extracting an entire disk image on a regular basis without your knowledge it's probably just as feasible for them to replace it with a file system that's more convenient for them (think "decrypts on mounting then only pretends to encrypt thereafter") just as discreetly.


This is very much about dealing with how much an attacker can discover by continually imaging your encrypted disk that hides crypto in free blocks:



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.