Fortsetzen beim Neustart

In Android 11 können OTA-Updates mithilfe der A/B-Update- oder virtuellen A/B-Update- Mechanismen in Kombination mit den Methoden der RecoverySystem- Klasse angewendet werden. Nachdem ein Gerät neu gestartet wurde, um ein OTA-Update anzuwenden, entsperrt Resume-on-Reboot (RoR) den Credential Encrypted (CE)-Speicher des Geräts.

Obwohl Partner diesen Prozess mit einer OTA-Systemfunktion koppeln können, die Updates anwendet, wenn das Gerät voraussichtlich inaktiv ist, benötigen Partner in Android 12 keine zusätzliche OTA-Systemfunktion. Der RoR-Prozess bietet Benutzern zusätzliche Sicherheit und Komfort, da die Updates während der Leerlaufzeiten des Geräts durchgeführt werden können, während die Multi-Client- und serverbasierten Update-Funktionen von Android 12 zusammen Sicherheit auf Gerätehardwareebene bieten.

Sie müssen zwar eine Geräteberechtigung für die Funktion android.hardware.reboot_escrow erteilen, um RoR in Android 11 zu unterstützen, aber Sie müssen dies nicht tun, um serverbasiertes RoR in Android 12 und höher zu aktivieren, da diese kein HAL verwenden.

Hintergrund

Ab Android 7 unterstützt Android Direct Boot , wodurch die Apps auf einem Gerät gestartet werden können, bevor der CE-Speicher vom Benutzer entsperrt wird. Die Implementierung der Direct Boot-Unterstützung bot Benutzern ein besseres Erlebnis, bevor der Lock Screen Knowledge Factor (LSKF) nach einem Bootvorgang eingegeben werden musste.

RoR ermöglicht die Entsperrung des CE-Speichers aller Apps auf einem Gerät, einschließlich derjenigen, die Direct Boot nicht unterstützen, wenn nach einem OTA-Update ein Neustart eingeleitet wird. Mit dieser Funktion können Benutzer nach dem Neustart Benachrichtigungen von allen installierten Apps erhalten.

Bedrohungsmodell

Eine Implementierung von RoR muss sicherstellen, dass es für den Angreifer äußerst schwierig ist, die CE-verschlüsselten Daten des Benutzers wiederherzustellen, wenn ein Gerät in die Hände eines Angreifers fällt, selbst wenn das Gerät eingeschaltet, der CE-Speicher entsperrt und das Gerät entsperrt ist der Benutzer nach Erhalt eines OTA-Updates. Der Widerstand gegen Insider-Angriffe muss auch dann wirksam sein, wenn der Angreifer Zugriff auf die übertragenen kryptografischen Signaturschlüssel erhält.

Insbesondere darf der CE-Speicher nicht von einem Angreifer gelesen werden, der das Gerät physisch besitzt und über die folgenden Fähigkeiten und Einschränkungen verfügt:

Fähigkeiten

  • 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.
  • Kann den Betrieb jeglicher Hardware (z. B. eines Anwendungsprozessors oder eines Flash-Speichers) ändern – außer wie im Abschnitt „Einschränkungen“ unten beschrieben. (Eine solche Änderung bringt jedoch sowohl eine Verzögerung von mindestens einer Stunde als auch einen Aus- und Wiedereinschaltvorgang mit sich, der den RAM-Inhalt zerstört.)

Einschränkungen

  • Der Betrieb manipulationssicherer Hardware (z. B. einer Titan M) kann nicht geändert werden.
  • Der RAM des Live-Geräts kann nicht gelesen werden.
  • Die Anmeldeinformationen des Benutzers (PIN, Muster, Passwort) können nicht erraten oder auf andere Weise deren Eingabe veranlasst werden.

Lösung

