Riprendi al riavvio

In Android 11, gli aggiornamenti OTA possono essere applicati utilizzando i meccanismi di aggiornamento A/B o aggiornamento A/B virtuale , combinati con i metodi della classe RecoverySystem . Dopo il riavvio di un dispositivo per applicare un aggiornamento OTA, Resume-on-Reboot (RoR) sblocca l' archiviazione Credential Encrypted (CE) del dispositivo.

Sebbene i partner possano associare questo processo a una funzionalità del sistema OTA che applica gli aggiornamenti quando il dispositivo dovrebbe essere inattivo in Android 11, in Android 12 i partner non necessitano di una funzionalità del sistema OTA aggiuntiva. Il processo RoR offre maggiore sicurezza e praticità agli utenti perché gli aggiornamenti possono essere effettuati durante i tempi di inattività del dispositivo, mentre le funzionalità di aggiornamento multi-client e basate su server di Android 12 insieme forniscono sicurezza del tipo a livello di hardware del dispositivo.

Sebbene sia necessario fornire l'autorizzazione del dispositivo per la funzione android.hardware.reboot_escrow per supportare RoR in Android 11, non è necessario per abilitare la RoR basata su server in Android 12 e versioni successive, perché non usano l'HAL.

fornire le autorizzazioni del dispositivo per la funzione android.hardware.reboot_escrow . Non è necessario eseguire alcuna operazione per abilitare il RoR basato su server in Android 12, perché Android 12 e versioni successive non utilizzano HAL.

Sfondo

A partire da Android 7, Android ha supportato Direct Boot , che consente l'avvio delle app su un dispositivo prima che l'archiviazione CE venga sbloccata dall'utente. L'implementazione del supporto Direct Boot ha fornito agli utenti un'esperienza migliore prima che fosse necessario inserire il Lock Screen Knowledge Factor (LSKF) dopo l'avvio.

RoR consente di sbloccare l'archiviazione CE di tutte le app su un dispositivo, comprese quelle che non supportano l'avvio diretto, quando viene avviato un riavvio a seguito di un aggiornamento OTA. Questa funzione consente agli utenti di ricevere notifiche da tutte le app installate dopo il riavvio.

Modello di minaccia

Un'implementazione di RoR deve garantire che quando un dispositivo cade nelle mani di un utente malintenzionato, è estremamente difficile per l'attaccante recuperare i dati crittografati CE dell'utente, anche se il dispositivo è acceso, l'archiviazione CE è sbloccata e il dispositivo è sbloccato da l'utente dopo aver ricevuto un aggiornamento OTA. La resistenza agli attacchi interni deve essere efficace anche se l'autore dell'attacco ottiene l'accesso alle chiavi di firma crittografiche trasmesse.

In particolare, lo storage CE non deve essere letto da un utente malintenzionato che possiede fisicamente il dispositivo e presenta queste capacità e limitazioni:

