Boot from fully encrypted disk which looks like unused

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.

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

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 

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.

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.

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

That would be nice.

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.

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.

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

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.

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: [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