About backdoors in Signal and other apps

… or why it’s useless to have the most secure crypto system in the world, when using non-free and untrustworthy tools and libraries to implement it.

tl;dr: There is a “backdoor” in Signal nobody cares about, only Google can use it.

This blog post was updated several times to add additional explanation and make it easier to understand for people that do not know a lot about the Android platform. The changes are always highlighted accordingly.

Recently, there was a huge discussion about a possible backdoor in the crypto code of WhatsApp, which finally led Moxie Marlinspike, the developer of the Signal crypto messenger to an interesting statement.

We believe that WhatsApp remains a great choice for users concerned with the privacy of their message content.

So, what you want to say me is that Signal is essentially useless, because WhatsApp is as good? So why don’t stop Signal and join forces with WhatsApp?

If you use Signal, you probably would not want that: Signal is an open-source messenger, well audited and suggested by major security and privacy experts. WhatsApp however is closed-source and owned by Facebook.

If you think the same about Signal, I have to tell you, that you’re wrong. Well beside the point about Signal being suggested by several widely known people: While Signal is indeed open-source, it is still not free software because it uses an external library that is not open. So every audit that works on the source code will fail to find security issues and backdoors in that externally included code – and this is where I want to start to look into Signal now.

Google Play Services

Google Play Services consists of numerous features and thus the library that may be included is separated into multiple parts. To stay with the Signal example, it includes the parts for using Google Cloud Messaging, showing a Google Map and asking the user for it’s current location (ref). All three work differently and obviously all of them leak certain data to Google, usually via TLS encrypted connection that does not use pinned certificates. For further analysis, we consider Google to be the evil party (which they might become due to US law enforcement) and every Signal user uses Signal on a default Android system (as shipped with a device).

EDIT: In a previous version of this blog post, the following two sections were in reversed order. People seem to stop reading when they hear about sth. they already know, even if new points might come later, so I decided to reorder…

Maps Integration

After selecting to share a location, Signal shows a small map with a pin on the selected location. After the map is loaded, a screenshot of it is sent as an image to the other side, together with some string describing the location.

The relevant thing here is the displaying of the map. This is done by embedding the MapView when displaying a conversation, and showing it up when there is something to show. This means the MapView is already initialized when opening a conversation in Signal. Critical about this is that the MapView view as used by Signal is just a wrapper that loads the actual MapView, by including code from the Google Play Services binary (which means code outside of the apk file you meant to use). This code is included by calling the createPackageContext-method together with the flags CONTEXT_INCLUDE_CODE and CONTEXT_IGNORE_SECURITY. The latter is a requirement as the android system would deny loading code from untrustworthy sources otherwise (for a good reason). The code is then executed in the Signal process, which includes access to the Signal history database and the crypto keys.

The Google Play Services binary can easily be updated in background through Google Play Store, even targeted to single users, and the updated code would become active inside Signal the moment you use it next time. Can it get worse? Yes. An apk update would be detectable to the user, but Google Play Services uses a dynamic module loading system (called Chimera and/or Dynamite) that seems to be capable of replacing the Maps implementation from a file not installed to the system, as long as it’s signed by Google. If it is possible for Google to push an update only for this module and remove it later, it might be possible for them to inject code into the Signal client that uploads your complete local chat history unencrypted and afterwards removes all signs of it’s existence.

What does “seems to be able” mean? Well it’s hard to determine exactly. The relevant binary is highly obfuscated and thus hard to understand. Maybe someone wants to waste his time on this, but remember it can be changed in the next release again…

Google Cloud Messaging and other METADATA

Signal uses Google Cloud Messaging (GCM) to transfer information about incoming messages to the client. These packets send from Signal servers to devices using GCM contain no valueable data (no text, not even encrypted strings, only a friendly ping). However they are metadata. What kind of metadata is in there? It is just the information that there is a new incoming message, what’s so wrong with it?

