FAQ

Aide connexe

Questions d'actualité

Nous sommes souvent interpellés sur des sujets qui ne sont pas forcément liés au fonctionnement de l’application. Ces sujets n’en demeurent pas moins très importants. Ils sont parfois techniques, sensibles, sujets à controverse, et malheureusement commentés de façon approximative (en moins de 280 caractères). Notre objectif est ici de trouver le meilleur compromis entre un discours accessible au plus grand nombre, sans faire l’économie d’un minimum d’explications techniques. Vous n’y échapperez pas 😱.

Souveraineté

La cryptographie mise en œuvre par Olvid permet à chaque utilisateur d’être souverain. Contrairement à la quasi-totalité des services sur internet, la souveraineté des données ne dépend pas de la localisation des serveurs ni de la nationalité de l’éditeur de la solution.

Pour aller plus loin :

AWS

Nos serveurs sont hébergés par AWS. La rupture technologique d’Olvid est de garantir la sécurité de ses utilisateurs via des mécanismes cryptographiques, qui n’ont pas de nationalité, sans avoir à faire confiance aux serveurs.

Pour aller plus loin :

Les mots comptent : chiffrer ou crypter ?



Le mot « crypter » n’est pas utilisé en cryptographie. Le mot adéquat est « chiffrer ». Le chiffrement protège la confidentialité d’une donnée. Seul un individu en possession de la bonne « clé » pourra « déchiffrer » et recouvrer l’information « en clair ». Attention cependant : un adversaire peut tenter de « décrypter  » le message, c’est-à-dire de recouvrer l’information sans connaître la bonne « clé ».

Adresses IP

Olvid s’appuie sur internet pour permettre à ses utilisateurs de communiquer et a donc accès à leur adresse IP. Ce n’est pas une particularité d’Olvid : quand vous naviguez sur internet, y lisez un article, consultez un réseau social, votre adresse IP est accessible au fournisseur de service tout simplement parce que c’est ainsi qu’internet fonctionne. Olvid ne conserve pas ces adresses.

Tracker

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 ne contient pas de tracker, mais la version Android inclut une dépendance indirecte qui peut engendrer une fausse alerte.

Pour aller plus loin :

La fonctionnalité X n’est toujours pas disponible. Pourquoi !?!?

Parce que nous avons développé la fonctionnalité Y avant. Et si nous avions fait le contraire, cela nous aurait été reproché.

Gratuité

Olvid est gratuite. Vous connaissez probablement la rengaine : « Quand c’est gratuit, c’est vous le produit ». Pourquoi ? Car les applications prétendument gratuites se financent généralement via l’exploitation de vos données personnelles. Ce n’est pas le cas d’Olvid qui est financée par des fonctionnalités payantes.

Certification

Nos certifications CSPN datent d’environ 3 ans, et ce sont surtout nos protocoles cryptographiques qui ont été certifiés. Ceux-ci n’ont pas changé depuis et aucune faille ne nous a été remontée : en ce sens, ils restent parfaitement sûrs. L’ajout de nouvelles fonctionnalités ne remet pas en cause la solidité de notre base cryptographique.

Pour aller plus loin :

Utilisation de Keycloak dans l’offre Entreprise

L’utilisation de keycloak dans notre offre entreprise ne suit pas les schémas usuels de déploiement d’applications web. Certains éléments peuvent donc surprendre. Mais tous nos clients, entreprises et administrations, dont les équipes techniques ont étudié en détail notre schéma de déploiement, peuvent confirmer qu’il ne pose aucun problème.

Données Personnelles

Lorsque vous voulez accéder à un service web, il vous est généralement demandé de créer un compte, que le service stocke sur un serveur auquel il a accès. Ce n’est pas le cas d’Olvid : le compte que vous créez reste en local sur votre appareil et aucune des données saisies (comme votre nom) n’est partagée avec les serveurs d’Olvid. Olvid utilise votre adresse IP pour son fonctionnement, comme discuté ici.

