Vers un réseau géo-social avec dégradation des données 

Télécharger le fichier pdf d’un mémoire de fin d’études

État de l’art

Dans le chapitre précédent, nous avons montré qu’il y avait une forte de-mande pour le développement de solutions techniques garantissant le droit à l’oubli. Malgré le résultat d’impossibilité évoqué plus haut, diverses mé-thodes ont été développées. Si elles n’offrent pas une solution générale, elles permettent toutefois de résoudre partiellement le problème du droit à l’oubli, dans certains contextes bien définis.
Dans ce chapitre, nous allons passer en revue les méthodes existantes en fonction des application considérées, en progressant du contexte le plus étroit vers le plus général.

Oubli programmé

Toutes les techniques que nous étudions dans cette section ont en commun un point essentiel : un mécanisme d’auto-destruction est intégré au système. Ainsi, toute donnée est ultimement condamnée à disparaitre, et ce dès son introduction dans le système. Le droit à l’oubli est ici assuré par la nature même de la technique de publication ou de stockage des données. Certaines techniques permettent toutefois de prolonger activement la durée de vie d’une donnée, mais assurer un stockage à long terme n’est clairement pas l’objectif principal de ce type d’architecture. Pour éviter de se reposer uniquement sur la bonne foi de l’hébergeur, ces techniques font intervenir des acteurs extérieurs. Une approche possible est par exemple de publier des données chiffrées et de garantir l’effacement des clés de chiffrement après un certain délai. Les deux systèmes de ce type les plus connus sont Ephemerizer [22] et Vanish [12].

Ephemerizer : une approche centralisée