Well, you need to consider that Google knows a lot about everyone. The usual Android user will grant Google access to his contact database, list of installed apps, when which app is started, your current location, which text you write using the devices virtual keyboard (when using the “Gboard”) and even more. For most of this data, current implementations will share only a certain amount of it to Google servers and keep some of the analysis on the device. However if Google is the attacker all of this belongs to them and depending on your privacy settings, quiet a lot of it is already available to them.

So, when using Gboard, Google already knows the content of the messages shared, but not the recipient. And this is where the GCM data can be used. It shouldn’t be too hard to correlate the fact that one user is sending a message via Signal to another user receiving it. Sending is easily known due to the app being active on one device (information Google collects for statistical reasons). With Gboard active, Google even knows the exact moment the message is sent (enter key is pressed). Of course there are millions of Signal users with different users likely sending messages in approximately the same time, but it’s no problem if you need multiple messages to be sure and there is another bunch of information further restricting the search space: both users likely have the phone number of the other one in their phone’s contact list and Google is usually well aware of the contents of your contact list.

EDIT: Even when not using Gboard, the issue with GCM metadata + contact list + app in foreground is still present and thus makes it possible to gather the information who is chatting with whom at what time. Without using GCM, this data would be available to the Signal server operator only, by using GCM, Google gets it as well.

You can hardly name this thing a backdoor? But metadata can still kill you.

Backdoors everywhere (?)

The same details also apply to every app that uses the here mentioned parts of Google Play Services. I don’t know all the crypto messengers, but WhatsApp seems to be affected by exactly the same issues and probably some other messengers too.

But, is this really a backdoor? The feature that allows Google to update libraries without users consent is not really a backdoor, but more a security feature. Of course the fact that it’s not possible to disable it is bad and maybe it should not execute its code in the sandbox of the app, but rather in a separate sandbox. But I bet, when Google set up this system, they had no intention to add a backdoor, neither did Signal or WhatsApp. They just wanted to make it user-friendly – but unfortunately user-friendly and secure are still not available in combination.

But Signal is Forward secret, You can’t read old messages

The forward secrecy feature is only on the transport level. At both ends (in groupchats, all ends) the messages are available in plain text in form of a history. If you or the other(s) don’t wipe your chat history regularly, your history is still attackable. But this is how users want it, because it’s more user-friendly.

EDIT: This is not a huge problem, if the operating system ensures that data of other apps is not easily reachable, which Android does. And this is the reason why the aforementioned backdoor is in fact important: without this backdoor, Google would not be able to read your messages, due to it they are.

Did you know that you can have forward secrecy in TLS as well? This means that if you have proper TLS encrypted links in a highly federated network (using a protocol like XMPP) you can have forward secrecy as well.

Fixing it

This is not primarily about a specific problem. The problem is that you just can’t trust a messenger that is – even partially – non-free software. Signal is, WhatsApp is, Facebook Messenger is, Google Allo is. Deal with it!

You can of course also fix the Signal app. LibreSignal was a fork of Signal that does not use any Google services and thus does not suffer from the problems mentioned, but releases were halted following WhisperSystems request to do so.

Or you just switch to a better system. As mentioned XMPP can be used with forward secrecy. XMPP is a federated system where users can set up their own servers, write their own clients. It’s about moving trust away from large US companies and to people next to you that you actually can trust. If you can trust your and the other’s XMPP server provider as much as you trust Google and the servers are properly set up, you can just use XMPP over TLS even without OTR/PGP/OMEMO (which all are crypto systems on top of XMPP) and reach the same level of secrecy as with Signal. Set up your very own XMPP server and use a Google-free Android device and you can communicate even more secret then with Signal. Fantastic, isn’t it?

No, I’m not going to make this an ad about microG.

