Pi Pico AES Timing Attack and Firmware Patch

ISEF Category: Embedded Systems

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

The Hook

A program can be secure and still leak secrets through timing. Tiny differences in how long code runs can reveal patterns an attacker can use. That makes side-channel attacks one of the sneakiest problems in embedded security. You can study both the leak and the fix in one project.

What Is It?

This project looks at side-channel leakage in embedded cryptography. A side channel is any clue the device gives off besides the actual data, like timing, power use, or memory access patterns. In this case, you would study an AES implementation on a Pi Pico, then measure whether a caller can infer secret-dependent behavior from how long operations take or from other repeatable signals.

Think of it like a locked box that still rattles differently depending on what is inside. The lock may work, but the sound gives away clues. A constant-time implementation tries to make every path take the same amount of work, so secret data does not change the observable behavior. Your second phase would test a firmware patch, then use mutual information, which measures how much one signal tells you about another, to see whether leakage dropped.

Why This Is a Good Topic

This is a strong science fair topic because you can measure a real security weakness, test a fix, and compare results with clear data. It connects to phones, smart devices, payment systems, and any product that stores secrets on a tiny chip. You can learn software timing, experimental controls, leakage metrics, and basic security analysis, which makes the project feel real instead of toy-like.

Research Questions

• How does input data choice affect the timing variance of an AES implementation on a Pi Pico??
• What is the effect of replacing secret-dependent branches with constant-time logic on timing leakage?
• Does the firmware patch reduce mutual information between secret inputs and observed execution time?
• To what extent do compiler settings change the measurable side-channel signal?
• Which AES code paths create the largest leakage under repeated measurement?
• How does noise from USB communication affect the attacker’s ability to distinguish secret-dependent timing?

Basic Materials

• Raspberry Pi Pico or Pico W board.
• USB cable and host computer.
• Breadboard and jumper wires.
• Logic analyzer or oscilloscope with digital timing capture if available.
• Multimeter for basic electrical checks.
• Serial monitor software on the host computer.
• Python environment for analysis.
• CSV file storage for timing logs.
• Open-source AES firmware example for the Pico.
• Simple LEDs or GPIO test pins for event marking.

Advanced Materials

• Raspberry Pi Pico or similar ARM Cortex-M microcontroller board.
• USB current measurement setup or power analysis board.
• Logic analyzer with high sample rate.
• Oscilloscope with math and trigger features.
• Differential probe if power leakage analysis is included.
• Custom firmware build chain for cross-compiling and profiling.
• Reference AES implementation and constant-time candidate patch.
• High-quality shielded cables and stable power supply.
• Laboratory computer for repeated capture and batch processing.
• Data acquisition scripts for synchronized traces.

Software & Tools

• Python: Processes timing logs, computes statistics, and runs mutual-information analysis.
• Jupyter Notebook: Organizes plots, comparisons, and clean writeups of results.
• NumPy: Handles arrays and repeated measurement data.
• SciPy: Supports hypothesis tests and distribution comparisons.
• ImageJ: Can help inspect plotted trace images if you export them as figures, though it is less central here.

Experiment Steps

1. Define the secret-dependent behavior you want to test, then choose one AES code path as your baseline.
2. Design a measurement setup that captures repeated execution time or another leakage signal in a consistent way.
3. Build a control case that keeps the input format the same while changing only the secret-dependent variable.
4. Plan a patch strategy that aims for constant-time-equivalent behavior, then decide how you will verify the change without trusting the code alone.
5. Choose your leakage metrics, including timing spread, classification accuracy, and mutual information.
6. Set up a comparison plan that tests the original firmware against the patched version across many repeated trials.

Common Pitfalls

• Changing multiple firmware details at once, which makes it impossible to tell whether the patch or the compiler caused the result.
• Measuring only one run per input, which hides timing jitter and produces fake patterns.
• Letting USB or serial printing happen inside the timing window, which adds noise that swamps the signal.
• Comparing different input sizes or formats, which creates a timing difference unrelated to secret leakage.
• Trusting average time alone, which can miss a strong side channel hiding in the tails of the distribution.

What Makes This Competitive

A class-level version of this project stops at “the patch seems faster or slower.” A stronger version shows exactly how much secret information leaks before and after the patch, using repeated trials and a clear statistical test. You can raise the level by comparing multiple constant-time strategies, testing compiler settings, and checking whether the fix still holds across different input classes. If you can show a small but real drop in mutual information, that gives your project a serious research feel.

Project Variations

• Test whether different compiler optimization flags change leakage even when the source code stays the same.
• Compare timing leakage across several AES modes or lookup-table styles on the same Pi Pico board.
• Replace timing with power-based capture and see whether the same patch reduces both timing and power leakage.

Learn More

• NIST SP 800-38A: Find the standard through the NIST Computer Security Resource Center for background on block cipher modes and testing contexts.
• NIST Computer Security Resource Center: Search for guidance on side-channel resilience, cryptographic validation, and implementation issues.
• USENIX Security proceedings: Search for peer-reviewed papers on timing attacks, constant-time coding, and mutual information leakage.
• MIT OpenCourseWare: Look for courses on computer systems security and embedded systems to review low-level performance measurement.
• PubMed: Search for review articles on mutual information and signal analysis if you want a statistics refresher.
• arXiv: Search for preprints on side-channel analysis, though you should confirm key claims with peer-reviewed sources.