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




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

Explorer les cartes à puce multi-applications

Une seule et même carte à puce couvrant tous les besoins de la vie courante, voila ce que l’on peut espérer (ou redouter ?) pour les années à venir. Dès à présent, les cartes de paiement, de transport en commun, ou de téléphonie mobile se préparent discrètement à cette (r)évolution, nous obligeant à adapter nos techniques d’exploration.

Différents signes devraient commencer à nous mettre la puce à l’oreille : des cartes bancaires dans lesquelles on incorpore un porte-monnaie électronique Monéo, des badges d’accès au salon Cartes qui permettent de prendre librement le RER, jusqu’aux cartes SIM de troisième génération (USIM), qui affichent de grandes ambitions. Tout faire, oui, mais sûrement pas n’importe quoi : une rigoureuse étanchéité s’impose entre les différents compartiments des cartes combinant plusieurs applications sensibles. Pas question que notre opérateur de téléphonie mobile puisse lire, à notre insu, l’historique des transactions de notre carte bancaire, ou le détail du trajet que nous venons d’effectuer dans le métro, cela ne le regarde pas !
Le principe général, qui peut toutefois subir des entorses qu’il va s’agir de surveiller de très près, est qu’une application donnée ne puisse pas accéder aux données d’une autre, cohabitant pourtant dans la même carte. En pratique, quand une application est active, toutes les autres sont maintenues au repos, ce qui n’empêche nullement d’en faire fonctionner plusieurs en alternance. Gare alors aux données pouvant être mémorisées par l’application informatique du terminal, et aux recoupements toujours possibles en temps réel ou après-coup. Dans l’immense majorité des cas, le terminal qui reconnaît une carte dotée de plusieurs applications commence par sélectionner celle qu’il souhaite faire fonctionner. Cela peut même se faire avec le concours de l’utilisateur, qui choisira par exemple s’il veut payer par carte bancaire ou par porte-monnaie électronique.
Souvent, c’est par examen de la « réponse au reset » (ATR) de la carte ou par tentative de lecture d’un fichier « DIR » que le terminal détermine à quel genre de carte il a affaire. Mais il peut aussi essayer, « en aveugle », de sélectionner toutes les applications qu’il sait gérer, dressant petit à petit une liste de celles que la carte reconnaît. Inutile de préciser que ce mécanisme pourra nous être d’un grand secours pour tirer les vers du nez à telle ou telle carte que nous soupçonnerons d’être plus dégourdie que ce que l’on veut bien nous dire...

Sélectionner une application

Même s’il existe quelques cas particuliers (à commencer par la BasicCard ZC 6.5), les cartes multi-applications respectent très majoritairement un mode opératoire bien normalisé ; c’est alors une variante de la commande SELECT (destinée originellement à sélectionner des fichiers) qui sert à activer telle ou telle application. Par le fait, il y a fonctionnellement fort peu de différence entre sélectionner un fichier (DF ou Dedicated File) ou une application. Une application dite « par défaut » étant bien souvent active tant qu’on n’en a pas sélectionné une autre, on peut fort bien ne pas s’apercevoir que l’on est en présence d’une carte multi-applications ! Des applications peuvent ainsi rester longtemps dormantes, ou encore être ajoutées, parfois subrepticement, à n’importe quel moment de la vie de la carte. D’où l’intérêt d’ouvrir l’œil...
Prenons l’exemple d’une carte USIM pour téléphone portable 3G : introduite dans un mobile non-UMTS, elle se comporte comme une carte SIM très ordinaire, exécutant l’application GSM disponible dès le RESET. Un mobile UMTS, par contre, lui enverra une commande ainsi composée :

00 A4 04 04 07 A0 00 00 00 87 10 02

