5

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.

Improve this question
2
  • In public key infrastructure, there always are things you need to explicitly trust. In the most well-known, TLS, for instance, there are a series of Root CA Certificate Signers that are explicitly trusted by the clients (by having their public keys in their truststore). This is unavoidable - the client must have a way of verifying the other party. This is normally done by an out of band method (like downloading a client that contains the public key from a source verified by TLS).
    – crovers
    Oct 12, 2016 at 20:43
  • Yes, SSL/TLS has root CA's and PGP has the web of trust. I wonder how clients in Signal implementations authenticate PK's? Do they use a WoT type of scheme? Are keys signed by some root key? Or is there a different mechanism? And can we verify that ourselves, like we can verify certificate chains and trust signatures? (Or rather: can we inspect the protocol on the wire so we can check the implementation does what the spec says?)
    – Evert Lammerts
    Oct 12, 2016 at 21:49

3 Answers 3

Reset to default
2

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.

Improve this answer
0

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.

Improve this answer
1
  • Yes, binary platforms are impossible to trust. But we don't need an audited platform running audited apps for e2e. (Even if we did have that, then e.g. identity exchange still exposes lots of attack vectors, with the possible exception of Zimmerman's ZRTP, but that's not going to be mass adopted). I think it'd be enough to have wire inspectability, ie be able use Linux + WireShark + OpenSSL + the Signal spec to sniff e2e traffic and verify it.
    – Evert Lammerts
    Oct 19, 2016 at 12:43
0

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/:

safety numbers

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:

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .