Available Thesis Topics

Below is the list of some available topics. If none of the following topics fits you, but you are interested to write your thesis at ImpSec, you may send us an email () by attaching your transcript of records. We will get back to you possibly by some other topics which may better fit to your background.

Motivation:

The application of masking in cryptographic algorithms is a widely adopted strategy for protecting implementations against side-channel attacks [1]. By employing Shamir's secret sharing scheme, each secret variable is divided into multiple shares that are independently and uniformly distributed. This approach ensures that any potential leakage is independent of the original secret. Over the years, numerous variants of masking techniques have been developed, each optimized for different objectives. However, all of these methods share a common requirement: they rely on uniform randomness for the initial sharing of secrets and, in some cases, during the computation of the masked algorithm (often referred to as online randomness). This need for randomness is particularly critical in hardware masking schemes, which consume significant amounts of random bits per cycle due to their parallel architecture. Recent research has begun to address the need for efficient hardware pseudo-random number generators (PRNGs) to supply the required randomness for masked hardware implementations [2]. However, generating randomness in software is also a non-trivial challenge.

Research Question:

Although the demand for randomness in a single clock cycle tends to be lower in software due to its sequential nature, devices may still be heavily constrained in terms of resources. Furthermore, the rapid generation of large quantities of randomness becomes even more crucial when simulating masked hardware designs for testing purposes. In these scenarios, the testing software must generate substantial amounts of randomness, which is then fed into a simulator. For an example, we refer to [3]. Accelerating the generation of randomness would not only speed up the sharing process but also enhance the overall efficiency of the simulation.

Requirements:

  • Structured way of working
  • C/C++ programming
  • Fun in optimizing code

Your Task:

To date, randomness generation has been facilitated by number-theoretic libraries, such as FLINT [4], which serve various objectives. The aim of this work is to develop a software library specifically designed for the efficient generation of random variables in arbitrary finite fields, with particular emphasis on meeting the requirements of hardware masking.

Contact:

If you are interested in this topic, please contact Nicolai Müller ().

Literature:

[1] https://www.iacr.org/archive/eurocrypt2013/78810139/78810139.pdf (opens in new tab)

[2] https://cic.iacr.org/p/1/2/4/pdf

[3] https://tches.iacr.org/index.php/TCHES/article/view/9822/9327

[4] https://flintlib.org/

Motivation:

Side-channel attacks are an ubiquitous threat in embedded devices. By observing physical characteristics, e.g., the power consumption of a device, adversaries are able to recover secret data. The masking countermeasure is an effective solution against side-channel attacks. It is commonly applied on the algorithmic level, i.e., during software implementation. Unfortunately, compilers are known to (partially) remove the security of masking during compilation from high-level code to assembly code. To avoid this from happening, PoMMES-EXTRA was introduced, which implements the register allocation of a compiler backend. The register allocation is crucial for the correctness of code generation and assigns the physical registers of a CPU to the internal representation inside compilers. We added constraints to the register allocation such that the security level of the masking countermeasure does not get degraded during compilation.

Your task:

Currently PoMMES-EXTRA only supports the generation of ARMv6-M assembly instructions. However, we would like to extend the functionality of PoMMES-EXTRA to be able to generate also assembly code which is in line with the ARMv7-M ISA. Therefore your task will be to integrate the distinction and handling of different ARM instruction set architectures in PoMMES-EXTRA. Additionally you should compare the performance of PoMMES-EXTRA between the generation of ARMv6-M and ARMv7-M assembly code.

Requirements:

  • Good knowledge in C++
  • Familiarity with ARM assembly

Contact:

If you are interested in this topic, please contact Jannik Zeitschner ().

Motivation:

Protection against side-channel attacks is crucial in the context of embedded programming. Power side-channel attacks are a powerful attack vector against micro-controller and allow the adversary to retrieve secret data based on the observation of the power consumption during the execution of software. To protect implementations against side-channel attacks we apply the masking countermeasure during the implementation of software algorithms. Usually software is written in a high-level language, e.g., the C language, and then compiled to machine code. As compilers are unaware of side-channel attacks and the concept of masking, they might negatively interfere with the masking countermeasure and remove it during the compilation process. The tool PoMMES-EXTRA prevents this from happening as is places constraints on the register allocation, which is an important backend compiler pass. These constraints aim to inhibit choices during register allocation that might lower the security of masking.

Your task:

