intelseek comp_help comp_help comp_help 90012004 comp_help comp_help



banner


encryption, collection of text by Mandriva and other authors:

As of mdv2009.1, cryptoloop is deprecated, and cryptoloop encrpyted filesystems will no lounger be mounted automatically. If you have any filesystems like this, you should migrate them to LUKS. You can still mount manually via a process such as this (not tested on a partition created by drakcrypt):

1) Encryption of a partition by LUKS

initscripts supports mounting of LUKS encrypted filesystems at boot, however you will have to create the encrypted volumes manually.
In recent releases of Mandriva (2009.0 and later?), diskdrake supports creation of LUKS based encrypted volumes, including during installation. Screenshots should be added here.
This section covers the (easy) task of just encrypting the /home partition. Encrypting the root partition is more complex.
Note that this was done with an LVM volume set aside for /home, if you are not using LVM, replace all occurrences of /dev/mapper/VGsys-home or /dev/VGsys/home with the partition you are using (e.g. /dev/hda6).
Creating an encrypted volume
You should be able to do this with diskdrake, either during or after installation (as of 2009.0). The command-line method was documented here before this, and is retained for completeness.
Firstly, ensure you aren't accessing the block device you are going to create the encrypted filesystem on, otherwise you will receive funny error messages.

Install the necessary software
urpmi cryptsetup-luks

Create the encrypted volume (in this case an LV)

cryptsetup -h sha256 -c twofish-cbc-essiv:sha256 -s 256 luksFormat /dev/mapper/VGsys-home

or, to use the default (aes-cbc-essiv:sha256):

cryptsetup luksFormat /dev/mapper/VGsys-home

Test that you can open the encrypted volume

cryptsetup luksOpen /dev/mapper/VGsys-home cryptohome

This should have created a new block device as /dev/mapper/cryptohome, which is the unencrypted version of /dev/mapper/VGsys-home

Create the filesystem

mkfs.ext3 /dev/mapper/VGsys-home

Close the volume

cryptsetup luksClose /dev/mapper/VGsys-home

Mounting the filesystem manually

Assuming the volume was closed, open it again:

cryptsetup luksOpen /dev/mapper/VGsys-home cryptohome

Mount the unencrypted version:

mount /dev/mapper/cryptohome /home

Mounting the filesystem at boot

To ensure the filesystem is mounted at boot, you now need to make two changes:

Edit /etc/fstab, and change the entry for /home, in my case it was from:

/dev/mapper/VGsys-home /home ext3 noatime 0 0

to

/dev/mapper/cryptohome /home ext3 noatime 0 0

Now, initscripts needs to know how to run the 'cryptsetup luksOpen' command, it does this by reading /etc/crypttab, add an entry like this:

cryptohome /dev/mapper/VGsys-home

rebuild the initrd:
bootloader-config --action rebuild-initrds

Mounting the filesystem at login

It should be possible to mount the filesystem at login using pam_mount (in contrib), just install using:

urpmi pam_mount

Removable Devices

HAL apparently has support for LUKS encrypted devices. However, on Mandriva 2007.1 under GNOME, while inserting a flash disk with a LUKS-encrypted filesystem prompts for the passphrase, entering the correct passphrase does not result in it being mounted. Under KDE4 (4.1 and later I think), click on the "Volume (crypto_LUKS)" entry in either the hardware notifier, or the "Places" panel in Dolphin, and you should get a dialog prompting you for your passphrase. Once you enter a correct passphrase, new volumes will appear (in the device notifier plasmoid and the Places panel in Dolphin). Click them to mount the filesystem. Under KDE3, no dialog appears at all. However, it can be mounted quite easily with pmount:

[bgmilne@comanche ~]$ pmount /dev/sda1
Enter LUKS passphrase:
[bgmilne@comanche ~]$ mount|grep sda1
/dev/mapper/_dev_sda1 on /media/sda1 type vfat (rw,noexec,nosuid,nodev,quiet,shortname=mixed,uid=500,gid=500,umask=077,iocharset=utf8)

2) Encrypted SWAP

While it is possible to have the SWAP partition encrypted with a random key on every boot ... what happens to resuming from suspend-to-disk ? Since encrypted partitions are usually more useful on laptops ... and so is suspending ... it seems it may not really be practical. But, in the end, if someone has stolen your laptop, the chances of them recovering data off your /home are *much* better than them being able to reconstruct documents from your swap partition (IMHO). Creating an encrypted file acting as a partition (using loopback)

The /swap Partition

