Fortsetzen nach Neustart

In Android 11 können OTA-Updates mit dem A/B-Update angewendet werden. oder virtuelles A/B-Update, in Kombination mit RecoverySystem Klassenmethoden. Nachdem ein Gerät neu gestartet wurde, um ein Over-the-air-Update anzuwenden, entsperrt die Funktion „Resume-on-Reboot“ (RoR) den Credential Encrypted (CE)-Speicher des Geräts.

Partner können diesen Vorgang zwar mit einer OTA-Systemfunktion kombinieren, die Updates anwendet, wenn das Gerät in Android 11 voraussichtlich inaktiv ist. In Android 12 benötigen Partner jedoch keine zusätzliche OTA-Systemfunktion. Der RoR-Prozess bietet Nutzern zusätzliche Sicherheit und Komfort, Die Updates können während der Inaktivitätszeit des Geräts vorgenommen werden, während Android 12 Mehrfachkunden- und serverbasierte Update-Funktionen bieten gemeinsam auf Hardwareebene.

Für android.hardware.reboot_escrow musst du jedoch eine Geräteberechtigung erteilen. RoR in Android 11 unterstützt, müssen Sie dies nicht tun, um serverbasierten RoR in Android 12 und höher, da sie verwenden Sie den HAL nicht.

Hintergrund

Seit Android 7 unterstützt Android den Direktstart, mit dem die Apps auf einem Gerät gestartet werden können, bevor der CE-Speicher vom Nutzer entsperrt wird. Die Implementierung von Direct Boot-Support bot den Nutzern eine bessere Erfahrungen vor der Eingabe des Lock Screen Knowledge Factor (LSKF) nach dem Booten.

Mit RoR kann der CE-Speicher aller Apps auf einem Gerät entsperrt werden, einschließlich derjenigen, die Direct Boot nicht unterstützen, wenn nach einem OTA-Update ein Neustart gestartet wird. Mit dieser Funktion können Nutzer Benachrichtigungen von allen ihren Apps nach dem Neustart installiert.

Bedrohungsmodell

Bei der Implementierung von RoR muss sichergestellt werden, dass es für Angreifer extrem schwierig ist, die mit der clientseitigen Verschlüsselung verschlüsselten Daten des Nutzers wiederherzustellen, wenn ein Gerät in ihre Hände fällt, selbst wenn das Gerät eingeschaltet, der clientseitige Speicher entsperrt und das Gerät vom Nutzer nach Erhalt eines Over-the-air-Updates entsperrt wurde. Der Schutz vor Insiderangriffen muss auch dann wirksam sein, wenn der Angreifer Zugriff auf die kryptografischen Signaturschlüssel erhält, die gesendet werden.

Insbesondere darf der CE-Speicher nicht von einem Angreifer gelesen werden, der das Gerät physisch in seinem Besitz hat. Er hat folgende Funktionen und Einschränkungen:

