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?

Improve this question
8
  • 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 askubuntu.com/help/on-topic as Linux is covered in SE Unix & Linux
    – guiverc
    Jun 23, 2022 at 13:05
  • Seems like a duplicate of security.stackexchange.com/questions/231543/…
    – user535733
    Jun 23, 2022 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, 2022 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, 2022 at 15:35
  • @AlexOnLinux The Linux machine is on the customer site. The usb thumb drive is not protected either.
    – afar
    Jun 23, 2022 at 15:43

1 Answer 1

Reset to default
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.

Improve this answer
2
  • 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, 2022 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, 2022 at 23:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .