Mobile on Guardian Project

Build Your Own App Store: Android Media Distribution for Everyone

Wed, 22 Feb 2017 09:45:11 -0400

Most people get their Android apps from Google Play. It is usually the simplest and most secure option for them. But there are also many people who do not have access to Google Play. This might be due to lack of a proper internet connection or simply because Google Play is blocked within their country.

The F-Droid project already offers tools to create independent app distribution channels for Android apps. These tools are ready for production, but require expert knowledge and the command-line to be used. Now, we want to build upon this foundation and develop curation tools that can also be used by people with little technical knowledge, thus making the app distribution technology more broadly available.

Use-Cases

The primary use-case we want to address is to circumvent app store censorship and blocking. But there are other use-cases that benefit from easy-to-setup app stores as well.

There are Android phones and tablets that do not have Google Play available, either because their manufacturer did not get a license from Google or because their owners prefer their phones Google-free.

Similar to Apple’s app store, the terms of service of Google Play exclude certain apps from being distributed and these are being removed on a regular basis. Having alternative means for distribution of apps is often the only way to bring those apps to people.

Features

Core Features

Create a new app repository
Add new apps/media to the repository
Update existing apps/media to the repository
Update the description and metadata of apps/media
Remove apps/media from the repository
Automatic generation of repository website with QR Code (and instructions)
Import apps directly from other repositories

Optional Future Features

Archive apps/media to archive repository
Remove installed apps/media from user’s devices
Provide hosted web-app with user-management (Sign-Up, Lost Password) as a service
Allow multiple curators to manage the same repository
Import apps (and their description) from Google Play
Check for updates from Google Play periodically and automatically import them
Making the repository available through the Tor network
Generate custom white-labelled repository app (based on F-Droid)
App security scanner for vulnerable libraries and Virus Total (opt-in) upload
App browsing and download on generated repository website

Target Audience

The main audience for this work are activists and trainers with moderate technical knowledge who need to securely distribute apps and updates to their community. This is especially a concern in countries where the official app store is blocked. Organizations like Amnesty International for example still need to enable people in those countries to securely receive their apps and updates.

The person maintaining the repository might use any operating system and in some cases might not even have a laptop/desktop computer available. They might be targeted by advanced attackers that can intercept and insert arbitrary traffic, but do not have the ability to compromise large service providers such as Amazon.

Furthermore, this work might also be used by the following groups:

service providers (who want own distribution and update mechanism for their apps)
individual software developers (who want to distribute beta releases for e.g. user-testing)
everybody else who needs full control of the entire distribution and update process

Implementation Options

There are roughly four different ways, the app store curation tool could be implemented. Each has their own pro and cons as well as different implications for the usability.

Command-line interface

The current app repository tools are already used via the command-line, but they require some setup and several non-intuitive commands to be executed. The goal here would be to reduce the number of required commands as much as possible and make them easy to understand and remember. This would be similar to how Letsencrypt’s Certbot simplified SSL certificate management.

Pros

least amount of work building directly on existing tools
signing key could be created and stored on local device

Cons

too difficult to use for people with no prior command-line experience
off-putting and not inviting for potential non-expert curators
adds little benefit to existing solution

Cross-Platform Desktop Application

A graphical user interface (GUI) could be added to the existing tools to make them easier to use. Existing UI toolkits such as Qt, Gtk or Tcl/Tk could be used for this.

Pros

can make use of existing python tools
signing key could be created and stored on local device

Cons

requires a desktop computer and installation procedure (possibly of dependencies as well)
need to maintain and support install packages for Windows and MacOS

Android App

The free software F-Droid app already includes repository functionality used for direct app swapping. This could be modified to publish repositories to remote servers and extended by curation functionality. Alternatively, a new app could be developed that is dedicated to repository curation and could contrary to F-Droid even be distributed via Google Play.

Pros

Simple installation
No desktop computer required

Cons

Needs reimplementation of existing Python code in Java
Signing key stored on potentially less secure mobile device

Web App

The user interface for repository curation could be implemented as a web application that is accessed through a web browser. Low-risk curators could use a hosted instance for maximum simplicity while others could also access the interface through a local (built-in) web-server. Powerful web frameworks such as Flask or Django might be a good choice for that job.

Pros

Very easy to use from every device
Does not need installation (lower usage barrier)
Can make use of existing python tools
Makes multi-curator feature potentially easier to implement

Cons

In hosted mode: signing keys need to be stored permanently on a web server

Security Considerations

Repository Attacks

The technology used for app distribution needs to ensure the integrity and authenticity of apps provided in the repository. It can not prevent malicious apps from being intentionally distributed, but can offer a security scanner to reduce the risk of unintentional distribution. An attack is considered successful when the content provided by the curator of the repository can be altered so that the changes propagate to users’ devices.

Malicious apps might compromise the targeted application or the entire phones (root exploit). There are two defenses against unintentional distribution of malicious apps:

app package signatures: clients trust the provided app signature on first installation (TOFU) and refuse updates with a different signature.
repository signature: clients check signature when repository is installed and with every update. They warn and refuse operations with the repository when the signature is invalid.

The first defense is out of scope for this work, because app packages are signed when the app is built so that they are already signed when added to the repository. The repository curation should still not allow to publish an update that carries a different signature.

The second defense needs to be provided automatically by the curation tools. A repository signing key needs to be created and securely stored. If this key is compromised, an attacker can modify app metadata and can inject modified apps for specific or all users when they install them for the first time. Malicious updates of already installed apps are prevented by above package signature.

If the repository key is created and stored automatically by a service (see implementation option 4), the curator needs to trust the service and the hosting provider. Both need to be out of reach of attackers from the curators’ threat-model. For example, if the Guardian Project provides a repository service hosted in Amazon’s Cloud, this service should be out of reach of most attackers that have neither the ability to compromise the Guardian Project, nor Amazon. Advanced nation-state adversaries could compromise both and thus the repository. Recipients of apps need to trust their distributors/curators and their ability to keep their own system secure.

However, we can generally not protect against attackers who has the ability to directly compromise the users’ devices. All that can be done is to prevent malicious applications from being installed via the repository (without knowledge of the curator). If the attacker can compromise users’ devices through other means, this defense does not matter anymore.

Root and Unknown Sources

In order to get content from the provided repository onto a generic device, the user needs to install F-Droid which requires allowing the installation of apps from unknown sources. This can put the user at risk, because it makes installing malicious application very easy. Alternatively, super user privileges (root) can be used to install F-Droid’s system extension effectively trusting all apps installed via F-Droid. However, the security risks associated with super user privileges are even more severe as they can lead to compromise of the entire device.

Lack of Updates

If a repository is the user’s sole source for an application, any delay in providing updates might put the user at risk of an adversary exploiting a vulnerability in that application that would have otherwise been fixed by the missing update.

What We Will Do

The main goal of the curation tools is to make creating and maintaining repositories as easy as possible for our target audience.

This rules out the command line and the desktop application, since today’s user experience expectations are no longer being fulfilled by these technologies. While a desktop application comes closer, the need for an installation procedure and for maintaining it for different operating systems makes it too difficult and error-prone compared to the two other remaining options.

Implementing the curation tools within an Android application has its merits. It comes with an easy installation procedure, provides a familiar state-of-the-art user interface and allows apps to be added directly from the curators’ device. However, some existing functionality would need to be reimplemented in Java and maintained along-side the existing Python codebase. Also the curator needs to provide an external storage location for the repository which can be a barrier for many users and needs its own documentation.

The easiest and most flexible solution is a web-application based on the existing Python tools. More advanced curators can use it on a local desktop computer with a built-in web-server just like a desktop application, only that the UI is in the browser. This usage scenario comes with the same pros and cons like the desktop application. The repository signing key for example is stored locally under the curator’s control.

But it allows for other usage scenarios as well. If installed on a trusted web-server as a service, the curation tools can also be used by curators with little technical knowledge. The curators don’t need to install anything and can use them from any device. They can even switch devices without a data migration. However, they would need to give up control over the signing key.

If time permits, the app store creator can be turned into a full repository service that allows user registrations and several repositories per user. A trusted organization such as the Guardian Project could host this as a service and provide it to an activist community. Software freedom would allow other organizations to host their own repository services as well. You can imagine the activist collective Riseup for example not only hosting its own repository of recommended apps, but also allowing its users to create and curate their own repositories.

This becomes even more interesting when people fill their repositories not only with apps, but with all sorts of files such as books, music and photos.

Building the most private app store

Thu, 02 Jun 2016 11:08:52 -0400

App stores can work well without any tracking at all

Attackers are increasingly seeing app stores as a prime attack vector, whether it is aimed at the masses like XCodeGhost or very targeted like in FBI vs Apple. When we install software from an app store, we are placing a lot of trust in a lot of different parties involved in getting the source code from the original developer delivered to our device in a useful form. Most people are entirely unaware of how much trust they are putting into this system, which they are entrusting with their personal data. Even for people who do understand the technical details involved, figuring out whether the people and the system itself is trustworthy is difficult to do.

We are building an app store that requires the bare minimum of trust: only the software developers themselves and the code they produce. We consider the app store operators and servers a threat. Building an ecosystem that enables automated, effective auditing lets the computers verify to make trust decisions easier. Effective external auditing requires an ecosystem that cannot deliver targeted content to just the auditing system, while feeding users something else (aka “binary transparency”).

Most app stores track as much as possible

The vast majority of apps stores track their users actions in detail. Some is necessary when using the business model of the app store operator taking a percentage of sales, but none of the tracking is inherent to running an app store. For example, payment verification can be handled in the app itself like shareware. A software delivery system that tracks its users makes it simple to hide malware delivery since it can target any auditing system. Most app stores know a lot about their users:

account name
identity
payment methods
everything you search for in the app store
everything you look at in the app store
everything you download, install, uninstall
which apps you actually run
where you are, based on IP, declared preference, etc.
your preferred language
and more…

Apps stores need to know very little in order to function: how to give you the files you request. That means indexes, descriptions, icons, apps, and install/delete requests (for “push” install/delete). Given that information, the client can do everything needed to provide a full app store user experience. For this work, we chose to build upon F-Droid, a community-run Android app store that distributes verified Free Software. The community has had an interest in privacy all along, and has always worked to avoid tracking. The security architecture is based on models proven by Debian, The Update Framework , and others:

HTTPS connections by default
pinned TLS certificate built into the client app
updates verified based on the signature on the app itself
file integrity protected by signed metadata
signed metadata includes hashes of the app and its signing key
signed metadata generated on a separate machine, which can be fully offline
public key for verifying metadata signatures built into F-Droid client app
signed metadata includes timestamp and expiry

While the current setup is already a solid platform, we are implementing a number of improvements. The signed metadata will include list of official mirrors, then the client chooses mirrors based on availability and freshness based on local criteria like whether Tor is in use, closest on the internet, etc. We are also moving the standard HTTP “etag” cache check from the server to the client so it cannot be abused to track users.

In order to defend against an attacker that holds the signing keys for the app repository, there must be a trustworthy source of information to compare against. Reproducible builds means that anyone with the same source code will produce the exact same binary. When paired with an auditing system, it is easy to catch malware inserted in the build process, rather than the source code, like XCodeGhost. Reproducible builds also makes it possible to have all builds of a release binary have the exact same hash. Then any app repository can build apps only from source code, and have a source of verification data from any other app repository building the same app. Building software from source has become cheap enough that many companies like gitlab.com and Travis CI are offering free, automated build services in the cloud. Since the whole F-Droid toolset is free software and designed to be easy to setup, the barriers to setting up automatic auditing are quite low. People in separate areas of the world with different risk profiles can run verification servers to provide more trustworthy information.

Another key aspect of the F-Droid project is to provide the complete toolset needed to run an app store. This enables a more decentralized ecosystem. Therefore, one key goal is to lower the risks of running the services, so that more people can run their own app stores. If the app store does not track its users, then that removes the hassle of protecting personal data from any attacker. These services can be run without fear of responding to secret orders for personal information. It also means that the server setup is a lot simpler because it does not need dynamic content. The app store serve only needs to serve files (e.g. indexes, apps, etc.). The app repository is generated on a secure machine, or even a fully offline machine, and posted to the server. The main server is purely a mirror of the offline machine where the signed repository is generated. Mirrors just shuffle bits from place to place, they are no longer an attack vector.

Putting all these pieces together provides a system where users need only audit the source code in order to verify a trustworthy app delivery. The file pipeline provides redundantly secure data transmission, the apps can be reproducibly from source code, the app repositories can be automatically audited. Of course, this system relies not only on the power of cryptography, but also the power of transparency. Debian provides a great example of the power of transparency: Debian gives a thousand volunteers root access to every Debian install (by virtue of their ability to upload signed packages that get installed as root). Yet this system has been proven over the past 20+ years to provide solid security. Ultimately we hope that this will de-emphasize the signing key as the sole protection against abuse. If malware has a decent change of being spotted, it makes it much less likely to be used since malware authors either rigorously defend their exploits, or use well known exploits that are not difficult to automatically detect.

Future Work

One attack vector that is not well covered is malware that installable by everyone, that then uses data on the local device to target specific users. That would be a way to target individuals using an app store that does not track its users. We are starting to implement automated dynamic analysis of every app using tools like Drozer.

We are also working towards making as many apps as possible build reproducibly. Some of our quick checks show that a large number of the apps in f-droid.org already will build reproducibly, given the right build environment. We are working on making the process of setting up that build environment as automated as possible.

The F-Droid “verification server” has been prototyped, and it will be further developed with the aim of making it dead simple to run in common cloud services.

We already have the infrastructure in place to do verified double-signing, where the developer first signs the release bulid, then once f-droid.org reproduces that build, it adds its signature. Then Android would enforce that both signatures need to be present in order for it to be a valid update.

As the full localization support is built out, the language that a user is using will not be reported to the server. While speaking Spanish in Spain does not provide much information, speaking Quechua in Uzbekistan can narrow it down to a single user. Instead of dividing the index metadata by language, it will instead be grouped by app. We will then group apps so that it is difficult to tell which app in the group is the one people are interested in. For example, if one very popular app is only grouped with apps that are rarely downloaded, then it is an easy assumption that someone getting info about that block of apps is most likely looking for that popular app.

First working test of IOCipher for Obj-C

Mon, 26 Jan 2015 04:32:29 -0400

Every so often, we revisit our core libraries in the process of improving our existing apps, and creating new ones. IOCipher has become a standard part of our apps since it provides a really easy way to include encrypted file storage in Android apps. And we are now working on spreading it to iOS as well, headed up by Chris Ballinger, with the first preliminary tests of IOCipher for Obj-C. Testing and contributions are most welcome! Find us in our chat room or mailing list for questions, or just post a comment below! Since the iOS version is based on the exact same core library, libsqlfs, the container files they produce will also be fully compatible with each other.

Now that iOS 8 has full disk encryption by default and a host of other security improvements, you might be wondering why you would bother with app-specific encryption. The problem with full disk encryption is that the disk is only locked when your iPhone is fully turned off. Using IOCipher adds protection for sensitive data that helps in a few different scenarios.

First, full disk encryption does not protect the data at all if malware is able to get root on the device. That malware will be free to read all files on the device. Second, for people who have not set up a strong passphrase on their iOS device, using app-specific encrypted storage make it harder to access that app’s data on devices with no passcode set, especially if any additional passphrase is stored in the keychain and disallowed from backup, or if it’s just stored in your own memory.

Third is for added protetion from forensic acquisition systems, which often work using root exploits in order to read the entire filesystem without unlocking the screen[1][2][3]. By having an app-specific encrypted file container that is not mounted like a filesystem, then even root cannot directly access the files in the container. Even root needs to get the key in order to unlock the IOCipher container, whether it is in use or not, and getting that key means either a key logger, which means planning ahead, or reading they key from memory if the container is unlocked, which is a more elaborate and targeted attack that full disk acquisition after rooting.

Now consider that there is a large market 0days, i.e. unpublished exploits, and companies like VUPEN, FinFisher, and Hacking Team making it easy to purchase them, even providing guarantees that one of their exploits will work within 30 days, it seems quite likely that customers of such companies have access to secret root exploits to even iOS 8. While there are ethical and lawful reasons to use software like this, many governments are also using them for illegal and unethical things. Since we believe that everyone has a right to privacy, to speak freely, and to peaceably protest, it is important to provide protection to people who are unfairly targeted.

There is also another key advantage of the IOCipher approach when it comes to mobile devices. IOCipher is ultimately based on SQLite transactions in SQLCipher, which means that it does not require being mounted in the normal sense. There is no open state once a transaction is complete. Each read or write operation is a self-contained SQLite transaction, so if the file system is forcably quit, SQLite’s transactions prevent the whole file system from being corrupted. This is important in mobile operating systems like Android and iOS since any app or process can be killed at any moment without warning. That means that the worst that can happen to an IOCipher volume is a single write command does not get written. The whole file system will not be corrupted if the process is killed.

Coming Soon

When IOCipher is used in conjunction with our CacheWord library, it is possible for an app to provide protection even against the $5 wrench attack. CacheWord generates a strong passphrase and manages feeding it to IOCipher and SQLCipher. The user provides their own password for encrypting that strong passphrase. That CacheWord file is tiny, and can be rapidly deleted. Once it is gone, the actual passphrase that unlocks the IOCipher encryption is gone, the user’s passphrase will not unlock IOCipher directly. This is something we are working to add in all of our apps, and to also hook it up to panic button triggers. We would be quite happy to see you beat us to it by adding this feature to your app!

IOCipher with a hardware security module (HSM) aka smartcard would be really nice, since it would provide some measure of added protection without the user setting an app-specific passphrase. HSMs provide write-only private key storage locked by pin code, so even if some was able to get the encrypted file and the pincode, they would not be able to retrieve the key to unlock the encrypted file. The only way to unlock the file would be with the physical device itself, or by finding the key backup, if that existed. This is possible now using an external microSD HSM

Sharing your location privately

Fri, 23 Jan 2015 15:00:10 -0400

Facebook location sharing embeds the location in every single message, providing a detailed log to the recipient, Facebook, and anyone Facebook shares that data with

One handy feature that many smartphones give us is the ability to easily share our exact position with other people. You can see this feature in a lot of apps. Google Maps lets you click “Share” and send a URL via any method you have available. In Facebook Messenger, you can click a button and the people on the other side of the chat will receive a little embedded map showing the received location. Of course, the question we always ask is: how can we do this in a privacy-preserving way? And the follow up question: what kinds of information are apps leaking, storing, using, etc? Location is especially valuable and sensitive metadata, especially when there is a lot of it, because it can be used to derive so much information about a person. Most people do not want to publicly post their phone number or home address on the internet, yet are unwittingly giving away far more detailed information by using the various location-based services that are available. There is a lot of specific location information that people do not want to publicize that they visit: a cancer specialist, an abortion clinic, a criminal court, a mistress’ house, or any location information to an abusive spouse. For a great illustration of the power of location metadata, you can watch an animation of German politician Malte Spitz’s life, based on his telephone metadata that his telecom had stored.

Google, Facebook, and so many others make money by collecting as much data on their users as possible, then selling access to that data to their customers. So both those companies have incentives to make sure that you will always share your location information with them as well. The question is: are they treating this information as carefully as you would? In China, the indigenous services are much more popular than most foreign alternatives. The Chinese companies are good at making products that are popular with Chinese users, and since they collaborate with the government censorship and tracking, it is easier for them to do business in China. This combination often means that Chinese companies put security and privacy at a very low priority, even though they could comply with the Chinese law while improving their security. A good example of this is the fact that none of the major map providers in China (Baidu, Amap, or QQ) provide even an optional HTTPS interface. They only have unencrypted communications, which allows lots of people easy access to snooping, including anyone who is on the same wifi network as you are.

The tools for tracking people via location data are getting better, cheaper, and more available. One funny example is I Know Where Your Cat Lives, which shows the locations of cat pictures found on the public internet via the geo location included in the EXIF image data.

I know where your cat lives!

Location and Panic

