A Simple Proposal To Improve Security for the Internet of Things

A small change can help stop big hackers.

Almost every IoT security breach in recent news can be traced to the poor architecture of the wireless protocol used by the device. But unlike fighter pilots who maintain radio silence in order to avoid detection by the enemy, it is surprising how few IoT technologies were designed with even a minimum level of stealth in mind.

Remaining quiet is not the most important principle of IoT security and privacy, but it’s a pretty basic one.

Avoiding or minimizing the chances of unauthorized discovery is not technically difficult. But today’s IoT technologies like Bluetooth, 6lowpan, Sigfox, LoRaWAN, and others make unauthorized discovery very easy and it creates the worst kind of angst in IT departments.

Today’s IoT Is Pretty Damn Noisy

“Some security measures are often not thought of originally and embedded in the system, so they have to be put in later … A lack of attention and planning is always a source of security problems that inevitably come up when new technology is deployed.” — Ruggero Contu, analyst @ Gartner

Most wireless IoT technologies were originally conceived as ways to stream large files (Bluetooth, WiFi) while some were designed to be “lighter” versions of WiFi (e.g., ZigBee). Today they are being re-positioned as “IoT” technologies and security, to put it nicely, is an afterthought. Oh yes — some have tried to “layer on” security and may profess to support encryption, but hacks for all of these technologies are quite public yet fundamentally traceable to one original sin:

these wireless IoT technologies don’t know how to keep quiet.

Most wireless IoT technologies need to make themselves known in order to make it easy for users or networks to “discover” them. If you connect to WiFi in public or even around your home or office, you know what I mean:

More recently, drones are being used to hunt for ZigBee-based endpoints, giving bad actors an easy way to discover, map, and hack ZigBee endpoints:

this type of hack provides all sorts of information about each endpoint, including manufacturer ID.

Oh and drones are being used to discover WiFi, too. Hacking devices called “pineapples” enable ridiculously easy man-in-the-middle WiFi surveillance:

Using a drone with a “pineapple” to map and hack WiFi endpoints

And of course when you hunt for a new Bluetooth device to pair you often discover plenty of Bluetooth devices advertising themselves around you:

This need to be “discoverable” — and this is not limited to ZigBee, Bluetooth or WiFi but to most wireless IoT technologies — requires a near-constant advertising of a device’s presence, leading to any number of “disaster scenarios” that others have extensively written about. In my experience, few people who understand IoT customer requirements will object to the principle of quiet or “stealthy” IoT endpoints, at least in principle. In technical practice, however, it means upgrading or replacing legacy technologies, of which there are roughly three classes as it relates to stealth:

1. Chatterboxes. These devices talk non-stop, sending data to the network every few milliseconds whether they have something important to say or they just want to repeat what they said 200 milliseconds ago. They usually share things in the clear (not encrypted) and are easy to spot in the wild. And hack.
2. Cuckoos. Like a cuckoo clock, these devices don’t necessarily talk non-stop but they periodically blurt out their presence — usually every few seconds — in order to sync with a network and aid discovery. They are usually capable of sending a message when they have news of an event to share — like a change in temperature, for example.
3. Snipers. These devices speak only when an authorized device queries them or, like Cuckoos, when they have something important to share with the network. They don’t “fire” their weapon unless absolutely required.

Most wireless IoT endpoints in the marketplace today fall into the chatterbox or cuckoo class, which violate what should be a first principle of IoT device security:

Be stealthy.

Why Stealthy IoT Endpoint Design Matters

“Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it.” — Edward Snowden

The natural state of most things in the world is … quiet. Think about it. Thousands of years of trial and error prove that being quiet (perhaps in combination with hiding) helps to avoid alerting predators to your location, enables prey to hear an approaching predator, provides an ambient environment that gives others the ability to be heard, and conserves energy. In the world of wireless, radio silence has been a basic tenet of military communications security that remains in place today.

The first CSO …

Silence is almost always inexpensive, easy to do, and effective and is probably the most popular security behavior practiced by humans since … Neanderthal man.

There is no technical reason that the Internet of Things cannot embrace silence, or stealth as I prefer to call it, as a first principle of endpoint security. Stealth is not a silver bullet for IoT security (there is no silver bullet) and stealth alone won’t protect a network from intrusions, but dollar-for-dollar, stealth is the simplest, cheapest, and most effective form of IoT security protection available.

The simplest and least expensive security requirement for next generation wireless IoT technology design is stealth.

Why?

1. Cloaking. It is harder to discover, hack, spoof, and/or “stalk” an endpoint if a hacker cannot locate the endpoint.
2. Googling the IoT. Stealth enables real-time queries of endpoints, a la Google search that non-stealthy endpoints can’t support. Stealth also enables fast queries (<2 seconds) in environments with thousands of endpoints, in turn enabling big data analytics at the true edge of the network.
3. Minimize interference. Less data being transmitted minimizes the opportunities for interference and failed message transmissions. Contrast this with the tragedy of the commons at 2.45 GHz, where WiFi, ZigBee, microwave ovens, and other countless other technologies engage in wireless gladiatorial combat and cause too many customers to return their IoT gadgets because they “don’t work”.
4. Maximize wireless network capacity. Stealthy endpoints send and receive less data and make it possible to operate in radio spectrum where spectrum is “narrow”. This is particularly important with newer LPWAN technologies that appear poised for success in the IoT.
5. Power. Less data being transmitted reduces power consumption both at the endpoint and in the downstream network. If your IoT endpoint is battery powered (most are), then stealth is important unless your customers enjoy changing or recharging batteries.
6. Access control. Stealthy endpoints make it easier to control access to the endpoint by limiting who can query the endpoint.
7. Storage. Less data being transmitted reduces storage costs. Storage vendors, on the other hand, love the non-stealthy IoT status quo.

