Fortsetzen nach Neustart

In Android 11 können OTA-Updates mithilfe der Mechanismen A/B-Update oder virtuelles A/B-Update in Kombination mit den Methoden der Klasse RecoverySystem angewendet werden. 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, da die Updates während der Inaktivität des Geräts durchgeführt werden können. Die Multi-Client- und serverbasierten Updatefunktionen von Android 12 bieten zusammen eine Sicherheit auf Gerätehardwareebene.

Sie müssen zwar die Geräteberechtigung für die android.hardware.reboot_escrow-Funktion angeben, um die Rückrufoption in Android 11 zu unterstützen, dies ist jedoch nicht erforderlich, um die serverbasierte Rückrufoption in Android 12 und höher zu aktivieren, da diese nicht die HAL verwenden.

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. Durch die Implementierung des Direct Boot-Supports konnten Nutzer schneller loslegen, da der Sperrbildschirm-Kenntnisfaktor (LSKF) nicht mehr nach dem Start eingegeben werden musste.

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

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.
  • Dies kann dazu führen, dass das Gerät ein OTA-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) können nicht erraten werden und es ist auch nicht möglich, dass sie anderweitig eingegeben werden.

Lösung

Das RoR-Updatesystem von Android 12 bietet Schutz vor sehr ausgefeilten Angreifern. Dabei bleiben Passwörter und PINs auf dem Gerät – sie werden nie an Google-Server gesendet oder dort gespeichert. Dieses ist eine Übersicht über den Prozess, mit dem sichergestellt wird, dass die bereitgestellten Sicherheitsniveaus ähnlich wie ein hardwarebasiertes RoR-System auf Geräteebene:

  • Android schützt auf dem Gerät gespeicherte Daten mit kryptografischen Verfahren.
  • Alle Daten werden durch Schlüssel geschützt, die in der vertrauenswürdigen Ausführungsumgebung gespeichert sind. (TEE)
  • Der TEE gibt die Schlüssel nur frei, wenn das ausgeführte Betriebssystem die Prüfung bestanden hat kryptografischer Authentifizierung (bestätigter Bootmodus)
  • 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 auf allen Android-Geräten.
  • 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 auf, seine PIN einzugeben, und berechnet dann ein synthetisches Passwort (SP).
    • Anschließend wird der Dienstanbieter zweimal verschlüsselt: einmal mit dem im RAM gespeicherten Schlüssel K_s und ein weiteres Mal mit dem im RAM gespeicherten Schlüssel. mit einem in TEE gespeicherten Schlüssel K_k.
    • 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. Beleg mit K_k verschlüsselt werden, bevor sie auf dem Laufwerk gespeichert werden.
  • 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, die Ihr Smartphone schützen, können zu einer für Sie günstigen Zeit durchgeführt werden: während Sie schlafen.

SIM-PIN-Wiederholung

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 zugehörigen SIM-Karteninformationen (ICCID und SIM-Slot-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 wird die SIM-PIN zusammen mit Schlüsseln gespeichert, die durch das 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 PIN für die SIM-Karte wird jedes Mal neu verschlüsselt und gespeichert, wenn der Nutzer sie erfolgreich aktiviert. verifiziert oder modifiziert. Die SIM-PIN wird verworfen, wenn einer der folgenden Punkte zutrifft: tritt auf:

  • Die SIM wurde entfernt oder zurückgesetzt.
  • Der Nutzer deaktiviert die PIN.
  • Es hat ein nicht von RoR initiierter Neustart stattgefunden.

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 nie die TelephonyManager App und kann nicht von externen Modulen 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.

Damit Nutzer in diesen Zeiträumen nicht durch Over-the-air-Updates gestört werden, sollten Sie den Dunkelmodus verwenden, um die Lichtemissionen zu reduzieren. Dazu muss der Bootloader des Geräts nach dem String „reason“ unattended suchen. Wenn unattended den Wert true hat, 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 mehrere Kunden gibt es einen neuen Aufruf, isPreparedForUnattendedUpdate, wie unten dargestellt:

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

Sie müssen dies nicht implementieren, da der HAL seit dem Android 12

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 auch nach einem Neustart unterstützt, können OEMs den Standardimplementierung in AOSP (Default RAM Escrow)
  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-Timerquelle, die nach Neustarts erhalten bleibt. Das heißt, der Parameter Die Enclave muss den Neustart erkennen und einen Timer ablaufen lassen, der vor dem Ereignis neu starten.
    • 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, dass Insider oder Angreifer ihn nicht wiederherstellen können.

Standard-RAM-Treuhänder

AOSP hat eine Implementierung der RoR HAL mit RAM-Persistenz. Dazu müssen OEMs dafür sorgen, dass ihre SoCs RAM-Persistenz unterstützen. über einen Neustart. 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 hierfür finden Sie im folgenden Abschnitt.

Ablauf der OTA-Aktualisierung mit RoR

Die OTA-Client-App auf dem Smartphone muss die Berechtigungen Manifest.permission.REBOOT und Manifest.permission.RECOVERY haben, um die erforderlichen Methoden zum Implementieren von RoR aufzurufen. 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 über den Sperrbildschirm und das Gerät ist bereit damit das Update angewendet wird.
  4. Die OTA-Client-App ruft RecoverySystem#rebootAndApply auf, was sofort einen Neustart auslöst.

Am Ende dieses Vorgangs startet das Gerät neu und der RoR um den CE-Speicher (Credential Encryption, CE) zu entsperren. Für Apps sieht das wie eine normale Entsperrung durch den Nutzer aus. Sie erhalten also alle Signale, die sie normalerweise erhalten würden, z. B. ACTION_LOCKED_BOOT_COMPLETED und ACTION_BOOT_COMPLETED.

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 Warmstart verwenden (wenn die Stromversorgung des DRAM während des Neustarts nicht unterbrochen wird).

Markierung für die Funktion „Escrow 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 der Linux-Kernel-Gerätestruktur

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

  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.

Änderungen an device.mk

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 des Geräts die folgenden 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