Riprendi al riavvio

In Android 11, gli aggiornamenti OTA possono essere applicati utilizzando i meccanismi di aggiornamento A/B o di aggiornamento A/B virtuale, in combinazione con i metodi della classe RecoverySystem. Dopo il riavvio di un dispositivo per applicare un aggiornamento OTA, la funzionalità Riprendi al riavvio (RoR) sblocca lo spazio di archiviazione con crittografia CE del dispositivo.

Sebbene i partner possano associare questo processo a una funzionalità di sistema OTA che applica gli aggiornamenti quando si prevede che il dispositivo sia inattivo su Android 11, in Android 12 i partner non hanno bisogno di un'ulteriore funzionalità di sistema OTA. Il processo RoR offre maggiore sicurezza e praticità agli utenti perché gli aggiornamenti possono essere eseguiti durante i tempi di inattività dei dispositivi, mentre le funzionalità di aggiornamento multi-client e basate su server di Android 12 offrono insieme sicurezza del tipo a livello di hardware del dispositivo.

Anche se devi fornire l'autorizzazione del dispositivo affinché la funzionalità android.hardware.reboot_escrow supporti il RoR in Android 11, non è necessario farlo per abilitare il RoR basato su server in Android 12 e versioni successive, perché non viene utilizzato l'HAL.

Premessa

A partire da Android 7, Android supportava l'Avvio diretto, che consente l'avvio delle app su un dispositivo prima che l'utente sblocchi lo spazio di archiviazione CE. L'implementazione del supporto per l'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 lo spazio di archiviazione CE di tutte le app presenti 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

L'implementazione del RoR deve garantire che, quando un dispositivo cade nelle mani di un utente malintenzionato, sia estremamente difficile per l'utente malintenzionato recuperare i dati criptati CE dell'utente, anche se il dispositivo è acceso, lo spazio di archiviazione 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'utente malintenzionato riesce ad accedere alle chiavi di firma di crittografia di trasmissione.

Nello specifico, l'archiviazione CE non deve essere letta da un utente malintenzionato che possiede fisicamente il dispositivo e presenta le seguenti funzionalità e limitazioni:

