Difference between revisions of "Dm-crypt/Encrypting a non-root file system"

From ArchWiki
Jump to: navigation, search
(Automated unlocking and mounting: rm accuracy tag; systemd-initramfs is supposed to handle unmounting on shutdown, (re: deprecation of mkinitcpio shutdown hook))
m (Manual mounting and unmounting: we usually format "e.g." more simply :))
 
(46 intermediate revisions by 13 users not shown)
Line 1: Line 1:
 
{{Lowercase title}}
 
{{Lowercase title}}
[[Category:Security]]
+
[[Category:Encryption]]
 
[[Category:File systems]]
 
[[Category:File systems]]
Encrypting a secondary filesystem usually protects only sensitive data, while leaving the operating system and program files unencrypted. This is useful for encrypting an external medium, such as a USB drive, so that it can be moved to different computers securely. One might also choose to encrypt sets of data separately according to who has access to it. For example, in the case of a computer that has multiple users, each user's home directory may be encrypted separately to ensure that users can not access each others' data, while still having access to the system and public files.
+
[[ja:Dm-crypt/root 以外のファイルシステムの暗号化]]
 +
Back to [[dm-crypt]]
  
Although encrypting a non-root filesystem is possible with [[dm-crypt]], there are more flexible and user friendly ways to achieve the same result. Because dm-crypt is a [[Disk Encryption#Block_device_encryption|block-level]] encryption layer, it only encrypts [[Dm-crypt/Encrypting_a_non-root_file_system#Partition|partitions]] and [[Dm-crypt/Encrypting_a_non-root_file_system#Loop_device|loop devices]]. To encrypt individual files requires a filesystem-level encryption layer, such as [[eCryptfs]] or [[EncFS]]. See [[Disk Encryption]] for general information about securing private data.
+
The following are examples of encrypting a secondary, i.e. non-root, filesystem with dm-crypt
 +
== Overview ==
 +
Encrypting a secondary filesystem usually protects only sensitive data, while leaving the operating system and program files unencrypted. This is useful for encrypting an external medium, such as a USB drive, so that it can be moved to different computers securely. One might also choose to encrypt sets of data separately according to who has access to it.  
 +
 
 +
Because dm-crypt is a [[Disk encryption#Block_device_encryption|block-level]] encryption layer, it only encrypts full devices, [[#Partition|full partitions]] and [[#Loop_device|loop devices]]. To encrypt individual files requires a filesystem-level encryption layer, such as [[eCryptfs]] or [[EncFS]]. See [[Disk encryption]] for general information about securing private data.
  
 
== Partition ==
 
== Partition ==
Line 11: Line 16:
 
{{Tip|You can either have a single user's {{ic|/home}} directory on a partition, or create a common partition for all user's {{ic|/home}} partitions.}}
 
{{Tip|You can either have a single user's {{ic|/home}} directory on a partition, or create a common partition for all user's {{ic|/home}} partitions.}}
  
First, prepare the partition by securely erasing it, see [[Dm-crypt/Drive Preparation#Secure erasure of the hard disk drive]].
+
First make sure the partition is empty(has no file system attached to it). Delete the partition and create an empty one if it has a file system. Then prepare the partition by securely erasing it, see [[Dm-crypt/Drive preparation#Secure erasure of the hard disk drive]].  
  
 
Then setup the LUKS header with:
 
Then setup the LUKS header with:
 
  # cryptsetup ''options'' luksFormat ''device''
 
  # cryptsetup ''options'' luksFormat ''device''
  
Replace {{ic|''device''}} with the previously created partition. See [[Dm-crypt/Device Encryption#Encryption options for LUKS mode]] for details like the available {{ic|''options''}}.
+
Replace {{ic|''device''}} with the previously created partition. See [[Dm-crypt/Device encryption#Encryption options for LUKS mode]] for details like the available {{ic|''options''}}.
  
 
To gain access to the encrypted partition, unlock it with the device mapper, using:
 
To gain access to the encrypted partition, unlock it with the device mapper, using:
Line 31: Line 36:
 
To mount the partition:
 
To mount the partition:
  
  cryptsetup open --type luks ''device'' ''name''
+
  # cryptsetup --type luks open ''device'' ''name''
  mount -t ext2 /dev/mapper/''name'' /mnt/home
+
  # mount -t ''fstype'' /dev/mapper/''name'' /mnt/home
  
 
To unmount it:
 
To unmount it:
  
  umount /mnt/home
+
  # umount /mnt/home
  cryptsetup luksClose ''name''
+
  # cryptsetup close ''name''
 +
 
 +
{{Tip|[[GVFS]] can also mount encrypted partitions. One can use a file manager with gvfs support (e.g. [[Thunar]]) to mount the partition, and a password dialog will pop-up. For other desktops, {{Aur|zulucrypt}} also provides a GUI.}}
  
 
=== Automated unlocking and mounting ===
 
=== Automated unlocking and mounting ===
  
There are two different solutions for automating the process of unlocking the partition and mounting its filesystem.
+
There are three different solutions for automating the process of unlocking the partition and mounting its filesystem.
  
==== Crypttab ====
+
==== At boot time ====
Using crypttab, unlocking happens at boot time: this is the recommended solution if you want to use one common partition for all user's home partitions (or another general mount).
+
  
To make systemd open and mount the encrypted partition on boot, two files need to be edited, {{ic|/etc/crypttab}} and {{ic|/etc/fstab}}. The {{ic|/etc/crypttab}} file describes encrypted block devices that are set up during system boot by {{ic|systemd-cryptsetup-generator}} automatically.
+
Using the {{ic|/etc/crypttab}} configuration file, unlocking happens at boot time by systemd's automatic parsing. This is the recommended solution if you want to use one common partition for all user's home partitions or automatically mount another encrypted block device.  
  
For example, to open the encrypted LUKS partition on the device {{ic|/dev/sdx1}} with the name {{ic|home}}, add this line:
+
See [[Dm-crypt/System configuration#crypttab]] for references and [[Dm-crypt/System configuration#Mounting at boot time]] for an example set up.
  
{{hc|/etc/crypttab|home /dev/sdx1 none luks}}
+
==== On user login ====
The option {{ic|none}} will trigger a prompt during boot to type the passphrase for unlocking the partition. A keyfile can also be set up and referenced instead. This results in an automatic unlocking, if the keyfile is accessible during boot. Since LUKS offers the option to have multiple keys, the chosen option can also be changed later.
+
  
See {{ic|man crypttab (5)}} and read the file {{ic|/etc/crypttab}} for more information.
+
Using ''pam_exec'' and systemd service file, it is possible to unlock the partition on user login: this is the recommended solution if you want to have a single user's home directory on a partition. See [[dm-crypt/Mounting at login]].
  
Edit {{ic|/etc/fstab}} and add an entry for the previously created path in {{ic|/dev/mapper}}. Following above example the fstab entry looks like this:
+
Unlocking on user login is also possible with [[pam_mount]].
  
{{hc|/etc/fstab|/dev/mapper/home /home <filesystem> defaults 0 2}}
+
== Loop device ==
  
==== Pam mount ====
+
A loop device enables to map a blockdevice to a file with the standard util-linux tool {{ic|losetup}}. The file can then contain a filesystem, which can be used quite like any other filesystem. A lot of users know [[TrueCrypt]] as a tool to create encrypted containers. Just about the same functionality can be achieved with a loopback filesystem encrypted with LUKS and is shown in the following example.  
With Pam mount, unlocking happens on user login: this is the recommended solution if you want to have a single user's home directory on a partition.
+
  
See [[Pam mount]].
+
First, start by creating an encrypted container, using an appropriate [[random number generator]]:
  
== Loop device ==
+
# dd if=/dev/urandom of=/bigsecret bs=1M count=10
  
A loop device enables to map a blockdevice to a file with the standard util-linux tool {{ic|losetup}}. The file can then contain a filesystem, which can be used quite like any other filesystem. A lot of users know [[Truecrypt]] as a tool to create encrypted containers. Just about the same functionality can be achieved with a loopback filesystem encrypted with LUKS and is shown in the following example.  
+
This will create the file {{ic|bigsecret}} with a size of 10 megabytes.  
  
First, start by creating an encrypted container:
+
{{Note|To avoid having to [[#Resizing the loopback filesystem|resize]] the container later on, make sure to make it larger than the total size of the files to be encrypted, in order to at least also host the associated metadata needed by the internal file system. If you are going to use LUKS mode, its metadata header requires one to two megabytes alone.}}
  
dd if=/dev/urandom of=/bigsecret bs=1M count=10
+
Next create the device node {{ic|/dev/loop0}}, so that we can mount/use our container:
  
This will create the file {{ic|bigsecret}} with a size of 10 megabytes. Next create the device node {{ic|/dev/loop0}}, so that we can mount/use our container:
+
# losetup /dev/loop0 /bigsecret
  
losetup /dev/loop0 /bigsecret
+
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|# losetup -f}}.}}
 
+
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|losetup -f}}.}}
+
  
 
From now on the procedure is the same as for [[#Partition]], except for the fact that the container is already randomised and will not need another secure erasure.
 
From now on the procedure is the same as for [[#Partition]], except for the fact that the container is already randomised and will not need another secure erasure.
  
{{Note|If while running {{ic|cryptsetup luksFormat /dev/loop0}} you get an error like:
+
{{Tip|Containers with ''dm-crypt'' can be very flexible. Have a look at the features and documentation of [[Tomb]]. It provides a ''dm-crypt'' script wrapper for fast and flexible handling.}}
Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors
+
then run {{ic|modprobe dm-mod}}.}}
+
  
 
=== Manual mounting and unmounting ===
 
=== Manual mounting and unmounting ===
 
To unmount the container:
 
To unmount the container:
  
  umount /mnt/secret
+
  # umount /mnt/secret
  cryptsetup luksClose secret
+
  # cryptsetup close secret
  losetup -d /dev/loop0
+
  # losetup -d /dev/loop0
  
 
To mount the container again:
 
To mount the container again:
  
  losetup /dev/loop0 /bigsecret
+
  # losetup /dev/loop0 /bigsecret
  cryptsetup open --type luks /dev/loop0 secret
+
  # cryptsetup --type luks open /dev/loop0 secret
  mount -t ext2 /dev/mapper/secret /mnt/secret
+
  # mount -t ext4 /dev/mapper/secret /mnt/secret
  
 
=== Resizing the loopback filesystem ===
 
=== Resizing the loopback filesystem ===
 
First unmount the encrypted container:
 
First unmount the encrypted container:
  umount /mnt/secret
+
  # umount /mnt/secret
  cryptsetup luksClose secret
+
  # cryptsetup close secret
  losetup -d /dev/loop0
+
  # losetup -d /dev/loop0
  
After this expand the container file with the size of the data you want to add:
+
Next, expand the container file with the size of the data you want to add:
 
+
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret
+
  
 
{{Warning|Be careful to really use '''two''' {{ic|>}}, or you will override your current container.}}
 
{{Warning|Be careful to really use '''two''' {{ic|>}}, or you will override your current container.}}
 
+
# dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret
You could use {{ic|/dev/zero}} instead of {{ic|/dev/urandom}} to significantly speed up the process, but with {{ic|/dev/zero}} your encrypted filesystems will ''not be as secure''. See [[Random Number Generation]] for more alternatives. A faster (almost instant) method than ''dd'' is ''truncate'', but its use has the same security implications as using {{ic|/dev/zero}}. The size passed to ''truncate'' is the final size to make the file, so do not use a value less than that of the current file or you will lose data. E.g. to increase a 20G file by 10G run {{ic|truncate -s 30G filename}}.
+
  
 
Now map the container to the loop device:
 
Now map the container to the loop device:
  losetup /dev/loop0 /bigsecret
+
  # losetup /dev/loop0 /bigsecret
  cryptsetup open --type luks /dev/loop0 secret
+
  # cryptsetup --type luks open /dev/loop0 secret
  
After this resize the encrypted part of the container to the maximum size of the container file:
+
After this, resize the encrypted part of the container to the maximum size of the container file:
  cryptsetup resize secret
+
  # cryptsetup resize secret
  
Finally, resize the filesystem. Here is an example for ext2/3/4 (check the file system first as it's a bad idea to resize it if it is broken):
+
Finally, perform a filesystem check and, if it is ok, resize it (example for ext2/3/4):
  e2fsck -f /dev/mapper/secret
+
  # e2fsck -f /dev/mapper/secret
  resize2fs /dev/mapper/secret
+
  # resize2fs /dev/mapper/secret
  
You can now mount your container again:
+
You can now mount the container again:
  mount /dev/mapper/secret /mnt/secret
+
  # mount /dev/mapper/secret /mnt/secret

Latest revision as of 02:56, 2 April 2016

Back to dm-crypt

The following are examples of encrypting a secondary, i.e. non-root, filesystem with dm-crypt.

Overview

Encrypting a secondary filesystem usually protects only sensitive data, while leaving the operating system and program files unencrypted. This is useful for encrypting an external medium, such as a USB drive, so that it can be moved to different computers securely. One might also choose to encrypt sets of data separately according to who has access to it.

Because dm-crypt is a block-level encryption layer, it only encrypts full devices, full partitions and loop devices. To encrypt individual files requires a filesystem-level encryption layer, such as eCryptfs or EncFS. See Disk encryption for general information about securing private data.

Partition

This example covers the encryption of the /home partition, but it can be applied to any other comparable non-root partition containing user data.

Tip: You can either have a single user's /home directory on a partition, or create a common partition for all user's /home partitions.

First make sure the partition is empty(has no file system attached to it). Delete the partition and create an empty one if it has a file system. Then prepare the partition by securely erasing it, see Dm-crypt/Drive preparation#Secure erasure of the hard disk drive.

Then setup the LUKS header with:

# cryptsetup options luksFormat device

Replace device with the previously created partition. See Dm-crypt/Device encryption#Encryption options for LUKS mode for details like the available options.

To gain access to the encrypted partition, unlock it with the device mapper, using:

# cryptsetup open device name

After unlocking the partition, it will be available at /dev/mapper/name. Now create a file system of your choice with:

# mkfs.fstype /dev/mapper/name

Mount the file system to /home, or if it should be accessible to only one user to /home/username, see #Manual mounting and unmounting.

Tip: Unmount and mount once to verify that the mapping is working as intended.

Manual mounting and unmounting

To mount the partition:

# cryptsetup --type luks open device name
# mount -t fstype /dev/mapper/name /mnt/home

To unmount it:

# umount /mnt/home
# cryptsetup close name
Tip: GVFS can also mount encrypted partitions. One can use a file manager with gvfs support (e.g. Thunar) to mount the partition, and a password dialog will pop-up. For other desktops, zulucryptAUR also provides a GUI.

Automated unlocking and mounting

There are three different solutions for automating the process of unlocking the partition and mounting its filesystem.

At boot time

Using the /etc/crypttab configuration file, unlocking happens at boot time by systemd's automatic parsing. This is the recommended solution if you want to use one common partition for all user's home partitions or automatically mount another encrypted block device.

See Dm-crypt/System configuration#crypttab for references and Dm-crypt/System configuration#Mounting at boot time for an example set up.

On user login

Using pam_exec and systemd service file, it is possible to unlock the partition on user login: this is the recommended solution if you want to have a single user's home directory on a partition. See dm-crypt/Mounting at login.

Unlocking on user login is also possible with pam_mount.

Loop device

A loop device enables to map a blockdevice to a file with the standard util-linux tool losetup. The file can then contain a filesystem, which can be used quite like any other filesystem. A lot of users know TrueCrypt as a tool to create encrypted containers. Just about the same functionality can be achieved with a loopback filesystem encrypted with LUKS and is shown in the following example.

First, start by creating an encrypted container, using an appropriate random number generator:

# dd if=/dev/urandom of=/bigsecret bs=1M count=10

This will create the file bigsecret with a size of 10 megabytes.

Note: To avoid having to resize the container later on, make sure to make it larger than the total size of the files to be encrypted, in order to at least also host the associated metadata needed by the internal file system. If you are going to use LUKS mode, its metadata header requires one to two megabytes alone.

Next create the device node /dev/loop0, so that we can mount/use our container:

# losetup /dev/loop0 /bigsecret
Note: If it gives you the error /dev/loop0: No such file or directory, you need to first load the kernel module with modprobe loop. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with # losetup -f.

From now on the procedure is the same as for #Partition, except for the fact that the container is already randomised and will not need another secure erasure.

Tip: Containers with dm-crypt can be very flexible. Have a look at the features and documentation of Tomb. It provides a dm-crypt script wrapper for fast and flexible handling.

Manual mounting and unmounting

To unmount the container:

# umount /mnt/secret
# cryptsetup close secret
# losetup -d /dev/loop0

To mount the container again:

# losetup /dev/loop0 /bigsecret
# cryptsetup --type luks open /dev/loop0 secret
# mount -t ext4 /dev/mapper/secret /mnt/secret

Resizing the loopback filesystem

First unmount the encrypted container:

# umount /mnt/secret
# cryptsetup close secret
# losetup -d /dev/loop0

Next, expand the container file with the size of the data you want to add:

Warning: Be careful to really use two >, or you will override your current container.
# dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret

Now map the container to the loop device:

# losetup /dev/loop0 /bigsecret
# cryptsetup --type luks open /dev/loop0 secret

After this, resize the encrypted part of the container to the maximum size of the container file:

# cryptsetup resize secret

Finally, perform a filesystem check and, if it is ok, resize it (example for ext2/3/4):

# e2fsck -f /dev/mapper/secret
# resize2fs /dev/mapper/secret

You can now mount the container again:

# mount /dev/mapper/secret /mnt/secret