Verifica dell'avvio

L'avvio verificato richiede la verifica crittografica di tutto il codice eseguibile e dei dati che fanno parte della versione di Android avviata prima di essere utilizzati. 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 calcolando il relativo hash. Questo valore hash calcolato viene quindi confrontato con il valore hash previsto . Se il valore non corrisponde, Android non verrà caricato. Per ulteriori 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 viene confrontato con il valore hash radice previsto . Android include il driver dm-verity per verificare partizioni più grandi. Se a un certo punto l'hash root calcolato non corrisponde al valore hash root previsto , i dati non vengono utilizzati e Android entra in uno stato di errore. Per maggiori dettagli, vedi dm-verity corruzione .

Gli hash previsti vengono generalmente 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 di AVB supporta entrambi gli approcci, vedere Avvio verificato da Android per i dettagli.

Protezione contro il rollback

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 quella versione di Android per installare un exploit persistente. Da lì l'attaccante possiede in modo permanente il dispositivo e può fare qualsiasi cosa, inclusa la disabilitazione degli aggiornamenti.

La protezione contro questa classe di attacchi è denominata protezione rollback . La protezione dal rollback viene in genere implementata utilizzando l'archiviazione antimanomissione 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 rollback, vedere AVB README .

Gestione degli errori di verifica

La verifica può fallire al momento dell'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 fallisce 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à restart , se si verifica un errore di verifica, il dispositivo viene immediatamente riavviato con un flag specifico impostato per indicare il motivo. Il boot loader dovrebbe notare questo flag e commutare dm-verity per utilizzare la modalità I / O Error ( eio ) e rimanere in questa modalità fino a quando non viene installato 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- eio non riavvia 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 venga eseguito il programma di aggiornamento del sistema (quindi è possibile installare un nuovo sistema operativo senza errori di danneggiamento) o che l'utente possa ottenere il maggior numero possibile di dati dal dispositivo. Una volta installato il nuovo sistema operativo, il boot loader rileva il sistema operativo appena installato e torna alla modalità di restart .