Fortsetzen nach Neustart

In Android 11 können OTA-Updates mit dem A/B-Update angewendet werden. oder virtuelles A/B-Update, in Kombination mit RecoverySystem Klassenmethoden. Nachdem ein Gerät neu gestartet wurde, um ein OTA-Update anzuwenden, Mit der Funktion „Bei Neustart“ wird der CE-Speicher (Credential Encrypted Storage) des Geräts entsperrt.

Partner können diesen Prozess zwar mit einer OTA-Systemfunktion kombinieren, aktualisiert, wenn das Gerät voraussichtlich unter Android 11 inaktiv ist, in Android 12-Partner benötigen kein zusätzliches OTA-System . Der RoR-Prozess bietet Nutzern zusätzliche Sicherheit und Komfort, Die Updates können bei Inaktivität durchgeführt werden, während Android 12 Mehrfachkunden- und serverbasierte Update-Funktionen bieten gemeinsam auf Hardwareebene.

Für android.hardware.reboot_escrow musst du jedoch eine Geräteberechtigung erteilen. RoR in Android 11 unterstützt, müssen Sie dies nicht tun, um serverbasierten RoR in Android 12 und höher, da sie verwenden Sie den HAL nicht.

Hintergrund

Ab Android 7 wird Direct Boot von Android unterstützt. wodurch die Apps auf dem Gerät gestartet werden können, bevor der CE-Speicher durch Nutzenden. Die Implementierung von Direct Boot-Support bot den Nutzern eine bessere Erfahrungen vor der Eingabe des Lock Screen Knowledge Factor (LSKF) nach dem Booten.

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

Bedrohungsmodell

Durch die Implementierung von RoR muss sichergestellt werden, dass, wenn ein Gerät in den ist es für den Angreifer extrem schwierig, den CE- verschlüsselter Daten, selbst wenn das Gerät eingeschaltet ist, der CE-Speicher entsperrt ist und Das Gerät wird vom Nutzer nach Erhalt eines OTA-Updates entsperrt. Insider muss auch dann wirksam sein, wenn sich der Angreifer Zugang zu kryptografischer Signaturschlüssel zu senden.

Insbesondere darf der CE-Speicher nicht von einem Angreifer gelesen werden, der sich physisch Geräte mit folgenden Funktionen und Einschränkungen:

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.
  • den Betrieb von Hardware (wie einem Anwendungsprozessor, oder Flash-Speicher) – außer wie im Abschnitt Einschränkungen unten beschrieben. (Eine solche Änderung beinhaltet jedoch eine Verzögerung von mindestens einer Stunde, und das Gerät aus- und wieder einschalten, um RAM-Inhalte zu löschen.

Beschränkungen

  • Der Betrieb von manipulationssicherer Hardware (z. B. einer Titan M).
  • Der RAM des Live-Geräts kann nicht gelesen werden.
  • die Anmeldedaten des Nutzers (PIN, Muster, Passwort) nicht erraten oder anderweitig eingegeben werden müssen.

Lösung

Das Android 12 RoR-Updatesystem bietet Sicherheit raffinierten Hackern zu schützen. PINs bleiben auf dem Gerät und werden nie an Google-Server gesendet oder auf diesen gespeichert. Dieses ist eine Übersicht über den Prozess, mit dem sichergestellt wird, dass die bereitgestellten Sicherheitsniveaus ähnlich wie ein hardwarebasiertes RoR-System auf Geräteebene:

  • 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 gespeichert sind. (TEE)
  • Der TEE gibt die Schlüssel nur frei, wenn das ausgeführte Betriebssystem die Prüfung bestanden hat kryptografischer Authentifizierung (verifizierter Bootmodus)
  • Der auf Google-Servern ausgeführte RoR-Dienst schützt CE-Daten durch Speichern eines Secrets die nur für begrenzte Zeit abgerufen werden können. Das funktioniert auf allen Android-Geräten.
  • Ein kryptografischer Schlüssel, der durch eine Nutzer-PIN geschützt ist, wird zum Entsperren des Geräts verwendet. und entschlüsseln Sie den CE-Speicher.
    • Wenn ein Neustart über Nacht geplant ist, fordert Android den Nutzer dazu auf, seine PIN und berechnet dann ein synthetisches Passwort (SP).
    • Anschließend wird der Dienstanbieter zweimal verschlüsselt: einmal mit dem im RAM gespeicherten Schlüssel K_s und ein weiteres Mal mit dem im RAM gespeicherten Schlüssel. 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. Beleg mit K_k verschlüsselt werden, bevor sie auf dem Laufwerk gespeichert werden.
  • Nach dem Neustart entschlüsselt Android den Beleg über K_k und sendet ihn dann an 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 jederzeit für dich: während du schläfst.

SIM-PIN noch einmal abspielen

Unter bestimmten Umständen wird der PIN-Code einer SIM-Karte aus einem Cache, einen Vorgang namens SIM-PIN-Replay.

Eine SIM-Karte mit einer aktivierten PIN muss ebenfalls einen nahtlosen PIN-Code durchlaufen. Bestätigung (Wiedergabe einer SIM-PIN) nach einem unbeaufsichtigten Neustart zur Wiederherstellung des Mobilfunknetzes Verbindung (erforderlich für Telefonanrufe, SMS und Datendienste). Die SIM-PIN und die entsprechenden Informationen zur SIM-Karte (ICCID und SIM-Steckplatz) Nummer) werden zusammen sicher gespeichert. Die gespeicherte PIN kann abgerufen und verwendet werden erst nach einem erfolgreichen unbeaufsichtigten Neustart aktiviert werden. Wenn das Gerät wird die SIM-PIN zusammen mit Schlüsseln gespeichert, die durch das LSKF geschützt sind. Falls die SIM aktiviert ist, erfordert die Interaktion mit dem RoR-Server eine WLAN-Verbindung für das OTA-Update und den serverbasierten RoR, was die grundlegenden Funktionen (mit Mobilfunkverbindung) nach dem Neustart.

