Breaking News
View Comments: Oldest First | Newest First | Threaded View
Page 1 / 3   >   >>
rick merritt
User Rank
Author
Howdy, Howdy
rick merritt   11/18/2013 10:56:14 AM
NO RATINGS
Welcome to EE Times as a new blogger. I look forward to some frank, objective views on where IoT is at and going.

howdypierce
User Rank
Rookie
Re: Howdy, Howdy
howdypierce   11/18/2013 11:47:29 AM
NO RATINGS
Thanks, look forward to it!

RichQ
User Rank
CEO
How about gateways?
RichQ   11/18/2013 4:47:48 PM
NO RATINGS
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.

Bert22306
User Rank
CEO
Re: How about gateways?
Bert22306   11/18/2013 6:57:16 PM
NO RATINGS
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.

RichQ
User Rank
CEO
Re: How about gateways?
RichQ   11/18/2013 7:31:09 PM
NO RATINGS
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?

 

RichQ
User Rank
CEO
How about remote commands?
RichQ   11/18/2013 7:33:59 PM
NO RATINGS
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?

Bert22306
User Rank
CEO
Re: How about gateways?
Bert22306   11/18/2013 7:46:30 PM
NO RATINGS
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.

Bert22306
User Rank
CEO
Re: How about remote commands?
Bert22306   11/18/2013 8:01:34 PM
NO RATINGS
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.

Sheetal.Pandey
User Rank
Manager
Re: How about remote commands?
Sheetal.Pandey   11/19/2013 12:09:59 AM
NO RATINGS
Yes security is the biggest issue in internet of things and connecting your home devices to remote contron. BUt continuous check and being alert is the only option.

Cuno
User Rank
Rookie
Re: How about remote commands?
Cuno   11/19/2013 5:23:47 AM
NO RATINGS
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.

Cuno Pfister

Page 1 / 3   >   >>
Top Comments of the Week
August Cartoon Caption Winner!
August Cartoon Caption Winner!
"All the King's horses and all the KIng's men gave up on Humpty, so they handed the problem off to Engineering."
5 comments
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Radio
LATEST ARCHIVED BROADCAST
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.
Flash Poll