When Timing Attacks Reveal Power Usage
In previous columns, the idea of timing attacks was often limited to the granularity of the time it takes for individual instructions to execute. A recent academic paper demonstrated that timing, when measured at very high resolution, provides a proxy for power consumption. This article sets out to show an easy way to demonstrate that on simple microcontrollers (MCUs).
This month, I discuss an interesting side channel measurement technique that was published at the 2023 conference on Cryptographic Hardware and Embedded Systems (CHES). The CHES conference is one of the most important academic events for the type of work I cover in this column, so there are always lots of relevant papers. This year, CHES will be in my city of Halifax, Nova Scotia, Canada. So, if you want to see more papers like the one I cover here (and say hello in person), I invite you to attend!
The paper in question is entitled “JitSCA: Jitter-based Side-Channel Analysis in Picoscale Resolution,” by Kai Schoos, Sergej Meschkov, Mehdi B. Tahoori, and Dennis R. E. Gnad. Its central idea is that if an embedded device generates a clock (such as those commonly used in communications protocols), small timing variations in that clock can leak information about data being processed by the device. How could that be?
We know that the power consumption of a device can be used to leak cryptographic secrets, as I’ve shown in many previous columns. But the power consumption of a device changes, as does the voltage on internal rails. These small voltage variations cause timing variations, which in turn can be measured with external equipment.
In this article, I demonstrate how we can validate this on a simple MCU (SAM4S2AA), and use that knowledge to validate other systems you work with. I do this with my open-source ChipWhisperer system, and in particular, I show how you can easily (and cheaply) measure these small timing variations.
System Setup
To begin with, let’s look at our basic MCU (Figure 1). The important part here is that we’ve got a 12MHz clock (external crystal). Internally, a Phase Locked Loop (PLL) increases that to the maximum frequency this particular device can use, 120MHz.
A very common microcontroller clock setup, where an external crystal drives a PLL in the microcontroller.
This 120MHz clock is then used by the core and peripherals. There is often further division and other operations performed on the clock. Serial output blocks, for example, often have additional dividers to produce standard baud rates.
Based on the assumption of the paper, once the MCU processes the clock, it picks up variations related to the power consumption (which are related to data or instruction sequences). As more divider steps are taken, this effect should be magnified. But even the output of the PLL should show some variation with power.
How do we effectively measure these small variations? Directly measuring the time requires a high sample rate oscilloscope (or logic analyzer). In the original paper, a Time to Digital Converter (TDC) is used, which is implemented in an FPGA. This can be a rather low-cost method, but it might be harder to work with since it’s not available as standard test gear. I wanted to find something that would be easier for anyone to recreate.
So instead, I’ll take advantage of the input clock the MCU is using (the crystal) being available as a reference source, and measure the difference between a clock processed by our device under test and one that isn’t. In theory, a clock processed by an external device shouldn’t see the same jitter as one processed by the device under test.
Measuring the phase difference between two clocks is a much easier goal to accomplish. In fact, I can simplify this further because I can use my existing ChipWhisperer hardware to do this. The setup for this is shown in Figure 2.
The PCLK outputs the internal clock, and is converted into an analog signal for measurement on the ChipWhisperer.
The idea is to use the PLL inside of the ChipWhisperer unit to create my own 120MHz clock. Because the input is the same 12MHz clock, this clock will be phase-locked to the 120MHz clock from the MCU. But it won’t have the small variations present that represent the side-channel data we want to measure.
The target MCU has a “programmable clock” (PCLK) peripheral. This is used to generate a clock for external devices, and I use it to generate my measurement clock. I could have instead used, for example, the SPI block or anything else that outputs a clock, but for this initial testing, the PCLK signal is easier since it’s always on.
To measure this output clock, I use a voltage divider and the input circuitry of the ChipWhisperer to create a low-pass filter. The ChipWhisperer is designed to measure small signals, so the 3.3V swing of the I/O output is far too high. That is why I have such an aggressive voltage divider.
The reason we want a low pass is we’re actually trying to convert small variations in timing to an analog signal that we sample with the ADC. To better understand this, take a look at Figure 3, which shows some of the signals.
The top clock shows the stable clock used for sampling, and by sampling the jittery clock that has been passed through a low-pass filter we get different ADC sample values for different amounts of jitter.
The top graph in Figure 3 is the 120MHz clock to the ADC. This would be the same as the clock from the MCU (target) if there was no jitter or variation. But the second graph in Figure 3 is a clock with some random jitter. The dashed lines show the location of rising edges from the top clock, and they don’t line up exactly.
Finally, the lower graph is the result of a low-pass filter on the jittery clock, and the dots show the locations of ADC samples. Variations in timing (phase changes) get converted to a different analog value sampled by the ADC.
I used this method of measuring the phase changes because it was already sitting on my desk. There are other ways to measure phase differences, but the fact that this works with existing side-channel measurement equipment makes it especially helpful. The only real trick here is that my measurement is happening with a controlled phase, which is what makes it possible for me to measure these small timing variations so effectively. If you try this with a regular oscilloscope, you’ll need to feed in a reference clock to get the same phase lock effect.
Measuring Results
My existing ChipWhisperer demos can run AES on command, which is typically what I used to demonstrate a side-channel leakage. The only tweak is I enabled the PLL at 120MHz from a 12MHz input, and setup the PLL to drive the MCU core as well as an output pin.
The pattern that is visually present from the ADC measurement is shown in Figure 4. This was the result of an average of 2500 recordings; the results look much noisier than a “normal” power trace. But this is still interesting, as it looks similar to a power measurement. There is a noticeable repeated pattern because AES runs multiple rounds, and we are seeing two of those rounds in this view.
The result of the jitter-based measurement shows the characteristic AES rounds.
You might be concerned that my measurement’s electrical connection means this difference comes from the power (and voltage) variations directly, and not due to the timing variations. To confirm this isn’t the case, I did two measurements: one with the I/O line set to a constant high, and one where the I/O line is driven from a different clock (which will break the phase measurement). Of those, the constant I/O line is the most interesting, but even that result (Figure 5) has only a few spikes present. Like Figure 4, this is an average of 2500 measurements.
If we disable the clock to check for a coupling into the I/O voltage, we see the pattern disappear.
The Atmel SAM4S2AA target MCU uses a 1.2V core voltage as well, so the actual core voltage and I/O voltage are different supplies. This should help with isolation, but since side channels can couple in unexpected ways, it’s important to validate that the measurement isn’t just a different coupling mechanism.
But just observing a pattern isn’t enough. Besides performing an attack, a typical method of validating a side channel leakage is using a statistical t-test. A specific version of that is called Test Vector Leakage Assessment (TVLA). With TVLA we are trying to check if there is any statistical difference in a side channel measurement between a fixed encryption key and a random encryption key. If such a difference exists, it suggests the system is leaking information about the encryption key.
The results of this are shown in Figure 6, where the sample number is associated with each sample point as in Figure 4. We typically use an absolute value greater than 4.5 to mean a statistical leak is present, as we can tell the difference between the two keys with high confidence. You can see this is the case for my measurement; we are exceeding that threshold in multiple places by a large margin. Again, swapping to a constant I/O pin value shows no leakage present (maximum t-test results are below 3.2), so I’m confident my measurement technique is successfully capturing these small timing variations.
The T-Test statistic shows there is a statistically relevant leakage.
In the future, I’ll build an isolated measurement system that will make this suitable for a wide range of devices, and I’ll further demonstrate that the leakage is different from directly measuring the analog values. But for now, I wanted to show you how easy it is to recreate some interesting work from academia.
And of course, another potential threat to your devices is that clock outputs could be leaking sensitive information. If an attacker has access to a stable clock source, it’s easy for them to measure these small variations. If you’ll be sending a clock externally, you can pass it through a PLL which will remove these small variations. But for many digital interfaces, you cannot easily filter the clock, so you should consider if this threat model is important to you when designing your systems.
If you’d like to try recreating this yourself, I’ve posted links to the code on my GitHub for this column [1]. While I used a ChipWhisperer-Husky, you can see from Figure 2 that the important part is anything with an ADC where you can phase-lock the sampling logic. So, you may be able to try this on other FPGA boards, software-defined radio (SDR) platforms, or even oscilloscopes. I hope you have fun experimenting with yet another side channel!
RESOURCES
CHES | ches.iacr.org
NewAE Technology | www.newae.com
REFERENCES
[1] Embedded System Essentials GitHub: https://github.com/colinoflynn/circuitcellar-EmbeddedSystemEssentials
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • MARCH 2024 #404 – Get a PDF of the issue
Colin O’Flynn has been building and breaking electronic devices for many years. He is an assistant professor at Dalhousie University, and also CTO of NewAE Technology both based in Halifax, NS, Canada. Some of his work is posted on his website (see link above).
