Il Boot verificato richiede la verifica tramite crittografia di tutto il codice e i dati eseguibili
che fanno parte della versione di Android che viene avviata prima che venga utilizzata. Sono inclusi il kernel (caricato dalla partizione boot), l'albero del dispositivo (caricato dalla partizione boot), la partizione system, la partizione vendor e così via.dtbo
Le partizioni piccole, come boot e dtbo, che vengono lette solo una volta vengono solitamente verificate caricando l'intero contenuto in memoria e poi calcolandone l'hash. Questo valore hash calcolato viene poi confrontato con il
valore hash previsto. Se il valore non corrisponde, Android non verrà caricato.
Per maggiori dettagli, vedi Flusso di avvio.
Le partizioni più grandi che non rientrano nella memoria (ad esempio i file system) possono utilizzare un albero di hash in cui la verifica è un processo continuo che si verifica quando i dati vengono caricati nella memoria. In questo caso, l'hash principale dell'albero di hash viene calcolato durante il tempo di esecuzione e viene confrontato con il valore dell'hash principale previsto. Android include il driver dm-verity per verificare partizioni più grandi. Se a un certo punto l'hash della radice calcolato non corrisponde al valore hash della radice previsto, i dati non vengono utilizzati e Android entra in uno stato di errore. Per ulteriori dettagli, consulta Corruzione di DM-Verity.
Gli hash previsti vengono in genere memorizzati all'inizio o alla fine di ogni partizione verificata, in una partizione dedicata o in entrambe. È fondamentale che questi hash siano firmati (direttamente o indirettamente) dalla radice della struttura di attendibilità. Ad esempio, l'implementazione di AVB supporta entrambi gli approcci. Per maggiori dettagli, consulta Android Verified Boot.
Protezione rollback
Anche con una procedura di aggiornamento completamente sicura, è possibile che un exploit del kernel Android non persistente installi manualmente una versione precedente e più vulnerabile di Android, riavvii il sistema nella versione vulnerabile e poi utilizzi questa versione di Android per installare un exploit persistente. Da quel momento, l'utente malintenzionato diventa proprietario permanente del dispositivo e può fare qualsiasi cosa, inclusa la disattivazione degli aggiornamenti.
La protezione contro questa classe di attacchi si chiama Rollback Protection. La protezione di rollback viene in genere implementata utilizzando un archiviazione con rilevamento di manomissione per registrare la versione più recente di Android e rifiutarsi di avviare Android se è precedente alla versione registrata. Le versioni solitamente vengono monitorate in base alla partizione.
Per maggiori dettagli su come AVB gestisce le protezioni di rollback, consulta il file README di AVB.
Gestire gli errori di verifica
La verifica può non riuscire all'avvio (ad esempio se l'hash calcolato sulla partizione boot non corrisponde a quello previsto) o in fase di esecuzione (ad esempio se dm-verity rileva un errore di verifica nella partizione boot).system Se la verifica non va a buon fine al momento dell'avvio, il dispositivo non può avviarsi e l'utente finale deve seguire i passaggi per recuperarlo.
Se la verifica non va a buon fine in fase di esecuzione, il flusso è un po' più complicato. Se il dispositivo utilizza dm-verity, deve essere configurato in modalità restart. In
restart, se viene rilevato un errore di verifica, il dispositivo viene
riavviato immediatamente con un flag specifico impostato per indicare il motivo. Il bootloader dovrebbe rilevare questo flag e impostare dm-verity in modo da utilizzare la modalità Errore I/O (eio) e rimanere in questa modalità fino a quando non viene installato un nuovo aggiornamento.
All'avvio in modalità eio, il dispositivo mostra una schermata di errore che informa l'utente che è stata rilevata una corruzione e che il dispositivo potrebbe non funzionare correttamente. La schermata viene visualizzata finché l'utente non la chiude. In
modalità eio, il driver dm-verity non riavvia il dispositivo se viene rilevato un
errore di verifica, ma viene restituito un errore EIO e l'
app deve gestire l'errore.
L'obiettivo è che venga eseguito l'aggiornamento del sistema (in modo da poter installare un nuovo sistema operativo senza errori di danneggiamento) o che l'utente possa recuperare il maggior numero possibile di dati dal dispositivo. Una volta installato il nuovo sistema operativo, il bootloader lo rileva e torna alla modalità restart.