- Problem Description (The Security Gap)
Currently, Home Assistant OS (HAOS) on modern hardware (e.g., RPi 5 with SSD) enables Full-Disk Encryption (FDE) by default. This is highly appreciated, but the implementation only protects against theft of the drive itself.
The key remains stored internally (on the Pi’s boot partition or TEE chip). This means a thief who steals the entire device (the Pi + SSD) can simply boot the system and gain access to all data (configurations, secrets, camera feeds).
- The Critical Security Need: Off-Site Backup Protection
The security risk is compounded when using an Off-Site Backup (stored at a friend’s or family member’s location).
Risk Scenario: A visitor with Wi-Fi access or another device in the remote network could potentially access the backup drive (e.g., a 2TB SSD connected via FRITZ!Box).
Vulnerability: If the backup drive is not protected by network-based authentication, the data is exposed to everyone in the remote network.
The following steps are required to mitigate the risk of local access and network snooping:
The Version Conflict : The Supervisor installer actively rejects the installation on unsupported systems like Debian 13 (“Trixie”). This forces the user to manually flash the supported Debian 12 (“Bookworm”) base OS.
- Manually flashing a temporary “tool” OS (e.g., Debian on an SD card) to prepare the drives.
- Manually partitioning and encrypting the target SSDs (using LUKS).
- Manually writing a custom systemd service (luks-unlock.service) that executes the following, working command chain to retrieve the key and unlock the data partition:
WORKING NETWORK UNLOCK COMMANDS (on Debian 12):
- Connect NAS (Fixing the Bug):
(Establishes a stable connection to the FRITZ!Box NAS by circumventing the known Stale file handle bug.)
“mount -t cifs //192.168.178.1/FRITZ.NAS /mnt/fritz_nas -o username=‘HA-User’,password=‘HA-Users-Password’,vers=2.0,noserverino,iocharset=utf8” - Unlock LUKS:
(Uses the network-retrieved keyfile to open the LUKS volume.)
“cryptsetup luksOpen --key-file /mnt/fritz_nas/ha_key/ha.keyfile /home/haadmin/cloud_container.img ha_data” - Manually install all dependencies (docker, cryptsetup, cifs-utils, os-agent, jq, systemd-resolved, etc.).
- Manually installing the Supervisor .deb package.
- Primary Security Use Case (Against Physical Theft)
Scenario: Device Theft (HA Server)
HAOS Default (Current Risk): The thief steals the entire device (RPi + SSD). The system key is found on the Pi, allowing the thief to boot the OS and access all stored data (passwords, camera feeds, config files).
Proposed NBDE Solution: The key is stored externally (e.g., on the FRITZ!Box or a dedicated server). The Pi attempts to boot, fails to locate the key over the network, and the entire SSD remains unreadable LUKS data. Data is secure.
Scenario: Off-Site Backup Access
HAOS Default (Current Risk): The backup drive (at a remote location) is mounted via Samba/CIFS. A malicious guest/device in the remote network accesses the shared backup folder.
Proposed NBDE Solution: The backup drive itself is LUKS encrypted. The key is only retrieved over the network during the specific backup process and is never stored on the remote drive itself. This prevents passive browsing by local network users.
Scenario: Drive Removal
HAOS Default (Current Risk): The thief steals only the SSD and connects it to a different PC.
Proposed NBDE Solution: Data is secure. The drive is useless without the external key.
- Operational Use Cases (Beyond Security) - TEXT VERSION
Scenario: Automated Failover
Description: In a cluster environment, if the primary HA instance fails, a secondary HA instance can be configured to attempt to retrieve the same LUKS key from the network.
Benefit of NBDE: Enables quick, automated decryption and mounting of the data disk by a backup server, minimizing downtime.
Scenario: Headless Boot
Description: The system needs to restart unattended (e.g., after a power failure or OS update).
Benefit of NBDE: Guaranteed unattended boot. The system automatically retrieves the key from the FRITZ!Box over the network, removing the need for a user to manually enter the password via SSH.
- Proposed Solution (The “Perfect Plan” for Everyone)
I request that native support for Network-Bound Disk Encryption (NBDE) be integrated directly into HAOS, ideally as a secure, opt-in feature during onboarding.
If “External” is chosen, HAOS should natively handle the process of fetching the LUKS key via a stable protocol:
SMB/CIFS (e.g., FRITZ!Box NAS): The key is retrieved using specialized, stable parameters (like the ones we found: vers=2.0, noserverino).
Simple HTTPS Endpoint (e.g., Custom Server/ESP32): The key is fetched directly via a secure web request.
- Why this must be implemented:
Closes the Physical Security Gap: Solves the critical “theft of the whole device” problem.
Secures Off-Site Backups: Ensures that sensitive data is never stored unencrypted in remote networks that the main user cannot fully control.
Democratizes Security: Makes true, external-key FDE accessible to all users, not just Linux experts who can manipulate systemd and cryptsetup.
Increases Trust: Solidifies Home Assistant’s position as a secure, enterprise-ready smart-home solution…