Client open source

Une messagerie qui revendique un chiffrement de bout en bout et des propriétés cryptographiques fortes doit permettre de vérifier ces revendications, plutôt que de demander qu’on la croie sur parole. Cette vérifiabilité repose sur deux éléments : une documentation cryptographique claire, qui décrit précisément les protocoles employés, et un code client ouvert, qui permet de confirmer que l’application implémente réellement ce que la documentation décrit.

Quid du code du serveur de relais (ou de l’annuaire, quand il existe) ?

Publier le code du serveur n’est pas nécessaire à la sécurité des échanges. Si celle-ci est réellement de bout en bout, le serveur ne joue pas plus de rôle qu’un routeur réseau situé entre votre appareil et celui de votre correspondant : nul besoin de connaître le logiciel qui tourne dans un routeur pour vérifier la confidentialité et l’authenticité d’un échange qui le traverse. Par ailleurs, il est extrêmement difficile de vérifier que le code exécuté sur un serveur auquel on n’a pas accès correspond exactement au code publié par l’éditeur. Il n’en reste pas moins que la publication de code est appréciable et, à l’image de Signal, Matrix et Olvid, certaines solutions ont fait ce choix.

Builds reproductibles

La majorité des utilisateurs d’une messagerie télécharge l’application officielle via un « store » sur son smartphone (comme l’App Store d’Apple ou Google Play par exemple). Rares sont les utilisateurs qui compilent eux-mêmes le code source ouvert d’une application. Par conséquent, le caractère « open source » d’un client de messagerie ne permet pas à lui seul de garantir que l’application installée sur le téléphone a bien été compilée à partir de ce code.

Dans certains cas, il est possible pour le développeur de la solution de prendre les mesures nécessaires pour que toutes les étapes de la compilation (permettant de transformer le code source en une application utilisable) soient déterministes. Dans cette situation, il est alors possible pour un tiers de procéder très exactement aux mêmes étapes de compilation afin d’obtenir le même « binaire » (la même application), au bit près. Ce faisant, n’importe quel tiers peut vérifier que le binaire téléchargé à partir du magasin d’applications est identique à celui qu’il a lui-même obtenu en reproduisant le processus de compilation. Dès lors, on peut conclure que l’application téléchargée correspond bien au code publié.

Le cas particulier d’iOS

Cette vérification est réalisable sur Android (voir la documentation de Signal^archivé, Threema^archivé ou Olvid^archivé à ce sujet), mais elle se heurte sur iOS à un obstacle qui n’est pas propre à une messagerie donnée. Apple chiffre toute application soumise à l’App Store au moyen de sa technologie FairPlay. Le binaire téléchargé est donc chiffré, et ne devient comparable à une recompilation locale qu’une fois déchiffré, ce qui suppose de l’extraire à l’exécution depuis un appareil débridé (jailbreaké). En conséquence, la quasi-totalité des messageries renoncent aux builds reproductibles sur iOS ; à notre connaissance, seul Telegram propose une procédure de vérification, qu’il qualifie d’expérimentale et qui exige un téléphone jailbreaké^archivé. Nous considérons ici qu’une solution propose des builds reproductibles dès qu’elle le fait sur Android^archivé.

Application de ce critère

✅Bon si le code source du client (l’application qui manipule les clés) est publié sous une licence open source (AGPL, GPL, MIT, Apache, etc.), garantissant à quiconque le droit de l’examiner, de le compiler et de partager ses analyses. La simple mise à disposition du code « en lecture seule » (source available) ne suffit pas : elle ne donne aucun droit pérenne, et prive notamment du droit de recompiler l’application, sur lequel repose la vérification par builds reproductibles décrite ci-dessus.