a possible "attack" on dm-crypt

(Sorry if this appears twice on the list, used the wrong sender address at first).

Hi.

I was discussing that already with Jonas Meurer, who maintains cryptsetup within Debian, but we did not came to some real conclusion, I guess.
Therefor I thought it might be a good idea to put this for some general discussion at the list.

I think there might be some attack on dm-crypt,... not technically on dm-crypt itself, but on how it is used by scripts and other stuff around it.

In theory, dm-crypt gives only encryption, but not integrity or even authenticity, right?
But I guess in theory it _does_ give you some kind of integrity and authenticity, because while an attacker (who gets physical access to the storage medium) can of course change anything on it, he does not know what he should change (to which value at which position) in order to really make a successful attack (e.g. adding a key-logger or some root-kit).
Of course he can always make kind of a DoS attack and simply destroy the medium,... but there is no prevention for this anyway.

So I claim, dm-crypt gives you - when used "correctly" - also a high level of security against attacks where people do not just want to read your data, but where they want to hack your system (with root-kits, etc.), e.g. while you're away at lunch or holidays.

With "using it correctly" I basically mean, that it only works, if really the whole system (e.g. laptop HDD) or so is encrypted. Not only the data partitions and swap, but also the root-filesystem itself. The critical place is now the bootloader and /boot (kernel+initrd). There's no way to encrypt and therefore secure those guys against compromise.
So you might argue, that an attacker who wants to install some rootkit or whatever, could simply hack my kernel/initrd/bootloader in such a smart way,... that the rootkit/etc. is automatically installed, once I've booted/decrypted the system. The above claim of integrity/authenticity protection would be gone.

A simple (and I guess the only way) to avoid this, is if you take bootloader/kernel/initrd always with you, e.g. on a small USB-stick that can be attached to your keyring.
Then you'd recognise whenever some tries to change them on that stick,.. because it is always with you.
Of course CIA/NSA could simply kidnap you and take the stick by force,.. but then you'd know at least.
Of course mighty evil attackers could even go further and simply replace your hardware (CPU,etc) with one that is so cleverly hacked,... that it installs the root-kit/etc. but I guess we can never protect against this.

I guess the above "setup" is quite secure, at least against all kinds of normal attacker who don't have millions of € or so, and actually all people using dmcrypt that I know, use it in exactly that way, because all of them are really security paranoid nerds ;)

So much for the intro ;) Now where does the attack on this come in? I guess an attacker could exchange one of your encrypted volumes with a non-encrypted (!) volume (that is compromised of course), or you could accidentally put that booting-USB-stick in a non secure system, and leak your key.

cryptsetup (or better said "setting up the mapping of an encrypted volume") happens in many places and it can happen on plain dm-crypt volumes or on LUKS volumes:
- I can happen "during" the initramfs image by some scripts preparing the root-fs.
- It can happen "during" the (non-initramfs) init, e.g. as in Debian's /etc/init.d/cryptdisks and /etc/init.d/cryptdisks-early scripts.
- It can happen by using wrapper scripts, e.g. Debian's cryptdisks_start.
- It can happen when the user manually uses cryptsetup (e.g. luksOpen).

At a first glance, all of them seem to be safe (and they are in fact):
-plain dm-crypt
I you set up a mapping for the wrong device (either one that is encrypted, but where the key doesn't fit to, or one which is not encrypted at all), you'll get some device but this contains only garbage.

-LUKS
I you set up a mapping for the wrong device (either one that is encrypted, but where the key doesn't fit to, or one which is not encrypted or not an LUKS volume at all), you'll get an error, as the master-key cannot be decrypted (aka the key slot cannot be unlocked).

BUT: There are many scripts around the usage of crypt setup, which is why I think one might be prone to attacks in both cases (plain and LUKS):
-plain dm-crypt
As far as I understood e.g. Debian's cryptsetup package, it makes a check (the check= option in crypttab) after the mapping has been set up. This is per default a simple blkid to check whether a known filesystem has been found.
If the test results in a false (which would be most likely the case in that attack scenario) the mapping is removed, right? (Jonas can confirm or deny this probably much better than I can :) .)
-LUKS
Well there won't be any device at all, as the mapping could not been set up.

If the scripts that invoked cryptsetup (e.g. the ones from your secure initramfs image) don't fail and really _stop_ now one can run into the following troubles:
Another script "around" may try to mount the filesystem on that device. As it has no knowledge that setting up the mapping failed (perhaps just a warning was given) it may simply try to mount via LABEL=root. And this will most likely work. The attacker gave us an evil volume, one that is simply not encrypted. He guessed the right LABEL or he new the UUID (this is for example leaked out with many bug-report tools in Debian) and the scripts actually mounting the root-fs will simply do so and hand control over from the still secure initramfs image from your USB stick to the compromised volume.

I guess its fairly easily to show similar attack vectors for non-root-fs-volumes,.. e.g. for an encrypted /home-fs or /var-fs.

The conclusion I draw is the following:
Either
1) don't use UUID/LABEL at all. (This might be impossible, as it may be used in many places without your knowledge).
or
2) whenever it fails to set up a cryptsetup mapping, fail with most critical errors ("fail resoundingly"), in order to ensure that no one (and no script/etc) simply tries to continue and mount the filesystem.

This may seem harsh, Jonas for example argumented that he don't want to stop the boot process, just because some "unimportant" device like /home is not there.
But I guess dm-crypt/cryptsetup is all about most paranoid security. That's why we do not store the master key in multiple places, and that's way it was (AFAIK) decided to block TRIM per default.

I'm really curious for your opinions (e.g. whether we should take care on this, or other solutions, etc.) :)

Cheers,
Chris.

