Threat modeling an STM32 sensor node with STRIDE

A lot of embedded security advice is a list of features: use secure boot, enable RDP, turn on the watchdog. All useful, but which ones does your product actually need, and why? Pick at random and you over-build in one place and leave a gap in another.

Threat modeling answers that before you write firmware. The common method, STRIDE, takes about an afternoon on a typical device. This article runs STRIDE on one STM32 product and, for each threat, points to the STM32 feature that handles it. You end up with a threat table and a reusable threat-to-feature list.

STRIDE stands for the six things that go wrong:

Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.

The example device

A battery-powered environmental sensor: an STM32 reads a sensor and reports over a radio (BLE or LoRaWAN) to a gateway and then to a cloud backend. It sits in the field, often somewhere a person can reach: a wall, a pipe, a lamp post. That physical access matters. This is the kind of node that ends up in a botnet when nobody threat-models it.

Whatever your real product is, the method is the same. Swap in your own boxes and arrows.

Step 1: Draw the data-flow diagram

You cannot find threats in a device you cannot see. Start with a data-flow diagram: the processes (running code), the data stores (flash, keys), the data flows (radio link, sensor bus), and the external entities (the gateway, the cloud, the person with a screwdriver). Then add trust boundaries: dashed lines wherever control or privilege changes hands.

Three boundaries matter most here:

• Device to gateway: an untrusted radio link anyone nearby can listen to or inject on.
• Gateway to cloud: a wide-area link over infrastructure you do not own.
• The device's own edge: its debug port (SWD/JTAG), its bootloader and its package are all entry points for someone holding the hardware.

Number each element, then walk the diagram with STRIDE.

Step 2: Walk STRIDE

For each threat, ask whether it can happen here, and if so, what on the chip stops it.

S: Spoofing

A rogue node could pretend to be your sensor and feed the cloud fake readings. A rogue server could pretend to be your backend and send the device bad commands or a bad update.

STM32 feature: give the device a real identity and use it to authenticate both ends.

• Every recent STM32 has a 96-bit unique device ID at a fixed address. Newer secure parts derive a per-device identity from a hardware-unique key (HUK) or PUF. Use it for authentication, but treat the raw ID as an identifier, not a secret.
• Authenticate the link with TLS, using a client certificate or a pre-shared key (PSK), so the device proves who it is and checks the server's certificate before trusting anything. Provision the key in manufacturing.

T: Tampering

Someone reflashes the device with modified firmware, glitches the boot to skip a check, or edits data in transit.

STM32 feature: a secure boot chain plus flash protection.

• Secure boot (X-CUBE-SBSFU on classic parts; OEMuRoT or a TF-M-based SBSFU on Cortex-M33) checks the firmware signature before it runs, so modified code will not start. Images are signed (ECDSA P-256 or RSA) with a SHA-256 hash.
• RDP or product state and WRP stop the flash being read out or overwritten in the first place (see the companion article).
• On the newest parts, watch for fault injection: a voltage or clock glitch can try to skip the signature check. TF-M's fault-injection hardening and the clock and voltage monitors below are the countermeasures.

R: Repudiation

A node, or someone spoofing it, claims it never sent a reading, or a config change cannot be traced. For a sensor this is often low-stakes; for anything that actuates or bills, it is not.

STM32 feature: signed, tamper-evident logging.

• Sign or MAC log entries with a device key so their source is provable.
• Use a monotonic counter (the TAMP peripheral's backup registers, or an RTC-backed counter) so entries cannot be rolled back or replayed, and gaps show up.

I: Information disclosure

Three leaks here: the firmware (read out over debug), the data on the link (sniffed off the radio), and the OTA image (dumped and cloned).

STM32 feature: close each path.

• Firmware at rest: RDP Level 1 or product-state CLOSED blocks read-out over SWD or the bootloader; disable the debug port in production; keep root-of-trust secrets behind HDP.
• Data in transit: TLS or DTLS end to end. Do not plan to add encryption later. Seed it from real entropy (next point).
• OTA image: ship it encrypted and signed, so a captured update gives nothing away and a forged one will not install.

D: Denial of service

A malformed packet hangs the radio stack. A flood drains the battery. A brown-out or a stuck clock wedges the device where nobody can reach it.

STM32 feature: the availability parts most designs already have but do not wire up.

• IWDG: the independent watchdog runs off its own low-speed clock (LSI), so it still fires if the main clock dies or the code deadlocks. Use it to bound critical operations (decryption, flash writes) and to recover from hangs.
• PVD and brown-out reset: detect a low supply (also a common fault-injection symptom) and reset or shut down cleanly.
• CSS (clock-security system): fall back to the internal oscillator if the external clock fails, so the firmware keeps running long enough to react.
• Check input lengths on every packet before you touch a buffer.

E: Elevation of privilege

The classic MCU case: a bug in the large, often third-party comms stack (BLE, LoRaWAN, TCP/IP) is exploited, and now attacker code runs with access to your keys and the whole address space.

STM32 feature: isolation. Keep the network stack away from the secrets.

• MPU (memory protection unit) is on almost every STM32. Put the comms stack in an unprivileged region with no access to the memory holding keys and critical code. This works on classic F4 and L4 parts today.
• TrustZone plus GTZC (Cortex-M33: L5/U5/U3/H5/WBA) goes further: keys and the crypto engine sit in a secure world the non-secure comms stack cannot read. If the stack is exploited, the attacker is still on the wrong side of a hardware wall.

Step 3: The cheat sheet

Put all of that into a table you can reuse on your own product. This is the real output of a threat model.

Classic parts (F0/F1/F2/F4/L4) already have an answer for every row: device ID, MPU, IWDG/PVD, RDP/WRP/PCROP, secure boot through X-CUBE-SBSFU. The Cortex-M33 families (L5/U5/H5/WBA) give a stronger version of the same jobs: TrustZone instead of MPU-only isolation, product state instead of RDP, hardware key storage instead of a bare device ID. You threat-model the same way on either; you just reach for a bigger tool where the silicon has one.

Step 4: Check your work

A threat model is only useful if it is honest. Before you call it done:

• Model the data flow, not the control flow. If you find yourself saying "and sometimes it also...", split that into another flow and look at it.
• Cover every boundary and every element. Walk all six letters against each box and each arrow, not just the interesting ones.
• File a bug for each threat you have not mitigated. A threat with no fix and no ticket is a note you will forget. Track it like any other defect and test that the fix holds.
• Re-run it when the design changes. New radio, new cloud endpoint, new debug feature: redraw the diagram and walk STRIDE again.

Done this way, "we should add some security" turns into a short list of features to enable, with a reason for each.

Want the hands-on version? Running STRIDE on real STM32 designs, then building the mitigations (secure boot, TrustZone isolation, TLS, encrypted OTA) on actual boards, is the core of Ac6's 2-day course SEC5: Embedded Security for STM32-based Devices: