Une carte à puce est un bout de plastique de taille normalisée sur lequel est disposé une puce dont les dimensions et emplacement exact sont également normalisés.
La puce en elle-même est invisible car cachée derrière 8 connecteurs en métal conducteur.
Historiquement les premières puces n'etaient que de simples mémoires. C'etait le cas de la carte à puce objet du brevet de Roland Moreno ou des premières cartes téléphoniques Télécarte. Ces cartes sont aujourd'hui dépassées et ne sont plus utilisées.
De nos jours, seules les cartes à micro-processeur subsistent.
Sur les 8 connecteurs visibles, seuls 5 sont utilisés. Leur nom montre à quel point une carte à puce est dépendante du lecteur dans lequel on l'insère, puisque celui-ci doit lui fournir l'alimentation électrique (pattes VCC et VSS, généralement 5V) ainsi que l'horloge (patte Clock, généralement à 3.5 Mhz). Le lecteur peut également faire rebooter la puce en mettant brièvement la patte RESET à 0 (reset à chaud).
La communication entre la puce et le lecteur se fait en mode série, bit à bit, sur la patte input/output. Faire une communication bi-directionnelle sur une seule patte a un avantage (une seule patte utilisée) mais a deux défauts : la faible vitesse d'une part, et la gestion électrique de la patte d'autre part. En effet, il est évident que si la puce cherche a y parler en y mettant du 5V alors qu'au même moment le lecteur cherche aussi à y parler en y mettant du 0V, l'un des deux va griller.
Pour éviter cela, le protocole T=0 qui est celui qui est quasiment le seul utilisé, prévoit que la puce ne parle jamais tant qu'elle n'y est pas invitée par le lecteur. Le dialogue se fait selon la séquence suivante :
1) Mise sous tension électrique de la puce par le lecteur et envoi permanent de l'horloge par le lecteur vers la puce. La puce boote.
2) La puce émet une séquence d'octets appelée ATR (Answer To Reset, ou réponse à l'initialisation). Il s'agit d'une séquence de 2 à 32 octets émis par la puce à 9600 bauds et qui est censée donner au lecteur des informations sur le fonctionnement de la puce. Décrire l'ATR dans son ensemble est assez compliqué (voir la page Wikipédia pour plus d'infos). L'octet le plus important dans l'ATR est le premier : il vaut soit 0x3B pour dire que la puce fonctionne en convention directe, soit 0x3F pour signaler que la puce fonctionne en convention inverse (voir plus bas).
3) Une fois que la puce a envoyé son ATR, elle ne parle plus tant qu'elle n'y est pas invitée par le lecteur. C'est donc le lecteur qui a la main sur la patte input/output. Quand le lecteur veut intéragir avec la puce, il lui envoie un APDU (Application Protocol Data Unit), c'est à dire une séquence de généralement 5 octets. Le premier octet est la classe (CLA) de la commande. Le deuxième octet est l'instruction dans la classe (INS), les 3ème et 4ème octets sont les paramètres P1 et P2 de l'instruction, et le 5ème octet est généralement la taille de la réponse attendue.
Donc un APDU a généralement la forme : CLA INS P1 P2 Le
La classe sert à éventuellement mettre plusieurs applications dans la carte à puce. Avec l'octet de classe, la carte sait à quelle application l'APDU s'adresse.
Prenons un exemple avec les anciennes cartes bancaires à puce B0 d'avant 2006, elles réagissaient à la classe 0xBC et l'instruction pour lire une zone mémoire était 0xB0. Si l'on voulait lire 16 octets de mémoire à partir de l'adresse 0x9F0 par exemple, il suffisait d'envoyer à la carte l'APDU : BC B0 09 F0 10.
4) Quand la carte à puce a reçu un APDU, elle donne une réponse qui est formatée soit :
XX XX XX XX SW1 SW2, soit SW1 SW2, c'est à dire que la réponse se termine toujours par deux octets qui donnent le statut de la réponse, avec éventuellement une réponse avant.
Les octets SW1 et SW2 relèvent de la pure convention. Une carte bancaire moderne EMV renvoie 90 00 quand tout s'est bien passé, mais elle peut renvoyer autre chose si l'on demande une info qui nécessite d'avoir présenté au préalable le code PIN par exemple.
Une fois que la carte à puce a donné sa réponse à l'APDU, elle libère électriquement la patte input/output et elle attend patiemment un autre APDU.
Il est clair que la première chose à se procurer lorsqu'on veut expérimenter avec une carte à puce c'est la liste des ADPU qu'elle connait et comment elle y répond.
Convention directe et convention inverse
La communication entre la carte à puce et le lecteur emprunte soit la convention directe, soit la convention inverse. C'est la carte qui impose son mode de communication au lecteur.
Dans la convention directe, un niveau logique 1 est envoyé sur la patte input/output avec du +5V et un niveau logique 0 avec du 0V. Par contre les bits de l'octet à transmettre sont émis du LSB (less significant bit) vers le MSB (most significant bit).
Dans la convention inverse, un niveau logique 1 est envoyé sur la patte input/output avec du 0V et un niveau logique 0 avec du +5V. Par contre les bits de l'octet à transmettre sont émis du MSB vers le LSB.
Que ce soit en convention directe ou inverse, l'octet à transmettre est toujours précédé d'un bit de start à 0, et suivi d'un bit de parité paire. Après la transmission d'un octet, la carte attend l'équivalent de 2 bits de stop.
Ce genre de détails sur la transmission des bits est complètement transparent pour le programmeur du côté du PC (c'est l'interface PCSC qui gère cela). Par contre pour le programmeur dans la carte à puce, cela dépend. Je pense que dans une java card les classes java fournies rendent également transparent cela. Par contre, et là j'en suis sûr, le programmeur doit gérer ces aspects lorsqu'il programme une carte à puce à base de micro-contrôleur, comme les wafer gold ou Silvercard.
Terminons sur ces quelques connaissances de base pour signaler que l'intégralité des aspects normatifs liés aux cartes à puce (dimensions, caratéristiques électriques, protocoles de communication, etc.) sont définis dans la norme ISO 7816.
Structure des fichiers
Les premières cartes à puce à micro-processeur, comme la carte bleue bancaire B0 active jusqu'en 2006 par exemple, ne connaissaient pas la notion de fichiers. Elles avaient un espace mémoire, c'est tout, dont certaines zones étaient accessibles en lecture depuis le lecteur sans le code PIN, et d'autres zones accessibles seulement après avoir présenté le code PIN à a carte.
Les cartes à puce modernes, comme la carte bancaire EMV ou la carte SIM des téléphones cellulaires, ont maintenant la notion de fichiers. En plus des ADPU reconnus par la carte, il faut donc aussi connaitre la liste des fichiers et leur contenu. A mon avis cette avancée ne sert strictement à rien en terme de fonctionnalités. Je pense qu'il s'agit juste de complexifier le fonctionnement de la carte pour compliquer le travail des pirates. En tout cas, en ce qui me concerne, je ne compte pas utiliser cette notion de fichiers dans mes futurs développements personnels à base de Silvercard.
Publié par Alan Cartman le 19 juillet 2016
Aucun commentaire:
Enregistrer un commentaire