So I understand that even if the secrets are encrypted on disk that HA is going to need a way to use them unencrypted. But I feel like it’s still a pro if the only way to get decrypted secrets is through HA APIs at runtime instead of having them hanging out unencrypted on disk, right?
For example, what if you could provide an encryption key on a USB drive connected to the host device? Then HA OS could put that key somewhere it has access to but supervisor specifically cannot access. It would then provide that key as a config value to supervisor giving it what it needs to decrypt secrets. But the secrets themselves always remain encrypted at rest, secrets are only available to integrations via APIs that HA carefully manages and controls and no one can get to the encryption key itself from within supervisor. Since supervisor doesn’t let anyone access it’s config value and the file itself is completely inaccessible to anything other then the host OS (which by default provides no mechanism for accessing it directly).
I mean look, I’m not an expert here at all. So absolutely feel free to tell me I’m a naive idiot and dont know what I’m talking about. It just seems like there must be a way. I mean look at node reds handling of credentials which I think seems to work pretty well. Secret value provided via config used to encrypt the credentials on disk with APIs for carefully managed decrypted access only for component developers (and only for the creds they requested in that component).
It depends on the threat model. In any case, to protect everything we only need to keep one secret.
Threat: non-technical wife/kids/friends
Security level: obfuscation
Implementation: hard coded encryption
Caveats: is it worth it?
Threat: Add-On developers stealing your stuff
Security level: general, per-addon encryption
Implementation: each container asks the main container to decrypt secrets
Caveats: need a place to store that one code and keep it safe, like a special file in a container instance. Likely will need to keep two files, one with user password and one with system.
Threat: hackers/government agencies
Security level: per-instance/process implementation
Implementation: Trusted Execution environment processing, RPMB storage, Trusted Execution handles storage.
Caveats: not supported on RPI. RPI does not have a RPMB. No backup on x86, no way to transport by swapping disks.
I think the first thing is to lay out the user stories.
Then we can figure out what’s technically possible
What do we want to get out of encryption? That’s @frenck’s job because what he wants is what is best for the users.
This is as good as obfuscation when you’ve got access to the machine.
After reading all concerns, I’d suggest a good compromise between extreme lockdown and usability might be a built-in password manager. It would be owned by the ha instance and never show the password in the UI once entered. It would have access granted per-requester based on stack trace. It would not be available outside python Api without an API key for the password manager. Depending on the system, it could utilize platform resources such as RPMB/Trusted Execution Environment, or other. Since owned by HA, it could also be backed up and the backup could be protect via key.
User enters password and assigns key and which addon/platform is being used
Platform request key password or addon/API request key with token
Authorization is verified by token or stack trace (this could be better).
Password is returned
This would protect against posting, addon devs, friends and hackers/government entities depending on the platform.
I like @adamoutler’s suggestion a lot. If implemented and audited, I’d consider using integrations that rely on sensitive credentials. There are so many integrations that I’ve been holding off on, and, for that matter, I’ve been writing a bunch of integrations (e.g. car, home security, etc.) that are now tabled due to this security issue.
Admittedly I mostly use secrets as variables for just about anything that gets used in multiple places in my config, like MAC and IP Addresses so that if they change, I can update them in one place without trying to remember everywhere I use that bit of info, more than I use it for passwords… and I’m sure I’m not the only one, cause it works really well for that!
So hopefully if this was followed on with and implemented, it would either allow usage like that as well, or secrets.yaml could be also kept in place (maybe renamed to identify its for not so sensitive info that is used in a lot of places).
But either way, I would love to see something like that implemented
Had a thought on this today. I noticed the LinuxServer Home Assistant image doesn’t run HA as root but rather as a user in the container. Doing that seems like it could be a solution here. Something like this:
Map a new volume to the home assistant container, call it /etc/secrets for sake of argument
There’s one file in there for now, secrets.yaml
S6 reads in these secrets and provides them as arguments to HA when launching it in run
When reading in the YAML config, HA first looks in the secret store provided via arguments. On fail to find it then looks in /config/secrets.yaml for backwards compatibility
S6 runs HA as a non-root user. This user has no access to /etc/secrets
This solution should work on all 4 installation types although some additional work required for supervisor:
HA Core - User modifies HA launch to include secrets arguments
HA Container - User maps folder to /etc/secrets when launching container
HA OS/Supervised - 2 ways:
(Quick way) Allow addons to map /etc/secrets as a volume. Update the Samba/SSH addons with this mapping. Discourage all other addons from using this since it hopefully is a temporary fix in favor of…
Add a “secrets” tab in supervisor panel. This UI lets users add and update secret values. The values become masked after entry and can only be replaced, they cannot be seen again (like Github secrets). Supervisor updates /etc/secrets/secrets.yaml with what is entered here. Supervisor and HA share the /etc/secrets volume, no other addon or HA container can.
Note that I’m imagining the file itself remains unencrypted and we rely on user controls to prevent access to it. Encrypting the file is trickier because to Frenck’s point way above, you have to get the encryption key in without letting others see it (hence it can’t be anywhere the root user can see it or you didn’t change anything). And have a solution that supports all 4 installation methods which becomes tricky. This seems like it could work in the meantime?
Of note there would be one downside here. Any change along these lines would mean that updates to secrets would require a restart of HA. HA wouldn’t be able to reload parts of its config with fresh secret values like it does today because it cannot access the secrets file. I feel like that’s an acceptable cost personally but perhaps others think differently.
Did you ever get a chance to review the proposals in this thread @frenck?
You’re right in that anyone that has breached the filesystem of the device can realistically crack anything as the project is open source, but there are many reasons that the /config directory of a HA install may end up exposed to the internet, and there’s no reason that the key material securing any encrypted/sensitive values needs to be in that same location.
Any level of security is nothing more than obfuscation to someone with physical access, but this isn’t about physical access, this is about making it easy for end users to protect their credentials instead of storing them in plain text.
node-red does it very nicely. It uses a root secret which is then used to encrypt all other secrets. It would be nice to have HA use similar concept. The idea is to limit the blast radius in case of breach. While that single secret could be used to decrypt other secrets, it reduces the risk a bit since attacker would have to compromise both the files and security algorithm used.
