ACBM - Le Virus Informatique qui vous défend !Retour à l'accueilLes brèvesLe magasinContacts Ecrire dans le virusListe de diffusionPetites annoncesLes concours



Paru dans Pirates Magazine n°12
2002-08-02 00:00

Explorer... ou clôner la carte Vitale


Après une entrée en scène plutôt laborieuse, la carte Vitale a fini par faire ses preuves, au point d'éveiller l'intérêt d'un certain nombre d'autres pays ! Très proche de celle de la carte bancaire, sa technologie mérite assurément d'être passée au peigne fin, compte tenu du caractère éminemment « sensible » des données qu'elle est appelée à sécuriser.

Chacun sait que la carte bancaire B0' est basée sur la technologie Bull CP8, mais qu'elle n'exploite que très imparfaitement (et c'est le moins que l'on puisse dire...) le puissant arsenal sécuritaire dont sa puce est pourtant dotée. Datant forcément d'avant 1998 (l'année de sa mise en place dans des régions test), la carte Vitale semble avoir été développée sur une base très comparable, si ce n'est par les mêmes « experts ». Un rapide coup d'œil montre, en effet, que la carte Vitale reconnaît sensiblement le même jeu de commandes (avec une « classe ISO » égale à BCh) que sa cousine germaine.

Une carte « Scot » ?
En creusant un peu les choses, il apparaît que la similitude est encore bien plus marquée avec la famille « Scot », une gamme de cartes Bull CP8 destinée aux applications les plus variées, et pour laquelle on trouve sur le marché un « kit de développement » très complet. Sa technologie correspond à peu près à ce qui était « l'état de l'Art » en 1991. Conformément à la bonne vieille stratégie du « rideau de fumée », le GIE Sesam Vitale ne divulgue aucune information technique en dehors de partenariats avec des industriels « triés sur le volet » (par exemple, les constructeurs des bornes de consultation, des terminaux de professionnels de santé, ou des lecteurs de poche genre Xiring ou Lexibook). Qu'à cela ne tienne ! La lecture du manuel (nullement confidentiel) des kits de développement Scot est fort riche d'enseignements...
Il n'en faut pas davantage pour partir à l'aventure, dans le but avoué (car parfaitement avouable !) d'évaluer le degré de confiance que l'on peut accorder à une carte qui « ne contient aucune donnée confidentielle » (c'est ce que l'on dit aux titulaires), mais dont « les informations administratives qu'elle contient sont cryptées, par respect de la vie privée » (c'est ce que l'on affirme aux professionnels).

Une carte à lecture libre !
L'organisation logique des cartes Scot repose sur des mots de 32 bits (4 octets), mais l'adressage se fait au niveau du quartet (groupe de quatre bits). Une commande de lecture, transmise par n'importe quel lecteur de cartes à puce asynchrones, sera de la forme BC B0 P1 P2 LE, l'adresse à lire étant désignée par les deux octets P1 et P2, le nombre d'octets à lire (maximum 256) étant, quant à lui, indiqué par l'octet LE. Il faudra donc incrémenter P1P2 de deux unités pour avancer d'un octet (c'est-à-dire de deux quartets), et de huit unités pour avancer d'un mot de 32 bits. L'espace mémoire d'une carte Scot est découpé en plusieurs zones, dont les adresses initiales sont stockées dans autant de pointeurs spécifiques :
AD1 : Clefs émetteur
ADS : Jeu secret
AD2 : Codes porteur
ADM : Zone d'accès
ADC : Zone de travail n° 2 (dite « confidentielle »)
ADT : Zone de travail n° 1
ADL : Zone de lecture
Les valeurs de ces pointeurs (et bien d'autres informations utiles) résident dans la zone de lecture qui, comme son nom l'indique, est toujours à lecture libre. Chacun peut donc en prendre connaissance après avoir calculé les adresses où ils résident. Cela nécessite de se procurer la valeur ADMAX (adresse de fin de mémoire + 8h), en envoyant une commande BC C0 00 00 08 à la carte juste après un « reset ». On trouvera ADMAX dans les troisième (poids fort) et quatrième (poids faible) octets du mot reçu en réponse. Ses deux derniers octets (TA et PZT2) renseignent respectivement sur le type d'algorithme cryptographique supporté par la carte, et sur les modalités de protection de la zone de travail n° 2. Une carte Vitale typique pourra ainsi répondre ADMAX = 2188h, TA = 0Eh, et PZT2 = 08h. En clair, cela signifie qu'elle contient un peu plus de 8 000 quartets (la première adresse accessible étant invariablement 0200h), soit environ 4 000 octets, que la carte supporte le DES (un algorithme pas vraiment moderne), et que la zone de travail n° 2 est libre en lecture (mais protégée en écriture), tout comme la zone de travail n° 1.

Plus « puissante » que la carte bancaire !
Les remarques suivantes s'imposent donc tout naturellement à un explorateur averti :
- La capacité mémoire est largement supérieure à celle d'une carte bancaire (tout juste 1024 octets), et pourrait donc potentiellement héberger un volume significatif de données (confidentielles ?).
- L'intégralité des données (cryptées ?) que contiennent les zones de travail est librement accessible en lecture, par n'importe quel détenteur, légitime ou non, de la carte.
- Aucun code PIN (code porteur) n'est remis au titulaire, bien que le mécanisme correspondant existe dans les cartes Scot : d'intrépides expérimentateurs sont ainsi parvenus à bloquer leur carte Vitale en lui envoyant plusieurs commandes BC 40 00 00 00 (ratification d'un code PIN non présenté, et donc considéré comme erroné), puis à se la faire « débloquer » par les soins de leur caisse (qui dispose par conséquent d'ores et déjà des outils nécessaires) ! Notons qu'en revanche, un code PIN est (tout de même...) indispensable pour l'utilisation des cartes de professionnel de santé. Il n'est donc pas interdit d'imaginer qu'une sécurisation supplémentaire par code « porteur » pourrait être instaurée si le besoin devait s'en faire sentir un jour… Toujours dans le cas d'ADMAX = 2188h, on trouvera les pointeurs des différentes zones dans le second octet des mots de 32 bits dont voici les adresses, calculées par simple soustraction récursive de la valeur 08h :
AD1 : 2168h
ADS : 2158h
AD2 : 2150h
ADM : 2148h
ADC : 2140h
ADT : 2138h
ADL : 2130h
En prime, on trouvera le numéro de série de la carte (sur 25 bits) à l'adresse 2178h, un certain nombre de paramètres techniques aux adresses 2180h et 2170h, et le « type d'application » (sur 14 bits) en 2160h. Nous avons ainsi fait le tour complet de ce qu'il est convenu d'appeler la « zone de fabrication », qui occupe l'essentiel de la « zone de lecture ».

Dans le vif du sujet
Muni de tous ces précieux indices, il n'est guère compliqué de procéder à la lecture exhaustive de la carte, exception faite des clefs secrètes (naturellement protégées en lecture !) et de la « zone d'accès » (qui ne sert guère qu'à tenir la comptabilité des présentations réussies ou non des clefs et codes PIN).
Développé en ZCBasic (le Basic du fameux kit BasicCard, disponible gratuitement), le court programme que voici pourra fonctionner (après compilation en un exécutable Windows 32 bits) sur n'importe quel lecteur de cartes à puce conforme au standard PC/SC (ComPort=101), ou sur le lecteur « CyberMouse » fourni dans les kits du commerce (ComPort=1 s'il est branché sur COM1:, ou ComPort=2 s'il est relié à COM2:).

#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$)
Call WaitForCard
ResetCard:Call CheckSW1SW2:Print
Call RESP(S$,Le=8):Call CheckSW1SW2
ADM$=Mid$(S$,3,2)
Call AFF(ADM$):MAX=ValH(T$)
A=ValH(T$)-&H56
Call LIT(P1P2=A+16,S$,Le=2)
Call AFF(S$):A=ValH(T$)
Open"Vitale.log" For Output As #1
While A<MAX
Call LIT(P1P2=A,S$,Le=4):Call AFF(S$):Print#1,T$:Print T$;
A=A+8:Wend
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


Ce programme n'est pas très rapide, car il ne lit (volontairement) qu'un seul mot de 32 bits par commande BC B0. Cela présente l'avantage de laisser le temps de voir ce qui défile sur l'écran, pendant que les mêmes informations s'enregistrent dans un fichier texte (VITALE.LOG). Bien évidemment, les valeurs hexadécimales que contient ce fichier pourront être consultées ultérieurement, ou même imprimées, avec le premier éditeur de texte venu.

Une suite de « fiches » ?
Il sautera immédiatement aux yeux que seule une toute petite partie de la mémoire disponible est réellement utilisée, ce qui confirme bien que, dans l'état actuel des choses, la carte ne contient certainement pas de données purement médicales, telles un équivalent de l'inénarrable « carnet de santé ». Il semblerait plutôt qu'elle rassemble un certain nombre de « fiches », avec pour chacune d'elles un numéro de sécurité sociale et une date de mise à jour (format « année, mois, jour »), en « clair ». Une première fiche identifierait le titulaire de la carte (chef de famille), les suivantes correspondant sans doute chacune à l'un de ses ayants droit. D'après ce que parviennent à lire les bornes de consultation et les lecteurs de poche, il est clair que chaque fiche contient aussi des informations plus « confidentielles » : état-civil (nom, prénoms, date de naissance), validité des droits, caisse de rattachement, etc. Rien de plus, en somme, que ce qui était imprimé sur les cartes « papier » !



Un cryptage performant ?
Compte tenu du faible nombre d'octets de chaque fiche, il paraît évident qu'un cryptage relativement élaboré doit être appliqué, opérant au passage une certaine forme de compression. Tous les lecteurs disposent donc nécessairement d'un algorithme de décryptage et de la clef correspondante, même ceux qui fonctionnent indépendamment de la « carte de professionnel de santé » (CPS). Le rôle de celle-ci se bornerait-il donc à sécuriser seulement l'émission et la télétransmission des « feuilles de soins électroniques », ou bien jouerait-elle tout de même un rôle de clef d'accès à la partie la plus confidentielle des données personnelles, présentes ou à venir ?
Il est intéressant de faire la distinction entre les lecteurs de poche destinés au grand public, et les « consulteurs », plutôt conçus pour les professionnels prodiguant des soins à domicile. Les lecteurs les plus simples (XL 2000 ou XL 3000 de Xiring ou Lexibook, par exemple) opèrent aussi bien sur les cartes bancaires (consultation de l'historique des transactions) ou les Télécarte (lecture du solde d'unités), que sur les cartes Vitale (numéro d'immatriculation, centre d'affiliation...). Sous une apparence très similaire, les « consulteurs » affichent aussi des informations plus « sensibles », telles que le détail des droits attachés à la carte. En gros, un consulteur donne accès aux données qui étaient imprimées sur la carte « papier », tandis qu'un lecteur affiche plutôt l'équivalent de ce qui apparaissait sur un « extrait de carte », expurgé de toute information confidentielle.

À l'affût des modifications
Une fois émise, la carte Vitale doit faire l'objet de mises à jour à chaque modification de la situation des assurés qui lui sont rattachés. Cela peut se faire dans les bornes de consultation, qui établissent pour la circonstance une liaison par modem avec le système informatique de la caisse (en protocole Minitel). Il est possible de mettre en évidence les modifications apportées au contenu de la mémoire (et notamment aux dates de telles ou telles fiches), dans la mesure où le fichier VITALE.LOG aura été préalablement sauvegardé. Le programme suivant vient tout simplement relire la carte, et la comparer au fichier ainsi archivé.

#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$)
Call WaitForCard
ResetCard:Call CheckSW1SW2:Print
Call RESP(S$,Le=8):Call CheckSW1SW2
ADM$=Mid$(S$,3,2)
Call AFF(ADM$):MAX=ValH(T$)
A=ValH(T$)-&H56
Call LIT(P1P2=A+16,S$,Le=2)
Call AFF(S$):A=ValH(T$)
Open"Vitale.log" For Input As #1
While A<MAX
Call LIT(P1P2=A,S$,Le=4):Call AFF(S$):Print T$,
Line Input #1, U$:Print U$
If T$<>U$ Then Input Z$
A=A+8:Wend
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


Toute discordance entraîne l'arrêt du défilement sur l'écran, un simple appui sur la touche de retour à la ligne du clavier permettant de repartir après examen. Ce même programme pourra servir à s'assurer que le contenu de la carte ne change pas après insertion dans le terminal d'un professionnel de santé, certainement pas habilité (au moins dans l'état actuel des choses) à effectuer une quelconque mise à jour.

N'écrit pas qui veut !
Modifier le contenu de la carte suppose nécessairement qu'une clef spécifique lui soit présentée, puisque l'opération consiste à écrire... dans des zones protégées en écriture. Il faut espérer que cette clef ne soit pas la même pour tout le monde (car il ne serait pas bien difficile de l'intercepter avec l'arsenal présenté dans Pirates Mag' 11), mais qu'elle soit plutôt calculée à partir d'un identifiant unique, lu dans chaque carte, voire même présentée en mode crypté (grâce à ce fameux DES). Avec le cryptage des données, cela apporterait une protection raisonnablement efficace contre des mises à jour frauduleuses, en vue par exemple de prolonger des droits arrivés à expiration ou de s'octroyer indûment une couverture à 100 %, sans même parler du « tiers payant ».
Par contre, il saute aux yeux que rien ne semble être prévu pour empêcher le « clonage » des cartes, aimable plaisanterie à laquelle aucun « expert » ne devait sérieusement songer en 1998 ! N'importe quelle carte à système d'exploitation ouvert (ou, comme les « Gold Wafer cards », sans système d'exploitation du tout) peut théoriquement servir à réaliser une « copie de sauvegarde », non protégée en écriture (voir encadré). Rien de plus simple que de vérifier jusqu'à quel point celle-ci est acceptée « les yeux fermés » par les lecteurs de poche ou les bornes de consultation, mais on se lassera vite de ce petit jeu. Il serait, par contre, bien plus piquant qu'un médecin ose l'introduire, « juste pour voir », dans son consulteur ou son « terminal de professionnel de santé », quitte à tirer objectivement ses propres conclusions de l'expérience... En somme, chacun se convaincra aisément qu'une carte clonée s'apparente à une simple photocopie d'une carte « papier » : pas de quoi fouetter un chat, finalement !

Le composant interne

Il ne faudrait surtout pas imaginer que toutes les cartes Vitale sont équipées de la même « puce » électronique. Dès le début du masque B0', les cartes bancaires pouvaient déjà contenir un microprocesseur d'origine STMicroelectronics, Motorola, ou Texas Instruments, le cinquième octet de leur « réponse au reset » indiquant même la variante utilisée. Une application d'une telle envergure ne peut en effet raisonnablement dépendre, comme ce fut longtemps le cas de la télécarte T2G, d'un seul et unique « fondeur ». Particulièrement impliqué dans les cartes à puce pour les applications « de service public », le fabricant américain Atmel affirme être, lui aussi, un fournisseur majeur de Sesam Vitale. On retiendra donc qu'un même « masque » logiciel peut fort bien être « porté » sur une multitude de composants électroniques différents. Peut-être faut-il chercher par ici la raison d'être de ces mystérieuses commandes arborant une classe ISO A4h, que semblent reconnaître certaines cartes Vitale : A4 30, A4 32, A4 B8 ? Il pourrait s'agir de commandes « administratives » ne servant qu'au moment de la personnalisation des cartes, comme dans le cas des cartes SIM des téléphones portables. En pareil cas, on ne saurait évidemment trop conseiller de s'abstenir de les essayer à l'aveuglette...

Et avec une BasicCard...

La BasicCard a cela d'extraordinaire, que quelques lignes de Basic suffisent pour lui faire émuler, dans certaines limites, le jeu de commandes de telle ou telle carte à puce existante, avec souvent un surcroît de souplesse. Voici, par exemple, un court programme qui, chargé dans une BasicCard « Professional » (ZC4.1 ou ZC4.5), la dote des commandes nécessaires pour être lisible dans les mêmes conditions qu'une carte Scot.

EEPROM T$(4000) As String*4
Public K As Byte
Declare Binary ATR=&H3B,&HF5,&H11,&H00,&HFF,&H40,&H80, _
&H2C,&H09,&H69,&H90,&H00,&H01
Command &HBC &HC0 RESP(Lc=0,S$)
S$=T$(0)+T$(1)
IF Le<>8 Then SW1SW2=&H6708
End Command
Command &HBC &HB0 LIT(Lc=0,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)
IF Lc<>4 Then SW1SW2=&H6704
ADR=P1P2/8
T$(ADR)=S$
End Command


La commande d'écriture, cependant, a été largement simplifiée, et ne pourra donc servir qu'à initialiser la mémoire, par exemple, à partir de données recueillies dans une carte à lecture libre. La loi autorisant expressément les « copies de sauvegarde » dans une grande variété de situations, il serait dommage de se priver de ce petit plaisir !
Notre second programme facilite au maximum la manœuvre, qui se fera en insérant successivement dans le lecteur PC/SC l'original, puis la BasicCard programmée comme nous venons de l'indiquer.

#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)
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+16,S$,Le=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<MAX
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<MAX
Input#1,U$:Print".";
Call UPD(P1P2=A,U$)
A=A+8:Wend
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


La structure mémoire du « modèle » sera scrupuleusement respectée, les différents pointeurs demeurant inchangés. Par rapport à l'original, la « copie de sauvegarde » ainsi réalisée perd bien sûr toutes les données qui étaient éventuellement protégées en écriture, au minimum les différents jeux de clefs secrètes. Pas question, par conséquent, de faire mettre à jour une telle « photocopie » d'une carte Vitale dans une borne à ce destinée, opération qui serait d'ailleurs assimilable à une falsification. Par contre, le fait que le premier lecteur venu arrive à lire indifféremment l'original ou la copie démontre, à l'évidence, que le décryptage des principales données personnelles ne fait aucunement appel aux clefs secrètes confiées à la carte ! On s'en serait presque douté...

Patrick Gueulle

Tous les ouvrages de l'auteur





Vous aimez cette page ? Partagez-en le lien sur les réseaux sociaux !

Facebook
Twitter
Google+
LinkedIn


Retour aux archives
Retour à l'accueil
[RSS]
Legal & cookies