• Aucun résultat trouvé

3.2. D E LA DESCRIPTION DES SICSS AUX BESOINS DE SÉCURITÉ À SATISFAIRE

3.2.3. Étude de cas 3!: Analyse de différents scénarios d’anonymisation

3.2.3.4 L’anonymisation dans les pays européens

3.2.3.4.1 L’anonymisation en France

En 1995, le CHU de Dijon, ainsi que d’autres établissements de santé de la région Bourgogne ont choisi l’algorithme de hachage SHA (Standard Hash Algorithm) pour transformer, d’une manière irréversible (anonymisation), les variables d’identification : nom, prénom, date de naissance et sexe. Le but est d’obtenir un identifiant strictement anonyme, mais toujours le même pour un patient donné [Quantin et al. 1998]. Néanmoins, même si SHA est mathématiquement irréversible, il ne résiste pas aux attaques “ponctuelle” ou “par dictionnaire ”. En effet, supposons qu’un tiers malveillant, Bob, a accès à une base de données médicale anonyme BDMA.

Dans une attaque ponctuelle, Bob voudrait, par exemple, savoir si Alice a le SIDA. La première étape consiste à appliquer l’algorithme de hachage aux variables identifiantes d’Alice afin d’obtenir l’identifiant anonyme associé à Alice : NAAlice. La deuxième étape consiste à

Dans une attaque par dictionnaire, Bob pourrait appliquer l’algorithme de hachage à une liste de variables identifiantes (dictionnaire) pour disposer d’une table Tid-Num reliant des variables identifiantes à des codes anonymes. En faisant un simple rapprochement entre la base de données médicales anonymes et la table, il pourrait facilement déduire les informations médicales des personnes dont les noms figurent sur son dictionnaire (figure 3.7).

Figure 3.7 : Attaque par dictionnaire.

Pour illustrer la procédure d’anonymisation utilisée dans la région Bourgogne, considérons maintenant le cas où les hôpitaux transmettent des données médicales au Département d’Informations Médicales (DIM). Celui-ci effectue des analyses médico-économiques, avant d’archiver toutes les données médicales de tous les patients (aux niveaux des agences régionales d’hospitalisation par exemple).

Si on n’utilise qu’une fonction de hachage du côté des hôpitaux, les personnes en charge des traitements statistiques et médico-économiques (au DIM) peuvent remonter aux identités par une simple attaque ponctuelle (ils disposent des données médicales anonymes et de l’algorithme de hachage). Par ailleurs, du côté du DIM, si on n’utilise qu’une fonction de hachage avant l’archivage, les employés des hôpitaux pourront retrouver les identifiants (utilisés dans les archives) de n’importe lequel de leurs patients, ainsi que toutes les informations concernant ce patient, y compris celles provenant des autres établissements (rappelons que la loi [Loi 2002] donne au patient le droit d’interdire que certaines de ces données soient communiquées à d’autres professionnels de santé “voir section 3.2.2.1.5”).

Pour prévenir ce type d’attaques, deux clés ont été ajoutées à l’algorithme de hachage SHA.

La première clé k1, utilisée par tous les émetteurs des données (hôpitaux et médecins), est concaténée à l’identité. Une fonction de hachage est ensuite appliquée au résultat : empreinte1

= H(k1 | identité). Cette opération produit une empreinte qui varie d’une identité à l’autre, mais qui est toujours la même pour un patient donné. Les informations transmises au centre de traitement des fichiers (DIM) en vue de leur rapprochement sont ainsi devenues strictement anonymes et les personnes qui assurent les traitements centralisés ne peuvent pas lever l’anonymat à l’aide d’une attaque par dictionnaire puisqu’elles ne connaissent pas la clé k1. De

Utilisateur malveillant qui

l’autre côté de la communication, les informations reçues par le DIM sont hachées par le même algorithme mais avec une seconde clé k2, qui n’est pas communiquée aux hôpitaux : empreinte2

= H(k2 + empreinte1) (voir figure 3.8).

Figure 3.8 : Procédure de double hachage des informations traitées par le DIM.