Là où une carte SIM répondrait 6E 00 (classe inconnue, puisqu’elle ne reconnaît que la classe ISO A0h et non pas 00h), une carte USIM répondra par exemple 61 3B, indiquant ainsi qu’elle tient une réponse de 59 octets (3Bh) à la disposition du terminal, à charge pour lui d’en prendre connaissance par une commande GET RESPONSE (00 C0 00 00 3B).
Sans même aller chercher cette réponse, ce qui nous entraînerait beaucoup trop loin, on sait donc déjà que la carte supporte au moins cette application dont l’identifiant (AID ou Application IDentifier) se compose des champs A0 00 00 00 87 (RID) et 10 02 (PIX). En fait, cette valeur de RID est réservée aux applications relevant du 3GPP (le groupe de travail en charge de la téléphonie mobile de troisième génération). De même, le RID A0 00 00 00 09 est attribué à l’ETSI (cartes SIM Java, par exemple), D2 76 00 01 24 aux cartes « openPGP », A0 00 00 00 63 aux cartes PKCS#15, etc. Chaque émetteur de cartes titulaire d’un RID (attribué selon une procédure administrative décrite dans la norme ISO 7816-5) pouvant décider de rendre celui-ci public, ou au contraire de le tenir confidentiel, les autorités en charge de ces attributions ne publient évidemment pas le répertoire officiel exhaustif que nous pourrions espérer.
Tous les moyens sont donc bons pour se constituer ses propres listes, quitte à les mettre en commun pour faire avancer la « veille technologique » qui s’impose. Il est ainsi amusant de lire, sur bon nombre de tickets de distributeurs de billets, une ligne A0 00 00 00 42 10 10 : l’AID complet de l’application EMV (Visa crédit), que l’on refuserait certainement de communiquer à un simple curieux qui s’aviserait de le demander ! Dans un tout autre ordre d’idées, envoyer la commande 94 A4 08 00 02 31 00 à un badge « congressiste » du salon Cartes activera ainsi l’application multi-usages de ce qui est en fin de compte un authentique pass Navigo à technologie mixte, avec et sans contact. Ne dirait-on pas une simple sélection de fichier ? Cela fait, une commande 94 A4 02 00 02 31 20 suffira d’ailleurs pour sélectionner le fichier (en lecture libre) dans lequel plusieurs enregistrements contiennent les détails personnels du titulaire. 94 B2 01 04 1D lira alors le nom du porteur dans le premier enregistrement, et ainsi de suite. La preuve est ainsi faite que la classe ISO 00h n’est pas systématiquement celle qu’il convient d’utiliser pour sélectionner une application ! L’application « transport », pour sa part, pourrait être sélectionnée en utilisant la commande 94 A4 08 00 02 20 00 ; de quoi prendre connaissance du « journal de transport » (fichier 20 10, contenant trois à six enregistrements de 29 octets). Ce fichier « circulaire » (dans lequel les compostages les plus récents écrasent les plus anciens) mémorise donc le strict nécessaire pour qu’un contrôleur puisse vérifier la validité du parcours effectué, mais serait bien insuffisant pour reconstituer des déplacements d’une façon véritablement indiscrète (à moins de venir le consulter très fréquemment). Bien entendu, les fichiers plus sensibles sont protégés par tout un système de codes confidentiels, et par conséquent ni lisibles ni modifiables par le premier venu. Eh oui, la carte à puce est une technologie sûre, et la carte Vitale la principale exception qui confirme la règle !

A la pêche aux AID !

Compte tenu du nombre potentiel de combinaisons RID-PIX, il serait largement illusoire de tenter de découvrir, par force brute, les AID que reconnaît une carte 100 % inconnue, même si des possibilités de sélection par « nom partiel » permettent de limiter le champ des recherches. Connaissant RID, il ne serait par contre pas déraisonnable de tenter une recherche systématique sur de nombreuses valeurs de PIX, avec quelques chances de succès. Mais l’arme absolue, c’est de faire parler non pas la carte, mais un terminal dans lequel on sait qu’elle fonctionne ! Cela, évidemment, en se limitant à des automates dans lesquels il n’y a pas d’inconvénient légal à introduire une carte « maison », qui sera de toute façon refusée, mais dans laquelle se seront peut-être enregistrées des choses intéressantes... Une fois de plus, la BasicCard se prête admirablement à ce genre d’exercice d’interopérabilité, dans la mesure où l’on peut personnaliser assez librement son ATR, son jeu de commandes, les réponses qu’elle renvoie, et que nous avons depuis longtemps développé des techniques lui permettant d’enregistrer et de restituer les commandes qu’elle reçoit du terminal.
Prenons l’exemple du code source ci-dessous, destiné à une ZC 5.4 Rev. A ou supérieure. Son ATR (T=0) est calquée sur celle d’une carte bancaire 100 % compatible EMV et par conséquent anglaise, puisqu’en France nous vivons toujours une période transitoire où de nombreuses cartes sont encore à mi-chemin du masque B0’ franco-français et de l’EMV.

