Authentification de bout en bout

Nous avons souligné pourquoi le chiffrement de bout en bout est une condition nécessaire afin de protéger la confidentialité des échanges. Mais nous avons aussi fait remarquer qu’il ne s’agit pas d’une condition suffisante, contrairement à ce que laissent parfois supposer certaines explications approximatives sur le sujet. Pour le comprendre, il faut se demander comment ce chiffrement est mis en œuvre. Cela passe par la compréhension d’une notion fondamentale : l’authentification.

Dans le cadre d’une messagerie, l’authentification est ce qui permet à un utilisateur de « savoir à qui il parle », autrement dit, de s’assurer de l’identité de ses interlocuteurs : qui m’a envoyé ce message ? À qui suis-je en train d’écrire ? Lorsque cette authentification ne dépend d’aucun tiers, on parle d’authentification de bout en bout.

Le cas instructif de l’email

Dans le cas du mail, par exemple, l’utilisateur n’a absolument aucune garantie sur l’authenticité de la source. Il est en effet très facile d’envoyer un mail en indiquant une fausse adresse « From: », afin de faire croire au destinataire que le message reçu provient de quelqu’un d’autre. Cette faiblesse en termes d’authentification est la source d’un nombre considérable de problèmes de sécurité rencontrés par les utilisateurs. Les attaques par « phishing » (hameçonnage) exploitent très exactement cette faille : en usurpant l’identité d’un expéditeur de confiance (banque, service en ligne, président de la société, etc.), l’attaquant incite la victime à révéler des informations sensibles ou à commettre une action dommageable.

Pour sécuriser les échanges par email, deux solutions existent : S/MIME et PGP. Leurs approches sont radicalement opposées :

• S/MIME nécessite un certificat, délivré par une « autorité de certification », dont l’objectif est de garantir le lien entre l’adresse email d’un utilisateur et sa clé cryptographique publique. Ce certificat est signé cryptographiquement par l’autorité, qui est donc garante de la légitimité de ce lien. Lorsque vous envoyez un email chiffré à votre destinataire, vous utilisez la clé publique indiquée dans le certificat associé à son adresse email. Si l’association est correcte, seul votre destinataire pourra déchiffrer votre message, car il est le seul détenteur de la clé privée associée à la clé publique que vous avez utilisée. Le principe est simple mais souffre d’au moins deux problèmes :
  • le certificat a souvent un coût non négligeable, ce qui est légitime, puisque le travail de l’autorité n’est pas anodin : elle doit s’assurer sérieusement que chaque utilisateur est bien celui qu’il prétend être
  • et l’autorité est un point de défaillance unique : si sa propre sécurité est compromise, la sécurité du système s’effondre pour tous les utilisateurs.
• À l’inverse, PGP ne nécessite aucun tiers de confiance. Ce système suppose que les utilisateurs s’échangent leurs clés publiques eux-mêmes. Mais comment échanger ces clés à distance ? La réponse est paradoxale : souvent par email, c’est-à-dire via un canal non sécurisé. Le problème est qu’un attaquant capable d’intercepter cet email peut remplacer votre clé publique par la sienne (attaque de type man-in-the-middle), et ainsi déchiffrer par la suite toutes les communications qui vous sont destinées. Cette situation est évidemment prise en compte par PGP : une fois les clés échangées de façon non sûre par deux utilisateurs, il est prévu qu’ils s’échangent une empreinte cryptographique de leur clé publique, concrètement une suite de 40 caractères hexadécimaux. Cette empreinte n’est pas secrète et permet simplement de vérifier que la clé reçue est effectivement celle qui a été envoyée. Le canal par lequel on la compare n’a donc pas besoin d’être confidentiel : il suffit qu’il soit authentique, une notion sur laquelle nous allons revenir. En pratique, les utilisateurs peuvent s’appeler (même via une ligne écoutée) ou se rencontrer. Les utilisateurs les plus avertis ont participé à des « soirées de signature de clés » dont l’objectif est de réunir physiquement des utilisateurs de PGP (ou plutôt de son implémentation libre GPG) afin, notamment, de s’échanger des clés. GPG est gratuit, libre, mais peu ergonomique. La vérification des empreintes est optionnelle et donc rarement effectuée.

Les enseignements fondamentaux à retenir

Malgré leurs limites respectives, S/MIME et PGP illustrent parfaitement ce que la cryptographie permet, et ce qu’elle ne permettra jamais. Pour le formuler précisément, il faut distinguer (au moins) trois types de canaux de communication :

• le canal non sécurisé, qui n’offre aucune garantie (l’email, comme on l’a vu) ;
• le canal authentique, qui garantit l’identité de l’interlocuteur et l’intégrité des échanges, mais pas nécessairement leur confidentialité (un appel téléphonique où l’on reconnaît la voix de son correspondant, même sur une ligne écoutée) ;
• et le canal sécurisé, qui ajoute la confidentialité à l’authenticité (une conversation privée en tête-à-tête).

L’objectif d’une messagerie sécurisée est précisément d’établir un canal sécurisé entre ses utilisateurs. Tout repose sur l’authentification : acquérir la certitude qu’une clé cryptographique appartient bien à la personne que l’on croit. Et pour cela, il n’existe que deux possibilités :

• Déléguer cette vérification à un tiers, comme le fait S/MIME avec son autorité de certification. L’expérience est « transparente » pour l’utilisateur, mais si ce tiers n’est pas intègre, ou s’il est compromis, la garantie s’effondre : vos échanges seront peut-être chiffrés de bout en bout, mais sans que vous sachiez avec qui, ce qui en ôte tout l’intérêt.
• Effectuer cette vérification vous-même, de bout en bout, comme le propose PGP. Il faut alors, de votre côté, une opération « manuelle » via un canal authentique : une rencontre physique, ou un appel téléphonique où vous reconnaissez la voix de votre correspondant.

