Gibt es eine Dokumentation, wie genau der Factory Reset Protection (FRP) funktioniert?

Gibt es eine detaillierte Dokumentation, wie genau der Factory Reset Protection (FRP) auf Android-Geräten funktioniert?

Antworten (1)

Ich denke, vieles davon wird absichtlich "still" gehalten ... als ich vor einiger Zeit selbst einiges davon recherchiert habe, ist dies das Beste, was ich "im Detail" finden konnte.

https://github.com/intel/kernelflinger/blob/master/doc/FRP.md

Bootloader-Richtlinie und Factory Reset Protection Googles Verified Boot (GVB)-Spezifikation und Google Factory Reset Protection (FRP) für AndroidTM definieren eine Reihe von Sicherheitsprotokollen, um die Systemintegrität sicherzustellen bzw. Gerätediebstahl zu verhindern.

Es gibt legitime Gründe, den Bootloader zu entsperren, ohne die PIN zum Entsperren des Bildschirms zu kennen. insbesondere RMAs. Ein RMA-Bearbeitungszentrum sollte in der Lage sein, Geräte-Flashing-Beschränkungen in Fastboot zu entsperren und das Gerät in einen fabrikneuen Zustand zurückzusetzen, ohne dass der Benutzer seine PIN zum Entsperren des Bildschirms preisgeben muss oder möglicherweise seine Benutzerdaten für eine Kompromittierung öffnen muss.

Diese Dokumentation beschreibt die Lösung zum Definieren eines Geräts der Klasse A und einen Mechanismus, der das Entsperren eines Geräts für RMA unabhängig vom FRP- oder Klasse-A-Status ermöglicht. Es erfüllt die Sicherheitsanforderungen von Google FRP, indem sichergestellt wird, dass es keinen einzelnen Schlüssel gibt, um Geräte zu entsperren, wenn alle Sicherheitsüberlegungen implementiert sind. Es ermöglicht auch die Bereitstellung von Geräten, sodass die Entität mit Entsperrungsberechtigung ein Anbieter, der OEM, ODM, ein Spediteur oder eine Unternehmensorganisation sein kann.

Benutzererfahrung des Geräts Der Benutzer startet das Gerät mit Fastboot. Der Benutzer erhält eine Aktionsherausforderung. Fastboot oem get-action-nonce force-unlock fastboot flash action-authorization token_file Fastboot führt die autorisierte Aktion aus Implementierung Das OEM-Aktionsautorisierungsprotokoll ist eine einfache Challenge-Response, bei der Fastboot des Geräts eine einmalige Nonce generiert, der OEM-Aktionsautorisierungs-Agent die Nonce signiert und die Aktion mit seiner privaten Überschreibungsautorisierung genehmigt Schlüssel (OAK), um ein Autorisierungstoken zu generieren, und dann validiert der Fastboot des Geräts das Aktionsautorisierungstoken und führt die Aktion aus.

Override Authorization Key Der Override Authorization Key (OAK) ist ein öffentlicher Schlüssel, der während der Herstellung im Gerät festgelegt wird und zur Validierung von Aktionsautorisierungstoken verwendet wird. Wenn kein OAK festgelegt ist, werden alle Aktionsautorisierungsfunktionen deaktiviert und das standardmäßige Bootloader- und Fastboot-Verhalten, das in GVB und FRP angegeben ist, ist wirksam. Da der OAK die Klasse-A- und FRP-Richtlinien außer Kraft setzen kann, ist es wichtig sicherzustellen, dass er nicht durch nicht autorisierten Code geändert werden kann, wodurch die Identität der Personen, die die Richtlinie außer Kraft setzen können, geändert würde.

Der OAK kann als Validierungsstammzertifikat fungieren, wenn das Zertifizierungsstellenattribut des Zertifikats „true“ ist – standardmäßige Handhabung von X.509v3-Zertifikaten. Das bedeutet, dass der OAK verwendet werden kann, um Zertifikate auszustellen, die auch in der Lage sind, Aktionsautorisierungstoken zu signieren. Dies ist die bevorzugte Methode zum Festlegen des OAK in Fällen, in denen mehrere Entitäten die Möglichkeit benötigen, Aktionsautorisierungstoken auszugeben, ohne Zugriff auf einen einzelnen Schlüssel zu haben.

OAK wird als zeitbasierte authentifizierte OAK-EFI-Variable unter der Fastboot-GUID 1ac80a82-4f0c-456b-9a99-debeb431fcc1 gespeichert. Der Inhalt dieser Variable ist die SHA256-Summe des OAK-Zertifikats.

