Silvercard et autres cartes à puce à base de PIC

Il y a 3 types de cartes à puce. Tout d’abord, et ce sont les plus répandues, les cartes émises par les fondeurs de cartes. C’est le cas de toutes les cartes bancaires, navigo, et autres. Ces cartes ont ce qu’on appelle dans le jargon un « masque », c’est-à-dire un logiciel intégré en dur sur la base d’un système d’exploitation maison dédié. Ces cartes sont programmées une fois pour toutes en usine.

Ensuite il y a les cartes programmables de haut niveau, comme les java cards ou les basic cards. Il s’agit de cartes comportant un système d’exploitation capable de faire tourner des applications écrites dans un langage de haut niveau (java, basic) et qui surtout fournit aux programmeurs de la carte des fonctions de haut niveau déjà écrites (briques logicielles) permettant l’utilisation directe de composants logiciels déjà programmés et réutilisables, sur la gestion des entrées/sorties par exemple ou pour l’utilisation de fonctions cryptographiques.

Enfin, il y a les cartes programmables de bas niveau. Ce sont celles qui m’intéressent et qui font l’objet de cet article. Dans cette catégorie, on retrouve les cartes wafer gold, silvercard ou greencard. Ici pas de brique logicielle ni de composant logiciel réutilisable. La carte est programmable mais est fournie nue, sans rien de logiciel dedans. Le langage de prédilection pour les programmer est l’assembleur, voire le C dans le meilleur des cas (mais pas de java ni de basic).

Dit comme cela, ces cartes semblent moins intéressantes que les cartes programmables de haut niveau. Elles ont pourtant un intérêt, cela dépend de ce que l’on veut faire. Si l’on veut développer une application qui ne nécessite pas trop de mémoire, elles sont faciles à programmer et l’investissement initial est minime (un simple programmateur de cartes à quelques dizaines d’euros).

En tout cas, pour le projet que j’ai en tête, une silvercard est largement suffisante. Présentons donc cette famille de cartes à puce dans le détail.

Des puces à micro-contrôleur

Si les années 60-70 ont vu l’explosion de l’utilisation des micro-processeurs, les années 80-90 ont-elles été le théâtre de l’explosion de l’utilisation des micro-contrôleurs. Un micro-contrôleur c’est un micro-processeur simple, mais avec de la RAM, de la PROM (ou mieux de l’EEPROM) et des entrées/sorties dedans. En fait, dans un micro-contrôleur on a pratiquement un ordinateur complet dans une seule puce à quelques euros.

Bien sûr les micro-contrôleurs ne sont pas destinés à équiper des ordinateurs, mais plutôt des lave-vaisselle, des robots industriels, ou des lave-linge. Dans ce cadre sont apparus sur le marché plusieurs marques de micro-contrôleurs.

Dans les années 90, l’explosion de l’utilisation des cartes à puce a amené certains fabricants à avoir l’idée d’intégrer des micro-contrôleurs standards dans des cartes à puce. C’est ainsi que sont apparues ces cartes programmables de bas niveau. Deux fabricants de micro-contrôleurs en particulier ont bénéficié de cette dynamique : Microchip qui fabrique les micro-contrôleurs PIC, et Atmel qui fabrique les micro-contrôleurs du même nom.

Ainsi on retrouve des cartes programmables de bas niveau à base de micro-contrôleurs PIC comme les wafer gold cards, les silvercards, ou les greencards. D’autres cartes comme la Funcard ou la Jupiter embarquent un micro-contrôleur Atmel.

La différence entre ces cartes tient en la référence exacte du micro-contrôleur embarqué ainsi que la quantité de mémoire EEPROM l’accompagnant. En effet, la quantité de mémoire nécessaire au développement d’applications sérieuses n’étant généralement pas compatible avec le peu de mémoire embarquée dans le micro-contrôleur, les cartes embarquent une mémoire EEPROM en plus du micro-contrôleur.

Les cartes à puce à base de PIC

Nous voilà donc au cœur du sujet. L’architecture interne de ces cartes est toujours la même : les pattes externes de la carte à puce sont reliées en interne aux pattes équivalentes du micro-contrôleur (la patte horloge externe par exemple est reliée en interne à la patte horloge du micro-contrôleur, idem pour l’alimentation, etc.), y compris la patte input/ouput qui elle est reliée à l’une des pattes d’un des ports de communication du micro-contrôleur. La mémoire EEPROM est elle aussi reliée à des pattes internes du micro-contrôleur (ce qui permet au PIC de lire ou d’écrire dedans), mais n’est pas accessible depuis l’extérieur de la carte à puce.

Cette mémoire EEPROM interne, non accessible depuis l’extérieur de la puce, pose problème quant à son remplissage initial puisque justement … elle n’est pas accessible depuis l’extérieur de la puce. On est donc obligé de passer par un programme spécial, appelé « loader », à charger dans le PIC et dont le but est de prendre les données qu’on lui envoie et c’est le PIC qui transfère ces données vers l’EEPROM. Une fois que l’EEPROM est remplie, on efface le loader du PIC et on y met le programme final.

D’un point de vue de la sécurité le PIC est protégé, car il dispose d’un bit de sécurité qu’on peut positionner à 1 et qui empêche de pouvoir le lire pour y analyser le programme qu’il contient. Ce n’est pas le cas de l’EEPROM. Il faut donc faire attention à mettre les données sensibles dans le PIC et non dans l’EEPROM quand on design un système. En effet, si votre PIC est protégé en lecture, un assaillant peut toujours écraser votre programme par un programme à lui qui communique à l’extérieur le contenu de l’EEPROM.

La carte wafer gold est une carte à puce de couleur or renfermant un PIC16F84 et une mémoire EEPROM 24LC16B (de 2 Ko) câblée selon le schéma ci-dessous.

Il est à noter qu’il est tout à fait possible de recréer ces cartes en mettant sur un bout d’epoxy le PIC, l’EEPROM et en les reliant comme sur le schéma, en reliant le tout à des connexions de carte à puce.

La silvercard est une carte à puce de couleur argent refermant un PIC16F876 (ou 16F877) et une EEPROM 24LC64 (8 Ko) câblée selon le schéma ci-dessous.

On trouve aussi des greencards  (PIC16F876 + 24C128), des greencards 2 (PIC16F876 + 24C256), des bluecards, des emeraldcards, des canarycards.

Programmation de ces cartes

Hormis le fait qu’il faut disposer d’un programmateur physique, c’est-à-dire un dispositif à même d’injecter dans le PIC qui est dans la carte le programme qu’on a écrit pour lui (un simple lecteur de carte à puce en est incapable), encore faut-il savoir écrire un programme pour un PIC.

Et là il faut trois choses :

• Un : maitriser un langage de programmation supporté
• Deux : être capable de compiler le programme qu’on a écrit
• Trois : connaitre parfaitement le fonctionnement du PIC

Concernant le point 3, il n’y a pas 36 manières de faire : il faut récupérer et bûcher le datasheet du PIC sur le site de Microchip.

Concernant le point 1, en gros, il y a le choix entre 2 langages : le C ou l’assembleur. Le problème du C, c’est qu’on ne maitrise pas aussi bien la bête qu’en assembleur, et surtout les compilateurs C pour PIC sont payants à ma connaissance.

Concernant le point 2, il faut un compilateur. Soit on achète un compilateur C, soit on installe un compilateur assembleur gratuit, son on programme son propre compilateur. Cela parait bizarre de suggérer de programmer son propre compilateur, mais en réalité c’est assez facile, le PIC ne connaissant que 35 instructions assembleur. Je l’ai fait plus jeune pour le PIC16F84, le compilateur ne faisait que quelques centaines de lignes de C. J’ai aussi fait dernièrement un désassembleur de PIC16F876 en C, que je présenterai dans un prochain article. Sous Linux, il suffit d’installer le compilateur ASM PIC du GNU, gpasm (sudo apt-get install gputils).

Les compilateurs produisent des fichiers textes au format hex intel.

Il va de soi que, quel que soit le projet qu’on envisage de faire avec une PIC card, il y a des routines assembleur incontournables qui seront nécessairement à mettre dans le programme. On peut citer :

• Une routine capable d’émettre un octet pour un APDU en convention directe ( !)
• Une routine capable d’émettre un octet pour un APDU en convention inverse ( !)
• Une routine capable de recevoir un octet APDU en convention directe ( !)
• Une routine capable de recevoir un octet APDU en convention inverse ( !)
• Une routine capable de lire dans l’EEPROM interne du PIC (*)
• Une routine capable d’écrire dans l’EEPROM interne du PIC (*)
• Une routine capable de lire dans l’EEPROM externe ( !)
• Une routine capable d’écrire dans l’EEPROM externe ( !)
• Des routines de cryptographie

Il faut donc avoir ces routines dans sa boite à outil. Il se trouve que les routines (*) sont données dans la datasheet des PIC, et les routines ( !) sont aisément retrouvables dans les programmes « loaders » (vu au-dessus) qui pullulent sur Internet.

Pour un programme personnel, il n’y a pas besoin de routines en convention directe et en convention inverse. On en choisit une. En ce qui me concerne, j’ai récupéré une routine SEND et une routine RECEIVE en convention inverse.

Concernant les routines de cryptographie, elles sont normalement indispensables. En effet, généralement si l’on utilise une application à base de carte à puce, c’est qu’il y a un processus à sécuriser. Or, dans notre époque moderne, la sécurité c’est la cryptographie.

Microchip met à disposition de la doc et une librairie pour faire de la crypto avec les PIC. En ce qui me concerne j’ai l’intention d’utiliser l’algorithme TEA pour sécuriser les communications. Ce sera l’objet d’un prochain article.

Piratage

Bien sûr, ce genre de carte peut servir, et a servi dans le passé, pour faire du piratage. Cependant, pour faire une bonne carte à puce de contrefaçon, il faut à la fois simuler un fonctionnement correct de la puce et reproduire le look de la partie plastique de la carte à puce.

D'aucuns seraient tentés, pour simplifier le problème du look de la partie plastique de la puce, de desceller la puce d'une vraie carte pour la remplacer par la puce d'une PIC card correctement programmée. Comme cela, ni vu ni connu je t'embrouille.

Sauf que non. Les concepteurs des PIC cards ont pensé à cette éventualité et l'ont contré en personnalisant la puce des PIC cards : elles contiennent toutes un dessin du symbole "alpha" ce qui rend les fausses puces collées très vite décelables.

Symbole alpha présent sur la puce d'une Silvercard

Publié le 21 juillet 2016 par Alan Cartman