Liste de sous-traitants

En dehors de nos serveurs chez AWS, nous n’avons pas de sous-traitant au sens du RGPD.

Transparence

Nous avons documenté toute la technologie d’Olvid afin d’en faire profiter celles et ceux qui s’y intéressent. Publication des cibles de sécurité, rapports de certification et certificats ANSSI ; publications des deux rapports techniques d’évaluation produits par le CESTI Synacktiv ; publication d’articles scientifiques. Et le code source des applications mobiles est open source.

Pour aller plus loin :

Pour aller plus loin - Fonctionnement d’Olvid

Olvid est une application de messagerie instantanée permettant d’échanger entre deux appareils (à date, Olvid est compatible avec Android, iOS, iPadOS, macOS, Windows et Linux) des messages, des fichiers (documents, photos, vidéos, messages vocaux, etc.), et de passer des appels audio.

Toutes les informations échangées via Olvid sont chiffrées de bout en bout. Dans le cas des messages, par exemple, l’appareil de l’envoyeur utilise une clé de chiffrement pour chiffrer le message, détruit la clé (qui ne servira donc jamais une deuxième fois) et envoie le chiffré. Ce dernier n’est déchiffré qu’à un seul endroit : sur l’appareil du destinataire, seul endroit où se trouve la clé de déchiffrement. Une fois le message déchiffré, la clé de déchiffrement est détruite.

Ce mode de fonctionnement (combiné à un rafraîchissement habile des clés cryptographiques) permet de garantir la confidentialité persistante des échanges. En pratique, cela signifie que si l’émetteur et le destinataire ont supprimé le message de leur appareil, Olvid garantit cryptographiquement qu’il sera impossible pour un tiers de recouvrer ce message, même si ce tiers a enregistré l’intégralité du trafic internet et dérobé les appareils des deux utilisateurs pour en extraire toutes les clés cryptographiques.

Comme nous le disions plus haut, les données échangées avec Olvid sont systématiquement chiffrées de bout en bout. Tout ce qu’un appareil envoie sur le réseau via Olvid présente la structure suivante :

Données chiffrées ou aléatoires || Clé publique du destinataire

Étant donnés les algorithmes de chiffrement utilisés par Olvid (dans le cas des messages : Encrypt-then-MAC avec AES-256 en mode CTR et HMAC sur SHA256), les données chiffrées sont indistinguables de données aléatoires uniformément distribuées (autrement dit, indistinguables d’un bruit numérique). Il est donc cryptographiquement impossible d’en extraire quelque information que ce soit (en dehors de la taille de la donnée chiffrée, mais là encore, Olvid applique certaines techniques pour mitiger ce risque). La clé publique du destinataire (en clair) permet de transmettre le message à son destinataire (à l’image d’une adresse sur une enveloppe cachetée). Cette clé publique ne permet pas de déduire la moindre information personnelle sur son propriétaire (i.e., sur l’appareil détenant la clé cryptographique privée correspondante).

En première conclusion : un (message) chiffré Olvid ne permet pas d’extraire d’information personnelle concernant le contenu de l’information échangée, pas plus que sur l’identité physique de l’émetteur ou du destinataire.

C’est sur cette première conclusion que s’appuie notre modèle de sécurité : Olvid garantit une sécurité totale des communications, quand bien même l’intégralité du réseau serait malveillant. Autrement dit, peu importe le réseau, le câble transatlantique, le routeur, ou le serveur qu’un message chiffré Olvid pourrait traverser. Par conception, la structure même de ce chiffré garantit une confidentialité cryptographique des informations qu’il contient.

De l’importance de l’authentification entre utilisateurs

Olvid n’est pas l’unique solution à proposer du chiffrement de bout en bout. D’autres messageries instantanées le font aussi. Une question bien légitime se pose donc alors : en quoi Olvid est-elle différente de ces autres solutions ?

