978-1-4244-4078-8/09/$25.00 ©2009 IEEE. 7.E.2-1

COMPILER/HARDWARE ASSISTED APPLICATION CODE AND DATA SECURITY IN EMBEDDED SYSTEMS

Chunguang Bu, Xiang Wang, and Chi Zhang, School of Electronic and Information Engineering, Beihang University, Beijing100191, China

Jizhong Liu Xiaodong Wang, Chuntang Qi,and Xiaoying Gao, National Key Lab. of Sci. and Tech. on Aerospace Intelligent Control, Beijing100854, China

Baosen Li, Luoyang Optoelectro Technology Development Center, Luoyang 471009, China

Abstract Embedded systems have stepped deeper into

Integrated Avionics systems, and security is becoming an important concern. Most embedded systems present a number of software vulnerabilities, such as buffer overflows. Furthermore, the rapid growth and pervasive use of embedded systems makes it easier for a sophisticated attacker to gain physical access to launch physical attacks on insecure off-chip main memory. This paper presents a novel compiler/ hardware assisted application code and data protection architecture (CHCDP) to monitor the execution of application. The compiler extracts the control flow and static data integrity validation information using hashing and cyclical redundancy check (CRC) integrity algorithms at compile time. The dynamic data integrity validation is generated in the process of application execution. Likewise, the function return address and frame point are also protected at runtime. The designed hardware observes its dynamic execution trace and checks whether the trace conforms to the permissible behavior. And it will trigger appropriate response mechanisms if finding a mismatch. An OR1200 processor is assigned to build a System on a Programmable Chip (SOPC) that implements the architectural design. The experimental analysis shows that the proposed techniques can eliminate a wide range of common software and physical attacks with low performance penalties and minimal overheads.

Introduction Along with the technical innovations in the past

decades, embedded systems have stepped deeper into our lives and are often used in communication networks and automatic control etc.

However, most embedded software expose to a number of vulnerabilities. Additionally, with the wide application of wireless connection to the networks or the Internet, many embedded systems with these programs are easily becoming the targets for software-based security attacks.

Similarly, the widely use of embedded systems makes them easier for an attacker to carry on physical access. With the help of advanced electronic equipment the sophisticated attacker can control the address/data bus to tamper, inject or replay memory blocks when the application code and data are loading to the processor.

Most of the existing approaches tackle the security problems at the software level, but they cannot avoid vulnerabilities and often cause high overheads in performance.

This paper presents a novel hardware solution to assist the application execution security. The compiler extracts the control flow and static data integrity validation information using hashing and CRC integrity algorithms at compile time. The dynamic data integrity validation information is generated at runtime. The return address and frame point of the functions are also protected to avoid the stack smashing attacks. The designed hardware observes its dynamic execution trace by the monitoring model. When a mismatch is detected, it will trigger the response mechanism.

A Xilinx Field Programmable Gate Array (FPGA) and an open-source OR1200 processor are assigned to build a SOPC, which verifies the proposed architecture. The experimental analysis shows that the proposed approach can eliminate a wide range of common software and physical attacks with low performance degradation and minimal overheads.

7.E.2-2

The rest of this paper is organized as follows. Section 2 discusses the related work. Section 3 describes the motivation. Section 4 presents the monitoring architecture in detail. Section 5 provides the security analysis of the proposed mechanism. Section 6 shows the experimental analysis. Section 7 concludes this paper.

Related Work The security protection methods have been

greatly increased over the past decades. The related software-based and hardware-based techniques are examined as below.

The software-based approaches used to be the main methods for detecting and preventing exploits. Abadi et al [1] propose a software technique to monitor the control flow. It derives the control flow graph (CFG) of a program using static analysis and enforces the CFG check at runtime. StackGuard[2] recompiles the source code to place a random word on the stack to prevent return address corruption resulted from stack overflow. In [3], the author presents a self-checking technique which uses digital signatures to help identify whether application code has been modified to destroy the integrity at runtime.

Recently, hardware-based approaches become the state-of-the-art method. Yunsi Fei et al.[4] proposed a micro-architectural monitoring module to monitor the code integrity. The AEGIS[5] presents techniques for control-flow and code tampering prevention. Zhang et al. [6] proposed a secure co-processor for monitoring kernel data structures, but it is too expensive to be used for resource restricted embedded systems. Arora [7] presents a hardware control flow monitor to enhance embedded system security. CODESSEAL[8] uses compiler inserting signature to the object file, and the runtime reconfigurable FPGA logic validate the application execution at a cache block level. REM.[9] propose an architectural mechanism to prevent malicious code execution.

