# automatic mounting of LUKS /home partition

## ycUygB1

The documentation for LUKS is in a very sorry state.  I knew I was in trouble when the docs said

 *Quote:*   

> LUKS adds 4 actions to cryptsetup, namely luksFormat, luksOpen, LuksAddKey, and luksDelKey.  Although the names are quite 
> 
>       self-explanatory, I'll give brief examples...

 

Then no explanation is given about what the commands do, and to make matters worse, there is actually another command "luksClose"

which is not explained either.  Enough flaming.

I would like to encrypt /home and have it mounted automatically at boot time. 

The encryption password should be required to boot.  On shutdown, the partition should

be cleanly unmounted.

Here's what I have done so far:

# cryptsetup -y -s 256 luksFormat /dev/sda6

# crytsetup luksOpen /dev/sda6 /home

# mkreiserfs /dev/mapper/home

# mount /dev/mapper/home /home

# cd /home

# adduser -m harold

Then I added the following line to /etc/fstab:

/dev/mapper/home   /home   reiserfs   noatime  0 2

Now I can create files in /home and then:

# umount /home

# cryptsetup luksClose home

I was a little nervous that this would delete all the data on the encrypted partition, 

since there is absolutely no description in the docs about what this command does

other than to say that it is obvious.

But apparently, after this, I can access the data again by

# cryptsetup luksOpen /dev/sda6 home

# mount /dev/mapper/home /home

So things are working, after a bit of finger-crossing and guessing.  But now the question is,

how to make this happen automatically at boot time??  

Right now, when I boot, I get the error message:

 *Quote:*   

> mount: special device /dev/mapper/home does not exist.

 

After booting finishes, I am able to access the data using cryptsetup luksOpen and mount as above.

Also, for the sake of completeness, it might be useful to answer the following questions about

LUKS

1)  Please describe the relationship between the "master key" and the other keys that are added

with luksAddKey.  For instance, does one generally need both the master key and the second key 

in order to access the data?  Can you access the data with just the second key?  Does each user

have a different key?  Can they access each other's data?  I know they can delete each other's keys.

That seems weird.

2)  What is the relationship between a user's Linux password and the luks Key?  Would it be

possible to have each user's password also be a luks key?  Is this a good idea?

3)  What does luksClose actually do?  What does luksOpen actually do?  It appears necessary to 

"open" the device before mounting it.  Why?  Why is it necessary to unmount before closing?

----------

## ycUygB1

I feel like a rat that went down every possible path in the maze only to find out that the way out of the maze

was right next to me.

Although there doesn't seem to be any documentation on this, it seems that cryptsetup-luks is part

of the baselayout installation (at least in my ~x86).  In fact, the cryptsetup package blocks cryptsetup-luks,

so you need to unmerge cryptsetup.  You should have a file /etc/conf.d/cryptfs

Here are the steps I took:

1) Compile the kernel with support for tmpfs and dm-crypt

CONFIG_TMPFS=y

# CONFIG_BLK_DEV_CRYPTOLOOP is not set

CONFIG_DM_CRYPT=y

CONFIG_CRYPTO=y

# CONFIG_CRYPTO_HMAC is not set

# CONFIG_CRYPTO_NULL is not set

CONFIG_CRYPTO_MD4=m

CONFIG_CRYPTO_MD5=m

CONFIG_CRYPTO_SHA1=m

CONFIG_CRYPTO_SHA256=m

CONFIG_CRYPTO_SHA512=m

# CONFIG_CRYPTO_WP512 is not set

# CONFIG_CRYPTO_TGR192 is not set

# CONFIG_CRYPTO_DES is not set

CONFIG_CRYPTO_BLOWFISH=m

# CONFIG_CRYPTO_TWOFISH is not set

# CONFIG_CRYPTO_SERPENT is not set

CONFIG_CRYPTO_AES_586=m

# CONFIG_CRYPTO_CAST5 is not set