Das Android 12 RoR-Updatesystem bietet Sicherheit vor sehr raffinierten Angreifern, und zwar während die Passwörter und PINs auf dem Gerät verbleiben – sie werden niemals an Google-Server gesendet oder dort gespeichert. Dies ist eine Übersicht über den Prozess, der sicherstellt, dass die bereitgestellten Sicherheitsstufen einem hardwarebasierten RoR-System auf Geräteebene ähneln:

  • Android wendet kryptografischen Schutz auf die auf einem Gerät gespeicherten Daten an.
  • Alle Daten werden durch Schlüssel geschützt, die in der Trusted Execution Environment (TEE) gespeichert sind.
  • Der TEE gibt die Schlüssel nur dann frei, wenn das laufende Betriebssystem die kryptografische Authentifizierung ( verifizierter Start ) besteht.
  • Der auf Google-Servern ausgeführte RoR-Dienst sichert CE-Daten, indem er ein Geheimnis speichert, das nur für eine begrenzte Zeit abgerufen werden kann. Dies funktioniert im gesamten Android-Ökosystem.
  • Ein durch die PIN eines Benutzers geschützter kryptografischer Schlüssel wird zum Entsperren des Geräts und zum Entschlüsseln des CE-Speichers verwendet.
    • Wenn ein Neustart über Nacht geplant ist, fordert Android den Benutzer zur Eingabe seiner PIN auf 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 erneut mit einem in TEE gespeicherten Schlüssel K_k .
    • Der doppelt verschlüsselte SP wird auf der Festplatte gespeichert und der SP wird aus dem RAM gelöscht. Beide Schlüssel werden frisch generiert und nur für einen Neustart verwendet.
  • Wenn es Zeit für einen Neustart ist, vertraut Android K_s dem Server an. Die Quittung mit K_k wird verschlüsselt , bevor sie auf der Festplatte gespeichert wird.
  • Nach dem Neustart verwendet Android K_k , um die Quittung zu entschlüsseln, und sendet sie 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 Telefon schützen, können zu einem für Sie passenden Zeitpunkt erfolgen: während Sie schlafen.

SIM-PIN-Wiedergabe

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

Eine SIM-Karte mit aktivierter PIN muss nach einem unbeaufsichtigten Neustart außerdem einer nahtlosen PIN-Code-Überprüfung (SIM-PIN-Wiedergabe) unterzogen werden, um die Mobilfunkverbindung wiederherzustellen (erforderlich für Telefonanrufe, SMS-Nachrichten und Datendienste). Die SIM-PIN und die zugehörigen SIM-Karteninformationen (die ICCID und die SIM-Steckplatznummer) werden gemeinsam sicher gespeichert. Die gespeicherte PIN kann erst nach einem erfolgreichen unbeaufsichtigten Neustart abgerufen und zur Verifizierung verwendet werden. Wenn das Gerät gesichert ist, wird die SIM-PIN mit durch die LSKF geschützten Schlüsseln gespeichert. Wenn die PIN der SIM-Karte aktiviert ist, erfordert die Interaktion mit dem RoR-Server eine WLAN-Verbindung für das OTA-Update und serverbasiertes RoR, was die Grundfunktionalität (mit Mobilfunkverbindung) nach dem Neustart gewährleistet.

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

  • Die SIM-Karte wurde entfernt oder zurückgesetzt.
  • Der Benutzer deaktiviert die PIN.
  • Es ist ein nicht von RoR initiierter Neustart aufgetreten.

Die gespeicherte SIM-PIN kann nach dem RoR-initiierten Neustart nur einmal und nur für eine sehr kurze Zeitdauer (20 Sekunden) verwendet werden – sofern die Angaben der SIM-Karte übereinstimmen. Die gespeicherte SIM-PIN verlässt niemals die TelephonyManager-App und kann nicht von externen Modulen abgerufen werden.

Richtlinien zur Umsetzung

In Android 12 sorgen die Multi-Client- und serverbasierten RoR-Funktionen für eine geringere Belastung für Partner, wenn sie OTA-Updates pushen. Notwendige Aktualisierungen können während günstiger Geräteausfallzeiten erfolgen, beispielsweise während der festgelegten Ruhezeiten.

Um sicherzustellen, dass OTA-Updates in solchen Zeiträumen die Benutzer nicht unterbrechen, verwenden Sie den Dunkelmodus, um die Lichtemissionen zu verringern. Lassen Sie dazu den Geräte-Bootloader nach der Zeichenfolge reason unattended suchen. Wenn unattended true ist, versetzen Sie das Gerät in den Dunkelmodus. Beachten Sie, dass es in der Verantwortung jedes OEM liegt, Geräusch- und Lichtemissionen 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-Funktionalität zu implementieren.

Es gibt einen neuen Aufruf im Multi-Client-Flow, 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 veraltet ist.

TelefonieManager

Der OTA-Client ruft die TelephonyManager System-API auf, wenn in Android 12 ein Neustart bevorsteht. Diese API verschiebt alle zwischengespeicherten PIN-Codes vom Status AVAILABLE in den Status REBOOT_READY . Die TelephonyManager System-API ist durch die vorhandene REBOOT Manifest-Berechtigung 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

