QEMU Fault Injection for AES Security

ISEF Category: Systems Software

Subcategory: Cybersecurity  ·  Difficulty: Advanced  ·  Setup: University Lab  ·  Time: Full Year

The Hook

A tiny power glitch can make secure code fail in seconds. That means one bad voltage drop can turn strong encryption into a weak spot. You do not need real hardware to study that risk. You can simulate the failure and see how different AES implementations hold up.

What Is It?

This project studies fault injection, which means forcing a system to make mistakes on purpose so you can see how it breaks. In hardware, a voltage glitch can cause a chip to skip an instruction, flip a bit, or return the wrong value. Your simulator copies that idea in software by using QEMU, a program that mimics a computer system, plus a custom plugin that injects faults into AES execution.

Think of it like testing a bridge by drawing cracks on a model first. You are not breaking a real bridge, but you are learning where it would fail. Here, the bridge is encryption code. AES is a common encryption algorithm, and OpenSSL and BearSSL are two different software libraries that implement it. Your job is to see how fault patterns change their behavior, then trace which glitch paths lead to useful exploit chains.

Why This Is a Good Topic

This topic works well for a science fair because you can test a real security question with a clear cause and effect. You change the fault model, then measure how often each AES implementation leaks, crashes, or produces a wrong result. That gives you data, not just a demo. The project also connects to real problems in embedded security, where attackers may use physical glitches to defeat encrypted devices. You can learn simulation, vulnerability analysis, and experimental design without needing a chip lab.

Research Questions

• How does the location of a simulated voltage glitch change the success rate of fault attacks on AES?
• What is the effect of different glitch timing windows on exploit chain discovery in OpenSSL?
• Does BearSSL resist simulated faults better than OpenSSL under the same attack model?
• To what extent does the fault model change the type of output errors produced by AES?
• Which injected fault patterns lead to the fastest automatic discovery of a usable exploit chain?
• How does the number of fault attempts affect the probability of recovering a useful secret or bypass condition?

Basic Materials

• Computer with enough RAM to run QEMU smoothly.
• Linux operating system or a Linux virtual machine.
• QEMU installed from source or package manager.
• Custom QEMU plugin or hook framework for fault injection.
• OpenSSL source code or test build.
• BearSSL source code or test build.
• Version control tool such as Git.
• Spreadsheet software for logging results.
• Python for parsing logs and plotting trends.

Advanced Materials

• Workstation or server with multiple CPU cores and large memory for batch runs.
• QEMU source tree with plugin development support.
• Debug symbols for OpenSSL and BearSSL test builds.
• GDB for tracing execution paths and verifying fault locations.
• Python scientific stack for automated experiment runs and analysis.
• A corpus of AES test cases and harnesses for repeated evaluation.
• Container or virtualization setup for reproducible builds.
• Static analysis tools for comparing code paths before fault injection.

Software & Tools

• QEMU: Simulates the target system so you can inject faults without real hardware.
• Python: Automates test runs, log parsing, and statistical analysis.
• GDB: Helps you trace execution and confirm where the fault changes program flow.
• ImageJ: Not needed for this project, so skip image tools and focus on code traces.
• Git: Tracks code changes in the plugin, harness, and analysis scripts.

Experiment Steps

1. Define the exact AES behavior you want to break, such as decryption output, control flow, or key handling.
2. Map the code paths in OpenSSL and BearSSL so you know where to place controlled faults.
3. Design a fault model that mimics a voltage glitch in software terms, such as skipped instructions or flipped state bits.
4. Build a repeatable harness that runs the same encryption test many times under the same conditions.
5. Plan your metrics, including crash rate, wrong-output rate, and exploit chain success rate.
6. Compare implementations with the same attack script, then analyze which design choices make one library harder to break.

Common Pitfalls

• Treating any wrong ciphertext as a real exploit, which inflates success rates without proving a useful attack.
• Injecting faults at random points without mapping the AES execution path, which makes the results hard to interpret.
• Comparing OpenSSL and BearSSL with different build settings, which creates a fairness problem.
• Changing multiple variables at once, which hides the effect of the fault timing or location.
• Using too few repeated runs, which makes rare fault outcomes look more important than they are.

What Makes This Competitive

A stronger version of this project does more than count crashes. You compare libraries under the same fault model, then explain why one path fails more often than another. You can also test whether your automatic exploit discovery finds paths that a simple brute-force script misses. Careful statistics, clean controls, and a new way to measure fault success can move the work from a demo to real research.

Project Variations

• Test AES fault behavior in a different library, such as mbed TLS, to see whether implementation style changes resilience.
• Change the fault model from instruction skipping to register corruption and compare which one reveals more exploit chains.
• Analyze fault effects on another crypto primitive, such as RSA or ChaCha20, to see whether your simulator generalizes beyond AES.

Learn More

• QEMU documentation: Read the official emulator docs and plugin notes on the QEMU project site.
• OpenSSL source and docs: Inspect AES code paths and build options in the OpenSSL repository and manual pages.
• BearSSL documentation: Review the library design notes and AES implementation details on the BearSSL site.
• MIT OpenCourseWare, Computer Systems Security: Search MIT OpenCourseWare for security lectures that cover fault attacks and system hardening.
• PubMed: Search for review articles on fault injection attacks in cryptographic implementations.
• IEEE Xplore: Search for peer-reviewed papers on software fault injection, AES, and glitch-based attacks through your school access or library.