Fortsetzen nach Neustart

In Android 11 können OTA-Updates mit den 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 OTA-Update anzuwenden, wird durch Resume-on-Reboot (RoR) der mit Anmeldedaten verschlüsselte Speicher (Credential Encrypted, CE) des Geräts entsperrt.

Partner können diesen Prozess zwar mit einer OTA-Systemfunktion kombinieren, die Updates anwendet, wenn das Gerät in Android 11 voraussichtlich im Leerlauf ist. In Android 12 ist jedoch keine zusätzliche OTA-Systemfunktion erforderlich. Der RoR-Prozess bietet Nutzern zusätzliche Sicherheit und Komfort, da die Updates während der Leerlaufzeiten des Geräts durchgeführt werden können. Die Multi-Client- und serverbasierten Updatefunktionen von Android 12 bieten zusammen Sicherheit auf Hardwareebene.

Obwohl Sie die Geräteberechtigung für die android.hardware.reboot_escrow-Funktion bereitstellen müssen, um RoR in Android 11 zu unterstützen, ist dies nicht erforderlich, um serverbasiertes RoR in Android 12 und höher zu aktivieren, da diese Versionen den HAL nicht verwenden.

Hintergrund

Ab Android 7 wurde Direct Boot unterstützt. Damit können Apps auf einem Gerät gestartet werden, bevor der CE-Speicher vom Nutzer entsperrt wird. Die Implementierung der Direct Boot-Unterstützung bot Nutzern eine bessere Erfahrung, bevor der Lock Screen Knowledge Factor (LSKF) nach einem Bootvorgang eingegeben werden musste.

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

Bedrohungsmodell

Bei einer RoR-Implementierung muss sichergestellt werden, dass es für einen Angreifer extrem schwierig ist, die CE-verschlüsselten Daten des Nutzers wiederherzustellen, wenn ein Gerät in die Hände des Angreifers gelangt, selbst wenn das Gerät eingeschaltet ist, der CE-Speicher entsperrt ist und das Gerät vom Nutzer nach Erhalt eines OTA-Updates entsperrt wird. Der Schutz vor Insider-Angriffen muss auch dann wirksam sein, wenn der Angreifer Zugriff auf die kryptografischen Signierschlüssel für Broadcasts erhält.

Konkret darf ein Angreifer, der das Gerät physisch besitzt, nicht auf den CE-Speicher zugreifen, und es gelten die folgenden 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 OTA-Update erhält.
  • Die Funktionsweise von Hardware (z. B. Anwendungs- oder Flash-Speicher) kann geändert werden, sofern dies nicht in den Einschränkungen unten beschrieben ist. Eine solche Änderung führt jedoch zu einer Verzögerung von mindestens einer Stunde und einem Neustart, bei dem der RAM-Inhalt gelöscht wird.

Beschränkungen

  • Die Funktionsweise von manipulationssicherer Hardware (z. B. Titan M) kann nicht geändert werden.
  • Der Arbeitsspeicher des aktiven Geräts kann nicht gelesen werden.
  • Die Anmeldedaten des Nutzers (PIN, Muster, Passwort) dürfen nicht erraten oder auf andere Weise eingegeben werden.

Lösung

