1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
1. Introduction
---------------
Kernels more recent than 2.6.12 have dropped support for devfs, which
means that initrd-tools can no longer be used to boot into an encrypted
root partition. Instead, a similar functionality has been developed for
use with an initramfs-image.
2. A fresh installation
-----------------------
If you plan to perform a completely new installation of Debian onto a
machine and to do so using an encrypted root partition, you might want
to consider using a version of Debian Installer with partman-crypto
(see http://wiki.debian.org/DebianInstaller/PartmanCrypto).
The installation will then take care of all the details and perform the
necessary configuration for you, meaning that you should not have to
read the rest of this document to get a machine with an encrypted
root fs up and running.
However, if you are not planning to perform a new installation from scratch,
the following information might be useful to you.
3. Requirements
---------------
In order to boot from an encrypted root fs, you need an initramfs-image
which includes the necessary kernel modules and scripts to setup
the root device after the kernel has been initialized, but before the rest
of the operating system is booted.
To do so, you need two partitions:
- an unencrypted /boot partition
- an encrypted / partition
In addition, you need to have initramfs-tools installed.
NOTE: You should make sure that your swap partition is either encrypted, or
that you are using a swap file on an encrypted partition, as crypto keys and
other sensitive information might otherwise be written out to the swap
partition in unencrypted form.
4. Setup (regular dm-crypt)
---------------------------
First of all, you must edit /etc/crypttab and add a line describing your
root device, for example:
cryptroot /dev/hda2 none cipher=aes-cbc-essiv:sha256,size=256,hash=sha256
This will allow cryptsetup to create /dev/mapper/cryptroot from the
encrypted partition /dev/hda2 during boot.
In addition, you must also make sure that the root device is listed in
/etc/fstab, for example:
/dev/mapper/cryptroot / ext3 defaults 0 1
This will allow the initramfs support scripts to know which of the devices
in the crypttab that is the root device.
After doing these changes, you should regenerate the initramfs by running
"initramfs-update -u", then make sure that your boot loader is configured
to feed the initramfs to the kernel when booting. The kernel root argument
should also be changed to /dev/mapper/cryptroot.
Now, reboot the machine, and if everything is correctly configured, you
should be given a prompt to type in the passphrase for the encrypted
root partition before the boot can continue.
NOTE: the initramfs scripts default to using the sha256 hash function while
the plain cryptsetup binary defaults to using the ripemd160 hash function.
In order to ensure that the crypto setup works in a consistant manner, you
should make sure that the hash function is specified in the /etc/crypttab file
if you are using regular dm-crypt (with LUKS the hash function to use is stored
in the LUKS header).
5. Setup (using LUKS)
---------------------
If you are using the LUKS feature of cryptsetup, the above setup recipe should
still apply, but since most options can be derived from the information stored
in the LUKS header on-disk, the line to add to /etc/crypttab should look
something like this:
cryptroot /dev/sda2 none luks
6. Exotic key types
-------------------
The above examples assume that you use a regular passphrase as the key to the
encrypted filesystem. However, if you wish to make use of more complex setups
(such as root-key-on-usb-memory), you can create a script which does all the
steps necessary to retrieve the key and then prints it to stdout.
Then add a keyscript=/path/to/your/script.sh to the options (fourth column) in
the above mentioned /etc/crypttab line, so that it looks something like this:
cryptroot /dev/sda2 none luks,keyscript=/usr/local/sbin/cryptkey
Next, regenerate your initramfs image. This will copy the script into the
initramfs image as /sbin/cryptgetpw.
NOTE: there is a limited set of tools available when the script is executing
as part of the initramfs bootup, you have to make sure that you do not use
any tools which are not available or your script, and therefore boot, will
fail.
7. "cryptopts" boot argument
----------------------------
In general, you should use the above approach with a line describing your
root partition in /etc/crypttab and /etc/fstab. However, if for some reason
you wish to override the settings that are derived from these files and
stored in the initramfs image, you can use the "cryptopts" boot argument
(this *only* works for the root partition).
The format of cryptopts is:
cryptopts=<opt1>=<value1>,<opt2>=<value2>...
Beside the "hash", "size", "cipher" and "lvm" options that correspond to the
same options in the fourth field of /etc/crypttab, the options "target",
"source" and "key" are also supported. They correspond to the first, second
and third field of /etc/crypttab, respectively. See the crypttab man page
for further details.
Several "cryptopts" boot arguments can also be specified in case more than
one mapping needs to be setup in the initramfs stage of the boot.
Example boot arguments:
root=/dev/mapper/crypt0 cryptopts=target=crypt0,source=/dev/hda1,cipher=twofish
8. Resume device support
------------------------
The initramfs scripts will also try to automatically determine the devices,
if any, that are used for software suspend (swsusp, suspend2 or uswsusp) and
to set them up during the initramfs stage in order to allow suspend and resume
in combination with encryption to keep the resume image safe from potential
attackers.
Note: this will not work as expected until #398302 has been fixed as the
decrypted suspend image will currently not be recognized as such.
If your resume device and your root partition use two different cryptsetup
mappings, you might want to use the "decrypt_derived" keyscript as described
below.
9. The "decrypt_derived" keyscript
----------------------------------
Assume that you have two entries in /etc/crypttab:
cryptroot /dev/hda1 none luks
cryptswap /dev/hda2 none luks
If cryptswap is used as your suspend/resume device, you'd normally need to
enter two different passphrases during the boot, but the "decrypt_derived"
script can generate the key for the second mapping using a hash of the key
for the first mapping.
In short, you'll need to do something like the following to take advantage
of the decrypt_derived script:
1) swapoff -a
2) cryptsetup remove cryptswap
3) edit /etc/crypttab and change the cryptswap line to e.g.:
cryptswap /dev/hda2 cryptroot cipher=aes-cbc-essiv:sha256,size=256,hash=sha256,keyscript=/lib/cryptsetup/scripts/decrypt_derived
4) /etc/init.d/cryptdisks start
5) Make sure that /dev/mapper/cryptswap has been created
6) mkswap /dev/mapper/cryptswap
7) swapon -a
8) (optional) update-initramfs -u
After you've followed the above steps, your swap device should be setup
automatically after the root device has been setup during the boot stage.
-- David Härdeman <david@hardeman.nu>
|