Le protocole présenté en Bourgogne s’avère complexe et risqué. En effet, il nécessite une distribution de la même clé secrète à tous les fournisseurs d’informations (médecins libéraux, hôpitaux, cliniques, etc.), tout en supposant que cette clé doit rester secrète. Certes, une personne qui ne connaît pas une des clés secrètes (k1 ou k2) est dans l’impossibilité d’effectuer les transformations. Néanmoins, si une clé est corrompue, le niveau de sécurité est considérablement réduit. De même, si un jour il s’avère que l’algorithme (ou la longueur de la clé) n’est plus efficace, comment faire le rapprochement entre les identifiants avant et après changement de l’algorithme ou de la clé (sachant que les empreintes dépendent de la clé supposée être toujours la même et chez tous les fournisseurs d’informations) ? Si ce problème survient, la seule solution envisageable consiste à appliquer une autre transformation à toute la base de données, solution qui n’est guère aisée.

Étudions à présent une autre procédure qui a été élaborée par le CESSI de la CNAM-TS pour le PMSI (Programme de Médicalisation des Systèmes d’Information) privé : la procédure FOIN (Fonction d’Occultation d’Informations Nominatives). Comme en Bourgogne, la procédure de la CNAM utilise une fonction de hachage à sens unique (SHA) avec une clé des deux côtés. L’originalité de cette méthode réside dans l’utilisation de la technique de Fragmentation-Redondance-Dissémination ou FRD [Fabre et al. 1996]. Les étapes de cette technique de tolérance aux intrusions, déjà expliquée, sont les suivantes :

- découper l’information (clé secrète) en fragments de telle sorte que des fragments isolés ne puissent fournir d’information significative ;

- ajouter de la redondance pour empêcher que la modification ou destruction de quelques fragments n’ait pas de conséquence pour les utilisateurs autorisés ;

- isoler les fragments les uns des autres par dissémination de sorte qu’une intrusion (la corruption d’une partie de la clé secrète) dans une partie du système ne fournisse que des fragments isolés.

En utilisant cette technique de FRD pour protéger la clé secrète nécessaire à la fonction d’anonymisation, FOIN fragmente la clé secrète en N images de telle sorte qu’elle ne peut être reconstruite qu’à partir d’un certain nombre s (dit seuil de reconstitution) d’images différentes.

En fait, cette notion de seuil repose sur le schéma à seuil de Shamir qui peut se résumer ainsi : - le partage du secret k (clé secrète) est fait sur N images distinctes ;

- il s’effectue à l’aide d’un polynôme P(x) de degré “s-1”, s étant le seuil de reconstruction : P(x) = a0 + a1x + .. + as-1xs-1 ;

- il suffit de rassembler s images distinctes parmi les N images pour permettre de recalculer le secret k ;

- les calculs se font dans un corps de Galois (corps fini offrant certaines propriétés mathématiques) ;

Transmetteur Service chargé du traitement (DIM)

Premier hachage à clé secrète K1

Deuxième hachage clé secrète K2

Message à transmettre M1

Message reçu

Chiffrement

déchiffrement

- le secret k est l’ensemble des coefficients du polynôme : (a0, a1, .., as-1). La figure 3.9 présente un exemple avec s=2 (P(x) = a0 + a1x).

Figure 3.9 : Fragmentation-Redondance-Dissémination de la clé secrète.

Les images de la clé secrète sont disséminées sur un nombre de supports distincts. La première image sera placée dans la fonction d’anonymisation (dans le logiciel distribué aux transmetteurs d’informations), les autres sont données à des personnes de confiance, comme le responsable de l’application ou le directeur de la CNAM. Ainsi, même s’il existe N images (fragments) de la clé, la présence de “s -1” personnes de confiance est suffisante pour reconstituer le secret (figure 3.10).

Comme en Bourgogne, et pour se prémunir contre toute attaque ponctuelle ou par dictionnaire, la fonction d’anonymisation FOIN est utilisée à deux niveaux : une première fois dans les hôpitaux, avant de transmettre les données médicales des patients et une deuxième fois, avant l’archivage de ces données.

Figure 3.10 : Procédure FOIN.

Néanmoins, le cas où s = 2 est confronté aux mêmes faiblesses de la procédure du CHU de Dijon. Si en plus, N > 2, les images seront détenues par N personnes et n’importe laquelle pourra reconstituer la clé (puisqu’une des deux images nécessaires est présente dans le logiciel). De plus, la technique de FRD ne résout que le problème du stockage “longue durée”.

