Transparenzlog für Android Mainline-Module

Im Transparenzlog für Android Mainline-Module werden überprüfbare Datenstrukturen verwendet, um die Integrität von Mainline-Modulen zu gewährleisten.

Der Nutzen von Transparenzlogs wurde bereits durch Projekte wie Pixel Binary Transparency und Certificate Transparency bewiesen.

Transparenzlogs basieren auf Merkle-Bäumen. Auf dieser Seite wird davon ausgegangen, dass Sie über allgemeine Kenntnisse zu Merkle-Bäumen und binärer Transparenz verfügen. Unter Überprüfbare Datenstrukturen finden Sie eine Übersicht zu Merkle-Bäumen und auf der Hauptseite eine Übersicht zu den Bemühungen um binäre Transparenz in Android.

Log-Implementierung

Das Transparenzlog für Android Mainline-Module wird mit Tessera implementiert und entspricht der Spezifikation für tlog-Kacheln mit einer Kachelhöhe von 8 (jede Kachel oder jedes Bundle enthält maximal 28 = 256 Elemente).

Der Stamm der Log-Inhalte wird unter https://gstatic.com/android/binary_transparency/mainline/2026/02/tile/entries/ bereitgestellt.

Der Stamm der Kachelinhalte wird unter https://gstatic.com/android/binary_transparency/mainline/2026/02/tile/ bereitgestellt.

Diese URLs sind keine Standardwebseiten. Stattdessen sollte programmatisch über Tools wie Tessera oder die Golang SumDB Tlog libraryauf die Logeinträge in seinen Unterverzeichnissen zugegriffen werden.

  • Baumkacheln: Die Hashes der inneren und Blattknoten des Merkle-Baums werden unter tile/<level>/<path> bereitgestellt (z.B. tile/0/000, tile/1/000).
  • Eintrags-Bundles: Die Nutzlasten der Log-Blätter sind in Eintrags-Bundles unter tile/entries/<path> organisiert (z. B. tile/entries/000, tile/entries/001). Jedes Bundle enthält bis zu 256 verkettete Einträge.

Unter Log-Inhalte finden Sie eine Beschreibung der Inhalte der einzelnen Einträge.

Der Stamm-Hash des Merkle-Baums des Logs, der in einem Checkpoint enthalten ist, wird im Checkpoint-Format unter https://gstatic.com/android/binary_transparency/mainline/2026/02/checkpoint bereitgestellt. Der Ursprung des Checkpoints ist gstatic.com/android/binary_transparency/mainline/modules/2026/1.

Checkpoint-Signaturen werden mit dem Ed25519-Signaturalgorithmus generiert. Die Signatur des Checkpoints kann mit dem folgenden öffentlichen Schlüssel im Note-Verifier-Format (wie in golang.org/x/mod/sumdb/note) oder im Standard-PEM-Format überprüft werden:

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

Archiviertes Log (V1)

Vor dem Update im dritten Quartal 2026 wurde das Log mit einer früheren V1-Implementierung mit ECDSA-Signaturen (NIST P-256 mit SHA-256) betrieben. Das V1-Log ist archiviert und schreibgeschützt, bleibt aber öffentlich zugänglich, um Verlaufsdaten zu überprüfen:

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

Da Mainline-Module APKs ähneln, gelten hier auch die auf der Seite Google APKs überprüfen beschriebenen Überprüfungsmethoden. Mit den dort beschriebenen Methoden können Sie die im Claimant-Modell gemachten Aussagen überprüfen.