We need to encrypt the swap partition, since we don’t want encryption keys to be swapped to an unencrypted disk. To do that we can first use the cryptsetup to encrypt the partition and then create a swap filesystem on it in the usual way and turn it on with swapon. The actual commands can be seen below: a) short method:
open /etc/crypttab with an editor and enter the line:
cryptswap /dev/sda6 /dev/urandom swap,check=/bin/true
The option check=/bin/true is not necessary!
After that open /etc/fstab and enter the following line for the swap-partition:
: /dev/mapper/cryptswap swap swap defaults 0 0

b) extended method:

cryptsetup -c serpent -h sha512 -d /dev/urandom create swap /dev/sda2
mkswap /dev/mapper/cryptswap
swapon /dev/mapper/cryptswap


The commands above read the key from /dev/urandom, which is appropriate for swap. If we would like to store our hibernation file on the swap partition, we can’t use the /dev/urandom, but we must use a password as with every other encrypted partition. In such cases, the key must be known in advance, since we need to be able to read the contents of swap in order to boot from the hibernation file. In such a case, we can use the commands shown below to create an encrypted swap partition:
cryptsetup --verify-passphrase --cipher serpent-cbc-essiv:sha256 --key-size 256 create swap /dev/sda2
mkswap /dev/mapper/cryptswap
swapon /dev/mapper/cryptswap
cryptsetup luksAddKey /dev/sda2 /root/keyfile

We also need to change the /etc/fstab for the system to be able to use the encrypted swap. The fstab swap entry must contain something like this:
/dev/mapper/cryptswap swap swap defaults 0 0

3) En-/decryption of this partition through a stored key

dd if=/dev/urandom of=/media/usb/key bs=4k count=1
1+0 Datensätze ein
1+0 Datensätze aus
4096 Bytes (4,1 kB) kopiert, 0,0018383 Sekunden, 2,2 MB/s
cryptsetup luksAddKey /dev/hda3 /media/usb/key
Enter any LUKS passphrase:
key slot 0 unlocked.
Command successful

cryptsetup luksOpen /dev/hda3 hda3_crypt --key-file /media/usb/key
key slot 1 unlocked.
Command successful

automated encryption for this:
edit crypttab:

#
hda3_crypt /dev/hda3 /media/usb/key luks

This is not all. Advise cryptsetup to mount the media with the key, before crypttab takes into effect. Therefore an adequate entry into /etc/fstab should not be missed, what might be the one from above.
Then enter the mountpoint into /etc/default/cryptdisks:

CRYPTDISKS_MOUNT="/media/usb"

After a decryption of all encrypted partitions, the media is unmounted automatically. At last, in order to reach more security, build up the initial ram disk:

update-initramfs -u

Also keep this password further on as a replacement. It can be deleted by cryptsetup with luksDelKey. If the USB-stick with the key is plugged in, the system is booting without manual entries, unlocking all partitions ented into crypttab. This configuration is functioning for all partitions except the root-partition. If there are programs needed for decryption almost on this partition, some more methods might become essential.

4) encryption of the root-partition by a password

a) Nach der von uns empfohlenen Methode von Gentoo: Gentoo: Linux komplett verschlüsseln - erschienen in der Kategorie Software, am 10.09.2013

b) Methode nach Andreas Janssen
Wie oben schon erwähnt kann der Bootloader das System nicht direkt von einer verschlüsselten Root-Partition hochfahren. Man benötigt also eine separate, unverschlüsselte Boot-Partition. Auf dieser befinden sich nachladbare Module des Bootloaders, der Kernel und eine initial ram disk (initrd). Diese enthält ein Minimalsystem mit Treibern für den Festplattencontroller, für das Dateisystem auf der Root-Partition und in unserem Fall auch cryptsetup. Wer ein neues System mit dem Debian-Installer einrichtet kann gleich eine Boot-Partition mit anlegen, bei einem vorhandenen System kann sie jederzeit von Hand angelegt und eingebunden werden. Bei einem vorhandenen System empfiehlt es sich außerdem, für den Umzug der Root-Partition auf eine verschlüsselte LUKS-Partition den Rechner mit einer Live-CD wie GRML (http://grml.org) zu starten und alle Änderungen von dort aus zu erledigen.
Während beim Wechsel anderer Partitionen auf dm-crypt nur die crypttab und die fstab angepasst werden müssen, reicht das bei der Root-Partition nicht aus. Es muss ebenso die Bootloaderkonfiguration geändert werden. Für dieses Beispiel gehe ich davon aus, daß grub verwendet wird und die Einträge für die Kernel automatisch durch update-grub erzeugt wurden. Als Beispiel dient wieder hda3. Ich setze ebenso voraus, daß der fstab schon hda3 durch hda3_crypt ersetzt wurde und die crypttab einen Eintrag für diese Partition enthält. In der /boot/grub/menu.lst muss nun der Root-Eintrag geändert werden. Dazu wird die #kopt-Zeile angepasst. Zum Beispiel wird

kopt=root=/dev/hda3 ro

geändert zu

kopt=root=/dev/mapper/hda3_crypt

Das Kommentarzeichen am Anfang der Zeile muss erhalten bleiben. Das Programm update-grub übernimmt die kopt-Einstellung für alle automatisch erstellten Kerneleinträge und legt eine neue menu.lst an, mit dem Befehl update-initramfs -u wird außerdem noch eine neue initrd erstellt.

Damit ist die Konfiguration abgeschlossen. Beim nächsten Neustart verlangt cryptsetup nach dem Passwort für die Root-Partition. Diese wird dann entsperrt und von der initrd aus eingehängt.

5) root-Partition mit Schlüssel auf USB-Stick

