As of August 2020 the site you are on (wiki.newae.com) is deprecated, and content is now at rtfm.newae.com.

Tutorial CW305-3 Clock Glitching

From ChipWhisperer Wiki
Revision as of 07:59, 18 January 2017 by Gdeon (Talk | contribs) (Results)

Jump to: navigation, search

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.

Background

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 (SubBytes(), ShiftRows(), MixColumns(), and AddRoundKey()), and the output is stored back into the state port.

Our goal in this tutorial is to cause the AES execution to fail by applying clock glitches. If we trigger a short clock glitch right next to a clock edge, we might be able to corrupt some of the bits of the state array. If we can manage this, the output ciphertext will be totally different! Remember that one of the primary goals of cryptographic algorithms is diffusion: if we change a single bit of the input, the round function will cause that one bit to affect all 128 bits of the output.

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.

Glitch Setup

Hardware/Software Setup

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.

In the previous examples, we wanted to clock our Artix-7 from the target board's PLL. Now, we want to inject glitches into this clock, so we want to use the clock generated by our capture hardware. To do this, we need to change switch J16 to 1. This switch will force the FPGA to use the ChipWhisperer's input clock instead of the PLL.

Next, we need to generate our own clock signal. Set up the ChipWhisperer's CLKGEN output to run at 10 MHz, and use CLKGEN x4 as the ADC clock source:

CW305Clkgen.PNG

Then, set up the glitch module to use CLKGEN as the input clock and set the glitch trigger to external single-shot. We'll be playing with the rest of the settings later.

CW305GlitchModule.PNG

Finally, under CW Extra Settings, change the Target HS IO-Out to use the Glitch Module output. Capture a trace and make sure you can see a glitch in the power. For example, here is a trace with a visible glitch from samples 30 to 35. (You might need to change the glitch width and offset - this screenshot was captured using 30% and 10%.)

CW305GlitchExample.PNG

Glitch Explorer

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.

The first thing we need to do is get our FPGA to use a fixed plaintext and key. If we change the inputs on every capture, it'll be more difficult to tell when a glitch was successful. The rest of this tutorial will use the fixed key 2B 7E 15 16 28 AE D2 A6 AB F7 15 88 09 CF 4F 3C and the fixed plaintext 5C 69 2F 91 03 B2 30 29 14 D7 E5 55 E4 DC EE 49, but you can use any key and plaintext.

Using our fixed key and plaintext, we can set up the glitch explorer to detect when we've successfully glitched the FPGA. Open the glitch explorer, then click Capture 1 to see the format of the output. With the plaintext and key mentioned above, the received output is '06f36a65e8a99ff8907b2e5e5ddd77de'. Set the glitch explorer's normal/successful responses to check for this string. Then, set up two tuning parameters to sweep the glitch module's width and offset. When everything is set up, your glitch explorer should look like:

CW305GlitchExplorer.PNG

Once everything is ready, click Use this value and start capturing.

Results

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:

CW305GlitchMap.PNG

This map doesn't tell us what the actual ciphertext was with each of these settings, but it does give us a clue about where to look in the glitch explorer. The other thing that we can check is the glitch explorer output: looking at the glitched ciphertexts shows a wide variety of different outputs with different glitch settings.

CW305GlitchOutput.PNG

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.

Further Analysis

- AES intermediate script - Outline code process - Show code in appendix - Show output plots