We've enabled OEMs to create their own transparency log to help their users verify the OS or firmware running on their devices. For example, the Pixel Binary Transparency Log is published by Google to increase trust in Pixel factory images. We encourage users to leverage binary transparency and other OEMs to create their own transparency log.
The rest of this page provides an overview of how Google is applying binary transparency to Android Pixel devices.
If you want to run Pixel firmware with the highest degree of confidence, see the verification process on Pixel Binary Transparency Full Verification.
If you want to familiarize with concepts of Pixel Binary transparency using your Pixel device, see the Verification Process on the Pixel Binary Transparency Technical Details page.
Threat Model
Transparency systems can be used to detect—and thus deter—supply chain attacks. Let's address some examples:
Suppose an attacker maliciously modifies a Pixel image and even manages to sign it with the key that Google owns. Anyone who receives the malicious image can query the binary transparency log to verify the image's authenticity. The user will find that Google has not added the corresponding image metadata to the log and will know not to trust the compromised image. Since publishing to the log is a separate process from the release process with signing, this raises the bar for the attacker beyond just compromising the key. Additionally, external, independent parties are encouraged to monitor the integrity of the log because it is public. These parties can attest to the append-only property of the log, and report any tampering.
The Android Open Source Project is extensive and relies on code dependencies like any other modern software. Unfortunately, this can serve as an attack vector if a bad actor is able to introduce a backdoor in one of the code dependencies. Before releasing a Pixel version and publishing to a binary transparency log, Google performs code audits. This way, if a Pixel owner verifies that their image is in the log, they can transitively trust that it has passed the security and compliance audits.
Lastly, the very existence of this system and the additional discoverability of attacks discourages malicious activity. If an image is compromised but users only trust those that are in the log, the compromised image would need to be publicly exposed. This increases the likelihood of discovering that the compromised image exists, and action can be taken to remove its distribution.
Claimant Model
The Claimant Model is a framework used to define the roles and artifacts in a verifiable system. In the case of Pixel Binary Transparency, the claim we make is that the factory images downloaded from the Android factory images website are official Google/Pixel factory images.
- ClaimFactoryImage: (I, Google, claim that
$factoryImage_instanceis for$deviceNameOrSku), where:$factoryImage_instanceare all factory images, beginning from Pixel 6, available for download from the official Android factory images website.$deviceNameOrSkucan be determined by navigating to "Settings->About phone->Device name" from the user's device. The corresponding$deviceNameOrSkucan be used to find the correct$factoryImage_instancefrom the website mentioned earlier.
Log Content
When Google releases a new factory image for Pixel 6 or newer phones, it adds a corresponding entry to the Pixel Binary Transparency Log.
The entry contains two pieces of image metadata:
- The build fingerprint of the factory image. This unique human-readable string corresponds to a particular Android implementation and revision, which allows for customizations specific to the firmware.
- The VBMeta digest of the factory image. This is a hash of all descriptors and metadata used in Android Verified Boot. For more information, see the Android Verified Boot repository.
Google provides the tools necessary for a Pixel owner to extract the two pieces of information for a given image. With this in hand, the user can query the log for image authenticity.
The log does not contain any personal data associated with a device, only metadata of the factory image.
Ecosystem Diagram