Funktionen

  • Kann den Signaturschlüssel eines beliebigen Anbieters oder Unternehmens verwenden, um beliebige Nachrichten zu signieren.
  • Kann dazu führen, dass das Gerät ein Over-the-air-Update erhält.
  • den Betrieb von Hardware (wie einem Anwendungsprozessor, oder Flash-Speicher) – außer wie im Abschnitt Einschränkungen unten beschrieben. (Eine solche Änderung beinhaltet jedoch eine Verzögerung von mindestens einer Stunde, und das Gerät aus- und wieder einschalten, um den RAM-Inhalt zu löschen.

Beschränkungen

  • Die Funktionsweise manipulationssicherer Hardware (z. B. Titan M) kann nicht geändert werden.
  • Der RAM des Live-Geräts kann nicht gelesen werden.
  • die Anmeldedaten des Nutzers (PIN, Muster, Passwort) nicht erraten oder anderweitig eingegeben werden müssen.

Lösung

Das Android 12 RoR-Updatesystem bietet Sicherheit raffinierten Hackern zu schützen. PINs bleiben auf dem Gerät und werden nie an Google-Server gesendet oder auf diesen gespeichert. Hier ein Überblick über den Prozess, der dafür sorgt, dass die bereitgestellten Sicherheitsebenen denen eines hardwarebasierten RoR-Systems auf Geräteebene ähneln:

  • Android wendet kryptografische Schutzmaßnahmen auf Daten an, die auf einem Gerät gespeichert sind.
  • Alle Daten werden durch Schlüssel geschützt, die in der vertrauenswürdigen Ausführungsumgebung gespeichert sind. (TEE)
  • Die TEE gibt die Schlüssel nur frei, wenn das laufende Betriebssystem die kryptografische Authentifizierung (verifizierter Boot) besteht.
  • Der RoR-Dienst, der auf Google-Servern ausgeführt wird, schützt CE-Daten durch das Speichern eines geheimen Schlüssels, der nur für einen begrenzten Zeitraum abgerufen werden kann. Das funktioniert im gesamten Android-Ökosystem.
  • Ein kryptografischer Schlüssel, der durch eine Nutzer-PIN geschützt ist, wird zum Entsperren des Geräts verwendet. und entschlüsseln den CE-Speicher.
    • Wenn ein Neustart über Nacht geplant ist, fordert Android den Nutzer dazu auf, seine PIN und berechnet dann ein synthetisches Passwort (SP).
    • Anschließend verschlüsselt er den SP zweimal: einmal mit einem Schlüssel K_s, der im RAM gespeichert ist, und noch einmal mit einem Schlüssel K_k, der im TEE gespeichert ist.
    • Der doppelt verschlüsselte SP wird auf dem Laufwerk gespeichert und der SP wird aus dem RAM gelöscht. Beide Schlüssel werden neu generiert und nur für einen Neustart verwendet.
  • Wenn ein Neustart erforderlich ist, vertraut Android dem Server K_s. Der Beleg mit K_k wird vor dem Speichern auf dem Laufwerk verschlüsselt.
  • Nach dem Neustart entschlüsselt Android den Beleg mit K_k und sendet ihn an den Server, um K_s abzurufen.
    • Mit K_k und K_s wird der auf dem Laufwerk gespeicherte Dienstanbieter entschlüsselt.
    • Android verwendet den SP, um den CE-Speicher zu entsperren und den normalen App-Start zu ermöglichen.
    • K_k und K_s werden verworfen.

Die Updates zum Schutz deines Smartphones können jederzeit für dich: während du schläfst.

SIM-PIN noch einmal abspielen

Unter bestimmten Bedingungen wird der PIN-Code einer SIM-Karte aus einem Cache überprüft. Dieser Vorgang wird als SIM-PIN-Wiederholung bezeichnet.

Eine SIM-Karte mit einer aktivierten PIN muss ebenfalls einen nahtlosen PIN-Code durchlaufen. Bestätigung (eine SIM-PIN-Neuwiedergabe) nach einem unbeaufsichtigten Neustart zur Wiederherstellung der Mobilfunkverbindung Verbindung (erforderlich für Telefonanrufe, SMS und Datendienste). Die SIM-PIN und die entsprechenden Informationen zur SIM-Karte (ICCID und SIM-Steckplatz) Nummer) werden zusammen sicher gespeichert. Die gespeicherte PIN kann abgerufen und verwendet werden erst nach einem erfolgreichen unbeaufsichtigten Neustart aktiviert werden. Wenn das Gerät gesichert ist, wird die SIM-PIN mit Schlüsseln gespeichert, die durch den LSKF geschützt sind. Wenn die SIM aktiviert ist, erfordert die Interaktion mit dem RoR-Server eine WLAN-Verbindung für das OTA-Update und den serverbasierten RoR, was die grundlegenden Funktionen (mit Mobilfunkverbindung) nach dem Neustart.

Die SIM-PIN wird jedes Mal neu verschlüsselt und gespeichert, wenn der Nutzer sie aktiviert, bestätigt oder ändert. Die SIM-PIN wird verworfen, wenn einer der folgenden Fälle eintritt:

  • Die SIM wurde entfernt oder zurückgesetzt.
  • Der Nutzer deaktiviert die PIN.
  • Ein nicht durch RoR initiierter Neustart ist aufgetreten.

Die gespeicherte SIM-PIN kann nur einmal nach dem durch RoR initiierten Neustart verwendet werden. nur für sehr kurze Zeit (20 Sekunden) – wenn die Details der SIM-Karte Kartenübereinstimmung. Die gespeicherte SIM-PIN verlässt die TelephonyManager App niemals können von externen Modulen nicht abgerufen werden.

Implementierungsrichtlinien