14 thoughts on “About backdoors in Signal and other apps

  1. This is probably a good moment to mention Kontalk. An Android IM app based on XMPP that uses phone numbers to be simple to use like WhatsApp and Signal, but only optionally uses Google Play (the F-Droid builds do not).

    While currently still lacking group chats in the latest stable release, it is available in beta releases and should be publicly available soon(TM).

    My personal preference is still XMPP with OMEMO (using Conversations and Gajim) because of the security and multi-device support, but Kontalk is great for Android-based chats with non-technical users.

    • You mentioned the ease of use of Kontalk, which is indeed an important point – not everybody out there is willing (or capable) to configure Conversations o Gajim.
      Well, I have good news: Just three days ago I asked Daniele of the Kontalk devteam whether further integration into the XMPP network plus implementation of OMEMO (both they announced for 2017) would mean, that users of Kontalk will be able to exchange e2e encrypted messages with users of Conversations, ChatSecure or Gajim. And yes, he is very optimistic about it.

  2. “So, what you want to say me is that Signal is essentially useless, because WhatsApp is as good? So why don’t stop Signal and join forces with WhatsApp?”

    WhatsApp uses the Signal protocol.

    • Don’t mix up crypto protocol, network protocol and app. WhatsApp uses the same crypto, but that doesn’t mean the network protocol or app are the same.

      That’s like saying Skype and XMPP are basically the same, because both use TLS.

        • I answered on the linked website.

          The double ratchet is a sort of transport encryption as well. It does not say anything about what is encrypted and theoretical you could also put HTTP through it. So, while used differently (double ratchet is usually used for e2e whereas TLS is not), both can provide similar features (TLS also supports client certificates). Double ratchet is just more suited to the asynchronous messaging style we usually see in mobile instant messaging.

  3. Signal is looking to get away from google cloud messaging as other people already brought that up. Currently copperheadOS packages noise (a fork of signal without google play services) that works just fine, been using it for awhile. and the creator of Signal said that later editions of signal would figure out a solution to that problem.

    • Yes, but removing the GCM dependency does not mean that the Maps-based backdoor is gone. As the GCM problem is already about to be tackled, it’s even more important the emphasize other problems.

  4. recently some said on Medium that Wire is better than Signal because it use the Signal protocol while does not require a mobile number (a big advantage for certain countries’ users where one mobile number reveals too much) to register like Signal. Also, Wire does give an apk for android setup, instead of Google play store. Could this be seen as avoiding the issue you brought up?

    Wire concealed the no-mobile number registration option on their mobile app currently so No, I’m not going to make this an ad about it, really.

    • Wire is affected by the Maps backdoor as well, but apparently it can only be used if you open the location sharing dialog. AFAIK, you can disable GCM in Wire to combat the GCM issue.

  5. It doesn’t matter if you’re using an open source app or not if you’re on a compromised OS. If Google is your adversary, they don’t need to patch MapView to be malicious, they have root. They can upload your sqlite files or take screenshots. They can do that for Whatsapp, Signal and Conversations alike. They can log your keystrokes. They can insert a logging hook into TextView. Should apps stop using TextView too?

    Please don’t take it as a defense of Signal.

    • Google does not have root on the devices. Google’s apps are sandboxed as every other app (although they have some permissions usual apps can’t have, like the ability to install app updates in background). Google’s libraries are only available when explicitly requested by apps and thus can not influence the app security if not requested. To access your private data / use root permissions, Google would be required to use an unpatched critical security issue or a hidden backdoor in the AOSP code. This, although possible, is very unlikely to happen, as it would open the same door for a malicious third-party app. (On stock Pixel and Nexus phones, Google can push updates that divert from AOSP and contain a hidden backdoor). Google is also able to read private app data on apps that use their backup feature, but this is disabled in Signal (I guess for exactly this reason).

      This means, that without the MapView issue, Google is not (or at least very unlikely) able to read into Signal’s private storage and thus won’t be able to directly snoop into your history or grab your crypto keys.

  6. from the blog we can read very well the position “politically correct” of Moxie.
    open source is not important!!!!! signal is only a playground for cryptonerd!!!
    Zuckerberg metadata we know. don’t ask to explain to simple people.!

    -waiting for a Google free push we use a firewall to block all others app. we lost push, but we try to survive.just click by your finger every 30 minutes.

  7. @harold from 31. Jan 2017
    Could you please rephrase what you tried to express?
    Maybe I’m too stupid but I can’t make any sense to it. Thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>