I am using eCryptfs to encrypt the home directory and would like to access files without having the user log in. The program pam_mount will automount encrypted file systems, but it seems like that only happens when the user logs in. Is there a way to do this without having a user login or turning on auto-login?

I may be approaching this the wrong way - I'm trying to run a python program as a static display but don't want to expose the python code to someone who can mount the drive in another machine and see the unencrypted files. This application is launched using a systemd service.

  • How would you provide the encryption password? If you don't want someone who can read the disk directly to be able to decrypt the data, the encryption key has to be outside the disk. – Gilles 'SO- stop being evil' Aug 29 '19 at 21:37
  • I'm not sure the best way as it's a little out of my wheelhouse. Worst case is security through obscurity by stashing it somewhere unassuming. It doesn't need to be a bulletproof solution, just enough to stop people with general linux knowledge from coming across the files. – Roy Aug 29 '19 at 21:46

You want your data to be readable to run your application and display it with that one script, but you don't want people to be able to read your data if they have access to the machine and can remove the hard disk.

Encryption can help, but only if the key is not on the disk. So forget about automounting: it won't help you. If the key is on the disk, you don't gain any security compared to leaving the data unencrypted.

If the key isn't on the disk, where can it be?

  • The key can be derived from a password. But then someone needs to enter the password at boot time. dm-crypt would be easier to set up for that than ecryptfs: ecryptfs is meant for multiuser system so that each user has their own encryption key, whereas dm-crypt is designed to encrypt a whole disk or partition.
  • The key can be on some other piece of removable hardware which is not left permanently connected to the computer. The easiest solution is to use dm-crypt and a key file on an USB drive or SD card. Again, someone has to be present at boot time to insert the drive containing the key.
  • The key can be on some other piece of hardware that's permanently attached to the computer. But then you need to prevent the attacker from booting from a different disk, recovering the key, then decrypting the original disk. Or booting from a different disk, modifying the boot code on the existing disk to add a program that would export the data or allow a passwordless login, then booting from the original disk. So you need some form of secure boot. (That's secure boot as in you have the keys and can control what runs on your machine, as opposed to secure boot as in the manufacturer has the keys and prevents you from installing the operating system of your choice.)

If you don't want to rely on physical security alone (put the computer in a locked box that can't be opened without power tools), and you don't want someone to have to intervene each time the computer starts up, secure boot is the only solution.

This means you need a PC with a TPM that you can take control of, or an Arm board with secure boot that you can take control of (those are somewhat uncommon, but you may be able to run your application on an Android phone that has secure boot, or on an iPhone).


As Gilles pointed out, you obviously need the key somewhere, and if you want this process automated with no password input required and no requirement to manually insert an external USB, then you essentially need a TPM or equivalent device.

To be a bit more precise though, you don't technically need secure boot. I think this phrase is sometimes used broadly, but in this context I'm referring to the boot-up security feature of the UEFI spec responsible for validating digital signatures over components in the boot chain. In fact, secure boot and TPMs are totally independent. Secure boot can be utilized without a TPM, and TPMs can be utilized without secure boot, or they can be used simultaneously.

Furthermore, TPMs are more commonly used with a similar technology to secure boot called trusted boot, but there is also no requirement that one must use trusted boot with a TPM either, though it expands your capability in terms of what components in the system can be tied into your chain of trust and thus have their integrity play a role in dictating whether a TPM will hand over secrets to some piece of software requesting them.

In a very, very brief summary that leaves much actual detail out, a TPM acquires SHA-1 and/or SHA-256 hash digests (depending on TPM version), or measurements, over software components in the system as the machine boots. They are accumulated in TPM internal registers called PCRs, or platform configuration registers. The nature of which components have their firmware/software measured is largely dependent on support for this whole paradigm by the various components in your system, but you essentially end up with a slew of measurements that can then be used to lock down various secrets through the capabilities offered by the TPM. For instance, a key could be written into the TPM's NVRAM and locked to a specific set of these measurements such that the TPM will not allow read access unless the exact set and their values match what was present or specified at the time of writing. There are other ways too, this is just a brief bit.

Practically though, what this ends up meaning is that you end up needing to write a bit of software, or use something existing, to handle talking to the TPM and acquiring secrets from it, and then using them for whatever purpose you need, such as decrypting a LUKS partition.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.