Esphome and permissions

Hi, I’m just starting to play around with esphome and I was looking at the protocol. I’m particularly curious about: SubscribeHomeAssistantStateResponse & HomeassistantServiceResponse.
If I understand correctly, this gives the esphome device full access to the entire home assistant install:

  • the esp device can read any entity that exists on the home assistant server
  • the esp device can call any service that exists on the home assistant server

If I’m correct in my understanding, then this seems a bit lax on security? if I leave a esp+dht temperature sensor outside, it would give someone admin access to my home assistant server.

I was wondering if it would be possible for the esphome component on the home assistant side to be restricted by a policy? either by having the entity act as a user and have its actions be checked by home assistant’s policy engine or the very least having a coarse grained permissions that allow/deny the esp device from calling services, injecting events to other entities or subscribing to home assistant events

The ESP device has to be added to home assistant first. There is no way to do that remotely.

Only if the nefarious “someone” removed your firmware and added their own.

You should also be protecting your devices with ESPHome’s encryption.

Only if the nefarious “someone” removed your firmware and added their own.

Yes, this is the problem I’m referring to. Nothing in the ESP device protects the credentials inside. So conceptually, leaving a connected ESP mcu outside is similar to leaving a thumb drive with the device’s credentials outside.
Thus I was hoping for a way to limit the blast radius. If I had a way to limit SubscribeHomeAssistantStateResponse & HomeassistantServiceResponse, then I could isolate the damage to single device. ie someone can play havoc on all of the entity states associated with that device, but I can retain trust in the rest of my iot devices.

Ideally I would like to have the following setup:

  • each ESP device has its own unique eap-tls creds
  • all ESP devices exist on their own vlan that can only talk to hass
  • each ESP device has its own unique api/ota password
  • each ESP can only affect the entities associated with it in home assistant

This way, if someone picks up my outdoor temp sensor, dumps the firmware and extracts string from it, the damage can be isolated to that one device.

The ESP device has to be added to home assistant first. There is no way to do that remotely.

In the current scheme of things compromising a single ESP device, means that the “someone” can add & remove any and all of the devices remotely

You should also be protecting your devices with ESPHome’s encryption.

I think this is orthogonal to the current discussion.

Maybe it is an option for you to place an inkbird bluetooth temperature sensor outside and an esp bluetooth proxy inside? Safer alltogether, and ipx4 waterresistant to boot.

Or, use mqtt and do not give it HA credentials in the first place.

Based on the esphome docs, it sure looks like this is a feature concern.

I dumped the flash from one of my esphome devices to see how difficult it would be to get credentials. The esp devices allow the flash to be read over the serial. Opening the saved firmware binary with a text editor showed the wifi credentials in plain text stored with a bunch of other text strings. Sample below. The esphome encryption key wasn’t in the firmware in text format, it is likely stored as hex value so a little harder to find. The described physical attack appears quite trivial to perform. Reading the flash to plain text can be mitigated using the esp flash encryption. Until and esphome support flash encryption, a nefarious someone with physical access to an esphome device can get a lot of access to the network and HA install.

  board: esp32dev
    type: esp-idf

    key: "noiseKEYnoiseKEYnoiseKEYnoiseKEYnoiseKEYKEY="
  password: "theOTApassword!"

  ssid: "theWIFIapSSID"
  password: "thesecretWIFIpw"


Adding a proxy between esphome and home assistant would work. I think I would prefer a software proxy instead of hard ble one though. However I’d like to see something upstream. Unfortunately it seems like role based security isn’t being actively worked on so I think using has’ policy engine is more effort than its worth. When I have some free time I’ll open a PR to add configuration to disable remote service calls and event subscriptions

The ota password brings in an entirely new angle…ota protocol is not encrypted, so if someone packet captures a firmware update, then they can overwrite the firmware. I’m coming to the conclusion that security is not the primary focus. And in my case I don’t think it matters that much…I don’t think my neighbors have any interest in taking over my network, but this saddens my inner perfectionist :frowning:

1 Like