Declare Binary ATR = &H3B,&H66,&H00,&HFF,_
&H4A,&H43,&H4F,&H50,&H32,&H30,_
&H01
Open "Card.Log" For Append As #1
Write#1,""
Command &HC8 &H04 COPY(Lc=0,S$)
S$="(c)2006 Patrick GUEULLE"
End Command
Command &HC8 &HA2 FLUSH()
Close
Kill "Card.log"
End Command
Command Else NOTIN(S$,Disable Le)
C$=CHR$(CLA)+CHR$(INS)+CHR$(P1)+CHR$(P2)+Chr$(Lc)+S$
S$=""
Write#1,C$
SW1SW2=&H6E00
End Command

Pas question de parler de « fausse carte », puisque celle-ci répondra systématiquement 6E 00 (classe inconnue) à toute commande que le terminal voudra bien lui envoyer. Si d’aventure tel ou tel automate ne tenait aucun compte de ce compte-rendu d’erreur et continuait le dialogue comme si de rien n’était, à qui la faute ? Normalement, la carte doit être refusée de façon quasiment instantanée, mais des choses tout à fait dignes d’intérêt se sont sûrement enregistrées dans sa mémoire... Pour en prendre connaissance (puis les effacer), il suffit de se servir de l’utilitaire ci-dessous, préalablement compilé en un fichier exécutable grâce à un kit logiciel BasicCard (lire notre ouvrage Plus loin avec les cartes à puce), et d’introduire la carte dans un simple lecteur PC/SC (par exemple un Teobyxiring, vedette du salon Cartes 2006).

#Include CARDUTIL.DEF
#Include COMMERR.DEF
ComPort=101
Declare Command &HC8 &HA2 FLUSH()
Declare Command &HC8 &H04 COPY(Lc=0,S$)
Declare Sub FlushCB()
Declare Sub ReadSpy()
CLS:PRINT"SPYUTIL Copyright (c)2001,2006 Patrick GUEULLE":PRINT
Call WaitForCard
ResetCard:Call CheckSW1SW2:PRINT
Call COPY(S$)
IF Len(S$)<>&H17 Then Print"Carte non reconnue !":EXIT
menu:PRINT
PRINT:PRINT"1 -->  Transfert fichier interne"
PRINT:PRINT"2 -->  Vidage du fichier interne"
PRINT:PRINT"0 -->  Quitter"
PRINT:PRINT"Votre choix, puis ENTER"
LINE INPUT X$:PRINT:PRINT
ResetCard:Call CheckSW1SW2()
IF X$="1" THEN Call ReadSpy()
IF X$="2" THEN Call FlushCB()
IF X$="0" OR X$="" THEN EXIT
GOTO menu
Sub FlushCB()
Call FLUSH():Call CheckSW1SW2
IF SW1SW2=&H9000 THEN CLS:PRINT "Fichier interne vide !"
End Sub
Sub ReadSpy()
Open"@:card.log" For Input As #1
Open"card.log" For Output As #2
While Not EOF(1)
Input#1, Z$
For F=1 To LEN(Z$)
Z=ASC(MID$(Z$,F,1))
Y$=Hex$(Z)+" "
If Len(Y$)=2 THEN Y$="0"+Y$
Print Y$;:Print#2,Y$;
Next F:Print:Print#2
Wend
Print:Print"---- Fin de fichier ----"
Close
End Sub

