Best practices when encrypting external hard drive?

penguin · 2016-05-24 18:41:13

Hi!

I'm trying to figure out the best practices when encrypting an external hard drive. I've been reading through:
https://wiki.archlinux.org/index.php/Dm … ile_system
https://wiki.archlinux.org/index.php/Dm-crypt
But I'm not convinced I'm doing things right. For instance, must one use LVM, or is it fine to skip it?

Here is what I did:
1. I removed all partitions on the external drive, and created one big partition with fdisk

2. The device (/dev/sdb1) is a seagate 3 TB drive, so I call it "seagate":

cryptsetup --cipher aes-xts-plain64 --key-size 512 --verify-passphrase luksFormat /dev/sdb1
cryptsetup open /dev/sdb1 seagate
mkfs.ext4 /dev/mapper/seagate

3. Now mount it (if not already mounted):

cryptsetup --type luks open /dev/sdb1 seagate
mount -t ext4 /dev/mapper/seagate /media/disk

However, how do I best mount this drive and have access to it as a normal user, sometime after boot?

For normal, unencrypted FAT drives, I have the following in my fstab, which allows me to work with usb-sticks as normal user:

/dev/sdb1          /media/disk  auto    user,noauto,rw,umask=111,dmask=000 0 0

But when mounting this encrypted partition, I could not move files to it unless root. Is there a clash when mounting this device to /media/disk?

Also, when using ext4 on an external device, what is the best way to deal with file ownership?

Thanks!

EDIT:
As suggested by @dakota and @Xyne, I should also backup my LUKS header, and store somewhere safe (here at my $HOME, which is also encrypted):

sudo cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file  ~/backup_seagate_LUKS_HEADER.img

EDIT2:
Also, test the backup:

sudo cryptsetup -v --type luks --header /path/to/backupheader open /dev/sdb1 seagate

Last edited by penguin (2016-05-26 09:54:37)

dakota · 2016-05-24 20:44:36

Hello Penguin,

Funny you should mention this... I just got done working my way through both those wikis!