One use that we are particularly interested in is sending location to trusted contacts when a panic button is pressed. When thinking about panic button features, privacy must be a central concern. When someone triggers their panic button, it is clearly a sensitive situation. That means that leaking more location information could exacerabate the situation. Since sending location is a useful and popular feature, it is important to consider the whole picture of where that location information might go. To start with, the panic message needs to be sent using a method that will reliably reach its intended destination. Unfortunately, that often means using insecure communications like SMS, or an app that is fully tapped by the same government that is detaining the user, like WeChat. Part of this T2 Panic research and development effort is focused on how to make a complete, secure panic solution. So we will also focus on making ChatSecure and other secure communications an available channel for sending panic messages.

The next step is to break down the entire path of where that location information might be intercepted. The first place is on the sending device itself. The panic message will stored with the sent messages with most communications apps, and that can recovered by whoever is detaining the user. Even if the device is encrypted, it is very likely the user can be compelled to unlock the device. So the panic message should be designed with that in mind.

So if we consider a fully anonymous method of communication, like ChatSecure’s “Secret Identity”, then protecting the location information becomes important even if all of the messages and their recipients are recovered from the sending device. The full “Secret Identity” procedure of creating an account per person you want to chat with, and only using that single account to communicate with that other person. It has been outlined by many people, including Laura Poitras when describing how she communicates with Edward Snowden. In this case, even if someone recovers the recipient address, all they will have is an anonymously created account with no other links to other accounts. Then location URL then becomes a way to deanonymize the recipient. First, if the URL takes the recipient to an unencrypted connection, then that it is easy to track. Even with an encrypted connection, if the server providing the map service is providing information to the government, then the encrypted connection will not help. Making this connection over Tor will also help since the map service will not be able to see the IP address of the device where the user clicked on this URL. Now consider a location URL using Google Maps, or any similar service where users frequently login. If the original panic message was sent using such a URL, and the recipient was a regular user of a service that used logins, then that login information would deanonymize the recipient if they viewed the location URL in a browser where they were also logged in with their normal Google account.

User Stories

This can perhaps be better illustrated using some quick user stories:

A journalist and a source set up Secret Identities in ChatSecure devoted to each other when they met up in person. Each have panic buttons set up to contact the other in case of emergency. The journalist uses https://openstreetmap.org to generate a shortlink that points to the chosen meeting location, then sends it to the source using the Secret Identity, http://osm.org/go/0ju_SMlBn. The source clicks the link, and chooses to open the link in Firefox. Therefore, the website is shown using an unencrypted, direct connection, which is easily observed. Even though the recipient has HTTPS Everywhere set up in his browser to force HTTPS for openstreetmap.org, the osm.org shortlink does not currently have working HTTPS so it is an HTTP link. This shortlink is now a unique ID that links the journalist and source’s real IP address. If the source was using a cellular internet connection, then this will also link the IP address to the devices IMEI unique ID. The IMEI is then quite easy to link to a real identity information.
A circle of activists all set each other up with a panic button app on burner Android phones. They only use these burner phones to communicate with each other. They prepare in advance to discard all the phones in case someone triggers the panic. One activitist gets detained by the secret police and triggers the panic. The secret police get the panic message and all the other phone numbers from the detainee’s phone, but the activists are no longer using those phones so they cannot be tracked by them. The activists manually copy the Google Maps shortlink https://goo.gl/maps/Cji0V to their computer to find out where the detainee is. They type the map link into Internet Explorer, making sure to type HTTPS, and then again confirm that the webpage is still using an HTTPS link. What they did not see is that the shortlink first redirected to a HTTP link http://maps.google.com/?q=28.118860,98.008069&hl=en&gl=us, which leaked the location in plain text. Since this URL describes a very specific point, the secret police use this as a data point to search for the IP address of all devices that have accessed that URL. Those IP addresses divulge the locations of all the activists who viewed the map URL, and provide the secret police a method for tracking them all.

I did not cover other more common use cases here because there are so many leaks that the protections presented are moot. All is not lost, there is still a lot that you can do to improve things. First off, we recommend using map apps that can work fully offline. For Android, Osmand is the best one out there, it uses OpenStreetMap data which can be freely downloaded. It is also important to encourage developers to improve the privacy of their apps. Since we are software developers, we file bug reports and make pull requests to nag location-related projects to improve their security. Here are some recent examples of what we have contributed:

OpenStreetMap

Issue #799: Implement geo: URLs for sharing
Issue #870: share makes HTTP url even when connecting via HTTPS
Issue #862: support osm.org in HTTPS certificate

Osmand

Pull #1033: modernize location sharing
Pull #1043: add support for a proxy and use more HTTPS
Pull #1045: update URL parsing

We will be following up with further posts on this topic with more detail, including research into what is possible to derive from location data, technical details of issues, and possible solutions and work that can be done to improve things.

Improving trust and flexibility in interactions between Android apps

Tue, 21 Jan 2014 13:51:57 -0400

Activity1 sending an Intent that either Activity2 or Activity3 can handle.

Android provides a flexible system of messaging between apps in the form of `Intent`s. It also provides the framework for reusing large chunks of apps based on the `Activity` class. `Intent`s are the messages that make the requests, and `Activity`s are the basic chunk of functionality in an app, including its interface. This combination allows apps to reuse large chunks of functionality while keeping the user experience seamless and fluent. For example, an app can send an Intent to request a camera `Activity` to prompt the user to take a picture, and that process can feel integrated into the original app that made the request. Another common use of this paradigm is choosing account information from the contacts database (aka the _People_ app). When a user is composing an new email, they will want to select who the message gets sent to. Android provides both the contacts database, and a nice overlay screen for finding and selecting the person to send to. This combination is an `Activity` provided by Android. The message that the email program sends in order to trigger that `Activity` is an `Intent`. As usual, one of the downsides of flexibility is increased security risk. This is compounded in the Android system by rules that will automatically export an Activity to receive Intents from any app, when certain conditions are met. If an `Activity` is exported for any app to call, it is possible for apps to send malicious Intents to that `Activity`. Many `Intents` are meant to be public and others are exported as a side effect. Either way, at the very least, it is necessary to sanitize the input that an `Activity` receives. On the other side of the issue, if an app is trusting another app to provide a sensitive service for it, then malware can pose as the trusted app and receive sensitive data from the trusting app. An app does not need to request any permissions in order to set itself up as a receiver of Intents.

Activity/Service hijacking: watch out for the little devil in the system

