Encryption advice... [Solved]

WonderWoofy · 2012-12-15 01:46:03

So I am thinking about encrypting my system. I have been doing a bunch of reading, and I think what I want to do is use LVM2 on Luks. This is actually what huntertompson suggested to cfr in this thread. I figure this way I will be able to unlock the entire system with one key, and then still have all the benefits of how awesome LVM2 is.

My issue is that my LVM2 virtual group is actually spanning two drives. From what I have found so far, I think that the encrypt hook only supports unlocking one partition. Though, through my searching, I found this thread, which lead me to this package in the AUR. Basically it is a modfied encrypt hook that allows for multiple decryptions on boot.

So I would just like to ask if there is anyone out there that has tried (or uses) this package/encrypt hook?

I have never used dm-crypt/Luks before, so would I be better off using the Luks on top of LVM2 and then simply having my root partition decrypt the rest of my partitions? This does not sound as appealing to me, nor does it sound as awesomely simple as LVM2 on Luks, but if it will ultimately make my life simpler, then I see this as a plausible option.

Any advice is appreciated. Thanks community!

Edit: I maked this thread as [Solved], but I don't really know if this is truly a solvable kind of a thread. I recieved some great input as you will find below, which helped me choose the method in the end. Basically I ended up using software RAID to make my two devices one, then put dm-crypt/LUKS on top of that, and then LVM2 on top of that. It works great, and is pretty speedy.

Last edited by WonderWoofy (2012-12-16 21:36:35)

Strike0 · 2012-12-15 18:12:12

Now that's a bit of a surprise that you start to tinker with encryption also. I was unaware of that encrypt-hack till today. Hence I have not tried it either. Sounds great but from the looks at it, it seems to require you to input single passphrases for each of the devices to be unlocked. That makes away some of the convenience of using LVM under the encrypted block device.

However, there is another way that you might consider: It is possible to "onion-nest" block-devices. So, you can have (1) a LVM-vg spanning your disks physical volumes as you have now, then (2) create a single encrypted dm-crypt block device into it and (3) have another LVM inside that containing your logical volumes.

In your mkinitcpio, you then have "... lvm2 encrypt lvm2 filesystems ...". How it works you see here. One would hope that systemd introduction has not changed that nesting to work ..

saharchie · 2012-12-15 18:37:34

WonderWoofy wrote:

My issue is that my LVM2 virtual group is actually spanning two drives.

Is this part of a RAID? If it is a software RAID you could encrypt the RAID and put a lvm2 on top of that. mkinitcpio would look like:

 ...sata mdadm_udev encrypt lvm2 filesystems ...

WonderWoofy · 2012-12-15 21:04:50

@saharchie, I actually thought about that. But I am not entirely sure that using RAID would be a great idea in my case. I have two SSDs, they are both of similar speed and are the exact same size (albiet different vendors). The problem is that one is a regular 2.5" drive and the other is an mSATA. Despite the fact that they are both SATA III, a typical HM77 laptop provides two SATA III ports, one of which is for the HDD bad and the other is for the optical. So my mSATA SSD actually functions at about half the speed of the other.

@strike0, I have been thinking about encryption for a while. Not necessarily because I need the security, but just because it sounded interesting. Also, I have an Intel i5 3210M, which has the AES-NI instruction set. So I figued it would be neat to try that out and see how well the aesni-intel module works. From what I have heard, it works pretty well.

As far as the lvm2 -> Luks -> lvm2, that indeed looks fairly interesting. I am not sure that I necessarily want to nest in such a fashion though (just seems kind of overkill). I surely appreciate the idea though, and will definitely keep it in mind. The reason I am a bit apprehensive about the cryptsetup-multi package is because it is based on a script found in these forums (that in itself is fine), and if you look at the date of submission and date of last update, they are one in the same. So it makes me think that there is not anyone even really maintaining the script.

Honestly, the more I think about it, the more I am thinking that Luks on LVM2 might be the better way to go. Then simply include all the rest of the partitions in the crypttab. I really don't think that I would be losing any functionality of LVM2, though I would have to then resize the Luks containers in addition to resizing the logical volumes and filesystems.