# CONFIG_CRYPTO_CAST6 is not set

# CONFIG_CRYPTO_TEA is not set

# CONFIG_CRYPTO_ARC4 is not set

# CONFIG_CRYPTO_KHAZAD is not set

# CONFIG_CRYPTO_ANUBIS is not set

# CONFIG_CRYPTO_DEFLATE is not set

# CONFIG_CRYPTO_MICHAEL_MIC is not set

# CONFIG_CRYPTO_CRC32C is not set

# CONFIG_CRYPTO_TEST is not set

# CONFIG_CRYPTO_DEV_PADLOCK is not set

2)  emerge multipath-tools cryptsetup-luks

3)  Read http://www.gentoo.org/proj/en/hardened/disk-cryptography.xml and setup your swap as in item 3.

4)   For an encrypted /home partition:

```

# cryptsetup -v -y -c aes -s 256 create crypt-home /dev/sda5

# mkreiserfs /dev/mapper/crypt-home

# mount /dev/mapper/crypt-home /home

```

5)  Edit /etc/conf.d/cryptfs:

```
swap=crypt-swap

source='/dev/sda3'

mount='crypt-home'

source='/dev/sda5'

options='-c aes -s 256'

```

6)  Check to make sure that things are working with

```
 #dmsetup ls

crypt-home      (254, 1)

crypt-swap      (254, 0)

```

7) Edit /etc/fstab:

```
/dev/sda2               /boot           ext2            noatime         1 3

/dev/sda6               /               ext3            noatime         0 1

/dev/mapper/crypt-home  /home           reiserfs        noatime         0 2

/dev/mapper/crypt-swap  none            swap            sw              0 0

none                    /tmp            tmpfs           defaults        0 2
```

8)  Add a user who will use the encrypted /home partition

```
 

# useradd -m -G wheel,audio harold         

# passwd harold

```

When you reboot, you will be asked for the password in order to mount crypt-home.

It wasn't that hard, after I made every possible mistake.

----------

## GenKreton

I recently encrypted my entire / so I have spent some time drudging through the intricacies of dm_crypt luks.

 *Quote:*   

> 1) Please describe the relationship between the "master key" and the other keys that are added
> 
> with luksAddKey. For instance, does one generally need both the master key and the second key
> 
> in order to access the data? Can you access the data with just the second key? Does each user
> ...

 

The keys are independent it seems. You can, for example add a key in slot 1 and remove the original key in slot 0. The only pain is in remembering which keys were in which slot. So they act independently to access the very same data.

 *Quote:*   

> 2) What is the relationship between a user's Linux password and the luks Key? Would it be
> 
> possible to have each user's password also be a luks key? Is this a good idea? 

 

There is no relationship at all. I would advise against using the same passwords but it doesn't really matter. If someone has spent enough energy accessing your data that they broke your encryption either something was implemented poorly, there was a bug, or you chose very weak passphrases. With that said, if they got that far placing the harddrive in another machine or chrooting from a livecd or such would be trivial.

 *Quote:*   

> 3) What does luksClose actually do? What does luksOpen actually do? It appears necessary to
> 
> "open" the device before mounting it. Why? Why is it necessary to unmount before closing?

 

Someone else can probably explain this better than I. Essentially it readies what they call the device mapper. It is a layer that sits between your physical harddrive and the operating system that is sending data at it. if you sent data right to the hd, there would be no way to encrypt it. These devices you create handle the encryption then pass the data to the physical device. With that said, you have to umount before closing the mapper device because the mapper device will be busy as long as the mapper device is in use (mounted).  It could be useful to think of it as a loop device if you are familiar with them.

I hope this helps and I didn't confuse anybody farther.

----------

## ycUygB1

I think you should consider writing the docs for LUKS, because you explained it a lot better

than the official docs did.

Encrypting / scares me.  I suppose you had to make an initrd in order to do this?

