Members can download this article in PDF format.
What you’ll learn:
- Methods to enhance security for microcontrollers.
- What questions to ask when considering a security solution.
Strong security requires a strong foundation. Before the MCU can secure the entire system, it must secure itself. While it’s vital to determine the relevant threat model and security policy for a specific product, some security solutions are very broadly applicable. Part 1 looked at a couple of the simpler solutions. Part 2 delves into other, more aggressive steps engineers can take to secure MCUs.
Keeping Things Separate: Isolation Mechanisms
The concept of isolation is new to microcontrollers. Since MCU code is often developed by a small team or even by a single engineer, it may seem pointless to protect the MCU from itself. But now that MCUs are active on the internet and applications are created from a significant amount of third-party code, that level of protection needs to be considered. Isolation mechanisms can also protect against inadvertent damage from run-away code, potentially serving as a safety feature.
The best protection mechanisms are hardware-enforced isolation. Memory protection units (MPUs) can be very effective, but they often have coverage gaps. Proprietary mechanisms such as Arm TrustZone fill many of these gaps.
One thing to watch for: How are the boundaries between the trusted and the non-trusted regions set? If they’re set in software, then malicious code could potentially alter them. The strongest solutions set these boundaries immutably, but this introduces the potential complication of requiring firmware updates to remain within a specific size.
Some questions to ask include:
- What third-party code should potentially be isolated?
- What code is so complex that it’s impossible to provide 100% test coverage?
- What assets and services do you need to protect from inadvertent or malicious alteration?
Protecting Firmware Updates: Secure Bootloader
Your product may not be as high-profile as a smartphone, but even humble devices such as connected thermostats can offer hackers a way into a targeted infrastructure. As a result, security consortiums and governments worldwide are recognizing the need to be able to update firmware in connected devices to protect against security threats. To ensure that this capability doesn’t introduce more problems, this update must be done securely.
There are multiple ways to create a secure bootloader, and as tempting as it is to create one from scratch, it’s much more efficient to leverage a trusted open-source project. Many MCU vendors even offer ports of these solutions in their software packages. Such solutions are configurable for most common use cases, and since they’re open source, you can modify them for your specific needs.
The best thing about these solutions is that you’re leveraging years of “lessons learned” from experienced firmware engineers. And the implementation is subject to inspection and review by security experts to ensure there are no hidden “back doors.”
Since the requirement for supporting firmware updates is going to be required by government legislation, the questions here are more limited. Simply, do you have an external interface over which a new firmware image can be received?
Taking Cues from Microprocessors: First-Stage Bootloader
The secure bootloader solution mentioned earlier typically focuses on ensuring that only authentic firmware updates are accepted. Many of these solutions also offer another feature—the ability to authenticate the application code prior to executing it. But what ensures that the secure bootloader itself hasn’t been corrupted?
Microprocessors solve this dilemma by using a first-stage bootloader. It’s a small amount of executable code built into the silicon that authenticates the application’s secure boot solution, which is then termed as the second-stage bootloader.
Figure 1 illustrates the secure-boot process when an isolation mechanism is also included. It’s good to note that these bootloaders can double as a safety feature, ensuring that the code hasn’t inadvertently been corrupted. One thing to watch for: It will take some time to perform an authenticity check on the code, so study the available options to find the best balance for your product.