About being surprised that I am wanting to tinker with encryption, I think I just like to tinker with things in general. I think that might go for most of us around here though. I am typically not put off by the occasional tinker to breakage.

Strike0 · 2012-12-16 01:07:31

WonderWoofy wrote:

Honestly, the more I think about it, the more I am thinking that Luks on LVM2 might be the better way to go. Then simply include all the rest of the partitions in the crypttab. I really don't think that I would be losing any functionality of LVM2, though I would have to then resize the Luks containers in addition to resizing the logical volumes and filesystems.

Ok, with respect to your encryption that means you are going to have key-files (probably) somewhere in your encrypted root. That is fine, but also a fine difference to a pass that stays in ram.

Now, given you are not deterred by occasional breakage: If you continue this lvm->luks route, do have a close look at Milan Broz's tutorial to the new re-encryption feature. From his LVM example you will see that you might be able to encrypt without re-installation even.

WonderWoofy · 2012-12-16 01:15:12

Thanks Strike0, I'll check it out after I make some dinner here.

My thoughts on key files for the non-root partitions were initially to simply have them in the encrypted root. I think this should be fine, but I also think that if I am going to have an USB provided key for the root partition, why not simply have the other key files in there as well. I think that by doing so, it would therefore be loading them into RAM, rather than having them on the SSD itself. It is not like I am going to yank out that USB key the instant I know that the root has been decrypted (nor do I think I would have the reaction time to achieve such a feat). Any thoughts on this?

Edit: Very intruiging write up there Strike0. I think I may end up putting my two drives in a RAID-0 setup and then encrypting that with LVM2 on top of that. Though, if I do that, I will not be able to use the cryptsetup-reencrypt.

Last edited by WonderWoofy (2012-12-16 02:34:05)

Strike0 · 2012-12-16 13:52:36

It is an excellent write up, that's what I thought. Maybe a too complex scenario he uses, but that makes it even more educative.

If you don't use cryptsetup-reencrypt now to change your setup, it also introduced another just as important feature: the ability to re-encrypt later. Until this cryptsetup release there was no method to change the master key hash created during setup. Now you can.

That leads to your open question about key-files. For example: if you loose your USB key file dongle, you can now use your backup keys not only to access the machine, but also to invalidate the lost keys even if they were the Luks master keys.

But with respect to having the keys on an USB/SD, I think it is important to be clear about practical implications: Do you mind having to handle the USB dongle safely all the time, have it stick out when you carry around the powered notebook, etc.

Disk encryption is for physical security, i.e. the number one risk you use it against is notebook theft. It does not protect against any runtime logical attacks. So, you have to either keep the key-files encrypted (requiring even more hacks of standard tools to get that to work, see Luks wiki) or keep the USB/SD physically secure and separate from the machine, particularly in mobile situations (when physical theft may occur).

You get my reasoning: For the average user with one machine's Luks keys to be protected I would say key-files on those standard removable medium are simply not practical enough to weigh in against the benefits.

WonderWoofy · 2012-12-16 16:48:29

I definitely found that writeup very informative. Actually when I was looking at what tools/files were included with the cryptsetup package, I noticed there was the reencrypt, but I didn't take the time to look at the man page, as I was so busy learning just the basics. There was no mention of the cryptsetup-reencrypt on the wiki page, so I forgot about it until you linked me to that article. Even if I don't end up using that tool, it is definitely good information to have. Even though I have never used encryption before, I really think that the ability to reencrypt must make it so much more versatile.

So are you telling me that if I want to use a key-file on a USB/SD, obviously I have to have it in when I boot, but I also have to keep it plugged the whole time the conputer is operational? I was under the impression that once it was unlocked, it was unlocked. I could see if the computer is somehow set up to lock itself from inactivity, there would then be the need to once again unlock with the key.