Funzionalità

  • Puoi usare la chiave di firma di qualsiasi fornitore o azienda per firmare messaggi arbitrari.
  • Il dispositivo potrebbe ricevere un aggiornamento OTA.
  • Può modificare il funzionamento di qualsiasi hardware (ad esempio un processore dell'applicazione o la memoria flash), fatta eccezione per i casi descritti nella sezione Limitazioni di seguito. Tuttavia, tale modifica comporta un ritardo di almeno un'ora e un ciclo di spegnimento e spegnimento che distrugge i contenuti della RAM.

Limitazioni

  • Non può modificare il funzionamento dell'hardware antimanomissione (ad esempio, Titan M).
  • Impossibile leggere la RAM del dispositivo in uso.
  • Non possono indovinare le credenziali dell'utente (PIN, sequenza, password) o altrimenti causarne l'inserimento.

Soluzione

Il sistema di aggiornamento RoR di Android 12 fornisce protezione contro utenti malintenzionati molto sofisticati, così come le password e i PIN sul dispositivo rimangono sul dispositivo e non vengono mai inviati ai server di Google né memorizzati sui server. Questa è una panoramica della procedura che garantisce che i livelli di sicurezza forniti siano simili a quelli di un sistema RoR a livello di dispositivo e basato su hardware:

  • Android applica protezioni crittografiche ai dati archiviati su un dispositivo.
  • Tutti i dati sono protetti da chiavi archiviate nell'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 Google protegge i dati CE archiviando un secret che può essere recuperato solo per un periodo di tempo limitato. Questa opzione funziona in tutto l'ecosistema Android.
  • Una chiave di crittografia, protetta dal PIN di un utente, viene utilizzata per sbloccare il dispositivo e decriptare l'archiviazione CE.
    • Quando viene programmato un riavvio notturno, Android chiede all'utente di inserire il PIN e calcola una password sintetica (SP).
    • Quindi cripta l'SP due volte: una con una chiave K_s archiviata nella RAM e di nuovo con una chiave K_k archiviata in TEE.
    • L'SP con doppia crittografia è archiviato su disco e l'SP viene cancellato dalla RAM. Entrambe le chiavi sono state generate di recente e utilizzate per un solo riavvio.
  • Al momento del riavvio, 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 decriptare la ricevuta, quindi la invia al server per recuperare K_s.
    • K_k e K_s vengono utilizzati per decriptare l'SP archiviato sul disco.
    • Android utilizza l'SP per sbloccare lo spazio di archiviazione CE e consentire il normale avvio dell'app.
    • K_k e K_s vengono eliminati.

Gli aggiornamenti per proteggere il tuo smartphone possono avvenire in un orario comodo per te: mentre dormi.

Riproduzione PIN SIM

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

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

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

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

Il PIN della SIM memorizzato può essere utilizzato solo una volta dopo l'avvio del riavvio RoR e solo per un periodo di tempo molto breve (20 secondi), se i dettagli della scheda SIM corrispondono. Il PIN della SIM memorizzata non viene mai trasferito dall'app TelephonyManager e non può essere recuperato dai moduli esterni.

Linee guida per l'implementazione

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

Per garantire che gli aggiornamenti OTA durante questi periodi di tempo non interrompano gli utenti, utilizza la modalità Buio per mitigare le emissioni di luce. A questo scopo, chiedi al bootloader del dispositivo di cercare il motivo della stringa unattended. Se unattended è true, attiva la modalità Buio nel dispositivo. Tieni presente che è responsabilità di ogni OEM mitigare le emissioni sonore e luminose.

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

C'è una nuova chiamata nel flusso multi-cliente, isPreparedForUnattendedUpdate, mostrata di seguito:

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

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

Gestore telefonia

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 è in esecuzione come root (adb root).

Solo Android 11

Il resto di questa pagina riguarda Android 11.

A partire da luglio 2020, le implementazioni del 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 o il SoC del dispositivo supporta un'enclave hardware sicura (un coprocessore di sicurezza discreto con RAM e ROM proprie), deve:
    • Essere in grado di rilevare un riavvio principale della CPU.
    • Avere un'origine timer hardware che persiste durante i riavvii. Ciò significa che 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 memoria RAM/ROM dell'enclave in modo che non possa essere recuperata con attacchi offline. Deve archiviare la chiave RoR in modo che renda impossibile il recupero per gli addetti ai lavori o per gli utenti malintenzionati.

Deposito a garanzia RAM predefinita

AOSP ha un'implementazione dell'HAL RoR utilizzando la persistenza della RAM. Affinché questo comando funzioni, gli OEM devono garantire che i SoC supportino la persistenza della RAM tra i riavvii. Alcuni SoC non sono in grado di rendere persistenti i contenuti RAM durante un riavvio, quindi consigliamo agli OEM di consultare i propri partner SoC prima di abilitare questo HAL predefinito. Il riferimento canonico a questo argomento 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 il RoR. Con questo prerequisito, il flusso di un aggiornamento segue questi passaggi:

  1. L'app client OTA scarica l'aggiornamento.
  2. L'app client OTA chiama RecoverySystem#prepareForUnattendedUpdate, il che attiva la richiesta all'utente di PIN, sequenza o password per la 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. L'app client OTA chiama RecoverySystem#rebootAndApply e attiva immediatamente un riavvio.

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

Modificare le configurazioni dei prodotti

Un prodotto contrassegnato come supporto della funzionalità RoR in Android 11 deve includere un'implementazione dell'HAL RiavviaEscrow e includere il file XML degli indicatori di 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 funzione di riavvio del deposito a garanzia

L'indicatore degli elementi deve essere presente anche:

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

Implementazione predefinita dell'HAL per il reboot escrow

Per utilizzare l'implementazione predefinita, è necessario prenotare 65.536 (0x10000) byte. Non scrivere mai questi byte nello spazio di archiviazione permanente per garantire che le proprietà di sicurezza rimangano perse.

Modifiche alla struttura ad albero dei dispositivi kernel Linux

Nella struttura dei dispositivi del kernel Linux, devi riservare la memoria per una regione pmem. L'esempio seguente mostra che 0x50000000 è prenotato:

  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 simile a /dev/block/pmem0 (ad esempio pmem1 o pmem2).

Modifiche device.mk

Supponendo che il 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 SELinux

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