1


Dossier technique : Fonctionnement des cartes à puces et utilisation d’un porte-monnaie électronique.



Introduction



I/ Le monde des cartes actuelles



II/ Présentation des normes ISO 7816

II.1/ Vue d'ensemble des normes ISO 7816

II.2/ Protocole de transmission entre les cartes asynchrones et les terminaux

II.3/ Vue d'ensemble du système de fichiers

II.4/ Vue d'ensemble de l'architecture de sécurité



III/ Interface électronique et logiciel Smart Terminus

III.1/ L’interface électronique

III.2/ le logiciel Smart Terminus



IV/ Solutions de porte-monnaie électronique avec la Payflex

IV.1/ Description de la Payflex

IV.2/ Architecture usuelle

IV.3/ Description d’échanges réalisés lors d’une opération

IV.4/ Fonctionnalités pouvant être modifiées suivant les besoins


Conclusion


Glossaire


Liens utiles







Introduction




Dans le cadre de mon stage d’application ingénieur réalisé au sein de la société ARD, j’ai dû concevoir un lecteur de carte à puce. Mon travail devait servir à la réalisation d’automates rechargeant ou débitant un porte-monnaie électronique sur des cartes Payflex produites par l’entreprise Schlumberger. Mes compétences en électronique m’ont permis d’utiliser des montages électroniques existants chez ARD, et mes compétences informatiques m’ont permis de réaliser un logiciel de gestion de cartes, que j’ai nommé Smart Terminus.


La première partie de ce dossier vous présente une vision globale du monde des cartes, afin de pouvoir y situer notre Payflex.

La deuxième partie traite du fonctionnement des cartes à puce asynchrones. Nous y reprendrons notamment les points importants des normes ISO 7816-3 et ISO 7816-4.

La troisième partie permet de poursuivre le travail que j’ai accompli. Vous y verrez entre autres comment se servir du logiciel Smart Terminus.

La quatrième partie présente les solutions de porte-monnaie électronique possibles, en utilisant la technologie des cartes Payflex.




I/ Le monde des cartes actuelles :




Les cartes telles que nous les connaissons aujourd’hui servent à stocker des informations. Leurs applications sont diverses et variées : cartes d’accès, cartes téléphoniques, cartes bancaires, cartes de santé, cartes de transport…


Les points communs entre la plupart des cartes sont :


Il existe ensuite divers moyens d’y stocker de l’information :






Caractéristiques :




Caractéristiques :



Caractéristiques :


Notre Payflex est une carte à puce à contact, elle est assez fidèle à sa norme : l’ISO 7816.


Parmi les cartes à puces à contact on distingue 2 grandes familles de cartes :





La Payflex est une carte asynchrone. J’ai donc dû, pour pouvoir l’utiliser, réaliser un lecteur de cartes asynchrones. Le lecteur que j’ai réalisé ne prend pas en compte certains protocoles existants de communication parce que je n’avais pas la documentation nécessaire ou bien parce que je n’avais pas la possibilité de les mettre en œuvre avec un simple ordinateur. Il permet cependant de lire la majorité des cartes asynchrones existantes actuellement (cartes bancaires, cartes vitales …). Nous allons résumer le contenu des Normes ISO 7816 qui nous intéressent dans la partie suivante.






II/ Présentation des normes ISO 7816 :




Du point de vue technique, les cartes asynchrones peuvent être classifiées en deux types principaux: programmable et non programmable. Un programmeur d'application de carte à puce peut mettre la logique d'application sur la borne ou sur la carte si cette dernière est programmable. Nous pouvons assimiler les cartes asynchrones non programmables à un stockage externe (disquette…) avec des dispositifs de sécurité. Par conséquent, nous pouvons stocker certaines informations portatives sur la carte et la logique d'application sera assignée du côté terminal. D'autre part, les cartes à puce programmables, telle la Java card, permettent à la logique d'application d'être partiellement établie sur la carte.




II.1/ Vue d'ensemble des normes ISO 7816


ISO 7816-1 : Caractéristiques physiques des cartes : définit les dimensions des cartes et les contraintes physiques.

ISO 7816-2 : Dimensions et emplacement des contacts : définit les dimensions, l'emplacement et le rôle des contacts électriques sur la puce (l’alimentation VCC, la masse GND, l'horloge CLK, le reset RST, le port d’entrée-sortie I/O, la tension de programmation VPP et deux contacts supplémentaires réservés pour un usage ultérieur RFU).

ISO 7816-3 : Signaux électroniques et protocoles de transmission : définit les caractéristiques des signaux électroniques échangés entre la carte et la borne et deux protocoles de transmission : T=0 (protocole semi-duplex asynchrone de transmission de caractères) et T=1 (protocole semi-duplex asynchrone de transmission par blocs).

ISO 7816-4 : Commandes intersectorielles pour les échanges : définit un ensemble de commandes standard et une structure hiérarchique de système de fichiers.

ISO 7816-5 : Système de numération et procédé d'enregistrement pour des applications spécifiques : définit un nom unique d'application de carte.

