Secure Embedded Processing through Hardwareassisted Runtime Monitoring Zubin

Secure Embedded Processing through Hardware-assisted Run-time Monitoring Zubin Kumar

Introduction � Security compromised by execution of "trusted" software - unintended program behavior, info leakage. � Embedded software content development around 140% per year (faster than Moore's Law). Thus most security attacks are software based. � Most software attacks exploit the weakness of trusted code or application. (Buffer overflow). 2

� Security considered at various stages of embedded systems - system architecture, hardware and software. � Hardware assisted run - time monitoring system to detect unintended program execution - static program analysis to allow permissible run - time behavior � Program properties captured - inter/intra procedural control flow, instruction integrity checker. � Methodology to design application - specific hardware monitors. 3 � Why Hardware assisted monitoring?

Secure program checking categories � 1) Static checking, 2) Software based program monitoring, 3) Hardware unit for secure execution. 1)Static checking - scan tools used to eliminate weakness in software in design phase. . Rule based and limited by known cases of weaknesses. . . 2)Software based program monitoring - authors provide formal specification for execution trace, violations checked by comparing execution trace. Monitoring software embedded in system. . Monitoring by software so this is again vulnerable, 4

3)Hardware monitor unit - may have encryption and decryption algorithms to verify source of input data. Can also have trace of application to prevent unintended behavior � New approach - Merge static checking of program behavior with run - time monitoring using hardware. 5

Block Diagram of Hardware-assisted Monitor 6

� 5 stage pipelined processor, monitor inputs - IR and PC address. � Monitor outputs - stall (if monitor cannot keep pace with processor execution), invalid (if security breached, unmaskable interrupt to trigger security mechanisms). � Monitor checks for program properties - inter/intra procedural control flow, instruction integrity checker. These basic properties are violated in unintended execution, chosen because concise, scalable, little overhead in monitoring. � Two modes for flagging invalid behavior in inter/intra procedural check - 1) Detection mode - processor is allowed to continue while the monitor is running and is stalled only if an instruction completes before the previous control 7 instruction has been verified. 2) Prevention mode - no new instruction is allowed to

Inter procedural control flow - to check between different procedures in a program (coarse grained) � Implemented as FSM with N+1 states. � N states for states in N functions in a program. � +1 state for invalid transition check. � If control goes between any of the N states via valid call/returns then control valid, else for invalid call/return, invalid state (+1 th state). 8 � Validity of call/return checked via program trace.

Intra procedural control flow logical succession of inter procedural check, to check inside a procedure (fine grained) � Implemented as Block Information Table. � Function divided into blocks - each block has row in Information Table. � For blocki, rowi<index, offset, s 0, s 1>. index = block index, offset = starting address of blocki w. r. t. function, s 0, s 1 = where the control should go from blocki 9 (only 2 block exits).

Instruction Integrity check - (finer grained) � Intra procedural check is not fool proof as a block can still be altered without any immediate effect to control flow. � Integrity check complements intra procedural control flow. � Integrity of dynamic instruction stream checked using Hash functions - "Given a message x and its cryptographic hash H(x), it is computationally infeasible to find a message y such that y != x but H(y) = H(x)". 10

� Hash calculation is intensive so values for each block's instruction, Hash computed before hand saved using a dedicated processor for Intra procedural stage. � Hash values matched between Intra procedural stage (already saved), Integrity check stage. � Hash values calculated for Integrity check stage using Hash engine. Latency of hash computation does not permit stalling the processor for each instruction. Processor and Hash unit run in parallel and processor stalled if only if hash unit buffer is full. � Hash output = 16 to 20 bytes, so for time saving, a fixed number Hash output bits are only matched. 11

Hash Block � SHA-1 hash function block. � A, B, . . . , E are words, F is non linear function, <<<n denotes left bit rotation by n, Wt and Kt are constants. 12

Hardware Architecture of Monitor 13

� The Inter/intra procedural checks and integrity checks are logically independent, but they share hardware and need to communicate with each other. � The execution trace is extracted and loaded onto monitor before executing application. User options can be set to control configuration of execution trace to be loaded. 14

Design Impacts � Area overhead increases with the monitor system. Largest area overhead from Inter procedural control flow block. However, efficient S. o. C. implementations of monitor can reduce this. � If on chip memory used to store monitor's execution trace, performance degradation is less as compared to when off chip memory is used. 15

CPI for off chip memory execution trace even in this case, the impact is fairly small (average of 1. 77% for detection mode and 4. 94% for prevention mode). 16

Conclusion � Scalable, make monitor configurable for better performance. � Performance and area overheads are not too costly so design is viable. � Using more efficient encryption algorithms instead of Hash. � Has the potential to counter any threat. 17

Thank you. Questions? 18