Comment nous avons perdu 230 euros chez CJ Affiliate (Conversant)




[accueil]  [menu]  [suivez-nous !]  [chercher]


Paru dans Pirates Magazine n°19

Problèmes de sécurité de la carte Vitale : suite... mais pas fin !

Qui ne dit mot consent, dit-on ! Mais comment aurait-on pu démentir nos révélations de Pirates Mag' 18, tant elles sont faciles à vérifier ? Le silence radio était, à l'évidence, la seule réaction possible, et il faut bien reconnaître qu'il a été scrupuleusement respecté, même par nos confrères de la grande presse. Pourtant, nous n'étions qu'au tout début de nos surprises…

Lors de nos investigations portant sur des applications « carte », nous mettons surtout en évidence des failles de sécurité provenant de maladresses de conception purement involontaires, et donc plus ou moins excusables. Quel informaticien n'en commet jamais ? Dans le cas de la carte Vitale, la situation est totalement différente, car la pathétique insécurité du système tout entier résulte manifestement de choix stratégiques délibérés. Il ne s'agit pas d'un cas isolé : lorsque l'Allemagne a lancé sa carte d'assuré social à puce, il n'a jamais été question de cacher qu'il s'agissait d'un support de données non sécurisé, tout juste destiné à remplacer une saisie manuelle. Comme de coutume, la France a vu infiniment plus grand, et a défini un système fort ambitieux. Fidèles à notre grande tradition technocratique, les « experts » chargés de ce chantier ont imposé des exigences draconiennes aux industriels retenus, tout en s'appliquant à eux-mêmes la « loi du moindre effort ».
Dès le 20 avril 1998, SGS Thomson publiait fièrement un communiqué de presse annonçant que son circuit intégré ST16SF44/RHQ venait de décrocher la certification sécuritaire ITSEC de niveau E3. Délivré par le SCSSI au vu de tests pratiqués par le CESTI (CNET de Caen), ce certificat portait nommément sur la version dotée du masque « RHQ », développé spécialement (dit-on) par BULL CTS pour la carte Vitale 1. Rien à reprocher, par conséquent, ni au fondeur ni au concepteur du masque « carte », dont la résistance des mécanismes sécuritaires a été jugée d'un « niveau élevé ». Par la suite, ce masque de type « SCOT 400 M9V1 » a été porté sur d'autres composants, faisant à chaque fois l'objet d'une nouvelle évaluation sécuritaire : tant le AT05SC1604R (Atmel) que le ST19XS04D (STMicroelectronics), choisis pour supporter respectivement les masques IGEA 340 et IGEA 440 d'Axalto, sont certifiés EAL4+. C'est le plus haut niveau de sécurité requis pour des applications non militaires, sensiblement équivalent à l'ITSEC E3 « strong ». Même si cela a sûrement permis de faire injecter, par le contribuable, beaucoup d'argent dans le « fleuron de l'informatique française » au nez et à la barbe de Bruxelles, on se demande bien à quoi bon développer des cartes aussi sûres, si on ne se sert pas de leurs fonctionnalités sécuritaires !


Fondamentalement, une carte SCOT est partitionnée en plusieurs zones pouvant être protégées à volonté en lecture et/ou en écriture. Parallèlement, tout un système de clefs secrètes permet d'authentifier aussi bien la carte auprès d'une application externe, que toute entité cherchant à lire ou écrire des données dans la carte. Même dans une carte bancaire (ne rions pas !), il est prévu des zones confidentielles, qui ne peuvent être lues qu'après présentation d'un code PIN ou d'une clef « émetteur ». Dans la carte Vitale, toutes les données sont en lecture libre, car il paraît qu'un code « porteur » empêcherait le malade d'envoyer un proche faire les courses à la pharmacie ! À qui, sinon à des énarques, fera-t-on gober pareil argument ? Après tout, les cartes de fidélité de supermarché sont elles aussi à lecture libre, mais leur contenu est crypté. Trop compliqué dans le cas de la carte Vitale, comme le dit avec un bel aplomb le rapport N° 2002-142 de l'Inspection générale des affaires sociales : « la gestion de clefs pour une population de plusieurs millions de personnes représente une tâche insurmontable ». Et comment font les opérateurs de téléphonie mobile, alors ?



Du côté de la protection en écriture, on a par contre fait très fort : rien, absolument rien, ne peut être modifié sans présentation préalable d'une clef qui, si l'on en croit les bits « système » et les spécifications SCOT, serait tout bonnement… ce fameux code PIN que l'on ne confie pas au porteur (et pour cause !). Une petite zone de 64 bits est même tellement protégée que l'émetteur en personne n'a plus le droit d'y écrire une fois la carte en circulation. Bizarrement, son contenu (adresse 0288h) est le même pour tout le monde : « 2C 9A 05 85 26 59 85 A0 ». Supprimons les deux bits système de chaque mot de quatre octets, découpons ce qui reste en blocs de cinq bits, et nous lirons, dans le bon vieux code à « 5 moments » des télétypistes de l'après-guerre, les deux mots « VITALE » et « SESAM ». Information ultra-sensible s'il en est ! Logiquement, on aurait pu s'attendre à trouver là un « certificat » cryptographique individuel, non ?