Le concept d’Ephemerizer a été introduit par Perlman en 2005 [22]. Le système a été conçu au départ pour garantir la suppression d’e-mails ou de fichiers locaux après une date T . Dans ce qui suit, nous nous consacrons uniquement au cas des messages, par soucis de simplicité. En effet, on peut simuler des fichiers locaux éphémères si on sait réaliser des messages éphémère en s’envoyant un message à soi-même.
Une solution naïve consisterait à envoyer des messages chiffrés dont la clé est stockée sur une carte à puce sécurisée (pour éviter que la clé soit compromise ou copiée par erreur) et à détruire la carte après la date T . Cependant, cette solution nécessite autant de cartes à puce sécurisées que de dates d’expiration différentes. Elle serait donc coûteuse (prix des cartes) et peu pratique (gestion d’un grand nombre de cartes), donc irréaliste.
L’idée centrale d’Ephemerizer est d’assigner la gestion des clés à un service tiers appelé ephemerizer, qui concentrera ainsi l’expertise cryptographique nécessaire tout en amortissant les coûts sur plusieurs utilisateurs et plusieurs messages. De plus le système garantit que même si l’ephemerizer ou le desti-nataire du message est compromis 1, aucun message dont la date d’expiration
T est passée ne pourra être lu. Cette propriété est appelée confidentialité per-sistante, ou Perfect Forward Secrecy en anglais (PFS).
Considérons un scénario où un utilisateur, par exemple Alice, veut envoyer un message éphémère à un destinataire appelé Bob. Dans la suite, fMgK désigne le message M chiffré à l’aide de la clé K. Le principe est le suivant :
– L’ephemerizer diffuse des triplets (clé éphémère publique, identifiant, date d’expiration) = (Keph; keyId; T ). Lorsque T est passée, il oublie la clé privée associée à Keph ;
– Alice choisit une date d’expiration T et une chaine aléatoire S. Elle utilise un algorithme de chiffrement symétrique pour obtenir fMgS, puis elle utilise à la fois Keph et la clé publique de Bob KBob pour obtenir ffSgKBobgKeph. Elle transmet ensuite à Bob fMgS; ffSgKBobgKeph; keyId .
– Bob transmet ffSgKBobgKeph; keyId à l’ephemerizer et lui demande de déchiffrer fSgKBob ;
– Si Keph est encore valide, l’ephemerizer lui retourne effectivement fSgKBob, et Bob peut déchiffrer S avec sa clé privée, puis M à l’aide de S. Sinon, l’ephemerizer rejette la requête, le message est « oublié » puisqu’il ne peut pas être lu.
Pour respecter la propriété PFS annoncée, il ne faut pas stocker les données éphémères chiffrées uniquement avec des clés privées à long terme comme KBob. En effet, si on transmettait directement ffMgKBobgKeph, un atta-quant qui compromettrait Bob, même après la date T , pourrait déchiffrer M. Pour cette raison, on utilise un secret aléatoire S. Ainsi, si Bob est com-promis, fMgS ne peut quand même pas être déchiffré, et si Keph a expiré, l’ephemerizer ne peut plus déchiffrer ffSgKBobgKeph. En conclusion, tout message dont la date d’expiration est passée au moment de la brèche de sécurité ne pourra pas être lu 2.
De nombreuses extensions d’Ephemerizer ont été développées, en particu-lier les deux suivantes :
IBE-based Ephemerizer : Il s’agit d’une amélioration proposée par Nair, Dashti, Crispo et Tanenbaum en 2007 [19], qui révèle une faille dans le pro-tocole initial d’Ephemerizer et propose un schéma alternatif résistant à cette attaque. De plus, ce nouveau schéma utilise une technique cryptographique appelé chiffrement fondé sur l’identité (Identity Based Encryption, IBE [6]) où l’on peut choisir arbitrairement la clé publique utilisée pour chiffrer les données. Le destinataire des données doit ensuite solliciter la clé de déchiffre-ment auprès d’une autorité de confiance qui la calcule à la volée. Les auteurs utilisent cette propriété pour permettre à l’émetteur de choisir la date d’ex-piration qui sera encodée dans la clé IBE, au lieu de lui imposer une liste de dates pré-définies.
Timed-Ephemerizer : En 2009, Tang propose [25] une solution à la faille évoquée ci-dessus, ainsi qu’un modèle de sécurité rigoureux et prouvé ma-thématiquement, qui garantit que le système résiste aux attaques passives par écoute (même venant de l’ephemerizer lui-même) et qu’un destinataire compromis après l’expiration ne permet pas à l’attaquant de récupérer le message éphémère. Il introduit également dans le schéma de communication la possibilité de bloquer l’accès à un message avant une date pré-définie (Timed-Release Encryption), d’où le titre de l’article. Au lieu de donner uni-quement la date d’expiration du message, on peut ainsi définir précisément une fenêtre pendant laquelle il sera disponible. Cette fenêtre ne débute pas forcément dès son émission.

Vanish : exploiter le P2P