ISO 7816-7 : Commandes intersectorielles pour le Langage d'Interrogation Structuré de Carte (SCQL) : définit un ensemble de commandes pour accéder au contenu de carte à puce à la structure de base de données relationnelle.


D'autres documents existent et ne sont pas cités ici puisque inutiles à la programmation d'application pour carte à puce ou puisque toujours en cours de préparation. Détaillons maintenant les normes ISO 7816-3 et ISO 7816-4.





II.2/ Protocole de transmission entre les cartes asynchrones et les terminaux



Les protocoles de transmission entre la carte asynchrone et le terminal sont décrits dans l’ISO 7816-3 (protocole de transport) et dans l’ISO 7816-4 (protocole d'application). Ces deux protocoles sont brièvement décrits dans cette section. La borne initialise une carte asynchrone en transmettant un signal au contact reset (RST) de la carte. La carte répond à ce signal en transmettant une chaîne d’octets à la borne appelée l'ATR (Answer To Reset). Cette chaîne d’octets se compose de deux parties : les octets de protocole fournissent des informations au sujet des protocoles de transmission soutenus par la carte, et les octets historiques fournissent des informations au sujet du type de carte. Un exemple est donné pour l'ATR de la carte à puce ACS ACOS1 (qui est un type de carte à mémoire de l’Advanced Card System company):


Protocol Bytes Historical Bytes


3B BE 11 00 00 41 01 10 04 00 12 00 00 00 00 00 02 90 00 (en hexadecimal)


Les détails de l'ATR sont décrits dans la norme ISO 7816-3. Voici une brève description des 3 premiers octets : Le caractère initial  ‘3B’ indique que la transmission des octets se fait en convention directe. Le second caractère ‘BE’ signifie qu'il y a de l'information additionnelle (E=>14 octets historiques). Le caractère ‘11’ donne des informations sur le taux de transfert et sur la fréquence de l’horloge CLK. Les octets historiques fournissent des informations sur les références et les versions du circuit intégré et du logiciel d'exploitation embarqué. Après que l'ATR ait été transmis, la borne peut communiquer avec la carte asynchrone en envoyant des commandes. Les commandes sont encapsulées en paquets. Ces paquets s'appellent « Transport Protocol Data Unit (TPDU) » soit en français « unité de données de protocole de transport ». Chaque paquet commence par les cinq octets suivants (en-tête) suivis d'un certain nombre d’octets de donnée si nécessaire :



CLA



INS


P1


P2


P3

TPDU Header


L’octet de classe CLA : indique une classe d’instructions. En général une carte n’accepte que très peu de valeurs de CLA différentes. Par exemple, l’octet de classe de la carte à puce ACS ACOS1 est 80 H et celui de la carte Java 32 bits de Gemplus est A8 H.

L’octet d'instruction INS : indique une instruction particulière. Par exemple, l'instruction VERIFICATION de la carte à puce ACS ACOS1 se code 20 H.

Les octets de paramètre P1 et P2 : indiquent des paramètres pour l'instruction. Par exemple, pour lire à partir du dixième octet avec la commande READ BINARY on aura P1 = 00 H et P2 = 0A H.

L’octet de paramètre P3 : indique le nombre d’octets de données qui sont transmis par la commande pendant l'échange. Cet octet peut indiquer le nombre d’octets que la borne enverra à la carte (Le) ou le nombre d’octets que la borne compte recevoir de la carte (Lc). Par exemple, le P3 pour l'instruction SUBMIT PIN est 08 H puisque le code PIN (numéro d'identification personnelle) pour la carte à puce ACS ACOS1 est codé sur 8 octets.


Après réception de l'en-tête, la carte émet un octet de procédure : en fonction de sa valeur par rapport à l’octet INS, celui-ci indique si elle a accepté la commande TPDU ou si le terminal doit attendre plus longtemps une réponse, ou bien encore si le transfert des octets de données se fera d’un coup ou bien octet par octet. Pour certaines cartes cet octet permet aussi de déterminer le format APDU (Application Protocol Data Units), la commande du protocole APDU est formée avec l'en-tête de TPDU. Il y a quatre formats possibles de la commande APDU :


  1. Aucun échange d’octet de donnée requis.


CLA

INS

P1

P2


Format 1 of APDU command


  1. Le terminal attend Le octets de données de la carte.


CLA

INS

P1

P2

Le


Format 2 of APDU command


  1. Le terminal envoie Lc octets de données vers la carte.


CLA

INS

P1

P2

Lc

Data


Format 3 of APDU command


  1. Le terminal envoie Lc octets de données vers la carte puis attend Le octets de données de la carte .


CLA

INS

P1

P2

Lc

Data

Le


Format 4 of APDU command

Quand les octets de données ont été transmis, la borne attend les 2 octets d’état (Status Word 1 et 2) qui finissent la commande. Leur signification est normalisée dans l’ISO 7816-4. Voici un sous-ensemble d’octets d’état courants :


SW1 SW2

Meaning

90 00

O.K.

67 00

Wrong P3

69 66

Command not available

6A 86

P1-P2 incorrect

6D 00

Unknown INS

6E 00

Invalid CLA


Basée sur SW1 et SW2, une réponse APDU aura le format suivant. Les octets de données sont facultatifs, puisque certaines commandes APDU n'exigent aucune donnée en retour, cf. les formats 1 et 3 précédents.

Data

SW1

SW2


Format of response APDU


La communication entre la borne et une carte asynchrone (représentée sur le schéma suivant) inclut une commande APDU qui est envoyée par la borne à la carte et une réponse APDU envoyée par la carte à la borne qui indique le résultat de la commande APDU. Ces échanges passent par la couche TPDU (protocole de transport). Un échange sur la couche APDU (protocole d'application) peut nécessiter plus d'un échange sur la couche TPDU. C’est notamment le cas pour le format 4 d’échange APDU et quand les quantités de données échangées dépassent 256 octets, on se sert alors de commandes TPDU qui n’existent pas au niveau APDU.


Protocole de transmission entre un terminal et une carte asynchrone.


Voici un exemple de la dépilations de la couche APDU jusqu'aux octets en passant par la couche TPDU. Nous reprenons ici le format 4 d’APDU, avec la commande INTERNAL_AUTHENTICATE qui permet au terminal d’authentifier et d’accepter la carte.


INTERNAL AUTHENTICATE:


To authenticate the smart card to the terminal.


Command APDU :


CLA

INS

P1

P2

Lc

DATA

Le

80

88

00

02

08

Challenge 1

08



Response APDU:


DATA

SW1 SW2

DES(Challenge 1,#K_02)

Status

Challenge 1 Eight random bytes

DES(Challenge 1,#K_02) Eight bytes challenge 1 encrypted with Key n°2 (K_02)


Commands TPDU :

Responses TPDU :


Cadre1


Cadre2


Cadre3


Cadre4


Bytes on the I/O contact :


CLA

INS

P1

P2

P3

Proc

DATA

SW1

SW2

80

88

00

02

08

88

8 bytes

61

08


CLA

INS

P1

P2

P3

Proc

DATA

SW1

SW2

80

C0

00

00

08

C0

8 bytes

90

00


Cet exemple montre ce qui se passe le plus couramment. Car il existe en effet plusieurs contrôles au niveau des couches : Au plus bas niveau il se peut que des octets n’ont pas été reçus avec la bonne parité ; dans ce cas il seront tout de suite re-émis. Et au niveau TPDU il se peut que l’octet de procédure indique directement un octet d’état SW1, auquel cas il n’y a pas d’octet DATA sur le contact, et la carte émet le deuxième octet d’état SW2. Ces octets d’état indiquent alors directement le statut de la réponse APDU (qui correspond sans doute à une situation d’échec).




II.3/ Vue d'ensemble du système de fichiers



Le système de fichiers spécifié dans l'ISO 7816-4 est un des composants importants des cartes asynchrones pour le stockage de données. Il décrit une structure hiérarchique qui s’apparente aux structures MS-DOS ou UNIX : Le système de fichiers possède :


Tous ces éléments sont référencés par un numéro d’identification (FID) codé sur deux octets. Il y a quatre structures de fichiers élémentaires :

Dans la carte à puce ACS ACOS1, les dossiers sont définis et construits dans l'étape de personnalisation. Voici un exemple de mapping construit durant cette étape et un exemple de la commande SELECT_FILE qui est employée pour sélectionner un fichier ou un répertoire :


SELECT FILE:

To select a data file for subsequent READ RECORD and WRITE RECORD commands.


Command TPDU:



CLA

INS

P1

P2

P3

DATA

80

A4

00

00

02

File ID


File ID Two bytes file identifier


Response TPDU:


SW1 SW2

Status


Specific Status Codes:


SW1 SW2

Meaning

6A 82

File does not exist.

61 xx

File selected.

xx is the number of the record in the User File Management File which contains the File Definition Block of the selected file.





II.4/ Vue d'ensemble de l'architecture de sécurité



Il y a deux mécanismes principaux de sécurisation des donnés pour les applications sur cartes asynchrones : le contrôle d'accès et la cryptographie.


Pour le contrôle d'accès, l'application (ou le détenteur de la carte) doit soumettre un numéro d'identification personnelle (PIN) avant n'importe quelle commande d'application. En outre, on peut placer dans la carte un ensemble de clés spécifiques (verification keys) afin d'augmenter les contrôles d'accès dans le système de fichiers : à chaque fichier sont assignés des attributs de sécurité (lecture, écriture, mise à jour…) qui définissent les conditions d’accès devant être remplies pour permettre l'opération respective.


Le canal de transmission entre la carte et le terminal peut être protégé par l’utilisation d’algorithmes cryptographiques comme le DES (Data Encryption Standard) ou le RSA (algorithme à clef public mis au point par Rivest, Shamir et Adleman).


Par ailleurs, il peut exister d'autres mécanismes spécifiques de sécurité, fournis par les différents fabricants de carte à puce.





III/ Interface électronique et logiciel Smart Terminus




III.1/ L’interface électronique



Elle se compose de 3 modules : un lecteur matériel de carte à puce à contact, un convertisseur 0-5V/RS232, et un circuit d’alimentation qui alimente le tout à une tension de 5 Volts.

Le lecteur physique qui correspond à la norme 7816-2 possède notamment :


Le convertisseur RS232 permet la conversion entre les signaux RS232 du port série de l’ordinateur et les signaux 0-5 Volts du lecteur physique. Dans le montage que j’ai effectué je me suis servi de cinq des neufs signaux disponibles sur le port série : RTS, DTR, RX, TX, et CTS. Le signal CTS permet de savoir si une carte est présente dans le lecteur, le signal RTS permet d’activer le reset de la carte à puce par l’intermédiaire de son contact RST, le signal DTR permet d’alimenter ou non une carte présente dans le lecteur, enfin les signaux RX et TX permettent la communication série entre la carte et l’ordinateur. A noter : comme les cartes asynchrones ne possèdent qu’un seul contact pour la communication série, celle-ci se fait donc en semi-duplex.


Les différents schémas des montages électroniques cités ici peuvent être accessibles en annexe, suivant autorisation de la société ARD.




III.2/ le logiciel Smart Terminus



Le logiciel Smart Terminus que j’ai réalisé permet de manipuler la plupart des cartes asynchrones existantes actuellement. Il ne répond pas à un cahier des charges prédéfini et je l’ai réalisé en même temps que j’assimilais les 2 normes ISO 7816-3 et 7816-4 que j’avais à ma disposition. D’ailleurs la norme ISO 7816-3 que j’avais ne comportait pas les rubriques définissant le protocole par bloc T=1. Smart Terminus ne gère donc pas les cartes nécessitant ce protocole.


Pour me familiariser avec le logiciel de développement C++ builder de Borland, je suis parti d’un petit projet réalisé par mon premier maître de stage Thibaut Reinhard. Ce projet qu’il avait intitulé Terminus permettait de gérer la communication série depuis un PC : j’ai donc pu reprendre une partie de ses codes étant donné que je gère la carte à puce depuis le port série du PC.


Etant donné que je fus tout seul sur ce projet et que ce logiciel ne répond à aucune demande précise, il nécessite sans doute quelques améliorations pour paraître vraiment abouti. Smart Terminus est un prototype destiné à l’apprentissage des technologies liées aux carte à puce. Il a permis d’introduire un savoir-faire dans l’entreprise, et son but n’était pas de répondre à des contraintes industrielles de qualité.




III.2.a/Explication des fichiers de Smart Terminus



Le logiciel se compose d’un fichier exécutable  ‘terminus.exe’ et de plusieurs fichiers de ressource de la forme *.ini ou *.pdu . Les fichiers ressources ne sont pas nécessaires à l’exécution de l’application mais permettent de travailler plus efficacement : ils contiennent notamment des données spécifiques à chaque type de carte asynchrone. Ce sont des fichiers ASCII, qui peuvent donc s’éditer avec la plupart des logiciels de traitement de texte. Pour les gérer je me suis servi de l’API de Windows qui gère les fichiers d’initialisation *.ini, par l’intermédiaire de l’objet ‘TiniFile’ de C++ Builder.



  1. CLA qui indique l’octet de classe en hexadécimal, par défaut CLA=00.

  2. lbCLA qui peut indiquer un commentaire sous l’octet CLA, par défaut lbCLA=Octet de classe.

  3. INS qui indique l’octet de commande en hexadécimal, par défaut INS=00.

  4. lbINS qui peut indiquer un commentaire sous l’octet INS, par défaut lbINS=Octet de commande.

  5. P1 qui indique le 1er octet de paramètre en hexadécimal, par défaut P1=00.

  6. lbP1 qui peut indiquer un commentaire sous l’octet P1, par défaut lbP1=1er octet de paramètre.

  7. P2 qui indique le 2ème octet de paramètre en hexadécimal, par défaut P2=00.

  8. lbP2 qui peut indiquer un commentaire sous l’octet P2, par défaut lbP2=2ème octet de paramètre.

  9. P3 qui indique l’octet de longueur en décimal, par défaut P3=0.

  10. DataIO qui indique si le terminal doit envoyer (DataIO=1) ou attendre (DataIO=0) des données, par défaut : DataIO=1.

  11. Data qui peut indiquer en hexadécimal les données à envoyer quand DataIO=1.


Voici un exemple de commande stockée dans un fichier *.pdu, et crée à partir de l’ISO 7816-4 :

[select root]

INS=A4

lbINS=Sélection de fichier

P1=00

lbP1=Contrôle de la sélection

P2=00

lbP2=Options de la sélection

DataIO=1

P3=2

Data=3F 00




Voici un exemple d’une section de ce fichier :


[22 09 69 90 00]

name=carte VITALE

use=carte d'assurance maladie




[select root]

0=00 A4 00 00 02

1=3F 00




[iso7816-4.pdu]

FID root=3F 00

code1=31 32 33 34 35 36 37 38






III.2.b/ Utilisation du logiciel



Lançons maintenant l’exécution du fichier Terminus.exe : il apparaît une fenêtre dotée de 5 onglets : 



Le dessin à gauche indique la position des contacts sur la puce, conformément à la norme ISO 7816-2. Elle peut aussi indiquer, par changement de couleur, le niveau de tension sur le contact Power ou le Reset. A côté se trouve le bouton « Obtenir et traduire L’ATR » qui permet de reseter et d’identifier la carte. En dessous se trouve une zone de texte qui correspond au résultat des diverses fonctions appelées. A droite se trouve la boîte de texte « Protocole de la carte » qui sert à indiquer les informations sur le type de communication que supporte la carte, enfin à droite de cette boîte se trouvent 2 zones de texte qui servent à indiquer quel type de carte est dans le lecteur (si cette dernière a déjà été identifiée dans le fichier hist_bytes_atr.ini).


Les 2 lignes de texte côte à côte tout en bas de l’application indiquent la signification des octets SW1 et SW2 suivant la norme ISO 7816-4. Et pour finir il y a une barre de progression qui indique la progression des différentes fonctions de scan.




Le bouton Valider permet au logiciel d’ouvrir le port série, avec les paramètres disponibles dans la boîte Communication série.

Le bouton Initialiser carte asynchrone règle les paramètres de la communication série afin de pouvoir Lire l’ATR.

La boîte Communication série est divisée en 2 sous-boîtes car les paramètres de la première boîte ne peuvent être changés après ouverture du port série, alors que ceux de la deuxième partie ne dépendent pas de l’état du port série.


Donc pour utiliser Smart Terminus afin de lire des cartes asynchrones il faut d’abord cliquer sur le bouton Initialiser carte asynchrone avant de Valider. A noter que pour certaines cartes qui demandent après l’ATR un débit différent de 9600 bauds ou bien 1 seul bit de stop, on doit alors fermer le port pour le re-paramétrer avant de le ré-ouvrir.



Si le port s’est ouvert correctement nous devons voir apparaître la fenêtre suivante :


Les 5 premières boîtes juxtaposées en haut à gauche permettent de sélectionner les valeurs des octets CLA, INS, P1, P2 et P3. Les valeurs doivent être écrites en hexadécimal, à l’exception de P3 qui accepte aussi l’écriture décimale. Dans la boîte de P3 nous avons 2 boutons radios qui permettent au logiciel de savoir si les octets au nombre spécifié par P3 doivent être attendus ou bien émis :


Le bouton Go (1) permet de procéder à l’échange TPDU.


En dessous se trouvent 2 listes déroulantes (2) : la première sert à sectionner un fichier *.pdu dans lequel sont stockées les commandes accessibles par la deuxième liste.


Entre les boîtes « Données entrantes » et « Données sortantes » se trouvent une liste déroulante et un bouton (3). Ils permettent de mémoriser les données entrantes ou sortantes suivant les boutons radios de P3, et de rappeler ces données en données entrantes à tout moment. Ces données sont stockées dans le fichier Data.ini. A noter que ces données sont spécifiques à un seul fichier *.pdu : lorsque que l’on change de fichier de commande *.pdu , la liste des données enregistrées change également.


Enfin se trouve la boîte Scan (4) qui permet de tester les commandes TPDU que supporte la carte. Cela peut être utile quand on a perdu la notice d’une carte. Attention toutefois à ne pas bloquer cependant la carte, car en testant diverses commandes TPDU, des commandes bloquantes peuvent être émises à la carte.






Elle permet de gérer des séquence de trames à émettre, l’utilisation de cette rubrique est assez intuitive. Les séquences disponibles dans la liste déroulante sont celles stockées dans le fichier Sequences.ini. On peut d’ailleurs les supprimer ou en enregistrer de nouvelles depuis Smart Terminus.






Les 2 premières boîtes juxtaposées permettent de gérer les états des 5 lignes de contrôle du port série.


La boîte en-dessous permet de crypter/décrypter des messages en utilisant l’algorithme DES (Data Encryption Standard) et triple-DES. Comme cet algorithme réalise une bijection de 8 octets sur 8 octets, Smart Terminus rajoute automatiquement des espaces ( 0x20 en code ASCII) afin que le message à crypter soit un multiple de 8.


Enfin la dernière boîte permet de scanner les fichiers accessibles par leur FID depuis un répertoire ou un fichier spécifique. L’octet de classe qui est pris en compte pour les échanges TPDU est celui spécifié à la rubrique TPDU… . Ce scan, qui sert surtout à déterminer le mapping d’une carte quelconque, est extrêmement long puisque qu’il peut réaliser jusqu’à 65 536 échanges TPDU soit plus de 650 000 caractères non consécutifs.






Elle permet de visualiser les échanges entre la carte et le terminal, les échanges sous contrôle comme ceux effectués lors d’un scan ou bien d’un échange TPDU ne sont affichés que si l’onglet spécifique de la rubrique « Bonjour » est validé.



Maintenant que nous savons communiquer avec des cartes asynchrones avec Smart Terminus, voyons une application possible de porte-monnaie électronique sur la Payflex.





IV/ Solutions de porte-monnaie électronique avec la Payflex de Schlumberger.



IV.1/ Description de la Payflex.



La Payflex de Schlumberger est une carte asynchrone, qui dialogue avec le protocole par octet T=0 à 9600 bits/sec. Elle possède les spécificités suivantes :




IV.2/ Architecture usuelle.




Voici un exemple de mapping mis en place sur une Payflex afin d’utiliser de façon sécurisée un porte-monnaie électronique. Les fichiers existants après l’encartage de la puce par Schlumberger sont grisés.





Signification des abréviations utilisées :




Type de fichier FT

(valeur en hexadécimal)

Opérations indiquées par les conditions d’accès AC

1er octet

2nd octet

38 : répertoire (DF)

RFU

créer fichier

RFU

RFU

01 : fichier binaire

Lire

mettre à jour

RFU

bloquer mises à jour

02 : fichier linéaire

lire enregistrement

mettre à jour enreg_t

initialiser enreg_t

RFU

06 : fichier cyclique

lire enregistrement

mettre à jour enreg_t

RFU

RFU

12 : clés de calcul

lire enregistrement

RFU

initialiser enreg_t

RFU

22 : code PIN

lire enregistrement

RFU

initialiser enreg_t

débloquer

32 : clés de vérification

lire enregistrement

RFU

initialiser enreg_t

débloquer

1E : porte-monnaie

lire enregistrement

modifier la quant max

débiter

créditer


Les fichiers de type 12, 22 et 32 possèdent une structure de fichier linéaire avec des enregistrements fixes de 10 octets, dont 8 octets qui contiennent la valeur d’une clef. Le fichier porte-monnaie possède une structure de fichier cyclique avec au moins deux enregistrements de 6 octets : 2 octets pour le numéro de transaction et 4 pour la valeur contenue dans le porte-monnaie.


Valeur en hexadécimal

Signification la valeur de la condition d’accès AC

0

L’opération ne nécessite aucune authentification préalable

1

L’opération nécessite l’authentification par un code PIN

2

L’opération nécessite l’authentification par une clé de vérification

3

L’opération nécessite les deux authentifications précédentes

F

L’opération n’est pas permise


Si on prend, par exemple, le cas du fichier « porte-monnaie » avec AC=02 01. La première valeur 0 indique que l’on peut donc en lire le contenu avec la commande READ_RECORD (INS=B2) sans aucune opération préalable. Tandis qu’il faudra exécuter une commande VERIFY ou bien une commande EXTERNAL_AUTHENTICATION (qui permet de sécuriser le câble de transmission en cryptant la clé de vérification) avant de mettre à jour le maximum autorisé avec la commande UPDATE_MAX_AMOUNT.


Cependant il ne faut pas croire que AC=0 pour l’opération débiter signifie que le débit n’est pas sécurisé : cela signifie juste que l’on a pas à faire d’opération d’authentification par PIN ou par clé de vérification au préalable. En effet les fonctions DEBIT et CREDIT sont elles-même protégées par l’utilisation obligatoire d’un cryptogramme spécifique dans les données DATA qu’elles comportent.


Le fichier contenant les clés de calcul sert justement à stocker les clés de cryptage et de décryptage.



IV.3/ Description d’échanges réalisés lors d’une opération.


Ces échanges sont réalisées avec une carte SAM, qui est une Payflex dotée de plus de mémoire et dont le système d’exploitation est doté de plusieurs fonctions supplémentaires. La carte SAM est souvent placée à l’intérieur de chaque terminal. Elle permet de sécuriser au mieux la transaction puisque les données qu’elle contient sont quasiment inaccessibles directement, contrairement à un terminal sur lequel on peut plus facilement accéder au circuit électronique pour en lire les mémoires.


La carte SAM contiendra au moins 2 types de données :

Ainsi lorsque la Payflex d’un utilisateur sera débitée, la SAM du terminal sera créditée, et ensuite l’opération sera validée. Et lorsque la Payflex utilisateur sera créditée la SAM sera juste auparavant débitée.


Pour débiter le porte-monnaie de l’utilisateur le terminal doit donc lui envoyer en paramètre le SAM Debit Certificat calculé à partir d’une chaîne d’octet aléatoire (Challenge), du numéro de transaction, de la quantité d’argent, du numéro de série de la carte utilisateur et de la clé Master_Debit_Key stockée uniquement à l’intérieur de la SAM.

Le cryptogramme n’est donc jamais deux fois le même, et pour le reproduire il faut surtout la clé Master_Debit_Key, stockée dans une zone inaccessible de la SAM, sur laquelle repose finalement toute la sécurité de cette opération. La payflex utilisateur ne possède pas la Master_Debit_Key mais la Debit_Verification_Key qui doit être directement le résultat du DES effectué avec la Master_Debit_Key et le numéro de série de la carte. Cette Debit_Verification_Key doit aussi être inaccessible car sinon on pourrait retrouver la Master_Debit_Key en effectuant le DES-1 avec le numéro de série de la carte qui est quant à lui accessible.


Cette transaction est donc extrêmement sécurisée. Si les cartes ont bien été personnalisées par le développeur de l’application, il n’existe alors aucun moyen informatique permettant de faire des opérations sans connaître les clés contenues à l’intérieur des cartes.

Les seules solutions qui restent alors au malfrat potentiel sont d’attaquer la puce au microscope électronique ou bien d’agresser l’ingénieur qui pourrait savoir comment retrouver les clés (qui doivent être détruites après la personnalisation), ou bien encore d’agresser la vieille dame qui fait ses courses avec son porte-monnaie électronique…



IV.4/ Fonctionnalités pouvant être modifiées suivant les besoins.


Pour réduire les frais on pourrait tout d’abord se passer des cartes SAM, mais les clés permettant de crypter les données qui passent par le câble de transmission sont alors moins protégées puisqu’en mémoire sur le terminal. D’autre part il faudrait savoir exactement comment fonctionne le DES implémenté sur les Payflex, et savoir aussi exactement comment les SAM calculent les certificats de débit et de crédit.

Pour ma part je n’ai pas eu accès à ces détails, et je n’ai donc pas pu simuler une carte SAM depuis l’ordinateur. J’avais implémenté dans le logiciel Smart Terminus le DES qui existe partout sur Internet mais celui utilisé par la Payflex que j’ai essayé avec la commande INTERNAL_AUTHENTICATION ne correspondait visiblement pas.


Ensuite on peut rajouter sur les cartes des fichiers cycliques contenant par exemple le journal des numéros de terminaux où le client a utilisé sa carte…

Si la carte doit servir sur un campus on pourrait aussi y stocker des bulletins de notes…


Bref, comme la Payflex permet de stocker jusqu'à 4 kilo-octets (sur certains modèles) de données de façon sécurisé, on peut lui trouver une infinité d’application en plus du porte-monnaie électronique.



Conclusion



Le projet qui m'a été confié m'a particulièrement intéressé et je pense qu'il m’a été très formateur. Ce dernier m'a permis d'aborder plusieurs domaines en relation avec la formation qui m'a été dispensée à l’Institut Supérieur d’Electronique de la Méditerranée.


En effet je me suis servi de compétences en électronique-informatique acquises en grande partie dans mon école d’ingénieur. J’ai du aussi m’adapter aux technologies de l’entreprise et à des documentations techniques telles que les normes ISO, dont le contenu est très dense et souvent peu clair.


J’ai une certaine satisfaction du stage que j’ai effectué. J’ai bien assimilé les documentations techniques mises à ma disposition, et j’ai réalisé un lecteur et un logiciel de gestion des cartes asynchrones utilisable avec une grande partie des cartes à puces existantes actuellement. J’ai aussi bien compris le fonctionnement de la carte Payflex de Schlumberger, et je suis désormais à même de réaliser des solutions spécifiques utilisant tous les avantages de cette carte.


Mais le développement de solutions utilisant des cartes à puce peut parfois devenir très complexe et la criticité de leur utilisation très importante. Pour réaliser des solutions vraiment performantes et sans failles, il vaut donc mieux y travailler en équipe, avec un maximum de concertation, et ne pas avoir peur de remettre en question des systèmes autour de l’utilisation de la carte à puce. Ce sont les meilleurs façons d’éviter les erreurs rencontrées dans le passé, notamment à propos de la carte bleue avec l’affaire « Serge Humpich » : cet homme avait honnêtement dénoncé des failles énormes dans les cartes bancaires, et, depuis son arrestation qui a provoqué la divulgation massive de ses découvertes, les fraudes autour des systèmes de paiement électroniques ont atteint des proportions alarmantes bien que les chiffres exacts soient dissimulés par les banques.


De plus, cette période en entreprise m'a permis de connaître réellement le monde de l’entreprise, et l’importance du statut des gens qui y travaillent. Je pense être plus apte à intégrer le monde du travail de par mes connaissances et mon savoir-faire, et avoir acquis une plus grande maturité.




Glossaire




API (Application Programming Interface)

Une API est en quelque sorte une DLL qui propose des fonctions ou routine particulières à un logiciel. Exemple: Direct X est une API, il est chargé de faire le lien entre les jeux et les drivers de cartes 3D, drivers de cartes son et les drivers de périphériques de jeu (joystick...). Les fabriquant de cartes 3D s'efforcent d'optimiser leur drivers pour que la carte fonctionne le mieux possible sur DirectX tandis que de leur côté, les éditeurs programme leur jeu en utilisant DirectX. Cette standardisation permet d'éviter aux fabriquant de la carte 3D d'optimiser le produit pour chaque jeu.




ASCII (American Standard Code for Information Interchange)

C’est une norme de codage sur un octet, qui contient les chiffres, les caractères de A à Z en majuscule et en minuscule, plus les signes de ponctuation et les caractères accentués. On parle de contenu ASCII pour un texte sans enrichissement typographique, et sans graphiques.



Convention directe

Convention de codage des octets, référencée dans l’ISO 1177, pour laquelle un 0 est représenté par un état bas, un 1 par un état haut, et l’ordre d’arrivé des bits se fait du plus petit (lower significant bit) au plus grand (most significant bit).

Le signal ci-dessous se lit 3B H en convention directe.

Signal

Cadre1

Temps



Convention inverse

Convention de codage des octets, référencée dans l’ISO 1177, pour laquelle un 1 est représenté par un état bas, un 0 par un état haut, et l’ordre d’arrivé des bits se fait du plus grand (most significant bit) au plus petit (lower significant bit).

Le signal ci-dessous se lit 3F H en convention inverse.

Signal

Cadre2

Temps


Criticité

La criticité est le produit mathématique de l'évaluation de l'Occurrence et de la Sévérité (cf. systèmes de qualité ISO 9000 et 9001). Criticité = (S) × (O). Ce nombre est employé en priorité pour des éléments nécessitant un niveau de qualité supérieur.



Débit (Anglais : Bit rate )

Nombre de bits transmis pendant un intervalle de temps rapporté à la durée de cet intervalle. Un débit binaire s'exprime en bit/sec ou en bauds : les bauds sont en général employées quand la voie de transmission est analogique, un baud équivaut alors 1, 2, 4, ou 8 bit/sec. Dans la communication série utilisant le port COM, 1 baud est égal à 1 bit/sec.



DLL = Dynamic Library Link (Bibliothèque de lien dynamique).

Ce sont des bibliothèques de code compilé mais pas sous forme d'un exécutable.



Embarqué

Terme employé pour désigner un processeur utilisé pour une application spécifique, dans un système qui est invisible pour l’utilisateur. Très souvent, un processeur embarqué est un micro contrôleur qui a des capacités significatives en entrée/sortie, tels que les ports parallèles, séries ou USB, des interfaces mémoires pré-codées… Les processeurs embarqués sont définis par leurs applications, plutôt que par le design même du processeur. N’importe quel type de processeur peut être embarqué.



Myfare
Carte Myfare : carte à puce sans contact, issue de la norme ISO 14443 internationale.



RFU (Reserved for Future Use)

Terme souvent utilisé pour désigner quelque chose présent dans un système mais qui ne possède pas, ou pas encore, d’utilité.



Solvance

Logiciel principal d’ARD destiné principalement à l’organisation complète d’établissement scolaires à tous les niveaux : restauration, contrôle d’accès, gestion des absences, avis aux familles, gestion du CDI, monétique, réservation de repas, casiers, cafétéria… Solvance fonctionne en mono poste ou client/serveur, et peut être multi-utilisateur, avec différents degrés d’accès. Le serveur contrôle une unité de gestion (UG) qui commande les terminaux à chaque point important de l’établissement (portails, portes, tourniquet au self, distributeurs de plateaux pour les repas, photocopieur…)

Ce système gère les autorisations d’accès (parking, bâtiments…). Solvance a été développé sous Windows 9x/2k en Delphi et C++ (inline). La partie de la gestion embarquée est développée en assembleur et en C.





Liens utiles



http://sudriabotik.free.fr/fichiers/serie.htm et

http://membres.lycos.fr/quacky/portserie.htm : rappellent le fonctionnement et le brochage des ports séries sur PC.



http://cryptage.online.fr/html/divers/plan.html : Contient des informations concises sur la cryptologie. Décrit notamment le fonctionnement de plusieurs algorithmes tels que le DES ou le RSA. Dommage que ce site soit mal conçu car son contenu est vraiment excellent.



http://home.ecn.ab.ca/~jsavard/crypto/jscrypt.htm : Contient quasiment tout ce qu’il faut savoir sur la cryptologie. Cite notamment les variations possibles du DES.



http://www.openssl.org : Librairie de cryptage/décryptage open source compatible avec les plus gros standards actuels en matière de cryptologie. Il s'agit d'une des librairies de sécurisation par la cryptographie les plus réputées, sécurisées et utilisées. Elle gère des algorithmes comme les DES, RSA, DSA, TLS...



http://web.iie.cnam.fr/~a3ie/public/mag/numero3/dossier.html : Dossier réalisé par un thésard sur la sécurisation d'un système informatique distribué. Très intéressant pour se faire une idée sur les problèmes de sécurité informatique. Parle notamment des cartes à puces.



http://www.parodie.com : « Portail de la parodie et de la critique », contient des pages réalisées par des amis de Serge Humpich et qui révèlent les failles actuellement connues et reconnues des cartes bancaires.



http://www.schlumberger.com : Site officiel de la société Schlumberger.