Encryption Questions

[StargateGamingGeek]

I am making my first post on these Gentoo Forums here and just jumping right into the heavy questions. So here goes...

I am trying to figure out how to do some pretty interesting looking stuff with Gentoo and encryption mostly for the purpose of security on a laptop computer. I have been reading up on these forums and elsewhere on DM-crypt and Truecrypt and LVM2 and I have put together a "plan" so to speak but I think I may need some guidance on how to implement it. My thought is to setup a single partition with some logical volumes inside so that from the outside everything looks like one big partition filled with random data. Inside that You would of course need a / partition and a SWAP partition (need there is up for debate with SWAP I understand but let's just take it as a given here). Those could be encrypted with DM-crypt and auto-mount/created during boot. /boot itself could be contained on a USB Thumbdrive so that you don't have to have the unencrypted data on the drive to foil your deniability. Then you could have a partition for /home and other personal stuff encrypted using truecrypt. The thing I wondered about there was the possibility of setting that up to mount when you log-on to your user account. Anyone have any suggestions or critique of my "plan" or helpful advice on hwo to pull it off? I have managed to find good tutorials on how to setup Gentoo with this kind of setup without LVM2 or truecrypt. I can't find anything helpful in the way of instruction on how to setup LVM2 and dm-crypt together in this manner. And I haven't been able to find much of anything for setting up truecrypt. Any help or advice is appreciated.

[guero61]

Here's a bit I wrote about my exploits in this arena. In short, you'll want LVM on top of cryptfs (I had an additional RAID-1 layer there). To do it right, you may need an initrd, but you're already on your way there using a thumb drive. I've long toyed with the idea of setting up an initrd that put a shim in before /sbin/init that would request a password and do the decryption for you, but I've just not had time to mess around with it.

What I really want is a bootloader that will do the password/decryption scheme, but that kinda goes beyond the scope of GRUB or LILO and more into the realm of xen or some other hypervisor.

One thing you should want to do is use LUKS - primarily because it's compatible with several open source cryptfs paradigms, including some for Windows.

[StargateGamingGeek]

What does all that really say? I got most of it but alot of it didn't make sense. That may be because of my lack of experience with LVM but here's my question for you. I was hoping to set it up so that you only have one visible partition and set the rest up using logical volumes inside the bigger physical volume. Resizing isn't an issue really I just wanted LVM for that because I seem to remember seeing a howto using encrypted volumes and LVM in a setup like that but I can't find it anymore.

[guero61]

This is how I did it; there are likely holes, so don't take any of this for perfect truth:

1. cryptsetup luksFormat <my encrypted partition>
2. cryptsetup luksOpen <my encrypted partition>
3. edit /etc/lvm/lvm.conf & add "types = [ "device-mapper", 16 ]" (less outer quotes) to the devices block
4. pvcreate /dev/mapper/<cryptvol>
5. vgcreate -n VGCRYPT /dev/mapper/<cryptvol>
6. Partition out your LVM w/lvcreate.
7. Modify RC_VOLUME_ORDER in /etc/conf.d/rc to put LVM after cryptfs
8. Edit /etc/conf.d/cryptfs to load your encrypted partition at boot

If that's still a bit confusing, I strongly suggest spending some time familiarizing yourself with cryptfs and LVM - each by itself is quite a technology to pick up and understand.

[StargateGamingGeek]

That is a bit clearer yes. That was kind of what I figured I'd end up having to do was find a spare drive and just install gentoo a bunch of times and mess with the process until I finally got it right the way I wanted it. Thanks for the help. I'll keep posting results as I get them. Anybody else has any advice please post. The way I see it there's a place for trial-and-error but why does it all have to be your error when others may have paved the way and can help you steer clear of the error? That is why I love forums like this. There is always someone who does done something at least close to what you want to do before or has seen someone that did.

[Reikinio]

Hi,
Just to let you know, that you might be interested in a guide I wrote(see sig), it documents the process of setting up an encrypted Gentoo system using dm-crypt, crypsetup(luks).
It's far from perfect, and it doesn't contain instructions for lvm since I didn't consider it necessary for my setup, but it does contain instructions for booting from usb-stick(although at the moment the gpg key has to reside on the initramfs, I'll try to change this in the future since I think it's silly).
Anyway, see if you can find anything useful on it.

Bye

[StargateGamingGeek]

I was browsing around through an LVM tutorial and all the sudden I had one of those Eureka moments. I was re-reading the terminology involved with LVM and suddenly it clicked. Anyone who knows about LVM feel free to correct me if my epiphany was not complete but here goes:

What I'm looking for is setting up a real partition as the PhysicalVolume(PV) for LVM. Breaking that into three LogicalVolumes(LV's) which are basically "partitions". Making one of those SWAP and one / and the other /home. Then pass those LV's to DM-Crypt and create a mapping and a filesystem. The DM-Crpyt stuff I can do following Reikinio's Guide. The LVM stuff I'll need to find conrete instructions on but at least I have a Model for what I'm Looking for now. To DM-Crypt the LV's should be nothing more than partitions on a normal setup so there shouldn't be a problem there. So it would look like:

