Dgradation des donnes

par publication phmre

Simon Bouget

Sbastien Gambs

Guillaume Piolle

Rsum 

Le respect de la vie prive est un droit fondamental mais dicile garantir sur
Internet. Malgr les recommandations des experts, le principe de minimisation des donnes 
qui exige notamment que les donnes soient eaces aussitt qu'elles ne sont plus strictement
ncessaires (rtention minimale )  est rarement appliqu, en raison d'intrts divergents
entre les hbergeurs des donnes personnelles et les utilisateurs. Pour diminuer l'impact de
ces divergences, une alternative la rtention minimale a t propose, la dgradation des
donnes : au lieu d'tre compltement eace, une donne peut tre progressivement dgrade
vers des tats moins prcis qui protgent mieux la vie prive de l'utilisateur tout en conservant
(partiellement) l'utilit de la donne initiale. Cependant, aucune architecture n'existe l'heure
actuelle qui garantisse la dgradation des donnes sans un gestionnaire de base de donnes
de conance. En utilisant un systme de publication phmre (une donne ne peut plus
tre accde aprs une date d'expiration xe l'avance), nous proposons dans ce travail
une architecture dcentralise qui garantit la dgradation des donnes sans aucun acteur de
conance dans le systme.
1 Introduction

Le respect de la vie prive est un droit fondamental mais malheureusement dicile protger en
ligne. Dans un eort de systmatisation, la recherche dans ce domaine a dgag un grand principe qui,
s'il est mis en pratique, permet de limiter les risques pour les utilisateurs : le principe de minimisation
des donnes, qui consiste notamment limiter la collecte et la rtention des donnes personnelles : un
utilisateur ne doit rvler que les donnes ncessaires pour raliser le service souhait et rien de plus
et elles ne doivent pas tre conserves plus longtemps que la dure ncessaire pour remplir ce service.
Pourtant, ce principe est rarement implment dans les technologies existantes. En particulier, les dlais
de rtention sont quasi-systmatiquement survalus, voire non explicitement dclars, sous prtexte de
constituer un prol client, de fournir des services personnaliss plus performants, etc. En eet, c'est
grce la montisation des donnes de leurs utilisateurs (via la publicit par exemple) que la plupart
des services en ligne gagnent de l'argent. Il y a donc une contradiction importante entre les intrts du
contrleur des donnes, qui cherche maximiser son prot partir des donnes personnelles collectes,
et l'utilisateur, qui souhaite le respect de sa vie prive.
Pour minimiser ce conit, un nouveau mcanisme a t propos [1] qui est une variante de la suppression
exige par la rtention minimale : la dgradation des donnes. Au lieu d'une situation binaire  soit
conserve soit eace , une donne peut exister dans dirents tats, dirents niveaux de prcision,
qui protgent de manire plus ou moins forte la vie prive de l'utilisateur mais, inversement, permettent
de pouvoir raliser plus ou moins de services.

ENS

Cachan - Antenne de Bretagne : simon.bouget@ens-cachan.fr

Universit
SUPELEC

de Rennes 1 / Inria : sebastien.gambs@irisa.fr

: guillaume.piolle@supelec.fr

Toutefois, l'heure actuelle, les seuls systmes de dgradation des donnes qui existent en pratique
sont mis en uvre par un SGBD 1 spcialement adapt pour cette tche. L'utilisateur doit donc faire
conance au contrleur des donnes et le croire sur parole lorsqu'il dclare appliquer la dgradation.
tant donn notre motivation de dpart  rduire l'impact des intrts divergents entre utilisateur et
contrleur , cette hypothse nous parat dicile admettre, et nous proposons ici une architecture qui
ore des garanties techniques sur l'application de la dgradation des donnes, sans ncessiter l'existence
d'un acteur de conance dans le systme, et fonde sur un systme de publication phmre dcentralis
qui assure la dgradation des donnes.
Par la suite, nous prsentons les travaux existants dans les domaines de la publication phmre et de
la dgradation des donnes (Section 2), puis nous dtaillons l'architecture propose partir de ces deux
mcanismes (Section 3). Enn, nous dveloppons un exemple utilisant cette architecture pour illustrer
nos propos (Section 4), avant de conclure.
2 tat de l'art

