Remote Access After Reboot for Full Disk Encryption

Privacy Questions
1

Are there any solutions that will allow a remote unlock of a full disk encrypted system?

For example: assume a desktop computer with Arch or Fedora has full disk encryption that requests passcode on boot. It is set up with remote access via ssh or VNC. The desktop suffers an unexpected power loss while the owner is on a week long trip out of the state. The computer boots automatically when power is recovered but it cannot boot without the disk encryption passcode. Is there a method to remotely send this passcode, or something like an ssh cert to allow for decryption remotely?

1 Like
2

Depends. If your /boot partition including the initramfs and kernel is unencryoted, and the root partition is encryoted, you can use dropbear ssh with its initramfs scriots to remotely unlock root.
However… Having initramfs unencrypted also allows attack like evil maid attack. To prevent that you will need encrypted /boot with encrypted initramfs, and grub will be used to decrypt that before booting it. I don’t know any method to remotely decrypt that with grub. Wou may also need secure grub and boot with tmp, signrd grub/shim and signed kernel and modules so its complicated.

I am in the same boat as you and looking for solution. I have both system, boot encrypted (grub unprotected), and boot unencrypted. I cannot unlock the first remotely. Second cam be done but I still get half a solution.

I’m starting to think that I might have been a little too crazy on the security with the encryoted boot and grub unlock. Because it is inconvenient and prevent remote recovery and reboot. My thread model is not that high. I dont think evil maid attack is probable against me. Might br something law enforcement might use, but they are not a thread I am willing to guard against,its too hard to do and not worth it for me. Maybe I should changes my system to be able to imolement dropbear ssh remote unlock…

https://www.cyberciti.biz/security/how-to-unlock-luks-using-dropbear-ssh-keys-remotely-in-linux/

1 Like
3

Also, if were just talking about reboot and not cold boit, I found this solution in the past that might be good for you. It register a temporary key t tuks to reboot, and then remove it after reboot.

Keyless Entry

Easily switch on/off keyless reboot for ext4 Linux systems with LUKS encryption

Home page: GitHub - jikamens/keyless-entry: Easily switch on/off keyless reboot for Linux systems with LUKS encryption

4

In the past I’ve setup a home server that could be unlocked remotely via ssh (dropbear). For example.

5

It’s possible: SDB:Encrypted root file system - openSUSE Wiki

With the help of TPM 2.0 chip, it’s possible to automatically decrypt the root partition without typing any passphrase. The key concept is to seal the LUKS key against a proper set of TPM Platform Configuration Registers(PCRs). When the system reaches a certain state, then the boot loader, i.e. grub2, can unseal the LUKS key with the expected PCRs and decrypt the root partition.

The potential use cases:

  • a remote server or cloud VM to boot without intervention
  • a local server to boot automatically after the power outage
6

This confuses me. Under what threat model does this protect data? If the whole disk is encrypted with LUKS, once it is booted and decrypted, the kernel has access to the full disk as if it were unencrypted. It seems like the main threat that full disk encryption protects against would be if the system had been powered down and someone was physically present and confiscated the device or drive, in which case, storing the keys in the TPM chip would decrypt it for them. Am I missing something here?

7

You’ll always have an unencrypted part. In this case someone could probably compromise grub. You’d need secure boot to prevent an evil maid attack

1 Like
8

I’ve used mkinitcpio-dropbear for around a decade and it works well. See section 3.1 of dm-crypt/Specialties - ArchWiki

9

If someone is physically there, the data is still (theoretically) protected by the login manager. (Assuming you don’t have auto-login enabled!) Your system decrypts the drive, boots to the login screen, and then you need to know the user (not LUKS) password to be able to access any files.

Taking the HDD/SSD out of the computer or booting a live Linux is also useless because then the disk won’t be decrypted by the TPM chip.

I think overall it’s less secure than having to enter two passwords, because if there’s any bug allowing you to circumvent the Linux login screen then indeed you can access all the unencrypted files. But the convenience of not having to enter two passwords or being able to access remote machines after a reboot are also worth considering.

10

That’s the logic behind UKIs and signing the whole package.

11

And the various services running too. If I start a server, for example a nas that offer files through windows sharing or a nextcloud server, any of those two services coukd have a vulnerability that enable access to the files or the underlying file system, once full disk encryption is unlocked