En effet, la clef reste vulnérable au vol par un utilisateur malveillant qui réussit à la lire ou la copier lorsqu’il l’utilise durant les traitements.

Secret K Fragmentation

Redondance

Dissémination K1

K2

KN

K1 K2

KN

Ks Ks x

x x

K1

K2

Ks

Copies Images conservées

sur supports distincts Reconstitution du secret .

.

Données nominatives

Procédure de reconstitution de la clé secrète

Variables identifiantes et clé secrète Hachage Identifiant anonyme

Image 2 De la clé

Image S De la clé

Image 1 De la clé

Procédure d’anonymisation

Clé secrète

3.2.3.4.2 L’anonymisation des données sur le cancer en Allemagne

Le RNC (Répertoire National du Cancer) allemand est un registre épidémiologique fondé en 1953. De nos jours, il contient les données de plus de deux millions de patients atteints du cancer. Le but majeur est de pouvoir effectuer des statistiques médicales et des recherches épidémiologiques sur le cancer. Dans les années quatre-vingt, et pour des raisons techniques, seuls les fichiers centralisés ont été informatisés. Pour chaque cas, les détails suivants ont été enregistrés :

- identification personnelle du patient ;

- établissement, historique, stade, diagnostic et thérapie ; - autres traitements et suivis médicaux ;

- historique individuel et familial ; - décès et résultat de l’autopsie.

La procédure d’enregistrement transite par deux étapes et à travers deux institutions [Blobel 1996] :

- Dans un premier temps, un site de confiance rassemble les données auprès des médecins, dentistes et centres de suivi. Les données identifiantes sont d’abord chiffrées par une clé de session IDEA générée aléatoirement. Cette clé est elle-même chiffrée par une clé publique RSA d’une longueur minimale de 640 bits. Par ailleurs, et pour permettre une association non-ambiguë des informations au fichier du patient, un identifiant anonyme est généré à partir de certaines données personnelles du patient. Cet identifiant est en fait généré par l’application de la procédure de hachage à sens unique “MD5”, suivi d’un algorithme de chiffrement symétrique (IDEA). Cet identifiant est le même, sur tout le territoire allemand, pour un patient donné. Le format obtenu est nommé “format de chaînage”.

- Le site de confiance transmet au site d’enregistrement à la fois les données d’identité sous forme chiffrée et les données épidémiologiques en clair. Le site d’enregistrement enregistre le fichier dans la base de données du NCR et rassemble les données appartenant au même patient. Il procède de la manière suivante : un numéro aléatoire est ajouté à l’identifiant, et le résultat est chiffré par IDEA. Le format obtenu est nommé “format de stockage”.

Sur demande et pour des raisons scientifiques, l’exploitation des données anonymisées du registre est possible, mais restreinte en temps (durée) et en quantité (nombre de fois). Dans certains cas particuliers, un comité de conseil peut autoriser le déchiffrement des données identifiantes.

Nous commenterons cet exemple après avoir présenté celui de la Suisse assez similaire.

3.2.3.4.3 Le traitement statistique des données médicales en Suisse

Du point de vue statistique, il n’est pas nécessaire de savoir à qui appartient un fichier médical. Néanmoins, en Suisse, l’Office Fédéral des Statistiques (OFS), responsable de la collecte des données médicales auprès des hôpitaux, a besoin de reconnaître si deux fichiers différents correspondent à la même personne. L’implémentation suisse propose de hacher les identifiants dans les hôpitaux avant de les transmettre à l’OFS ; puis à la réception, les données médicales sont chiffrées par la clé secrète de l’OFS [Jeanneret et al. 2001] (figure 3.11).

La première étape consiste à remplacer les données d’identité par un identifiant personnel, le code anonyme de lien. Les données sur lesquelles le calcul repose doivent être disponibles et constantes dans le temps. Trop de restrictions sur le choix peut conduire à des collisions, tandis qu’une multitude de données peuvent être non disponibles ou, du moins, changer au cours du

temps. Le choix s’est porté sur un ensemble minimal d’identifiants : la date de naissance, le sexe, le nom et le prénom.

