So, I finally got my STM32F3 working properly, and I am able to get a nice Side-Channel leakage for me to do some analyzing.
Now, I want to move on to the STM32F415 target. I am now able to successfully program the chip. However, I’ve read the wiki page (https://wiki.newae.com/Targets_with_Internal_Regulators) and notice it’s a bit tricky to get a proper power trace. After a bit of experimenting, I’ve encounter several problems, and I hope you guys may have some answers.
what is the maximum voltage I can use before damaging the device?
(I’ve skim through the data sheet, and the V_cap was not designed for us to input voltages, therefore, I can’t seem to find a warning for maximum input voltage) https://www.st.com/resource/en/datasheet/stm32f415rg.pdf
Although I’ve managed to get a power trace with Side-Channel leakage, there are lots of noisy spikes, which I’ve not seen in the other targets (ATmega328p, XMEGA, STM32F3). I am wondering, are those spikes normal? or I’ve somehow already damaged my target device? Is there a way to remove those spikes?
There are some unintended jittering in the power trace of my AES implementation, which didn’t appear in other targets. Why is that? Is there a cache or some branch prediction mechanism in STM32F4?
Looking at the schematic and the datasheet for the STM32F4, it looks like running off the external regulator isn’t supported. For the variants that do support it, Vmax across the cap pins (V12 on the datasheet) is 1.3V depending on the max frequency of the device. We have run them up to 1.8V without damage, but we didn’t seem to get much of a noise reduction vs. just using the internal regulator.
The topic of caching/branch prediction actually has quite a few unknowns that I’ve run into (mostly from trying to update Tutorial B2 for the F3) since (I believe) Arm creates the reference core and sells/licences that to ST, so it’s hard to say where their spec ends and the reference manual for the devices begin. Basically, the spec for M4 cores (like the F3 and F4) describes a 3 stage instruction pipeline (load/prefetch, decode, execute) along with stuff like branch prediction. In addition to that (I think), the F3 and F4 also have fetch systems to reduce the effect of flash latency. The F4’s is much more complicated, so that might contribute to the jitter. We also recently changed flash latency to be 0 on the F3 (down from 5), while it’s still 5 on the F4, so that’s might also be a factor.
Information is pretty sparse, but you may want to check out the reference manuals for the F3 and F4, since they describe the instruction fetch systems (I think they’re under system overview or flash, usually in chapter 2 or 3).
You mentioned that I can change ‘flash latency’.
How exactly do I do that? adding some flag in the Makefile?
After a little bit of experimenting, I find that removing the const of the Sbox can solve the jittering issue.
However, it is clear from the power trace, that the processor is doing something quite different.
Flash latency can be changed to 0 by changing FLASH_ACR_LATENCY_5WS to FLASH_ACR_LATENCY_0WS in hardware/victims/firmware/hal/stm32f4/stm32f4_hal.c (line 32).
Thank you so much! Now my traces don’t jitter anymore. (I finally got a chance to try it.)
BTW, I recently got the CW508 low pass filter, and it works quite well for removing the spikes on my power trace.
Just wondering, do you guys know what frequency the spikes are in?
Good to hear that fixed it for you. It’s hard to say what the frequency of the spikes are, since the sample rate of the ChipWhisperer probably isn’t high enough to really tell (especially if the LPF is making a difference, which has its -3dB cutoff at 20.8MHz). For reference, here’s the frequency response of the LPF:
I’ll continue the discussion asking something about security (concerning the STM32F4 version):
were someone of you able to attack the AES of the overmentioned model? If so, how did you do this?
To attack the STM32F4 hardware AES, you’ll need to use the LastRoundStateDiff leakage model (instead of SBox_output). It also helps a lot if you attack precisely where the encryption is happening (usually attack.setPointRange((1312, 1314)) for the standard ChipWhisperer aes firmware).
Hello…the spec for M4 cores like the F3 and F4 describes a 3 stage instruction pipeline load/prefetch, decode, execute along with stuff like branch prediction. In addition to that, the F3 and F4 also have fetch systems to reduce the effect of flash latency. The F4’s is much more complicated, so that might contribute to the jitter.
I see, thanks for answering my question.
I did notice when I set the flash latency to anyting other than 0, the jittering shows.
And it makes my power analysis a bit more challenging.
