feature article
Subscribe Now

IoT Security

Hints of Solutions to Come

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.]

16 thoughts on “IoT Security”

  1. As stated in the article, the more complex the IoT solution is, the more points there will be for exploits.

    The real problem is the complete lack of old school KISS — Keep It Simple Stupid!!!

    There is significant security in a $100 bill, targeted specifically to keep it from being easily reproduced. And nearly zero other physical security, other than a serial number, to maybe help identify it if stolen. This specifically transfers the security problem to the environment in which it’s used, stored, and transported.

    IoT security requires a similar solution … one where there is strong security to minimize the device from being tampered with or counterfeited. And other physical and network security for it’s use and storage needs to be the responsibility of the environment in which it’s actually used and deployed.

    If this device is able to become a trojan horse, or can bring your data center or factory to a stand still if exploited or bricked, then you MUST provide strong physical and network security around it to COMPLETELY prevent that.

    The Sony attack was both costly and severe, but not nearly as damaging as what we will see in the future with targeted attacks to bring businesses and governments to their knees.

    It doesn’t really matter how cute, or cheap, or useful a device is. As a professional, you must understand that each $1 IoT device that is deployed in your company is a potential trojan horse or economic weapon possibly designed specifically to bring your company or government to it’s knees. Especially if it was design by, or manufactured by, a government owned/controlled company that is potentially hostile to our ideals and freedoms.

    If you do not get this … please find another job with less responsibility. Nobody is going to care you saved a few dollars with a poor purchasing, deployment, or contract manufacturing decision, that cost everyone their jobs after a successful targeted attack.

    How at risk are we as a nation? Just for a minute consider that China had been planning WWIII for the last five years, and every device manufactured in that country inthe last five years suddenly ceased working during their initial attack on our country. Nearly every cell phone, portable phone, internet router, computer, automobile electronics parts, light dimmers, and more suddenly failed.

    Our homes crippled, our factories crippled, our communications crippled, our businesses crippled, our government using these devices crippled.

    At war, in the stone age, without reliable technologies we depend on.

    True, or not … the risk remains real … maybe too real …http://freebeacon.com/national-security/china-military-preparing-fo

    The last thing we need to do as engineers, is hand some crazy military dictatorships the means to wage an effective war with major governments too afraid to use nukes in the chaos.

    Again, if you do not understand this, please, please get another job with less responsibility.

  2. @TotallyLost. The things you mentioned are totally lost . IoT is pretty much on low level of hardware and you need sometime layers of layers of software to activate/deactivate or control those devices from a distance/or upclose. So keep dreaming about China doing some of such a sort. Of course the fight for protecting those clusters of Machines will be fierce for the lion share in the next few years(we are already seeing that). Actually QNX/BBRY has such a power. Of course GOOG, APPL, MSFT are all fighting in that field, but Certicom ECC(Elliptic Curve Cryptography) which is so far the standard for security should play a vital role in M2M communications.

  3. @ValdDaGreat LOL … sorry, you can not waive your magic wand and claim all the trojan security problems are gone because you proclaim yourself to be Great.

    you are going to have to work a bit to demonstrate that an IoT device sitting on your wireless or cabled internal Ethernet network, is automatically blocked from using IP resources on that network.

    It really doesn’t matter a bit if the native protocols for the device are hidden in the best crypto, if the device can be shipped with a trojan back door, or can be later updated with a trojan back door.

    Once the trojan is activated, and if the device can obtain a physical or wireless connection to your network, then the trojan device is free to roam, sniff, and spoof that network using whatever protocols are available.

    Even if you believe the device wasn’t advertised with 802.11 wireless controls, they may be hidden in the device and can be used later to coordinate an attack between compromised devices. These days 802.11 WiFi is packaged in devices smaller an SD Card with integrated antennas. So even if your environment is a formal screen room, trojan IoT devices can specifically target it.

    So Vald Da Great, wave your magic wand and declare it not a problem … the rest of us need a very strong Show Me case that actually proves a successful security model with expected trojans that are aggressive agents.

    Again, if you do not understand this, please, please get another job with less responsibility.

  4. Pingback: GVK Bioscience
  5. Pingback: GVK BIO
  6. Pingback: friv 1
  7. Pingback: TS Escorts
  8. Pingback: kari satilir
  9. Pingback: Law Diyala
  10. Pingback: online casino
  11. Pingback: scr888
  12. Pingback: العراق

Leave a Reply

featured blogs
May 8, 2024
Learn how artificial intelligence of things (AIoT) applications at the edge rely on TSMC's N12e manufacturing processes and specialized semiconductor IP.The post How Synopsys IP and TSMC’s N12e Process are Driving AIoT appeared first on Chip Design....
May 2, 2024
I'm envisioning what one of these pieces would look like on the wall of my office. It would look awesome!...

featured video

Introducing Altera® Agilex 5 FPGAs and SoCs

Sponsored by Intel

Learn about the Altera Agilex 5 FPGA Family for tomorrow’s edge intelligent applications.

To learn more about Agilex 5 visit: Agilex™ 5 FPGA and SoC FPGA Product Overview

featured paper

Altera® FPGAs and SoCs with FPGA AI Suite and OpenVINO™ Toolkit Drive Embedded/Edge AI/Machine Learning Applications

Sponsored by Intel

Describes the emerging use cases of FPGA-based AI inference in edge and custom AI applications, and software and hardware solutions for edge FPGA AI.

Click here to read more

featured chalk talk

Battery-free IoT devices: Enabled by Infineon’s NFC Energy-Harvesting
Sponsored by Mouser Electronics and Infineon
Energy harvesting has become more popular than ever before for a wide range of IoT devices. In this episode of Chalk Talk, Amelia Dalton chats with Stathis Zafiriadis from Infineon about the details of Infineon’s NFC energy harvesting technology and how you can get started using this technology in your next IoT design. They discuss the connectivity and sensing capabilities of Infineon’s NAC1080 and NGC1081 NFC actuation controllers and the applications that would be a great fit for these innovative solutions.
Aug 17, 2023