One core piece of our approach is thinking about very high risk situations, like Ai Weiwei or Edward Snowden, then making the tools for operating under that pressure as easy to use as possible. That means that we might occasionally come across as a little paranoid. It is important to dive into the depths of what might be possible. That is an essential step in evaluating what the risks and defenses are, and how to prioritize them. Making usable software is not just making things easy, but rather making tools for real world situations that are a simple as possible.
We recently received some vindication of our paranoia: we have been resistant to putting all of our trust into the Google Play app store, despite many obvious advantages. Even though Google Play is probably the most secure of the big app stores, its security approach is rather thin, relying mainly on HTTPS with no signature for verification, and the Five Eyes partnership (NSA, GCHQ, etc) noticed this, and worked to exploit it.
The Android/Google Play security model is relatively simple, and that is mostly a good thing. There are two essential pieces: the signature on the APK file itself and the TLS connection to Google that provides the APK file. Once an app is installed, all APK files used to update an app must have a matching signing key. That provides a reasonably strong mechanism to defend against malware that wants to install over existing apps.
Unlike package systems like Debian, there is no path to verify that the APK signing key. That means Google Play relies heavily on the TLS transport encryption to protect the APK files for when installing an Android apps for the first time. The first time an app is installed, the signing key in that app’s APK file is blindly trusted (this is called “Trust On First Use” or TOFU). It turns out that TOFU has a solid track record for security in the real world. One key aspect of implementing a good TOFU system is to make the first use indistinguishable from any other use, so that it is difficult to target only first uses while ignoring repeat uses. Intercepting repeat uses is very likely to trigger a warning and alert the user that something is wrong.
Now let’s put together the pieces based on what the Chinese government can do. A few TLS certificate authorities have been caught issuing fake certificates. A company affiliated with CNNIC was caught issuing certificates for Google domains. A trusted certificate authority can issue usable certificates for any domain, so any computer that trusts CNNIC would trust their fake certificates for Google. That lets the Chinese government transparently Man-in-the-Middle traffic to Google servers. China could then use the Great Firewall to generate targeted malware on the fly, seeing the user credentials that Google Play requires, seeing the list of apps that each user has installed, etc. Then when the targeted user goes to install a new app, the APK file is intercepted, malware is added, then it is re-signed and transparently sent off to the user.
This targeted malware can be designed to avoid the malware scanners in Google Play, Lookout, etc. since it would be direct addition of code rather than via an exploit. It would be just adding Java classes to the APK. Or alternatively, in combination with some of the signing exploits that have been discovered in Android, like Master Key, the Great Firewall is able to inject malware into the real APK itself without changing the signature.
Of course, when Google Play’s TLS connection includes X.509 certificate pinning, then the above attack would not be possible since the client would have a whitelist of certificate authorities that it trusts for play.google.com, and CNNIC would probably not be on that whitelist. This highlights the importance of pinning certificate authorities in apps that need good security over TLS or HTTPS. All TLS connections support pinning at the system level starting in Android 4.2. We are crazy enough to support down to Android 2.3 since there are lots of older Android devices in use, and even new devices being sold with Android 2.3.3. That means we think about making apps self-contained in terms of security improvements like pinning.
It gets worse
Many indigenous app stores like Cafe Bazaar and Xiaomi’s MiMarket lack basic protections like TLS, making targeted attacks trivial for governments, or even anyone who gains control of a piece of the network path. These days that is actually easy to do by exploiting home routers, which are generally easy to exploit. One of those botnets would easily start looking for app installs in the network traffic, then add exploits accordingly. As long as the first install is easy to detect and the user easy to track, then the malware can transparently inject malware designed to be difficult to detect by malware scanners and people alike.
The Alternative
FDroid also has the key advantage of being designed from the beginning to avoid tracking users, and to use proven methods of delivering software, following the signed repository model of Debian, Ubuntu, etc. but then served over a solid HTTPS channel for increased privacy and a backup layer of security. It is also possible to use privacy proxies like Tor or I2P via the proxy settings. There is no user credentials needed, it is all free software, so FDroid users can even hide themselves from the server delivering the apps, as well as any network observers. Since all APKs are delivered via signed metadata that is verified using a key built into the FDroid client app, there is no risk of getting served malware even if the HTTPS connection is completely and transparently broken.
As part of our Bazaar Project, we have been putting more and more efforts into the FDroid project, and working to make it much easier to use. All Guardian Project apps are available in FDroid, as well as all the core apps that you might need like Firefox, a Twitter client, K-9 email, etc. Tech journalist Dan Gillmor agrees: free software that respects privacy is not only for the über-geek anymore.