Currently only the register allocation is implemented in PoMMES-EXTRA. You should improve the code quality of the generated assembly code by implementing multiple common compiler optimizations into PoMMES-EXTRA. As there are various compiler optimizations we can discuss which optimizations might be interesting and beneficial for the code quality of the assembly code. Afterwards you should compare the performance of the unoptimized assembly code with the optimized variant.

Requirements:

  • Good knowledge in C++
  • Familiarity with ARM assembly

Contact:

If you are interested in this topic, please contact Jannik Zeitschner ().

Motivation:

Electromagnetic fault injection (EMFI) has quickly become a favored technique for inducing faults in integrated circuits (ICs) due to its non-invasiveness and precision. However, there has historically been a lack of detailed understanding of the physical mechanisms by which EMFI causes faults. Recent studies, including [1] and [2], aim to fill this gap by providing a thorough analysis of electromagnetic induction effects on ICs. These works not only explore the theoretical foundations of EMFI but also validate their models through extensive experimentation, demonstrating their effectiveness in predicting fault behavior. In addition to these theoretical approaches, more practical studies like [3] suggest that defining an adversary's strength solely by the number of faults they can inject is unrealistic. To address this limitation, two newer models have been proposed: the Random Fault Model [4] and the Generalized Random Fault Model [5]. These models define an adversary's strength by the probability that injected faults will become active, making them well-suited to account for multiple faults. As a result, these models provide a robust framework for evaluating the resilience of implementations against EMFI, enabling efficient, tool-assisted analyzes of their vulnerability to such adversaries.

Research Problem:

The objectives of this work are (1) to verify a tool currently under development and (2) to define parameters that align the tool's verification process as closely as possible with real-world conditions. This tool evaluates an implementation using the General Random Fault Model [3], simulating an EMFI (Electromagnetic Fault Injection) adversary. Your primary task is to conduct a series of EMFI attacks on both protected and unprotected implementations. Then, compare the outcomes of these practical attacks with the results generated by our tool. Based on these findings, you will propose suitable parameters to characterize various types of EMFI adversaries. If these practical attacks reveal any limitations in our tool or model, you will identify these shortcomings and recommending strategies to address them.

Requirements:

  • Structured way of working
  • Basic knowledge of Hardware Circuits
  • Familiarity with programming or tools to analyze the results (C++, Python, MATLAB)

Contact:

If you are interested, please contact Felix Uhle ().

Literature:

Motivation:

Since Kocher et al.'s early work on Side-Channel Analysis (SCA) attacks [1, 2], protecting cryptographic hardware from SCA has been a major focus of research. Numerous countermeasures, particularly masking [3] based on secret sharing [4], have been proposed to prevent information leakage. Masking [3] is popular for its straightforward security assumptions. To evaluate the strength of masked implementations, it is essential to define the capabilities of potential adversaries. One highly abstract model used for this purpose is the d-probing model [5]. Its high level of abstraction makes it widely used for proving the security of specific designs. However, designing, implementing, and verifying masked circuits remains a challenging and error-prone task, leading to many schemes being found insecure due to overlooked design flaws or incomplete adversary modeling [6, 7]. To address these issues, various tools have been proposed to detect leakage [8, 9, 10, 11, 12, 13, 14]. VERICA[12] and PROLEAD[13] are two tools that verify circuits within the d-probing model. VERICA is exact and based on Binary Decision Diagrams (BDDs), while PROLEAD utilizes a statistical approach based on simulations. The advantage of PROLEAD lies in its simulation-based strategy, which allows it to assess the security of implementations in large and complex designs, particularly in scenarios where transitions must be considered—an area that is not verifiable by VERICA.

Research Problem:

PROLEAD can evaluate large and complex circuits, such as a RISC-V ALU, enabling designers to perform tool-assisted evaluations of their designs. However, while PROLEAD effectively identifies leakage from probing sets, it does not help designers pinpoint the specific reasons for this leakage. This can be addressed by determining the minimal combination or combinations of probes that are leaking. The goal of this work is to implement an efficient strategy for identifying these minimal subsets of probes that cause leakage.

Requirements:

  • Structured way of working
  • Efficient C/C++ programming

Contact:

If you are interested, please contact Felix Uhle ().

Literature:

Motivation:

