Category Archives: Internet of Things

Fu and Xu on the Insecurity of Sensors

In past posts, I have complained about the poor design and insecurity the “Internet of Too Many Things”.

This month Kevin Fu and Wenyuan Xu give me yet more sphincter tightening reasons to worry about these systems: transduction attacks [1].

Much of the IoT is built of small devices equipped with sensors of many kinds.  These clever little devices are transducers, converting physical phenomena (light, vibration, head, motion, etc.) into electrical signals and ultimately digital numbers.  Anyone who has explored sensor technology knows how awesome this magic can be.

Any input device can be attacked with bogus input, and the output of any module can be subverted by intercepting or messing with its output. Conventional security measures are designed to protect the integrity of inputs and outputs (e.g., with cryptography and error detection).

But physical sensors are also face a third kind of attack, a transduction attack which “exploits a vulnerability in the physics of a sensor to manipulate its output or induce intentional errors”. ([1], p. 20) Yoiks!   If I can’t trust my sensors, the whole system is in peril.

F&X say this is a huge problem because most commercial systems to date are not designed with this threat in mind.

Billions of deployed sensors lack designed-in protections against intentional physical manipulation” ([1], p. 20)

For instance, most consumer-grade voice recognition is vulnerable to DolphinAttack: ultrasound signals that fool the system into executing commands unheard by the humans. This is possible because the microphone can detect ultrasound (which it arguably doesn’t need to) and the algorithms can be fooled.

Hacking my phone is annoying enough, but this is far more dangerous when it is an airliner, autonomous car, or a hospital being hacked this way.  Yoiks!

Protecting against transduction attacks is difficult because the consequences arise as software symptoms, but the risks begin in the physics of hardware.” ([1], p. 21)

What can be done?

Obviously, relying on software testing isn’t sufficient, nor is reliance on tests of individual components.  The overall system needs to be designed to be able to check outputs of sensors, with the assumption that they may be untrustworthy. (This will be painful and add cost and complexity.)

F&X note that many of these attacks exploit the resonance of physically connected components.  E.g., attacks on motion sensors via sounds sent to the speaker works because the components are mechanically coupled so the vibration of the speaker can fiddle the accelerometer.

They note a recent CERT advisory that recommended ways to mount the component in order to minimize physical coupling and control vibrations in critical ranges (i.e., the resonant frequencies of nearby components).

F&X also note that this problem calls for broader, interdisciplinary design expertise. Computer Scientists don’t necessarily know the physics and mechanical engineering needed, and vice versa.  This teamwork is particularly important for systems such as autonomous vehicles, which need to be trustworthy.

F&X refer to this as “back to basics” for the Computer Science curriculum. It is so easy to focus on all the power of software, and simply assume that the hardware black-box just “works”.

students may seek comfort hiding behind a beautiful Java facade rather than facing the ugly limitations of computing machinery.” (p. 23)

  1. Kevin Fu and Wenyuan Xu. 2018. “Risks of trusting the physics of sensors.” Communications of the ACM 61 (2):20-23.

IoT Isn’t Even Close To Trustworthy

I have already beefed about the current version of the Internet of Things, which is of dubious value and badly engineered, to boot. (Here, here, here, here, here, here)

The most visible face of these developments are the network connected home “Assistants”, such as Alexa, Siri, Google Home, and so on. Aside from the extremely questionable rationale (Why do I need a voice interface to my refrigerator? Why do I need my refrigerator to connect to the entire freaking Internet?) there are famous cases that illustrate that these beasts are deeply invasive.

Last fall, Hyunji Chung and colleages at US National Institute for Standards and Technology (NIST) wrote about the trustworthiness of these systems.

[S]uch interactions should be solely between you and the device assisting you. But are they? How do you know for sure?” (p. 100)

These are complicated, network connected systems which are not trivial to understand and evaluate. But they are in our homes, so everyone needs to know just how far to trust them.

The researchers sketch the “ecosystem” of network connected components and services. The very fact that they are complex enough to warrant the term, “ecosystem”, is the fundamental problem.

[W]e performed cloud-native artifact analysis, packet analysis, voice-command tests, application analysis, and firmware analysis” (p. 101)

Uh, oh. Does anyone besides me see a problem with deploying such a system unsupervised in private homes?

