1.1 What is Security?
1.2 What is an Embedded System?
1.3 Embedded Security Trends
1.3.1 Embedded Systems Complexity
1.3.1.1 Case Study: Embedded Linux
1.3.2 Network Connectivity
1.3.3 Reliance on Embedded Systems for Critical Infrastructure
1.3.4 Sophisticated Attackers
1.3.5 Processor Consolidation
1.4 Security Policies
1.4.1 Perfect Security
1.4.2 Confidentiality, Integrity, and Availability
1.4.3 Isolation
1.4.4 Information Flow Control
1.4.5 Physical Security Policies
1.4.6 Application-Specific Policies
1.5 Security Threats
1.5.1 Case Study: VxWorks Debug Port Vulnerability
1.6 Wrap-up
1.7 Key Points
1.8 Bibliography and Notes
1.1 What is Security?
Any book about security must start with some definition for it. If ten security professionals are asked to define the term, ten different results will be forthcoming. To attain validity for the innumerable variety of embedded systems and their functions, our brush uses a broad stroke:
Key Point
Security is the ability of an entity to protect resources for which it bears protection responsibility.
In an embedded system, this protection responsibility may apply to resources within or resources of the overall system to which the embedded system is connected or in which it is subsumed. As we discuss later in this chapter, the protective properties of a component or system are embodied in its security policy.
1.2 What is an Embedded System?
Attempts to define âembedded systemâ are also often fraught with controversy. For the purposes of this book, we define embedded system as follows:
Key Point
An embedded system is an electronic product that contains a microprocessor (one or more) and software to perform some constituent function within a larger entity.
Any definition of embedded system must be augmented with examples. We do not claim an aircraft is an embedded system, but its flight control system; traffic collision avoidance system (TCAS); communication, navigation, and surveillance system (CNS); electronic flight bag system (EFB); and even in-flight entertainment system are all examples of embedded systems within the aircraft (see Figure 1.1).
Figure 1.1 Embedded systems within modern commercial aircraft.
We do not claim the automobile is an embedded system. But its infotainment âhead-unit,â anti-lock breaking system, powertrain engine control unit, digital instrument cluster, and a plethora of other electronic subsystemsâdozens in the typical modern carâare all examples of embedded systems (see Figure 1.2).
Figure 1.2 Some embedded systems within a typical automobile.
Embedded systems are often characterized by what they are not: the antithesis of the embedded system is the desktop personal computer whose main Intel Architecture (IA)-based microprocessor powers the human interface and application environment that serves as the entityâs sole purpose. Similarly, a rack-mounted serverâs main microprocessor performs a dedicated service, such as hosting a website.
A gray area causes the aforementioned controversy. Some argue whether a smartphone is an embedded system or just a miniature desktop computer. Nevertheless, there is little debate that individual components within the phone, such as the radio with its own baseband microprocessor and software, are embedded systems. Similarly, some servers contain auxiliary daughter cards that perform health monitoring and remote management to improve overall availability. Each card contains a microprocessor and software and hence meets our definition of embedded system.
The scope of this book liberally includes smartphones whose overall security is highly dependent upon embedded hardware and software.
Of course, this book is concerned about embedded systems that are involved in some security-critical function, and some embedded systems lack security requirements altogether. This book generally does not concern itself with a standalone, battery-powered thermostat run by an 8-bit microcontroller and a few kilobytes of software programmed in assembly code. The largest security challenge in embedded systems lies in network-connected, sophisticated electronic products that are managed by an embedded operating system running significant software applications written in high-level programming languages such as C, C++, Ada, and Java.
1.3 Embedded Security Trends
The MP944, what many consider to be the worldâs first microprocessor, ran the flight control system aboard the U.S. Navyâs F-14 Tomcat fighter jet and began what has been more than 40 years of advancement in embedded systems technology. Depending on the particular analyst asked, embedded computers account for 94% to 98% of the worldâs computers. Practically every major multinational corporationâfirms such as Lockheed Martin, Exxon, General Motors, Hewlett Packard, and Johnson & Johnsonâbuilds and depends on embedded systems within its most important products. And, of course, the average consumer depends on the embedded applications within aircraft, automobiles, games, medical equipment, and so on, constantly.
At the same time, software and hardware complexity, network connectivity, and malicious attack threat continue to grow in embedded systems, which are increasingly relied upon for consumer safety and security. The smart gridâwith its smart appliances and sensors, smart meters, and network gateways (all embedded systems)âis a good example, but only one of many. The complex set of embedded systems and networks in a smart grid is shown in Figure 1.3.
Figure 1.3 Smart grid, embedded systems content, and sample network topology.
1.3.1 Embedded Systems Complexity
One of the first embedded systems within an automobile was the 1978 Cadillac Sevilleâs trip computer, run by a Motorola 6802 microprocessor with 128 bytes of RAM and two kilobytes of ROM. The printed source code could not have occupied more than a handful of pages.
In contrast, even the lowest-end automobile today contains at least a dozen microprocessors; the highest-end cars are estimated to contain approximately 100 microprocessors. With infotainment systems running sophisticated operating systems such as Microsoft Windows and Linux, the total embedded software content can easily exceed 100 million lines of code. The F-35 Joint Strike Fighterâs avionics is estimated to host approximately 6 million lines of code, driven by fly-by-wire controls, complex situational-awareness capabilities, sensor processing, and high-resolution graphical displays for the pilot. Enterprise network switches and routers routinely contain millions of lines of code for network protocol processing, management and configuration, anti-virus rate limiting, and access controls.
In short, complexity is driven by the inexorable demand for better capabilities, the digitization of manual and mechanical functions, and the interconnection of our world. While this growth in electronic content has been beneficial to society, that growth is also a key source of our security woes.
Key Point
Many of the problems relating to loss in quality, safety, and/or security in electronic products can be attributed to the growth of complexity that cannot be effectively managed.
It is well known that operational flaws, such as a buffer overflows (when software fails to validate the length of an input, permitting the input to overwrite beyond the end of an allocated memory area that is used to hold the input), are often the means by which attackers are able to circumvent system security policies. Complexity, of course, cannot be measured only by code size or transistor count.
Key Point
Linear growth in hardware/software content creates far more than linear growth in overall complexity due to an exponential increase in interactions between functions and components.
Complexity breeds flaws, and flaws can be exploited to breach system security. Controlling complexity from a security perspective is one of the foremost concerns of this book.
1.3.1.1 Case Study: Embedded Linux
To help better understand the scope of this complexity problem and motivate the information in Chapters 2 and 3 regarding software security, letâs take a closer look at the use of Linux within embedded systems. Embedded Linux has been growing in popularity due to its royalty-free licensing, open source accessibility, and wide availability of device drivers and applications. Despite having thousands of contributors worldwide, the strictly controlled change management process for Linux (especially the Linux kernel) is excellent relative to general commercial software quality standards. Steve McConnell, in his book Code Complete, estimates a software industry average of approximately 30 bugs per 1,000 lines of production code.1 Yet the Linux kernel boasts a far better track record of between 1 and 5 bugs per 10,000 lines of code.
The use of Linux in systems requiring high levels of security has been a f...