There are two methods for improving IoT device security: secure partitioning and secure coding. The latter seems to have gained favor, not only for cloud software, but also for IoT device firmware. This may be because there has not been an effective firmware partitioning solution for microcontroller-based devices using memory protection units (MPUs).
We are now offering such a solution. It is embodied in our next generation RTOS, SecureSMX. This new methodology, supported by SecureSMX, enables dividing firmware into multiple, isolated partitions, such that if a cyber-criminal gains access to one partition, he cannot access data or code in other partitions. Partitioning has been used for a long time for processes in systems with memory management units (MMUs) but it has not been available for systems with only MPUs. Nor has it been available at the task rather than the process level. SecureSMX changes this.
The purpose of this paper is to present some of the advantages of secure partitioning vs. secure coding for developing secure IoT devices. However, this does not mean that both should not be used concurrently.
A “zero-day” vulnerability is one which has already been exploited before being discovered by the white hats and submitted to be fixed. Hence, fixing a zero-day and downloading firmware with the fix to an IoT device may already be too late — like closing the barn door after the horse has escaped. Malware inserted by means of the zero-day may already be hiding in the main system, waiting for a call from Central Command to go into action.
However, if the vulnerability is inside of an isolated partition, the cyber-criminal may not have been able to insert malware into the main system, and the main system may still be safe. Hence, secure partitioning provides not only an additional level of protection to systems with IoT devices, but it also can protect against zero-days yet to be discovered and fixed. Considering that the most dangerous cyber-criminals (e.g. state actors) are well-equipped with large inventories of zero-days, this is an important protection for secure IoT devices.
Living with SOUP
Software of Unknown Provenance poses yet another challenge for IoT device security. With increasing frequency, SOUP is being incorporated into embedded systems and IoT devices due to schedule pressure, lack of in-house expertise, or for other reasons. Often it is open source software that is not well-supported, well-documented, nor well-designed. Sometimes only the object code is available. In addition to these problems, chances are that no one on the IoT development team understands the package or it would not have been brought into the project, in the first place. Even if the software is well-designed and well-documented, editing code that is not well-understood is a hazardous, time-consuming adventure. Fixing a security vulnerability could well result in introducing a bug that later causes a system failure in the field.
Putting SOUP into an isolated partition offers an easier way to deal with vulnerabilities in it. By isolating the SOUP from the rest of the system, if hacker penetrates it, he is not likely to be able to go further into the system. Hence, protection is achieved without the risk of introducing a system failure due to changing the SOUP. See Ref 1 for more information on how to do this.
Problems with Secure Code Updates
The process of finding and submitting vulnerabilities, fixing them and updating code, distributing signed code updates over wire or air, authenticating device and server, then installing the updates, while good on paper has problems in practice. There are many reasons for this:
- Lack of awareness.
- Lack of training.
- Insufficient staff or resources.
- Device requires manual updates.
- Device requires replacement.
Lack of awareness of the importance of security, of course, affects any method of security improvement. However, due to the efforts of many organizations, this problem is declining.
Secure code training seems to be beset with less than optimal results (Ref 2). Some programmers seem to have difficulty applying secure coding methods. Partitioning IoT firmware can help with this problem by allowing less-talented programmers to be assigned to less-important partitions. Without isolated partitioning the best-written code is unprotected from vulnerabilities in the least well-written code — everything is in the same sandbox. With isolated partitioning, if less-secure code is penetrated by cyber-criminals, they cannot access mission critical code and data in other partitions. This gives project management a powerful tool to achieve acceptable security on a tight budget with a short schedule and using existing staff.
Many small OEMs do not have sufficient staff to keep up with all of the vulnerabilities in all of their products. Partitioning can help to prioritize IoT vulnerabilities — those in unimportant partitions can be deferred, thus allowing programmers to focus on IoT vulnerabilities in mission-critical partitions. This could be the difference between survival and failure of a small OEM company.
The last two reasons in the above list mean that more than one or two updates are unlikely during the lifetime of the IoT device. Partitioning helps, in this case, by isolating vulnerabilities, thus allowing the IoT device to function acceptably even with vulnerabilities going unfixed. Secure partitioning may be a one-time event for these products, whereas it can be incrementally improved for systems that can be updated via wire or air, thus leading to a high level of IoT device security.
For high security, developers must theoretically find every vulnerability in an IoT device, whereas black hats need only to find one or a few. Surely a gambler would bet on the black hats! Partitioning helps because it can reduce the need to fix vulnerabilities that are partitioned off. Then a cyber-criminal may find himself locked into unbreakable sandbox and thus would need to find another vulnerability. This may not level the battlefield, but it helps to make the IoT device more secure. Also the better-lock idea applies — maybe the cyber-criminal will go on to a less well-protected device and leave this one alone.
The Curse of Complexity
The vast increases in hardware and software complexity that have occurred to date are to the advantage of black hats. More complexity fosters more vulnerabilities — it is like throwing gasoline on a fire. Engineers and programmers are already severely challenged to get reliable products to market on time, let alone fix mushrooming vulnerabilities. In fact, surveys show that equipment is being shipped with known vulnerabilities, due to schedule pressures (Ref 3). For many companies, getting a product out the door is the difference between survival and bankruptcy, so it is understandable that IoT security takes a back seat, in such cases.
It is my personal opinion that our industry will not get a good handle on security until the complexities of both hardware and software are substantially reduced. Instead of components and software being designed to be jacks-of-all-trades, I think it is time to for just-enough functionality, especially for IoT devices. If we reign in excessive complexity, not only will it be easier for IoT developers to get their devices working properly, but also they will have more time for security. In view of the liability and other severe consequences of cyber-crime, those OEMs that deliver just-enough functionality with superior security will probably come to dominate their markets. I think that rich functionality with poor security is on its way out. Buyers will opt for security through simplicity.
In the meantime, secure partitioning mitigates the complexity problem by allowing poorly-understood complexity to be walled off — comparable to sweeping crumbs under the rug. Not ideal, but effective!
Building Better Designs
Partitioning has other advantages, besides security. Important among these are detecting stack and buffer overflows, wild pointers, improper accesses (e.g. executing data), and other common programming errors. Partitioning also creates a modular firmware structure, which has many benefits, one of which is well-defined interfaces between programmers. These reduce system integration problems, which often are responsible for seriously missed delivery schedules.
Although there is a learning curve for secure partitioning, as there is for secure programming, partitioning is likely to help developers to meet development schedules rather than causing them to be missed, and the final product will be more robust. Post-delivery, partitioning permits partition updates rather than full system updates, thus exposing less code to possible in-house tampering, before being signed. Also partitioning facilitates drop-in code replacements to meet differing customer requirements.
To learn more about how SecureSMX accomplishes isolated partitioning for microcontroller-based devices, see Ref. 4.
1. Ralph Moore, “What’s In Your SOUP?”, Micro Digital, Inc., Nov 12, 2021
2. “Shifting from reaction to prevention: The changing face of software security” Secure Code Warrior, July 6, 2021.
3. Mike Pittenger, “How the Columbia lawsuit could put software vendors back on the hook for security”, Black Duck Software, June 6, 2015.
4. Ralph Moore, “Achieving Device Security”, Micro Digital, Inc., Dec 32, 2021.
Copyright © 2022 Micro Digital, Inc. All rights reserved.