Comment nous avons perdu 230 euros chez CJ Affiliate (Conversant)
[accueil] [menu] [suivez-nous !] [chercher]
Paru dans
Pirates Magazine n°19Problè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 !
Une sécurité sabotée
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 ?
Faire ses propres cartes ?
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 !
Aucun contrôle ?
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.
Un progiciel indépendant
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
LockSmith 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'auteurVous voulez soutenir une information indépendante ? Rejoignez notre
Club privé !
Vous cherchez un ancien numéro ?
Nous avons peut-être un exemplaire pour vous ! !
Certains liens présents dans cette page peuvent être affiliés. Sauf si c'est spécifié dans le texte, cela ne veut pas dire que la rédaction vous recommande les produits/services en question.
[homepage] [RSS] [archives]
[contact & legal & cookies] [since 1997]