The number of IoT devices connected to the internet are increasing rapidly and is expected to reach 75.44 billion by the end of 2025, which clearly states a fivefold increase within a decade. IoT devices are expected to become the major target for malware attacks. Even in 2019, of the overall cyber-attacks, it is estimated that IoT related breaches is about 26%.

Ranging from automobiles, medical implants to casinos – IoT related attacks have become prominent and it is essential to incorporate security features within IoT devices to help lower the increasing menace.

This blog covers a few steps that can be employed in Securing Embedded Firmware for IoT Applications at a high level. While these guidelines help you understand the overall picture, it is also necessary to analyze the threats that are specific to your product and integrate them with due diligence. Some of the considerations discussed here include

• Securing Boot Firmware
• Secure firmware update
• Secure data storage
• IoT Product Physical Security

Securing Boot Firmware

The First and foremost step in securing the firmware is to protect the processor which is the heart of the system. Almost all the modern variants of the MCUs/MPUs etc., are equipped with features that are specific to security such as HAB (high assurance boot) and TPM (Trusted Platform Module). In some cases, the processor offers a Secure Boot mechanism in which it validates the sanity of the boot code before it starts executing it.

Some silicon vendors provide mechanisms where the hash of the boot code can be stored in a One Time Programmable (OTP) memory. Once the boot code is prepared, the hash is created and stored in these flashes. Upon bootup, the processor reads the complete boot code, calculates the hash and compares it with the pre-programmed value. Only if there is a match, the code will be executed.

On a more powerful system, it is possible to encrypt the hashes with a private key. The public keys can be programmed along with the boot code. The system calculates the hash and compares it with the hash that was decrypted with the public key. To authenticate the veracity of the public key, its hash is stored in the OTP flashes.

On simpler devices, when the reprogramming of boot code is envisaged, microcontrollers offer a mechanism that tend to blow fuses that will permanently lockout the code area in flash and prevent it from further writes and reads by external sources. Such mechanisms lock out the binaries and increase the security as it is difficult to reverse engineer the firmware and identify potential weaknesses.

Once the boot code is authenticated by the system, it validates the next level of firmware/applications by maintaining the chain of trust.

Secure Firmware Update

In many cases, during the life cycle of a product, it is required to update the firmware for specific reasons like: adding new features, fixing defects in the present release etc., Such products offer secure firmware update feature where by the new firmware can be sent to the device either remotely Over The Air (OTA) or physically using memory cards. Before usage, the firmware is must be authenticated and updated in a fail-safe manner.

Modern firmware typically take advantage of asymmetric cryptographic algorithms with the private keys stored securely at the vendor facility. The public key is stored usually in a secured location within the end-product. The firmware to be updated will be signed by the private key and shared over the internet in a secured manner. The device validates the downloaded image with the public key that is available with itself.

While the above mechanism only validates the authenticity of the image, sometimes it is also essential to protect the firmware against reverse engineering. In such scenarios, the whole image is encrypted with the help of the private key. Only the end device will be able to decrypt it and program itself.

When such designs tend to improve security, it is of prime necessity to consider the flexibility of the update process as well. For example, if there is a security breach at the server, these designs should be able to revoke the present keys and replace them with another set.

Secure Data Storage

Secure data storage emphasizes on the importance of safe guarding the data content of the end device. These devices might be collecting sensitive information that should be protected against un-authorized access. In such cases, mechanisms such as encrypting the disk drives can be used to render the disk content unusable, unless it is decrypted by the same set of keys. The key storage should be in a safe place that is protected against cyber-attacks. Cryptographic chips are also available for storing the keys in a secured manner, that even when probing at wafer level, the data cannot be retrieved. Though the cost might go up by a few tens of cents, the amount of security these devices offer is really worth it.

Across product lines, the OEM must ensure that different keys are used for each of them. In this case, even if one of the products is compromised, it will lose effect on the others.

Also, communication with external devices, if possible, must be encrypted to prevent hacking of the system easily.

IoT Product Physical Security

Securing the IoT device physically is also a major consideration that is supposed to be taken into account while improving the security outlook. They include:

Closing Debug Ports – Debug serial ports, USB drivers etc., are used during the course of development. These features should be removed in the final release to reduce the surface of attack. In boot loaders such as Linux Uboot, break-on-user-input feature must be disabled to avoid manipulation of boot images.

JTAG/SWD connectors – Debugging tools such as debuggers and emulators that come in handy during board bring up must also be prevented from access in the field.

Firewall and closing ports – Network enabled products must run at least a minimal version of firewall. Also, closing of TCP/IP/UDP ports that are not in use is highly recommended. Using non-standard port numbers add a small level of security than that of using the standard ports.

Passwords – Many Linux systems have ubiquitous passwords such as root, admin, password, root123. These login credentials must be hardened and validated before product launch.

Mechanicals – Physical product designs can also include mechanisms that prevent easy device access as well as tamper detection mechanisms.

As an English phrase states – “a chain is as strong as its weakest link”, it is essential to ensure whether all the steps in the device operation is carefully reviewed and scrutinized. Security audits can be performed to profile the effectiveness of the design. Standards such as ISO/IEC 27001 can be a base to start with. But as mentioned earlier, these are all just outlines that aid in Securing Embedded Firmware for IoT Applications. Other device specific and domain related improvements must be built over it.

About Embien:

Embien is in the field of embedded product design since a decade and has helped customers realize products with all the features needed for today’s world.

For developing a secured embedded system for your business or to perform a security audit of your present design, get in touch with our team.