Um die neue API zu testen, führen Sie 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 lassen sich Implementierungen von RoR HAL in zwei Kategorien einteilen:

  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 Sicherheits-Coprozessor mit eigenem RAM und ROM) unterstützt, muss es zusätzlich Folgendes tun:
    • Sie können einen Neustart der Haupt-CPU erkennen.
    • Verfügen Sie über eine Hardware-Timer-Quelle, die auch nach Neustarts bestehen bleibt. Das heißt, die Enklave muss in der Lage sein, den Neustart zu erkennen und einen vor dem Neustart eingestellten Timer ablaufen zu lassen.
    • Unterstützt das Speichern eines treuhänderischen Schlüssels im RAM/ROM der Enklave, sodass dieser nicht durch Offline-Angriffe wiederhergestellt werden kann. Der RoR-Schlüssel muss so gespeichert werden, dass er von Insidern oder Angreifern nicht wiederhergestellt werden kann.

Standard-RAM-Escrow

AOSP verfügt über eine Implementierung des RoR HAL mit RAM-Persistenz. Damit dies funktioniert, müssen OEMs sicherstellen, dass ihre SoCs die RAM-Persistenz über Neustarts hinweg unterstützen. Einige SoCs sind nicht in der Lage, RAM-Inhalte über einen Neustart hinweg beizubehalten. OEMs wird daher empfohlen, ihre SoC-Partner zu konsultieren, bevor sie diesen Standard-HAL aktivieren. Die kanonische Referenz dazu finden Sie im folgenden Abschnitt.

Ablauf der OTA-Aktualisierung mit RoR

Die OTA-Client-App auf dem Telefon muss über die Berechtigungen Manifest.permission.REBOOT und Manifest.permission.RECOVERY verfügen, um die erforderlichen Methoden zum Implementieren von RoR aufzurufen. Wenn diese Voraussetzung erfüllt ist, folgt der Ablauf einer Aktualisierung diesen Schritten:

  1. Die OTA-Client-App lädt das Update herunter.
  2. Die OTA-Client-App ruft RecoverySystem#prepareForUnattendedUpdate auf, was dazu führt, dass der Benutzer beim nächsten Entsperren auf dem Sperrbildschirm zur Eingabe seiner PIN, seines Musters oder seines Passworts aufgefordert wird.
  3. Der Benutzer entsperrt das Gerät über den Sperrbildschirm und das Gerät ist bereit, das Update anzuwenden.
  4. Die OTA-Client-App ruft RecoverySystem#rebootAndApply auf, was sofort einen Neustart auslöst.

Am Ende dieses Ablaufs wird das Gerät neu gestartet und der RoR-Mechanismus entsperrt den mit Anmeldeinformationen verschlüsselten (CE) Speicher. Für Apps erscheint dies als normale Benutzerentsperrung, sodass sie alle Signale wie ACTION_LOCKED_BOOT_COMPLETED und ACTION_BOOT_COMPLETED erhalten, die sie normalerweise erhalten.

Produktkonfigurationen ändern

Ein Produkt, das als unterstützend für die RoR-Funktion in Android 11 gekennzeichnet ist, muss eine Implementierung des RebootEscrow HAL und die Feature-Marker-XML-Datei enthalten. Die Standardimplementierung funktioniert gut auf Geräten, die einen Warmstart verwenden (wenn die Stromversorgung des DRAM während des Neustarts eingeschaltet bleibt).

Markierung der Escrow-Funktion neu starten

Der Feature-Marker 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-Reboot-Escrow-HAL-Implementierung

Um die Standardimplementierung zu verwenden, müssen Sie 65536 (0x10000) Bytes reservieren. Schreiben Sie diese Bytes niemals in einen nichtflüchtigen Speicher, um sicherzustellen, dass die Sicherheitseigenschaften bestehen bleiben.

Änderungen im Linux-Kernel-Gerätebaum

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

  reserved-memory {
    my_reservation@0x50000000 {
      no-map;
      reg = <0x50000000 0x10000>;
    }
  }

  reboot_escrow@0 {
    compatible = "pmem-region";
    reg = <0x50000000 0x10000>;
  };

Stellen Sie sicher, dass Sie im Blockverzeichnis ein neues Gerät mit einem Namen wie /dev/block/pmem0 (z. B. pmem1 oder pmem2 ) haben.

Device.mk ändert sich

Vorausgesetzt, dass Ihr neues Gerät aus dem vorherigen Schritt den Namen pmem0 hat, müssen Sie sicherstellen, dass 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 diese neuen Einträge zu den 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