Aby zwiększyć zaufanie do aplikacji i usług Google, zobowiązujemy się do umieszczania w dzienniku przejrzystości informacji o każdym pakiecie usług Google. Opublikowaliśmy dziennik przejrzystości, aby publicznie potwierdzić nasze oświadczenia dotyczące tych pakietów (plików APK i APEX).
Model zagrożeń
Systemy przejrzystości mogą służyć do wykrywania ataków na łańcuch dostaw, a tym samym do ich powstrzymywania. Ilustrujemy to kilkoma przykładami.
Załóżmy, że atakujący złośliwie modyfikuje aplikację lub usługę Google, a nawet udaje mu się podpisać ją kluczem podpisywania używanym do dystrybucji w Google Play. Dzięki dziennikowi przejrzystości binarnej każdy, kto otrzyma podejrzany pakiet (APK lub APEX), może użyć go jako dodatkowego, weryfikowalnego źródła prawdy podstawowej, aby sprawdzić autentyczność pakietu. Osoba ta stwierdzi, że Google nie dodało odpowiednich metadanych pakietu do dziennika, i będzie wiedzieć, że nie należy ufać naruszonemu pakietowi.
Ponieważ publikowanie w dzienniku jest procesem oddzielnym od procesu wydawania z podpisywaniem (jak pokazano na schemacie ekosystemu), utrudnia to atakującemu działanie, ponieważ nie wystarczy już tylko naruszyć klucz.
Planujemy też zintegrować ten dziennik z publiczną siecią świadków za pomocą standardowego protokołu świadka, zachęcamy jednak zewnętrzne, niezależne podmioty do monitorowania integralności tego publicznie dostępnego dziennika. Podmioty te mogą potwierdzić, że do dziennika można tylko dodawać wpisy, i zgłaszać wszelkie próby manipulacji.
Istnienie takiego systemu przejrzystości i dodatkowa możliwość wykrywania ataków zniechęca do złośliwych działań. Jeśli pakiet zostanie naruszony, ale użytkownicy będą ufać tylko tym, które znajdują się w dzienniku, naruszony pakiet będzie musiał zostać publicznie ujawniony. Zwiększa to prawdopodobieństwo wykrycia, że istnieje naruszony pakiet, i podjęcia działań w celu usunięcia go z dystrybucji.
Model strony wnoszącej roszczenie
Model strony wnoszącej roszczenie to struktura służąca do definiowania ról i artefaktów w systemie weryfikowalnym. W przypadku przejrzystości aplikacji Google oświadczamy, że hasz pliku pakietu zarejestrowany w tym dzienniku reprezentuje konkretną wersję oficjalnej usługi Google przeznaczonej do publicznego użytku.
- ClaimGoogleApp: (Ja, Google, oświadczam, że
$hashAppjest przeznaczony dla$googleApp), gdzie:$hashAppto hasz kryptograficzny (np. SHA256) pliku pakietu (w tym podzielonych plików APK i pakietów APEX) konkretnej wersji elementu$googleApp.$googleAppto pakiet Androida (APK lub APEX), który stanowi aplikację lub usługę tworzoną i dystrybuowaną przez Google.
Każdy, kto ma kopię $googleApp, może zweryfikować to oświadczenie,
a proces ten opisujemy szczegółowo na
stronie weryfikacji.
Zawartość dziennika
Gdy Google udostępnia nową wersję pliku APK lub pakietu APEX, dodaje odpowiedni wpis do dziennika przejrzystości aplikacji Google.
Każdy wpis w tym dzienniku zawiera 4 metadane:
- Hasz pliku APK lub APEX podpisanego przez Google. Jest to ciąg szesnastkowy skrótu SHA256 całego pliku.
- Opis typu poprzedniego haszu. Jest to ciąg znaków.
- Nazwa pakietu. Jest to ciąg znaków.
- Numer wersji (versionCode) pakietu. Jest to niezerowa liczba całkowita.
Format wpisu logu to konkatenacja 4 informacji z znakiem nowego wiersza (\n), jak pokazano poniżej:
hash\nhash_description\npackage_name\npackage_version\n
Ponieważ usługa Google może być dystrybuowana jako plik APK lub APEX, opis haszu jest ustawiony na SHA256(APK) lub SHA256(APEX). Zapewnia to kompleksowe pokrycie zawartości każdego pliku i ułatwia użytkownikom uzyskanie tego pomiaru.
Schemat ekosystemu
