Die Embedded Security Gruppe bietet nach individueller Rücksprache weiter Bachelor- und Masterarbeiten mit Themenschwerpunkten FPGA Security, Hardware Reverse Engineering sowie Physical-Layer Security an. Vorkenntnisse im Bereich Kryptographie, algorithmische oder VHDL Grundlagen oder Drahtloskommunikation sind erwünscht, jedoch nicht zwangsläufig nötig.
Anfragen zu Abschlussarbeiten sind an die Kontakt-Emailadresse emsec+BA_MA@rub.de zu richten. Wir bitten um ein kurzes Anschreiben (einige Worte zur eigenen Person, Stärken/Schwächen, Motivation,…) sowie einen aktuellen Notenspiegel.
Open positions (BA/MA/SHK/WHB) on FPGA Security
FPGAs are reconfigurable devices used in all sorts of security-relevant applications. Hence, securing their boot process and loading their configuration — the so-called bitstream — is of utmost importance for a secure system. Internally, the bitstream configures all basic elements like LUTs and FFs and the routing between them. For most commercially available FPGAs, the bitstream encoding and its security features are proprietary.
Our latest research discovered several flaws in the bitstream protection of Xilinx FPGAs [1, 2, 3]. To foster our research, we are looking for your support and would like to welcome you to our team as a WHK/SHK or as part of a BA/MA thesis. Please feel free to contact us (Felix Hahn or Maik Ender) to discuss these topics, whatever your course or stage of study is.
Potential projects on FPGA security can be clustered in the following two general topics: fuzzing of FPGA configuration engines and general bitstream security.
[1] https://www.youtube.com/watch?v=IBhOKS9Cdms[2] https://ieeexplore.ieee.org/document/9786118
[3] https://tches.iacr.org/index.php/TCHES/article/view/11435
Fuzzing FPGA Configuration Engines
While fuzzing is a well-established technique in the software domain, it is not well-explored on hardware. Your objective would be to work with our fuzzing framework, ConFuzz [1], or explore new techniques on devices from vendors other than Xilinx.
[1] https://github.com/emsec/ConFuzz- LLM-guided Configuration Engine Fuzzing
We want to explore the possibilities of training an LLM with the structure of bitstreams [1, 2, 3, 4]. The goal is to use the LLM to generate suitable bitstreams for our fuzzing framework, ConFuzz. Additionally, we want to explore using NLP to process the available documentation and further improve test case generation.
[1] https://arxiv.org/abs/2404.16297
[2] http://arxiv.org/abs/2406.07714
[3] https://www.ndss-symposium.org/ndss-paper/large-language-model-guided-protocol-fuzzing/
[4] https://www.usenix.org/conference/usenixsecurity23/presentation/wang-dawei/ - Fuzzing with side channels
You would use power side channels or other state-of-the-art techniques to enhance our view into the configuration engine’s state. - Advanced analysis methods/better GUI
The data acquisition phase during our fuzzing campaign and the subsequent analysis should be enhanced by connecting it to a database and building an improved web interface. - PCAP fuzzing on Zynq Ultrascale(+)
Explore the possibility of porting our fuzzing framework, ConFuzz, directly to the ARM processor on a Zynq FPGA to enhance the fuzzing speed. - Automated fuzzing and/or automated recovery of the state machine
Currently, we use manual analysis techniques for fuzzing results. Your task would be to optimize and automate this using state-of-the-art fuzzing techniques. - Fuzzing the Xilinx JTAG Controller
The JTAG controller has some advanced security features, which might be exploitable to attack the bitstream security.
Reverse Engineering & Securing Bitstreams
The vendor’s tools are a one-way street, as they generate only the bitstream from the netlist (an intermediate product in synthesizing hardware — we will guide you through the jungle of hardware ;)). Thus, these tools do not provide any way back from a given bitstream to netlist, but with our work [1] and open-source projects [2, 3], we can understand the bitstream format for certain FPGAs pretty well. However, these methods should be developed further and applied to other vendors. Advanced questions can be raised after understanding the bitstream format, such as how can we formally verify the bitstream encryption?
[1] https://dl.acm.org/doi/10.1145/3287624.3288742[2] https://f4pga.readthedocs.io/projects/prjxray/en/latest/
[3] https://fpga-interchange-schema.readthedocs.io/index.html
- Bitstream format reverse engineering (SHK/WHK)
Our current methods should be developed further to better understand the bitstream format. You will continue to develop our existing tools and methods in a project with our research colleagues from UMass Amherst. - Xilinx UltraScale(+) PIP reversing
While the bitstream format for Xilinx UltraScale(+) is mostly reversed, the routing details remain unknown. Your task would be to implement a tool to use the available Xilinx tools to reverse the PIP structure. - Bitstream format reversing of further vendors and FPGA families (BA/MA)
Besides our current framework for reverse engineering bitstreams, other vendors and families are of interest. You would develop a technique to reverse bitstreams using state-of-the-art methods [1, 2, 3].
[1] https://ieeexplore.ieee.org/document/10035199
[2] https://github.com/epfl-vlsc/bitfiltrator
[3] https://www.mdpi.com/2079-9292/7/10/246 - Software reverse engineering in FPGA security
Software is used all over the FPGA life cycle. A better understanding of this cycle is necessary for a comprehensive security analysis. Therefore, your reverse engineering skills would help us delve deeper into this cycle. - Verifiable Bitstream Protection
Formal methods proved to be effective in preventing architectural and protocol flaws in the first place. Your task would be formally verifying an (open source) bitstream protection engine (in HDL). - Analyzing Xilinx Zynq Security Features
Xilinx Zynq SoCs combine an FPGA with an ARM CPU. Its boot process is different from that of traditional FPGAs. A dedicated CPU core manages the security and configuration of all Zynq devices. Your task would be to analyze the security of the boot process. For example, CVE-2021-27208 [1, 2], CVE-2021-44850 [3, 4], and CVE-2022-23822 [5, 6] would be good starting points for the topic.
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27208
[2] https://blog.ropcha.in/part-3-zynq-cve-2021-27208.html
[3] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44850
[4] https://blog.ropcha.in/part-4-zynq-cve-2021-44850.html
[5] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23822
[6] https://eprint.iacr.org/2023/1913