L'avvio verificato richiede la verifica crittografica di tutto il codice eseguibile e dei dati che fanno parte della versione di Android che viene avviata prima di essere utilizzata. Ciò include il kernel (caricato dalla partizione di boot ), l'albero dei dispositivi (caricato dalla partizione dtbo ), la partizione di system , la partizione del vendor e così via.
Piccole partizioni, come boot e dtbo , che vengono lette solo una volta vengono in genere verificate caricando l'intero contenuto in memoria e quindi calcolandone l'hash. Questo valore hash calcolato viene quindi confrontato con il valore hash previsto . Se il valore non corrisponde, Android non verrà caricato. Per maggiori dettagli, vedere Flusso di avvio .
Partizioni più grandi che non si adattano alla memoria (come 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 radice dell'albero hash viene calcolato durante il runtime e confrontato con il valore dell'hash radice previsto . Android include il driver dm-verity per verificare partizioni più grandi. Se a un certo punto l'hash di radice calcolato non corrisponde al valore di hash di radice previsto , i dati non vengono utilizzati e Android entra in uno stato di errore. Per maggiori dettagli, vedere danneggiamento di dm-verity .
Gli hash previsti vengono in genere archiviati alla fine o all'inizio di ogni partizione verificata, in una partizione dedicata o in entrambi. Fondamentalmente, questi hash sono firmati (direttamente o indirettamente) dalla radice della fiducia. Ad esempio, l'implementazione AVB supporta entrambi gli approcci, vedere Android Verified Boot per i dettagli.
Protezione antiribaltamento
Anche con un processo di aggiornamento completamente sicuro, è possibile per un exploit del kernel Android non persistente installare manualmente una versione precedente e più vulnerabile di Android, riavviare nella versione vulnerabile e quindi utilizzare tale versione di Android per installare un exploit persistente. Da lì l'attaccante possiede permanentemente il dispositivo e può fare qualsiasi cosa, inclusa la disabilitazione degli aggiornamenti.
La protezione contro questa classe di attacchi è denominata Rollback Protection . La protezione dal rollback viene in genere implementata utilizzando l'archiviazione a prova di manomissione per registrare la versione più recente di Android e rifiutando di avviare Android se è inferiore alla versione registrata. Le versioni vengono in genere monitorate in base alla partizione.
Per maggiori dettagli su come AVB gestisce le protezioni di rollback, vedere AVB README .
Gestione degli errori di verifica
La verifica può non riuscire all'avvio (ad esempio, se l'hash calcolato sulla partizione di boot non corrisponde all'hash previsto) o in fase di esecuzione (ad esempio, se dm-verity rileva un errore di verifica sulla partizione di system ). Se la verifica non riesce all'avvio, il dispositivo non può avviarsi e l'utente finale deve eseguire i passaggi per ripristinare il dispositivo.
Se la verifica non riesce in fase di esecuzione, il flusso è un po' più complicato. Se il dispositivo utilizza dm-verity, dovrebbe essere configurato in modalità di restart . In modalità di restart , se si verifica un errore di verifica, il dispositivo viene immediatamente riavviato con un flag specifico impostato per indicarne il motivo. Il caricatore di avvio dovrebbe notare questo flag e passare a dm-verity per utilizzare la modalità I/O Error ( eio ) e rimanere in questa modalità fino all'installazione di un nuovo aggiornamento.
Quando si avvia in modalità eio , il dispositivo mostra una schermata di errore che informa l'utente che è stato rilevato un danneggiamento e che il dispositivo potrebbe non funzionare correttamente. Lo schermo viene visualizzato fino a quando l'utente non lo chiude. In modalità eio , il driver dm-verity non riavvierà il dispositivo se si verifica un errore di verifica, ma viene restituito un errore EIO e l'applicazione deve gestire l'errore.
L'intento è che il programma di aggiornamento del sistema venga eseguito (in modo che sia possibile installare un nuovo sistema operativo senza errori di danneggiamento) o che l'utente possa ottenere quanti più dati possibile dal dispositivo. Una volta installato il nuovo sistema operativo, il caricatore di avvio rileva il sistema operativo appena installato e torna alla modalità di restart .