Wenn Sie die Entwicklungen in Android verfolgt haben, müssen Sie in den letzten Jahren den Namen „Verified Boot“ schon ziemlich oft gehört haben. Google hat die Sicherheitsfunktion in Android 4.4 (Kitkat) auf eine völlig unaufdringliche Weise eingeführt und seine Sichtbarkeit in den neueren Versionen des Android-Betriebssystems langsam erhöht.
In den letzten Tagen haben wir Nachrichten über das Vorhandensein eines „ strikt erzwungenen Verified Boot “ in Googles neuester Iteration des weltweit am häufigsten verwendeten mobilen Betriebssystems gesehen. Android Nougat verwendet beim Starten des Geräts eine höhere Sicherheitsüberprüfung. Während bei Marshmallow der Benutzer von Verified Boot nur eine Warnung ausgegeben hat, wird Android Nougat einen Schritt weitergehen und, wenn er etwas Unzulässiges mit der Systempartition entdeckt hat, das verwenden, was Google als "Strictly Enforced Verified Boot" bezeichnet Lassen Sie das Gerät überhaupt nicht hochfahren, wenn es Anomalien in der Partition, Änderungen am Bootloader oder das Vorhandensein von "schädlichem" Code auf dem Gerät erkennt. Dies wirft die Frage auf: "Was genau bedeutet das für die Nutzer?", Stellt sich heraus, die Antwort unterscheidet sich für die zwei Hauptkategorien von Android-Benutzern (Gelegenheits- und Power-User), und wir werden für beide die Antwort geben .
Streng erzwungener verifizierter Startvorgang
Zunächst ein kleiner Hintergrund zum Verified Boot: Normalerweise führt Android einen Überprüfungstest für Partitionen durch, indem die Partitionen in 4-KB-Blöcke unterteilt und gegen eine signierte Tabelle geprüft werden. Wenn alles klappt, ist das System vollkommen sauber. Wenn jedoch einige Blöcke auftauchen, um manipuliert oder beschädigt zu werden, informiert Android den Benutzer über die Probleme und überlässt es dem Benutzer, das Problem zu lösen (oder nicht).
Das alles wird sich mit Android Nougat und dem streng erzwungenen Verified Boot ändern. Wenn Verified Boot im erzwungenen Modus ausgeführt wird, toleriert es keine Fehler in den Partitionen. Wenn Probleme erkannt werden, kann das Gerät nicht gestartet werden, und möglicherweise kann der Benutzer in einer abgesicherten Umgebung starten, um die Probleme zu beheben. Streng erzwungenes Verified Boot ist jedoch nicht nur eine Überprüfung auf fehlerhafte Datenblöcke. In der Regel können auch Fehler in Datenblöcken korrigiert werden. Möglich wird dies durch das Vorhandensein von Forward Error Correcting-Codes, mit denen Fehler in Datenblöcken korrigiert werden können. Dies kann jedoch nicht immer funktionieren, und wenn dies nicht der Fall ist, sind Sie im Wasser ziemlich tot.
Streng erzwungener Verified Boot: Das Gute, das Böse und das Hässliche
1. das Gute
Das Erzwingen eines verifizierten Starts auf Android-Geräten erhöht die Sicherheit der Geräte. Falls das Gerät durch Malware infiziert wird, erkennt Strictly Enforced Verified Boot das Gerät beim nächsten Neustart des Geräts und repariert es entweder oder fordert Sie möglicherweise auf, etwas dagegen zu unternehmen.
Diese Funktion prüft auch, ob Daten beschädigt sind. In den meisten Fällen können Fehler aufgrund der FEC-Codes in den Daten korrigiert werden. Google verwendet FEC-Codes, mit denen ein unbekannter Bitfehler in 255 Bit korrigiert werden kann. Sicher, das scheint eine ziemlich kleine Zahl zu sein, aber lassen Sie uns dies in Bezug auf ein mobiles Gerät in die richtige Perspektive bringen:
Hinweis: Die folgenden Werte stammen aus dem Blogeintrag 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 Platzbedarf aufgrund der 32 Bit redundanter Daten wäre fast 15% gewesen. und das ist viel, besonders auf mobilen geräten. Hinzu kommt, dass Android auf Budget-Smartphones, die mit 4-8 GB-Speichern ausgeliefert werden, das vorherrschende Betriebssystem ist und dass 15% mehr Speicherplatz sicher viel zu sein scheint.
Durch die Behebung von Fehlerkorrekturfunktionen zugunsten der Platzersparnis entschied sich Google für die Verwendung von RS (255, 253) -FEC-Codes. Diese Codes können nur einen einzelnen unbekannten Fehler in 255 Bits korrigieren, der Platzaufwand beträgt jedoch nur 0, 8%.
Hinweis: RS (255, N) ist eine Darstellung von Reed-Solomon-Codes, bei denen es sich um fehlerkorrigierende Codes handelt.
2. Das Böse
Schon mal was von "Es gibt zwei Seiten einer Münze" gehört? Natürlich hast du. Während Googles Absichten mit Strictly Enforced Verified Boot zweifellos als Baby-Einhorn rein waren, haben sie ihre eigenen Probleme.
Wenn Strictly Enforced Verified Boot nach Malware sucht, wird auch nach illegalen Änderungen am Kernel, am Bootloader und an anderen Dingen gesucht, mit denen ich Sie nicht langweilen werde. Dies bedeutet jedoch, dass Android Nougat wahrscheinlich Probleme mit dem Rooting und anderen Problemen hat benutzerdefinierte ROMs blinken, da Verified Boot nicht zwischen unerwünschtem Malware-Code und dem Code unterscheiden kann, der den Bootloader entsperrt hat. Das bedeutet, wenn Ihr Gerät mit einem gesperrten Bootloader geliefert wurde und Ihr OEM das Entriegeln des Bootloaders nicht zulässt, können Sie dies praktisch nicht tun. Hoffentlich wird jemand einen Exploit dafür finden.
Glücklicherweise verwenden die meisten Benutzer, die ihre Geräte rooten und benutzerdefinierte ROMs für die zusätzlichen Funktionen und Funktionen verwenden, entwicklungsfreundliche Handys wie das Nexus. Zu diesem Thema gibt es viel zu beachten, und es ist definitiv nicht das Ende von Custom ROMs, zumindest nicht auf Geräten, die mit einem nicht gesperrten Bootloader geliefert werden oder die das Entriegeln des Bootloaders ermöglichen. Geräte wie Samsung-Telefone erlauben jedoch nicht offiziell das Entriegeln des Bootloaders. Auf diesen Geräten wird das Entsperren des Bootloaders von Verified Boot definitiv als "Problem" angesehen, wodurch das Starten des Geräts verhindert wird.
Ein weiteres Problem, das bei Strictly Enforced Verified Boot auftreten wird, betrifft auch die Benutzer, die sich nicht wirklich mit Root-Rechten auskennen oder benutzerdefinierte ROMs installieren möchten. Im Laufe der Zeit, wenn Sie Ihr Gerät verwenden, wird der Speicher natürlich auf natürliche Weise beschädigt. Nicht wegen des Vorhandenseins einer Malware, sondern weil es passiert. Dies ist normalerweise kein Problem oder zumindest kein so schwerwiegendes Problem, wie es von Verified Boot erkannt wird. Wenn Sie über beschädigte Daten verfügen, die durch Strictly Enforced Verified Boot beim Booten nicht behoben werden können, können Sie Ihr Gerät nicht starten. Meiner Meinung nach ist dies ein größeres, sichtbareres Problem als einige beschädigte Daten in der Benutzerpartition.
3. Die hässliche
Bei all den Vorteilen der Durchsetzung von Verified Boot und allen potenziellen Problemen ist die Tatsache, dass OEMs dieses Gerät möglicherweise missbrauchen, um ihre Geräte so zu sperren, dass die Benutzer Android nicht so nutzen können, wie es beabsichtigt war Seien Sie offen, entwicklerfreundlich und vollständig anpassbar. Strikt erzwungenes Verified Boot wird OEMs in die Hände geben, um sicherzustellen, dass Benutzer die Bootloader auf ihren Geräten nicht entsperren können. Dadurch wird ihnen die Installation von benutzerdefinierten ROMs und die Verbesserung von Tools wie Xposed Modules untersagt.
Android Nougat: Eine radikale Veränderung in der Art und Weise, wie Android funktioniert?
Obwohl wir sicher sind, dass Googles Absicht lediglich darin bestand, potenzielle Probleme für gelegentliche Android-Benutzer zu vermeiden, die nicht wissen, was zu tun ist, falls ihr Gerät von einer Malware betroffen ist oder wenn der Speicher beschädigte Datenblöcke aufweist, hat es möglicherweise OEMs übergeben und Hersteller ist das perfekte Werkzeug, um Benutzer daran zu hindern, mit dem, was ihnen angeboten wird, zu leben, und nicht mehr.
Natürlich wird jemand einen Exploit oder einen Workaround für diese Situation finden, und wir hoffen, dass dies im wahren Geiste von Android geschieht. Bis jemand eine Lösung findet, können wir als Benutzer jedoch nur sicherstellen, dass wir unsere Geräte von entwicklerfreundlichen Herstellern kaufen.
Featured Image Courtesy: Flickr