Die PIN für die SIM-Karte wird jedes Mal neu verschlüsselt und gespeichert, wenn der Nutzer sie aktiviert, verifiziert oder modifiziert. Die SIM-PIN wird verworfen, wenn einer der folgenden Punkte zutrifft: tritt auf:

  • 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 durch RoR initiierten Neustart verwendet werden. nur für sehr kurze Zeit (20 Sekunden) – wenn die Details der SIM-Karte Kartenübereinstimmung. Die gespeicherte SIM-PIN verlässt die TelephonyManager App niemals können von externen Modulen nicht abgerufen werden.

Implementierungsrichtlinien

In Android 12 wurden die -Funktionen verringern die Belastung von Partnern, wenn sie OTA-Updates veröffentlichen. Notwendige Updates können während praktischer Ausfallzeiten der Geräte erfolgen, z. B. während festgelegten Schlafzeiten.

Um sicherzustellen, dass OTA-Updates in solchen Zeiträumen die Nutzer nicht unterbrechen, dunklen Modus zur Minderung von Lichtemissionen. Lassen Sie dazu das Gerät Bootloader-Suche nach dem Stringgrund unattended. 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 reduzieren.

Wenn Sie ein Upgrade auf Android 12 durchführen oder Android 12-Geräten müssen Sie nichts unternehmen, die neue RR-Funktion implementieren.

Im Ablauf für Mehrfachkundenkonten gibt es einen neuen Anruf: 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 der HAL seit dem Android 12

Telefonmanager

Der OTA-Client ruft die System-API TelephonyManager auf, wenn ein Neustart bevorsteht. für Android 12. Diese API verschiebt alle im Cache gespeicherten PIN-Codes von den Status AVAILABLE in den Status REBOOT_READY. Das TelephonyManager-System API wird durch das vorhandene REBOOT geschützt Manifestberechtigung.

 /**
    * 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 den Standardimplementierung in AOSP (Default RAM Escrow)
  2. Ob die Hardware oder das SoC des Geräts eine sichere Hardwareenklave (eine separate Sicherheitskoprozessor mit eigenem RAM und ROM), muss er zusätzlich Folgendes: <ph type="x-smartling-placeholder">
      </ph>
    • 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, der Parameter Die Enclave muss den Neustart erkennen und einen Timer ablaufen lassen, der vor dem Ereignis neu starten.
    • Die Speicherung eines treuhänderischen Schlüssels im RAM/ROM der Enklave, damit er nicht durch Offlineangriffe wiederhergestellt werden. Der RoR-Schlüssel muss so gespeichert werden, damit Insider oder Angreifer es nicht wiederherstellen können.

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 RAM-Persistenz unterstützen. über einen Neustart. Einige SoCs können den RAM-Inhalt bei einem Neustart nicht beibehalten, OEMs sollten sich an ihre SoC-Partner wenden, bevor sie diesen Standard-HAL aktivieren. Die kanonische Referenz hierfür finden Sie im folgenden Abschnitt.

Ablauf der OTA-Aktualisierung mit RoR

Die OTA-Client-App auf dem Smartphone muss über Manifest.permission.REBOOT (Manifest.permission.REBOOT). und Manifest.permission.RECOVERY, um die erforderlichen Methoden RR implementieren. Mit dieser Voraussetzung kann führen Sie folgende Schritte aus:

  1. Die OTA-Client-App lädt das Update herunter.
  2. Die OTA-Client-App ruft RecoverySystem#prepareForUnattendedUpdate auf, was wird der Nutzer aufgefordert, seine PIN, sein Muster oder sein Passwort auf der Sperrbildschirm beim nächsten Entsperren wieder aktivieren.
  3. Der Nutzer entsperrt das Gerät über den Sperrbildschirm und das Gerät ist bereit damit das Update angewendet wird.
  4. Die OTA-Client-App ruft RecoverySystem#rebootAndApply auf, was sofort löst einen Neustart aus.

Am Ende dieses Vorgangs startet das Gerät neu und der RoR um den CE-Speicher (Credential Encryption, CE) zu entsperren. Für Apps: wird als normales Entsperren des Nutzers angezeigt, sodass er alle Signale erhält, z. B. AKTION_LOCKED_BOOT_ABGESCHLOSSEN und AKTION_BOOT_ABGESCHLOSSEN wie sie es normalerweise tun.

Produktkonfigurationen ändern

Produkte, die in Android 11 die RoR-Funktion unterstützen, müssen Folgendes enthalten: Implementierung des neustartEscrow-HAL und fügen Sie die XML-Datei für die Funktionsmarkierung ein. Die Standardimplementierung funktioniert gut auf Geräten, die einen warmen Neustart verwenden (wenn der Die Stromversorgung des DRAM bleibt während des Neustarts eingeschaltet.

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. Nie diese Byte in einen nichtflüchtigen Speicher schreiben, um sicherzustellen, dauerhaft.

Ä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 folgendem Namen befindet: /dev/block/pmem0 (z. B. pmem1 oder pmem2).

Änderungen an Device.mk

Wenn das neue Gerät aus dem vorherigen Schritt den Namen pmem0 hat, müssen Sie Achten Sie darauf, 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 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