Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Can I be sure that the (unencrypted) contents of my LUKS volume were not tampered with if it accepts my passhprase on an otherwise trusted system?
In other words, can an attacker with access to my encrypted LUKS partition create another encrypted partition with the same passphrase(s) as my original, but new data? I know they can't get the encryption key nor the passphrase, but can they create a new encryption key and encrypt it so that the original passphrases can decrypt it?
can they create a new encryption key and encrypt it so that the original passphrases can decrypt it?
I don't see how that would be possible.
As you already know, Luks works by generating a random "master" key which is stored in the Luks header and used to encrypt the contents of the disk. Actually there are 8 key slots which reference encrypted copies of the master key. If you open a Luks partition, you provide a passphrase to decrypt one of the encrypted master copies, which will then be used to decrypt the contents of the container.
Encrypting and decrypting the master key is done using symmetric encryption. So if someone wanted to create his own Luks partition which accepted the same passphrase as yours, he'd need to know at least one of your passphrases so that when you entered your passphrase on the fake luks container, the passphrase would be able to correctly decrypt the master key with which the data in the container was encrypted.
Can I be sure that the (unencrypted) contents of my LUKS volume were not tampered with if it accepts my passhprase on an otherwise trusted system?
No. Not knowing the passphrase does not protect the Luks container from tampering. An attacker can always overwrite any part of the container with any data he chooses; it's just that usually, when you open the container and decrypt whatever was changed, it will decrypt to random nonsense and possibly break the file system, which will then notify you that the file system got corrupted. However, it might take a while before you access a section of the filesystem that was tampered with; until you access it or run a filesystem integrity check, you won't notice any tampering was done.
That's probably not what you're worried about, but how about this scenario:
You have a Luks partition. You're very diligent, so you back it up onto another hard drive using dd (e.g. making a byte-by-byte copy of the partition).
The attacker gets hold of your backup hard disk. What he can do now is compare the two disks, the new one and the old one, and figure out there are changes. When he finds a section that looks promising to him, he can take the old section from the backup drive and copy it to the exact same spot on the productive luks partition.
Sometimes, this will fail and also result in a corrupted filesystem. However, in some cases it will work, e.g. it will change some file or directory contents back to what they were when you took the backup, without giving you any warning that the Luks partition was modified by someone else. This attack is more likely to work on older, non-journaling filesystems and it will most likely always fail on copy-on-write filesystems such as btrfs.
So, to sum up, making exact byte-level backups of a Luks partition might enable an attacker to transparently revert any change made on the productive partition to the version in the backup.
If that's a problem, you can avoid it by creating a fresh luks partition on the backup medium and copying the plaintext filesystem data inside the container instead of cloning the Luks container itself.
In order to make your Luks container tamperproof, you can build a hash sum over it whenever you're done using it and close it. You store this hash sum somewhere safe. Before you open the container the next time, you again build the hash sum and compare it to your stored one. If they match, nobody tampered with it.
The problem with this solution is that file systems are usually very large and building a hash over the whole filesystem data can take hours or days.