btw: I hope no one get's the impression that I want to point with my finger (or even offend) Debian or even Jonas (who does really great work on the cryptsetup package). :)
It's just that I'm using Debian and not the other distros.

Answers inline below, summary at the bottom. -- Arno

Correct.

So we are talking about a data-change attack here? This one is not very relevant, because it requires to steal and give back the encrpted medium or to get access that allows changing the on-disk data (requires root permissions in most cases), but not to get enough permissions to sniff the passphrase when it is input by the the user the next time.

But lets discuss it anyways, sometimes sucessful attacks come from surprising directions.

So it is even worse: The attacker cannot judge where to change things and the attacker cannot judge whether a change done was efecctive, ineffective and/or becomes obvious to the attacked user.

Indeed.

Well, dm-crypt does, but the rest of the system does not. If you can change the data on disk, then you have root access (typically, some admin may have screwed up and given user access to a block device representing a dm-crypt partition). If you have root access, you can install a keyboard sniffer, for example by modifying the cryptsetup executable, the kernel, the shell or other parts of the system. You can then record the passphrase or master key when the device is opened the next time.

And thereby you actually do not need to encrypt the root filesystem at all in most cases, as it does increase security only marginally.

Yes.

The attacker having physical access or breaking into a running system and getting root permissions was your attack scenario.

In the first case, a determined attacker could still install a (potentially physical) keyboard sniffer or patch attack code into the BIOS chips and maybe unused disk areas. In the second scenario, you cannot take the bootloader/kernel/initrd with you.

Not really. The art of pickpocket is highly developed with some folks.

Indeed. The technical term is "Tamper Evident".

If you put all non-encrypted parts of your system on portable storage and take it with you, yes that helps a lot. It is not perfect though, as an attacker could break into your system while you are using it. And takeing the storage with you does not protect against hardware/BIOS keyboard sniffers at all.

Keep in mind however, that these are high-effort attacks and are unlikely to be conducted against you due to cost reasons, unless you are specifically targetted.

Why is that a problem? Decryping a non-encrypted filesystem (as you would do on access) is immediately obvious, as the filesystem will be unaccessible, with all data turned to random bytes..

And said non-secure system could well be your laptop or main PC at home.

There will be no script "around" if your secure initramfs is still secure.

I see the issue.

My conclusions:

1. This is not a dm-crypt or LUKS problem at all

2. Helpful automatization that tries to "access something" in the presence of errors is a security risk. This is well known. Whether Debian currently overdoes it in the automation department I cannot say. I use Debian a lot, but I do not use "crypttab" as it strikes me as a not too good idea in the first place. However I would be surprised if information from "crypttab" was used for unencrypted mounting at all. And the user should either get an error message or not be asked the passphrase. Both would be highly suspicuous.

3. Just mount your encrypted volume manually and the attack goes away.

4. The whole scenario is unrealistic. An attacker with physical access (required to change data on a non-running system) would leave some kind of keyboard sniffer/recorder and collect the passphrase later.

IMO the whole thing is a nice thought experiment, but not a practical risk. It may be something to put on the list of things to make sure an implementation does not mess up.

Side note: Known keyboard sniffing possibilities:
- Chip in your PC (cheap)
- Chip in your keyboard (cheap)
- Patched BIOS (very expensive as it would need to patch the system)
- Sound recording of your keyboard while you type (moderately expensive)
- Camera pointing at keyboard (moderately expensive)
- Electromagnetic emanations (moderately expensive)

I am sure there are a few others as well.

I don't think there is a risk of misunderstandings.

Arno

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

See later parts of my previous mail.

See later parts of my previous mail.

No? Why you can simply take a laptop that was powered off, and mount it on another machine...

Actually it makes a lot of sense... if booting, e.g. from a usb stick that is always with you (and therefore secure from attacks).

Uhm? I rather talked about physical access,... on a powered off system. But in principle it does not matter whether powered off or not, as you can add hotpluggable volumes to the system.

BIOS chip and other hardware CPU, etc.) is of course always an issue we can never really solve.
keyboard sniffers can be partially knocked out by using e.g. encrypted keys (gpg, openssl) to unlock the passphrase.
An attacker would only sniff the passphrase for the encrypted key,.. not the key to decrypt the keyslot itself.

Why not? Simply after the system was booted,.. unplug the stick...

As I said...

Yes yes,... read my whole email before commenting ;)

Yes yes,... read my whole email before commenting ;)

*G*

I'm strongly sure that I said this sometimes :)

No it would not, but you have e.g.
/etc/crypttab:
# <target name> <source device> <key file> <options>
rootfs /dev/sda1 whatEver luks

/etc/fstab:
LABEL=root / ext4 defaults 0 1

Now cryptsetup's initramfs scripts fail to set up the device,... but just give a warning or so.
Then comes the initramfs script, which would do the actual mounting of the root-fs. It will not look for /dev/mapper/rootfs, but simply use /dev/disk/by-label/rootfs and that one might be there, if an attacker simply replaced the disk by a non-encrypted one.

Quite impractical for daily use... especially on the root-fs

Not necessarily. If he already has a copy of the disk, and just want's to access the data,... he only needs the key...

I've tried it already with a friend,... worked quite well... the hacked root-fs-volume even sent me the contents of his boot-usb-stick including his key.
Of course that one was still gpg encrypted,.. but then I can do dictionary attacks and so on.

Of course,.. but there's nothing we can do at the disk-encryption-level agains all these..

Cheers,
Chris.

btw: With some modern filesystems (btrfs,zfs) we should even get integrity/authenticity as they're doing checksums... That plus dm-crypt is I guess similar to MAC.

Cheers,
Chris.