Security Assumptions and Types of Attacks

Get Complete Project Material File(s) Now! »

Chapter 2 Literature Review

This chapter covers background topics and related work that pertain to this thesis. It begins with a general discussion of FPGAs, and follows with dynamic partial reconfiguration, bitstream manipulation, and related security issues.

FPGAs

FPGAs are semiconductor devices containing both programmable logic and programmable interconnects. Unlike ASIC (Application Specific Integrated Circuit) devices, an FPGA’s function is not known at the time of manufacturing. Furthermore, the function defined by the FPGA’s configuration can be changed as many times as desired. Though generally slower than ASICs because of their reconfigurability, FPGAs have several advantages including shorter time to market, reusability, rapid prototyping and debugging on the target hardware, and in-field updates [27]. Moreover, FPGAs offer the advantages of dynamic and partial reconfiguration [28]

Dynamic Partial Reconfiguration

Reconfiguration can be divided into two sub-categories, static and dynamic [29]. Static reconfiguration implies that a device is configured once at the outset, after which it does not change during the execution of the task at hand. Dynamic reconfiguration allows the device’s configuration to change at any moment, enabling the device to adapt within changing environments. Furthermore, dynamic partial reconfiguration allows for only a portion of the configuration to change. Recent applications such as [30] demonstrate that dynamic partial reconfiguration offers the advantage of reduced silicon utilization by allowing the device to only be configured with the appropriate functionality for the current conditions. Two other areas of interest made possible by dynamic partial reconfiguration are evolvable hardware [31,32] and fault-tolerance [33].
The following sections develop the concept of dynamic partial reconfiguration in stages. First discussed are the advantages run-time reconfiguration provides. The second section addresses partial reconfiguration and its difficulties. The final section introduces the concept of self-reconfigurability

Run-time reconfiguration Advantages

Run-time reconfiguration (RTR) is the process of reconfiguring the FPGA while it is oper-ating. The main advantage RTR offers is the ability to reduce both software and hardware complexity. An example is given in [8] in which a hardware-software interface is optimized using RTR. Software drivers interfacing with register-level hardware are replaced with only static registers in the hardware whose values are altered by reconfiguring the device. Also discussed is the possibility of folding the register values into the design and optimizing the hardware for the given value of the registers. In [8], it is demonstrated that run-time re-configuration can remove the software-hardware interface as well as reduce the amount of silicon needed to implement the design. This methodology can be further expanded to large SoC designs, in which entire systems are replaced during operation using run-time reconfig-uration.

Partial Reconfiguratio

Partial reconfiguration further promotes optimization by offering the ability to modify only a portion of the design. By altering distinct parts of the design, a system implemented on an FPGA can have sections still operating while others are being replaced; however, achieving this functionality has proven to be complex, as partial reconfiguration is a difficult task [34].
Since the 1990s, partial reconfiguration has been of interest to researchers who have demonstrated its usefulness [6,7,9]. Early systems such as the JERC [35] utilize the recon-figurable array of logic cells available on the Xilinx 6200 series devices [4]. These devices allow each logic cell to be individually accessed much like normal computer memory. Un-fortunately, the overhead associated with this type of device does not allow for the FPGAs to have large configuration densities. The Xilinx Virtex series of FPGAs supports partial reconfiguration and provides sufficient capacity for implementing or prototyping complete configurable systems [36]. Unlike the 6200 series, the smallest addressable unit on the Virtex FPGAs is a frame. Each frame may contain configurable logic blocks (CLBs), input-output blocks (IOBs), block RAMs (BRAMs), clock resources, programmable routing, and config-uration circuitry [37]. The FPGAs are configured using a bitstream that contains the data for each frame. Partial reconfiguration requires the creation of partial bitstreams that work with the frame-based architecture.
Several contributions have been made toward refining the procedure of partial bitstream creation. In the application of JRTR [38], a host computer controls the reconfiguration pro-cess. The configuration is altered in a Java application, which ultimately uses JBits [39] to manipulate the original configuration bitstream and create a partial bitstream. Due to the low-level at which JBits operates, other solutions have been developed that provide abstrac-tion for the designer. In the implementation of Dynamic Hardware Plugins (DHP) [40], the PARBIT tool [34] is used to alter the configuration. Though still operating at the bitstream level, the PARBIT tool extracts the configuration bits related to an area defined by the user in order to create the partial bitstream. This allows the user to define the configuration changes at a higher level of abstraction.
Further experimentation has been conducted so that the designer may create partial bitstreams at the modular level. Designs specified behaviorally–by functionality as opposed to a specific hardware structure–are often broken up into modules. Each module can describe various functioning segments of the design. Partial creation at the modular level often allows for modules to be specified as static or dynamic. The compilation tools in [13] evaluate a design and distinguish reconfigurable regions. The regions are identified when two or more modules drive the same output. The tools not only provide partial bitstream development at the modular level, but also work toward making it an automated process.
Xilinx has also increased its software tool support for partial reconfiguration. Xilinx offers two partial reconfiguration flows as part of their build sequence [41]. The module-based flow is more applicable when large blocks are to be reconfigured. It allows for modules to be constrained to specific areas of an FPGA. The specific area can be partially reconfigured, effectively changing the functionality of the constrained module. This also allows a designer to know what functionality is being manipulated when reading back or modifying a particular section of the design. Mastering module-based flows is an area of current research, as recent works [42,43] have sought new ways of simplifying the process.
The second flow, the difference based flow, allows a designer to make small changes to the design, usually in FPGA Editor [44], and generate a partial bitstream based on the differences between the two designs [45]. In this thesis, this method is used to create the partial bitstreams that test the system by simulating a fault injection attack. This method is preferred in this thesis because the small changes resemble the bit manipulations an attacker might make to the currently running functionality rather than completely loading a new functionality as is usually done in module-based partial reconfiguration

