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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