In Android 12 sorgen die client- und serverbasierten RoR-Funktionen für eine geringere Auslastung der Partner, wenn sie OTA-Updates pushen. Erforderliche Updates können während der Geräteauslastung erfolgen, z. B. während der festgelegten Ruhezeit.

Um sicherzustellen, dass OTA-Updates in solchen Zeiträumen die Nutzer nicht unterbrechen, dunklen Modus zur Minderung von Lichtemissionen. Dazu muss der Bootloader des Geräts nach dem String „reason“ unattended suchen. Wenn unattended true ist, versetzen Sie das Gerät in den dunklen Modus. Beachten Sie, dass es in der Verantwortung jedes OEMs liegt, Schall- und Lichtemissionen reduzieren.

Wenn Sie ein Upgrade auf Android 12 durchführen oder Android 12-Geräten müssen Sie nichts unternehmen, implementieren Sie die neue RoR-Funktion.

Im Ablauf für Mehrfachkundenkonten gibt es einen neuen Anruf: isPreparedForUnattendedUpdate, (siehe unten):

@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
            android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)

Sie müssen dies nicht implementieren, da die HAL seit Android 12 eingestellt wurde.

TelephonyManager

Der OTA-Client ruft die TelephonyManager-System-API auf, wenn in Android 12 ein Neustart bevorsteht. Diese API verschiebt alle im Cache gespeicherten PIN-Codes von den Status AVAILABLE in den Status REBOOT_READY. Das TelephonyManager-System API wird durch das vorhandene REBOOT geschützt Manifestberechtigung.

 /**
    * The unattended reboot was prepared successfully.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_SUCCESS = 0;

   /**
    * The unattended reboot was prepared, but the user will need to manually
    * enter the PIN code of at least one SIM card present in the device.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED = 1;

   /**
    * The unattended reboot was not prepared due to generic error.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_ERROR = 2;

   /** @hide */
   @Retention(RetentionPolicy.SOURCE)
   @IntDef(prefix = {"PREPARE_UNATTENDED_REBOOT_"},
           value = {
                   PREPARE_UNATTENDED_REBOOT_SUCCESS,
                   PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED,
                   PREPARE_UNATTENDED_REBOOT_ERROR
           })
   public @interface PrepareUnattendedRebootResult {}

   /**
    * Prepare TelephonyManager for an unattended reboot. The reboot is
    * required to be done shortly after the API is invoked.
    *
    * Requires system privileges.
    *
    * <p>Requires Permission:
    *   {@link android.Manifest.permission#REBOOT}
    *
    * @return {@link #PREPARE_UNATTENDED_REBOOT_SUCCESS} in case of success.
    * {@link #PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED} if the device contains
    * at least one SIM card for which the user needs to manually enter the PIN
    * code after the reboot. {@link #PREPARE_UNATTENDED_REBOOT_ERROR} in case
    * of error.
    * @hide
    */
   @SystemApi
   @RequiresPermission(android.Manifest.permission.REBOOT)
   @PrepareUnattendedRebootResult
   public int prepareForUnattendedReboot()

Die TelephonyManager-System-API wird von privilegierten APKs verwendet.

Testen

Führen Sie zum Testen der neuen API diesen Befehl aus:

    adb shell cmd phone unattended-reboot

Dieser Befehl funktioniert nur, wenn die Shell als Root (adb root) ausgeführt wird.

Nur Android 11

Der Rest dieser Seite gilt für Android 11.

Ab Juli 2020 fallen Implementierungen von RoR HAL in zwei Kategorien:

  1. Wenn die SoC-Hardware die RAM-Persistenz über Neustarts hinweg unterstützt, können OEMs die Standardimplementierung in AOSP (Default RAM Escrow) verwenden.
  2. Ob die Hardware oder das SoC des Geräts eine sichere Hardwareenklave (eine separate Sicherheitskoprozessor mit eigenem RAM und ROM), muss er zusätzlich Folgendes:
    • Sie müssen einen Neustart der Haupt-CPU erkennen können.
    • eine Hardware-Timer-Quelle haben, die auch nach einem Neustart bestehen bleibt. Das heißt, die Enclave muss den Neustart erkennen und einen vor dem Neustart festgelegten Timer ablaufen lassen können.
    • Unterstützung für das Speichern eines Treuhänderschlüssels im Enclave-RAM/-ROM, sodass er nicht durch Offlineangriffe wiederhergestellt werden kann. Der RoR-Schlüssel muss so gespeichert werden, damit Insider oder Angreifer es nicht wiederherstellen können.

