In your blog post, you mention SSL. However, while fine for more powerful and expensive gateway devices, I feel that SSL is too heavy-weight for low-end gateways or high-end smart sensors/actuators. Do you see a more resource-friendly alternative on the horizon that could become used widely enough to be a real alternative to SSL?
We can use more efficient (and even more secure) alternatives in systems where we control all endpoints, but not if only the device side is under our control.
SSL and the related protocols are definitely a pain in the rear ... a comment that applies to security generally :)
However, at least for Wi-Fi-based products, the computational overhead of SSL is basically something you're paying for already. For instance, if your silicon is capable of joining a WPA2 network, it's capable of AES encryption. We are seeing components from several major vendors targeted at exactly this application, and they've normally got SSL, HTTPS, and so on built in at relatively decent prices, at least in volume.
If instead you are talking about Zigbee and the other 802.15.4 protocols, then yes, those chips don't normally offer SSL support (at least as far as I'm aware). But in this case, you're typically not talking about using IP on the device; instead, the gateway between 802.15.4 and IP would translate between the non-IP protocol and the IP backhaul to the cloud, and that's the point at which you'd apply SSL. (As I said in another comment, though, I'd want to think hard about the security of this configuration more generally. I'm not sure I'd trust, for instance, a Zigbee-based lock on my front door.)
THanks for the good advice about IoT devices. Do the same principles apply to gateways, and are there additional needs there? There is a lot of uncertainty about using TCP/IP all the way to the end device, which implies that gateways will bave a big role in the IoT. So, some advice regarding them would be welcome.
You mean, the modem/router in your home? IoT devices in principle are just like having another PC or tablet in your home. I'd expect that they will get an IP address from your broadband modem or your WiFi access router (if your WiFi is set up as a router and not a layer 2 access point), when the device is booted up, just like any other device. If they were to communicate with any web-based server out there, they would most likely have to initiate that session. I agree that mandating that the IoT devices initiate all sessions with web servers is a good way to help prevent hacking. And encryption would then prevent devices out there from intruding during the session.
With IPv4, the home gateway is typically also a network address translation gateway. As such, the IP address specific to each IoT device inside the home network is not known to hosts outside your home. With this type of setup, it is still possible to have an outside computer initiate sessions with devices behind the gateway, but only if the gateway is deliberately set up to allow this to happen. So, simply don't allow that the happen.
As to hacking into the home gateway from outside, to reprogram it, that type of access is password-protected. So I think the advice in the article is good.
Bert, no I am not asking about a modem/router. I am asking about gateways, which convert from some other network protocol to the TCP/IP that the Internet uses. Zigbee devices, for instance, may not be able to support the kind of security that WiFi devices can. So, there is a gateway device to convert ZigBee to TCP/IP. What special security software needs does it have, if any, to help protect the edge devices from outside attack?
Rich, if the IP communications are end to end, then it makes no difference what link layer is used to get to the device. But if you're talking specifically about Zigbee without having IP layered on top, then Zigbee does have its own 128-bit symmetric encryption, actually. The IP protection would go between the server and the IP-Zigbee gateway, and then Zigbee's own encryption scheme takes care of the rest.
If you're referring to most routers in public or in your homes, this shouldn't really be an issue. IoT devices should work just like a PC, phone, tablet etc. It should ask for an IP via dhcp just like everything else.
Your home network gateway plays an important role to the security of your home network as well. Typically, my gateway doesn't listen to any port in the extenal network. If it does, I only allow connection from a specific IP address, e.g. my office gateway address. 5 tips in this article are very good. I am sure there will be more tips and in some IoT application, some tips may be found difficult to apply. Nonetheless, this article is a good starting point to develop a complete list. Security is no doubt the main concern in IoT. The sooner the list is nailed down, the better security we will earn.
I recently upgraded my home router, and I was impressed by how locked down the new one was by default. They randomized the SSID, closed down any inbound connections by default, turned off ping response, provided a unique default password, and a number of other enhancements. It is still quite possible to override these settings, but a user that doesn't do that will be much safer by default with new equipment like this.
If we design to have the device initiate all communications, how to handle the situation where you want to remotely command the device? Do you issue a command that waits until the device opens a dialog because has something it wants to say? Should the device be configured to check in on a regular basis so that queued commands can be delivered? How often? (Answer affects battery lifetime) How about the situation where you want an immediate response to a command, such as when one IoT device senses a condition that another IoT device should react to, but the point where the two devices connect is in the cloud?
Rich, it all depends how much security you want. I'm simply suggesting that if web-based sessions are always opened by the device, or by some in-home server, and the session begins with negotiating a security protocol, then this is the best way to ensure security. That's how you do most of your secure online sessions, say when purchasing items online, or dealing with your bank.
And since homes are typically connected via NAT gateways anyway, this is the most practical way of operating with a NAT. This avoids any manual configuration of the modem/gateway box.
Allowing an outside device to "wake" the inhome device is certainly possible, but it's asking for trouble. Like you say, having the IoT device poll some web-based server, if it needs input from that server, is possible. At whatever interval makes sense for the application. Or if you need the outside server to have quick responses from the IoT device, hopefully this fast back and forth can be limited to a relatively short amount of time, during which you simply keep the secure TCP/IP session open.
And it's not a good idea to force some web-based server in the middle of a conversation between two in-home devices, I don't think. That's a solution that doesn't scale well, plus it introduces unnecessary vulnerability.
If it makes sense for your application to give the device a server role, so that communication can be initiated from the "outside" (anywhere on the Internet) anytime, this usually means opening incoming ports in a firewall. As the article correctly pointed out, this is undesirable. For this reason, in some industrial settings it can be hard or even impossible to convince your customer's IT to open incoming ports, e.g. to enable remote troubleshooting, and rightly so.
We have hit this problem several times in customer projects, and looked at many possible solutions, from VPNs to XMPP and many others. We found nothing appropriate for the given requirements and thus created our own solution. Basically the idea is to provide an incoming port logically, but physically use an outgoing port, using a relay server on the Internet and some kind of "reverse HTTP" protocol. The device connects to the relay server and registers there with a unique ID. A client application, e.g. a standard Web browser, then can connect to the relay server, whith the device's ID as part of the URL. If nothing happens for half a minute, the connection is closed and the device re-registers. Note that the device itself thus has and needs no IP address, but it has a URL through which it can be addressed and accessed via the relay server.
This is a simple scheme, but the devil was in the details, and in the requirement of one customer to scale to more than half a million devices (i.e., more than half a million simultaneously open SSL connections...). We ended up with an implementation that can be deployed to fault-tolerant server clusters in the cloud.
Of course, this approach is a challenge for battery-operated devices, as a connection must be kept open all the time.
I don't want to misuse this forum for something that would amount to an advertisement, even though we have published the source code of the relay server, so if anyone is interested in more information, please contact me at pfister (at) oberon.ch.
Regarding the role of the gateway between the IP-based network and the 802.15.4 protocols (of which Zigbee is but one example) -- there are a whole host of issues here and probably deserving of an entire blog post. (To address Bert's comment: This configuration is common because of the very low power requirements of 802.15.4. Unfortunately, typically the IP communcations are terminated at the gateway instead of being carried all the way to the device.) Specifically regarding the security of this configuration, I think there are likely to be vulnerabilities there, at least if you assume that attackers can get reasonably close to your 802.15.4 network. Definitely something to worry about.
Regarding how you engineer things to statisfy my "outbound connections only" rule, I have another blog post addressing that: http://www.cardinalpeak.com/blog/?p=1791
Thanks for the wonderful recommendations and suggestions. It is not the IoT that is the problem. The weakest link in Information security is people. As long as the average person do not know the meaning of "outbound"; or how about "HTTPS and SSL"; and what about "backdoor." Come on...Once again, wonderful suggestions.
Very good article. One thing that I would add, though, is the need to particularly lock down video feeds. This is an item that many people add to increase security but neglect to adequately lock down. Not only does that make it handy for an intruder to surveil the premises, but it can also provide a convenient open window. Peeping toms no longer have to hide in the bushes outside of a physical window.