Third Party Android App Store Validation Gaps

Android has a robust system of application authenticity provided by digital signatures, usually terminating in a single root-of-trust, either the Google App store, or in some cases the OEM app store. Today I will discuss some problems crossing those lines and possible solutions, using Google and Amazon as examples.

How this works for Google Apps on Google Devices

Application signatures work the same for most app store vendors but Google serves as the most common example.

Developer

1. Applications are signed by the developer
2. Upon upload to the Play Store, they are signed again into a Google PKI.

User

1. Upon download to a device, the Android OS validates that the application installer, or APK, was signed by Google. There is some later use of the developer signature, but mostly for upgrades so we shall gloss over it today
2. The Android platform normally requires apps be installed through a PKI. This is set up by a list of trusted root certificates. Most applications ship with the Google public app store certificates, verifying applications came through the app store.
3. The enforcement of this PKI is not done by the App Store, but at a lower level. It also impacts APKs downloaded manually and pushed over ADB. This is a good thing.
4. Unless something is wrong, the above steps are transparent to end-users

How this works for adding Amazon apps to a non-Amazon device.

Developer

1. Applications are signed by the developer
2. Upon upload to a store, they may signed again into a different PKI.

User

1. The Amazon App store includes an App, but it seems Google does not want to sign other app stores into the Play Store, probably to limit fragmentation.
2. So, users must first enable installing apps from unknown sources
3. Then they install the new app store
4. Now they can install apps from the new store. But, since apps from the new store are not signed by Google, the Unknown Sources option must stay enabled.
5. The lowest level of signature enforcement, locked to the developer signature, is still enforced, usually transparent to the user.

What is wrong with this

Ideally, the Unknown Sources option would never be used on end-user devices, it would only be used for developers. The Unknown Sources option makes it very easy to click a bad link and download malware, leaving the only defence the user not installing it. This is best not left to end-users.

Worse yet, Unknown Sources must be enabled for the duration of 3rd party store usage, or must be manually enabled before installing each application then disabled once done. This tedium impacts the user-experience and forces us into a usability-security trade-off that is not present when utilizing a custom app store. Generically, we should be providing users with both, and trying to avoid manual steps like this almost entirely.

How can it be improved

The current options for app stores, either using the vendor-provided app store or requiring Unknown Sources, are two very different ends of a spectrum. I would not suggest that Google sign the Amazon store into Google Play and provide it with a permission to verify other applications - the decision to extend or wield such power should not come lightly.

I propose that 3rd party app stores be allowed to install a second root-of-trust. Similarly to how applications are already sandboxed by the developer signature, apps installed by different stores would not be allowed to upgrade or replace each other, except through complete destruction of the sandbox. Roots of trust in this system would need to be revokable in case of a store compromise, possibly with a signature-upgrade path for known good applications. In one way, multiple roots of trust increases the exposure for malware to be signed by a trusted root, as we now trust each app store to verify its own applications. But without this, the requirement to enable Unknown Sources exposes most users to a much wider risk, in that there is no usually no verification at all unless the user remembers to manually adjust the special settings hidden in the developer menu.