...
Enter LUKS passphrase:
failed to setup dm-crypt mapping
failed to read from key storage
Command failed: No key available with this passphrase
mount: special device -dev-mapper-root does not exist
umount: /root: not mounted
Command failed: no such device
Enter LUKS passphrase:

2. The tutorial explains about linuxrc "Basically its job will be to set up dm-crypt, ..."; but i really do not understand where this script does so. So i decided to try to solve this by inserting dm-crypt and dm-mod modules (just like it is explained here: http://wiki.blagblagblag.org/Encrypting_Root_Filesystem#Create_initrd ): so i copied dm-crypt.ko, dm-mod.ko and insmod to the initrd and added

Hi,
You're probably following the guide, right? if so, please do not skip steps unless you know exactly what you're doing, for example if you're going to differ from the initrd showed in the guide, do so with care. I highly recommend however that you follow step by step the guide, it's not hard to understand.

Quote:

1. after reboot and entering the correct LUKS passphrase

Code:

Enter LUKS passphrase:
failed to setup dm-crypt mapping
failed to read from key storage
Command failed: No key available with this passphrase
mount: special device -dev-mapper-root does not exist
umount: /root: not mounted
Command failed: no such device
Enter LUKS passphrase:

1)
Well, did you included the necessary kernel options?
http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS#Kernel_Configuration
Note: Compile them into the kernel and not as modules, if you however decide to compile them as modules, then you'll have to edit 'linuxrc' in order to load the modules before trying to luksOpen the partition.
Make sure you include the necessary ciphers as well.
2) Did you created the nodes yourself inside the initrd or you used the script ?

Check the two things I mentioned above

Quote:

2. The tutorial explains about linuxrc "Basically its job will be to set up dm-crypt, ..."; but i really do not understand where this script does so. So i decided to try to solve this by inserting dm-crypt and dm-mod modules (just like it is explained here: http://wiki.blagblagblag.org/Encrypting_Root_Filesystem#Create_initrd ): so i copied dm-crypt.ko, dm-mod.ko and insmod to the initrd and added
Code:

Again, it is best to compile dm-crypt and device-mapper into the kernel instead of modules, i will add this to the guide to avoid confusion.

Bottom line, either re-start your installation from scratch(this time follow the guide), or boot up with your livecd, luksOpen it from there, recompile your kernel, fix the initrd(do it the way it is posted on the guide), and double check everything is in place.

i will try to insert some ciphers via insmod an if this won't work, i'll check the configuration of the kernel and recompile it.
this may take some time, but i'll let you know, if it worked and how it went.

Quote:

I highly recommend however that you follow step by step the guide, it's not hard to understand.

my thought was: i have (temporarily, untill the root-encryption works) a second unencrypted root-partition wich is compiled exactly like the encrypted one. and from this system i can open/encrypt/mount the encrypted partition without any problems. so i thought, this should work from the initrd as well if i include the right modules.

Quote:

Did you created the nodes yourself inside the initrd or you used the script ?

i tried to use the script, which didn't work. so i replaced the script by one, that only checks for procfs and devfs and

Code:

mknod --mode=600 /dev/mapper/control c 10 63

just to see if it works - and it does. (at least there is no error message.)

Quote:

insmod: error inserting `dm-crypt.ko`: -1 Unknown symbol in module

this problem can be solved by inserting dm-mod.ko before dm-crypt.ko (as i figured out in the meantime) but this does nothing to solve the first problem.

The genkernel ebuild on luks.endorphin.org is pretty old and dont works with udev (at least for me) that means you have to create the devnode for your hdd manualy (ugly hack) or you have to use devfs (even uglier). I use a customized genkernel 3.3.5 to build my initramfs with udev enabled and it works reasonably well:)

Enter LUKS passphrase:
failed to setup dm-crypt mapping
failed to read from key storage
Command failed: No key available with this passphrase
mount: special device -dev-mapper-root does not exist
umount: /root: not mounted
Command failed: no such device

checking your FAQ and the luks-Mailinglist, I get a few hints but nothing helped me.

