Difference between revisions of "Talk:Dm-crypt"

From ArchWiki
Jump to: navigation, search
(suggestion to use shred)
(Encrypting a LVM setup (section 8))
(43 intermediate revisions by 12 users not shown)
Line 11: Line 11:
  
 
Does anyone have objections to my plans, or should I just go ahead and we can revert back if it doesn't fit?
 
Does anyone have objections to my plans, or should I just go ahead and we can revert back if it doesn't fit?
 +
[[User:WhiteMagic|WhiteMagic]] 12:56, 24 May 2007 (EDT)
  
[[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)
 
: 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)
  
== Suspend to disk instructions are insecure ==
+
:: This is new territory for me, but I want to implement this topic myself soon. I'll start with removing some duplicated content. [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 07:25, 16 June 2013 (UTC)
 
+
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 ==
 
== 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:
 
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
 
  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.
 
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 daily builds of ubuntu http://cdimage.ubuntu.com/daily-live/current/). It worked for me. [[User:inthemedium|inthemedium]] 10:14, 6 February 2008 (EST)
 
:'''Question:''' xts-plain VS xts-benbi http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2585 [[User:Ekerazha|ekerazha]] 09:13, 13 April 2008 (EDT)
 
:: -plain is the good one (specs: http://grouper.ieee.org/groups/1619/email/pdf00086.pdf ) [[User:Ekerazha|ekerazha]] 13:00, 16 April 2008 (EDT)
 
 
== Badblocks insecure ==
 
I wrote this down at the Gentoo wiki. Since I've been getting into Arch I thought I would share...<br />
 
Here's an example<br />
 
 
If you write to a device with the command...<br />
 
''<nowiki>/sbin/badblocks -c 10240 -s -w -t random -v /dev/loop0</nowiki>''<br />
 
... or somthing similar as recommended in many places.<br />
 
 
Then...<br />
 
''xxd /dev/loop0''<br />
 
---SNIP---
 
002e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
 
002e810: 1a18 a663 0b58 0e53 054f b72f 8058 d7a1  ...c.X.S.O./.X..
 
002e820: a4f8 b5a5 c74e 0bf9 a11e 447b 6edd 5888  .....N....D{n.X.
 
002e830: f5fe ec00 56fa 535c 490b 8bc9 6363 6b07  ....V.S\I...cck.
 
002e840: 5b20 ac22 6eb7 1c0f d560 8a43 3de2 cc32  [ ."n....`.C=..2
 
002e850: e0b8 3236 b286 92fc 911e c5f4 8130 fbdc  ..26.........0..
 
002e860: 50a7 ffbe 5f1b cd34 7b57 78b8 3944 ea19  P..._..4{Wx.9D..
 
002e870: fc1c 50ae a2e2 aa33 0070 2781 a022 5ef1  ..P....3.p'.."^.
 
002e880: ca5d af29 787d 5df3 d4d5 ab0e 1995 2715  .].)x}].......'.
 
002e890: b177 c454 5a6e 875a deaf dc7f d13a 709b  .w.TZn.Z.....:p.
 
---SNIP---
 
 
Then... looking for the data at 0x002e800...<br />
 
''xxd /dev/loop0 | grep "214c 2113 01ce 9965 3253 134a da50 99dd"''<br />
 
You'll get<br />
 
---SNIP---
 
002e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
 
0a2e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
 
142e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
 
1e2e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
 
282e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
 
322e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
 
3c2e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
 
462e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
 
502e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
 
5a2e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
 
642e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
 
6e2e800: 214c 2113 01ce 9965 3253 134a da50 99dd  !L!....e2S.J.P..
 
---SNIP---
 