Hardware platforms play a pivotal role in establishing a root-of-trust in security applications. Reconfigurability can help maintain robust system security throughout a device’s lifecycle, comparable to software. However, physical attacks, such as side-channel and fault-injection attacks targeting cryptographic implementations, might exploit certain characteristics on the hardware level since the circuit behavior is directly influenced by the algorithm design and its realization using physical components in conventional architectures. Ensuring secure implementations on existing general puspose devices is an active and challenging research area, often incurring significant overheads in terms of area and latency. An alternative approach, though more demanding, involves designing reconfigurable platforms specifically for physically secure applications. This concept prioritizes security guarantees, potentially leading to more specialized, yet efficient solutions. One method is to base the platform design on gadget-based masking, i.e., composable subcircuits that provide formal security under a specified model. For such a custom FPGA, the associated toolchain must also be adapted to generate the appropriate bitstream.We are seeking an ambitious student eager to engage with latest research, including work that is still partly unpublished.

Your Task:

Design and implement a physically secure open-source FPGA platform with configurable security order using the FABulous framework [1]. Adapt the toolchain to automatically generate a suitable bitstream for several cryptographic implementations. Ideally, conduct a side-channel analysis by emulation of the custom platform on a real world FPGA.

Requirements:

  • Structured and organized way of working
  • Fundamental knowledge of hardware design and the F4PGA toolchain
  • Basic programming skills in VHDL / verilog and Python\
  • Familiarity with Hardware Masking is a plus

Literature:

Contact:

If you are interested in this topic, please contact Daniel Lammers ().

Introduction:

Fault Injection Analysis (FIA) was first demonstrated on public-key cryptography by Boneh et al. [BDL97], followed shortly by the introduction of Differential Fault Analysis (DFA) [BS97], a class of FIA targeting symmetric cryptography. Since then, a wide range of FIA variants have emerged, including algebraic attacks such as DFA [BS97], Safe-Error Attack (SEA) [SJ00], Ineffective Fault Analysis (IFA) [Cla07], and Fault Sensitivity Analysis (FSA) [LSG+10], as well as statistical attacks like Statistical Fault Analysis (SFA) [FJLT13] and Statistical Ineffective Fault Analysis (SIFA) [DEK+18]. Unlike transient faults caused by environmental factors (e.g., radiation), FIA is adversarial and intentional: attackers exploit faults—induced via laser, voltage glitching, or electromagnetic interference—to corrupt computations and extract secrets.

Traditional countermeasures against FIA attacks rely on either fault detection or fault correction, with their security guarantees typically formalized in the f-threshold fault model [IPSW06]. Tools like VerFi [AWMN20] (simulation-based assessment) and FIVER [RBRSS+21] (symbolic-execution verification) systematically evaluate such implementations under this model.

Impeccable Circuits [AMR+20] addresses a critical limitation of fault-detection schemes: fault propagation, which can undermine error-detection capabilities. Its fault-correction counterpart, Impeccable Circuits II [SRM20], extends this approach to guarantee security within the f-threshold fault model. Impeccable Circuits III [RSM21] unifies both detection and correction, enabling protection against up to f_c correctable faults and f_d detectable faults. Müller et al. [MM24] introduced a framework—called AGEFA—to automatically protect circuits with the approach presented in Impeccable Circuits II.

Research Problem:

While the Impeccable Circuits strategies and AGEFA were originally designed for hardware implementations of cryptographic primitives, this approach faces two fundamental limitations:

  • Immutability: Fabricated hardware lacks post-fabrication flexibility, unless deployed on Field Programmable Gate Arrays (FPGAs).
  • Overhead: Each cryptographic algorithm requires dedicated hardware components, limiting scalability and increasing area costs.

Software-based fault protection offers flexibility and instruction reuse but cannot address faults in hardware components (e.g., Arithmetic Logic Units (ALUs)) and incurs latency overhead due to temporal redundancy (e.g., repeated instruction execution). A hybrid approach—protecting microprocessor hardware (e.g., ALUs) with methods like Impeccable Circuits [AMR+20, SRM20, RSM21]—combines the strengths of both paradigms:

  • Minimized area overhead: Secured low-level operations (e.g., arithmetic/logic units) are reusable across different cryptographic algorithms, reducing redundant hardware.
  • Software-like flexibility: Cryptographic algorithms can be updated or replaced without modifying the underlying hardware, enabling adaptability to evolve standards or threats.
  • Broad fault coverage: Detects hardware-level faults that pure software countermeasures cannot address, ensuring robustness against physical attacks.

This hybrid model bridges the gap between hardware efficiency and software adaptability.

Your Task:

