I’m trying to attack the AES Hardware implementation on a custom target, but had no success so far. Even with a high number of traces I wasn’t able to reproduce the recovery of a single sub byte.
With the same target I’m able to recover all key bytes of the AES software implementation with about 500 traces.
My target is a SoC running at 50 MHz, which I sample with 50 MHz (clkgen_x1). I’m using the leakage model “last_round_state_diff”, which gives me a relatively high correlation for wrong bytes, at a position in the trace where the AES operation is already done. Here is a picture:
This was an attack with 60000 traces and recovered a single sub byte (which is not reproducible, most of my measurements recover 0 bytes). I usually just attack the area in the traces where the actual AES operation takes place. The picture shows the highest correlation in the whole trace.
I also tried using different leakage models, different clocks for the SoC and different sample rates (also tried clkgen_x4 100MHz, with 25 MHz target clock) but none of this was showing any success.
The AES core of this SoC is this one from opencores.orgOverview :: high throughput and low area aes core :: OpenCores
Does anybody have an idea what might be the problem attacking the AES hardware implementation of this target?
I’ve never tried that implementation, and from a quick look at the RTL it should be possible to successfully attack it.
Are you using the CW305, or the UFO Spartan6 target?
What version of CW software are you running? If you’re using a release, then you’ll have to update to the latest 5.1.3 release. There was a bug in prior CW5 releases that was fixed by this commit .
I’m using the latest version of CW 5.1.3. My target is neither the CW305 nor the Spartan 6, it is a SoC for industrial communication. For the pupose of attacking this target, I have designed a carrier PCB, in order to use the UFO board with the CW Lite.
My traces I’m recording look like this:
Between the red lines, the AES operation is taking place. One can clearly see, that the trace has some DC portion and my setup seems to have a certain capacitance. Never the less, I was still able to successfully attack the AES software implementation (mbedtls) with as few as 500 traces.
The AES core from opencores doesn’t have any countermeasure against side channel attacks, so I’m wondering what the problem might be.
My assumptions are the leakage model or my measurement setup, even though it is working just fine for the software implementation.
The region between the red lines looks like it’s about 70 samples, but that AES HW implementation should be doing AES in 10 to 14 clock cycles?
The small number of large peaks in that region aren’t what one would expect from a 1 round / cycle implementaiton; this suggests that there is other activity on the SoC?
If so. and if the other activity is independent of AES, then you may have more success with averaging several measurements (for the same AES inputs), to average out the “noise”.
It might be worthwhile to put the AES implementation on its own on one of the NewAE FPGA targets, in order to confirm that it can be successfully attacked in that idealized environment. This would also provide some guidance re: points 2 and 3 (e.g. what are the AES traces supposed to look like).
@CMG I didn’t have any success with the HW-AES. I think the reason is my measurement setup. If you have any success, it would be awesome if you could share your results.
Are you using the same HW-AES implementation from opencores.org?
And what target are you working with?
@jpthibault Thanks for your thoughts. Indeed on this SoC is a lot going on. I already tried averaging traces with the same inputs, but didn’t have any success with that either.
The idea with the NewAE FPGA target is pretty good, but sadly I won’t have time for that.
Since I didn’t want to invest more energy and time into the HW-AES, I started analyzing the Montgomery core of the SoC and have pretty good results with the RSA operations (Squaring and Multiplying), even though the multiplication and the squaring (which is actually also a multiplication) operations can’t be differentiated by time.
I tried several models, but sadly none of them worked out for me.
I’m also doing academic research, using my company’s SoC. I successfully broke the cryptographic core for RSA and ECC operations, but the AES core seems to be pretty robust.
Finally, we decide to use TVLA to check the vulnerable leakage.
I think the models from ChipWhisperer may not exactly reflect the real implementation of our Hardware-AES.
The success rate of CPA/DPA attack heavily depends on the hypothesis models a lot.
So, we try to lower the impact of hypothesis model, since we don’t know how a hacker’s capabilities.
