Initial Thoughts on Code Transparency

Over nine months since I broached the uncomfortable questions about app signing,we have the official response. It is simultaneously more than I would have expectedand less than what we need.

These materials have only been in my hand for a few hours, and I expect I���ll write moreabout the situation next week. But, let���s see what we got.

First, there is this FAQ entry from ���The future of Android App Bundles is here���,the post where Google firmly declared that the App Bundle requirement is coming in a month:

When distributing apps on Google Play, how do I ensure my app is delivered to users the way I intend?

At any time, you can download and inspect artifacts from the Play Store, from the app bundle explorer in the Play Console, and via the Play Developer API to verify your app. In addition, code transparency for app bundles is a new, optional feature that can be used to inspect that code running on a device matches the code that was originally built and signed by the developer.

The first sentence is typical subterfuge. At best, all downloading those artifacts dois tell us the state of those specific artifacts.Google is perfectly capable of delivering different artifacts to different people. Itis not significantly different than is serving different Web pages to different people,which Google has been doing since its inception. So, they can give unmodified artifacts tothe developer and give tampered artifacts to other parties.

In terms of the second sentence, the passive tense in ���can be used��� is doing a lot of heavy lifting.As it turns out, ���can��� is somewhat theoretical at this time.

More of the details are in the ���Code transparency for app bundles���page in the developer documentation.

(Google seems indecisive over whether or not App Bundle is a proper noun ��� I will giveit The Capital Treatment here for consistency with past posts on this subject)

Code transparency creates a roster of SHA256 hashes for each DEX file and each .sofile that is part of the App Bundle. If that file ships to a user as part of an app,somebody could use it to confirm that the DEX files and .so files in the app match theirhashes. And, the code transparency file itself is signed, using a signing key private to the developer,so in principle we can determine if the code transparency file itself has been modified(e.g., to reflect hashes of tampered files rather than the original files).

That sounds good, and to an extent, it is.

However, all Google needs to do is remove the code transparency file from the apps that they deliverto users. After all:

They have full signing authority, so they can remove whatever they want

There is no legal or contractual requirement for them to ship this file

There is nothing in the operating system that is looking for this file, as they readily admit:

Important: The Android OS does not verify code transparency files at install time, and continues to rely on the APK signing schemes for verification of any installed APKs.

If there is no code transparency file, there is no code transparency.

Also, verifying that the code transparency file itself is the original implies that wecan validate that its signature is intact and was from the developer���s signing key.There is no current infrastructure for this, as Google also admits:

Important: To verify that the signature comes from the original developer, the printed fingerprint from one of the following methods must be compared with the public key communicated by the developer through a trusted channel. For example, the developer can host their public certificate on a secure website that is known to belong to them. To ensure no other changes have been made to the app, checking the APK signature is also necessary and recommended.

In addition, the code transparency file conveniently omits some things:

It does not include the manifest (or resources, assets, etc.)

It does not seem to preclude there being additional DEX or .so files, beyond the ones in the code transparency file

There has been an app-resigning attack available since Android 8.0 that neatly fits thosetwo omissions.

The upshot is that we, the developer ecosystem, will need to build a secure, reliableway for developers to advertise, for any given versionCode of an applicationId,that a code transparency file was included in the App Bundle, along with the certificate (orcertificate hash) that was used to sign that code transparency file. Google, at leastat present, is washing their hands of that mess. Without this, we have no way of knowing,for any given app, whether a missing code transparency file is a problem and whetheran existing code transparency file is valid.

Then, we, the developer ecosystem, will need to create practical tooling aroundthis stuff. What Google has given us is new commands for bundletool.As a reference implementation, that���s great. As a practical matter, that is very limited.For example, an anti-malware app running on Android itself is not going to be using bundletooldirectly via a shell command, if that���s even realistic. We are going to need a specificationfor the code transparency file, along with implementations that can be used in moreflexible ways (e.g., a library). It is unclear to what extent Google will be interested inany of that.

In addition, we, the developer ecosystem, will need to experiment with extending thissystem to include other developer-chosen content, such as the manifest, and deal with the���what if there���s other stuff here than what���s listed?��� issue.

Plus, we, the developer ecosystem, will need to get tools in the hands of users to actually validate the code transparency. It does us no good to have code transparencyfiles if nothing checks for them and verifies that the app was not modified by Google.This will likely need to be some mix of existing security-relatedapps (e.g., the aforementioned anti-malware apps) and dedicated code transparencyaudit apps. Google is unlikely to help here, and frankly, we should view any such helpas being suspect (���the fox guarding the henhouse���).

Also:

None of this affects APK-based uses of Play App Signing ��� official code transparency isonly for App Bundles

None of this affects other distribution channels that employ equivalents to PlayApp Signing��� such as the Amazon AppStore for Android,coming to a Windows 11 installation near you soon

We, the developer ecosystem, are going to need to figure out how to address thosescenarios as well.

Worst of all, these are just the things that I have thought of. I am certain to be missingsome problems or skipping over some scenarios, and those might add to the pile of work to be done.

Google���s implementation of code transparency is more than I expected,insofar as I really did not expect Google to do much ofanything. I have no idea how robust the core elements of their solution are, and we willonly find that out over time. But, the fact that this even exists is a positive step, incompleteas it may be.

That incompleteness is why this is less than what we need.

And all of this is just to avoid allowing developers to continue distributing APKsthe way that they have for over a decade, if they so choose.

In essence, Google has slashed our car tires, and then has generously offered to pay for alift home. While that is a nice gesture, it does not address the problem with the car, and itwould have been nicer if Google had not slashed the tires in the first place.

Again, I expect to write more about this in the coming weeks and months. Suffice it to say:there���s a lot of work ahead for those of us concerned about the problem. If you areconcerned about the problem, enough to perhaps help with that work,please reach out!