• Propulsée par Matignon, la messagerie Olvid soulève des questions

Que pense Olvid de cette décision ?

Nous sommes évidemment très heureux de cette décision ! Cela fait plusieurs années que nous travaillons toujours vers plus de transparence (par exemple, en libérant l’intégralité du code source et notamment toute la cryptographie, garante de toutes les propriétés de sécurité), et que nous faisons de notre mieux pour qu’Olvid soit sûre et que cela soit reconnu (par exemple, via nos certifications de l’ANSSI).

Mais nous ne sommes pas naïfs. Faire de son mieux ne suffit pas toujours, et la compétition est rude. Et même si certains trouvent que le choix du gouvernement est « logique », je le trouve formidable. Au-delà du coup de projecteur sur Olvid, c’est une décision qui montre l’importance grandissante de l’attention qu’il faudra apporter à la cybersécurité en général.

Avez-vous joué un rôle dans la création de cette circulaire ?

Si vous me demandez si nous avons participé à sa rédaction, la réponse est simple : absolument pas !

On ne nous a rien demandé, et c'est bien normal. Ce n’est pas notre rôle. Cela étant dit, nous expliquons régulièrement ce que nous faisons, comment et surtout pourquoi. Et cela finit par porter ses fruits, notamment dans la circulaire.

Par exemple, ce qui distingue notre modèle de sécurité de celui de la plupart des applications de messagerie chiffrées de bout en bout est, je trouve, astucieusement résumé dans cette circulaire lorsqu’elle mentionne un « annuaire décentralisé ». C’est une autre façon de parler d’authentification de bout en bout, et je trouve l’analogie assez parlante. Mais nous savons que des tests d’Olvid ont été effectués « en conditions réelles » d’utilisation au sein du gouvernement. La capacité d’Olvid de s’adapter à des conditions réseaux particulières a certainement joué un rôle important dans le choix final de la solution à adopter.

Que pensez-vous de la mention, dans cette circulaire, de la présence de failles de sécurité dans les autres applications ?

Quand on parle d’une application de la taille d’Olvid (environ 230 000 lignes de code Swift pour la version iOS par exemple) ou de n’importe quelle application de messagerie sécurisée, il faut être très clair : aucune n’est capable de prouver que le code source effectue très exactement ce pour quoi il a été conçu. Peut-on alors certifier que ces applications n’ont pas de failles ? Non.

C’est pour cette raison que la plupart des développeurs s’accordent sur l’idée que le seul moyen de ne pas introduire de bogue, c’est de ne pas écrire de ligne de code. Il existe évidemment des moyens d’écrire du code dont on peut prouver mathématiquement qu’il fait exactement ce qu’on attend de lui, mais cela n’est pas envisageable à cette échelle et étant donnée la vitesse à laquelle toutes les messageries (et, plus généralement, l’immense majorité des applications) doivent livrer de nouvelles fonctionnalités.

Alors pourquoi Olvid plutôt qu’une autre ?

Nous voyons plusieurs raisons mais, la plus importante, c’est certainement son modèle de sécurité. Contrairement aux autres, Olvid ne garantit pas seulement le chiffrement (la confidentialité) de bout en bout mais aussi l’authentification de bout en bout. Tout cryptologue vous le dirait : sans authentification, la confidentialité perd de son sens.

Pour s’en convaincre, imaginez-vous avoir une discussion confidentielle, mais sans certitude de l’identité exacte de la personne avec laquelle vous êtes en train d’avoir cette discussion. Cela n’a aucun sens… On voit bien que l’authentification est un préalable à la confidentialité.

C’est ce que nous martelons chez Olvid depuis plusieurs années : Imposer un annuaire centralisé d’utilisateurs (comme le font la plupart des autres messageries) brise la caractéristique « de bout en bout » de la sécurité, puisque l’immense majorité des utilisateurs va faire confiance à cet annuaire pour entrer en contact avec d’autres utilisateurs de la solution. Souvent, ils n’ont même pas conscience de l’existence de cet annuaire.

Nous ne sommes pas seuls à nous préoccuper de la surface d’attaque plus importante qu’implique l'utilisation d’un annuaire centralisé. Dans un billet daté du 27 octobre 2023 (dont je vous recommande la lecture complète), l’équipe « Security Engineering and Architecture » d’Apple indique : « Bien qu'un service d'annuaire de clés tel que le service d'annuaire d'identité d'Apple (IDS) résolve le problème de la découverte de ces clés, il représente un point unique de défaillance dans le modèle de sécurité. »

