|
Improving IoT Device Security
by Ralph Moore
December 8, 2021
I just read a very good article, Supply Chain Security Guidance, by the staff at Finite State, Inc. This article brings home the massive impact upon embedded devices that President Biden's Executive Order on Improving the Nation's Cybersecurity will have. I think it is clear from this article that very few existing connected devices are going to meet the new security requirements without substantial rework. It looks to me like device OEMs should to get to work on this immediately.
Finite State, Inc. provides tools to test that a final system has no vulnerabilities and it also provides a tool to produce reports attesting to this for customers, such as the Federal Government. To me the first part seems like a gargantuan effort. So far, over 900 Common Weakness Enumerations (CWEs) have been identified and documented by MITRE, and the list is growing rapidly. Of these, over 400 are classified as software weaknesses. Each weakness is described in a separate document, which also discusses its impact and its likelihood, and provides examples of the weakness.
A typical new product project is composed of new firmware, legacy firmware, and third-party firmware. Whereas incorporating secure coding techniques into new firmware may not be much of a problem, it could be a big problem for legacy firmware, and an even bigger problem for third-party firmware, especially open source firmware.
Legacy code is likely to be finely tuned over generations of prior products. Adding secure coding techniques, such as checking function parameters and checking function return values may upset the apple cart. The legacy code may no longer meet critical time deadlines or it may even stop working altogether. One might think: just upgrade to a faster processor. That may entail a new hardware design and may bring in power dissipation and battery life problems, even cost problems — a serious conundrum for an OEM of any size.
The situation with third-party software is that the whole reason it was initially used was that the OEM team lacked the necessary skills or time to write it. So the OEM has a body of code that no one on the OEM team understands. Attempting to modify such code is likely to be disastrous. So the OEM must turn to the originator of the code for the security upgrade. This is not likely to be a fortuitous event — the vendor may have a different agenda or the open source author may have moved on and not be interested — at least not on the schedule of the OEM. The author may not even remember how the code works anymore! (A frequent problem I have.)
It is my belief that partitioning of connected device code will prove to be the most practical solution to the above problems and to related problems that may arise. In the case of legacy code, partitioning allows protecting it from threats originating in vulnerable partitions of the firmware. As shown in the figure below, the legacy, mission-critical code lies below the pmode barrier, which is hardware-enforced and cannot be penetrated from umode.
Hence, it is protected and thus can run in pmode, unmodified. Note that the Vault, which contains crypto keys and other secrets is similarly protected. With regard to vulnerable, third-party code, an OEM's programming team can simply partition it off from the rest of the system, as shown by Apps 1, 2, and 3. This does not require in-depth understanding of the code, as does securifying it. Principally it requires defining MPU regions that the code is restricted to access, possibly defining a task to run the code, and creating one or more portals to communicate with the code. As shown above, the same is true for middleware and its device drivers.
Partitioning is a generally accepted and proven technique for larger systems using powerful processors with memory management units (MMU). Many such systems, for example, run Linux in one partition and an RTOS in another. Arm's Platform Security Architecture (PSA) also is based upon partitioning. However, isolated partitioning has not been utilized in microcontroller-based systems using memory protection units (MPU), for lack of an RTOS that supports it. Our next generation RTOS, SecureSMX, does exactly this. It provides all of the necessary tools to achieve fully isolated partitions within reasonable development time and budget constraints.
It makes sense to incorporate SecureSMX into new designs and even legacy designs, now, before the inevitable government restrictions from the executive order come into effect. This can be done with minimal initial code change by running the entire application as a single partition under SecureSMX. Then, as security regulations come into effect, an OEM team has more options at its disposal to meet them, rather than only attempting to rewrite massive amounts of code or finding another job. For details, see the following:
- Is Your Thing In Danger?
- Where's The Gold?
- What's In Your Soup?
- Get Along Little Dogies
Ralph Moore is a graduate of Caltech. He and a partner started Micro Digital Inc. in 1975 as one of the first microprocessor design services. Now Ralph is primarily the Company RTOS innovator. He does all functions including product definition, architecture, design, coding, debugging, documenting, and assisting customers. Ralph's current focus is to improve the security of IoT and embedded devices through firmware partitioning. He believes that it is the most practical approach to achieving acceptable security for devices connected to networks and to the Cloud.
Copyright © 2021 Micro Digital, Inc. All rights reserved.
|
