Olvid

« Sans authentification, la confidentialité perd de son sens »

[Interview] Thomas Baignères : sécurité, circulaire, tracker… les explications d’Olvid

Olvid

Abonnez-vous pour tout dévorer et ne rien manquer.

Déjà abonné ? Se connecter

Abonnez-vous

La messagerie sécurisée Olvid a été largement mise en avant par la Première ministre, avec un discours qui soulevait plusieurs questions (voir notre précédente analyse). Thomas Baignères, cofondateur d'Olvid, a répondu à nos questions sur la position d’Olvid, sa sécurité et celle de ses concurrents.

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.

Sommaire de l'article

Introduction

Que pense Olvid de cette décision ?

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

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

Alors pourquoi Olvid plutôt qu’une autre ?

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 ?

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

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

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

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

Commentaires (14)


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é)

Quand le code source de la partie serveur sera-t-il publié ?
Il n’y a pas de date prévue pour l’instant.


C'est contradictoire comme discours pour moi.
Modifié le 14/12/2023 à 18h37
C'est contradictoire comme discours pour moi.


Oui et non. Oui dans le cas général, non dans la mesure où il s'agit de chiffrement de bout en bout. Avec un chiffrement de bout en bout, la partie cliente suffit pour s'assurer de la sécurisation du protocole.

Après, d'un point de vue transparence et cohérence dans le discours, il vaudrait mieux effectivement que la partie serveur soit aussi rendu open-source.

fdorin

C'est contradictoire comme discours pour moi.


Oui et non. Oui dans le cas général, non dans la mesure où il s'agit de chiffrement de bout en bout. Avec un chiffrement de bout en bout, la partie cliente suffit pour s'assurer de la sécurisation du protocole.

Après, d'un point de vue transparence et cohérence dans le discours, il vaudrait mieux effectivement que la partie serveur soit aussi rendu open-source.
Ma remarque était purement en terme d'image, pas technique : on ne peut pas dire "on libère l'intégralité" (raison pour laquelle j'ai surligné ce terme) et derrière dire "pas de plans pour le serveur".

C'est le genre de communication à deux vitesses qui me fait immédiatement perdre toute envie de faire confiance en un produit car discours incohérent.
C'est contradictoire comme discours pour moi.


Tout à fait.
Le principe de la sécurité est celui derrière les algorithmes cryptographiques au cœur de celle-ci : ils doivent être ouverts et revu par les pairs, au défaut d'être disqualifiés. Le secret est garanti par une des deux entrées : une clé mathématique.
C'est sur cette base qu'est apparue la maxime "la sécurité par l'obscurité n'est pas de la sécurité".

Toute application ne suivant pas ces préceptes ne devrait être honorée de confiance.
Et pourtant, dans ce monde informatique biberonné de logiciels privateurs depuis l'avènement des premiers gros, habitude est prise de fermer les yeux.

Rappelons, à toutes fins utiles, que tous les fondamentaux d'Internet et de la cryptographie sont des normes libres & ouvertes.
Consommer ce travail de chercheurs pour en produire un travail fermé est de l'accaparement et/ou de l'enfermement.
C'est le principe des licences GPL (largement violées aujourd'hui) que de tenter de propager l'ouverture.
C'est du pur discours marketing. Et j'aimerais bien connaître les vrais accords financiers derrière tout ceci.
Olvid est peut être une excellente application parfaitement sécurisée. Maintenant, la sécurisation n'est pas suffisante. Les failles ne sont pas que techniques. Elles peuvent être juridiques.