Wie normale Partitionen mit einem Schlüssel auf einem USB-Stick automatisch entsperrt werden können wurde oben schon erklärt. Um das bei der Root-Partition zu ermöglichen sind leider einige weitere Eingriffe nötig. So muss man sicherstellen daß die initrd die nötigen Treiber für den USB-Stick enthält. Außerdem funktioniert das automatische Mounten des Sticks über CRYPTDISKS_MOUNT und die fstab nicht, da die dazu nötigen Informationen in der initrd nicht vorhanden sind.

Es gibt aber eine Alternative. In der crypttab kann man der Partition ein Keyscript zuweisen, welches den Schlüssel besorgt und ihn ausgibt. Dieses Skript wird, sofern es in der crypttab eingetragen ist, automatisch in die initrd übernommen. Es muss alle zum Erlangen des Schlüssels notwendigen Schritte übernehmen, das beinhaltet das Laden der Treiber für den USB-Stick, das Anlegen eines Mountpunktes, das Mounten, die Ausgabe des Schlüssels und das Aushängen des USB-Sticks. Das Skript wird im laufenden Betrieb außer in der initrd nicht benötigt und kann zum Beispiel in /root angelegt werden. Meines sieht folgendermaßen aus:

#!/bin/sh
modprobe usb-storage 1>&2 #Kernelmodul für den USB-Stick laden
sleep 5 #5 Sekunden warten damit der Stick bereit ist
mkdir /usb 1>&2 #Mountpunkt anlegen
mount -t vfat -o ro,umask=077 /dev/sda1 /usb 1>&2 #Stick mounten
cat /usb/key #Schlüssel ausgeben
umount /usb 1>&2 #USB-Stick aushängen

Da cryptsetup den Schlüssel in der Standardausgabe des Skriptes erwartet, wird die Ausgabe aller anderen Programmaufrufe im Skript in die Fehlerausgabe umgelenkt (1>&2). Außerdem muss das Skript ausführbar sein.

Außerdem muss noch sichergestellt werden, daß die initrd alle nötigen Treiber enthält. update-initramfs fügt automatisch die Module für USB-Speicher hinzu. Die Module für das auf vielen USB-Sticks verwendete FAT-Dateisystem muss man aber ausdrücklich anfordern. Dazu werden in der Datei /etc/initramfs-tools/modules folgende Zeilen hinzugefügt:

nls_cp437
nls_iso8859_1
vfat
Als vorletztes muss nun die crypttab angepasst werden:

# hda3_crypt /dev/hda3 none luks,keyscript=/root/keyscript

Nun wird eine Kopie der alten initrd in /boot erstellt. Diese wird als Ersatz benötigt falls das Entsperren der Root-Partition nicht klappt. Dann kann nämlich das System nicht hochgefahren werden. Startet man neu und verlangt von grub, statt der neuen die alte initrd zu verwenden, kann man die Root-Partition wieder mit dem Passwort entsperren und nach dem Hochfahren den Fehler beheben. Das geht wesentlich schneller als die Benutzung einer Live-CD für diesen Zweck. Als letztes wird dann eine neue initrd erstellt:

update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.18-4-k7


Nach einem Neustart wird cryptsetup nun versuchen, den Schlüssel vom USB-Stick einzulesen und damit die Root-Partition zu entsperren. Nachdem das erfolgt ist wird von der initrd zur Root-Partition gewechselt und das System wie gewohnt hochgefahren.