Alle Geräte, die mit Android Pie (Android 9) gestartet werden, müssen Verified Boot (Android Verified Boot 2.0) unterstützen, was einen Rollback-Schutz ermöglicht.
Android Pie (Android 9) ist erst heute online gegangen für Google Pixel, Google Pixel 2 und sogar die Unverzichtbares Telefon. Aus Interviews erfahren wir so viel wie möglich über die Veröffentlichung (das Google Pixel 3). wird nur Gestennavigation haben!), Die AOSP-Code-Dropund schließlich das Compatibility Definition Document (CDD). Wir haben über a gepostet Neue Funktion für „schwergewichtige“ Apps heute früher, aber jetzt haben wir festgestellt, dass Google den Wortlaut einer in Android Oreo eingeführten Funktion geändert hat: Rollback-Schutz. Die Funktion wird ermöglicht durch Android-verifizierter Boot 2.0 (auch einfach als Verified Boot bekannt), OEMs waren jedoch nicht verpflichtet, AVB 2.0 in der Oreo-Version zu implementieren. Jetzt schreibt Google vor, dass alle Geräte, die mit Android Pie gestartet werden, Verified Boot und damit auch einen Rollback-Schutz unterstützen.
Rollback-Schutz in Android Oreo
Der Kern der Funktion besteht darin, dass sie den Start Ihres Telefons verhindert, wenn festgestellt wird, dass das Gerät heruntergestuft wurde auf eine frühere, jetzt nicht genehmigte Version der Software, die aus Sicherheitsgründen als unsicher gilt Verletzlichkeit. Eine etwas technischere Erklärung ist, dass die VBMeta-Datenstruktur, die den Hash für die Boot-Partition und enthält Hashtree-Metadaten für System- und Herstellerpartitionen, verwendet einen Rollback-Index, um Bilder abzulehnen, die über ein älteres Rollback verfügen Index.
Diese Funktion ist auf Geräten wie Google Pixel 2, Razer Phone und OnePlus 6 vorhanden, auf vielen anderen Geräten wie dem Samsung Galaxy S9 jedoch nicht (obwohl Samsung eine eigene Form davon anbietet). Rollback-Schutz in Knox.) Jetzt macht Google die Funktion für jedes Gerät, das mit Android Pie startet, zur Pflicht.
Verifizierter Start in Android Pie
Gemäß dem aktualisierten Wortlaut im Abschnitt „Geräteintegrität“ im Kompatibilitätsdefinitionsdokument müssen Geräte, die mit Android 9 gestartet werden, Verified Boot unterstützen.
9.10. Geräteintegrität
Die folgenden Anforderungen gewährleisten Transparenz über den Status der Geräteintegrität. Geräteimplementierungen:
- [C-0-1] MUSS über die System-API-Methode PersistentDataBlockManager.getFlashLockState() korrekt melden, ob ihr Bootloader-Status das Flashen des Systemabbilds zulässt. Der Status FLASH_LOCK_UNKNOWN ist Geräteimplementierungen vorbehalten, die ein Upgrade von einer früheren Android-Version durchführen, bei der diese neue System-API-Methode nicht vorhanden war.
- [C-0-2] MUSS Verified Boot für die Geräteintegrität unterstützen.
Wenn Geräteimplementierungen bereits gestartet werden, ohne Verified Boot auf einer früheren Android-Version zu unterstützen und keine Unterstützung für diese Funktion mit einem Systemsoftware-Update hinzufügen können, sind sie möglicherweise davon ausgenommen Erfordernis.
...
- [C-1-10] MUSS einen Rollback-Schutz für von Android verwendete Partitionen implementieren (z. B. Boot-Partitionen, Systempartitionen). und verwenden Sie manipulationssicheren Speicher zum Speichern der Metadaten, die zur Bestimmung des minimal zulässigen Betriebssystems verwendet werden Ausführung.
- SOLLTE einen Rollback-Schutz für jede Komponente mit persistenter Firmware (z. B. Modem, Kamera) implementieren Für die Speicherung der Metadaten, die zur Bestimmung des zulässigen Mindestwerts verwendet werden, SOLLTE manipulationssicherer Speicher verwendet werden Ausführung.
Wie Sie in den letzten beiden Aufzählungspunkten sehen können, gibt es eine Einschränkung zu beachten. Für von Android verwendete Partitionen (Boot, System, Hersteller usw.) ist ein Rollback-Schutz erforderlich, nicht jedoch für Partitionen mit persistenter Firmware (Modem, Kamera usw.). In der ersten Gruppe von Partitionen werden die meisten Sicherheitslücken entdeckt und behoben. Daher ist es schön zu sehen, dass der Schutz dieser Partitionen vorgeschrieben ist. Es gab jedoch auch Exploits, die auf Partitionen mit persistenter Firmware abzielten. Daher sind wir uns nicht sicher, warum Google für sie keinen Rollback-Schutz vorschreibt.
XDA-Senior-Mitglied npjohnson, ein Mitglied des LineageOS-Teams, vermutet, dass ein Rollback-Schutz auf Partitionen mit persistenter Firmware erforderlich wäre erfordern Secondary Bootloader (SBL) und eXtensible Bootloader (XBL)-Einbindungen, da diese Partitionen früher beim Booten gemountet werden Verfahren. Für kleinere OEMs wäre es kostspielig, angepasste XBLs zu implementieren, die zu den angepassten Modems und anderen persistenten Partitionen passen. Daher macht Google dies möglicherweise nicht zu einer Anforderung, um es Geräteherstellern zu erleichtern, die neuesten Anforderungen der CDD zu erfüllen.
So überprüfen Sie, ob Ihr Telefon AVB 2.0 unterstützt
Es gibt zwei ADB-Shell-Befehle, mit denen Sie überprüfen können, ob Ihr Telefon AVB 2.0 unterstützt.
adb shell
dumpsys package | grep "verified_boot"ODER
adb shell
getprop | grep "avb"Wenn die Ausgabe des ersten Befehls „android.software.verified_boot“ lautet, wird AVB 2.0 unterstützt. Wenn die Ausgabe des zweiten Befehls „[ro.boot.avb_version]“ und „[ro.boot.vbmeta.avb_version]“ anzeigt und jeweils eine Versionsnummer auflistet, wird dies unterstützt.
Verifizierter Boot- und kundenspezifische Entwicklung
Android Verified Boot hat für die meisten Benutzer von benutzerdefinierten ROMs keine wirklichen Auswirkungen, obwohl es eine zusätzliche Sicherheitsebene hinzufügt, die Sie in einigen Fällen umgehen müssen. Zum Beispiel, Flashen eines generischen System-Images erfordert die Deaktivierung von AVB. Das Ändern bestimmter Partitionen wie „Vendor“ auf dem OnePlus 6 erfordert auch die Deaktivierung von AVB. wie ich kürzlich erfahren habe. Entsprechend npjohnson, richtig implementiertes AVB 2.0 ermöglicht es, dass benutzerdefinierte Boot-Images mit einem gesperrten Bootloader funktionieren. Wir werden sehen, wie sich die Integration von AVB 2.0 auf Geräten, die mit Android Pie ausgeliefert werden, auf die Landschaft auswirkt, aber wir hoffen, dass es nicht zu solchen Situationen kommt jüngster Ziegelstein-Schrecken in der Xiaomi Redmi Note 5 Pro-Community. Obligatorisches AVB 2.0 ist nur eine weitere Möglichkeit für Google Verbessern Sie die Sicherheit der Android-Plattform, aber die größte Veränderung ist unserer Meinung nach die Überarbeitung der OEM-Vereinbarungen, um regelmäßige Sicherheitspatches vorzuschreiben.