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 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 eine Geräteberechtigung für die Funktion 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 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. 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 mit dem Signaturschlüssel eines beliebigen Anbieters oder Unternehmens beliebige Nachrichten 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 beinhaltet jedoch sowohl eine Verzögerung von mindestens einer Stunde als auch einen Aus- und Einschaltzyklus, der die RAM-Inhalte 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) können nicht erraten werden und es ist auch nicht möglich, dass sie anderweitig eingegeben werden.

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. 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 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 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 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 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 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 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 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 den 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 die OTA-Aktualisierung und einen serverbasierten RoR, der die grundlegende Funktionalität (mit Mobilfunkverbindung) nach dem Neustart sicherstellt.

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.
  • Es hat ein nicht von RoR initiierter Neustart stattgefunden.

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. Erforderliche Updates können während geeigneter Geräteauszeiten 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 OEM 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 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 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.
    • Die Speicherung eines treuhänderischen Schlüssels im RAM/ROM der Enklave, damit er nicht mit Offlineangriffen wiederhergestellt werden kann. Der RoR-Schlüssel muss so gespeichert werden, dass Insider oder Angreifer ihn nicht wiederherstellen können.

Standard-RAM-Escrow

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

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

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

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

Änderungen am Gerätebaum des Linux-Kernels

In der Gerätestruktur des Linux-Kernels müssen Sie Arbeitsspeicher 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 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