C’est dans le fichier CARD.LOG que l’on découvrira tous les AID qu’un terminal français essaie sur cette carte étrangère, identifiée comme telle d’après son ATR puisque celle d’une carte bancaire française commencerait plutôt par 3Fh (convention inverse) que par 3Bh (convention directe). Notre moisson pourra ainsi ressembler à ce qui suit (suite de commandes SELECT, avec pour argument un AID de 7 octets) :

00 A4 04 00 07 A0 00 00 00 42 10 10
00 A4 04 00 07 A0 00 00 00 42 20 10
00 A4 04 00 07 A0 00 00 00 42 40 10
00 A4 04 00 07 A0 00 00 00 42 40 20
00 A4 04 00 07 A0 00 00 00 03 10 10
00 A4 04 00 07 A0 00 00 00 03 20 10
00 A4 04 00 07 A0 00 00 00 04 10 10
00 A4 04 00 07 A0 00 00 00 04 30 60

Parfois, on remarquera aussi une ligne de la forme :

00 A4 04 00 0E 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31

(tentative de sélection d’un répertoire baptisé « 1PAY.SYS.DDF01 » selon les spécifications EMV). En première position, on retrouve l’AID déjà repéré sur les tickets des DAB français, puis quelques autres parmi lesquels ceux des cartes de crédit Visa (03 10 10) et Mastercard (04 10 10), mais aussi des cartes à autorisation systématique Electron (03 20 10) et Maestro (04 30 60). Comme il s’agit d’une carte étrangère, le terminal n’a aucune raison d’essayer l’AID (de 6 octets) du porte-monnaie franco-français Monéo (A0 00 00 00 69 00), que l’on verrait par contre sûrement apparaître si on simulait l’ATR (T=1) d’un tel PME :

Declare Binary ATR = &H3B,&HE6,&H00,&HFF,&H81,&H31,&H80,&H05,_
&H16,&H01,&H01,&H27,&HB1,&H37,_
&H06
Open "Card.Log" For Append As #1
Write#1,""
Command &HC8 &H04 COPY(Lc=0,S$)
S$="(c)2006 Patrick GUEULLE"
End Command
Command &HC8 &HA2 FLUSH()
Close
Kill "Card.log"
End Command
Command Else NOTIN(S$,Disable Le)
C$=CHR$(CLA)+CHR$(INS)+CHR$(P1)+CHR$(P2)+Chr$(Lc)+S$
S$=""
Write#1,C$
End Command

Simuler avec précision une carte bancaire B0’ serait, en revanche, plus délicat : seule la Rev. D de la ZC 5.4 permet de déclarer une ATR T=0 à convention inverse (par exemple 3F 65 00 FF 58 04 6C 90 00 ou 3F 65 25 08 58 04 6C 90 00), mais elle n’a été commercialisée que fort peu de temps. Ceci expliquerait-il cela ?

Tirer les marrons du feu

Une fois cette récolte effectuée, il reste à essayer, sur des cartes réellement en circulation, les AID ainsi découverts. Cela ne leur fera aucun mal, puisque la manœuvre est identique à celle qu’effectuerait le premier publiphone ou distributeur de carburant venu. N’importe quel utilitaire permettant d’envoyer directement des commandes ISO 7816 (ou mieux des scripts) fera l’affaire, mais on peut aussi écrire un petit programme ZCBasic plus ciblé.
C’est là que des surprises sont à prévoir avec les cartes bancaires mixtes B0’/EMV, dont le comportement diffère du tout au tout de celui de leurs cousines étrangères. Pourtant, depuis le 1er janvier 2007, le mode B0’ est censé être désactivé dans tous les terminaux de paiement, toutes les cartes devant comporter « au moins » une application EMV. Le fait est qu’il ne semble plus guère s’enregistrer d’historique des transactions dans la mémoire des cartes, ce qui confirme bien qu’il s’est passé « quelque chose ». Mais quoi au juste ? Au moins un ralentissement des transactions, c’est flagrant aux caisses de certains supermarchés. Camouflerait-on adroitement une insuffisance de certaines cartes par des autorisations en ligne plus systématiques ? Rappelons qu’initialement, la migration de B0’ vers EMV devait être achevée pour le 1er mai 2003...
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]