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

vers Virus Info


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


2010-05-25 00:00

Les cartes à puce des casinos


Qu'elles soient basées sur des technologies avec ou sans contact, les cartes d'accès et de fidélité émises par les casinos sont très intéressantes à explorer, voire à « bricoler », évidemment en tout bien tout honneur.

En France, les casinos sont soumis à une réglementation très stricte et font l'objet de nombreux contrôles. Le Code Pénal interdisant les jeux d'argent, « à l'exception de ceux autorisés par les autorités », la Loi du 15 juin 1907 est venue définir les dérogations à cette prohibition, les critères (modifiés depuis) d'implantation des casinos, ainsi que leurs modalités et procédures d'exploitation. Le décret et l'arrêté du 22 décembre 1959 fixent quant à eux la réglementation des jeux dans ces établissements. La Loi du 12 juillet 1983 interdisant les « appareils automatiques de jeux de hasard » sur le territoire français, il aura fallu attendre celle du 5 mai 1987 pour que les machines à sous (dites « bandits manchots ») soient finalement autorisées, mais uniquement dans les casinos. Leur taux de redistribution, fixé par l'État, est rigoureusement contrôlé. Le Code Monétaire et Financier (article D. 564-2, notamment) entend pour sa part lutter contre de possibles blanchiments de fonds transitant par les caisses des établissements de jeux (Loi du 29 janvier 1993 dite « loi Sapin »).
Le 1er novembre 2006, enfin, la vérification d'identité est devenue obligatoire à l'entrée des espaces de jeux des casinos, sous le prétexte commode de protéger les mineurs et les interdits de jeu. Il est donc parfaitement clair que l'anonymat n'a pas sa place dans un casino, que l'on y joue ou pas : assister simplement à un spectacle ou prendre un repas au restaurant suppose la présentation d'une pièce d'identité si l'accès se fait par la salle des jeux.
Cette formalité « policière » risquant d'indisposer certains clients, les casinotiers ont imaginé une solution fort élégante pour satisfaire à leurs obligations tout en valorisant leur image : la carte de « client privilégié » !
En pratique, cette carte est établie immédiatement et gratuitement, sur présentation d'une pièce d'identité qui est généralement scannée ou au moins photocopiée, mais de toute façon archivée. Pour que sa présentation au contrôle d'accès puisse être considérée comme suffisante, un moyen d'identification biométrique est mis en oeuvre : prise de photographie (avec une simple webcam !) ou même d'empreinte digitale. Il est donc légitime de se demander si les données correspondantes sont enregistrées dans la carte elle-même ou dans un serveur informatique, question à laquelle nos investigations devraient notamment permettre d'apporter une réponse !
Au delà de cette fonctionnalité de contrôle d'accès « convivial », la plupart de ces cartes font bénéficier leur porteur d'avantages souvent significatifs : accumulation de points de fidélité, réductions sur l'hôtellerie et la restauration, menus cadeaux, gratuités diverses pouvant aller de la coupe de champagne jusqu'à un repas d'anniversaire au restaurant, en passant par le stationnement de proximité. Autant dire que cette enquête a été plutôt agréable à mener, nous conduisant à profiter, sans jouer un seul centime, d'établissements offrant toutes sortes de plaisirs raffinés.

Les principales cartes
Le marché français des casinos est assez nettement dominé par deux grands groupes (Barrière et Partouche), suivis par Joa (anciennement Moliflor). Le premier propose sa carte Casinopass (sans contact), et le second sa concurrente dite Players Plus (à contacts). Certains groupes de plus petite taille ont aussi leur propre carte : Tranchant (sans contact), Emeraude (magnétique), ainsi que quelques casinos indépendants, bien conscients de l'attractivité de la formule.
La délivrance de ces cartes suppose invariablement que l'on remplisse un formulaire d'adhésion par lequel on accepte des conditions de fonctionnement et un « code de bonne conduite » dont le non-respect peut entraîner une exclusion, éventuellement définitive. Le plus grand tact s'imposera donc dans la conduite des manipulations auxquelles on pourra être tenté de procéder avec ces cartes qui restent, selon la formule consacrée, « la propriété du casino émetteur » : pour mieux comprendre leurs mécanismes de fonctionnement, bien sûr, mais aussi pour dépister de possibles atteintes au respect de notre vie privée. On découvrira à cette occasion une grande diversité dans les solutions techniques adoptées, ce qui est une aubaine pour expérimenter avec des familles de cartes sans contact dont il n'est pas forcément facile d'obtenir des échantillons. Nous le verrons, beaucoup de place inutilisée est à notre disposition dans leur espace mémoire, dont il s'agira de profiter avec rigueur et discernement.


