3

In CBC mode of operation, ciphertext from previous block is used as IV in next block. How then can AES-CBC be used for disk encryption (LUKS), when the data on the disk (ie the ciphertext) keeps changing?

Whenever data is written to disk, the ciphertext is changed. Obviously, it cannot be that all subsequent blocks need to be recalculated with the changed IV. There must be some other mechanism.

How does it work ?

  • I think you are confusing blocks on the disk with blocks in the cipher. A disk block corresponds to a message, not a cipher block. This might be helpful. – David Schwartz May 5 '16 at 10:23
  • @David Schwartz - Consider the whole HDD as one big file, that keeps changing. How can then the ciphertext be used as IV, when it is not static? – Martin Vegter May 5 '16 at 10:40
  • One disk block has no effect on any other disk block. As far as the cipher is concerned, they're different messages. When a disk block changes, the new ciphertext for that block is computed and written to the hard drive. AES-CBC is used because the disk block size is larger than the cipher block size. – David Schwartz May 5 '16 at 10:43
  • You say "the changed IV". Why would the IV change? The IV is arbitrary -- it can be anything you want, public, private, whatever. Why would something ever force you to change the IV? – David Schwartz May 5 '16 at 10:45
  • @David Schwartz - Does that mean that identical disk blocks are encrypted to identical ciphertext ? – Martin Vegter May 5 '16 at 10:48
4

This is actually a quite tricky problem with no perfect solution.

If the file system was one were data is written only once and written entirely sequential, a single CBC encryption all the way from the start of the media to the end would be suitable. You can do random access decryption of CBC, you just need to read one additional cipher block. This could work for encrypting something like ISO9660.

But when random access writes are required, doing a single CBC encryption of the entire media won't work.

Ways of choosing an IV

Instead one has to encrypt each sector with a new IV. This does lead to a new problem, which is that the encrypted data is larger than the plaintext. If the underlying media was designed to be used with a secure encryption, it could very well have been designed to use slightly larger physical sectors in order to solve that problem. I haven't come across any media where this is the case. CDs do have an unusual physical block size, but the historical reasons for this are not related to encryption.

Faced with the problem of where to store the IV, various ways of cutting corners have been seen. The first and very poor approach was to simply use the sector number as IV.

The sector number is predictable. And an adversary can easily construct data patterns which will cause IV on neighboring sectors to cancel out with patterns in the data and result in two neighboring sectors on the encrypted media having exactly identical ciphertext. Multiple storage encryption products have had this vulnerability.

A slightly better approach is to encrypt the sector number and use that as IV. If you only have a single snapshot of the encrypted media, I don't know of any way to exploit this. However backups, remapped sectors on hard drives, wear leveling on SSD, use of SAN, etc. can lead to scenarios where an adversary can see more than one ciphertext encrypted using the exact same IV. At that point it will be visible to the adversary how many cipher-blocks from the start of the data is identical between the two versions.

An even better approach is to compute a cryptographic hash of sector number and all of the plaintext - except from the first block of the sector. Then encrypt the hash and use as IV. So if you are using AES which has a block size of 16 bytes, and you encrypt sectors of 512 bytes, you would hash the sector number and 496 bytes of the sector. This means IV reuse only happens if you write the exact same data to the exact same sector number. This is still a leak, though a very minor one compared to simply using sector number as IV. Unfortunately the hashing step increase the CPU usage for this approach.

Using a random IV

You can use a random IV if you can somehow store the additional data. But if physical and logical sectors have identical sizes, this means every time a plain-text sector is written, you have to write two physical sectors. This is a major problem because if a write operation is interrupted, you lose data. Write behind caching can address the slowdown associated with multiple writes being needed, but it makes the risk of data loss even worse.

Journaling could solve the data loss problem. But at that point you would be moving lots of functionality into the encryption layer, which you'd usually want at a different layer.

GBDE is the only example I know of using a disk layout in which each logical sector is stored as the full 512+16 bytes on disk. This means each 32 logical sectors are stored as 33 physical sectors. It was however designed without the journaling layer, which means there is a risk of data loss. Moreover the author of GBDE invented his own PRNG which turned out to be weak, so it isn't a great example of how to design a storage encryption.

Alternatives to CBC

The many cases of poorly chosen IVs for CBC have lead to a fairly common perception that CBC is weak. For those reasons alternatives to CBC have been considered for storage encryption. However some of the alternatives which have been proposed are even worse, for instance it has been proposed to use CTR mode which generates a pseudorandom one-time-pad. Simply using this to encrypt a media will lead to parts of the one-time-pad being reused each time you write to a sector which has previously been written.

Most usage of CBC in storage encryption as well as all the alternatives I have seen all have one thing in common. They encrypt a logical plaintext sector to a single physical ciphertext sector of the same size. This means none of them can achieve semantic security.

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.