7

One of the problems of disk encryption is providing authentication. An attacker with access to the ciphertext can modify the ciphertext at will without consequence. Given, this isn't a likely attack, but nevertheless a possible one.

An interesting thought occurred to me. My disks are encrypted with LUKS in AES-CBC ESSIV mode. I then run LVM inside of the encrypted disk, then BTRFS on the interior logical volume. If an attacker modified the ciphertext while the data was at rest, I normally would have no way of noticing that it had happened. However, since BTRFS checksums both metadata and data, a corruption would probably be noticed by the filesystem itself when trying to read that file.

Granted, BTRFS uses CRC-32 as a hash algorithm, but is my theory more or less accurate? Do I get authentication by using BTRFS in a LUKS volume?

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
Naftuli Kay
  • 6,715
  • 9
  • 47
  • 75

2 Answers2

1

No, because CRC checksums provide integrity and not authentication. CRC algorithms have a property that is known in cryptography as malleability. Even if data is encrypted and not known, it can be xored with arbitrary bits and the checksum then has to be xored with a certain function of these bits. This allows to fake CRC checksums without even knowing what the data was. This works with stream ciphers and certain block modes, not sure whether it applies to ESSIV.

Furthermore, upon short research I found Disk encryption theory article:

While CBC (with or without ESSIV) ensures confidentiality, it does not ensure integrity of the encrypted data. If the plaintext is known to the adversary, it is possible to change every second plaintext block to a value chosen by the attacker, while the blocks in between are changed to random values. This can be used for practical attacks on disk encryption in CBC or CBC-ESSIV mode.

ArekBulski
  • 332
  • 1
  • 2
  • 11
1

In a way, yes. However, btrfs will silently repair the data where possible so unless there is an unrecoverable error, you won't know. Since you use LVM and btrfs, there is a good chance the data will be fragmented making it even more difficult for an attacker to change it consistently. Offline cryptanalysis of a btrfs filesystem is complicated enough on its own as the filesystem is, in my opinion, less predictable.

In respect to this, off topic - using LVM under btrfs is redundant. Btrfs features all the goodies LVM does and more. Performance-wise this is not optimal - btrfs uses extents of its own while unaware of LVM's extents. This could result in mid-extent fragmentation. It may look like a "security" feature but it is in fact not.

If you want "authenticated" data on a filesystem, the only way is signing them or at least having an off-line hash for the entire block device or any and all subsets of blocks on the device.

cptMikky
  • 455
  • 2
  • 5
  • 1
    FYI I'm primarily using LVM to make it easier to put a swap volume in the encrypted drive as well. If it works as expected, I could probably just create a partition table in the encrypted volume and that might work for these purposes. – Naftuli Kay Jun 03 '15 at 17:10
  • Encrypted swap is yet another issue and the better approach is to have swap on a separately encrypted block device. Off-topic here though. – cptMikky Jun 03 '15 at 17:19