Puisque la transformation cryptographique doit être appliquée tout le temps et par tous les hôpitaux, l’utilisation d’une clé secrète n’est pas la solution la mieux adaptée. À l’inverse, l’utilisation des empreintes22 (hachage des données identifiantes) satisfait mieux ces objectifs, avec l’inconvénient de ne pas résister aux attaques par dictionnaires. Il convient donc de chiffrer les données d’identité, d’abord durant la transmission de l’hôpital à l’OFS, ensuite dans les bases de données. Les étapes de cette procédure sont les suivantes (figure 3.11) : - Hachage des variables identifiantes : Hachage[Var-ID] = Empreinte.

- Génération en arrière-plan (dans l’ordinateur de l’hôpital) d’une clé de session : c.

- Chiffrement de l’empreinte avec IDEA en employant c : IDEA[Empreinte]c ; et chiffrement de c par la clé publique de l’OFS, (notée E) en utilisant l’algorithme RSA : RSA[c]E.

- Transmission de la clé de session (chiffrée), de l’empreinte (chiffrée) et des données médicales (chiffrées) à l’OFS.

- À la réception, déchiffrement de la clé secrète (de session) c par RSA en employant la clé privée de l’OFS notée “D” ;

- Déchiffrement de l’empreinte (avec IDEA et la clé c), et re-chiffrement de cette empreinte avec une clé k (fragmentée) pour donner le lien anonyme utilisé comme code personnel (code de liaison uniforme) lors du stockage des données médicales au niveau de l’OFS.

Figure 3.11 : Transformation des données identifiantes en Suisse.

Les solutions allemandes et suisses se ressemblent, c’est pourquoi on se contentera de discuter la deuxième. Comparons la procédure suisse et la fonction FOIN de la CNAM-TS :

22 Rappelons qu’une empreinte a été définie dans la section 3.2.3.4.1 (page 81) comme étant un code anonyme qui varie d’une identité à une autre mais qui est toujours le même pour un patient donné.

Données identifiantes Hachage à sens

unique

Chiffrement avec IDEA en employant la clé secrète c

Transfert de la clé secrète c utilisée par l'hôpital pour crypter les empreintes

- les données transmises sont chiffrées dans la solution suisse, tandis qu’elles ne le sont pas dans FOIN ;

- FOIN utilise la technique Fragmentation-Redondance-Dissémination qui vise, non seulement la confidentialité et l’intégrité, mais aussi la disponibilité. Dans la procédure suisse, même si K est fragmentée en plusieurs parties, elle ne peut être reconstituée qu’en présence de toutes les personnes disposant de ces fragments (de K). La reconstitution est faite par un simple ou exclusif “K = K1 ⊕ .. ⊕ KN” C’est donc un cas particulier de FOIN, où on considère N = s (seuil de reconstitution).

Par ailleurs, les trois opérations effectuées au niveau de l’OFS (retrouver la clé secrète c, retrouver l’empreinte, et chiffrement avant archivage) ne doivent jamais être visibles aux utilisateurs de l’OFS. Cependant, comment s’assurer qu’elles ne sont jamais enregistrées sur aucun support ? Un cheval de Troie opérant pour une personne malveillante, aussi bien interne qu’externe, pourrait récupérer les valeurs de la clé secrète c ou des empreintes, et effectuer par la suite une attaque par dictionnaire. Pour pallier ce type de risques, nous pensons que ces étapes (phase de calcul) doivent être faites par un module matériel bien protégé. Des mécanismes inviolables de contrôle d’accès, éventuellement matériels, pourront renforcer la protection de ce module de façon à ce que seules les personnes de confiance puissent réaliser l’opération composite calcul ; le serveur d’autorisation leur donne les droits correspondants sans qu’elles puissent lire ou copier, ni l’empreinte, ni les clés secrètes K et c ; des droits distribués sont donnés aux composants matériels ; chaque composant effectue les opérations qui lui sont destinées.

Cette analyse montre, les avantages et les faiblesses de chacune des solutions actuelles et renforce notre volonté d’une démarche analytique préalable des risques, des besoins, des exigences ainsi que des objectifs de sécurité, avant de recourir aux solutions de sécurité assurant l’anonymisation. Complétons ainsi cette analyse par une étude détaillée d’un ensemble de scénarios du domaine médical.