Always On, Always At Risk

Always-on devices are everywhere, and each of them is a potential target for hackers.

While many people associate always-on devices with smart speakers such as an Amazon Alexa or Google Home, or a connected security camera, that’s only one component in a system. There’s a broader infrastructure behind those devices. So even if you power down a digital assistant/smart speaker, everything it’s connected to — wirelessly or wired — usually remains fully operational. Those other pieces are connected to the Internet, either directly or indirectly, and actively moving and storing data without any human involvement.

At the end-device level, the ability to wake up automatically to key words or sounds, images, or odors stems from continuing advances of different interfaces, as well as improvements in partitioning for power. A smoke sensor in a forest or a chemical sensor in a factory, for example, can last a decade or more on a single battery due to some sophisticated low-power design.

Today, there are billions of such devices in use, and the number is growing rapidly. In December 2018, Google said it had sold 52 million Google Home devices. Several weeks later, Amazon revealed that more than 100 million Alexa-equipped devices had been sold. In China, sales of these devices are skyrocketing, as well, with Baidu, Xiaomi, and Alibaba reporting significant gains in that market.

Some of those devices are more secure than others, although definitions may vary greatly. Government regulation and standards trail far behind the technology, and it’s not always clear what constitutes a hack, what’s an invasion of privacy, or even what’s legal. One security expert recalled a conversation with friends about their vacation plans, only to find his inbox filled with advertisements for vacation packages and offers to the same destination.

While IoT devices garner the most attention because of how frequently people directly interface with them, always-on technology has deep roots in commercial technology, as well. Computers that are “off” can be programmed to wake up at loading docks, and they can be programmed to wake up on a corporate LAN for regular updates. Using similar approaches, entire fleets of cars can be updated overnight, usually with little or no human intervention.

But for always-on technology to work, it has to be connected to other devices that are always on, such as routers and modems, which in turn are connected to the Internet. All of these devices are nearly ubiquitous, and they are constantly being updated to improve throughput and take advantage of new wireless protocols and improved bandwidth options. That keeps demand high, and market saturation low. Wireless router sales reached $10.43 billion in 2020 and are expected to grow to $18.02 billion by 2021, according to ResearchandMarkets.

That rapid turnover of technology also makes it hard to work out all the bugs. “Who really has any idea what’s on the pointy end of your router — the part that’s Internet-facing?” asks Scott Best, director of anti-tamper security technology at Rambus. “I used to run some intrusion detection software on a Linux box that I had spliced between my router and modem, and it’s amazing what tries to get into your system without even trying that hard. There are software bots knocking on doors looking to see whether you left your SNMP (Simple Network Management Protocol) interface open. In some cases, somebody set up a script for this — maybe even as far back as 2001 — and it’s still running.”

The 2016 Mirai botnet attack was a very visible example of how these kinds of issues can be exploited. Despite bringing down some highly sophisticated servers, Mirai was just a surface-level attack. Rather than one always-on device, there typically are at least two or three in any network. Even for a wearable device with a tiny battery, there often is another companion device with a larger battery or plug sharing some short-range connectivity protocol such as Bluetooth.

More processors, more complications
Computer systems have been under attack since the rollout of the PC and distributed computing, but for the most part those attacks focused on software. Chip security is a relative newcomer, and until recently it was fairly straightforward to secure a chip against remote attacks with a secure perimeter. That was possible because you literally had to have a chip in your possession to figure out how to hack it, using a grinder, probe, and scanning electron microscope to understand the security schemes.

That’s no longer the case, and it’s particularly concerning when it comes to heterogeneous chip and package design, where there may be multiple customized processing elements and memories. Every processing element is capable of executing code, and nearly all of them are connected to each other and ultimately to other devices and the Internet.

“Any processor, theoretically, can represent some kind of security hole,” said George Wall, director of product marketing for Tensilica Xtensa processor IP at Cadence. “It executes code, it accesses resources, so it could be a target. Even in the case where a processor is used as a deeply embedded offload engine behind a large applications processor that has a secure island around it, hackers can still get in there, potentially download unauthorized code, and cause the offload engine to misbehave. We’re very cognizant of that.”

Regardless of how an attacker gains entry, if they can control a processing element, they can execute code to take over an entire system. And with always-on devices, this can be done at any time. Governments are especially worried about disruption of public utilities, transmission of classified data, as well as how to limit the damage from a system that has been hijacked.

“As it’s actively ‘listening’ it could be vulnerable to unauthorized code executing on it,” Wall said. “You want to make sure when it boots up, that it authenticates in a known state, that the code it is booting from is known to be good, and that it’s partitioned in a way that it can’t be caused to disrupt any of the system. Getting there is always a challenge.”

A new wrinkle
Securing an always-on system becomes even more difficult when it includes AI, which is true for an increasing number of chip designs. Two of the key reasons behind utilizing AI in electronics — optimizing systems for power or performance and the automation of controls and different functions — are the same reasons why it’s so hard to secure these devices. If something looks different, there’s almost no visibility into what caused that change.

The real challenge is with training data, which can affect millions of devices. It’s difficult to spot tiny bits of code that can cause significant changes in the behavior of the end device. Even devices that aren’t always on can be turned on and off by a compromised system.

“The training code and the training data are the crown jewels because that’s what makes the systems behave properly or behave according to the intended operations they’re supposed to conduct,” said Mike Borza, security IP architect at Synopsys. “Getting access to either of those things allows you to influence how the system behaves. It provides really interesting opportunities to plant Trojans by embedding a behavior in an AI system that people are not expecting, but which can be triggered at will by the person who invented it.”