From the application data protection perspective, many technologies are also proposed. In [10], the author presents a hardware/software approach to secure the application data. Their work enhances the memory hierarchy to represent the attributes of each datum as security tags, and adds a configurable hardware checker that interprets the semantics of the

tags and enforces the desired security policies. Gelbart[11] presents an architectural support for securing application data integrity. Their scheme can protect the application data from physical attacks. PE-ICE[12] enables to guarantee confidentiality and integrity of data exchanged between the safe SoC and its external memory.

Motivation In this section, we will illustrate the software

vulnerabilities and physical attacks on application code and data.

Buffer[16]

sfp

ret

*str

Maliciouscode

Stack growth

Overflow

--------------------------------void function(char *str) { char buffer[16]; strcpy(buffer,str);}void main(){ char large_string[256]; int i; for( i = 0; i < 255; i++)

large_string[i] = 'A';

function(large_string);}--------------------------------

……

(a) (b)

Figure 1. Stack Smashing Attack and its Stack Structure

In software attacks, the attacker exploits software vulnerabilities that presented in the “trusted” application (e.g.,OS) to launch attacks. Figure 1(a) illustrates a typical smashing attack. Function() uses strcpy() to copy the large_string[] into local buffer. Since strcpy() does not verify whether the input exceeds the buffer size, an attacker can overflow the buffer[] to overwrite the return address(ret) and previous frame pointer(fp). Figure 1(b) shows its stack structure. By careful design, an attacker can make the return address point to the malicious code as shown in Figure 1(b). After the program returns, the normal control flow will be interrupted to execute the malicious code. A variation of this kind of attacks overflows the previous fp only. Since previous fp will point to the stack frame of main() after returning from function(), a similar attack can be activated when the program returns from main().

7.E.2-3

Another kind of attacks considered in this paper is the physical attacks as shown in Figure 2. We assume that the SOC is trusted, but the off-chip external memory can be attacked. When the attacker has physical access to the embedded equipment, he can interfere with the communication between CPU and memory to launch attacks as below.

(1) Code or data injection/modification attacks: The attacker can modify the application code or data in the external with a random value or inject a portion of code or data.

(2) Control flow altering attacks: The attacker can obtain the control flow of an application by sniffing on the address bus. By controlling the address bus, he can change the execution in his designed direction.

(3) Code/data replay attacks: The attacker can record a portion of instruction code/data and reuse it later. By observing the results, the attacker can catalog the information of individual replay attacks which can be used to get a greater corruption or a better understanding of the application.

Figure 2. Physical Attack on External Memory

The Compiler/Hardware Approach for Secure Application Code and Data

This section describes the proposed Compiler/hardware assisted application code and data protection architecture (CHCDP).

Overview CHCDP has two main components shown in

Figure 3. At compile time, the compiler compiles and links the source code to generate the executable binary code. Meanwhile, it extracts the control flow integrity and static data integrity monitoring model. At runtime, the hardware logic compares the dynamic

execution stream with the monitoring model. The hardware has three functions: control flow validation, code integrity validation and static/dynamic data integrity validation. Once the attacks occur, a control signal will be sent to the processor to trigger the response mechanism (e.g., terminating or recovering the program). The monitoring hardware is implemented on-chip, so it can not be compromised by many malicious software and physical attacks.

Figure 3. The CHCDP Design Flow

The Compiler Design The compiler plays an crucial role in the offline

security analysis. It generates the monitoring model automatically. A good monitoring model needs to have the capacities as follows: a)Easily extract through automatic program analysis. b) Accurately describe the program intended behavior. c) Promptly detect the unintended behavior. d) Necessarily meet lightweight demand for resource-limited embedded system.

Considering the above requirements, the basic block level is chosen to monitor the application code execution and the cache block level is chosen to monitor the application data. We define the end of a basic block is a branch or jump instruction, and the next instruction is the beginning of another basic block. The designed model contains four sets: F, B, C&D.

7.E.2-4

F: Function calling information of program.

Fi ∈ F, fi={address}. fi is the ith function absolute entry address.

B: Basic block jump information of program.

bi∈ B, Bj={type_b[j],com[j],tag[j], TARGET_b[j]}

bj is the jth basic block jump information. index_f[j] is the jth basic block corresponding function index in

F; addr_bn[j] is the relative address between the entry address of the jth basic block and the entry address of the function corresponding to the jth basic block; type_b[j] is the jumping type of the jth basic block which is shown in Table I. TARGET_b[j] is the possible target jump address sets of the jth basic block. Table I shows the next possible path of control flow.

