End-to-end authentication

We have stressed why end-to-end encryption is a necessary condition for protecting the confidentiality of exchanges. But we have also pointed out that it is not a sufficient one, contrary to what some loose explanations of the subject sometimes suggest. To understand why, one has to ask how this encryption is actually put in place, which requires understanding a fundamental notion: authentication.

In a messaging app, authentication is what allows a user to “know who they are talking to,” in other words to be sure of the identity of the people they are communicating with: who sent me this message? Who am I writing to? When this authentication depends on no third party, it is called end-to-end authentication.

The instructive case of email

With email, for instance, the user has absolutely no guarantee as to the authenticity of the source. It is very easy to send an email with a fake “From:” address, to make the recipient believe the message comes from someone else. This weakness in authentication is the source of a considerable number of the security problems users run into. Phishing attacks exploit precisely this flaw: by impersonating a trusted sender (a bank, an online service, the company’s CEO, etc.), the attacker leads the victim to reveal sensitive information or to take a harmful action.

To secure email exchanges, two solutions exist: S/MIME and PGP. Their approaches are diametrically opposed:

• S/MIME requires a certificate, issued by a “certificate authority,” whose purpose is to guarantee the link between a user’s email address and their public cryptographic key. This certificate is cryptographically signed by the authority, which thereby vouches for the legitimacy of that link. When you send an encrypted email to your recipient, you use the public key listed in the certificate associated with their email address. If the association is correct, only your recipient will be able to decrypt your message, since they alone hold the private key associated with the public key you used. The principle is simple but suffers from at least two problems:
  • the certificate often comes at a significant cost, which is legitimate, since the authority’s work is no small matter: it must rigorously verify that each user is who they claim to be
  • and the authority is a single point of failure: if its own security is compromised, the security of the system collapses for all users.
• PGP, on the contrary, requires no trusted third party. This system assumes that users exchange their public keys themselves. But how do you exchange those keys remotely? The answer is paradoxical: often by email, that is, over an insecure channel. The problem is that an attacker able to intercept that email can replace your public key with their own (a man-in-the-middle attack), and thereafter decrypt every communication meant for you. PGP obviously takes this situation into account: once two users have exchanged keys in an insecure way, they are expected to exchange a cryptographic fingerprint of their public key, that is, a string of 40 hexadecimal characters. This fingerprint is not secret; it simply makes it possible to check that the key received is indeed the one that was sent. The channel used to compare it therefore does not need to be confidential: it only needs to be authentic, a notion we will come back to. In practice, users can call each other (even on a tapped line) or meet in person. The most knowledgeable users have attended “key signing parties,” whose purpose is to physically gather PGP users (or rather users of its free implementation, GPG) in order, among other things, to exchange keys. GPG is free of charge and open source, but not very user-friendly. Fingerprint verification is optional and therefore rarely done.

The fundamental lessons to remember

Despite their respective limitations, S/MIME and PGP perfectly illustrate what cryptography makes possible, and what it will never make possible. To put it precisely, one must distinguish (at least) three types of communication channels:

• the insecure channel, which offers no guarantee at all (email, as we have seen);
• the authentic channel, which guarantees the identity of the other party and the integrity of the exchanges, but not necessarily their confidentiality (a phone call where you recognize your correspondent’s voice, even on a tapped line);
• and the secure channel, which adds confidentiality to authenticity (a private face-to-face conversation).

The purpose of a secure messaging app is precisely to establish a secure channel between its users. Everything rests on authentication: becoming certain that a cryptographic key really belongs to the person you think it does. And for that, there are only two possibilities:

• Delegate this verification to a third party, as S/MIME does with its certificate authority. The experience is seamless for the user, but if that third party is dishonest, or if it is compromised, the guarantee collapses: your exchanges may well be end-to-end encrypted, but without you knowing with whom, which defeats the whole purpose.
• Perform this verification yourself, end to end, as PGP proposes. That requires, on your side, a “manual” operation over an authentic channel: a physical meeting, or a phone call where you recognize your correspondent’s voice.

Relying on a third party often makes things simpler for the user, but that simplicity comes at a cost. A financial cost, sometimes: S/MIME certificates, as we have seen, are not free. And a security cost, always: the chain of trust now has one more link, which you have to take at its word, and whose compromise is enough to bring everything down.

There is no third possibility. This is not a temporary gap in cryptographic knowledge that future discoveries will fill. The reason is more fundamental: trust in the link between an identity and a key has to be anchored “somewhere.” Either you anchor it in yourself, by verifying that link over a channel you know to be authentic; or you anchor it in a third party, by relying on what it asserts. There is no third option, because trust cannot be manufactured out of nothing. This is true today, and it will be true tomorrow.

Fundamentally, this dichotomy separates two families of solutions: those that centralize security, by delegating authentication to a third party, and those that decentralize it, by placing end-to-end authentication in the hands of the users themselves.

Note that verifying keys yourself need not remain an individual affair: a contact whose key you have authenticated can, in turn, vouch for another user they have themselves authenticated. Trust then propagates from one contact to the next, over channels verified end to end, without the operator being involved: this is the principle of the “web of trust,” which we will come back to.

Without reliable authentication, encryption loses most of its value

Encryption is not an end in itself, but a means of guaranteeing the confidentiality of exchanges. Confidentiality only makes sense if you know who you are talking to. Yet encrypting a message first requires having the recipient’s public key. If the key you believe to be theirs is in fact someone else’s, the encryption, however strong, no longer protects anything: the message will be perfectly encrypted, but for the wrong person.

Consider the most common scenario, that of a messaging app that distributes keys through a centralized directory run by the operator:

1. Alice generates her key pair and publishes her public key in the operator’s directory.
2. Bob wants to write to Alice: his application asks the directory for Alice’s public key.
3. Bob encrypts his message with the key he received, then sends it.

As long as the directory really returns Alice’s key, all is well: she alone can decrypt. If, however, the directory sends Bob a key that the operator controls (in other words, one whose private key it holds) instead of Alice’s, Bob will unknowingly encrypt his message for the operator. The operator can then decrypt it, read it, re-encrypt it with Alice’s real key and pass it on to her. Neither Alice nor Bob notices anything. This is an attack known as “man-in-the-middle.”

The encryption is still technically “end-to-end,” but it has lost all meaning, since you no longer know who you are communicating with. This is why authentication is not an optional refinement, but what gives encryption its value. While Olvid enforces systematic verification whenever a contact is added, most messaging apps (such as WhatsApp or Signal) only offer optional verification — comparing with each of your contacts a 60-digit “safety number” — which the majority of users never perform.

The contrast with certificate authorities is worth pointing out. Their role is identical: to guarantee the link between an identity and a key. But they exercise it within a strict framework: independent audits, the requirements of browser and operating system trust programs, European regulation. A messaging app’s key directory takes on exactly the same responsibility, for billions of users in the case of WhatsApp, without being subject to any obligation of that kind.

Just as end-to-end encryption has become the norm for any messaging app that claims to be “secure,” end-to-end authentication should be too. One without the other makes little sense, since the point of end-to-end encryption is to protect against a potentially malicious operator, whereas without end-to-end authentication that same operator can bypass the encryption.

If you build a system where everything comes down to trusting the server, you might as well dispense with all the complexity and forget about end-to-end encryption.

Applying this criterion

✅Good if end-to-end authentication is systematic: it is not possible to add a contact without the link between that contact and their key having been verified, either directly by the user (over a channel whose authenticity they are sure of), or through a mutual contact, previously authenticated, who vouches for the introduction. In both cases, the chain of trust involves only users who have authenticated one another, never the operator of the service.