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 lo spazio di archiviazione con crittografia delle credenziali (CE) del dispositivo.

Sebbene i partner possano abbinare questa procedura a una funzionalità di sistema OTA che applica gli aggiornamenti quando il dispositivo è inattivo in Android 11, in Android 12 i partner non hanno bisogno di un'ulteriore funzionalità di sistema OTA. La procedura RoR offre maggiore sicurezza e praticità agli utenti perché gli aggiornamenti possono essere eseguiti durante i periodi di inattività del dispositivo, mentre le funzionalità di aggiornamento multi-client e basate su server di Android 12 forniscono insieme una sicurezza di tipo hardware per il dispositivo.

Sebbene tu debba fornire l'autorizzazione del dispositivo per la funzionalità android.hardware.reboot_escrow per supportare RoR in Android 11, non devi farlo per attivare RoR basato su server in Android 12 e versioni successive, perché non utilizzano l'HAL.

Sfondo

A partire da Android 7, Android supporta l'avvio diretto, che consente alle app su un dispositivo di avviarsi prima che l'utente sblocchi lo spazio di archiviazione CE. L'implementazione del supporto dell'avvio diretto ha offerto agli utenti un'esperienza migliore prima che fosse necessario inserire il fattore di conoscenza della schermata di blocco (LSKF) dopo l'avvio.

RoR consente di sbloccare l'archiviazione CE di tutte le app su un dispositivo, incluse quelle che non supportano l'avvio diretto, quando viene avviato un riavvio in seguito a un aggiornamento OTA. Questa funzionalità 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 malintenzionato, sia estremamente difficile per quest'ultimo recuperare i dati criptati con CE dell'utente, anche se il dispositivo è acceso, l'archivio CE è sbloccato e il dispositivo viene sbloccato dall'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 crittografica di trasmissione.

Nello specifico, l'archivio CE non deve essere letto da un malintenzionato che ha fisicamente il dispositivo e presenta le seguenti funzionalità e limitazioni:

Funzionalità

  • Può utilizzare la chiave di firma di qualsiasi fornitore o azienda per firmare messaggi arbitrari.
  • Può causare la ricezione di un aggiornamento OTA da parte del dispositivo.
  • Può modificare il funzionamento di qualsiasi hardware (ad esempio un processore di applicazioni o una memoria flash), ad eccezione di quanto descritto in Limitazioni di seguito. Tuttavia, questa modifica comporta un ritardo di almeno un'ora e un ciclo di accensione che distrugge i contenuti della RAM.