Android, of course, does provide some added protections for cases like this. For very sensitive situations, an Activity can be setup to only receive Intents from apps that meet certain criteria. Android permissions can restrict other apps from sending Intents to any given exported Activity. If a separate app wants to send an Intent to an Activity that has be set with a permission, then that app must include that permission in its manifest, thereby publishing that it is using that permission. This provides a good way publish an API for getting permission, but leaving it relatively open for other apps to use. Other kinds of controls can be based on two aspects of an app that the Android system enforces to remain the same: the package name and the signing key. If either of those change, then Android considers it a different app altogether. The strictest control is handled by the “protection level”, which can be set to only allow either the system or apps signed by the same key to send Intents to a given Activity. These security tools are useful in many situations, but leave lots of privacy-oriented use cases uncovered.

There are some situations that need more flexibility without opening things up entirely. The first simple example is provided by our app Pixelknot: it needs to send pictures through services that will not mess up the hidden data in the images. It has a trusted list of apps it will send to, based on apps that have proven to pass the images through unchanged. When the user goes to share the image from Pixelknot to an cloud storage app, the user will be prompted to choose from a list of installed apps that match the whitelist in Pixelknot. We could have implemented a permission and asked lots of app providers to implement it, but it seems a mammoth task to get lots of large companies like Dropbox and Google to include our specific permission.

There are other situations that require even tighter restrictions that are available. The first example here comes from our OpenPGP app for Android. Gnu Privacy Guard (GPG) provides cryptographic services to any app that requests it. When the app sends data to GPG to be encrypted, it needs to be sure that the data is actually going to GPG and not to some malware. For very sensitive situations, the Android-provided package name and signing key might not be enough to ensure that the correct app is receiving the unencrypted data. Many Android devices are still unpatched to protect against master key bugs, and for people using Android in China, Iran, etc. where the Play Store is not allowed, they don’t get the exploit scanning provided by Google. Telecoms around the world have proved to be bad at updating the software for the devices that they sell, leaving many security problems unfixed. Alternative Android app stores are a very popular way to get apps. So far, the ones that we have seen provide minimal security and no malware scanning. In China, Android is very popular, so this represents a lot of Android users.

Another potential use case revolves around a media reporting app that relies on other apps to provide images and video as part of regular reports. This could be something like a citizen journalist editing app or a human rights reporting app. The Guardian Project develops a handful of apps designed to create media in these situations: ObscuraCam, InformaCam, and an new secure camera app in the works that we are contributing to. We want InformaCam to work as a provider of verifiable media to any app. It generates a package of data that includes a cryptographic signature so that its authenticity can be verified. That means that the apps that transport the InformaCam data do not need to be trusted in order to guarantee the integrity of the uploaded InformaCam data. Therefore it does not make sense in this case for InformaCam to grant itself permissions to access other apps’ secured Activitys. It would add to the maintenance load of the app without furthering the goals of the InformaCam project. Luckily there are other ways to address that need.

The inverse of this situation is not true. The reporting app that gathers media and sends it to trusted destinations has higher requirements for validating the data it receives via Intents. If verifiable media is required, then this reporter app will want to only accept incoming media from InformaCam. Well-known human rights activists are often the target of custom malware designed to get information from their phones. For this example, a malware version of InformaCam could be designed to track all of the media that the user is sending to the human rights reporting app. To prevent this, the reporter app will want to only accept data from a list of trusted apps. When the user tries to feed media from the malware app to the reporting app, it would be rejected, alerting the user that something is amiss. If an reporting app wants to receive data only from InformaCam, it needs to have some checks setup to enforce that. The easiest way for the reporting app to implement those checks would be to add an Android permission to the receiving Activity. But that requires the sending app, in the example above that is InformaCam, to implement the reporting app’s permission. Using permissions works for tailored interactions. InformaCam aims to bring tighter secure to all relevant interactions, so we need a different approach. While InformaCam could include some specific permissions, the aim is to have a single method that supports all the desired interactions. Having a single method here means less code to audit, less complexity, and fewer places for security bugs.

We have started auditing the security of communication via Intents, while also working on various ideas to address the issues laid out so far. This will include laying out best-practices and defining gaps in the Android architecture. We plan on building the techniques that we find useful into reusable libraries to make it easy for others to also have more flexible and trusted interactions. When are the standard checks not enough? If the user has a malware version of an app that exploits master key bugs, then the signature on the app will be valid. If a check is based only on a package name, malware could use any given package name. Android enforces that only one app can be installed with a given package name, but if there are multiple apps with the same package name, Android will not prevent you from installing the malware version.

TOFU/POP: delicious vegan treat and clever software interaction!

The strictest possible checks can be based on the hash of the whole APK, while tracking the signing key of a given APK is also often useful. These two data points are the most reliable ways to verify a given app. They can be tracked in two different ways: pinning and trust-on-first-use (TOFU/POP). Pinning means that a verified hash or signing key for the apps that need to be trusted is included in the app that must trust them. Then the trusting app can verify what it is sending or receiving

Intents from, the installed app is then compared to the pre-stored pinned value. This kind of pinning allows for checks like the Signature permission level but based on a key that the app developer can select and include in the app. The built-in Signature permissions are fixed on the signing key of the currently running app.

TOFU/POP means Trust-On-First-Use/Persistence Of Pseudonym. In this model, popularized by SSH, the user marks a given hash or signing key as trusted the first time they use the app, without extended checks about that apps validity. That mark then describes a “pseudonym” for that app, since there is no verification process, and that pseudonym is remembered for comparing in future interactions. One big advantage of TOFU/POP is that the user has control over which apps to trust, and that trust relationship is created at the moment the user takes an action to start using the app that needs to be trusted. That makes it much easier to manage than using Android permissions, which must be managed by the app’s developer. A disadvantage is that the initial trust is basically a guess, and that leaves open a method to get malware in there. The problem of installing good software, and avoiding malware, is outside of the scope of securing inter-app communication. Secure app installation is best handled by the process that is actually installing the software, like the Google Play Store or F-Droid does.

To build on the InformaCam example, in order to setup a trusted data flow between InformaCam and the reporting app, custom checks must be implemented on both the sender and the receiver. For the sender, InformaCam, it should be able to send to any app, but it should then remember the app that it is configured to send to and make sure its really only sending to that app. It would then use TOFU/POP with the hash as the data point. For the receiver, the reporting app, it should only accept incoming data from apps that it trusts. The receiver then includes a pin for the signing key, or if the app is being deployed to unupdated devices the pin can be based on the hash to work around master key exploits. From there on out, the receiving app checks against the stored app hashes or signing keys. For less security-sensitive situations, the received can rely on TOFU/POP on the first time that an app sends media.

There are various versions of these ideas floating around in various apps, and we have some in the works. We are working now to hammer out which of these ideas are the most useful, then we will be focusing our development efforts there. We would love to hear about any related effort or libraries that are out there. And we are also interested to hear about entirely different approaches than what has been outlined here.

Setting up your own app store with F-Droid

Tue, 05 Nov 2013 11:55:43 -0400

(_This blog post as now been cooked into an updated HOWTO_)