But after I disable the linuxrc-script and compiled also the SHA256 crypto in, I have success in mounting root .

Switching back to the default linuxrc, I get the error again. So I compare my linuxrc with this in your Wiki and I see that /proc is still mounted when I tried to cryptosetup root. So I disable it in your script and my gentoo boots.

So I think when you add this in your FAQ it could help more linux noobs like me.

But after I disable the linuxrc-script and compiled also the SHA256 crypto in, I have success in mounting root .

What are you exactly trying to say in this line? what do you mean by "after I disable the llinuxrc-script" ? You need that script to boot your system, otherwise you won't be able to decrypt the root partition
So what line did you comment in the linuxrc script ? did you unmounted proc later in the script ?

Also, And very important, if you used sha256 when you created the mapping, then sha256 must be compiled into the kernel, otherwise it will fail, with the error you posted above, the wiki FAQ says this, and so does the LUKS site.
Remember, all the ciphers you use must be built into the kernel(You can build them as modules, but it is simpler and better not to).

Could you post here the diff between your linuxrc script and the one posted in the wiki ? together with the ciphers you used and the relative kernel configuration.

So the only change I made, was to umount /proc after I mounted root. Is the /proc needed by cryptsetup for the ciphers ??? This would explain it.

No, I don't think /proc needs to be mounted for cryptsetup execution, your problem was the ciphers, you didn't had sha256 builted in the kernel, yet you used it when you created the mapping, therefore it failed when you tried to decrypt it. That's way it all worked fine when you recompiled your kernel with sha256 builted in.
Unmounting /proc after executing cryptsetup is not needed, but it doesn't hurt either, so there is no need to change your linuxrc script.

This paper implements a side-channel attack on the AES implemention of
the Linux kernel via dm-crypt. That is, the encryption key is reveal to
any legal user of the system by probing the processor's cache after
about 800 read/write requests.

These kinds of attacks are quite new, and there is no clear answer how to
deal with them. I presume it will take a while before we see this gap
closed. For the moment: Don't use dm-crypt on systems where users can
write to disks for that they are not authorized to know the encryption
key.
....

The attacks allow an unprivileged process to attack other processes running in parallel on the same processor, despite partitioning methods such as memory protection, sandboxing and virtualization

If I understand that sentence right, you would need access to the system via a user account for executing such unprivileged processes & exploiting the weakness.
Since this Thread is about System Encryption, meaning the whole disk (except /boot) is encrypted, there is no such way to exploit it, since the attacker doesn't even have a user account in the first place. If for example local agencies do a house search because you downloaded too many linux ISOs and find your pc shut down (i.e. not running with a user logged in) they will not be able to attack the encryption since they're also not able to gain user access.
Even if the PC is running at the time of a house search with a user logged in, the pigs will surely not start hacking for the decryption key right away, but instead shut it down, and try gaining access in their IT department later on, which I with these assumptions?
I hope I'm right with these assumptions?

Yes, I think you're right, at least I came to the same conlusion after reading it, so most of us don't have to worry about it.
I just posted it because it's interesting and to let others(that didn't knew about it) know about this.

Since this Thread is about System Encryption, meaning the whole disk (except /boot) is encrypted,

Sorry, i do not really understand which difference that makes. if i understood correctly, this kind of attack is possible, if the encrypted disk is opened and the attacker owns a process on the local machine - no matter if there are unencrypted disks/partitions as well. or did i understand something wrong?

Quote:

We discuss in detail several such attacks on AES, and experimentally demonstrate their applicability to real systems, such as OpenSSL and Linux's dm-crypt encrypted partitions

