[dm-crypt] Boot from fully encrypted disk which looks like unused

[dm-crypt] Boot from fully encrypted disk which looks like unused

[dhvvcb]

Using luks is the standard way of boot from an encrypted disk. However
luks header is not encrypted and it may cause a security issue when it
is necessary to hide the fact of encryption.

Usual section of grub.conf when root file system is placed on an
unencrypted disk has the form:

title Fedora 12
root (hd0,0)
kernel /boot/vmlinuz-2.6.31.12-174.2.3.fc12.i686.PAE ro root=/dev/sda1
LANG=ru_RU.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us
rhgb quiet
initrd /boot/initramfs-2.6.31.12-174.2.3.fc12.i686.PAE.img

Boot works.

After this I rsync this file system as a whole to a filesystem on an
encrypted virtual disk /dev/mapper/hdd2 corresponding to another
physical disk, for example /dev/sdb. Then I created an additional
section in grub.conf so as to make it possible to boot from /dev/sdb. It
looks the same as above, but with some distinctions. Location of
bootloader and kernel image is unchanged (1st sector and /boot
directory), only root filesystem is transferred onto an encrypted new
device.

title Fedora 12 NEW
root (hd0,0)
kernel /boot/vmlinuz-2.6.31.12-174.2.3.fc12.i686.PAE ro
root=/dev/mapper/hdd2 LANG=ru_RU.UTF-8 SYSFONT=latarcyrheb-sun16
KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet
initrd /boot/initramfs-NEW.img

Two modifications of the initial section have been done:
1. root=/dev/sda1 ---> root=/dev/mapper/hdd2
2. initramfs-2.6.31.12-174.2.3.fc12.i686.PAE.img ---> initramfs-NEW.img

The second modification is needed to prepare /dev/mapper/hdd2 before
mounting it as a root filesystem. So changing initramfs is necessary. I
did it in the following way.

1. At the beginning of /mount/mount-root.sh, before 'mount' command, I
put the string:
cryptsetup -d /etc/key -c aes-cbc-essiv:sha256 -s 256 create
hdd2 /dev/sdb

2. key file is added to /etc

After this I reboot and select the second item in grub menu. During the
boot the messages appear:

WARNING: Deprecated config file /etc/modprobe.conf, all config files
belong into /etc/modprobe.d/.
(... the same string repeats a number of times ...)
No root device found
Boot has failed, sleeping forever 

Please, give me a suggestion what should I do to solve the problem.

Re: [dm-crypt] Boot from fully encrypted disk which looks like unused

[Arno Wagner]

On Sun, May 22, 2011 at 09:53:02PM +0600, dhvvcb@lavabit.com wrote:
> Using luks is the standard way of boot from an encrypted disk. However
> luks header is not encrypted and it may cause a security issue when it
> is necessary to hide the fact of encryption.

In practice it is basically never necessary to hide encryption.
Either it is perfectly legal for you to refuse handing over the
keys, or the presence of a large, random-looking partition or file
is already enough that they can lock you up and demand the key.

So there really is no security issue. I propose you do not try
to jump through hoops for no effect.

Maybe I should add this as a FAQ item. 

Arno

 
> Usual section of grub.conf when root file system is placed on an
> unencrypted disk has the form:
> 
> title Fedora 12
> root (hd0,0)
> kernel /boot/vmlinuz-2.6.31.12-174.2.3.fc12.i686.PAE ro root=/dev/sda1
> LANG=ru_RU.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us
> rhgb quiet
> initrd /boot/initramfs-2.6.31.12-174.2.3.fc12.i686.PAE.img
> 
> Boot works.
> 
> After this I rsync this file system as a whole to a filesystem on an
> encrypted virtual disk /dev/mapper/hdd2 corresponding to another
> physical disk, for example /dev/sdb. Then I created an additional
> section in grub.conf so as to make it possible to boot from /dev/sdb. It
> looks the same as above, but with some distinctions. Location of
> bootloader and kernel image is unchanged (1st sector and /boot
> directory), only root filesystem is transferred onto an encrypted new
> device.
> 
> title Fedora 12 NEW
> root (hd0,0)
> kernel /boot/vmlinuz-2.6.31.12-174.2.3.fc12.i686.PAE ro
> root=/dev/mapper/hdd2 LANG=ru_RU.UTF-8 SYSFONT=latarcyrheb-sun16
> KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet
> initrd /boot/initramfs-NEW.img
> 
> Two modifications of the initial section have been done:
> 1. root=/dev/sda1 ---> root=/dev/mapper/hdd2
> 2. initramfs-2.6.31.12-174.2.3.fc12.i686.PAE.img ---> initramfs-NEW.img
> 
> The second modification is needed to prepare /dev/mapper/hdd2 before
> mounting it as a root filesystem. So changing initramfs is necessary. I
> did it in the following way.
> 
> 1. At the beginning of /mount/mount-root.sh, before 'mount' command, I
> put the string:
> cryptsetup -d /etc/key -c aes-cbc-essiv:sha256 -s 256 create
> hdd2 /dev/sdb
> 
> 2. key file is added to /etc
> 
> After this I reboot and select the second item in grub menu. During the
> boot the messages appear:
> 
> WARNING: Deprecated config file /etc/modprobe.conf, all config files
> belong into /etc/modprobe.d/.
> (... the same string repeats a number of times ...)
> No root device found
> Boot has failed, sleeping forever 
> 
> Please, give me a suggestion what should I do to solve the problem.
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
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 

Re: [dm-crypt] Boot from fully encrypted disk which looks like unused

[dhvvcb]

