Wszystkie urządzenia uruchamiane z systemem Android Pie (Android 9) muszą obsługiwać funkcję Verified Boot (Android Verified Boot 2.0), która umożliwia ochronę przed wycofywaniem zmian.
Android Pie (Android 9) właśnie dzisiaj uruchomiłem transmisję na żywo dla Google Pixel, Google Pixel 2 i nawet Niezbędny telefon. O premierze dowiadujemy się jak najwięcej z wywiadów (Google Pixel 3 będzie obsługiwał wyłącznie nawigację gestami!), o Spadek kodu AOSPi wreszcie dokument definicji zgodności (CDD). Pisaliśmy o nowa funkcja dla „ciężkich” aplikacji wcześniej dzisiaj, ale teraz odkryliśmy, że Google zmieniło sformułowanie dotyczące funkcji wprowadzonej w Androidzie Oreo: zabezpieczenie przed cofnięciem. Ta funkcja jest możliwa dzięki Zweryfikowany rozruch systemu Android 2.0 (znany również jako Verified Boot), jednak producenci OEM nie byli zobowiązani do implementowania AVB 2.0 w wersji Oreo. Teraz Google wymaga, aby wszystkie urządzenia uruchamiane z systemem Android Pie obsługiwały funkcję Verified Boot, a co za tym idzie, ochronę przed wycofywaniem zmian.
Ochrona przed wycofaniem w Androidzie Oreo
Istotą tej funkcji jest to, że uniemożliwia uruchomienie telefonu, jeśli wykryje, że wersja urządzenia została obniżona do wcześniejszej, obecnie niezatwierdzonej wersji oprogramowania, która została uznana za niebezpieczną ze względu na bezpieczeństwo słaby punkt. Nieco bardziej technicznym wyjaśnieniem jest to, że struktura danych VBMeta, która przechowuje skrót partycji rozruchowej i hashtree dla partycji systemowych i dostawców, wykorzystuje indeks wycofywania do odrzucania obrazów, które mają starszą wersję wycofania indeks.
Ta funkcja jest dostępna na urządzeniach takich jak Google Pixel 2, Razer Phone i OnePlus 6, ale nie jest dostępna na wielu innych urządzeniach, takich jak Samsung Galaxy S9 (chociaż Samsung oferuje własną formę ochrona przed wycofaniem w Knox.) Teraz Google wprowadza tę funkcję jako obowiązkową dla każdego urządzenia uruchamianego z systemem Android Pie.
Zweryfikowany rozruch w systemie Android Pie
Zgodnie ze zaktualizowanym sformułowaniem w sekcji „Integralność urządzenia” w dokumencie definicji zgodności, urządzenia uruchamiane z systemem Android 9 muszą obsługiwać funkcję Verified Boot.
9.10. Integralność urządzenia
Poniższe wymagania zapewniają przejrzystość stanu integralności urządzenia. Implementacje urządzeń:
- [C-0-1] MUSI poprawnie zgłosić za pomocą metody System API PersistentDataBlockManager.getFlashLockState(), czy stan ich programu ładującego pozwala na flashowanie obrazu systemu. Stan FLASH_LOCK_UNKNOWN jest zarezerwowany dla implementacji urządzeń aktualizujących się z wcześniejszej wersji Androida, w której nie istniała ta nowa metoda systemowego API.
- [C-0-2] MUSI obsługiwać zweryfikowany rozruch w celu zapewnienia integralności urządzenia.
Jeśli implementacje urządzeń zostały już uruchomione bez obsługi funkcji Verified Boot we wcześniejszej wersji Androida i nie mogą dodać obsługi tej funkcji poprzez aktualizację oprogramowania systemowego, MOGĄ zostać zwolnione z wymóg.
...
- [C-1-10] MUSI wdrożyć ochronę przed wycofywaniem zmian dla partycji używanych przez Androida (np. boot, partycje systemowe) i korzystaj z magazynu zabezpieczającego przed manipulacją do przechowywania metadanych używanych do określenia minimalnego dopuszczalnego systemu operacyjnego wersja.
- POWINNO wdrożyć ochronę przed wycofywaniem zmian dla dowolnego komponentu z trwałym oprogramowaniem sprzętowym (np. modemu, kamery) i POWINIEN używać magazynu zabezpieczającego przed manipulacją do przechowywania metadanych wykorzystywanych do określania dopuszczalnego minimum wersja.
Jak widać z dwóch ostatnich zestawów punktorów, należy zwrócić uwagę na jedno zastrzeżenie. Ochrona przed wycofaniem danych jest wymagana w przypadku partycji używanych przez system Android (rozruch, system, dostawca itp.), ale nie w przypadku partycji z trwałym oprogramowaniem sprzętowym (modem, kamera itp.). W pierwszym zestawie partycji wykrywa się i łata większość luk w zabezpieczeniach, więc miło jest widzieć, że ochrona tych partycji jest wymagana. Istnieją jednak exploity atakujące również partycje z trwałym oprogramowaniem sprzętowym, więc nie jesteśmy pewni, dlaczego Google nie wymaga dla nich ochrony przed wycofywaniem zmian.
Starszy członek XDA npjohnsonczłonek zespołu LineageOS spekuluje, że wymagałoby to ochrony przed wycofywaniem zmian na partycjach z trwałym oprogramowaniem sprzętowym wymagają powiązania Secondary Bootloader (SBL) i eXtensible Bootloader (XBL), ponieważ te partycje są montowane wcześniej podczas rozruchu proces. Dla mniejszych producentów OEM byłoby kosztowne wdrożenie niestandardowych XBL pasujących do niestandardowych modemów i innych trwałych partycji, więc być może Google nie stawia tego wymogu, aby ułatwić producentom urządzeń spełnienie najnowszych wymagań CDD.
Jak sprawdzić, czy Twój telefon obsługuje AVB 2.0
Istnieją dwa polecenia powłoki ADB, których możesz użyć, aby sprawdzić, czy Twój telefon obsługuje AVB 2.0.
adb shell
dumpsys package | grep "verified_boot"LUB
adb shell
getprop | grep "avb"Jeśli wyjściem pierwszego polecenia jest „android.software.verified_boot”, wówczas obsługiwany jest AVB 2.0. Jeśli wynik drugiego polecenia pokazuje „[ro.boot.avb_version]” i „[ro.boot.vbmeta.avb_version]” i wyświetla numer wersji każdego z nich, oznacza to, że jest ono obsługiwane.
Zweryfikowany rozruch i rozwój niestandardowy
Android Verified Boot tak naprawdę nie wpływa na większość użytkowników niestandardowej pamięci ROM, chociaż dodaje dodatkową warstwę zabezpieczeń, z którą w niektórych przypadkach trzeba się obejść. Na przykład, flashowanie ogólnego obrazu systemu wymaga wyłączenia AVB. Modyfikowanie niektórych partycji, takich jak dostawca w OnePlus 6, wymaga również wyłączenia AVB, jak się niedawno dowiedziałem. Według npjohnson, odpowiednio zaimplementowany AVB 2.0 umożliwia współpracę niestandardowych obrazów rozruchowych z zablokowanym programem ładującym. Zobaczymy, jak włączenie AVB 2.0 na urządzeniach dostarczanych z Androidem Pie wpłynie na krajobraz, ale mamy nadzieję, że nie spowoduje to sytuacji takich jak niedawny strach przed murowaniem w społeczności Xiaomi Redmi Note 5 Pro. Obowiązkowe AVB 2.0 to po prostu kolejny sposób, w jaki Google może to zrobić poprawić bezpieczeństwo platformy Android, ale naszym zdaniem największą zmianą jest przeróbka umów OEM w celu wymuszenia regularnych poprawek bezpieczeństwa.