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 RecoverySystem-Klasse angewendet werden. Nachdem ein Gerät zum Anwenden eines OTA-Updates neu gestartet wurde, wird durch das Zurücksetzen bei Neustarts (Resume-on-Neustart) der CE-Speicher (Credential Encrypted) des Geräts entsperrt.

Partner können diesen Prozess zwar mit einer OTA-Systemfunktion koppeln, die Updates anwendet, wenn das Gerät unter 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 Aktualisierungen während der Inaktivitätszeiten des Geräts vorgenommen werden können. Die Mehrclient- und serverbasierte Update-Funktionen von Android 12 sorgen zusammen für Sicherheit auf Gerätehardware-Ebene.

Sie müssen zwar eine Geräteberechtigung für das Feature android.hardware.reboot_escrow zur Unterstützung von RoR in Android 11 bereitstellen, dies ist jedoch nicht erforderlich, um den serverbasierten RoR in Android 12 und höher zu aktivieren, da HAL nicht verwendet wird.

Hintergrund

Ab Android 7 wird Direct Boot von Android unterstützt. Dadurch können die Apps auf einem Gerät gestartet werden, bevor der CE-Speicher vom Nutzer entsperrt wird. Die Implementierung des Direct Boot-Supports bot Nutzern eine bessere Erfahrung, bevor der Sperrbildschirm-Wissensfaktor (LSKF) nach dem Start eingegeben werden musste.

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

Bedrohungsmodell

Durch die Implementierung von RoR muss sichergestellt werden, dass es dem Angreifer, wenn ein Gerät in die Hände eines Angreifers fällt, die CE-verschlüsselten Daten des Nutzers extrem schwer wiederherstellen kann, selbst wenn das Gerät eingeschaltet, der CE-Speicher entsperrt und das Gerät nach Erhalt eines OTA-Updates vom Nutzer entsperrt wird. Die Abwehr von Insiderangriffen muss auch dann effektiv sein, wenn sich der Angreifer Zugriff auf die kryptografischen Signaturschlüssel verschafft.

Insbesondere darf der CE-Speicher nicht von einem Angreifer gelesen werden, der das Gerät tatsächlich besitzt und der folgende Funktionen und Einschränkungen aufweist:

Funktionen

  • Kann mit dem Signaturschlüssel eines beliebigen Anbieters oder Unternehmens beliebige Nachrichten signieren.
  • Dies kann dazu führen, dass das Gerät ein OTA-Update erhält.
  • Kann den Betrieb jeder Hardware, z. B. eines Anwendungsprozessors oder Flash-Speichers, ändern, sofern unten nicht unter Einschränkungen beschrieben. Eine solche Änderung beinhaltet jedoch sowohl eine Verzögerung von mindestens einer Stunde als auch einen Neustart, der den RAM-Inhalt zerstört.

Beschränkungen

  • Der Betrieb von 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) dürfen nicht erraten oder anderweitig dazu führen, dass sie eingegeben werden.

Die Lösung

Das Android 12 RoR-Updatesystem bietet Sicherheit gegen ausgeklügelte Angreifer und tut dies, während On-Device-Passwörter und PINs auf dem Gerät verbleiben und nie an Google-Server gesendet oder auf diesen gespeichert werden. Dies ist eine Übersicht über den Prozess, mit dem sichergestellt wird, dass die bereitgestellten Sicherheitsstufen einem hardwarebasierten RoR-System 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 (Trusted Execution Environment, TEE) gespeichert werden.
  • Das TEE gibt die Schlüssel nur frei, wenn das ausgeführte Betriebssystem die kryptografische Authentifizierung (verifizierter Bootmodus) besteht.
  • Der auf Google-Servern ausgeführte RoR-Dienst schützt CE-Daten, indem ein Secret gespeichert wird, das nur für eine begrenzte Zeit abgerufen werden kann. Das funktioniert auf allen Android-Geräten.
  • 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 der SP zweimal verschlüsselt: einmal mit einem im RAM gespeicherten Schlüssel K_s und einmal mit einem in TEE gespeicherten Schlüssel K_k.
    • Der doppelt verschlüsselte SP wird auf dem Laufwerk gespeichert und der SP 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 verschlüsselt, bevor er auf dem Laufwerk gespeichert wird.
  • Nach dem Neustart entschlüsselt Android die Quittung mit K_k und sendet sie dann 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 zu einer für dich passenden Zeit erfolgen: während du schläfst.

SIM-PIN noch einmal abspielen

Unter bestimmten Bedingungen wird der PIN-Code einer SIM-Karte aus einem Cache verifiziert. Dieser Vorgang wird als SIM-PIN-Wiedergabe bezeichnet.

Eine SIM-Karte mit einer aktivierten PIN muss nach einem unbeaufsichtigten Neustart ebenfalls einer nahtlosen PIN-Code-Überprüfung (SIM-PIN-Wiedergabe) unterzogen werden, um die Mobilfunkverbindung wiederherzustellen (erforderlich für Telefonanrufe, SMS und Datendienste). Die SIM-PIN und die zugehörigen Informationen zur SIM-Karte (ICCID und SIM-Steckplatznummer) werden sicher zusammen gespeichert. Die gespeicherte PIN kann erst 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 das LSKF geschützt sind. Wenn für die SIM die PIN aktiviert ist, erfordert die Interaktion mit dem RoR-Server eine WLAN-Verbindung für das OTA-Update und den serverbasierten RoR, der die grundlegende Funktionalität (mit Mobilfunkverbindung) nach dem Neustart gewährleistet.

