Doc GOMI

Doc GOMI

Carte Vitale, la plus grande mystification de la sécurité informatique ?

Depuis de nombreuses années, la France se distingue par une innovation assez datée, la carte vitale et la carte professionnelle de santé, qui "sécurisent" les informations et transactions concernant les patients ; c'est dumoins ce qui nous a été vendu.

 

Un peu d'historique et début des soupçons :

 

IL y a trois ans, lors d'un formatage de lot avant la télétransmission des actes effectués au cours de la journée, une erreur s'est glissée dans un lot (microcoupure?) et ce lot altéré n'était donc plus en état d'être télétransmis.

 

La cpam locale me dit de prendre contact avec mon éditeur de logiciel, auquel j'ai donc envoyé ce lot corrompu, et qui me le répara ; une fois reçu je l'ai retélétransmis.

 

Et puis je réalise alors que ce lot a été lu, réparé, et remis en forme sans ma carte vitale professionelle et sans la carte vitale des patients, j'interroge mon éditeur, ses explications sont "confuses".

Armé de mon éditeur de texte, je vais donc à la recherche d'un fichier B2 à télétransmettre et l'ouvre, je découvre alors que rien (ou presque) n'est crypté - chiffré plus exactement.

 

Il est donc possible à cette époque de fabriquer ou réparer des factures FSE non rejetées par la sécurité sociale sans CPS, sans lecteur de carte vitale, avec un simple éditeur de texte.

 