Notre travail repose sur la combinaison de deux aspects : la dgradation des donnes et la publication
phmre, pour lesquels nous dtaillons les travaux existant dans ce qui suit.
Les systmes de publication phmre permettent de publier des chiers tout en garantissant qu'ils ne
seront plus accessibles au del d'une date d'expiration T . L'hypothse importante commune tous ces
systmes est qu'aucun utilisateur mal intentionn ne doit accder un chier avant la date T . Sinon, il
peut en faire une copie et rediuser cette copie ou y accder aprs l'expiration, et la publication phmre
perd tout son intrt. Les systmes de publication phmres supposent donc que des mcanismes de
contrle d'accs plus traditionnels sont mis en place pour protger le chier avant son expiration.
L'article fondateur du domaine est celui de Radia Perlman en 2005, o elle introduit Ephemerizer [7].
L'ide centrale est que pour avoir des messages phmres, il sut de diuser des messages chirs et
d'assurer l'eacement des cls la date d'expiration. Cependant, cette gestion des cls peut tre dicile
mettre en place si chaque utilisateur doit grer ses propres cls et de nombreuses dates d'expiration.
Perlman propose donc de concentrer les tches de gestion dans un service centralis, nomm ephemerizer,
ce qui permet d'amortir les cots sur l'ensemble des utilisateurs et sur un nombre plus important de
messages.
Depuis, diverses extensions et amliorations ont t dveloppes pour Ephemerizer : dtection puis
correction de failles l'aide de nouveaux schmas de communication [6, 9], granularit plus ne de
la date d'expiration [6] et mme spcication d'une fentre de disponibilit au lieu d'une simple date
d'expiration [9]. Toutefois, l'ephemerizer est un nud central sur lequel repose tout le systme. Mme si
ce n'est plus l'hbergeur, c'est encore un acteur auquel il est ncessaire de faire conance. En consquence,
cela revient seulement dplacer le problme.
Avec la volont de supprimer ce besoin de conance dans une partie cruciale du systme, Geambasu,
Kohno et al. ont cherch dcentraliser Ephemerizer. partir de 2009, ils ont propos Vanish [4], o
l'ephemerizer central est remplac par une THD 2 et les cls de chirement sont stockes en plusieurs
fragments sur dirents nuds l'aide d'un partage de secret la Shamir [8]. De cette manire, aucun
nud du rseau ne possde seul la capacit d'accder aux donnes, et il n'y a plus besoin d'acteur de
conance.
Comme pour Ephemerizer, de nombreuses amliorations ont t proposes pour Vanish. On notera en
particulier Cascade [3], un framework gnrique qui permet de rpartir les parts du secret dans n'importe
quel systme de stockage (et mme dans plusieurs systmes simultanment), et plus seulement dans une
THD ; Tide [3] et EphPub [2], qui permettent respectivement de stocker les parts dans des serveur Apache
et DNS.
En ce qui concerne le principe de dgradation, son intrt en tant qu'alternative la simple suppression
a t postul par Anciaux, van Heerde et al. partir de 2008 [1, 12] et principalement explor dans la thse
1. Systme de Gestion de la Base de Donnes
2. Table de Hashage Distribue.

de van Heerde [11], publie en 2010. Comme eux, nous pensons que la dgradation des donnes permet
d'augmenter la valeur totale 3 d'un ensemble de donnes personnelles, compar la simple suppression.
Cependant, la dgradation y est prsente comme une mesure que le contrleur des donnes (ici, le
gestionnaire de la base) peut mettre en place pour limiter les consquences d'une fuite involontaire tout
en prservant l'utilit des donnes. De notre point de vue, le problme abord n'est pas la fuite involontaire
des donnes, mais le manque de conance entre l'utilisateur et le contrleur. En consquence, la mise en
place de la dgradation directement par le contrleur n'est pas satisfaisante.
3 Description du systme

Dans cette section, nous allons prsenter en dtails l'architecture que nous proposons partir des deux
techniques dtailles ci-dessus.
3.1 Acteurs en prsence

Nous considrons des systmes qui mettent en relation deux types d'acteurs : les utilisateurs (ou
et les hbergeurs (ou contrleur ). Ces systmes peuvent tre de purs systmes d'hbergement (e.g.
Dropbox 4 ) ou des rseaux sociaux (e.g. Facebook 5 , Foursquare 6 ) qui hbergent les donnes relatives
l'utilisation du systme (liste des pages aimes par l'utilisateur, des lieux visits, etc.).
En ralit, le rle de l'hbergeur est souvent double : en plus d'tre contrleur des donnes, il en est
aussi le processeur, c'est--dire celui qui eectue des traitements sur les donnes pour les valoriser. C'est
particulirement le cas dans les rseaux sociaux, o les donnes que l'utilisateur publie permettent de
lui construire un prol que le rseau social pourra ensuite montiser (auprs d'une rgie publicitaire par
exemple). Par la suite, nous prendrons soin de distinguer prcisment ces deux rles de contrleur et de
processeur.

sujet )

