Securing your IoT device: a growing concern

How MacGyver Triggered a Reflection on IoT Device Security

When I was younger, I used to love watching MacGyver.

Back then Richard Dean Anderson’s Angus ‘Mac’ MacGyver was about the coolest guy on TV: he’d get himself into all sorts of dire circumstances, only to figure out a way to survive and bust the bad guys with little more than a pocketknife, a roll of duct tape, and a little basic engineering know-how.

In one episode he was tasked with opening a casino vault but had nothing on hand save for a couple of glasses and a bottle of wine. With a little ingenuity and with the knowledge that the vault could be cracked open with a series of different frequency sounds, the vault door was quickly sprung open.

Three decades later, would it be possible for MacGyver to crack casino security with not much more than a computer and a fish tank?

The answer, perhaps surprisingly, is yes – and this time you wouldn’t see him do it on a fictional series, you’d read about it in your daily news.

As the Washington Post reported in 2017:

Two casino security hacks, but with three key differences.

First, one was fictional while the other was a real-life loss – but perhaps you would be hard-pressed to guess which was which?

Second, the goal of opening the vault in MacGyver was to free the valuable loot from the casino. The fish-tank hack, though, was about freeing the casino of something even more valuable: its data.

Third, MacGyver needed to be at the casino vault door to succeed in his break-in. The fish-tank hackers were not only outside the casino doors, but they also weren’t even in the same country.

In a world where the most valuable currency is data and where every connected device is a potential attack target, IoT device security needs to be top of mind for every device owner and operator.

In this article, I’ll lay out the sorts of threats that should be defended against and the ways in which you can protect your devices and networks from the digital MacGyver’s of the twenty-first century, starting with security by design.

Three Reasons to Think Secure by Design

There are three kinds of risks that every IoT device security professional needs to be concerned about:

1. Financial Risk. There is a risk that you could face significant costs – direct and indirect – from a bad actor exploiting an insecure system. Whether it is an actual casino vault falling victim to a hack or a customer that relies on your connected devices to secure their facilities, there’s a real risk of financial loss should your IoT device security come under attack.
2. Physical Risk. IoT devices today control gates, doors, and the physical security of thousands of workers. Should your IoT device security be compromised, and your device goes down or falls under the control of a bad actor, the physical and personal security of individuals might be at risk.
3. Reputational Risk. The public disclosure of any IoT device security breach is bound to impact your professional and corporate reputation. It’s sometimes difficult to quantify but the impact of a breach on a company’s reputation is real, and it can be expensive. If your firm earns a reputation as an easily breached vendor, there’s little light at the end of that tunnel.

Of course, no business is risk-free and there are different levels of acceptable risk for finance, physical security, and reputation. The goal, then, is to invest in sufficient IoT device security by design to deter bad actors while understanding that no connected network can ever be 100% safe. This cost/benefit analysis is one of the first essential steps in any IoT security strategy, and the costs and benefits will depend on the type of attack you are preparing to deter.

Three Types of Attacks on IoT Devices

Just as there are three kinds of IoT device security risks to consider, there are three types of attacks that every IoT operator needs to consider.

Communication Attacks on IoT Devices

Communication attacks focus on exploiting communication ports on IoT devices.

• The 2016 Mirai Botnet

In 2016, for example, a massive internet outage was produced by a botnet named Mirai. Mirai targeted a specific camera brand, more than 500,000 of which were connected to the internet with their SSH port open. What’s more, the root account of the camera was protected with a password hardcoded into the device and set to the word ‘root’. Essentially, this made each camera a virtual sitting duck for the Mirai botnet.

• Unencrypted MQTT Communications

IoT devices are constantly connected and communicating with the cloud, with a base, and with each other. While those communications should be encrypted, oftentimes they are not. Indeed, in 2015 one researcher found that he could access the unencrypted information from hundreds of thousands of devices around the world by scanning Port 1833, the unencrypted port for MQTT.

• Password Problems

Most IoT devices come equipped with generic accounts and those accounts with credentials and passwords. As the Mirai Botnet attack proved, oftentimes these IoT device security passwords are easily guessed and even more easily exploited. While best practice is to make a product unusable until the end-user changes that generic password, many devices ship without even such elemental precautions.

Protecting from communication attacks is a matter of securing the ports and denying access to surfaces that attackers might use to breach devices.

Secure by Design to Avoid Software Attacks

Software attacks focus on getting access to a device, either remotely or locally, and executing software on that device. Protecting against such attacks can involve a number of different strategies, including:

• Root of Trust

A common attack vector for bad actors is pushing a false update or tampering with a true update to the embedded software on a device. Protecting against this threat is best achieved by embedding a root of trust in the product.

A root of trust means that, from the very first later of software (the root layer), each layer verifies the signature of the next layer that will load in the memory before it starts executing. An encryption key makes this root of trust possible, but it does come with its own problem: where should the key be stored, and how can we be sure that the key has not been tampered with?

NXP offers an elegant solution to this question of IoT device security which consists of fusing the hash of the public key into their i.MX family of microcontrollers. Because of this, when the ROM code loads the public key, it verifies the hash and verifies that it matches the value that has been fused in the processor. As it is impossible to tamper with the eFuse of the processor, the only software that will ever be executed on the processor is that which is signed with the right private key.

• Block Layer Encryption

While a root of trust ensures that software on the product cannot be tampered with. Yet validating a complete filesystem, in the same way, would be far too time-consuming, yet again there is a secure solution. A tool like DM-Verify uses a Merkel tree to make the whole process faster in much the same way as a blockchain works for a cryptocurrency. There’s a limitation, though: the file system needs to be in read-only mode, and hence an alternative is to use DM-Crypt which encrypts the filesystem as a block level.

There are two significant advantages to this approach: first, the filesystem can still be modified during runtime, and second, the data at rest cannot be accessed.

This second advantage has an interesting and positive side effect of its own: if someone physically takes control of the device and unsolders the chip used to store the software from the IoT device board in an effort to access the data, it will be all but impossible to do so.

Yet the issue of secure storage of the key used for encryption remains.

For IoT devices that use a processor from the i.MX family, there is the option to use a black key. The black key is a secret key derived from a secret root key that is unique to each i.MX processor. The key is never accessible from the OS in a readable format and is, as such, incredibly secure.

Hardware Attacks on IoT Devices

Hardware attacks bypass network ports and software weaknesses and instead target the physical components of the device itself. Protecting against such attacks is getting a whole lot closer to the practical engineering of MacGyver.

Debugging code on a commercial version of a product is convenient but should be disabled. Most processors have a fuse that can be burnt to disable access to the JTAG interface.

Critical buses should also be routed within the internal layers of your PCB. While it might still be possible to x-ray the device, map the internal layers, and drill into the PCB, the cost/benefit analysis of such an attack is not positive for the bad actor.

Tamper protections should be stock standard and some processors include sensors that can detect a hacker trying to tamper with hardware. For example, the sensor could trigger a signal when a device is opened or tampered with that would zero all of the cryptographic keys in the RAM.

Finally, you could take action to drown a board in epoxy or use specialized screws to avoid physical tampering with your hardware. This won’t assuage all bad actors, of course, but again the cost/benefit analysis is in favor of the manufacturer over a bad actor tasked with tampering with a device.