Android Mainline Modules Transparency

To further increase trust in the Android OS, we are committed to listing every Android OS module (called Mainline) that is offered as an update via Google Play in our transparency log. We publish the transparency log to verify the claims we make about these modules. Pre-installed modules are not explicitly listed as they are already covered by Pixel Binary Transparency.

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 Mainline module (which could either be an APEX of APK file) and even manages to sign it with the signing key that is used for distribution via Google Play. Anyone who receives a questionable module can query the binary transparency log to verify the module's authenticity. They will find that Google has not added the corresponding module metadata to the log and will know not to trust the compromised OS module.

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.

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 OS module is compromised but users only trust those that are in the log, the compromised module would need to be publicly exposed. This increases the likelihood of discovering that the compromised modules 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 Android Mainline Modules Transparency, the claim we make is that the hash of a module file recorded in this log represents a specific version of an official Android module meant for public consumption.

  • ClaimMainlineModule: (I, Google, claim that $hashModule is for $mainlineModule), where:
    • $hashModule is a cryptographic hash (e.g. SHA256) of the OS module file of a specific version of $mainlineModule.
    • $mainlineModule is either an APEX or an Android package (APK) that makes up an OS module that Google creates, signs, and distributes.

Anyone with a copy of $mainlineModule can verify this claim. The verification page provides detailed instructions for this process. These steps apply to both regular APKs and Mainline modules (which can be either APK or APEX files).

Log Content

When Google releases a new version of a Mainline module, it adds a corresponding entry to the Mainline Modules Transparency Log.

Each entry in this log contains four pieces of metadata:

  1. The hash of the APK or APEX of a signed Android Mainline module. This is a hex string of the SHA256 digest of the entire file.
  2. The description of the type of hash above. This is a string.
  3. The package name of the module. This is a string.
  4. The version number (versionCode) of the module. 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 mainline module can either be an APK or an APEX file, the hash description can be either SHA256(APK) or SHA256(APEX).