Donc j'ai installé Olvid sur mon smartphone qui est sous Sailfish OS (mais qui fait tourner un Android dans un container - Android 11 pour le moment). Facile d'usage et apparait aussi bien sécurisée que Signal. La faille d'Olvid c'est son hébergement. Mon analyse juridique fait qu'en raison de l'extraterritorialité du droit américain, même avec Olvid, en raison de son hébergement chez AWS, le droit américain US a vocation à s'appliquer sur l'ensemble des communications. Combien même c'est chiffré de bout en bout. C'est comme utiliser le $ dans les affaires. Moralité, tant que l'hébergeur ne sera pas européen et a fortiori français, utiliser Signal ou Olvid revient au même. Olvid n'est pas une application souveraine à mon sens. Maintenant je peux me tromper. Faudrait poser la question à Noyb par exemple.
Modifié le 14/12/2023 à 19h18
Le fait que cela soit hébergé par une société étrangère, c'est effectivement problématique. Avec le chiffrement de bout en bout, il est vrai qu'il y a peu de risque sur le contenu des communications.

Par contre, un risque important (d'autant plus pour une solution prônée par un gouvernement) c'est une coupure du service. AWS est et reste une société de droit américaine, soumise au droit américain. La question de l'application extra-territoire des lois américaines est une question qui revient fréquemment sur le devant de la scène. Si demain on donne l'ordre à Amazone de couper le service, ils n'auront pas d'autre choix que d'obtempérer.

Reste à voir aussi les métadonnées qui transitent. Les métadonnées peuvent donner de nombreuses informations : heure, localisation, correspondant, etc. Car même si le chiffrement est de bout en bout, il faut bien un moyen pour connaitre l'émetteur et le destinataire d'une communication pour permettre la délivrance d'un message.

fdorin

Le fait que cela soit hébergé par une société étrangère, c'est effectivement problématique. Avec le chiffrement de bout en bout, il est vrai qu'il y a peu de risque sur le contenu des communications.

Par contre, un risque important (d'autant plus pour une solution prônée par un gouvernement) c'est une coupure du service. AWS est et reste une société de droit américaine, soumise au droit américain. La question de l'application extra-territoire des lois américaines est une question qui revient fréquemment sur le devant de la scène. Si demain on donne l'ordre à Amazone de couper le service, ils n'auront pas d'autre choix que d'obtempérer.

Reste à voir aussi les métadonnées qui transitent. Les métadonnées peuvent donner de nombreuses informations : heure, localisation, correspondant, etc. Car même si le chiffrement est de bout en bout, il faut bien un moyen pour connaitre l'émetteur et le destinataire d'une communication pour permettre la délivrance d'un message.
Je me pose la question sur la légalité que le gouvernement US puisse demander à une entreprise de ne plus fournir de service à un autre sous prétexte que les données hébergées soient chiffrées. Les US pourront demander les données, ils n'auront que des trucs indéchiffrables et les méta données liées (qui doivent être légères).
Ensuite, politiquement, il y a très peu de chance que cela arrive, si c'était légal même. Cela demanderait un prétexte bien fort à utiliser contre des alliés. J'y crois pas.

swiper

Je me pose la question sur la légalité que le gouvernement US puisse demander à une entreprise de ne plus fournir de service à un autre sous prétexte que les données hébergées soient chiffrées. Les US pourront demander les données, ils n'auront que des trucs indéchiffrables et les méta données liées (qui doivent être légères).
Ensuite, politiquement, il y a très peu de chance que cela arrive, si c'était légal même. Cela demanderait un prétexte bien fort à utiliser contre des alliés. J'y crois pas.
Je me pose la question sur la légalité que le gouvernement US puisse demander à une entreprise de ne plus fournir de service à un autre sous prétexte que les données hébergées soient chiffrées.


Attention, je n'ai pas dit que le prétexte devait être que les données étaient chiffrées. Le prétexte peut être "tout et n'importe quoi". Un conflit commercial, politique, etc. Ils ont déjà mis en place des mesures d'embargo contre des pays entiers ou contre certaines sociétés pour des raisons parfois plus ou moins discutable, et applicable à toutes sociétés utilisant le dollar. On a également déjà vu les Etats-Unis faire preuve d'une agressivité sans précédent envers des alliés (par ex. l'affaire Alstom).
Ensuite, politiquement, il y a très peu de chance que cela arrive, si c'était légal même. Cela demanderait un prétexte bien fort à utiliser contre des alliés. J'y crois pas.


Ils ont pourtant bien espionné, et à grande échelle, leurs concitoyens ainsi que leurs alliés. Et si aucun pays allié n'a donné asile à Edward Snowden malgré l'ampleur des révélations, ce n'est pas pour rien ("peur" des conséquences d'un tel acte).

Les désaccords profonds peuvent survenir rapidement, y compris entre alliés. Et les sujets ne manquent pas (réchauffement climatique, espionnage, conflits armées, etc.). Et là, ils auraient les moyens d'impacter les moyens de communication utilisés et poussés par un gouvernement. Cela ferait un "joli coup de semonce".
Signal n'a-t-il pas, lui aussi, une sorte de carnet d'adresses décentralisé ?
Si oui, quel est l'intérêt de Olvid par rapport à Signal ?


Autre chose : je m'étonne que personne ne pointe le fait que passer par des serveurs AWS peut permettre à Amazon de savoir qui communique avec qui rien qu'avec l'adresse IP (et les trames réseau).
Je m'explique : Jean utilise son téléphone pour aller sur Amazon pour acheter un grille-pain. Il envoie un lien vers le grille-pain à Sophie,via Olvid. Sophie clique sur le lien et arrive sur la page Amazon.
Amazon sait donc que l'adresse IP de Jean a été sur Amazon et a envoyé un message Olvid à quelqu'un, et que l'adresse IP de Sophie a reçu un message venant d'un serveur Olvid : si Jean et Sophie sont connectés tous les 2 à leur compte Amazon, on peut facilement en déduire que Jean a envoyé un message à Sophie. Surtout si Sophie répond à Jean alors qu'ils ont la même adresse IP. Et pour encore assurer le truc, on peut regarder si le message envoyé de Jean à Olvid est de la même taille que celui envoyé de Olvid à Sophie.
Modifié le 14/12/2023 à 23h51
Beaucoup de solides arguments, mais entre AWS, Google Drive et un serveur opaque, ça fait plus que tâche ...
Niveau fonctionnalités, ne pas pouvoir émettre d'appels vocaux sur la version gratuite, c'est aussi selon moi un gros manque par rapport à la concurrence.

Par ailleurs :
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


Et plus loin
la version open-source de l’application (disponible sur GitHub) propose une version « no Google »


Ben dans ce cas, autant ne pas mettre d'intégration à Google Drive du tout. Surtout au vu de la nature de cette entreprise, et de l'ajout d'un « pisteur » obligatoire pour pouvoir l'utiliser ... Pour une solution censée être cocorico-super-sécurisée-top-secret++, ça la fout mal ...
J'avoue que je me pose sérieusement la question de savoir à quoi sert cette intégration à Google Drive.
C'est pour faire un backup des conversations ?
C'est pas possible de passer par les Google Services pour faire ça ? (J'y connais pas grand chose en dev mobile, mais ça me semblerait logique.)
Partage d’écrans, appels vers numéro de téléphone classique, on premise et j’achète ^^
Je fais un tire groupé.

Olivid utilise aws pour la partie serveur, ouai... Mais la modif des sources en automatique par Google, Samsung, Apple par contre vous passez totalement à côté ?

J'ai pas vérifié le code source, et j'en suis incapable de toute manière.
Si les échanges sont chiffrés convenablement, même si ça passe par Google ou Meta, peu importe.

Pour rappel,sur mobile on change d'IP régulièrement, la géo-localisation peut être altérée, savoir que je suis jne personne parmis 50 000 ça va pas trop les aider les gafam et les us.

De plus, si Olvid échange des identifiants anonymes,potentiellement changeant pour chaque destinataire,ça devient compliqué de savoir qui est qui.

Enfin, si vous avez un joli smartphone, peut être que l'Os fournira lui même les infos sur lesquelles vous faites une psychose avec cette article.

Bref, prudence ok, paranoïa par contre on évite, merci.
Fermer