Vanish, développé depuis 2009 par Geambasu, Kohno, Levy et Levy [12] vise à résoudre le même problème qu’Ephemerizer mais sans utiliser un tiers de confiance. En effet, l’approche de Perlman implique deux inconvénients :
(a) il faut faire confiance à l’ephemerizer, qui peut potentiellement être mal-veillant et représente un point de vulnérabilité unique dans le système (ainsi, si l’ephemerizer est indisponible, un message ne peut pas être lu) ; (b) il faut créer et maintenir un nouveau service. Ces deux inconvénients posent une barrière importante à l’adoption d’un tel système.
Les concepteurs de Vanish ont donc décidé d’utiliser des Tables de Hachage Distribuées (DHT, d’après le nom anglais) pour remplacer l’ephemerizer. Une DHT implémente de manière robuste une base de données stockant des paires (clé, valeur) sur un ensemble de nœuds d’un réseau pair-à-pair. Les DHT possèdent quatre propriétés particulièrement appropriées au contexte de Vanish :
1. Leur passage à l’échelle (plus d’1 million de nœuds pour la DHT de Vuze, un des clients BitTorrent les plus utilisés [10]) et la répartition géographique des nœuds à travers le monde entier les protègent effica-cement d’adversaires légalement puissants et influents. En effet, un tri-bunal n’a pas forcément autorité pour exiger la divulgation de données stockées dans un autre pays et un gouvernement pourrait difficilement négocier avec l’ensemble de tous les autres pays impliqués ;
2. Une DHT fournit un stockage redondant et décentralisé, donc plus fiable qu’un serveur unique comme dans Ephemerizer. En effet, même si certains nœuds sont indisponibles, il y a une grande probabilité pour que la donnée requise soit disponible sur un autre nœud. Le système ne possède plus de point de défaillance unique. Un message a donc plus de chances d’être disponible jusqu’à sa date d’expiration ;
3. En même temps, le phénomène d’attrition (churn en anglais) garantit de manière probabiliste que le message sera bien supprimé et qu’au-cune copie de sauvegarde ne survivra par erreur. Une DHT évolue en permanence, au fur et à mesure que des nœuds rejoignent ou quittent le réseau, changent d’identifiant ou nettoient leur mémoire interne, et les données qui ne sont pas activement répliquées disparaissent ainsi de manière irrévocable ;
4. Enfin, des infrastructures implémentant des DHT existent et sont déjà disponibles. Il n’y a donc pas besoin de développer et maintenir un nou-veau service uniquement pour Vanish (contrairement à Ephemerizer).
Vanish repose également sur la technique du partage de secret de Shamir [24] qui permet de découper un message en n morceaux et de garantir que, pour un entier k < n prédéfini : (a) tout sous-ensemble de k morceaux permet de reconstituer le texte initial ; (b) aucun sous-ensemble de k 1 morceaux ne donne d’information sur le contenu du texte initial.
Pour envoyer un message éphémère avec Vanish, Alice chiffre le message en utilisant une clé K pour obtenir fMgK, elle coupe K en n parts et les répartit dans la DHT en utilisant une clé d’accès L choisie aléatoirement, et elle envoie à Bob (fMgK; L). Bob utilise alors L pour récupérer au moins k parts sur la DHT (k est prédéfini par Alice au départ) et reconstitue la clé K. Il peut ainsi déchiffrer fMgK.
Ici, le canal de communication entre Alice et Bob est supposé sécurisé : en effet, quiconque possède L peut reconstituer le message. Vanish, comme Ephemerizer, ne protège que les messages dont la date est expirée au mo-ment de la brèche de sécurité. En pratique, le message (fM gK; L) peut être simplement chiffré avec un logiciel comme PGP ou GPG 3 : c’est la suppres-sion de K dans la DHT qui garantit que le message ne sera plus disponible au-delà d’une certaine date, et cela même si la clé de chiffrement GPG est compromise a posteriori.
Initialement, Vanish était proposé comme un plug-in Firefox et son im-plémentation reposait au choix sur Vuze [10], réseau ouvert avec plus d’un million de nœuds, ou sur un réseau à accès restreint, construit à par-tir d’OpenDHT [23], ce qui permet d’éviter certains types d’attaques. Par exemple, un attaquant peut entrer sur la DHT de Vuze et copier toutes les clés disponibles pour empêcher leur effacement. Avec OpenDHT, un atta-quant externe à la DHT (donc utilisant simplement l’interface standard de la DHT) n’aura pas connaissance de la localisation des clés, qui est pseudo-aléatoire, et ce type d’attaque sera beaucoup plus difficile. Depuis, de nom-breuses extensions ont été proposées :
Cascade [11] est un framework modulaire qui permet de répartir des parts de secret dans différents systèmes hétérogènes. De cette manière, chaque système apporte des garanties de sécurité complémentaires et un attaquant doit être capable de corrompre tous les systèmes pour reconstituer le message initial ;
Tide [11] est un système de stockage des parts s’appuyant sur Apache. Il permet notamment d’éviter les attaques par crawling, où un attaquant récupère activement un maximum de clés pendant leur période de validité, et les stocke pour un usage ultérieur (sans savoir lesquelles seront effectivement utiles) ;
Comet [13] est une DHT personnalisable en fonction de l’application visée. L’idée est qu’un objet stocké dans la DHT n’est pas qu’une valeur passive mais peut transporter avec lui un fragment de code qui va contrôler son comportement. Appliqué à Vanish, cela permet par exemple de contrôler précisément la réplication des clés, qui était trop agressive dans Vuze 4 ;
EphPub [8] est un système de publication éphémère qui stocke les clés dans des serveurs DNS au lieu d’utiliser une DHT. Les serveurs DNS sont naturellement résistants aux attaques Sybil, qui consistent à générer un grand nombre d’identités virtuelles pour contrôler une large proportion des nœuds d’un réseau distribué. Il s’agit d’une amélioration par rapport à Vanish car les DHT ouvertes comme celle de Vuze sont particulièrement sensibles à ce type d’attaques, même si les inventeurs de Vanish proposent déjà [11] des solutions pour limiter ce problème.
À noter que des plug-in Firefox et Thunderbird ont été publiés pour Vanish et EphPub. Ils ne sont toutefois pas maintenus et ne sont plus compatibles avec les versions actuelles.