La réponse tient dans les moyens mis à disposition des utilisateurs pour s’accorder sur les fameuses clés de chiffrement/déchiffrement des messages. En cryptographie, il existe très exactement deux façon de procéder :

  • La première est de s’appuyer sur un serveur tiers : c’est le choix fait par l’immense majorité des autres messageries sécurisées grand public. Dans ce cas, chaque utilisateur doit préalablement créer un compte sur un annuaire centralisé (un serveur) généralement opéré par le fournisseur de service. Ce compte contiendra nécessairement des données personnelles puisqu’il devra permettre au fournisseur de service de rattacher ce compte à l’utilisateur. En particulier, cet annuaire conservera un identifiant unique pour l’utilisateur, généralement son numéro de téléphone ou une adresse email. Cette approche présente plusieurs dangers en termes de sécurité :

    • Si le tiers de confiance (le serveur centralisé servant d’annuaire de comptes utilisateurs) est compromis, la sécurité de toute la solution s’effondre, pour tous les utilisateurs.
    • Tout individu capable de convaincre le tiers qu’il est bien propriétaire de l’identifiant (numéro de téléphone ou adresse email) sera considéré comme l’utilisateur légitime. Par exemple, toute personne capable d’intercepter un SMS pourra pirater (ou « hijack », dans le jargon) le compte de l’utilisateur légitime.

  • La seconde approche (celle choisie par Olvid) est de ne pas imposer de tiers aux utilisateurs. Ce tiers est remplacé par des protocoles cryptographiques, exécutés exclusivement sur les appareils des utilisateurs. Tant que les appareils ne sont pas piratés, ces protocoles permettent de prouver qu’aucune attaque ne peut avoir lieu. Olvid met en œuvre plus d’une dizaine de protocoles. Si certains ont été conçus sur mesure (comme le protocole de création de groupe de discussion), d’autres sont très directement inspirés de la recherche publique (comme le protocole de mise en relation à base de codes, basé sur le protocole SAS de Serge Vaudenay). Ces protocoles sont open-source, documentés et audités. Contrairement à la première approche, les utilisateurs n’ont pas à faire confiance à quelque infrastructure serveur que ce soit.

En deuxième conclusion : Si Olvid n’est pas l’unique solution de messagerie instantanée grand public à proposer du chiffrement de bout en bout, elle est (à notre connaissance) la seule à garantir également l’authentification de bout en bout, autrement dit, à ne pas faire reposer la confidentialité et l’authenticité des échanges sur un annuaire centralisé.

« 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 ».
« 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 ».
Matthew Green
Cryptography professor at Johns-Hopkins University
Wired

Conclusion

Nous avons tâché de trouver le juste équilibre entre concision et précision. Ces explications sont importantes puisqu’elles permettent de comprendre en quoi la technologie au cœur d’Olvid est unique, en quoi Olvid n’est pas simplement « une messagerie instantanée sécurisée de plus ».

La chose la plus importante à retenir : beaucoup de messageries instantanées proposent du chiffrement de bout en bout. Mais les garanties de ce dernier en termes de confidentialité nécessitent de faire confiance à un annuaire (serveur) centralisé. Ce dernier doit lui-même faire confiance à d’autre tiers (comme l’opérateur téléphonique lorsque le numéro de téléphone est utilisé comme identifiant). Si un seul de ces maillons fait défaut, la sécurité de l’utilisateur peut être compromise. Ce n’est pas le cas avec Olvid qui n’impose aucun tiers de confiance, aucun annuaire centralisé.

Pour aller plus loin - Infrastructure serveur

Afin qu’une messagerie instantanée soit utilisable par le plus grand nombre, il est nécessaire de garantir des communications asynchrones : si votre destinataire est hors-ligne (dans un avion) au moment où vous lui envoyez votre message, vous vous attendez néanmoins à ce que ce message lui parvienne dès l’instant où il sera à nouveau en ligne (à la descente de l’avion).

