How do you keep IoT connected assets secure?

Hacking! Horrible word isn’t it, but one that we are seeing with too much frequency on our news channels. It seems that even the massive blue chip companies aren’t immune to cyber-attacks. Once the activity of the lone computer cowboy, online crime is big business and one that knows no boundaries. So, how do we protect our digital footprint to leave no trace?

IoT endpoints and gateways are perennial targets for hackers. Any connected device can expect to be attacked at some time in its life. 

Surveys suggest that probing will start looking for vulnerabilities only minutes after a new device first goes online.

Developers are challenged to design-in proper resistance to attacks against smart, connected devices. It’s a battle of “arms versus armour” that will never end. Each time defences are strengthened; attackers will immediately start looking for new opportunities to penetrate them.

Smart connected devices are potentially vulnerable when booting. If a bad hacker can influence this process by causing corrupt software to be loaded, the device may be simply bricked or taken over for various purposes. These may include revealing private data, sabotaging the owner/operator’s activities, or harnessing the device as part of a botnet to attack third parties.

Secure boot protects against this type of attack. It establishes trust in the device, which is founded on the immutability of hardware: the hardware root of trust.

Simply described, secure boot ensures that the digital signature of the first-stage bootloader matches with a key that is written into the device during production and confirmed with one-time-programmable fuses that prevent any further changes. This provides the hardware root of trust. The trusted bootloader verifies the credentials of the software loaded in the next stage of the boot process.

Each subsequent stage verifies the following stage until the entire boot sequence is complete, creating a chain of trust that’s rooted in hardware.

Secure boot protection for an application processor comprises on-chip logic as well as software libraries and a PC-based code-signing tool. NXP’s High Assurance Boot (HAB) for i.MX 8M processors (and earlier i.MX generations) enables ROM to authenticate the bootloader and kernel. The i.MX8 and i.MX8X families feature Advanced HAB (AHAB), which authenticates the bootloader, kernel, and other controller firmware to extend the chain of trust – showing how security features for IoT devices continue to evolve and become stronger.

How Does Secure Boot Work?

Generating a digital signature marks a software element as an official release by the vendor. It can be applied to various binaries: not only the bootloader, but also software such as the kernel, files/folders, and applications. Appointed staff perform sensitive processes like generating security keys, programming and burning the key in the device memory under secure conditions, and keeping root keys safe.

The code-signing tool on the host PC is used to calculate a mathematical hash of the bootloader. This hash is encrypted using a private key, producing a digital signature that is a unique file to the particular binary. This signature is attached to the bootloader and the target device is flashed. A public key is generated from the private key and stored securely on the device using one-time-programmable fuses. Once the key is stored it cannot be changed.

When the target device powers on, the bootloader software loads into memory along with the signature. HAB logic computes a hash for the bootloader binary. HAB also decrypts the digital signature using the public key to generate a hash that can be compared with the freshly computed hash of the bootloader binary. If the hashes match, the bootloader image can be trusted as authentic. This diagram illustrates the process.

How/Why is Secure Boot Effective?

Let’s consider how a hacker might try to overcome HAB. They could easily write rogue software, generate a hash, and encrypt that hash using their own rogue private key. Then, let’s say they can gain access to our device and manage to load the rogue code and digital signature.

The code and signature would match, but this is not enough to fool HAB. As the device is starting, computes a hash of the rogue bootloader binary and decrypts the rogue digital signature using the public key stored on the chip. The hash and the decrypt do not match and booting stops.

If the hacker were to discover the private key, they could digitally sign their rogue bootloader, posing as the software vendor. Then the rogue software hash and the signature decrypt calculated during boot-up would match. Although they can discover the public key by gaining access to the device, reverse engineering it to reveal the private key is mathematically impossible.

What are the Limitations of Secure Boot?

Secure boot prevents unauthorised images running on the device. This ensures that the software comes from the providing vendor/deployer and ensures that the device will operate as intended. In addition to protecting against “hijacking” and unauthorized modifications, secure boot helps detect any accidental software corruption and generally protects the vendor’s intellectual property.

Although secure boot provides effective protection when the device is particularly vulnerable, this, alone, cannot provide complete protection. It does not prevent cloning the device, for instance. And, of course, protection and processes are needed at the programming site to prevent hackers finding out the software manufacturer’s keys.

Moreover, blocking attacks on devices is just one part of a multi-faceted challenge. A comprehensive approach to security involves not only a suitable level of prevention (it is not practicable or possible to provide 100% protection for every device against every attack), but discovering quickly when a breach has occurred, minimising the consequences, and quickly covering the exposed vulnerability. Forthcoming posts will examine these in more detail.

There is no standing still; there will always be new, harsher, and more ingenious attacks, and device developers, owners, and operators must remain aware of their exploits and continuously strengthen and extend protection using the best techniques available.

If you missed the first in this security series, you can catch up here:

Resisting Security Threats with iMX8 processors

Watch our for further blogs in the series coming soon:

• Secure Networks and Cyber Attacks
• Encyption: HW and SW Engines
• Surviving physical attacks on your device