The threat envelope is huge. The basic logic of the assitant is implemented mainly in “the cloud”, with components on local devices that communicate with the cloud. Many assistants have third party apps as well. They report that the Alexa “Skill Store” has 10,000 such voice-actuated apps.

The point of the analysis is, of course, risk assessment. They identify many, many risks—basically, everything that might threaten the Internet.

  • Wiretapping
  • Compromises devices
  • Malicious voice commands
  • Eavesdropping

Wireless communication is, of course, a weakness. The researchers report the appalling fact that not all the communications are encrypted. Even when encrypted, traffic sniffing can still reveal considerable information about the devices and users.

Obviously, devices may be hacked. In this case, there is no expert IT department to defend the network, detect intrusions, or patch bugs. One has to think that home devices are relatively defenseless, and certain to be cracked over time.

One reason I don’t like voice commands is that they are hard to secure. Even the best voice recognition systems are vulnerable to mistakes, and low-cost, consumer-maintained systems probably aren’t top of the line. (And who wants your Alexa to reject commands because it isn’t certain that you are really you.)

And, of course, every link is a potential channel for someone to listen in on your life.

This article makes clear that these systems have a lot of potential issues, even if they are configured correctly and work as designed. Unfortunately, personal and home devices are not likely to be carefully configured or monitored. I have a PhD in computer science and have done my share of sysadmin, and I have not the remotest clue how to set up and keep one of these systems.

These researchers carefully don’t answer the question, “can I trust you?” But it is very clear that the answer is “no”.

I’m afraid that people are taking these devices on faith. They are sold as appliances, and the look like appliances, so they must be as safe as a consumer appliance, right?

Well, no.

This is a really great article, and everyone should read it before turning on any cloud service, let alone installing an “assistant” in their home.

And if you don’t understand what this article says, then you definitely shouldn’t install one of these assistants in your home.

  1. Hyunji Chung, Michaela Iorga, Jeffrey Voas, and Sangjin Lee, “Alexa, Can I Trust You?”. Computer, 50 (9):100-104, 2017.

CertiKOS – This is what the IOT should be

Now and again I have criticized the software architecture of contemporary consumer electronics, including mobile devices, home automation, and the Internet of Things.

In particular, in response to the never-ending stream of security oopsies, I have said that it is a mistake to use a general-purpose operating system on these extremely exposed and unmanaged devices.  Realistically, there is no way to make complex systems such as Linux, Android OS or iOS secure, and once breached, the whole system is exposed (and worse, can be repurposed).

It is easy to say what not to do, Bob, but how do you do it right?

Secure operating systems are very, very hard to make, and every cunning advance in hardware (multicore, multiple busses, complex memory hierarchies, integrated networking, etc.) makes it all that harder.  Furthermore, creating a provably secure OS has to be fast and cost effective, because there are so many devices coming out.

One good example of what I’m talking about is CertiKOS from Yale.  As in any secure system, the logic is formally verified to help assure that it does what it is supposed to and only what it is supposed to.  Importantly, their system is composable, designed to be able to build up a system from components, and keep it kosher [1].

Phew!  This stuff makes by brain hurt to try to follow it.  But this is what needs to be done.

What I would like to see is to use something like this to build “certified” software for each and every IoT device and home automation gadget.  In particular, I want the IoT device to do only the limited things it is supposed to do, and simply not be able to do anything else.

A “smart light bulb” should only do what a SLB should do. Which, honestly, isn’t much.  Hack into my light bulb?  Even if you can, who cares?  It can’t do anything.

OK, I know this isn’t the whole story.  Securing networks of devices is more complicated, since there will still be problems, such as fiddling with traffic and loads.

It is also true that it will be very challenging to create a device that can load endless third-party apps, like your mobile phone can today.  But, that’s probably a good thing to cut back on, anyway.

This kind of modular device can probably help privacy as well.  How many times do we have to learn about some app that is surreptitiously spying on users.  If a device can’t spy on you, then you don’t need to worry so much about who is subverting your pocket or your living room.

Obviously, this kind of privacy is hard.  A “secure” Alexa (Salexa?) would have components to exactly and  do only what is needed. That would require designing the functions in advance, which would require understanding how people live, and designing to meet those needs

