Secure Operating Systems for Deeply Embedded Devices

As we add more intelligence to our embedded devices, we find that they are becoming increasingly integrated into our information technology infrastructure. Though system security is not a new concept, security-in-depth is a new paradigm developers are now starting to address.


  • Page 1 of 1
    Bookmark and Share

We read daily about security breaches of our corporate computers, our home computers, as well as many government computers. Even though these systems may have varying levels of security, they still experience unauthorized access on a routine basis. This problem will assuredly become a real threat for embedded systems as they become a more integral part of our network-centric infrastructure.

As we move more and more into the net-centric world, embedded devices will become a key portal into our Information Technology infrastructure. The embedded systems of tomorrow will need to have an operating system that will assure security. This will prove true for our military infrastructure as well as our commercial systems.

We secure our systems today in the form of login passwords and data encryption, but that is not enough. Clearly, the security available today is not robust enough. The main reason for the current level of security breaches is that there is a lack of “security-in-depth.”

We protect access at the upper levels, but not much below the application layer. Let’s face it. If the operating system itself can be hacked into, then the application above it can only be as secure as the operating system it is running on. For embedded systems, there is a real need to deploy systems that are indeed secure.

The Department of Defense (DoD) is taking embedded system security seriously. The U.S. military is moving rapidly to the “Net-Centric” warfare model. From the soldier in the battlefield to the General back at headquarters, everything and everyone will be connected together in a worldwide network. These systems will track troop movements, provide targeting information, issue battle orders, transmit top-secret information and even order meals for the troops. Given the vast range of information that these systems will be handling, they will need the capability to carry multiple levels of secure transmissions, from unclassified to top secret.

The Department of Defense and the NSA are driving the adoption of secure embedded systems. DoD Directive 8500.1 establishes a policy to achieve information assurance (IA) through the “defense-in-depth” approach that integrates the capabilities of personnel, operations and technology, and supports the evolution to network-centric warfare.

Due to this and other mandates, the DoD is pushing very rapidly to get the latest major military programs to move to embedded operating systems that meet certain levels of security as defined by the Common Criteria. Common Criteria defines seven different security levels called Evaluated Assurance Levels (EAL), ranging from one to seven, with one being the lowest level and seven being the highest level. While Common Criteria does not require the use of EALs, it is generally accepted as the best means for defining the security level of OSs. EAL-7 is equivalent to security Level A in the DoD Orange Book, the highest level of security for government systems.

Embedded software products used in these secure products have their entire systems evaluated for security. This system evaluation, however, is extremely costly. As a result, in many instances the OS is allowed to run and work in concert with other systems in what is referred to as “system high mode,” where security and information assurance responsibility is offloaded across several OSs to create a high security environment (Figure 1). This usually requires multiple sets of hardware in order to keep security separation. Designers are driving toward the goal of achieving Multiple Independent Levels of Security (MILS) on one set of hardware and a single operating system (Figure 2).

This movement is prevalent in the DoD, and companies in the private sector are starting to be held to the same security standards as U.S. Government agencies. For example, ISPs, financial institutions and power companies are being forced to evaluate their OSs and products that are part of the country’s critical security infrastructure. Recent virus attacks have demonstrated that there is a significant need for secure OSs that cannot be hacked or compromised. Security breaches costs hundreds of millions, if not billions of dollars.

With the formation of the Department of Homeland Security, it will not be long before regulations are put in place mandating that companies evaluate the security level of their embedded software products for system integrity to ensure that security cannot be compromised. Ultimately, what will be needed are operating systems that are highly secure, that will support multiple levels of security and can be evaluated to ensure that they meet the requirements.

Why has no one built a secure OS? The answer to that question depends on the level of security needed. The DoD has spent over half a billion dollars sponsoring numerous failed attempts such as ISA/AMPS, BLACKER and CANEWARE to provide a generic, readily available, secure OS that can be evaluated to the highest assurance levels used by the government. The NSA concluded that each OS encountered the same problem: each became over-utilized in addressing various security concerns.

As a result, each OS was too large and it became mathematically impossible to evaluate the design of the OS, breaking one of the basic four tenets that have been identified to assure a secure OS. Those four tenets are: Always Invoked, Non-Bypassable, Tamperproof and Verifiable. In addition, NSA experts concluded that part of the responsibility of security lies with the applications. However, if a secure OS is not available then a secure application is not achievable. To facilitate the building and evaluating of a secure OS, the NSA examined the paradigm of a Separation Kernel.

The New Paradigm—The Separation Kernel

