Security in the IoT
We give an overview of IoT security and cover one aspect, the safe connection of end devices, in more depth.
What does it matter?¶
"What does it matter?" can really only be asked to provoke reactions.
It is clear that with more and more devices around us connected to the Web, generating information about us, privacy concerns are raised to a new level. We are entering the age where everything about us is known by the devices that increasingly surround us. Whether we think we have something to hide from others or not, I am sure we would all prefer that some parts of our lives or information about us remain private (if not, why not send me your bank account login?).
Safety as another concern also takes on a different meaning in a world where machines whose failure could kill you are increasingly connected to the Web.
It's not a theoretical concern¶
Neither of the above concerns is in any way theoretical. Security failures in the IoT space have made it possible to get your Google account credentials from smart fridges, to remotely disable the brakes in some car models, or to remotely control drug infusion systems.
With so many connected devices already out there, some breaches are to be expected. These cases, however, are not isolated incidents, but a symptom of wide-scale security failures out there. A HP study from last year found that 50% of examined devices did not use transport encryption and 60% did not have secure update mechanisms. Devices are shipped with security holes as big as running VNC services which are accessible without authentication!
Security is hard, but it's worth trying¶
First off: Security for networked devices is hard. Really hard. But you can make it hard enough that almost all attackers will fail. There is a difference between being open to abuse by any script kiddie and being vulnerable to a big-budget attack by the NSA.
In the emerging IoT world though, security more often seems to be an afterthought. With everybody scrambling to get in on the IoT wave, product deadlines are often the most important thing, and anything not on the feature list gets ignored. Delivering the product is what matters now, and a catastrophic security breach may already be something that the next management has to worry about.
There is also the culture clash: Companies from all kinds of industries are now making what are effectively networked computing devices, without having any background in how to secure them. Mistakes that people in the computing industry have (often) learned to avoid through a long and painful process of trial and error are repeated by people who are trying for the first time, and have yet to be burned by their failures.
IoT security is a wide field, so to go into more detail here we need to narrow the scope and take a closer look at just a single aspect. And why not one of the most central ones: The question of how to securely connect an IoT device.
To start of, we use a usage example which is boiled down to the minimum: You want to control a lamp from any browser via the Internet.
The simplest way of getting there is to run an HTTP server on the lamp, and then just post an HTTP request to it from the browser (POST with a body containing the argument or GET with the argument as a fragment part is up to you). Since HTTP can be used from any runtime, you're also already prepared for adding other devices in the future.
To secure the connection we use HTTPS (and configure this so we don't use any ciphers which are already cracked).
Done - quick and simple.
In practice you quickly start to run across problems getting this to work. IP addresses are scarce, and most of the time at least one of the two participants in your system will be behind a NAT. The device you are trying to post to may not be reachable directly. It almost certainly won't be if it is in your home.
So you start to modify things.
If you have access to the router or routers, you can set up port forwarding. If you do not have a static IP address for the network (the usual case for homes and small companies) then you can add a DynDNS solution.
Often You will not have that access (e.g. because your browser runs on a mobile device and the network operator controls the NAT). So maybe you try a VPN that all participants connect to.
Are you ready to wait for a while? IPv6 has to happen eventually, and with it IPv6 NATs may become a thing of the past (more likely not though).
Things become neither quick nor simple very quickly.
Do we want open ports?¶
At this point it is worth taking a step back and looking at the bigger picture, and to include security considerations from the start (the HTTPS was really more of an afterthought).
When thinking about security you need to consider where your system can be attacked (the attack surface) and what you can do to secure these points. You want to minimize the attack surface. Here you will probably want to start with the parts which are difficult to secure first of all.
In an IoT application, devices like our lamp will be numerous - and there will also be potentially multiple different devices. At the same time, these devices will more often than not be low-powered. Add to that the fact that updates are likely difficult to install across all of them, when they are available at all, and you get a pretty bleak picture: with the devices you have a huge attack surface where you have few resources you can devote to security, and where security bugs may remain unfixed forever.
(An example of the problem with security updates: Home cable modems and routers using TR-069 for remote management have a Web server running which accepts requests to initiate a connection. Unfortunately on over 200 different devices out there an old implementation allows remote control of the Web server using a single magic cookie. The problem was fixed by the manufacturer of the software in 2005, but vulnerable version are still used on new devices. This means that millions of these devices can be taken over by anybody who bothers to download a script and try. For details see this Web site.)
Things here are unlikely to fundamentally improve anytime soon. New hardware models will continue to consume their producers development and support resources. Security fixes for old models will remain low priority, and just not be released most of the time. Software on the devices out there will be buggy, and even if there are fixes, distribution is difficult.
Reverse the direction¶
So open ports which attackers can scan are something we want to have as little of as possible - whether these are on the public Internet or within a VPN which an attacker might compromise. It would dramatically reduce the attack surface in almost all applications to have only outbound connections from our IoT devices.
This, of course means that we require some central instance which does accept inbound connections. The downsides are that we no longer have peer to peer connections, and that this is now a much more interesting attack target than any individual device was before.
The first is more of a philosophical concern than a practical one. In practice NATs mean that vanilla P2P is not possible. If we get things working by using a VPN then there's already an additional intermediary.
Our consideration of the second aspect is implicit in what we said about the attack surface that the individual devices present: a single sever, or a small number of servers, are easier to protect than a huge number of devices out there. You can update it continuously and you have the resources to run proper security measures. It is also much easier to monitor and detect intrusions in time when they do happen. Having just a single attack target is a big net win in security, even if that target is more interesting to an attacker.
So what's our architecture now?¶
We now have the lamp, the browser and an intermediary between them. With our use of HTTP, the lamp can poll the server for commands, and the browser now posts its commands to the server. The server then routes commands and the result returns between the two.
This is what we have with WAMP and Crossbar.io: Clients connect to a WAMP router, and they do not have any open ports. Crossbar.io is updated regularly, and installing these updates is trivial compared to updating all clients. For us security is not an afterthought, and we devote more time to ensuring it than you could probably afford when developing your application components.
WAMP does routed Remote Procedure Calls: in our simple example, the lamp registers a procedure for switching its state with the WAMP router, and the browser, or any other client wanting to change that state calls the procedure. (Nice side effect: All the caller needs to know is the procedure name - how the lamp is connected and how it can be reached is no longer any concern of it.)
About the (mis)use of HTTP: The polling is conceptually ugly. It is also wasteful and increases latency. You have wire traffic when there are no actual events to transmit, and full HTTP headers are sent on every request (which can be a couple of KB of traffic for just a few bytes of payload). As long as a long-polling request is currently open, latency is low, but there are gaps when the next polling request is underway.
Crossbar.io supports HTTP (long) polling as a fallback transport (for really old browsers). The default, however, is WebSocket.
This offers persistent, low-latency bi-directional connections. It is browser-native, and there is support for basically any programming language and framework. Using WebSocket, messages are only sent when there is an actual need. The protocol is designed with small messages in mind so there is minimal overhead per message. There is no need for connection establishment before each message, which improves latency.
Should neither work for your use case, then WAMP has fully pluggable transports: any ordered, reliable, bi-directional, message-based transport can be used in principle. WAMP started on the Web, but it can extend well beyond Web technologies.
Not a silver bullet¶
The above is one way of looking at things. We think we have good arguments - but for your particular deployment scenario, things may look different. There's never one answer that fits all use cases. There are no silver bullets in security (anybody who tells you differently is either naive or lying).
So take a look at what you want to do and where the potential attack surfaces are. We are confident that a lot of you will find that our model of shifting the attack surface to a central router makes perfect sense for you.
Full disclosure: I'm not a network security expert. As with anything, you should always look at the arguments first and foremost.