This contrasts to current methodology, which release a powerful, general-purpos platform and loads whatever combination of apps the user buys.  And in many cases, the device really knows very little about what should be done, and surveilles the user to “learn” their behavior and preferences.  This approach both invades privacy (by design) and exposes the user to huge risks if the system is infiltrated by enemies (not by design).

I think the bottom line is that  secure kernels are necessary but not sufficient to make network systems more secure.  Security and privacy are end-to-end problems, and only as good as the weakest link. But making components stronger is a good start.

The cool thing about the Yale work is that they are building tools and processes for building and composing components.  This is a crucial technology for building systems, if not the complete solution.

Nice work.

  1. Ronghui Gu, Zhong Shao, Hao Chen, Xiongnan (Newman) Wu, Jieung Kim, Vilhelm Sjöberg, and David Costanzo, CertiKOS: An Extenisble Architecture for Building Certified Concurrent OS Kernels, in USENIX Symposium on Operating Systems Design and Implementation. 2016. p. 653-669.

3D Printed Objects ‘Connect to Wifi’

Researchers at University of Washington report some interesting work creating simple 3D printed objects that “connect” to wifi without complex electronics [1]. The objects can be used a sensor or input device.

The basic idea is that this technology can be low-cost, ubiquitous, and customized. While this system isn’t quite “without electronics” [2], the objects are simple enough to be fabricated with a 3D printer.  The fancy stuff is in a mobile device and the wireless network—which is assumed to be ubiquitous infrastructure.

The researchers made several examples, including an anemometer, a flow meter (water wheel), and a spring scale.  They also created input devices, a push button, a slider, and a dial knob.  These examples are building blocks for user interaction and for environmental or industrial sensing.

The idea is to use radio back scatter as a simple signaling device. Basically, an antenna is embedded in the printed object, with a switch that changes the reflectivity of the antenna. The 3D objects trigger the switch using clockwork or other mechanical action (e.g., a push button or turbine).  This mechanism can represent a (low bit rate) signal as a series of modulated reflections.

The signal is detected by processing the reception from a wifi or other radio receiver. Filtering out the high frequency signals will detect the low frequency data from the sensor.  This can be done with a mobile device such as a phone of tablet.

The coolest part is the 3D printed clockwork mechanisms used to modulate the transmission. Gears! Springs! Buttons!

The technical paper has details about how well it works, as well as interesting examinations of the interference of human movement (which modulates back scatter).  In order to use more than one such device, the “channel” can be frequency multiplexed by printing devices with different gear ratios!  That’s kind of cool.

  1. Vikram Iyer, Justin Chan, and Shyamnath Gollakota, 3D printing wireless connected objects. ACM Transactions on Graphics, 36 (6):1-13, 2017.
  2. Jennifer Langston, In first, 3-D printed objects connect to WiFi without electronics in UW News. 2017.


Semantic Web and The Internet of Things

I’m not a gigantic fan of the contemporary Internet of Things (AKA The Internet of Way To Many Things), but this is not because I don’t understand the concept. Quite the reverse actually – I was doing this stuff back at the fin de vingt-et-unième siècle.

I must say that I thought most of that early work was out of date, surpassed by big data, machine learning, and billions of dollars.

This month I was shocked to see not one but two articles about using the Semantic Web for the Internet of Things—exactly what I was talking about back in ought-five [4].

Problem:  the world is filled with more and more autonomous devices which need to connect, configure, and cooperate with each other.

In the IoT, there are no system admins, let alone configuration files, and so on.

So how do nodes know who is who, what is what, and how to talk to anything?

This was the motivating problem at the beginning of my own thesis work (circa 1998-9).

Configuring these devices requires something like scripts, rules, and triggers, but simple scripts

can only apply to known places, users, and IoT devices personal needs.

This lack of discovery and adaptation severely restricts the rules’ expressive power.” ([1], p. 18)

Way back in the last century, I started exploring the use of Semantic Web technology to address this challenge (“Semantic Infrastructure for a Ubiquitous Computing Environment” [4])  I thought it was the right idea, but I haven’t seen much development in the ensuing ages.

