Dziennik przejrzystości modułów magistrali Androida

Dziennik przejrzystości modułów Mainline w Androidzie korzysta z weryfikowalnych struktur danych, aby zapewnić integralność modułów Mainline.

Użyteczność dzienników przejrzystości została potwierdzona przez projekty takie jak Pixel Binary Transparency i Certificate Transparency.

Dzienniki przejrzystości są oparte na drzewach Merkle. Na tej stronie zakłada się ogólną znajomość drzew Merkle i przejrzystości binarnej. Więcej informacji o drzewach Merkle znajdziesz w artykule Weryfikowalne struktury danych, a o działaniach związanych z przejrzystością binarną w Androidzie – na stronie głównej.

Implementacja dziennika

Dziennik przejrzystości modułów Mainline w Androidzie jest implementowany za pomocą Tessera i jest zgodny ze specyfikacją tlog-tiles z wysokością kafelka równą 8 (każdy kafelek lub pakiet zawiera maksymalnie 28 = 256 elementów).

Główny katalog zawartości dziennika jest dostępny pod adresem https://gstatic.com/android/binary_transparency/mainline/2026/02/tile/entries/.

Główny katalog zawartości kafelków jest dostępny pod adresem https://gstatic.com/android/binary_transparency/mainline/2026/02/tile/.

Pamiętaj, że te adresy URL nie są standardowymi stronami internetowymi. Zamiast tego do wpisów w dzienniku w jego podkatalogach należy uzyskiwać dostęp programowo za pomocą narzędzi takich jak Tessera lub biblioteka Golang SumDB Tlog.

  • Kafelki drzewa: skróty wewnętrznych i liściowych węzłów drzewa Merkle są dostępne pod adresem tile/<level>/<path> (np. tile/0/000, tile/1/000).
  • Pakiety wpisów: ładunki liści dziennika są uporządkowane w pakiety wpisów pod adresem tile/entries/<path> (np. tile/entries/000, tile/entries/001), a każdy pakiet zawiera do 256 połączonych wpisów.

Opis zawartości poszczególnych wpisów znajdziesz w artykule Zawartość dziennika.

Główny skrót drzewa Merkle dziennika, zawarty w punkcie kontrolnym, jest dostępny pod adresem https://gstatic.com/android/binary_transparency/mainline/2026/02/checkpoint w formacie punktu kontrolnego. Źródło punktu kontrolnego to gstatic.com/android/binary_transparency/mainline/modules/2026/1.

Podpisy punktów kontrolnych są generowane za pomocą algorytmu podpisywania Ed25519. Podpis punktu kontrolnego można zweryfikować za pomocą tego klucza publicznego w formacie weryfikatora notatek (zgodnie z definicją w golang.org/x/mod/sumdb/note) lub w standardowym formacie PEM:

  • Format weryfikatora notatek (<name>+<key_hash>+<public_key_bytes>):
MainlineModulesLogV2+e490c9dd+AfwnHm59rNQTJICchMd7a2W5PQa7nC5h2gTEfq3fhCEI
  • Format PEM (SubjectPublicKeyInfo):
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEA/Ccebn2s1BMkgJyEx3trZbk9BrucLmHaBMR+rd+EIQg=
-----END PUBLIC KEY-----

Zarchiwizowany dziennik (wersja 1)

Przed aktualizacją w 3 kwartale 2026 r. dziennik działał w oparciu o wcześniejszą implementację w wersji 1, która korzystała z podpisów ECDSA (NIST P-256 z SHA-256). Dziennik w wersji 1 jest zarchiwizowany i tylko do odczytu, ale nadal jest publicznie dostępny do weryfikowania wpisów historycznych:

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEr6nPds8eKCYU42avidXNM1GDCtQ/
66GjGuIpUcZjqQNngwRFVCFZDpWuvDnqXzhJRxqccL9lbeEVVZGpa4x6pg==
-----END PUBLIC KEY-----

Ponieważ moduły Mainline są podobne do plików APK, obowiązują tu również metody weryfikacji opisane na stronie Weryfikacja plików APK Google apply here as well. Możesz ich użyć do weryfikacji informacji podanych w modelu zgłaszającego.