Secure OTA Updates in Embedded Linux Systems

About the Course

IoT devices require continuous monitoring, security patching, and new feature deployment. OTA (Over-The-Air) mechanisms have become as critical as the operating system itself.

In the embedded environment, two concepts are key:

• Atomicity — an update either succeeds completely or not at all
• Fault tolerance — power loss during update doesn’t “brick” the device

The STM32MP1 platform with its heterogeneous architecture (Cortex-A7 + Cortex-M4) poses unique challenges: file system management, kernel dependencies, Device Tree, and coprocessor firmware synchronization.

This training guides you through complete OTA implementation — from an empty Yocto project, through A/B partitioning, to failure scenarios with automatic rollback.

🎯 Project Goal: “Resilient Update System”

During the course, we build a production-ready OTA system, not just configure tools. Participants will create a system that:

✓ Supports A/B updates — new image written to inactive slot, atomic switch

✓ Verifies digital signature (X.509/CMS) — only authorized packages are accepted

✓ Automatically reverts to previous version — rollback after failure (Kernel Panic, no network)

✓ Updates M4 coprocessor firmware — A7 + M4 version synchronization

✓ Protects against Downgrade Attack — blocks installation of older versions

✓ Works with TF-A metadata — RAUC integration with STM32MP1 specifics

📅 Training Program

DAY 1: The Foundation – Architecture and Partitioning

OTA system fundamentals. Flash Layout, A/B strategy, and Yocto layer integration.

Module 1.1: Update Architecture on STM32MP1

• Why apt-get upgrade doesn’t work in embedded? (failure = inconsistent file system)
• A/B (Dual Bank) strategy: Atomicity and fault tolerance
• Boot process: ROM Code → TF-A → U-Boot → Linux
• Role of metadata partition — TF-A decides slot selection!

Module 1.2: Flash Layout for OTA

• Partition layout design for A/B (Dual Bank) strategy
• Key components: bootloader, kernel, rootfs, user data
• metadata partition and FWU bank states
• Lab: Building base st-image-core image without OTA (starting point)

Module 1.3: OTA Tool Selection

• Overview of available solutions: Mender, SWUpdate, RAUC
• Selection criteria: size, flexibility, ecosystem integration
• Why RAUC? Reference tool for STM32MP1
• Lab: Yocto layer configuration for RAUC

DAY 2: The Mechanism – RAUC and TF-A Metadata

RAUC configuration, bootloader integration, and update package creation.

Module 2.1: RAUC Configuration

• Slot mapping and system configuration
• Common pitfalls in U-Boot integration
• Lab: RAUC configuration for A/B layout

Module 2.2: Integration with U-Boot and TF-A

• Communication between Linux and bootloader
• TF-A metadata management
• Lab: Verifying integration correctness

Module 2.3: Switching Scripts (Handlers)

• Update lifecycle: installation → restart → validation
• Success confirmation mechanism (“Mark Good”)
• Lab: Implementing custom handlers

Module 2.4: Creating Update Packages (Bundle)

• RAUC package structure and format
• Building bundles in Yocto
• Lab: Creating and analyzing an update package

DAY 3: The Security & Resilience – Security and Failure Scenarios

Signing, encryption, rollback protection, and resilience testing.

Module 3.1: PKI Infrastructure and Signing

• X.509 and CMS basics in OTA context
• Key hierarchy: CA, development keys, production keys
• Lab: Creating PKI and signing packages

Module 3.2: Attack Simulation

• Verifying resistance to package manipulation
• Lab: Attempting to install unauthorized/modified packages

Module 3.3: Artifact Encryption (Confidentiality)

• Intellectual property protection in OTA packages
• Per-device vs per-fleet encryption
• Discussion: When to encrypt? (cost vs risk)

Module 3.4: Rollback Protection (Anti-Rollback)

• Threat: Downgrade Attack
• Protection mechanisms: monotonic counters, versioning
• Lab: Configuring and testing downgrade protection

Module 3.5: Failure Scenarios and Rollback

• Watchdog and Bootcount mechanism
• Automatic rollback after failed update
• Lab: Failure simulation and observing automatic recovery

Module 3.6: Heterogeneous Updates (A7 + M4)

• Linux + coprocessor firmware version synchronization
• Rollback strategies for multi-core systems
• Lab: Update including M4 firmware

💰 Pricing and Participation Models

I offer a flexible model tailored to the scope of knowledge needed.

Option A: CORE OTA (2 Days)

Ideal for teams that need to implement a basic A/B mechanism with RAUC, without advanced security scenarios.

Option B: SECURE OTA (3 Days) ⭐ Recommended

Complete training with PKI, anti-rollback, and resilience testing. Essential for products requiring certification or compliance (CRA, IEC 62443).

Promotion: By choosing the 3-day package upfront, you save €100 compared to adding the 3rd day separately.

Small teams: For teams smaller than 5 people - rates are negotiated individually.

🏆 Why is it worth it?

🛠️ Requirements

Hardware (provided):

• STM32MP157C-DK2 board
• 16GB microSD card (class 10)
• USB Type-C cable, USB-UART converter

Software:

• Ubuntu 20.04/22.04 LTS (or Docker container)
• OpenSTLinux SDK (Kirkstone/Scarthgap)
• Layers: meta-rauc, meta-st-ota

Participant knowledge:

• Linux basics (shell, partitioning)
• Yocto basics (building images, adding layers)
• Nice to have: U-Boot familiarity

Want to reserve a date for your team? Contact me to arrange details. Build a system that survives every update — even a failed one.