Bei Verified Boot müssen alle ausführbaren Codes und Daten, die Teil der gestarteten Android-Version sind, vor der Verwendung kryptografisch überprüft werden. Dazu gehören der Kernel (geladen von der Partition boot), der Gerätebaum (geladen von der Partition dtbo), die Partition system, die Partition vendor usw.
Kleine Partitionen wie boot und dtbo, die nur einmal gelesen werden, werden in der Regel überprüft, indem der gesamte Inhalt in den Arbeitsspeicher geladen und dann der Hash berechnet wird. 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 ein kontinuierlicher Prozess ist, der stattfindet, während Daten in den Arbeitsspeicher geladen werden. In diesem Fall wird der Stamm-Hash des Hash-Baums zur Laufzeit berechnet und mit dem erwarteten Stamm-Hash-Wert verglichen. Android enthält den dm-verity-Treiber, um größere Partitionen zu überprüfen. Wenn der berechnete Stamm-Hashwert irgendwann nicht mit dem erwarteten Stamm-Hashwert übereinstimmt, werden die Daten nicht verwendet und Android wechselt in einen Fehlerstatus. Weitere Informationen finden Sie unter dm-verity-Fehler.
Die erwarteten Hashes werden in der Regel am Ende oder am Anfang jeder überprüften Partition, in einer dedizierten Partition oder an beiden Stellen gespeichert. Wichtig ist, dass diese Hashes (direkt oder indirekt) von der Vertrauensbasis 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 Update-Prozess ist es möglich, dass ein nicht persistenter Android-Kernel-Exploit manuell eine ältere, anfälligere Version von Android installiert, in der anfälligen Version neu gestartet und dann diese Android-Version verwendet wird, um einen persistenten Exploit zu installieren. Ab diesem Zeitpunkt gehört das Gerät dem Angreifer und er kann alles damit tun, einschließlich der Deaktivierung von Updates.
Der Schutz vor dieser Art von Angriffen wird als Rollback Protection bezeichnet. Der Rollback-Schutz wird in der Regel durch die Verwendung eines manipulationssicheren Speichers implementiert, in dem die aktuelle Version von Android aufgezeichnet wird. Android wird nicht gestartet, wenn die Version niedriger als die aufgezeichnete Version ist. Versionen werden in der Regel pro Partition erfasst.
Weitere Informationen dazu, wie AVB Rollback-Schutzmaßnahmen handhabt, finden Sie in der README-Datei für AVB.
Fehler bei der Bestätigung beheben
Die Überprüfung kann entweder beim Booten (z. B. wenn der berechnete Hash auf der Partition boot nicht mit dem erwarteten Hash übereinstimmt) oder zur Laufzeit (z. B. wenn dm-verity einen Überprüfungsfehler auf der Partition system feststellt) fehlschlagen. Wenn die Überprüfung beim Booten fehlschlägt, kann das Gerät nicht gestartet werden und der Endnutzer muss Schritte zur Wiederherstellung des Geräts durchführen.
Wenn die Überprüfung zur Laufzeit fehlschlägt, ist der Ablauf etwas komplizierter. Wenn das Gerät dm-verity verwendet, sollte es im Modus restart konfiguriert werden. Im restart-Modus wird das Gerät bei einem Bestätigungsfehler sofort mit einem bestimmten Flag neu gestartet, das den Grund angibt. Der Bootloader sollte dieses Flag erkennen und dm-verity in den Modus „E/A-Fehler“ (eio) wechseln. Dieser Modus sollte beibehalten werden, bis ein neues Update installiert wurde.
Beim Booten im eio-Modus 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 Bestätigungsfehler auftritt. Stattdessen wird ein EIO-Fehler zurückgegeben und die App muss den Fehler beheben.
Entweder wird das System-Update-Tool ausgeführt, sodass ein neues Betriebssystem ohne Beschädigungsfehler installiert werden kann, oder der Nutzer kann so viele Daten wie möglich vom Gerät herunterladen. Sobald das neue Betriebssystem installiert ist, erkennt der Bootloader das neu installierte Betriebssystem und wechselt zurück in den restart-Modus.