Der verifizierte Start erfordert die kryptografische Überprüfung aller ausführbaren Codes und Daten, die Teil der zu startenden Android-Version sind, bevor sie verwendet werden. Dazu gehören der Kernel (geladen von der boot Partition), der Gerätebaum (geladen von der dtbo Partition), die system , die vendor usw.
Kleine Partitionen wie boot und dtbo , die nur einmal gelesen werden, werden normalerweise überprüft, indem der gesamte Inhalt in den Speicher 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 Einzelheiten finden Sie unter Boot Flow .
Größere Partitionen, die nicht in den Speicher passen (z. B. Dateisysteme), verwenden möglicherweise einen Hash-Baum, bei dem die Überprüfung ein kontinuierlicher Prozess ist, der beim Laden der Daten in den Speicher stattfindet. In diesem Fall wird der Root-Hash des Hash-Baums zur Laufzeit berechnet und mit dem erwarteten Root-Hash-Wert verglichen. Android enthält den dm-verity-Treiber zur Überprüfung größerer Partitionen. Wenn der berechnete Root-Hash irgendwann nicht mit dem erwarteten Root-Hash-Wert übereinstimmt, werden die Daten nicht verwendet und Android geht in einen Fehlerzustand über. Weitere Einzelheiten finden Sie unter dm-verity-Korruption .
Die erwarteten Hashes werden normalerweise entweder am Ende oder am Anfang jeder überprüften Partition, in einer dedizierten Partition oder an beiden gespeichert. Entscheidend ist, dass diese Hashes (entweder direkt oder indirekt) von der Vertrauenswurzel signiert werden. Beispielsweise unterstützt die AVB-Implementierung beide Ansätze. Weitere Informationen finden Sie unter Android Verified Boot .
Rollback-Schutz
Selbst bei einem völlig sicheren Aktualisierungsprozess 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 startet und dann diese Android-Version verwendet, um einen persistenten Exploit zu installieren. Von dort aus besitzt der Angreifer dauerhaft das Gerät und kann alles tun, einschließlich der Deaktivierung von Updates.
Der Schutz gegen diese Angriffsklasse wird als Rollback-Schutz bezeichnet. Der Rollback-Schutz wird in der Regel implementiert, indem ein manipulationssicherer Speicher zum Aufzeichnen der neuesten Android-Version verwendet wird und der Start von Android verweigert wird, wenn diese niedriger als die aufgezeichnete Version ist. Versionen werden normalerweise für jede Partition nachverfolgt.
Weitere Einzelheiten dazu, wie AVB mit Rollback-Schutzmaßnahmen umgeht, finden Sie in der AVB- README-Datei .
Umgang mit Verifizierungsfehlern
Die Überprüfung kann entweder beim Booten fehlschlagen (z. B. wenn der berechnete Hash auf der boot nicht mit dem erwarteten Hash übereinstimmt) oder zur Laufzeit (z. B. wenn dm-verity einen Überprüfungsfehler auf der system feststellt). Wenn die Überprüfung beim Booten fehlschlägt, kann das Gerät nicht booten und der Endbenutzer 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 restart konfiguriert werden. Wenn im restart ein Überprüfungsfehler auftritt, wird das Gerät sofort neu gestartet, wobei ein bestimmtes Flag gesetzt wird, um den Grund anzugeben. Der Bootloader sollte dieses Flag bemerken und dm-verity auf den E/A-Fehlermodus ( eio ) umstellen und in diesem Modus bleiben, bis ein neues Update installiert wurde.
Beim Booten im eio Modus zeigt das Gerät einen Fehlerbildschirm an, der den Benutzer darüber informiert, dass eine Beschädigung erkannt wurde und das Gerät möglicherweise nicht ordnungsgemäß funktioniert. Der Bildschirm wird angezeigt, bis der Benutzer ihn schließt. Im eio Modus startet der dm-verity-Treiber das Gerät nicht neu, wenn ein Verifizierungsfehler auftritt. Stattdessen wird ein EIO-Fehler zurückgegeben und die Anwendung muss sich mit dem Fehler befassen.
Die Absicht besteht darin, dass entweder der System-Updater ausgeführt wird (damit ein neues Betriebssystem ohne Beschädigungsfehler installiert werden kann) oder der Benutzer so viele seiner Daten wie möglich vom Gerät entfernen kann. Sobald das neue Betriebssystem installiert ist, erkennt der Bootloader das neu installierte Betriebssystem und wechselt zurück in den restart .