Fulvio Corno and colleagues at Politecnico di Torino describe a system that follows this very approach.  Key elements are [1]:

  • An abstract desctiption of devices, fucntions, etc.
  • Logical rules for composing and reusing about these descriptions
  • Standard, cross-vender representation

The purpose is to have a way for computers to know when a rule applies to some ‘node’, and how to apply it, even when the node is a complete stranger.

Corno and colleagues are particularly interested in “programming by functionality”, i.e., making the right thing happen without knowing all the details in advance.

Their system includes a “Semantic Reasoning block” which “maps user-defined trigger-action rules to devices and services in the IoT Ecosystem in order to reproduce the desired behaviors.” (p. 21 )  In other words, it takes an abstract description of what is supposed to happen, and figures out a set of concrete devices and actions that will accomplish the intended goal. (This is “semantic” because the computer is deducing what is “meant” to do.)

The project uses semantic web standards because they (a) are universal and portable and (b) they define a formal logical model for the reasoning that is needed.  The former means that the rules can be vendor independent and will work anywhere, and the latter means that you can do the mapping they need to do.

A second article discusses the more general problem of “Machine to Machine” (M2M) interoperability [2]. Even absent the swarm of IoT things, there is a plethora of computers, systems, and data on the network. Getting systems to work together can be a painful process, and in principle, semantic web technology is designed to ease this process.

However, Hodges and colleagues point out that most semantic models are poorly written and unlikely to be useful for interoperability.

many of these ad hoc ontologies are information silos

This group is working to develop better semantic models based on accepted industry standards.  I.e., the semantic models describe the concepts of existing standards, as well as mapping between multiple standards.

These models have obvious advantages.  Based on accepted standards, they represent existing models, with existing audiences, and known domain applicability. In short, given the effort invested in creating, promulgating, and implementing a standard, it is worth the trouble to create a good semantic model for it.

I would also say that a good standard has a rigorous definition of conformity, so it is possible to check that a node actually implements the standard correctly. That means that it is possible to know that the semantic model can map to one or more concrete implementations.

The big news, though, is that the formal logic of the semantic web makes it possible to formally map between multiple standards, making it possible for a computer to translate.

The general idea here is to use these standards as the basis for the abstract description of the decentralized system.  The semantic web makes it possible to automatically combine and translate between descriptions from many sources.

(Another blast from the past: Hodges et al. suggest using PROV-O ontology to model the behavior of a sensor.  PROV-O is a representation of the Provenance Data Model, which I contributed to at its birth.)

It was nice to see these articles confirming that the technology I called out as important might actually be important.  The motives and general approach are pretty much exactly as I was thinking way back when.  It is great to feel like a vindicated pioneer.

On the other hand, these articles were a pleasant surprise because these technologies are not actually in use yet.  Ten years and more, and it’s still a future wonder.  “They hold the promise of interoperability in name only.” ( p. 27)

I still think this is a good approach, not least because of the principle that:

Any problem in computer science can be solved by an extra level of indirection.”  (The original source of this quote is not precisely known. Lampson et al. [3] attribute this phrase to David Wheeler, citing the authority of Roger Needham.)

I also think that the burgeoning Internet of Too Many Things will make this problem more and more pressing.  However, the IoT is currently dominated by centralized architectures managed by large vendors.  These companies are selling silos, and have little reason to provide open solutions.

  1. Fulvio Corno, Luigi De. Russis, and Alberto Monge Roffarello, A Semantic Web Approach to Simplifying Trigger-Action Programming in the IoT. Computer, 50 (11):18-24, 2017.
  2. Jack Hodges, Kimberly. García, and Steven Ray, Semantic Development and Integration of Standards for Adoption and Interoperability. Computer, 50 (11):26-36, 2017.
  3. Butler Lampson, Martin Abadi, Michael Burrows, and Edward Wobber, Authentication in Distributed Systems: Theory and Practice. ACM Transactions of Computer Systems, 10 (4):265-310, 1992.
  4. Robert E. McGrath, Semantic Infrastructure for a Ubiquitous Computing Environment, in Computer Science. 2005, University of Illinois, Urbana-Champaign: Urbana.


BeePi: Open Source Hardware

OK, I have my reservations about the Internet of Things (AKA the Internet of Way Too Many Things, or the Internet of Things That Don’t Work Right).  And I have also expressed concerns about DIY environmental sensing, which is usually long on sensing and short on validity.

