Signierte OTA‑Update‑Pipeline (ESP32 + STM32)

September 3, 2025

⚠️ Referenz‑Implementierung für Produktteams und Schulungen. Anpassungen an Ihre Hardware/Toolchain sind vorgesehen.

• Sicherheit by Design: Ed25519‑Signaturen + SHA‑256‑Integrität + Anti‑Rollback.
• Robustheit: A/B‑Slots, Watchdog‑freundliche OTA‑Writes, Rollback bei Fehlern.
• Transparenz: Kanonisches Manifest (prüfbar, diff‑bar); reproduzierbarer Signier‑Prozess.
• DevEx: Python‑Signer, Verifier, CI‑Workflow (GitHub Actions) – sofort nutzbar.
• Cross‑Target: ESP32 (ESP‑IDF v5.x) & STM32 (Bootloader‑Skeleton) aus einem Baukasten.

• Kanonisches Manifest (JSON): device, version, slot, timestamp, image.sha256/size, meta.*
• Signaturen: Ed25519 über den kanonisierten Manifest‑Body (stabile Sortierung/Separatoren)
• Anti‑Rollback: Monotone Versionsprüfung (NVS/Flash) + optional HW‑Counter
• A/B‑Schema: Sichere Umschaltung, Selbsttest, commit only when healthy
• CI‑fähig: Build → Sign → Artefakt, Schlüsselinjektion via Secrets, Release‑Promotion
• Erweiterbar: SBOM (CycloneDX), Release‑Signaturen (cosign), Staged Rollouts

• Tooling („signer/“): Keygen, Signer, Paket‑Builder (.ota‑ZIP mit manifest.json + firmware.bin), Verifier
• ESP32‑App: OTA‑Flow (Download/Stream), Versionierung, NVS‑Hook, Rollback‑Support über IDF‑Bootloader
• STM32‑Bootloader: Slot‑Auswahl, Manifest‑/Hash‑Validierung (Ed25519‑Verify als Port/Library), Jump‑Logic, Rollback‑Marker
• CI‑Workflow: GitHub Actions‑Vorlage (Build, Sign, Artefakt‑Upload)
• Dokumentation: Threat‑Model, Testplan, Integrationsleitfaden

[CI Build]  ──(Artefakte)──>  [Signer]  ──( .ota Paket )──>  [OTA‑Server/CDN]
                                                │
                                         (HTTPS, Auth)
                                                │
                                         [Device‑Flotte]
ESP32: Downloader → Verify(Signatur+Hash) → Stream in OTA‑Partition → Reboot → Self‑Test → Commit
STM32: Bootloader wählt Slot → Verify(Signatur+Hash) → Jump → bei Fehlern Rollback/Alternativ‑Slot

• Authentizität & Integrität: Ed25519 über Manifest; SHA‑256 über Image
• „Verify‑before‑Commit“: Keine Aktivierung ohne vollständige, geprüfte Daten
• Rollback‑Resilienz: A/B‑Schema + monotone Version
• Schlüsselhygiene: Offline‑Root, kurzlebige CI‑Keys, Rotation & Pinning der Public Keys
• Supply‑Chain: Optional SBOM + Release‑Signaturen + reproduzierbare Builds

{
  "body": {
    "device": "esp32|stm32",
    "version": "1.2.3",
    "slot": "ota_0|ota_1|app_a|app_b",
    "timestamp": "2025-09-03T12:00:00Z",
    "image": { "sha256": "…", "size": 524288 },
    "meta": { "min_bootloader": "1.0.0", "rollback_protected": true }
  },
  "signature": { "algo": "ed25519", "value": "BASE64_SIG" }
}

• Partitionen: factory, ota_0, ota_1
• OTA‑Stream via esp_https_ota
• Pre‑Commit‑Prüfungen: Manifest‑Signatur, Image‑Hash, Version
• Self‑Test nach Reboot; esp_ota_mark_app_valid_cancel_rollback()

• Slots A/B + Manifest‑Header im reservierten Bereich
• Verify(Signatur/Hash) vor Jump
• Rollback‑Marker in Backup‑SRAM/Option Bytes
• Power‑fail‑sicheres Umschalten

1. Build (ESP32/STM32) → Binärartefakt
2. Sign: signer.py erzeugt .ota mit Manifest+Signatur
3. Publish: Upload zum OTA‑Server/CDN, Freigabe per Environment‑Gate
4. Deploy: Gerät lädt Paket (HTTPS), prüft Manifest/Hash, streamt in Ziel‑Slot
5. Commit: Nach Self‑Tests → Commit, sonst Rollback

# 1) Schlüssel erzeugen (offline)
cd signer && python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
python generate_keys.py  # keys/ed25519_priv.pem + ed25519_pub.pem

# 2) ESP32 bauen
idf.py -C esp32 set-target esp32 && idf.py -C esp32 build

# 3) Paket signieren
python signer.py \
  --pubkey keys/ed25519_pub.pem \
  --privkey keys/ed25519_priv.pem \
  --device esp32 --version 1.0.0 --slot ota_0 \
  --image ../builds/esp32-app.bin \
  --out ../dist/esp32-app-1.0.0.ota

# 4) Paket prüfen
python verify_package.py --pubkey keys/ed25519_pub.pem --package ../dist/esp32-app-1.0.0.ota

• Device‑seitige Ed25519‑Verifikation als leichtgewichtige Library (z. B. TweetNaCl‑Port) integriert/portiert.
• Public Key im Gerät hinterlegt (Rotation via Update möglich).
• Optional: NVS‑Verschlüsselung (ESP32) & Secure Boot/TrustZone/TPM‑Anbindung.

• Unit: Signer/Verifier (Schema, Kanonisierung, Round‑Trip), Versionslogik
• Integration (ESP32): Positivpfad, Signaturfehler, Hash‑Mismatch, Rollback‑Pfad
• Integration (STM32): Slot‑Matrix (A/B gültig/ungültig), Brown‑Out während des Updates
• HIL: Netzabbrüche, Watchdog‑Trigger, Wiederanlauf‑Szenarien

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Service",
    "name": "Signierte OTA‑Update‑Pipeline (ESP32 + STM32)",
    "provider": {
      "@type": "Organization",
      "name": "Büngener Software",
      "url": "https://buengener-software.de"
    },
    "areaServed": "EU",
    "serviceType": "Embedded OTA Security",
    "offers": {
      "@type": "Offer",
      "price": "0",
      "priceCurrency": "EUR",
      "availability": "https://schema.org/InStock"
    }
  }
</script>

• v1.0 – Referenz‑Pipeline (Tooling, ESP32/STM32, CI, Doku)