Bei Bootmodus mit Verifikation muss der gesamte ausführbare Code und alle 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-Hashwert 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 beides gespeichert. Wichtig ist, dass diese Hashes (direkt oder indirekt) von der Root of Trust signiert werden. Die AVB-Implementierung unterstützt beispielsweise beide Ansätze. Weitere Informationen finden Sie unter Android Bootmodus mit Verifikation.
Rollback-Schutz
Selbst bei einem vollständig sicheren Updateprozess 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 letzte 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 AVB-README-Datei.
Fehler bei der Überprüfung 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 boot erkennt) fehlschlagen.system 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 Bestätigung 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 E/A-Fehlermodus (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 Modus eio 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.
Entweder wird der System-Updater 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.