Talk:Dm-crypt

From ArchWiki
Revision as of 03:22, 8 June 2012 by Fengchao (Talk | contribs) (Badblocks insecure)

Jump to: navigation, search

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)

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.

--Jmawebb 19:44, 27 February 2010 (EST)

Is there a fix for this yet? Maybe the luksSuspend function? --Revelation60 21:21, 20 December 2010 (GMT+1)

Encrypted Swap

http://bbs.archlinux.org/viewtopic.php?id=26097 - this is I think, better solution for encrypted swap.

Probably the SWAP keyword, which can be used in /etc/crypttab, should be mentioned. --gothmog.todi 12:47, 24 July 2007 (EDT)
I've added a paragraph about the SWAP keyword some while ago. Does anybody see a reason to keep the information about setting up random swap encryption manually? I can't think about a use case where it should be preferred to the automatic one. -- gothmog.todi 15:16, 5 February 2008 (EST)

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.

Setting up LUKS

cryptsetup -c aes-lrw-benbi -h sha256 -y -s 384 luksFormat /dev/sda3

I'm quite sure that the '-h' here is ignored by luksFormat. Somebody knows about this?

-- gothmog.todi 14:57, 31 January 2008 (EST)

I tested it and luksFormat does ignore it, so I removed it. -- gothmog.todi 17:27, 3 February 2008 (EST)
--Alveraan 15:07, 7 June 2011 (EDT) from the Cryptsetup 1.1.0 release notes: "Uses libgcrypt and enables all gcrypt hash algorithms for LUKS through -h luksFormat option. Please note that using different hash for LUKS header make device incompatible with old cryptsetup releases.". This has been supported since january 2010 now. It has been changed in the page but I just wanted to update this section of the discussion.

Misc

Look: http://wiki.archlinux.org/index.php/User_talk:Gothmog.todi#LUKS

Summary: we could insert a short explanation so every user can chose between a "LRW mode" swap partition or a "CBC-ESSIV mode" swap partition. ekerazha 07:11, 3 February 2008 (EST)

Improved the "note" (I hope) ;-) ekerazha 12:28, 3 February 2008 (EST)
Thank you, it's better now. I added a shot info about suspend2disk in connection with encrypted swap. -- gothmog.todi 17:26, 3 February 2008 (EST)
I've added other info because with "uswsusp" you can also encrypt the suspend image, so it should also encrypt the "kernel space" key we used for dm-crypt before storing it to the lrw ciphered volume. ekerazha 09:30, 4 February 2008 (EST)

Merge proposal

As you can see, I tried to merge 4 articles that covered the same (or very similar) subject into this one. There was wrong/redundant informations between the various pages. -- ekerazha 18:36, 3 February 2008 (EST)

There's still a very redundant page (this one: Disk encryption) but the user "Post" believes to own it (see User_talk:Ekerazha) so I can't merge/redirect that page... and I have no desire to lose my time with him. -- ekerazha 19:12, 3 February 2008 (EST)
Sure, your page contains more topics (USB stick and loopback), but the overall quality still sucks.
Post 19:28, 3 February 2008 (EST)
You still don't understand this ISN'T "my" page: many users contributed to this page. However, "YOUR" page, compared to this, is *very* superficial, just look at the notes with deeper explanations we have here. If you have improvements (but I doubt it, considering the low level of your arguments), you can contribute to this page instead of keeping a redundant page because you like to own a wiki page. -- ekerazha 19:36, 3 February 2008 (EST)
Owning a wiki page is 1337.
Post 19:55, 3 February 2008 (EST)

Now really, could you both please try to behave a little bit more like grown-ups? A wiki is supposed to be a place of objective information and discussion, you know. I don't know if you are aware how this normally works, so I'm going to explain it: I added merge-tags on both pages (as it probably should have be done from the beginning). And now a discussion should be started whether or not the pages should be merged. -- gothmog.todi 04:32, 4 February 2008 (EST)

So, Disk_encryption does indeed seem rather redundant to me. Post, could you may try to explain why you think there is a need for it as an independent article? -- gothmog.todi 04:37, 4 February 2008 (EST)

The current situation is: 3 pages already merged here, 2 proposed merges (Disk_encryption and RAID_Encryption_LVM). This article doesn't talk about the LVM setup, RAID_Encryption_LVM mainly talks about the LVM setup (not only however), Disk_encryption (the page "property of Post") talks about both LVM and non-LVM setups but in a very superficial way. These pages should be definitely merged together in order to avoid redundant informations. Gothmog.todi seems to agree to me about the redundancy of Disk_encryption. -- ekerazha 07:23, 4 February 2008 (EST)

