About backdoors in crypto messengers
blogs.fsfe.org
blogs.fsfe.org
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
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)
For iOS ChatSecure was just released with OMEMO support https://chatsecure.org/blog/chatsecure-v4-released/
Regarding desktop clients, I can recommand Gajim which also has a OMEMO plugin.
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.
It is still possible to run a phone with Signal without any proprietary google code on your phone (see: microG).
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.
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.
If you're considering Google an adversary, and use a version of Android without Google support, you can't use Signal anyway.
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...
Speak for yourself. This backdoor is the reason why I don't use Signal.
Why even use a phone?
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.
Neo900 looks pretty good for baseband isolation.
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.
A Motorola C139.
>Which custom device are you building?
A, uh, custom one.
>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.
firefox will never be better than mx or vlc for video. those apps should have chromecast support.
it's so hard to remove the gapp dependence used for that tiny feature that the icecat maintainers just gave up.
Is there open source alternative for Signal?
Edit: And server code under AGPLv3.
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
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.
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.
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.
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.
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.
That's like saying you shouldn't fix your leaking engine, if your brakes don't work.
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.
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?
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).
Except they're working on it right now: https://github.com/WhisperSystems/Signal-Android/pull/5962
Actual question: are google services not apps that run on android similar to other apps, within confined environments?
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.
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.
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...
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).
---------------------------
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.
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.