Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

About backdoors in crypto messengers

blogs.fsfe.org

Post reply on HN
Print view View original

61–70 of 71 posts

Re: About backdoors in crypto messengers

#61

Post by temprature »

vurpo wrote: post #57
em3rgent0rdr wrote: post #36

Earlier quoted context omitted.

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. https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

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.

[0] https://whispersystems.org/blog/cyanogen-integration/

Re: About backdoors in crypto messengers

#62

Post by thinkloop »

arghwhat wrote: post #54
thinkloop wrote: post #53

Earlier quoted context omitted.

> They could backdoor the process isolation and poke around at Signal memory if they felt like it. Actual question: are google services not apps that run on android similar to other apps, within confined environments?

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 l…

Ty. In that case, specifically regarding poking in memory, isn't that not possible regardless of how malicious the program is?

Re: About backdoors in crypto messengers

#63

Post by larma »

tokenizerrr wrote: post #29
larma wrote: post #20

Earlier quoted context omitted.

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 a…

They can patch the sandbox out in an update, right?

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.

Re: About backdoors in crypto messengers

#64

Post by larma »

arghwhat wrote: post #35

tl;dr: this is stupid. 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 ver…

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...

Re: About backdoors in crypto messengers

#65

Post by BjoernSchiessle »

lima wrote: post #28
dbalan wrote: post #23

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 -…

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 makin…

> Now we only need a desktop client that supports the same features... And iOS

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.

Re: About backdoors in crypto messengers

#66

Post by arghwhat »

larma wrote: post #64
arghwhat wrote: post #35

tl;dr: this is stupid. 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 ver…

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 re…

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.

Re: About backdoors in crypto messengers

#67

Post by larma »

arghwhat wrote: post #66
larma wrote: post #64

Earlier quoted context omitted.

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 re…

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 potenti…

> someone controlled by Google

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).

Re: About backdoors in crypto messengers

#68

Post by BuuQu9hu »

Sir_Cmpwn wrote: post #26
BuuQu9hu wrote: post #25

Earlier quoted context omitted.

Which device are you using OsmocomBB on? Which custom device are you building? 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.

>Which device are you using OsmocomBB on? 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 i…

Make sure it is secure from the SIM card too.

Re: About backdoors in crypto messengers

#69

Post by arghwhat »

thinkloop wrote: post #62
arghwhat wrote: post #54

Earlier quoted context omitted.

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 l…

Ty. In that case, specifically regarding poking in memory, isn't that not possible regardless of how malicious the program is?

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.

Re: About backdoors in crypto messengers

#70

Post by gcb0 »

angry_octet wrote: post #44
gcb0 wrote: post #27

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.

Speak for yourself, Chromecast is very useful. Though obviously you should be able to turn it off.

it is usefull but not in a browser.

firefox will never be better than mx or vlc for video. those apps should have chromecast support.

Post reply on HN