The Google Play Store for Android is not available in all parts of the world, US law restricts its use in certain countries like Iran, and many countries block access to the Play Store, like China. Also, the Google Play Store tracks all user actions, reporting back to Google what apps have been installed and also run on the phone. Because of the NSA leaks, we’re seeing that governments are actively tapping into the raw data streams of Google, Yahoo, and others. So that means the information the Google Play Store sends back to Google is also intercepted by the NSA (and probably other country’s agencies), and that information is shared with other governments. In other words, your activity on the Google Play Store is far from private. Lastly, the Google Play Store is not free software, unlike the core of Android itself. It is proprietary software that Google entirely controls.

F-Droid is a wonderful, free app store for Android. It is modeled after the Debian GNU/Linux distro. It has its own package repositories (repos) and build servers for all the apps that are part of the official OS. Like Debian and Ubuntu, you can also setup your own repos for anyone to use. Any free software can be added to the official F-Droid repos, where they are built and signed by the F-Droid server. This can be annoying because it means that your apps in F-Droid are signed by a different key than your apps in the Google Play Store. If you host your own F-Droid repo, then people can use F-Droid to install your own builds signed by your own signing key.

This is a quick HOWTO for how to setup such a repository on a Debian or Ubuntu box. It is somewhat technical, you will use the terminal, but you don’t need to be a terminal expert to follow along. First you need a the fdroidserver tools and a webserver. For the webserver, here we use nginx for the webserver since its lightweight, but any will do if you already have one running. The fdroidserver tools are not yet in the official Debian/Ubuntu/etc repos, so you have to add our PPA (Personal Package Archive) to get it (fingerprint: F50E ADDD 2234 F563):

sudo add-apt-repository ppa:guardianproject/ppa
sudo apt-get update
sudo apt-get install fdroidserver nginx

In the case of this HOWTO, we’re going to setup a “Simple Binary Repository” to host our official APKs. The repo will be set up in the recommended fdroid/ subdirectory. This gives the fdroid tool its own directory to work in, and makes the repo URL clearly marked as an FDroid repo. Let’s give our normal user control over this subdirectory in the web root so that we don’t need to run the F-Droid tools as root (with nginx, the webroot is /usr/share/nginx/www, it is different for other webservers):

sudo mkdir /usr/share/nginx/www/fdroid
sudo chown -R $USER /usr/share/nginx/www/fdroid
cd /usr/share/nginx/www/fdroid
fdroid init

Now put your APK files into /usr/share/nginx/www/fdroid/repo and you are ready to run the commands to build the repo (if fdroid init cannot find your Android SDK in /opt/android-sdk or $ANDROID_HOME, it will prompt you for the path):