Tell me if I'm wrong, but that kinda seems to defeat the purpose of randomizing the HDD
 
 
--
 
 
This guy is correct. Remember badblocks is a random '''pattern''' it just repeats its randomness over and over again.
 
 
 
  0800000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  1200000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  1c00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  2600000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  3000000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''0''
 
  3a00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''A''
 
  4400000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''4''
 
  4e00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''e''
 
  5800000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  6200000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  6c00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  7600000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  8000000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  8a00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  9400000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  9e00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  a800000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  b200000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  bc00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  c600000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''0''
 
  d000000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''a''
 
  da00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''4''
 
  e400000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N. ''e''
 
  ee00000: cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
  10200000:cc23 0fe8 0438 552b 2b25 2afb dccd 4e1d  .#...8U++%*...N.
 
 
 
As you can see the pattern is repeating and it isn't very long between each time it repeats. This hardly makes it any more secure.
 
 
--[[User:Tama00|Tama00]] 15:11, 19 November 2010 (EST)
 
: Warning is added to the article. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 03:22, 8 June 2012 (UTC)
 
:: Wouldn't it make more sense to completely remove it from the article instead? Seeing as it apparently provides no security benefit compared to using zero bytes... --[[User:Sas|Sas]] ([[User talk:Sas|talk]]) 12:39, 4 July 2012 (UTC)
 
::: At the same time, using badblock to erase data has no major problem. In Arch the decision should be made by users themself. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 04:41, 5 July 2012 (UTC)
 
 
== How about including shred instead of or along with badblocks ==
 
 
I just used it recently and it worked great.
 
 
  # shred -v -n 1 /dev/sdb
 
  ...
 
  shred: /dev/sdb: pass 1/1 (random)...572GiB/932GiB 61%
 
  shred: /dev/sdb: pass 1/1 (random)...573GiB/932GiB 61%
 
  shred: /dev/sdb: pass 1/1 (random)...574GiB/932GiB 62%
 
  shred: /dev/sdb: pass 1/1 (random)...575GiB/932GiB 62%
 
  shred: /dev/sdb: pass 1/1 (random)...576GiB/932GiB 63%
 
 
Are there any objections or complaints about this tool? My experience was that it was A LOT faster then using /dev/random as well, and it provides display to the user of the progress. Id say it should be the first recommended option.
 
[[User:MrSk1yj8|MrSk1yj8]] ([[User talk:MrSk1yj8|talk]]) 29 July 2012
 
  
 
== Proposed update of the section 'Storing the key between MBR and 1st partition' ==
 
== 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;"
 