Partant de la constatation que toutes les données, confidentielles ou non, sont sciemment logées dans des zones à « lecture libre » et aucunement cryptées, on voit mal comment quiconque pourrait prétendre interdire leur lecture (et pourtant, la loi se le permet !). Si la lecture est possible, la création de « copies de sauvegarde » l'est forcément aussi, mais en 1998, personne n'imaginait que des cartes à puce à « système d'exploitation ouvert » allaient bientôt se démocratiser. Dès que l'on a vu des microcontrôleurs PIC se faire « encarter », puis la BasicCard montrer le bout de son nez, les sueurs froides ont dû se faire contagieuses ! Curieusement, c'est à peu près à cette époque que l'on a songé à interdire carrément la détention de lecteurs de cartes à puce, mais il était déjà bien trop tard.
Pourtant, malgré les multiples coups de poing sur la table des conférenciers du salon CARTES, on a continué à saborder la sécurité d'excellentes cartes en bâclant le développement de leurs applications. Le moment est venu d'en payer le prix fort, dirait-on… Lorsque nous avons expliqué, dès 2002, comment « cloner » expérimentalement des cartes Vitale, nous avions encore l'intime conviction qu'un système de clefs de contrôle devait tout de même être prévu quelque part. Depuis, des développeurs ayant accès aux spécifications à « diffusion restreinte » du GIE nous ont ri au nez : non seulement nos « copies de sauvegarde » fonctionneraient parfaitement avec leurs progiciels « agréés », mais elles resteraient même fonctionnelles après modification de leur contenu ! Bref, si on ne peut pas les mettre à jour dans une borne de la CPAM (car nous n'avions volontairement pas implémenté les commandes supposées nécessaires), il est à craindre qu'on puisse le faire soi-même !


Comme il n'y a apparemment aucune clef de contrôle (même en cherchant bien, on ne voit vraiment pas où elle pourrait être), chacun devrait théoriquement pouvoir s'octroyer lui-même les droits dont il souhaite bénéficier : ce serait gravissime, et expliquerait peut-être tout bonnement l'existence même du « trou de la sécu » !
Les autorités ayant été dûment averties… en vain, sans doute faudra-t-il un énorme scandale pour que la carte « Vitale 2 » mette en oeuvre, aux côtés d'une photo d'un intérêt discutable, les moyens sécuritaires qu'exige une application dont le piratage massif serait fatal à l'assurance maladie « à la française ». Car celle-ci est tenue de payer toutes les « feuilles de soins électroniques », dès lors que son système informatique n'a pas rejeté la carte du bénéficiaire, qu'elle soit vraie ou fausse !
À l'intention de tous ceux qui ne croient que ce qu'ils voient (et ils ont bien raison !), Jérôme Crêtaux s'est donné la peine de développer une proof of concept de qualité professionnelle.
Découvrant, un peu grâce à nous, tout ce que l'on pouvait faire en se passant totalement des API, il a vite saisi combien un développeur indépendant pouvait faire mieux que les effectifs pléthoriques du GIE. Nous avons eu la possibilité de tester son œuvre.


LockSmith 7.0 est basé sur un concept assez iconoclaste : doter les cabinets médicaux d'un progiciel compatible avec leur actuel poste de travail Sesam Vitale, mais totalement indépendant des applications en place. Son but avoué est d'apporter une solution confortable à une situation fréquente : un patient habituel qui n'a pas toujours sa carte Vitale sur lui !
Avec son accord (légalement indispensable), et en conformité avec la législation sur les copies de sauvegarde, le praticien aura conservé dans un fichier (vraiment) sécurisé, une copie intégrale de sa carte Vitale (données confidentielles comprises). Un vrai rôle de « tiers de confiance », en somme, sûrement compatible avec la déontologie médicale. À tout moment, il pourra ainsi être établi une « carte navette » provisoire, double fidèle susceptible d'être accepté par l'application agréée Sesam Vitale, pour émettre et signer une feuille de soins électronique. Bien entendu, cette copie qui n'est nullement destinée à remplacer une carte perdue ou volée, ne quittera pas le cabinet et sera effacée après usage.



Outre cette réelle commodité qu'il offre, tant aux patients qu'aux médecins, ce progiciel révolutionnaire apporte la preuve de la totale absence de sécurisation de la carte Vitale telle que nous la connaissons : on peut, en effet, la dupliquer à volonté, sans que la carte de professionnel de santé n'intervienne le moins du monde dans le processus ! Et ce n'est qu'un début : il est d'ores et déjà annoncé que la version suivante de Lock­Smith permettra de mettre à jour des données administratives dans la copie, la situation du malade ayant pu évoluer depuis sa dernière consultation (prolongation de droits, changement de régime, mise à 100 %, etc.) ! Faut-il considérer cela comme une déclaration de guerre, ou comme une pierre apportée à cet édifice qu'il va bien falloir reconstruire ? Les assurés sociaux et leurs médecins traitants sont maintenant invités à se forger leur propre opinion, et les responsables à s'expliquer.

Suite dans Pirates Mag' 20 (novembre 2005)

Patrick Gueulle

Tous les ouvrages de l'auteur




Vous voulez soutenir une information indépendante ? Rejoignez notre Club privé !


[homepage]  [RSS]  [archives]
[contact & legal & cookies]  [since 1997]