Das RoR-Updatesystem für Android 12 bietet Schutz vor sehr ausgeklügelten Angriffen. Dabei bleiben Passwörter und PINs auf dem Gerät und werden nie an Google-Server gesendet oder dort gespeichert. Hier finden Sie einen Überblick über den Prozess, der dafür sorgt, dass die bereitgestellten Sicherheitsstufen 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 sind durch Schlüssel geschützt, die in der vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) gespeichert sind.
  • Das TEE gibt die Schlüssel nur frei, wenn das ausgeführte Betriebssystem die kryptografische Authentifizierung (Verified Boot) besteht.
  • Der auf Google-Servern ausgeführte RoR-Dienst schützt CE-Daten, indem er ein Secret speichert, das nur für einen begrenzten Zeitraum abgerufen werden kann. Das funktioniert im gesamten Android-Ökosystem.
  • Ein kryptografischer Schlüssel, der durch die PIN eines Nutzers geschützt ist, wird verwendet, um das Gerät zu entsperren und den CE-Speicher zu entschlüsseln.
    • 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 das SP zweimal verschlüsselt: einmal mit einem im RAM gespeicherten Schlüssel K_s und noch einmal mit einem im TEE gespeicherten Schlüssel K_k.
    • Der doppelt verschlüsselte SP wird auf der Festplatte gespeichert und aus dem RAM gelöscht. Beide Schlüssel werden neu generiert und nur für einen Neustart verwendet.
  • Wenn es an der Zeit ist, den Server neu zu starten, übergibt Android die Verantwortung an K_s. Die Rechnung mit K_k wird verschlüsselt, bevor sie auf dem Laufwerk gespeichert wird.
  • Nach dem Neustart verwendet Android K_k, um den Beleg zu entschlüsseln, und sendet ihn dann an den Server, um K_s abzurufen.
    • K_k und K_s werden zum Entschlüsseln des auf der Festplatte gespeicherten SP verwendet.
    • 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 einem für Sie passenden Zeitpunkt erfolgen: während Sie schlafen.

SIM-PIN noch einmal eingeben

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

Bei einer SIM-Karte mit aktivierter PIN muss nach einem unbeaufsichtigten Neustart auch eine nahtlose PIN-Code-Bestätigung (eine SIM-PIN-Wiederholung) erfolgen, um die Mobilfunkverbindung wiederherzustellen (erforderlich für Telefonanrufe, SMS und Datendienste). Die SIM-PIN und die zugehörigen SIM-Karteninformationen (ICCID und SIM-Slot-Nummer) werden gemeinsam sicher gespeichert. Die gespeicherte PIN kann nur nach einem erfolgreichen unbeaufsichtigten Neustart abgerufen und zur Bestätigung verwendet werden. Wenn das Gerät gesichert ist, wird die SIM-PIN mit Schlüsseln gespeichert, die durch den LSKF geschützt sind. Wenn die PIN der SIM-Karte aktiviert ist, ist für die Interaktion mit dem RoR-Server eine WLAN-Verbindung für das OTA-Update und das serverbasierte RoR erforderlich. Dadurch wird die grundlegende Funktionalität (mit Mobilfunkverbindung) nach dem Neustart sichergestellt.

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

  • Die SIM-Karte wird entfernt oder zurückgesetzt.
  • Der Nutzer deaktiviert die PIN.
  • Es wurde ein Neustart durchgeführt, der nicht von RoR initiiert wurde.

Die gespeicherte SIM-PIN kann nach dem vom RoR initiierten Neustart nur einmal und nur für einen sehr kurzen Zeitraum (20 Sekunden) verwendet werden, wenn die Details der SIM-Karte übereinstimmen. 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 Belastung der Partner beim Pushen von OTA-Updates. Erforderliche Updates können während der Geräteausfallzeiten erfolgen, z. B. während der Schlafenszeit.

Damit OTA-Updates in solchen Zeiträumen Nutzer nicht unterbrechen, sollten Sie den Dark Mode verwenden, um die Lichtemissionen zu reduzieren. Lassen Sie dazu den Geräte-Bootloader nach dem String „reason“ unattended suchen. Wenn unattended true ist, versetze das Gerät in den dunklen Modus. Es liegt in der Verantwortung der einzelnen OEMs, die Emissionen von Geräuschen und Licht zu reduzieren.

Wenn Sie entweder ein Upgrade auf Android 12 durchführen oder Android 12-Geräte auf den Markt bringen, müssen Sie nichts tun, um die neue RoR-Funktion zu implementieren.

Im Multi-Client-Ablauf gibt es einen neuen Aufruf, isPreparedForUnattendedUpdate, der unten dargestellt ist:

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

Sie müssen dies nicht implementieren, da das HAL ab Android 12 nicht mehr unterstützt wird.

TelephonyManager

