Securing Your IoT Product: Beware of Point Solutions

At Sensors Converge 2023, there was a surprising amount of talk about IoT security for a sensor trade show. That's an encouraging sign. Manufacturers of sensors for consumer and industrial IoT products are increasingly aware of the importance of securing sensor data to protect user privacy and safeguard critical infrastructure. What is concerning is how many security providers promote their technology as a complete security solution. These security technology providers let a manufacturer claim their IoT product is secure when the reality is quite different.

The problem is that there are many aspects of security in an IoT product. Even if a given security solution delivers on its promise, there's no way for any single solution to be a comprehensive solution. The Moddable SDK has many capabilities engineered to help secure products, but we never promote it as a one-stop security solution.

IoT product manufacturers are sincere in wanting to deliver a product that is secure, just as they want to deliver a product that is accurate, reliable, energy efficient, and cost-effective. But IoT security is relatively new, so many manufacturers of IoT products don't yet understand it well.

This article describes key layers of IoT security based on Moddable's experience creating consumer and industrial IoT products. We hope it will provide valuable guidance as you evaluate the layers of security that your IoT product needs.

Securing Firmware

The primary goal of securing your product's firmware is to make sure that it is running only the software you intend. If an attacker can replace or modify the device firmware, they can take complete control of the product. There are many initiatives, standards, and technologies to help with the different aspects of securing firmware. For the most part, products built using a microcontroller rely on the technology provided by the microcontroller manufacturer to secure the firmware. That's because only the low-level hardware has sufficient control to guarantee it. Consequently, if securing the firmware of your product is important, it should be a factor when deciding which microcontroller to use.

There are several aspects to securing the firmware of a product. Here's a quick overview:

• Signing - Signing ensures that the firmware comes from a trusted source and that its integrity has not been compromised. The manufacturer uses a cryptographically strong hash of the firmware image to sign the image. This ensures that the firmware was created by the manufacturer and has not been tampered with since being created.

• Encrypting - Encryption prevents unauthorized parties from reading the firmware image. This ensures that any secret information cannot be extracted. It also prevents reverse engineering of the firmware, which might be done to look for vulnerabilities or extract trade secrets about how the product works.

• Eliminating backdoors - Microcontrollers typically have some debugging facility, such JTAG. During development, it is common to log status information to the serial console, or even accept commands over a serial connection. These create backdoors to access sensitive information or even take control of the product. These should all be irreversibly disabled in production builds as part of the securing the firmware.

• Updating - Security vulnerabilities may be discovered after a product is installed and operating at a customer's site. IoT products need to include a way to update the firmware in the field to patch vulnerabilities. Products needs to take care only to apply updates when it is safe to do so, perhaps only with permission from the user or operator.

Controversy

Securing firmware is probably the most controversial topic in this article. Once the firmware is successfully secured, only the manufacturer can change it. That prevents product owners from adapting or improving the product for their own needs and from repairing the product themselves. These are key principles of the right to repair movement.

To address this, manufacturers may decide to offer both locked and unlocked versions of their product so customers can choose which best meets their security needs. Products may also offer managed solutions - like mobile phones allow installation of apps - for extensibility that maintains a secure firmware. The Moddable SDK does this using mods.

Securing Runtime

Securing the runtime means ensuring that the software running in the IoT product does not contain any errors that lead to security vulnerabilities. IoT products often contain a substantial amount of software, so the overall risk can be quite high.

A great deal of energy has been focused on tools to identify security vulnerabilities in code. The industry has slowly realized that it isn't practical to eliminate all vulnerabilities in large projects written in C and C++. If companies with extensive resources to secure their runtimes including Google, Apple, Amazon, and Microsoft don't always get it right, smaller organizations won't either.

As a result, attention has turned to programming languages that eliminate common vulnerabilities and can guarantee memory safety. One of these languages is JavaScript. Designed as a safe language for the web, it has been refined over two decades of real-world experience to provide a robust, secure, safe runtime environment. Everyone using the web trusts JavaScript to keep their personal information private and their online financial transactions secure.

Eliminating Common Vulnerabilities

IoT products that adopt JavaScript for the majority of their software are inherently more secure. One way to appreciate how many vulnerabilities JavaScript eliminates is to review common vulnerabilities that occur in C and C++. Common Weakness Enumeration (CWE) is a widely cited database of well-known software vulnerabilities. Here's a partial list of CWE vulnerabilities that software written in JavaScript is immune to:

• Use after free
• Expired Pointer Dereference
• Double free
• Stack buffer overflow
• Heap-based Buffer Overflow
• Buffer underflow
• Out of bounds write
• Out of bounds read
• Use of uninitialized variable
• Missing Initialization of a Variable
• Uninitialized resource (memory)
• Improper null termination (string)
• Integer Overflow or Wraparound
• Integer Overflow to Buffer Overflow
• Improper Validation of Array Index
• Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
• Signed to Unsigned Conversion Error
• Unsigned to Signed Conversion Error
• Numeric Truncation Error
• Return of Stack Variable Address
• Use of Path Manipulation Function without Maximum-sized Buffer