3.2 Architecture propose

L'interaction entre les dirents acteurs, rsume dans la Figure 1 (p. suivante), s'articule de la manire
suivante : lorsqu'il souhaite publier une donne, un utilisateur doit d'abord eectuer localement les tapes
de dgradations vers chaque niveau de prcision. Il envoie ensuite une copie chire de chaque tat
l'hbergeur. videmment, chaque tat doit tre chir avec une cl dirente puisqu'il a potentiellement
sa propre date d'expiration. Les cls de chirements sont ensuite stockes dans une structure de donnes
dcentralise  non contrle par l'hbergeur , une position dtermine partir de cls de localisation
alatoires. Dans un systme la Vanish, la structure utilise est une THD, mais il peut galement
s'agir de serveurs DNS, Apache, etc. Enn, l'utilisateur envoie chaque processeur la cl de localisation
correspondant au niveau de prcision qu'il est autoris consulter.
De cette manire, l'hbergeur ne possde que des copies chires, et c'est le systme dcentralis 
rsistant aux collusions et de nombreux types d'attaques  qui assure la dgradation des donnes, en
oubliant les cls de chirement au fur et mesure que le temps passe. La rtention minimale de chaque
niveau de prcision est ainsi assure. Seuls les processeurs explicitement autoriss par l'utilisateur (via
l'envoi de la cl de localisation) peuvent accder aux donnes, et il peut avoir globalement conance que
la dgradation est bien applique
Il faut noter que si l'hbergeur est uniquement hbergeur, il n'a plus aucun intrt fournir le service.
En gnral, il sera donc aussi un processeur autoris un faible niveau de prcision, dont la rtention
au-del de la date d'expiration ne prtera pas consquence au cas o l'hbergeur serait malveillant.
3.3 Dtail des sous-systmes

L'architecture propose est constitu de deux sous-ensembles : le systme d'hbergement proprement

dit et le systme de gestion des cls. Dans cette section nous allons dtailler leur fonctionnement.
3. Valeur totale au sens de bien commun, valeur cumule pour l'utilisateur et le contrleur.
4.
5.
6.

https://www.dropbox.com/
https://www.facebook.com/
https://foursquare.com/

Stockage distribu
(DHT, ...)

4) Rcupre le secret
partir de Li

Diffrents processeurs
de donnes

2) Stocke les Ki

sur n nuds distincts

choisis partir des Li

5) Rcupre
la donne chiffre et
la dchiffre
avec le secret

3) Transmet chaque Li

au processeur autoris

Secrets Ki n parts +

1) Envoie une donne chiffre

et pr-dgrade

Hberg.

Cls de localisation Li
Utilisateur

Figure 1: Schma simpli de notre architecture, avec les direntes tapes de publication d'une donne.

Hbergement

Lorsqu'un utilisateur veut ajouter une entre dans la base de donnes, il doit dgrader
les donnes avant de les transmettre l'hbergeur. Dans notre contexte, on ne peut pas parler du niveau
global de prcision d'une entre, il faut traiter les donnes attribut par attribut. Avoir dirents niveaux
de prcision pour un attribut revient ddoubler la colonne correspondante de la base, ce qui augmente
l'espace de stockage ncessaire pour chaque entre. Toutefois, les donnes dont la date d'expiration est
passe peuvent tre supprimes, ce qui permet de rcuprer de l'espace de stockage le cas chant.
Cependant, le SGBD n'a pas connaissance de l'expiration des donnes. Il faut donc introduire un nouveau mcanisme pour lui permettre de supprimer les donnes obsoltes. Nous envisageons deux solutions :
 le SGBD considre une dure de vie a priori pour chaque colonne, ce qui n'empche pas l'utilisateur
de spcier une dure de vie plus courte. Par contre, s'il spcie une dure de vie plus longue, la cl
sera prsente dans le systme de gestion des cls mais la donne aura dj t eace de la base ;
 l'utilisateur spcie au moment o il ajoute une entre la date d'expiration de chaque attribut.
Cette solution augmente lgrement la consommation de bande passante, mais ore une plus grande
exibilit au systme.

Gestion des cls

Pour illustrer notre proposition, nous dcrivons ici le fonctionnement d'un systme
de type Vanish, mais n'importe quel autre systme de publication phmre conviendrait galement. Le
systme de gestion des cls est le suivant : pour chaque cl de chirement utilise, l'utilisateur eectue
un partage de secret. Le partage de secret, ou schma seuil (k, n), est une technique cryptographique
consistant dcouper un secret en n parts avec les proprits suivantes :
 n'importe quel sous-ensemble de k parts permet de reconstruire l'intgralit du secret ;
 tout sous-ensemble d'au plus (k 1) parts ne donne aucune information sur le secret.
