Embedded Systems Security - Part 1: Security requirements

David Kleidermacher and Mike Kleidermacher -February 05, 2013

Editor's Note: Embedded Systems Security aims for a comprehensive, systems view of security: hardware, platform software (such as operating systems and hypervisors), software development process, data protection protocols (both networking and storage), and cryptography. In this excerpt, the authors offer an in-depth look at the role of the operating system in secure embedded systems. In this installment, the authors offer an in-depth look at the role of the operating system in secure embedded systems. In part 2, the authors discuss how an OS provides access control for ensuring process security. In part 3, the authors examine the use of hypervisors in implementing system virtualization. In part 4, the authors review the security pitfalls and trends in embedded I/O virtualization.

Adapted from "Embedded Systems Security" by David Kleidermacher and Mike Kleidermacher (Newnes)

2.1 The Role of the Operating System
Because the operating system controls the resources (e.g., memory, CPU) of the embedded system, it has the power to prevent unauthorized use of these resources. Conversely, if the operating system fails to prevent or limit the damage resulting from unauthorized access, disaster can result. In an operating system context, unauthorized actors may refer to applications/processes, collections of applications, and/or human users that attempt to access computer resources not permitted by the system security policy.

Key Point
The operating system bears a tremendous burden in achieving safety and security.

Operating system security is not a new field of research. Yet practically all the deployed embedded operating systems are unable to meet meaningfully high levels of security certification. One of the reasons for the lack of secure operating systems is the historical approach taken to achieve security. In most cases, security is bolted on as an afterthought. However, even operating systems designed for security attempted to provide a kitchen sink of services -- protection and partitioning, device access controls, secure file systems, and secure network services. As a result, these systems were simply too large and complicated to evaluate at high levels of security.

We would all agree that it is a bad idea to trust our critical embedded systems to insecure operating systems. Unfortunately, much of the world’s computer systems used to monitor and control plants and equipment in industries such as water and waste control, energy, and oil refining are running such operating systems, the same as those running a run-of-the-mill desktop PC. As stated by Michael Vatis, executive director of the Markle Foundation’s Task Force on National Security in the Information Age, “The vulnerabilities are endemic because we have whole networks and infrastructures built on software that’s insecure. Once an outsider gains root access, he could do anything. Any given day, some new vulnerability pops up.”23

2.2 Multiple Independent Levels of Security
Recently, a small number of embedded operating system technologies have taken a new approach that attempts to divide and conquer the problem of operating system security. These operating systems adopt the Multiple Independent Levels of Security (MILS) architecture that stipulates a layered approach to security.

Key Point
The foundation of a MILS-based embedded system is the separation kernel, a small microkernel that implements a limited set of critical functional security policies, including data isolation, information flow control, damage limitation, and periods processing.

2.2.1 Information Flow
Information cannot flow between partitioned applications unless explicitly permitted by the system security policy.

2.2.2 Data Isolation
Data within partitioned applications cannot be read or modified by other applications.

2.2.3 Damage Limitation
If a bug or attack damages a partitioned application, this damage cannot spread to other applications.

2.2.4 Periods Processing
Periods processing is a policy that ensures that information within one component is not leaked into another component through resources, such as kernel-managed memory buffers and CPU registers, which may be reused across execution periods. For example, if component A stores private information in a memory page and then releases that memory page back to the operating system kernel, the kernel must ensure that the page is cleared before it can be reused by another component B requesting a memory page allocation (see Figure 2.1). Similarly, if microprocessor registers are written with data during A’s execution, the operating system must ensure that these register values are cleared when context switching to B on the same core. Without periods processing, the confidentiality of A’s information would be violated by disclosure of information to B through these computer resources.

Figure 2.1. Periods processing example: sanitization of memory prevents information leakage across security domains.

The MILS separation kernel realizes these MILS policies by using the microprocessor’s memory management hardware to prevent unauthorized access between partitions and by implementing resource allocation mechanisms that prevent one partition’s operation from affecting another (e.g., by exhausting a resource such as memory or CPU time). The information flow policy prevents unauthorized access to devices and other system resources by employing an efficient capability-based object model that supports both confinement and revocation of these capabilities when the system security policy deems it necessary. Capabilities and the associated revocation and confinement properties are discussed later in this chapter.

Next: Title-1

Loading comments...

Write a Comment

To comment please Log In