"Modern Intel chips support a feature called Software Guard Extensions (SGX). SGX allows applications to provision a “secure enclave” that is isolated from the host operating system and kernel, similar to technologies like ARM’s TrustZone. SGX enclaves also support a feature called remote attestation. Remote attestation provides a cryptographic guarantee of the code that is running in a remote enclave over a network.
Originally designed for DRM applications, most SGX examples imagine an SGX enclave running on a client. This would allow a server to stream media content to a client enclave with the assurance that the client software requesting the media is the “authentic” software that will play the media only once, instead of custom software that reverse engineered the network API call and will publish the media as a torrent instead.
However, we can invert the traditional SGX relationship to run a secure enclave on the server. An SGX enclave on the server-side would enable a service to perform computations on encrypted client data without learning the content of the data or the result of the computation."
https://signal.org/blog/private-contact-discovery/#trust-but...
I don't know if they've got that in production yet - and I don't know just how strong the "cryptographic guarantee" of the secure enclave code is, but the fact that they're trying it fills me with joy...
And of course for major apps, there are people doing so.
Have you tried this? Most people seems content that there is some source available and trust the binary. That may not be an option for everyone.
There's a non-zero number of people around the world who check the builds. Your security rests on the difficulty of feeding you a subverted APK without feeding any of them the same APK.
If the attacker can identify your devices 100% precisely, just one device, then the rest doesn't really matter. But if the attacker has incomplete information or a coarse attack vector, then others must be attacked along with you. For example, if the attack works by putting a subverted APK on one or more CDN nodes, then everyone else in your geographic area gets the APK along with you.
If there's one person who gets the subverted APK and checks it against the original, the attacker's attack is public. If there's one person who automatically uploads all new installed APKs to apkmirror.com, then the attacker's attack is public. See?
There is (AFAICT) no single list of people who would discover the attack, and who therefore must be avoided by the attacker.
Now, if the attacker is willing to have the attack revealed a day after it happens, this may be acceptable. But otherwise, the attacker has to find a way to target you and avoid any false positives who might do that checking.
https://github.com/signalapp/Signal-Android/wiki/Reproducibl... is a thorough recipe, but I didn't actually do all of that. I had the right build environment anyway.
However, a few points to consider:
1. The signal server can't "see" the group. Clients are just sending N messages to everyone in the group with some encrypted metadata that says it's a group message.
2. The client app is open source. You can go look for a ghost user or backdoor mechanism yourself.
3. The build is reproduceable. You can build it yourself and sideload your own APK, or compare it to the APK coming from the play store.
I don't think it's impossible to put a backdoor in, but I think it at least makes vigilance a good defense. Smart serious people are paying attention.