But let’s combine IoT concepts with useful environmental monitoring, and validate the measurements, and I’m all for it.

Plus, I’m really worried about the bees.

So I am very interested in Vladimir Kulyukin’s BeePi, a Respberry Pi based bee hive monitor. Over the past decade, his team has developed low cost sensors and in situ data analysis that measures the sound, sight, and temperature of a bee hive. The sensors are minimally invasive, and collect data more or less continuously.

Vladimir Kulukin downloads data from a BeePi system at a honey bee hive in Logan on Monday afternoon. The USU computer science professor started a Kickstarter campaign for the device and surpassed his goal within the first two weeks. John Zsira/Herald Journal

Unlike bogus “Pigeon backpack” projects, this group has actually developed, validated, and published analytics that turn the sensor traces into potentially useful data about the behavior of bees. (E.g. see [1].)

The sound recordings can, in principle, give clues about the number and activity of the bees. At the coarsest level, they have easily documented the daily cycle of activity. I.e, they have confirmed day and night.

The visual imagery is used to detect bees entering and leaving the hive. This is an important indicator of foraging activity and overall health of the colony, and might give early warning of trouble in the hive.

The temperature measures correlate with overall activity, and abberant readings would indicate serious problems inside the colony.

The researchers aim to publish their hardware and software designs, so others can build and improve the idea. (It isn’t immediately clear what kind of licensing is intended, other than it is open source.)

In a sad sign of the times, they are doing a kickstarter to raise money ($1,000 !?) to build some more prototypes. In a sane world, funding agencies and companies would be beating down their doors trying to give them research support. And it would be many tens of thousands.

Another sign of the times is that the kickstarter is the most complete information about the project. Get a web page, guys!!

This project is pretty cool, and made me think.

As a distributed systems guy, the need for manual downloads is just too crude. A future version should have some kind of low power networking that, ideally, will automatically upload data to archives, e.g., in a cloud. A concomitant upgrade would be to beef up the data formats (they need to be documented, and would be better with standard metadata). It would be nice to have standard APIs for pushing and grabbing the data.

Bee hives tend to be scattered and far from networks, though. But perhaps a small UAV “data harvester”, might fly around, hover a couple of meters away to suck out the data through a short range link, and return to base after its rounds. Sort of “sneaker net” in the age of ubiquitous drones.  Such a drone might be useful for many environmental sensing tasks.

On the sensor front, I would think that humidity sensors would be a simple and important addition to the system. I think (but I’m not sure) that humidity is linked to some possible colony problems.

And what about lidar or sonar? The cost of lidar and sonar is crashing, so you might be able to add these to the sensors. Combined with the imagery, this would give even better bee counts (and in all weather, assuming the bees are active in all weather, which I’m not sure about).

Finally, I would suggest that the creators define how they want to share their system and data from it. Creative commons would be a place to look for ideas. <<link>> I would think that the plans and software might be shared through some existing maker community archive. E.g., Instructables, SparkFun, or AdaFruit would be plausible possibilities.  (Call me.)

This is a good example of low cost environmental sensing.  They are doing the hard work of validating the measurements.

There is a lot of work that could be done to make this a slicker and easier to use open source project. Documentation, publishing the design, and setting up a data archive are pretty straightforward, but would make a huge difference.  (Call me.)

  1. Vladimir Kulyukin and Sai Kiran Reka, A Computer Vision Algorithm for Omnidirectional Bee Counting at Langstroth Beehive Entrance, in nternational Conference on Image Processing, Computer Vision, and Pattern Recognition (IPCV’16). 2016: Las Vegas. p. 229-235.
  2. John Zsiray, USU professor hopes ‘BeePi’ hive sensors will help honeybees, in The Herald Journal – 2017.

Airgap, Smairgap

For many years, computers have been secured by keeping them off the Internet. This is called an “air gap”, which refers to the physical separation of the device from the outside world. (With wireless networks, an air gap isn’t a literal open space, obviously.)

For as long as I can remember (since the 1980’s at least), we’ve been taught not to rely on air gaps. They are necessary but hardly sufficient to protect your system.

The most common way to bridge an air gap is probably through human actions, either human error or espionage.

