0

A Linux machine has a partition with sensitive data. The goal is to prevent one from booting up from a live usb and mounting the machine's hard drive and copying the data.
The partition is encrypted with cryptsetup. But it has to get decrypted on boot. So a key file is created to hold the password. The key is added to LUKS:

sudo cryptsetup luksAddKey <encrypted_device> <path_to_key>

For the system to find it on boot, the key file is linked in the /etc/crypttab:

$ sudo nano /etc/crypttab
# Content of the crypttab file
cryptpart    UUID=<partition_uuid>    <path_to_key>    luks

Reference

Question
Using a live USB, one can read the /etc/crypttab and find the path of the key file and break the lock.
What is the solution?

afar
  • 1
  • You've provided no OS/release details; but if encryption is setup correctly you cannot read anything in /etc from live media - I'm involved with QA & know current installs don't allow for this, as it's part of the Quality Assurance for encrypted installations (ie. I boot live media & try and read data off the install!). I don't see anything currently on-topic here? Why are you here? Refer https://askubuntu.com/help/on-topic as Linux is covered in SE Unix & Linux – guiverc Jun 23 '22 at 13:05
  • Seems like a duplicate of https://security.stackexchange.com/questions/231543/arent-keyfiles-defeating-the-purpose-of-encryption – user535733 Jun 23 '22 at 13:27
  • As far as i know the boot folder remains unencrypted. An attacker could also place malicous code in /boot like a keylogger. Apart from that, the keyfile is also unencrypted and could be copied. Best would be to place /boot and or the keyfiles on a usb thumb drive or a cd. A cd cannot be modified, but how to upgrade than? I dont know. If you try to encrypt while having an automatic boot process you will always run into this problem. I suggest you ssh into your machine. You can activate busybox (ssh server) that runs prio the os boots. It will be loaded from /boot by initramfs to enter the pw – AlexOnLinux Jun 23 '22 at 14:07
  • @guiverc
    OS is Xubuntu 22.04. Before posting the question, I used the live usb of the same os and could see the /etc
    – afar Jun 23 '22 at 15:35
  • @AlexOnLinux The Linux machine is on the customer site. The usb thumb drive is not protected either. – afar Jun 23 '22 at 15:43
  • @atar now i do have to ask, what is your goal? Is there a person next to the pc when it boots up and can enter a password, or do you not trust the person that boots the pc up? In the latter case you can log in via busybox and decrypt it by yourself. Or are we talking about different partitions where one has the sensitive data an another one has the keys like / /boot /very-sensitive-data For me it is not really clear what your setup is an what you try to achieve and what you try to secure. You say keyfile, but it is the keyfile that has to secure somethink. You cant place keyfiles in /boot – AlexOnLinux Jun 24 '22 at 06:09
  • if you do full encryption and have various partitions you can decrypt the first partition with a password and all consecutive partitions with a keyfile that lays inside the first partition that you had to decrypt with the password. [PowerButton] > /boot > [Enter Password] > /root > [RedOutKeyfile] > /sensitive-data - what i want to say is: you press the power button. boot will be read by the system. than you will be asked for a pw. next /root is decrypted where the keyfiles lay. Next crypttab uses the keyfiles to decrypt all the other partitions with sensitive data – AlexOnLinux Jun 24 '22 at 06:16

1 Answers1

2

What you have essentially described is keeping the key next to the lock. It's convenient, but you are correct that it's not secure.

Ideally, you should store the keyfile on a different device. Preferably hardware (like a USB stick) that is securely stored separately from the encrypted system.

This scenario is not a failure of the design of Linux encryption nor the design of Ubuntu. The developers did their part properly. It's a failure by the human admin of that system to do their part, and cannot be readily solved by software.

user535733
  • 62,253
  • The Linux PC is on the customer site. So using a USB stick is not secure either. Can't they still use a second live usb and boot up and use the first usb stick with keyfile and dycrypt it? Also there is a possibility of power outage. So I cannot do this one time and unplug the usb and walk away. – afar Jun 23 '22 at 22:08
  • Who is the admin of that system? One if your fellows? Or one of the customer's fellows? It's that person's job to figure out a proper security plan within the resources and constraints. – user535733 Jun 23 '22 at 23:01