What is your thinking about why you should encrypt / and not just /home swap and use tmpfs?

I opted for a simpler solution because it seems to be what Gentoo supports,

and that is usually good enough.

----------

## GenKreton

 *hnaparst wrote:*   

> I think you should consider writing the docs for LUKS, because you explained it a lot better
> 
> than the official docs did.

 

Well thank you. My intentions throughout this, besides garnering experience personally and encrypting my own machines, was to write a definitive guide to the plethora of methods available to use. My friend and I were going to collaborate with our findings on performance, ease, implementation, etc at our LUG in Nashua as a starting ground for this. Right now the information on encryption is too far spread out and contradictory because a lot of the sites are outdated. I firmly believe everyone should be using some encryption.

 *hnaparst wrote:*   

> Encrypting / scares me.

  It's a lot to get into a first but it is worth it and very rewarding once you start to experience successes.

 *hnaparst wrote:*   

> I suppose you had to make an initrd in order to do this?

  Yes I had to make an initrd for a full / encryption scheme.

 *hnaparst wrote:*   

> What is your thinking about why you should encrypt / and not just /home swap and use tmpfs?

  I was thinking that being able to access my binaries without cracking the encryption scheme was the weakest point in my system. They could drop in their own modules and edit things till they could obtain the keys/passwrds to break it if they got my laptop long enough to do the work. Some of my reasoning was paranoia, some of it was motivated by the challenge of doing it. Obviously only encrypting the sections containing personal data wll improve your performance some too.

 *hnaparst wrote:*   

> I opted for a simpler solution because it seems to be what Gentoo supports,
> 
> and that is usually good enough.

  I have to agree with you here. Encrypting individual partitions like /home, /temp and swap is EXTREMELY easy using dmcrypt luks and the unstable baselayout. The gentoo developers did a superb job with /etc/conf.d/cryptfs. It is a lot less work to use this method. Hopefully, myself and others can reduce the work for full root encryption though.

If you have any more questions or input, feel free to post or message me.

----------

## Massimo B.

 *hnaparst wrote:*   

> there is actually another command "luksClose" which is not explained either.

 

luksClose deletes the mapper device /dev/mapper/_xxx which holds the decrypted blockdevice. You have to Open it again and provide one of the passphrases.

 *hnaparst wrote:*   

> how to make this happen automatically at boot time??

 

 Automatically mount dm-crypt encrypted home with pam_mount explains how to open the encrypted home partition with the user password only automatically.

The Howto doesn't explain LUKS. But according to the /etc/security/pam_mount.conf comments, pam_mount should be LUKS aware (so far I didn't succeed either, but later about that..):

```
# Note that pam_mount is LUKS (http://luks.endorphin.org) aware. To

# use luks, you need to have cryptsetup-luks (get it at

# http://luks.endorphin.org/dm-cryp) installed. A config line would be

#volume user1 crypt - /dev/yourpartition /yourmountpoint - - -

# and cryptsetup will be told to read cypher/keysize/etc. from the luks-header.
```

 *hnaparst wrote:*   

> 1)  Please describe the relationship between the "master key" and the other keys that are added
> 
> with luksAddKey.  For instance, does one generally need both the master key and the second key 
> 
> in order to access the data?  Can you access the data with just the second key?  Does each user
> ...

 

The master key will be encrypted by your passphrase. The masterkey is never stored in plain text. Every slot contains a version of the masterkey encrypted by the passphrase of that slot. But I don't know where the masterkey comes from or wether it is generated randomly. You can access your data with every passphrase. To add another passphrase you have to provide one of the registered passphrases. You can delete every passphrase slot. There is nothing like a master passphrase. This I know from the  LUKS-homepage

 *hnaparst wrote:*   

> 2)  What is the relationship between a user's Linux password and the luks Key?  Would it be
> 
> possible to have each user's password also be a luks key?  Is this a good idea?

 

