C’est un article de France Inter qui a déclenché la guerre de communication. Nos confrères se sont demandés si les données manipulées par Doctolib étaient correctement protégées, notamment si leur chiffrement était suffisamment fort.

L’article qui en est ressorti, un peu confus, évoque un chiffrement incomplet, avec des tests ayant permis de conclure que les données étaient en clair sur les serveurs d’Amazon Web Services – utilisé par Doctolib pour le stockage et certifié pour le stockage des données de santé – avant d’être envoyées chez l’utilisateur. Doctolib et AWS pourraient accéder aux données.

Conclusions réfutées par Stanislas Niox-Château : « Une clé de chiffrement est générée et processée (sic) par Atos, de telle sorte que AWS n’a aucun accès à cette clé de chiffrement, ni en transit ni au repos ». Pas de chiffrement de bout en bout ? Il « ne peut pas se fabriquer sur l’ensemble des cas d’usage et la sécurité à 100 % n’existe jamais, sur aucun système au monde ». Mais il est quand même utilisé « pour la protection des documents médicaux et pour notre nouveau logiciel médical pour les médecins libéraux ».

Des éléments de réponse que l’on retrouve dans le communiqué du PDG sur Medium. Il y affirme que les données sont chiffrées au repos comme en transit, que le chiffrement de bout en bout – technique décrite comme « avant-gardiste » et « très faiblement déployée dans le monde » – continuera sa progression au sein de l’entreprise. En outre, les « différentes méthodes de chiffrement mises en place par Doctolib représentent l’état de l’art (sic) des recommandations des agences gouvernementales sur la cybersécurité ».

Pas question non plus qu’AWS accède aux données : elles sont hébergées en France et en Allemagne, elles sont chiffrées, et les clés sont hébergées en France chez ATOS. Et de rappeler que « le respect de la vie privée est un droit fondamental et c’est l’une des valeurs essentielles de Doctolib ».

Les découvertes de Rémy Grünblatt, chercheur à Inria, vont cependant dans le sens de France Inter. Il a ainsi découvert que les photos des médecins et établissements étaient stockées chez Cloudinary. Lors d’une requête pour trouver un praticien, les images sont chargées depuis les serveurs du prestataire. Cloudinary est donc en capacité de savoir « si l'utilisateur cherche un oncologue, un chirurgien dentiste, et peut techniquement re-construire la requête de l'utilisateur en utilisant les photos des praticiens ».

Selon lui, Doctolib envoie également des métadonnées à Google Analytics et Amazon sous forme de télémétrie. Malheureusement, dans les données envoyées à AWS, « on peut retrouver des URLs qui correspondent à ce que visite ou recherche l'utilisateur ».

Il pointe également l’utilisation de Cloudflare, dont l’adresse IP répond aux requêtes, même si le certificat TLS est celui de Doctolib. Pour le chercheur, cela « veut très probablement dire que Doctolib a uploadé sa clef privée sur les serveurs de Cloudflare (qui sert ainsi de terminaison TLS), ce qui signifierait que Cloudflare peut lire les données « en clair » ». Le réglage de Doctolib sur Cloudflare ne pouvant être connu, il ne pourrait être vérifié qu'après enquête, par exemple de la CNIL.

Les conclusions d’InterHop – association de promotion et de mise à disposition des logiciels libres et open-sources pour la santé – sont équivalentes. Les données de santé ne sont ainsi pas toujours chiffrées, il est « hautement probable » que Cloudflare y ait accès en tant que relais entre l’App Server et l’application, le chiffrement de bout en bout devrait être élargi à l’ensemble des documents et le risque d’ingérence américaine est à prendre au sérieux, en vertu du FISA, de l’Executive Order 12333 et du Cloud Act.

Voilà pourquoi InterHop et douze autres requérants avaient déposé un recours en urgence au Conseil d’État, pour demander l’annulation du partenariat entre Doctolib et l’État pour la campagne de vaccination contre la Covid-19. Le recours était examiné lundi, la réponse du Conseil est imminente.