Solutions grand public

Les systèmes précédents n’ont jamais dépassé le stade du prototype de recherche. Cependant, des systèmes de publication éphémère disponibles pour le grand public existent, et plusieurs ont récemment suscité l’intérêt.
Le premier, X-pire ! [5], a été proposé dès 2011 pour publier des photos sur Facebook ou Flickr de manière éphémère. En effet, Facebook et Flickr (et la plupart des services actuels) ré-encodent les photos uploadées. Or Epheme-rizer ou Vanish ne permettent pas la modification du chiffré et ne pouvaient donc pas être utilisé dans ce contexte. X-pire ! est une solution payante 5 fondée sur le principe d’Ephemerizer.
Peu de détails techniques sont disponibles sur Poke 6, développé de ma-nière fermé par Facebook, mais le système semble également fondé sur Ephe-merizer, avec Facebook dans le rôle du tiers de confiance central. Facebook précise cependant que la suppression des clés de chiffrement effectuée n’est pas parfaite et que des traces peuvent en subsister dans les logs ou les copies de sauvegarde pendant 90 jours. 7
Parmi les solutions évoquées ici, Snapchat 8 est malheureusement à la fois la plus populaire 9 et celle qui offre le moins de garanties 10. En réalité, l’application consiste simplement en une interface avec le système de fichier, et n’utilise ni cryptographie ni suppression sécurisée. Il est donc possible de récupérer les images même après leur prétendue expiration.

Oubli envisagé

Les techniques étudiées dans la section précédente garantissent que les données seront supprimées après une certaine date. Cependant, beaucoup de données ne sont pas a priori destinées à être supprimées. Par exemple, les données stockées dans un nuage sont souvent là pour être conservées sur le long terme. Pourtant, un utilisateur qui décide de supprimer un fichier veut être sûr que le fichier est réellement supprimé, et que le service d’héberge-ment n’en conserve pas une copie en dépit de sa demande de suppression, se contentant de retirer les liens publics vers le fichier.
Pour répondre à ces situations, un sujet a besoin d’un système qui lui permette de garder le contrôle sur ses données et de tracer les copies réalisées, pour être en mesure de supprimer une donnée et ses différentes copies s’il le souhaite, quel que soit l’hébergeur actuel. Les politiques adhésives (sticky policies en anglais) permettent de réaliser toutes ces fonctionnalités.

Concept général de politique adhésive

