F303, F415, L443 have different AES trace lengths and shapes

1

Hi,
I have 3 devices F303, F415 and L443 which I am implementing on UFO board.
Setup

  1. Clock Frequency = 7.328MHz, clkgen_x1
  2. I am executing simpleserial-aes on all devices.
  3. All devices have Cortex M4 processor.

Since the processor (difference in SRAM) and clock frequencies are identical I was assuming the AES trace lengths for each one will be close to each other. But I observe that the trace lengths vary for each one of the devices.

Figures

f303
f3031440×764 132 KB

Setup Images
F303

F303
F3031920×1440 403 KB

F415

F415
F4151920×1440 442 KB

L443

L443
L4431920×1440 402 KB

My questions are

  1. Do the traces look like AES power traces, especially F415?
  2. Is it correct to have different trace lengths for each device?
  3. Is there a way to have trace lengths close to each other for different devices?
  4. Along with trace length the trace shapes are also very different. Could this be due to internal variations? If so what internal variations can account for this.

Please let me know if there is any more information required to answer the questions.

Thanks.

2

The 415 and 443 have hardware AES. Are you building their firmware with HWCRYPTO defined?

3

I think so. Here is the code snippet

SCOPETYPE = 'OPENADC'
PLATFORM = 'CW308_STM32L4' 
#PLATFORM = 'CW308_STM32F4'
#PLATFORM = 'CW308_STM32F3'

CRYPTO_TARGET = "HWAES" ##Used for F415 and L443 device
#CRYPTO_TARGET = "MBEDTLS" ##Used for F303 device

I do not know if this will help, but I get the following warnings while compiling F415 device. No warnings while compiling F303 and L443.

In file included from .././hal/stm32f4/stm32f4_hal.c:3:
.././hal/stm32f4/stm32f4_hal_lowlevel.h:108: warning: "STM32F415xx" redefined
  108 | #define STM32F415xx
      | 
<command-line>: note: this is the location of the previous definition
In file included from .././hal/stm32f4/stm32f4_hal_lowlevel.c:39:
.././hal/stm32f4/stm32f4_hal_lowlevel.h:108: warning: "STM32F415xx" redefined
  108 | #define STM32F415xx
      | 
<command-line>: note: this is the location of the previous definition
.././hal/stm32f4/stm32f4xx_hal_rng.c: In function 'HAL_RNG_GenerateRandomNumber':
.././hal/stm32f4/stm32f4xx_hal_rng.c:264:17: warning: implicit declaration of function 'HAL_GetTick' [-Wimplicit-function-declaration]
  264 |     tickstart = HAL_GetTick();
      |                 ^~~~~~~~~~~

Can we ignore this warning?

4

Indeed you are. Which means that your 415 and 443 targets are using the hardware AES module included in those processors, instead of the software implementation. So it’s no surprise that the power trace would look very different.
Using the hardware offload also makes the encryption much faster; you can see how many clock cycles the encryption takes by checking scope.adc.trig_count for each case.

If you recompile your 415 and 443 targets with CRYPTO_TARGET set to what you used for the 303, then you should obtain more similar-looking power traces. But don’t expect them to be exactly the same: even though all three are “Cortex M4” processors, the firmware generated for each target could be different (due to differences in their respective HALs); furthermore, the 3 processors may not be identical at the transistor level.

I think so but @Alex_Dewar can confirm.

Jean-Pierre

5

Yeah, that error is safe to ignore.

6

Thanks Jean-Pierre and Alex for you prompt reply.
By changing CRYPTO_TARGET to “MBEDTLS” before compiling software for F415 and L443, I am now able to get traces that are almost the same length.
Here is an image after the change.

f303_f415_l443_24db
f303_f415_l443_24db1440×757 134 KB