Firmware Anti-Rollback: Warum signierte Firmware trotzdem downgegradet werden kann

Betrachten wir ein Produkt ohne durchgesetzten Mindest-Sicherheitsstand: Ein Angreifer flasht Firmware-Version 3 auf ein Gerät, das Version 5 läuft. Das Image ist alt, aber echt, signiert mit dem echten Release-Key, korrekt gehasht, sauber verpackt. Jede Signaturprüfung besteht. Das Gerät bootet es fröhlich. In diesem Beispiel enthält Version 3 Schwachstellen, die spätere Releases beheben. Ihre Annahme bringt diese Schwachstellen trotz gültiger Signatur zurück.

Das ist ein Downgrade-Angriff, und nichts an der Signaturprüfung verhindert ihn. Signaturen belegen Authentizität, nicht Aktualität. Schutz vor sicherheitsrelevanten Rollbacks ist eine eigene Eigenschaft, eine Version Policy, und muss als solche konstruiert werden. Nicht jeder Wechsel zu einem älteren Release verletzt diese Policy.

Was ein Downgrade dem Angreifer bringt

Downgrades sind attraktiv, weil sie bereits investierte Arbeit in Angriffsmöglichkeit verwandeln. Das alte Image enthält bekannte, dokumentierte Schwachstellen, solche, die Sie nach echten Befunden gefixt haben. Der Angreifer braucht keine Zero-Day; er braucht Ihr v3-Binary und einen Weg, das Gerät dazu zu bringen, es anzunehmen. Die Pfade sind gut verstanden: das Update-Interface selbst (wenn es jedes signierte Paket akzeptiert), ein Recovery- oder Field-Service-Mode, der Images mit weniger Prüfungen lädt, oder direkter Flash-Zugriff bei geöffnetem Gehäuse.

Es gibt eine zweite, leisere Variante: das Zurückrollen nicht des ganzen Images, sondern der Konfiguration. Ein Gerät, das seine Policy-Einstellungen herunterstuft, schwächeres TLS akzeptiert, ein Debug-Interface reaktiviert, einen Prüfschritt lockert, verliert dieselben Fixes, ohne dass ein Byte Firmware wechselt.

Firmware-Version ist nicht Security-Version

Eine Firmware-Version bezeichnet ein Release. Ein unabhängiger Security-Counter beschreibt den Sicherheitsstand, den die Release-Policy zuweist. Dieser Counter muss nicht bei jedem Feature-Update steigen. In unserem illustrativen Beispiel tragen Firmware v4 und v5 jeweils Security-Counter 8, v3 dagegen Counter 7. Bei gespeichertem Mindestwert 8 kann v4 nach v5 weiterhin zulässig sein, während v3 abgelehnt wird. Ein gleicher Counter beweist keinen gleichen Sicherheitsstand: Der Release-Prozess muss sicherstellen, dass jedes Image mit diesem Wert die vorgesehene Sicherheitsbasis erfüllt.

Diese Trennung ist in Trusted Firmware-M ausdrücklich vorgesehen, kein Workaround. Auch eine strengere Policy anhand der Release-Versionen ist möglich. Das Produkt muss definieren, welche Regel gilt, und sie durchgängig erzwingen.

Monotone Counter: der Mechanismus

Bei einer Security-Counter-Policy vergleicht der Prüfer den authentifizierten Image-Counter mit einem geschützten Mindestwert. Diesen Mindestwert darf ein Angreifer innerhalb des definierten Bedrohungsmodells nicht absenken können. Mögliche Bausteine sind:

• eFuse-/OTP-Bits. Irreversible Änderungen können einen monotonen Sicherheitswert kodieren. Kodierung und verfügbare Übergänge sind plattformspezifisch und endlich; eine Release-Nummer entspricht nicht unmittelbar der Zahl verbrauchter Fuses.
• RPMB-gestützter Speicher. eMMC/UFS-RPMB bietet authentifizierten, replay-geschützten Zugriff mit einem Schreibzähler. Die gespeicherten Daten sind nicht von sich aus monoton: Vertrauenswürdige Software muss das Absenken des gespeicherten Sicherheitsminimums verhindern und den Autorisierungsschlüssel schützen. Die OP-TEE-Speicherdokumentation unterscheidet den RPMB-Schreibzähler von den Daten seiner Speicherblöcke.
• Geschützte Counter oder Speicherdienste. Secure Element oder TEE können je nach Baustein und Integration einen geschützten Mindestwert bereitstellen. Dessen Änderungsrechte und Lebenszyklus bleiben Teil der Prüfung.

