特殊:Badtitle/NS100:EncryptedFilesystemHowto7

来自Ubuntu中文
Oneleaf留言 | 贡献2007年5月24日 (四) 11:47的版本
跳到导航跳到搜索

{{#ifexist: :EncryptedFilesystemHowto7/zh | | {{#ifexist: EncryptedFilesystemHowto7/zh | | {{#ifeq: {{#titleparts:EncryptedFilesystemHowto7|1|-1|}} | zh | | }} }} }} {{#ifeq: {{#titleparts:EncryptedFilesystemHowto7|1|-1|}} | zh | | }}



MOSTLY WRITTEN FROM MEMORY.
NEEDS TESTERS AND FEEDBACK.

Unlike Debian, the Ubuntu 7.04 FeistyFawn installer doesn't support partition encryption yet. But it has gotten way simpler to set up a fully encrypted system. This HOWTO version concentrates on converting existing partitions in-place, without reinstallation or temporary partitions and back and forth copying. It is meant experienced users, because this process is a little difficult and dangerous. There is now a simple luksConvert utility, but this guide concentrates on the -easier-to-convert-into- non-LUKS partition format. You should also be warned, that the Ubuntu bootup splash screen is somewhat quirky and makes entering your password at bootup a mystery currently (more about that later).

The HOWTOS that describe the process using temporary setups or using the manual installer are way safer and easier to follow, and only slightly slower. Specifically these are a recommended reading:

  • EncryptedFilesystemHowto6 - clean manual debootstrap installation, specifically for Feisty
  • EncryptedFilesystemHowto3 - temporary root partition method, Dapper and Edgy
  • EncryptedFilesystemHowto - contains more introduction and guidance for cryptsetup and dm_crypt

If you still want to follow this method, remember to make a backup first regardless! Some steps might be left unmentioned, as this is a HOWTO for commandline-loving and experienced users. (Okay, actually the whole topic is.)


support in Feisty Fawn

Since FeistyFawn (Ubuntu 7.04), booting from an encrypted root partition is supported without manually tweaking the boot image scripts. You just have to install a single package and regenerate the kernel boot ramdisk.

There is however a small glitch in how the crypto scripts interact with the usplash screen. This will either be fixed by an update, or later in GutsyGibbon. So if you don't want to disable the usplahs screen, take in mind:

  • The password prompt stops the usplash screen.
  • It will jump to VirtualTerminal VT8, where you have to enter your password blindly.
  • The question for the password is however errornously displayed on VT1, but you have to stay on VT8 for entering it.
  • After entering it incorrectly once (boot won't proceed), you THEN have to switch to VT1 (Ctrl+Alt+F1) to enter it.

As soon as it is available, just use the CryptorootUsplashFix...


Preparations

This HOWTO assumes, that you already have a working Ubuntu installation.

Your setup should have a separate /boot partition already. If not, please create it, and copy /boot/ over and reinstall grub with correct menu.lst settings.

We use pseudo-device names here (/dev/hda99ROOT) that you have to adapt to your setup and needs, of course. The examples assume you have already a separate /home partition as well. Just leave that part out or adapt otherwise, if this isn't the case.

Then you want to refresh your backup from last friday(!), because the procedure is highly dangerous and easily screwed with a single typo. And should the process be interrupted (power loss), your data is mostly gone.


LUKS vs plain old encryption format

As said, we convert the unencrypted partitions in-place. For that to work, it's best to not use the new LUKS encryption format. The old cryptoloop / bare dm_crypt scheme provides exactly the same encryption algorithms and security level. The only difference is that LUKS is easier to manage, and allows multiple access keys per partition.

LUKS stores the actual encryption master key and its up to 8 chiffred access keys. It uses a 516K header to store this redundantly, so in case of sector errors the master key wouldn't get lost. The master key can never be changed, but all access keys can quickly. Another advantage of LUKS is the embedding of the encryption parameters, so opening the partition later gets easier and typo resistant.

With the old format, no configuration header is embedded in an encrypted partition. It does not even store a trace of its single key on the disk. Therefore it wouldn't likewise become completely inaccessible from a hard disk failure. Since your access key is identical to the master encryption key of the whole partition, it cannot be changed as easily as with LUKS. Changing it would require another complete 'dd' in-place overwriting of the partition.

Unless you're turned off by the single-unchangeable-key restriction, you should use the old format. This is easier to convert to, and base for the following examples. This is the best approach to easily and quickly encrypt your system RIGHT NOW. Even if you now use the simple format, you could later still upgrade to LUKS. Either follow one of the temporary partition method EncryptedFilesystemHowto's, or the second part of this HOWTO.

Update: There is now a utility for conersion to the LUKS format. Since it's guided, this is actually easier than the dd-conversion. But the tool hasn't been widely tested yet, and the conversion process has by no means become any safer. (Regardless which method you use, in case of a power loss, your partition is only half-encrypted and most data inaccessible.)


configuration and boot image

We start by configuring your existing Ubuntu/Debian installation for cryptoroot support. We perform the actual encryption just thereafter.

First you want to install the cryptsetup tool:

sudo apt-get install cryptsetup

This package prepares dm_crypt and the commandline helpers. It also adds support for /etc/crypttab and hooks into initramfs.

An encrypted system must first boot the kernel and a init ramdisk from the unencrypted /boot partition. This ramdisk must contain appropriate kernel crypto modules. It will also contain the configuration settings, after we've later rebuild it.

We start by adapting the partition mount points and mappings, as if the partitions were already encrypted. First hereby is '/etc/fstab' to edit:

#<devive>        <mountpoint>  <fstype>  <options>
/dev/mapper/root    /          ext3    defaults  0  0
/dev/mapper/home    /home      ext3    defaults  0  0

You can choose the symbolic devicemapper names (/dev/mapper/*) yourself. They map back onto the former physical device from fstab. This is what '/etc/crypttab' is for. Create it as follows:

#<dmapname>  <src device>  <keyfile>  <options, encryption algorithm parameters>
root       /dev/hda99ROOT    none    cipher=aes-cbc-essiv:sha256,hash=sha1,size=128
home       /dev/hda99HOME    none    cipher=aes-cbc-essiv:sha256,hash=sha1,size=128

The forth row needs the algorithm parameters only if we use the old partition format. For LUKS this is saved in the partitions header, and 'luks' would suffice above.

The next step might be redundant, because Feisty cryptsetup does it automatically. But we here proceed to prepare '/etc/initramfs-tools/modules' so the init ramdisk contains the required kernel crypto modules. If they weren't in, booting would break as if the filesystem modules were absent. Add following:

dm_mod
dm_crypt
aes
sha256

We then finally create a new cryptsetup-ready boot image with:

sudo update-initramfs -u

Almost done. The grub boot configuration wants to be updated now as well.

Search '/boot/grub/menu.lst' for your latest kernel and boot image block. You need to get rid of the UUID=... partition specifiers, and instead use the new device mapper names 'root=/dev/mapper/root'.


title           Ubuntu, kernel 2.6.20-15-generic
kernel          /vmlinuz-2.6.20-15-generic root=/dev/mapper/root ro
...

In case you wonder, the /dev/mapper/ is not there from the beginning. Our embedded cryptoroot script will create it automatically. There are alternative cryptoroot= options to do so, but Feisty can do it automatically because of the embedded crypttab configuration.

Even if the system is now set up as if the partitions were encrypted, in emergency we still could eventually still boot. The cryptoroot boot script in the ramdisk is forgiving. So if at boot you reverse to the old names, at least the root partition should get mounted read-only.

So far for the preparations. To actually encrypt your root and home partitions, you need to reboot a LiveCD now (maybe your Ubuntu CD if you have it handy). Just remounting your partitions read-only is unlikely to work, because the partition and applicaiton binaries get scrambled while the system is still running from it. The LiveCD method is safer and recommended therefore.


bare dm_crypt / cryptoloop format

As said before, this HOWTO concentrates on the easy conversion method using the old format. The LUKS method is described in the next section.

When you are in the LiveCD system, get to a terminal or the console and become root.

sudo bash

You have to reinstall the cryptsetup tool in the LiveCD environment.

apt-get install cryptsetup

And load required kernel modules.

modprobe dm_crypt
modprobe sha256
modprobe aes

And just as reminder, let's peek at the partition table again.

fdisk -l /dev/hda

And make sure that none of your hard disk partitions is mounted yet.


encryption

Then we setup the dm_crypt loop device from the existing unencrypted root partition. Beware not to use "luksFor..." like the other HOWTOs say! This is how we create the plain dm_crypt partition format:

cryptsetup create  /dev/hda99ROOT  root  -v -y -c aes-cbc-essiv:sha256 -h sha1 -s 128

The 'create' command actually means opening the encryped data read-write. (So with the bare cryptoloop format there is just no formating step necessary as with LUKS.)

password

This command is verbose (-v), asks us twice about the password (-y), and sets the cipher (-c) and hash functions, and AES key size.

  • AES128 is sufficient for everyone, you should just take care that your password is too.
  • The 128 bit key is actually overkill until your password length goes beyond 20 characters.
  • Remember to use numerals too, at least one uppercase letter, and at least one very uncommon special character (€ or § or ...).
  • Filling in dashes and dots or 7334 letter replacements are always fine.
  • Using something like the F12 or ESC key for your password might not work with the boot image keymap. - So be careful.
  • If you write down your password, than only partially and scrambled and spread across multiple paper snippets. (Hide one part under the bed, bury one in your garden, in the bank, and so on...)
  • See also StrongPasswords and EncryptedFilesystemHowto#~How+many+bits

'dd' in-place encryption

Now we have /dev/hda99ROOT and /dev/mapper/root pointing to the same data - even if the latter would only return garbage. With a simple trick we now reverse that, making /dev/hda99ROOT scrambled by sector-wise over-copying everything. The venerable 'dd' utility comes in handy, and makes the whole process a snap due to the headerless dm_crypt format.

Just pipe one over the other, and sit back and listen how your data gets encrypted on the fly:

dd if=/dev/hda99ROOT of=/dev/mapper/root bs=512 skip=0 seek=0

This will take a few minutes - depending on your partition size.

After that be sure to sync, and unmap your dm_crypt loop device, using 'cryptsetup remove root'. If something went wrong it's too late to fix it anyhow, but you could also reopen and check your partition right now.

Then reboot. Don't forget about the usplash bug and its invisible password prompt, if you haven't yet disabled it.


the LUKS conversion process

It is recommended to follow the easier process above for initial conversion. It is however also possible to encrypt an existing partition and reshape it into the LUKS container format. This is way more dangerous and cumbersome, and not possible in all cases. Unless you can adapt the partition table, this is even slower than the temporary partition method described in the other EncryptedFilesystemHowto's.

theory

Unlike the bare dm_crypt / cryptoloop format, a LUKS partition is a container format. LUKS adds functionality by using the first 516K of the partition for itself. If we now want to convert an existing partition into the LUKS format, we have to free this space first. Since we don't want to throw away the existing data however, we need to move it around, resize the filesystem contained on the partition, or move the partition, or even all of that stuff.

The LUKS header is typically 1032 sectors in size (=8+1024). It is however not guaranteed to. (http://luks.endorphin.org/LUKS-on-disk-format.pdf) It might be any other size, because LUKS adapts itself according to the encryption scheme or other parameters, or might change everything in future versions. Now 1032 sectors seemed to be the value for me regardless if the partition was 1MB, 5GB or 40GB. Therefore let's just trust cryptsetup/LUKS on kernel 2.6.20 to use that. BUT THIS INFORMATION COMES AT ABSOLUTELY NO WARRANTY. RETAIN YOUR DAMAGE. Should it behave differently for you, then YOU are going to screw your data. (Use 'cryptsetup luksDump' on a test image to verify how it will work on your system.)

how to do it manually

Then you need to have a good partitioning program. Linux fdisk doesn't quite cut it, and even gparted might be overwhelmed by such fine-grained partition moving. The theory however is to enlarge your partitions size by exactly 1032 sectors in front of the start sector. (1032 sectors means sectors #0-#1031 added, and #1032 the former start sector.) To do so, you either need to have space in front of the partition, or resize the preceeding. Additionally some operating systems might cry about partitions not beginning at the supposed cylinder and head boundaries (even if all hard disks and the partition tables use LBA nowadays).

The other option is to resize the filesystem in your existing unencrypted partition by at least 1032 sectors and afterwards move all the data inside it. Don't use 'dd' for that! This would just smear the first sectors over everything else - because dd does operate from the beginning and not from the back (where you want to shuffle the data to).

ONLY if you somehow managed to 'free' the first 1032 sectors (516K) of your partition, you may attempt to encrypt it. The procedure is similar to the one before, but of the 'cryptsetup' calls and getting 'dd' to skip parts.

cryptsetup luksFormat /dev/hda99ROOT -v -y -c aes-cbc-essiv:sha256 -h sha1 -s 128

cryptsetup luksOpen /dev/hda99ROOT root

dd if=/dev/hda99ROOT of=/dev/mapper/root skip=1032 seek=0 bs=512

cryptsetup luksClose root

Oh, and if you seriously try that approach, remember that your initially made /etc/crypttab contains the option 'luks' rather than all the 'cipher=...' options. Otherweise the procedure is identical.


luksConvert script

I've written a script to perform the encryption and conversion. It doesn't need any partition table fixing or data moving, and works mostly like the 'dd' method. Additionally it integrates all the cryptsetup steps.

While it contains a lot of safeguards (partition checks, sector backup, cryptsetup test run), it might still screw everything up. Like this HOWTO, you therefore use it AT YOUR OWN RISK.

Before you use this tool, take care to first resize your unencrypted partitions filesystem. Shrink it by the mentioned 1032 sectors. Use resize2fs for that. This involves determining the correct block count for your partition, and subtracting 516 from that (each is 1K in size):

apt-get install resize2fs

e2fsck /dev/hda99ROOT

e2fsck 1.40-WIP (14-Nov-2006)
/dev/loop0: clean, 11/2256 files, 3750000/'''9999999''' blocks

resize2fs  /dev/hda99ROOT  '''9999450''

Using the luksConvert utility after that is a snap:

luksConvert /dev/hda99ROOT

This utility will use the defaults of this HOWTO, but you could also specify any other --cipher or --hash or --key-size, like you do with cryptsetup.

You'll get prompted for the password three times. The two first are for the internally called luksFormat, and the third for the luksOpen. After that the old unencrypted partition will be copied over automatically.

The script ends with a "write error", but this is normal operation.

download

Ok, there it is:

AttachList

Just save, and chmod +x it.


Asorted Notes

  • The examples left it out, but for the home partition you follow the same process.
        • Rather than making you prompt for its password too, you can store the key as a file on the already encrypted root partition.
        • Use 'dd if=/dev/random bs=1 count=16 of=/etc/keys/home' and add this filename in 'crypttab's third row (in place of "none").
  • An actual conversion utility for LUKS might be easy to write. Just needs a 516K ring buffer, do the luksFormat call itself, and except behave like 'dd'.
        • Ok, did it myself. Maybe it becomes part of the cryptsetup package somewhen..

AttachFile