Published on Oct 02, 2016
Today, security in one form or another is a requirement for an increasing number of embedded systems, ranging from low-end systems such as PDA's(Personal Digital Assistants), wireless handsets, networked sensors, and smart cards, to high-end systems such as routers, gateways, firewalls, storage servers, and web servers.
Technological advances that have spurred the development of these electronic systems have also ushered in seemingly parallel trends in the sophistication of security attacks. It has been observed that the cost of insecurity in electronic systems can be very high.
In an increasing number of distributed embedded applications the individual nodes must communicate with each other over insecure channels like e.g. the public Internet or via wireless communication links. Internet connections expose applications to intrusions and malicious attacks. Unfortunately, security techniques developed for enterprise and desktop computing might not satisfy embedded application requirements because of the following reasons which will be explained in detail later.
1) Cost sensitivity
2) Interactive matters
3) Energy constraints
4) Development environment
Embedded systems cover a large range of computer systems from ultra small computer-based devices to large systems monitoring and controlling complex processes. IEEE has the following definition for embedded systems:
A computer system that is part of a larger system and performs some of the requirements of that system; for example, a computer system used in an aircraft or rapid transit system. (IEEE, 1992).
Most of such embedded systems can also be characterized as real-time systems, (i.e., systems in which the correctness of the system depends not only on the logical result of the computations it performs but also on time factors). Embedded real-time systems contain a computer as a part of a larger system and interact directly with external devices. They must usually meet stringent specifications for safety, reliability, limited hardware capacity etc. The increased complexity of embedded real-time systems leads to increasing demands with respect to requirements engineering, high-level design, early error detection, productivity, integration, verification and maintenance.
In many cases embedded systems are safety or mission critical systems and hence the demands on reliability, robustness, availability and other characteristics of dependable systems are important.
The most important requirements of an embedded system are:
> Real-time properties: The real-time system functions are time-related; a violation of time requirements even of a proper functional response violates the system functionality.
> Dependability: Dependability is defined as an ability of a system to deliver service that can justifiably be trusted and an ability of a system to avoid failures that are more severe and frequent than is acceptable to the users. The main means to attain dependability are related to avoidance of faults. Dependability is characterized by several attributes such as reliability, availability, integrity, safety, confidentiality and maintainability.
> Resource consumption: Many embedded systems have strong requirements for low and controlled consumption of different resources. The reasons may be the size of the systems and/or the demands on lower production costs.
> Life cycle properties: In general embedded systems are tightly coupled with their environment and the absence of their services can have large consequences on the environment. In many domains the embedded systems have very long life time running round the clock year after year. During the lifetime of a system several generations of hardware and software technologies can be used. The long life systems must be able to cope with these changes introduced either into the surrounding environment or into the systems themselves.
Internet connections expose applications to intrusions and malicious attacks. Unfortunately, security techniques developed for enterprise and desktop computing might not satisfy embedded application requirements.
Embedded systems are often highly cost sensitive—even five cents can make a big difference when building millions of units per year. For this reason, most CPUs manufactured worldwide use 4- and 8-bit processors, which have limited room for security overhead. Many 8-bit microcontrollers, for example, can't store a big cryptographic key. This can make best practices from the enterprise world too expensive to be practical in embedded applications. Cutting corners on security to reduce hardware costs can give a competitor a market advantage for price-sensitive products. And if there is no quantitative measure of security before a product is deployed, who is to say how much to spend on it?
Many embedded systems interact with the real world. A security breach thus can result in physical side effects, including property damage, personal injury, and even death. Backing out financial transactions can repair some enterprise security breaches, but reversing a car crash isn't possible .Unlike transaction-oriented enterprise computing, embedded systems often perform periodic computations to run control loops with real-time deadlines. When a delay of only a fraction of a second can cause a loss of control-loop stability, systems become vulnerable to attacks designed to disrupt system timing .
Embedded systems often have significant energy constraints, and many are battery powered. Some embedded systems can get a fresh battery charge daily, but others must last months or years on a single battery. By seeking to drain the battery, an attacker can cause system failure even when breaking into the system is impossible. This vulnerability is critical, for example, in battery-powered devices that use power-hungry wireless communication.
Many embedded systems are created by small development teams or even lone engineers. Organizations that write only a few kilobytes of code per year usually can’t afford a security specialist and often don't realize they need one. However, even seemingly trivial programs may need to provide some level of security assurance. Until standard development practice includes rigorous security analysis, developers may overlook even the solutions already available.
Because embedded systems can effect changes in the physical world, the consequences of exploiting their security vulnerabilities can go beyond mere annoyance to significant societal disruption. Let's dispense with the most obvious potential attack first. Attackers that break into a computer and get complete control of it can do anything they want with the attached sensors and actuators—send commands to traffic lights, shut down power stations, and so on. We could argue that industrial-strength security approaches will take care of the really big systems, but smaller systems are less likely to receive lavish attention .Consider, for example, the household thermostat, which controls heating and cooling.
Many have an embedded computer that adjusts the set point a few times each day to keep the house comfortable when people are present and to save energy when they aren’t. Some thermostats let a homeowner use the Internet, perhaps via cell phone, to communicate imminent arrival home after a vacation or a day at work. This gives the thermostat time to reach a comfortable temperature before the owner actually arrives. However, allowing Internet control of a thermostat gives rise to several potential attacks.
If the system permits transition only between a pair of "comfort" and "saver" set points, an attacker could send false "I'm coming home" messages to change set points and waste energy. If it permits arbitrarily changing set points, the attacker could subject the house to extremes of heat and cold or even turn off the system, causing pipes to freeze in the winter and pets to die of heat in the summer. Centralized control for a power-saving scheme can create even more serious problems. Attacks that successfully break into the central control computer for set point commands, or even just spoof commands, can attempt to coordinate power consumption among many homes.
For example, someone might trick a number of thermostats into thinking that it is not a peak day, thereby increasing demand. If done on a broad enough scale, this could cause power-grid failure, especially if the electricity provider has factored the ability to change set points into its plan for sizing its generating capacity.