Your task is to protect the Ibex RISC-V Core [1], which is based on the Zero-riscy core [DSCR+17] using AGEFA with the Impeccable Circuits II approach. To achieve this, you must:

  • Adjust AGEFA to support the automated generation of a protected version of the Ibex Core.
  • Extend VerFi to enable security assessments under the f-threshold fault model for the generated and protected Ibex Core.

The primary objective is to guarantee security in the f-threshold fault model. The secondary objective is to optimize the design for area and latency. To meet these goals, you will evaluate the generated designs and iteratively refine AGEFA to reduce the performance overhead.

References:

  • [1] https://github.com/lowRISC/ibex
  • [AMR+20] Anita Aghaie, Amir Moradi, Shahram Rasoolzadeh, Aein Rezaei Shahmirzadi, Falk Schellenberg, and Tobias Schneider. Impeccable circuits. IEEE Transactions on Computers, 69:361–376, 3 2020.
  • [AWMN20] Victor Arribas, Felix Wegener, Amir Moradi, and Svetla Nikova. Cryptographic fault diagnosis using verfi. In 2020 IEEE International Symposium on Hardware Oriented Security and Trust (HOST). IEEE, 12 2020.
  • [BDL97] Dan Boneh, Richard A. DeMillo, and Richard J. Lipton. On the Importance of Checking Cryptographic Protocols for Faults, pages 37–51. Springer Berlin Heidelberg, 7 1997.
  • [BS97] Eli Biham and Adi Shamir. Differential fault analysis of secret key cryptosystems, pages 513–525. Springer Berlin Heidelberg, 5 1997.
  • [Cla07] Christophe Clavier. Secret External Encodings Do Not Prevent Transient Fault Analysis, pages 181–194. Springer Berlin Heidelberg, 2007.
  • [DEK+18] Christoph Dobraunig, Maria Eichlseder, Thomas Korak, Stefan Mangard, Florian Mendel, and Robert Primas. Sifa: Exploiting ineffective fault inductions on symmetric cryptography. IACR Transactions on Cryptographic Hardware and Embedded Systems, 2018(3):547–572, Aug. 2018.
  • [DSCR+17] Pasquale Davide Schiavone, Francesco Conti, Davide Rossi, Michael Gautschi, Antonio Pullini, Eric Flamand, and Luca Benini. Slow and steady wins the race? a comparison of ultra-low-power risc-v cores for internet-of-things applications. In 2017 27th International Symposium on Power and Timing Modeling, Optimization and Simulation (PATMOS). IEEE, 9 2017.
  • [FJLT13] Thomas Fuhr, Eliane Jaulmes, Victor Lomne, and Adrian Thillard. Fault attacks on aes with faulty ciphertexts only. In 2013 Workshop on Fault Diagnosis and Tolerance in Cryptography (FDTC). IEEE, 8 2013.
  • [IPSW06] Yuval Ishai, Manoj Prabhakaran, Amit Sahai, and David Wagner. Private Circuits II: Keeping Secrets in Tamperable Circuits, pages 308–327. Springer Berlin Heidelberg, 2006.
  • [LSG+10] Yang Li, Kazuo Sakiyama, Shigeto Gomisawa, Toshinori Fukunaga, Junko Takahashi, and Kazuo Ohta. Fault Sensitivity Analysis, pages 320–334. Springer Berlin Heidelberg, 2010.
  • [MM24] Nicolai Müller and Amir Moradi. Automated generation of fault-resistant circuits. IACR Trans. Cryptogr. Hardw. Embed. Syst., 2024(3):136–173, 2024.
  • [RBRSS+21] Jan Richter-Brockmann, Aein Rezaei Shahmirzadi, Pascal Sasdrich, Amir Moradi, and Tim Güneysu. Fiver – robust verification of countermeasures against fault injections. IACR Transactions on Cryptographic Hardware and Embedded Systems, pages 447–473, 8 2021.
  • [RSM21] Shahram Rasoolzadeh, Aein Rezaei Shahmirzadi, and Amir Moradi. Impeccable circuits III. In 2021 IEEE International Test Conference (ITC). IEEE, 10 2021.
  • [SJ00] Sung-Ming Yen and M. Joye. Checking before output may not be enough against fault-based cryptanalysis. IEEE Transactions on Computers, 49:967–970, 2000.
  • [SRM20] Aein Rezaei Shahmirzadi, Shahram Rasoolzadeh, and Amir Moradi. Impeccable circuits II. In 2020 57th ACM/IEEE Design Automation Conference (DAC). IEEE, 7 2020.

Contact:

If you are interested in this topic, please contact Felix Uhle ().