Put simply, IoT wireless endpoint design that does not embrace stealth is inherently less secure and less private.

Principles of Stealthy IoT Endpoint Design

There is no global consensus on how best to implement wireless IoT endpoint security. Competing vendors claim to solve for slices of what amounts to a massive challenge, but reasonable people should be able to agree on first principles of next-gen IoT endpoint design in order to achieve stealth:

• Chatterboxes and Cuckoos are out, Snipers are in. Wireless protocols that constantly advertise their presence or otherwise spew too much data are obsolete or obsolescent. Their inherent security and privacy flaws stem from design that took place in a different era with a different vision of IoT use cases and different silicon.
• Listen-Before-Talk (“LBT”). Listen-before-talk implies an endpoint that “listens” for an authorized interrogator before transmitting anything to the network. Its means of network synchronization, the way it checks for new messages, the way it masks its address, and other factors encompass the way a LBT endpoint behaves. LBT is essential to stealthy IoT endpoint design.
• Event-driven messages. “Event-driven” implies an endpoint that transmits a message about an event — for example, a change in temperature or the detection of movement — when the event occurs. Like LBT, event-driven messages are essential to stealthy IoT endpoint design as data is only transmitted in connection with important events rather than at some arbitrary interval or for purposes of synchronizing with the network.

• Full-stack stealth. Implementation of listen-before-talk and event-driven architecture in the endpoint cannot be limited to a single layer (e.g. Layer 2) in the OSI stack, but rather must implemented throughout the endpoint’s firmware/software stack — from layers 2 through 7. For example, the principle of stealth is defeated if the low level operating mode of the endpoint is “quiet” but the means of network syncronization or the application running on the endpoint forces unnecessary chatter with the network. All layers of the firmware stack must work in concert to successfully achieve stealth.
• Data caching. Rather than transmit data as it is created, stealthy endpoints cache data in the endpoint until the endpoint is queried by an authorized user or an event triggers the sharing of the data. By caching, we enable real-time endpoint queries and reduce the strain on wireline network infrastructure and storage.
• Better Low-Level Cryptography. Stealthy endpoint design must define methods for managing a network of multiple keys, as well as new ciphers suited to small data payloads. WiFi hackers, for example, take advantage of the fact that WiFi devices talk too much, and common traffic from different devices can be analyzed against each other. This works because all the devices on the network use the same key. During WWII, British code breakers used this same basic strategy to break German codes.
• Firmware updates. Stealthy endpoint design must not preclude the secure execution of over-the-air (OTA) firmware updates and patches. As devices age, they require maintenance including security patches, and the operating mode of a wireless protocol should not preclude OTA software updates.
• Open Source. Many security vulnerabilities are simply bugs or oversights which would have been quickly detected and fixed if there had been an open source community working on the project. A famous example is the security firmware for the smart card payment platform MiFare.

It is worth mentioning that almost by definition achieving stealth results in an endpoint consuming less power. Similarly, stealthy endpoints that speak when queried are better stewards of scarce radio spectrum. So while stealth is an important next step in IoT security, it simultaneously solves for other IoT usability and scalability goals.

How We Can Bring Stealth to the IoT … Now

If security is such a big deal for the IoT — and there are more than a few experts who think it is — then we should be taking steps now towards implementing stealthier endpoints.

• Rethink roadmaps. First, and most importantly, established vendors should re-think wireless protocol design roadmaps and incorporate full stack stealth at least as a matter of corporate responsibility, if not for revenue opportunities. The kind of shareholder and brand fallout experienced in recent payment card and email hacks is sure to reach the Internet of Things soon, so responsible CXO’s and boards are asking whether IoT roadmaps include full stack stealth. There is also little reason why standards bodies like the ZigBee Alliance, the Thread Group, and others who profess to care about IoT security cannot add stealth as a requirement for their next iterations of their stacks.
• New ventures may already have the answer. The huge number of new IoT ventures being created every month reflects the scale and scope of the opportunity. Companies like the one I co-founded, Haystack, are bringing new stealth-based IoT technologies like DASH7 to the marketplace and others may follow, but LBT and event-driven messaging is at the core of what we designed at Haystack.
• Borrow & Mix. A combination of the first two may provide the industry with an interim solution. Melding new technologies and standards on top of existing standards may provide a way of staunching some of the bleeding.

“We believe that by adopting the best practices we’ve laid out, businesses will be better able to provide consumers the protections they want and allow the benefits of the Internet of Things to be fully realized.” — FTC’s Edith Ramirez

• Regulatory pressure. Short of industry moving to stealthier connectivity for business reasons, we will likely see external drivers of stealth, too. The prospect of government regulation of the IoT is a growing threat now in Washington as the IoT is seen as rife with risks to consumer privacy and homeland security.

You can find me on Twitter at @patdash7 or email pat at haystacktechnologies dotcom