OUR VISION: SECURE IT INSTEAD OF IT SECURITY
Written by Maja Malenko, Hardware Researcher at HENSOLDT Cyber
Today we are continuing the story of hardware security started in our previous blog post. This time, we will take a closer look at two hardware attacks: reverse engineering and fault injection attacks.
Reverse Engineering
Reverse engineering (RE) is the process of extracting knowledge about the structure and the functionality of an unknown design. While in software RE the unknown design is a software binary, hardware RE aims to understand unknown hardware modules, including integrated circuits (IC). Moreover, software RE relies on mature automated tools to get to an appropriate software abstraction level. Except for several university projects, hardware RE tools have not yet reached the same level of maturity.
History has given us examples of reverse engineered and cloned military designs, including the well-known American Boeing B-29 bomber. Today, more than ever, RE should be of a great importance to governments, militaries, and industries. Beyond the economic impact of simple cloning, the cost of maliciously modified designs produced in untrustworthy foundries can also be extremely high. Therefore, more research and industrial effort should be invested on this subject.
Is Hardware Reverse Engineering just bad?
In general, hardware RE is considered an adversarial mechanism. While malicious motives include identifying critical modules for further exploitation, inserting hardware Trojans, cloning, counterfeiting, and overproduction, RE can also be used to identify and mitigate these attack scenarios.
A simplified example of the RE process of an IC is shown in figure 1. In this process, the goal is to extract the gate-level netlist, to find the logic behind the sea of gates, and ultimately to infer the hardware description of the design. Figure 1 shows the netlist of a half adder module only for illustrative purposes. The netlist of a realistic IC is much more complex with thousands of gates and connections. In our previous blog post, we already mentioned that RE is complicated and expensive when executed on a physical IC. In untrustworthy foundries, the extraction of the netlist from the layout files is a straightforward process.
Figure 1: The process of hardware reverse engineering
Netlist Reverse Engineering
For the MITHRIL project, we address the topic of netlist RE. This process consists of two fundamental steps:
To improve the identification of modules in complex designs, authors in [1, 2] use machine learning-based RE. This fuzzy approach identifies unknown modules by comparing them to a library of known and similar designs. In comparison to other methods, this graph-based approach is less restricted in size, technology, and accuracy of the netlist and is scalable for large designs. Figure 2 shows the graph representation of three different cryptographic cores. By observing the graph of an unknown cryptographic implementation and comparing it with these unique graph structures, its basic interpretation can be inferred.
Figure 2: Graph representation of three different cryptographic cores (AES, DES, RSA) [1]
Fault Injection Attacks
Fault injection attacks (FIAs) manipulate a device to compromise its security. Faults can be injected by altering the clock source, briefly dropping the supply voltage, exposing the device to a precise and high-intensity laser beam or to an electromagnetic pulse. Most FIAs require prior knowledge about the design, physical access to the device, specialized tool set, temporal, and spatial precision.
What can be faulted?
The goal of a FIA is to either extract a secret or bypass a security-critical operation executed by the software. Examples of fault injection effects include skipped instructions, modified instructions (instruction opcodes or operands), modified memory or register locations, or corrupted control signals in the processor’s pipeline.
Optical fault injections are conducted by precise laser or focused ion beams, while electromagnetic fault injections use focused electromagnetic pulses. They have proven to be very successful in compromising the processor’s control flow and its cryptographic operations. These attacks, however, require access to an exposed silicon die and must inject the fault at the precise moment when a critical operation is occurring. Figure 3, 4, and 5 show experimental images from the electromagnetic fault injection performed on two boards with the MiG-V processor.
Figure 3: Setup and board orientation
Figure 4: Side view of a probe on an open board
Figure 5: Side view of a probe on a board with 3D printed interposer
To simulate FIAs on secure boot and post-quantum cryptographic algorithms, the team in MITHRIL is using open-source instruction set simulators as described in [3, 4]. For both scenarios, the target architecture is RISC-V.
FIA on Secure Boot
Secure boot uses cryptographic signatures to guarantee the authenticity and integrity of a software. A common FIA on secure boot is bypassing the signature verification of the software binary. Ultimately, the program control-flow is compromised, and untrusted software can be executed. This effect can usually be achieved by skipping branch or compare instructions. Furthermore, depending on the underlying architecture, with only a single bit flip, an instruction can be modified to follow insecure code paths. Even if the code of the secure boot does not contain any memory safety vulnerabilities, fault injections can still make it misbehave.
A simplified process of modifying the control-flow of the secure boot is shown in figure 6. The source code segment written in C (figure 6a) is compiled to the underlying RISC-V instructions (figure 6b). In the compiled code, it becomes clear where the fault should be injected. With only a single bit flip, the opcode of a branch if not equal (bne) instruction is converted into a branch if equal (beq) instruction (figure 6c). If malicious software is being verified, this will effectively circumvent its signature verification.
In reality, this process is not as straightforward as shown in this example. However, after finding the critical operation, the correct timing, and the precise location to inject the fault, and after many iterations and failed attempts, the real attack will eventually succeed.
int result = verifySignature(&softwareImage);
if(!result)
error();
boot();
call verifySignature
bne a0, zero, error
call boot
a. C code segment
b. Assembly instructions
c. Opcode of two branch instructions
Figure 6: Code example of bypassing the secure boot signature verification
Hardware Attack Awareness
Hardware attacks such as reverse engineering and fault injection are becoming cheaper and easier to execute. The equipment is not only more affordable, but also more sophisticated. Therefore, it is very important to raise the awareness of these attacks and the reality of their existence.
Possible countermeasures against the presented attacks will be the topic of our final blog post in this trilogy. Stay tuned for more!
[1] M. Werner, B. Lippmann, J. Baehr, H. Gräb. “Reverse Engineering of Cryptographic Cores by Structural Interpretation Through Graph Analysis”. IVSW 2018.
[2] J. Baehr, A. Bernardini, G. Sigl, U. Schlichtmann. “Machine learning and structural characteristics for reverse engineering”. ASP-DAC 2019.
[3] D. Mueller-Gritschneder, M. Dittrich, J. Weinzierl, E. Cheng, S. Mitra, U. Schlichtmann. “ETISS-ML: A multi-level instruction set simulator with RTL-level fault injection support for the evaluation of cross-layer resiliency techniques”. DATE 2018. (https://github.com/tum-ei-eda/compas-ft-riscv)
[4] F. Hauschild, K. Garb, L. Auer, B. Selmke and J. Obermaier. “ARCHIE: A QEMU-Based Framework for Architecture-Independent Evaluation of Faults”. Workshop on Fault Detection and Tolerance in Cryptography (FDTC), 2021. (https://github.com/Fraunhofer-AISEC/archie)
International Day of Families at HENSOLDT Cyber Interview with Markus Wolf, Sascha Fedderwitz, Emilia Fries We asked some of our colleagues a few questions on
How to mitigate hardware attacks? Written by Maja Malenko, Hardware Researcher at HENSOLDT Cyber In the final blog post of our hardware security trilogy, we
Is Hardware Reverse Engineering a Real Threat? Written by Maja Malenko, Hardware Researcher at HENSOLDT Cyber Today we are continuing the story of hardware security
Hardware Security: HENSOLDT Cyber’s MITHRIL Project Written by Maja Malenko, Hardware Researcher at HENSOLDT Cyber Creating secure hardware is a challenging task, especially in times
Successful ISO 9001:2015 certification We are pleased to announce that after eight months of hard work, preparation, and intensive teamwork, HENSOLDT Cyber has certified its
Hello Secure World – How to build and run your first secure TRENTOS® system Building on our first video session in which we took a
LEGAL:
CONTACT US:
FOLLOW US ON:
HEADQUARTER POSTAL ADDRESS:
OUR OFFICE IS LOCATED HERE: