Przejrzystość modułów magistrali Androida

Aby jeszcze bardziej zwiększyć zaufanie do systemu operacyjnego Android, zobowiązujemy się do umieszczania w naszym dzienniku przejrzystości informacji o każdym module systemu operacyjnego Android (zwanym Mainline), który jest oferowany jako aktualizacja w Google Play. Publikujemy dziennik przejrzystości, aby weryfikować nasze twierdzenia dotyczące tych modułów. Preinstalowane moduły nie są wymienione, ponieważ są już objęte Przejrzystością plików binarnych Pixela.

Model zagrożeń

Systemy przejrzystości mogą służyć do wykrywania, a tym samym do odstraszania ataków na łańcuch dostaw. Ilustrujemy to kilkoma przykładami.

Załóżmy, że haker złośliwie modyfikuje moduł Mainline (który może być plikiem APEX lub APK), a nawet udaje mu się podpisać go kluczem podpisywania używanym do dystrybucji w Google Play. Każda osoba, która otrzyma podejrzany moduł, może wysłać zapytanie do dziennika przejrzystości plików binarnych, aby sprawdzić jego autentyczność. Odkryją, że Google nie dodało do logu odpowiednich metadanych modułu, i będą wiedzieć, że nie mogą ufać naruszonemu modułowi systemu operacyjnego.

Publikowanie w dzienniku jest procesem odrębnym od procesu wydawania z podpisywaniem, co utrudnia atakującemu działanie, ponieważ nie wystarczy już tylko przejęcie klucza.

Planujemy też zintegrować ten dziennik z publiczną siecią świadków za pomocą standardowego protokołu świadków. Zachęcamy jednak zewnętrzne, niezależne podmioty do monitorowania integralności tego publicznie dostępnego dziennika. Te podmioty mogą potwierdzić, że dziennik jest tylko do odczytu, i zgłosić wszelkie próby manipulacji.

Istnienie takiego systemu przejrzystości i dodatkowa możliwość wykrywania ataków zniechęcają do szkodliwych działań. Jeśli moduł systemu operacyjnego zostanie naruszony, ale użytkownicy ufają tylko tym modułom, które znajdują się w dzienniku, naruszony moduł będzie musiał zostać publicznie ujawniony. Zwiększa to prawdopodobieństwo wykrycia zainfekowanych modułów i podjęcia działań w celu usunięcia ich z dystrybucji.

Model roszczącego

Model podmiotu zgłaszającego to struktura służąca do definiowania ról i artefaktów w systemie weryfikowalnym. W przypadku przejrzystości modułów głównych Androida stwierdzamy, że skrót pliku modułu zarejestrowany w tym dzienniku reprezentuje konkretną wersję oficjalnego modułu Androida przeznaczonego do użytku publicznego.

  • ClaimMainlineModule: (I, Google, claim that $hashModule is for $mainlineModule), where:
    • $hashModule to skrót kryptograficzny (np. SHA256) pliku modułu systemu operacyjnego w określonej wersji $mainlineModule.
    • $mainlineModule to APEX lub pakiet Androida (APK), który tworzy moduł systemu operacyjnego tworzony, podpisywany i dystrybuowany przez Google.

Każda osoba, która ma kopię dokumentu $mainlineModule, może zweryfikować to roszczenie. Szczegółowe instrukcje znajdziesz na stronie weryfikacji. Te czynności dotyczą zarówno zwykłych plików APK, jak i modułów Mainline (które mogą być plikami APK lub APEX).

Treść dziennika

Gdy Google udostępni nową wersję modułu Mainline, doda odpowiedni wpis do dziennika przejrzystości modułów Mainline.

Każdy wpis w tym logu zawiera 4 rodzaje metadanych:

  1. Hash pliku APK lub APEX podpisanego modułu głównego Androida. Jest to ciąg szesnastkowy zawierający skrót SHA256 całego pliku.
  2. Opis typu powyższego haszu. To jest ciąg znaków.
  3. Nazwa pakietu modułu. To jest ciąg znaków.
  4. Numer wersji (versionCode) modułu. Jest to liczba całkowita różna od zera.

Format wpisu logu to konkatenacja 4 rodzajów informacji ze znakiem nowego wiersza (\n), jak pokazano poniżej:

hash\nhash_description\npackage_name\npackage_version\n

Moduł główny może być plikiem APK lub APEX, więc opis skrótu może mieć wartość SHA256(APK) lub SHA256(APEX).