Quelques années passent, nouveau cahier des charges CPS 1.40, nouvelle carte CPS (appel d'offre initial de fabrication à 3 millions d euros.....) , je me dis que le progrès est passé par là.

 

 

Et puis à la suite d'une discussion le doute m'amène à reprendre quelques investigations :

 

je découvre que rien (ou pas grand chose) n'a changé : les fichiers de télétransmission ne sont quasi pas chiffrés , et contiennent les informations d'identification : du médecin, mais aussi du patient (numéro de sécurité sociale et date de naissance), acte en tiers payant, bénéfice de la CMU, grossesse avec date de début, accident de travail, et codage des actes en ATM (qui semble une simple translation et non pas un chiffrement des actes).

 

Depuis la version 1.40 certains éléments sont chiffrés, le cahier des charges n'indique pas les quels, et je me demande finalement ce qui l'est vraiment : les codes des actes semblent simplement "translatés", et non pas chiffrés : le codage des actes CCAM indique précisément ce qui a été fait au patient (tumorectomie du sein...) mais ne figure pas en l'état, est utilisé un codage dit ATM, qui est une description précise de ce qui qui a été réalisé, mais la liste ATM des actes est "confidentielle" (disponible dans tous les organismes de sécurité sociale).

 

Toutes ces informations non chiffrées sont lisibles plus facilement avec un utilitaire B2viewer.exe qui permet une remise en forme, et cet utilitaire se trouve sur internet en trois click (avec les versions d'essai des logiciels médicaux).

 

Pour ceux qui s'intéressent à la totalité des informations transitant ainsi par internet le cahier des charges de la norme B2 est disponible ici et n'a pas évolué depuis 2007.

 

Pourquoi s'émouvoir de cette situation ?

 

Tout d'abord par ce que le ministère, l'ASIP et les industriels nous ont toujours vendu de la sécurité et du cryptage, du chiffrement et s'apercevoir qu'aucune des sécurité promise n'a été activée est tout de même déstabilisant : le lecteur CPS, les certificats de sécurité, les fonctions de cryptage, quasi rien n'est fonctionnel, et tout ce bazar ne sert qu'a mettre en forme des fichiers ASCII lisibles et modifiables avec un simple éditeur notepad. (quelques éléments sont chiffrés mais je ne sais pas à quoi ils correspondent, peut être des vérifications d'intégrité).

 

Ce qui nous est vendu ne correspond pas à la réalité : aucune des clefs publiques de la carte cps ne me semble utilisée (sauf peut être pour le chiffrement très discret visible dans les fichiers B2 mais en tout cas pas pour le transport des flux)  et les documents contractuels précisant le niveau de chiffrement et la technologie employée n'existent pas : on nous vend du marketing, pas de la sécurité.

 

A l'heure de la privatisation de la sécurité sociale par les complémentaires, qu'en est t'il du secret médical lorsque le codage des actes ATM permet de connaitre par la "banqueassurance" du patient, ce qui a été fait, à quelle date, et par qui (généraliste, psychiatre, cancérologue...) ?

 

Et enfin dernier élément : ces informations transitent par des relais mails SMTP, et par les dorsales et backbones du net, et sont aussi enregistrés, captés et stockés, si l'on en croit les récentes révélations concernant le programme PRISM et ses équivalents nationaux.

 

Quitte a payer un lecteur CPS, et tout le pseudo attirail de sécurité qui va avec , serait t'il possible de le faire fonctionner, de l'activer en quelque sorte ?

 

J avais publié cet article il y a une quinzaine de jours, et l ai dépublié

 

Suite à un échange twitter avec un collègue geek , qui m'a indiqué que, peut être, le chiffrement était ultérieur à la génération des fichiers B2 par le logiciel médical + CPS + code porteur.

 

A défaut de sécurité "de base" lors de la fabrication des lots de factures, un chiffrement de transport rendrait les informations non captables sur internet.

 

J'ai donc fortement douté et j ai vérifié : j ai dans un premier temps appelé le Réseau Santé Social, et Orange Santé, qui m 'ont assuré du chiffrement de transport et de la sécurité des informations véhiculées.

 

On se dit qu'au minimum un simple SSL permettant de tunneliser est forcément utilisé, surtout quand on a acheté tout ce matériel, migré en 1.4, installé le kit de connexion et j'en passe..... ; puisqu 'un simple provider lambda propose cette option sans avoir besoin de l'attirail CPS....

 

Je leur ai demandé de me fournir un document contractuel décrivant leur offre de service : ce document n'existe pas ! et je me suis donc mis à douter encore plus.

 

Tout ce systême est très bien organisé pour ne pas être transparent : en effet les factures télétransmises ne sont pas consultables car les mails envoyés ne sont pas visibles, d'ou l'impossibilité pour l'utilisateur médecin ou professionnel de santé de se faire une idée de ce qu 'il envoie sur le réseau internet.

 

Le webmail n'est pas disponible, qui permettrait de voir ces envois et de connaitre l'étendue du chiffrement.

 

Deux solutions pour savoir : un proxy SMTP entre mon poste et mon FAI, ou l'analyse des trames réseaux avec Wireshark, j ai utilisé cette deuxième solution.

 

Sur le port SMTP après filtrage on obtient ceci lors de l'envoi d une FSE :

cap1.jpg

 

 

 

Avouez que ça a une bonne tête  : les mails sortants de chez moi semblaient bien chiffrés.

 

Sauf que c'est marqué dessus, c'est en fait un simple encodage base64 permettant une vérification d 'intégrité, et non un chiffrement ( cf la RFC 4648 ) et là encore, la CPS reste inutilisée, alors qu'elle contient les clefs publiques nécessaires et suffisantes pour faire le job de chiffrement.

 

Après opération de décodage Base 64 ( qui peut se faire en ligne ici), je retrouve bien mon fichier B2 non chiffré, avec les données d 'identification en clair (nom du médecin, identifiant Adeli, numero SS et date de naissance du patient) et tout celà sort de mon ordinateur depuis 10 ans sans que je sois au courant.

 

Au final, la télétransmission des actes de médecine se décompose en deux opérations qui laissent les données personnelles et d'identification du patient et du médecin circuler en clair sur internet :

 

- l'une consistant en la fabrication des lots à télétransmettre dits B2

 

- l'autre consistant en l'envoi de cette facture B2 par internet sous forme d'un mail, pour lequel la CNIL préconisait déjà en 2007 un chiffrement de transport, qui n'est pas effectif dans la très grande majorité des cas (voire la totalité des cas, mais je n ai pu tester tous les FAI, seulement les "plus sécurisés") : ni VPN hardware qui partirait du modem routeur , ni même une petite cession SSL (et je ne sais pas ce qu'il en est pour les factures des cliniques, hôpitaux, laboratoires....).

 

Quelle conclusions à tout ceci et qu'exiger ?

 

- tout d'abord de la transparence et des engagements contractuels et écrits envers les professionnels de santé de la part des éditeurs, des transporteurs de flux, et du GIE sésam vitale,  qui se foutent quand même un peu de notre poire quand ils nous causent chiffrement et sécurité avec la haute bénédiction ministérielle et la participation de tout ce monde à ce qui ressemble grandement à une mystification.

 

- les experts, le ministère, la CNIL n 'auraient t'ils rien vu ? un peu hilarant ou désolant, au choix.

 

- cette transparence doit pouvoir se matérialiser dans la visibilité des informations transmises sur le réseau par le professionnel de santé, ce qui n'est pas le cas aujourd'hui : je veux voir ce qui sort de mon ordinateur et qui va transiter sur internet.

 

Je suis au final un peu ébahi par ce systême, son coût, et son mode de fonctionnement totalement dégradé par rapport à ce qui nous est promis et vendu à l'heure ou n'importe quel provider SMTP est en mesure de fournir du SSL. (orange le fait avec les offres de base depuis le 5 mai 2011 par exemple).

 

Bien sûr un chiffrement intégral des FSE poserait de grands défis techniques, et il faut certainement un statu quo raisonnable (sans doute un layer SSL de transport, n'utilisant pas forcément les clefs publiques CPS) ; en passant je remarque que le prochain appel d 'offre CPS pourrait faire l'économie en deniers publics de toutes les fonctions non activées de la carte CPS.

 

Mais l'opacité, les inexactitudes et dans certains cas les mensonges qui entourent l'épopée sésam vitale, son obsolescence programmée en raison de l 'arrivée des technologies NFC sont tout de même extrêmement problématiques, et posent la question de la confiance que professionnels de santé et citoyens-patients-contribuables peuvent accorder aux discours rassurant et lénifiants des organisateurs de cette drôle de mystification collective.

 

On retombe sur les problématiques de l'expertise technique et de la démocratie, ou plus exactement de sa confiscation : chacune des organisations, éditeur de logiciel médical, GIE sésam vitale, ministère, industriel, organisme de normalisation (CNDA) a l'impression de faire au mieux et de ne pouvoir bouger le systême (qui nécessiterait des modifications techniques sur l ensemble de la chaîne) ; chacun a aussi de très bons arguments pour expliquer que rien n'est possible et que la responsabilité est celle d'un autre acteur de la chaine ; mais au final, le produit livré ne correspond absolument pas à ce qu'on est en droit d'en attendre ; si on interpelle les individus, chacun reconnait que le résultat final ne correspond pas à la communication réalisée par les organisations.

 

Se pose aussi bien évidemment la question de la confidentialité de notre travail, du secret dû au patient, d'un vieux truc qui ne semble plus d'actualité : le secret médical, et plus globalement du BigData et de la confidentialité des données personnelles. 

 

 

exempleB2.JPG

 

Ci dessus un fichier B2 reconstitué : il s 'agit d'une trame réseau whireshark du port 25, décodée en base64 (car non chiffrée) et simplement copiée collée dans un wordpad.

En l ouvrant avec B2 viewer, on constate l'étendue des informations d 'identifications qui partent en clair sur internet : quel médecin a été consulté, quel jour, son numéro adeli, le numéro de SS et la DDN du patient, le montant facturé, entre autres.

 

 

 

 

 

 

 

 

 

 

 

 



13/08/2013
11 Poster un commentaire

A découvrir aussi


Inscrivez-vous au blog

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 232 autres membres