L'utilisateur choisit ensuite alatoirement une cl de localisation L qui dtermine quelle adresse seront
stockes les parts dans la THD, puis il transmet aux nuds correspondants la date d'expiration souhaite
et une des n parts du secret. Enn, il envoie chaque processeur la ou les cls de localisation qui lui
permettront de dchirer les attributs auxquels il a le droit d'accder.

3.4 Hypothses et limitations

Notre architecture reposant sur un systme de publication phmre, elle doit vrier les mmes
hypothses que le systme en question. Pour Vanish, il faut en particulier les proprits suivantes :
 le sujet est capable d'tablir un canal de communication asynchrone et sr avec les processeurs, pour
leur transmettre les cls de localisation. C'est possible par courrier lectronique avec chirement
asymtrique, par exemple, mais cela constitue un point d'attaque supplmentaire sur le systme. De
plus, cela peut complexier l'interface du systme et avoir un impact sur l'adoption par le grand
public 7 ;
 un attaquant ne peut pas de manire raliste prendre le contrle d'une part signicative de la THD
et collecter prventivement assez de parts du secret pour dchirer les donnes aprs leur date
d'expiration. Cela dpend de la THD utilise, et la validit de cette hypothse a t conteste [13],
mais les direntes corrections et extensions ralises [3, 5] orent des garanties raisonnables sur ce
point.
De plus, quel que soit le systme de publication phmre utilis, seule l'expiration de l'exemplaire
original de la donne est garantie. Si un acteur accde (de manire lgitime) une donne en clair avant
la date d'expiration et en fait une copie, cette copie ne sera pas protge, il est donc ncessaire que
chaque acteur prenne un soin particulier viter les copies intempestives, comme cela peut se produire
avec la mise en cache de pages web ou l'archivage de requtes sur une base de donnes, par exemple.
Enn, la base de donnes tant chire, de nombreuses recherches ou agrgations de donnes deviennent
impossibles. Ce n'est pas toujours gnant, notamment dans le cas d'interactions entre utilisateurs d'un
rseau social (accs direct une entre donne, sans recherche), mais cela peut empcher certaines tches
de fouilles de donnes par exemple. On peut supposer que les acteurs qui ralisent ces tches sont des
processeurs autoriss un faible niveau d'accs, qui feront une copie locale en clair des donnes traites,
qu'ils auront la charge de protger convenablement contre les accs illgitimes.
4 Vers un rseau go-social avec dgradation des donnes.

L'architecture prsente dans la section prcdente est gnrique et peut potentiellement tre applique
n'importe quelle base de donne. Cependant, de nombreux dtails sont spciques chaque application
particulire : nombre d'tapes de dgradation, choix du processus de dgradation (gnralisation, ajout
de bruit, ...), dure de rtention pour chaque niveau de prcision, etc. Pour illustrer plus prcisment
notre propos, nous dcrivons dans cette section un exemple ctif mettant en application ce qui prcde.
Pour notre exemple, nous avons choisi un rseau go-social de type Foursquare car les donnes golocalises se prtent relativement bien au principe de dgradation : on peut gnraliser des coordonnes
GPS par troncature, un lieu avec un arbre ontologique, etc.
Tout d'abord, dnissons les lments du systme.
Les acteurs en prsence sont : (a) l'entreprise qui gre le rseau go-social ; (b) un utilisateur-tmoin, du
point de vue duquel les exemples seront dtaills ; (c) ses relations dans le rseau ; (d) des fournisseurs
d'applications tierces.
Les donnes stockes par le rseau sont : (i) lieux visits ; (ii) coordonnes visites ; (ii) date des visites ;
(iii) conseils sur un lieu. Les lieux sont dgrads par gnralisation en utilisant une ontologie (suppose
partage entre tous les utilisateurs). Les coordonnes sont dgrades par transformation en intervalle.
Les conseils sont dgrads par suppression du nom de l'auteur.
Enn, droulons quelques cas d'usage :
 une relation de l'utilisateur-tmoin veut le retrouver : c'est un processeur autoris avec un niveau de
prcision maximale sur les coordonnes visites, mais avec un dlai de rtention trs faible (quelques
heures) ;
 un commerant local (application tierce) veut envoyer une promotion l'utilisateur lorsqu'il est
proximit : c'est un processeur autoris pour les coordonnes visites avec un niveau de prcision
"quartier" pour un dlai de rtention de quelques heures ;
7. L'article original sur Vanish proposait un plug-in Firefox pour envoyer des mails phmres via GMail, et les auteurs
avaient particulirement veill ce que son utilisation soit la plus transparente possible.

 l'entreprise gestionnaire veut tablir un prol publicitaire : c'est un processeur autoris pour les