La carte Players Plus
Seule carte à puce à contacts parmi toutes celles que nous avons eu l'occasion de nous faire délivrer, la carte du groupe Partouche porte au verso les nom et prénoms du titulaire, un code à barres, un numéro en clair et une toute petite photo d'identité. C'est visiblement la puce, et elle seule, qui est mise à contribution lors du contrôle d'accès : insérée dans un lecteur (en l'occurence un simple ACR 30 dans l'un des casinos visités) qui n'y accède que pendant une fraction de seconde (allumage très bref du voyant de lecture), elle déclenche l'affichage de la photo de son titulaire sur l'écran de l'agent de sécurité. Celle-ci est donc, selon toute vraisemblance, lue dans une base de données centrale et non pas dans la carte.
En salle de jeux, des bornes en libre service permettent de lire un solde de points de fidélité qui augmente au fur et à mesure que l'on joue (à condition d'insérer la carte dans la fente des machines à sous), mais qui peut aussi diminuer si on reste trop longtemps sans s'en servir. Là encore, on peut raisonnablement penser que le compteur de points ne réside certainement pas dans la carte, mais bien dans un serveur informatique central et donc à l'abri de toute manipulation indésirable.
Il semblerait en fait que le rôle de la carte se limite à une fonction d'identification, qui pourrait tout aussi bien passer par une lecture optique du code à barres ou une saisie manuelle du numéro. Pour chercher à confirmer cette hypothèse, il est évidemment tentant d'explorer la puce électronique , ce que nous ferons notamment avec le petit programme (PLAYER.BAS) que voici.

#Include CARDUTIL.DEF
#Include COMMERR.DEF
Declare Command &H00 &HA4 SEL(S$)
Declare Command &H00 &HB2 RREC(S$)
ComPort=101
CLS:PRINT"PLAYER (c)2010 Patrick GUEULLE":PRINT
Call WaitForCard:ResetCard(S$):Call CheckSW1SW2
Print:Print S$:Print
S$=Chr$(240)+Chr$(0)+Chr$(0)+Chr$(0)+Chr$(7)+Chr$(0)+Chr$(1)
Call SEL(P1P2=&H0400,S$,Disable Le):Call CheckSW1SW2
Call RREC(P1P2=&H010C,Lc=0,S$,Le=18):Call CheckSW1SW2
For F=5 TO 12
C$=MID$(S$,F,1):C=ASC(C$):C$=HEX$(C)
IF LEN(C$)=1 then C$="0"+C$
Print C$;
Next F:Print:Print
Call WaitForNoCard