The Separation Kernel was designed to be certified to EAL-7 and meet each of the basic four tenets. The Separation Kernel executes in system mode, provides time and space partitioning and restricts the kernel to only two main functions: Information Flow and Data Isolation. Information Flow sets restrictions on when applications are allowed to communicate and Data Isolation ensures that data cannot intentionally or accidentally infiltrate an application. If the kernel is limited to these two functions it will remain relatively small.

As a result, and given the small amount of code in the kernel, the four tenets are achievable and a secure operating system can be built. Additional kernel activities are then moved to the application space. Since applications must always use the kernel for communication outside their own partition, the security policies are Always Invoked and are Non-Bypassable.

In the Separation Kernel in Figure 3, the system services shown in red are a subset of the overall security policy, allowing them to be evaluated at the highest level of security. Since the security policies are also at the highest security level in the system, it is possible for the system to support applications of mixed security levels and allow or deny communication between differing levels of security. This is referred to as Multi Level Security (MLS).

The DoD has recognized and mandated the need for MLS in their future systems. MLS will allow the DoD to have soldiers in the field use systems that are capable of running very sensitive information and ensure that this same data is not accidentally shared with personnel who are not authorized to view it. This eliminates the need for all the embedded computers in a system to run on system high. The aviation industry currently recognizes some of these concepts in DO-178B Level A systems.

Leveraging DO-178B in a Secure OS

DO-178B is a standard used by the FAA to certify systems for flight. There are five levels ranging from Level E to Level A, depending on how the system is impacted in case of failure. For example, Level E states that no safety issues exist. Level A systems refer to catastrophic failures that will more than likely result in loss of life and aircraft. Level A systems typically include flight controls, engine controls and primary flight displays.

It is already possible to have different safety levels of applications running on a partitioning kernel that is certified to the FAA DO-178B safety standard. In addition, a COTS operating system, in this case Linux, can run in user mode inside a partition and maintain separation from the other applications (Figure 4).

The University of Idaho in 2001 and 2002 performed a study comparing DO-178B and Common Criteria and concluded that software developed to DO-178B Level A standards maps closely to EAL-4 or in some cases, EAL-5, with some additional work in the area of adding security functions to the kernel. This additional work is mandatory to satisfy objectives generally not covered by DO-178B. However, good engineering practices such as delivery mechanisms and vulnerability assessments may satisfy these requirements.

A DO-178B kernel’s space partitioning generally will solve most of the problems related to Information Flow since there is no sharing of memory between partitions. This is done to protect partitions from one another. In addition, the time partitioning used in DO-178B kernels will prevent system resources from being monopolized by a single partition, which often causes system security concerns. These two features alone meet most of the requirements needed in a secure kernel.

However, levels EAL-5, EAL-6 and EAL-7 require additional work that can be done in the required semi-formal and formal design analysis. Additional software development will be mostly in the area of Information Flow between partitions to ensure that data is isolated at the same time.

Where Do We Go from Here?

Currently, there is no COTS OS that is certifiable to level EAL-7. Consensus between the NSA and the embedded OS industry is that most of the work will be in formal methods (mathematical modeling) necessary to achieve an EAL-7 rating, provided that the kernel is kept small and only provides the minimal functionality needed to support Information Flow and Data Isolation. If developers have at their disposal a DO-178B Level A certifiable system, a large part of the work for a high assurance OS is already done.

Several DO-178B Level A certifiable real-time operating systems currently exist, including LynuxWorks’ LynxOS-178. Certified by the FAA, LynxOS-178 is a POSIX-conformant OS. With the addition of a Separation Kernel, LynxOS-178 has demonstrated EAL-7 functionality. Currently, LynxOS-178 can be easily certified to the Common Criteria EAL-5 and LynuxWorks is building on this technology to be able to deliver a real-time operating system certifiable to the Common Criteria EAL-7.

Today, our military can take advantage of COTS operating systems that can be evaluated to EAL-4 or 4+. By choosing to use only an operating system that complies with an open standard, such as POSIX, there is a path of achieving EAL-7 assurance. POSIX and/or Linux are the interfaces that developers should be using to 1) ensure low cost applications development and reuse, and 2) have a migration path to more secure systems (Figure 5).

Embedded systems developers will be required to develop secure systems. Security is not just for servers and desktop PCs, but for every device that can connect into the IT infrastructure. Using embedded OSs that are robust and secure is a critical element of security for both military and commercial systems. Developers today can use versions of DO-178B certified OSs to get to an EAL-4 level of security using an open standard POSIX or Linux interface. In the very near future, developers will have a migration path to EAL-7 security utilizing the same open interfaces. If developers today stick with open standard interfaces using a robust OS, they will have less work later when they need to move their applications to a highly secure operating system.

San Jose, CA.
(408) 979-3900.