Promoting an approach where every thing is a server is a security nightmare

[hspaay]

Note: this issue might be somewhat strongly worded but considering what is at stake it is best to be clear.

The architecture sections on common patterns describe many cases as if the gateways and edge device need to connect to the appliance. This means the IoT device (appliance) acts as a server. Libraries such as webthing-node create a server that the gateway discovers and connects to.

There are a few drawbacks to this approach, but by far the worst is that it increases the attack footprint to never seen before proportions. Imagine that the majority of IoT devices can be connected to. Who wants to be responsible to ensure that every single manufacturer creates bomb proof security on their servers? Most likely the same thing will happen as what happened to cameras. One day someone finds a vulnerability and the next day the internet burns down, or your identity gets stolen. Point in case are the DDOS reflection attacks facilitated by the CoAP protocol. This is not imaginary as explained in this article on IoT vulnerabilities

There are two steps that the WoT specification can do to mitigate this potential disaster (and hopefully more):

1. The most secure server is the one that doesn't exist. Rather than including a server in every IoT device, define that gateways or edge devices receive connections from IoT devices and aggregate the data. There are far fewer edge devices/gateways than IoT devices so this approach significantly reduces the footprint. The moment an appliance 'joins a gateway' its server must be off.

2. Second, provide a secure reference implementation of this gateway that has had thorough reviews of its security aspects and receives regular updates.

If you put out a specification like WoT you also bear responsibility for its weaknesses. Yes it requires some rethinking of the data flow and security best practices, but the high level abstract architecture does not have to change much. WoT already has gateways and edge devices, which is fine, but it just need to be clear that the role of the thing is to connect to a gateway or edge device, not the other way around. Ignoring this problem is simply irresponsible.

It is not my intention to offend anyone. It is clear that a lot of hard work went into the WoT specification and I sincerely hope it will be a massive success. But please reconsider the servers aspect of it and don't create the proverbial skynet.

[mmccool]

Thank you for your comments. We also looked at the similar issues you posted and linked above, and acknowledge your concerns. We have been discussing your input in our Security meeting and while we don't yet have a complete response, here are some points of discussion which came up:

• WoT is descriptive. It does not mandate particular security mechanisms or mitigations, although we do provide best practices guidance for "new" implementations
• There will always be a tradeoff between centralization and decentralization. Centralizing in a gateway may be good if the gateway is secure, but it also becomes a single point of failure. Co-tenancy of services also carries its own risks.
• There is no "perfect" security configuration. However it is true that a gateway will have more resources (memory, processor power, connectivity) which may make it easier to implement stronger security.
• Many existing IoT implementations use the "device is a server" approach (eg OCF, which is in turn based on CoAP). Since WoT is descriptive, it needs to be able to describe such architectures. Note that it still supports client-based architectures, but ultimately to be compatible with RESTful web services (eg to support mashups) there needs to be a "server" that provides a network API to access the device.
• A WoT "Thing" is actually an abstraction for a service that provides access to a device... it does not need to run on the device itself, and often does not. In fact, in the Mozilla implementation, all Things run on the gateway, and the devices are (typically) clients... exactly like what you propose.
• There are other reasons why it makes sense to structure IoT devices as clients, in particular they may only be active periodically to save battery. This also motivates an architecture where a service running somewhere else (e.g. a gateway) shadows the device (as a server), and the device itself is not actually running a server. For similar reasons a device may not host its own Thing Description.

We can certainly discuss updates to the WoT Architecture and WoT Security and Privacy Guidelines documents to better capture and discuss the above points. We could, for example, point out in the security documents that implementing devices as clients and running the Thing services in a gateway may allow for more centralized security implementations.

[hspaay]

Great reply @mmccool. Everything that you mentioned makes sense. You see a need to support existing technology and you do see the need for Things to connect as clients to a server. If existing technology can be supported through plugins on a gateway there is no concern. Also true and the reference implementation of the gateway supports this. Sofar all is good.

However I haven't seen anything that discourages a Thing to expose a server. This is about new devices that implement the Thing WoT protocols to support an interoperable web of things (a superb vision!), not legacy devices.

Where in the spec does it define the APIs needed to let Things update their status with a gateway or intermediary. Right now all I see is examples that require the Thing to run a server and have a gateway or intermediaries connect to a Thing to get a status. This is the insecure and flawed approach I'm referring to and my main concern. Right now it is promoted. Set an example and others will follow.

Why can't it be stated that 'Things' (new devices) don't run a server and should connect to a gateway to announce themselves and push their status updates. (I'm aware of the directory service but it isn't enforced). Leaving it open leads to two incompatible approaches.

Reference to the insecure approach:
[1] Build your own web things: https://iot.mozilla.org/framework/
[2] webthings-node: https://github.com/WebThingsIO/webthing-node

I'm happy to elaborate if these examples are not clear. In the interim I'm working on an extension that defines how Things connect to a gateway to push their status updates. I was hoping the API's for this would be defined somewhere but haven't found them (yet).
Thanks again for taking these concerns serious and I hope this discussion will contribute to a safer web of things.

[mmccool]

We understand the concerns you are raising and we'll review your suggestions carefully. We see also that you wrote up more details on your proposed approach here: https://wostzone.github.io/

