Diese Seite wurde von der Cloud Translation API übersetzt.

Resume-on-Reboot

In Android 11 können OTA-Updates mithilfe der A/B-Update- oder virtuellen A/B-Update- Mechanismen in Kombination mit den RecoverySystem- Klassenmethoden 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 in Android 11 voraussichtlich im Leerlauf 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-Funktionalitäten von Android 12 zusammen Sicherheit auf Geräte-Hardware-Ebene bieten.

Obwohl Sie die Geräteberechtigung für die Funktion android.hardware.reboot_escrow bereitstellen müssen, um RoR in Android 11 zu unterstützen, müssen Sie dies nicht tun, um serverbasiertes RoR in Android 12 und höher zu aktivieren, da sie die HAL nicht 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 eine bessere Erfahrung, bevor der Lock Screen Knowledge Factor (LSKF) nach einem Start eingegeben werden musste.

RoR ermöglicht das Entsperren 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 ihren 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 gelangt, 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 wirksam sein, selbst wenn der Angreifer Zugriff auf die gesendeten kryptografischen Signaturschlüssel erhält.

Insbesondere darf CE-Speicher nicht von einem Angreifer gelesen werden, der physisch im Besitz des Geräts ist und über diese 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 jeder Hardware (z. B. eines Anwendungsprozessors oder eines Flash-Speichers) ändern – außer wie in den Einschränkungen unten beschrieben. (Eine solche Änderung beinhaltet jedoch sowohl eine Verzögerung von mindestens einer Stunde als auch einen Einschaltzyklus, der den RAM-Inhalt zerstört.)

Einschrä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.
Kann die Anmeldeinformationen des Benutzers (PIN, Muster, Passwort) nicht erraten oder anderweitig veranlassen, dass sie eingegeben werden.

Lösung

Das Android 12 RoR-Update-System bietet Sicherheit gegen sehr raffinierte Angreifer, und dies, während Passwörter und PINs auf dem Gerät auf dem Gerät verbleiben – sie werden niemals an Google-Server gesendet oder auf diesen gespeichert. Dies ist ein Überblick über den Prozess, der sicherstellt, dass die bereitgestellten Sicherheitsstufen einem hardwarebasierten RoR-System auf Geräteebene ähneln:

Android wendet kryptografischen Schutz auf auf einem Gerät gespeicherte 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 frei, wenn das laufende Betriebssystem die kryptografische Authentifizierung ( verifizierter Bootvorgang ) 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 kryptografischer Schlüssel, der durch die PIN eines Benutzers 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 Benutzer auf, seine PIN einzugeben, und berechnet dann ein synthetisches Passwort (SP).
- Dann verschlüsselt er den SP zweimal: einmal mit einem im RAM gespeicherten Schlüssel K_s und erneut mit einem im 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 neu 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 verwendet, um den auf der Platte gespeicherten SP zu entschlüsseln.
- 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 günstigen 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-Wiedergabe bezeichnet wird.

