Changes

The goal of this tutorial is to apply clock glitching to the CW305 Artix target, causing it to produce erroneous results during the encryption process. This isn't the most interesting software to glitch - in [[Tutorial A2 Introduction to Glitch Attacks (including Glitch Explorer)]], we glitched past a password check, which is a much more rewarding target. However, the setup and process in this tutorial is applicable to a wide range of FPGA programs.

In the previous tutorials, we said that our FPGA implementation of AES executes each round of the algorithm in a single clock cycle. This probably means that there's one 128-bit port used to store the internal state. On each clock cycle, this state is fed through a couple of different blocks (<code>SubBytes()</code>, <code>ShiftRows()</code>, <code>MixColumns()</code>, and <code>AddRoundKey()</code>), and the output is stored back into the state port.

In this tutorial, we'll say that a successful glitch is any glitch that causes the ciphertext to change. However, at the end of the tutorial, we'll look a bit deeper into the exact position and magnitude of these glitches to see exactly how our glitches are changing the output.

The hardware setup for this tutorial is largely the same as [[Tutorial CW305-1 Building a Project]]. Start the hardware setup by following those steps (connect the boards, run the example script, and upload the bitstream). Then, we need to make a few changes to our setup.

[[File:CW305GlitchExample.PNG]]

Once we've gotten clock glitches working, the objective is to find a set of glitch parameters that cause the encryption process to fail. We can do this automatically using the glitch explorer, so let's set this up to search for glitches.

Once everything is ready, click <code>Use this value</code> and start capturing.

When your capture is finished, there are two places to check the results. First, the glitch map shows us which glitch widths and offsets caused successful glitches. The green points on this map indicate combinations of tuning parameters that caused the encryption to fail. With some luck, your glitch map should look something like ours:

That's it - if your goal was to set up clock glitching the CW305, you're done. The last section of this tutorial will be a deeper analysis of this AES setup to check if we can determine exactly what effect our glitches had.

Earlier, we said that our clock glitches would corrupt some bits of the internal state inside the FPGA's AES module. It's actually possible to use our glitched ciphertext to check if this is happening! Here's a rough outline of the steps required to do this:

* Modify an AES implementation to save the values in the state array after every round (instead of only returning the output from the last round)

The first two curves show a significant dip at round 6, suggesting that the glitch caused 30 to 40 bits of the state to be corrupted after the 6th round. Then, these bits were immediately diffused into the rest of the state in the next round, causing the output to look totally random (because a Hamming distance of 64 indicates a 50% match rate). However, the final curve doesn't show this dip. It's possible that this glitch caused a different kind of error - perhaps the key schedule was corrupted instead.

<div class="toccolours mw-collapsible mw-collapsed">

<code>aes-int.py</code>