That brings up another quick question I have been pondering. I don't know that I will actually implement this, as again, I am really just thinking about doing this because I like to tinker. But what about relocking the computer after a period of inactivity. I would imagine that simply suspending the machine itself would not result in a relocked machine. I know there are screen lockers, but it seems like a rather weak solution for someone who is going through the trouble of encrypting the entire drive. The only plausible solution that I could think up was to use hibernation. That way the computer is actually powered down and the Luks container is then locked down.

BTW, Strike0, I really appreciate you taking the time to toss ideas back and forth with me here. It is always good to get some input before venturing forth.

cfr · 2012-12-16 17:07:34

I'm not sure this is relevant/helpful at all but in Fedora, I use LUKS but not LVM. So individual partitions are encrypted. At boot, I enter the password once and this must unlock multiple partitions (at least / and /var). However, when I login, I get asked for the password again and I get a series of error messages complaining that partitions cannot be mounted. These are spurious, I think - sometimes the complaints include / even though / is clearly mounted fine. In fact, everything gets unlocked and mounted fine.

However, that makes me wonder whether you'd need the key for more than just boot. But this might just be a quirk of Fedora. Since I'm using a different setup in Arch, I can't be sure whether it is or is not something about Fedora's system or the particular config I'm using in that case.

WonderWoofy · 2012-12-16 17:18:41

Thanks for the input cfr, I was surprised it took you this long to sniff out my thread here.

My /boot is actually separate, as it is my ESP as well. (I am one of those that simply mounts my EFI System Partition to /boot directly). So I don't ahve to typical concerns about using a bootloader that can handle encrypted stuffs and whatnot.

That is very interesting that Fedora acts that way on your computer. Is the process of installing an encrypted system with Fedora automated at all? I kind of thought that there were options to handle this within the installer. But from what I seem to gather from my reading here, if you create a crypttab (or rather add entries to the one shipped with filesystem), and you include the location of the keys, systemd should treat it similarly to the fstab, and use a generator to create systemd-cryptsetup@.service units. I foudn that there is /usr/lib/systemd/systemd-cryptsetup-generator that should handle this for you.

What is it that you ended up going with in the end cfr? For you Arch system, did you do LVM on Luks?

cfr · 2012-12-16 19:24:35

It didn't take me this long to find the thread - I just didn't have anything to say before. (Also, my laptop is not behaving itself very well again.)

For Fedora, yes, the installer automated the process.

For Arch, I used LVM on LUKS and that works just fine. Basically, I have three partitions: EFI, /boot, LUKS. I then have LVM on LUKS with all the rest of the partitions within the LVM. Since I only use the one disk, this is entirely straightforward and works quite elegantly - just enter password on boot and that's it.

Strike0 · 2012-12-16 20:19:23

Debian/Ubuntu ship a cyptsetup script for key-derivation. That basically does derive keys from your master key for mounts like /tmp or swap. I don't know Fedora, but I would assume cfr's install uses something like that. What the error he sees is about, I have no idea. Bug them ;-) But (important!) don't ever try to change your luks master key until you clarify how those mounts get the keys/unlocked there, cfr.

Usually, once the blockdevice is unlocked the key-file medium can be unmounted. But if you, WonderWoofy, revisit your posts: you started thoughts on which other key-files apart from that for your root device you could put on the medium, now you turn to relocking the device on non-activity ... each of those require prolonged or repeated use of the key-file medium. So, thou shall remember more often how much passphrase typing you save when re-plugging it :-)

As for screen lockers, I think you underrate that. I write that although, just with Xorg 1.11 this year, there was a severe vulnerability in the screensaver. Plus it is not the first, just google it. However, we are using Arch and that shiny bug got rolled over particularly swiftly .. too quick for notebook thieves to ramp up their activities one would presume (something that commercial software firms dont ... err .. always achieve, i read). You know a way to circumvent the screensaver or why you consider it weak?

If you are worried that much about your data, you should use separate measures to protect it. For example, having a separate partition for that data or a further encrypted directory in your usual /home (e.g. with ecryptfs).

WonderWoofy · 2012-12-16 21:33:02