Une fois ces quelques lignes de ZCBasic compilées en un exécutable Windows (PLAYER.EXE) au moyen du kit BasicCard (téléchargeable gratuitement), n'importe quel lecteur PC/SC se fera un plaisir d'afficher les caractères historiques de l'ATR de la carte traduits en ASCII (PlayersPlus1.1), puis le numéro qui figure au verso (16 chiffres sans clef de Luhn, avec des zéros de bourrage à gauche). A noter que ce numéro semble s'incrémenter tout simplement d'une unité pour chaque nouvelle carte émise, et ne résulte donc manifestement pas d'un quelconque calcul cryptographique. Quelques octets de plus seraient éventuellement lisibles au moyen d'une commande 00 B2 01 14 08, mais ils ne semblent pas présenter beaucoup d'intérêt...
Bien entendu, ce programme simpliste ne conviendrait pas forcément à une future version (peut-être avec et sans contact ?) qui pourrait succéder un jour à la 1.1. Mais si dans l'état actuel des choses il n'y avait que cela à lire dedans (ce qui, nous le verrons, n'aurait rien d'invraisemblable), alors son
« clonage » avec une simple BasicCard serait techniquement envisageable. Nous ne verrions pourtant pas là de véritable faille de sécurité, dans la mesure où le contrôle d'accès proprement dit est effectué par un personnel physionomiste, à partir d'une photo que la présentation de la carte aide juste à afficher rapidement, et probablement d'une consultation automatique du fichier des interdits de jeu.
D'un autre côté, si la carte ne supporte effectivement, dans la classe 00h, que des instructions de sélection et de lecture (A4, B2, et C0), elle en reconnaît 14 de plus dans la classe 80h (14, 20, 24, 30, 82, 84, C8, CA, CC, D2, E2, E4, E6, E8). Cela rappelle d'assez près le « vocabulaire » des cartes ACOS d'ACS, tentons un « coup de poker » en essayant les commandes 80 A4 00 00 02 FF 00 puis 80 B2 01 00 08. Gagné ! La réponse obtenue (41 43 4F 53 03 01 00 08) est bel et bien typique d'une ACOS 3 version 1.0 (8 Ko d'EEPROM), dotée de tout le nécessaire pour implémenter des mécanismes de mots de passe ou même d'authentification mutuelle. Envoyons ainsi, autant de fois que nous le voudrons, 80 84 00 00 08, et nous recevrons à chaque fois en réponse un bloc aléatoire de 8 octets. Mais ces fonctionnalités natives de la famille ACOS en général sont-elles mises à contribution dans la vie courante de cette carte en particulier ? Il suffit d'inspecter les autres fichiers système à lecture libre (FF01, FF02, FF04 et FF07) pour avoir de très sérieux doutes, car ils sont complètement vierges ! Bien que la clef « de transport » (41 43 4F 53 54 45 53 54 soit ACOSTEST) ait été changée, ce qui est tout de même la moindre des choses, aucun autre fichier n'aurait donc été créé par l'émetteur. Rien d'étonnant, pourtant, quand on voit comment fonctionnent les cartes des groupes concurrents...


La carte CasinoPass
Très différente, la carte du groupe Lucien Barrière porte au recto le prénom et le nom de son titulaire, un numéro à huit chiffres, et une date de création (car elle n'est valable que deux ans). Au verso, une bande magnétique est apposée en position standard, mais un lecteur de piste ISO 2 n'y trouve rien à lire. Un examen au révélateur magnétique confirme que la bande est complètement vierge, et par conséquent inutilisée à ce stade de la vie de la carte. Comme il n'y a pas non plus de puce à contacts, nous sommes vraisemblablement en présence d'une carte contactless. Rapide inspection par transparence, et bingo : un bobinage de sept spires est nettement visible, trahissant une technologie 13,56 MHz. Oui, mais laquelle ?
Présentée à nos lecteurs RFID et NFC habituels (ACR 120 et 122 d'ACS, SCL010 et SCL3711 de SCM Microsystems), la carte n'est pas détectée, donc elle ne répond pas aux spécifications ISO 14443. Cela se présente mal, dirait-on ! Essayons alors le Cardman 5321 d'Omnikey (providentiellement fourni dans les kits BasicCard dual interface), et cette fois le voyant vert nous fait un clin d'oeil rouge ! Or, parmi tous ceux essayés, ce lecteur est le seul à supporter la technologie ISO 15693, dont la portée peut atteindre (avec des antennes appropriées), 1,50 m à 2 m au lieu des 10 cm habituels ! Une telle possibilité pourrait permettre de lire (ou écrire) dans la carte « au vol », lors du passage d'un portillon (ou ailleurs...), sans même avoir à la sortir de sa poche. Pratique, certes, mais potentiellement inquiétant pour tous ceux qui craignent d'être suivis à la trace jusque dans les toilettes.
Envoyons donc au lecteur une commande FF CA 00 00 08. Spécifique au 5321, celle-ci nous retourne l'UID (identifiant unique et inaltérable) du composant interne, de la forme XX XX XX XX XX 01 04 E0. A en croire la spécification ISO 15693-3, le E0 final indique que les octets qui précèdent sont compatibles ISO 7816 : 04 et 01 révèlent ainsi respectivement que la puce est de marque NXP (Philips) et de type ICODE SLI. Ce type de composant, fort peu sécurisé, est à l'origine destiné à des applications de suivi d'objets sur des chaînes de manutention ou dans des magasins, mais présente l'avantage d'être très bon marché (guère plus de 0,60 € la carte « blanche », par quantités).
Dotée de 28 blocs de 4 octets chacun (soit 896 bits), sa mémoire EEPROM peut se lire intégralement au moyen de commandes compatibles PC/SC 2.0, mises en oeuvre par le petit programme ZCBasic que voici (PASS.BAS).

#Include CARDUTIL.DEF
#Include COMMERR.DEF
Declare Command &HFF &HCA UID(S$)
Declare Command &HFF &HB0 RBIN(S$)
ComPort=102
REM Pour Omnikey 5321 avec driver 1.2.0.6 / XP (ou sup)
CLS:PRINT"PASS (c)2010 Patrick GUEULLE":PRINT
Call WaitForCard:ResetCard(S$):Call CheckSW1SW2
Print:Print
Call UID(P1P2=&H0000,Lc=0,S$,Le=8):Call CheckSW1SW2
Print "UID : ";
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$
Print C$;
Next F:Print:Print
Call RBIN(P1P2=&H0000,Lc=0,S$,Le=&H70):Call CheckSW1SW2
R=0
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$
Print C$;:R=R+1
If R=4 Or R=8 Or R=12 Then Print" ";
If R=16 Then Print:R=0
Next F:Print:Print
Call WaitForNoCard

A noter toutefois que Windows XP ou supérieur est nécessaire, ainsi que le driver propriétaire d'Omnikey en version 1.2.0.6 au minimum (ne pas se contenter d'un driver s'installant éventuellement par défaut lors du premier branchement du lecteur !). Remarquons d'ailleurs que pour une fois, nous avons fixé ComPort à 102 au lieu de 101, car le 5321 étant de type bi-mode (avec et sans contacts), ce fameux driver expose deux lecteurs PC/SC distincts : le n°1 correspond ainsi à la fente pour cartes à contacts, et le n°2 à l'antenne contactless. Ne nous trompons pas, et ne branchons pas d'autre lecteur en même temps sans prendre soin de modifier ComPort en conséquence.
Lançons maintenant l'exécutable compilé (PASS.EXE), qui affiche cette fois l'UID et le contenu entier de la carte. Sur celle qui nous a été délivrée, quatre blocs seulement contenaient quelque chose : les 0E, 0F, 10, et 1B (dernier). Pas de corrélation évidente entre ces 32 octets et le numéro imprimé sur la carte, et il en va de même avec l'UID. On peut donc imaginer qu'il pourrait y avoir un semblant de cryptage, ou tout bonnement qu'il existerait une correspondance, dans la base de données centrale où réside manifestement la photo du titulaire, entre le numéro de la carte et son contenu et/ou son UID.
Mais le plus surprenant c'est que, bien que la puce ICODE SLI dispose d'une possibilité de protection (irréversible) en écriture bloc par bloc, tout est en lecture et écriture libres ! On pourrait donc modifier aisément ce qui est inscrit dans la carte, rétablir à volonté son contenu d'origine, ou encore tout effacer...
Faisons par exemple FF D6 00 00 04 AA BB CC DD pour écrire quatre octets arbitraires dans le bloc n°0, puis après une relecture de contrôle, FF D6 00 00 04 FF FF FF FF pour le remettre dans son état initial de virginité. Sauf si elles ne servent à rien, ces données ont donc vraisemblablement vocation à être actualisées de temps à autre, aussi aura-t-on intérêt à les surveiller au fur et à mesure des visites dans un ou plusieurs casinos du groupe, et selon ce que l'on y aura fait. Cela pourrait être instructif...
Il aurait pourtant pu être fait usage de la version ICODE SLI-S de ce produit très populaire, couramment utilisée pour protéger les livres prêtés par les bibliothèques. Pour cette dernière application, il est évidemment nécessaire que l'on ne puisse pas modifier abusivement le contenu de la mémoire, aussi est-il prévu tout un système de mots de passe à 32 bits.

Il est clair que ces observations accréditent notre hypothèse qu'en matière de contrôle d'accès dans les casinos, la véritable sécurité ne doit pas se situer dans la carte, mais dans un système informatique vis-à-vis duquel celle-ci ne servirait que de simple identifiant, au même titre qu'un numéro de Sécurité Sociale. Et ce n'est pas la suite de nos expériences qui va nous faire changer d'avis !


La carte JoaClub
Tout comme la précédente, la carte des casinos Joa est reconnue par le lecteur Omnikey 5321 comme répondant à la spécification ISO 15693. Il est vrai que dans les établissements du groupe, il est courant de franchir, dès l'entrée, un portique rappelant les systèmes anti-vol des supermarchés, puis d'être admis dans la salle des jeux sans autre formalité qu'un cordial « bonjour » si on a bien sa carte en poche. Au verso se trouvent le nom du titulaire, la date de création de la carte, un numéro à 8 chiffres sans clef de Luhn, et un code à barres reproduisant celui-ci, précédé cependant de 6 chiffres supplémentaires. Cette fois, la piste ISO 2 de la bande magnétique est encodée, avec ce même numéro précédé de 12 chiffres sans signification flagrante.
Là encore, l'UID (XX XX XX XX XX 00 12 E0) ne se rapproche d'aucune de ces données, mais indique sans équivoque que le fabricant du composant interne est Inside Contactless : code 12h, au sens de la spécification ISO 7816-6. Le lecteur identifie plus précisément la carte comme étant une ICLASS 2KS, riche de 32 blocs d'EEPROM de 8 octets chacun (soit un total de 2 Kbits) tout comme les Picopass 2KS du même fabricant. Seulement, cette « puce » est bien plus sécurisée que la précédente, puisque même sa lecture est subordonnée à la présentation d'une clef... que nous ne connaissons pas. Qu'à cela ne tienne ! Ces cartes sont supportées par une API dite « synchrone », téléchargeable sur le site d'Omnikey et venant compléter le driver du 5321. Suite à son installation, plusieurs logiciels fort utiles se trouvent mis à notre disposition, dont un ICLASS explorer qu'il serait dommage de ne pas mettre à contribution.


L'écran principal de ICLASS explorer

Au delà de la confirmation de ce que nous avions déjà découvert, il nous montre beaucoup de zones vierges (à FFh), et nous propose d'aller lire davantage de détails. C'est à ce stade qu'il va nous demander soit de saisir une clef, soit d'indiquer le numéro d'une de celles qu'il connaît d'origine (mais qu'il ne nous dévoilera pas, même sous la torture !).
Après quelques essais infructueux, la clef pré-programmée n°33 est acceptée, mais la lecture ne va pas plus loin, apparemment pour cause de « limite d'application invalide ». L'explication est simple : la firme HID (à laquelle appartient Omnikey) commercialisant sous sa propre marque des cartes ICLASS partitionnées d'une façon spécifique, le logiciel ICLASS explorer cherche à lire la partition correspondant à « l'application HID ». Or celle-ci est tout bonnement absente de la carte Joaclub. La preuve, la clef n°33 est la « clef de transport par défaut » activée par Inside contactless avant la livraison de ses puces ! La carte Joaclub n'est donc finalement pas plus sécurisée que la Casinopass, et nous allons le démontrer de ce pas en allant lire et écrire dans sa mémoire.
Pas moyen, malheureusement, de faire cela en ZCBasic ou avec un scripting tool ordinaire, car le driver du lecteur ne permet pas d'utiliser directement des commandes PC/SC 2.0 pour opérer sur cette famille de cartes. Le logiciel de démonstration de l'API synchrone peut heureusement prendre la relève, nous dispensant ainsi de tout travail de programmation ! A noter tout de même qu'il est fourni avec deux variantes de son code source, en C et en Visual Basic, dont il ne serait pas interdit de s'inspirer pour aller plus loin. Il semblerait, à vrai dire, que l'intégralité de la carte soit lue spontanément dès que la bonne clef est présentée, puis que l'API génère toute seule les réponses aux pseudo-commandes de lecture de tel ou tel bloc qui lui sont en suite adressées. Mais qu'importe, c'est le résultat qui compte !


Le logiciel « contactlessdemovb »

Dans le champ « ICLASSTRANSMIT », il faut ainsi entrer des pseudo-APDU qui seront donc interprétées par l'API sans être retransmises à la carte, et dont le dictionnaire limitatif est fourni dans la documentation (nullement confidentielle) allant avec le logiciel. Commençons donc par présenter la fameuse clef n°33, dont nous ne connaîtrons décidément pas la valeur, en tapant 80 88 01 33. Un compte-rendu 90 00 (au lieu de 69 83 lorsque la clef sélectionnée n'est pas la bonne) nous confirmera que la porte est désormais grande ouverte (et sans effraction, s'il vous plaît !).
Pour examiner la totalité de la mémoire de la carte, il nous suffit maintenant d'enchaîner des commandes allant de 80 B0 00 00 08 à 80 B0 00 1F 08. Nous trouverons alors l'UID de la carte dans le bloc 00h, un bloc de configuration en 01h, un porte-monnaie électronique en 02h (contenu initial FE FF FF FF FF FF FF FF indiquant probablement qu'il est vide), et une zone émetteur complètement vierge en 05h. Les blocs 03h et 04h hébergent pour leur part des clefs baptisées Kd et Kc (débit et crédit), dont la valeur est fort classiquement masquée en lecture par des octets FFh. Les blocs 06h à 1Fh constituent la zone libre dans laquelle on peut lire et écrire à volonté. A vrai dire, le seul dans lequel nous ayons trouvé quelque chose est le premier : à une commande 80 B0 00 06 08, notre carte a répondu 0B 0C 0D 0E 0F 10 11 12, autrement dit des données parfaitement arbitraires et en tout cas sans aucun rapport avec le numéro qui est imprimé au verso. Et pour couronner le tout, aucune protection n'empêche d'écrire ou d'effacer n'importe quel bloc : une commande 80 D6 00 1F 08 01 02 03 04 05 06 07 08 modifiera ainsi le contenu du bloc 1F, tandis que 80 D6 00 1F 08 FF FF FF FF FF FF FF FF le remettra dans l'état vierge qui était le sien avant cette petite plaisanterie. Le succès de chacune de ces deux opérations pourra naturellement être vérifié au moyen d'une commande de lecture 80 B0 00 1F 08.
Bien entendu, il sera souhaitable de surveiller le contenu de la carte au fur et à mesure de son utilisation dans les casinos. Notre petit doigt nous dit pourtant qu'il ne se passera sans doute pas grand-chose dedans, le solde de points de fidélité étant par exemple consultable sur des bornes lisant... la piste magnétique, avec composition d'un code confidentiel qui n'atteindra jamais la puce RFID. Rien n'interdirait toutefois à l'émetteur d'ajouter un jour des fonctionnalités et de modifier alors la clef par défaut, ce qui sauterait immédiatement aux yeux des explorateurs avertis que nous sommes en train de devenir.


La carte Tranchant
Pas ordinaire, cette carte du groupe Tranchant, puisque lors de son établissement, un relevé d'empreinte digitale remplace la traditionnelle prise de photo ! Par la suite, lors de chaque accès au casino, il faudra d'abord présenter brièvement la carte devant un lecteur sans contact, puis poser le doigt sur un capteur. La carte elle-même ne porte guère, au verso, que le prénom et le nom du titulaire, ainsi qu'un numéro à neuf chiffres (dont le nôtre, tout au moins, passe avec succès le test de Luhn comme celui de toute honnête carte bancaire). Mais elle est, cette fois, reconnue par tous les lecteurs sans contact de notre laboratoire, car c'est tout bonnement une Mifare 1K !
Il est donc nécessaire de présenter une clef pour lire chacun des 16 secteurs de 64 octets qu'elle contient, et c'est là que les choses se corsent... Même la version « pro » du logiciel Smart Card Commander de SCM microsystems, qui intègre une large bibliothèque de clefs « par défaut » couramment utilisées (à commencer par les classiques A0 A1 A2 A3 A4 A5, B0 B1 B2 B3 B4 B5, et FF FF FF FF FF FF), a été essayée en vain. Un bon point, en somme, sur le plan de la sécurité ! Seule l'UID du composant interne (quatre octets) peut ainsi être lue, mais pourquoi ne reste-t-il même pas un seul secteur inutilisé, avec ses clefs par défaut ? L'empreinte digitale serait-elle donc stockée dans la carte ? Ce serait théoriquement possible, car comme il ne faut guère que 240 octets pour coder les 15 « minuties » nécessaires à une reconnaissance fiable, les 1024 octets disponibles dans le Mifare 1K suffiraient amplement. Cela supposerait toutefois de s'étaler sur quatre secteurs, et donc d'effectuer quatre authentifications. Or, le peu de temps que prend la lecture de la carte rend cette hypothèse peu plausible. A notre avis, lire l'UID (difficilement falsifiable) suffirait pour retrouver le gabarit de l'empreinte dans la base de données du casino, mais peut-être le numéro imprimé sur la carte est-il également enregistré (et donc lu) quelque part ? Ou alors, n'y aurait-il pas là une application encore « dormante », telle qu'un porte-monnaie électronique ou un collecteur de points de fidélité ? Pour le moment, le mystère reste entier, ce qui nous fait considérer cette carte comme l'une des plus sûres parmi celles qu'il nous a été donné d'examiner. Et pourtant, on sait bien que le Mifare « classic » a été craqué !

Les cartes des « petits » casinos
En dehors des grands groupes, des réseaux de casinos de moyenne importance ou même des établissements indépendants mettent un point d'honneur à offrir leur propre carte à leur clientèle. Celle du groupe Emeraude, par exemple, est purement magnétique donc a priori copiable et modifiable, car à lecture et écriture entièrement libres. Sur sa piste ISO 2, on retrouve le numéro à quatre chiffres (sans clef de Luhn) qui accompagne, au recto, le prénom et le nom du titulaire. Complété à gauche par des zéros de bourrage, notre numéro est précédé d'un groupe de chiffres qui commence curieusement par un 7, tout comme sur notre carte Joaclub. Si nous remarquons, de surcroît, que le nombre total de chiffres est de 20 dans les deux cas, il est permis de se demander s'il ne s'agit vraiment là que d'une simple coïncidence... En tout cas, une telle carte ne pourrait en aucune façon contenir la photo de son porteur, fût-elle fortement compressée.
Il en va de même avec cette carte, bizarrement toute blanche, émise par un casino indépendant de la côte normande : équipée d'une puce sans contact à technologie 125 kHz (plutôt utilisée pour l'accès à des parkings), elle ne peut guère contenir qu'un identifiant de quelques dizaines d'octets, bien que sa présentation déclenche, là encore, l'affichage quasiment instantané de la photo de son porteur.
A vrai dire, malgré de profondes différences technologiques d'une enseigne à l'autre, on retrouve pratiquement partout des principes sécuritaires fort comparables et longuement éprouvés : intervention humaine et consultation automatisée d'une base de données. Reste maintenant à savoir si les possibilités latentes des cartes à puce, actuellement sous-employées, se déchaîneront un jour afin de choyer (ou surveiller) encore mieux des clients plus ou moins privilégiés. Déjà, différents statuts de membre sont parfois disponibles, en fonction de l'ancienneté et/ou de la rentabilité du porteur de carte. On pourrait aussi imaginer que la carte devienne partie prenante dans certains jeux automatiques, voire même en ligne, mais là, c'est une autre paire de manches... Une chose au moins est sûre : lorsque quoi que ce soit se trouvera modifié dans la mémoire de ces cartes, nous serons aux premières loges !

Et pour les farceurs...

Le fait qu'une fonction de sécurité ne soit pas activée par l'émetteur d'une carte ne la rend pas forcément inaccessible, car il n'a sans doute pas davantage pris la peine de la verrouiller... Prenons l'exemple de la carte Casinopass, dont la puce ICODE-SLI est dotée d'un dispositif antivol principalement destiné aux magasins et aux bibliothèques : l'EAS (Electronic Article Surveillance). Son fonctionnement est simple : le portique de sécurité situé à la sortie envoie des commandes dites « EAS Alarm » à toutes les puces compatibles qu'il détecte dans son rayon d'action. Si une au moins a son EAS activé (ce qui est évidemment le cas de celles cachées dans tous les articles ou livres n'ayant pas encore été présentés en caisse ou au contrôle de sortie), elle répond par un mot de 32 octets invariable (et nullement confidentiel !) 2F B3 62 70 D5 A7 90 7F E8 B1 80 38 D2 81 49 76 82 DA 9A 86 6F AF 8B B0 F1 9C D1 12 A5 72 37 EF. Le système d'alarme se déclenche alors, sans forcément connaître l'identifiant de la puce responsable. Mais si l'EAS a bien été désactivé afin d'autoriser la sortie sans encombre de l'objet, alors la puce reste muette et le lecteur retourne tout au plus un code d'erreur.
Essayons donc ! Posons la carte sur un lecteur CardMan 5321 et envoyons lui la commande FF 30 06 00 20. Si nous recevons en réponse un code d'erreur 64 00, c'est que l'EAS est désactivé (mais pas forcément verrouillé). Pour l'activer, c'est facile : il suffit d'envoyer la commande FF 30 00 01 04 01 06 00 01. Vérifions le succès de l'opération en envoyant de nouveau FF 30 06 00 20, et si l'EAS n'était pas verrouillé, nous devrions cette fois recevoir les 32 octets convenus, accompagnés d'un compte-rendu 90 00. Dès lors, si l'on franchit, avec cette carte en poche, le portique de sécurité d'un établissement utilisant cette technologie antivol, eh bien cela déclenchera l'alarme ! Une fouille sommaire (à laquelle nul n'est d'ailleurs tenu de se soumettre si elle n'est pas pratiquée par un représentant de la force publique) est le maximum que l'on risque si on a la conscience tranquille. Mais l'aventure aura au moins eu le mérite de révéler quel est le système de sécurité mis en oeuvre, ainsi que ses vulnérabilités potentielles !

