Notification d‘un destinataire

Lorsqu‘un partage est créé, chaque destinataire doit être notifié afin de pouvoir récupérer les documents auxquels il a droit. Dans le Web actuel où les moyens de communications sont légions et disparates, le courriel apparaît comme le moyen le plus universel et interopérable pour contacter un destinataire. Nous l‘utilisons donc comme système de base pour notifier le sujet d‘un partage. Cela implique donc que le propriétaire d‘un Cloud personnel connaisse à minima l‘adresse mail d‘un sujet pour pouvoir partager avec lui. Si c‘est bien le cas, un e-mail est automatiquement généré et contient une URL forgée à partir des métadonnées du partage qui devra être cliquée par le destinataire pour qu‘il puisse visualiser le partage. Deux cas de figure peuvent se produire :

 Cas 1 : l’émetteur du partage connaît l’adresse du Cozy du destinataire. L‘e-mail contient alors une URL forgée à partir de cette adresse et qui redirige le destinataire vers sa propre plateforme, afin qu‘il puisse visualiser les permissions demandées et accepter le partage.

 Cas 2 : L’émetteur du partage ne connaît pas l’adresse du Cozy du destinataire. L‘e-mail contient une URL qui redirige le destinataire vers la plateforme de l‘émetteur. Il lui est alors demandé de rentrer l‘adresse de son Cozy pour recevoir le partage. Une fois cela fait, le destinataire est redirigé vers son Cloud personnel pour visualiser les permissions. Parallèlement, le Cozy de l‘émetteur complète automatiquement la fiche contact du destinataire avec l‘URL fournie, dans le respect du principe d’auto-administration.

Ce système de notification et de visualisation des permissions est indispensable pour s‘assurer du principe d’empowerment éclairé, mais cette fois du point de vue du destinataire. Comme ce dernier accorde des droits en écriture sur sa plateforme afin de recevoir les documents partagés, il doit s‘assurer que ce qui lui est demandé soit bien légitime. La Figure 22 montre un exemple de visualisation des permissions pour un partage de répertoire.

133

Figure 22. Pages des permissions

Ici, la connaissance d‘un destinataire est conditionnée par la connaissance de son e-mail. Le problème de l‘identité sur internet est un sujet intéressant mais néanmoins complexe, et de nombreux travaux existent pour tenter de le résoudre, au moins partiellement. Citons par exemple WebID [Inkster 2017], présenté en 2.2.1, qui propose d‘utiliser des URI sémantiques comme moyen d‘échanger des identités et d‘en découvrir de nouvelles grâce à graphe social exprimé en FOAF. De même, XDI [Reed 2004] recommande un identifiant unique sur le Web pour chaque individu auquel chacun peut associer des traits d‘identité publics ou privés. Des registrars sont alors en charge d‘assurer la correspondance entre identifiant et trait d‘identité, de la même façon qu‘un DNS traduit un nom de domaine en IP. Malheureusement, ces travaux n‘ont pas encore fait consensus et sont pour le moment difficilement exploitables dans un contexte industriel comme celui de Cozy Cloud. Cependant, bien qu‘extrêmement populaire, le courriel souffre d‘un problème natif de sécurité ; le contenu des e-mails est transmis en clair sur le réseau, ce qui le rend vulnérable à des attaques de confidentialité. Un attaquant qui écoute le réseau serait potentiellement capable d‘intercepter un e-mail de partage, avec les conséquences décrites ci-dessous.

134 S‘il s‘agit du cas 1, où l‘URL contenu dans l‘e-mail redirige vers le Cozy du destinataire, l‘attaquant ne pourra rien faire de plus qu‘apprendre l‘existence du partage entre les deux pairs. Il sera incapable de connaître le contenu des documents, ni d‘impacter le déroulement du partage. Une fois établi, tous les échanges du protocole sont chiffrés via TLS⁶⁵. L‘attaquant ne pourra donc rien intercepter de plus que ce qui est dévoilé par ce protocole, c‘est-à-dire les métadonnées des échanges, comme les adresses IP de l‘émetteur et du destinataire.

En revanche, s‘il s‘agit du cas 2, l‘URL redirige vers une page du Cozy de l‘émetteur qui n‘est pas protégée, car le destinataire ne dispose alors d‘aucun secret partagé avec l‘émetteur. L‘attaquant serait donc capable d‘entrer l‘adresse de son propre Cloud personnel pour recevoir le partage à la place du destinataire légitime et potentiellement tous les futurs partages, si l‘émetteur ne se rend pas compte de la supercherie.

Plusieurs solutions peuvent être envisagées pour se protéger de ce genre d‘attaque. PGP [Zimmermann 1995], détaillé en 2.2.1, permet de chiffrer le contenu des e-mails de bout en bout et d‘authentifier l‘émetteur. Mais il est loin d‘être massivement utilisé, notamment à cause de sa difficulté d‘utilisation et la complexité liée à la signature des clés et de la confiance qui peut leur être accordée. De plus, seul le contenu est chiffré, les en-têtes contenant les métadonnées restent en clair.

Le protocole OTR [Borisov 2004] est une autre piste envisageable. Il permet de réaliser des échanges asynchrones chiffrés en évitant certaines faiblesses de PGP, en particulier le manque de forward secrecy, qui se traduit par le fait que la compromission d‘une clé PGP permet de déchiffrer toutes les communications passées. La répudiation est une autre propriété intéressant de OTR, qui permet à un tiers de nier avoir eu des communications passées avec un sujet.

D‘autres protocoles préfèrent l‘utilisation du numéro de téléphone comme identifiant universel [Ermoshina 2016]. Ce système se révèle efficace pour les communications mobiles chiffrées [Cohn-Gordon 2016], mais requiert l‘installation d‘une application dédiée sur un

135 appareil du destinataire, typiquement son Smartphone, ce qui n‘est pas vraiment adapté à l‘usage du Cloud personnel.

Bien que des solutions existent, aucune ne s‘impose réellement et ce problème reste ouvert. L‘implémentation actuelle utilise les e-mails pour notifier les destinataires, via STARTTLS qui impose l‘utilisation du chiffrement TLS durant le transport, donc de protéger contre un attaquant qui espionnerait le réseau. Dans le futur, nous souhaiterions utiliser des systèmes plus robustes, tout en préservant une expérience utilisateur fluide. La simplicité de la découvertede nouveaux contacts et la façon de les notifier est un point crucial pour la facilité d‘utilisation du partage et de son adoption. Nous espérons donc que le modèle actuel servira de base à l‘utilisation de moyens plus évolués et sécurisés pour atteindre ces objectifs.