Okay, so I decided to just go ahead and do it. I backed up to an external drive (which took suprisingly little time since it is USB 3.0), then I actually booted from said drive so that I could reference this thread easily and so I could continue to do other things while it transferred. Then I ended up doing LVM2 on Luks on RAID. I went with RAID 0 because, like I mentioned, my data is not super valuable, and I am simply doing this to tinker.

So in the end, it was super easy because I went with RAID, and that made it one large drive. I used a simple passphrase for the key, but I also used a random picture of my late dog Woofy as a separate backup key. Then I saved it to a usb key for test purposes. It works great. Thanks to the aesni-intel module, I really don't see any real reduction in speed either.

I don't think that I am going to worry about the screen lockers and all that, as I don't really care. @Strike0, the reason I mentioned the security vulnerabilities of the screen lockers is because of what I have read on the internets in the past. I don't personally have an opinion of weaknesses or anything, but just thought I would ask.

Thanks cfr, Strike0, and saharchie for all the input.

OT, @cfr I am sorry to hear your laptop is an the fritz again. Is it randomly powering off again?

cfr · 2012-12-17 23:14:51

OT reply: yes. It did it twice this weekend while I was staying with friends. So now I've reproduced it not-in-my-office. All extremely weird...

Glad you got all encrypted. I found writing the random data to the drive was what took the time in the end.

Last edited by cfr (2012-12-17 23:15:32)

Strike0 · 2012-12-18 00:16:42

Excellent, I'm glad too to read about that swift migration & sorry to read about your dog.

Let me take the opportunity to add to the thanks by thanking the authors of the aes/aes-asm modules. Also for optimizing the code years ago when no cpu had AES hardwired.

WonderWoofy · 2012-12-18 03:18:53

Thanks again cfr and Stike0. I am honestly really surprised how fast things actually are with the aesni-intel module. I have really not been able to tell a difference from before. The only time I think I was able to see a difference was when I went through the steps outlined on the SSD Benchmarking wiki page. But actual usage is the same. So I will second your thanks to the authors of the aes modules.

And about my dog, he died about a year and a half ago. But he was 19 years old, so had lived a long and happy life. I remember getting him when I was ten years old. He was a year, and he died last year when I was 28. So as sad as it was/is, I was glad to have given him a good home for as long as I was able. He is actually the dog pictured as my avatar. His passing was what prompted the use of WonderWoofy as my username for many things.

cfr · 2012-12-18 21:10:58

It is obviously possible that your usage pattern makes a difference but, to be honest, I haven't been able to tell a difference using encryption either and I have none of the benefits of the hardware support as mine does not support it. That's not to say that they haven't done a good job - just that I'm not sure that your experience would establish that unless you had some control case for comparison!

Arch Linux

#1 2012-12-15 01:46:03

Encryption advice... [Solved]

#2 2012-12-15 18:12:12

Re: Encryption advice... [Solved]

#3 2012-12-15 18:37:34

Re: Encryption advice... [Solved]

#4 2012-12-15 21:04:50

Re: Encryption advice... [Solved]

#5 2012-12-16 01:07:31

Re: Encryption advice... [Solved]

#6 2012-12-16 01:15:12

Re: Encryption advice... [Solved]

#7 2012-12-16 13:52:36

Re: Encryption advice... [Solved]

#8 2012-12-16 16:48:29

Re: Encryption advice... [Solved]

#9 2012-12-16 17:07:34

Re: Encryption advice... [Solved]

#10 2012-12-16 17:18:41

Re: Encryption advice... [Solved]

#11 2012-12-16 19:24:35

Re: Encryption advice... [Solved]

#12 2012-12-16 20:19:23

Re: Encryption advice... [Solved]

#13 2012-12-16 21:33:02

Re: Encryption advice... [Solved]

#14 2012-12-17 23:14:51

Re: Encryption advice... [Solved]

#15 2012-12-18 00:16:42

Re: Encryption advice... [Solved]

#16 2012-12-18 03:18:53

Re: Encryption advice... [Solved]

#17 2012-12-18 21:10:58

Re: Encryption advice... [Solved]

Board footer