Table 1. Path of Control Flow

X Type_b Addr_t

0 Intra-function unconditional jump

∀ addr_t∈TARGET,addr_t=addr_f[i]+addr_bn[t];t∈TARGET_b[j]

1 Intra-function conditional jump

∀ addr_t∈TARGET, addr_t=addr_f[i]+addr_bn[t]; or addr_t=addr_f[index_f[j+1]]]+addr_bn[j+1]; ∈TARGET_b[j]

2 Inter-function unconditional jump

∀ addr_t∈TARGET, addr_t=addr_f[index_f[t]]]+addr_bn[t]; t∈TARGET_b[j]

3 Inter-function conditional jump

∀ addr_t ∈ TARGET, addr_t=addr_f[index_f[t]]]+addr_bn[t];or addr_t=addr_f[index_f[j+1]]]+addr_bn[j+1]; t∈TARGET_b[i]

4 Multi branches jump ∀ addr_t∈TARGET, having an traverse search of TARGET

5 Function call return addr_t obtained directly through a stack mapped unit

C: The application code integrity information

Cj={HASH/CRC}. Cj is the jth basic block integrity information of application code. Its value is calculated by SHA-1, SHA-256 or CRC hash algorithms. The location is according to the demand of binary search algorithm to assist the hardware in searching quickly.

D: The application data integrity information

Dj={HASH/CRC}. Dj is the jth Cache block integrity information of application static data. Its value is calculated by CRC hash algorithms.

Control Flow Integrity Validation The control flow integrity validation scheme is

embedded into the pipeline stages shown in Figure 4. The statically extracted control flow integrity monitoring model is loaded into an internal F, B&C memory table. We define the control flow instruction is the basic block’s starting instruction.

Figure 4. The Architecture of Control Flow Integrity Monitor

During the execution process of application, the hardware buffers current basic block’s beginning Program Counter (PC) signal at IF stage. Depending on this PC, the mapped basic block monitoring model is fetched. Then, the monitoring hardware logic begins to calculate the next possible basic block’s starting address. When the next real control flow instruction is emerged, the hardware can compare the next basic block’s real PC with the calculated one to validate the control flow behavior.

7.E.2-5

At the same time, the monitoring hardware buffers the instruction register (IR) stream corresponding to the basic block at EXE stage. When a control flow instruction is encountered, it signals the hardware Dynamic Integrity Calculation unit to compute the Hash/CRC value of the buffered basic block. The computed value is then compared with the value stored in the monitoring model to validate the integrity. The comparing unit detects deviation of program execution, but if it isn’t accomplished, the processor must be frozen to let the comparing unit catch up. When founding a mismatch, the monitor logic will assert the control signals to notify the Operating System to trigger response mechanism.

Shadow Call Stack Figure 5 illustrates the shadow call stack (SCS),

which is employed to provide correct, uncorrupted return address and frame pointer.

Figure 5. The Architecture of Shadow Call Stack Monitor

In ID stage, the hardware SCS decodes the instruction. When finding a push instruction that store the return address onto the stack, the SCS pushes the current return address information onto the top of its corresponding last in first out (LIFO) memory in MEM stage. When finding a pop instruction, the SCS pops the current return address information from the top of LIFO memory. In EXE stage, the real return address is compared with the LIFO popped return address, and then the compared unit determines whether it trigger the response mechanism.

As illustrated in Figure 1, there is a variation of attacks that corrupt previous fp only. To prevent

these kinds of attacks, the fp must also be pushed and popped as the return address. So, any attacks that defending against return address or fp corruption in the stack memory can be detected efficiently.

Data Integrity Validation Many attacks are initiated by tampering the

application data rather than altering control flow or tampering application code integrity. In order to detect the physical attacks on unsafe off-chip main memory data, we design the data integrity validation hardware as Figure 6 shows.

Figure 6. Data Integrity Validation Architecture

The application data contains static data (constants, initialization values, string tables) and run-time data (stack and heap). The integrity information of static data can be derived at compile. However, the dynamic data can be extracted only when the process is active. As Figure .6 shows the hardware monitors all memory communication between the CPU and main memory. At runtime, when the CPU executing a store instruction, the hardware receives memory contents before the main memory. So it can calculate the integrity information depending on the cache block. These data integrity Hash/CRC are stored at our on-chip memory as the static data does. When executing a load instruction, if a data cache miss occurs, the CPU issues a read signal and then the memory dumps the contents on the bus. The hardware calculates the data integrity Hash/CRC before sending into the D-Cache. The hardware realizes the data address requested, so it can fetch the previous stored integrity monitoring Hash/CRC. The two integrity Hash/CRC values are then

