Employ a secure flavor of Linux
Linux is popular for many embedded applications, but if your application requires it, make sure you put in the hooks to keep hackers out.
With the ever-increasing presence of Linux implementations in embedded devices, there's a strong demand for defining the security requirements, thereby augmenting, enhancing, and hardening the operating environment. Currently, an estimated 70% of new semiconductor devices are Linux-enabled; such a high growth rate is accompanied by inevitable security risks, hence the requirement for hardware-based trusted and secure computing environments. To provide the appropriate levels of protection, these environments are enhanced with mandatory access control (MAC) mechanisms.
Meeting the emerging but nevertheless stringent security requirements for resource-constrained embedded devices by establishing the trust-chain on hardware root of trust and deploying MAC mechanisms, requires balancing performance and control. This can be a particularly challenging task.
The line that divides embedded systems from nonembedded systems (such as general purpose and personal computers) is becoming increasingly blurred. Whether the system has an elaborate user interface or operates under a resource-constrained environment, the identifiers we've used for categorizing these systems in the past are no longer sufficient.
Fueling this transformation is the availability of more computing power at a low cost; developers and manufacturers are interested in adding more functionality to devices that were traditionally either not capable of or not expected to have this quality (such as smart phones, hand-held devices, complex medical control systems, and navigation gear). The difficulty in satisfying the security requirements of a software package is proportional to its design complexity. The default access control method in Linux, also known as discretionary access control, is at best considered "insufficient" for any security sensitive implementation, hence the increase in demand for MAC in recent years.
Hardware Assisted Security (HAS) hasn't been sufficiently standardized, and the industry still considers HAS to be in its infancy. However, HAS is one more item in the toolbox of security architects who need to provide solutions for fundamental problems such as establishing a trusted computing base using hardware-based root of trust, managing key material, and security governance of the system.
In recent years, developers are increasingly adopting Linux for use in various environments. The accelerated pace of this adoption is partially due to the Linux kernel's modular architecture, functionality, and maturity, resulting in a lower cost of ownership.
One must note, however, that this growth is accompanied by complex and elaborate software solutions built atop embedded Linux devices to address the market's increasing demands, and hence the complex security requirements of such devices. This makes implementing a holistic security strategy for Linux more challenging, especially when one considers the variety of embedded devices adopting, or planning to adopt Linux. The potential environments possess a unique set of security characteristics and requirements, and therefore, present different challenges.
Figure 1 shows a typical Linux-based architecture for a mobile phone; although basic, the complexity of this design conveys the level of challenge involved in providing a cohesive security for such an environment.
Memory footprint and performance tradeoffs are the most commonly considered constraints when designing and developing software components for an embedded device. Memory footprint is important because most embedded devices have limited memory available at run time. Any security solution for such devices must therefore have an acceptable and small memory footprint.
The performance tradeoff is important because the computing power available in an embedded device is typically low, due to hardware architecture characteristics, as well as issues pertaining to power management in battery-operated devices. Low power consumption is the main reason why the ARM architecture is so popular for such devices.
A set of guidelines should be followed to execute embedded design, keeping in mind the simplicity and modularity that's desired. The reasons behind choosing these principles are ease of use and adoption of the architecture by embedded solutions where varying levels of security are to be achieved. We've attempted to make the approach as simple as possible to ensure that no unnecessary complexity is introduced into the system and the overall security-analysis of the system is easier to perform. The modularity of the proposed architecture ensures that the approach could also be implemented on hardware architectures that lack the security capabilities introduced, and also environments where the types of attacks (or the security assets of the system) would not require the high degree of protection provided by this approach.
Secure Boot (also known as High Assurance Boot) is a technique for verifying and asserting the integrity of an executable image prior to passing the control to it. Assuming the verification mechanism is based on the digital signature of the image being verified, the reliability of this verification is at best as good as the reliability of the protection mechanism provided in the device for the public key of the image signer.
The most important assumption here is that the code that performs the integrity verification process is itself trustworthy. To assert this assumption, the implementations typically put the public key material (as well as the verification code) into non-writable areas of memory, which in turn are protected using some sort of hardware protection mechanism.
Figure 2 shows a generic Secure Boot architecture. In this approach, the first step after boot-up is to verify the integrity of the Secure Boot code itself using digital signature verification. Next, the Secure Boot code performs integrity checking of basic security parameters (such as the signers' public key), and then after that validation of system images (such as the entire kernel or individual system libraries) occurs, and finally the user-space application validation takes place. The integrity of each layer relies on the integrity of the layers underneath. At any point, if the verification fails, the system can be put in a halt-state.
This approach enables establishing the chain of trust by ensuring that the trust on each layer of the system is based on (and is only based on) the trust on the layer(s) underneath it, all the way down to the hardware security component, which serves as the "root of trust." If verification fails to succeed at any given stage, the system might be put in a suspended mode to block possible attacks.
One must note, however, that this architecture, although ensuring the integrity of the operating environment when a "hard boot" occurs, doesn't guarantee its integrity "during" the run time; that is, in case of any malicious modification to the operating environment when running, this approach won't detect it until the next hard boot occurs.
The Buffer Overflow class of attacks is practically impossible to prevent in native environments with no type- and boundary-checking available at run time. Executing native code in operating environments like Linux makes it specifically susceptible to this category of attacks. This, therefore, makes exploiting a buffer overflow attack of particular interest to hackers; mounting it is considered a badge of honor! Effective Containment in this context, is therefore referred to as a class of techniques that "contain" (as opposed to "prevent") such attacks for which there are no practical prevention mechanisms available. This could be achieved using various security technologies. Applying a MAC mechanism is one way to implement effective containment.
One method to achieve a MAC is by implementing Role-Based Access Control (RBAC). NSA's SELinux, among other features such as MLS (Multi Level Security), provides Linux with MAC through RBAC. SELinux wasn't originally designed for the ARM architecture, or for embedded devices. However, there have been previous (and reasonably successful) attempts to port SELinux or parts of it into an ARM-based embedded device.
By adding a MAC mechanism such as SELinux on top of Secure Boot, we can address one of its fundamental shortcomings--providing a level of protection at run time. " 3 shows this architecture, combining Secure Boot and MAC mechanisms. In this approach, not only have we accomplished augmenting the Secure Boot mechanism (by way of providing run-time containment), but we've also enabled a way to expose hardware-security capabilities such as the Trusted Platform Module (TPM) standard services to the applications and processes during the system run time.
As a side-note, it's important to mention that RBAC isn't the only mechanism to implement MAC. Other implementations exist that might be suited for embedded devices: Tomoyo Linux and Novel's AppArmor are examples of such solutions that implement a technology called Name-Based Access Control (NBAC). Linux Intrusion Detection System (LIDS) is another example. At the time of this writing, neither of these implementations have gained enough traction (by embedded-device manufacturers) to be the default MAC mechanism for such devices. This state, however, may change as the above-mentioned technologies mature.
The embedded industry of late is focusing on adding more computing power to embedded devices. This means not only adding more processing capabilities to each core, but also increasing the number of cores. One advantage to using multiple cores is the ability to dedicate a hardware resource for each high-level task, making it easier to manage and implement software design because the hardware is compartmentalized.
This approach has resulted in recent growth in implementing virtualization technologies in the embedded space. Various types of virtualization techniques exist (hardware- and software-based) that all provide multiple "guest domains," each assuming total access to the underlying hardware and conceptually having no awareness of the other guest domains. A fundamental element of any virtualization implementation is a layer called Hypervisor, which mediates the interactions among guest domains, providing access to underlying hardware resources to the guest domains, and providing necessary lifecycle management to each guest domain.
As is in most cases, this technique has existed in large-scale enterprise systems prior to the embedded space. As usual, the implications of this technology in resource-constrained embedded devices are different than those of the enterprise systems. The use cases, however, remain similar. Therefore, any modern design that attempts to provide a security solution for embedded applications must assume it might be contained in a virtualized guest domain.
TrustZone is a security technology introduced by ARM in its 1176 core. The technology provides a hardware-based isolation for execution environments and divides the isolation into two halves--secure and normal. The security-sensitive applications are executed in a separate memory space that isn't accessible to "normal" applications. TrustZone is the first ARM technology to provide hardware-based security in its core.
Although this could potentially provide the operating environment with an enhanced level of security, at its core this could be considered a hardware-based virtualization solution, which is conceptually not a new idea. Furthermore, and considering compartmentalized security and separation of execution environments due to applications' security requirements, "separation of concerns" have all been well understood and known concepts in computer science and software engineering for decades. This approach considers the availability of ARM TrustZone technology on the underlying hardware architecture. However no parts of this approach "rely" on this capability. The proposed architecture shown in Figure 4 addresses the security requirements discussed here.
Let's now discuss each domain's Virtual Machine (VM), which in turn arbitrates the interactions between domains and the underlying VM manager (VMM). From this point on, the integrity verification of domains happen in parallel and follows the same path as in Figure 3.
An important aspect of this architecture is the link between the domain-level access-control mechanism within the VMM, and the access-control mechanism governing each domain at run time. This link must be well-defined and implemented efficiently to allow for a viable solution.
This approach is based on a hardware root of trust to provide security as reliable as the mechanism protecting this root. The approach implements a MAC mechanism based on embedded SELinux and can do it in a virtualized environment. This approach deploys the security capabilities available in hardware (such as TrustZone) to enforce isolation among guest domains, by dedicating separate memory areas to different processes that exist in each domain.
The overall security management, such as secure Inter Process Communication (IPC) of such processes is the responsibility of the VMM, which acts as the Hypervisor. This approach enables a hardware-enforced isolation among processes running in each guest domain, with a fine-grained MAC mechanism, provided by SELinux infrastructure. The initial verification of each guest domain happens prior to bringing it up. After each domain is online, ensuring its integrity is performed by SELinux infrastructure.
It's presumable that, due to differences in security requirements during start-up and run time, not all embedded devices would require all the elements discussed here. However, this doesn't indicate a weakness in the architecture, as the main security aspects of the approach could be implemented/enabled independently (that is, these aspects are "loosely coupled").
We've examined an approach to embedded Linux security that deploys a hardware root of trust to provide secure execution of applications in a virtualized environment. We augment that approach by adding a MAC mechanism to provide enhanced protection to applications and processes at run time.
On a system which requires and implements all the capabilities provided in this architecture, a thorough analysis must be performed to ensure an appropriate security policy is in place to deploy the SELinux capabilities efficiently. An unnecessarily comprehensive and restrictive policy has the potential to hamper the overall performance and will increase the system's memory footprint.
The performance of the Hypervisor is also the key in this approach, as it's the layer that arbitrates the interactions among the processes in each guest domain. A fast and high-performing Hypervisor is the quintessential key to the successful implementation of this approach.
Jim Ready is the founder chief technical officer of MontaVista Software. With over 25 years of technical and entrepreneurial experience, Jim is a recognized authority in the embedded systems and real-time software industry. He holds a BA degree from University of Illinois at Urbana-Champaign and an MA from the University of California, Berkeley. Jim can be reached at email@example.com.
Hadi Nahari is the chief security architect at MontaVista Software. He has 14 years of experience in all aspects of software development lifecycle, including extensive work in design and architecture, verification, proof-of-concept, and implementation of software systems. Hadi can be reached at firstname.lastname@example.org.