Verifizierter Start erfordert die kryptografische Überprüfung aller ausführbaren Codes und Daten, die Teil der zu bootenden Android-Version sind, bevor sie verwendet werden. Dazu gehören der Kernel (von der dtbo boot Partition geladen), system , die vendor und so weiter.
Kleine Partitionen wie boot und dtbo , die nur einmal gelesen werden, werden normalerweise verifiziert, indem der gesamte Inhalt in den Speicher geladen und dann der Hash berechnet wird. Dieser berechnete Hash-Wert wird dann mit dem erwarteten Hash-Wert 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 stattfindet, wenn Daten in den Speicher geladen werden. In diesem Fall wird der Root-Hash des Hash-Baums zur Laufzeit berechnet und gegen den erwarteten Root-Hash-Wert geprüft. Android enthält den dm-verity-Treiber , um größere Partitionen zu überprüfen. 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. Weitere Einzelheiten finden Sie unter dm-verity-Korruption .
Die erwarteten Hashes werden normalerweise entweder am Ende oder am Anfang jeder verifizierten Partition, in einer dedizierten Partition oder beidem gespeichert. Entscheidend ist, dass diese Hashes (entweder direkt oder indirekt) von der Vertrauenswurzel signiert werden. Beispielsweise unterstützt die AVB-Implementierung beide Ansätze, siehe Android Verified Boot für Details.
Rollback-Schutz
Selbst bei einem vollständig sicheren Aktualisierungsprozess ist es möglich, dass ein nicht persistenter Android-Kernel-Exploit eine ältere, anfälligere Version von Android manuell 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 das Gerät dauerhaft und kann alles tun, einschließlich des Deaktivierens von Updates.
Der Schutz vor dieser Art von Angriffen wird als Rollback-Schutz bezeichnet. Der Rollback-Schutz wird normalerweise implementiert, indem ein manipulationssicherer Speicher verwendet wird, um die neueste Version von Android aufzuzeichnen, und sich weigert, Android zu starten, wenn es niedriger als die aufgezeichnete Version ist. Versionen werden in der Regel pro Partition nachverfolgt.
Weitere Einzelheiten darüber, wie AVB den Rollback-Schutz handhabt, finden Sie in der AVB README .
Behandlung von Überprüfungsfehlern
Die Überprüfung kann entweder beim Booten fehlschlagen (z. B. wenn der berechnete Hash auf der Startpartition nicht mit dem erwarteten Hash übereinstimmt) oder zur Laufzeit (z. B. wenn dm- boot 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 die 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 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 anzuzeigen. Der Bootloader sollte dieses Flag bemerken und dm-verity auf die Verwendung des 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 Überprüfungsfehler auftritt, stattdessen wird ein EIO-Fehler zurückgegeben und die Anwendung muss den Fehler behandeln.
Die Absicht ist, 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 wurde, bemerkt der Bootloader das neu installierte Betriebssystem und wechselt zurück in den restart .