Hacker News new | ask | show | jobs
by petsounds 4502 days ago
Whisper Systems' headquarters is located in San Francisco, according to http://en.wikipedia.org/wiki/Whisper_Systems

Doesn't that make them susceptible to a search warrant forcing them to give up the private keys (or equivalent) to TextSecure, ala Lavabit?

4 comments

Yes it would make them susceptible...if, like Lavabit, they actually held private keys that secured your communications. They don't.

While I have the utmost admiration for Levison's stand, the fact that Lavabit held centralized private keys for its users was a very bad technical and security decision. Moxie has more about this here [1].

Now some may be wondering, what's to stop Whisper Systems from backdooring TextSecure by court order? In a word, this: [2]. The TextSecure client is open source. Not only can the community scan the source for something suspicious, but we can build and verify the binaries ourselves.

[1] http://www.thoughtcrime.org/blog/lavabit-critique/

[2] https://github.com/WhisperSystems/TextSecure/

The fact that the app is open source is nice, but realistically speaking very few users will build their own copy from source over just downloading an existing binary from Google Play or the Apple App Store. Nothing (but garden variety trust in the source of the binaries) is stopping a situation where there is a clean open source version and then a version with a backdoor built into binaries submitted to the app stores.

And even if you are one of those paranoid users who builds from source, a backdoored central build could still impact you personally unless you're sure everyone you are messaging has also built their own from clean source.

Personally I wouldn't worry too much about this scenario playing out, but I don't see that the client being OSS really buys you much safety practically speaking.

I think you're right that the scenario is unlikely to happen, and I think it is for this and related reasons an OSS client actually offers you a great deal of additional safety over a closed-source one:

1) It allows you to ensure that your personal copy doesn't contain code that does overtly malicious things, like backdoor your computer.

2) An open-source client may not be an automatic certificate of good faith, but a closed-source client is practically a certificate of bad faith/incompetence when your business is security. (indeed, this scenario is predicated on the vendor attempting to capitalize on that very fact - and even if successful, the base-rate probability is still massively in favor of OSS)

3) It is very difficult to hide malicious code in a binary for which the source is available for comparison. It is comparatively very easy to hide malicious code in a closed-source binary.

4) If there is cleanly-building source available, not only users but many vendors (including most Linux distros) will package their own version from that. Many people who don't build the source themselves will still get a clean version.

5) The risk of discovery would be high and the consequences, catastrophic. Sooner or later someone will compile your source, compare the result with your binary, and find something suspicious.

It is overwhelmingly unlikely that an attacker would opt for this strategy. OSS is much safer.

This is true, but at least it lets a small group of people do the verification work and post in a public place if the publicly distributed binary stops matching up with the one built from source.
Yeah, but you have to trust that someone (who is really independent and not in on the backdoor) is actually doing that. Also, the fact that all binaries distributed through mobile stores have to be signed with a private key makes this a more difficult proposition with mobile software than it is with desktop software. (Unlike desktop EXEs you can't just hash the resulting binaries).

I supposed you could pull apart the container format (apk or ipa) and compare the .class files (Assuming Java, I haven't looked at this software so I don't know if it is standard Android or a lot of NDK stuff) or ObjC object files one by one to look for discrepancies versus a local build using the same tools... hopefully someone volunteers to do that and keeps doing it again on each new release.

The Whisper Systems people and the community are already discussing this issue, at least for the released Android app:

https://github.com/WhisperSystems/TextSecure/issues/127

For iOS I believe that decrypting the binary and doing an objdump, then comparing the resulting assembly is a reasonable approach to ensuring that two builds do the same thing. Comparing objdump results won't protect against particularly insidious backdoors like those injected through data resources or binary headers, but in tandem with a source audit should give a fairly respectable degree of assurance.

This process would be quite easy to automate.

> For iOS I believe that decrypting the binary and doing an objdump, then comparing the resulting assembly is a reasonable approach to ensuring that two builds do the same thing.

Not a chance.

And if someone is doing this, we are well past "particularly insidious".

You have to trust everyone who claims the binary is clean, yes. But the vendor must also trust all these conspirators! And they can't bribe everyone - it only takes one honest guy with a decompiler and it's game over.
Debian SSL bug lasted a while.
It all comes down to the idea that if you the user have concerns with the app, you the user can take the approrpriate measures to verify, given enough time.
I know that I have grabbed the apk's from Google Play before and then decompiled them to compare with the original sources. What I did was compile my own version, then decompile it again and compare those source with the decompiled original sources.

There were some differences where the compiler/decompiler made a different decision, and that had to be checked out manually but in the end it was a pretty nice experience.

That sounds fascinating. Mind writing it up so others can do the same?
Awesome, thanks!
But what is the alternative to open source for securing communications? From my perspective, you've just described problems with commercial app stores, the extra effort required to build from source, build reproducibility, and the effort required to audit software. NSA and their global colleagues aren't going to simply go away due to having their activities publicized for the nth time.
Well, there's not really any practical alternative. And I do think it being open source is much better than it being closed source, as long as people are aware that ultimately unless you build it yourself you can never be sure of the security inside (and even if you do build it yourself, you have to be sure there are no subtle bugs either intentionally or unintentionally introduced).
It would be really nice if WS moved to deterministic builds. Really helps with not everyone having to compile themselves (if somebody is checking the source).
I don't think they retain keys, but aren't all the messages (encrypted) routed through their servers, giving them access to metadata?
Yes, but they mentioned the option of letting people run their own servers.
I'm pretty sure Whisper Systems never get any private keys, because the private keys are only stored on the end user devices.
Legal intercept legislation would likely require them to patch customer systems to allow the reporting of the key.
If you're really paranoid then you should build the code yourself from github, not just install the version on the play store.
In a compiler that was compiled by someone else. /tinfoil hat
That's why in the future we'll be using compilers which are open-source and using deterministic builds and double-compilation (or "n-compilation") : )
I recently discovered that there are no basic deterministic OS image builds (like a bootable .iso) with just a toolchain and wget and gpg and a shell.

I was surprised; seems like a good basic target.

Intercept legislation that applies to makers of non-interconnected (i.e., doesn't touch the PSTN) chat functions is extremely unlikely. I'm guessing whisper falls into that category.

I use Silent Circle myself, but I assume on Whisper you can't just type in a normal mobile number and have the chat message go to the right person. If you can, then those chats at least are subject to intercept, and maybe the other chats (whisper-whisper chats) are too. I don't remember how all those rules shake out/how courts have decided.

Wouldn't the relevant TLA just tell Google to enable the backdoor and then sniff the necessary keys from the device ...
Upon compiling TextSecure from source and installing it on my phone (I don't have the play store), I've discovered it requires the Play Store to do the "iMessage" style messaging over data. I guess the encryption is still done on-phone before being sent through whatever data API, but I still wonder if that (the play store being installed) might enable key-sniffing? Perhaps that's somewhat negated by users having a strong passphrase though?
That is Whisper Systems, not Open Whisper Systems. They are different.
Wrong, Whisper Systems is Open Whisper Systems but whether they are still located in SF I don't know.
Wasn't Whisper Systems/Moxie bought by Twitter some time back?
Kind of-- some older code was (is?) copyright WS, newer code is OWS, in both cases everything is GPLv3 and all future code will continue to be OWS & GPLv3.