There's no relationship between LUKS passphrase and huser password. The goal of the pam_mount Howto is to achieve that. Instead of a passphrase you take a key-file which is stored on another partition. But obviously not in plain text but ssl encrypted. This encryption is done with the user password. pam_mount reads the key-file decrypted by your user password and opens+mounts the home partition. In order to change a user password you only have to reencrypt the keyfile, manually or with the tool passwdehd

 *hnaparst wrote:*   

> 3)  What does luksClose actually do?  What does luksOpen actually do?  It appears necessary to 
> 
> "open" the device before mounting it.  Why?  Why is it necessary to unmount before closing?

 

luksOpen makes the binding between encrypted /dev/hda3 and the clear /dev/mapper/_dev_hda3. Everyone (who has physical access of course, that is what we talk about) is able to mount that device. Therefore the usual way is alwas: luksOpen -> mount ,  umount -> luksClose

----------

## Massimo B.

To my problem: I've had the pam_mount solution without LUKS working. I would prefer LUKS. LUKS is working manually, but it doesn't accept the passphrase given from pam_mount. I have a hunch that maybe LUKS doesn't read properly from pipe, while reading from file works. Take a look at that:

```
home # echo $KEY >cache

 

home # cryptsetup -c aes-cbc-essiv:sha256 luksFormat /dev/hda5 cache

 

WARNING!

========

This will overwrite data on /dev/hda5 irrevocably.

 

Are you sure? (Type uppercase yes): YES

 

home # cryptsetup -d cache luksOpen /dev/hda5 _dev_hda5

key slot 0 unlocked.

 

home # cryptsetup remove _dev_hda5

 

home # echo $KEY |cryptsetup luksOpen /dev/hda5 _dev_hda5

Command failed: No key available with this passphrase.
```

And of course, I found a quite old  bug report . I opened a  new one.

But for now it seems that only cryptsetup-luks is affected. cryptsetup works fine with pam_mount.

----------

## Massimo B.

I got an answer from the mailinglist: *Quote:*   

> > # echo $KEY >cache 
> 
> Try "echo -n $KEY > cache"
> 
> as noted in the man page, password reading from a file descriptor are
> ...

 

----------

## batistuta

interesting discussion.... few questions   :Very Happy: 

- Do you guys know if the latest ~x86 pam_mount supports luks now?

- How many passwords slots are in LUKS table? The documentation says that there is a limit, but it doesn't say how many

- According to what paoleela said, pam_mount doesn't use a key slot but rather a different file. Does this mean that a limit in the number of slots wouldn't be an issue for large userbase systems?

Just for knowledge

- Let's say that we have a box with 10 users (i.e. a company) all mounting LUKS /home with pam_mount. Then this person leaves the company. Is there any way that he could have "stolen" the master key given (a- he was admin, b- he was just a normal user)?

Any tutorial on encrypting / ?

Thanks

----------

## Massimo B.

pam_mount now supports LUKS at least for my version: sys-libs/pam_mount-0.17-r1. Take the sunrise overlay, that offers a new pam_mount.

I have in mind something around 9 or 10 keyslots.

Every key can delete or overwrite the other keys, but cannot see the passphrase of any other slot.Greetings to Aachen!

----------

## batistuta

My question was based on something you wrote:

 *Quote:*   

> The goal of the pam_mount Howto is to achieve that. Instead of a passphrase you take a key-file which is stored on another partition. But obviously not in plain text but ssl encrypted. This encryption is done with the user password. pam_mount reads the key-file decrypted by your user password and opens+mounts the home partition.

 

So does this mean that the master key to the partition is encrypted with the login password and stored inside a file in some partition? Or does pam_mount use this file, encrypted with the user login passwd, as a second key to then decrypt a master key in a LUKS slot, and this third key in turn opens the partition? In the first case, the only difference is the location of the key (file or LUKS slot). I would assume the file is in some location not accessible to the user otherwise he could get the key. But this approach has a loopwhole, that any other user could boot from a liveCD or via an ext3 driver from a Windows boot, access the key locations, steal the file, and decrypt it with his own password for future access if his account is later deleted. Or an external user could steal the file and run a dictionary attach on these files off-line.

