Security of automatically unlocking encrypted lvm partition

Zorbik · 2016-10-08 19:27:43

I just fresh installed Arch and decided to use full system encryption (including boot) using dm-crypt LVM on LUKS and grub's boot encryption.
I decided that I did not want to type in my password twice so I created a keyfile that would automatically unlock my system partition.
Basically the boot process goes like this: GRUB unencrypt password -> select to boot arch -> keyfile automatically unlocks system partition.

Here lies my question though. Is it more secure to take the couple of extra seconds to type in a second password to unlock my system partition?
I assumed that as long as an attacker has access to my boot partition they can also gain access to the rest of my system and having a second password will only slow them down.
Am I correct in this assumption?

Thanks for the help.

In case you wanted to know, I used this and this guide to setup my encrypted partitions.

Xyne · 2016-10-08 21:10:40

edit 2
I had not understood that the boot partition was encrypted with LUKS when I first replied. See my second reply below.

Your current setup provides no security yet still incurs the overhead of encryption. There is no point in locking a door if you leave the key on a hook on the outside of the door.

The bios and/or grub passwords are not encryption passwords. A bios password is basically just an intrusion detection password. Anyone can open up the system and reset it if they really want to. You'll know that someone has reset it, but it won't protect your data. A grub password just prevents someone from booting the installed system directly. An attacker could e.g. boot a live system and change the grub configuration files then reboot, or just access your data directly via the live system.

In either case, "anyone" can directly access the physical disk and the data on it if it isn't encrypted. Even if it is encrypted as in your case, someone with access to the disk will have access to the key file (the key on the door). So yeah, it is far more secure to type in that second password. Disk encryption passwords should be long and very hard to guess, by both humans and computers.

The only time it makes sense to use a keyfile is when you are mounting additional partitions. For example, if you have encrypted root and home partitions, you could set up your system to prompt for a (strong) password when mounting root, then use a keyfile on root to unlock home. The encryption of the root partition protects the keyfile for home. You should still use an equally strong password for the home partition (or even the same as root), just in case you ever lose the keyfile.

edit
If most of your data is not confidential and you just want to keep out casual snoopers, skip the hassle of encryption entirely. For anything that really needs it, create a separate partition or an encrypted filesystem that is only mounted while you access it. You should do that even if you have full system encryption, which only protects your data when the system is off.

Last edited by Xyne (2016-10-08 21:58:07)

graysky · 2016-10-08 21:26:27

I guess if you're using encryption so that if a disk needs to be RMA'ed, it probably doesn't matter, but if not, Xyne's post says it all. I never understood the reason for a full system encryption setup. If you want to hide your porn, use an encrypted data partition that's mounted on demand as Xyne said.

Zorbik · 2016-10-08 21:30:21

Xyne wrote:

Your current setup provides no security yet still incurs the overhead of encryption. There is no point in locking a door if you leave the key on a hook on the outside of the door.
The bios and/or grub passwords are not encryption passwords. A bios password is basically just an intrusion detection password. Anyone can open up the system and reset it if they really want to. You'll know that someone has reset it, but it won't protect your data. A grub password just prevents someone from booting the installed system directly. An attacker could e.g. boot a live system and change the grub configuration files then reboot, or just access your data directly via the live system.
In either case, "anyone" can directly access the physical disk and the data on it if it isn't encrypted. Even if it is encrypted as in your case, someone with access to the disk will have access to the key file (the key on the door). So yeah, it is far more secure to type in that second password. Disk encryption passwords should be long and very hard to guess, by both humans and computers.
The only time it makes sense to use a keyfile is when you are mounting additional partitions. For example, if you have encrypted root and home partitions, you could set up your system to prompt for a (strong) password when mounting root, then use a keyfile on root to unlock home. The encryption of the root partition protects the keyfile for home. You should still use an equally strong password for the home partition (or even the same as root), just in case you ever lose the keyfile.
edit
If most of your data is not confidential and you just want to keep out casual snoopers, skip the hassle of encryption entirely. For anything that really needs it, create a separate partition or an encrypted filesystem that is only mounted while you access it. You should do that even if you have full system encryption, which only protects your data when the system is off.

Is there any point in having an encrypted boot partition then? From what you have said it sounds like setting up an encrypted boot partition is just a lot more hassle with no end benefit.

Xyne · 2016-10-08 21:40:09

graysky wrote:

