Google Product Application Transparency

To increase trust in Google apps, we are now committed to listing every Google product app in our transparency log. We published the transparency log to publicly verify the claims that we make with regards to these APKs.

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 and even manages to sign it with the signing key that is used for distribution via Google Play. With a binary transparency log, anyone who receives a questionable APK can utilize it as a verifiable source of ground truth to verify the APK's authenticity. They will find that Google has not added the corresponding APK metadata to the log and will know not to trust the compromised APK.

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 an APK is compromised but users only trust those that are in the log, the compromised APK would need to be publicly exposed. This increases the likelihood of discovering that the compromised APK 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 1st Party App Transparency, the claim we make is that the hash of an APK file recorded in this log represents a specific version of an official Google app meant for public consumption.

  • ClaimGoogleApp: (I, Google, claim that $hashApp is for $googleApp), where:
    • $hashApp is a cryptographic hash (e.g. SHA256) of the APK file (including split APKs) of a specific version of $googleApp.
    • $googleApp is an Android package (APK) that makes up an app 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, it adds a corresponding entry to the Google 1st Party APK Transparency Log.

Each entry in this log contains four pieces of metadata:

  1. The hash of the APK file of a Google signed app. 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 APK. This is a string.
  4. The version number (versionCode) of the APK. 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\nSHA256(APK)\npackage_name\npackage_version\n

Since we are measuring the entire APK file, the hash description is set to SHA256(APK). 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