Difference between revisions of "Talk:Dm-crypt"

From ArchWiki
Jump to: navigation, search
(Main article changed and the crypttab format is changed as the of the introduction of systemd' cryptsetup tools which uses keyfile-offset and keyfile-size options instead.)
(Restructuring: rm closed item)
 
(126 intermediate revisions by 17 users not shown)
Line 1: Line 1:
== Cleanup and Clarification ==
+
== New idea ==
Hello. This wiki page while very exhaustive in content is tangenital with a fractured flow. It seems the prefered method for straight forward system encryption in single drive systems is to use a combination of Luks and LVM2 - this solution provides for an encrypted swap that does not have any issues with hibernation or suspend. I propose making this section the first part of the wiki page to follow the justification for using Luks with the rather large volume of detailed information to follow in other sections. If there are no objections I'll go ahead and structure this in the wiki page itself.
+
The philosophy behind the <s>current</s> old structure was to try to generalize the various steps for encrypting an entire system or a device and managing it, however we've noticed it's kind of hard. A new idea for reducing duplication of content while maintaining, if not improving, readability, would be to <s>rename the "/Examples" subpage to "/Common Scenarios" and move it to first place in [[Dm-crypt with LUKS/draft]], so it's used</s> use the [[dm-crypt#Common scenarios]] section as the starting point by the readers. It should contain the most common uses for encryption, which IMO are:
[[User:Vinhsynd|Vinhsynd]] 9:55, 30 September 2010 (CDT)
+
  
Hey all, I was trying to encrypt my hd using this page as a reference, but it was a bit difficult to read. As such, I'm going to try to clean things up a bit. It would be nice if there were a clean set of instructions with tips along the way for specialized setups.
+
*[[dm-crypt/Encrypting a Non-Root File System]]
 +
**partition
 +
**loopback
 +
*[[dm-crypt/Encrypting an Entire System]]
 +
**plain dm-crypt (merge [[Plain dm-crypt without LUKS]], done)
 +
**dm-crypt + LUKS (no LVM)
 +
**LVM on LUKS (merge [[Encrypted LVM]], done)
 +
**LUKS on LVM (merge [[Encrypted LVM]], done)
 +
**(I think it would be really cool if we could also include an example with software RAID)
  
On a related note... would anyone mind if some of the posts on this page were erased? There are a number of posts from 2007, 2008...
+
Each of those scenarios should be mostly a stripped sequence of commands with short descriptions that should link to generic sections in the other subpages of <s>[[Dm-crypt with LUKS]]</s> [[dm-crypt]], pointing out all the particular suggested adaptations that apply to that particular scenario.
--[[User:Arcanazar|Arcanazar]] 13:22, 21 August 2010 (EDT)
+
  
I'm considering to do some editing and rewriting of this page, mainly in part "4 The Steps". The content would mostly stay the same, safe for some changes introduced with the newer versions of arch, where less console switching and module loading is needed. On the same subject should we drop, or move to a subsection, the parts related to versions 0.72 of arch?
+
The idea is quite clear in my mind, I hope I've managed to explain it well enough, I'll try to put it into practice and see if it raises major problems.
  
Does anyone have objections to my plans, or should I just go ahead and we can revert back if it doesn't fit?
+
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:08, 23 November 2013 (UTC)
[[User:WhiteMagic|WhiteMagic]] 12:56, 24 May 2007 (EDT)
+
  
: Clean up is really needed. Please someone with enough knowledge start the job. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 02:55, 8 June 2012 (UTC)
+
EDIT: since [[Plain dm-crypt without LUKS]] would be merged here, the main article should be just renamed to [[dm-crypt]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:09, 23 November 2013 (UTC)
  
:: Someone review the made changes to clean up. Suggested next bits to clean-up should include removing legacy Grub section after making sure the relevant kernel parameters are adequately covered in the Grub2 paras. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:14, 26 September 2012 (UTC)
+
EDIT: updated for current structure. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:31, 8 December 2013 (UTC)
 +
===Scenario structure===
 +
:Plenty of stuff to do, yet: Taking for granted we want an additional example with RAID sometime, it might be worth considering to split [[dm-crypt/Encrypting an Entire System]] into a subpage for (e.g.) [[dm-crypt/Encrypting a single disk system]] and [[dm-crypt/Encrypting a system across multiple disks]] scenarios. The latter covering "LUKS on LVM" and said RAID. Main reason: page length. If you agree, let's better do it now. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:11, 8 December 2013 (UTC)
  
== Discard/TRIM support for solid state disks (SSD) ==
+
::Not a bad idea at all! However IMHO the proposed titles are a bit misleading: I would go for [[dm-crypt/Encrypting a System on Physical Devices]] and [[dm-crypt/Encrypting a System on Virtual Devices]], in fact you ''can'' use multiple physical disks in every case if you want. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:48, 9 December 2013 (UTC)
Does leaving half the drive unpartitioned (to manually resize partition-table, LUKS and filesystems when needed) ease problems?
+
::EDIT: Note that the history of [[dm-crypt/Encrypting an Entire System]] should be preserved by ''moving'' it to one of the two titles, and then (or before) splitting the other page. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:49, 9 December 2013 (UTC)
:That's an interesting question. Before the TRIM feature was added, this was the general advice to avoid degrading SSD performance over time due. I am not aware of a general answer to this, particularly since SSDs chipsets evolve considerably still. If someone has a link to up-to-date information (e.g. a comparison of pros/cons of discard and leaving empty space on a drive) that is very worthwile adding in my opinion. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:34, 30 September 2012 (UTC)
+
:::+1 to your edit, I learned that from watching. The one letdown of this whole fun exercise is that the wiki engine does not seem to support basic content splits and joins preserving history. Anyhow, we might as well just keep it in mind and consider splitting it later (when there is something about RAID). Funnily, I find the use of "physical" (all blockdevices are on one) and "virtual" (suggests a qcow device) as differentiator not totally clear too. Let's meditate over it again until someone has another snappy idea. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:16, 9 December 2013 (UTC)
Altough the security limitation topic is already explained within other sections above I think there should be a small but explicit WarningBox about Discard/TRIM as once there already was. --[[User:Nonix|Nonix]] ([[User talk:Nonix|talk]]) 12:38, 28 September 2012 (UTC)
+
:The first two paras of that SSD trim section '''only''' talk about the security impacts and why it is not default. In my opinion that is enough. Add a regular sentence ala "As explained above in section ...", if you really feel it necessary. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:06, 29 September 2012 (UTC) I have added another sentence & link regarding TRIM issues, have a look if its better now in your view also. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:01, 2 October 2012 (UTC)
+
 
+
== Suspend to disk instructions are insecure ==
+
They cause the swap encryption key to be picked up by mkinitcpio and stored on the unencrypted /boot partition, thus rendering the encryption useless. Better still, the suspend image contains the keys for any other encrypted partitions that were currently open too...
+
 
+
Unless someone thinks otherwise, I'm going to remove the stuff about key files and replace it with a warning not to do that. I think the approach using a password should be secure, and it's somewhat workable (at least in my setup with uresume): we can place the 'openswap' and 'uresume' hooks ''before'' 'encrypt' and rely on the above-mentioned keys in the suspend image to magically have the root unlocked once the resume is complete. Downside is typing two passwords during a normal boot - it's a quick fix for the current instructions at any rate.
+
 
+
There are a few other options, but probably the tidiest strategy would be to put root and swap (and anything else) on an encrypted LVM PV, then the 'encrypt' hook can unlock everything in one go. I guess that makes a mess if the VG contain other PVs which need decrypting too, but that's probably not an issue at least for laptop users. I've not tried this though.
+
 
+
Of course, ideally there'd be support for multiple volumes (preferably with a single password prompt) in the 'encrypt' hook.
+
 
+
--[[User:Jmawebb|Jmawebb]] 19:44, 27 February 2010 (EST)
+
 
+
:Is there a fix for this yet? Maybe the luksSuspend function? --[[User:Revelation60|Revelation60]] 21:21, 20 December 2010 (GMT+1)
+
 
+
== Luks and suspend2 ==
+
Would it be worth adding a section on opening encrypted drives from the kernel command line, or more specifically on combining luks and suspend2? As far as I can tell opening a swap partition from crypttab doesn't make it available in time to resume from, but adding the following to a lilo append option does:
+
resume2=swap:/dev/mapper/swap cryptdevice=/dev/sda2:swap
+
I'm not sure if this is the correct/best way of doing this, though, and didn't see other documentation.
+
 
+
== New cipher mode ==
+
Kernel 2.6.24 supports "aes-xts-plain" (instead of "cbc" or "lrw"). Waiting for kernel 2.6.24 to reach [core] (and new CD version), stay tuned :-) [[User:Ekerazha|ekerazha]] 09:00, 6 February 2008 (EST)
+
:Sounds cool.
+
 
+
:If you can't wait you can get a livecd that has a 2.6.24 kernel (such as the [http://cdimage.ubuntu.com/daily-live/current/ daily builds of ubuntu]). It worked for me. --[[User:inthemedium|inthemedium]] 10:14, 6 February 2008 (EST)
+
:'''Question:''' [http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2585 xts-plain VS xts-benbi] --[[User:Ekerazha|ekerazha]] 09:13, 13 April 2008 (EDT)
+
:: -plain is the good one (specs: [http://grouper.ieee.org/groups/1619/email/pdf00086.pdf aes-xts-plain_specs.pdf from grouper.ieee.org]) --[[User:Ekerazha|ekerazha]] 13:00, 16 April 2008 (EDT)
+
 
+
:::Note that after [https://wiki.archlinux.org/index.php?title=Dm-crypt_with_LUKS&oldid=225227#Prepare_hard_drive_for_Arch_Install_Scripts 26.09.2012 (revision 225227)] the default luksFormat Instructions were [https://wiki.archlinux.org/index.php?title=Dm-crypt_with_LUKS&diff=225278&oldid=225227 changed] back to cryptsetup's compiled in vanilla defaults. (aes-cbc-essiv / sha1) This has advantages in compatibility with older cryptsetup versions.
+
:::'''explanatory statement:'''"Change luksFormat to default compiled in cypher, less typing for everyone, less CPU overhead and default for a reason."
+
 
+
:::I added a table comparing and explaining the default options for a LUKS container with one single passphrase keyslot against example options in the [[#Using_LUKS_to_Format_Partitions_with_a_Passphrase]]-section.
+
 
+
:::Everyone is welcome to adopt it in the keyfile or other sections on corresponding options. The [[Wikipedia:Help:Table|format]] of the table is yust screwed together, improvements would be great!
+
 
+
:::'''Question:''' I think the {{ic|-y}} switch is deprecated as it '''is''' the compiled-in default at least for cryptsetup >=1.5. --[[User:Nonix|Nonix]] ([[User talk:Nonix|talk]]) 03:03, 27 September 2012 (UTC)
+
::::'''Comment:''' Yeah, I tried it also, it seems to default to "y". I also looked at the google code revision, but could not find adhoc a definite statement plus in the current manpage it is still advised to use "y" with luksFormat. That's why I think we better leave that in for now not to provoke easy user errors. Thanks for looking over it!! (I was actually writing it up a couple of weeks after doing it - do correct what you think has to change. Thanks)  --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 15:52, 27 September 2012 (UTC)
+
 
+
== Proposed update of the section 'Storing the key between MBR and 1st partition' ==
+
{| style="background-color: #f3f9ff; margin: 1em 2.5% 0 2.5%; padding: 3px 3px; border: 1px solid #aaa;"
+
|-
+
|'''Background'''
+
+
I tried to setup automatic mount of my LUKS encrypted {{ic|/home}} using a keyfile stored between MBR and first partition header of my USB key following this wiki page and realized that it didn't work out because the howto is incomplete. I had to manually go through the encrypt hook to figure out what it does. To save other users this tiresome work that cost me hours until all finally worked out the way I wanted it I propose to update the mentioned section in the following way. Suggestions welcome. Maybe it should be noted in the parent section that {{ic|/etc/crypttab}} conflicts with using the howto presented here.
+
|}
+
 
+
Add the temporary keyfile we created before with cryptsetup:
+
cryptsetup luksAddKey /dev/hda3 secretkey
+
 
+
That should return you output like this:
+
Enter any LUKS passphrase:
+
key slot 0 unlocked.
+
Command successful.
+
 
+
Next you'll have to write the key directly between MBR and first partition.
+
 
+
WARNING: you should only follow this step if you know what you are doing - '''it can cause data loss and damage your partitions or MBR on the stick!'''
+
 
+
If you have a bootloader installed on your drive you have to adjust the values. E.g. GRUB needs the first 16 sectors, you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your GRUB installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key.
+
 
+
''Optional''
+
dd if=/dev/usbstick of=64sectors bs=512 count=64  # gives you copy of your first 64 sectors
+
hexcurse 64sectors                                # determine free space
+
 
+
Write your key to the disk:
+
dd if=secretkey of=/dev/usbstick bs=512 seek=4
+
 
+
If everything went fine you can now overwrite and delete your temporary secretkey:
+
shred --remove --zero secretkey
+
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.
+
 
+
Now you have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} (GRUB), it should look something like this:
+
kernel /vmlinuz-linux root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048 cryptdevice=/dev/hda4:home
+
Format for the cryptkey option:
+
cryptkey=BLOCKDEVICE:OFFSET:SIZE
+
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be (if you use skip=16 in the 'dd' command above to protect the bootloader)
+
kernel /vmlinuz-linux root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048 cryptdevice=/dev/hda4:home
+
Format for the cryptdevice option:
+
cryptdevice=BLOCKDEVICE:MAPPING_TARGET
+
The encrypted block device BLOCKDEVICE will then be mapped to {{ic|/dev/mapper/MAPPING_TARGET}}
+
 
+
'''Note:''' You will _not_ need to have {{ic|/etc/crypttab}} setup for this device then (but maybe you want to use it for other encrypted devices where you want to enter the passphrase manually or e.g. use a keyfile stored on this afterwards decrypted partition)! But don't forget to activate the ''encrypt'' hook in {{ic|/etc/mkinitcpio.conf}} (_before_ the ''filesystems'' hook)
+
 
+
That's all, reboot and have fun! And look if your partitions still work after that ;-).
+
 
+
== Backup of volume header ==
+
I think that its important to backup headers of your volumes. This should be mentioned in the wiki imo.
+
 
+
== LVM2 and LUKS ==
+
I'm quite sure this section is misleading. You have to setup up encryption ''before'' LVM2 partitions on the decrypted device.
+
 
+
And you have to add the "encrypt" hook ''before'' the "lvm2" hook, because you need to make the decrypted device available before LVM2 imports volume groupe and makes logical volumes available.
+
 
+
Yet this chapter tends to tell the other way round. Is my English so bad ?
+
 
+
I agree.. I find this entire wiki article unnecessarily complicated .. this link for an LVM on top of an encrypted partition is MUCH!!! easier to follow, and for a laptop would be better. [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]
+
 
+
- This section is misleading. What the author meant was if you encrypt the contents of LVM partitions, THEN you have to move the lvm2 hook before the encrypt hook. I made a few small changes, so other newbies (like me) don't end up with an unbootable system.
+
 
+
-- I also agree that the section needs a further overhaul, assuming here everyone commenting means the "Encrypting and LVM Setup" (because "LVM2 and LUKS" is not in the TOC). Having encrypt over (i.e. before) LVM is def the typical and easiest setup (and this should be expanded on more clearly in the wiki like in the link above I agree). However, all methods have a usecase. It depends what the user wants to achieve. Time permitting, the differences should be worked out. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:53, 18 September 2012 (UTC)
+
 
+
==  Prepare hard drive ==
+
The actual text is:
+
 
+
Skip the Partitioning and Auto-Prepare business and go straight to "Set Filesystem Mountpoints". When asked for your {{ic|/}} (root) partition, do NOT select {{ic|/dev/sda3}} as you normally would. Select {{ic|/dev/mapper/root}} instead. Similarly, use {{ic|/dev/mapper/home}} instead of {{ic|/dev/sda4}} as the partition to be mounted as {{ic|/home}}. The same is valid for a swap partition which is set up like the home partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/boot}} partition or else the installer will not properly set up the bootloader.
+
 
+
but the Arch Linux installer says:
+
[code]
+
/dev/sda1
+
/dev/sda2
+
/dev/mapper/root
+
/dev/mapper/lvm-home
+
/dev/mapper/lvm-root
+
/dev/mapper/lvm-swap
+
/dev/mapper/lvm-tmp
+
[/code]
+
When asked for {{ic|/}} (root) partition: is it {{ic|/dev/mapper/root}} or {{ic|/dev/mapper/lvm-root}}. I suppose it is the first one because the second one does not match.
+
 
+
== Decryption of root during boot with the assistance of UDEV when key is stored on USB drive between MBR and 1st Partition ==
+
The instructions in the wiki were very helpful but a bit confusing/lacking when it comes to getting Decryption via USB keyfile stored between MBR and 1st Partition.
+
 
+
[[System_Encryption_with_LUKS#Storing_the_key_between_MBR_and_1st_partition]] makes references to {{ic|/dev/usbkey}} but the previous instructions aren't entirely clear on how to ensure your usb drive can always be found at this location.
+
 
+
When modifying your bootloader you will be unable to use ''/dev/disk/by-uuid'' because you are not referencing a filesystem.  You wouldn't want to use ''/dev/sd[x]'' because this can and will change depending on what other drives and media you have connected during boot.  The best bet is to create a udev rule that will exist in early userspace to alias your usb drive to an arbitrary name, in this case "usbkey".  The rule must be added to the initial ramdisk so it can be read and processed to alias your drive at ''/dev/usbkey'' before root decryption is attempted via the key hidden on the drive.
+
 
+
[[System_Encryption_with_LUKS#Using_udev]] runs you through the initial steps you need to create a basic rule based on the USB drive's serial number.  That is the very same rule I used.  I named the rules file "62-usbkey.rules" and placed it in {{ic|/etc/udev/rules.d/}}.
+
 
+
Now modify {{ic|/etc/mkinitcpio.conf}}, look for the "FILES" section and add the udev rule that you created above:
+
 
+
<pre>
+
# FILES
+
# This setting is similar to BINARIES above, however, files are added
+
# as-is and are not parsed in any way.  This is useful for config files.
+
# Some users may wish to include modprobe.conf for custom module options
+
# like so:
+
#    FILES="/etc/modprobe.d/modprobe.conf"
+
FILES="/etc/udev/rules.d/62-usbkey.rules"
+
</pre>
+
 
+
Run ''mkinitcpio'' ala [[Mkinitcpio#Image_creation_and_activation]] and rebuild your ramdisk with the new udev rule you've included.  You can now continue to follow the instructions in [[System_Encryption_with_LUKS#Storing_the_key_between_MBR_and_1st_partition]] to modify your bootloader and substitute references to "usbkey" to whatever you named your drive alias above.
+
 
+
[[User:S0ma|S0ma]] 13:48, 16 December 2011 (EST)
+
 
+
== GRUB-Legacy/GRUB2 changes regarding the Kernel Line ==
+
Since GRUB-Legacy doesn't play that much of a role anymore it'd be advisable to exchange the explainations for adjusting the kernel line in the bootloader to the procedure used in GRUB2.
+
 
+
For example @ the last step of #With_suspend-to-disk_support
+
 
+
 
+
== systemd addidtions ==
+
systemd requires lvm-on-cryptdevice.service active in order to open LVMs on cryptdevices that are not the root partition (which is handled by the initrd).
+

Latest revision as of 08:33, 10 April 2016

New idea

The philosophy behind the current old structure was to try to generalize the various steps for encrypting an entire system or a device and managing it, however we've noticed it's kind of hard. A new idea for reducing duplication of content while maintaining, if not improving, readability, would be to rename the "/Examples" subpage to "/Common Scenarios" and move it to first place in Dm-crypt with LUKS/draft, so it's used use the dm-crypt#Common scenarios section as the starting point by the readers. It should contain the most common uses for encryption, which IMO are:

Each of those scenarios should be mostly a stripped sequence of commands with short descriptions that should link to generic sections in the other subpages of Dm-crypt with LUKS dm-crypt, pointing out all the particular suggested adaptations that apply to that particular scenario.

The idea is quite clear in my mind, I hope I've managed to explain it well enough, I'll try to put it into practice and see if it raises major problems.

-- Kynikos (talk) 03:08, 23 November 2013 (UTC)

EDIT: since Plain dm-crypt without LUKS would be merged here, the main article should be just renamed to dm-crypt. -- Kynikos (talk) 03:09, 23 November 2013 (UTC)

EDIT: updated for current structure. -- Kynikos (talk) 04:31, 8 December 2013 (UTC)

Scenario structure

Plenty of stuff to do, yet: Taking for granted we want an additional example with RAID sometime, it might be worth considering to split dm-crypt/Encrypting an Entire System into a subpage for (e.g.) dm-crypt/Encrypting a single disk system and dm-crypt/Encrypting a system across multiple disks scenarios. The latter covering "LUKS on LVM" and said RAID. Main reason: page length. If you agree, let's better do it now. --Indigo (talk) 12:11, 8 December 2013 (UTC)
Not a bad idea at all! However IMHO the proposed titles are a bit misleading: I would go for dm-crypt/Encrypting a System on Physical Devices and dm-crypt/Encrypting a System on Virtual Devices, in fact you can use multiple physical disks in every case if you want. -- Kynikos (talk) 03:48, 9 December 2013 (UTC)
EDIT: Note that the history of dm-crypt/Encrypting an Entire System should be preserved by moving it to one of the two titles, and then (or before) splitting the other page. -- Kynikos (talk) 03:49, 9 December 2013 (UTC)
+1 to your edit, I learned that from watching. The one letdown of this whole fun exercise is that the wiki engine does not seem to support basic content splits and joins preserving history. Anyhow, we might as well just keep it in mind and consider splitting it later (when there is something about RAID). Funnily, I find the use of "physical" (all blockdevices are on one) and "virtual" (suggests a qcow device) as differentiator not totally clear too. Let's meditate over it again until someone has another snappy idea. --Indigo (talk) 23:16, 9 December 2013 (UTC)