BaDSeED: Backdoor Detection Systems for Embedded Devices

School of Computer Science
University of Birmingham

Research Project

We live surrounded by an increasing number of embedded devices with computing and (wireless) networking capabilities. We rely on these embedded devices for many critical applications and infrastructure. In most cases, the manufacturing and programming of microcontrollers and field programmable gate arrays (FPGAs) used in embedded devices is outsourced. Indeed, most of these devices are made in factories on the other side of the planet--well beyond our control. But can we trust them? A key problem is that detecting the presence of a backdoor on a chip is an extremely challenging, expensive and time consuming task. This PhD project will address the problem of detecting backdoors in embedded devices. Specifically, building on methods we have recently developed to extract the firmware from embedded devices, we will develop novel techniques to test the software and firmware of embedded devices for the presence of backdoors.

Technical Approach

An important contribution of this PhD will be to develop methods to help indicate when firmware may contain a backdoor. Rather than trying to test if firmware matches its specification exactly (which we do not believe would be practical), we will adapt and develop state of the art software analysis methods to look for indicators of the presence of a backdoor in embedded devices. The most common type of backdoor found so far are hardcoded login accounts. These have been found in many embedded systems of which smart meters [San12] and routers1 are just two examples. More advanced backdoors might add substantial extra functionality to a device, which could be exploited by an attacker. For instance, the ProASIC3 chip which was found to have a backdoor which could be accessed via an on chip web server [SW12] and TURCK BL20 gateway2 had a backdoor accessible via an ftp server. If these chips had no legitimate reason to run a web and ftp server, and the existence of this functionality was not mentioned in their documentation, then the presence of these protocols in the firmware may indicate a backdoor. To detect such backdoors we will develop heuristics that indicate what a particular region of code may be doing, for instance, does it contain strings or sequences of commands that are known to relate to particular encryption algorithms, or network protocols? In the case of particular network protocols, we will also develop techniques that scan the code for possible hardcoded passwords and usernames and try to use them to log in. Another type of backdoor we will search for is a backdoor that allows the expected control flow or information flow to be interfered with. Continuing with the example of an iris scanner gate, if this gate was only suppose to open on the presentation of a correct iris scan, or in a particular emergency mode, then any control flow through the program that opens the gate, without going via the code that tests the iris scan or emergency mode, would be suspect and may indicate the presence of a backdoor. Likewise, there should be a clear information flow from the data from the iris scanner along all possible paths: if the details of the key input can be ignored by the device then there is likely a backdoor. We will adapt existing techniques on both static and dynamic information flow analysis e.g. [CBP+13, CKNP13] to look for such flows. In summary: over the course of the studentship we will address the challenge of detecting backdoors in embedded devices in three main steps:

People Involved