Der OTA-Client ruft die System-API TelephonyManager auf, wenn in Android 12 ein Neustart bevorsteht. Mit dieser API werden alle im Cache gespeicherten PIN-Codes vom Status AVAILABLE in den Status REBOOT_READY verschoben. Die TelephonyManager-System-API ist durch die vorhandene Manifestberechtigung REBOOT geschützt.

 /**
    * 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 folgenden Befehl aus, um die neue API zu testen:

    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. Wenn die Gerätehardware oder das SoC eine sichere Hardware-Enklave (einen separaten Sicherheits-Coprozessor mit eigenem RAM und ROM) unterstützt, muss sie zusätzlich Folgendes tun:
    • Er muss einen Neustart der Haupt-CPU erkennen können.
    • Sie benötigen eine Hardware-Timerquelle, die auch nach Neustarts erhalten bleibt. Das heißt, die Enklave muss den Neustart erkennen und einen vor dem Neustart festgelegten Timer ablaufen lassen können.
    • Unterstützung für das Speichern eines hinterlegten Schlüssels im RAM/ROM der Enklave, sodass er nicht durch Offline-Angriffe wiederhergestellt werden kann. Der RoR-Schlüssel muss so gespeichert werden, dass er nicht von Insidern oder Angreifern wiederhergestellt werden kann.

Standard-RAM-Treuhand

AOSP enthält eine Implementierung des RoR-HAL mit RAM-Persistenz. Damit dies funktioniert, müssen OEMs dafür sorgen, dass ihre SoCs die RAM-Persistenz bei Neustarts unterstützen. Bei einigen SoCs können RAM-Inhalte nicht über einen Neustart hinweg beibehalten werden. OEMs sollten sich daher mit ihren SoC-Partnern beraten, bevor sie diesen Standard-HAL aktivieren. Die kanonische Referenz dafür finden Sie im folgenden Abschnitt.

Ablauf eines OTA-Updates 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 aufrufen zu können. Wenn diese Voraussetzung erfüllt ist, läuft ein Update so ab:

  1. Die OTA-Client-App lädt das Update herunter.
  2. OTA-Client-App-Aufrufe an RecoverySystem#prepareForUnattendedUpdate, wodurch der Nutzer beim nächsten Entsperren auf dem Sperrbildschirm zur Eingabe seiner PIN, seines Musters oder seines Passworts aufgefordert wird.
  3. Der Nutzer entsperrt das Gerät auf dem Sperrbildschirm und das Gerät ist bereit für das Update.
  4. OTA-Client-App-Aufrufe an RecoverySystem#rebootAndApply, wodurch sofort ein Neustart ausgelöst wird.

Am Ende dieses Ablaufs wird das Gerät neu gestartet und der RoR-Mechanismus entsperrt den mit Anmeldedaten verschlüsselten Speicher (Credential Encrypted, CE). Für Apps sieht das wie eine normale Entsperrung durch den Nutzer aus. Sie erhalten also alle Signale, die sie normalerweise erhalten, z. B. ACTION_LOCKED_BOOT_COMPLETED und ACTION_BOOT_COMPLETED.

Produktkonfigurationen ändern

Ein Produkt, das in Android 11 als RoR-kompatibel gekennzeichnet ist, muss eine Implementierung des RebootEscrow-HAL und die XML-Datei mit der Funktionsmarkierung enthalten. Die Standardimplementierung funktioniert gut auf Geräten, die einen Warm-Reboot verwenden (wenn die Stromversorgung des DRAM während des Neustarts aufrechterhalten wird).

Markierung für die Funktion „Neustart-Treuhand“

Die Markierung für die Funktion 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

Standardmäßige HAL-Implementierung für die Escrow-Funktion beim Neustart

Wenn Sie die Standardimplementierung verwenden möchten, müssen Sie 65.536 Byte (0x10000) reservieren. Schreiben Sie diese Bytes niemals in einen nichtflüchtigen Speicher, damit die Sicherheitseigenschaften erhalten bleiben.

Ä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 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. Dann müssen die folgenden neuen Einträge zu vendor/<oem>/<product>/device.mk 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 die folgenden neuen Einträge zur file_contexts des Geräts 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