W Androidzie 14 modyfikowanie certyfikatów systemowych nie jest już dozwolone, nawet jako root

AC Androida 14

Android 14 prezentuje zmiany w zarządzaniu certyfikatami urzędów

Kilka dni temu Twórcy zestawu narzędzi HTTP udostępnili za pośrednictwem posta na blogu, informacja o szczególe które zauważyłeś w sposobie aktualizacji certyfikatów ośrodków certyfikacji (CA) na Androidzie 14.

A twórcy HTTP Toolkit zwrócili uwagę na fakt, że w Androidzie 14 certyfikaty systemowe Nie będą już powiązane z oprogramowaniem sprzętowym, ale będzie dostarczany w oddzielnym pakiecie, który jest aktualizowany poprzez systemowy sklep z aplikacjami „Google Play”.

Kiedy w 2007 roku Android został po raz pierwszy ogłoszony przez stowarzyszenie Open Handset Alliance (pod przewodnictwem Google), jego flagowy projekt był reklamowany jako „otwarta platforma”, „zapewniająca programistom nowy poziom otwartości” i zapewniająca im „pełny dostęp do możliwości i narzędzi telefonów. «.

Od tego czasu przebyliśmy długą drogę, stale odchodząc od otwartości i kontroli urządzeń przez użytkownika na rzecz znacznie bardziej zamkniętego i kontrolowanego przez dostawców świata.

W swojej publikacji deweloperzy podzielić się niektórymi swoimi obawami w ewolucji, a zwłaszcza na drodze, jaką obrał rozwój Androida, który coraz bardziej odchodzi od tego, co obiecywano „platformą otwartą”, ponieważ wraz z upływem czasu na uruchamianie różnych wersji system „bardziej się zamknął” i więcej."

Wspominają o tym w sekcji certyfikaty urzędu „stają się znacznie bardziej rygorystyczne i wydają się uniemożliwiać modyfikację zestawu zaufanych certyfikatów” nawet na w pełni zrootowanych urządzeniach.

Jeśli chodzi o zmianę obsługi certyfikatów w Androidzie 14, Takie podejście „ma” ułatwiać aktualizację certyfikatów i usuwanie certyfikatów z zaatakowanych urzędów certyfikacji, a także uniemożliwi producentom urządzeń manipulowanie listą certyfikatów głównych i uniezależni proces aktualizacji od aktualizacji oprogramowania sprzętowego.

Zamiast katalogu /system/etc/security/cacerts, certyfikaty w systemie Android 14 są one ładowane z katalogu /apex/com.android.conscrypt/cacerts, hostowany w oddzielnym kontenerze APEX (Android Pony EXpress), którego zawartość jest dostarczana za pośrednictwem Google Play, a integralność jest kontrolowana cyfrowo i podpisana przez Google. Dlatego nawet mając pełną kontrolę nad systemem z uprawnieniami root, użytkownik bez dokonywania zmian w platformie nie będzie miał możliwości zmiany zawartości listy certyfikatów systemu.

Kluczowym punktem zwrotnym w tym procesie był system Android 7 (Nougat, wydany w 2016 r.), w którym urzędy certyfikacji urządzeń (CA), które wcześniej były w pełni modyfikowalne przez właściciela telefonu, zostały podzielone na dwie części: lista została dostarczona przez dostawcę systemu operacyjnego. i używane domyślnie przez wszystkie aplikacje na Twoim telefonie, oraz inny zestaw modyfikowalnych przez użytkownika urzędów certyfikacji, nad którymi użytkownicy mogli kontrolować, ale które były używane tylko w przypadku aplikacji, które specjalnie na to wyraziły zgodę (czyli prawie żadnych).

Nowy schemat przechowywanie certyfikatów może powodować trudności dla programistów zajmujących się inżynierią wsteczną, inspekcja ruchu drogowego lub badania oprogramowania sprzętowego i mogą potencjalnie skomplikować rozwój projektów mających na celu opracowanie alternatywnego oprogramowania sprzętowego dla systemu Android, takiego jak GrapheneOS i LineageOS.

Ponieważ nie wszystko jest tak dobre, jak się wydaje i jak już wspomnieliśmy, HTTP Toolkit wyraża swój sprzeciw wobec nowej metody dostarczania, ponieważ nie pozwoli użytkownikowi na wprowadzanie zmian w certyfikatach systemowych, nawet jeśli ma on dostęp root do systemu i mieć pełną kontrolę nad oprogramowaniem sprzętowym.

Zmiana dotyczy wyłącznie certyfikatów CA systemu, Są one domyślnie używane we wszystkich aplikacjach na urządzeniu i nie wpływają na przetwarzanie certyfikatów użytkownika ani na możliwość dodawania dodatkowych certyfikatów dla poszczególnych aplikacji (pozostaje np. możliwość dodania dodatkowych certyfikatów dla przeglądarki).

Jednocześnie problem nie ogranicza się tylko do pakietu z certyfikatami: w miarę przenoszenia funkcjonalności systemu do oddzielnie aktualizowanych pakietów APEX, zwiększa się liczba elementów systemu, których użytkownik nie może kontrolować ani zmieniać, niezależnie od obecności uprawnień roota do urządzenia.

Wreszcie sJeśli chcesz dowiedzieć się więcej na ten temat, możesz sprawdzić szczegóły W poniższym linku.