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?
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, 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.
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.