MCUboot kann den Image-Security-Counter beispielsweise im geschützten TLV-Bereich tragen. Entscheidend ist: Images unterhalb des verbindlich gesetzten Mindest-Security-Counters ablehnen, den Image-Counter authentifizieren und das Absenken des gespeicherten Mindestwerts durch einen Angreifer verhindern. Das ist nicht zwangsläufig die höchste je gestartete Release-Nummer.

Das Counter-Budget-Problem

Nutzt das Design endliche OTP-Übergänge, ist die Counter-Vergabe eine Aufgabe des Release-Engineerings. Sicherheitsupdates von Feature-Versionen zu trennen ist ein regulärer Weg, dieses Budget zu schonen. Entscheidend ist, welche Fixes einen neuen Security-Counter erfordern, wie alle Images eines Counter-Werts auf der vorgesehenen Sicherheitsbasis bleiben und was bei ausgeschöpftem Hardware-Budget passiert. Einem Image stillschweigend einen alten Sicherheitswert zuzuweisen, obwohl es einen höheren Mindeststand voraussetzt, untergräbt die Policy, nicht der unabhängige Counter selbst.

Der Anti-Brick-Trade-off

Ein zu früh angehobener Mindestwert kann das letzte funktionierende Recovery-Image sperren. Bei A/B- oder Trial-Boot-Designs brauchen Installation, erfolgreiche Funktionsprüfung, Bestätigung und verbindliches Anheben des Minimums deshalb eine definierte Reihenfolge. Stromausfall und ausbleibende Bestätigung gehören in den Test. Der sichere Ablauf hängt von Bootloader und Plattform ab; einfach das höchste je versuchte Image zu vermerken reicht als Design nicht aus.

Ein Recovery-Pfad darf ein älteres Release zulassen, das den verbindlichen Mindest-Sicherheitsstand weiterhin erfüllt. Er darf nicht stillschweigend einen bekanntermaßen verwundbaren Sicherheitsstand wiederherstellen. Eine minimale Recovery-Umgebung kann eine eigene, ausdrücklich begrenzte Policy haben, muss aber die vorgesehenen Schutzmechanismen bewahren und das geforderte Minimum für installierte Images durchsetzen.

Was eine sichere Update-Policy braucht

Wenn wir Update-Mechanismen reviewen, sind die Versionsfragen fix:

• Vergleicht die Policy Release-Versionen oder unabhängige Security-Counter, und welche Releases bleiben bewusst zulässig?
• Wo liegt der Mindest-Sicherheitswert, und was hindert einen Angreifer mit Flash-Zugriff daran, ihn abzusenken?
• Was passiert bei einem Vergleichsfehler, loggen, verweigern oder trotzdem booten?
• Gilt die Policy auch für Konfigurations- und Policy-Daten, oder nur für das Haupt-Image?
• Erzwingen Recovery-Pfade denselben Mindest-Sicherheitsstand, und welche ausdrücklichen Ausnahmen gibt es?
• Wer darf das Minimum anheben, wie ist das authentifiziert und wann wird es im Verhältnis zu Trial Boot und Bestätigung verbindlich gesetzt?
• Wenn die Counter-Technologie aufgebraucht oder abgekündigt ist: Was ist der Migrationsplan?

Ein sinnvoller Test nutzt mehr als irgendein altes Image: Bieten Sie ein signiertes Image unterhalb des verbindlichen Sicherheitsminimums an und, sofern die Policy es erlaubt, ein älteres Release mit demselben Security-Counter. Das erste muss abgelehnt werden; das zweite darf zulässig bleiben, wenn auch Signatur-, Kompatibilitäts- und alle übrigen erforderlichen Prüfungen bestehen. Wiederholen Sie das über Update- und Recovery-Pfade und dokumentieren Sie Policy, Plattformkonfiguration und beobachtete Entscheidungen. So unterscheidet man einen kontrollierten Rückfall von der Wiedereinführung einer Schwachstelle.