Le concept de politique adhésive a été introduit pour la première fois par Karjoth et Schunter [15], puis formalisé par Casassa Mont, Pearson et Bram-hall [7] de la manière suivante :
– Les données personnelles du sujet sont chiffrées avant qu’il ne les diffuse ;
– Une politique d’utilisation est définie par l’utilisateur 11. Elle est ensuite liée aux données de manière persistante et résistante à la falsification, d’où le terme de politique « adhésive » ;
– Les données ne peuvent être lues par un processeur potentiel que s’il satisfait aux exigences de la politique associée ;
– Pour pouvoir déterminer les responsabilités des différents processeurs et hébergeurs, toute divulgation consécutive des données est enregistrée et vérifiée.
La description ci-dessus est une spécification de haut niveau, purement fonctionnelle. Elle ne présage rien des moyens techniques à mettre en œuvre, mais décrit simplement les propriétés que doit satisfaire un système utili-sant des politiques adhésives. Dans le même article, les auteurs suggèrent cependant quelques techniques qui seront détaillées plus loin.
Toutefois, il faut signaler que le passage du concept à l’implémentation est loin d’être évident. En effet, il est difficile de donner des garanties sur le respect des propriétés décrites plus haut, en particulier de s’assurer que les politiques resteront bien « adhésives » tout au long de l’utilisation des données et qu’un contrôleur qui divulgue les données à une tierce partie le reporte effectivement à l’autorité de vérification compétente. De plus, la spécification même des politiques n’est pas une tâche évidente.
Enfin, il faut noter que si les politiques adhésives permettent effectivement d’implémenter le droit à l’oubli, leur champ d’application est beaucoup plus vaste. Définir quand une donnée doit être supprimée n’est que l’un des nom-breux aspects qui peuvent être spécifiés dans une politique d’utilisation des données et un utilisateur peut également définir les traitements autorisés sur ses données, s’il doit être notifié lorsque ces traitements sont effectués, quels sont les contrôleurs autorisés, etc.

Spécification des politiques

À l’heure actuelle, les politiques de confidentialité et les conditions d’utili-sation des sites web ou des services en ligne sont toujours exprimées en lan-gage naturel, la plupart du temps sous forme de termes juridiques 12. Ainsi, elles sont à la fois inaccessibles à la compréhension de l’utilisateur moyen et non interprétables par une machine. Or pour toute mise en pratique réaliste des politiques adhésives, elles doivent être interprétables par une machine, afin d’automatiser le traitement décrit par Casassa Mont, Pearson et Bram-hall [7]. Dans cette optique, différents langages et normes ont été développés :
– Le projet P3P (Platform for Privacy Preference) [20] est un standard développé par le consortium W3C, débuté en 2000 ;
– XACML (eXtensible Access Control Markup Language, actuellement en v3.0) [17] définit un schéma XML pour représenter des politiques de contrôle d’accès. Il est développé par OASIS, organisation encourageant l’adoption de standards pour le e-business et les services webs ;
– PPL (PrimeLife Policy Language) [26], une extension de XACML 2.0 qui permet d’exprimer de manière symétrique les préférences de l’utili- sateur et les politiques appliquées par le contrôleur des données.

Garantie sur l’application des politiques

