Google-Produktantrag – Transparenzlog

Das Google Product Application Transparency Log nutzt die Transparenzlog-Technologie.

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

Transparenzlogs werden mit Merkle-Bäumen implementiert. Auf dieser Seite wird davon ausgegangen, dass Sie über allgemeine Kenntnisse zu Merkle-Bäumen und binärer Transparenz verfügen. Unter Verifiable Data Structures finden Sie eine Übersicht über Merkle-Bäume und auf der Hauptseite eine Übersicht über die Bemühungen zur binären Transparenz in Android.

Log-Implementierung

Das Google Product Application Transparency Log wird mit Tessera implementiert und entspricht der Spe2zifikation für tlog-Kacheln mit einer Kachel hö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/google1p/apk/2026/02/tile/entries/ bereitgestellt.

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

Beachten Sie, dass es sich hierbei nicht um reguläre Webseiten handelt. Die in den Unterverzeichnissen enthaltenen Logeinträge sollten programmatisch mit einer tlog-tiles Client Bibliothek (z. B. Tessera oder Golang SumDB Tlog Library) und nicht über einen Browser gelesen werden. Wir geben den Link hier zur Klarheit an.

  • 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), wobei jedes Bundle bis zu 256 verkettete Einträge enthält.

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

Der Merkle-Baum-Stamm-Hash des Logs, der in einem Checkpoint enthalten ist, wird unter https://gstatic.com/android/binary_transparency/google1p/apk/2026/02/checkpoint im Checkpoint-Format bereitgestellt. Der Ursprung des Checkpoints ist android.transparency.goog/google1p/apk/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>):
android.transparency.goog/google1p/apk/2026/1+fc654374+ATr9NQE0gvOtVfj5cCStUzdlflEp3oZoNHD8pImzPj5O
  • PEM-Format (SubjectPublicKeyInfo):
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAOv01ATSC861V+PlwJK1TN2V+USnehmg0cPykibM+Pk4=
-----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 historische Einträge zu überprüfen:

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEaP7xodTP5/teDOUYFAUHF0MqvOXt
+jamtcDYWxTjY99hyYczpB/cF2fxHhIqEznNpLcI2Vorl+iEchWhZ0y3Mg==
-----END PUBLIC KEY-----

Log-Ansprüche überprüfen

Auf der Überprüfungsseite wird genauer beschrieben, wie die verschiedenen Komponenten des Logs verwendet werden, um die im Claimant Model gemachten Ansprüche zu überprüfen.