Anomalous path detection with hardware support

Abstract

Embedded systems are being deployed as a part of critical infrastructures and are vulnerable to malicious attacks due to internet accessibility. Intrusion detection systems have been proposed to protect computer systems from unauthorized penetration. Detecting an attack early on pays off since further damage is avoided and in some cases, resilient recovery could be adopted. This is especially important for embedded systems deployed in critical infrastructures such as Power Grids etc. where a timely intervention could save catastrophes. An intrusion detection system monitors dynamic program behavior against normal program behavior and raises an alert when an anomaly is detected. The normal behavior is learnt by the system through training and profiling.However, all current intrusion detection systems are purely software based and thus suffer from large performance degradation due to constant monitoring operations inserted in application code. Due to the potential performance overheads, software based solutions cannot monitor program behavior at a very fine level of granularity, thus leaving potential security holes as shown in the literature. Another important drawback of such methods is that they are unable to detect intrusions in near real time and the time lag could prove disastrous in real time embedded systems. In this paper, we propose a hardware-based approach to verify program execution paths of target applications dynamically and to detect anomalous executions. With hardware support, our approach offers multiple advantages over software based solutions including minor performance degradation, much stronger detection capability (a larger variety of attacks get detected) and zero-latency reaction upon an anomaly for near real time detection and thus much better security.

Architectural Support for Run-Time Validation of Control Flow Transfer

“…This, together with its sophisticated cache management algorithm, causes considerable memory overhead (3.02MByte vs 512Kbit hardware memory) and performance degradation (up to 170% vs 7.7%) comparing to our solution. Another similar work [25] also validates control flow transfer in hardware. But it mainly focuses on direct jumps and uses a sophisticated co-processor.…”

“…Also, during the software testing and development phase, the test cases being used should cover most, if not all, possible execution paths for each branch; therefore an IBP table can be generated as a side product. The second way to initialize the IBP table is to perform "training" as many model-based solutions have done [10][11] [25]. By running the application either in a particular time interval or until the unique IBPs converges in a secure environment, the processor can regard all seen IBPs as legitimate ones.…”

A low overhead hardware technique for software integrity and confidentiality

“…The SICM mode makes creation of meaningful arc injection attacks much more difficult, but it does not prevent them. Complete protection from such attacks may be provided by using a dedicated resource to store allowed targets of indirect jumps and a secure stack [8], or by using data encryption.…”

Off-Chip Control Flow Checking of On-Chip Processor-Cache Instruction Stream

“…It has been extensively studied for applications in fault tolerance [4,5,8,9,10,11,12,13,14,16] and computer security [1,2,18]. CFC techniques are either implemented in hardware using an on-chip monitor or watchdog processor (WP) [2,4,5,8,9,10,11,13,14,18] (or equivalently, an off-chip WP in systems without on-chip caches) or in software [1,12,16]. Hardware implemented CFC using on-chip WPs have the advantages of potentially low performance overheads, but also the disadvantage of imposing appreciable processor chip-area overhead that can indirectly lower performance (some high-performance enabling hardware has to be left out when the die area is a constraint) or result in higher cost (due to increased die area).…”

“…Hardware implemented CFC using on-chip WPs have the advantages of potentially low performance overheads, but also the disadvantage of imposing appreciable processor chip-area overhead that can indirectly lower performance (some high-performance enabling hardware has to be left out when the die area is a constraint) or result in higher cost (due to increased die area). Software-based CFCs can work with any commodity processor but have the disadvantage of high performance overheads, as well as vulnerability to security attacks [18]. In this paper, we develop techniques for off-chip hardware-based CFC that have little of the above disadvantages of on-chip and software techniques, but have most of their advantages.…”