特殊:Badtitle/NS100:EncryptedFilesystemHowto7:修订间差异

来自Ubuntu中文
跳到导航跳到搜索
Oneleaf留言 | 贡献
无编辑摘要
Wikibot留言 | 贡献
无编辑摘要
 
(未显示同一用户的7个中间版本)
第1行: 第1行:
{{From|https://help.ubuntu.com/community/EncryptedFilesystemHowto7}}
{{From|https://help.ubuntu.com/community/EncryptedFilesystemHowto7}}
{{Languages|UbuntuHelp:EncryptedFilesystemHowto7}}
{{Languages|UbuntuHelp:EncryptedFilesystemHowto7}}
 
{|border="1" cellspacing="0"
<pre><nowiki>
| {i} Please refer to [[UbuntuHelp:EncryptedFilesystems|EncryptedFilesystems]] for further documentation.
 
|}
MOSTLY WRITTEN FROM MEMORY.
Unlike Debian, the Ubuntu 7.04 [[UbuntuHelp:FeistyFawn|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).
NEEDS TESTERS AND FEEDBACK.
 
</nowiki></pre>
 
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:
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:
 
* [[UbuntuHelp:EncryptedFilesystemHowto6|EncryptedFilesystemHowto6]] - clean manual debootstrap installation, specifically for Feisty
* EncryptedFilesystemHowto6 - clean manual debootstrap installation, specifically for Feisty
* [[UbuntuHelp:EncryptedFilesystemHowto3|EncryptedFilesystemHowto3]] - temporary root partition method, Dapper and Edgy
* EncryptedFilesystemHowto3 - temporary root partition method, Dapper and Edgy
* [[UbuntuHelp:EncryptedFilesystemHowto|EncryptedFilesystemHowto]] - contains more introduction and guidance for cryptsetup and dm_crypt
* 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.)
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 ===
=== support in Feisty Fawn ===
Since [[UbuntuHelp:FeistyFawn|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:
<pre><nowiki>
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:


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.
* The password prompt stops the usplash screen.
 
* It will jump to VirtualTerminal VT8, where you have to enter your password blindly.
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 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.
* 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...
As soon as it is available, just use the CryptorootUsplashFix...
 
</nowiki></pre>
 
==== Preparations ====
==== 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.
This HOWTO assumes, that you already have a working Ubuntu installation.
We use pseudo-device names here (/dev/hda99ROOT and /dev/hda99SWAP) that you have to adapt to your setup and needs, of course.
 
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.
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 ====
==== 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.
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.
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.
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.  
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.
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.
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.
Even if you now use the simple format, you could later still upgrade to LUKS. Either follow one of the temporary partition method [[UbuntuHelp:EncryptedFilesystemHowto|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.)
'''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 ==
== configuration and boot image ==
We start by configuring your existing Ubuntu/Debian installation for cryptoroot support. We perform the actual encryption just thereafter.
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:
First you want to install the cryptsetup tool:
<pre><nowiki>
<pre><nowiki>
sudo apt-get install cryptsetup
$ sudo apt-get install cryptsetup
</nowiki></pre>
</nowiki></pre>
This package prepares dm_crypt and the commandline helpers. It also adds support for /etc/crypttab and hooks into initramfs.
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.
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.
Adapt the partition mount points and mappings, as if the partitions were already encrypted. First hereby is '/etc/fstab' to edit:
 
We start by adapting the partition mount points and mappings, as if the partitions were already encrypted. First hereby is '/etc/fstab' to edit:
<pre><nowiki>
<pre><nowiki>
#<devive>        <mountpoint>  <fstype>  <options>
#<devive>        <mountpoint>  <fstype>  <options>
#(Leave /boot setting as-is.)
/dev/mapper/root    /          ext3    defaults  0  0
/dev/mapper/root    /          ext3    defaults  0  0
/dev/mapper/home   /home      ext3   defaults  0  0
/dev/mapper/swap   none      swap   sw        0  0
</nowiki></pre>
</nowiki></pre>
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:
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:
<pre><nowiki>
<pre><nowiki>
#<dmapname>  <src device>  <keyfile> <options, encryption algorithm parameters>
#<dmapname>  <src device>  <keyfile>     <options, encryption algorithm parameters>
root      /dev/hda99ROOT    none   cipher=aes-cbc-essiv:sha256,hash=sha1,size=128
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
swap       /dev/hda99SWAP   /dev/random  swap,cipher=aes-cbc-essiv:sha256
</nowiki></pre>
</nowiki></pre>
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 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  
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:
'/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:
第94行: 第63行:
dm_mod
dm_mod
dm_crypt
dm_crypt
aes
aes_i586
sha256
sha256
</nowiki></pre>
</nowiki></pre>
 
Add the following line to '/etc/modprobe.d/aliases' to ensure that optimized aes_i586 is used for encryption:
We then finally create a new cryptsetup-ready boot image with:
<pre><nowiki>
<pre><nowiki>
sudo update-initramfs -u
alias aes aes_i586
</nowiki></pre>
</nowiki></pre>
Almost done. The grub boot configuration wants to be updated now as well.
Almost done. The grub boot configuration wants to be updated now as well.
 
==== Grub Boot Adjustment ====
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'.
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:
<pre><nowiki>
# defoptions=quiet nosplash
</nowiki></pre>
Add a '# kopt' line including pound symbol, based on your kernel version (2.6.20 for Feisty) like so:
<pre><nowiki>
<pre><nowiki>
 
# kopt_2_6_20=root=/dev/mapper/root ro
title          Ubuntu, kernel 2.6.20-15-generic
kernel          /vmlinuz-2.6.20-15-generic root=/dev/mapper/root ro
...
</nowiki></pre>
</nowiki></pre>
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.
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.
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:
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.
<pre><nowiki>
 
$ sudo update-initramfs -u
 
$ sudo update-grub
</nowiki></pre>
So far for the preparations. To actually encrypt your root and home partitions, you need to reboot a [[UbuntuHelp:LiveCD|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 [[UbuntuHelp:LiveCD|LiveCD]] method is safer and recommended therefore.
== bare dm_crypt / cryptoloop format ==
== 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.
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 [[UbuntuHelp:LiveCD|LiveCD]] system, get to a terminal or the console and become root where your command prompt will change from '$' to '#'.
When you are in the LiveCD system, get to a terminal or the console and become root.
<pre><nowiki>
<pre><nowiki>
sudo bash
$ sudo bash
</nowiki></pre>
</nowiki></pre>
You have to reinstall the cryptsetup tool in the LiveCD environment.
You have to reinstall the cryptsetup tool in the [[UbuntuHelp:LiveCD|LiveCD]] environment.
<pre><nowiki>
<pre><nowiki>
apt-get install cryptsetup
# apt-get install cryptsetup
</nowiki></pre>
</nowiki></pre>
And load required kernel modules.
And load required kernel modules.
<pre><nowiki>
<pre><nowiki>
modprobe dm_crypt
# modprobe dm_crypt
modprobe sha256
# modprobe sha256
modprobe aes
# modprobe aes_i586
</nowiki></pre>
</nowiki></pre>
And just as reminder, let's peek at the partition table again.
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:
<pre><nowiki>
<pre><nowiki>
fdisk -l /dev/hda
# swapoff && dd if=/dev/urandom of=/dev/hda99SWAP bs=512
</nowiki></pre>
</nowiki></pre>
And make sure that none of your hard disk partitions is mounted yet.
=== encryption ===
=== 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:
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:
<pre><nowiki>
<pre><nowiki>
cryptsetup create  /dev/hda99ROOT root  -v -y -c aes-cbc-essiv:sha256 -h sha1 -s 128
# cryptsetup create  root /dev/hda99ROOT -v -y -c aes-cbc-essiv:sha256 -h sha1 -s 128
</nowiki></pre>
</nowiki></pre>
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.)
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 ====
==== 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.
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.
* AES128 is sufficient for everyone, you should just take care that your password is too.
第161行: 第123行:
* Using something like the F12 or ESC key for your password might not work with the boot image keymap. - So be careful.
* 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...)
* 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
* See also [[UbuntuHelp:StrongPasswords|StrongPasswords]] and [[UbuntuHelp:EncryptedFilesystemHowto|EncryptedFilesystemHowto]]#~How+many+bits
 
==== 'dd' in-place encryption ====
==== '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.
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:
Just pipe one over the other, and sit back and listen how your data gets encrypted on the fly:
<pre><nowiki>
<pre><nowiki>
dd if=/dev/hda99ROOT of=/dev/mapper/root bs=512 skip=0 seek=0
# dd if=/dev/hda99ROOT of=/dev/mapper/root bs=512 skip=0 seek=0
</nowiki></pre>
</nowiki></pre>
 
This will take long minutes - possibly over an hour - depending on your partition size.
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.
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!
Then reboot. Don't forget about the usplash bug and its invisible password prompt, if you haven't yet disabled it.
== 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 [[UbuntuHelp:EncryptedFilesystemHowto|EncryptedFilesystemHowto]]''''''s.
 
== 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 ===
=== 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.
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)
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.)
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 ====
==== 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.)
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).
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).
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.
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.
<pre><nowiki>
<pre><nowiki>
cryptsetup luksFormat /dev/hda99ROOT -v -y -c aes-cbc-essiv:sha256 -h sha1 -s 128
# cryptsetup luksFormat /dev/hda99ROOT -v -y -c aes-cbc-essiv:sha256 -h sha1 -s 128


cryptsetup luksOpen /dev/hda99ROOT root
# cryptsetup luksOpen /dev/hda99ROOT root


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


cryptsetup luksClose root
# cryptsetup luksClose root
</nowiki></pre>
</nowiki></pre>
 
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.
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 ===
=== 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.
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.
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 [http://www.linuxcommand.org/man_pages/resize2fs8.html resize2fs] for that. This involves determining the correct block count for your partition, and subtracting 516 from that (each is 1K in size):
Before you use this tool, take care to first resize your unencrypted partitions filesystem. Shrink it by the mentioned 1032 sectors. Use [http://www.linuxcommand.org/man_pages/resize2fs8.html resize2fs] for that. This involves determining the correct block count for your partition, and subtracting 516 from that (each is 1K in size):
<pre><nowiki>
<pre><nowiki>
apt-get install resize2fs
# apt-get install resize2fs


e2fsck /dev/hda99ROOT
# e2fsck /dev/hda99ROOT


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


resize2fs  /dev/hda99ROOT  '''9999450''
# resize2fs  /dev/hda99ROOT  '''9999450''
</nowiki></pre>
</nowiki></pre>
Using the luksConvert utility after that is a snap:
Using the luksConvert utility after that is a snap:
<pre><nowiki>
<pre><nowiki>
luksConvert /dev/hda99ROOT
# luksConvert /dev/hda99ROOT
</nowiki></pre>
</nowiki></pre>
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.
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.
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.
The script ends with a "write error", but this is normal operation.
=== download ===
=== download ===
Ok, there it is:
Ok, there it is:
 
<<AttachList>>
[[AttachList]]
 
Just save, and chmod +x it.
Just save, and chmod +x it.
 
== Assorted Notes ==
 
== Asorted Notes ==
 
* The examples left it out, but for the home partition you follow the same process.
* 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.
* 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").
* 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'.  
* 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..
* 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
AttachFile
----
[[category:CategorySecurity]]


[[category:UbuntuHelp]]
[[category:UbuntuHelp]]

2008年12月16日 (二) 18:26的最新版本

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

{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