Securing your IoT device: a growing concern

Homepage 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:

The fish tank had sensors connected to a PC that regulated the temperature, food and cleanliness of the tank.

“Somebody got into the fish tank and used it to move around into other areas (of the network) and sent out data,” said Justin Fier, Darktrace’s director of cyber intelligence…

The report said 10 GB of data were sent out to a device in Finland.

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 go down or fall 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 and embedded 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 hard coded 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, often times 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 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 of 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.

Three Concepts to Watch in IoT Device Security

Intrusion Detection Systems

 Since the early 1980s software applications have been developed to monitor networks for malicious activities. This early security work has inspired companies to adapt these tools to detect rogue IoT devices in real time in network traffic. These are known as Intrusion Detection Systems, often represented with the acronym IDS. Should a pattern of a device move out of a certain predefined range, the IDS agent will automatically trigger an alarm. The alarm, in turn, can be used to disable the rogue device.

Installing an IDS is relatively straightforward. To begin with, the tool needs to be installed directly onto a server. Next, control of the different router/switches that the network infrastructure consists of should be set using a software definition network.

An alternative approach would be to directly implement the IDS on an edge node, router, or switch located in between the IoT device and the rest of the network infrastructure. The benefit of this approach is in the reactivity – in just a couple of milliseconds the IDS would be able to disconnect a detected rogue IoT device from the network.

A final approach to integrating the IDS is to use it on new devices. While it is clear that it is impossible to completely protect a device from all actors, it can be interesting to integrating a watchdog that will control the network, log kernel crashes and program executions. While there are implications for battery power, it is increasingly an approach that is proving attractive to security conscious device owners.


Blockchain for IoT devices is, to turn a popular phrase, something like sex for teenagers: everybody seems to talk about it, but nobody has really done anything about it. Yet there is considerable ‘heat’ around the concept of the blockchain, and with good reason: it offers the potential to provide trust between ‘strangers’ without the help of a third party.

The blockchain offers an immutable history of all transactions and interactions and shares this history of transactions between all the nodes in the network. The blockchain ledger is immutable, and ‘fake’ entries are impossible to validate.

Adopting a blockchain enables a communication between nodes with a validation completed by the users of the network itself. The proof of work creates a relations of trust between the users which is incentivized and their record of all of the transactions cannot be changed. There is always the possibility of small networks being overwhelmed by a 51% attack, yet a network of hundreds of thousands of devices – something that is not uncommon in the IoT world – this is not a significant challenge. Blockchains make ‘man in the middle’ attacks impossible and the ledger is impossible to tamper with as it would mean modifying all of the blocks in the chain from its beginning.


A key concept in cybersecurity is to reduce the attack surface. As a result, when a device with a high level of security is required, it is important to make sure that – besides the application on the device – the bare minimum of software is running on the device. However, when using an operating system like Linux or Android, removing unused services might be extremely challenging because everything is – for want of a better word – tangled, and removing something that is not used by the application might break the rest of the operating system.

Imagine, though, if it might be possible to isolate the application in a ‘box’ with just what is required to run it. While this sounds like containerization, there is another approach called UniKernel which might provide a new and better answer.

A UniKernel consists of the application, the environment needed to run it, and nothing else. It’s the ultimate in a minimal OS with only the dependencies needed for your application. While it is not a perfect system – there are issues with the drivers for the OS and in how to reuse existing code – and it does mean redeveloping existing software to run on top of a UniKernel, there is still some interest among IoT device developers.

As a conclusion, it’s impossible for any modern OS to entirely bug free and just as impossible to secure a device against every imaginable attack. However, by considering the various attack vectors and attack surfaces, it is possible to make the cost of a bad actor hacking your IoT device to be too high for the likely benefit they could receive by overwhelming your network or stealing your data.

IoT device owners adopting a secure by design mentality need to think about the different risks they are protecting against (financial, physical, and reputational), the different types of attack that need to be blocked (communication, software, and hardware), and the emerging strategies for protecting IoT networks (intrusion detection systems, the blockchain, and UniKernel).

No matter the strategy selected, however, IoT device security by design needs to be top of mind for developers, owners, operators, and users alike. In a world of bad actors, security can never be ignored.

You might also like...
Cedric Vincent - Chief Technical Officer
11 May 2021