Certaines solutions prétendument « décentralisées » (autrement dit, sans serveur centralisé) garantissent ce résultat en testant activement la connectivité avec le téléphone du destinataire avant d’envoyer le message, et en renvoyant le message si la délivrance de celui-ci n’est pas confirmée. L’expérience utilisateur est généralement nettement moins bonne : les messages mettent régulièrement beaucoup de temps à être transmis, l’utilisation de la batterie est importante, l’utilisation de la bande passante aussi.

D’autres solutions, comme Olvid, s’appuient sur un serveur de relais pour mettre les messages chiffrés « en attente » jusqu’à ce que le destinataire soit en ligne. Une fois que le destinataire a téléchargé le message, ce dernier est supprimé du serveur.

Comme nous l’avons expliqué plus haut, la structure même du message garantit que le serveur de relais ne pourra en extraire aucune information personnelle, pas plus que d’information sur le contenu du message.

Les protocoles cryptographiques discutés plus haut permettent de considérer le serveur de relais de la même façon que l’on considère déjà toutes les autres parties du réseau (antennes relais, câble transatlantique, routeurs, etc.) : on ne leur fait généralement pas confiance (à raison) mais la cryptographie permet de faire abstraction de leur existence. Il en va de même avec notre serveur de relais : les protocoles cryptographiques mis en œuvre par Olvid permettent d’en faire abstraction puisqu’il ne joue aucun rôle dans la sécurité des communications.

Parallèle avec TLS

Lorsqu’on se connecte à un site internet dont l’adresse commence en https://, il n’est pas nécessaire de se soucier de la sécurité des câbles et des routeurs (sur lesquels nous n’avons aucune maîtrise) entre notre appareil et le serveur qui héberge le site. Ceci est rendu possible par la cryptographie mise en œuvre par le protocole TLS, qui garantit l’authenticité du site (indispensable, par exemple, pour qu’un paiement qu’on y effectuerait soit bien à destination de la bonne personne) ainsi que la confidentialité des données que nous échangeons avec lui (pour que votre achat ne soit pas nécessairement connu de tous).

De la même façon, le chiffrement et l’authentification de bout en bout mis en œuvre par Olvid permettent de ne pas se soucier de la sécurité de ce qui se trouve entre votre appareil et celui de votre correspondant : que ce soient des câbles et des routeurs (comme pour TLS), mais aussi le serveur de relais de message. La cryptographie permet d’en faire abstraction.

Savoir qui contrôle le serveur n’a donc pas plus d’importance que de savoir qui contrôle les différents routeurs nécessairement traversés. La cryptographie exécutée sur votre appareil et sur celui de votre correspondant suffit.

Comment ce serveur de relais fonctionne-t’il ?

Puisque le serveur de relais ne joue aucun rôle en termes de sécurité, son fonctionnement est relativement simple : lorsque l’appareil envoie un message chiffré, ce dernier est stocké sur le serveur de relais. Grâce à la clé publique du destinataire, ce serveur peut le notifier qu’un message l’attend sur le serveur. Cette notification s’appuie soit sur des technologies de « notification push » d’Apple ou de Google lorsque l’utilisateur en a fait ce choix, soit sur la base d’une connexion websocket entre le téléphone du destinataire et le serveur de relais. Une fois notifié, l’utilisateur prouve au serveur (via une preuve de connaissance à divulgation nulle de connaissance) qu’il est bien le destinataire légitime du message (ce afin de limiter le risque de déni de service), il télécharge le message chiffré, et le serveur supprime le message.

Dans le cas d’un message comportant des pièces jointes, le comportement est similaire : l’expéditeur dépose son message sur le serveur en indiquant le nombre de fichiers à y joindre et récupère pour chacun d’eux une URL signée unique l’autorisant à venir déposer la pièce jointe chiffré sur le serveur. Une fois la dernière pièce jointe déposée, le serveur notifie le destinataire qu’il peut récupérer le contenu du message et à nouveau une URL signée l’autorisant à télécharger chaque pièce jointe. Le message et ses pièces jointes sont supprimés une fois la dernière pièce jointe téléchargée par le destinataire.

