个人工具

UbuntuHelp:EncryptedFilesystemForExistingPartitionsOnFeisty

来自Ubuntu中文

跳转至： 导航, 搜索
Geographylogo.png 文章出处: 

https://help.ubuntu.com/community/EncryptedFilesystemForExistingPartitionsOnFeisty

Geographylogo.png 点击翻译: 

English

请不要直接编辑翻译本页，本页将定期与来源同步。

<<Include(Tag/Unsupported)>>

{i} Please refer to EncryptedFilesystems for further documentation.

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 for 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:

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. It is suggested to disregard the following unless you insist on keeping the (unnecessary) Ubuntu-logo splash screen: 

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 usplash 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 erroneously 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 setup with '/', '/boot', and swap partitions. 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 and /dev/hda99SWAP) that you have to adapt to your setup and needs, of course. 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 conversion 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 rebuilt it. Adapt the partition mount points and mappings, as if the partitions were already encrypted. First hereby is '/etc/fstab' to edit: 

#<devive>        <mountpoint>  <fstype>  <options>
#(Leave /boot setting as-is.)
/dev/mapper/root    /          ext3    defaults  0  0
/dev/mapper/swap    none       swap    sw        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
swap       /dev/hda99SWAP    /dev/random  swap,cipher=aes-cbc-essiv:sha256

The forth column 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_i586
sha256

Add the following line to '/etc/modprobe.d/aliases' to ensure that optimized aes_i586 is used for encryption: 

alias aes aes_i586

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

Grub Boot Adjustment

Take note of your kernel version, then edit '/boot/grub/menu.lst' and search for '## ## Start Default Options ##'. The default options listed in this block appear to be commented-out but are in fact actively used by Ubuntu's "automagic" update-grub feature. We adjust this section so that neither the splash screen nor kernel/OS updates will prevent you from entering your passphrase at boot time. Change the '# defoptions' line to exclude splash: 

# defoptions=quiet nosplash

Add a '# kopt' line including pound symbol, based on your kernel version (2.6.20 for Feisty) like so: 

# kopt_2_6_20=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. We then finally create a new cryptsetup-ready boot image and boot menu with: 

$ sudo update-initramfs -u
$ sudo update-grub

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 application 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 where your command prompt will change from '$' to '#'. 

$ 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_i586

And just as reminder, check the output from the 'mount' command and make sure that none of your hard disk partitions are mounted yet. Use 'umount' to unmount regular partitions, and 'swapoff' to unmount the swap partition if necessary. Here we will also erase the swap partition to prepare it for encrypted use: 

# swapoff && dd if=/dev/urandom of=/dev/hda99SWAP bs=512

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  root /dev/hda99ROOT -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 long minutes - possibly over an hour - 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. Finally, reboot into your encrypted system!

the LUKS conversion option

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 preceding. 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. Otherwise 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.

Assorted 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..
  • cprise: Tested; Changed grub instructions to ensure that root options and splash absence are retained through system upgrades; Switched to Ubuntu's 586-optimized AES which doubles throughput.
  • If you have already setup an encrypted system using plain 'aes', you can switch to 'aes_i586' by editing /etc/initramfs-tools/modules and /etc/modprobe.d/aliases as shown above, then running 'sudo update-initramfs -u'. After rebooting, the output of 'lsmod' should show the optimized module being used.
  • cprise: The instructions for separate /home partition were incomplete so I removed them. Also added directions for encrypted swap (very necessary feature).

AttachFile

取自“https://wiki.ubuntu.org.cn/index.php?title=UbuntuHelp:EncryptedFilesystemForExistingPartitionsOnFeisty&oldid=121628”