----> LV1 --> DM-Crypt mapping --> filesystem --> /
/
/hda--->LVM(PV)-<------> LV2 --> DM-Crypt mapping --> filesystem --> SWAP
\
----> LV3-->TBD

The only missing link comes from LV3 which is /HOME. I want to try and encrypt it using truecrypt. I think I can manage to auto-mount /HOME at user log-in using PAM once I get it setup. I just have to find out some stuff about using truecrypt in this kind of scenario first. Like I said any sort of opinion or experience that might be helpful here is appreciated.

[Clansman]

Hi everyone.

I've been on to this issue for some months now, but I don't think there is (yet?) an elegant solution. I don't know what happens under the hood, but from the user's perspective, the elegant solution is one like OSX'.

You see, most of the filesystems are practically of no use for others (unless you're not careful where you put your data). What really REALLY matters is users's data - homedirs.

The perfect solution would be to have filesystem level encryption to support dinamic size and encryption keys/algorithms per user. The perfect solution is to say: "this subtree is from now on secured with encryption algorithm XYZ, hashing algorithm ZYX, the key is stored _here_, use _this_ password (or login's) and put a recovery key _there_", and that's it! no loopback volumes of fixed size, no global encryption, no different complicated setup for desktops/servers/etc., no fixed algorithms/keys, ...

Man, when (not if, I'm a believer) Linux gets there, there will be much rejoycing

Care to comment?

Cheers guys,
_________________
http://www.pjvenda.org

[guero61]

The difference is what your expectations are. If you trust the system to never be touched, never be compromised and only want to protect users' data, then yes - only encrypting /home is a reasonable approach.

However, if you're paranoid (like me) and want to assume that at any point in time someone has been able to take your drive[s] out and image them or replace system binaries with trojaned ones, then full-disk encryption is the only viable approach (no, tripwire can be circumvented too at that point - don't go there). We're talking fully hostile environment here, with pwn4ge intent - not stealing data.

My perfect solution would be a hardware drive controller that requires a dongle and takes a boot-time password (during POST) before the OS even starts. I might still encrypt some files therein, but the intent is to completely mask what's on the drive and prevent any tampering whatsoever, short of destroying the data. If such a thing exists and is reasonably priced, someone please point me there.

[Clansman]

Maybe my proposal isn't appropriate for state secrets or something like that. It's just a very effective and elegant solution for a very common problem (that most people aren't aware of).

I couldn't care less if someone stole my wireless shared key by stealing my laptop, but I'd pissed (and eventually fired) if my personal and professional information would be compromised. Guess where that is? /home, of course.

Anyway, experience taught me that security is inversely proportional to usability (just look at all the work you guys are having to encrypt the whole filesystem with 1 key and 1 algorithm). So the best solution is allways, but I mean ALLWAYS a compromise. What good is a uber-secure server if you can't use it?

Consider the situation where you use different linux desktops or servers and you have your home in an USB drive. It would great if my proposed scheme was possible! The only information that matters is what's in the USB drive and no thief can use it. At the same time, all desktops would be able to mount and use my home directory before my credentials remember that encryption is at filesystem level so the mount procedure would be transparent.

Well, I'm just thinking out loud.

Cheers,
_________________
http://www.pjvenda.org

[StargateGamingGeek]

Actually most of this stuff when fully implemented will be as simple as you are wanting. Once you get it setup you can have it so with one password at boot you get everything mounted except /home. Then with your user password you can access the credentials and mount /home. If you store the credentials for all that mounting on a USB thumbdrive and password protect them and probalby GPG encrypt them you made them secure and added another authentication facotr to the mix meaning that now you have Two-Factor-Authentication as opposed to single-fact-authentication. That is better for security because it means you can trust that you are who you say you are with higher reliability. Your points about setting it up are valid of course but once it's setup right you can do this all as easy as you want to. In fact if you don't mind the compromise to security you can have it decrypt everything except /home just by having the USB Token plugged in at the right time but you sacrifice the two-factor-authentication for that decryption which can be an issue if you are concerned about the security of things that may accidentally get out of your /home partition. But like I said your points on setup are fully valid and are something that is being worked on by many as we speak. DM-Crpyt is something that is built into the kernel as is LVM2 it just needs a simpler list of commands to set it up. Or more likely to be able to satisfy you a GUI. However most people that use Linux and especially the kind paranoid/tech-savvy enough to do something like this aren't going to be afraid of doing some work at a command prompt. In fact many would prefer to do it themselves at a prompt than to trust that someone else had done it right in a script and remove a possible weakness in the implementation by doing the setup themselves.

[Clansman]

[guero61]

There's only one misnomer I'd care to address:

[StargateGamingGeek]

I get the feeling you are just ignoring some of the stuff I said. I fully agreed with your points on how it needs to be made less complicated to do. I pointed out that alot of people feel safer doing it the hard way but I don't mean to imply that that is how it should be done at all. As I said again it is something that must be customized in implementation to the setting where it is used. Not everyone can deal with having a password to mount root and a passwor to mount /home so you can do away with that. Also GPG is only one option for how that can be secured. You can leave it in the clear really. It's about how paranoid you want to be. Again it comes back to customized implementation. Certificates could provide the same functionality without the need for keys to be encrypted. But I wonder about your comments on using your GPG encrypted USB token on multiple computers. Mainly why are you using the same keys on multiple computers? That's not such a good idea. And if you are moving data on the Token then a different solution may be required. Say a self extracting encrypted file with a password on it. That would be portable and encrypted and growable. If you want a "mount" solution that isn't size limiting and want to grow your stuff then consider loop-AES which allows you to setup a file as a filesystem and should as a result allow you to expand it as needed. I'm not sure if you can expand that however so you would have to check. The point is that you have options. That is one of the main reasons I was drawn to opensource, the options. There isn't just one way you can do something but alot of different ways to do it that can be made to work for your specific situation. If some of this stuff won't work for you there is no need to complain about how that's not right or whatever just look around and find something that is right for you. The options are out there and all you have to do is look for them. If a GUI is what you require then you could use some of your time and coding skills and help write one. Complaining is not something that will help get you anywhere.

Going back to your original post about your scheme here's some ideas:
You could keep the /home on an external harddrive giving you the size you want and keep the keys and the static software on a usb thumbdrive and use that to acess your /home.
Or you could keep a large loop file on whatever you use for storage and have a digital certifacte in the clear on the storage medium and your encryption program. I know the winblows version of truecrypt can run in traveller mode so you never have to install it but can still access it from any computer maybe the linux version has a similar feature? Even if it doesn't there are similar products that might. I'm sure there is a way to implement the scheme of which you spoke it just may not be entirely seemless in setup. At this stage that is something you just have to accept. Encryption in linux hasn't gotten to the point where it is fully integrated and seemless. It is still something that has to be done almost hacked together. But the more people use it and help refine the programs and systems involved the sooner it will be ready to be integrated so that it can be seemless.

[Clansman]

Sorry if I seemed to ignore you. That was not the purpose. Also I wasn't clear on some points either, but you all got the general point and your last comments show that you understood the idea.

The method of having lvm on top of cryptfs is nice and makes sense, but what if I want to expand my VGs, is there a way to create another cryptfs on another md device with the same key and then do some more PVs there? I'd say it can.

I'm thinking in investing some time onto it for my laptop. Since I'm the only user, I'll probably mount /home on an lvm on top of cryptfs. --> Time to investigate!

Again thanks for the comments.
Cheers,
_________________
http://www.pjvenda.org

[Carlo]

Be sure to have read this article, before you choose a crypto implementation.
_________________
Please make sure that you have searched for an answer to a question after reading all the relevant docs.

[guero61]

@Carlo
I appreciate that article - haven't seen it before. I wonder, though, if it's not a bit irrelevant since it specifically states, "dm-crypt in kernels prior to 2.6.10" - if dm-crypt was fixed then and since most of us are using 2.6.16 series kernels, we should be okay using it... The other stuff doesn't count *as much*, since we're (SGG & I) are primarily discussing full-disk encryption w/dm-crypt. I'll have to dig more before I commmit a whole-disk installation to this.

@Clansman
I don't see any reason you couldn't do that very thing - in fact, doing that makes a nice end-around on the [assumed] cryptfs chokepoint.

Does anyone have any specific documentation (I'll look myself) that dm-crypt filesystems cannot be expanded?

[Clansman]

Thanks. That's very nice reading!

Cheers,
_________________
http://www.pjvenda.org

[StargateGamingGeek]

I have a question mainly for guero but anybody is welcome to answer. You mentioned having put the crypto layer first then lvm would that still allow you to have a single large partition and then slice it up into smaller partitions using LVM? And could you then add another layer of crypto ontop of the lvm layer in order to have swap with a random key and other things like that?

Also I found an article talking about dm-crypt and various things and the reason I mention it is because of an interesting idea brought up in the comments. Namely that you could create a temporary mapping with dm-cryt using a long key generated from /dev/random and then write ti that mapping with /dev/zero and fill it with random data quickly. It seems like it might work aybody tried anything like that or know of a reason why it will or won't work?

[guero61]

[StargateGamingGeek]

@guero That's great to hear it will make my life a bit easier. I wonder how much difference that would make to swap? and would you gain much in the way of security? over un-encrypted swap I'm sure you'd be more secure just by having the encryption layer either way. I might have to try it in different setups and check the speed gained/lost. I was really liking the security idea of just having a partition filled with "random" data and no visible OS and having unencrypted external /boot so as maybe to gain some plausible-deniability. Give them the whole "I was messing with some crypto stuff just for kicks and nuked my data partition" type scenario.

[guero61]

[Carlo]

guero61: The article gets updated regularly and quoting the relevant part

[guero61]

guero61 smacks himself

Note to self: re-read 3x before posting any synopsis.

[troymc]

I've been running something similar for a while.