Limitazioni

  • Non è possibile modificare il funzionamento dell'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 far sì che vengano inserite.

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 memorizzati sui server di Google. Di seguito è riportata una panoramica del processo che garantisce che i livelli di sicurezza forniti siano simili a un sistema RoR basato su hardware a livello di dispositivo:

  • Android applica protezioni crittografiche ai dati memorizzati su un dispositivo.
  • Tutti i dati sono protetti da chiavi archiviate nel Trusted Execution Environment (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 secret che può essere recuperato solo per un periodo di tempo limitato. Questa funzionalità è disponibile in tutto l'ecosistema Android.
  • Una chiave crittografica, protetta dal PIN di un utente, viene utilizzata per sbloccare il dispositivo e decriptare lo spazio di archiviazione CE.
    • Quando viene pianificato un riavvio notturno, Android chiede all'utente di inserire il PIN, quindi calcola una password sintetica (SP).
    • Dopodiché, cripta il SP due volte: una volta con una chiave K_s archiviata nella RAM e una seconda volta con una chiave K_k archiviata nel TEE.
    • La SP con doppia crittografia viene archiviata su disco e la SP viene cancellata dalla RAM. Entrambe le chiavi vengono generate di recente e utilizzate per un solo riavvio.
  • Quando è il momento di riavviare, Android affida K_s al server. La ricevuta con K_k viene criptata 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 decriptare il SP memorizzato sul disco.
    • Android utilizza l'SP per sbloccare lo spazio di archiviazione CE e consentire l'avvio normale dell'app.
    • K_k e K_s vengono eliminati.

Gli aggiornamenti che proteggono il tuo smartphone possono essere eseguiti in un momento per te comodo: mentre dormi.

Ripetizione del PIN della SIM

In determinate condizioni, il codice PIN di una scheda SIM viene verificato da una cache, una procedura chiamata replay del PIN della SIM.

Una scheda SIM con un PIN abilitato deve anche essere sottoposta a una verifica del codice PIN senza interruzioni (una ripetizione del PIN della SIM) dopo un riavvio automatico per ripristinare la connettività cellulare (necessaria per chiamate, SMS e servizi dati). Il PIN della SIM e le informazioni corrispondenti della scheda SIM (ICCID e numero dello slot SIM) vengono 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 il PIN della SIM è abilitato, l'interazione con il server RoR richiede una connessione Wi-Fi per l'aggiornamento OTA e RoR basato su server, che garantisce la funzionalità di base (con connettività cellulare) dopo il riavvio.

Il PIN della SIM viene nuovamente criptato e memorizzato ogni volta che l'utente lo attiva, lo verifica o lo modifica. Il PIN della SIM viene eliminato se si verifica una delle seguenti situazioni:

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

Il PIN della SIM memorizzato può essere utilizzato una sola 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'implementazione

In Android 12, le funzioni RoR multiclient e basate su server forniscono un carico più leggero ai partner quando eseguono il push degli aggiornamenti OTA. Gli aggiornamenti necessari possono essere eseguiti durante i tempi di inattività del dispositivo, ad esempio durante le ore di sonno designate.

Per assicurarti che gli aggiornamenti OTA durante questi periodi non interrompano gli utenti, utilizza la modalità Buio per ridurre le emissioni di luce. Per farlo, fai in modo che il bootloader del dispositivo cerchi la stringa reason unattended. Se unattended è true, metti il dispositivo in modalità Buio. Tieni presente che è responsabilità di ogni OEM mitigare le emissioni sonore e luminose.

Se esegui l'upgrade ad Android 12 o avvii dispositivi Android 12, non devi fare nulla per implementare la nuova funzionalità RoR.

Nel flusso multicliente è presente una nuova chiamata, isPreparedForUnattendedUpdate, mostrata di seguito:

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

Non devi implementarlo perché l'HAL è ritirato a partire da Android 12.

TelephonyManager

Il client OTA richiama l'API di sistema 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 TelephonyManager è protetta dall'autorizzazione Manifest REBOOT 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 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 viene eseguita come root (adb root).

Solo Android 11

Il resto della 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 durante 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 sicuro (un coprocessore di sicurezza discreto con RAM e ROM proprie), deve inoltre:
    • Essere in grado di rilevare un riavvio della CPU principale.
    • Avere un'origine timer hardware che persiste dopo i riavvii. ovvero 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 di deposito nella RAM/ROM dell'enclave in modo che non possa essere recuperata con attacchi offline. Deve memorizzare la chiave RoR in modo da rendere impossibile il recupero da parte di addetti ai lavori o malintenzionati.

Escrow RAM predefinito

AOSP ha un'implementazione dell'HAL RoR che utilizza la persistenza della RAM. Affinché questa funzionalità 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 dopo un riavvio, pertanto i produttori OEM sono invitati a consultare i partner SoC prima di attivare questo HAL predefinito. Il riferimento canonico per questo nella sezione seguente.

Flusso di aggiornamento OTA utilizzando RoR

L'app client OTA sullo smartphone deve disporre delle autorizzazioni Manifest.permission.REBOOT e Manifest.permission.RECOVERY per chiamare i metodi necessari per implementare RoR. Una volta soddisfatto questo prerequisito, il flusso di un aggiornamento segue questi passaggi:

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

Al termine di questo flusso, il dispositivo si riavvia e il meccanismo RoR sblocca l'archivio delle credenziali criptate (CE). Per le app, questo viene visualizzato come un normale sblocco dell'utente, quindi ricevono tutti gli indicatori, come ACTION_LOCKED_BOOT_COMPLETED e ACTION_BOOT_COMPLETED che normalmente ricevono.

Modificare le configurazioni dei prodotti

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

Indicatore della funzionalità di riavvio dell'escrow

Deve essere presente anche il marcatore della funzionalità:

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 di escrow di riavvio predefinito

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

Modifiche al Device Tree del kernel Linux

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

  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 (ad esempio pmem1 o pmem2).

Modifiche a Device.mk

Supponendo che il nuovo dispositivo del passaggio precedente si chiami 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 SELinux

Aggiungi queste nuove voci a 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