You should at first clean up this page before merging all other pages with it and making it the Ultimate Guide to Encryption. It contains some really weird/obsolete stuff, like loading modules (it is done automatically), generating a keyfile with head (lawl), setting up swap via /etc/rc.local, giving "-y" option to cryptsetup, etc. Of course, I could fix these things, but there is one thing I cannot fix - that someone who simply wants to set up encryption will need to read all this crap and waste his time (like I was back then when I was setting up encrypted partitions for the first time).
Post 14:05, 4 February 2008 (EST)
You say loading modules is done automatically... partially it could be true (I didn't write that paragraph), however on x86_64 what module is used? As I've written inside a "note", x86_64 can *also* use an optimized version of the AES module: you can't settle everything "automatically" and "your" page doesn't explain there are 2 different modules. And what's wrong with giving "-y" to cryptsetup? The page you have written is a strictly "step by step" guide for people who don't understand what is doing. Why do you use "cbc-essiv" instead of "lrw" for the swap partition? Who knows... of course, that page is shorter and "step by step" but because of this, it is really really superficial (and still redundant). This is why I think it should be definitely merged. -- ekerazha 06:26, 5 February 2008 (EST)
I don't think that the additional information given in this article is crap. (But it does need some love) I rather see it as important for someone using encryption to fully understand what he is doing. Sure, for someone who just needs a quick step-by-step it's burdensome to filter out the needed commands. Maybe some kind of "short version" of the setup would help here? (I remember that something like this was in an early version of Disk_encryption) What do you think of this? I would prefer it to an extra article, which would likely lead to inconsistency between it and this one. -- gothmog.todi 14:43, 5 February 2008 (EST)

About RAID_Encryption_LVM: I really don't see much reason to keep this separate. It's rather out-of-date and would need some serious revisions. And the difference compared to the normal cyrpto setup is not really big: it could easily be put in a subsection here, with a link to the article about LVM/raid setup (Installing_with_Software_RAID_or_LVM. This one is out-dated as well, but thats another topic) -- gothmog.todi 15:08, 5 February 2008 (EST)

I agree. However I don't use LVM (I prefer UnionFS for my needs), so I don't have the "background" to merge that part. Could you do this? -- ekerazha 15:45, 5 February 2008 (EST)
I merged it, but it still needs some cleanup. -- gothmog.todi 08:13, 6 February 2008 (EST)

I merged mine. ^^

Post 18:51, 5 February 2008 (EST)

Well... now some cleanup is needed: maybe we could begin removing the "rc.local" way of setting up the swap partition (the other one is more elegant). ekerazha 06:25, 6 February 2008 (EST)

Yeah, I already proposed that in another section of this page ;-) (#Encrypted_Swap) Lets go for it. -- gothmog.todi 07:11, 6 February 2008 (EST)
I removed the rc.local way, and adapted the automatic one, it may still need some work to fit in. -- gothmog.todi 08:15, 6 February 2008 (EST)
"-y" option to cryptsetup (at least when using LUKS) is unnecessary, since LUKS asks to confirm the password by default. Two methods for generating a key are given (head/tail and dd). The former is just... weird. And why the key size given in the latter is 2K? No explanations given. And does someone use Arch64? It needs to be tested whether the aes_x86_64 module is loaded automatically. Well, and it's not supposed to be step-by-step, but sections 5-8 ARE step-by-step. This page really needs to get improved.
Post 10:52, 6 February 2008 (EST)
Inside "man cryptsetup" it's not documented that -y doesn't affect luks (it IS documented that it ACCEPTS -y, while it's documented that -h doesn't affect luksFormat), is there another guy that could confirm this (I'll try by myself asap). About the key generation, cleanup the unuseful stuff if you want... I didn't write that part so I can't say why it is that way. I use Arch64 and I didn't test what it loads by default, however reading the source code and some web pages, it seems like it uses the unoptimized "aes.ko" module (not "aes-i586.ko" and not "aes_x86_64.ko"), but I wait for confirmations. -- ekerazha 12:30, 6 February 2008 (EST)
And, if your root partition is on lvm, change USELVM in /etc/rc.conf to yes.
What THIS has to do with the root partition? The root partition needs to be already mounted in order to read /etc/rc.conf. Isn't this for scanning for other (non-root) volumes?
Post 11:04, 6 February 2008 (EST)
Yes, you are right. Thank you, I changed it. -- gothmog.todi 13:56, 6 February 2008 (EST)

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 :-) 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. 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 ekerazha 09:13, 13 April 2008 (EDT)
-plain is the good one (specs: http://grouper.ieee.org/groups/1619/email/pdf00086.pdf ) 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...
Here's an example

If you write to a device with the command...
/sbin/badblocks -c 10240 -s -w -t random -v /dev/loop0
... or somthing similar as recommended in many places.

Then...
xxd /dev/loop0

---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...
xxd /dev/loop0 | grep "214c 2113 01ce 9965 3253 134a da50 99dd"
You'll get

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

--Tama00 15:11, 19 November 2010 (EST)

Warning is added to the article. -- Fengchao (talk) 03:22, 8 June 2012 (UTC)

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 menu.lst (Grub), it should look something like this:

kernel /vmlinuz26 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 /vmlinuz26 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 ;-).

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


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

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

Idupree 22:45, 3 March 2010 (EST)

Agreed, /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. --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

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)