Ein Update-Pfad, der Pakete signiert, aber der Zustellung vertraut, oder beim Download verifiziert, aber nicht bei der Installation, macht aus einer Wartungsfunktion einen Angriffspfad. Der Mechanismus ist per Design privilegiert: Er schreibt Code, der mit voller Geräte-Autorität ausgeführt wird.
Die gefährlichste Divergenz liegt zwischen dem Normal-Pfad und dem Recovery-Pfad. Der normale Updater erzwingt Signaturprüfungen und Versions-Policy. Der Recovery-Updater, gebaut für Feld-Ausfälle, nicht für Angreifer, akzeptiert ein älteres, gültig signiertes Image, damit ein Techniker ein gebricktes Gerät wiederbeleben kann. Genau diese Eigenschaft braucht ein Angreifer: ein Rollback auf eine Version mit bekannter Schwachstelle, vom Hersteller signiert, vom Bootloader vertraut.
Die Verifikations-Reihenfolge ist so wichtig wie die Verifikation selbst. Wenn der Versions-Check nach der Installation läuft, hat ein Angreifer, der eine Recovery-Installation auslösen kann, das Gerät bereits downgegradet, bevor die Policy greift. Jeder dieser Fehler ist unsichtbar in einer Checkliste, die nur fragt: „Ist die Firmware signiert?“
Die Update-Eigenschaft hängt von mehreren technischen Annahmen ab.
- Signatur-Verifikation Wird jedes Paket verifiziert, bevor irgendein Teil davon vertraut wird, und ist die Prüflogik selbst korrekt?
- Versions-Policy Wird die Version vor der Installation geprüft, nicht danach, und übersteht der Check den Recovery-Pfad?
- Rollback-Schutz Werden ältere, gültig signierte Images überall abgelehnt, auch Fallback- und Factory-Images?
- Recovery-Pfade Erzwingt Recovery dieselbe Signatur- und Versions-Policy wie der normale Updater, oder schwächere Regeln?
- Slot-Handling Bei A/B-Designs: Welcher Slot bootet als nächster, wer entscheidet, und kann ein veralteter Slot einen Security-Fix überleben?
- Key-Handling Wo leben die Verifikationsschlüssel, wie werden sie rotiert, und kann ein alter Key noch neue Installationen autorisieren?
- Zustellungs-Integrität Ist der Transport authentisiert, und prüft das Gerät das Paket bei der Installation erneut?
Korrekt signiert, und trotzdem ein Downgrade.
Der Updater verifiziert Signaturen vor der Installation. Die Versions-Policy wird durchgesetzt, auf dem Normal-Pfad. Ein Recovery-Trigger akzeptiert ein älteres, gültig signiertes Image, um Feld-Reparatur zu ermöglichen. Das Downgrade erreicht die Policy-Prüfung nie, weil die Policy greift, nachdem das Image bereits akzeptiert wurde.
Der Mechanismus wirkte isoliert sicher: Jeder sichtbare Pfad war signiert. Der Fehler lebt im Übergang zwischen zwei Pfaden, die nie gegeneinander reviewt wurden.
Den Update-Mechanismus als Angriffspfad testen.
Wir mappen die komplette Update-Topologie, normal, Recovery, Fallback, Factory, und vergleichen die Policy, die auf jedem Zweig durchgesetzt wird. Dann testen wir die Übergänge: manipulierte und gedowngradete Pakete, Recovery-Trigger, Slot-Manipulation und abgebrochene Updates, jeweils gegen die Annahme, dass das Gerät nur approved Firmware akzeptiert.
- Neuer OTA- oder Firmware-Update-Mechanismus
- Recovery- oder Fallback-Pfad hinzugefügt oder geändert
- Anti-Rollback-Verhalten muss vor Release verifiziert werden
- Signing-Key-Migration geplant
- Gerät wechselt von Development zu Production-Lifecycle
- Gemeldete Downgrade- oder Update-Schwachstelle muss bewertet werden
- Regulatorische Anforderungen verlangen Nachweise zu Secure Update