This sleeper code is often unrecognizable, even by seasoned programmers. “You’re adjusting the connectivity, the weights between neurons, and how those neurons respond to things in their environment,” said Borza. “You need to be able to look at that and understand what it’s going to do, and that’s been a challenge. We’re looking now at ways to enhance observability and controllability, and to have these devices provide feedback about what it is and how they’re making their decisions so that you can diagnose them when they start misbehaving. It’s very easy in that kind of scenario to embed some behavior that can be triggered by the right set of inputs, or the right sequence of inputs, or the right collection of images, and produce a behavior that the adversary wants.”

Developing solutions
With security, there is no single answer to what works best, and even the best solutions may not work as well in the future. In this context, always-on circuits need to be partitioned properly so the device can’t be hijacked and remain on.

“There’s nothing magical about always-on” said Steve Hanna, distinguished engineer for Connected Secure Systems at Infineon Technologies. “However, very few devices require 99.999% uptime. Your car doesn’t. You turn it off. You do the same for a light bulb and a computer and a cell phone. And they need that down time, because if you don’t get a chance to update the firmware, then those devices become less and less secure over time. There are systems that require 99.999% uptime — like cellular access points, cloud servers, or industrial control systems — and they tend to have dual processors so they can reboot while one processor stays on. That’s the technique for maintaining high reliability. Most IoT devices don’t have that, and when they do there are features included like dual processors and redundant power supplies.”

As with all security, closing up a security hole doesn’t last forever, which is a growing problem for a different reason. As chips are increasingly used in automotive and industrial applications, as well as in data centers, OEMs are looking to extend their lifetimes. The problem from a security standpoint is that what is considered state-of-the-art security today may be relatively easy to crack 5 or 10 years later. Security needs to evolve over time, and sometimes at a different pace than the system or the software running on it. For always-on circuits, that becomes even more imperative.

“As soon as you fix something, somebody else will come in with something that’s crafty, which is what causes the zero-day approach,” said Gajinder Panesar, fellow at Siemens EDA. “One way to fix this is to provide enough data, and then analyze that data to make sure things haven’t changed. So it comes down to patterns — having something that can observe activity within a chip in a way that doesn’t affect the behavior and doesn’t leak information to some potential hacker. You need some sort of introspection infrastructure in place, and that infrastructure should be able to provide information on things like, ‘This is the sequence of transactions from this CPU to that peripheral.’ It should always be the same. ‘And when this activity is happening, this is what should happen.’ A system should be fed that this is the correct behavior, and more importantly, it should learn this is the correct behavior, especially in the case of over-the-air updates. To that end, we can observe transactions as patterns, but also create signatures in flight and use those signatures for correct behavior.”

So while it’s impossible to predict all future threats, it is possible to create an architecture that can evolve. “It goes back to defining the security architecture upfront,” said Cadence’s Wall. “What are the security goals for the product? What restrictions are going to be placed on each of these elements in the system? And you need to define what kind of monitoring or intervention is going to be put in place to either detect or correct any kind of security violation. It’s analogous to what this industry has done with memories in terms of ECC. When bits get flipped, these systems can detect and correct that. In the functional safety space, you’re establishing very clear goals for each of the processing elements in the subsystem.”

But there’s also only so far the system can protect itself. There needs to be some diligence on the part of the end user, too, as well as the companies providing updates and security patches.

“How these rollouts have happened in the past has been very undisciplined,” said John Hallman, product manager for trust and security at OneSpin Solutions. “Our culture has adopted the old approach of pushing out updates quickly and blindly accepting them and the terms that come with the updates. Nobody wants to read all the fine print and disclaimers or the release notes that come with the software or firmware update. We’ve lost the sense of discipline that catches so many of these updates as they come out, and the adversaries or attackers are just playing on that lack of discipline to be able to slip things into these updates.”

Conclusion
In the past, most people turned off their electronic devices at night, regardless of whether they were at home or in the office. But as more capabilities and interfaces have developed, more of these devices are merely powered down, with at least some circuitry left on to handle specific actions.

“There are some sensor systems that cannot reasonably be powered down,” said Rambus’ Best. “They can go into a low-power state, but definitely not a deep sleep state. When you’re booting up your car, for example, your backup camera still comes on because people shift the car into reverse before everything is set up. That system, and all the collision sensors and the heads-up display come on immediately. You don’t want the driver backing up into a wall, but you don’t care if it takes you 10 seconds to connect to Sirius radio.”

From a security standpoint, this is a risk. And as chips and systems become more complex, and as they adapt and customize, the risk of a security breach grows bigger. An always-on chip or device only compounds the risk, and as these devices proliferate, that risk continues to expand.

Related
Semiconductor Security Knowledge Center
Top Stories, Special Reports, Videos, Blogs on Semiconductor Security
Security Research Bits
New security technical papers presented at the August 21 USENIX Security Symposium.
New Security Approaches, New Threats
Techniques and technology for preventing breaches are becoming more sophisticated, but so are the attacks.
IoT Security: Confusing And Fragmented
Regulations and compliance are inconsistent and often inadequate, but adding better security boosts cost and impacts performance and power.
Design Issues For Chips Over Longer Lifetimes
Experts at the Table: Keeping systems running for decades can cause issues ranging from compatibility and completeness of updates to unexpected security holes.