Automatic Generation of Hardware Sandboxes for Hardware Trojan Mitigation in Systems on Chip

Speaker:  Christophe Bobda – Gainesville, FL, United States
Topic(s):  Architecture, Embedded Systems and Electronics, Robotics

Abstract

Embedded systems operate at the heart of many systems such as planes, unmanned aerial systems (UAS), autonomous ground vehicles, communication systems, and weaponry. The design of embedded systems is a complex undertaking that involves various teams of hardware and software designers. The trend towards miniaturization provides opportunities to integrate more functions on a small footprint, which poses major challenges in design, verification, and security. Component (IP) based design is one the preferred method to tackle system complexity, and reduce costs and time-to-market.  In this process, major parts of the IP design and IC production are outsourced to facilities distributed across the globe, thus opening the door for malicious component (Trojan) insertion. While hardware Trojans have gained a lot of attention recently, software Trojans have been a matter of concern in software during the last few decades and continue to be a treat in computing systems. Hardware Trojans can be inserted in hardware at any stage of the IP integration process (3PIP), including the specification, design, verification, and manufacturing stages. Software Trojans, however, can be planted more easily in large and complex program code, thus making them more difficult to detect and purge. 
 
Hardware Sandboxing was introduced in 2015 as as a means to overcome the shortcoming of traditional static Trojan mitigation methods, which uses intense simulation, verification, and physical tests to detect the evidence of malicious components before system deployment. Hardware sandboxing is a generalization of existing run-time approaches that are limited checkers to monitor signal behavior and detect potential Trojans. Hardware sandboxing is enforced through a partitioning of the system into a trusted area and a non-trusted area. Components in the trusted area are designed under strict control of a system integrator such as the military and its trustworthy partners. These components are assumed to be safe and can access any system resource. Components in the non-trusted area are designed by non-trusted contractors, and because they may contain Trojans, are placed in a sandbox along with virtual resources they need to run.  

The feasibility of hardware sandboxing was proven in our work in the summer of 2015 with case studies and real-world applications. However, manual design was used and no method was proposed to automate the design process of system-on-chips that incorporate hardware sandboxes to provide a high-level of security in embedded systems. In this talk, we will discuss design methods for automatic generation of hardware sandboxes in system-on-chips. The proposed approach assumes the traditional component-based system-on-chip (SoC) design, extended with the sandbox specification and generation portion. Systems are assembled from instances of communicating IP through various channels and protocols that are modeled using interface automata (IA) formalism. In addition, the properties specification language (PSL-SERE) is used to define interaction rules and non-authorized behavior of components in the sandbox. We will present a framework called CAPSL (Component Authentication Process for Secure Layers) that provides a way for designers to specify their IA and PSL and translates these descriptions into a single extended interface automaton. It then generates all the resources needed for an isolated execution of the component in the sandbox, including virtual resources, controller and configuration register.

About this Lecture

Number of Slides:  49
Duration:  40 minutes
Languages Available:  English
Last Updated: 

Request this Lecture

To request this particular lecture, please complete this online form.

Request a Tour

To request a tour with this speaker, please complete this online form.

All requests will be sent to ACM headquarters for review.