Weryfikacja rozruchu

Zweryfikowany rozruch wymaga kryptograficznej weryfikacji całego kodu wykonywalnego i danych, które są częścią uruchamianej wersji Androida, zanim zostanie on użyty. Obejmuje to jądro (ładowane z partycji boot ), drzewo urządzeń (ładowane z partycji dtbo ), partycję system , partycję vendor i tak dalej.

Małe partycje, takie jak boot i dtbo , które są odczytywane tylko raz, są zazwyczaj weryfikowane przez załadowanie całej zawartości do pamięci, a następnie obliczenie jej skrótu. Ta obliczona wartość skrótu jest następnie porównywana z oczekiwaną wartością skrótu . Jeśli wartość nie jest zgodna, system Android nie zostanie załadowany. Aby uzyskać więcej informacji, zobacz Przepływ rozruchu .

Większe partycje, które nie mieszczą się w pamięci (takie jak systemy plików), mogą używać drzewa skrótów, w którym weryfikacja jest ciągłym procesem zachodzącym podczas ładowania danych do pamięci. W takim przypadku skrót główny drzewa skrótów jest obliczany w czasie wykonywania i porównywany z oczekiwaną wartością skrótu głównego . Android zawiera sterownik dm-verity do weryfikacji większych partycji. Jeśli w pewnym momencie obliczony skrót główny nie pasuje do oczekiwanej wartości skrótu głównego , dane nie są używane, a Android przechodzi w stan błędu. Aby uzyskać więcej informacji, zobacz Korupcja dm-verity .

Oczekiwane skróty są zwykle przechowywane na końcu lub na początku każdej zweryfikowanej partycji, w dedykowanej partycji lub na obu. Co najważniejsze, te skróty są podpisywane (bezpośrednio lub pośrednio) przez rdzeń zaufania. Jako przykład, implementacja AVB obsługuje oba podejścia, zobacz Android Verified Boot , aby uzyskać szczegółowe informacje.

Ochrona przed wycofaniem

Nawet przy całkowicie bezpiecznym procesie aktualizacji możliwe jest, że nietrwały exploit jądra Androida ręcznie zainstaluje starszą, bardziej podatną wersję Androida, zrestartuje wersję podatną na ataki, a następnie użyje tej wersji do zainstalowania trwałego exploita. Stamtąd osoba atakująca jest na stałe właścicielem urządzenia i może robić wszystko, w tym wyłączać aktualizacje.

Ochrona przed atakami tej klasy nosi nazwę Rollback Protection . Ochrona przed wycofywaniem zmian jest zwykle implementowana przy użyciu pamięci masowej umożliwiającej manipulacje w celu rejestrowania najnowszej wersji systemu Android i odmowy uruchomienia systemu Android, jeśli jest on niższy niż wersja nagrana. Wersje są zazwyczaj śledzone na podstawie partycji.

Aby uzyskać więcej informacji o tym, jak AVB obsługuje zabezpieczenia przed wycofywaniem zmian, zobacz AVB README .

Obsługa błędów weryfikacji

Weryfikacja może zakończyć się niepowodzeniem w czasie rozruchu (na przykład, jeśli obliczony skrót na partycji boot nie jest zgodny z oczekiwanym hashem) lub w czasie wykonywania (na przykład, jeśli dm-verity napotka błąd weryfikacji na partycji system ). Jeśli weryfikacja nie powiedzie się w czasie rozruchu, urządzenie nie może się uruchomić, a użytkownik końcowy musi wykonać kroki w celu odzyskania urządzenia.

Jeśli weryfikacja nie powiedzie się w czasie wykonywania, przepływ jest nieco bardziej skomplikowany. Jeśli urządzenie korzysta z dm-verity, należy je skonfigurować w trybie restart . W trybie restart , jeśli zostanie napotkany błąd weryfikacji, urządzenie jest natychmiast restartowane z określoną flagą ustawioną, aby wskazać przyczynę. Program ładujący powinien zauważyć tę flagę i przełączyć dm-verity na tryb I/O Error ( eio ) i pozostać w tym trybie do czasu zainstalowania nowej aktualizacji.

Podczas uruchamiania w trybie eio urządzenie wyświetla ekran błędu informujący użytkownika, że ​​wykryto uszkodzenie i urządzenie może nie działać poprawnie. Ekran jest wyświetlany, dopóki użytkownik go nie odrzuci. W trybie eio sterownik dm-verity nie uruchomi ponownie urządzenia w przypadku napotkania błędu weryfikacji, zamiast tego zwracany jest błąd EIO i aplikacja musi poradzić sobie z błędem.

Intencją jest, aby albo aktualizator systemu działał (aby można było zainstalować nowy system operacyjny bez błędów), albo użytkownik mógł pobrać jak najwięcej swoich danych z urządzenia. Po zainstalowaniu nowego systemu operacyjnego program ładujący zauważa nowo zainstalowany system operacyjny i przełącza się z powrotem do trybu restart .