#Include CARDUTIL.DEF
#Include COMMERR.DEF
Declare Command &HFF &HCA UID(S$)
Declare Command &HFF &H30 ICODE(S$)
ComPort=102
REM Pour Omnikey 5321 avec driver 1.2.0.6 / XP (ou sup)
CLS:PRINT"EASON (c)2010 Patrick GUEULLE":PRINT
Call WaitForCard:ResetCard(S$):Call CheckSW1SW2
Print:Print
Call UID(P1P2=&H0000,Lc=0,S$,Le=8):Call CheckSW1SW2
Print "UID : ";
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$
Print C$;
Next F:Print:Print
S$=Chr$(1)+Chr$(6)+Chr$(0)+Chr$(1)
Call ICODE(P1P2=&H0001,Lc=4,S$,Disable Le):Call CheckSW1SW2
Call ICODE(P1P2=&H0600,Lc=0,S$,Le=32)
R=0
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$
Print C$;:R=R+1
If R=16 Then Print:R=0
Next F:Print:Print
Call WaitForNoCard

Le petit programme ZCBasic EASON.BAS a été développé pour automatiser entièrement cette manoeuvre sous Windows XP ou supérieur : il suffit d'exécuter sa version compilée EASON.EXE sur un lecteur 5321, et si les 32 octets attendus s'affichent bien, alors tout est prêt !
Bien entendu, il conviendra de remettre ensuite la carte dans son état initial, au moyen de la commande FF 30 00 01 04 01 06 00 00, sauf si on souhaite s'en servir pour faire une (bonne ?) blague à quelqu'un. Cette désactivation se fera on ne peut plus facilement au moyen du programme EASOFF.BAS, dont l'exécution de la version compilée EASOFF.EXE devra donner comme résultat un compte-rendu 64 00. A n'utiliser qu'à bon escient, naturellement !

#Include CARDUTIL.DEF
#Include COMMERR.DEF
Declare Command &HFF &HCA UID(S$)
Declare Command &HFF &H30 ICODE(S$)
ComPort=102
REM Pour Omnikey 5321 avec driver 1.2.0.6 / XP (ou sup)
CLS:PRINT"EASOFF (c)2010 Patrick GUEULLE":PRINT
Call WaitForCard:ResetCard(S$):Call CheckSW1SW2
Print:Print
Call UID(P1P2=&H0000,Lc=0,S$,Le=8):Call CheckSW1SW2
Print "UID : ";
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$
Print C$;
Next F:Print:Print
S$=Chr$(1)+Chr$(6)+Chr$(0)+Chr$(0)
Call ICODE(P1P2=&H0001,Lc=4,S$,Disable Le):Call CheckSW1SW2
Call ICODE(P1P2=&H0600,Lc=0,S$,Le=32)
Print"SW1SW2 = ";Hex$(SW1SW2)
Print:Print
Call WaitForNoCard


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]