I guess if you're using encryption so that if a disk needs to be RMA'ed, it probably doesn't matter

Don't forget to wipe the keyfile in that case.

graysky wrote:

I never understood the reason for a full system encryption setup.

For most people it's overkill and pointless.
For some it's just a game/practice to harden the system.
For a select few, it guarantees that the system has not been tampered with. I bet e.g. Snowden has legitimate reasons to go for full encryption.

Even for casual users, I doubt that many would want to hand over an unencrypted system for imaging at a border crossing even if there's nothing of interest on there to the border agents.

edit

Zorbik wrote:

Is there any point in having an encrypted boot partition then? From what you have said it sounds like setting up an encrypted boot partition is just a lot more hassle with no end benefit.

Ah, I was lazy and didn't fully read your post and the links. Disregard my post. If boot is encrypted then the keyfile is fine. I didn't realize that encrypted boot partitions are now supported. In that case your setup offers the same security as a password-protected root partition with a keyfile for other partitions.

Last edited by Xyne (2016-10-08 21:45:50)

Zorbik · 2016-10-08 23:14:33

Xyne wrote:

Ah, I was lazy and didn't fully read your post and the links. Disregard my post. If boot is encrypted then the keyfile is fine. I didn't realize that encrypted boot partitions are now supported. In that case your setup offers the same security as a password-protected root partition with a keyfile for other partitions.

Ahh ok. So in that case if they have the tools to get into the encrypted boot partition then they will also be able to get into the rest of the system therefore being pointless to require myself to type the password.

Thank you

Leonid.I · 2016-10-10 10:33:03

Zorbik wrote:

I just fresh installed Arch and decided to use full system encryption (including boot) using dm-crypt LVM on LUKS and grub's boot encryption.
I decided that I did not want to type in my password twice so I created a keyfile that would automatically unlock my system partition.
Basically the boot process goes like this: GRUB unencrypt password -> select to boot arch -> keyfile automatically unlocks system partition.
Here lies my question though. Is it more secure to take the couple of extra seconds to type in a second password to unlock my system partition?
I assumed that as long as an attacker has access to my boot partition they can also gain access to the rest of my system and having a second password will only slow them down.
Am I correct in this assumption?
..

No, you are absolutely wrong. Here is why:
1. Your boot partition is NOT encrypted. Grub password is used to only protect kernel command line, not encrypt the filesystem. The latter can not be encrypted because it contains the kernel that later decrypts root. What do you think decrypts the kernel? You guessed it right: Nothing because it is not encrypted.

2. An attacker having access to your boot partition doesn't need a key file because he can subvert the kernel and steal your pass phrase. Hence your suggested solution will not work.

The only way to make your system secure is to move boot partition away, e.g. on an external USB stick which you always have in your possession. Whether or not said drive should contain the keyfile is almost entirely irrelevant for security.

Leonid.I · 2016-10-10 10:33:44

[deleted]
Note to myself: Never use the back button

Last edited by Leonid.I (2016-10-10 10:35:42)

rdeckard · 2016-10-10 16:51:00

There are a lot of misconceptions being thrown around on this thread. Everything is encrypted on your system except for the BIOS boot partition (the small section at the beginning of the disk that loads GRUB itself). Having a key embedded in the initramfs is fine, because it, with the kernel, is on the encrypted /boot which is not decrypted until GRUB decrypts it. Yes, GRUB really can decrypt a LUKS-encrypted partition to get to the initramfs and kernel. When the system is off, the key is in on the encrypted section of the disk and is secure.

Arch Linux

#1 2016-10-08 19:27:43

Security of automatically unlocking encrypted lvm partition

#2 2016-10-08 21:10:40

Re: Security of automatically unlocking encrypted lvm partition

#3 2016-10-08 21:26:27

Re: Security of automatically unlocking encrypted lvm partition

#4 2016-10-08 21:30:21

Re: Security of automatically unlocking encrypted lvm partition

#5 2016-10-08 21:40:09

Re: Security of automatically unlocking encrypted lvm partition

#6 2016-10-08 23:14:33

Re: Security of automatically unlocking encrypted lvm partition

#7 2016-10-10 10:33:03

Re: Security of automatically unlocking encrypted lvm partition

#8 2016-10-10 10:33:44

Re: Security of automatically unlocking encrypted lvm partition

#9 2016-10-10 16:51:00

Re: Security of automatically unlocking encrypted lvm partition

Board footer