|
Where's the Gold?
by Ralph Moore
March 2024
Many Things are embedded systems to which networking has recently been added. As such, hackers coming in via the Hacker's Highway (aka the Internet) can overcome the weak defenses of such systems and gain access to critical information such as encryption keys. As a consequence, entire networks can become compromised all the way into the Cloud.
There is a solution to prevent hackers from easily breaking into your system and stealing your gold and jewels. The following is a simple, step-by-step approach to protect your new Thing, using SecureSMX®, our next generation RTOS.
Start
Figure 1 shows a typical embedded system, before adding networking. The dashed ellipses represent functional areas. Boot & Initialize functions run following power on or system reboot. They run in non-task mode. When basic initialization is completed, control is transferred to System Services, which starts the Application running in task mode. Code in all three areas runs in privileged mode (pmode).
Step 1
The first step is to set SMX_CFG_MPU = 1, which turns on the MPU, with all regions cleared, and turns on Background Region (BR). BR allows access to all memory. When basic initialization has been completed, the scheduler dispatches the idle task at maximum priority to complete initialization and turns BR off. Normally each task has its own Memory Protection Array (MPA), which is loaded into the MPU when the task starts running. In this case, all tasks use the default MPA, mpa_dflt, an example of which is shown in Figure 2a.
In Figure 2a, sys_code and sys_data are regions needed by System Services, exceptions, and interrupts. sram_block and rom_block are memory regions and IO1 and IO2 are IO regions — all needed by the application. Slots 6 and 7 are not present in mpa_dflt, because slot 6 is assumed to be unused and slot 7 is reserved for the task stack region. The latter is automatically created by smx_TaskCreate() and is loaded into MPU[7] each time a new task starts running.
Regions are defined using SecureSMX macros, for example
RGN(0 | RA("sys_data") | V, PDATARW | SRD("sys_data") | RSI("sys_data") | EN, "sys_data")
sys_data is defined as a block in the linker command file, for example [1]:
define block sys_data with size = sdsz*5/8, alignment = sdsz
{rw section .sys_bss, rw section .sys_data, rw section .sys_noinit };
Sections are defined by command lines in the project file for groups of modules, for example:
--section .data=.sys_data
Thus, defining mpa_dflt for a system is relatively simple. With these changes, the application should still run normally, except task switches will be slightly slower due to loading the MPU.
Figure 2b shows results, so far. Note the pmode Barrier and unprivileged mode (umode) above it. These are enforced by the processor. They are not attributable to the MPU, but they are coming into play soon. umode code cannot directly access anything below the pmode Barrier. So far, there is no umode code, but that's coming. The Application and System Services are now considered to be weak partitions, as shown by light solid boundaries.
Despite the small amount of changes, so far, there are some significant gains:
- Task stack overflows will be detected and cause Memory Manage Faults (MMFs).
- Attempts to execute from a task stack or any data region will cause MMFs.
- Attempts to access memory outside of the defined MPU regions will cause MMFs. This includes unused memory and Boot & Initialize memory.
Due to the above, is likely that some latent bugs will be found!
Step 2
Secure networking can now be dropped in, as shown in red and yellow in Figure 3. It consists of four partitions:
- Ethernet & TCP/IP (ETIP), which runs in umode.
- Network API & Apps (NAP), which runs in pmode.
- Security partition (SP), which runs in pmode.
- Vault partition, which is accessible only by the Security partition in pmode.
ETIP is a fully isolated partition, as shown by heavy solid boundary. It is prevented from accessing any of the partitions below the pmode Barrier, by the processor, itself. ETIP exchanges encrypted data with NAP via a tunnel portal. The tunnel portal consists of a portal buffer (pbuf) that is shared between ETIP and NAP. pbuf is a small DATARW region accessible by either ETIP or NAP, one at a time. The tunnel portal is controlled by NAP. The worst a hacker could do would be to modify the data going through the portal. However since the data is encrypted, this would be easily detected, either by the Security partition for received data or by security software in the Cloud for sent data.
ETIP is limited to making system calls via the SWI (SoftWare Interrupt) interface, which permits only a safe subset of system services to be accessed from umode. Encryption/decryption, certificates, signatures, authentication, etc. are handled by SP, and only SP is able to access the Vault, thus adding to security for keys and other secrets.
Done
This is all it takes! A hacker has numerous methods to break into an Ethernet driver or into a TCP/IP stack. However, having done so, the only data he will see is encrypted data, and the encryption key is protected by the pmode Barrier, which is hardware-enforced, so there is no getting around it. He cannot read the data, nor can he change it. His only other access to pmode is via the SWI interface. However, this allows him to do only system services that will not harm the system. The only chink in the armor is ISRs, which must run in pmode. However, these can be kept short and they can be ruggedized to resist hacking.
As time goes on, tasks in the application partition can be given their own templates with greatly reduced regions in order to improve security and safety. Many that don't use networking can be moved into umode. Boot can be replaced with Secure Boot & Update (SBUP) and an OTW/OTA update path can be added from SP to it. A firmware update would pass through the ETIP just like any other encrypted data. SP would authenticate it and pass the new code on to the new SBUP, which would install it, and then reboot the system.
No security is perfect. If the reward is large enough, a hacker will find a way to defeat any security. However, SecureSMX offers a very strong solution without requiring system redesign.
Notes
[1] This example is for Cortex-v7M processors. Regions are simpler for Cortex-v8M processors
Ralph Moore is President of Micro Digital. A graduate of Caltech, he has served many roles at Micro Digital since founding it in 1975. Currently he is lead architect and programmer for SecureSMX.
Copyright © 2021-2024 Micro Digital, Inc. All rights reserved.
smx is a registered trademark of Micro Digital Inc. smx product names are trademarks of Micro Digital, Inc.
More Solution Papers
|
