Signal protocol implementations: pub key authentication and inspectability? (Allo, WhatsApp, FB messenger, Signal)

Question

A critical part of the Signal protocol, used by Google Allo, WhatsApp, Facebook Messenger and Signal, among others) is a public key infrastructure. Public keys are needed to set up sessions. As far as I can see, it doesn't specify a way to authenticate the keys. Ie, when Alice sets up a session with Bob, how can she be sure she receives his public key and nobody else's?

Secondly, assuming the above question has a satisfying answer, can we check what happens on the wire? Ie, can Alice (having access to her private keys) examine the protocol on the wire, extract Bob's public key and authenticate it by hand (fingerprint it, call Bob and ask him to compare)?

This probably differs per implementation, I guess. As a start, I don't see an answer in the WhatsApp encryption overview whitepaper. So how is this implemented?

In a broader context the real question is of course: to what extent do we need to trust the implementations, i.e. the service providers? Honestly, it's strange to me that there's so much fuss over these services being end-to-end encrypted; it seems to me (NOT an expert on the protocol!) that it's easy enough for the service providers to eavesdrop, if they'd want to. They may not want or intent to, but for whomever privacy is important enough, it's still a liability.

Answer 1

when Alice sets up a session with Bob, how can she be sure she receives his public key and nobody else's?

She currently can’t. (A better question would have been: how can Alice be sure that the client uses Bob’s public key for setting up the session, and not one of a malicious user?) The WhatsApp security whitepaper says:

For authentication, users can manually compare public key fingerprints through an outside channel.

There are two problems with this:

• Alice has to rely on the client to generate the public key fingerprint / QR code. You may see the problem with relying on the client to verify that the client is using the correct keys.
• Which brings us to the second problem: even if Alice can fingerprint the public key that the client stores for Bob without using the client, then how can she be sure that the client uses this key when she communicates with Bob, instead of e.g. using the public key of some malicious user? Verifying the protocol on the wire is what is needed here. The client being closed source doesn’t make things any easier either.

can we check what happens on the wire?

Not as far as I know. In the Reddit thread relating to this question, one commenter notes that better documentation for the Signal Protocol will be published soon. Hopefully this will help. But what we really need for this are detailed instructions on verifying the traffic.

to what extent do we need to trust the implementations, i.e. the service providers?

First of all, as far as I can see the Signal protocol includes basically everything that is required from an encryption protocol to set up secure e2e channels. If key exchange ever becomes secure, we have all ingredients needed for e2e communication.

But with the current implementations we’re not there yet.

So as an answer to this question, I’d say we should assume that the secrecy of our chat messages fully depends on the good will of the service providers.

Answer 2

Right now we need to trust implementation running on binary only platforms and no real way to make sure that all encryption, certificates and randomness is handled correctly inside of these 'binary delivered' systems. My belief is that what ever is created on iOS or Android and others, cannot be trusted and all end-to-end encryption is useless because end point security fails in big time. Due 'known unknowns' inside these OS's.

I've been contributing to project where we created external encryption device to be used with your apple or android. We compile Linux kernel 4.8, libraries and e2e encryption (with user handled PKI) from 100% source tree and replaces trust with an correct and audit able implementation. This, I believe is only way to approach answer to this question.

So run your encryption before it hits phones and networks, totally untrusted domain.

Answer 3

This question has been dormant for quite a while - but during the interim, Signal has come up with the concept of 'safety numbers'. Safety numbers are a unique fingerprint for a conversation, based on the underlying public keys of the participants in the conversation. Both participants can see the safety number for the conversation on their devices, and verify with each other through some out-of-band method (e.g. a phone call) that their safety numbers match, as can be seen in the image below from https://signal.org/blog/safety-number-updates/:

As can be seen, the safety numbers can be compared either numerically or using QR codes. If the safety numbers match, then this ensures that there is no MITM attack taking place.

For more info, see:

• https://signal.org/blog/safety-number-updates/
• https://crypto.stackexchange.com/questions/42993/how-does-signal-messengers-safety-number-works/93394#93394.