Later updates seems to break STM32F4 Usage

Embedded Security ChipWhisperer Software
#1

I have previously implemented Kyber and Saber both on the CWLITEARM and CW308_STM32F3/4 and it works fine. I’ve been having trouble attempting to print out the Saber secret key. I could print it out for the Kyber algorithm and everything else but the secret key for Saber. I updated to the latest CW version and I can now successfully print out the SK with the correct CRC.

One of the problems I ran into is that it seems that one of the updates between the Windows executable version of CW to the latest is that I cannot run any STM32F4 code. I can run Kyber/Saber fine on both my CWLITEARM and CW308_STM32F3 but cannot run on the STM32F4 board. I get the problem saying that the trigger cannot be seen.

I’ve attempted to rollback the HAL from a couple months ago but it still seems to not work. I’ve used Simpleserial 2.0 for the past couple months and it worked fine until I got to the SK from Saber problem. I’ve also tested this on the “1 - Connecting to Hardware” notebook where it uses Simpleserial base and it works fine for both SS 1.1 and 2.1 for the STM32F3. For the F4, neither works, and I cannot even read the message sent to the board when doing the read command or find the trigger.

I’d also like to note that when using the STM32F4 for TRNG, I got a warning saying that inside “stm32f4xx_hal_rng.c”, “HAL_GetTick()” is never implemented, so I put that function in the header file inside “stm32f4_hal_lowlevel.h” so that it could be used. It seemed to fix the problem when attempting to use TRNG on the Windows CW version.

Another note is that it’d be nice if you guys allowed an easy turn on for FPU usage on the STM32F3 like the STM32F4. I did the solutions from this post and it seemed to work with also changing the makefile similar to the STM32F4 makefile.

#2

Hi,

Thanks for the report on the STM32F4 issues. I’ll see if I can replicate this and find a fix. Do you mean that adding the function prototype for HAL_GetTick() to stm32f4_hal_lowlevel.h fixed the issue for you?

Our HAL_GetTick() is a pretty big hack to avoid interrupt use - basically the normal HAL always has an interrupt timer going in the background that increments a counter, which can mess with side channel analysis. Unfortunately, this can also break some other parts of the HAL, so you might be running into this here.

Yup, I can get this done for you. IIRC we disable the FPU by default, since it can cause situations where some versions of GCC will include invalid library code that ends up crashing the target and being pretty hard to debug.

Alex

#3

Hello,

Yes, adding HAL_GetTick() to stm32f4_hal_lowlevel.h and including it in the RNG file fixed the issue on running the STM32F4 board on CW 5.5.2. Before, I could not run the STM32F4 at all until I added this part.

I’m not sure exactly what’s causing the STM32F4 to not work on the latest CW version, but I did also do the HAL_GetTick() again so it could be the reason.

Tristen

#4

Hello,

When attempting to debug, it seems to be stuck on the while-loop on line 136 in stm32f4_hal_lowlevel.c where it’s waiting until the “HSE” is ready.

Tristen

#5

Hello,

Disregard the HAL_GetTick() in header fix as it runs fine without that trick I did on CW 5.5.2. Not sure what problem I was facing at the time but the TRNG runs fine without any fix.

I removed that function from the header but it still does not run the F4 on the latest CW version.

I’m going roll back to CW 5.5.2 for the time being.

Tristen