Self-Reconfiguration

The manner in which an FPGA is configured with a partial bitstream is another important area of research. Oftentimes, configuration is done off-chip using a host processor. As dynamic partial reconfiguration becomes more feasible for real world applications, area and cost factors make the dependency on a host computer an unattractive consideration. Self-reconfiguration allows configuration control protocols to be implemented in user logic. This enables a module that determines what configuration should be implemented as well as the configuration controller to be within an FPGA; it allows the device to be in control of its own functionality.
An application of partial self-reconfiguration is developed in [46]. A Xilinx Virtex-II FPGA is reconfigured through the Internal Configuration Access Port (ICAP) using bit-streams stored in the FPGA’s Block RAM (BRAM). The implementation demonstrates many benefits of self-reconfiguration, including flexibility in both configuration methods and media sources as well as security considerations. Partial self-reconfiguration could be used to help an FPGA defend itself from malicious attacks. The system presented in this thesis will be running on the FPGA that is susceptible to attack. Should the FPGA configu-ration become corrupted, the system will detect the alteration and the FPGA itself will know that it has been compromised. As will be discussed in Section 5.5, the system could also request partial bitstreams to reconfigure and repair the altered area. Partial run-time self-reconfiguration can allow the system to defend itself in the event of an attack

Bitstream Manipulation

As described earlier, bitstream manipulation can be used for partial bistream generation. Due to its tedious nature, the usefulness of bitstream manipulation compared to other meth-ods of partial bitstream creation may be questioned; however, its low-level access can be appealing because the regular tool chain may be bypassed entirely, allowing for faster generation of partial bitstreams.
Mentioned previously, JBits [39] is one of the better known bitstream manipulation tools. It is a set of Java classes that provide an Application Programming Interface (API) to manipulate Xilinx configuration bitstreams. JBits can be used to quickly alter details as minute as look-up table (LUT) contents. Its features can also be used to check the state of elements using configurations readback from the FPGA. Additionally, other applications such as REPLICA [47] have found different and sometimes quicker methods. REPLICA is an extension of PARBIT [34]. Acting like a filter, it reduces the overhead of PARBIT by allocating the bits for a dynamic area while programming the target FPGA.
Knowledge of the configuration at the bit-level is also important for security considera-tions. As will be discussed in the Section 2.4, certain attacks and thus their corresponding protection strategies can utilize bit manipulation of the configuration. Unfortunately, de-signing a system that will use bitstream manipulation is difficult. The challenges arise from a lack of information about the structure of the bitstream. In order to protect intellectual property and to hypothetically enhance configuration security, FPGA manufacturers are reluctant to release information pertaining to the architecture of the bitstream.
The necessity of this information is shown by the Alternate Wire Database (ADB) [48] tool in which Xilinx proprietary files, as well as information from JBits, are required. ADB is an application that can interface with JBits to provide routing, unrouting, and tracing services. Its wiring services are helpful when exhaustive wiring support is needed [48]. Though some details needed to do such a task can be derived from Xilinx’s documentation on the Virtex Series Configuration Architecture [37], this information is primarily intended for reading and manipulating BRAM and LUT contents and is therefore insufficient for general logic and routing configuration [27]. Furthermore, information pertaining to or applications using bitstream manipulation have not targeted newer families such as the Virtex-4 and Virtex-5

1 Introduction 
1.1 Motivation
1.2 Contribution
1.3 Thesis Organization
2 Literature Review 
2.1 FPGAs
2.2 Dynamic Partial Reconfiguration .
2.3 Bitstream Manipulation
2.4 FPGA Security
3 Design Considerations 
3.1 Security Assumptions and Types of Attacks
3.2 Attacker Classification
3.3 Proposed Design .
4 Implementation 
4.1 Platform
4.2 On-chip Configuration Integrity Checker
4.3 Partial Authentication and Reconfiguration
4.4 Challenge-Response Protocol
5 Results and Analysis 
5.1 Operation Verification
5.2 Device Utilization
5.3 Timing Analysis
5.4 Security Analysis .
5.5 Run-time Repair and Checking Granularity Considerations
6 Conclusion 
6.1 Summary
6.2 Future Work
Bibliography
GET THE COMPLETE PROJECT