Bachelor Informatica
Multi-Objective Optimization
of Secure Embedded Systems
Architectures
Tim van Elsloo
June 7, 2016
Inf
orma
tica
—
Universiteit
v
an
Ams
terd
am
Abstract
As embedded systems attract the attention of more and more attackers, the security aspect is more important than ever during the design space exploration. Covering the security aspect in the earliest phases is necessary to design systems that are both secure and efficient. This literature study provides an overview of the current design process, various types of attacks on embedded systems and proposes a method to integrate protection mechanisms against those attacks in the earliest phases of the design space exploration.
Contents
1 Introduction 7 1.1 Scope . . . 8 1.2 Related Work . . . 8 2 Embedded Systems 11 2.1 Properties . . . 11 2.2 Applications . . . 12 2.2.1 Aviation . . . 12 2.2.2 Automotive . . . 12 2.2.3 Consumer Products . . . 12 2.3 Constraints . . . 13 2.3.1 Speed . . . 13 2.3.2 Power Efficiency . . . 13 2.3.3 Footprint . . . 14 2.3.4 Reliability . . . 14 2.3.5 Maintainability . . . 14 2.3.6 Security . . . 14 2.3.7 Utilization . . . 15 2.3.8 Production Cost . . . 15 2.4 Hardware Components . . . 15 2.4.1 Processor Units . . . 15 2.4.2 Memory . . . 16 2.4.3 Network Topology . . . 173 Design Space Exploration 19 3.1 Y-Chart . . . 19
3.1.1 Architecture Model . . . 20
3.1.2 Application Model . . . 21
3.1.3 Mapping . . . 22
3.2 Simulation . . . 22
4 Attack Vectors and Counter Measures 25 4.1 Side-Channel Attacks . . . 25
4.1.1 Power Analysis . . . 25
4.1.2 Timing Attacks . . . 26
4.1.3 Scan Attacks . . . 27
4.1.4 Differential Fault Analysis . . . 28
4.1.5 Electromagnetic Analysis . . . 28
4.2 Denial of Service . . . 28
4.3 Software Attacks . . . 29
4.3.1 Buffer Overflows . . . 29
4.4 Cryptanalysis . . . 29
4.5.1 Access Level . . . 30
4.5.2 Passivity . . . 31
4.5.3 Target Roles . . . 32
4.5.4 Evaluation . . . 32
5 Design Exploration Integration 35 5.1 Processors . . . 35
5.1.1 General Purpose Processors . . . 35
5.1.2 Secure Cryptoprocessor . . . 37 5.2 Busses . . . 37 5.3 Enclaves . . . 38 5.4 Workload Distribution . . . 38 5.5 Security Policies . . . 39 5.6 Scoring . . . 40 6 Case Study 41 6.1 Application . . . 41 6.1.1 Stream Cipher . . . 41 6.1.2 Video Decompression . . . 42 6.1.3 Operating System . . . 43
6.1.4 Inter- and intraconnection . . . 43
6.1.5 Security Policies . . . 43 6.2 Architecture . . . 44 6.3 Mapping . . . 44 6.4 Optimization . . . 45 6.4.1 Static Evaluation . . . 45 6.4.2 Dynamic Evaluation . . . 46 6.4.3 Improvements . . . 47 6.4.4 Multi-Objective Optimization . . . 47 7 Conclusions 49 7.1 Future Work . . . 49 8 Bibliography 51
CHAPTER 1
Introduction
Over the course of the past century, computer systems have become an essential part of daily life. Not only do most people own a desktop or laptop computer, or even a smartphone, we also use them when they are embedded in other products. These embedded systems are everywhere. We have digital thermostats that are connected to phones and computers through Wi-Fi and Bluetooth. We drive cars that are essentially filled with small embedded system units. Even toothbrushes are embedded systems.
When designing such systems, various objectives can be thought of. Often, power efficiency, speed and production cost make up the most important objectives. After all, these are most often associated with the quality of consumer products. Very often, it is also a requirement rather than merely an objective. Automatic transmission in cars and fly-by-wire systems in airplanes need to be real-time: even the slightest latency would be disastrous.
Many of these objectives are correlated and the designer has to make trade-offs. For example, improving performance almost always results in an increase in power consumption.
During the design space exploration, the goal is to find an optimal design for all of those features. This is called a multi-objective optimization process because there are multiple objectives that often have an adverse effect on each other.
Security is often not taken into account during the design exploration. There are several reasons for this. For starters, security cannot be easily quantified and thus cannot realistically be inte-grated in a numerical optimization. Furthermore, security actually relates to multiple objectives: integrity, authenticity, confidentiality are all aspects of security.
However, fixing security in an embedded system after it has been designed is a painstakingly difficult process because at that point, many definitive choices have already been made. Adding security components to the system afterwards has an adverse effect on the other objectives, for example the energy consumption. Since those security components were not part of the optimization process, the system in its entirety cannot be optimized.
Thus, it would be tremendously useful to find a way to integrate the security aspect in the design process itself.
This literature study starts with a broad overview of applications, components and objectives in embedded systems in chapter 2. In chapter 3, a detailed explanation of the design process and each individual step is provided. Next, a survey on all different types of attacks that embedded systems have to withstand, constitutes chapter 4. In chapter 5, we propose an approach to integrate the security aspect in embedded system design. Then we evaluate the usefulness of this integration in a case study of a digital decoder inside a tv in chapter 6. Finally, we will conclude this literature study with a few remarks in 7.
1.1
Scope
First of all, we need to define security. Security is a broad term and a particularly hard one to capture in a single definition. For one, it shares some common ground with safety even though that is an entirely different subject. For clarification, we show the difference and intersection between the two topics in fig. 1.1.
Security Safety
Attackers Nature
Wear and tear Reliability
Figure 1.1: Venn-diagram of the difference and similarity of security and safety in embedded system design.
This work will only examine the security aspect of embedded system design. This includes a part of the reliability, for example as a constraint (sec. 2.3.4) and as a weakness exposed to fault analysis (sec. 4.1.4).
This work will only consider embedded systems, although the results of this study may also be used to improve the security of any computer system design. Embedded systems are computer systems that are embedded in other products, such as cars. We will elaborate this definition in sec. 2.1 by listing a few properties that all embedded systems have in common.
Finally, this work is a literature study, which means that its primary focus is to provide a detailed overview on its topic: integration of the security aspect in embedded system design.
1.2
Related Work
Not a lot of research has been done to find generic methods to integrate the security aspect in the design space exploration. We have listed several approaches below and indicate why they differ from the approach we are taking.
[1] integrates evaluation of security protocols in the design process. For example, it rates the security of a system based on the probability of a hash collision. However, it does not cover other types of attacks, such as timing attacks and power analysis. We will use the same approach to quantify the security aspect, but apply it to a whole new range of security threats. The evaluation of security protocols is one of those (sec. 4.4).
[2] neutralizes several types of side-channel attacks by means of spatial isolation. This is a novel approach but it does not protect from power analysis, among others. In addition, we are looking for a method that integrates the security aspect in the multi-objective optimization (as an objective). Instead, this approach completely secures a system from some types of side-channel attacks, without any notion of the trade-offs. This approach is further explained in sec. 5.3. [3] defines 4 attacker capabilities and corresponding requirements that refer to the confidentiality, integrity, availability and authenticity respectively. The problem of this approach is that it is not trivial to relate types of attacks to those capabilities and requirements. Moreover, the same
problem arises as with the previous approach: since security is modelled as a requirement, we cannot optimize trade-offs.
Furthermore, there are several articles that are closely related at many points to this work but come short to covering a particular aspect. We have listed each of those articles below and indicate what aspect is not covered.
[4] provides an excellent overview of the methods used during the earliest design exploration of embedded systems. It explains in great detail the intermediate steps in the design process. The article also surveys a wide range of available benchmarks, simulation techniques, implementations and strategies. However, unfortunately it does not address the security aspect.
[5] provides an overview of the challenges and proposed solutions in secure design of embedded system architectures. The authors briefly evaluate a number of attack types but do not cover protection against these attacks. It does provide a detailed comparison of three solutions for spatial isolation.
[6] proposes a state of the art on an extensive range of attacks on embedded systems as well as a detailed technical background on the security protocols, challenges and objectives. Many of those topics are also covered in this literature study. However, this literature study will focus primarily on security during the design process, whereas the authors of [6] cover security in general. It becomes apparent that there is not much related work on combining the topics of security and the design space exploration, which is what this literature study focuses on.
CHAPTER 2
Embedded Systems
Although we mostly associate computers with desktop or laptop PCs, computers have become an integral part of almost any technical product. Computer systems that are embedded in other products, are called embedded systems. Most products that have even the slightest form of intelligence, are equipped with an embedded system inside. These products range in size from Bluetooth connected toothbrushes to airplanes.
There are some properties that all of these embedded systems have in common. We will start by listing those in sec. 2.1. Next, in sec. 2.2 we will provide three example applications of embedded systems that are heavily constrained. Then, in sec. 2.3 we will list many of those constraints and finally in sec. 2.4 we will provide detailed explanations of hardware components most often present in an embedded system architecture.
2.1
Properties
Before we look at a few applications of embedded systems, we will first list and explain several properties that all embedded systems have in common.
For starters, embedded systems are designed for a single purpose. Unlike personal computers, embedded systems can only be used for that purpose. There is an exception however, some systems, such as smart TVs and smart phones have evolved into complex multi-purpose systems. These systems can still be identified using the other two properties.
Secondly all embedded systems are designed and developed on a different system. In order to illustrate this, we take a look at personal computers again. Developers write software for personal computers on the same platform that they are targeting for their software to run on. In contrast, developers of smart phone apps and other embedded software and hardware, have to resort to a different platform (most often a desktop computer) to compile the software to run on the target platform.
Finally, embedded systems are typically heavily constrained. A large share in embedded systems is mobile powered and thus needs to satisfy strict power efficiency constraints. In sec. 2.3 we will elaborate on this with a comprehensive overview of all constraints that play a part in a successful embedded system design.
We can see that although smart TVs and smart phones do not comply with the first property, they clearly do with the last two properties.
2.2
Applications
Although individual embedded systems are designed for a single purpose, embedded systems are collectively used in many different environments. These environments are often heavily constrained, which we will discuss further in sec. 2.3. In this section, we will discuss a few illustrative applications of embedded systems and the requirements of systems designed for each application.
2.2.1
Aviation
Aircraft used to have mechanical or hydro-mechanical flight control systems. With a basic mechanical or hydro-mechanical flight control system, wings are connected to the flight controls by cables of stainless steel. Aircraft can then be controlled by pulling one of the cables. This approach has several disadvantages, the most obvious being the weight and complexity of the cables.
Concorde was the first airliner to replace the manual flight control system with a fly-by-wire system[7]. In a fly-by-wire system, the heavy stainless cables are replaced by light electronic wires that transmit signals from the cockpit to individual components on the aircraft.
Even newer aircraft, starting with the Airbus A320, have implemented a digital fly-by-wire sys-tem which is controlled by a computer. At this point, the airplane is controlled by a heavily constrained embedded system. One significant constraint of the system is its hard real-time na-ture, considering that the main advantage of mechanical flight control systems was their negligible latency.
This type of trade-offs is typical for embedded systems and requires optimization during the design exploration.
2.2.2
Automotive
Embedded systems are also heavily utilized in the automotive industry. Within a motor vehicle, these systems are called Electronic Control Units (ECUs). An average modern car consists of up to 70 ECUs[8]. There is a wide variety of constraints that each ECU within a car has to satisfy. For example, an anti-lock braking system (ABS) has to be able to respond to sensor measurements instantaneously. Failing to do so in time can potentially cause a lethal accident.
On the other hand, in-car entertainment and multimedia systems such as a stereo audio system, as well as several comfort systems such as persistent seat preferences, are not subject to these real time constraints. Instead, performance is only guaranteed to be best-effort and the design process is focused on energy efficiency.
2.2.3
Consumer Products
Embedded systems are also increasingly often incorporated in consumer products. These prod-ucts range in size from portable audio players to washing machines.
First of all we can distinguish consumer embedded systems by their power source. A large fraction of embedded systems is powered by an embedded battery. This constitutes a challenge when it comes to the power efficiency of such devices. In the best case, these devices can be recharged once or twice a day. In the worst case, they have to be able to be powered for several months without a recharge. In terms of security, battery powered devices are also at risk of being targeted by denial of service attacks.
There is one constraint in particular that all consumer products have in common. Since consumer products are often mass produced, the production costs have to be significantly low.
2.3
Constraints
A notable difference between embedded systems and traditional systems is that embedded sys-tems are heavily constrained to a particular environment, more so than general purpose comput-ers. For example, real-time systems cannot have latency, mobile phones are optimized for power efficiency and electronic toothbrushes are optimized for a small footprint with regards to its size and weight.
2.3.1
Speed
Embedded systems can both process aperiodic events, as well as real-time streams. Aperiodic events are usually emitted by the user of a system. Real-time data streams are sent by sensors in an embedded systems. For example, a navigation system for cars responds to user input for the destination address, which is entered at an irregular interval. In addition, at a predefined interval, the system also processes updates of the GPS location and heading of the car.
All tasks in a real-time system have deadlines. When its deadline cannot be fulfilled, a task is terminated by the system. This is useful because it prevents tasks from delaying subsequent tasks. We distinguish two types of real time systems[9], based on the consequences of failure to satisfy these deadlines.
• Hard real-time systems are intolerant to latency. For example, latency in industrial em-bedded control systems that move and rotate a robotic arm could result in damage to the arm and surrounding objects.
• Soft real-time systems are satisfied with best-effort delivery of data. For example, an in-flight entertainments attempts to deliver at least 30 frames per second to each screen on an airplane but failing to do so does not result in a catastrophe.
The speed of an embedded system is determined by the speed of its individual components. For example, attaching a slow memory component to a fast processor component will still result in inferior performance of the system altogether.
Performance of a system or a component usually refers to its speed. Also note that the perfor-mance of a system, in particular a real-time system, is subject to precise optimization during the design exploration. Using an architecture that is too fast, will result in a system that is often running idle and results in inefficient power consumption.
2.3.2
Power Efficiency
Many embedded systems are powered by batteries, rather than an AC power supply. In order to increase battery life, precautions have to be taken to ensure sufficient power efficiency. Power efficiency can be achieved both by optimizing the software that is ran on an embedded system, as well as by selecting optimal hardware components and an optimal mapping of the application on the architecture (sec. 3.1.3).
It can be a challenge to optimize both speed and power efficiency because both are negatively correlated.
2.3.3
Footprint
Another constraint that is particularly important with embedded systems is size and weight of their components. For example, this is one of the most important objectives in the design phase of embedded systems for aviation[7].
2.3.4
Reliability
Reliability is an important objective in nearly all embedded systems. Not only is it important that an embedded system is reliable, it is also incredibly useful to have a realistic expectation of its reliability. For example, in aviation, the reliability estimations can be used to order enough spare components.
A commonly used method to express reliability numerically is the mean-time to failure (MTTF). All components will fail eventually. The MTTF is the average time between production and a system failure. Obviously, higher means better. Note that the MTTF is only relevant with regards to the first failure. The possibility of repairing components is not reflected.
However, some embedded systems, especially those not intended for consumer markets, can be repaired when they fail. In those cases, it can be useful to express the reliability in the mean-time between failures (MTBF) instead. The MTBF is the average time between production and a system failure, and each subsequent failure.
Manufacturers of embedded system components often provide their failure expectancies on a com-ponent fact sheet. Thus, the reliability of an embedded system can be estimated and optimized by using those figures.
2.3.5
Maintainability
Maintainability refers to the possibility of updating the embedded system. Thus, in order to provide maintainability, a system needs to be flexible enough to be improved, updated and replaced after its manufacturing.
Maintainability in itself can improve the security of a system, but it can also lead to new vul-nerabilities and security concerns.
For example, many smart phones and game consoles are sandboxed by their vendors. Depending on the specific platform, that means that software that is ran on it, is controlled by the platform vendor.
Many of these devices are jailbreaked by their users to circumvent DRM on multimedia. The jailbreak is performed by replacing the vendor software that runs on the system with their own software.
However, circumventing the built-in security by jailbreak, also opens up new opportunities for malware to settle on the system. Essentially, this is what happened on desktop computers that were never sandboxed in the first place.
Thus, the flexiblity of a system can be both an advantage and a disadvantage.
2.3.6
Security
Security differs from all other constraints because it is difficult to quantify. During the embedded system design exploration, we will be using multi-objective optimization to ensure the best possible trade-off to satisfy all constraints. This optimization is numerical and incorporates all performance numbers that result from running a simulation of the system. We will discuss this
further in sec. 3. We cannot incorporate security in this optimization due to the fact that it is not trivial to express it in a single number.
The goal of this literature study is to provide an overview of all concerns related to security during the design space exploration of embedded systems and to propose a solution to express the security aspect in a number and incorporate it in the multi-objective optimization.
2.3.7
Utilization
Utilization is another important aspect of a system. The designer of a system will aim to reduce the under-utilization of a system as much as possible, in order words reduce its idle time. Optimal utilization is achieved by the multi-objective optimization during the design phase. With that optimization, the designer is looking for an optimal combination of performance, energy behavior and cost or other objectives. Utilization is directly related to all three of those objectives: under-utilization is costly both with regards to energy behavior as well as production cost. Thus optimal utilization will always be the result.
2.3.8
Production Cost
Embedded systems are applied in a wide variety of environments. Many embedded systems are designed for use in consumer products. These systems are often mass produced and thus even the slightest increase in production cost of any individual component can affect profits.
The production cost is always included in the multi-objective optimization of an embedded system design and is negatively correlated with almost all other constraints. For example, often the production cost is reduced by neglecting to implement the necessary security measures to protect a system.
2.4
Hardware Components
In order to function, at the heart of all embedded systems are one or multiple processors. A processor unit controls the system and the data flow from and to other components. Through busses, a processor is connected with memory components and often also with other types of processors, such as a digital signal processor and a floating point unit.
2.4.1
Processor Units
Processor units execute software that is installed on the embedded system. Before the processor can run the software, the software first needs to be translated to many, very simple instructions. Processors are produced by multiple brands and each brand produces multiple implementations of processors. Such an implementation is called an architecture and each architecture is opti-mized for different applications. The instruction set that is provided by the architecture varies significantly and relates directly to the area of the processor. Each instruction in the set has to be wired in the chip.
Therefore, after software is translated into simple instructions, the number of instructions is often much higher than the original software. The original software is easier to maintain and less vulnerable to bugs. This is due to the level of abstraction. When writing software developers do not have to deal with the allocation of resources. Instead, a compiler does the heavy-lifting when translating the software in bytecode that the processor can understand. One out of many ad-vantages is that developers can write software and compile it for multiple architectures. Another advantage is that the compiler can specifically optimize for a particular architecture.
There are multiple types of processors. The most commonly used processor units are General Purpose Processors (GPPs). This type of processor is not optimized for a particular purpose (hence the name) and instead is used to control and coordinate the main tasks of the system and therefore is often referred to as the Central Processing Unit (CPU). Most systems have only one CPU.
The problem with GPPs is that for very specific tasks, they are not efficient at all. Examples of those tasks are 3D graphics, audio and video processing and cryptographic processing. For each of those, we have provided a detailed explanation below.
For starters, 3D graphics are incredibly computationally intensive to render. Fortunately, many problems in 3D graphics are highly parallelizable, either by means of data or task parallelism. Data parallelism means that one task is processing multiple data elements at the same time: for example a 1-dimensional convolution. On the other hand, task parallelism means that a system can perform multiple different tasks at the same time: for example, a system can start rendering the next frame while finishing the current frame. For these problems, a Graphics Processor Unit (GPU) is used. A GPU is also often present in modern personal computers and has developed into a broadly applicable component. It can even be used to do many of the tasks within the video decompressor in our case study (sec. 6.1.2).
For audio, image and video processing, a Digital Signal Processor (DSP) is used. Applications that benefit from a dedicated DSP range from professional amplifiers in the music industry to mobile phones. DSPs are optimized for problems that relate to one-, two- or three-dimensional signals, such as audio, images and video respectively. One of the most important functions of DSPs is the Fast Fourier Transform (FFT) and its inverse. The FFT can be used for pitch estimation, pitch shifting and equalizers, to list a few. Another important feature on DSPs is convolution of signals with filters. This can be used for image effects, such as blurring, as well as edge detection, among others.
Applications that reply on encryption, will often need a secure cryptoprocessor (SCP). These include smart cards, such as SIM cards. The SCP is tamper-resistant and ensures that all operations are constant time.
Sometimes, even a CPU or a GPU is not powerful enough for a particular purpose. In those cases, an Application Specific Integrated Circuit (ASIC) can be developed. An ASIC is designed for a very specific purpose, rather than for general use. For example, ASICs that target Bitcoin mining, have been developed. These are faster than mining on CPUs and GPUs. This type of trade-off of performance against flexibility is very common in embedded systems.
However, designing an ASIC is expensive, complex and takes a long time to develop. An attrac-tive alternaattrac-tive is an Application Specific Instruction Set Processor (ASIP)[10]. An ASIP can either be implemented through an Instruction Set Architecture (similar to CPUs, as discussed in this same section) or using gate arrays, similar to a FPGA. This way, it combines the flexibility of a CPU, with the performance of an ASIC.
Many embedded system attacks target processors in general and do not distinguish the exact type of processor. However, not all processor are as valuable for an attacker. For example, a secure cryptoprocessor is bound to process very sensitive data and thus is very valuable. A GPU or DSP on the other hand, is likely not.
2.4.2
Memory
When software is loaded to an embedded system, it is stored in read-only memory. Read-only memory is non-volatile, which means that it will not decay when the system is not powered. As its name suggests, it can also not be overwritten by its user, which poses both an advantage: the software cannot easily be corrupted, as well as a disadvantage: the software cannot be upgraded. Therefore, designers of embedded systems inevitably want to store some sort of persistent soft-ware and data in the system. For this purpose, flash memory is often used.
Finally, there is one more type of memory that is worth distinguishing. Often, applications load memory from persistent storage into Random Access Memory (RAM). RAM is volatile, which means any data that is stored, is lost when it is not powered. RAM is much faster than persistent storage however.
Note that memory is not necessarily placed on a separate chip. For Systems on a Chip, the memory is actually embedded on the same chip as the processor. With regards to security, this is an improvement that we will discuss later on. However, we will still consider it a separate component.
2.4.3
Network Topology
Finally, an architecture needs some kind of network topology to provide communication channels between individual components. We distinguish two simple topologies.
A B C
D
(a) Point-to-Point Link Topology
A B C
D E F
(b) Bus Topology
Figure 2.1: Two network topologies. Left contains 4 point-to-point links. Right contains 1 bus.
A point-to-point link topology is the most intuitive topology. A point-to-point link connects two components, such as a processor and memory. Such a link is always connected to two components.
A bus, on the other hand, connects to several components. Any token that is transmitted over the bus is received by each component that is connected simultaneously.
From a security point of view, the point-to-point links are easier to secure. When using a bus topology, each process that connects to a bus has to implement the same security policy. We will come back to this in sec. 6.1.5.
CHAPTER 3
Design Space Exploration
Designing a new embedded system is a complex and time intensive process. In order to streamline the process, many guidelines and frameworks have been developed.
At the heart of many frameworks is an implementation of the Y-Model, which we will comprehen-sively discuss first in sec. 3.1. Y-Model is also used by Sesame, which is the framework developed at the University at Amsterdam and serves as the refrence framework for this literature study.
3.1
Y-Chart
It has become apparent that cost efficiency is one of the most significant factors in embedded system development and production due that the fact that many systems are mass produced. Satisfying only a single constraint (as discussed in sec. 2.3) is not enough. For example, selecting the fastest processors for any task is not cost efficient. Instead during the design space exploration components are selected that perform sufficiently for the purpose of the system, yet do not outperform its requirements. Thus, a significant part of the design process focuses on reducing under-utilization of resources, thereby increasing the cost efficiency.
One approach is to start with specifying the hardware in an embedded system in a Hardware Description Language (HDL). A HDL is a low-level language in which each detail of the hardware has to be specified. However, the disadvantage of this approach is that developers need to take design decisions in a very early stage. Afterwards, very little tweaking and optimization can be performed to further improve the design. Often, this results in an inefficient design.
The Y-Chart Methodology was first proposed in [11] and further elaborated in [12] is an approach that resolves these issues by providing a way to refine the architecture during the design process. In the Y-Chart Methodology, a developer specifies multiple architecture models and multiple application models (see fig. 3.1). Each model has specific parameters that can improve the performance of a mapping between a particular architecture and one or more applications. Each candidate architecture has its own model. The model specifies what components the architecture consists of and how those components are connected. On the other hand, the system may be designed for use with more than one application and thus there may be multiple application models that are mapped to the same architecture model. This is especially significant to reduce resource under-utilization. Designing a system for use with multiple application poses a challenge, but we will see that the Y-Chart Methodology guides us through the process nevertheless.
Mapping
Architecture Instance Application
Performance Analysis
Performance Numbers (1)
(2)
(3)
Figure 3.1: Overview of the Y-Chart Methodology. The Architecture Instance is generated from the Architecture Model. The Application is generated from the Application Model. After mapping and simulation, the performance numbers can indicate that the designer should focus on (1) improving the architecture, (2) improving the mapping or (3) improve the application.
We will start with explaining the architecture model and application model that are specified by the designer. We will then discuss the mapping of both models. Finally, we will examine comprehensively the work-flow of the Y-Chart Methodology.
3.1.1
Architecture Model
An architecture model specifies all hardware components and links in an architecture. The model is abstract and can be expressed as a graph AR = (VA, EA) where VA refers to the
individual components within the architecture and EA refers to the connections between those
components. This model is not fixed however and there are several parameters that can still be tuned to improve its performance with regards to any particular constraint.
FIFO X Y Interface Interface Trace Processor Port Execution Unit Bus
Figure 3.2: Example architecture model from [13].
In order to simulate an architecture, a new instance of the model has to be made and thus all of those parameters have to be fixed for the duration of the simulation. A naive approach would be to simulate with any permutation of parameter values in an architecture. However, usually the simulation and the performance analysis that follows, provide sufficient feedback for the designer to improve a specific set of parameters.
3.1.2
Application Model
An application model or model of computation specifies the behavior of the processes that are going to run on an architecture. Again, the model is abstract, for one because it cannot be com-piled until it is mapped onto a specific architecture. The Y-Chart Methodology does not specify a specific formal representation. In this literature study, we will apply Kahn Process Networks[14] (KPN) for this purpose because it is used in the Sesame framework (sec. 3.2). The model can be expressed as a directed graph AP = (VK, EK) where VK refers to the individual processes
within the KPN and EK refers to the communication channels between those processes. A KPN
specification can be derived either automatically by using a framework such as Compaan[13] or its successor PNgen[15], that processes an imperative application, or by hand.
Process Channel Process Port
Trace
Read Write
Execute
Figure 3.3: Example application model specified in a Kahn Process Network (KPN)[13].
We have added an example application model from [13] in fig. 3.3. Each communication channel is attached to a process port at each end of the channel. Each process has three ports: one for reading data, one for writing data and one for executing. Each port invokes a trace event. By investigating the trace log afterwards, the designer can better understand the computation and communication workload distribution.
Lastly, note that the application model is not necessarily implemented through software. For example, some cryptographic processes may be implemented by using a secure cryptoprocessor instead of a software library.
3.1.3
Mapping
Once several architecture models and application models have been designed, mapping can be-gin. Usually, an architecture is required to run multiple applications either simultaneously or sequentially. If an embedded system is designed to run multiple applications, then naturally all of those applications are mapped onto the same architecture.
The mapping specifies how the application is mapped onto the architecture. For example, the application in fig. 3.3 has more processes than there are processors in the architecture model in fig. 3.2. In that case, multiple processes are mapped to the same processor and scheduled. The mapping also describes the allocation of processor ports in the architecture to process ports in the application.
Note that the feasibility of each mapping may vary. Sometimes, mappings are not possible because the right components cannot be connected to each other. On the other hand, an archi-tecture may have components that are unused.
3.2
Simulation
Once an application is successfully mapped onto an architecture, it can be simulated and its performance analyzed. This technique is called software/hardware co-simulation[16].
10 ms 1 second 1 min 1 hour 1 day 1 month 0 % 5 % 10 % more details design complexity higher abstraction, automation lower accuracy single design evaluation time error cycle-accurate simulation trace-based analysis instruction set simulator static profiling system-level simulation synthesis calculus
Figure 3.4: Evaluation time of different evaluation methods from [4].
In fig. 3.4 we can see several evaluation methods and their trade offs with regards to the evalua-tion time, accuracy and level of detail and complexity. We will look at system-level simulaevalua-tion, which allows us to look at an entire system with a high level of abstraction at a relatively low evaluation time.
There are various simulation frameworks, developed for specific application domains. One such framework is Sesame, developed at the University of Amsterdam for use in the design process of embedded multimedia systems. Although the aspects of this literature study apply to all frameworks, we will use the Sesame approach[17] for the concluding case study.
The simulation will provide the designer with a detailed analysis of the system. In fig. 3.1 we can see that this analysis can indicate to the designer the need to improve either the architecture, the application or the mapping.
The designer can improve the architecture by replacing components with more suitable compo-nents, removing unused components or take other measures. The mapping can be improved by binding processes in the application to different components in the architecture. Finally, the application can be improved by restructuring the processes in the model.
CHAPTER 4
Attack Vectors and Counter Measures
We distinguish two types of attacks based on the purpose of the attack: side-channel attacks and denial of service attacks.
Side-channel attacks are used to retrieve data from a component within the embedded systems. Attackers will try to target cryptoprocessors, other processors that run cryptographic software, communication links or memory of the embedded system to retrieve passwords and private keys. Side-channel attacks come in a wide-variety characterized by the method that is used to execute the attack. Each variation is discussed in sec. 4.1
On the other hand, denial of service attacks are used to disrupt an embedded system. Most attacks of this class aim to occupy the embedded system in order to prevent it from doing the job it is meant to do. Denial of service attacks may also (unwittingly) corrupt system components, either physically (overheating) or virtually (memory corruption).
Lastly, although brute-force attacks are not directly related to hardware, their feasibility does depend on the quality of the hardware and the chosen algorithms that are implemented in the hardware. Therefore, we will conclude this chapter with discussing that type of attacks.
4.1
Side-Channel Attacks
A powerful analogy to side-channel attacks are wrapped birthday presents. Although the wrap-ping paper hides the exact contents of the present, its shape and structure still give away what it is. Side-channel attacks work similarly, by looking at derived metrics that leak from an embed-ded system and trying to reconstruct the data that is processed by the system at that moment in time.
We distinguish several side-channel attacks based on the metrics that they use in order to retrieve secret data from the system.
4.1.1
Power Analysis
Power analysis attacks are performed by measuring the power consumption of an embedded system over time[18]. The power consumption of an instruction that is performed by the processor depends on the data that is processed. By measuring a large number of power traces, the original data can be reconstructed.
All components in an embedded system are vulnerable to power analysis attacks and their relative security depends on the attractiveness of the data it processes or possesses.
Although all counter measures for this type of attack aim to mask the energy consumption of the component that needs securing, there are multiple approaches to implement this.
[19] masks the energy consumption of smart cards by doubling the width of the internal 32-bit busses and by implementing secure instructions that retrieve and store sensitive data over those 64-bit busses. The proposed system ensures that at all times, the number of ones transmitted over a bus is equal to the number of zeroes.
Another approach is to add noise to the energy consumption[20]. Since power analysis looks for peaks in the power signature, this approach aims at increasing the rest of the power signature in an attempt to conceal those peaks. This results in a trade-off because it increases security at the cost of energy consumption. This paper also presents a parameter that can be tuned to change the trade-off between security and power consumption. We will use that parameter in sec. 5.1.1 to score components that utilize this type of protection.
4.1.2
Timing Attacks
Timing attacks are performed by measuring the time of an operation that processes sensitive data. Similar to the power consumption of an operation, its duration often depends on the data that is processed. This behavior is best illustrated with a brief example in fig. 4.1.
0
start 8 1 1 2 5 3 4 4
Figure 4.1: Example of a process that is vulnerable to timing attacks. The process is a simplified case of the memcmp procedure, that compares a built-in PIN code (8154) with an input sequence of 4 digits.
The process in fig. 4.1 verifies the correctness of a 4 digit PIN code (8154) by comparing each digit in sequence and terminating as soon as an incorrect digit is found. It can be assumed that each comparison takes roughly the same time. For the sake of this example, let’s assume that each comparison takes 2 µs. Thus, the process takes 8 µs if the first three digits are correct, 6 µs if the first two digits are correct, 4 µs if the first digit is correct and 2 µs otherwise.
In general, the average number of attempts that is required to correctly guess a 4 digit PIN code is 1024. Here we assume that both the PIN code, as well as all tried permutations are drawn from a uniform distribution. However, by using a timing attack, we can dramatically reduce that number because we can verify the correctness of each individual digit based on the operation duration of the process. The average numbers of attempts that is required to guess the first a single digit is 102, thus to guess the entire PIN code only 1024 attempts are required, which is eight times less than without the timing attack.
A significant difference between timing attacks and power analysis is that timing attacks can also be easily performed at the application level[21]. For example, if two processes run on a single architecture and one of those can trigger a sensitive operation within the other process, it can measure the duration of the operation and thus derive sensitive data such as private keys. Protection against this type of attack aims at concealing the correlation between the duration of an operation and its input. If a process successfully hides this correlation, it is a constant-time process. In fig. 4.2 we have shown how such a protection can be added to the process of fig. 4.1.
0
start 1 2 3 4
0 /
8 1 5 4
Figure 4.2: Same process as fig. 4.1 with an additional sink state.
In fig. 4.2 we can see that a new sink state is added that is transitioned to when an incorrect digit is processed. For each additional digit, the state loops. The duration of this state is equal to any other state. Therefore, the total duration of the process is no longer related to its input. A more complex example of procedures vulnerable to timing attacks are those that run on modern CPUs and frequently access sensitive data. Retrieving data from memory is a time costly operation. Therefore modern CPUs have a fast cache that stores frequently accessed data. This results in a performance improvement because frequently accessed data does not have to be retrieved from memory more than once.
However this behavior can also be abused by attackers[22]. An attacker starts by filling the shared cache with their own data. The victim’s process will then store their sensitive data in the cache again, thereby evicting some of the attacker’s data. The parts of cache that are overwritten, can reveal to the attacker what parts are used to store the victim’s sensitive data.
AES is one of the most commonly used encryption standards and it has been shown that these cache-timing attacks on AES software implementations are extremely easy to perform[23]. The same research also concludes that any attempt to make AES constant in time will result in a significant and impractical decrease of performance. This is similar to the approach shown in fig. 4.2: adding a sink state to prevent timing analysis will also slow down the best-case execution time to the worst-case execution time.
Not all encryption standards are inherently vulnerable to cache-timing attacks. In particular, those that use S-boxes or lookup tables such as AES, are vulnerable. Resorting to alternative algorithms, such as the one used in the case study (chapter 6) is a viable solution to resist cache-timing attacks without compromising performance.
4.1.3
Scan Attacks
When designing new embedded systems, testability is one of the most significant aspects. In particular when the system has to meet high mass production requirements as well as high product quality, the need for fabrication and post-fabrication testing is evident. Scan-based Design-for-Test (DFT) is one such scheme[24]. Chips that implement this scheme are equipped with a JTAG port that can be used after fabrication for debugging purposes as well as during fabrication for quality control.
However, when it comes to securing an embedded system architecture, this debugging port becomes a security threat because it can be used to extract sensitive data from the system. Scan-based side-channel attacks were first proposed in [25]. Scan attacks are performed by partially running an encryption algorithm and then using the debug port to retrieve the internal algorithm state.
The same authors have also shown that the feasibility of a scan-attack depends on the chosen algorithm parameters[26].
4.1.4
Differential Fault Analysis
Naturally, in hardware there is a small probability of faulty computations. At that level of computations, the hardware is processing bits so a faulty computation results in a zero that is incorrectly set to a one, or a one that is incorrectly set to a zero. This behavior is particularly inconvenient for cryptographic routines.
For example, public-key cryptography works because prime factorization is a compute intensive task, whereas general integer factorization is trivial. Therefore, primes are very suitable for private keys. If due to a faulty computation by the hardware, a public-key cryptography routine incorrectly determines that a given number is a prime, retrieving the corresponding public key is trivial[27].
Additionally, attackers may also try to induce faults. For example, it has been shown that by inducing faults in a particular round of the DES encryption algorithm, only 10 ciphertexts are required to recover the complete secret key[28]. Even worse, if it is possible to induce faults in a particular position, only 3 ciphertexts are required.
A naive countermeasure would be to implement additional tests to verify that a computation is not faulty. However, doing that results in a large performance penalty, especially given the fact that many of those operations are frequently called. Fortunately, various countermeasures have been developed and optimized since. [29] provides an overview of these countermeasures. One of the classifications that are made is based on the type of countermeasures. It asserts that there are two classes: one that is based on implementing additional tests and one that aims to ensure that the data that is leaked is unusable to an attacker. The first class can be optimized by minimizing the number of additional checks.
Hardware faults occur naturally and if no precautions are taken, can be used by attackers to retrieve sensitive data. This requires no physical or virtual access to the system. For example, if the system distributes faulty public keys after incorrectly determining that an integer is prime, an attacker can easily recover the corresponding private keys.
Inducing faults, however, is only possible for an attacker that has physical access to the system.
4.1.5
Electromagnetic Analysis
Electromagnetic analysis is similar to power analysis and timing attacks. It is based on the observation that the electromagnetic radiation emitted by a processor depends on the data that it is working on.
This attack was first described in [30] although it shares much of the principles of side-channel attacks in general. Using this type of attack, a 3D signature of the electromagnetic radiation can be generated.
The authors also propose several countermeasures. One of those are very similar to those used to prevent power analysis attacks (sec. 4.1.1): dual line logic. With dual line logic all links are replaced with double links of which one transmits the exact opposite of the other link in order to reduce the significance of the electromagnetic signature.
Another approach is to embed the system in a Faraday cage. However, this is not very practical since physical access to the system is required anyway to be able to perform an electromagnetic analysis attack. Thus, for an attacker it would be trivial to remove the Faraday cage.
4.2
Denial of Service
Denial of Service attacks (DoS) are becoming more popular. In many cases, when performing a side-channel attack is infeasible, attackers will resort to a DoS which effectively disables a
system. A DoS is most often performed by sending many concurrent requests to a system, thereby occupying a large share of its resources. DoS are particularly hard to counter because it is often impossible to deterministically distinguish genuine requests from malicious ones. Battery-powered embedded systems are especially at risk because DoS tend to drain their battery if not countered timely[31]. In situations where the battery is not easily accessible or rechargeable, such as in aircraft, this type of attack creates an immediate safety hazard.
4.3
Software Attacks
So far, we have discussed only hardware attacks. There is an even wider variety of software attacks however. In this section, we will discuss only software attacks that an embedded system can be protected against by implementing hardware-assisted countermeasures.
4.3.1
Buffer Overflows
Buffer overflows are the most commonly occurring software vulnerabilities[32] and are inadver-tently introduced by software developers, although with open source projects buffer overflows can also be a way for passive attackers to disguise backdoors. These bugs can surface sporadically based on the input of an unwitting user but can also be exploited by attackers to deliberately trig-ger a buffer overflow. Buffer overflows destabilize a program and can result in corrupt memory, a system crash, or in the worst case leakage of potentially confidential data.
Protection against buffer overflows can be implemented both in the application as well as in the architecture of an embedded system. As discussed earlier in sec. 2.4.1, software is usually written at a high level of abstraction. Higher levels of abstraction provide great protection against buffer overflows. However, those levels come with the cost of reduced performance. Alternatively, protection can also be implemented in hardware. All implementations of such protection are similar in that they add a number of secure instructions to the processor instruction set, though the implementations range in complexity and sophistication.
One approach to protect against this type of attack is HSDefender[33]. HSDefender protects against two subtypes of this attack: stack smashing and function pointer attacks. With stack smashing attacks, data is written outside the stack to different parts of the memory. Stack smashing protection is implemented by verifying that each write to the stack points to an address within the stack. Note that it does not provide protection against out-of-bounds reads, nor does it protect against buffer overflows of heap memory. With function pointer attacks, an attacker attempts to change the control flow in a way that is was never intended and thereby extracting sensitive data from the system. For example, an attacker might attempt to reroute a generic cryptographic function to a debug output function so that all keys are written to a file instead of processed discretely. HSDefender provides protection by XORing all function addresses in all jump instructions. The addresses are XORed with a secret key that is stored in a secure inaccessible register and is generated at the start of each process in a random manner, thus making it hard for an attacker to guess and impossible to extract.
4.4
Cryptanalysis
Many embedded systems have a dedicated chip that implements and is optimized for crypto-graphic algorithms. Preimage attacks can be applied to cryptocrypto-graphic hash functions such as SHA-1 in which case the goal is to find a plain-text for a given hash. In a similar fashion, crypt-analysis applied to asymmetric cryptographic ciphers aims to find a private key that belongs to a known public key.
The feasibility of preimage attacks depends on algorithms that are used by the embedded sys-tem. Choosing stronger algorithms, in other words algorithms that are better preimage attack resistant, is a trade-off. In general, it can be assumed that stronger algorithms consume more energy[34].
4.5
Comparison of All Attacks and Protection Techniques
Before integrating the security aspect in the design process, all attacks and protection mechanisms have to be classified in such a way that they can be appropriately weighted and parametrized during the design process.
4.5.1
Access Level
We distinguish three access levels that can be used to classify all attacks. These levels indicate the access to an embedded system that is required to perform an attack.
Physical access level attacks require physical access to the embedded system. For example, this applies to using the JTAG-port on scan-architectures to extract data.
Virtual access level attacks require access to one process that runs within an application on the embedded systems. For example, this applies to inter-process timing attacks that measure the duration of operation by some other process to extract sensitive data.
Finally, there is also a no access level for attacks that require no access. For example cryptanalysis attacks often do not require access to the system as long as it has the image of a function within the embedded system. In the case of public key cryptography for example, the public key is distributed to other systems and therefore freely available.
Attack Subtype Access Level
Side Channel Power Analysis Physical
Timing Virtual
Scan Physical
Fault Analysis Physical and Virtual Electromagnetic Analysis Physical
Denial of Service Virtual
Software Buffer Overflow Virtual
Cryptanalysis None
Figure 4.3: Access levels required to perform various types of attacks on embedded systems.
We have added an overview of the access levels of various types of attacks in fig. 4.3. This classification will come in handy when scoring the security of an embedded system. The feasibility of each attack access level depends on the environment in which the system is going to run. For example, protection against power analysis attacks is only necessary when an embedded system is physically accessible by attackers. One might argue that in this particular example, cars should be protected against physical access level attacks because they are often unattended, and microwaves should not because physical access to them by attackers is unlikely.
4.5.2
Passivity
Another aspect of an attack is whether it is passive or active[35]. Active attacks manipulate a system. Manipulation can either be a means or a goal of an attack. For example, with scan attacks, manipulating the system to put it in test mode is a means, whereas a denial of service attack’s purpose is to disrupt the system. Note that active attacks are not necessarily noticeable by the system. For example, buffer overflow attacks do disrupt the system but the system often cannot tell that it is being disrupted. On the other hand, passive attacks do not manipulate or disrupt a system. Instead, they unnoticeably extract or derive sensitive data from a system.
Attack Subtype Passivity
Side Channel Power Analysis Passive
Timing Passive
Scan Active
Fault Analysis Active and Passive Electromagnetic Analysis Passive
Denial of Service Active
Software Buffer Overflow Active
Cryptanalysis Passive
Figure 4.4: Passivity of various types of attacks on embedded systems.
Again, we have added an overview of the passivity of various attacks in fig. 4.4. It is necessary to identify passive and active attacks because the likelihood of an attack depends on its passiveness and the data that a system processes. For example, systems that do not process sensitive data do not need to be protected against passive attacks. However, it can still be important that their service is not disrupted and therefore they should be protected against active attacks.
Whether or not an application needs protection against passive or active attacks, is often hard to establish. Therefore, we have used the same requirements as the authors of [3] and mapped them to passivity. We show a few example applications in fig. 4.5. We have listed our motivation behind each application below the figure.
Passive Active
Application Confidentiality Integrity Availability Authenticity
Anti-lock Braking System
ATM
Mobile Phones
DRM
Figure 4.5: Reference table for determining the passivity of a system based on security require-ments from [3].
An Anti-lock Braking System (ABS) does not process sensitive data and thus confidentiality is not necessary. However, it cannot be disrupted or manipulated, so integrity, availability and authenticity need to be guaranteed.
An ATM processes the PIN of a customer, which needs to be kept private (confidentiality). Moreover, forgery of PIN transactions should never be possible (integrity and authenticity). Availability, on the other hand, is at relative low risk: if service of an ATM is suspended, it does not pose a security threat, only an inconvenience.
With mobile phones, again, confidentially is very important, as is integrity, availability and authenticity. In this case, attacks on availability are battery drain attacks for example.
With regards to passivity, DRM is the exact opposite of Anti-lock Braking Systems. Interruption of DRM does not pose a security threat. The only thing that is important for DRM is that the keys it uses are kept confidential.
4.5.3
Target Roles
Next, we distinguish three different roles of components within the system.
Computation elements manipulate data. Examples of computation elements include general purpose processors, digital signal processors and cryptographic chips. In order to reduce the costs and energy consumption, computation elements are often shared with multiple processes in the same system. However, sharing a processor can introduce vulnerabilities with regards to timing attacks because one process can analyze the duration of operations performed by another. In order to transfer data within the system, communication elements are used. Again, in order to cut costs, communication elements may be shared with multiple processes in the same system. However, in sec. 5.3 we will show that we restrict this to processes that share the same security policy.
In fig. 4.6, we show the roles of components that are a potential target for each attack.
Attack Subtype Computation Communication Storage
Side Channel Power Analysis Vulnerable Vulnerable Vulnerable
Timing Vulnerable
Scan Vulnerable
Fault Analysis Vulnerable
Electromagnetic Analysis Vulnerable Vulnerable Vulnerable
Denial of Service Vulnerable Vulnerable
Software Buffer Overflow Vulnerable
Cryptanalysis Vulnerable
Figure 4.6: Target roles of various types of at-tacks on embedded systems.
4.5.4
Evaluation
Vulnerabilities may be further classified in terms of the moment of evaluation during the design process. Statically evaluated vulnerabilities are ideal, since they do not require simulation of the hardware. Dynamically evaluated vulnerabilities can only be evaluated during the simulation and thus their existence can only be accessed after the simulation. In fig. 4.7 we show the moment of evaluation for each attack. Below, we provide an explanation for each attack and evaluation moment.
Attack Subtype Evaluation
Side Channel Power Analysis Statically Timing Dynamically
Scan Statically
Fault Analysis Statically Electromagnetic Analysis Statically
Denial of Service Dynamically
Software Statically
Cryptanalysis Statically
Figure 4.7: Evaluation moment of vulnerability to attacks on embedded systems.
Vulnerability to power analysis attacks can be assessed statically. All components in an archi-tecture have a power signature that reveals what data is processed, unless specific precautions are taken. These precautions are known before run-time. This applies to scan, fault analysis and electromagnetic analysis attacks as well.
Timing attacks are hard to evaluate statically since there are many factors that are an influence. For example: caching behavior and branch prediction each affect the level of vulnerability to timing attacks.
Writing secure software is hard, and thus we assume that hardware protection against software attacks such as buffer overflow and function pointer attacks, is always necessary. Lack of these countermeasures can be evaluated statically.
Lastly, cryptanalysis refers to the best known cryptanalysis of the chosen algorithms and thus is known before simulation.
CHAPTER 5
Design Exploration Integration
Now that a clear overview of all types of attacks is established, they have to be integrated in the design space exploration so that the performance of the embedded system with regards to security can be measured during the performance analysis.
We propose an approach that works on several layers to score the security of each component, link and enclaves within an embedded system. At each level, a list of qualities is used to generate a score. Qualities are often not requirements and their purpose is to provide designers with a realistic analysis of their system security. Thus, designers will aim at a high level of security, but can always analyze at what costs that level is achieved.
In general, for each component a score is computed by summing the performance of each quality. The performance is expressed either in binary format (yes, no) or as a number. Some qualities may depend on other qualities, for example if the absence of one quality nullifies the performance of another.
Then, the communication links between each component are scored. The way this score is computed is similar to the score of individual components.
Finally, spatial isolation is used to separate different applications in enclaves. Each enclave con-tains all components and communication links that are required to run one or more applications with the same security policy.
5.1
Processors
5.1.1
General Purpose Processors
In fig. 5.1 we have provided an overview of all protection mechanisms discussed in this literature study, categorized by their attack group. In addition, the last column provides a hint for designers with regards to the trade-off for each mechanism.
Quality 0.0 score 1.0 score Trade-off against
Power Analysis (any)
Random Noise[20] q < 0.5 ∨ q > 0.5 q = 0.5 power consumption Dual Line Logic[19] no yes area overhead
Scan-based Attack (any)
Debug-Port yes no maintainability
Secure Scan Architecture[24] no yes area overhead Timing Attacks
Differential Fault Analysis (any)
Test-based Countermeasure[29] no yes performance Infective Countermeasure[29] no yes performance
Electromagnetic Analysis (any)
Faraday Cage[30] no yes cost
Dual Line Logic[30] no yes area overhead Software Attacks (all)
Stack Bounds Checking[33] no yes performance area overhead Function Pointer Protection[33] no yes performance
area overhead
Figure 5.1: Overview of security properties that apply to all types of processors. Note that some properties can only be evaluated dynamically (see fig. 4.7).
Power Analysis
In order to protect a system from power analysis attacks, two approaches have been discussed. The first one is adding random noise in an attempt to disguise the actual power behavior of the system. However, adding additional peaks to the power consumption, increases the overall power consumption. Therefore, the q coefficient can be used to tune the security/power trade-off. At q = 0.5 the noise cannot be predicted and thus the system is fully protected against a power analysis attack.
Either approach is sufficient on its own, thus only one has to be implemented in order to neutralize the security threat.
Scan-Based Attacks
Chips that use an accessible debug-port such as a JTAG-port (sec. 4.1.3) are vulnerable to physical access level attacks. This quality can be ignored if the embedded system is in a safe environment or is not physically accessible by attackers (see fig. 4.3). If the debug-port can only be used to read data and can not be used to modify the embedded system, this quality can also be ignored if the system does not process sensitive data.
If a debug-port is necessary for reasons of maintainability, designers can also resort to a secure scan architecture[24]. The secure scan architecture ensures that if the processor is put in test
mode, all registers are erased first.
Differential Fault Analysis
The authors of [29] conclude that it is better to use the infective countermeasure because it is harder to circumvent.
5.1.2
Secure Cryptoprocessor
Secure Cryptoprocessors share all of the security requirements with General Purpose Processors except for the software attacks protection mechanisms. In addition, we also score the algorithm that is implemented. In fig. 5.2 we show how we score the implemented algorithms.
Quality 0.0 score 1.0 score Trade-off
Cryptanalysis
Best Known Cryptanalysis 2128 or less 2512or more performance
Figure 5.2: Overview of security properties that apply to secure cryptoprocessors.
In the event that one secure cryptoprocessor implements multiple algorithms, the score for each algorithm is weighed according to the use of that algorithm. Thus, cryptographic algorithms that are implemented but are hardly ever used, are weighted less than those that are used very often. We will come back to this in 5.4.
5.2
Busses
The security qualities that apply to busses are a small subset of those that apply to processors. We have listed these qualities in fig. 5.3.
Quality 0.0 score 1.0 score Trade-off against
Power Analysis (any)
Random Noise[20] q < 0.5 ∨ q > 0.5 q = 0.5 power consumption Dual Line Logic[19] no yes area overhead Electromagnetic Analysis (any)
Faraday Cage[30] no yes cost
Dual Line Logic[30] no yes area overhead
Figure 5.3: Overview of security properties that apply to busses..
It is also important to note that all applications that are connected to a bus, should have the same security policy (sec. 5.5). Otherwise, potentially malicious applications could peak at the data that is transmitted between other applications.
5.3
Enclaves
Embedded systems often run multiple applications. Our case study (chapter 6) will run three different applications, one of which runs an application that can be replaced by the user with a potentially insecure application. An insecure application can use any attack that is possible with virtual access (see fig. 4.3) to retrieve sensitive data from the system or disrupt the system. Thus, separating groups of components and isolating those groups is necessary. This is spatial isolation and is extensively described in [2] in the context of design space exploration.
C B A
Figure 5.4: Illustration from [2] that shows several mapping shapes of three applications. The mapping of application A and B can be transformed into different shapes. Finally, an optimal combination of one shape per application is mapped by the run-time mapper.
In the example of fig. 5.4, we have three separate applications with 3, 4 and 2 processor elements respectively. The paper proposes several shapes (2nd column in the figure) that can be used to find an optimal mapping that still achieves spatial isolation. Spatial isolation is important to prevent applications from sharing the same channels. If an application uses those channels to transmit sensitive data, other potentially malicious applications may record that data.
5.4
Workload Distribution
The security that is measured in the previous sections depends only on the architecture model. We introduce a usage graph in addition to the scoring parameters discussed in the previous sections, that specifically takes into account the usage share of each component.
For example, if a system implements two ciphers, one that is far more secure than the other, but needs to implement the less-secure cipher as well because it has to communicate with older systems as well, we will want to take this into account.
Another example of this is when a cryptographic implements multiple ciphers, but uses only one of them, in which case only the used cipher should be scored and the unused ciphers should be ignored.