Capacità

  • Può utilizzare la chiave di firma di qualsiasi fornitore o azienda per firmare messaggi arbitrari.
  • Può far sì che il dispositivo riceva un aggiornamento OTA.
  • Può modificare il funzionamento di qualsiasi hardware (come un processore di applicazioni o una memoria flash), salvo quanto dettagliato nelle limitazioni di seguito. (Tuttavia, tale modifica comporta sia un ritardo di almeno un'ora, sia un ciclo di alimentazione che distrugge il contenuto della RAM.)

Limitazioni

  • Non è possibile modificare il funzionamento di hardware antimanomissione (ad esempio un Titan M).
  • Impossibile leggere la RAM del dispositivo live.
  • Non è possibile indovinare le credenziali dell'utente (PIN, sequenza, password) o altrimenti farle inserire.

Soluzione

Il sistema di aggiornamento RoR di Android 12 fornisce sicurezza contro aggressori molto sofisticati e lo fa mentre le password e i PIN sul dispositivo rimangono sul dispositivo: non vengono mai inviati o archiviati sui server di Google. Questa è una panoramica del processo che garantisce che i livelli di sicurezza forniti siano simili a un sistema RoR a livello di dispositivo basato su hardware:

  • Android applica protezioni crittografiche ai dati archiviati su un dispositivo.
  • Tutti i dati sono protetti da chiavi archiviate nell'ambiente di esecuzione attendibile (TEE).
  • Il TEE rilascia le chiavi solo se il sistema operativo in esecuzione supera l'autenticazione crittografica ( avvio verificato ).
  • Il servizio RoR in esecuzione sui server di Google protegge i dati CE memorizzando un segreto che può essere recuperato solo per un periodo di tempo limitato . Funziona in tutto l'ecosistema Android.
  • Una chiave crittografica, protetta da un PIN dell'utente, viene utilizzata per sbloccare il dispositivo e decrittografare l'archiviazione CE.
    • Quando è pianificato un riavvio notturno, Android richiede all'utente di inserire il PIN, quindi calcola una password sintetica (SP).
    • Quindi crittografa l'SP due volte: una volta con una chiave K_s memorizzata nella RAM e di nuovo con una chiave K_k memorizzata in TEE.
    • L'SP con doppia crittografia viene archiviato su disco e l'SP viene cancellato dalla RAM. Entrambe le chiavi sono appena generate e utilizzate per un solo riavvio .
  • Quando è il momento di riavviare, Android affida K_s al server. La ricevuta con K_k viene crittografata prima di essere archiviata su disco.
  • Dopo il riavvio, Android utilizza K_k per decrittografare la ricevuta, quindi la invia al server per recuperare K_s .
    • K_k e K_s vengono utilizzati per decrittografare l'SP archiviato su disco.
    • Android utilizza l'SP per sbloccare l'archiviazione CE e consentire il normale avvio dell'app.
    • K_k e K_s vengono scartati.

Gli aggiornamenti che tengono al sicuro il tuo telefono possono avvenire in un momento a tuo piacimento: mentre dormi.

Riproduzione SIM-PIN

In determinate condizioni il codice PIN di una carta SIM viene verificato da una cache, un processo chiamato SIM-PIN replay.

Una scheda SIM con un PIN abilitato deve anche essere sottoposta a una verifica del codice PIN (riproduzione SIM-PIN) dopo un riavvio automatico per ripristinare la connettività cellulare (necessaria per telefonate, messaggi SMS e servizi dati). Il PIN della SIM e le informazioni sulla scheda SIM corrispondenti (l'ICCID e il numero di slot della SIM) sono archiviati in modo sicuro, insieme. Il PIN memorizzato può essere recuperato e utilizzato per la verifica solo dopo un riavvio automatico riuscito. Se il dispositivo è protetto, il PIN della SIM viene memorizzato con chiavi protette da LSKF. Se la SIM ha il PIN abilitato, l'interazione con il server RoR richiede una connessione WiFi per l'aggiornamento OTA e RoR basata su server, che garantisce la funzionalità di base (con connettività cellulare) dopo il riavvio.

Il PIN della SIM viene nuovamente crittografato e memorizzato ogni volta che l'utente lo abilita, lo verifica o lo modifica con successo. Il PIN della SIM viene eliminato se si verifica una delle seguenti condizioni:

  • La SIM viene rimossa o ripristinata.
  • L'utente disabilita il PIN.
  • Si è verificato un riavvio non avviato da RoR.

Il PIN della SIM memorizzato può essere utilizzato solo una volta dopo il riavvio avviato da RoR e solo per un periodo di tempo molto breve (20 secondi) – se i dettagli della scheda SIM corrispondono. Il PIN della SIM memorizzato non esce mai dall'app TelephonyManager e non può essere recuperato da moduli esterni.

Linee guida per l'attuazione

In Android 12, le funzioni RoR multi-client e basate su server forniscono un carico più leggero ai partner quando spingono gli aggiornamenti OTA. Gli aggiornamenti necessari possono verificarsi durante i comodi tempi di inattività del dispositivo, ad esempio durante le ore di sonno designate.

Per garantire che gli aggiornamenti OTA durante tali periodi di tempo non interrompano gli utenti, utilizzare la modalità oscura per mitigare le emissioni di luce. Per fare ciò, fai in modo che il bootloader del dispositivo cerchi il motivo della stringa unattended . Se unattended è true , metti il ​​dispositivo in modalità oscura. Si noti che è responsabilità di ciascun OEM mitigare le emissioni di suoni e luci.

Se stai eseguendo l'aggiornamento ad Android 12 o avviando dispositivi Android 12, non devi fare nulla per implementare la nuova funzionalità RoR.

C'è una nuova chiamata nel flusso multi-client, isPreparedForUnattendedUpdate , mostrato di seguito:

@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
            android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)

Non è necessario implementarlo, perché l'HAL è deprecato a partire da Android 12.

Gestore di telefonia

Il client OTA richiama l'API di sistema di TelephonyManager quando è imminente un riavvio in Android 12. Questa API sposta tutti i codici PIN memorizzati nella cache dallo stato AVAILABLE allo stato REBOOT_READY . L'API di sistema di TelephonyManager è protetta dall'autorizzazione REBOOT Manifest esistente.

 /**
    * 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()

L'API di sistema di TelephonyManager viene utilizzata dagli APK con privilegi.

Test

Per testare la nuova API, esegui questo comando:

    adb shell cmd phone unattended-reboot

Questo comando funziona solo quando la shell è in esecuzione come root ( adb root ).

Solo Android 11

Il resto di questa pagina si applica ad Android 11.

A partire da luglio 2020, le implementazioni di RoR HAL rientrano in due categorie:

  1. Se l'hardware SoC supporta la persistenza della RAM tra i riavvii, gli OEM possono utilizzare l'implementazione predefinita in AOSP ( Default RAM Escrow ).
  2. Se l'hardware del dispositivo o il SoC supporta un'enclave hardware sicura (un coprocessore di sicurezza discreto con la propria RAM e ROM), deve inoltre eseguire le seguenti operazioni:
    • Essere in grado di rilevare un riavvio della CPU principale.
    • Disporre di un'origine timer hardware che persista durante i riavvii. Cioè, l'enclave deve essere in grado di rilevare il riavvio e far scadere un timer impostato prima del riavvio.
    • Supporta l'archiviazione di una chiave depositata nella RAM/ROM dell'enclave in modo che non possa essere recuperata con attacchi offline. Deve archiviare la chiave RoR in modo da rendere impossibile il suo recupero da parte di insider o aggressori.

Impegno RAM predefinito

AOSP ha un'implementazione di RoR HAL che utilizza la persistenza della RAM. Affinché ciò funzioni, gli OEM devono assicurarsi che i loro SoC supportino la persistenza della RAM durante i riavvii. Alcuni SoC non sono in grado di mantenere i contenuti della RAM durante un riavvio, quindi si consiglia agli OEM di consultare i loro partner SoC prima di abilitare questo HAL predefinito. Il riferimento canonico per questo nella sezione seguente.

Flusso di aggiornamento OTA tramite RoR

L'app client OTA sul telefono deve disporre delle autorizzazioni Manifest.permission.REBOOT e Manifest.permission.RECOVERY per chiamare i metodi necessari per implementare RoR. Con quel prerequisito in atto, il flusso di un aggiornamento segue questi passaggi:

  1. L'app client OTA scarica l'aggiornamento.
  2. L'app client OTA chiama RecoverySystem#prepareForUnattendedUpdate che attiva all'utente la richiesta di PIN, sequenza o password sulla schermata di blocco durante lo sblocco successivo.
  3. L'utente sblocca il dispositivo nella schermata di blocco e il dispositivo è pronto per l'applicazione dell'aggiornamento.
  4. L'app client OTA chiama RecoverySystem#rebootAndApply , che attiva immediatamente un riavvio.

Al termine di questo flusso, il dispositivo si riavvia e il meccanismo RoR sblocca lo storage di credenziali crittografate (CE). Per le app, questo appare come un normale sblocco utente, quindi ricevono tutti i segnali, come ACTION_LOCKED_BOOT_COMPLETED e ACTION_BOOT_COMPLETED che fanno normalmente.

Modifica delle configurazioni del prodotto

Un prodotto contrassegnato come supporto della funzionalità RoR in Android 11 deve includere un'implementazione di RebootEscrow HAL e includere il file XML dell'indicatore di funzionalità. L'implementazione predefinita funziona bene sui dispositivi che utilizzano il riavvio a caldo (quando l'alimentazione alla DRAM rimane attiva durante il riavvio).

Riavvia l'indicatore della funzione di deposito a garanzia

Deve essere presente anche il contrassegno di caratteristica:

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

Implementazione HAL dell'impegno di riavvio predefinito

Per utilizzare l'implementazione predefinita, è necessario riservare 65536 (0x10000) byte. Non scrivere mai questi byte nella memoria non volatile per garantire che le proprietà di sicurezza persistano.

Modifiche all'albero dei dispositivi del kernel Linux

Nell'albero dei dispositivi del kernel Linux, devi riservare memoria per una regione pmem . L'esempio seguente mostra che 0x50000000 è riservato:

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

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

Verifica di avere un nuovo dispositivo nella directory dei blocchi con un nome come /dev/block/pmem0 (come pmem1 o pmem2 ).

Device.mk cambia

Supponendo che il tuo nuovo dispositivo del passaggio precedente sia denominato pmem0 , devi assicurarti che le seguenti nuove voci vengano aggiunte a 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
Regole di SELinux

Aggiungi queste nuove voci ai file_contexts del dispositivo:

/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