The problem seems not to be luks- (but AES-) specific. Does that mean that any currently used partition encryption-methods are affected (since they are all AES-based, aren't they?)? Or are there any elliptic-curve-cryptographic-methods yet?

if i understood correctly, this kind of attack is possible, if the encrypted disk is opened and the attacker owns a process on the local machine - no matter if there are unencrypted disks/partitions as well. or did i understand something wrong?

But how is the attacker supposed to open the disk in the first place, if it is encrypted? IMO the only way to exploit this weakness is if you give an attacker a user account on your machine or if he gets physical access to it while it is still running - if the PC is powered off, he'll need to encrypt the disk first.

Now here's my problem:
Everything is working fine basically, except that i don't like to type passwords everytime at boot, but instead I'd like to store a keyfile on my USB-Stick (but don't want to boot completely from the USB-Stick).
So I make some device nodes in the initrd for my USB-stick which is on /dev/sdb1 (sda is my harddisk):

Problem is that i get a boot message saying that /dev/sdb1 is not a valid block device, so right now I've gone back to storing that key file inside the initrd, so I can at least boot.
I have USB Support, FAT & Codepage support compiled into the kernel (not as modules), and
i see some kernel messages prior to the error telling me a low speed USB device is found.

EDIT: After 12932 reboots i finally fixed the problem myself. I had to put a "sleep 12" instead of just "sleep 1" in the linuxrc file because the USB-Stick takes very long to be fully recognized by the kernel. I also added a "sfdisk -R /dev/sdb" after that, but I don't really know if that is necessary. Anyway it's all working fine now.

Btw. the syslinux approach from the Howto didn't work for me because syslinux has incompabilities with certain kinds of Promise ATA controllers (which I unfortunately have).

Thanks for this very nice guide.
Unfortunately I couldn't get my USB-Stick to boot (propably due to the funny BIOS on my old laptop).
Also I had probs making the device-node manually - so I used devmap_mknod

I decided to combine the scripts provided by Reikinio and unixtroll.

If no USB-Stick plugged, you get the chance to enter your password manually.
If you provide a keyfile on USB-Stick, the script will use it.
Wrong password/keyfile? No cookies!

#function to halt the system
stop()
{
b=0
while [ "$b" = 0 ]
do
echo ""
echo "you are out"
sleep 60
## if you work with 2 luks-passwords (eg slot0: very long pw from usb-key and
## slot1: rather weak pw to be entered without usb-key) you might want to add
## some extra security against bruteforcing by replacing "sleep 60" with something like
## crypsetup -q luksDelKey root 1
## this will delete the key for your root-device in slot1
## BE CAREFULL - "-q" overrides any confirmation!!! - be SURE to have your
## masterkey in slot0 (and don't lose it :-)

Hi,
to answer in short: it took ages!
On my laptop I created a 50GB-partition and dd finished in >8 hours time, but it has a damn slow HDD.
So don't expect miracles...
I was shocked too, but fortunately it was my a testing system, so I just had another coffee (and quite a few more after that one)

I would suggest not to use /dev/urandom to delete your harddisk. Shred is much faster, and 3 passes are usually more than enough. Took about a few hours on my system (160gb, 7.200 RPM).
I know there's some US official paper for secure harddisk erasure suggesting 16 (IIRC) passes, but that is just totally undue. Even professional data recovery firms are usually not able to recover anything after 3 times of overwriting.
It may not be as secure as overwriting with random data, depending on the filesystem used etc. the attacker will probably recognize where the encrypted disk is filled with data, und where it's just free space. However I wasn't able to find any document backing up that this enables the attacker to decrypt more easily. A certain amount of caution & paranoia is alright, but one shouldn't blow it outta proportion.

Last edited by unixtroll on Wed Oct 12, 2005 5:48 pm; edited 1 time in total

I have encrypted me /home wish is /dev/hdb1 with aes256 +luks. I could mount it and format it and copy files etc to it at first, problem is that after the first reboot dmesg says "unknown partition table". /dev/hdb1 doesnt exist, only /dev/hdb. So i cant mount it with cryptsetup luksOpen /dev/hdb1 hdb1.

The disk is found and responds to hdparm etc. Any ideas what could be wrong and how to fix it?

but, i've a problem: i tried to starting the system with an usb-device, but when starting the system syslinux print out a message that say "the sysstem is not avabile for this device, inserit the corret device"

i'm sure that i used step by step command on the guide for creating the syslinux, another spy is that the usb-memory is readeable on Windows system