Project 8: RP2350 Secure Boot Implementation

Build a signed boot chain with fallback and TrustZone partitioning on RP2350.

Quick Reference

Attribute	Value
Difficulty	Level 5: Master
Time Estimate	2-3 weeks
Main Programming Language	C
Alternative Programming Languages	Rust
Coolness Level	Level 5: “security engineer”
Business Potential	4. Critical for production devices
Prerequisites	Boot flow, hashing, basic crypto concepts
Key Topics	Secure boot, TrustZone, signature verification

1. Learning Objectives

Design a signed firmware image format.
Verify firmware signatures at boot.
Partition secure vs non‑secure memory regions.
Implement rollback protection.
Build a recovery path for invalid images.

2. All Theory Needed (Per-Concept Breakdown)

2.1 Secure Boot and Root of Trust

Fundamentals

Secure boot ensures only trusted firmware runs. The root of trust is the immutable key or ROM logic that decides what is valid.

Deep Dive into the concept

Secure boot chains validate each stage before execution. The RP2350 supports hardware‑accelerated hashing and cryptographic verification. A typical design: Boot ROM verifies a signed header, validates a hash of the firmware, and only then jumps to code. Root of trust keys are stored in OTP or hardware‑protected memory. If keys are compromised or misprogrammed, the device can be permanently bricked. Rollback protection uses monotonic counters stored in OTP or secure flash to prevent downgrades to vulnerable versions.

Key insights

Secure boot is only as strong as its root of trust storage.

2.2 TrustZone (Secure vs Non‑Secure)

Fundamentals

TrustZone splits memory and peripherals into secure and non‑secure regions. Secure code runs first and configures access controls.

Deep Dive into the concept

The secure bootloader configures the SAU/IDAU to mark memory regions. Secure code can access everything; non‑secure code is limited. The secure world should be minimal: verify images, initialize security, then hand off to non‑secure application. Any mistake in attribution can lock out required peripherals or expose sensitive data.

Key insights

Keep the secure world tiny and auditable.

2.3 Cryptographic Hashing and Signatures

Fundamentals

Hashes provide integrity; signatures provide authenticity. In secure boot, the firmware hash is verified using a signature and a public key.

Deep Dive into the concept

A signed image typically includes: version, size, hash, and signature. At boot, compute the hash over the firmware region and compare it to the signed hash. Hardware SHA engines reduce CPU cost. Choose an algorithm like ECDSA or Ed25519. Validate signature before copying or executing code.

Key insights

Integrity without authenticity is not enough.

3. Project Specification

3.1 What You Will Build

A secure bootloader for RP2350 that verifies signed firmware images, enforces rollback protection, and cleanly separates secure/non‑secure execution.

3.2 Functional Requirements

Signed firmware image format with version and hash.
Signature verification at boot.
TrustZone memory attribution.
Rollback protection using monotonic counters.
Recovery path to fallback image.

3.7 Real World Outcome

Valid images boot; tampered images are rejected. Logs show verification steps and fallback selection.

4. Solution Architecture

Boot ROM -> Secure Bootloader -> Verify -> Configure TZ -> Launch Non‑Secure App

5. Implementation Guide

5.10 Implementation Phases

Phase 1: Define image header and hashing
Phase 2: Signature verification + rollback
Phase 3: TrustZone partition and recovery slot

6. Testing Strategy

Validate good signature
Reject corrupted image
Rollback test with older version

7. Common Pitfalls & Debugging

Incorrect key in OTP
Misconfigured TrustZone regions

8. Extensions & Challenges

Add encrypted firmware storage
Add attestation report

9. Submission / Completion Criteria

Minimum Viable Completion:

Signed image verification works.

Full Completion:

Rollback protection and TrustZone separation.

Excellence:

Recovery path and audit logs.