Provides customizable obfuscation framework for FPGA bitstreams, with support for both Intel and AMD FPGA primitives. Supports BLIF parsing and verilog/BLIF output. Can be used as a standalone framework, or customized to integrate with another framework.
This project is built upon work originally conducted by Professor Robert Karam while at University of Florida (UF) [1][2]. Once I started working with Dr. Karam at University of South Florida (USF) in Spring 2018, I continued his work by investigating means of tuning and optimizing the existing framework for FPGA bitstream obfuscation. We found that, by optimizing the LUT selection and partitioning strategies, we were able to achieve optimal levels of security -- in terms of functional mismatch -- with minimized overheads in area, power and delay. Further, we integrated the first practical FPGA-based SAT Attack countermeasure with this approach, and published these in a paper in the ACM TODAES journal [3]. Most recently, we devised a method of replacing the obfuscation function with an HMAC which cryptographically ties the obfuscation approach to the design -- allowing proof of ownership and device authentication [4].
Feel free to use this project as you see fit and adapt it to your own purposes. If you are using this software tool to aid in research endeavors, we kindly ask that you cite our paper [3] where appropriate, thank you!
- Python 3+ (No extra libraries required)
To get a local copy up and running follow these simple steps.
-
Clone the repo
git clone https://github.com/BrooksOlney/FPGA_Obfuscation.git
-
(Optional) Import ObfuscationEngine as top module into your own python script to access the core functionality of the framework.
-
Use ObfuscationEngine.py in a command line interface.
Use this tool to obfuscate your FPGA IP cores by exporting them to BLIF format (for example from Quartus Prime II), and importing them as BLIF into the framework before applying custom obfuscation functions to varying portions of your hardware design.
To see a list of the command line arguments and possible values, run python ObfuscationEngine.py -h in your terminal. The output will look like this:
python .\ObfuscationEngine.py -h
usage: ObfuscationEngine.py [-h] [-i I] -vFiles VFILES VFILES [-op OP]
[-sat SAT] [-blif BLIF] -m M -v V
required arguments:
-i I Input BLIF file: -i {ckt_name.blif}
-vFiles VFILES VFILES
Verilog output filenames: -vFiles ckt.v ckt_secured.v
-m M FPGA manufacturer (for verilog primitives): -m
{xilinx/altera}
-v V Verilog Output Type: -v {comb, lutprim}
optional arguments:
-op OP Percentage of design to obfuscate: -op {float(0.0,
1.0]}
-sat SAT Implement SAT Attack resilience for the circuit: -sat
-blif BLIF BLIF ouput filename: -blif {ckt_name.blif}
As the prompt suggests, you must provide arguments for the input BLIF file, 2 names for the output verilog files, name of the target FPGA manufacturer, and the verilog output type. These arguments are necessary to instantiate the ObfuscationEngine and allow it to parse your circuit and enable obfuscation and output generation.
Additionally, there are a few optional arguments that tune the functionality of the framework. The obfuscation percentage (-op) controls how much of the design will be obfuscated by the engine. The SAT Attack argument (-sat) will integrate additional SAT hardening circuitry with your design. Finally, the BLIF (-blif) argument will output your obfuscated design to a BLIF file which is useful for tools such as ABC and the SAT Attack tool itself for verification purposes.
We've laid out how the arguments work, let's go over a small example. Let us consider a (hypothetical) soft processor core that we have constructed and tested in verilog. We have chosen to secure it by obfuscating a critical portion of the processor - the ALU4 unit. First, we have to convert the verilog implementation of our ALU4 circuit to a BLIF file.
The BLIF conversion can be done a few different ways; the first way (which we actually did in the paper) was by adding an obscure directive to the Quartus project configuration file, causing it to crash and output a BLIF reprentation of the circuit. Currently do not have documentation for this feature, pending. The other way would be to use a tool like ABC which supports many different logic synthesis and input/output functions.
Now that you have the BLIF representation of your circuit, you can make additional considerations about how you wish to secure your design. Let's say for this example, we want to try obfuscating roughly 50% of the ALU4 circuit while integrating SAT Attack resilience. Further, let's assume that we want to output the design in verilog with Altera's LUT primitive format. The appropriate command would look something like this:
python ObfuscationEngine.py -i alu4.blif -vFiles alu4.v alu4_secured.v -op 0.50 -sat -v lutprim -m alteraThe tool will implement the techniques described in [3] and output to the paths you have provided.
Of course if you're savvy enough, you can dig into the code, import it into your codebase and tailor it to your needs!
Distributed under the MIT License. See LICENSE for more information.
Brooks Olney - brooksolney@usf.edu
Project Link: https://github.com/BrooksOlney/FPGA_Obfuscation
[1] R. Karam, T. Hoque, S. Ray, M. Tehranipoor and S. Bhunia, "Robust bitstream protection in FPGA-based systems through low-overhead obfuscation," 2016 International Conference on ReConFigurable Computing and FPGAs (ReConFig), Cancun, 2016, pp. 1-8, doi: 10.1109/ReConFig.2016.7857187.
[2] R. Karam, T. Hoque, S. Ray, M. Tehranipoor and S. Bhunia, "MUTARCH: Architectural diversity for FPGA device and IP security," 2017 22nd Asia and South Pacific Design Automation Conference (ASP-DAC), Chiba, 2017, pp. 611-616, doi: 10.1109/ASPDAC.2017.7858391.
[3] Olney, B., and Karam, R. Tunable FPGA Bitstream Obfuscation with Boolean Satisfiability Attack Countermeasure, ACM Transactions on Design & Automation of Electronic Systems 25, 2 (Feb. 2020).
[4] B. Olney and R. Karam, "WATERMARCH: IP Protection Through Authenticated Obfuscation in FPGA Bitstreams," in IEEE Embedded Systems Letters, doi: 10.1109/LES.2020.3015092.