Et c’est là l’avantage (en termes de sécurité) d’Olvid par rapport à d’autres solutions : puisqu’elle fonctionne sans imposer d’annuaire d’utilisateurs, elle décentralise la sécurité et rend les attaques beaucoup plus coûteuses. Certes, au même titre que toutes les autres solutions, Olvid peut comporter des failles au niveau du code. Mais ces failles peuvent être corrigées (le processus de « Responsible Disclosure » ou « Divulgation Responsable » est évidemment à privilégier). Lorsque le problème vient d’un choix d’architecture, il ne s’agit généralement pas d’une correction à apporter, mais de tout reprendre à zéro.

On a pu voir, notamment par Stéphane Bortzmeyer sur Twitter, que l’application Olvid sur Android contient un tracker. S’agit-il simplement de télémétrie ? Peut-on le désactiver ?

M. Bortzmeyer n’est pas le premier à signaler ce problème. Certains outils tentent d’automatiser la détection de tracker au sein d’une application. Cette détection n’est pas une science exacte, il peut y avoir des faux positifs.

Olvid n'a bien évidemment pas de tracker intégré, mais ce qui est détecté comme OpenTelemetry par les outils d'analyse est en fait une libraire d'OpenCensus qui est une dépendance de la librairie de connexion à Google Drive. Olvid ne remonte aucune donnée de télémétrie, mais certains composants de la librairie sont utilisés pour les communications avec Google Drive (pour des mesures de bande passante), notamment pour la sauvegarde automatique chiffrée dans le Cloud.

Nous aurions aimé supprimer cette dépendance, mais elle est indispensable au fonctionnement de Google Drive. En revanche, la version open-source de l'application (disponible sur GitHub) propose une version « no Google » qui supprime toute dépendance à du code fermé (dont la librairie Google Drive).

Certains ont pointé une longue liste d’autorisations nécessaires pour Olvid, comment l’expliquez-vous ?

Vous faites sans doute référence à la liste affichée par Exodus lorsque l’on fait une recherche sur Olvid. Si c’est le cas, j’invite vos lecteurs à se rendre sur le site d’Exodus et à faire la recherche par eux-mêmes.

À date (10 décembre 2023), Olvid demande 27 permissions, contre 73 pour Signal, 74 pour WhatsApp, 61 pour Telegram (que certains considèrent, à tort, comme une messagerie sécurisée). Olvid demande donc moins de deux fois moins d’autorisations que les exemples cités. Ceux qui ont pointé du doigt la « longue » liste d’autorisations demandée par Olvid devraient sincèrement comparer cette liste à celles des autres applications avant d’en qualifier la longueur.

Par ailleurs, je pense que vos lecteurs partageront notre avis qu’il serait totalement ridicule de considérer que Signal est moins sûre que Telegram parce qu’elle demande plus d’autorisations. Au-delà de leur nombre, c’est la justification de ces autorisations qui importe.

Par exemple : la version Android d’Olvid demande un accès ACCESS_BACKGROUND_LOCATION, ce qui n’est pas le cas de Signal par exemple. C’est parce que Olvid permet (en activant certaines fonctionnalités encore en bêta) à l’utilisateur de partager sa géolocalisation avec les utilisateurs de son choix, même lorsque l’application passe en arrière-plan.

Signal demande l’accès aux SMS (via RECEIVE_SMS) ce que ne demande pas Olvid et pour cause, cet accès est nécessaire au bon fonctionnement de Signal et ne servirait à rien dans Olvid. Il ne faut pas systématiquement y voir une malveillance, mais plutôt une demande d’accès nécessaire au bon fonctionnement de l’application et aux services qu’elle propose.

Gardez également à l’esprit que ces permissions représentent simplement une liste d’autorisations que l’application a le droit de demander à l’utilisateur. Mais aucune permission « sensible » n’est donnée sans un accord explicite de l’utilisateur.

Pour reprendre l’exemple de ACCESS_BACKGROUND_LOCATION, cette permission ne peut pas être accordée à l’application sans que l’utilisateur aille dans les paramètres de l’application pour indiquer explicitement qu’il autorise l’application accéder à sa localisation « en permanence ».

Quelles sont les prochaines grandes étapes dans le développement du service ?

Nous avons bien évidemment plein de fonctionnalités nouvelles que nous souhaitons apporter à notre application de message, mais plus globalement, nous réfléchissons à tous les usages qui impliquent une communication entre des personnes physiques (drive, édition collaborative, etc.). Mais chaque chose en son temps.

Une version Linux du client desktop est-elle prévue ?

Notre CTO utilise tous les jours la version Linux d’Olvid ! Ce n’est pas qu’elle est prévue : elle marche déjà. Nous avons encore un travail de packaging à réaliser : si toutes les versions de Windows sont assez similaires, il existe de grandes disparités entre les différentes versions de Linux, rendant un packaging universel un peu plus compliqué. Même si cette fin d’année est très intense pour nous, promis, nous allons faire le maximum pour la rendre disponible aussi vite que possible.

Quand le code source de la partie serveur sera-t-il publié ?

Il n’y a pas de date prévue pour l’instant.