Pixel Binary Transparency Technical Details Page

The Pixel Binary Transparency Log leverages transparency log technology.

The utility of transparency logs has been proven with Certificate Transparency, an Internet protocol that requires Certificate Authorities to publish the certificates they issue to public Certificate Transparency logs. This process has greatly reduced the mis-issuance of certificates, thereby increasing the security of the Internet. Many Certificate Transparency log operators rely on an implementation of transparency logs found at transparency.dev.

Transparency logs are implemented with Merkle trees. This page assumes general knowledge of Merkle trees and binary transparency. See Verifiable Data Structures for an overview of Merkle trees and the landing page for an overview of binary transparency.

Log Implementation

The Pixel Binary Transparency Log is implemented as a tile-based Merkle tree. The root of the tile contents are served at https://developers.google.com/android/binary_transparency/tile. Note: this is not a regular web page; the log entries contained in its subdirectories should be read programmatically with the Golang SumDB TLog library and not through a browser.

See Log Content for a description of what the entries contain.

The Merkle tree root hash of a log, contained in a checkpoint, is served at https://developers.google.com/android/binary_transparency/checkpoint.txt. It is presented in the checkpoint format. The leaves of this Merkle tree are served at https://developers.google.com/android/binary_transparency/image_info.txt. The signature of the checkpoint can be verified with the following public key:

The verification process reads the checkpoint and tiles containing the log entries from the log.

Verification Process

A transparency log is implemented with a Merkle tree consisting of hashes. A leaf node contains data, and a parent node contains the hash of its children.

Two computations are performed on the Merkle tree to verify the tamper-evident property of transparency logs: the inclusion proof and consistency proof. The former proves that the log includes an entry corresponding to an image version, that is. The log entry includes the VBMeta digest, a hash that represents the OS images, which can be returned from a device. The latter proves that when new entries are added to the tree, the new checkpoint is consistent with the previous version of the tree.

To verify your Pixel image, perform the inclusion proof. Performing the consistency proof computation is optional, because third parties are continually doing so.

If you want to familiarize yourself with the concepts of verification in Pixel Binary transparency, you can follow the instructions below to use the image running on your Pixel device. If you want to run Pixel firmware with the highest degree of confidence, see the verification process on Pixel Binary Transparency Full Verification.

Prerequisites

Ensure the following dependencies are available:

Golang: The verification tool must be built with Go 1.17 or later, available from the Go site.
Android Debug Bridge (adb): Communicates with an Android device to inspect the image, available on the Android SDK Platform Tools website.
Inclusion proof verifier: Interfaces with the log to check that the Pixel image is in the binary transparency log.

# Source code for the inclusion proof verifier is found at avb/tools/transparency/verify
git clone https://android.googlesource.com/platform/external/avb

Inclusion Proof

A Pixel owner can check that their image is in the log by first extracting the relevant metadata, then comparing their recomputed root hash with the root hash contained in the published checkpoint. If they match, then the Pixel owner can be assured of some protections exemplified in the Threat Model.

To check that the image on a Pixel device is in the transparency log, connect to the device with adb, then run the following commands:

FINGERPRINT=$(adb shell getprop ro.build.fingerprint)
VBMETA_DIGEST=$(adb shell getprop ro.boot.vbmeta.digest)
LOG_ENTRY="${FINGERPRINT}\n${VBMETA_DIGEST}\n"
PAYLOAD_PATH="/tmp/log_payload.txt"
echo -e $LOG_ENTRY >> $PAYLOAD_PATH

cd avb/tools/transparency/verify/
go build cmd/verifier/verifier.go
./verifier --payload_path=$PAYLOAD_PATH

The first stanza retrieves the metadata from a Pixel device in the format of a log entry, and saves it to /tmp/log_payload.txt.

The second stanza runs the inclusion proof verifier published in the Android Verified Boot repository. This tool computes the hash of the candidate log entry, retrieves the other hashes necessary to recompute the checkpoint from the log, and compares it with the checkpoint published by the log.

The output of the command is written to stdout:

OK if the image is included in the log,
FAILURE if it is not.

Consistency Proof (Optional)

Since Google periodically releases new versions of the Pixel factory image, the transparency log is continually growing. A witness checks that the tree grows in a manner consistent with its previous leaves. The witness keeps track of the tree root hash, and computes the next candidate root hash by requesting the new leaf hashes from the tree. For a transparency log to be tamper-evident, it must be continually checked for consistency.

The append-only behavior of the transparency log is actively checked by third parties and so most users do not need to do this themselves, but it is possible for anyone to monitor the log's consistency. Google has published an open-source implementation of a witness in this Github repo. It is necessary to use the configuration specific to the Pixel Binary Transparency (PixelBT) log.