Die PIN der SIM-Karte wird jedes Mal neu verschlüsselt und gespeichert, wenn der Nutzer sie erfolgreich aktiviert, überprüft oder ändert. Die SIM-PIN wird verworfen, wenn eines der folgenden Probleme auftritt:

  • 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 per RoR initiierten Neustart 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 die TelephonyManager App nie und kann nicht von externen Modulen abgerufen werden.

Implementierungsrichtlinien

In Android 12 entlasten die Multiclient- und serverbasierte RoR-Funktionen Partner, wenn sie OTA-Updates senden. Notwendige Updates können während praktischer Ausfallzeiten des Geräts erfolgen, z. B. während festgelegter Schlafzeiten.

Damit OTA-Aktualisierungen während solcher Zeiträume die Nutzer nicht unterbrechen, sollten Sie den dunklen Modus verwenden, um Lichtemissionen zu minimieren. Dazu muss der Geräte-Bootloader nach dem Stringgrund unattended suchen. Wenn unattended den Wert true hat, versetzen Sie das Gerät in den dunklen Modus. Beachten Sie, dass jeder OEM dafür verantwortlich ist, Schall- und Lichtemissionen zu reduzieren.

Wenn Sie ein Upgrade auf Android 12 ausführen oder Android 12-Geräte einführen, müssen Sie nichts unternehmen, um die neue RoR-Funktion zu implementieren.

Im Mehrfachkundenablauf befindet sich ein neuer Aufruf, 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 HAL ab Android 12 eingestellt wird.

Telefonmanager

Der OTA-Client ruft die System-API TelephonyManager 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 System-API TelephonyManager wird 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 den 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 lassen sich die Implementierungen von RoR HAL in zwei Kategorien unterteilen:

  1. Wenn die SoC-Hardware die RAM-Persistenz auch nach einem Neustart unterstützt, können OEMs die Standardimplementierung in AOSP (Default RAM Escrow) verwenden.
  2. Wenn die Gerätehardware oder das SoC eine sichere Hardwareenklave unterstützt (einen diskreten Sicherheitskoprozessor mit eigenem RAM und ROM), muss das Gerät außerdem Folgendes tun:
    • 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 Enklave muss den Neustart erkennen und einen vor dem Neustart festgelegten Timer ablaufen können.
    • Die Speicherung eines treuhänderischen Schlüssels im Enklave-RAM/-ROM, damit er nicht mit Offlineangriffen wiederhergestellt werden kann. Der RoR-Schlüssel muss so gespeichert werden, dass er für Insider oder Angreifer nicht wiederhergestellt werden kann.

Standard-RAM-Treuhänder

AOSP verfügt über eine Implementierung von RoR HAL unter Verwendung der RAM-Persistenz. Dazu müssen OEMs dafür sorgen, dass ihre SoCs die RAM-Persistenz auch nach einem Neustart unterstützen. Einige SoCs können den RAM-Inhalt bei einem Neustart nicht beibehalten. Daher wird OEMs empfohlen, sich vor der Aktivierung dieses Standard-HAL an ihre SoC-Partner zu wenden. 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. Wenn diese Voraussetzung erfüllt ist, umfasst der Ablauf einer Aktualisierung die folgenden Schritte:

  1. Die OTA-Client-App lädt das Update herunter.
  2. Die OTA-Client-App ruft RecoverySystem#prepareForUnattendedUpdate auf. Dadurch wird der Nutzer beim nächsten Entsperren aufgefordert, auf dem Sperrbildschirm seine PIN, sein Muster oder sein Passwort einzugeben.
  3. Der Nutzer entsperrt das Gerät auf dem Sperrbildschirm und das Gerät kann aktualisiert werden.
  4. Die OTA-Clientanwendung ruft RecoverySystem#rebootAndApply auf, wodurch sofort ein Neustart ausgelöst wird.

Am Ende dieses Vorgangs wird das Gerät neu gestartet und der RoR-Mechanismus entsperrt den CE-Speicher (Anmeldedatenverschlüsselung). Für Apps wird dies als normale Entsperrung durch den Nutzer angezeigt. Sie erhält also alle Signale wie ACTION_LOCKED_BOOT_COMPLETED und ACTION_BOOT_COMPLETED, die sie auch sonst tun.

Produktkonfigurationen ändern

Ein Produkt, das die RoR-Funktion in Android 11 unterstützt, muss eine Implementierung des RestartEscrow HAL und die XML-Datei für die Funktionsmarkierung enthalten. Die Standardimplementierung funktioniert gut auf Geräten, die einen Warm-Neustart verwenden (wenn der DRAM während des Neustarts eingeschaltet bleibt).

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 für Treuhandzahlung standardmäßig neu starten

Um die Standardimplementierung zu verwenden, müssen Sie 65.536 (0x10.000) Byte reservieren. Schreiben Sie diese Byte niemals in einen nichtflüchtigen Speicher, um sicherzustellen, dass die Sicherheitseigenschaften erhalten bleiben.

Änderungen der Linux-Kernel-Gerätestruktur

In der Gerätestruktur des Linux-Kernels müssen Sie Arbeitsspeicher 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 befindet, z. B. pmem1 oder pmem2.

Änderungen an Device.mk

Wenn das neue Gerät aus dem vorherigen Schritt den Namen pmem0 hat, 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 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