Garantir l’application des politiques adhésives pose deux problèmes dis-tincts :
1. Comment vérifier que les politiques appliquées par un contrôleur ou un processeur sont compatibles avec les préférences d’un utilisateur avant de l’autoriser à lire ses données personnelles ?
2. Comment être sûr qu’un processeur, après avoir accédé aux données en clair, les chiffrera de nouveau avant de les transmettre à un tiers et rapportera bien la divulgation à l’autorité de vérification appropriée ?
Pour le premier point, il est possible d’utiliser des techniques de chiffre-ment IBE. Comme une clé publique IBE peut être une chaine de caractères arbitraire, on peut en particulier utiliser la politique d’utilisation des don-nées comme clé publique. Ceci garantit que la politique est liée aux données chiffrées de manière résistante à la falsification, puisque si la politique est mo-difiée, la clé publique n’est plus la bonne et les données ne peuvent plus être déchiffrées. Le destinataire des données (un processeur) doit ensuite solliciter la clé de déchiffrement privée auprès d’une autorité de confiance, éventuel-lement distribuée, qui la calcule à la volée à partir de la clé publique non altérée. Si une technique de certification forte est mise en place (voir pa-ragraphe suivant), cette autorité peut vérifier que le processeur satisfait les conditions exigées par la politique avant de retourner la clé. Toutefois, même en l’absence de certification, la clé publique utilisée est une trace fiable que le processeur s’est engagé à respecter la politique d’utilisation, et il pourra être tenu responsable des infractions constatées par la suite. On parle alors de privacy through accountability par opposition à privacy by design, que l’on pourrait traduire par « protéger la vie privée par la responsabilisation plutôt que par conception ». Casassa Mont, Pearson et Bramhall suggèrent d’utiliser cette technique [7].
Pour le second point, la technologie du Trusted Computing – littéralement « informatique de confiance » – semble être la voie privilégiée dans la littéra-ture à l’heure actuelle [16]. Une des implémentations du Trusted Computing repose sur un dispositif résistant à la falsification qui dispose d’un proces-seur, d’une mémoire sécurisée, de primitives cryptographiques, d’une horloge interne et d’une source d’énergie indépendantes et appelé TPM (pour Trus-ted Platform Module). À l’aide de son TPM, une plateforme de confiance est capable de garantir qu’elle n’a pas été compromise, de chiffrer des données en les « scellant » au matériel et de témoigner de certaines propriétés tout en conservant son anonymat [21]. En particulier dans le contexte qui nous intéresse, une plateforme de confiance peut attester qu’elle ne transmet les données personnelles que sous forme chiffrée et qu’elle ne diffusera pas la copie en clair après l’avoir déchiffrée.

Oubli sans mesure préventive

Il faut garder à l’esprit qu’à l’heure actuelle, les données sont persistantes par défaut, principalement de part leur nature numérique. Les solutions pré-sentées dans les sections précédentes permettent, pour certains cas d’utili-sation ou certains contextes, de changer ce comportement par défaut, mais elles ne sont pas toujours applicables. En particulier, elles exigent de prendre des précautions au moment de la publication, et ne peuvent être appliquées rétroactivement pour toutes les données déjà existantes. Il est donc aussi fondamental que les utilisateurs prennent conscience des problèmes de vie privée et assimilent ce que représente la publication de données en ligne. Le rapport de l’ENISA [9] souligne bien qu’un changement de comportement est nécessaire et doit être encadré par une évolution politique et juridique.
Toutefois, si les données sont aujourd’hui conservées indéfiniment, elles ne sont pas toujours exploitables. L’avènement du web collaboratif et de l’« In-ternet des objets » [4] a provoqué une explosion de la quantité d’informations disponibles, et certains spécialistes parlent aujourd’hui d’un « déluge de don-nées ». Pour accéder aux données, les utilisateurs se reposent de plus en plus sur des intermédiaires, par exemple les moteurs de recherche comme Google ou Bing, ou encore des systèmes de recommandations du type de Reddit. En un certain sens, une donnée qui est disponible en ligne en accès direct, mais qui n’est pas trouvable (ou difficilement) par les intermédiaires sus-mentionnés peut donc être considérée comme « oubliée » car non-visible.

Table des matières

1 Introduction 
1.1 Définitions
1.2 Problématique
2 État de l’art 
2.1 Oubli programmé
2.2 Oubli envisagé
2.3 Oubli sans mesure préventive
3 Application de la dégradation des données au droit à l’oubli 
3.1 Durée de rétention optimale
3.2 Dégradation progressive
3.3 Extension de la dégradation
3.4 Les pratiques de la dégradation à l’heure actuelle
4 Garantir la dégradation des données 
4.1 Acteurs en présence
4.2 Modèle d’attaque
4.3 Cas pratique
4.4 Description de notre architecture
4.5 Avantages
4.6 Limitations et extensions possibles
5 Vers un réseau géo-social avec dégradation des données 
5.1 Scénario de la simulation
5.2 Remarques sur l’implémentation
6 Conclusion 
Bibliographie

Télécharger le rapport complet