Security is the last unsolved problem of the Internet of Things (IoT). Really; all we have to do is make a security and it will all be good.

Poke around in IoT-Land a bunch, and you could come to that conclusion. Over the last year, I was excited to see the appearance of various whitepapers and presentations on IoT security, hoping to learn what solutions would get us over the security hump. But most just reiterated the fact that security was important and missing and someone should do something about it.

While security isn’t the only barrier to an IoT deployment explosion, it has been holding some folks back. Others have proceeded with less than ideal security since they wanted to do something without waiting for an engraved invitation to a secure IoT.

While perhaps not a global defining moment, the recent IoT DevCon conference was the first place where I started seeing bits and pieces that had more the flavor of a solution than yet another reiteration of the problem. And, if nothing else, it reinforced a really important point: there is no single Security-In-A-Can. IoT security is going to be made up of lots of bits and pieces, and that’s because there are lots of different things that have to be considered and protected.

It feels like these ideas are taking enough form for us to discuss them in these pages, but it’s all a work in progress, so we’ll attempt to lay down some fundamentals and then track significant developments as they occur. But the thing is, because there are so many different aspects to security, it’s impossible to cover in one non-TL;DR article. So we’ll sketch out some basics here and then, over the next few months, dive into specific areas that merit more attention.

The IoT is a Distributed System

The first thing to keep in mind is the fact that the IoT isn’t a box. It’s an agglomeration of boxes potentially spread out over continents. This is one of the main reasons that there are so many different pieces to a security solution. You can’t simply pour a concrete sarcophagus over the IoT to block unauthorized entry.

The pieces in this puzzle are:

• The “edge nodes” – the small, typically resource-constrained widgets with sensors or actuators that ultimately feed the IoT beast’s ravenous appetite for all the data.
• The servers – in the cloud or local or both – that sponge up all that data and – hopefully – use algorithms to learn something from the different data streams that couldn’t be learned from any individual stream on its own.
• Intervening nodes – hubs and brokers and gateways and base stations and routers – that pass messages or decide who gets messages or translate messages from one format to another. They may even perform some local intelligence on behalf of the rather less responsive Cloud.
• The wires between boxes communicating with wired connections.
• The air between boxes communicating over wireless connections.
• The phones and computers connecting to the IoT, either directly or via the Cloud
• The engineering centers where IoT capabilities are designed.
• The manufacturing centers where IoT systems are built.

This means that there are lots of nooks and crannies to exploit. Security wonks refer to the opportunities for mischief as the attack surface. And there’s a huge one with the IoT.

All of that said – and the hand-wringing notwithstanding – it’s not like we’re starting from scratch. Secure communications are already a thing. And folks have been working feverishly to protect servers for a long time. Why, you probably just today received another update or 20 from Microsoft to patch their latest round of vulnerabilities.

In the end, the thing we’re protecting is data. If something gets compromised, it’s of value to some miscreant primarily if it gives them access to data. Yes, it’s possible that someone could break in so that they can harness the machines as bots for some other nefarious purpose unrelated to the IoT function, but most of the IoT security concerns relate specifically to data security.

There are three places where data can exist, and all three create vulnerability:

• “Data at rest”: stored data sitting somewhere on a hard drive or flash memory or wherever.
• “Data in motion”: data that’s being communicated from one place to another. This could involve temporary “data rest stops” with store-and-forward mechanisms, but there is nothing new about that for the IoT, so we’ll keep that here as part of the overall communication category.
• “Data in process”: this may also involve stored data, but rather than it being permanently stored for future reference someplace quiet, it’s the data – or code – stored in RAM while algorithms are executed or while data is being readied for being put to rest or for being put into motion. Data that had been encrypted while at rest in a file may be in the clear during processing.

Edge-Node Considerations

The newest element in this assemblage of boxes is the edge node. And it’s the one that’s received the least security attention. As such, it’s often said to be the weak link in the whole shebang. They’re easy to access physically, they all look different, they may have various ports on them that may or may not conform to a physical or electrical standard, and they have stringent cost and power requirements, meaning they’ve got to jettison any function that’s not really important. Adding security will be done sparingly.

So those boxes are receiving the lion’s share of the attention. There are lots of things that can go wrong, and, if they do, they can compromise the integrity of everything on the network.

There is a laundry list of considerations for edge nodes, and this is where it makes more sense to spawn off follow-on discussions. Because each of these topics is a meaty one in its own right.

• Trusted entities: in a wild and wooly world, you’ve got to know who your friends are. Whom can you trust, and how do you know you can trust them, and how will you know if someone has turned them? It’s hard to do anything if you trust no one and nothing, so this is about identifying what can be trusted and proving that these bits are and remain trustworthy throughout. This isn’t a new concept, but it is less straightforward when your available resources are few.
• Authentication: There may be a number of entryways into your edge node. Does it admit plug-ins? Does it take consumables like ink jet cartridges? Does it have a debug port? All such entryways pose an opportunity for someone to walk on in. So how to do you make sure that whatever is currently darkening your doorway belongs there?
• Encryption: This is an old topic, but the types of encryption are changing, if slowly. There are new algorithms that may improve performance or increase security.
• Key protection: Authentication and encryption involve the use of keys. How do you ensure that your key is hidden well enough to keep it out of the wrong hands?
• Physical protection: We may think of hackers as silent sleuths slipping around the back way unnoticed. But there are others that might as well be gorillas pounding away on the box to get at the tasty treats hidden within. Think that can’t work? Well, it can if you’re not careful. In addition, your box may be giving away secrets without your realizing it. The physical form factor matters.
• Development and manufacturing processes: Everyone wants to trust their partners and employees. And, for the most part, you can. But it takes only one mole to ruin it for everyone else. How do you make sure that no one is sabotaging a design or pilfering from a manufacturing line without forcing all the teams to work naked in some sealed room somewhere?

These aren’t the only issues under consideration; heck, DDS only recently got its own security layer. And then there’s the question about multiple layers of security: say, DDS security over SSL/TLS over IPsec. Each does something, but if you’re going to rely on a lower layer for some aspect, then you really have to know what they do and don’t do for you – and where the holes are that need patching.

Wow, rereading all this, it sounds like yet another reiteration of the security problem, without solutions. So, assuming I’m not struck by a life-changing (or –ending) event over the next few months, let’s consider this a distributed article. We have now posed the questions in a way that admits the structure of the solutions to be discussed and debated. And, if you haven’t already done so, you can ponder your own answers to these questions and then compare them to the answer sheet when we discuss them. Just… be gentle in the comments if your answer differs from what comes up on the answer sheet.

 [Editor’s note: the next article in this series, on trust, can be found here.]