{| style="background-color: #f3f9ff; margin: 1em 2.5% 0 2.5%; padding: 3px 3px; border: 1px solid #aaa;"
 
|-
 
|-
Line 186: Line 68:
  
 
That's all, reboot and have fun! And look if your partitions still work after that ;-).
 
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 ==
 
== LVM2 and LUKS ==
 
 
I'm quite sure this section is misleading. You have to setup up encryption ''before'' LVM2 partitions on the decrypted device.
 
I'm quite sure this section is misleading. You have to setup up encryption ''before'' LVM2 partitions on the decrypted device.
  
Line 203: Line 80:
 
- 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.
 
- 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 ==
+
==  <s> Prepare hard drive </s> ==
 
The actual text is:
 
The actual text is:
  
Line 220: Line 98:
 
[/code]
 
[/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.
 
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.
 
== on the bashing of /dev/urandom ==
 
 
I don't take an opinion on whether old overwritten data can be read.
 
 
However, there is an unrelated reason to fill a LUKS partition from {{ic|/dev/urandom}} before LUKS-initializing it (and after checking for bad blocks if you wanted to do that).
 
 
It makes it harder for people trying to read your disk and find out what's on it.  If you filled it with zeroes, for example, then they would be able to tell which portions of the partition had been written to since you initialized it.
 
 
compate gentoo docs, http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS#Filling_the_disk_with_random_data
 
 
[[User:Idupree|Idupree]] 22:45, 3 March 2010 (EST)
 
 
Agreed, {{ic|/dev/urandom}} should be used to clear partitions, at least as default in the examples. If anyone wants to zero the partitions instead of using random data, they are free to do so. --[[User:Montschok|Montschok]] 20:53, 11 August 2010 (EDT)
 
  
 
== Decryption of root during boot with the assistance of UDEV when key is stored on USB drive between MBR and 1st Partition ==
 
== 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.
 
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.
  
Line 261: Line 124:
 
[[User:S0ma|S0ma]] 13:48, 16 December 2011 (EST)
 
[[User:S0ma|S0ma]] 13:48, 16 December 2011 (EST)
  
==<s>Moving the "why should I use encryption" section to a separate article</s>==
+
== 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).
 +
 
 +
== after 2012.07.15 ==
 +
 
 +
What change with the new installation process and systemd change ? If I understand correctly parts related to /etc/rc.conf files are no longer useful but what's the correct way now ? thanks --[[User:Martvefun|Martvefun]] ([[User talk:Martvefun|talk]]) 00:27, 9 January 2013 (UTC) -> question and response asked[https://bbs.archlinux.org/viewtopic.php?id=155863|here]
 +
:For reference - two more bbs threads covering the subject: [https://bbs.archlinux.org/viewtopic.php?pid=1212076#p1212076| with systemd] and [https://bbs.archlinux.org/viewtopic.php?pid=1170012#p1170012| with a nice backup script]--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:07, 9 January 2013 (UTC)
 +
 
 +
== Encrypted swap With suspend-to-disk support ==
 +
Shouldn't the openswap hook go after the encrypt hook? Otherwise you have to always open the root device prior to the swap, even on resume.
 +
:You meant to write ".. the openswap go before encrypt ..?" which sounds like a reasonable suggestion. Have you tried it? (I have not). Maybe it works still (without manual unlocking of root) because of the kernel parameter resume=.. In Debian it would go after, but there the key for swap is derived by the hook from the root master key (hence not input extra for swap, which is elegant).--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:06, 6 February 2013 (UTC)
 +
== Feature of Grub2 to decrypt /boot ==
 +
Original comment by Chehri on 8.6.13, moved from [Dm-crypt_with_LUKS#Creating_Disk_Partitions] to here:
 +
It is now possible to include /boot on a LUKS container thanks to grub 2.00. Zack Buhman (buhman) has proposed a [https://bugs.archlinux.org/task/31877 patch] which allows this. This allows kexec to be used to start a new kernel in remote situations. It also removes any possibility of the kernel being tampered with (though grub is still unencrypted; store on a removable drive for added safety).
 +
:Interesting patch/idea. I moved the out-of-date box here to discussion first for the following reason:
 +
:The patch you link to is proposed and not even commented on, i.e. it is not in the encrypt hook. Having it there as out-of-date in this general Luks section at the beginning will confuse new readers totally. Another reason is that the Luks page in that section is general, not grub specific. Everything there can be setup with standard Arch [core], i.e. also Syslinux.
 +
:I hope you agree to that, if not let's please discuss it. Thanks.
 +
 
 +
:I think the best way forward for the contribution would be to draft a subsection under 3.2 (e.g. as 3.2.7), we have different hook modifications there for the swap. (later on there is a specific section on encrypted keyfiles too where it might fit well). Once the section is complete and accurate to modify a standard Arch, one could link to it from the general section above. Once something like that goes into the vanilla Arch-encrypt hook, it should definetely be described earlier. Another (different) point would be to discuss the pros/cons security-wise of such a modification a bit. That could be done in the subsection too. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:35, 8 June 2013 (UTC)
 +
 
 +
== <s>AIF</s> ==
  
The section "Why should I use encryption" is referenced by other encryption-related articules (like [[System_Encryption_with_eCryptfs | this one]].
+
I just came here to try to update information concerning mkinitcpio.conf for LVM-on-LUKS. I'm not sure I've found everything to update as there seem to be several pages which cover similar but not quite the same information.
I'd like to move this to a separate article, since it treats subjects related to encryption in general, not especifically just LUKS. Is everyone ok with this? [[User:Hobarrera|Hobarrera]] ([[User talk:Hobarrera|talk]]) 02:00, 11 June 2012 (UTC)
+
  
:It would be great if we could have a generic article introducing to system encryption with content taken from the currently existing articles. [[User:Fengchao]] has [[User_talk:Sas/Disk_Encryption|proposed]] to move [[User:Sas/Disk Encryption]] to a regular article and use that as a start, and I concur, what do you think? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:17, 12 June 2012 (UTC)
+
I was wondering, though, what was planned for the AIF section. I think the inclusion of this is unnecessarily confusing to new users since this has been deprecated for quite some time.
:: I did the move. So please merge general encryption info to [[Disk Encryption]]. Maybe [[Disk Encryption]] should rename to  Encryption if file encryption is covered there. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 02:25, 15 June 2012 (UTC)
+
:::What about renaming to [[System Encryption]], so we still exclude other kinds of encryption like [[Secure Shell]]? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:28, 15 June 2012 (UTC)
+
:::: The section to be moved contain many information about "data encryption". [[System Encryption]] is too restrict about them. How about add link and short introduction about Secure Shell in the article ? That way the new article will be the most general introduction. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 04:35, 16 June 2012 (UTC)
+
:::::Ok, I like it, go with [[Encryption]] + the short introduction :)
+
:::::However a [[System Encryption]] redirect may be useful anyway.
+
:::::Besides, more important, the [[Encryption]] article should probably be linked from all its related articles, so that we can prevent users from adding generic information to those articles in the future, but direct them toward the general article.
+
:::::Finally, once these links are in place, we could rename [[System Encryption with LUKS]] and [[System Encryption with eCryptfs]] to just [[LUKS]] and [[eCryptfs]], just like [[TrueCrypt]].
+
::::: -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:16, 16 June 2012 (UTC)
+
:::::: I disagree about renaming [[Disk Encryption]], and have stated my reasons at [[Talk:Disk_Encryption]].
+
:::::: I completely agree about renaming the "System Encryption with..." articles though.
+
:::::: --[[User:Sas|Sas]] ([[User talk:Sas|talk]]) 18:42, 17 June 2012 (UTC)
+
  
: I have now merged the generic disk encryption info from this article's intro section (which turned out to be a ''lot'') into the [[Disk_Encryption]] article. Please review, and improve where appropriate. --[[User:Sas|Sas]] ([[User talk:Sas|talk]]) 12:43, 4 July 2012 (UTC)
+
--[[User:Margali|cfr]] ([[User talk:Margali|talk]]) 00:07, 15 July 2013 (UTC)
::I think it's been a very good job, Sas. I've just done the linking and renaming part, closing this discussion. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:25, 6 July 2012 (UTC)
+
  
== Specifying skip and count in /etc/crypttab for /tmp ==
+
:Agree it should be deleted.
In this wiki article, [[Dm-crypt_with_LUKS#.2Fetc.2Fcrypttab]], you're advised to put the following in your /etc/crypttab
+
:[[User:Jasonwryan|jasonwryan]] ([[User talk:Jasonwryan|talk]]) 00:14, 15 July 2013 (UTC)
  
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512
+
::This article has lots of very interesting content, but yeah some parts are outdated just like that one: AIF is dead/suspended (don't remember the official status), that section can go. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:16, 16 July 2013 (UTC)
 +
:::Thanks for bringing it up, I removed it (you can find it on my user-page for ~ a month). Next needing clean-up is 8.1 - 8.4 (please state your opinion below, thanks!). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:16, 16 July 2013 (UTC)
  
But doing that will not work. More specifically in /etc/rc.d/functions:do_unlock() in switch case /dev/*. After debugging with some `set -x`:es I found that if you specify the dd count and skip parameters in crypttab it will work i.e., e.g.,
+
== Encrypting a LVM setup (section 8) ==
 +
The content in sections 8.1 to 8.4 has to be updated, particularly the AIF and /etc/rc.conf references must go. Since another user created a "Encrypted LVM" stub article, which (arguably) has style problems but is a good read otherwise, I see two alternatives for section 8:
  
tmp /dev/lvm/tmp /dev/urandom:0:2048 -c aes-xts-plain -s 512
+
A. (1) Remove all outdated install instructions from 8.1 to 8.4, (2) link to the "Encrypted LVM" stub article for users looking for verbose LVM/LUKS install instructions, but (3) keep the LVM short instructions in this article too as a quick reference section. Next, (4) the "Encrypted LVM" should then properly link back properly to the "LUKS" page (particularly to the explanations about the LUKS options)!
  
If this is how it should be done I propose a change in the wiki to consider this. If not, do_unlock() is strange.
+
B. The second option would be to (5) move the stub article here into section 8, but this would require a major work to make it fit with the rest of the page (double content, a lot of linking up/down).
--[[User:Erikw|Erikw]] ([[User talk:Erikw|talk]]) 16:40, 17 July 2012 (UTC)
+
  
:Please add [[Template:Accuracy]] if you're not sure of something and want some feedback. I'm sorry but I can't help you on this now :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:19, 18 July 2012 (UTC)
+
Both can be done, I prefer A, also because the LUKS page itself is rather huge already. In fact I added links over to that stub page a while back so that new users find it so noone stumbles over /arch/setup et al.
 +
Maybe you have another idea than A or B. Opinions? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:16, 16 July 2013 (UTC)
  
::Oh I was not aware of this. It's added now. Thanks. --[[User:Erikw|Erikw]] ([[User talk:Erikw|talk]]) 18:54, 18 July 2012 (UTC)
+
:Yep, if you could take the time to implement A it would be a great improvement. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:42, 20 July 2013 (UTC)
 +
::Glad you approve and sure, I have started on it (great it will only be, if we don't loose some of the great content that still applies - that's the tricky bit imho; the edits for A are not that much). Anyone missing something can find the original section 8 on my user-page for the time being. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:44, 20 July 2013 (UTC)

Revision as of 17:44, 20 July 2013

Cleanup and Clarification

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

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... --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?

Does anyone have objections to my plans, or should I just go ahead and we can revert back if it doesn't fit? WhiteMagic 12:56, 24 May 2007 (EDT)

Clean up is really needed. Please someone with enough knowledge start the job. -- Fengchao (talk) 02:55, 8 June 2012 (UTC)
This is new territory for me, but I want to implement this topic myself soon. I'll start with removing some duplicated content. T1nk3r3r (talk) 07:25, 16 June 2013 (UTC)

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.

Proposed update of the section 'Storing the key between MBR and 1st partition'

Background

I tried to setup automatic mount of my LUKS encrypted /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 /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 /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 /dev/mapper/MAPPING_TARGET

Note: You will _not_ need to have /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 /etc/mkinitcpio.conf (_before_ the filesystems hook)

That's all, reboot and have fun! And look if your partitions still work after that ;-).

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. 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. --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 / (root) partition, do NOT select /dev/sda3 as you normally would. Select /dev/mapper/root instead. Similarly, use /dev/mapper/home instead of /dev/sda4 as the partition to be mounted as /home. The same is valid for a swap partition which is set up like the home partition. Make sure you mount /dev/sda1 as the /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 / (root) partition: is it /dev/mapper/root or /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 /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 /etc/udev/rules.d/.

Now modify /etc/mkinitcpio.conf, look for the "FILES" section and add the udev rule that you created above:

# 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"

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.

S0ma 13:48, 16 December 2011 (EST)

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).

after 2012.07.15

What change with the new installation process and systemd change ? If I understand correctly parts related to /etc/rc.conf files are no longer useful but what's the correct way now ? thanks --Martvefun (talk) 00:27, 9 January 2013 (UTC) -> question and response asked[1]

For reference - two more bbs threads covering the subject: with systemd and with a nice backup script--Indigo (talk) 20:07, 9 January 2013 (UTC)

Encrypted swap With suspend-to-disk support

Shouldn't the openswap hook go after the encrypt hook? Otherwise you have to always open the root device prior to the swap, even on resume.

You meant to write ".. the openswap go before encrypt ..?" which sounds like a reasonable suggestion. Have you tried it? (I have not). Maybe it works still (without manual unlocking of root) because of the kernel parameter resume=.. In Debian it would go after, but there the key for swap is derived by the hook from the root master key (hence not input extra for swap, which is elegant).--Indigo (talk) 22:06, 6 February 2013 (UTC)

Feature of Grub2 to decrypt /boot

Original comment by Chehri on 8.6.13, moved from [Dm-crypt_with_LUKS#Creating_Disk_Partitions] to here: It is now possible to include /boot on a LUKS container thanks to grub 2.00. Zack Buhman (buhman) has proposed a patch which allows this. This allows kexec to be used to start a new kernel in remote situations. It also removes any possibility of the kernel being tampered with (though grub is still unencrypted; store on a removable drive for added safety).

Interesting patch/idea. I moved the out-of-date box here to discussion first for the following reason:
The patch you link to is proposed and not even commented on, i.e. it is not in the encrypt hook. Having it there as out-of-date in this general Luks section at the beginning will confuse new readers totally. Another reason is that the Luks page in that section is general, not grub specific. Everything there can be setup with standard Arch [core], i.e. also Syslinux.
I hope you agree to that, if not let's please discuss it. Thanks.
I think the best way forward for the contribution would be to draft a subsection under 3.2 (e.g. as 3.2.7), we have different hook modifications there for the swap. (later on there is a specific section on encrypted keyfiles too where it might fit well). Once the section is complete and accurate to modify a standard Arch, one could link to it from the general section above. Once something like that goes into the vanilla Arch-encrypt hook, it should definetely be described earlier. Another (different) point would be to discuss the pros/cons security-wise of such a modification a bit. That could be done in the subsection too. --Indigo (talk) 17:35, 8 June 2013 (UTC)

AIF

I just came here to try to update information concerning mkinitcpio.conf for LVM-on-LUKS. I'm not sure I've found everything to update as there seem to be several pages which cover similar but not quite the same information.

I was wondering, though, what was planned for the AIF section. I think the inclusion of this is unnecessarily confusing to new users since this has been deprecated for quite some time.

--cfr (talk) 00:07, 15 July 2013 (UTC)

Agree it should be deleted.
jasonwryan (talk) 00:14, 15 July 2013 (UTC)
This article has lots of very interesting content, but yeah some parts are outdated just like that one: AIF is dead/suspended (don't remember the official status), that section can go. -- Kynikos (talk) 13:16, 16 July 2013 (UTC)
Thanks for bringing it up, I removed it (you can find it on my user-page for ~ a month). Next needing clean-up is 8.1 - 8.4 (please state your opinion below, thanks!). --Indigo (talk) 20:16, 16 July 2013 (UTC)

Encrypting a LVM setup (section 8)

The content in sections 8.1 to 8.4 has to be updated, particularly the AIF and /etc/rc.conf references must go. Since another user created a "Encrypted LVM" stub article, which (arguably) has style problems but is a good read otherwise, I see two alternatives for section 8:

A. (1) Remove all outdated install instructions from 8.1 to 8.4, (2) link to the "Encrypted LVM" stub article for users looking for verbose LVM/LUKS install instructions, but (3) keep the LVM short instructions in this article too as a quick reference section. Next, (4) the "Encrypted LVM" should then properly link back properly to the "LUKS" page (particularly to the explanations about the LUKS options)!

B. The second option would be to (5) move the stub article here into section 8, but this would require a major work to make it fit with the rest of the page (double content, a lot of linking up/down).

Both can be done, I prefer A, also because the LUKS page itself is rather huge already. In fact I added links over to that stub page a while back so that new users find it so noone stumbles over /arch/setup et al. Maybe you have another idea than A or B. Opinions? --Indigo (talk) 20:16, 16 July 2013 (UTC)

Yep, if you could take the time to implement A it would be a great improvement. -- Kynikos (talk) 07:42, 20 July 2013 (UTC)
Glad you approve and sure, I have started on it (great it will only be, if we don't loose some of the great content that still applies - that's the tricky bit imho; the edits for A are not that much). Anyone missing something can find the original section 8 on my user-page for the time being. --Indigo (talk) 17:44, 20 July 2013 (UTC)