Wikula » FullDiskEncryptionTheDebianWay
Last edit
2013-01-25 16:54:03
by sx9
[ Made some little changes to correct some grammar mistakes and to improve the style a little. One Que ]
Additions
Basic Linux / aptosid experience is required to understand and follow this article! Feel free to adjust the proceeding to fit your needs (especially if your hardware setup differs).
If you want to chainload other operating systems this method can also be used to encrypt the aptosid installation only. But certain commands below should be changed carefully to install and apply changes to the correct partitions. If aptosid is NOT your first installed system on your hard drive or if you want to save information on other partitions, then you should skip the "Wiping disk and filling with random data" section, and move on to "setting partitions". To check your current partition scheme open a terminal and enter the following commands:
Warning: THESE METHODS WILL WIPE ALL DATA ON A HARDRIVE! ALL THE DATA IT CONTAINS WILL BE LOST! IF YOU DO NOT WANT THAT, THEN SKIP TO THE "SETTING PARTITIONS" SECTION! IF YOU ARE USING MULTIPLE HARD DRIVES YOU SHOULD PHYSICALLY UNPLUG THE HARD DRIVES YOU DONT WANT TO GET OVERWRITTEN TO PREVENT ANY UNWANTED DATA LOSS DURING WIPING. AFTER THE WIPING PROCESS YOU CAN PLUG THEM BACK INTO YOUR COMPUTER TO GET YOUR BOOTLOADER RIGHT.
At first we should ensure, that absolutely nothing useful can be found on your harddisk, by overwriting the entire disk with random data. Depending on the capacity of your drive, this can take a very long time (on my laptop it took about 4 1/2 hours for a 60 GB harddisk)!
Deletions
Basic Linux / aptosid experience is required to understand and follow this article! Feel free to adjust the proceeding to fit your needs (especially if you hardware setup should differ).
If you want to chainload other operating systems this method can also be used to encrypt only the aptosid installation. But care is needed to make sure you change certain commands below to install and apply changes to the correct partitions. If aptosid is NOT your first installed system on your hard drive or you want to save information on any other partitions then you want to skip the "Wiping disk and filling with random data" section, and move on to "setting partitions". To check your current partition scheme open a terminal and enter the following:
Warning: THESE METHODS WILL WIPE ALL DATA ON A HARDRIVE ! ALL DATA WILL LOST! IF YOU DO NOT WANT TO DO THAT, THEN SKIP TO "SETTING PARTITIONS"! IF YOU ARE USING MULTIPLE HARD DRIVES YOU MAY WANT TO PHYSICALLY UNPLUG THE HARD DRIVES YOU DONT WANT OVERWRITTEN TO PREVENT ANY TRAGETIES DURING WIPING, THEN PLUG THEM BACK IN AFTER WIPING TO GET YOUR BOOTLOADER RIGHT.
At first we should ensure, that really nothing useful can be found on your harddisk, by overwriting the entire disk with random data. Depending on the capacity of your drive, this can take a very long time (on my laptop it took about 4 1/2 hours for a 60 GB harddisk)!
Edit
2011-03-01 21:41:13
by hefee
[ new encryption way is much easier ]
Additions
Tested with: sidux 2009-04, 32bit + 64bit, aptosid 2010-02 64bit kde light, aptosid 2011-01 32bit kde light
successfully install, aptosid 2011-01 "Γῆρας" kernel 2.6.37.0 kde 32bit.
If you have an Verson before 2011-01 you have to do the addational steps see below.
Chrooting and recreating initramfs
Postinstallation before 2011-01
Deletions
Tested with: sidux 2009-04, 32bit + 64bit, aptosid 2010-02 64bit kde light mkdir /media/aptosid/boot
Edit
2011-01-14 15:05:30
by skullfire
Additions
successful install, aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde 64bit. chainloading with multiple hd's and choosing the correct hd in the mbr option(sda,sdb,sdc, or sdd depending on how many you have) This choice does not write to the main mbr unless you are installing on the hd where the main mbr is,but you can change bios boot order to boot from the installed hd.
Deletions
successful install, aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde 64bit. chainloading with multiple hd's and choosing the correct hd in the mbr option(sda,sdb,sdc, or sdd depending on how many you have) This choice does not write to the main mbr.
Edit
2011-01-14 14:53:54
by skullfire
Additions
*failed attempts when chainloading and the "partition" option is selected for the bootloader mbr option section of the installer.
successful install, aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde 64bit. chainloading with multiple hd's and choosing the correct hd in the mbr option(sda,sdb,sdc, or sdd depending on how many you have) This choice does not write to the main mbr.
Edit
2011-01-13 06:36:37
by skullfire
Additions
mkswap -L swap /dev/cryptVG/swap -f
Deletions
mkswap -L swap /dev/cryptVG/swap
Edit
2011-01-13 06:31:13
by skullfire
Additions
Hint: You can find out the UUIDs of your devices for the above and following steps by taking a look into the folder /dev/disk/by-uuid in one terminal:
Now open another terminal, switch to root, and edit the file /media/aptosid/etc/crypttab :
Deletions
Hint: You can find out the UUIDs of your devices for the above and following steps by taking a look into the folder /dev/disk/by-uuid as in:
Now to edit the file /media/aptosid/etc/crypttab :
Edit
2011-01-13 06:23:42
by skullfire
Additions
Warning: THESE METHODS WILL WIPE ALL DATA ON A HARDRIVE ! ALL DATA WILL LOST! IF YOU DO NOT WANT TO DO THAT, THEN SKIP TO "SETTING PARTITIONS"! IF YOU ARE USING MULTIPLE HARD DRIVES YOU MAY WANT TO PHYSICALLY UNPLUG THE HARD DRIVES YOU DONT WANT OVERWRITTEN TO PREVENT ANY TRAGETIES DURING WIPING, THEN PLUG THEM BACK IN AFTER WIPING TO GET YOUR BOOTLOADER RIGHT.
Method 1
Method 2 Using Shred
Deletions
Warning: THESE METHODS WILL WIPE ALL DATA ON A HARDRIVE ! ALL DATA WILL LOST! IF YOU DO NOT WANT TO DO THAT, THEN SKIP TO THE NEXT STEP! IF YOU ARE USING MULTIPLE HARD DRIVES YOU MAY WANT TO PHYSICALLY UNPLUG THE HARD DRIVES YOU DONT WANT OVERWRITTEN TO PREVENT ANY TRAGETIES DURING WIPING, THEN PLUG THEM BACK IN AFTER WIPING TO GET YOUR BOOTLOADER RIGHT.
Method 1
Method 2 Using Shred
Edit
2011-01-13 06:21:34
by skullfire
Additions
Warning: THESE METHODS WILL WIPE ALL DATA ON A HARDRIVE ! ALL DATA WILL LOST! IF YOU DO NOT WANT TO DO THAT, THEN SKIP TO THE NEXT STEP! IF YOU ARE USING MULTIPLE HARD DRIVES YOU MAY WANT TO PHYSICALLY UNPLUG THE HARD DRIVES YOU DONT WANT OVERWRITTEN TO PREVENT ANY TRAGETIES DURING WIPING, THEN PLUG THEM BACK IN AFTER WIPING TO GET YOUR BOOTLOADER RIGHT. Choose one of the methods below:
Method 1
Method 2 Using Shred
Using a single pass of shred should be fine for common users. You can choose as many passes as you like, but passes 1,13, and 25 write random data. A single pass will take about 1-2 hours depending on your hardware. To use a single pass of shred open a terminal, switch to root, and enter the following command:shred -n 1 -v /dev/sda
%%
Edit
2011-01-13 05:50:56
by skullfire
Additions
Hint: You can find out the UUIDs of your devices for the above and following steps by taking a look into the folder /dev/disk/by-uuid as in:
ls -al /dev/disk/by-uuid
Now to edit the file /media/aptosid/etc/crypttab :
nano /media/aptosid/etc/crypttab
Make the file look like this:
press "ctrl x" to save, then y , then enter.
Now to edit the file /media/aptosid/etc/fstab (note that aptosid installer might have already set it up correctly):
nano /media/aptosid/etc/fstab
Adjust the files for your new devices so it look like this:
press "ctrl x" to save,then y,then enter
Now to edit the file /media/aptosid/etc/initramfs-tools/modules :
nano /media/aptosid/etc/initramfs-tools/modules
Add the following to the file:
press "ctrl x" to save,then y,then enter
Create the file /media/aptosid/etc/initramfs-tools/conf.d/cryptroot :
pico /media/aptosid/etc/initramfs-tools/conf.d/cryptroot
and put the following in it:
press "ctrl x" to save,then y,then enter
Deletions
Hint: You can find out the UUIDs of your devices for the above and following steps by taking a look into the folder /dev/disk/by-uuid as in: ls -al /dev/disk/by-uuid.
Edit the file /media/aptosid/etc/crypttab to make it look like this:
Edit the file /media/aptosid/etc/fstab to make it look like this (note that aptosid installer might have already set it up correctly):
edit the file /media/aptosid/etc/initramfs-tools/modules to load:
Create the file /media/aptosid/etc/initramfs-tools/conf.d/cryptroot and put the following in it:
Edit
2011-01-13 05:27:57
by skullfire
Edit
2011-01-13 05:18:03
by skullfire
Additions
If you are chainloading you will also need to decide which system to write to the mbr of the bootloader and make any needed changes to the bootloader using the installer during installation.
Edit
2011-01-13 05:13:45
by skullfire
Additions
Options and Other Considerations
If you want to chainload other operating systems this method can also be used to encrypt only the aptosid installation. But care is needed to make sure you change certain commands below to install and apply changes to the correct partitions. If aptosid is NOT your first installed system on your hard drive or you want to save information on any other partitions then you want to skip the "Wiping disk and filling with random data" section, and move on to "setting partitions". To check your current partition scheme open a terminal and enter the following:su
fdisk -l
Wiping disk and filling with random data
Setting Partitions
Create Encrypted Container & LVM
Deletions
Preparations
Edit
2011-01-13 04:33:53
by skullfire
Additions
successful attempt with aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde full 64bit released december 27, 2010. i changed a few of the settings below during my install to use ext4 on the boot and / partitions. i also adjusted my partition size to only encrypt my aptosid LVM partition for / and swap, as i want to chainload other systems on my other partitions. this successful attempt i let the bootloader write to the mbr (default choice) making the grub of aptosid the 1st choice during system start up.
Deletions
successful attempt with aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde full 64bit released december 27, 2010. i changed a few of the settings below during my install to use ext4 on the boot and / partitions.
Edit
2011-01-13 04:22:16
by skullfire
Additions
successful attempt with aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde full 64bit released december 27, 2010. i changed a few of the settings below during my install to use ext4 on the boot and / partitions.
Deletions
successful attempt with aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde full 64bit released december 27, 2010. i changed a few of the settings below to use ext4 on the boot and / partitions.
Edit
2011-01-13 04:21:00
by skullfire
Additions
successful attempt with aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde full 64bit released december 27, 2010. i changed a few of the settings below to use ext4 on the boot and / partitions.
Deletions
*multiple attemps with aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde full 64bit released december 27, 2010, install "NOT" successful ! i believe the problem for me is in the post installation and troubleshooting. i'm not knowlegeable enough to pin point it, but the update of initramfs in post installation and troubleshooting has different results with the 12-27-2010 release.
Edit
2011-01-10 23:49:38
by skullfire
Additions
*multiple attemps with aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde full 64bit released december 27, 2010, install "NOT" successful ! i believe the problem for me is in the post installation and troubleshooting. i'm not knowlegeable enough to pin point it, but the update of initramfs in post installation and troubleshooting has different results with the 12-27-2010 release.
Deletions
*multiple attemps with aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde full 64bit released december 27, 2010, install "NOT" successful !
Edit
2011-01-10 23:35:46
by skullfire
Additions
multiple tests with Aptosid 2010-02 "Κῆρες", based on Debian sid, kernel 2.6.35 and KDE 4.4.5 full 64bit install were successful ! *multiple attemps with aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde full 64bit released december 27, 2010, install "NOT" successful !
Deletions
multiple tests with Aptosid 2010-02 "Κῆρες", based on Debian sid, kernel 2.6.35 and KDE 4.4.5 64bit install were successful !
*multiple attemps with aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde 64bit released december 27, 2010, install "NOT" successful !
Edit
2011-01-10 23:34:38
by skullfire
Additions
multiple tests with Aptosid 2010-02 "Κῆρες", based on Debian sid, kernel 2.6.35 and KDE 4.4.5 64bit install were successful !
*multiple attemps with aptosid 2010-03 "Ἀπάτη" kernel 2.6.36.2 kde 64bit released december 27, 2010, install "NOT" successful !
Edit
2010-10-26 22:48:05
by raid
[ added 2010-02 entry and notes ]
Additions
Tested with: sidux 2009-04, 32bit + 64bit, aptosid 2010-02 64bit kde light
Boot from the aptosid Live CD, and open a root-terminal.
Note: if you didn't overwrite the disk, you still have a partition table there. Erase it using the fdisk command "o".
# Set the bootable flag on partition 1:
If the kernel doesn't recognize the new partition table, reboot from the Live CD to continue.
To reinstall, if needed:
Edit the file /media/aptosid/etc/fstab to make it look like this (note that aptosid installer might have already set it up correctly):
This installation method is considered absolutely safe and solid.
FIXME: What are these 3 lines for? Answer: you might not see the partitions in /dev/cryptVG if you don't scan.
Deletions
Tested with: sidux 2009-04, 32bit + 64bit
Boot from the aptosid LiveCD?, and open a root-terminal.
# Set the bootable flag port partition 1:
Edit the file /media/aptosid/etc/fstab to make it look like this:
This installation method is considered absolutely save and solid.
FIXME: What are these 3 lines for?
Edit
2010-09-29 17:43:59
by HennR
Additions
This installation method is considered absolutely save and solid.
How to regenerate initrd
If you need to generate new initrd to boot your encrypted system chroot into it as described above.After that you can do so like this:
update-initramfs -u -k all
-u stands for update
-k specifies the version to update. Using -k all updates all initrds available.
Which superseded this article before:
http://sidux.com/index.php?module=Wikula&tag=FullDiscEncryptionLaptopLVM∞
Deletions
Installing aptosid on an encrypted harddrive (full harddisk encryption - the Debian way)
This installation method is to be considered absolutely save and solid.
Run all of these commands as root:
TODO: how to update ramdisk and add mount --bind /dev/ to the chroot preparation
Large parts of this article have shamelessly been stolen from Full disc encryption for your laptop with luks + using LVM2 (during installation) by capone, since I used his article as a template. His instructions kind of work as well, but have some flaws, which made me write this guide, since I consider this the one & only proper way, of setting up full disk encryption "the Debian way".
Edit
2010-09-28 19:22:17
by HennR
Deletions
After these changes, the "Partitioning" tab has to look like this:
Partitioning tab of the aptosid-installer
Edit
2010-09-28 13:09:36
by HennR
Additions
Please update this note if you made it with a newer release!
Motivation
/dev/sda1 /boot Unencrypted boot partition/dev/sda2 Encrypted LUKS partition holding the logical volumes
Warning: AT THIS POINT, ALL STORED DATA ON THE HARDDRIVE WILL BE LOST FOREVER!
dd if=/dev/urandom of=/dev/sda bs=10MB
pkill -USR1 ^dd$
fdisk /dev/sda
# Set the bootable flag port partition 1:
mkfs.ext3 -L boot /dev/sda1
tune2fs -c0 -i0 -o journal_data /dev/sda1
cryptsetup luksFormat -y --cipher aes-xts-plain --key-size 512 /dev/sda2
cryptsetup luksOpen /dev/sda2 sda2_crypt
FIXME: Is this still true?
pvcreate /dev/mapper/sda2_crypt
vgcreate cryptVG /dev/mapper/sda2_crypt
lvcreate -n swap -L 3G cryptVG
lvcreate -n root -l 100%FREE cryptVG
mkswap -L swap /dev/cryptVG/swap
mkfs.ext3 -L root /dev/cryptVG/root
tune2fs -c0 -i0 -o journal_data /dev/cryptVG/root
mkdir /media/aptosid
mount /dev/cryptVG/root /media/aptosid
mkdir /media/aptosid/boot
mount /dev/sda1 /media/aptosid/boot
FIXME: I think these kind of entries are no longer needed, right?
Remark: Somebody could test whether really all modules are needed.
EDIT: As it seems for 64bits only the two modules (aes-x86_64, xts) are really needed.
Remark: It is not possible, to boot this kind of installation without that file being added to the initrd-image in the next step, but strangely when doing such an installation with the Debian installer on Debian or *Ubuntu, this file is not present. I could not find out, how the Debian installer handles that matter differently. If anybody knows more about this, please leave a comment in the forum thread (see at the end of this page).
mount -t proc proc /proc
mount -t sysfs sysfs /sys
update-initramfs -u
umount proc
umount sys
exit
Done!
Remark: The keyboard might be mapped as 'qwerty' (US standard). So, if you get an error like: "cryptsetup failed, bad password or option?" have a look at this keyboard picture∞ and find the corresponding keys for your password.
Run all of these commands as root:
mkdir /media/aptosid
cryptsetup luksOpen /dev/sda2 sda2_crypt
FIXME: What are these 3 lines for?
pvscan
lvscan
lvchange -ay /dev/cryptVG/root
mount /dev/cryptVG/root /media/aptosid
mount /dev/sda1 /media/aptosid/boot
mount --bind /dev/ /media/aptosid/dev
mount --bind /proc/ /media/aptosid/proc
If you are having problems with this howto, ask your questions over here in the forum:
Forum thread for "Installing aptosid on an encrypted harddrive (the Debian way)"∞
Deletions
This howto gets updated ATM, please give me some more time :)
/dev/sda1 /boot Unencrypted boot partition
/dev/sda2 Encrypted LUKS partition holding the logical volumes
Warning: AT THIS POINT, ALL STORED DATA ON THE HARDDRIVE WILL BE LOST FOREVER!
root@aptosid:/home/aptosid# dd if=/dev/urandom of=/dev/sda bs=10MB
root@aptosid:/home/aptosid# pkill -USR1 ^dd$
root@aptosid:/home/aptosid# fdisk /dev/sda
root@aptosid:~# mkfs.ext3 -L boot /dev/sda1
root@aptosid:~# tune2fs -c0 -i0 -o journal_data /dev/sda1
root@aptosid:~# cryptsetup luksFormat -y --cipher aes-xts-plain --key-size 512 /dev/sda2
root@aptosid:~# cryptsetup luksOpen /dev/sda2 sda2_crypt
root@aptosid:~# pvcreate /dev/mapper/sda2_crypt
root@aptosid:~# vgcreate cryptVG /dev/mapper/sda2_crypt
root@aptosid:~# lvcreate -n swap -L 3G cryptVG
root@aptosid:~# lvcreate -n root -l 100%FREE cryptVG
root@aptosid:~# mkswap -L swap /dev/cryptVG/swap
root@aptosid:~# mkfs.ext3 -L root /dev/cryptVG/root
root@aptosid:~# tune2fs -c0 -i0 -o journal_data /dev/cryptVG/root
root@aptosid:~# mkdir /media/aptosid
root@aptosid:~# mount /dev/cryptVG/root /media/aptosid
root@aptosid:~# mkdir /media/aptosid/boot
root@aptosid:~# mount /dev/sda1 /media/aptosid/boot
Remark: Somebody could test whether really all modules are needed.
EDIT: As it seems for 64bits only the two modules (aes-x86_64, xts) are really needed.
Remark: It is not possible, to boot this kind of installation without that file being added to the initrd-image in the next step, but strangely when doing such an installation with the Debian installer on Debian or *Ubuntu, this file is not present. I could not find out, how the Debian installer handles that matter differently. If anybody knows more about this, please leave a comment in the forum thread (see at the end of this page).
root@aptosid:~# chroot /media/aptosid
root@aptosid:/# mount -t proc proc /proc
root@aptosid:/# mount -t sysfs sysfs /sys
root@aptosid:/# update-initramfs -u
root@aptosid:/# umount proc
root@aptosid:/# umount sys
root@aptosid:/# exit
Some cleanup before we reboot (is this necessary?):
root@aptosid:~# umount /media/aptosid/boot
root@aptosid:~# umount /media/aptosid
Done!
Remark: The keyboard might be mapped as 'qwerty' (US standard). So, if you get an error like: "cryptsetup failed, bad password or option?" have a look at that picture∞ and find the corresponding keys for your password.
TODO: Put these entries into a table for better copy/paste possibility
| header1 | header2 |
|---|---|
| cell1 | cell2 |
root@aptosid:~# cryptsetup luksOpen /dev/sda2 sda2_crypt
root@aptosid:~# pvscan
root@aptosid:~# lvscan
root@aptosid:~# lvchange -ay /dev/cryptVG/root
root@aptosid:~# mount /dev/cryptVG/root /media/aptosid
root@aptosid:~# mount /dev/sda1 /media/aptosid/boot
%%(language-ref)
TODO: Create new forum topic and link to it
English Forum Thread: Installing aptosid on an encrypted harddrive (the Debian way)∞
Edit
2010-09-28 06:34:50
by slam
Additions
CategoryInstall
Deletions
Installation
Edit
2010-09-27 22:12:35
by HennR
Additions
This howto gets updated ATM, please give me some more time :)
Original version comes from:
http://sidux.com/index.php?module=Wikula&tag=FullDiskEncryptionTheDebianWay∞
Installing aptosid on an encrypted harddrive (full harddisk encryption - the Debian way)
Tested with: sidux 2009-04, 32bit + 64bit
Securing your data is not only relevant for laptop users, but should be the default for every installation (my opinion). Everbody has some sensible data on his harddisk, may it be passwords, confidential documents, pictures, emails, downloaded copyrighted stuff, whatever. If your computer gets stolen, or if you get busted by the police (why should you?), it would be all open to the offender. That's what we are trying to prevent here, by encrypting just about everything on your harddisk, so that nobody without the passphrase can get a clue, what's on it. This method even ensures, that you can savely hibernate your computer, because the swap-partition is an encrypted volume as well.
The Debian installer (which is also used by Ubuntu & Co) already has a nice option to perform an installation with full harddisk encryption, which means just a small unencrypted /boot partition, and everything else on an encrypted LUKS partition. Unfortunately aptosid is not using the Debian installer, and since it's a LiveCD?, some manual work is required to get to the same result.
This article is about installing aptosid onto an empty harddisk, so be sure, that there is no data on it, that you still need, because it will get DELETED! DO NOT FOLLOW THESE INSTRUCTIONS, IF YOU HAVE A MULTIBOOT ENVIRONMENT, OR ANYTHING ELSE ON YOUR HARDDISK, THAT MATTERS TO YOU!
Once the installation is finished, your drive will look like this:
Partition Mountpoint Comment
/dev/sda1 /boot Unencrypted boot partition
/dev/sda2 Encrypted LUKS partition holding the logical volumes
Basic Linux / aptosid experience is required to understand and follow this article! Feel free to adjust the proceeding to fit your needs (especially if you hardware setup should differ).
Preparations
Boot from the aptosid LiveCD?, and open a root-terminal.At first we should ensure, that really nothing useful can be found on your harddisk, by overwriting the entire disk with random data. Depending on the capacity of your drive, this can take a very long time (on my laptop it took about 4 1/2 hours for a 60 GB harddisk)!
Warning: AT THIS POINT, ALL STORED DATA ON THE HARDDRIVE WILL BE LOST FOREVER!
root@aptosid:/home/aptosid# dd if=/dev/urandom of=/dev/sda bs=10MB
If you want to check the progress, open another root-terminal and enter:
root@aptosid:/home/aptosid# pkill -USR1 ^dd$
Once this is finished, we create our two partitions:
root@aptosid:/home/aptosid# fdisk /dev/sda
Command (m for help): n
p
Partition number (1-4): 1
First cylinder (1-7296, default 1): [Enter]
Last cylinder or +size or +sizeM or +sizeK (1-7296, default 7296): +256M
Command (m for help): a
Partition number (1-4): 1
Command (m for help): n
p
Partition number (1-4): 2
First cylinder (33-7296, default 33): [Enter]
Last cylinder or +size or +sizeM or +sizeK (33-7296, default 7296): [Enter]
Command (m for help): p
Disk /dev/sda: 60.0 GB, 60011642880 bytes
255 heads, 63 sectors/track, 7296 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x65da6411
Device Boot Start End Blocks Id System
/dev/sda2 33 7296 58348080 83 Linux
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
Format the /boot partition and apply some optimizations (which I always use for !ext3, check the !tune2fs manpage for details):
root@aptosid:~# mkfs.ext3 -L boot /dev/sda1
root@aptosid:~# tune2fs -c0 -i0 -o journal_data /dev/sda1
Now we create the encrypted container on the second partition, and open it as sda2_crypt, which will create the device-node /dev/mapper/sda2_crypt:
root@aptosid:~# cryptsetup luksFormat -y --cipher aes-xts-plain --key-size 512 /dev/sda2
root@aptosid:~# cryptsetup luksOpen /dev/sda2 sda2_crypt
Remark:
Choose your passphrase wisely, because if you ever should forget it, you are doomed!
Choose a sufficient long password as well (16+) and use many different characters (special chars, capitals etc)!
A LUKS encrypted partition has 8 key slots, which means you can have more than one passphrase to unlock the encrypted container, and you can change your passphrase afterwards (by first adding another one, and then deleting the former one), which is recommended from time to time. Please have a look at the manpage (man cryptsetup) for more details.
Additionally: do not encrypt partitions over 1TB, since the aes-xts-plain security guarantee deteriorates as more data is encrypted with the same key.
Next comes the creation of the LVM physical volume, volume group and volumes onto the encrypted container:
root@aptosid:~# pvcreate /dev/mapper/sda2_crypt
root@aptosid:~# vgcreate cryptVG /dev/mapper/sda2_crypt
root@aptosid:~# lvcreate -n swap -L 3G cryptVG
root@aptosid:~# lvcreate -n root -l 100%FREE cryptVG
This creates a logical volume for swap with 3 GB (= /dev/!cryptVG/swap), and allocates the remaining free space to the logical volume for our / (= /dev/!cryptVG/root). Since I want to use hibernation, and my laptop has 2 GB RAM, I think, 3 GB for swap is a good number, and since it is all contained in one encrypted physical partition, The point for splitting up / into more separate logical volumes is increased security and preventing your system of growing out of space, the con is that you have choose wisely the space you allocate. But using a separate partition for /var is also used sometimes on production servers. A more practical case for a general case is having a separate partition to put the data that matters all in same place which allow for simple backup, if you want to be able to have a copy on you, consider using a virtual drive (a simple file used as a loop device.
The final step of our preparations is to create the filesystems on the logical volumes, create the necessary mountpoints, and mount our new / and /boot partitions:
root@aptosid:~# mkswap -L swap /dev/cryptVG/swap
root@aptosid:~# mkfs.ext3 -L root /dev/cryptVG/root
root@aptosid:~# tune2fs -c0 -i0 -o journal_data /dev/cryptVG/root
Installation
Now it is time to start the aptosid-installer.In the second tab (Partitioning), have a look, if /dev/!sda1 shows up in the device-list. If not (like it was in my case), start gparted by clicking on "Execute", quit it without changing anything, and /dev/!sda1 should be shown now.
You only need to unselect "format with ext3", and select /boot as mountpoint for /dev/!sda1.
After these changes, the "Partitioning" tab has to look like this:
Partitioning tab of the aptosid-installer
Then configure the settings in the other tabs, and finally start the installation.
If the Installer doesnt recognize the crypt partitions, start gparted through the 'execute' button, reinstall the Installer or manually include the mountpoints in /root/.sidconfig
apt-get update && apt-get install --reinstall install-gui
Post-Installation
Now mount the disks.root@aptosid:~# mkdir /media/aptosid
root@aptosid:~# mount /dev/cryptVG/root /media/aptosid
root@aptosid:~# mkdir /media/aptosid/boot
root@aptosid:~# mount /dev/sda1 /media/aptosid/boot
Once the installation has finished, we need to modify a few things to tell our new system about our encrypted setup.
Hint: You can find out the UUIDs of your devices for the above and following steps by taking a look into the folder /dev/disk/by-uuid as in: ls -al /dev/disk/by-uuid.
Edit the file /media/aptosid/etc/crypttab to make it look like this:
# <target name> <source device> <key file> <options>
# /dev/mapper/sda2_crypt = /dev/dm-0
sda2_crypt /dev/disk/by-uuid/[UUID of your /dev/sda2] none luks
Replace [UUID of your /dev/!sda2] with the actual UUID of your /dev/!sda2.
Edit the file /media/aptosid/etc/fstab to make it look like this:
# <filesystem> <mount point> <fstype> <mount options> <dump> <pass>
# /dev/cryptVG/root = /dev/mapper/cryptVG-root = /dev/dm-2
UUID=[UUID of your /dev/dm-2] / ext3 defaults,errors=remount-ro,noatime,user_xattr 0 1
# /dev/sda1
UUID=[UUID of your /dev/sda1] /boot ext3 noatime 0 2
# /dev/cryptVG/swap = /dev/mapper/cryptVG-swap = /dev/dm-1
UUID=[UUID of your /dev/dm-1] none swap sw 0 0
/dev/cdrom /media/cdrom auto noauto,rw,user,exec,utf8 0 0
Replace the three [UUID of your ...] with the actual UUIDs of your devices.
edit the file /media/aptosid/etc/initramfs-tools/modules to load:
xts
gf128
sha256
# for 32bit:
aes-i586
#for x86_64:
aes-x86_64
Remark: Somebody could test whether really all modules are needed.
EDIT: As it seems for 64bits only the two modules (aes-x86_64, xts) are really needed.
Create the file /media/aptosid/etc/initramfs-tools/conf.d/cryptroot and put the following in it:
target=sda2_crypt,source=UUID=[UUID of your /dev/sda2],lvm=cryptVG-root
Replace [UUID of your /dev/!sda2] with the actual UUID of your /dev/!sda2.
Remark: It is not possible, to boot this kind of installation without that file being added to the initrd-image in the next step, but strangely when doing such an installation with the Debian installer on Debian or *Ubuntu, this file is not present. I could not find out, how the Debian installer handles that matter differently. If anybody knows more about this, please leave a comment in the forum thread (see at the end of this page).
Now we have to chroot into our new installation and regenerate the initrd-image to incorporate the made changes:
root@aptosid:~# chroot /media/aptosid
root@aptosid:/# mount -t proc proc /proc
root@aptosid:/# mount -t sysfs sysfs /sys
root@aptosid:/# update-initramfs -u
root@aptosid:/# umount proc
root@aptosid:/# umount sys
root@aptosid:/# exit
Some cleanup before we reboot (is this necessary?):
root@aptosid:~# umount /media/aptosid/boot
root@aptosid:~# umount /media/aptosid
Done!
You are now ready to reboot into your new system.
Remark: The keyboard might be mapped as 'qwerty' (US standard). So, if you get an error like: "cryptsetup failed, bad password or option?" have a look at that picture∞ and find the corresponding keys for your password.
Additional Precautions
BIOS: Use a setup password, and configure the first boot device to be your boot-harddrive.GRUB: Set a grub password to protect your grub menu.
CRYPTSETUP: Change your passphrase for the LUKS encrypted container from time to time (have a look at man cryptsetup).
Keep in mind: Anyone with physical access to your harddrive can make changes to your /boot partition (like sniffing your password the next time you boot).
Remark: One could install /boot on an USB stick ...
Troubleshooting
This installation method is to be considered absolutely save and solid.If your encrypted machine nevertheless should not boot for any reason, simply boot from the aptosid LiveCD?, open a root-console, and mount your encrypted filesystem manually the following way, to be able to correct the problem:
TODO: Put these entries into a table for better copy/paste possibility
| header1 | header2 |
|---|---|
| cell1 | cell2 |
root@aptosid:~# cryptsetup luksOpen /dev/sda2 sda2_crypt
root@aptosid:~# pvscan
root@aptosid:~# lvscan
root@aptosid:~# lvchange -ay /dev/cryptVG/root
root@aptosid:~# mount /dev/cryptVG/root /media/aptosid
root@aptosid:~# mount /dev/sda1 /media/aptosid/boot
TODO: how to update ramdisk and add mount --bind /dev/ to the chroot preparation
Now you have full access to your installation again, and you can chroot into /media/aptosid, if needed (especially necessary, if you need to make changes to the file /etc/initramfs-tools/conf.d/cryptroot and regenerate the initrd-image).
chroot /media/aptosid
Notes
Large parts of this article have shamelessly been stolen from Full disc encryption for your laptop with luks + using LVM2 (during installation) by capone, since I used his article as a template. His instructions kind of work as well, but have some flaws, which made me write this guide, since I consider this the one & only proper way, of setting up full disk encryption "the Debian way".Questions or Comments
TODO: Create new forum topic and link to itEnglish Forum Thread: Installing aptosid on an encrypted harddrive (the Debian way)∞
Deletions
FullDiskEncryptionTheDebianWay
Oldest known version of this page was edited on 2010-09-27 22:04:19
by HennR
Full Disk Encryption - The Debian Way
FullDiskEncryptionTheDebianWay
Installation