cd /usr/share/nginx/www/fdroid
cp /path/to/*.apk /usr/share/nginx/www/fdroid/repo/
fdroid update -c
fdroid update

Voila! Now you have a working F-Droid Repo! Add it to an F-Droid client on your Android device to test it out. That is done in the Manage Repos screen available from the menu. Your repo URL will be the hostname or IP address of your machine with /fdroid/repo/ added to the end of it, i.e. https://mysecureserver.com/fdroid/repo/ or http://192.168.2.53/fdroid/repo/. You can temporarily uncheck the official repos to easily see what F-Droid found in your new repo.

Customization

You can also customize your repo by editing the config file. Be sure to use a programming text editor, like editor /usr/share/nginx/www/fdroid/config.py. In the config file, you can set the name of the repo, the description, the icon, paths to specific versions of the build tools, links to a related wiki, and whether to keep stats. Here’s the basic repo description block:

repo_url = "https://guardianproject.info/fdroid/repo"
repo_name = "My Local Repo"
repo_icon = "GP_Logo_hires.png"
repo_description = """
This is a local test repository of Hans-Christoph Steiner <&#x68;a&#x6e;s@&#x67;ua&#x72;d&#x69;&#x61;n&#x70;ro&#x6a;e&#x63;&#x74;.&#x69;nf&#x6f;>.  It is a repository of Guardian Project apps.
"""

To put your icon into your repo, choose a PNG image to put in your repo. The PNG goes in /usr/share/nginx/www/fdroid/, the file can be named whatever you want (by default its fdroid-icon.png). If you change the name from the default, be sure to update repo_icon and archive_icon in /usr/share/nginx/www/fdroid/config.py

More Security

Now that you have a working repo, its time to improve the security. Generating a repo in place is very easy, that is why this HOWTO started there, but it is not as secure as it should be if your repo is going to be your main distribution point. When generating the repo in place, make sure that config.py is not accessible via the web, since it contains passwords. If the file permissions are correct (e.g. chmod 0600 config.py), then config.py will not be readable by the webserver. But the signing keys will still be that public server. To improve this situation, generate the repo on a non-public machine like your laptop, keeping config.py and the keystore only on that machine, then use fdroid server update to publish the changes to your repo on a separate server. You just need to set serverwebroot in config.py properly, then fdroid server update will do the publishing via rsync over ssh. So both computers will have to have ssh and rsync installed and setup.

You can also use your own existing signing key rather than the one generated by fdroid init, just edit repo_keyalias, keystore, keystorepass, keypass, and keydname in /usr/share/nginx/www/fdroid/config.py

Since we like Tor and its Hidden Services for providing privacy, we also want to setup an F-Droid repository that is accessible over a Tor Hidden Service aka onion address. This will be covered in a future HOWTO.

Modernizing Expectations for the Nouveau Secure Mobile Messaging Movement

Tue, 16 Jul 2013 00:52:31 -0400

The tl;dr of this lengthy (tho entertaining and immensely important!) post is this: Stopping with “We support OTR” or “We support PGP” is not enough anymore. There are at least seven, if not more, very important security features that any app claiming to provide secure messaging must implement as soon as possible, to truly safeguard a user’s communication content, metadata and identity.

Note: The names “Gibberbot” and “ChatSecure” are used interchangeabley below, as we are in the midst of an app rebrand. Apologies!

There has been a great deal of activity recently around new apps and projects working towards the goal of end-to-end secure mobile messaging. This is both prompted by the overwhelming popularity of closed-source, insecure apps like WhatsApp, Viber, Line and WeChat, and by the recent revelations around government-sponsored surveillance in portions of the world that like to think of themselves as “free”.

Whether it be the effort by the CyanogenMOD team to build in a secure push messaging, the arrival of new apps like Gryphn, Wickr, Threema and SureSpot, or the very succesful crowdsourced funding of Heml.is, there is no question that there is both user and developer interest in this topic. I would also be remiss not to mention the continuing excellent work by Moxie and the Open Whisper Systems team on SMS-based secure messaging, Ge0rg and the Yaxim app, our iOS sister project ChatSecure, and of course, Silent Circle (are they open-source yet or what?).

Protecting Content, Metadata and Identity

At the Guardian Project, we have been working on open-source, standards-based, secure messaging for a few years now, and are simultaneously both excited and concerned about all of this activity. We are seriously thrilled that so many talented developers are finally interested in empowering every day mobile users with powerful tools to keep their communications private. We are amazed at the creativity and quality of output seen so far, as well as the diverse approaches to solving this complex problem. Most of these apps are innovating way beyond the basic concepts of secure messaging established by systems like OpenPGP and OTR encryption, and actually thinking deeply about what it means to be secure in a mobile context. However, we also think that, in many cases, the security being implemented may not be going far enough. At the least, we feel that a new bar needs to be set, that is nost just “more secure than WhatsApp”. We need to establish norms to help the user better understand and parse through their options.

In this context, the word “secure” should be taken to mean, that the contents of a message or conversation between one or more parties, should only be able to be viewed by those parties. This means that the application or service should ensure that message content, be it plain text or rich media, is both protected on the device and over the network, from extraction, interception, and decryption. In addition, “secure” should also extend to protect from network traffic surveillance, the fact that a conversation between one or more parties is even happening in the first place. Finally, as much as possible, the user should be able to control their identity within the messaging system, such that personal, real-world information (phone number, email, geolocation) is not exposed without their approval.

This three-fold approach to mobile security (Content, Metadata, Identity) is a work in progress, but does capture our basic sentiment and approach to secure mobile messaging. From here, I would like to step one level down, and talk about the set of features in our next release of Gibberbot, currently in alpha, that we feel keep our solution to mobile messaging at the head of the pack.

1. Full Local Data Encryption

Many apps feel their job in protecting messages is done once it gets to the device. In the face of Android app malware that can vacuum up data from a device and forensic extraction software and hardware, this is obviously not the case. Full disk encryption only protects when a device is locked or powered off, and besides, most users do not enable it. It is up to apps themselves to provide full encryption of all data – account configuration, sensitive settings values, messages, logs – anything that might expose a user’s information to other apps on the system or to a extraction software must be protected. Yes, this also means your user will need to enter a password every time they use your app, but it is possible to make that process less painful.

We have been working on two developer libraries, SQLCipher and IOCipher, which provide a simple means to enable database and file encryption in any app. More recently, we have added the CacheWord library to that mix, to help safely manage the locking and unlocking of these data stores. Apps like Gryphn have already implemented all three of these libraries, and so will the next version of Gibberbot.

2. Certificate Pinning

Moxie says it best in his post titled Your app shouldn’t suffer SSL’s problems: “If you have a mobile app that makes SSL connections to a service you control, there is really no reason to be validating your service’s certificate using CA signatures.” The Android Pinning library makes it quite simple to support this important feature in any app. For Gibberbot, we are pinning certificates of the most common known public XMPP services, such as Google (talk.google.com), Facebook, Jabber.org, Jabber.ccc.de, DuckDuckGo and few more. Beyond that, we offer manual verification (see #3 feature below for more on that). In summary, there is no reason anymore to trust the default CA’s for a messaging app.

3. TOFU/POP aka “Manual Certificate Verification”

Chris Palmer, formerly of the Electronic Frontier Foundation and iSec Partners and now of Google, gave a great talk a few years ago entitled “It’s Time to Fix HTTPS”. In it, he introduced, or perhaps just popularized, the phrase “Trust on First Use, Persistence of Pseudonym”, that is more happily expressed as TOFU/POP! What this means in user form is that when you connect to a new server for the first time over an SSL connection, instead of the SSL Certificate being verified by a built-in set of trusted root authorities (banks, corporations, governments), the certificate is presented to the user, in a human readable format, to be reviewed, accepted or declined. There are a number of useful pieces of information the user can look at to determine the validity – fingerprints, date generated, and so on. If you can safely verify it once, then you will only be notified or asked to verify again if the server’s certificate changes. At that point the user can be told “This site’s certificate changed, and it doesn’t look the same as it was yesterday. Maybe you should ask the admin or help system if it is still safe to use!”.

The implementation of TOFU/POP that we use in Gibberbot is the Memorizing Trust Manager library, originally developed for the Yaxim messaging app. It works very well, and again, is extremely simple to implement. Through the combination of features #2 and #3 we have removed the threat posed by the failure of the Root Certificate Authority system, and significantly reduced the success rate of Man-in-the-Middle attacks.

4. Proxy Support, ideally Tor

With all the talk of metadata recently, it should be clear how important traffic surveillance is. Knowing who is using what app when, or being able to see when two users connect peer-to-peer through a service is immensely valuable information. If it is possible to map a user’s social graph via your app based on analysis of packets coming in and out of your service, then you have failed in providing security to your users. Additionally, we have begun to see a new wave of Internet filtering around the world, as countries begin to block access to popular messaging app downloads and centralized servers.

This makes it critical that any messaging app a user will depend on to protect their messages, also works to protect their network of contacts (social graph), and ensures they will have access to the service no matter where they travel or live in the world. In order to achieve this, direct support for proxy servers should be built in to every secure messaging app. At a bare minimum HTTP proxies should be support, and ideally, HTTPS and SOCKS as well. Once you have support for those, you can easily tie into Orbot on Android, by setting the proxy to “localhost” and the appropriate port. If you want to avoid Tor Exit Node attacks or surveillance, you should then provide a Tor Hidden Service .ONION address for your servers, something that the CCC’s Jabber server has provided since 2011.

We have blogged in the past about Twitter’s support for proxying on Android and our OnionKit library, now named NetCipher. Gibberbot has supported proxying from nearly the beginning of its existence, and in v12 we are using the OrbotHelper class to add an automatic check if Orbot is installed and running, if a user selects to use it.

5. Verifiable Message Encryption

While we expect most nextgen secure messaing apps will support some form of public key encryption, OTR ideally and OpenPGP alternatively, that is not really the end of the message encryption problem. With OpenPGP, we know that most users of the software participate in key signing parties on a regular basis. The same is true for users of desktop OTR encryption in apps like Pidgin. People do not verify keys as often as they should. Since most messaging apps support in-band key exchange, it makes performing a MITM attack at the messaging layer quite trivial, if the SSL transport layer encryption is somehow intercepted.

What is needed are a variety of features, prods, pokes and motivational interventions to ensure that two people who are using an app to exchange encrypted messages know how fun and easy it can be to verify their keys. With Gibberbot, we were one of the first apps to support the display and scanning of OTR fingerprints as QR Codes. We will go beyond that in future releases with NFC support, as well. We also support shared secret and Socialist Millionaire Protocol-based verification, which in short means, if you and your friend have a real world secret or question and answer ready, you can easily verify your cryptographic fingerprints without ever having to look at a long string of alphanumeric characters.

6. Key Management

This feature comes under the “a great problem to have” category. Once a user really commits to using their app, they will begin building up a network of verified contacts (if you have implemented #5 properly), and generally come to regard your app as a type of secure identity management tool. In fact, they may have created a whole unique identity for themselves that only exists within the confines of your apps, and its encrypted local storage (if you have implemented #1 above). At this point, you need to figure out a means for a user to backup this identity, and generally import and export the data in a variety of ways. If you are using OTR or OpenPGP, then the user may want to share existing keyrings to and from other apps, most likely on their desktop or laptop machines. All in all, the user needs to be empowered to have control of their identity, to move it between devices, to back it up in case a device is wiped or lost, and to keep total control of that information (i.e. not have it backed up automatically to a cloud).

In our case, we have been working for quite a while on a desktop tool called OTR File Converter, which is built upon more fundamental research into the many ways that different OTR-enabled apps store their public and private keys. As of Gibberbot v12 alpha 3 (now called “ChatSecure” btw!), we now have working support for importing an OTR key ring from the desktop, in a manner that is secure and fairly simple. Our next stop is to add export from the client, and then automated sync between desktop and mobile on an ongoing basis. Beyond this capability, we also plan to expand the ability to manage keys within the Gibberbot app itself, so that a user can manually revoke, regenerate and update or remove trust of other users’ keys.

7. Panic as a feature!

Finally, we keep coming across this idea of a “Panic Button” being an important feature for addressing security issues in a mobile environment. A few years ago, we developed an app called In The Clear which attempted to provide data wipe and distress beacon functionality across your entire device, be it Android, Nokia or Blackberry. We quickly realized that there were many, many different definitions of what a “Panic Button” should do, and that one app may not be able to encompass all of these needs. Since then, we have thought more about “Panic!” as a feature for an app, and how each app we develop should incorporate the capability to assist users when they feel the data that the app holds may be at risk of being compromised or exposed.

In Gibberbot v12, we have implemented Panic as a quick access sidedrawer button. The action can trigger a configurable set of actions, ranging from simply logging out, to deleting all configured accounts, to uninstall the app itself. In the future, we would like to also consider supporting a “turtle shell” type feature where the app can hide itself on your device as an encrypted anonymous blob, until you are ready for it to come back out again. Additionally, supporting false passwords at app unlock that trigger account data wipe or the display of false data is also something we think would be useful to support.

What Are You Prepared To Do?

We know the deep feeling of adrenaline and satisfaction you get when ~~code~~ ship software that can truly have an impact on a human’s basic freedoms. We are moved when we receive an email from a user in a part of the world where speech and expression is limited and filtered, and they tell us how important our software is to them, and how they do not know what they would without us. These emotions, both from within and shared by others, make it that more important to ensure any development of secure messaging tools is approached in a serious and diligent manner. Checking feature boxes is not enough. Using HTTPS is not enough. Even supporting basic OTR and PGP is no longer enough. We must provide deep and broad security both on the network and on the device, at all times.

If you are not prepared to go the extra mile with your app’s security capabilities, then perhaps you are in the wrong line of work.

Proposal for Secure Connection Notification on Android

Thu, 15 Nov 2012 10:07:49 -0400

A major problem of mobile applications being increasingly used over web-based applications, is that there is no standard established for notifying the user of the state of security on the network connection. With a web browser, the evolution of the “lock” icon when an HTTPS connection is made, has been one that evolved originally out of Netscape’s first implementation, to an adhoc, defact industry-standard way of letting the user know if their connection is secure. Beyond just a binary on/off, the lock icon is also the entry point into viewing more information about the digital security tokens, keys and certificates that are powering the connection – who authorized them, who requested them, and so on. More recently, with browsers such as Chrome, there has been the user of color schemes (Green is good, Red is bad), verified domain display and other indicators to help ensure the user knows when to trust their connection, and when to be wary.

Firefox’s HTTPS certificate display

While many people claim that HTTPS/TLS/SSL are fundamentally broken, they are still an essential piece of basic frontline security on the web. In addition, when making a connection through a proxy network like Tor or a free VPN service, utilizing TLS/SSL is critical in making sure you network is not being intercepted along the way. The notification icon and related certificate viewing, is a critical component for the user, and one that is entirely missing in the mobile application space. The Android API does not provide a standardized method to share this information with the user, and the implementation on iOS is unclear, as well. Even worse, the proper implementation of a strong HTTP/S connection that properly handles verification of certificates, and provides an interactive option for users to accept or decline is entirely missing for the majority of mobile apps.

With that in mind, we have added a Secure Connection Notification feature into our new OnionKit for Android library. Build upon our previous work on implementing custom Root CA Certificate stores for Android, this library not only provides a clear way to enable HTTP and SOCKS proxying for your network requests (to enable use with our app, Orbot: Tor for Android), but it also includes a StrongTrustManager and a StrongHTTPSClient implementation, that works to defend against man-in-the-middle attacks, and other means to intercept a TLS or SSL connection between a mobile app and a remote server. Part of the defense, is providing a clear indicator to the user when a secure connection is in use.

We have provided a sample Android app to demonstrate how simple it is to enable this capability. The screenshots below are from that app.

In this first screenshot, the app has connected to https://check.torproject.org and you can see in the Notification bar a “key” icon indicating there is a secure connection active.

When you drag the notification bar down, you can see a more complete view of the Secure Connection Notification (SCN) message, which indicates the connection is Active and shows a summary of the secure certificate information. In a recent update to the OnionKit SCN code, it also allows for the application to include its name and icon in this notification.

Finally, you can tap on the SCN notification and bring up a larger pop-over view of the certificate information. We intend to develop this view further, to allow for better manual management of trust – meaning you may have the option to accept/decline or disable trust of this certificate or the certificate authority that provides it.

Beyond “Active” messages, the notification system will also warn or block connections that are deemed risky, invalid or otherwise unverifiable. You can use OnionKit in concert with the MemorizingTrustManager to manually override this verification process, if your application is expected to often connect to servers with unverifiable certificates. Finally, using our CACert project, you can generate custom Root CA stores for use with OnionKit, that utilize your own certificate authorities, or a custom rolled set.

Our goal is not to overwhelm the user, but instead to provide them a simple notification so they can understand which applications have their best interests in mind, and which do not. It is amazing how many popular mobile apps transmit personal information using HTTP completely in plain text, in the clear, allowing any number of parties along the network path between the device and server to passively vacuum up this data. Users generally are not aware or do not care about this issue. It is up to the mobile application developer, to adopt an approach like our Secure Connection Notification, or to directly utilize our OnionKit library itself.

Finally, we would like to see Android and other mobile operating systems, adopt a system such as this device-wide, such that it becomes as standard as the desktop web browser HTTPS lock.

If you are a developer, please check out OnionKit for Android today, and let us know what you think: https://github.com/guardianproject/OnionKit/