Le recours à un tiers rend souvent les choses plus simples pour l’utilisateur, mais cette simplicité a un coût. Un coût financier, parfois : les certificats S/MIME, on l’a vu, sont payants. Et un coût de sécurité, toujours : la chaîne de confiance compte désormais un maillon de plus, que l’on croit sur parole, et dont la compromission suffit à tout faire s’effondrer.

Il n’existe pas de troisième possibilité. Ce n’est pas une lacune passagère des connaissances en cryptographie, que de futures découvertes viendraient combler. La raison est plus fondamentale : la confiance dans le lien entre une identité et une clé doit être ancrée « quelque part ». Soit vous l’ancrez en vous-même, en vérifiant ce lien par un canal que vous savez authentique ; soit vous l’ancrez chez un tiers, en vous fiant à ce qu’il affirme. Il n’y a pas de troisième solution, parce qu’on ne fabrique pas de la confiance à partir de rien. C’est vrai aujourd’hui, ce sera vrai demain.

Fondamentalement, cette dichotomie distingue deux familles de solutions : celles qui centralisent la sécurité, en déléguant l’authentification à un tiers, et celles qui la décentralisent, en plaçant l’authentification de bout en bout entre les mains des utilisateurs eux-mêmes.

Notons que la vérification effectuée soi-même n’est pas condamnée à rester individuelle : un contact dont vous avez authentifié la clé peut, à son tour, se porter garant d’un autre utilisateur qu’il a lui-même authentifié. La confiance se transmet alors de proche en proche, par des canaux vérifiés de bout en bout, sans que l’opérateur intervienne : c’est le principe du « réseau de confiance », sur lequel nous reviendrons.

Sans authentification fiable, le chiffrement perd l’essentiel de sa valeur

Le chiffrement n’est pas une fin en soi, mais un moyen de garantir la confidentialité des échanges. La confidentialité n’a de sens que si l’on sait à qui l’on parle. Or chiffrer un message suppose d’abord de disposer de la clé publique de son destinataire. Si la clé que l’on croit être la sienne est en réalité celle d’un autre, le chiffrement, aussi solide soit-il, ne protège plus rien : le message sera parfaitement chiffré, mais à destination de la mauvaise personne.

Considérons le scénario le plus courant, celui d’une messagerie qui distribue les clés via un annuaire centralisé géré par l’opérateur :

1. Alice génère sa paire de clés et publie sa clé publique dans l’annuaire de l’opérateur.
2. Bob veut écrire à Alice : son application demande à l’annuaire la clé publique d’Alice.
3. Bob chiffre son message avec la clé reçue, puis l’envoie.

Tant que l’annuaire renvoie effectivement la clé d’Alice, tout va bien : elle seule peut déchiffrer. En revanche, s’il renvoie à Bob une clé que l’opérateur contrôle (autrement dit, dont il détient la clé privée) à la place de celle d’Alice, Bob chiffrera son message pour l’opérateur sans le savoir. Celui-ci pourra alors le déchiffrer, le lire, puis le re-chiffrer avec la vraie clé d’Alice et le lui transmettre. Ni Alice, ni Bob ne s’aperçoivent de rien. C’est une attaque connue sous le nom « d’homme du milieu » (ou « man-in-the-middle »).

Le chiffrement reste techniquement « de bout en bout », mais il a perdu tout son sens, puisqu’on ne sait plus avec qui l’on communique. C’est pourquoi l’authentification n’est pas un raffinement optionnel, mais ce qui donne sa valeur au chiffrement. Si Olvid impose une vérification systématique à chaque ajout de contact, la plupart des messageries (comme WhatsApp ou Signal) ne proposent qu’une vérification optionnelle — il s’agit de comparer, avec chacun de ses contacts, un « numéro de sécurité » de 60 chiffres — que la majorité des utilisateurs n’effectue jamais.

Le contraste avec les autorités de certification mérite d’être souligné. Leur rôle est identique : garantir le lien entre une identité et une clé. Mais elles l’exercent dans un cadre strict : audits indépendants, exigences des programmes de confiance des navigateurs et des systèmes d’exploitation, réglementation européenne. L’annuaire de clés d’une messagerie assume exactement la même responsabilité, pour des milliards d’utilisateurs dans le cas de WhatsApp, sans être soumis à la moindre obligation de ce type.

De la même manière que le chiffrement de bout en bout est devenu la norme pour toute messagerie qui se veut « sécurisée », l’authentification de bout en bout devrait l’être également. L’un sans l’autre n’a guère de sens, car on chiffre de bout en bout pour se protéger d’un opérateur potentiellement malveillant, alors que sans authentification de bout en bout ce même opérateur peut contourner le chiffrement.

Si vous construisez un système où tout se résume à faire confiance au serveur, autant se passer de toute complexité et oublier le chiffrement de bout en bout.

Application de ce critère

✅Bon si l’authentification de bout en bout est systématique : il n’est pas possible d’ajouter un contact sans que le lien entre ce contact et sa clé ait été vérifié, soit directement par l’utilisateur (via un canal dont il est sûr de l’authenticité), soit par l’entremise d’un contact commun, préalablement authentifié, qui se porte garant de la mise en relation. Dans les deux cas, la chaîne de confiance ne fait intervenir que des utilisateurs qui se sont authentifiés entre eux, jamais l’opérateur du service.