Beim Verified Boot muss vor der Verwendung der gesamte ausführbare Code und alle Daten, die zur gestarteten Android-Version gehören, kryptografisch verifiziert werden. Dazu gehören der Kernel (aus der boot-Partition geladen), der Gerätebaum (aus der dtbo-Partition geladen), die system-Partition, die vendor-Partition usw.
Kleine Partitionen wie boot und dtbo, die nur einmal gelesen werden, werden in der Regel durch Laden des gesamten Inhalts in den Arbeitsspeicher und anschließende Berechnung des Hashwerts überprüft. Dieser berechnete Hashwert wird dann mit dem erwarteten Hashwert verglichen. Wenn der Wert nicht übereinstimmt, wird Android nicht geladen.
Weitere Informationen finden Sie unter Boot-Ablauf.
Bei größeren Partitionen, die nicht in den Arbeitsspeicher passen (z. B. Dateisysteme), kann ein Hash-Baum verwendet werden, bei dem die Überprüfung kontinuierlich erfolgt, während Daten in den Arbeitsspeicher geladen werden. In diesem Fall wird der Stamm-Hash des Hashbaums während der Laufzeit berechnet und mit dem erwarteten Stamm-Hashwert verglichen. Android enthält den dm-verity-Treiber zur Überprüfung größerer Partitionen. Wenn der berechnete Root-Hash nicht mit dem erwarteten Root-Hashwert übereinstimmt, werden die Daten nicht verwendet und Android wechselt in den Fehlerstatus. Weitere Informationen finden Sie unter Beschädigung von dm-verity.
Die erwarteten Hash-Werte werden in der Regel entweder am Ende oder am Anfang jeder geprüften Partition, in einer speziellen Partition oder in beiden gespeichert. Entscheidend ist, dass diese Hash-Werte (direkt oder indirekt) vom Stamm der Vertrauenskette signiert werden. Die AVB-Implementierung unterstützt beispielsweise beide Ansätze. Weitere Informationen finden Sie unter Android Verified Boot.
Rollback-Schutz
Selbst bei einem vollständig sicheren Updateprozess ist es möglich, dass ein nicht persistenter Android-Kernel-Exploit eine ältere, anfälligere Version von Android manuell installiert, das Gerät neu mit dieser anfälligen Version startet und dann mit dieser Android-Version einen persistenten Exploit installiert. Ab diesem Zeitpunkt hat der Angreifer dauerhaft die Kontrolle über das Gerät und kann alles tun, einschließlich der Deaktivierung von Updates.
Der Schutz vor dieser Art von Angriffen wird als Rollback-Schutz bezeichnet. Der Rollback-Schutz wird in der Regel durch die Verwendung eines manipulationssicheren Speichers implementiert, um die neueste Android-Version zu erfassen und das Booten von Android zu verhindern, wenn die Version niedriger ist als die aufgezeichnete Version. Versionen werden in der Regel pro Partition erfasst.
Weitere Informationen dazu, wie AVB Rollback-Schutzmechanismen handhabt, finden Sie in der README-Datei für AVB.
Umgang mit Bestätigungsfehlern
Die Überprüfung kann entweder beim Starten (z. B. wenn der berechnete Hashwert der Partition boot nicht mit dem erwarteten Hashwert übereinstimmt) oder während der Laufzeit fehlschlagen (z. B. wenn dm-verity einen Überprüfungsfehler in der Partition boot erkennt).system Wenn die Überprüfung beim Start fehlschlägt, kann das Gerät nicht gestartet werden und der Endnutzer muss Schritte zur Wiederherstellung des Geräts ausführen.
Wenn die Überprüfung zur Laufzeit fehlschlägt, ist der Ablauf etwas komplizierter. Wenn das Gerät dm-verity verwendet, sollte es im restart-Modus konfiguriert werden. Wenn im restart-Modus ein Überprüfungsfehler auftritt, wird das Gerät sofort neu gestartet und ein bestimmtes Flag wird gesetzt, um den Grund anzugeben. Der Bootloader sollte dieses Flag erkennen und dm-verity auf den Modus „I/O-Fehler“ (eio) umstellen und in diesem Modus bleiben, bis ein neues Update installiert wurde.
Beim Starten im Modus eio wird auf dem Gerät ein Fehlerbildschirm angezeigt, auf dem der Nutzer darüber informiert wird, dass eine Beschädigung erkannt wurde und das Gerät möglicherweise nicht richtig funktioniert. Der Bildschirm wird angezeigt, bis der Nutzer ihn schließt. Im eio-Modus startet der dm-verity-Treiber das Gerät nicht neu, wenn ein Überprüfungsfehler auftritt. Stattdessen wird ein EIO-Fehler zurückgegeben und die App muss den Fehler beheben.
Ziel ist es, dass entweder der System-Updater ausgeführt wird (damit ein neues Betriebssystem ohne Beschädigungsfehler installiert werden kann) oder der Nutzer so viele Daten wie möglich vom Gerät kopieren kann. Sobald das neue Betriebssystem installiert wurde, erkennt der Bootloader das neu installierte Betriebssystem und wechselt zurück in den restart-Modus.