Google System APK Transparency

As part of Google's continuous investment in transparency of its products, we are adding transparency to two new Google system APKs: Android System SafetyCore (com.google.android.safetycore) and Android System Key Verifier (com.google.android.contactkeys). These APKs power the Sensitive Content Warnings and cryptographic key verification feature in Google Messages respectively. The transparency log we published to verify the claims that we make with regards to these APKs.

Covered Packages

This section describes packages that are covered in the transparency log and also their respective code transparency signing keys.

Android System SafetyCore

Android System SafetyCore (com.google.android.safetycore) is an Android system component that provides privacy-preserving on-device user protection infrastructure for apps.

Code from this APK is currently signed with the following key described by this certificate:

Android System Key Verifier

The Android System Key Verifier APK (com.google.android.contactkeys) is a service for contact verification on Android. It allows a user to verify a contact's public keys to confirm they are communicating with the person they intend to message. The service is a unified system for public key verification across different apps, which uses verification through QR Code scanning or number comparison.

Code from this APK is currently signed with the following key described by this certificate:

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 System APK and even manages to sign it with the signing key that is used by Google Play. Anyone who receives the malicious APK can query the binary transparency log 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 System APK Transparency, the claim we make is that the hash of signed binaries recorded in this log represents official code for respective Google System APKs.

Claim^{GoogleSystemApk}: (I, Google, claim that $codeSignature is for $googleSystemApk), where:
- $codeSignature is a signed JSON Web Token (JWT) that contains a list of DEX files and native libraries and their corresponding hashes included in a specific version of $googleSystemApk.
- $googleSystemApk is an Android package (APK) from the following set of packages: {Android System SafetyCore (com.google.android.safetycore), Android System Key Verifier (com.google.android.contactkeys)}

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

Log Content

When Google releases a new version of the APKs listed above, it adds a corresponding entry to the Google System APK Transparency Log.

Each entry in this log contains four pieces of APK metadata:

The hash of the code signature of a Google developed APK. This is a hex string of the SHA256 digest of a code transparency token (also known as Code Transparency JWT).
The description of the type of hash above. This is a string.
The package name of the APK. This is a string.
The version number (versionCode) of the APK. This is an 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(Signed Code Transparency JWT)\npackage_name\npackage_version\n

Note that in this release, we are experimenting with utilizing code transparency. This means that instead of the hash of the APK, we are recording the digest of the code transparency token. Thus the hash description is currently fixed as SHA256(Signed Code Transparency JWT).

Additionally, this demonstrates a way code transparency can be utilized by app developers when their app signing keys are held by Google Play.

Ecosystem Diagram

Verifiable Log Ecosystem Diagram