Google Product Application Transparency

To increase trust in Google apps and products, we are committed to listing every Google product package in our transparency log. We published the transparency log to publicly verify the claims that we make with regards to these packages (APKs and APEXs).

Threat Model

Transparency systems can be used to detect - and thus deter supply chain attacks. We illustrate with some examples.

Suppose an attacker maliciously modifies a Google app or product and even manages to sign it with the signing key that is used for distribution through Google Play. With a binary transparency log, anyone who receives a questionable package (APK or APEX) can utilize it as an additional verifiable source of ground truth to verify the package's authenticity. They will find that Google has not added the corresponding package metadata to the log and will know not to trust the compromised package.

Since publishing to the log is a separate process from the release process with signing (as illustrated in the Ecosystem Diagram), this raises the bar for the attacker beyond just compromising the key.

While we plan to also integrate this log into a public network of witnesses using a standard witness protocol, we encourage external, independent parties to monitor the integrity of this publicly available log. These parties can attest to the append-only property of the log, and report any tampering.

The existence of such a transparency system and the additional discoverability of attacks discourages malicious activity. If a package is compromised but users only trust those that are in the log, the compromised package would need to be publicly exposed. This increases the likelihood of discovering that the compromised package exists, and action can be taken to remove its distribution.

Claimant Model

The Claimant Model is a framework used to define roles and artifacts in a verifiable system. In the case of Google Product Application Transparency, the claim we make is that the hash of a package file recorded in this log represents a specific version of an official Google product meant for public consumption.

  • ClaimGoogleApp: (I, Google, claim that $hashApp is for $googleApp), where:
    • $hashApp is a cryptographic hash (e.g. SHA256) of the package file (including split APKs and APEX packages) of a specific version of $googleApp.
    • $googleApp is an Android package (APK or APEX) that makes up an app or product that Google creates and distributes.

Anyone who has a copy of $googleApp can verify this claim, and we describe this process in full detail in the verification page.

Log Content

When Google releases a new version of an APK or APEX package, it adds a corresponding entry to the Google Product Application Transparency Log.

Each entry in this log contains four pieces of metadata:

  1. The hash of the APK or APEX file of a Google signed package. This is a hex string of the SHA256 digest of the entire file.
  2. The description of the type of the preceding hash. This is a string.
  3. The package name of the package. This is a string.
  4. The version number (versionCode) of the package. This is a non-zero integer.

The format of a log entry is the concatenation of the four pieces of information with a newline (\n) character, as illustrated by the following:

hash\nhash_description\npackage_name\npackage_version\n

Since a Google product can be distributed as an APK or an APEX file, the hash description is set to either SHA256(APK) or SHA256(APEX). This provides comprehensive coverage of the content of each file, and makes it easier for users to obtain this measurement.

Ecosystem Diagram

Verifiable Log Ecosystem Diagram