Bootloader-Richtlinienmaske Die Bootloader-Richtlinienmaske (BPM) ist ein Satz von 64 booleschen Richtlinien-Flags. Wenn kein BPM festgelegt ist, verwendet Fastboot standardmäßig eine Richtlinie, die einem BPM-Wert von null entspricht. Wenn ein BPM-Wert eingestellt ist, zeigt ein Eins-Bit an, dass die entsprechende Richtlinie aktiv ist.

Der BPM wird bei der Herstellung im Gerät eingestellt.

Richtlinienname Bit(s) Beschreibung CLASS_A_DEVICE 0 Wenn gesetzt, erzwingt der Bootloader das von GVB definierte Verhalten für Geräte der Klasse A. MIN_BOOT_STATE 1-2 Zum Booten des Geräts erforderlicher minimaler Boot-Status (0 für Rot, 1 für Orange, 2 für Gelb und 3 für Grün) 456b-9a99-debeb431fcc1.

Generieren von One-Time-Nonce Die Einmal-Aktions-Autorisierungs-Nonce hat die Form "::<8-Bit-Aktions-ID>:<16 Client-Zufallsbytes>", wobei alle Felder hexadezimal codiert sind. Es wird generiert, wenn der Befehl fastboot oem get-action-nonce verwendet wird. Fastboot speichert den Wert für eine begrenzte Zeit, bevor er abläuft. Bei jeder Ausführung des Befehls wird ein neuer Wert generiert und der vorherige Wert überschrieben. Der Wert wird nicht persistent gespeichert. Wenn Fastboot neu gestartet wird, ist die alte Nonce nicht mehr gültig.

Die folgenden Aktionen sind definiert.

Name Aktions-ID Beschreibung Entsperren erzwingen 0x00 Lässt Kernelfliner den Flash-Entsperrbefehl von Fastboot ausführen, als ob die Entwickleroption „Enable oem unlock“ aktiviert wäre. Es gelten alle GVB-Standardeigenschaften, einschließlich des sicheren Löschens der Benutzerdatenpartition. Das Versionsfeld ist ein Ein-Byte-Wert. Für die aktuelle Version muss es Null sein.

Erstellen eines Aktionsautorisierungstokens Ein Aktionsautorisierungstoken wird generiert, indem die Aktionsautorisierungsnonce mit dem OAK signiert wird. Das Token ist ein PKCS #7-signiertes Dokument, bei dem der Hauptteil die Form „::<8-Bit-Aktions-ID>:<16 Client-Zufallsbytes>:<16 Auth-Agent-Zufallsbytes>“ hat, wobei alle Felder hexadezimal codiert sind. Die zufälligen Bytes des Auth-Agenten, die beim Erstellen der Autorisierung hinzugefügt werden, sollen verhindern, dass ein Angreifer einen Angriff startet, indem er bekannte Klartextwerte bereitstellt.

Der Token muss alle Zertifikate enthalten, die zur Validierung der Signaturkette des Tokens erforderlich sind.

Der Aktionsautorisierungsagent muss überprüfen, ob die Nonce genau im vorgeschriebenen Format vorliegt.

Der Aktionsautorisierungsagent muss überprüfen, ob die Aktions-ID in Nonce ein anerkannter Wert ist.

Wenn möglich, sollte der Aktionsautorisierungsagent überprüfen, ob die Seriennummer gültig ist.

Flashen des Aktionsautorisierungstokens Das Autorisierungstoken wird mithilfe des speziellen Flash-Ziels „Aktionsautorisierung“ an Fastboot gesendet. Fastboot überprüft, ob das Token gültig ist, macht die aktuelle One-Time-Nonce ungültig und führt die autorisierte Aktion aus.

Fastboot muss überprüfen, ob nach dem Analysieren des Tokens keine zusätzlichen Daten vorhanden sind.

Fastboot muss überprüfen, ob das Zertifikat der Signatur mit dem OAK-Satz bei der Herstellung verknüpft ist.

Fastboot muss überprüfen, ob alle Werte im Token-Hauptteil die vorgeschriebenen Werte haben.

Fastboot muss überprüfen, ob der vom Befehl „oem get-action-nonce“ zurückgegebene Wert mit dem Wert im Token-Hauptteil übereinstimmt und die Nonce nicht abgelaufen ist.