Good software engineers look at this list and declare they would never make those mistakes. Great software engineers look at this list and recall when they did. Mistakes happen, so choosing a language that eliminates entire classes of mistakes gives your product an advantage.

Runtime Protection

Because the mistakes documented in the CWEs are common, an industry of tools has grown to defend against them. For example, many C compilers can be configured to warn of some errors and sophisticated static analysis tools can detect others. These tools are valuable and should be part of any comprehensive effort to secure an IoT product's firmware but cannot detect every vulnerability.

However, several vendors offer tools that claim to add "runtime protection" to embedded projects "in a few clicks." These tools operate without any code changes and assert that they have almost no performance or memory impact.

Beware.

Effective runtime security comes with some cost. The most effective automatic runtime protection measures can't even be deployed on microcontrollers because they require a memory management unit (MMU), use additional RAM, and have a significant performance overhead. Such techniques work well on computers, which have plenty of resources. Still, even on a computer, they are just one layer in runtime security.

As a result, these automatic "runtime protection" solutions offered for microcontrollers are more about trying to detect catastrophic failures (native stack overflow, illegal memory access) than eliminating security vulnerabilities. Having information about such failures is useful for debugging failures in the field. However, effective attacks on the device's security and privacy will simply avoid triggering these kinds of failures, and so go undetected.

That's one reason we prefer to work in JavaScript. The language design eliminates many common vulnerabilities. JavaScript itself is a layer of runtime protection, far more comprehensive and reliable than any "one click" solution.

Securing Data at Rest

Data at rest refers to the information that an IoT product stores locally. This can be files in a file system, small key/value stores of information in preferences or non-volatile storage (NVS) store, or data stored some other way in flash memory. The data may include account credentials or access tokens, Wi-Fi access point names and passwords, data collected by the device such as sensor readings, user preferences, product configurations, and more.

Some data is more sensitive than others. As there is usually some overhead with reading and writing encrypted storage, it can be worthwhile considering whether there is data at rest that does not need to be encrypted. Still, the best practice is to encrypt whatever is practical. Some microcontrollers have encrypted storage features which can help with this. If not, software encryption is a viable option.

Tamper Resistance

Encrypting the data does not prevent it from being tampered with. An attacker could overwrite part of the encrypted data. While the attacker may not extract any information directly, they could easily corrupt the data in a way that exposes a vulnerability in the code that parses the data -- for example by invalidating a JSON file or creating an invalid UTF-8 sequence.

One basic defense is to ensure that code that reads data from secure storage is safe against invalid data of any kind. This can sometimes be difficult, though working in a memory safe language like JavaScript helps. Another approach is to store a cryptographic signature of data when writing and validate the signature when reading. The advantage of this approach is that it reliably detects unauthorized changes before the data is used. The disadvantages include taking more time to read and write, and requiring additional storage space for the signature.

Securing Data in Motion

Data in motion refers to information traveling between two different devices, such as sensor readings being transmitted from an IoT product to a cloud service or a mobile phone. Securing data in motion should guarantee that only the intended recipient can access the data and that any modification to the data in transmit is detected before the data is used. Fortunately, because securing data in motion is so critical to digital products, there are proven solutions readily available in the form of industry standards.

For moving data between devices on a TCP/IP network (Wi-Fi, Ethernet, etc) IoT products should use TLS 1.2 (or later, if available). When used with the latest recommendations, this provides excellent security of data in motion, something that would be difficult to beat with an ad-hoc solution. TLS is a complex protocol with many options, some of which impact the security of the data. Make sure to follow documented best practices for the TLS library you are using and, if you are not experienced with TLS, have your code and configuration reviewed by someone with experience to identify and correct any rookie mistakes.

Similarly, Bluetooth, BLE, LoRaWAN, and cellular (LTE, 5G) all have protocols in place to secure the data they are transporting. Use these rather than inventing a new way to secure data.

For some products, using any form of wireless communication is considered too risky or unreliable. For example, in an industrial manufacturing setting the RF noise may be so overwhelming that wireless communication is unreliable. Or even though a Wi-Fi connection may be fully encrypted, an attacker may be able to monitor the usage patterns to infer information about operation of the manufacturing facility. In these situations, wired connections are required. For cloud connections Ethernet is usually preferred; for short range communication, a serial connection.

Next Steps

Unfortunately, there isn't a simple, one-click solution to secure an IoT product. On the other hand, there are well-defined security layers that an IoT product can implement to achieve a secure result. This article describes the key layers based on Moddable's experience. As you would expect, these can all be supported using our Moddable SDK on a variety of embedded hardware platforms.

This article can only scratch the surface of IoT security. If you have questions about the information presented here or would like to talk about how the Moddable SDK can help you to deliver a secure IoT product using Embedded JavaScript, please contact us.