STM32F415 Hardware Crypto

Embedded Security ChipWhisperer Hardware
1

Hello,

I’ve read that the STM32F415 has a built-in hardware crypto module for AES, and found a limited description of it here: https://rtfm.newae.com/Targets/UFO%20Targets/CW308T-STM32F/#hardware-aes.

“To use the hardware crypto, call HW_AES128_Init() at the beginning of your program. You can update the key with HW_AES128_LoadKey(), encrypt plaintext with HW_AES128_Enc(), and decrypt data with HW_AES128_Dec().”

Is there a working example of this available somewhere that someone could point me to that works with the ChipWhisperer?

2

You can just use the typical AES calls with ChipWhisperer, but instead of CRYPTO_TARGET=TINYAES128C, use CRYPTO_TARGET=HWAES. We actually have a tutorial that does an attack on the STM32F4 HWAES:

Alex

3

Oh awesome. Thank you Alex!

4

Hello again. Do you know if this hardware implementation is masked or unmasked? I’d be curious to know if the provided hardware implementation for the CW305 FPGA is as well.

5

STM32F415 uses unmasked AES for its hardware accelerator.
If you want a hardware masked AES, you can try the K82F target for example.

6

Okay great, thank you.

7

The example CW305 AES implementation isn’t masked.

8

Good day. I can’t compile the example from this lab, when setting CRYPTO_TARGET = ‘HWAES’ the compiler gives errors. Is it possible to fix this? It seems that the code in the lab repository does not correspond to the code used for compilation.

9

What error message are you getting? Compilation works fine for me on the latest commit.

10

Topic 2, Part 2 - CPA on Hardware AES Implementation

SCOPETYPE = ‘OPENADC’
PLATFORM = ‘CW308_STM32F4’
CRYPTO_TARGET = ‘HWAES’

%%bash -s “$PLATFORM” “$CRYPTO_TARGET”
cd …/…/…/firmware/mcu/simpleserial-aes
make PLATFORM=$1 CRYPTO_TARGET=$2

Blockquote …/./hal/Makefile.hal:310: *** Missing fw-extra submodule. See GitHub - newaetech/chipwhisperer-fw-extra: Firmware files for extra firmware targets. Stop.

CalledProcessError Traceback (most recent call last)
Cell In[4], line 1
----> 1 get_ipython().run_cell_magic(‘bash’, ‘-s “$PLATFORM” “$CRYPTO_TARGET”’, ‘cd …/…/…/firmware/mcu/simpleserial-aes\nmake PLATFORM=$1 CRYPTO_TARGET=$2\n’)

File B:\ChipWhisperer5_70_V2\cw\home\portable\WPy64-31080\python-3.10.8.amd64\lib\site-packages\IPython\core\interactiveshell.py:2422, in InteractiveShell.run_cell_magic(self, magic_name, line, cell)
2420 with self.builtin_trap:
2421 args = (magic_arg_s, cell)
→ 2422 result = fn(*args, **kwargs)
2423 return result

File B:\ChipWhisperer5_70_V2\cw\home\portable\WPy64-31080\python-3.10.8.amd64\lib\site-packages\IPython\core\magics\script.py:153, in ScriptMagics._make_script_magic..named_script_magic(line, cell)
151 else:
152 line = script
→ 153 return self.shebang(line, cell)

File B:\ChipWhisperer5_70_V2\cw\home\portable\WPy64-31080\python-3.10.8.amd64\lib\site-packages\IPython\core\magics\script.py:305, in ScriptMagics.shebang(self, line, cell)
300 if args.raise_error and p.returncode != 0:
301 # If we get here and p.returncode is still None, we must have
302 # killed it but not yet seen its return code. We don’t wait for it,
303 # in case it’s stuck in uninterruptible sleep. -9 = SIGKILL
304 rc = p.returncode or -9
→ 305 raise CalledProcessError(rc, cell)

CalledProcessError: Command ‘b’cd …/…/…/firmware/mcu/simpleserial-aes\nmake PLATFORM=$1 CRYPTO_TARGET=$2\n’’ returned non-zero exit status 2.