Standard-RAM-Treuhänder

AOSP verfügt über eine Implementierung von RoR HAL unter Verwendung der RAM-Persistenz. Damit dies funktioniert, müssen OEMs dafür sorgen, dass ihre SoCs die RAM-Persistenz über Neustarts hinweg unterstützen. Einige SoCs können den RAM-Inhalt bei einem Neustart nicht beibehalten, OEMs sollten sich an ihre SoC-Partner wenden, bevor sie diesen Standard-HAL aktivieren. Die kanonische Referenz dazu finden Sie im folgenden Abschnitt.

Ablauf der OTA-Aktualisierung mit RoR

Die OTA-Client-App auf dem Smartphone muss über Manifest.permission.REBOOT (Manifest.permission.REBOOT). und Manifest.permission.RECOVERY, um die erforderlichen Methoden RR implementieren. Mit dieser Voraussetzung kann führen Sie folgende Schritte aus:

  1. Die OTA-Client-App lädt das Update herunter.
  2. OTA-Client-App-Aufrufe an RecoverySystem#prepareForUnattendedUpdate, die dazu führen, dass der Nutzer beim nächsten Entsperren auf dem Sperrbildschirm nach seiner PIN, seinem Muster oder seinem Passwort gefragt wird.
  3. Der Nutzer entsperrt das Gerät auf dem Sperrbildschirm und das Gerät ist bereit, das Update anzuwenden.
  4. Die OTA-Client-App ruft RecoverySystem#rebootAndApply auf, was sofort löst einen Neustart aus.

Am Ende dieses Ablaufs wird das Gerät neu gestartet und der RoR-Mechanismus entsperrt den verschlüsselten Speicher für Anmeldedaten. Für Apps: wird als normales Entsperren des Nutzers angezeigt, sodass er alle Signale erhält, z. B. AKTION_LOCKED_BOOT_ABGESCHLOSSEN und ACTION_BOOT_ABGESCHLOSSEN wie sie es normalerweise tun.

Produktkonfigurationen ändern

Ein Produkt, das als Unterstützer der RoR-Funktion in Android 11 gekennzeichnet ist, muss eine Implementierung der RebootEscrow HAL und die XML-Datei mit der Feature-Markierung enthalten. Die Standardimplementierung funktioniert gut auf Geräten, die einen warmen Neustart verwenden (wenn der Die Stromversorgung des DRAM bleibt während des Neustarts eingeschaltet.

Markierung für treuhänderische Funktion neu starten

Die Elementmarkierung muss ebenfalls vorhanden sein:

PRODUCT_COPY_FILES += \
    frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml

HAL-Implementierung des Standard-Neustarts Treuhandzahlung

Um die Standardimplementierung zu verwenden, müssen Sie 65.536 (0x10.000) Byte reservieren. Nie diese Byte in einen nichtflüchtigen Speicher schreiben, um sicherzustellen, dauerhaft.

Änderungen am Gerätebaum des Linux-Kernels

Im Gerätebaum des Linux-Kernels müssen Sie Speicher für eine pmem-Region reservieren. Im folgenden Beispiel wird gezeigt, wie 0x50000000 reserviert wird:

  reserved-memory {
    my_reservation@0x50000000 {
      no-map;
      reg = <0x50000000 0x10000>;
    }
  }

  reboot_escrow@0 {
    compatible = "pmem-region";
    reg = <0x50000000 0x10000>;
  };

Prüfen Sie, ob sich im Blockverzeichnis ein neues Gerät mit einem Namen wie /dev/block/pmem0 (z. B. pmem1 oder pmem2) befindet.

Device.mk-Änderungen

Angenommen, Ihr neues Gerät aus dem vorherigen Schritt heißt pmem0, müssen Sie dafür sorgen, dass vendor/<oem>/<product>/device.mk die folgenden neuen Einträge hinzugefügt werden:

# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
    ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
    android.hardware.rebootescrow-service.default
SELinux-Regeln

Fügen Sie dem file_contexts auf dem Gerät diese neuen Einträge hinzu:

/dev/block/pmem0  u:object_r:rebootescrow_device:s0
/vendor/bin/hw/android\.hardware\.rebootescrow-service\.default  u:object_r:hal_rebootescrow_default_exec:s0