💾 Archived View for wilw.capsule.town › log › 2023-03-05-self-host-encryption.gmi captured on 2024-08-18 at 17:20:30. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-04-19)
-=-=-=-=-=-=-
I self-host a number of services - Nextcloud [1], FreshRSS [2], PhotoPrism [3] etc. - at home on a Raspberry Pi. Attached to this Pi is a large SSD to hold the service data and configuration, and all of this is periodically backed-up via Restic to a remote site.
The SSD is simply formatted with `ext4`, and the directory containing all of these services and data is currently encrypted using fscrypt [4]. I (mainly) want to encrypt the data in order to protect against the case of break in and theft in my house, however likely or unlikely that is to occur.
However, the downside of this mechanism is that each time the power drops in the house (a fairly frequent event these days with constant building work going on), the directory is unable to auto-decrypt and so the services do not launch properly until I manually unlock the directory using a passkey.
Whilst this works fine, the approach feels a bit clunky. I wondered if anyone had any alternative solutions to managing this. I'm certainly not an expert in encryption mechanisms, but below I outline three approaches I've wondered about.
I notice from the documentation [5] that directories can be automatically unlocked at login-time through PAM. Is there a secure way to auto-login a user after boot (and drive-mounting) such that the directory is ready by the time the Docker daemon restarts the service containers?
In the past, I've used LUKS [6] to encrypt entire volumes, and `crypttab` to handle the unlock automatically at boot-time. I could use this to encrypt the entire volume on the SSD.
My concern with this is that (in my own way of thinking about it!) the encryption key must be stored unencrypted on the root/boot filesystem in order to facilitate the automatic unlock. If the device was to be stolen, this key would be available to anyone checking the filesystem. I may be misunderstanding the encryption approach here, or perhaps over-estimating an average thief's technical ability.
My final thought on this is to address the root cause of the issue, and to find a solution that keeps the Pi booted when there is no mains power. For example, this could be accomplished with a UPS (Uninterruptible Power Supply).
I understand that this must not be a rare problem. If you've had similar experiences and have found a solution that works well for you, I'd love to hear from you!
Please reach out to me on Mastodon (@wilw@fosstodon.org [7]) or via email (blog@wilw.dev [8]).