On Mon, 23/05/2011 в 02:13 +0200, Arno Wagner wrote:
> In practice it is basically never necessary to hide encryption.
> Either it is perfectly legal for you to refuse handing over the
> keys

That is only true if you live in a civilized country. However even in GB
there is a law that requires you to hand over the key, otherwise you are
considered as a criminal. 

> or the presence of a large, random-looking partition or file
> is already enough that they can lock you up and demand the key.

That is not necessarily the case. Assume you live in a lawful country.
They should prove that a random-looking partition contains sensible
information. There is presumption of innocence. And you always may
declare that you clean the disk from private photo, for example. However
if a partition contains an indication that it is encrypted, such as luks
header, and even prompts to enter a password, they can justly demand
this password (if there is an appropriate law).

So I still think that a bit of overhead to hide encryption may
considerably increase security.

Re: [dm-crypt] Boot from fully encrypted disk which looks like unused

[Milan Broz]

One simple change will be support for detached LUKS header in some
next version of cryptsetup.
So you can have header on separate (USB or so) device or in file.
The unlocked drive then does not contain any visible metadata then.

Milan

Re: [dm-crypt] Boot from fully encrypted disk which looks like unused

[Arno Wagner]

On Mon, May 23, 2011 at 09:35:52AM +0600, dhvvcb@lavabit.com wrote:
> On Mon, 23/05/2011 ?? 02:13 +0200, Arno Wagner wrote:
> > In practice it is basically never necessary to hide encryption.
> > Either it is perfectly legal for you to refuse handing over the
> > keys
> 
> That is only true if you live in a civilized country. However even in GB
> there is a law that requires you to hand over the key, otherwise you are
> considered as a criminal. 

Indeed. And how are they going to prove that you have a key in 
the first place? Wups, right, they cannot! So they can do this 
_without_ showing that you have the key, otherwise the whole
law would be ineffective. 
 
> > or the presence of a large, random-looking partition or file
> > is already enough that they can lock you up and demand the key.
> 
> That is not necessarily the case. Assume you live in a lawful country.
> They should prove that a random-looking partition contains sensible
> information. 

They cannot. And they know that. They are prepared for this
little hitch.

> There is presumption of innocence. And you always may
> declare that you clean the disk from private photo, for example. However
> if a partition contains an indication that it is encrypted, such as luks
> header, and even prompts to enter a password, they can justly demand
> this password (if there is an appropriate law).

Not really. The LUKS header is just a hint, not proof of anything.
What if this is encrypted swap you set up with a random key?
What it this is something old and you do not remember the key?
What is this is leftover from an old installation?

Right, this could all be true and they have no way to disprove your
claim. So they will have made very sure they can lock you up
(or worse) even if you use this type of explanation and they
cannot show otherwise.
 
> So I still think that a bit of overhead to hide encryption may
> considerably increase security.

It does not. This has been discussed extensively in the 
IT security community when the UK when that way. The problem
is that they really do not need to prove anything, otherwise
you could always claim to have forgotten the password. The
thing that makes such a law highly unethical is that you
could really have forgotten the password or that the large
random-looking partition may indeed not be encrypted data.

Anyways, for any practical purpose, they can demand passwords
as soon as they have a "reasonable suspicion". The presence
of a larger pice of random data is enough for that. Obviously
you must be a terrorist if you have that and claim it is not
encrypted data. Case closed.

You are kidding yourself if you believe otherwise. Not that
many people think your way. And if the country is less civilized,
here is what would happen: http://xkcd.com/538/

And, as I said, use plain dm-crypt if you really worry
about the header. Not that it will help you if they demand
the key. Personally, I make very sure to not have anything
that looks encrypoted when, e.g. crossing teh US border.
I even wipe free space with zeros instead of my usual
crypto-randomness wipe.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
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 

Re: [dm-crypt] Boot from fully encrypted disk which looks like unused

[PsiStormYamato]

That would be nice.

On Mon, 2011-05-23 at 09:09 +0200, Milan Broz wrote:
> One simple change will be support for detached LUKS header in some
> next version of cryptsetup.
> So you can have header on separate (USB or so) device or in file.
> The unlocked drive then does not contain any visible metadata then.
> 
> Milan

Re: [dm-crypt] Boot from fully encrypted disk which looks like unused

[dhvvcb]

On Mon, 23/05/2011 at 09:09 +0200, Milan Broz wrote:
> One simple change will be support for detached LUKS header in some
> next version of cryptsetup.
> So you can have header on separate (USB or so) device or in file.
> The unlocked drive then does not contain any visible metadata then.

Reasonable intention.

Arno Wagner

You consider only two extreme situations. First, you may easily refuse
to give the key. Second, government is hunting for you and keen to find
out your secrets. You will not believe, but there are many other
situations. Opponents may not be so intelligent and they do not know
that random-looking parts of a disk can contain information. If they
suspect presence of encryption, the extent how much they will try to
affect you depends on their confidence, and presence of a cryptographic
header would apparently be bad. And so on. I don't claim that deniable
encryption guarantee personal security. However there is a lot of
situations when visible cryptographic header is definitely undesirable.
I think it is obvious and I wouldn't like to argue about that. At last,
there is no legal ground to demand the key if there is no indication of
encryption. Citizens must not explain anything. Otherwise, it is
lawlessness. They should get used to random bits.

All I am interested in this topic is how to modify initramfs so that
kernel would understand option root=/dev/mapper/hhd2 or something like
that. In brief, task is following. Bootloader (grub), kernel (vmlinuz)
and vfs (initramfs) are placed on a usb flash drive. Encrypted root file
system is placed on hdd drive (with no cryptographic header). Kernel
should be able to decrypt root file system. Any hints are welcome.