Some observations,
1. At this point its extremely hard to use XMPP - there are too many competing standards that implements encryption (of which a subset has forward secrecy), and if sender server doesn't implement any the other end does, usually falls back to plain text, one can disable it - but this is just too much overhead for a regular user. (food for thought [1])
2. Again, reminder from countless HN comments - there is a PR in works to make GCM optional[2], as soon as its merged, this will be solved
3. Maps seems to the real problem here: this could be disabled after 2? (otherwise, whats the point?)
Conversations is a great XMPP client. It works very well, support inline images, stream resumption and everything.
The OMEMO standard brings the Signal protocol to XMPP and it works great. I use Conversations for my hacker friends who refuse to install Signal (GCM dependency!) and surprisingly, I'm not missing a lot.
Now we only need a desktop client that supports the same features... And iOS (but TextSecure is making progress there)
The backdoor referred to can be applied to any Android app that uses Google Maps. Also mentioned is that using the built-in Google keyboard is a vulnerability, because in theory it gives Google the ability to keylog you.
I supposed this boils down to knowing your adversaries. If you number Google amongst that list, life is going to be really difficult - no matter who you are.
Yes, any app that uses Google Maps is backdoored, but a secure messaging app needs to be held to a higher security standard than any old app that uses Google Maps.
It is still possible to run a phone with Signal without any proprietary google code on your phone (see: microG).
I guess it mostly boils down to Moxie and his ridiculous claims of how much more secure Signal is when compared to other solutions (like XMPP and anything based on PGP).
Don't get me wrong, I understand the design and user experience decisions of making Signal depending on GCM but Moxie just loves to bash on XMPP and federated protocols and putting Signal on a pedestal of exemplary security.
I admire the dedication on putting together the Axolotl protocol but I hate when he mixes his business interests with secure crypto solutions, because by the end of the day that is what he wants, to sell Axolotl to companies like Google and WhatsApp. And of course, bashing on XMPP is just a business pitch to those companies.
It's not Moxie doing that, it's virtually the entire community of cryptographic engineers. And Open Whisper Systems is a grant-funded nonprofit that until recently could so barely afford developers they were considering withdrawing their iOS version, so the idea that this is all about Moxie's business interests is horseshit.
Indeed, but the point is that it's the combination of using GCM and their software that makes this a problem. Because not only does Google know what you're sending, but who you're sending it too, because they have both the OS and the network, they can correlate.
I mean yes, it's basically impossible to do this. Even if you used a completely free OS, you still have radio chips to contend with etc.
Actually, it is possible to use Signal on Android without Google using the opensource microG and Xposed framework (setup is a bit involved...but you can google that :P for a guide).
Even with stock Android, on devices != Pixel or Nexus, Google parts are sandboxed in a way making it hard for them to access private app data. The only way would be to deliver a different app through play store which is easy to discover as it breaks the cryptographic signature and must be done on first install (android uses TOFU).
So without the mentioned issues through Play Services and Gboard, Google would not be able to access your Signal messages. On Stock Nexus/Pixel builds they can of course push updates that change this...
On Pixel and Nexus, yes. for every other device it would require coop with the device manufacturer: they build the open-source code (+ their own proprietary extensions), add google apps and libraries (that are sandboxed) and sign the build. Only they have the private keys to provide updates, Google does not have full device access.
I don't use Signal because of Google Play Services, which is the backdoor this article refers to.
I'm reasonably confident that my phone's OS is uncompromised and I take the radio problem into consideration as part of my threat model and change my behaviors on my phone accordingly. I have also made some progress on using OsmocomBB as a radio baseband, and on building a custom phone that treats the radio as hostile and isolates it as much as possible.
>The phone network and the protocols for connecting to it are pretty user hostile no matter how open and secure the phone and baseband are though.
>Don't forget the SIM card runs its own insecure OS that people have hacked before and you just can't replace that.
Yeah, I'm keeping both of those things in mind. There won't be any assumption that your phone calls or SMS will be secure, but rather that your mainboard OS is secure _from_ the radio and that you don't have to worry about discussions had near your phone and such.
So we should just aim for no security at all then? Why is it that every time someone points out a security flaw, people say "well then don't use a phone?" As if we shouldn't strive for improvements unless everything is 100% secure.
for the record, firefox for android also integrates the google backdoor for the sole purpose of allowing chromecast for videos... which zero users use or want.
Matrix is decentralized, proper open source, modern, has audited end-to-end encryption and all that. Be aware that if you install the Riot app from the Play Store, it uses GCM (which means that client is technically vulnerable to the same attack as described in the article), but if you install it from F-Droid it does not.
One strength of Matrix over Signal is indeed that you are free to choose or develop your own client to use with it. You can also host your own server for the decentralized Matrix network, but that point is kind of orthogonal and not related to this specific issue.
well LibreSignal was shut down because Moxie didn't like them using WhisperSystem's servers. I guess the libre community could figure out how to setup and fund an alternative server, but since Signal's server code isn't federated, then I don't believe there would be a straightforward way to send messages between the two systems.
The Signal server code has supported federation since the first commit in the git history. Whisper Systems' instance of the server doesn't federate with any other server anymore but there is nothing stopping the LibreSignal crowd from standing up their own network of federation-enabled servers.
Moxie and Whisper Systems is clearly against decentralization and federation, based on that blog post they wrote. This means it's unlikely that Signal is ever going to have any support for federation.
> This means it's unlikely that Signal is ever going to have any support for federation.
Signal had support for federation. Their server was federated with Cyanogen's for a while[0]. That being the disaster it was is why that blog post happened and no one seems to be forthcoming with solutions to the problems they had.
Obviously they can run an alternative server, and if their version is sufficiently more attractive people will switch their client.
They could 'solve' all these usability problems, fix the use of google interfaces the tin foil hat brigade detest, and deploy it on a non-existent non-proprietary secure phone platform. Oh and make it federated but keep it immune from spam. Yeah, seems like that is a bit hard.
True, but you still need to be aware of who your potential adversary is. If it is someone with access to SMS network texts logs, these encrypted texts will light up like a Christmas tree for someone looking for something unusual.
The threat model is that google and cell phone networks are untrusted adversaries. So your same concern can be said about Signal messages going through Google servers under the surveillance of the NSA. Either way the adversary sees a bunch of suspicious encrypted messages, but can't read them. But if the user has proprietary google code installed on their phone (i.e. Google Play Services), then the backdoor which this blog is warning about is the fact that now your phone software is/could be potentially compromised.
It depends on who you are hiding from. In some freer countries, encrypted texts at most get you flagged on some kind of list. In others you may get enhanced interrogation.
This would arguably be more secure. Depends who you trust least I guess, Apple or Google + OEMs. I think Apple has a lot to lose if they were to produce a backdoored firmware. Some android handset contract manufacturer or OEM? Not so much.
People seem to love analyzing security of tiny corners of systems while ignoring the rest of the system, and entirely avoiding figuring out a scope for the security.
The post complains about Signal using a Google service, that Google could utilize (either now or through an update) for malicious activity. A Google service that without a fair share of poking around is only available on Google versions of Android. I mean, what.
While this is a more serious problem than the usual whine about GCM (Yes, notifications can give a lot of info, but in case of Signal, the info given is "You received something from some Signal user while you were offline"), it is still amazing how blind the analysis seem to the environment. If you cannot trust Google to provide a "non-evil" Google play services, why the flying fuck do you think the Google-provided (or manufacturer-under-tight-google-control-provided) OS is fine? They could backdoor the process isolation and poke around at Signal memory if they felt like it.
Now, if you are security conscious and willing to let go of the conveniences of selling your soul to Google, you would be running a non-Google'd version of Android without Google services. Your only valid complaint in this case, is that Signal depends on Google services to operate, which makes you unable to use it (without hacking Google back into your Android version, but if you do that you might just as well stick to a Google version).
Oh, and what about the black box binary drivers you are using on your super-secure handset? Baseband? CPU (ME anyone?)? SIM card?
Before you talk about security, figure out what you are trying to protect against, and start from the top. You look like an idiot if you complain about breakable windows but do not notice that the door is open.
>If you cannot trust Google to provide a "non-evil" Google play services, why the flying fuck do you think the Google-provided (or manufacturer-under-tight-google-control-provided) OS is fine?
Because the likelihood of an a-priori exploit hidden in AOSP is far more remote than the possibility of malicious exploitation, at some point in the future, of the gaping wide security hole that is the "give Google root" subsystem.
>Now, if you are security conscious and willing to let go of the conveniences of selling your soul to Google, you would be running a non-Google'd version of Android without Google services. Your only valid complaint in this case, is that Signal depends on Google services to operate, which makes you unable to use it (without hacking Google back into your Android version, but if you do that you might just as well stick to a Google version).
Yup. And that's unacceptable. You can't really claim to be security conscious if your product comes with the stipulation that you give a megacorp root on your computer, can you?
> Because the likelihood of an a-priori exploit hidden in AOSP is far more remote than the possibility of malicious exploitation, at some point in the future, of the gaping wide security hole that is the "give Google root" subsystem.
I am not talking about AOSP. AOSP does not ship Google Play services unless you try to squeeze them in yourself (which would be silly - why would you run a google-clean system and stuff google back in?). I am talking about versions of Android that come with Google Play services - that is, Google shipped or manufacturer-controlled-by-google shipped.
(I sense that I may have misunderstood your point)
> Yup. And that's unacceptable. You can't really claim to be security conscious if your product comes with the stipulation that you give a megacorp root on your computer, can you?
Indeed it is unacceptable. However, Signal on a Google-powered android system is no less "backdoorable" if you avoid Google Play services. The only way out is to take a Google-less Signal, and put it on a Google-less Android. This is where OWS can start to get on my nerves, because they indeed do not want to make a google play services free version (Even if you do not care about security, you might care about the compatibility), and that they effectively took down libresignal.
Their reasons for doing so were sound (dealing with uncontrolled, potentially borked clients on a protocol and service that is still evolving is quite a pain), but they could quite easily have abstracted these things away in the official Signal implementation so that things could work both with and without, especially seeing how security oriented they are.
However, my problem with this post was that it took a Google Play powered signal on a Google powered Android, and started poking at how Google could backdoor Signal, when the ENTIRE system is under Google's control. I'm not saying that this does not matter until we have solved world hunger, I am saying that fixing this specific instance of the problem (Google Play services dependency of Signal) does not solve the specified problem at all (Google backdooring of Signal).
Yes, it is isolated with interaction through IPC and intents, although Google Play Services have a lot of permissions, it is a normal "app". To communicate with it, you use a Google-provided, obfuscated library which potentially could be malicious.
However, the "real backdoor" mentioned is in a component that is loaded dynamically when Signal prepares a MapView. The dynamic load means that Google can change what is loaded into the Signal app in the future, unlike the Google API client which while potentially malicious, is static until OWS updates it.
Yes, although the system can be modified to permit it.
Also, google play services require a library to use, and this library runs in your process. Likewise, the dynamically loaded mapview problem takes some external code and stuffs it into your process.
I'm saying that if you're trying to fix an engine leak, start with the giant hole in the block from the anti-tank round that was fired at point blank at it instead of starting with the leaking gasket.
Signal is told to be a secure crypto messenger everyone can use. This means that people are installing it on a usual Android device and assume that nobody is able to read their messages without physical access.
Of course you are right, there are many black boxes in most mobile devices. But does this mean we shouldn't care about any of them? Most of these black boxes are not updated on a regular basis or the update requires user consent. This means that, if they don't allow arbitrary code execution now, it is hard to make them do evil things.
The mentioned issue with Google Maps integration (leave the GCM problems aside) however is a real possibility to silently drive targeted attacks on Signal - it's actually damn easy for Google to do this. If we'd be doing a proper analysis on all other black boxes (processor, modem, manufacturer extensions, etc), I doubt we'll find such kind of backdoors in most of them. And if I will find such a thing, be sure I'll be writing about it as well.
This backdoor is important for those that want to securely communicate and their adversary is for example the US gov. e.g. the next Snowden. Google can be forced by US agencies to use this backdoor and this renders Signal unusable for them. These people should know about the backdoor. If you know and don't care, that's your problem...
If you are running an Android version that legitimately bundles Google Play, the Android release itself was either directly shipped by, or shipped by someone controlled by Google.
I am not saying we shouldn't care about problems because there are bigger ones. However, if the problem you are trying to fix is "Google is capable of poking around in your running instance of Signal" (That is, what the map trick is potentially capable of), then removing any Google integration from the Signal app will not help as long as you still run on a Google-controlled Android release.
The only unique thing about this specific Google dependency is that it is more dynamic than the OS, but as long as Google owns your OS, they have every possibility of monitoring your process memory. That's before you start worrying about the black box proprietary drivers most ARM devices use and all that jazz.
My complaint lies in that fixing this will not improve the security by any noticable measure (that is, no noticable reduction in Google's capability of reading process memory of your instance of Signal) for any of the current Signal users (which are implicitly Google Android users, although a some instances may be non-Google + google services manually patched in). The primary benefit is that some people that cannot currently run Signal due to the dependency can join while maintaining the non-Googliness of their system.
Manufacturers that ship GMS are not controlled by Google. I think you don't know a lot about how to apply for GMS integration, it's as easy as filling a form and passing the CTS (compatibility test suite).
Google is providing some non-free files (basically apps and libraries, all sandboxed) and configuration files to manufacturers that they apply on top of AOSP (or possible extensions they did). The only way for Google to break out of the sandbox is to make a backdoor in the AOSP code, that is openly available for review.
To repeat what I said to the other guy here: If you are not on a Nexus or Pixel device, Google is UNABLE to look into private app data of third-party apps (if they correctly configure the backup feature). This is possible with Signal only due to the mentioned "backdoor", making this an important issue.
You are however right that the manufacturer(s) might be able to look into app's private data, but that's another issue (especially as most manufacturers are non-US companies).
>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.
---------------------------
Glad someone points out the technical details of why many people had doubts about signal. Unfortunately, Moxie will dismiss it, and his following will claim "it affects other apps too" as if that makes it any better. "Other apps do it too" is not the standard a "privacy" app should aim for.
It difficult to see how a service that ties to your phone number can make any claim about privacy halfway seriously. This is reckless.
And worse tie itself to a company whose business model is based on creepily stalking you all over the internet and getting users psychologically accustomed to the fact they are under surveillance. These are serious escalations that go unnoticed because SV has become a magnet for those who want to profit from it.
A half way serious and sincere effort will be open source, not tied in any remote way to known surveillance companies, and based in a country that genuinely respects privacy.
2. Again, reminder from countless HN comments - there is a PR in works to make GCM optional[2], as soon as its merged, this will be solved
3. Maps seems to the real problem here: this could be disabled after 2? (otherwise, whats the point?)
[1] https://whispersystems.org/blog/the-ecosystem-is-moving/ [2] https://github.com/WhisperSystems/Signal-Android/pull/5962
edit: formatting, forward secrecy not e2e