7.E.2-6

compared. If there is a mismatch, it depicts that the application data is tampered on off-chip memory.

Security Analyze The designed architecture can detect many

kinds of attacks as below. It can protect the application execution from four aspects.

The first one is on the function level. As in Figure 7 F shows, the normal function call flow is①→ ③→ ②. However, if the attacker changes the flow to ①→③→④, and ④ is a malicious code, the proposed architecture can detected.

The second one is on the basic block level. As shown in Figure 7 B, there are 4 basic blocks in function 1. Now consider the branch instructions in b. For example, in if (x>0) b→c, if (x<=0) b→d. c and d are both considered to be the effective flow transferring from b. But if the attacker tampers the variable x, he can control the execution flow easily. Our mechanism can protect the basic block level control flow altering attacks.

The third one is based on Hash/CRC signatures for all the basic blocks. As Figure 7 C shows, the 20c0’s corresponding signature is sig_c, 20e8’s corresponding signature is sig_d. Suppose the processor requests (address for) block c after block b, the attacker can tamper, inject code in block_b or substitute it with block d. The monitoring hardware pick up sig_c by reading the entry address and compute the signature of the requested one. Since the signatures are obviously different, the hardware can detect the attack. For replay attacks, our mechanism makes sure that the signature is the latest one.

The fourth one is on the cache block level: data integrity validation. It likes the third one, but changes the basic block application code to cache block application data. Unlike application code that has the limitation of valid op-code in the instruction set, the application data can be tampered randomly. As Figure 7 D shows, the attacker can tamper the static data (rodata) or the dynamic data (stack data). The proposed data integrity validation can detect any data injection /modification and replay attacks.

Figure 7. The Monitoring Granularities of the Security Analyse

Experimental Results The embedded processor adopted is OR1200

which is a 32-bit scalar RISC with Harvard micro architecture, 5 stage integer pipeline. The system on programmable chip (SOPC) platform is built on a Xilinx FPGA. The software development tool for

OR1200 is the popular and free GNU. The systematic simulation toolset is OR1ksim.

Hardware Overhead The hardware overhead contains two parts:

memory overhead for monitoring model and logic

7.E.2-7

overhead for control and comparison. Our monitoring model memory overhead is different for diverse applications. As Table 2 Size shows, the width of set F, B, and SCS are assumed to 32 bits. In our experiment, SHA-1, SHA-256 and CRC32 are used as the integrity algorithm. Their

corresponding set width is 160 bit, 256 bit, and 32 bit respectively. Our design is synthesized under Xilinx ISE 8.2i. Table 2 presents the modest area overhead when adding F&B, SCS, Code Integrity validation and Data integrity validation units.

Table 2. Overhead and Detecting Speed

Set F B SCS Code Integrity Data SHA1 SHA256 CRC CRC

Size (bit) 32 32 32 160 256 32 32 Slices 297 305 360 366 326 275 Slice Flip Flops 253 264 303 303 273 238 4 input Luts 569 583 701 707 629 493 Clk ≤ 4 1 80 64 1 1

Detecting Speed In this paper, the designed monitoring hardware

runs in parallel with the processor. The detecting speed of the monitoring hardware can not completely match to the processor, which will result in a performance impact. Once the processing speed of the monitoring hardware is lower than the processor, the processor should be freeze. In our scheme, as in Table 2 Clk shows, the control flow behavior validation (F&B) employs little performance overhead. It takes at most 4 cycles to calculate the entry of next possible basic block. The main overhead is from the Code Integrity validation. The SHA-1 algorithm takes 80 FPGA cycles to finish the main operation. The SHA-256 is a little better, it takes 64 cycles. The application data is highly dynamic, if its execution is paused, the processor performance can be affected greatly. In order to meet the temporal requirements, a 32-bit CRC is chosen for substitution. This CRC hardware unit is implemented in combination circuit, and it takes only a single cycle to accomplish the calculation. Each basic block contains different number of application instructions. So, we use a parallel 512 input CRC. The basic blocks are imposed a limit length so that any one who excesses the limitation must be separated into sub-blocks and an XOR of the hash values are checked. The cache line is 128 bits, so the data integrity validation uses a parallel 128 bits CRC. Once the runtime state is calculated, the compare unit can accomplish the comparison in 1 cycle.

