Use Case: Providing a secure appliance

[hspaay]

I arrived here via the call for use cases & requirements web page

As a user of an appliance I want the guarantee that it is secure and I don't have to worry about it. I want to set it up with a simple button push and so that it connects to my gateway without anyone being able to connect to the appliance directly (until the appliance is reset).

For example, a WoT capable door lock would automatically connect to the gateway on the network after pushing the linking button. The gateway admin panel shows the request to link and the user accepts. Now the lock appliance is linked to the gateway and this is the only communication that is allowed with the lock. Bad actors on the network are not able to attack the lock directly as it is not listening on the network. Security is taken care of by the gateway.

The motivation for this use-case (or is it a requirement?) is that having a web server in each appliance is an accident waiting to happen. See also w3c/wot-security#197 and WebThingsIO/webthing-node#141 where I'm trying to explain the issue.

I think the WoT has a responsibility to support and promote a secure infrastructure in its architecture. This is currently not properly addressed. And no, a LAN is not secure.

[benfrancis]

Hi @hspaay, thanks for bringing these concerns to the Web Thing Protocol Community Group.

When I first started working on the Web of Things at Mozilla I identified three different integration patterns for devices to be exposed to the Web of Things (I didn't invent these patterns, they were defined in the Web Thing Model W3C member submission and are described in the book Building the Web of Things):

1. Direct - The device itself exposes a web server
2. Gateway - A gateway on the same local network as the device bridges it to the Web of Things by exposing a web server
3. Cloud - Like the gateway integration pattern, but the gateway exists as a cloud service and the device uses some other mechanism to communicate with the service over the internet

I think what you're really getting at here is that the direct integration pattern increases the potential attack surface because every device is acting as a server with ports open to the internet, and each of those devices therefore needs to be secured and kept up to date with security fixes. You're suggesting that the gateway integration pattern (where the gateway exposes the web server and the device uses some other approach for communicating with the gateway) is more secure, because only the gateway needs to be secured against attacks from the internet. You also suggest that a device should be able to connect to a gateway, rather than the other way around, for use cases where a device does not want to be generally discoverable or connectable from any WoT client/consumer.

Firstly, I don't necessarily agree that the direct integration pattern is inherently insecure (it is certainly possible to create an implementation using that pattern which is secure) and I think there are use cases where a device does want to be discoverable by any WoT client/consumer (e.g. a parking meter in a public place or an interactive exhibit in a museum). But I do agree that the direct integration pattern it poses additional risks that should to be highlighted, and in many cases it's a better idea to use the gateway or cloud integration pattern and have the device use another approach for connecting to the WoT server on the back end.

In practice I think what we're seeing is that the direct integration pattern is extremely rarely used. Even in cases where the device itself acts as a web server (e.g. using the WebThings Framework)*, that web server only tends to be exposed to the local network, with a gateway used to securely proxy it to the internet. Due to the limitations of IPv4, HTTP and TLS I think it's very likely we're going to see the Web of Things mostly used for gateways and cloud services, where devices themselves use other protocols which (like CHIP or MQTT) to communicate with those WoT endpoints on the back end.

I have a couple of suggestions based on these observations:

1. The security considerations section of the Web Thing Protocol specification should make reference to these different integration patterns and highlight the additional risks of using the direct integration pattern
2. We should explore the possibility of a use case of the WebSocket sub-protocol where a device acts as a client rather than a server. (This could potentially make deployment and security easier, but in return make discoverability/linkability harder.)

We can use this issue to track the former, and I have filed #16 for the latter.

* A known shortcoming of the current version of the WebThings Framework is that the libraries currently don't have any built-in security mechanisms like authentication or encryption. This isn't because we assume that the local network can be assumed to be secure (which it shouldn't be), but because the specifications for how to provide this in a standard way didn't exist yet. The authentication piece is being addressed by the security member of the W3C WoT Thing Description specification (though it currently has some flaws, which can hopefully be addressed in the new WoT Discovery specification). Another big challenge is how to use TLS on local networks, which is being addressed by the HTTPS in Local Network Community Group.

[hspaay]

Hello @benfrancis,

Well that is a very thoughtful and concise reply. You clearly explained that you understood the points that were brought up. 👍 As for the integration patterns, you are right, those are indeed the available patterns and I see nothing wrong with the way they are defined. I also agree that the direct integration pattern is not inherently unsafe, although it is very difficult to implement it securely.

The issue of secure implementation of direct integration I feel is not sufficiently addressed, even with your suggestion #1. Based on what we see happening with IoT devices today, supporting the direct integration pattern invites bad practices. This is not a good basis for a new standard. Security cameras and other IoT devices often come with instructions on how to open firewall ports so they can be accessed directly over the internet from someone's phone. That makes sense from a convenience point of view but now you have these devices open to the internet. Relying on manufacturers for security of these devices has already been proven to be ineffective. Just google around for IoT vulnerabilities and hacked IoT devices. So I'm not convinced that we will see Internet proof IoT devices any time soon so why endorse this as a valid use-case?

Your suggestion #1 helps but I would like to point out that it is not enough because it will likely just be ignored. Taking the position that this pattern is 'not recommended' would go a step further as now you can say that a device implemented a solution that is not recommended. Personally I would go a step further and say that there is no place for this pattern when the goal is to be secure. When Internet access is required the gateway integration pattern is the bare minimum and the cloud integration pattern preferred.

A second issue is that there is no good reason to consider the LAN as secure. It isn't. Many people, including myself, run Javascript from untrusted sources in our browser and thus on the LAN. We rely on the browser to keep us safe but that is also not a great premise to base the security of a new standard on. Not to mention computers infected with a virus have free roam. It is unlikely that the large amount of cheap IoT devices slowly flooding the market will be secured against attacks that occur now and in the future (they won't be upgraded). Should 'WoT' compliant not also mean that the device is secure? Simply following the security standard (which are under development is my understanding) is not enough to remain secure for the future.

Suggestion #2, using websocket and MQTT's would indeed address the concern if 'Things' are connecting to a gateway or MQTT server. There seems to be a similar evolution in thinking in the FiWare project. Initially context brokers connect to agents, which suffers the same problem with reaching agents. They have added MQTT support and support for WebSockets is in the works. It would be good to see WoT embrace the more secure way although I can see the reluctance to rely on a specific technology in this standard.

Rather than just being critical of a great piece of work, I'm working on an example where Things connect to a gateway using WebSockets and the gateway uses mDNS to announce itself. It is the reverse of what the reference implementation does. The second phase would include a cloud version of the gateway to act as an intermediary so no ports are opened to the LAN for access to the gateway. Plugins make the gateway protocol agnostics and provide ECMA scripting support as per WoT Servient spec. I'm a bit worried that this approach would not be WoT compliant but it is hard to tell reading the specs.

I'll check the project into github in case someone will like to participate with this approach and make sure it remains WoT compliant. The project's organization called 'wost zone' (tongue in cheek for Web of Secured Things 😉 ) and can be found at https://github.com/wostzone/wostzone.github.io. The intent is to provide the definitions of the gateway and an implementation using WebSockets. It is not unlike the reference implementation but the flow of connection control is reversed. Please note that it is very early days on this project as I'm still getting up to speed.

FYI, I've worked on an experiment project using MQTT for a secured IoT integration solution. Most of the ideas are still valid, but I'd rather spend my time on improving an open standard than be an island. The standard can be found at 'https://github.com/iotdomain/iotdomain-standard'.

Thank you again for a great reply @benfrancis. I hope this discussion helps the project somewhat.

directly. Same with light bulbs, locks, sensors and other devices.