Over the last few days, I’ve been trying different approaches to improve my side channel analysis technique against smartcards. This post serves as some notes on the sources of noise impacting a power trace, and some observations of easily implemented filtering mechanisms.
Perhaps a trigger warning is suitable – this post contains a sizeable heaping of intuitive maths.
To begin with, let’s review a horizontally aligned (AVR, GPIO trigger before AES128, think this was 125MSPS) signal:
Zooming in, we can see significant noise (mismatches) on the signal:
In my mind, there are a few sources of noise:
- Noisy power supply. Though decoupling capacitors are in use, they are not perfect, so some level of noise appears (though minimal)
- There is low-frequency noise and high frequency noise here. I’m not sure what’s the root cause of this (switching noise inside SMPS?)
- Execution changes. Changed execution can disturb power traces, though it’s possible to “watch” for this in software (via discarding traces that go outside a threshold when aligning, preferrably with the help of a low pass filter to bring out features). I think it’s too troublesome to denoise this, and it’s more efficient to just throw away the traces if it’s beyond a simple “shift left 5000 samples” denoise.
- Measurement noise. When you take an oscilloscope and touch a probe tip to it’s corresponding ground grabber, the result is not a straight horizontal line, indicating there’s some inherent noise in the measurement process itself (electromagnetic interference on the oscilloscope probe leads? noise from components in the scope?)
The impact of noise is that a trace, when impacted by noise, will work “against” you in statistical analysis.
- In a correlation attack, the power consumption for a given area may not go in the same direction as the hypothesis, causing the trace to contribute inaccuracy.
- In a DPA attack, noise can destroy the true power consumption value of a given operation, again causing the trace to contribute inaccuracy.
To give a feel for the impact of noise on a trace, let’s review a plaintext tlva graph of the above:
The distinguisher function is if the last bit of the first byte of plaintext is even: where there should be a clear leakage peak, the null hypothesis is not strongly rejected (relatively), the t-value is *just* above 4.5. Correlation peaks (for consistency: all attack examples are against AES first-round s-box output, starting from sample 3000, for a length of 10000 sample points) do show, as below:
The signal differencies which DPA relies on are almost all but destroyed:
Band Pass Filtering
Intuitively, a band pass filter (or either half of one) can help remove some of the noise. In the above trace, let’s review the signal in the frequency domain:
We can see the clock at 16Mhz, and harmonics at 32 and 64, and significant noise below 10Mhz. As an aside, this is far less clear when viewed through the lens of a spectrogram – though we can identify the cryptographic blocks via frequency component changes, it’s harder to see “where” the noise is.
Intuitively, the changes we want to measure shouldn’t be too far off from the clock frequency. Aided by the above, we can implement a band pass filter between 10Mhz and 25Mhz. The filtered trace looks like this:
Zooming in, we can see that a lot of the high-frequency noise has been removed, and the curve looks significantly “smoothed”:
Significantly stronger correlation peaks are now visible:
Stronger “point of difference” peaks are also now visible with a DPA attack:
I would have expected a significant number of traces to have their detailed information destroyed by the filtering process (particularly given that our sampling is not clock-synchronous, so will be off by a few ns here and there) – so to my limited understanding, this result is somewhat counter-intuitive.
Also, intuitively, it would be better to implement this in hardware, to preserve detail, rather than compound signal processing “errors” (treating signal as noise) with digitisation errors. Still, I’m not confident in my understanding of high-frequency circuit design, and I fear hand-made filters will induce such loss as to make traces useless.
I’ll probably edit this with better wording and more accurate terminology as time goes by, and I understand this topic better.
I recently stumbled across this technique when reading some IACR papers (side note: https://www.iacr.org/tinfoil.html is going into this coming semester’s COMP6443/COMP6483 course). In a nutshell, wavelets are an alternative method (to Fourier transforms) of decomposing a signal into it’s component frequency components. Intuitively, this “feels” like a repeat band-pass filter (though without needing to manually work out frequencies – each iteration of the wavelet contains half the detail of the previous one).
This video (and the series) goes some way to providing the background of wavelets.
Interestingly, while it is possible to apply a wavelet decomposition function to extract the wavelet components of a signal, it is also possible to take a series of wavelets and reconstruct (an approximation of) the original signal from them.
We can use the PyWavelets library (as per this blog post) to apply a wavelet decomposition, filtering and recomposition function to a signal. Based on previous liternature (lost the link) I used the Daubechies wavelet family, though more experimentation is needed to see the practical impact of other wavelet parameters.
The result of a wavelet-denoised signal looks like this:
Intuitively, the effect of the wavelet filter is, in this case, is highly similar to our band pass filter above, confirmed now by visual inspection. Correlation and differential analysis of the resulting signals confirm the same:
And for DPA:
More analysis is certainly needed, especially with hardware filtering implementations to preserve detail.
All sample data can be downloaded here.