Et Tu, WhatsApp

The “unthinkable” has happened: it is alleged that WhatsApp has a backdoor in its end-to-end encryption, and nobody has actually been getting any security all along. All of this while using  the acclaimed “open source” Signal protocol. This article will not break any news, but hopefully will make you think and be safer as a result.

Hint: it has all to do with the quotes in the first two sentences.

Quick recap first. January 13th, 2017, articles like this one reveal that WhatsApp, the popular messaging app, seems to have the capability to add encryption keys for offline users to any given conversation. This is the sanitized, technical language. In practice, it means that there is a way for messages to be decrypted by a specific third party, simply by adding their key to the encrypted message, without the main parties knowing about it. This is commonly known as a backdoor, which FBI’s Director Comey pushed for on every encryption product available in the US just last year, and is enshrined in a new law in the UK, to say nothing of places with a less stellar record on citizen privacy. But WhatsApp’s end-to-end encryption is based on the critically acclaimed Signal protocol, and it was presented with much fanfare and plenty of oohs and aahs a couple of years ago. The creators of Signal, of course, vehemently deny that this is a backdoor in WhatsApp. What happened here?

Well. . . perhaps the “unthinkable,” which I’m placing in quotes because it is actually not so hard to think of: one thing is code shown on a display case, and quite another code actually running in a computer. The code shown to the public has no backdoors, but the running code might have them. “Open source” doesn’t necessarily mean “actual code.” Surprised?

I’ve said it before, but it bears repeating here given the seriousness of this breach of trust. I’ll put it in capitals to help it sink in: SERVERS ARE NOT TO BE TRUSTED. You can’t see what’s running in a server; it could be running precisely what you don’t want and you’ll never know about it. The moment you involve a “trusted” server in an app or program, and you give it something that needs to be secured, you have in fact forfeited all security.

This is a flaw shared by all server-based solutions. Even the Signal app itself, which so far has been cleared of the charges leveled against its cousin WhatsApp, can be subverted just as easily. Just enter their server by legal or illegal means (software is agnostic about human ethics), and you can make it do exactly what WhatsApp has been doing, or worse. It could be its X3DH key agreement protocol, which relies on a server to store ephemeral public keys (authenticated by a separate channel) and delete them after use so others can’t impersonate their owners. It could be a software update that changes the processing on your very machine (can you read that, either?) so it adds a backdoor before anything else. It could be a dozen other things.

I know this because I was tempted to do it to PassLok only a couple years back. This is when terrorists in San Bernardino had been using a locked iPhone and the FBI was all in a fuss about reading what they might have said. PassLok uses pretty much the same cryptographic primitives as WhatsApp, and it is therefore possible to add a trusted recipient (law enforcement?) to all encrypted messages, even without involving any servers. The trusted recipient could then use its private key to decrypt the messages, just as if it had been encrypted for them. I thought about doing this while in a bout of concerned citizenship, but in the end I concluded that it would be a very bad idea, and so PassLok remains backdoor-free to this day and will remain so as long as I’m in charge of it and the code is public. And, since there is no server and the running code is visible to anyone who may want to look under the hood, you’ve got a pretty good assurance even beyond that.

PassLok is also more secure than Signal because it does not store secret material beyond the message where it needs to be used, which also lessens the “need” for a server (there’s never any real need for a server; everybody else uses a server so they can make money off you). In PassLok’s Read-once mode, a new Diffie-Hellman ephemeral key pair is generated for each outgoing message, while Signal does that only after a message is received. In PassLok, the Diffie-Hellman operation itself is of the old-fashioned Alice-and-Bob-and-nobody-else sort, rather than Signal’s X3DH protocol with a server holding extra keys.

Practical conclusion: use PassLok. You can find links to all its varieties at passlok.com, including Chrome and Firefox extensions that integrate it directly into your web-based email so it is available any time you want to use it but otherwise stays out of the way.

Leave a Reply

Your email address will not be published. Required fields are marked *