Protection de la vie privée sur Internet

28/08/2017
Publication REE REE 2006-8
OAI : oai:www.see.asso.fr:1301:2006-8:19681
DOI :

Résumé

Protection de la vie privée  sur Internet

Métriques

31
8
3.39 Mo
 application/pdf
bitcache://5ad4d11fcb6df846dc4dce3b8f4ccb84086e0d0c

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/1301:2006-8/19681</identifier><creators><creator><creatorName>Yves Deswarte</creatorName></creator><creator><creatorName>Carlos Aguilar Merchor</creatorName></creator><creator><creatorName>Vincent Nicomette</creatorName></creator><creator><creatorName>Matthieu Roy</creatorName></creator></creators><titles>
            <title>Protection de la vie privée  sur Internet</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2017</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Mon 28 Aug 2017</date>
	    <date dateType="Updated">Mon 28 Aug 2017</date>
            <date dateType="Submitted">Sun 9 Dec 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">5ad4d11fcb6df846dc4dce3b8f4ccb84086e0d0c</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>33438</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

Protection de la vie privée sur Internet Mots clés Sécuritéinformatique, Internet, Protectiondelavieprivée Yves DESWARTE, Carlos AGUILAR MELCHOR, Vincent NICOMETTE, Matthieu ROY LAAS-CNRS, Tou/ouse Au vu du rôle de plus en plus important joué par Internet dans notre société, il est pri- mordial d'assurer la sécurité des systèmes informatiques qui y sont connectés, et ceci dans le respect de la vie privée de ses utilisateurs. Les technologies de protec- tion de la vie privée présentées dans cet article peuvent aider à répondre à cette dou- ble attente. 1. Introduction Dans notre société, protéger sa vie privée est consi- déré comme l'un des droits primordiaux, reconnu entre autres par la charte européenne des droits fondamentaux [6]. Cette considération est à l'origine de nombreuses législations internationales sur le stockage, le traitement et la transmission de données personnelles. En 1978, la France était l'une des premières nations à se doter d'une loi protégeant les données personnelles, la loi dite « Informatique et Libertés » [18], révisée en août 2004 [19]. En septembre 1980, l'Organisation de Coopération et de Développement Économiques (OCDE) a publié un guide sur la protection et les mouvements transfrontières des données personnelles [15]. En décembre 1990, l'Assemblée générale des nations unies a elle aussi adopté un guide sur les fichiers informatiques de données personnelles. En 1995, la directive européenne 95/46/EC protégeant les données à caractère personnel a été adop- tée, et elle est maintenant transposée dans les législations nationales de tous les pays membres de l'Union euro- péenne. Malgré cette réglementation, les citoyens et les consommateurs considèrent que les nouvelles technolo- gies représentent un danger pour leur vie privée, et ce sentiment général est un frein au développement de la société de l'information. La réglementation est vue comme mal appliquée, comme le montrent de fréquents incidents qui font la manchette des journaux. Il est donc nécessaire de développer des technologies qui permettent de garantir la protection des données personnelles, et ainsi regagner la confiance du public. A première vue, la vie privée devrait pouvoir être proté- gée par des moyens classiques de sécurité informatique : au fond, il ne s'agit de garantir que la confidentialité de don- nées ou de méta-données personnelles [10], et il existe de nombreuses techniques pour protéger la confidentialité. Mais " le diable se niche dans les détails " des techniques de sécurité : pour contribuer à prouver qu'une action est légitime (ou non), il faut collecter et conserver beaucoup d'informations qui peuvent nuire à la vie privée. Ainsi le développement actuel des techniques de traçabilité et d'authentification forte se justifie par un souci d'amélio- rer la sécurité, mais il met en danger la vie privée des uti- lisateurs. Il faut donc protéger la vie privée par des tech- nologies adaptées. Les critères coiiiniiins [6] définissent la protection de la vie privée (privacy) comme une classe de fonctionna- lité, avec quatre exigences principales : ESSENTIEL SYNOPSIS Alors que dans notre société, protéger sa vie privée est reconnu comme l'un des droits fondamentaux,lescitoyenset les consom- mateursconsidèrent que les nouvellestechnologiesreprésentent un danger pour la protection de leur vie privée, et ce sentiment généralest un frein au développementde la société de/'informa- tion. Cet article présente des technologiesde protection de la vie privée (Privacy-Enhancing Technologiesou PET)qui permettent d'améliorerla confiancedes utilisateursenversles servicesdispo- nibles sur Internet. Elles sont au nombre de quatre : la gestion des identités, les communications et accès anonymes,les sché- mas d'autorisation respectant lavie privée,et la gestion des don- néespersonnelles. In our society, privacy is consideredas a fundamental right. Yet, with the rapid grow of Internet use, users lack ways to protect their privacy. This paper presents some Privacy-Enhancing Technologies (PETsIthat can contribute to give users more confi- dence on the protection of their privacy.Fourof these technolo- gies are considered: identity management,anonymouscommuni- cation and access, privacy-compliantauthorization schemes and personaldata management. REE N'9 Octobre2006 1 Repères RISQUES ET SÉCURITÉ DES RÉSEAUX ET DES SYSTÈMES A COMPOSANTE LOGICIELLE (2' " partie l'anonymat (anonyinity) exige que d'autres utilisa- teurs ou sujets soient incapables de déterminer l'identité d'un utilisateur associé à un sujet ou à une opération ; . la possibilité d'agir sous un pseudonyme (pseudony- MÏ exige qu'un ensemble d'utilisateurs ou de sujets soit incapable de déterminer l'identité d'un utilisateur associé à un sujet ou à une opération, mais que cet utilisateur réponde quand même de ses actions ; . l'impossibilité d'établir un lien (unlinkability) exige que des utilisateurs ou des sujets soient incapables de déterminer si le même utilisateur a déclenché cer- taines opérations spécifiques dans le système ; . la non-observabilité (unobservability) exige que des utilisateurs ou des sujets ne puissent pas déterminer si une opération est en cours d'exécution. Ce sont ces exigences que devraient satisfaire les technologies de protection de la vie privée (Privacy- Enhancing Technologies ou PET) pour améliorer la confiance des utilisateurs de services Internet. Mais l'im- plémentation de ces technologies ne doit bien sûr pas aller à l'encontre d'autres exigences critiques, comme la lutte contre la criminalité. Par exemple, l'usage de pseu- donymes (avec les propriétés indiquées ci-dessus) doit être préféré à un anonymat total : les PET devraient pro- téger les utilisateurs légitimes vis-à-vis d'entreprises ou d'agences qui tenteraient de violer leur vie privée, sans pour autant aider des criminels à perpétrer des actions illégales en toute impunité. Cela est possible si les PET sont fournies et maintenues sous le contrôle de citoyens honnêtes, qui coopèrent avec les autorités judiciaires dûment habilitées, mais qui ne contribueraient pas à un usage abusif par d'autres parties. Pour protéger la vie privée des utilisateurs d'Internet, on peut considérer quatre catégories de PET, qui sont brièvement décrites dans les sections suivantes : gestion des identités, communications et accès anonymes, sché- mas d'autorisation respectant la vie privée, et enfin ges- tion des données personnelles. La conclusion introduira quelques exemples d'autres PET, qui ne sont pas directe- ment reliés à l'Internet. 2. Gestion des identités Pour qu'une personne puisse protéger sa vie privée, il est important de cacher ou de réduire autant que possible les liens entre cette personne et les actions et données cor respondantes. Par exemple, si une personne est le seul uti- lisateur d'un ordinateur connecté à Internet avec une adresse IP fixe', il est possible pour un observateur d'as- socier à cette personne toutes les informations émises depuis cette adresse IP : l'adresse IP peut alors être consi- dérée comme un identifiant unique, c'est-à-dire qu'il est propre à une seule personne. De tels identifiants uniques permettent d'établir un lien fort entre différentes actions indépendantes réalisées par la même personne, ou entre des ensemble d'informations liées à la même personne. C'est donc une menace directe contre la vie privée, et en particulier vis-à-vis de la troisième exigence des critères communs présentés précédemment (unlinkability). Un moyen pour réduire les risques d'établissement de tels liens consiste à utiliser des communications anony- mes et des accès anonymes aux services (voir la section 3). Mais bien souvent c'est insuffisant, puisque pour obtenir un service personnalisé, l'utilisateur doit se faire reconnaître avec une identité. L'identité peut être définie comme la représentation d'une personne pour un service. Cette fois encore, si une personne accède à plusieurs ser- vices sous la même identité, il est possible d'établir un lien entre ces accès. Aussi est-il souhaitable d'avoir des identités virtuelles (ou pseudonymes) multiples pour accéder à des services multiples. Bien sûr, chaque per- sonne doit pouvoir sélectionner quelle identité utiliser pour chaque service, et doit pouvoir gérer la validité tem- porelle de ses identités : si la même identité est utilisée pour plusieurs accès à un ou plusieurs services, il est pos- sible d'établir une correspondance entre ces accès, et cette correspondance peut être plus ou moins sensible du point de vue de la vie privée. L'utilisateur devrait donc pouvoir définir une date d'expiration pour chacune de ses identités, les deux choix extrêmes étant une identité valide une fois (une nouvelle identité doit être générée à chaque accès) et une identité permanente. Différentes identités peuvent aussi être utilisées pour différents niveaux d'exigences vis-à-vis de la vie privée. Par exemple, certaines identités virtuelles ne servent qu'à permettre d'enregistrer certaines préférences de l'utilisa- teur, sans que ce soit des données personnelles directe- ment identifiantes (ou à caractère nominatif). Pour un service de météo par exemple, ces préférences porteront sur le choix de la ville, ou des unités (degrés Celsius ou Fahrenheit, miles ou kilomètres, etc.). En revanche, d'au- tres identités pourraient être dédiées aux accès à des ser- vices sensibles, tels que ceux de déclaration d'impôts ou de vote électronique, etc. La vérifiabilité des identités doit être directement liée à la sensibilité des services : aucune authentification n'est utile pour accéder à un ser- vice non sensible qui ne stocke ni ne gère aucune donnée personnelle à caractère nominatif, alors qu'une authenti- fication forte devrait être exigée pour des services sensi- Lefait qu'unutilisateuratoujours(ousouvent)la mêmeadresseIPpeuts'observerfacilement,parexempledanslesen-têtesdescourrielsqu'il envoie. 1 REE N'9 Octobre2006 Protection de la vie privée sur Internet bles, pour empêcher toute usurpation d'identité. De plus, un utilisateur devrait sélectionner des identités différentes pour accéder à des services sensibles différents. Par exemple, il faudrait utiliser des identités différentes, sans lien direct entre elles mais toutes deux avec une forte authentification, pour déclarer ses impôts et pour s'ins- crire sur des listes électorales, de façon à se prémunir contre des abus éventuels de certaines administrations ou gouvernements. Ainsi, il serait dangereux d'utiliser un unique certificat à clé publique (par exemple stocké sur une carte d'identité nationale électronique) pour l'accès à tous les services publics. Au contraire, il est souhaitable d'utiliser des certificats différents, même s'ils sont tous émis par des services de l'État, à condition bien sûr qu'il ne puisse y avoir collusion entre ces services. La gestion, par un utilisateur, de ses multiples identi- tés est un problème qui peut être complexe [16], et pour- tant elle doit être rendue suffisamment facile pour être utilisable et compréhensible par chaque citoyen, quelles que soient ses aptitudes techniques. Ceci est l'un des défis majeurs du projet européen PRIME (Privacy and Identity Management for Europe) è 3. Communication et accès anonymes L'écoute passive de communications est une menace importante contre la vie privée puisque, même si le contenu d'une communication peut être chiffré, la simple observa- tion des adresses source et destination (dans les paquets IP, par exemple) peut révéler des informations sensibles. 3.1. Définitions et exemples On peut définir plusieurs types d'anonymat pour les communications. L'anonymat d'émission est obtenu par un utilisateur face à un attaquant lorsque celui-ci est inca- pable de détecter l'émission de messages par l'utilisateur. De manière similaire, l'anonymat de réception est obtenu par un utilisateur face à un attaquant lorsque celui-ci est incapable de détecter la réception de messages par l'utili- sateur. L'anonymat relationnel est obtenu par un groupe d'utilisateurs face à un attaquant lorsque l'attaquant est incapable de savoir si deux membres du groupe commu- niquent entre eux ou pas. De ces définitions, il découle de façon immédiate que si l'anonymat d'émission (ou de réception) est garanti à chaque utilisateur d'un groupe, le groupe possède la propriété d'anonymat relationnel. Il est important de remarquer que les anonymats d'émission, de réception et relationnel ne procurent pas par eux-mêmes la confidentialité du contenu des messa- ges : il faut pour cela utiliser des techniques appropriées, comme le chiffrement. À l'inverse, le chiffrement du contenu des messages en soi ne procure pas l'anonymat des communications. Ces différents types d'anonymat sont intimement liés. Par exemple si un utilisateur n'a que l'anonymat d'émis- sion, et pas d'anonymat de réception, l'augmentation sou- daine du nombre de messages reçus par lui pourrait dévoiler l'existence d'une communication et donc indi- rectement qu'il est en train d'envoyer des messages. La cohérence des propriétés d'anonymat dans un système doit donc être analysée de façon rigoureuse. 3.2. Les MIX et les réseaux de MIX 3.2. 1. Les MIX En 1981 David Chaum a introduit le problème de l'analyse de trafic, en soulignant que la vie privée des uti- lisateurs était en danger dès lors qu'un observateur peut déterminer l'existence d'une communication ou identifier deux personnes qui communiquent entre elles [8]. Pour empêcher l'analyse de trafic, il a proposé un protocole utilisant des routeurs qu'il a appelés MIX. Les MIX sont des routeurs qui cachent le lien entre les messages entrants et sortants. Un attaquant peut essayer de rétablir ce lien grâce à deux techniques simples. La première consiste à analyser les contenus des messages pour recon- naître un message entrant parmi les messages sortants. Cette attaque peut être passive (par simple lecture et ana- lyse des messages), ou active, par l'introduction de faux messages. Par exemple, un attaquant peut comparer les tailles des messages entrants et sortants ou réémettre un message qui a été précédemment envoyé de façon légi- time, pour reconnaître parmi les messages sortants lequel est répété, identifiant ainsi la route du message original (attaque par rejeu). Pour éviter de telles attaques, les MIX utilisent du bourrage et un chiffrement aléatoire : en fonc- tion de l'implémentation, les messages entrants peuvent être déchiffrés puis chiffrés à nouveau (comme dans la figure 1), ou simplement déchiffrés si plusieurs couches de chiffrement sont appliquées au message original. -,,,, y1 E Figure 1. Un MIX simple. Un deuxième type d'attaques est basé sur le fait qu'un message entrant et un message sortant ont d'autant plus de chance d'être liés que le temps qui sépare la réception de l'un de l'émission de l'autre est court. Pour contrer cette analyse temporelle, un MIX peut utiliser deux tech- niques différentes. S'il reçoit un trafic important, le MIX 1 REE N'9 Octobre2006 Protection de la vie privée sur Internet Pour ces raisons, un effort important de recherche a été mené ces dernières années sur les structures de réseaux de MIX pair à pair, tels que Tarzan [13] et Morphix \ où n'importe quel utilisateur peut devenir un MIX et participer à une cascade. Dès lors, pour transmet- tre un message, on choisit aléatoirement des MIX dans un large ensemble de volontaires répartis partout dans le monde, ce qui réduit considérablement les risques de col- lusion : à la fois le grand nombre et la rapide évolution de l'ensemble de MIX garantit que ce serait une tâche colos- sale que de les pirater ou les contraindre à révéler leurs informations de routage. Ces systèmes sont appelés des réseaux de MIX (voir figure 3). Si les utilisateurs sont des noeuds du réseau de MIX, les messages transitant par chaque noeud (plus les faux messages, si nécessaire) for- ment un trafic de couverture pour les messages réelle- ment émis ou reçus par l'utilisateur correspondant à ce noeud, et donc l'émission et la réception ne peuvent être détectées par une simple écoute passive. Cela garantit les anonymats d'émission, de réception et relationnel. 3.3. Accès anonymes aux services Internet Fournir des communications anonymes ne suffit pas pour obtenir un accès anonyme à un service : les messa- ges envoyés au fournisseur de service peuvent contenir des informations identifiantes, qu'il faut effacer ou trans- former par un mandataire (proxy) avant qu'elles ne soient transmises au fournisseur. Cette transformation dépend de la sémantique du message (c'est-à-dire de la significa- tion de son contenu), et la tâche peut donc être très ardue. Si le mandataire est dédié à un service spécifique, il est relativement aisé d'analyser la syntaxe des en-têtes, par exemple, pour éliminer une partie des informations sensi- bles. Cependant, la structure des messages requis par la plupart des services peut être très variable, et donc très difficile à rendre anonyme. Bien sûr, utiliser un seul mandataire pour accéder à un service suppose que l'on ait confiance dans ses adminis- trateurs, puisqu'ils peuvent enregistrer des informations sensibles sur l'application comme sur les communica- tions. La façon la plus sûre de naviguer consiste sans doute à combiner un relais d'anonymat local au niveau application avec un réseau de MIX au niveau communi- cation. Néanmoins cette solution est coûteuse et peut par- fois être remplacée par une solution basée sur un manda- taire distant. 4. Schémas d'autorisation respectant la vie privée Les services Internet peuvent être classés en deux caté- gories : les services d'accès public, et les services d'accès restreint. Les services d'accès public devraient être acces- sibles sans authentification, et donc tout utilisateur devrait pouvoir y accéder sans se faire identifier, puisqu'aucune autorisation spécifique n'est nécessaire. En revanche, les services restreints ne sont fournis que selon des règles strictes d'autorisation. Dans a plupart des cas, l'autorisa- tion est basée sur le modèle client-serveur : le serveur décide d'accorder ou de refuser ses services au client, en fonction de règles définies par le serveur lui-même. Généralement, le serveur exige que le client soit enregistré, identifié et authentifié (par exemple, en échangeant un mot de passe au travers d'une adresse de courriel valide). Le serveur stocke aussi les données de la transaction pour ser- vir de preuve en cas de litige. Pour cela, le serveur doit ras- sembler de nombreuses informations personnelles sur le client pour chaque transaction, et ces données pourraient être utilisées abusivement à d'autres fins que la résolution de litiges : profilage de clients, marketing direct, y compris par spam, chantage et autres. Dans certains cas, ces don- nées peuvent être commercialisées auprès d'autres entre- prises, voire être utilisées pour usurper l'identité d'utilisa- teurs vis-à-vis d'autres serveurs'. Le projet Platfôrm for Privacy Preferencey' (P3P) du World-Wide-Web Consor- tium vise à réduire ces risques, en vérifiant que les exigen- ces de respect de la vie privée du client sont compatibles avec la politique de sécurité et de préservation de la vie pri- vée proclamée par le serveur. Mais en fait P3P ne garantit pas que la politique proclamée est bien mise en oeuvre par le serveur, avec des mécanismes de sécurité suffisamment efficaces, en particulier pour la gestion des données per- sonnelles dans les procédures non routinières comme la gestion des sauvegardes pour des systèmes de secours, les évolutions technologiques des serveurs, la transmission de fichiers clients à d'autres entreprises, la faillite ou la fusion d'entreprises, etc. Ce schéma asymétrique client-serveur s'adapte mal à de nombreuses applications sur Internet : non seulement il est dangereux pour la vie privée, mais en plus il est peu pratique lorsqu'il y a plus de deux parties prenantes dans une transaction. Par exemple, une transaction typique d'achat sur Internet implique non seulement un acheteur et un marchand, mais aussi un établissement de carte de cré- dit, la banque du client et celle du marchand, une entreprise de livraison, sans parler des fournisseurs d'accès à Internet ou les opérateurs de télécommunications. Pour résoudre ce problème dans le modèle client-serveur, l'une des parties, par exemple le marchand, sert généralement d'intermé- diaire avec toutes les autres : le marchand joue le rôle de serveur vis-à-vis de l'acheteur, mais aussi de client (man- dataire) vis-à-vis des autres parties (serveurs). Pour cela, le marchand collecte généralement d'abord auprès de l'ache- teur suffisamment d'information personnelle (y compris ' C'estaussiunedesraisonspourlesquellesilvautmieuxutiliserdesidentitésdifférentes(etdesmotsdepassedifférents)pouraccéderàdesservicesdifférents. 5 sion d'autorisation devrait être prise pour l'ensemble de la transaction, alors que la mise en oeuvre de la décision devrait être réalisée par toutes les parties de façon cohé- rente. La séparation en décision d'autorisation et mise en oeuvre de cette décision par des mécanismes de contrôle d'accès est un bon principe de conception, soutenu par des normes telles que [17], où les deux fonctions, « fonc- tion de décision de contrôle d'accès » et « fonction de mise en cpuvre de contrôle d'accès », sont bien séparées. Cela est particulièrement utile lorsque la transaction est répartie, c'est-à-dire lorsque différents mécanismes de contrôle d'accès doivent mettre en oeuvre une décision commune. Mais c'est aussi très naturel dans des systèmes centralisés, puisque la décision d'autorisation peut résul- ter d'un processus complexe, prenant en compte la politi- que de sécurité, quel sujet tente de réaliser quelle opéra- tion sur quel objet, et le contexte de sécurité courant. Pour que ce schéma soit efficace, il faut que la décision soit prise à un niveau élevé de granularité, par exemple une transaction complète. En revanche, le contrôle d'accès lui-même doit être mis en oeuvre au niveau de granularité le plus fin possible, par exemple à chaque accès élémen- taire, pour empêcher le contournement du contrôle d'ac- cès. Par exemple, la décision d'autoriser la lecture d'un fichier peut être prise à l'ouverture du fichier, alors que le contrôle doit s'appliquer à chaque accès au fichier. Les mécanismes de contrôle d'accès doivent obéir aux princi- pes du monitetir de références [20] : ils doivent être invio- lables, incontournables et totalement vérifiables. Ils doi- vent également être aussi rapides et simples que possible, et transparents pour le logiciel d'application. Un schéma d'autorisation basé sur ces principes a été développé par le projet européen MAFTIA (Malicious- and Accidental-Fault Tolerance for Internet Applica- tions) [9]. Lorsqu'un utilisateur désire exécuter une transac- tion répartie, il transmet une requête d'autorisation à un ser- veur d'autorisation distribué, qui, si la transaction est auto- risée, renvoie un ensemble de permissions à l'utilisateur. Les permissions sont des preuves d'autorisation pour toutes les opérations élémentaires qui peuvent faire partie de la transaction. La mise en oeuvre du contrôle d'accès se fait localement sur chaque machine-hôte participant à une trans- action MAFTIA, au moyen d'un moniteur de références, implémenté en partie dans une carte à puce pour résister efficacement aux tentatives de falsification. Chaque invoca- tion de méthode est interceptée par le moniteur de référen- ces de la machine où se trouve l'objet invoqué. Si l'invoca- tion est accompagnée d'une capacité valide, l'invocation est réalisée. Dans le cas contraire, elle est rejetée. Dans ce schéma, le serveur d'autorisation joue le rôle d'une tierce partie de confiance (TTP, Trusted Third Party), chargée des décisions d'autorisation pour les machines participantes. Pour le rendre digne de 1 REE N,9 Octobre2006 confiance, le serveur d'autorisation est distribué entre plusieurs sites, chacun administré séparément, de telle sorte que la défaillance ou la corruption d'un petit nom- bre de ces sites ne puisse empêcher des décisions correc- tes d'être prises et des permissions valides d'être géné- rées, ni convaincre les autres sites de prendre de mauvai- ses décisions ou de générer de fausses permissions : le serveur d'autorisation tolère les défaillances accidentelles et les intrusions dans un petit nombre des sites qui le com- posent. La décision peut être soit basée sur l'identité ou un pseudonyme de l'utilisateur, authentifié par un serveur d'authentification séparé (un autre TTP), soit basée sur des garanties anonymes, comme indiqué précédemment. Ce schéma peut donc être directement adapté pour implé- menter un système d'autorisation préservant la vie privée, ainsi que cela est envisagé pour le projet européen PRIME précédemment cité. 4.2. Monnaie électronique (e-Cash) La monnaie électronique (ou e-Cash) est un type de garantie anonyme particulier, dans le sens qu'elle permet d'effectuer certaines opérations (autorisation), avec une compensation financière, mais sans dévoiler d'identité. La monnaie électronique vise à apporter les mêmes avan- tages que les pièces de monnaie traditionnelles tout en permettant une utilisation dans un contexte numérique, comme c'est le cas pour les cartes de crédit. Parmi les propriétés de la monnaie traditionnelle qui sont souhaita- bles pour la monnaie électronique, on s'intéresse particu- lièrement à : . la transférabilité de la monnaie entre utilisateurs, sans interaction avec une banque ; . la liquidité : une pièce de monnaie peut être conver- tie en pièces de valeur moindre ; . l'anonymat : il ne doit pas être possible d'établir un lien entre les paiements effectués à l'aide des pièces de monnaie, ni entre les dépôts et les retraits, etc. ; l'infalsifiabilité : il ne doit pas être possible de créer de fausses pièces ; l'unicité : il ne doit pas être possible de dépenser plusieurs fois la même pièce. De nombreux articles ont été publiés ces dernières années sur ce sujet, et de nombreuses solutions théoriques sont actuellement disponibles. Certaines nécessitent que la banque soit en ligne, d'autres non. Il y a différentes approches, avec différentes propriétés. L'énumération de ces solutions déborderait de l'objectif de cet article, et nous recommandons au lecteur intéressé de consulter le site Web de l'International Financial Cryptography Association ". 5. Gestion des données personnelles Les données personnelles appartiennent à la personne à laquelle elles se rapportent, elles n'appartiennent pas au propriétaire du système qui stocke ces données. Par exemple, on reconnaît généralement, au moins en Europe, que le dossier médical appartient au patient, et non pas au médecin qui le crée ou le met à jour, ni à l'hô- pital qui le conserve dans ses fichiers. En tant que pro- priétaire de ses données personnelles, tout individu doit pouvoir garder ces informations sous son contrôle, autant que possible. Cela signifie que les données personnelles devraient être stockées de façon permanente seulement sur des dispositifs directement sous son contrôle, plutôt que sur des serveurs qu'il ne contrôle pas, et ces données ne devraient être divulguées à un tiers que selon le prin- cipe du besoin d'en connaître : . les données divulguées devraient se limiter à celles strictement nécessaires pour l'accomplissement de la tâche décidée ou acceptée par la personne (mini- misation des données personnelles), * te tiers ne devrait garder ces informations confiden- tielles et ne devrait y accéder que pour réaliser la tâche désignée par la personne ; il devrait donc les effacer dès qu'elles ne sont plus nécessaires à l'ac- complissement de cette tâche (autodétermination des données personnelles). Ces deux points sont analysés dans les sous-sections suivantes. 5.1. Minimisation des données personnelles La première mesure de minimisation consiste, pour l'utilisateur, à ne divulguer que les informations qui sont réellement nécessaires pour remplir l'objectif prévu pour la transaction, et ces informations ne devraient être divul- guées qu'aux seules parties qui en ont besoin. Prenons un exemple simplifié d'une transaction d'achat sur Internet, impliquant un client, un marchand, une entreprise de livraison, la banque du client et celle du marchand. Le marchand a besoin de savoir ce qui est acheté, et il doit être sûr qu'il sera payé pour cet achat (validité du moyen de paiement), mais il n'a pas besoin de connaître l'iden- tité de l'acheteur, la banque de cet acheteur, l'adresse de livraison, etc. L'entreprise de livraison doit connaître ' REE W9 Octobre2006 1 Repères RISQUES ET SÉCURITÉ DES RÉSEAUX ET DES SYSTÈMES A COMPOSANTE LOGICIELLE (2" " 1 partie) l'adresse de livraison et éventuellement ['identité du des- tinataire (qui n'est pas nécessairement l'acheteur), ainsi que les caractéristiques physiques de l'objet acheté (poids, dimension, si c'est fragile ou pas, etc.), mais elle n'a pas à connaître le prix d'achat, qui l'a acheté, etc. La banque du marchand doit savoir quel montant doit être viré et depuis quelle banque, mais n'a pas à connaître l'identité de l'acheteur ni même son numéro de compte, ce qui a été acheté, etc. La banque de l'acheteur doit connaître le montant à virer ainsi que la banque et le numéro de compte du marchand à créditer, mais pas ce qui a été acheté, l'adresse de livraison, etc. Dans cet exemple, aucune des parties n'a besoin de collecter toutes les infor- mations personnelles relatives à cette transaction ; elles doivent être fragmentées et distribuées entre les par- ties, et cela contribue à la confidentialité des données per- sonnelles [12]. Même lorsque l'identité d'une personne est néces- saire et doit être vérifiée (authentification), cette personne doit pouvoir sélectionner laquelle de ses identités elle désire divulguer (voir section 2.2), de façon à se prému- nir contre des liens qui pourraient être établis abusive- ment. Mais très souvent, des données personnelles sont collectées, traitées et redistribuées alors qu'il n'y a pas d'utilité à les relier à une personne identifiée. C'est le cas, par exemple, lorsque des données médicales sont rassem- blées dans un but de recherche sur de nouveaux traite- ments, ou pour protéger la population contre des épidé- mies, ou encore pour améliorer les ratios efficacité/coûts des soins médicaux. De telles données médicales sont des informations personnelles très sensibles, et doivent donc être rendues anonymes pour protéger la vie privée des patients : l'étude qui utilise ces données peut avoir besoin d'informations très détaillées sur les trajectoires de soins, voire les antécédents familiaux, etc., mais pour autant il n'est pas nécessaire de connaître la personne à qui ces données se rapportent. Dans certains cas, les données d'un même patient peuvent devoir être collectées par des sources différentes (hôpitaux, cabinets médicaux...), et à différents moments, et pourtant devoir être identifiées- comme reliées au même patient, sans pour autant divul- guer l'identité du patient. Cela nécessite la création d'un identifiant anonyme unique pour chaque patient mais commun aux différents points et instants de collecte des informations. Un tel identifiant anonyme devrait être généré de façon à empêcher toute tentative d'inverser le processus d'anonymisation, c'est-à-dire de faire corres- pondre une personne d'une population donnée à un iden- tifiant anonyme. De plus, dans certains cas, il peut être utile, ou même vital, de " désanonymiser " l'identifiant pour réidentifier le patient, par exemple lorsqu'un nou- veau traitement a été découvert pour une maladie identi- fiée à partir des données médicales anonymisées. Une technique d'anonymisation [1] a été développée pour contrôler la possibilité ou non d'établir un lien entre don- nées anonymisées correspondant à un même patient et pour donner au patient le contrôle sur le processus de dés- anonymisation. Les données personnelles anonymisées doivent elles- mêmes parfois être minimisées, en particulier pour empê- cher des attaques par inférence, qui permettraient d'iden- tifier une personne à partir de données anonymisées. Par exemple, la connaissance des semaines de naissance de deux frères ou soeurs suffit pour identifier de façon unique leur mère dans une grande population (celle de la France, par exemple). Il peut donc être nécessaire de réduire la précision de données personnelles anonymes, par appau- vrissement des données ou filtrage. Par exemple, il peut être souhaitable de remplacer une date de naissance par un âge ou une tranche d'âge, un code postal par un code de région, etc. Bien sûr, il faut établir un bon compromis entre la protection de la vie privée et la nécessité d'avoir des informations suffisamment précises pour réaliser l'étude pour laquelle elles sont collectées (selon le prin- cipe du besoin d'en connaître). Le filtrage et l'appauvris- sement peuvent aussi s'appliquer à des données person- nelles à caractère nominatif, de façon à permettre à un uti- lisateur de ne transmettre que la quantité d'information nécessaire pour réaliser une transaction acceptable. 5.2. Autodétermination des données personnelles Lorsque des données personnelles se trouvent sur un site distant, c'est-à-dire une machine qui n'est pas sous le contrôle direct de la personne concernée (typiquement, un serveur d'une entreprise ou administration), soit pour un court moment (par exemple l'exécution d'une simple transaction), soit pour plus longtemps (par exemple des dossiers médicaux dans un hôpital), l'accès à ces données devrait être strictement limité à l'usage souhaité par leur propriétaire, c'est-à-dire la personne correspondant à ces données. Cela signifie que le propriétaire des données doit pouvoir imposer une politique de protection de la vie privée sur ses données et que le serveur qui conserve et traite ces données doit mettre en oeuvre cette politique par des mécanismes de contrôle des accès à ces données. La politique en question peut définir des permissions et des interdictions précisant qui peut ou ne peut pas réaliser quelle opération sur ces données personnelles, mais aussi des obligations précisant, par exemple, que les données expirent (et donc doivent être effacées) après un délai donné suivant la terminaison de la transaction, ou que la divulgation de ces données à un tiers doit être notifiée au propriétaire par courriel, etc. Bien sûr, la politique de vie privée imposée par le propriétaire des données doit être compatible avec la politique de sécurité qui protège les biens de l'entreprise et gouverne l'exécution de l'applica- tion, et donc les accès effectifs aux données. La compati- bilité entre ces deux politiques doit être vérifiée avant la divulgation par l'utilisateur de ses données personnelles (voir le projet P3P précédemment cité). Suivant ces principes, le propriétaire du serveur est 1 REE N'9 Octobre 2006 Protection de la vie privée sur Internet responsable de la sécurité des données personnelles qu'il héberge, et peut être poursuivi en cas d'abus de ces don- nées. Il est donc important que le serveur implémente des mécanismes de sécurité capables de mettre en oeuvre effi- cacement les exigences de vie privée des utilisateurs et la politique de sécurité de l'entreprise. Cela peut se faire en utilisant des mécanismes de contrôle d'accès convention- nels et une conception rigoureuse des logiciels d'applica- tions et des procédures d'opération. Mais cela peut aussi être facilité par des mécanismes dédiés, tels que des médiateurs d'accès aux données, capables de mettre en oeuvre despolitiqttes indétachables (sticlypolicies) asso- ciées à chaque donnée personnelle élémentaire, sous forme d'une étiquette indétachable. L'article [31 présente une telle architecture, utilisant un chiffrement basé sur l'identité (Ideiitit) -Based Encrptioii). 6. Conclusion Cet article a présenté une vue d'ensemble de quatre catégories de technologies pour la protection de la vie pri- vée (PET) qu'il faudrait implémenter pour améliorer la confiance des utilisateurs dans le respect porté à leur vie privée lorsqu'ils se connectent à l'Internet : techniques de gestion des identités, communications et accès anonymes, autorisation préservant la vie privée et techniques de ges- tion des données personnelles. D'autres PET ont été pro- posés pour des applications non directement liées à Internet. Par exemple, le développement des applications liées à la localisation soulève d'importantes inquiétudes, puisque la localisation d'une personne à un moment donné peut être une information privée très sensible. Des PET sont actuellement développés spécifiquement pour ce type d'applications. Ils se basent généralement sur une gestion d'identités multiples (pseudonymes) pour chaque utilisateur, chaque pseudonyme n'étant connu que par l'une des nombreuses parties prenantes dans le service (par exemple, un opérateur de téléphonie mobile, des fournisseurs de services lié à la localisation, des fournis- seurs d'accès Internet, etc.). Le lien entre les différents pseudonymes d'une même personne doit alors être contrôlé par l'utilisateur lui-même ou par une tierce par- tie de confiance. De même le développement de l'infor- matique ubiquitaire, des réseaux de capteurs, des réseaux ad hoc, de routage et de stockage pair à pair, et toutes les autres technologies nouvelles d'information et de com- munication peuvent créer de nouveaux défis pour la pro- tection de la vie privée, qu'il faudrait analyser avant que ces technologies ne soient déployées. Après leur déploie- ment, il sera peut-être trop tard pour développer des solu- tions pratiques acceptables, et cela risque de conduire à la frustration des usagers : comment un citoyen pourrait-il abdiquer ce qu'il considère comme un droit fondamental, pour les bénéfices souvent illusoires des nouvelles tech- nologies ? Remerciements Cette étude a été partiellement soutenue par le projet PRIME (Privacy and Identity Management for Europe) IST-507591 du 6 " "' programme-cadre de la Commission Européenne. Une version étendue de cet article forme le chapitre 2 de l'ou- vrage Sécitt-ité des sistèii ? es d'infoi-iiiation V.2, rédigé sous la direction de Ludovic Me et Yves Deswarte, Traité IC2, série Réseaux et télécommunications, Hermès, ISBN 2-7462-1259-5, 390 pp., 2006. Références [11 A ABOU EL KALAM, Y DESWARTE, G TROUESSIN, E. CORDONNIER, Une démarche méthodologique pour l'anonymisation de données personnelles sensibles, Actes du 21'', Symposium sur la Sécurité des Technologies de l'Information et des Communications SSTIC 2004), Rennes (France), 2-4 juin 2004, pp. 91-115. [2] O. BERTHOLD, H. FEDERRATH, M. KOHNTOPP, Project Anonymity and Unobservabillty in the Internet, Proceedings of the Workshop on Freedom and Privacy by Design/ Conference on Computers, Freedom and Privacy 2000, Toronto, Canada, 4-7 avril 2000. [31 M. CASASSA MONT, S. PEARSON, P BRAMHALL, Towards Accountable Management of Identity and Privacy : Sticky Policies and Enforceable Tracing Services, HP Laboratories Bristol Report HPL2003-49, 2003, [61 Charte des Droits Fondamentaux de l'Union Européenne, Journal officiel des communautés européennes (2000/C 364/01), 18 décembre 2000. (71 Critères communs pour l'évaluation de la sécurité des tech- nologies de l'information, Partie 2. Exigences fonctionnel- les de sécurité, août 1999, version 2.1, CCIMB-99-032, dis- ponible sur [8] D CHAUM, Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms, Communications of the ACM, 24 (2), pp. 84-88, février 1981. [91 Y DESWARTE, N. ABGHOUR, V NICOMETTE, D. POWELL, An Intrusion-Tolerant Authorization Scheme for Internet Applications, in Sup. of the Proceedings of the 2002 International Conference on Dependable Systems and Networks (DSN2002, Washington, DC (USA), 23-26 juin 2002, pp. C-1.1 - C-1.6 [101 Y. DESWARTE et L. ME (sous la direction de), Sécurité des réseaux et systèmes répartis, Traité C2, Série Réseaux et télécoms, Hermès-Lavoisier, ISBN 2-7462-0770-2, 2004, 266 pp. [11] C D ! AZ, B. PRENEEL, Taxonomy of Mixes and Dummy Traffic, Information Secunty Management, Education and Privacy, Proc. of the 3rd Working Conf. on Privacy and Anonymity ln Networked and Distributed Systems (1-NetSec04), Toulouse, France, août 2004, Kluwer Academic Publishers, pp. 216-232 [121 J.-C. FABRE, Y DESWARTE, L. BLAIN, Tolérance aux fautes et sécurité par fragmentation redondance-dissémination, REE l, 9 Octobre2006 1 Repères RISQUES ET SÉCURITÉ DES RÉSEAUX ET DES SYSTÈMES ./ À COMPOSANTE LOGICIELLE (2,-,, partie) Technique et Science Informatiques TSI), Vol.15 (4), pp. 405-427, 1996. [131 M.J. FREEDMAN, R. MORRIS. TARZAN A Peer-to-peer Anonymizing Network Layer, ln Praceedings of the 9th ACM Conference on Computer and Communications Security (CCS 2002), pp. 193-206, Washington, DC, novem- bre 2002. [141 D.M. GOLDSCHLAG, D.M. REED, P SYVERSON, Onion Routing for Anonymous and Private Internet Connections, Communications of the ACM, 42 (2), pp, 84-88, 1999. [15] Guidelines on the Protection of Privacy and Transborder Flows of Personal Data, ISBN 9264197192, 2002, 66 pp. 116] Identity Management Systems (IMS). Identification and Comparison Study, Independent Centre for Privacy Protection IICPP)/Unabhangiges Landeszentrum fur Datenschutz (ULD) Schleswig-Holstein and Studio Notarile Genghini (SNG), 2003- 09-07 1171 Information Technolo_qy - Open Systems Interconnection - Security frameworks for open systems : Access conffo/fra- mework, International Standard ISO/IEC 10181-3, lst edi- tion, 1996-09-15. [18] Loi n'78-17 du 6 janvier 1978, Loi relative à informatique. aux fichiers et aux libertés. [19] Loi n'2004-801 du 6 août 2004, Loi relative à la protection des personnes physiques à l'égard des traitements de don- nées à caractère personnel. (201 Trusted Computer System Evaluation Criteria, US Department of Defense Standard, DoD 5200.28-STD, 26 décembre 1985. Yves Deswarte est ingén eur ISEN 1972) et ingénieur spécialisé en informatique de SupAéro (1973) Il est actuellement Directeur de Recherche au LAAS-CNRS dans le groupe " Tolérance aux fau- tes et sûreté de fonctionnement informatique " Ses travaux de recherche successivement à la Cil, la CIMSA, l'INRIA et au LAAS ont porté principalement sur la tolérance aux fautes et la sécurité informatique des systèmes répartis. Il est l'auteur de plus de 80 publications internationales dans ces domaines. Il est membre Senior de la SEE, ancien président du club SEE n'63 (Systèmes informatiques de confiance), membre de IACM et de ilEEE. Il est le représentant de FtEEE Computer Society au Technical Committee Il de l'IFIR consacré à la sécurité et la protection des systèmes de traitement de l'information. Carlos Aguilar Melchior est ingénieur de l'Ecole Polytechnique (2000) et termine actuellement ses travaux de thèse au LAAS- CNRS dans le groupe "Tolérance aux fautes et sûreté de fonction- nement Informatique'.'Ses travaux de recherche concernent la pro- tection de la vie pnvée dans les réseaux informatiques. Vincent Nicomette est ingénieur ENSEEIHT (1992) et docteur de l'Institut National Polytechnique de Toulouse. Il est actuellement maître de conférences à FiNSA de Toulouse et chercheur au LAAS CNRS dans le groupe de recherche " Tolérance aux fautes et sûreté de fonctionnement informatique'.'Ses travaux de recherche concernent la tolérance aux fautes et la sécurité des systèmes répartis. Matthieu Roy, normalien, Docteur de l'Université de Rennes 1/IRISA (2003), est Chargé de Recherche CNRS au LAAS-CNRS dans le groupe de recherche « Tolérance aux fautes et Sûreté de Fonctionnement informatique n. Ses travaux de recherche portent sur les mécanismes de tolérance aux fautes, sur les algorithmes distribués pour la cohérence de données et la sécurité en environ- nement réparti, et en particulier sur la protection des informations à caractère privé. 1 REE W9 Octobre 2006