search

w3c / wot-security

a repo exclusively for security to better manage issues and security considerations for WoT
https://w3c.github.io/wot-security/
18 stars 22 forks source link

Review security architecture of Home Assistant #191

Closed relu91 closed 3 years ago

relu91 commented 3 years ago

I forgot to mention this home hub: https://www.home-assistant.io/

Description from their web page:

Open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts. Perfect to run on a Raspberry Pi or a local server.

Company associated with project (supports cloud service for remote access): Nabu Casa, Inc.

mmccool commented 3 years ago

@relu91 Christiano, would you be willing to do a first pass on this, just collecting information? Should probably establish a template suitable for "home hubs" (defined as a service running on a local gateway that connects to local devices and may provide other services: common dashboard, protocol translation, remote access, etc), but basically...

It would also be helpful to summarize what services the hub offers.

relu91 commented 3 years ago

Ok, I re-reviewed home assistant; here is what I found.

Home Assistant in a nutshell is "just" a smart hub for home automation. Conceptually it is very similar to Mozilla Hub with the difference that it does not follow any WoT spec and has more automation capabilities. Devices or services are integrated through scripting (precisely python scripts) and, in general, it doesn't provide any specific security layer. To take an example that we know well, the Philips Hue is integrated using their API and security (API key). Another example is the MQTT integration where the security is handled by providing the username and password of the MQTT broker. Security parameters are provided to Smart Assistant by humans (administrator or other users) and are stored in encrypted configuration files.

Home Assistant does not expose any device or API by default (i.e., it just discover your local stuff and display/automate it). However, one script integration creates a RESTFull and WebSocket API. So if we have to create a TD for smart assistant we could use the HTTP and the WebSocket protocol bindings. Security in the RESTFull API uses a standard bearer token obtained by users from the home assistant web page (see here). On the other hand, the WebSocket API uses a custom protocol, which I think the Protocol Binding task force should look at as an example. Regarding security, the custom protocol expects a preamble message with the authentication parameters (see here).

Remote access (i.e., outside your local network) is handled with a private connection to a paid cloud service. From there is not clear if you gain complete access also to the REST API or just the ability to see your local web dashboard.

Other security mechanisms are different authentication methods to access the web dashboard but I think it is not relevant for our use cases.

mmccool commented 3 years ago

So when I first heard "Python" I was thinking that if only we had a Python binding of the WoT Scripting API we could use that to consume WoT Things in this hub. But it looks like we need to go the other way around instead here, talking to APIs exposed by the hub. Although (Cristiano's comment) we could always write a python script (manually...) to talk to a WoT device described in a TD.

The web socket protocol is unfortunately a heavy lift, but yes, it would be a good example of this approach to look at in the future.

mmccool commented 3 years ago

Thanks, @relu91 for the review. I'll copy the above content in a document and close the issue.

mmccool commented 3 years ago

Content copied over to https://github.com/w3c/wot-security/blob/master/background/hubs.md, as well as template. Closing this issue as resolved (future issues and PRs can however be raised against the hubs.md file; I did mark one thing as a "TODO" for future discussion).