← Back to branch summary

~ubuntu-branches/ubuntu/maverick/cryptsetup/maverick-proposed

« back to all changes in this revision

Viewing changes to debian/README.Debian

  • Committer: Bazaar Package Importer
  • Author(s): Martin Pitt
  • Date: 2009-11-11 15:04:27 UTC
  • mfrom: (0.1.7 squeeze)
  • Revision ID: james.westby@ubuntu.com-20091111150427-elb822l63lnihaue
Tags: 2:1.1.0~rc2-1ubuntu1
* Merge with Debian testing. Remaining Ubuntu changes:
  - debian/rules: cryptsetup is linked dynamically against libgcrypt and
    libgpg-error.
  - Upstart migration:
    + Add debian/cryptdisks-enable.upstart.
    + debian/cryptdisks{,-early}.init: Make the 'start' action of the init
      script a no-op, this should be handled entirely by the upstart job.
      (LP #473615)
    + debian/cryptsetup.postinst: Remove any symlinks from /etc/rcS.d on
      upgrade. 
    + debian/rules: Do not install start symlinks for those two, and install
      debian/cryptdisks-enable.upstart scripts.
  - Add debian/cryptsetup.apport: Apport package hook. Install in
    debian/rules, and create dir in debian/cryptsetup.dirs.
  - Start usplash in initramfs, since we need it for fancy passphrase input:
    + debian/initramfs/cryptroot-conf, debian/initramfs-conf.d: USPLASH=y
    + debian/control: Bump initramfs-tools Suggests to Depends:.

Show diffs side-by-side

added added

removed removed

Lines of Context:
debian/README.Debian
17
17
 
18
18
   7. Remotely unlock encrypted rootfs
19
19
 
20
 
   8. Credits
 
20
   8. Backup the LUKS header
 
21
 
 
22
   9. Credits
21
23
 
22
24
 
23
25
1. Introduction into Cryptsetup for Debian
131
133
 
132
134
 The 'check' option in crypttab allows to configure checks to be run against
133
135
the target device after cryptsetup has been invoked.
134
 
The default check 'vol_id' can check for any known filesystem type, as it uses
135
 
vol_id from udev. you can check for a particular filesystem by giving for
 
136
The default check 'blkid' can check for any known filesystem type, as it uses
 
137
blkid from util-linux. you can check for a particular filesystem by giving for
136
138
example 'checkargs=ext2' or 'checkargs=swap' as an option in /etc/crypttab.
137
139
 
138
140
 The 'precheck' option is for configuring checks to be run against the source
199
201
 That's it. Now that the encrypted root device is unlocked, the remote system
200
202
should continue with the boot process.
201
203
 
202
 
 
203
 
8. Credits
 
204
 /usr/share/doc/cryptsetup/README.remote.gz is a documentation with more
 
205
details on the setup of an initramfs with suppurt to remotely unlock the
 
206
encrypted rootfs.
 
207
 
 
208
 
 
209
8. Backup the LUKS header
 
210
-------------------------
 
211
 
 
212
 The LUKS header is located at the beginning of every LUKS encrypted device.
 
213
It stores information such as used cipher, hash, etc. But most importantly,
 
214
the header contains eight keyslots, which do keep an encrypted version of the
 
215
LUKS masterkey. the data on an encrypted LUKS partition is encrypted with this
 
216
masterkey. thus, there's no way to restore the data once the masterkey is
 
217
lost. For that reason, one might want to backup the LUKS header in order to
 
218
prevent accidential data loss.
 
219
 
 
220
 On the other hand keeping a backup of the LUKS header isn't recommended for
 
221
security reasons. The reason is, that LUKS was designed with key revocation in
 
222
mind. Once the LUKS header is copied to a backup, revoking a (possibly
 
223
compromised) passphrase or keyfile from the keyslot isn't enough anymore. the
 
224
revoked passphrase/keyfile can easily be reactived by writing back the header
 
225
backup to the device.
 
226
 
 
227
 If you still want to store a backup of your LUKS header with these drawbacks
 
228
in mind, at least do it the following way:
 
229
 
 
230
 Search for the 'Payload offset' in the output of
 
231
 
 
232
# cryptsetup luksDump <luks-device>
 
233
 
 
234
 Prepare a ramdisk to store the backup temporarely. You should do that in order
 
235
to prevent any hardware caching functions or filesystem jounals to copy the
 
236
backup around to places you cannot control. If you want to store the backup
 
237
permanently, write it to a read-only medium like CD immediately from ramdisk,
 
238
without your burning program writing an intermediate image to some temp dir.
 
239
 
 
240
 To actually backup the header, use the following command:
 
241
 
 
242
# dd if=<luks-device> of=<destination-on-ramdisk> count=<payload-offset>
 
243
 
 
244
 That's it. But once again, keep in mind all the security implications when
 
245
doing LUKS header backups. In general it's better to backup the data from
 
246
encrypted LUKS devices to another encrypted LUKS device. That way you can
 
247
manage the keyslots for both original and backup device independently.
 
248
 
 
249
 
 
250
9. Credits
204
251
----------
205
252
 
206
253
 People who contributed to documentation for the Debian cryptsetup package:
210
257
Bastian Kleineidam <calvin@debian.org>
211
258
Michael Gebetsroither <michael.geb@gmx.at>
212
259
 
213
 
 -- Jonas Meurer <mejo@debian.org>, Sun, 27 Jul 2008 17:02:56 +0200
 
260
 -- Jonas Meurer <mejo@debian.org>, Tue, 01 Sep 2009 12:20:51 +0200