Blockquote
Something like this… please note that for some reason it looks in the directory GitHub - newaetech/chipwhisperer-fw-extra: Firmware files for extra firmware targets. to which, naturally, I don’t have access… approximately the same messages if I try to compile examples from Topic 2, Part 2 - CPA on Hardware AES Implementation

Building for platform CW308_STM32F4 with CRYPTO_TARGET=HWAES
…/simpleserial/Makefile.simpleserial:24: *** Invalid SimpleSerial version: HWAES; allowed verions:
±--------±-------------+
| Version | SS_VER value |
±--------±-------------+
| V1.0 | SS_VER_1_0 |
| V1.1 | SS_VER_1_1 |
| V2.1 | SS_VER_2_1 |
±--------±-------------+
. Stop.

11

Yes, I also looked and did not find any HWAES defines in the simpleserial-aes.c and simpleserial-aes.cpp files. But it is quite possible that they should not be there.

12

The first error points directly to the problem: you’re missing the chipwhisperer-fw-extra subm odule.
Go to firmware/mcu/hal/ and run git submodule update chipwhisperer-fw-extra.

13

Managed to compile by changing the address of the code location for compilation, here is the line that works:
%%bash -s “$PLATFORM” “$CRYPTO_TARGET” “$SS_VER”
cd …/…/…/hardware/victims/firmware/simpleserial-aes
make PLATFORM=$1 CRYPTO_TARGET=$2 SS_VER=$3

Now we need to understand which leakage model works. Are there any developments on this controller?

14

Now a huge question has arisen why the input and output data in the project are the same, meaning textins=textouts. The data collection module is organized as follows from the example Lab 2_2 - CPA on Hardware AES Implementation (HARDWARE):
project = cw.create_project(“traces/STM32F4_HW_AES.cwp”, overwrite=True)
#Capture Traces
from tqdm.notebook import trange, trange
import numpy as np
import time

ktp = cw.ktp.Basic()

traces =
N = 200000 # Number of traces
scope.adc.samples=2000

scope.gain.db = 32
scope.glitch.arm_timing = “no_glitch”

for i in trange(N, desc=‘Capturing traces’):
key, text = ktp.next() # manual creation of a key, text pair can be substituted here

trace = cw.capture_trace(scope, target, text, key)
if trace is None:
    continue
project.traces.append(trace)

print(scope.adc.trig_count)

15

Is there a ready study to get the correct leakage model for Textins? tested HW and HD leakage at the entrance to the first SBOX. Unfortunately, the result is negative.

16

Hardware implementations of AES will generally only leak good amounts of information as the Hamming distance between the new and old state of its internal register. As such, the SBox output doesn’t work very well against hardware AES.

The lab explains this, but the final two states of the register end up being a good point to run an attack against.

17

Then it turns out that the data obtained after encryption is needed. Which is practically impossible to obtain in real devices. Well, I also understand the attack on the last round. By the way, wouldn’t an attack through profiling work on a real device?

18

And another question… what example of a project should I consider so that I could build these different crypto keys and different input data? Or do I need to write it myself?

19

I disagree. It does limit the attack, but I can think of many situations where you would have access to the ciphertext and not the plaintext.

I can see that being the case, considering the information is still there, just very weak. We’ve done attacks against the normal SBox output before, getting a partial key recovery after a few million traces.

There is also a chosen plaintext attack that is quite a bit more complicated, but does allow you to attack across mixcolumns: chipwhisperer-jupyter/courses/sca201/Lab 2_3 - Attacking Across MixColumns.ipynb at main · newaetech/chipwhisperer-jupyter · GitHub.

20

Thank you for your answers. Briefly, what I understood is that a leak through SBOX is possible, but through a MixColumns attack. Or the second option through Template attacks, but it is necessary to perform profiling on several million routes, detect points of interest and there is no guarantee that all the bits will be found. By the way, is there a ready-made example of code for this attack? I saw a PDF file where there was an attack on EFM32 and STM32, but unfortunately they did not contact me, no matter how I asked them to)