Answers inline below, summary at the bottom. -- Arno
On Sat, Jun 05, 2010 at 03:09:51PM +0200, Christoph Anton Mitterer wrote:
> (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?
Correct.
> 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).
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.
> Of course he can always make kind of a DoS attack and simply destroy the
> medium,... but there is no prevention for this anyway.
Indeed.
> 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.
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.
> 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.
And thereby you actually do not need to encrypt the root filesystem
at all in most cases, as it does increase security only marginally.
> 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.
Yes.
> 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.
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.
> Then you'd recognise whenever some tries to change them on that stick,..
> because it is always with you.
Not really. The art of pickpocket is highly developed with some folks.
> Of course CIA/NSA could simply kidnap you and take the stick by force,..
> but then you'd know at least.
Indeed. The technical term is "Tamper Evident".
> 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 ;)
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.
>
> 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
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..
> accidentally put that booting-USB-stick in a non secure system, and leak
> your key.
And said non-secure system could well be your laptop or main
PC at home.
>
> 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.
There will be no script "around" if your secure initramfs is still secure.
> 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 see the issue.
>
> 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.) :)
>
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.
> 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.
I don't think there is a risk of misunderstandings.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx
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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