But there are more and more cool ways to covertly connect to devices (scanners, microphones, and so on) and the potential effects are massive.

This month saw reports of two more interesting attacks on so-call Internet of Things devices.

A research group at Ben Gurion University have demonstrated that you can hack into a network via security cameras. Guri,  Bykhovsky, and  Elovici showed that a camera can be infected with malware that lets attackers send commands and receive data via IR [1].

The signals hidden in the video stream are then intercepted and decoded by the malware residing in the network.

This attack takes advantage of two essential features of the security camera.

First, the attack can work because, by design, these cameras are connected to the internal network, and look outside the network. Like a network firewall and other network border guards, they are especially vulnerable because they must operate across the “airgap”.

Second, the attack works via the infrared (IR) capabilities of the security camera used for night vision, but are difficult for humans to detect. This makes the hidden signals stealthy and difficult to block: defenders cannot simply filter out all IR signals, because that would eliminate the night vision essential to the purpose of the camera.

(By the way, the Guri et al. paper [1] reviews the extensive literature of methods to covertly bridge an air gap.)

While we’re on the topic of hacking into your network, a research group at Weizman Institute of Technology have demonstrated yet another way to hack into network enabled LED light bulbs [2]. Actually, there have been many reported ways to take over IoT capable LED lights and similar devices.

However, the Ronen et al. paper demonstrates how to install a worm which takes over all the light bulbs, creating a captive network of thousands of devices.

The attack can start by plugging in a single infected bulb anywhere in the city, and then catastrophically spread everywhere within minutes.

This can allow the intruder to disable all the devices, or possibly to employ them as a bot net for a DDOS attack.


The particular attack exploited a bug in the standard ZigBee protocols, and a method to snatch passwords. They were able to take over and reprogram the firmware of the light bulb. That’s right, you new light bulb has network protocols and passwords that need to be protected. Sigh.

Once compromised, a LED was able to infect nearby LEDs via its onboard network software (i.e., the suborned firmware). Depending on the number and density of lights, this could easily spread to a whole city within minutes.

Aside from the one-of-a-kind bug and side channel attack (which there will surely be many more in the future), the attack exploits the fact that these devices are controlled via a dedicated low power wireless link with a standard protocol. This network is separate from the Internet or TCP/IP local networks, but it also is not protected by the network security on those networks. The network of LEDs is essentially unmonitored and difficult to monitor if you wanted to try. This makes it possible for a worm to spread without detection or counteraction.

The attack also takes advantage of the capability to update the firmware via this network. This feature is almost certainly necessary, given that there are zillions of light bulbs, deployed in inaccessible places, and the devices don’t have human sysadmins to supervise updates. There is little choice but to push updates through the network. But, as Ronen and colleagues show, this process is vulnerable to attack.

I should note in passing that these devices are designed to be reasonably secure. The network communications are designed to only talk to nearby, presumably trusted, neighbors. And the only way to program them is by a corrupt update. The reported attack subverted both these protections, which goes to show you that it isn’t wise to be overly confident in such confidence building features.

This all would be funny if it weren’t so serious.

I continue to be astonished at the pace at which so-called Internet of Things IoT are deployed, despite the utter lack of compelling use cases, and the totally-not-ready-yet-ness of the technology.

Why do I need an internet connected light bulb?  You got me.

I would like to “just say no” to these things, but that is becoming impossible. Can I buy a new car that isn’t a rolling computer network, complete with Internet and satellite uplink?  I don’t think I can.

And, as these and many other studies show, these systems are like any other distributed computing system.  No matter how well designed and implemented, they are still going to be hacked.  And the consequences will be gigantic.

  1. Mordechai Guri, Dima Bykhovsky, and Yuval Elovici, aIR-Jumper: Covert Air-Gap Exfiltration/Infiltration via Security Cameras & Infrared (IR). arXiv arXiv:1709.05742 [cs.CR], 2017.
  2. Eyal Ronen, Adi Shamir, Achi-Or Weingarten, and Colin O’Flynn, IoT Goes Nuclear: Creating a ZigBee Chain Reaction, in IEEE Symposium on Security and Privacy (SP), San Jose, CA, 2017, pp. 195-212. 2017. p. 195-212.