L'Avvio verificato richiede la verifica crittografica di tutto il codice eseguibile e dei dati che fanno parte della versione di Android in fase di avvio prima che vengano utilizzati. Sono inclusi il kernel (caricato dalla partizione boot), il Device Tree (caricato dalla partizione dtbo), la partizione system, la partizione vendor e così via.
Le partizioni di piccole dimensioni, come boot e dtbo, che vengono lette una sola volta, vengono in genere verificate caricando l'intero contenuto in memoria e calcolandone l'hash. Questo valore hash calcolato viene quindi confrontato con il valore hash previsto. Se il valore non corrisponde, Android non viene 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 hash in cui la verifica è un processo continuo che si verifica quando i dati vengono caricati in memoria. In questo caso, l'hash della radice dell'albero hash viene calcolato durante il runtime e viene confrontato con il valore hash della radice previsto. Android include il driver dm-verity per verificare le 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 maggiori dettagli, vedi Corruzione di dm-verity.
Gli hash previsti vengono in genere memorizzati alla fine o all'inizio di ogni partizione verificata, in una partizione dedicata o in entrambe. È fondamentale che questi hash siano firmati (direttamente o indirettamente) dalla radice di attendibilità. Ad esempio, l'implementazione di AVB supporta entrambi gli approcci. Per maggiori dettagli, vedi Avvio verificato di Android.
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, esegua il riavvio nella versione vulnerabile e poi utilizzi quella versione di Android per installare un exploit persistente. A questo punto, l'aggressore possiede in modo permanente il dispositivo e può fare qualsiasi cosa, inclusa la disattivazione degli aggiornamenti.
La protezione da questa classe di attacchi è chiamata protezione rollback. La protezione rollback viene in genere implementata utilizzando l'archiviazione a prova di manomissione per registrare la versione più recente di Android e rifiutare l'avvio di Android se è inferiore alla versione registrata. Le versioni vengono in genere monitorate per partizione.
Per maggiori dettagli su come AVB gestisce le protezioni rollback, vedi il file README di AVB .
Gestire gli errori di verifica
La verifica può non riuscire al momento dell'avvio (ad esempio, se l'hash calcolato sulla partizione boot non corrisponde all'hash previsto) o durante il runtime (ad esempio, se dm-verity rileva un errore di verifica sulla partizione system). Se la verifica non riesce al momento dell'avvio, il dispositivo non può essere avviato e l'utente finale deve seguire i passaggi per recuperarlo.
Se la verifica non riesce durante il runtime, il flusso è un po' più complicato. Se il dispositivo utilizza dm-verity, deve essere configurato in modalità restart. In modalità restart, se viene rilevato un errore di verifica, il dispositivo viene riavviato immediatamente con un flag specifico impostato per indicare il motivo. Il bootloader deve notare questo flag e passare dm-verity all'utilizzo della modalità di errore di I/O (eio) e rimanere in questa modalità fino all'installazione di un nuovo aggiornamento.
Quando viene avviato 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'intento è che venga eseguito l'aggiornamento del sistema (in modo che possa essere installato un nuovo sistema operativo senza errori di corruzione) 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.