Wenn Sie die Entwicklungen in Android verfolgt haben, müssen Sie den Namen „Verified Boot“ in den letzten Jahren ziemlich oft gehört haben. Google hat die Sicherheitsfunktion in Android 4.4 (Kitkat) auf absolut unaufdringliche Weise eingeführt und die Sichtbarkeit in den neueren Versionen seines Android-Betriebssystems langsam erhöht.
In den letzten Tagen haben wir Nachrichten über das Vorhandensein eines „Streng erzwungener verifizierter Start”In Googles neuester Version des weltweit am häufigsten verwendeten mobilen Betriebssystems. Android Nougat verwendet eine höhere Sicherheitsstufe, wenn Ihr Gerät hochfährt. Während Verified Boot auf Marshmallow dem Benutzer nur eine Warnung gab, falls es feststellte, dass etwas mit der Systempartition nicht stimmt, geht Android Nougat noch einen Schritt weiter und verwendet das, was Google als "Strictly Enforced Verified Boot" bezeichnet Lassen Sie das Gerät überhaupt nicht starten, falls es Anomalien in der Partition, Änderungen am Bootloader oder das Vorhandensein von „bösartigem“ Code im Gerät feststellt. Dies wirft die Frage auf: „Was genau bedeutet das für die Benutzer?“, Stellt sich heraus, dass die Antwort für die beiden Hauptkategorien von Android-Benutzern (Gelegenheits- und Hauptbenutzer) unterschiedlich ist und wir die Antwort für beide geben werden.
Streng erzwungener verifizierter Start
Zunächst ein kleiner Hintergrund zum verifizierten Start: Wenn Android einen Verifikationstest für Partitionen ausführt, teilt es die Partitionen normalerweise in 4-KB-Blöcke auf und vergleicht sie mit einer signierten Tabelle. Wenn alles ausgecheckt ist, bedeutet dies, dass das System vollständig sauber ist. Wenn jedoch einige Blöcke manipuliert oder beschädigt werden, informiert Android den Benutzer über die Probleme und überlässt es dem Benutzer, sie zu lösen (oder nicht)..
All dies wird sich mit Android Nougat und Strictly Enforced Verified Boot ändern. Wenn Verified Boot im erzwungenen Modus ausgeführt wird, wird es toleriert keine Fehler in den Partitionen. Wenn es irgendwelche Probleme erkennt, ist es lässt das Gerät nicht hochfahren, und Macht Erlauben Sie dem Benutzer, in a zu booten Umgebung im abgesicherten Modus, um zu versuchen, die Probleme zu beheben. Strictly Enforced Verified Boot ist jedoch nicht nur eine Überprüfung auf fehlerhafte Datenblöcke. Es kann normalerweise auch Fehler in Datenblöcken korrigieren. Dies wird durch das Vorhandensein von Vorwärtsfehlerkorrekturcodes ermöglicht, mit denen Fehler in Datenblöcken korrigiert werden können. Dies kann jedoch nicht immer funktionieren, und in Fällen, in denen dies nicht der Fall ist, sind Sie im Wasser ziemlich tot.
Streng erzwungener verifizierter Boot: Der Gute, der Schlechte und der Hässliche
1. Das Gute
Das Erzwingen eines verifizierten Startvorgangs auf Android-Geräten wird ausgeführt Sicherheit erhöhen auf den Geräten. Falls das Gerät mit Malware infiziert wird, erkennt Strictly Enforced Verified Boot es beim nächsten Start Ihres Geräts und repariert es entweder oder fordert Sie möglicherweise auf, etwas dagegen zu unternehmen.
Diese Funktion wird auch auf Datenbeschädigung prüfen, In den meisten Fällen können Fehler in den Daten dank der FEC-Codes korrigiert werden. Google verwendet FEC-Codes, die dies können Korrigieren Sie einen unbekannten Bitfehler in 255 Bit. Sicher, das scheint eine ziemlich kleine Zahl zu sein, aber lassen Sie uns das in Bezug auf ein mobiles Gerät relativieren:
Hinweis: Die folgenden Werte stammen aus dem Blogbeitrag von Google Engineer Sami Tolvanen über Android-Entwickler.
Google hätte RS (255.223) FEC-Codes verwenden können: Diese Codes hätten 16 unbekannte Bitfehler in 255 Bit korrigieren können, aber der Speicherplatzaufwand aufgrund der 32 Bit redundanter Daten hätte fast 15% betragen. und das ist viel, besonders auf mobilen Geräten. Fügen Sie das der Tatsache hinzu, dass Android das vorherrschende Betriebssystem auf preisgünstigen Smartphones ist, die mit 4-8 GB Speicher ausgeliefert werden, und 15% zusätzlicher Speicherplatz scheint viel zu sein.
Durch den Verzicht auf Fehlerkorrekturfunktionen zugunsten der Platzersparnis entschied sich Google für die Verwendung von RS (255.253) FEC-Codes. Diese Codes können nur einen einzigen unbekannten Fehler in 255 Bit korrigieren, aber der Speicherplatzaufwand beträgt nur 0,8%.
Hinweis: RS (255, N) ist eine Darstellung von Reed-Solomon-Codes, bei denen es sich um eine Art von Fehlerkorrekturcodes handelt.
2. Das Böse
Schon mal was von "Eine Münze hat zwei Seiten" gehört? Natürlich hast du. Während Googles Absichten mit Strictly Enforced Verified Boot zweifellos rein wie ein Baby-Einhorn waren, haben sie ihre eigenen Probleme.
Bei strikt erzwungenem verifizierten Start prüft auf Malware, es prüft auch auf illegale Änderungen Für den Kernel, den Bootloader und andere Dinge, mit denen ich Sie nicht langweilen werde. Dies bedeutet jedoch, dass Android Nougat wahrscheinlich auf viele Probleme beim Rooten und Flashen von benutzerdefinierten ROMs stoßen wird, da Verified Boot nicht zwischen unerwünschtem Malware-Code unterscheiden kann. und den Code, der Ihren Bootloader entsperrt hat. Das heißt, wenn Ihr Gerät mit einem gesperrten Bootloader ausgestattet ist und Ihr OEM das Entsperren des Bootloaders nicht zulässt, können Sie dies so gut wie nicht tun. Hoffentlich wird jemand einen Exploit dafür finden.
Glücklicherweise entscheiden sich die meisten Leute, die ihre Geräte rooten und benutzerdefinierte ROMs für die zusätzlichen Features und Funktionen flashen, für entwicklerfreundliche Telefone wie das Nexus. Zu diesem Thema gibt es viel zu beachten, und es ist definitiv nicht das Ende von benutzerdefinierten ROMs, zumindest nicht auf Geräten, die mit einem entsperrten Bootloader ausgestattet sind oder das Entsperren des Bootloaders ermöglichen. Geräte wie Samsung-Telefone erlauben jedoch nicht offiziell das Entsperren des Bootloaders. Auf diesen Geräten wird das Entsperren Ihres Bootloaders von Verified Boot definitiv als "Problem" angesehen, wodurch ein Hochfahren des Geräts verhindert wird.
Ein weiteres Problem, das bei Strictly Enforced Verified Boot auftritt, betrifft selbst Benutzer, denen es nicht wirklich wichtig ist, Root-Berechtigungen zu erhalten oder benutzerdefinierte ROMs zu installieren. Wenn Sie Ihr Gerät verwenden, kann es im Laufe der Zeit zu einer natürlichen Beschädigung der Daten im Speicher kommen. nicht aufgrund des Vorhandenseins einer Malware, sondern einfach, weil es passiert. Dies ist normalerweise kein Problem oder zumindest kein so schwerwiegendes Problem, wie es Verified Boot daraus machen wird. Wenn Sie beschädigte Daten haben, die Strictly Enforced Verified Boot beim Booten nicht beheben kann, kann Ihr Gerät nicht gestartet werden. Meiner Meinung nach ist dies ein größeres, sichtbareres Problem als einige beschädigte Daten auf der Benutzerpartition.
3. Das Hässliche
Bei all den Vorteilen der Durchsetzung von Verified Boot und allen potenziellen Problemen ist die Tatsache wahrscheinlich am beunruhigendsten, dass OEMs dies möglicherweise missbrauchen, um ihre Geräte so zu sperren, dass Benutzer Android nicht für das verwenden können, wofür es gedacht war be: offen, entwicklerfreundlich und vollständig anpassbar. Strictly Enforced Verified Boot wird in die Hände von OEMs gelegt, um sicherzustellen, dass Benutzer die Bootloader auf ihren Geräten nicht entsperren können, wodurch ihnen die Installation von benutzerdefinierten ROMs und Tools zur Funktionsverbesserung wie Xposed Modules untersagt wird.
SIEHE AUCH: Kein benutzerdefiniertes Android N-ROM verfügbar? Wir haben die Lösung für Sie
Android Nougat: Eine radikale Veränderung in der Funktionsweise von Android?
Obwohl wir sicher sind, dass Google lediglich beabsichtigte, potenzielle Probleme für gelegentliche Android-Benutzer zu vermeiden, die nicht wissen, was zu tun ist, wenn ihr Gerät von einer Malware betroffen ist oder wenn ihr Speicher Datenblöcke beschädigt hat, hat es möglicherweise OEMs übergeben und der Hersteller ist das perfekte Werkzeug, um Benutzer daran zu hindern, mit dem zu leben, was ihnen angeboten wurde, und nicht mehr.
Natürlich wird jemand einen Exploit oder eine Problemumgehung für diese Situation finden, und wir hoffen, dass dies im wahren Geist von Android der Fall ist. Bis jemand eine Lösung gefunden hat, können wir als Benutzer nur sicherstellen, dass wir unsere Geräte von entwicklerfreundlichen Herstellern kaufen.
Ausgewähltes Bild mit freundlicher Genehmigung von Flickr