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.

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 nach dem Neustart Benachrichtigungen von allen installierten Apps erhalten.

Bedrohungsmodell

Bei der Implementierung von Datenwiederherstellung nach Diebstahl 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 gerät, 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. Die Widerstandsfähigkeit gegen Insiderangriffe 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.
  • Kann den Betrieb von Hardware (z. B. eines Anwendungsprozessors oder Flash-Speichers) ändern, sofern dies nicht unter Einschränkungen unten aufgeführt ist. Eine solche Änderung erfordert jedoch sowohl eine Verzögerung von mindestens einer Stunde als auch einen Neustart, der den RAM-Inhalt zerstört.

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. Hier ein Überblick über den Prozess, der dafür sorgt, dass die bereitgestellten Sicherheitsebenen denen eines hardwarebasierten RoR-Systems auf Geräteebene ähneln:

  • Android schützt auf dem Gerät gespeicherte Daten mit kryptografischen Verfahren.
  • Alle Daten werden durch Schlüssel geschützt, die in der Trusted Execution Environment (TEE) gespeichert sind.
  • 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 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 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 es an der Zeit ist, neu zu starten, übergibt Android K_s an den Server. 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.
    • K_k und K_s werden zum Entschlüsseln des auf dem Laufwerk gespeicherten SP verwendet.
    • Android verwendet den SP, um den CE-Speicher zu entsperren und das normale Starten von Apps 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 die PIN einer SIM-Karte aus einem Cache überprüft. Dieser Vorgang wird als SIM-PIN-Wiederholung bezeichnet.

Bei einer SIM-Karte mit aktivierter PIN muss nach einem unbeaufsichtigten Neustart auch eine nahtlose PIN-Bestätigung (SIM-PIN-Wiedergabe) erfolgen, um die Mobilfunkverbindung wiederherzustellen (erforderlich für Anrufe, 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 erst nach einem erfolgreichen automatischen 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 aktiviert ist, erfordert die Interaktion mit dem RoR-Server eine WLAN-Verbindung für das Over-the-air-Update und die serverbasierte Wiederherstellung, was nach dem Neustart grundlegende Funktionen (mit Mobilfunkverbindung) ermöglicht.

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-Karte wurde entfernt oder zurückgesetzt.
  • Der Nutzer deaktiviert die PIN.
  • Es hat ein Neustart stattgefunden, der nicht durch die Funktion „RoR“ (Restart on Reboot) initiiert wurde.

Die gespeicherte SIM-PIN kann nach dem durch die Wiederherstellungsoption veranlassten 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 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 true ist, versetzen Sie das Gerät in den dunklen Modus. Beachten Sie, dass es in der Verantwortung jedes OEMs liegt, Geräusche und Lichtemissionen zu minimieren.

Wenn Sie ein Upgrade auf Android 12 durchführen oder Android 12-Geräte auf den Markt bringen, müssen Sie nichts unternehmen, um die neue Funktion „On-Demand-Ressourcen“ zu implementieren.

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 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 vom Status AVAILABLE in den Status REBOOT_READY. Die TelephonyManager-System-API ist durch die vorhandene Manifest-Berechtigung 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 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 bezieht sich auf 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 diskreten Sicherheitscoprozessor mit eigenem RAM und ROM) unterstützt, muss sie außerdem Folgendes tun:
    • Sie müssen einen Neustart der Haupt-CPU erkennen können.
    • Eine Hardware-Timerquelle, die nach Neustarts erhalten 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, dass Insider oder Angreifer ihn nicht wiederherstellen können.

Standard-RAM-Escrow

AOSP hat eine Implementierung der RoR HAL mit 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 nicht nach einem Neustart beibehalten. OEMs sollten sich daher an ihre SoC-Partner wenden, bevor sie diese Standard-HAL aktivieren. Die kanonische Referenz dazu 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 zur Implementierung von RoR aufzurufen. Wenn diese Voraussetzung erfüllt ist, erfolgt die Aktualisierung in folgenden Schritten:

  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, wodurch sofort ein Neustart ausgelöst wird.

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 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“

Außerdem müssen folgende Angaben 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

Standard-HAL-Implementierung für die Treuhänderschaft beim Neustart

Wenn Sie die Standardimplementierung verwenden möchten, müssen Sie 65.536 Byte (0x10000) reservieren. Schreiben Sie diese Bytes niemals in 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, 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