lieux visits, mais seulement au niveau de prcision "catgorie de lieu", avec un dlai de un an. Ces
rglages sont susants pour dnir des habitudes de consommation, sans rvler la localisation ou
les dtails de l'emploi du temps de l'utilisateur.
Ces exemples mettent en vidence que le choix des tapes de dgradation et des dlais de rtentions
pour chaque tat ne doit pas tre fait arbitrairement, mais en cohrence avec les services souhaits.
L'ensemble des choix possibles peut tre complexe grer pour un utilisateur non-avertis, mais on peut
raisonnablement esprer que des moteurs automatiss de gestions des politiques de condentialit comme
le PPL Engine [10] pourront terme intgrer ce paramtrage dans leurs fonctionnalits.
Conclusion

Dans ce travail, nous dfendons l'intrt de la dgradations des donnes en tant qu'alternative
leur suppression, pour augmenter la valeur totale d'un ensemble de donnes et minimiser l'impact des
intrts divergents entre utilisateurs et hbergeurs. De plus, ce nouveau mcanisme ne pourra tre largement adopt que s'il permet une conance accrue entre les dirents acteurs. Nous armons donc que
l'implmentation de la dgradation ne doit pas tre laisse aux mains des hbergeurs et nous prsentons
une architecture dcentralise, fonde sur un systme de publication phmre, qui permet des garanties
techniques sur la mise en pratique de ce mcanisme.
Nous terminons avec un exemple ctif qui permet d'illustrer nos propos et dtaille certains points
importants de la conception d'un systme de dgradation par publication phmre. Un prototype de
dmonstration de cet exemple, utilisant un systme existant de publication phmre et des donnes
relles est en cours de dveloppement.
Rfrences

[1] Nicolas Anciaux, Luc Bouganim, Harold Van Heerde, Philippe Pucheral, and Peter M.G. Apers.
Data Degradation : Making Private Data Less Sensitive Over Time. In Proceedings of the 17th
ACM Int. Conf. on Information and Knowledge Management (CIKM), pages 14011402, 2008.
[2] Claude Castelluccia, Emiliano De Cristofaro, Aurelien Francillon, and Mohamed-Ali Kafaar. EphPub : Toward robust ephemeral publishing*. Proceedings of IEEE ICNP, pages 118, 2011.
[3] Roxana Geambasu, Tadayoshi Kohno, Arvind Krishnamurthy, Amit Levy, Henry Levy, Paul Gardner, and Vinnie Moscaritolo. New directions for self-destructing data systems. Technical report,
2011.
[4] Roxana Geambasu, Tadayoshi Kohno, Amit A. Levy, and Henry M. Levy. Vanish : Increasing data
privacy with self-destructing data. Procs 18th USENIX Security, 2009.
[5] Roxana Geambasu, Amit Levy, Yoshi Kohno, Arvind Krishnamurthy, and Hank Levy. Comet : an
active distributed key-value store. Procs 9th OSDI, 2010.
[6] Srijith K. Nair, Mohammad T. Dashti, Bruno Crispo, and Andrew S. Tanenbaum. A hybrid PKIIBC based ephemerizer system. Procs 22nd IFIP SEC, 2007.
[7] Radia Perlman. The Ephemerizer : Making data disappear. Journal of Information System Security
(JISSec), 2005.
[8] Adi Shamir. How to share a secret. Communications of the ACM, November 1979.
[9] Qiang Tang. From Ephemerizer to Timed-Ephemerizer : Achieve assured lifecycle enforcement for
sensitive data (extended version). initially EUROPKI, 2009.
[10] Slim Trabelsi, Akram Njeh, Laurent Bussard, and Gregory Neven. PPL engine : A symmetric architecture for privacy policy handling. W3C Workshop on Privacy and data usage control, October :5,
2010.
[11] Harold van Heerde. Privacy-aware data management by means of data degradation : making private
data less sensitive over time. PhD thesis, University of Twente, Enschede, The Netherlands, June
2010.

[12] Harold van Heerde, Maarten Fokkinga, and Nicolas Anciaux. A framework to balance privacy and
data usability using data degradation. In Procs 12th CSE. Ieee, 2009.
[13] Scott Wolchok, Owen S. Hofmann, Nadia Heninger, Edward W. Felten, J. Alex Halderman, Christopher J. Rossbach, Brent Waters, and Emmett Witchel. Defeating Vanish with low-cost Sybil attacks
against large DHTs. In Procs 17th NDSS, 2010.