You might want to look into the "profiles" work. This is taking a more "prescriptive" approach than our original work (which was descriptive) and as such is meant to constrain "new" devices designed from the outset to work with WoT. However, I think we probably need to have a lot of discussion of security tradeoffs (the gateway approach is not without its own risks, so what are the pros and cons) before we would incorporate strong recommendations one way or the other in the specs or notes. Would you be willing to join the Security call? We can also just keep discussing things in this issue, but a live meeting might be faster.

[hspaay]

Got it, thank you for reviewing my concerns.

Yes I would like to take the opportunity to join the security call if I'm able to.

I hadn't seen the profiles before and they are very interesting. They constraints the scope of implementation with the assurance of interoperability, very useful. It does raise a few more questions (of course 😄).

If I interpret it correctly, the core profile data model seems to apply to the TD content, regardless where it lives (Thing, Gateway, Intermediary). It also seems that the protocol binding applies to that which serves the TD, regardless who that is. Must the (greenfield) Thing serve a TD in order to be called a Thing or is there a provision that it can proxy through a gateway and still be called a Thing and WoT compliant?
Reading the profiles document leads my thinking towards having to implementing the HTTP protocol binding on a Thing, eg run a server. The same happens when reading the other architecture documents which indicates to me a biased mindset. This is just an observation and I might be wrong. I'd rather see a bias towards a more gateway-centric approach 😉

I'd love to hear your thoughts on whether the WoT team is open to exploring the idea that a Thing is proxied through a gateway without the Thing running a server. It might require a dedicated protocol binding for Thing to gateway communication. Would a Thing that is designed this way still be considered a Thing?
I'm open to contribute to the discussion on pros and cons and tradeoffs. To me the key question is whether it is acceptable to require that Things always connect to a gateway for the sake of security.
Let me know how/if I can help.

[mmccool]

So, there is a PR against Architecture now that adds definitions for Gateway, Edge Device (a general category that includes the others), Hub, and Edge Computer. Architecture now needs to refine the discussion of the "Hub" architecture to make clear to people this is an acceptable architectural choice for a WoT system (it is). After we close on the pre-CR drafts of the normative documents (prob 1 May) we'll be updating the Security and Privacy Guidelines and can discuss when a hub architecture is most appropriate and the security tradeoffs against a peer-to-peer/Smart Objects approach.

You are , of course, still more than welcome to join our Security call to discuss in person, but please check for cancellations due to our F2F next week. See https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#Cancellations

[hspaay]

Thanks for the update and the link @mmccool. Unfortunately joining the call is a challenge with being on Pacific time and having a job. If it is not too much of a hassle I can comment with issues or maybe it is possible to open the discussion feature on github? I've tried Stack overflow but discussion/brainstorm type questions are downvoted.

I read the PR and am excited to see the terminology of Hub and Shadow devices. This fits nicely with Gateway Hub in the WoST implementation. Thanks for that!

I'm progressing with the WoST gateway Hub and are looking into a concrete implementation of the abstract specifications for Thing-Gateway provisioning, communication, first-contact discovery and directory queries. Also reviewing existing implementations.
One point of interest is that Thing provisioning and Thing-Hub communication has different authentication needs than Consumer-Directory communication. There are different stakeholders and use-cases. Things should be able to provision/register with an edge device without requiring a directory service on that edge device (I'd be happy to elaborate). This implies that the protocol binding and authentication for Thing provisioning, TD registration and communication (events, actions) can be quite different than that of the Directory Service. Let me know if this is already covered or if you find it interesting enough to discuss further.

[mmccool]

I think it would be useful to add a security consideration point to the Architecture document. See w3c/wot-architecture#672. In general I think we probably need to think about how to better support "client" devices in WoT.

[hspaay]

FYI, I've been working on a Hub that follows the hub-and-spokes architecture.

IoT devices do not run servers in this setup and are clients that discover the hub to connect to. A provisioning service establishes trust between IoT device and hub. Communication takes place over a message bus that the IoT device connects to, using the credentials given during provisioning. A diagram of the security aspects can be found here.

The repo of the hub with core services can be found here: https://github.com/wostzone/hub.

Some of the challenges I ran into were:

1. Existing provisioning standards that I could find are not really a good fit for this use-case. I ended up writing and implementing a specification that is https based, uses certificates and is simple to use. Out-of-band secrets can support bulk provisioning if needed.
2. How does an IoT device discover the hub? Aside of manual configuration, DNS-SD worked really well for this purpose. A hub per subnet seems to be a reasonable setup. Hubs could be tied together via a bridge protocol or other means.
3. Should an IoT device publish their TD's over HTTPS or can they use other protocols like MQTT. My understanding is that this is up to the IoT device. Since the communication with the client is bi-directional (publish TD's, events and receive actions), a message bus is used (MQTT) so the hub has a means to reach the IoT device.
4. Making the hub secure is hard. Very hard. For me it drives home that this is not something you can expect every single IoT device manufacturer to do well. Then there are the issues of account management, firmware updates, and so on. Users of a W3C specification would benefit from a holistic specification that does not leave these concerns unanswered. In short, a spec that includes a hub-and-spokes model would be more useful than a spec just for individual IoT devices. Just saying :)