Eine SIM-Karte mit aktivierter PIN muss außerdem nach einem unbeaufsichtigten Neustart einer nahtlosen PIN-Code-Verifizierung (einer 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 (ICCID und SIM-Steckplatznummer) werden zusammen sicher gespeichert. Die gespeicherte PIN kann nur nach einem erfolgreichen unbeaufsichtigten Neustart abgerufen und zur Verifizierung verwendet werden. Wenn das Gerät gesichert ist, wird die SIM-PIN mit Schlüsseln gespeichert, die durch das LSKF geschützt sind. 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, das die grundlegende Funktionalitä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 wird entfernt oder zurückgesetzt.
Der Benutzer deaktiviert die PIN.
Ein nicht von RoR initiierter Neustart ist aufgetreten.

Die gespeicherte SIM-PIN kann nach dem RoR-initiierten Neustart nur einmal und nur für einen sehr kurzen Zeitraum (20 Sekunden) verwendet werden – wenn die Daten der SIM-Karte übereinstimmen. Die gespeicherte SIM-PIN verlässt die TelefonieManager-App nie und kann nicht von externen Modulen abgerufen werden.

Umsetzungsrichtlinien

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

Um sicherzustellen, dass OTA-Updates während solcher Zeiträume Benutzer nicht unterbrechen, verwenden Sie den Dunkelmodus, um Lichtemissionen zu mindern. Lassen Sie dazu den Geräte-Bootloader nach der Zeichenfolge reason unattended suchen. Wenn unattended true ist, versetzen Sie das Gerät in den dunklen Modus. Beachten Sie, dass es in der Verantwortung jedes OEM liegt, Geräusch- und Lichtemissionen zu mindern.

Wenn Sie entweder auf Android 12 aktualisieren oder Android 12-Geräte starten, müssen Sie nichts tun, um die neue RoR-Funktionalität zu implementieren.

Es gibt einen neuen Aufruf im Multi-Client-Flow, isPreparedForUnattendedUpdate , wie unten gezeigt:

@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 ab Android 12 veraltet ist.

TelefonieManager

Der OTA-Client ruft die TelephonyManager System-API auf, wenn ein Neustart in Android 12 bevorsteht. Diese API verschiebt alle zwischengespeicherten PIN-Codes vom Zustand AVAILABLE in den Zustand 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 fallen Implementierungen von RoR HAL in zwei Kategorien:

Wenn die SoC-Hardware RAM-Persistenz über Neustarts hinweg unterstützt, können OEMs die Standardimplementierung in AOSP ( Default RAM Escrow ) verwenden.
Wenn die Gerätehardware oder der SoC eine sichere Hardware-Enklave (einen diskreten Sicherheits-Coprozessor mit eigenem RAM und ROM) unterstützt, muss er zusätzlich Folgendes tun:
- In der Lage sein, einen Haupt-CPU-Neustart zu erkennen.
- Haben Sie eine Hardware-Timer-Quelle, die über Neustarts hinweg bestehen bleibt. Das heißt, die Enklave muss in der Lage sein, den Neustart zu erkennen und einen vor dem Neustart gesetzten Zeitgeber ablaufen zu lassen.
- Unterstützen Sie das Speichern eines treuhänderisch hinterlegten Schlüssels im RAM/ROM der Enklave, sodass er nicht durch Offline-Angriffe wiederhergestellt werden kann. Es muss den RoR-Schlüssel so speichern, dass es für Insider oder Angreifer unmöglich ist, ihn wiederzuerlangen.

Standard-RAM-Escrow

AOSP hat eine Implementierung des RoR HAL mit RAM-Persistenz. Damit dies funktioniert, müssen OEMs sicherstellen, dass ihre SoCs RAM-Persistenz über Neustarts hinweg unterstützen. Einige SoCs sind nicht in der Lage, RAM-Inhalte über einen Neustart hinweg beizubehalten, daher wird OEMs empfohlen, sich an ihre SoC-Partner zu wenden, bevor sie diese Standard-HAL aktivieren. Die kanonische Referenz dazu 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 eines Updates diesen Schritten:

Die OTA-Client-App lädt das Update herunter.
Die OTA-Client-App ruft RecoverySystem#prepareForUnattendedUpdate auf, wodurch der Benutzer beim nächsten Entsperren auf dem Sperrbildschirm zur Eingabe seiner PIN, seines Musters oder seines Kennworts aufgefordert wird.
Der Benutzer entsperrt das Gerät auf dem Sperrbildschirm und das Gerät ist bereit, das Update anzuwenden.
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 Speicher (CE). 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 tun.

Ändern von Produktkonfigurationen

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

Escrow-Funktionsmarker neu starten

Die Feature-Markierung 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 den standardmäßigen Neustart

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 Gerätebaum des Linux-Kernels

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

  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

Angenommen, Ihr neues Gerät aus dem vorherigen Schritt heißt pmem0 , 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 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

Hintergrund

Bedrohungsmodell

Insbesondere darf CE-Speicher nicht von einem Angreifer gelesen werden, der physisch im Besitz des Geräts ist und über diese 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 jeder Hardware (z. B. eines Anwendungsprozessors oder eines Flash-Speichers) ändern – außer wie in den Einschränkungen unten beschrieben. (Eine solche Änderung beinhaltet jedoch sowohl eine Verzögerung von mindestens einer Stunde als auch einen Einschaltzyklus, der den RAM-Inhalt zerstört.)

Einschrä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.
Kann die Anmeldeinformationen des Benutzers (PIN, Muster, Passwort) nicht erraten oder anderweitig veranlassen, dass sie eingegeben werden.

Lösung

Android wendet kryptografischen Schutz auf auf einem Gerät gespeicherte 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 frei, wenn das laufende Betriebssystem die kryptografische Authentifizierung ( verifizierter Bootvorgang ) 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 kryptografischer Schlüssel, der durch die PIN eines Benutzers 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 Benutzer auf, seine PIN einzugeben, und berechnet dann ein synthetisches Passwort (SP).
- Dann verschlüsselt er den SP zweimal: einmal mit einem im RAM gespeicherten Schlüssel K_s und erneut mit einem im 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 neu 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 verwendet, um den auf der Platte gespeicherten SP zu entschlüsseln.
- 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 günstigen 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-Wiedergabe bezeichnet wird.

Die SIM-Karte wird entfernt oder zurückgesetzt.
Der Benutzer deaktiviert die PIN.
Ein nicht von RoR initiierter Neustart ist aufgetreten.

Umsetzungsrichtlinien

Wenn Sie entweder auf Android 12 aktualisieren oder Android 12-Geräte starten, müssen Sie nichts tun, um die neue RoR-Funktionalität zu implementieren.

Es gibt einen neuen Aufruf im Multi-Client-Flow, isPreparedForUnattendedUpdate , wie unten gezeigt:

@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 ab Android 12 veraltet ist.

TelefonieManager

 /**
    * 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 fallen Implementierungen von RoR HAL in zwei Kategorien:

Wenn die SoC-Hardware RAM-Persistenz über Neustarts hinweg unterstützt, können OEMs die Standardimplementierung in AOSP ( Default RAM Escrow ) verwenden.
Wenn die Gerätehardware oder der SoC eine sichere Hardware-Enklave (einen diskreten Sicherheits-Coprozessor mit eigenem RAM und ROM) unterstützt, muss er zusätzlich Folgendes tun:
- In der Lage sein, einen Haupt-CPU-Neustart zu erkennen.
- Haben Sie eine Hardware-Timer-Quelle, die über Neustarts hinweg bestehen bleibt. Das heißt, die Enklave muss in der Lage sein, den Neustart zu erkennen und einen vor dem Neustart gesetzten Zeitgeber ablaufen zu lassen.
- Unterstützen Sie das Speichern eines treuhänderisch hinterlegten Schlüssels im RAM/ROM der Enklave, sodass er nicht durch Offline-Angriffe wiederhergestellt werden kann. Es muss den RoR-Schlüssel so speichern, dass es für Insider oder Angreifer unmöglich ist, ihn wiederzuerlangen.

Standard-RAM-Escrow

Ablauf der OTA-Aktualisierung mit RoR

Die OTA-Client-App lädt das Update herunter.
Die OTA-Client-App ruft RecoverySystem#prepareForUnattendedUpdate auf, wodurch der Benutzer beim nächsten Entsperren auf dem Sperrbildschirm zur Eingabe seiner PIN, seines Musters oder seines Kennworts aufgefordert wird.
Der Benutzer entsperrt das Gerät auf dem Sperrbildschirm und das Gerät ist bereit, das Update anzuwenden.
Die OTA-Client-App ruft RecoverySystem#rebootAndApply auf, was sofort einen Neustart auslöst.

Ändern von Produktkonfigurationen

Escrow-Funktionsmarker neu starten

Die Feature-Markierung 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 den standardmäßigen Neustart

Änderungen im Gerätebaum des Linux-Kernels

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

  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

Angenommen, Ihr neues Gerät aus dem vorherigen Schritt heißt pmem0 , 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 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

Hintergrund

Bedrohungsmodell

Insbesondere darf CE-Speicher nicht von einem Angreifer gelesen werden, der physisch im Besitz des Geräts ist und über diese 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 jeder Hardware (z. B. eines Anwendungsprozessors oder eines Flash-Speichers) ändern – außer wie in den Einschränkungen unten beschrieben. (Eine solche Änderung beinhaltet jedoch sowohl eine Verzögerung von mindestens einer Stunde als auch einen Einschaltzyklus, der den RAM-Inhalt zerstört.)

Einschrä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.
Kann die Anmeldeinformationen des Benutzers (PIN, Muster, Passwort) nicht erraten oder anderweitig veranlassen, dass sie eingegeben werden.

Lösung

Android wendet kryptografischen Schutz auf auf einem Gerät gespeicherte 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 frei, wenn das laufende Betriebssystem die kryptografische Authentifizierung ( verifizierter Bootvorgang ) 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 kryptografischer Schlüssel, der durch die PIN eines Benutzers 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 Benutzer auf, seine PIN einzugeben, und berechnet dann ein synthetisches Passwort (SP).
- Dann verschlüsselt er den SP zweimal: einmal mit einem im RAM gespeicherten Schlüssel K_s und erneut mit einem im 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 neu 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 verwendet, um den auf der Platte gespeicherten SP zu entschlüsseln.
- 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 günstigen 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-Wiedergabe bezeichnet wird.

Die SIM-Karte wird entfernt oder zurückgesetzt.
Der Benutzer deaktiviert die PIN.
Ein nicht von RoR initiierter Neustart ist aufgetreten.

Umsetzungsrichtlinien

Wenn Sie entweder auf Android 12 aktualisieren oder Android 12-Geräte starten, müssen Sie nichts tun, um die neue RoR-Funktionalität zu implementieren.

Es gibt einen neuen Aufruf im Multi-Client-Flow, isPreparedForUnattendedUpdate , wie unten gezeigt:

@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 ab Android 12 veraltet ist.

TelefonieManager

 /**
    * 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 fallen Implementierungen von RoR HAL in zwei Kategorien:

Wenn die SoC-Hardware RAM-Persistenz über Neustarts hinweg unterstützt, können OEMs die Standardimplementierung in AOSP ( Default RAM Escrow ) verwenden.
Wenn die Gerätehardware oder der SoC eine sichere Hardware-Enklave (einen diskreten Sicherheits-Coprozessor mit eigenem RAM und ROM) unterstützt, muss er zusätzlich Folgendes tun:
- In der Lage sein, einen Haupt-CPU-Neustart zu erkennen.
- Haben Sie eine Hardware-Timer-Quelle, die über Neustarts hinweg bestehen bleibt. Das heißt, die Enklave muss in der Lage sein, den Neustart zu erkennen und einen vor dem Neustart gesetzten Zeitgeber ablaufen zu lassen.
- Unterstützen Sie das Speichern eines treuhänderisch hinterlegten Schlüssels im RAM/ROM der Enklave, sodass er nicht durch Offline-Angriffe wiederhergestellt werden kann. Es muss den RoR-Schlüssel so speichern, dass es für Insider oder Angreifer unmöglich ist, ihn wiederzuerlangen.

Standard-RAM-Escrow

Ablauf der OTA-Aktualisierung mit RoR

Die OTA-Client-App lädt das Update herunter.
OTA client app calls to RecoverySystem#prepareForUnattendedUpdate which triggers the user to be prompted for their PIN, pattern, or password on the lock screen during the next unlock.
The user unlocks the device at the lockscreen, and the device is ready to have the update applied.
OTA client app calls to RecoverySystem#rebootAndApply , which immediately triggers a reboot.

At the end of this flow, the device reboots and the RoR mechanism unlocks the credential encrypted (CE) storage. To apps, this appears as a normal user unlock, so they receive all the signals, such as ACTION_LOCKED_BOOT_COMPLETED and ACTION_BOOT_COMPLETED that they normally do.

Modifying product configurations

A product marked as supporting the RoR feature in Android 11 must include an implementation of the RebootEscrow HAL and include the feature marker XML file. The default implementation works well on devices that use warm reboot (when the power to DRAM remains on during reboot).

Reboot escrow feature marker

The feature marker must also be present:

PRODUCT_COPY_FILES += \
    frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml

Default reboot escrow HAL implementation

To use the default implementation, you must reserve 65536 (0x10000) bytes. Never write these bytes to non-volatile storage to ensure that the security properties persist.

Linux kernel device tree changes

In the Linux kernel's device tree, you must reserve memory for a pmem region. The following example shows 0x50000000 being reserved:

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

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

Verify that you have a new device in the block directory with a name like /dev/block/pmem0 (such as pmem1 or pmem2 ).

Device.mk changes

Assuming that your new device from the previous step is named pmem0 , you must ensure the following new entries get added to vendor/<oem>/<product>/device.mk :

# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
    ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
    android.hardware.rebootescrow-service.default

SELinux rules

Add these new entries to the device's file_contexts :

/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