Greeting to Bonn  :Very Happy: 

----------

## Massimo B.

As I said that was not about LUKS. That was before when I had usual cryptsetup. For better security I had a large keyfile encrypted with a small key (same as the user password) and connected to pam_mount. Actually LUKS does that on its own. It takes the keys to encrypt a big master key which no user need to know. Therefore changing the key is quick because only that master key has to be reencrypted, not the partition itself.

These things I remembered from my mind, not sure if it's completely correct. And I have to agree, the Luks documentation is a bit small compared to the importance of the project. At these times when I did my tests (it is running fine for months now without touching, for /home and also for some external usb and firewire devices; they are opened and mounted *if* they are connected at login) they told me to help making the docs better.

----------

## CodAv

 *batistuta wrote:*   

> - How many passwords slots are in LUKS table? The documentation says that there is a limit, but it doesn't say how many

 

LUKS provides 8 key slots. You need to enter any one of them to open the partition. This enables you to change and revoke passphrases without re-encrypting the whole partition.

 *batistuta wrote:*   

> - According to what paoleela said, pam_mount doesn't use a key slot but rather a different file. Does this mean that a limit in the number of slots wouldn't be an issue for large userbase systems?

 

On a multi-user system, you probably don't want to stuff all user data in one encrypted container. Rather, you'd create a container for each user's home dir, which is mounted to /home/$USERNAME at login. The container doesn't have to be a partition, you can LUKS format a simple file and mount it via the loop device. One drawback of this method is that you need to allocate a lot of disk space for the container files, even if a user has only a few kilobytes of data in his homedir.

 *batistuta wrote:*   

> Just for knowledge
> 
> - Let's say that we have a box with 10 users (i.e. a company) all mounting LUKS /home with pam_mount. Then this person leaves the company. Is there any way that he could have "stolen" the master key given (a- he was admin, b- he was just a normal user)?

 

There are rumours that it is possible to access the memory area storing the master key when a dm-crypt partition is mounted. As far is I know you only need to have just the rights of a local user to compromise the key. Again, to stay secure, every user should have his/her own LUKS container. As an "admin", which means he had root access to the machines, he could simply use a keylogger daemon to sniff the user's passwords.

----------

## batistuta

Is there no performance loss if using a loop device? I'm talking about a 30GB worth of data in my home partition. In any case, this approach doesn't scale too well... was LUKS never intender for enterprise solution or am I missing something? think about a samll company with 20 users. You can't have 20 LUKS slot, but neither 20 partitions or 20 loopback devices.

According to the docs, LUKS supports a keyfile as well. This was the steup I was refering to. Is this a stand-alone master key, or a key to decrypt a LUKS-slot key?

----------

## forrestfunk81

 *batistuta wrote:*   

> According to the docs, LUKS supports a keyfile as well. This was the steup I was refering to. Is this a stand-alone master key, or a key to decrypt a LUKS-slot key?

 

A keyfile uses a further key slot.

My way:

```

# create a file containing some text

 echo "aS?d2jfo305,qIjea_Efajs34EflkZ-jas@lk,.-fjPqeJrsA2klfjMd§y+#xco8jvyBx?:c" >> /home/XX/.crypt.key

# encrypt the content

dd if=/dev/random of=/home/XX/.crypt.key count=1

# add this key file

cryptsetup luksAddKey /dev/sdaX /home/XX/.crypt.key 

# open partition using the key file

cryptsetup luksOpen /dev/sdaX /dev/mapper/crypt-XX -d /home/XX/.crypt.key

```

then save the key file on your truecrypt encoded usb stick - paranoia ftw   :Wink: 

greetings

----------