1. I did not use LVM. In fact, I didn't even setup any partitions on the external drive, I just encrypted the whole device.
2. I did not edit the fstab because I intend to manually mount the drive only at selected times (using your step #3).
3. I am using btrfs instead of ext4.
4. Other than those three items, all of our steps match.

However, I don't have any trouble using the drive as a normal user!

I originally mounted my drive to /mnt/dmCrypt, but to check what you did, I created the path /media/disk and mounted my drive there. I still did not have any trouble accessing the drive as a normal user, so I do not think there is clash when mounting to /media/disk.

I created the path as a normal user using sudo, but when that worked I deleted the path and recreated it as root.

In both cases the folder permissions were...

drwxr-xr-x   2   root   root   blahblah   media
drwxr-xr-x   2   root   root   blahblah   disk

... but after the encrypted file system was mounted the permissions changed to...

drwxr-xr-x   2   root   root   blahblah   media
drwxrwxrwx   2   root   root   blahblah   disk

I suppose that explains why I can access it normally... but not why you cannot. Sorry.

When I write a file to the encrypted disk as a root, the owner and group are: root root. When I write to it as a normal user, they are: user user. So I think the intent is that you should not have to do anything special to manage file permissions.

I know I didn't answer your questions, but sometimes it helps to see what other people have done. Below were my steps...

1. Delete all partitions -- using gdisk (as Xyne notes below, if you are going to securely wipe the disk, there is no need to delete the partitions first!).
2. Securely wipe the disk -- using dd, and then for practice, shred.
3. Setup the Luks header.
4. Unlock the partition with device mapper.
5. Create a file system.
6. Mount the file system.

7. Add a key file.
8. Test the key file.
9. Backup the header.
10. Test the backup header.

2a. # dd if=/dev/urandom of=/dev/sdc bs=4096
2b. # shred -v /dev/sdc
3.  $ sudo cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 --use-random --verify-passphrase luksFormat /dev/sdc
4.  $ sudo cryptsetup open --type luks /dev/sdc crypt
5.  $ sudo mkfs.btrfs /dev/mapper/crypt
6a. $ sudo mkdir /mnt/dmCrypt
6b. $ sudo mount -t btrfs /dev/mapper/crypt /mnt/dmCrypt
6c. $ sudo chmod a=rwx /mnt/dmCrypt

I see in my notes that I changed the mode of /mnt/dmCrypt (step 6c), but I did not do this when I mounted the file system to /media/disk... so I'm not sure that step is necessary.

Cheers,

edit: changed some of the commands to sudo rather than root
edit2: added note from Xyne

Last edited by dakota (2016-05-25 01:18:43)

i_love_r34 · 2016-05-24 22:47:28

Hi!
To access to your external hard drive with ext4 you need to give permissions to the Hard drive like:

sudo chmod -R 777 /media/disk

And you can use with your normal user.
I recommed to use tune2fs to reduce or delete the reserved space on ext4 filesystem.
To reduce to 0% is

sudo tune2fs -m 0 /dev/sdb1

Regards

Last edited by i_love_r34 (2016-05-24 22:47:45)

Xyne · 2016-05-25 00:46:17

You can skip LVM but then you can't change partitions later. LVM with LUKS has 2 typical uses:

LUKS over LVM: Encrypt different virtual partitions and mount them as needed. Not all encrypted data is equally sensitive. Leaving your pirated music collection accessible all day while you're in front of the computer is probably fine... your porn collection, maybe not... banking details and other such data, almost certainly not. This scheme also allows you to have different encrypted virtual partitions for different users with simpler access via e.g. pam_mount (see below).
LVM over LUKS: Everything is unlocked at the same time but you can still compartmentalize your data with virtual partitions that you can resize as necessary. That can be useful in different backup systems etc.

If you just want one huge encrypted partition then skip LUKS. I would probably check though if there is non-negligible overhead for such a large encrypted partition.

For mounting, you should use mount's uid and gid options to restrict it to a given user if that's what you want. Without knowing how you intend to use the disk there's not much advice that we can give. crypttab and fstab should work. If you want something that's automounted when a certain user logs in and is only available to that user, take a look at pam_mount. If you want to automount it when you connect the disk for a certain user, I'm guessing there's a way to do that with udev and/or some systemd magic.

If you're sharing the disk between users then just set permissions correctly in the decrypted file system. Once it's decrypted and mounted it is no different than a regular disk. If you need to share directories, use access control lists (ACLs). autochown may also be useful.

Back up your LUKS headers as dakota suggests (cryptsetup luksHeaderBackup) along with any key files (in a secure location, preferably encrypted).

@i_love_r34
Setting 777 means that everyone on that computer will be able to not only read but also write and delete anything on the disk. If the data is sensitive enough to be worth encrypting then that is a bad idea.

@dakota
Why bother deleting partitions if you're going to dd the disk afterwards?

dakota · 2016-05-25 01:34:59

Xyne wrote:

LUKS over LVM: Encrypt different virtual partitions and mount them as needed. Not all encrypted data is equally sensitive. Leaving your pirated music collection accessible all day while you're in front of the computer is probably fine... your porn collection, maybe not... banking details and other such data, almost certainly not. This scheme also allows you to have different encrypted virtual partitions for different users with simpler access via e.g. pam_mount (see below).

A lightbulb pops up! Thank you!

Xyne wrote:

@dakota
Why bother deleting partitions if you're going to dd the disk afterwards?

Because I'm not very smart and I'm pretty vague on the whole 'partition' concept. (but I'm learning as fast as I can!)

Seriously, though, the information that I needed was contained on several pages. I must have mixed up the order when jumping back and forth. On the page about using dm-crypt to encrypt a non-root file system... under 'Partition' it states:

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

Clearly what the wiki is talking about is how to set up an encrypted partition on a device that has other partitions on it. I didn't realize that until I read your note above. So what they are talking about is securely erasing the partition, not the entire disk. Thank you very much!

Cheers,

Last edited by dakota (2016-05-25 01:35:24)

i_love_r34 · 2016-05-25 04:36:55

Xyne wrote:

@i_love_r34
Setting 777 means that everyone on that computer will be able to not only read but also write and delete anything on the disk. If the data is sensitive enough to be worth encrypting then that is a bad idea.

Yeah can be bad but if your external hard drive is for personal or backup purpose and if you are the one who knows the password. It is perfect

Last edited by i_love_r34 (2016-05-25 04:37:44)

penguin · 2016-05-25 07:11:00

@dakota, @i_love_r34, @Xyne
Thanks for great answers!

Xyne wrote:

Without knowing how you intend to use the disk there's not much advice that we can give.

It's only for backup (hopefully a few times a month), so I think I'll go with manual mount + chmod 777, as I'm the only user on the machine, and I'll be present during the full time it is mounted.

Xyne wrote:

Back up your LUKS headers as dakota suggests (cryptsetup luksHeaderBackup) along with any key files (in a secure location, preferably encrypted).

dakota wrote:

7. Add a key file.
8. Test the key file.
9. Backup the header.
10. Test the backup header.

That's interesting suggestion, I hadn't thought about it. I'll have to do some reading on this again.
I guess I should read Dm-crypt/Device_encryption#Backup_and_restore. I've added the command I used at the bottom of my first post as an "edit".

Btw, @dakota how did you test the backup of the LUKS header?

Some new questions:
1. If I want to run fsck, do I do it on /dev/sda1, /dev/mapper/seagate, or /media/disk ? I'm guessing it aught to be on /dev/mapper/seagate, when unencrypted?
2. If I want to change the password, can I do that without reformating the drive, and loosing all the data?
3. If I want to add a key file, can that also be done without loosing all the data, or is it at partition creation time only? I interpret the wiki as this can be done "whenever".

Thanks again!

dakota · 2016-05-26 00:40:05

Hello Penguin,

I'm struggling with this, same as you, but this is the first time in 2 years of lurking that I've had anything to say that might be valuable to someone.
Hopefully, if I say something truly embarrassing, someone will straighten me out.

Your command to create the backup header looks right. To test it you would add the <--header> option to your open statement...

$ sudo cryptsetup -v --type luks --header /path/to/backupheader open /dev/sdb1 seagate

... where -v is for verbose. And to open it with a key-file, you would add the <--key-file> option. Both of these are explained in: $ man cryptsetup.

$ sudo cryptsetup -v --type luks --header /path/to/backupheader --key-file /path/to/keyfile open /dev/sdb1 seagate

Some answers...

#1. I don't know.

#2 / #3. The way I read the wiki, the answer depends on the type of encryption you are using. With dm-crypt and LUKS, both answers are yes. You can check the comparison table for more detail.

The 'master key' is what is used in the encryption. A good master key would be quite long and nearly impossible to remember. The 'passphrase' is used to decrypt the master key. With dm-crypt/LUKS you can add, remove and modify your passphrases without changing the master key.

However, to be on the safe side, before I messed with my only key, I would add a second key and verify that it works! Obviously if you remove the only key you have, you won't be able to get back into the encrypted partition!

The thing I found very interesting is that the key can be a passphrase (as you've already done), or it can be a keyfile with a really long passphrase... or some random text... or a binary file like a photo, or an mp3, or a video!

Pretty cool.

Cheers,

dakota · 2016-05-31 19:24:03

dakota wrote:

The thing I found very interesting is that the key can be a passphrase (as you've already done), or it can be a keyfile with a really long passphrase... or some random text... or a binary file like a photo, or an mp3, or a video!
Pretty cool.

A warning: I just realized that if I type...

$ sudo cryptsetup -v --type luks --header /path/to/backupheader --key-file /path/to/keyfile open /dev/sdb1 seagate

... into the command line, it gets written to the un-encrypted bash history file ( ~/.bash-history)... complete with the name of the file I used as my key and its exact location! Not exactly what I was expecting. Unless you take other precautions, you're better off with a passphrase.

GuloGuloDesu · 2016-05-31 21:09:49

penguin wrote:

Some new questions:
1. If I want to run fsck, do I do it on /dev/sda1, /dev/mapper/seagate, or /media/disk ? I'm guessing it aught to be on /dev/mapper/seagate, when unencrypted?
2. If I want to change the password, can I do that without reformating the drive, and loosing all the data?
3. If I want to add a key file, can that also be done without loosing all the data, or is it at partition creation time only? I interpret the wiki as this can be done "whenever".
Thanks again!

1. Do fsck on /dev/mapper/seagate when it is unencrypted
2. Yes you can change the password without loosing all of the data on the drive. But I would recommend backing up the data just in case. This process also can take some time, as even though it only really has to update the header, it updates everything.
3. Yes, you can add a keyfile whenever. The commands to add a keyfile are:

Create a unique keyfile
dd bs=512 count=4 if=/dev/urandom of=/root/supersecretfile iflag=fullblock

Add the keyfile as a secondary decryption way (besides the password)
cryptsetup luksAddKey /dev/sdb1 /root/supersecretfile

Using the cryptsetup command, you can also add other passwords as well, without losing data.

penguin wrote:

... into the command line, it gets written to the un-encrypted bash history file ( ~/.bash-history)... complete with the name of the file I used as my key and its exact location! Not exactly what I was expecting. Unless you take other precautions, you're better off with a passphrase. smile

Be sure to set the proper permissions on the file, and you should be fine. Even if the file path is in your history.

teateawhy · 2016-05-31 22:07:21

penguin wrote:

... into the command line, it gets written to the un-encrypted bash history file ( ~/.bash-history)... complete with the name of the file I used as my key and its exact location! Not exactly what I was expecting. Unless you take other precautions, you're better off with a passphrase. smile

There are ways to stop a command from going to the history.
export HISTCONTROL=ignorespace
etc.

dakota · 2016-05-31 22:25:12

teateawhy wrote:

penguin wrote:
... into the command line, it gets written to the un-encrypted bash history file ( ~/.bash-history)... complete with the name of the file I used as my key and its exact location! Not exactly what I was expecting. Unless you take other precautions, you're better off with a passphrase. smile
There are ways to stop a command from going to the history.
export HISTCONTROL=ignorespace
etc.

Oooo. Very nice. I didn't know about this.

Here is some more information on controlling BASH history.

1. Bash HISTCONTROL
2. Using Bash History more efficiently.

Arch Linux

#1 2016-05-24 18:41:13

Best practices when encrypting external hard drive?

#2 2016-05-24 20:44:36

Re: Best practices when encrypting external hard drive?

#3 2016-05-24 22:47:28

Re: Best practices when encrypting external hard drive?

#4 2016-05-25 00:46:17

Re: Best practices when encrypting external hard drive?

#5 2016-05-25 01:34:59

Re: Best practices when encrypting external hard drive?

#6 2016-05-25 04:36:55

Re: Best practices when encrypting external hard drive?

#7 2016-05-25 07:11:00

Re: Best practices when encrypting external hard drive?

#8 2016-05-26 00:40:05

Re: Best practices when encrypting external hard drive?

#9 2016-05-31 19:24:03

Re: Best practices when encrypting external hard drive?

#10 2016-05-31 21:09:49

Re: Best practices when encrypting external hard drive?

#11 2016-05-31 22:07:21

Re: Best practices when encrypting external hard drive?

#12 2016-05-31 22:25:12

Re: Best practices when encrypting external hard drive?

Board footer