Notre serveur est hébergé chez AWS

La nature très simple du serveur donne sans doute le sentiment que nous pourrions l’héberger chez n’importe quel hébergeur. Toutefois, un service comme Olvid doit fournir la meilleure résilience aux pannes, la meilleure disponibilité à travers le monde, et avoir la capacité de passer à l’échelle rapidement en cas d’afflux d’utilisateurs ou de pic de charge ponctuel. Personne ne veut d’une messagerie dont les messages mettent du temps à arriver autour de 19h quand tout le monde s’en sert !

Nous avons donc fait le choix d’héberger ce serveur chez AWS car c’est là que nous avons trouvé la meilleure qualité de service, avec le moins d’effort à fournir de notre côté pour la maintenance et le passage à l’échelle de notre infrastructure.

Quel serait le cahier des charges pour un basculement vers un hébergeur SecNumCloud ?

Pour toutes les raisons évoquées plus haut, le basculement vers un hébergeur SecNumCloud est bien moins important pour un service comme Olvid que pour un service SaaS classique qui aurait accès aux données personnelles de ses utilisateurs. Par ailleurs, il nous paraît inutile de basculer l’intégralité de notre offre gratuite grand public sur des serveurs souvent très onéreux.

En revanche, nous prévoyons de proposer une architecture multicloud. Dans cette optique, nous sommes évidemment attentifs aux évolutions des offres PaaS labellisées SecNumCloud (ou une qualification européenne d’un niveau au moins équivalent).

Il existe aujourd’hui en France une offre SecNumCloud de type IaaS, c’est-à-dire, une infrastructure « nue » de serveurs. L’offre que nous utilisons aujourd’hui chez AWS est une offre de type PaaS (qui permet notamment d’abstraire les problématiques d’administration de serveur et de gestion de passage à l’échelle).

Il n’existe aujourd’hui pas d’offre SecNumCloud de type PaaS, car construire une offre de ce type à partir d’une IaaS représente un travail colossal. Plutôt que d’essayer de développer ce service nous-mêmes, il nous semble plus judicieux de profiter du savoir-faire des acteurs du cloud français en les laissant construire leur offre PaaS SecNumCloud à leur rythme.

Sans qu’elle soit exhaustive, voici une liste des technologies centrales au bon fonctionnement d’Olvid aujourd’hui (les dénominations utilisées sont celles d’AWS) :

  • API Gateway : permet d’implémenter une API REST et une API WebSocket à base de fonctions lambda, sans gérer de load balancing.
  • Fonctions lambda : qui nous permettent de traiter les requêtes clients sans avoir à gérer d’infrastructure serveur.
  • DynamoDB : Base de données dont le passage à l’échelle est entièrement « managé ».
  • SNS : qui nous permettent l’envoi de notifications push.
  • SQS : service PubSub pour le traitement asynchrone de certaines requêtes.
  • S3 : qui nous permettent de stocker les pièces jointes chiffrées de taille importante (parfois plusieurs gigaoctets).

Enfin, l’offre PaaS devra être capable de garantir une haute disponibilité.

Par ailleurs, nous faisons déjà appel à ces acteurs (comme Scaleway, Outscale et OVH) pour certains de nos outils en interne et pour certains de nos services aux entreprises et administrations.

Pour aller plus loin - Tracker

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. Cette librairie pourrait être utilisée pour remonter des données de télémétrie, mais elle n’est utilisée par Google Drive que pour des mesures de bande passante.

Olvid ne remonte donc aucune donnée de télémétrie, mais utilise Google Drive pour les sauvegardes automatiques dans le Cloud. Nous aurions aimé supprimer cette dépendance, mais elle est aujourd’hui 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).

Informations supplémentaires