Versendest du ein Bluetooth-Modul mit unsigniertem Firmware, hast du implizit jedem vertraut, der es flashen kann. Ein Konkurrent klont dein Produkt, ein Angreifer setzt eine Hintertuer, oder ein fehlerhaftes OTA bricked den Bestand — und beim Boot kannst du dein Image nicht von seinem unterscheiden. Secure Boot schliesst diese Luecke: die Hardware verifiziert kryptografisch eine Signatur, bevor irgendein Code ausgefuehrt werden darf. Dieser Artikel behandelt die technische Seite — Root of Trust, Signaturkette, Key-Provisionierung, Anti-Rollback, sicheres OTA, Debug-Lockdown und die Kompromisse, die du eingehst.
Warum Secure Boot existiert
Die Bedrohungen sind konkret:
- Klonen. Ein unsigniertes Image laesst sich von einer Einheit lesen und auf tausend Faelschungen flashen.
- Boeswilliges OTA. Ist der Update-Kanal nicht authentifiziert, gehoert dem Angreifer das Geraet, sobald er ihn erreicht.
- Manipulation in der Lieferkette. Ein kompromittierter Build-Server oder Dienstleister liefert Code, den du nie geschrieben hast.
- Persistente Implantate. Ein Implantat auf Bootloader-Ebene ueberlebt App-Updates, weil der App-Verifizierer *unter* ihm laeuft.
Ohne Secure Boot ist die einzige Grenze “kann der Angreifer physisch flashen oder den Port erreichen?”. Damit wird sie zu “besitzt der Angreifer den privaten Signier-Key?”.
Root of Trust
Alles ruht auf einem unveränderlichen ROM-Bootloader, der im Werk in den Silizium gebrannt wird. Er enthaelt die Verifizierungslogik des Herstellers und einen einmal programmierbaren Bereich (OTP / eFuse), der den *Hash deines oeffentlichen Schluessels* haelt — nie den privaten.
- Der private Schluessel lebt nur auf einem Offline-Signier-Server und beruehrt das Geraet nie.
- Die Vertrauenskette laeuft ROM -> Bootloader -> Anwendung. Jede Stufe verifiziert die Signatur der naechsten, bevor sie die Kontrolle uebergibt.
Ein uebliches Layout:
ROM (fest) --verifiziert--> Bootloader (signiert) --verifiziert--> Anwendung (signiert)Das Signaturverfahren
Der Mechanismus ist asymmetrische Signierung:
1. Das Image wird gehasht (SHA-256) und der Hash offline mit deinem privaten ECDSA-P-256- (oder Ed25519-)Schluessel signiert.
2. Der Bootloader berechnet den Hash beim Einschalten neu und verifiziert die Signatur gegen den oeffentlichen Schluessel, dem er vertraut.
3. Nur wenn die Verifizierung besteht, springt er in das Image.
Den vollstaendigen oeffentlichen Schluessel in eFuse zu speichern verschwendet knappe Bits, daher speichern die meisten Designs einen SHA-256 des oeffentlichen Schluessels. Der Bootloader prueft zuerst, ob der Schluessel im Image mit dem eFuse-Digest uebereinstimmt, und verifiziert dann die Signatur mit jenem Schluessel.
Eine minimale Verifizierung:
def verify_image(img, pk_digest, sig):
if sha256(img.public_key) != pk_digest:
return FAIL # falscher Schluessel
if not ecdsa_verify(img.public_key, sig, sha256(img.code)):
return FAIL # ungueltige Signatur
return OKAnti-Rollback
Ein signiertes Image genuegt nicht, wenn ein Angreifer ein *altes, anfaelliges* signiertes Image flashen kann, das du letztes Jahr ausgeliefert hast. Die Loesung ist ein monotoner Versionszaehler in eFuse:
- Das Image traegt eine Versionsnummer; das Geraet speichert die hoechste ausgefuehrte Version.
- Der Boot verweigert ein Image, dessen Version niedriger als der gespeicherte Zaehler ist.
- eFuse-Bits sind unidirektional, also muss der Zaehlerplan vor der Produktion feststehen — spaeter kann man nicht “mehr hinzufuegen”.
Sicheres OTA
Dieselbe Signatur, die das Werks-Image schuetzt, muss auch Updates schuetzen. Der Ablauf:
1. CI signiert das neue Image mit dem Offline-Schluessel; das Geraet verifiziert es beim Download.
2. Nutze ein Dual-Bank-Layout: schreibe das Update in Slot B, verifiziere und tausche dann. Schlaegt die Verifizierung fehl, laeuft Slot A weiter — kein Brick.
3. Der OTA-Signier-Key muss mit dem eFuse-Key uebereinstimmen, also ist der Update-Kanal Ende-zu-Ende authentifiziert.
Debug-Interface-Lockdown
Ein Bluetooth-Modul mit offenem SWD/JTAG ist ein offenes Buch: vollstaendiges Auslesen und Refashen des Codes. Secure Boot ist nur so stark wie der Debug-Port:
- Sperre das Debug-Interface nach der Provisionierung.
- Biete eine kontrollierte Wiederoeffnung — typischerweise “Alles loeschen zum Entsperren” oder Challenge-Response — damit Retouren/RMA gelsocHT, aber nie ausgelesen werden koennen.
- Ein Vergleich ueblicher Implementierungen:
| Steuerung | nRF Secure Boot (NSIB) | ESP32 Secure Boot v2 | Generisches eFuse-SoC |
|---|---|---|---|
| Schluesselstore | eFuse-Hash der Pubkey | eFuse-Pubkey-Digest | OTP-Hash |
| Signatur | ECDSA P-256 | RSA-3072 / ECDSA | ECDSA |
| Anti-Rollback | Monotoner Zaehler | Version in eFuse | Manuell |
| Debug-Lock | CTRL-AP-Lock | JTAG-disable eFuse | SWD-Lock |
| Sicheres OTA | MCUBoot / SUIT | Nativ | Custom |
Krypto-Hardware auf dem Modul
Moderne BLE-SoCs bringen die noetigen Primitiven mit: einen TRNG, AES und ECDSA-Beschleuniger (nRF52/53, ESP32, DA1459x). Eine Signaturverifizierung auf einem Cortex-M4 dauert Zehner von Millisekunden und zieht in dieser Burst mA — trivial gegenueber einem einmaligen Boot. Nutze die Bootloader-Bibliotheken des Herstellers; roll deine eigene Krypto nicht.
Kompromisse und Fehlermodi
Secure Boot ist nicht umsonst:
- Brick-Risiko. Verlierst du den privaten Schluessel, kannst du nie wieder signieren — keine Feld-Updates mehr. Die Schlüssel-Verwahrung ist das wichtigste Gut.
- Kein Downgrade. Eine schlechte neue Version laesst sich nicht durch Flashen der alten umgehen (der Zaehler blockt). Du musst ein *neueres* korrigiertes Build pushen.
- Provisionierungs-Ausbeute. eFuse-Burns sind unidirektional; ein Fehlburn bricked die Einheit in der Linie. Validiere die Gold-Einheit vor dem Massen-Burn.
- Recovery. Plane von vornherein einen Pfad fuer ein signiertes “Recovery”-Image; nachtraeglich ist es schwer.
Was ein OEM tun muss
Wer ein Bluetooth-Modul baut, das das Werk verlaesst, braucht mindestens:
1. Schluesselpaar auf einem Offline-HSM / Signier-Server erzeugen. Der private Schluessel gehoert nie auf einen Entwickler-Laptop oder CI-Runner.
2. Hash des oeffentlichen Schluessels in eFuse brennen in einem geschuetzten Provisionierungs-Schritt; an der Gold-Einheit vor der Massenproduktion verifizieren.
3. Jedes Artefakt signieren — Bootloader, Anwendung, OTA — in CI mit dem Offline-Schluessel.
4. Anti-Rollback aktivieren und Debug-Port sperren.
5. Einen Recovery-Pfad (signiertes Recovery-Image) und einen Plan fuer Schluessel-Rotation / Widerruf behalten.
Fazit
Secure Boot verschiebt das Vertrauen von “wer flashen kann” zu “wer den Schluessel hat”. Er ist im Design billig hinzuzufuegen und nachtraeglich fast unmoeglich. Baue ihn ein, sperre den Debugger und huete den privaten Schluessel wie einen Kronjuwel — denn fuer einen Angreifer ist deine Firmware-Signatur das einzige, was zwischen ihm und deinem Produkt steht.