Security and Overhead Tradeoffs SHA-1 and SHA-256 are both considered to be

the safe hash algorithms so far. Given a message x and its hash H(x), it is computationally infeasible to find another message y such that y ≠ x and H(y)=H(x). But SHA-1 and SHA-256 incur a long delay. CRC32 is a substitution which has a lower security but a faster calculation speed and shorter width. The probability of injecting instructions randomly which would result in the same SHA-1, SHA-256 and CRC32 is 1/2160, 1/2256 and 1/232 respectively. The application code is known after the compilation, so the security demand must be high. However the application data is dynamic, the CRC algorithm will be all right in this detecting system.

Conclusions The proposed CHCDP relies on the compiler to

generate the monitoring model at compile time; and the hardware monitor verifies the execution trace at runtime. CHCDP doesn’t change the compiler or the existing instruction set. So it imposes no restriction to the software developer. The structural design is implemented on an actual OR1200-FPGA platform. Different security schemes are formulated to meet the tradeoffs between overhead and security. The experimental results show that the CHCDP can protect from a wide variety of attacks with hardware design and reasonable overhead loss.

7.E.2-8

References [1] Abadi, M.Budiu, U.Erlingsson, J.Ligatti. Nov. 2005, Control-Flow Integrity Principles, Implementations, and Applications, In ACM Conference on Computer and Communication Security (CCS) (Alexandria, VA,), pp. 340–353

[2] C. Cowan et al., Jan. 1998, StackGuard: Automatic adaptive detection and prevention of buffer overflow attacks. in Proc. USENIX Security Symp, pp. 63-77.

[3] Aucsmith D, 1996, Tamper resistant software: An implementation, in Information Hiding: 1st Int. Workshop (Lecture Notes in Computer Science), vol. 1174, R. J. Anderson, Ed. Berlin, Germany: Springer-Verlag, pp.317–333

[10] Fei Yunsi, Jerry Shi Z, 2007, Microarchitectural support for program code integrity monitoring in application-specific instruction set processors, Proceedings -Design, Automation and Test in Europe, pp.815-820

[5] G. E. Suh, D. Clarke, B. Gassend, M. van Dijk, and S. Devadas. June 2003, AEGIS: Architecture for tamper-evident and tamper resistant processing, In Proc. Int. Conf. on Supercomputing, pp.160–171

[6] X. Zhang, L. Doorn, T. Jaeger, R. Perez, , and R. Sailer, Sept. 2002, Secure coprocessor-based intrusion detection, In Proc. ACM SIGOPS European Wrkshp, pp.239-242

[7] Arora Divya, Ravi Srivaths, Raghunathan Anand; Jha Niraj K, December 2006, Hardware-assisted run-time monitoring for secure program execution on embedded processors, IEEE Transactions on Very Large Scale Integration (VLSI) Systems, v 14, n 12, pp 1295-1308

[8] Gelbart Olga, Leontie Eugen, Narahari Bhagirath, Simha Rahul, March 2009, A compiler-hardware approach to software protection for embedded

systems, Computers and Electrical Engineering, vol 35(n2), pp315-328.

[9] Fiskiran A.M, Lee R.B., Oct. 2004, Runtime execution monitoring (REM) to detect and prevent malicious code execution, Computer Design: VLSI in Computers and Processors, ICCD, pp. 452 – 457

[10] Arora Divya, Ravi Srivaths, Raghunathan Anand, Jha Niraj K., May 2007, Architectural support for run-time validation of program data properties, IEEE Transactions on Very Large Scale Integration (VLSI) Systems, v 15, n 5, pp.546-559,

[11] Gelbart Olga, Leontie Eugen, 2008, Narahari Bhagirath, Simha Rahul, Architectural support for securing application data in embedded systems, IEEE International Conference on Electro/Information Technology, pp.19-24

[12] Elbaz Reouven, Torres Lionel, Sassatelli Gilles, Guillemin Pierre, Bardouillet Michel, Martinez Albert, 2006, A parallelized way to provide data encryption and integrity checking on a processor-memory bus, Design Automation Conference, pp. 506-509

Acknowledgment This research is supported by Astronautic

innovation Fund and Key Fund, Astronautic support Fund, and the National Science Foundation of China (Grant No. 60973106).

Email Addresses Xiang Wang: wxiang@buaa.edu.cn Chunguang Bu: bcgbest@163.com

28th Digital Avionics Systems Conference October 25-29, 2009