pc et carte a puce

Bienvenu dans notre page officielle pour les

ingénieurs et les futurs ingénieurs. le rôle de cette

page est de vous offrir les livres scientifiques dans

tous les domaines

Visiter notre site : http://ingenieurs-books.blogspot.com

Visiter notre page : https://www.facebook.com/ingenieurs.ebooks

http://ingenieurs-books.blogspot.com/

https://www.facebook.com/ingenieurs.ebooks

PC ET CARTES A PUCE

PATRICK GUEULLE Ingénieur EFREI

PC ET

CARTES A PUCE

Les schémas el logiciels regroupés dans cet ouvrage el sa disquette d'accompagnement ne doivent être utilisés qu'à des fins expérimentales ou personnelles, à l'exclusion de toute exploitation commerciale ou industrielle.

Pour toute demande de licence des brevets INNOVATRON ou BULL CP8, il conviendrait de s'adresser à leurs titulaires respectits.

© Dunod, Paris, 2008

TABLE DES MATIERES

Avant-propos 7

X t e s microprocesseurs des cartes à puce 9

Microprocesseurs, microcalculateurs ou microcontrôleurs 10

Exemples de ressources matérielles 10

Exemples de ressources logicielles 14

Exemples de ressources sécuritaires 17

Quelques notions de cryptographie 19

La notion de masque 23

Les masques BULL CP8 24

Les masques COS 30

2 À la découverte de la carte bancaire , 3 7

Une variante du masque BULL CP8 M4 38

Un lecteur de cartes à microprocesseur 39

Le bon usage du code confidentiel 47

Contrôlez vos relevés de compte 49

Une « boite à outils >• pour carte bancaire 50

Comment lire les pistes magnétiques i>8

Pour aller plus loin... 60

3 Un mini système de développement 73

Un adaptateur RS232 pour carte asynchrone 74

Un petit analyseur de protocole 78

Un petit simulateur de carte 82

Une carte à puce expérimentale à PIC16CXX 88

4 Les télécartes ou cartes synchrones 107

Un mini-lecteur ISO/AFNOR 108

Reconnaissance logicielle des types de puces 117

Télécartes et protection de logiciels 121

La T2G ou télécarte de seconde génération 124

Les cartes « Européennes » 134

La disquette du livre 141

Organisation de la disquette 142

Installation de la disquette 148

Mode d'emploi de cartes.exe 149

6

P C E T C A R T E S A P U C E

AVANT-PROPOS

Quand nous avons attaqué, en 1992, la rédaction de notre

ouvrage Cartes à puce. Initiation et applications, nous étions

loin de nous douter que nos innocentes expériences de lec

ture et d'écriture dans des télécartes vides allaient nous

conduire, trois ans plus tard, à percer les secrets des véri

tables « forteresses électroniques >` que sont les cartes à

microprocesseur et les nouvelles télécartes à mémoire réins-

! riptibk .

Cela avec l'aimable complicité des fabricants et émetteurs

de cartes eux-mêmes, dont la confiance est totale dans l'effi

cacité des mécanismes de protection de leurs applications.

Nous pouvons donc aujourd'hui montrer sans inconvénient

à nos lecteurs comment transformer leur PC en un puissant

outil d'exploration et même de simulation des cartes à puce

les plus diverses.

Quelques montages électroniques fort simples et une disquette de logiciels très particuliers constituent tout le nécessaire pour aller vers de passionnantes découvertes. Bon voyage dans le monde fascinant des cartes à puce !


I LES MICROPROCESSEURS DES CARTES À PUCE Microprocesseurs, microcalculateurs ou microcontrôleurs 10

Exemples de ressources matérielles 10

Exemples de ressources logicielles 14

Exemples de ressources sécuritaires 17

Quelques notions de cryptographie 19

La notion de masque 23

Les masques BULL CP8 24

Les masques COS 30

A la découverte de z la carte bancaire 37

a Un mini système de *j développement 73

4 Les télécartes ou caries synchrones ll)7

5 La disquette du livre 141

9


M I C R O P R O C E S S E U R S , M I C R O C A L C U L A T E U R S ,

O U M I C R O C O N T R O L E U R S ?

C'est en 1981, autrement dit deux arts avant la mise en cir-

`; culation des premières télécartes à puce, qu'est née chez

BULL la première carte à microcalculateur monochip.

11 s'agissait à l'époque d'une grande première, réussie grâce

à la collaboration de Motorola, car depuis les premiers pro

totypes produits des 1974 pour Roland Moreno, l'habitude

avait été prise d'associer au moins deux puces distinctes (le

microprocesseur et de la mémoire).

Entre temps, CM Honeywell-Bull prenait en 1976 la licence

des brevets Innovation et adoptait le terme de carte a micro-

calculateur pour désigner les produits qui, de nos jours,

constituent la galaxie CP8.

Même si les concurrents de BULL CP8 parlent plus volon

tiers de cartes è microprocesseur, on nous permettra d'estimer

; que le terme le plus approprié serait cartes à microcontrôleur.

En effet, l'architecture des actuelles puces de cartes réunit une unité centrale 8 bits, de la mémoire ROM, RAM, LPROM et/ou El.TKOM, et des ports d'entrée-sortie, exactement comme tout microcontrôleur qui se respecte.

Simplement, la tendance actuelle est d'y ajouter de plus en

plus de ressources dites sécuritaires, toujours sur une

même puce, et c'est là que pourrait bien se jouer la partie...

E X E M P L E S D E R E S S O U R C E S M A T É R I E L L E S

Si le marché des microcontrôleurs à encarter demeure assez

nettement dominé par Motorola, la concurrence est désor

mais très vive entre un nombre croissant de fabricants,

conscients de l'enjeu qu'il représente : on commence en

effet à produire des carres en quantités astronomiques !

SCS-Thomson est particulièrement bien placé, avec des produits

basés sur un cœur compatible avec les processeurs Motorola

mais bénéficiant de solutions sécuritaires fort originales.

Philips est de plus en plus présent à partir de son architecture 8051, avec des apports décisifs sur le plan des possibilités de calcul cryptographique.

10

L E S M I C R O P R O C E S S E U R S D E S C A R T E S A P U C E

Texas Instruments, concurrent direct de SCS-Thomson sur

le marché des puces pour télécartes, propose pour sa part

une gamme de microprocesseurs encartables dérivés de sa

famille TM537O.

Et naturellement, les japonais s'intéressent de près à la question, à commencer par OKI avec ses produits OSCAK.

11 est intéressant de comparer sommairement ce que

contiennent les microcontrôleurs de différentes marques,

couramment rencontrés dans les cartes à puce.

La figure 1.1 reproduit ainsi le schéma synoptique commun

à toutes les références de Motorola, basées sur un très clas

sique cœur 68HCO5.

La version SC24 (3K ROM, 1K EEPROM, 128 octets RAM}

équipe notamment les cartes bancaires françaises.

Figure 1.1.

Architecture des

M68HCO5SC de

Motorola.


La figure 1.2 dévoile pour sa part l'architecture des puces

ST16XYZ, cheval de bataille de SGS-Thomson associant une

unité centrale compatible 6805 à im ensemble de fonctions

sécuritaires aussi bien matérielles que logicielles : logique

de sécurité munie de capteurs détectant les tentatives

d'accès frauduleux à la puce, ROM à bus d'adresses brouillé,

système de masquage des variations de courant d'alimenta

tion en fonction du contenu de la mémoire, matrice d'accès

limitant les possibilités d'accès illicites à la mémoire, etc.

Notons que la version S" (vi()l fj équipe, en cartes bancaires françaises.

!, les

La figure 1.3 concerne un processeur particulièrement inno

vant de chez Philips, le 83C852. Son unité centrale de type

8051 est secondé par une unité de calcul spécialisée, véritable

coprocesseur rapide dédié aux opérations très particulières

nécessaires aux chiffrements de données. Le tout, bien

entendu, sur une seule et même puce.

- 12 -

Figure 1.2.

Architecture des

ST16XYZ

SGS-Thomson.

L E S M I C R O P R O C E S S E U R S D E S C A R T E S A P U C E X

Enfin, la figure 1.4 révèle l'organisation interne d'une puce Figure 1.3.

fort classique sinon très nouvelle, de Texas Instruments : le Architecture du

TMS373C007. 83C852 de Philips.

C'est une version plus récente (TMS373C012) qui équipe

certaines séries de cartes bancaires françaises.

On constate que, d'une marque à l'autre, la structure de

base ne varie guère. Pratiquement tous les composants dis

posent, par exemple, de deux lignes d'entrée-sortie série

alors que dans l'état actuel des choses on n'en utilise

presque toujours qu'une seule (half-duplex).

Souvent modulables au gré du client, les capacités mémoire

butent pour tout le monde sur les mêmes limites technolo

giques imposées par la surface de silicium pouvant être

commodément et économiquement logée dans une carte

(environ 4 x 6 mm), même si le recours à des filières submi-

croniques risque d'améliorer la situation à plus ou moins

court terme.

Reste qu'on peut déjà loger beaucoup de choses dans 8 Ko

d'EEPROM (réinscriptible) ou d'EPROM (consommable


SW, sans possibilité de recyclage), et que 16 Ko de ROM peu-

j i j vent héberger le code d'un système d'exploitation plus que

performant.

Figure 1.4.

Architecture du

TMS373OM7.

E X E M P L E S D E R E S S O U R C E S L O G I C I E L L E S

Toutes les puces de cartes à microcalculateur dérivent plus

ou moins directement de telle ou telle famille classique de

microprocesseurs' ou de microcontrôleurs.

Elles en héritent la majeure partie de leur jeu d'instructions,

même s'il est habituel de l'amputer de quelques fonctions

présentant peu d'utilité dans le contexte bien spécifique des

cartes à puce, quitte à introduire en remplacement des ins-

[ tructions plus spéciales.

Texas Instruments a ainsi inventé une instruction NOPV

(NOP à longueur variable, très utile pour réaliser des tem

porisations) et une instruction de déplacement de bit,

MOVB.

; Nous reproduisons à la figure 1.5 le jeu d'instructions com-

is plet le plus répandu dans le monde des cartes à micropro

cesseur, puisque sensiblement commun aux puces SGS-

Thomson et Motorola.

En principe, les manipulations courantes sur les cartes à

microprocesseur ne nécessitent pas (et même ne permettent

14


Figure 1.5.

Le jeu destructions

des ST16XYZ.

Register/Memory and Absolute Jump Croup

Function Mnemonic Addressing Mode

Function Mnemonic Immediate DNS Extended offset

Index 8 bit offset

Index 16 bit offset

Load A with memory LDA 2 A6 3 , B6 3 3 C6' 1 F6 3 2 E6* , D6C

Load X with memory LDX I AE ' !.(! • ,CE- , FE 3 ! EE 1 :. DE'

Load memory with A STA dC7 4 , F7 3 2 E7' 3 D7*

Load memory with X STX • BF • 3 CF * , FF 3 ! EF * oDF s

Add memory to A ADD ! AB 1 1 B ' 3 C B ' , FB 1 i EB* a DB s

Add memory and carry to A ADC ? A9 ( , 9S « s C9 • 1 F9 J

3 E9 * i D9"

Subtract memory to A SUB 2 AO 1 , BO 3 -, CO " , FO 3 ; EO* • DO 5

Subtract memory with carry SBC •1. A2 ' • • 3 C 2 * 1 F2 3 2 E2 ' 3 D 2 S

And memory to A AND ? A 4 ! , B4 3 aC4' 1 F4 a 2 E4« 3 D4 !

Or memory with A ORA • AA - j C A ' 1 FA 3 ! EA* 3 DA6

Exclusive OR EOR 2 A8 3 Bt a C B ' i F8 3 2 E8 1

3 D 8 "

Arithmetic Compare A CMP 2 A1 « , B1 3

3 C1 < , Fl 3 .. El ` 3 D1 5

Arithmetic Compare X CPX ; A3 ; 2 B3 3 aC3' , F3 a . E3 H

3 D 3 '

Bit compare A and memory BIT i B5 :

3 C 5 * I F5° ) E5 4

3 D5°

Absolute Jump JMP ; BC 1 •jCC3 i F C j EG ! 3 DC"

Jump to subroutine JSR 1 BIJ • s CD 8 , FD 6 2 ED 8 sOD '

Bit manipulation and test Group


Bit Set BSETb{b=0..7) i (10-r 2"b) B

Bit claai BCLRb(b--iD.7l s ( l l + 2 b ) 3

Test bit b and branch if true 8RSET b <b=Q..7) 3 (00 + 21» 1

Test bit and branch if false BRCLR b (0=0.7) a (01 + 2*b ) '

Read Modify/Write Group

Function Mnemonic Addiessing Mode

Function Mnemonic Inherent A Inherent X Direct Index B

bil offset

Increment INC. , 4C ! , 5C* , L«; , 7C S ; 6C*

Decremenl DEC , 4A ' , 5A 3 , 3A ' i 7A 1 26A"

Clear CLR ,4F 1 , GF ' , 3F 5 , 7F s , 6F"

Ones Complement COM , 43 » , 53 1 . 33 5 , 73 6 2 63 s

Negate (2'!! complement) NEG i 40 • , 50 • , 30 • , 70 s 2 6 0 s

Rnlale Left thru carry ROL , 4ft 2 , 59 ' : :'S , 69 0

Rotate Riqhl thru carry ROR , 46 2 i 56 3 ,• 3i! ' , 76 ' , 66 1

Logical shift left into Carry LSL , 48 2 i 58 ' , 38 ! i 78 s 2 68 a

Logical shift righ into Carry LSR , 44 ' , 54 * 1 34 : i 74 B 2 64 "

Arithmetic shift right into Carry ASR i 47 3 , 57 - , 37 5 , 77 s 2 67 »

Test for Negative or Zero TST , 4D' , 5D • .30 1 , 7D 3 2 6D"

1 5


Figure 1.5.

Le jeu d'instructions

desS 6XYZ.

Branch Group


Function Mnemonic RELATIVE

Hranch Always BF\A 2 20 3

Branch Never BRN , 21 3

Branch it Higher BHI 2 22 3

Branch if Unsigned Lower or Same BLS 2 23 3

Branch if Carry Clear BCC • 24 1

liianch it Unsigned Higher or Same BHB i 24 3

Branch if Carry Sot rscs 2 25 « Branch if Unsigned Lower Vian BLCJ

3 25 • Branch if Not Equal BNE ! 26 3

Branch if Eoual BEQ , 27 >

Branch if Half Carry Clear BHCC 2 28 ' Branch if Not Half Carry Set BHCS I 2 9 ' Branch if Plus BPL i 2A 5

Blanch if Minus BMI , 2B ' Branch if Not Interrupt Mask BMC *2C S

Branch if interrupt Mask BMS i 2D 3

Branch if Interrupt Line Low BIL ?2E> Branch if Interrupt Line High BUI , 2 F 5

Branch to Subroutine BSI1 i AD 1

Miscellaneous Group

Mnemonic Addressing Mode

Mnemonic INHERENT

Multiply [X:A=X* A) MUL 1 42 1 0

Transfer A to X TAX , 97 !

l ransfer X to A TXA 1 9F ' Transfer SP to A TSA • 9E ' Clear Carry Flag CLC ae Sel Carry Flag SEC 1 99 1

Clear Interrupt Mask bit CLI . QA> Set Interrupt Mask bit SEI 1R J

Reset Stack Pointer RSP , 9C 1

No ( )peratinn NOP , 90 !

Return from Interrupl RT1 • 80 • Return from Subroutine RTS , B1 ` Software Interrupt SWI , 83 ' Halt CPU/Enable INT WAIT , BF ' Ha* CPU/STOP C*x*s/Enabte INT SIOP . BE'


pas) la program mat ion directe de l'unité centrale, four des

raisons de confort d'exploitation (mais aussi de sécurité !)

le processeur est entièrement placé sous le contrôle d'un

système d'exploitation résidant en ROM.

Mais, exception qui confirme la règle, certaines cartes dites

COS possèdent une sorte de porte d'entrée permettant

d'implanter un peu de code personnel en EPROM ou en

EEPROM.

C'est là qu'une bonne connaissance du jeu d'instructions du processeur s'impose, et justement ces cartes sont souvent équipées d'un ST16CXYZ !

E X E M P L E S D E R E S S O U R C E S S É C U R I T A I R E S

Quelle que soit l'application envisagée, la vocation d'une

carte à puce peut toujours se ramener à un stockage de don

nées sous une forme plus ou moins protégée (ne parle-t-on

pas d'ailleurs de cartes fl mémoire ?)

La supériorité d'une carte à microprocesseur par rapport à

une simple carte à mémoire, même sécurisée, tient d'une

part dans son protocole de communication plus simple et

normalisé, et d'autre part dans la possibilité qu'elle a de

faire subir des traitements parfois complexes aux données

qu'elle reçoit ou qu'elle émet.

Grâce aux ressources de la cryptographie, une carte à micro

processeur peut en effet fort bien ne jamais répondre deux

fois de façon identique à une même sollicitation, du moins

si on utilise correctement les possibilités qu'offre son systè

me d'exploitation.

Un tel comportement complique singulièrement, c'est évi

dent, toute tentative de rejeu, c'est-à-dire d'interception,

puis de reproduction de la réponse de la carte.

Mais sans même aller jusque là, certaines données secrètes

présentes en mémoire ne doivent en aucun cas pouvoir sor

tir de la carte : seul le système d'exploitation doit pouvoir

y accéder, en tant qu'éléments de calculs dont il ne révélera

que le résultat.

Il en va ainsi, notamment, des codes confidentiels attribués à

l'utilisateur de la carte (code porteur) ou à son émetteur : pas


question de les lire comme sur une simple piste magnétique

pour les comparer, à l'extérieur de la carte, au code tapé sur

un clavier !

La procédure sécurisée consiste à présenter le code à la carte,

qui va le vérifier, par l'intermédiaire de son système

d'exploitation, de façon purement interne. Cette vérification

effectuée, la carte peut ou bien dire tout simplement (de

façon claire ou codée) si le code est bon ou faux, ou bien se

contenter d'autoriser l'accès à une zone de sa mémoire qui

était jusqu'à présent verrouillée.

C'est ce haut niveau de sécurité qui permet de se servir de

cartes ou de clefs à microprocesseur pour des applications

aussi sensibles que la monétique (carte bancaire, porte-mon

naie électronique, etc.), la téléphonie cellulaire (GSM), ou la

télévision à péage.

La figure 1.6 montre ainsi (selon SGS-THOMSON) com

ment sont construits les décodeurs de télévision compa

tibles avec les systèmes de crvptage les plus modernes.

Équipée d'une mémoire ELI'ROM au contenu modifiable

de multiples fois, la carte contient toutes les données

secrètes dont a besoin, avec celles reçues en même temps

que les émissions, le microprocesseur du décodeur pour

piloter son dési nibrouilteiir digital.

Figure 1.6.

Principe d'un CUBOC

- 1 8 -


Le contenu île la carte peut fort bien être modifié à distance par le diffuseur de programmes, au moyen de commandes incorporées dans le signa] vidéo, tandis qu'en cas de profonds changements dans le système, il est infiniment plus pratique d'envoyer de nouvelles cartes par courrier que de procéder à des échanges de décodeurs.

Il est d'ailleurs assez piquant de remarquer que les puces

utilisées pour cette application sont très sensiblement plus

puissantes que celles utilisées dans les cartes bancaires !

Q U E L Q U E S N O T I O N S D E C R Y P T O G R A P H I E

Le but de la cryptographie (science des messages secrets) est

I de permettre la transformation de données confidentielles

en un message totalement dénué de signification pour qui

conque parviendrait à s'en emparer.

On procède donc à un chiffrage des données à l'aide d'une clef, puis ultérieurement à un déchiffrage avec une clef qui peut être la même (algorithmes dits symétriques) ou une autre (algorithmes tis\imrt tjitts).

11 est bien évident que si la clef de déchiffrage est identique

à la clef de chiffrage, la protection de celle-ci pose les

mêmes problèmes que celle des données elles-mêmes.

En effet, on peut évidemment décrypter un message codé si

l'on connaît la clef et l'algorithme de codage, mais la chose

est également réputée possible quand, ignorant tout de

i l'algorithme, on dispose à la fois de la clef et d'échantillons

de messages en clair accompagnés de leur version codée.

L'un des procédés les plus simples de cryptage informa

tique consiste à effectuer un OU exclusif entre chaque octet

des données à crypter et chaque octet de la clef.

Le grand intérêt de la méthode est que le même algorithme,

appliqué avec la même clef, permet le décryptage.

Sous réserve d'une protection sans faille de la clef et qu'on

• n'utilise celle-ci qu'une seule et unique fois, même un pro

cédé aussi simpliste apporte une protection absolue à

condition que la longueur de la clef (son nombre d'octets)

soit au moins égale à celle du message à coder.


Si par contre une même clef de faible longueur sert à de

multiples reprises pour coder différents tronçons d'un mes

sage nettement plus long, alors toute la sûreté du cryptage

est compromise.

10 REM XOR.BAS

20 AS="(c)l995 Patrick GUEULLE"

30 FOR G=l TO LEN[A$)

40 D$=MID$(A$,G,l):D=ASC(D$t

50 R=D XOR 47

55 REM clef unique » 47

70 PRINT D$,R,

80 K=R XOR 47

100 PRINT CHRS(K)

110 NEXT G

120 END

Le petit programme XOR.BAS permet de se familiariser

avec cette méthode cryptographique élémentaire, et ce

dans les pires conditions : la clef est en effet constituée

d'un seul octet, ce qui veut dire qu'un même caractère sera

toujours représenté par un même nombre (cela revient à un

codage dit par substitution, analogue à ceux qu'utilisent les

scouts).

Par contre, on conviendra que si la longueur du message se

limite elle aussi à un octet, il est bel et bien impossible de se

passer de la clef pour le décoder.

Le problème des clefs a été résolu de façon très élégante par

le principe dit des algorithmes à clefs publiques.

Un tel système cryptographique utilise deux clefs distinctes :

une pour le codage, et une pour le décodage.

En général, la clef de codage est publique et celle de décoda

ge secrète : pour envoyer un message à un correspondant,

on lui demande sa clef publique (à la limite on la cherche

dans un annuaire spécial).

Même si les algorithmes de codage et de décodage sont eux

aussi publics, seul le possesseur de la clef secrète pourra

déchiffrer les messages chiffrés avec sa clef publique.

Mais le système peut fonctionner à l'envers : un message

crypté avec la clef secrète pourra être décrypté par n'impor

te quel possesseur de la clef publique correspondante, qui


aura ainsi une preuve formelle de l'origine du message (on

parle de signature électronique).

L'algorithme à clef publique le plus connu est le RSA

(Riivst Shamir Adleman), qui utilise les propriétés mathéma

tiques des exponentiations modulo N.

Sa mise en œuvre suppose que l'on choisisse deux nombres

premiers (;» et q) dont le produit {}>q) servira de modulo pour

les calculs de puissances à venir.

En termes simples, A puissance ft modulo N est tout bon

nement A multiplié H fois par A, moins autant de fois N

qu'il faut pour arriver à un résultat inférieur à N mais enco

re positif.

L'algorithme RSA repose sur le fait que :

<P - ' ^ - " . i m o d u l o p ,

à condition toutefois que I ne soit divisible ni par p, ni par q.

En pratique, cette condition est automatiquement remplie si

p et q sont supérieurs à x, ce qui est généralement le cas en

cryptographie (on travaille le plus souvent sur des nombres

de 512 bits !)

10 REM MODULO. BAS

20 KEY ÛFF:CLS

30 INPUT"donnée ? ",D

40 INPUT"exposant ? ",E

50 INPUT"modulo ? ",M

60 R=D

70 FOR F=l TO E-l

80 R=R*D

90 IF R<M THEN 110

100 R=R-M:GOTO 90

110 NEXT F

120 PRINT"RESULTAT: ";R

130 PRINT:GOTO 30

140 REM (c)1995 Patrick GUEULLE

Le petit programme MODULO.BAS est là pour permettre

quelques expérimentations avec des opérandes librement

choisis, et pour montrer le principe utilisé pour faire de

l'exponentiation modulaire en f>ASIC sans trop de risques

d'erreurs de dépassement (overflau>).


Les deux clefs RSA (clef publique e et clef secrète d ou vice

versa) doivent être choisies afin de répondre à la condition

suivante :

ed = lmodulo(p - 1 ) ( q - 1)

Moyennant quoi, on a :

x {modulo pq)

tandis que rien ne permet de déduire d de e ou inversement.

10 REM RSA. BAS

20 A$=*(cU995 Patrick GUEULLE"

30 FOR G=l TO LEN(A$)

40 D$=MID$(AS,G,l):D=ASCiD$)

50 E=l5:M=39l

55 REM clef publique = 15 , modulo = 391

60 GOSUB 130

70 PRINT D$,R,

80 E=47:M=39l

85 REM clef secrète = 47 , modulo = 391

90 D=R:GOSUB 130

100 PRINT CHR$(R)

110 NEXT G

120 END

130 R=D

140 FOR F = l TO E-l

150 R=R*D

160 IF R<M THEN 180

170 R=R-MrGOTO 160

1B0 NEXT F

190 RETURN

Le petit programme RSA.BAS applique cet algorithme dans

des conditions exactement comparables aux précédentes,

avec les clefs suivantes :

• clef publique : 15, modulo 391 ;

• clef secrète : 47, modulo 391 ;

extraites des nombres premiers p = 17 et .f = 23.

Bien entendu, la sûreté de l'opération n'est pas meilleure

que précédemment, puisque nous opérons toujours octet

par octet alors qu'il faudrait traiter des blocs de 512 bits.


Mais l'expérience a pour mérite de montrer à quel point les

calculs sont lents, même sur des blocs de huit bits : c'est la

raison pour laquelle on ne peut guère équiper des cartes à

puce en RSA qu'avec l'assistance de coprocesseurs spécia

lisés, en attendant d'hypothétiques cartes à puce à cœur

32 bits.

Le 83C852, par exemple, arrive à faire le calcul en une

seconde et demi, alors qu'il faudrait presque trois minutes

pour l'exécuter â l'aide du jeu d'instructions de base d'un

microprocesseur 8 bits...

Compte tenu de ce problème, la plupart des cartes à micro-

calculateur se contentent encore d'un algorithme symétrique

dont la clef (ultra-secrète) est physiquement présente dans

la carte, et doit par conséquent être sévèrement protégée.

Le plus courant est le DES {Data Encryption Standard) améri

cain qui opère sur des blocs de M bits, mais on peut aussi

citer le TELEI*ASS, algorithme développé par BULL CP8.

L A N O T I O N D E MASQUE

En micro-électronique, le terme de masque désigne couram

ment les clichés servant à réaliser les opérations de photoli

thographie nécessaires à la fabrication des circuits intégrés.

Dans le monde des cartes à puce, on appelle volontiers masque le logiciel du système d'exploitation qui, implanté en ROM, fixe le comportement des cartes à microprocesseur. É

Rien de plus logique, en fin de compte, puisque cette ROM

est de type mosquée, c'est-à-dire programmée lors de la

fabrication même des puces, précisément à l'aide d'un ou

plusieurs masques de photogravure spécifiques.

Dans l'immense majorité des cas, une puce de carte à

microprocesseur (et à plus forte raison une carte) sort de

chez son fabricant irréversiblement équipée de son système

d'exploitation. Pas question donc pour l'utilisateur d'y pro

grammer son propre code écrit en assembleur, sauf porte

d'entrée volontairement ouverte à cet effet et de toute façon

placée sous le contrôle du système d'exploitation (points

d'entrée, interruptions, etc.).

2 !


IC'est en partie pour cette raison que nous vous explique

rons, dans un prochain chapitre, comment fabriquer vous-

mêmes vos propres cartes à microcontrôleur, et comment

écrire votre mini système d'exploitation personnel.

L E S M A S Q U E S B U L L C P 8

La carte BULL CP8 la plus répandue est sans conteste la

M4, dont la version BO n'est autre que la carte bancaire

française à puce. Mais une nouvelle génération commence

déjà à prendre le relais sous la forme du nouveau masque

BO', propriété de la communauté bancaire. Nous y revien

drons au prochain chapitre !

À partir de ce produit de base, BULL CP8 a progressive

ment développé toute une famille de cartes à microcalcula

teur, dont la figure 1.7 retrace l'évolution.

La plupart des applications non bancaires doivent mainte

nant être envisagées dans le cadre de la famille SCOT, dont

la figure 1.8 résume la composition : de 8 à 64 Kb (soit 1 à

8 Ko) de mémoire EPROM ou EEPROM, avec algorithme

cryptographique TELEPASS ou DES incorporé.

Figure 1.7. Fondamentalement, une carte CP8 est une mémoire non

Panorama volatile, associée sur la même puce à un microprocesseur

de la •• galaxie CP8 ». qui en contrôle totalement l'accès.

24

Ses zones les plus secrètes, en particulier, ne peuvent être

lues, écrites, ou s'il y a lieu effacées que par le microproces

seur et en aucun cas directement depuis l'extérieur : on ne

pourra exploiter leur contenu que de façon indirecte, par

exemple en interprétant le résultat d'un calcul eryptogra-

phique dont il constitue seulement l'une des données.

Quelques cartes

BULL CP8

(à b et 8 contacts).

La puce

Motorola

d'une carte

BULL CP8 (environ

4 x 5 mm).

25


SCOT 10

SCOT 20 DES

SCOT SO

SCOT 60 DES

SCOT 100

SCOT 110 DES

64 Kbits EPFIOM 8 Kbits EEPROM 24 Kbits EEPROM

TELEPASS DES TELEPASS DES TELEPASS DES

< 2 1 2

Figure 1.8.

Les Ciiriu térisliqiiL s ttV

base des cartes SCO i

BULL CP8.

La mémoire des cartes SCOT ou M4 est organisée en un

petit nombre de zones aux prérogatives bien déterminées,

dont la figure 1.9 détaille l'agencement général, de moins

en moins sécuritaire au fur et à mesure qu'on se déplace

vers le haut de la mémoire.

Les droils d'accès â ces différentes /ones dépendent du sys

tème d'exploitation interne de la carte, de l'application elle-

même, et de la phase de vie de la carte (en usine, chez

l'émetteur, ou dans la poche de l'utilisateur).

La figure 1.10 définit les conditions d'accès à chacune des

zones, depuis la zone secrète accessible uniquement en

interne par le microprocesseur, jusqu'aux zones de lecture

et de fabrication qui peuvent être lues tout à fait librement

par le premier venu.

C'est naturellement au développeur de l'application qu'il

appartient de décider dans quelle zone il doit placer telle ou

telle information, en fonction du degré de sécurité qu'il esti

me nécessaire.

O2OOh ZONE SECRETE

ADM ZONE DACCES

ADC ZONE CONFIDENTIELLE

OU ZONE DE TRAVAIL N°2

ADT ZONE DE TRAVAIL N°1

ADL ZONE DE LECTURE

AD MAX - 8h ZONE DE FABRICATION

Figure 1.9.

Définition des zones

mémoire des cartes

BULL CP8.


Droits d'accès aux différentes zones

Effacement L ur. Ecriture

Zone secrète Interdit Interdite Interdite

Zone d'accès mm Protégée Interdite

Zone confidentielle ( option 1 zone de travail ) Interdit Protégée Interdite

Zone de travail 2 ( option 2 zones de travail )

L'application définit les droits d'accès à cette zona

Zone de travail 1 L'application définit les droits d'accès

Zone de lecture Interdit Libre ,™ Zone de fabrication Interdit Libre Interdit (sauf

verrous)

Comme il faut bien pouvoir écrire dans les zones les plus Figure 1.10.

secrètes lors de la fabrication des cartes puis lors de leur Les droits d'accès

personnalisation chez l'émetteur, quatre verrous définis à la aux zones mémoire

figure 1.11 peuvent être actionnés de façon irréversible à la des cartes BULL

fin de chaque phase de vie de la carte : le premier (LF) CP8.

avant que la puce, numérotée individuellement, ne quitte

l'usine, puis le second (l,C) lorsque l'émetteur a terminé son

travail de personnalisation.

Les deux autres verrous ne sont pas forcément utilisés au

cours de la vie normale d'une carte : LU sert à neutraliser

le code confidentiel d'origine après son remplacement par Figure 1.11.

un autre (en principe à l'initiative du porteur de la carte), Les différents

tandis que IV permet d'invalider définitivement une carte, « verrous » des

par exemple en cas de détection d'une tentative de fraude. cartes BULL CP8.

27


2 8

Figure 1.12.

Cartographie de la mémoire des cartes SCOT.


Chaque zone de mémoire est organisée en mots de 32 bits

(soit 4 octets) adressables au niveau de chaque quartet

(chaque adresse pointe donc sur un mot de quatre bits et

non sur un octet entier, et il faut, par conséquent, avancer

de deux adresses pour passer à l'octet suivant).

Il est important de noter que ces adresses ne correspondent pas nécessairement (et en pratique quasiment jamais !) à celles directement traitées par le microprocesseur : elles sont en effet mes à travers le système d'exploitation, qui a toute latitude pour les transposer (ou brouiller) comme il l'entend.

L'adresse de début de chaque zone est contenue dans un

pointeur spécifique, à l'exception de la zone secrète qui

commence toujours à O2 Oh.

ADM marque ainsi le début de la zone d'accès, ADC le

début de la zone confidentielle (ou de la seconde zone de

travail), ADT le début de la zone de travail, et ADL le début

de la zone de lecture.

La zone de fabrication, pour sa part, est placée juste en des

sous du dernier mot de la mémoire. Elle prend donc fin à

l'adresse ADMAX-8h, ADMAX étant la dernière adresse de

la mémoire, variable d'un type de carte à l'autre.

La figure 1.12, qui détaille de façon plus précise l'allocation

de ces zones dans le cas général de la famille SCOT, montre

que les pointeurs en question sont eux-mêmes stockés dans la

zone de lecture ; chacun peut donc en prendre librement

connaissance, tandis que le développeur dispose ainsi de

larges possibilités de fixation de la taille de telle ou telle zone.

On remarquera également que les clés et codes confiden

tiels résident obligatoirement dans la zone secrète, tout

comme le jeu secret utilisé dans les calculs cryptogra

phiques. Il ne sera donc jamais possible de les lire, même en

L'accès à la mémoire se fait, sous le contrôle du micropro

cesseur, à partir d'un jeu d'instructions compatibles avec la

norme 7816, dont la figure 1.13 donne la liste.

Conformément à cette norme, une commande envoyée à la

carte par son lecteur se présentera sous la forme d'un bloc

de cinq octets composé de la façon suivante :


• un octet dit dusse, égal à liCh dans le cas des cartes BULL

CP8 ;

> un octet contenant le Code operation de l'instruction ;

' deux octets précisant l'adresse à laquelle doit opérer

l'instruction ;

* un octet indiquant la longueur du bloc de données

devant être envoyé à la carte ou reçu de celle-ci (OGh s'il

n'y a pas échange de données).

Ordre disponible INS Lecture noh

Ecriture DOh

Recherche d'un mot sur argument AOh

Recherche Ou premier mot vierge AOh Recherche Ou premier non vierge ABh

Lecture de résultat COh

Ecriture des venous SOri Effacement domaine OEh

Demande de nombre aléatoire C4h

Présentation en clair de clé ou code 10h 3Oh 2Oh

Présentation clé de déblocage 2Oh 28fl

Présentation chiffrée de dé I8h 38h

Valiâatio de clé ou code 4Oh

Validation en écriture 70b Calcul de certificat 8Oh Changement code porteur D2b

L E S M A S Q U E S C O S

Les cartes COS comptent parmi les cartes à microprocesseur

les plus répandues, en raison de leur extrême souplesse de

personnalisation. COS signifie Chip Operating System ou

Card Operating System, par allusion au système d'exploita

tion chargé de la gestion de l'ensemble de la mémoire dis

ponible, sous la protection de nombreux mécanismes de

sécurité-

La figure 1.14 résume l'architecture du système interne à la

carte, laquelle existe en versions EPROM et EEPROM.

30

Figure 1.13.


des cartes SCOT.


Le principe EI'ROM, le plus ancien, ne permet pas l'efface

ment puis la réutilisation de zones mémoire : une satura

tion de la carte peut donc intervenir tôt ou tard.

Les cartes COS EEI*ROM, pour leur part, stmt n cyclable$

presque à l'infini.

Cette technologie est appelée à se généraliser de plus en

plus, car une carte à microprocesseur coûte tout de même

relativement cher et doit être remplacée aussi peu souvent

que possible.

Une variante de carte COS, dite MCOS, permet même

d'héberger plusieurs applications totalement indépendantes

dans une seule et unique carte : on parle alors de carte

multiprestataim.

La figure 1.15 révèle le plan mémoire des cartes COS

l ËPROM 16 Kb de Gemplus Card International, tandis que Figure 1.14.

la figure 1.16 se rapporte au modèle 24 Kb, deux exécutions Le principe

particulièrement courantes. du masque COS ».


Figure 1.15.

Cartographie

de la mémoire des

cartes COS EEPROM

16Kb.

;jjj Bien que chaque octet de mémoire puisse éventuellement

être lu ou écrit directement, le principe COS permet d'orga

niser la carte en un certain nombre de fichiers, un peu

comme une disquette sous DOS {Disk Operating Si/sfcm ; la

similitude est évidente...).

Bien entendu, chaque fichier peut bénéficier de multiples protections sécuritaires, précisées dans un descripteur approprié. En particulier, l'écriture et /ou la lecture peuvent être subordonnées à la présentation de codes confidentiels (chaque carte en supporte jusqu'à sept différents !).


Figure 1.16.

Cartographie

de la mémoire

des cartes

Certaines cartes COS intègrent l'algorithme de chiffrement COS EEPROM

DES, permettant de crypter les échanges de données entre 24 Kb.

la carte et l'extérieur : pas moyen par exemple de lire tin

voi un code confidentiel présenté ainsi à la carte !

D'un point de vue technologique, la mémoire est subdivi

sée en deux parties contiguës :

33


• une zone EPROM de 32 octets située au début de la

mémoire, où seule l'écriture simple est possible. Une

•] donnée dans cette partie de la mémoire ne peut jamais

être effacée ou mise à jour, à commencer par le numéro

I de série individuel de chaque carte ;

M une deuxième partie qui comprend tout le reste de la

I mémoire, de type EEPROM. Ici, une donnée peut être

I effacée et réécrite à volonté.

I L'ensemble de l'espace mémoire est constitué de mots de 32

!S? bits, c'est-à-dire de 4 octets.

P Dans la zone EPROM, on trouve d'abord la zone d'identifi-

li cation de la carte (le fameux numéro de série inscrit par le

f, fabricant) et de l'émetteur (identifiant inscrit par l'organis

me qui distribue les cartes). Il s'agit des mots l à 3.

: La zone suivante est la zone de contrôle du code ROM. A cheval sur les zones EPROM et EEPROM, elle contient six mots

l (4 à 9) :

• Le mot 4 héberge les verrons {locks) de la carte, et notam

ment les bits BFAB et BPERS décrits à la figure 1.17, dont

la mise à 1 est irréversible.

Dans une carte en cours de fabrication (au sein de l'usine) les bits BFAB et BPERS sont tous deux à zéro, et le mot 4 vaudra par exemple OOh. Pour l'instant, la sécurité de la carte est pratiquement nulle.

Figure 1.17. Les différents `` verrous »

des cartes COS.

HBBHBHHHHBiHHIHHBBHHHHI^BiHHBBIEIiilXII9 ~^i L E S M I C R O P R O C E S S E U R S D E S C A R T E S A P U C E _ | _

Dans toute carte quittant l'usine (avec un numéro de série) mais pas encore fwrsonitaliséc par l'émetteur, BFAB est à 1 et BPERS à 0 : le mot 4 vaudra alors O4h. C'est notamment le cas des cartes échantillon.

Lorsque l'émetteur aura terminé son travail de personnalisation, il mettra le bit BPERS à 1 : le mot 4 vaudra alors OCh, valeur la plus probable à rencontrer lorsqu'on manipule avec des cartes mises en circulation dans le public.

• Le mot 5, appelé filtre, contient le point d'entrée d'un programme applicatif éventuellement implanté en mémoire EEPROM. Si les deux derniers octets du mot ri sont OOh, alors le programme standard du COS est exécuté.

11 s'agit là d'une possibilité extrêmement puissante du COS, permettant en fait au développeur de conférer à la carte un comportement qui ne dépend pratiquement que du programme qu'il va écrire, à partir du jeu d'instructions du microprocesseur de la carte (en général un ST16XYZ de SCS-Thomson).

• Les mots 6 à 8 sont réservés au système. • Le mot 9 contient toutes les options qui vont régir le

comportement du code ROM de base : tvpe de protocole de transmission, mode d'allocation des fichiers, classe d'application, certains éléments de la réponse au re.se/, etc.

Vient ensuite, à partir du mot 10 (adresse l)24h), le bloc de

sécurité de la carte, contenant notamment les codes confidentiels et leurs descripteurs.

Dès la fin du bloc de sécurité commencent les fichiers, contrôlés par la table d'allocation physique contenue en fin du même espace mémoire, et que l'on peut comparer à la FAT d'une disquette.

Enfin, deux mots de lest sont placés tout à fait en haut de la mémoire : 64 bits que l'on peut venir lire et écrire tout à fait librement sans aucune repercussion par ailleurs.

35

http://re.se/


1 Les microprocesseurs A des cartes à puce 9

À LA DÉCOUVERTE DE LA CARTE BANCAIRE Une variante du masque BULL CP8 M4 38

Un lecteur de cartes à microprocesseur 39

Le bon usage du code confidentiel 47

Contrôlez vos relevés de compte 49

Une « boîte à outils » pour carte bancaire 50

Comment lire les pistes magnétiques 58

Pour aller plus loin... 60

Un mini système de J développement 73

4 Les télécartes ou cartes synchrones 107


T t l_i a p p l i c a t i o n carte bancaire const i tue un b o n t e r r a i n d ' e x p é r i m e n ta t ion a u t o u r des cartes à microprocesseur , sur tou t q u a n d on a eu la ( b o n n e ?) i d é e de ne pas rest i tuer n i d é t r u i r e ses cartes p é r i m é e s .

37

PC ET CARTES A PUCE

Mais à défaut, il faut savoir que les manipulations qui vont

être décrites peuvent fort bien être menées sur des cartes en

cours de validité, puisque nous nous limiterons essentielle-

menl à des opérations de lecture.

Par ailleurs, il faut savoir que les « cartes France Télécom »

(anciennement « PASTEL ••) sont très proches des cartes

bancaires et peuvent aussi servir de matière première.

Précisons simplement qu'en tout état de cause, chacun

devra assumer la pleine et entière responsabilité de ses

propres tentatives, quelles qu'elles soient, compte tenu de

leur caractère totalement expérimental.

U N E V A R I A N T E D U M A S Q U E B U L L C P 8 M 4

L'important pour s'attaquer à la lecture des cartes bancaires

est de se souvenir que la < classe ISO » des cartes BULL

CP8 est BCh et que, jusqu'à preuve du contraire, le pointeur

ADL vaut O8EOh pour toutes les cartes bancaires françaises

el pour les cartes France Télécom.

C'est suffisant pour prendre connaissance, avec un PC équipé d'un lecteur approprié, des données dont la lecture est libre. Mais à partir du moment où on possède le code confidentiel de la carte servant de cobaye (et quoi de plus normal quand on en est le titulaire ?) il est fort tentant de s'en servir pour déverrouiller certaines zones déjà mieux protégées. Toujours jusqu'à preuve du contraire, ADC est égal à ADT (il n'y aurait donc pas de « zone confidentielle » à proprement parler), et peut prendre des valeurs telles que O2Euh, U28Oh, G2BOh, O36Oh, etc.

ADM est pour sa part à t)2tiOh sur les « vieilles » cartes ban

caires à mémoire FPROM (masque dit BO).

Sur les nouvelles cartes à mémoire EEPROM (masque dit

BO'), ADM serait plutôt à O29Oh. Cela trahit une « zone

d'accès » (dite ici « zone d'état ») de taille sensiblement

inférieure.

C'est la conséquence logique de ce changement de technologie qui, permettant le « recyclage »> de cette zone, supprime le risque de « saturation » dont ont eu à se plaindre les gros utilisateurs de cartes dans les années passées.

38

A L A D É C O U V E R T E D E L A C A R T E B A N C A I R E

39

i II est facile de distinguer les cartes BO des cartes BO' par le

A fait que ces dernières portent normalement une « puce » en

jjiÇ position ISO (dite « centrée »), et ne possédant que six

jj3j contacts au lieu de huit.

Ill Par contre, et même muni du bon code confidentiel, il ne

faudra pas espérer pouvoir accéder à la « zone secrète ». En

présence de tentatives de ce genre, la carte adoptera tout

simplement un farouche mutisme, et c'est heureux !

Il va en effet de soi que si tel n'avait pas été le cas, nous n'aurions jamais écrit ce chapitre ni même probablement ce livre...

Bien entendu, les informations sur lesquelles est basé notre propos ne sauraient être considérées comme immuables.

Avec la probable généralisation mondiale de la carte de eré-

' dit à puce, il faut s'attendre à de profondes modifications

aussi bien matérielles que logicielles.

Un avant-goût de celles-ci est présenté dans les spécifica

tions « EMV » (Europay, Mastercard, Visa) qui nous

apprennent par exemple que la classe ISO des cartes de

paiement pourrait bien devenir 8Oh. Affaire à suivre donc,

avec le plus grand intérêt...

U N L E C T E U R D E C A R T E S À

M I C R O P R O C E S S E U R

Une solution commode pour s'attaquer aux cartes bancaires

(et plus généralement à toutes les cartes CP8) est disponible

sous la forme du kit d'initiation mis au point par BULL, et

commercialisé par TEKELEC.

Pour le prix d'un compatible PC moyen, cette mallette

contient un lecteur T I P 224, une vingtaine de cartes SCOT

50, un jeu de manuels et toute une bibliothèque de logiciels.

Il y a donc là non seulement de quoi apprendre à maîtriser

convenablement cette famille de caries, mais aussi tous les

éléments d'une plate-forme de développement suffisante

pour prototyper de véritables applications dans les règles

de l'art.

La documentation fournie s'articule autour du « manuel

d'utilisation de la famille SCOT », gros ouvrage de référence

contenant tout ce qu'on peut souhaiter savoir sur ces cartes.

Sa lecture nous a été extrêmement utile pour mener à bien

les recherches dont nous présentons ici les résultats.

Mais une grande part de l'intérêt du kit réside dans son contenu logiciel.

Parallèlement à quelques programmes à caractère surtout

démonstratif, on appréciera à leur juste valeur les drivers et

bibliothèques en langage C qui faciliteront considérable

ment le développement d'applications réelles.

Vu sous cet angle, le prix du kit peut être considéré comme

raisonnable, alors qu'une dépense de cet ordre ne saurait se

justifier par le seul souci de satisfaire une simple curiosité.

L'approche que nous allons privilégier ici repose donc plu

tôt sur la construction d'un lecteur économique, à partir de

composants courants.

Il s'agit naturellement de celui que nous avons décrit en détail dans notre livre Cartes à puce, Initiation et applications,

paru dans cette même collection (nouvelle édition avec disquette).

Tous les logiciels pour cartes à microprocesseur réunis dans

le présent ouvrage et sur sa disquette d'accompagnement

4 0


Le kit d'initiation

de BULL CP8.

ont été spécifiquement écrits pour lui, mais on pourrait au Le lecteurCCR2Ofl

besoin songer à les transformer pour d'autres plates-formes. de Gemplus Card

International.

Pour que le présent ouvrage puisse se suffire à lui-même,

nous reproduisons ici les plans de ce lecteur bâti, rappe

lons-le, autour d'un PIC ldCS4 qui, programmé à partir du

fichier COUP84.HF.X fourni sur la disquette, fait office de

« coupleur » simplifié.

L'opération de programmation peut se faire avec le très simple programmateur de PiC décrit dans notre ouvrage Composants électroniques programmables sur PC, paru dans cette même collection.

Si d'aventure on préférait se servir d'un autre programma

teur (par exemple le P1CSTART 16B de Microchip), alors il

faudrait utiliser de préférence le fichier COUP84.OB] et

positionner manuellement les « fusibles » de configuration

du PIC : oscillateur en mode XT, WDT et PWRT « ON », et

protection du code selon les désirs de chacun.

La figure 2.1 reproduit donc le tracé du circuit imprimé à

graver, et la figure 2.2 son plan de câblage. Le schéma théo

rique et le code source du logiciel embarqué, nullement

indispensables pour la construction du montage, ne sont

par contre pas repris.

4 1


COTE CUIURE

N = 2N2222 P = 2N29O7

Le montage nécessite une alimentation externe de 5 volts,

une éventuelle tension de programmation Vpp ne devant

être appliquée au second hornier que pour certaines opéra

tions bien spécifiques, et uniquement avec certaines cartes à

technologie ancienne.

Reste maintenant à construire un connecteur de carte qui

sera relié au circuit « coupleur » par un court câble méplat

équipé de deux fiches HE10 à dix contacts, tous reliés en

parallèle fil à fil.

Figure 2.2.

Plan de câbkigi du lecteur universel.

42

• Attention ! L'embase DB9 (liaison RS232 avec le port ; GOM1: du PC) doit impérativement être du type « femelle »,

Figure 2.1. Si et recevoir un câble du type " rallonge de moniteur » (mâle-

Le circuit imprimé femelle). Une embase mâle associée à un câble « double

du lecteur universel. # femelle » ne conviendrait pas.

A L A D É C O U V E R T E D E L A C A R T E B A N C A I R E ^

Figure 2.4.

Plan de câblage

du connecteur

de cartes.

43

La figure 2.3 fournit le tracé du cuivre nécessaire, et la figu

re 2.4 le plan de câblage correspondant.

Figure 2.3.

Le circuit imprimé

du connecteur de

cartes ISO/AFNOR.


Notons que deux réceptacles pour fiches HE10 sont prévus

(en l'occurrence deux tronçons de barrette sécable à double

rangée de picots carrés coudés). L'un correspond aux cartes

à puce en position ISO (centrée) et l'autre aux puces en

position AFNOR (excentrée). Il conviendra naturellement

d'utiliser le bon connecteur pour chaque carte.

Sur le plan logiciel, i! est bien sûr possible de partir à la

découverte de la Carte Bancaire en utdisant simplement un

programme capable de nouer un dialogue conforme à la

norme ISO 7816.

Les cartes bancaires étant pour le moment à convention

inverse » et à protocole - T=O ••, on mettra à contribution le

programme INVERSE.BAS présenté dans notre ouvrage

précité, et dont une version exécutable INVERSE.EXE se

trouve sur la disquette ci-jointe.

En présence d'une carte à convention directe, il faudrait par

contre se tourner vers DIRECT.EXE, dont le mode d'emploi

est identique.

Ces logiciels permettent d'envoyer à la carte n'importe

quelle commande ISO normalisée, aussi bien •• entrante

que •' sortante -, et d'afficher sa réponse.

Rappelons qu'on appelle commande •• entrante une com

mande destinée à émettre un bloc de données vers la carte.

4 4

A L A D E C O U V E R T E D E L A C A R T E B A N C A I R E ^

et commande « sortante » une commande destinée à

recueillir des données en provenance de celle-ci.

Muni de la liste des instructions reconnues par les cartes

bancaires, reproduite à la figure 2.5, on peut donc partir

librement à la découverte de toute carte de ce type ou appa-

; rentée.

INS O R D R E

OE Effacement

10 Présentation de la clé banque (CB)

20 Présentation du code confidentiel (CC) ou de la dé de déblocage de la carte

30 Présentation de la clé d'ouverture (CO)

40 Validation de lecture

50 Ecriture de verrou

70 Validation d'écriture

80 82 84 86 88

Certification avec • 1 er jeu secret - 2ème jeu secret - 3éme jeu secret - 4àme jeu secret - 5ème jeu secret

AO RechercJie du premier mot vierge ou sur argument

A8 Recherche du premier mot non vierge

BO Lecture d'octets

CO Lecture de résultat

DO Ecriture d'un mot

il est logique de commencer par s'attaquer à la « zone de

lecture », dont une cartographie approximative est fournie,

sous toutes réserves, à la figure 2.6.

IOn remarquera que chaque mot de 32 bits commence par

une <• clef de contrôle » souvent égale à 0011, mais fixée à

0010 lorsqu'elle marque le début d'un bloc dit « prestataire ».

4 5

Figure 2.5.


des cartes bancaires

M4BO'.


ADL (OBEO) 0010 1110 Prestataire 03 L=48 clef CCE

OSES 0011 oooo 1 oooo 1 oooo 1 oooo 1 D M 0011 320 bits (valeur d'authenuficaticm}

(0946) 0010 1110 Prestataire 02 L=56 tu I CCE

0011 Codeenieg, 00 N" carte (1B caracterfta BCD]

0968 0011 usage (3 car. BCD) début validité (4 a tr. BCD)

0070 0011 langue (3 car. BCD) Un validité (4 k ir. BCD)

0676 0011 devise (3 car. BCD) exposant Bin. réf. (début)

M M 0011 IDENTITE DU PORTEUR (26 caractères ASCII)

0988 0011 IDENTITE DU PORTEUR RUF I Bin. réf. (stile)

O9CO 00 AD1 CCE RUF

O9C8 00 ADL CCE ADT CCE

O9DO 00 ADC CCE ADM CCE

OSDB GO AD2 CCE ADS CCE

O9EO TYPE -3FE5 (CB) CCE

O9E8 00 AD1 CCE N" fabricant CCE

09F0 N' de série CCE

O9F8 10011

Le prestataire le plus intéressant est le n" 02, qui contient

des données sensiblement équivalentes à celles qui sont

gravées (on dit aussi embossées > ) dans le plastique de la

carte et enregistrées sur ses pistes magnétiques : numéro de

carte, identité de son porteur, dates de validité, etc.

I .e prestataire ll.'>, quant ,i lue joue déjà un rôle sécuritaire :

il contient en effet une « valeur d'authentication » codée

sur 320 bits, encore appelée •• identité certifiée > .

II semblerait que ce soit le résultat d'un calcul cryptographique mettant en jeu le contenu du prestataire 02 et le « jeu secret » dont on sait qu'il n'est en aucun cas lisible directement.

Un moyen comme un autre pour démontrer que la carte est authentique !

Figure 2.6.

Cartographie de la

zone de lecture des

cartes bancaires.

A L A D E C O U V E R T E D E L A C A R T E B A N C A I R E

L E B O N U S A G E D U C O D E C O N F I D E N T I E L

Dès qu'on tentera des opérations de lecture à des adresses

inférieures à ADL, il faudra présenter à la carte le code

confidentiel de son porteur.

Oil butera alors sur une particularité propre aux cartes CP8,

, qui exigent que tout code présenté soit ensuite « validé »

(on dit aussi « ratifié »} par une instruction spéciale.

11 ne suffira donc pas d'envoyer une commande de présen-

: talion de code de la forme BC 20 00 00 04, puis dans un

second temps les quatre octets du code « PIN ».

Pour mettre en œuvre l'instruction de ratification de code

(4Oh), à l'adresse OOh et avec une longueur des données de

OOh, il faudra encore envoyer la trame suivante : BC

40 00 00 00.

Mais nous ne sommes pas encore au bout de nos peines !

En effet, un code confidentiel normalement constitué se

compose de quatre chiffres, alors que la carte attend un mot

de quatre octets (huit chiffres hexa).

Le code 4950 devra par exemple être présenté sous la forme

(hexadécimale) 12 54 3F FF.

Chacun aura donc à « transcoder •> les codes confidentiels

de ses cartes avant de les présenter, en l'occurrence à l'aide

du petit logiciel PIN2CB.BAS que nous avons écrit à cet

effet.

4 7


Le déblocage en lecture de la zone de travail nécessitera

donc l'enchainement des opérations suivantes :

• lancement de INVERSE.EXE puis insertion de la carte ;

• attente de la « réponse au ttttt » de la carte ;

• émission d'une commande de présentation de PIN (BC

20 00 0 0 0 4 ) ;

• attente de la réponse de la carte (octet de procédure 2Oh) ;

• envoi direct des quatre octets du code (dans notre exem

ple 12 54 3F FF) ;

• attente du compte-rendu de bonne exécution (90 00 si tout

va bien, une autre valeur que 00 pouvant indiquer qu'un

code taux a été présenté et ratifié au cours d'une session

précédente) ;

• ratification de ce code (BC 40 00 00 00) ;

• attente de l'octet de procédure (40b ou 4lli), immédiatement

suivi du compte-rendu de bonne exécution (90 00 si le code

présenté était correct).

Notons qu'un octet de procédure égal à 41 h au lieu de 4Oh

indique que la carte réclame une tension de programmation

Vpp. Faute de celle-ci, la ratification échoue sur un compte-

rendu différent de 90 00, mais le code déjà présenté, quel

qu'il soit, n'est pas considéré comme faux.

Il faut alors recommencer toute ia procédure en appliquant

le Vpp (souvent 21 volts mais à vérifier au cas par cas) juste

avant de lancer la ratification, et sans oublier de le retirer

juste après (puisque nous n'avons pas la prétention d'écrire

dans la carte !)

48


|| Il ne reste plus alors qu'à procéder, autant de fois qu'on le

î voudra, à la lecture de blocs d'octets à l'intérieur de cette

zone, c'est-à-dire à partir de l'adresse O29Oh ou O2fVOh (selon

l'âge de la carte).

La commande à envoyer à la carte sera de la forme BC BO

WX YZ LL, avec les conventions suivantes :

• WXYZ - adresse de début de lecture (en hexadécimal) ;

• LL = nombre d'octets à lire (en hexadécimal).

Pour lire 32 octets à partir de O29Oh, on enverrait ainsi BC

BO 02 90 20.

Le bloc d'octets reçu en retour arrivera encadré par un

« octet de procédure `> BOh et par un compte-rendu qui, si

tout s'est bien passé, sera égal à 90 00.

On devrait normalement trouver, dans ces parages, une

suite de 0 séparer d'une suite de F par un chiffre pouvant

être égal à 1, 3, ou 7 (0001, 0011, ou 0111 en binaire).

Selon nos observations et nos informations, chaque présen

tation avec ratification d'un code confidentiel correct vien

drait mettre un bit à zéro dans cette chaîne de bits à 1. Il y

aurait donc ici un véritable « compteur » surveillant l'usage

qui est fait de la carte et pouvant éventuellement, sur les

cartes « B0 », se trouver saturé •> en cas d'utilisation parti

culièrement intensive.

Bien entendu, il y a ici une possibilité permettant de véri

fier si une carte a été utilisée à !'insu de son porteur, mais

attention ! Le contrôle nécessitant la présentation du code

confidentiel, il « consomme » nécessairement un bit...

Enfin, 0 semblerait que la présentation d'un code faux, avec

ratification, laisse une trace prenant la forme d'un 1 non

transformé en 0.

C O N T R Ô L E Z V O S R E L E V É S D E C O M P T E

ILes blocs de quatre octets qui suivent reproduisent (s'il y a

lieu) l'historique des paiements effectués, mois après mois,

par l'intermédiaire de la puce (et en aucun cas des pistes

magnétiques) de la carte.

Un mot " 30 00 95 12 • marquerait par exemple le début du


mois de décembre 1995 tandis que les mots 33 58 38 18 »

ou « 33 98 4C F4 » trouvés juste après retraceraient deux

achats effectués, avec présentation du code confidentiel à la

puce, dans le courant de ce même mois.

Moyennant le décodage de ces mots de 32 bits, on arrive à

retrouver trace, au centime près ou au franc près, selon les

cartes, de chaque achat et de sa date : de quoi reconstituer

un véritable » relevé de compte » !

Bien entendu, la tenue dans la carte elle-même de cet histo

rique détaillé de toutes les transactions explique les phéno

mènes de saturation parfois signalés avant la fin des deux

années de validité des cartes bancaires à puce, car le

masque BO utilisant de la mémoire EPROM, aucun « recy

clage •> des zones utilisées n'est possible.

Réalisées en technologie L`bl'KOM (réinscriptible), les nou

velles cartes BO' supportent une procédure dans laquelle les

transactions les plus anciennes sont effacées pour céder de

ia place aux plus récentes. Le problème peut donc être

considéré comme réglé !

U N E « B O I T E À O U T I L S » P O U R

C A R T E B A N C A I R E

Même si INVERSE.EXE permet de procéder à toutes les % opérations imaginables sur les cartes bancaires, son utilisa

tion peut se révéler laborieuse lorsque les groupes d'octets reçus de la carte nécessitent un décodage particulier.

C'est notamment le cas des données stockées dans la zone

• : de lecture, et du fameux « relevé de compte » dont nous

venons de révéler l'existence.

Nous avons donc développé un jeu de logiciels prenant en

; charge tout le travail fastidieux et affichant « en clair » les

données les plus intéressantes.

Pouvant être considérés comme faisant partie de cette « boîte à outils », les programmes de lecture et de décodage de la réponse au reset (ATR.EXE et DECATR.EXE) sont fournis sur la disquette de notre ouvrage Cartes à puce,

Initiation et applications.


5 1

Nous ne les reproduisons pas ici, car ils n'ont rien d'indis

pensable pour les manipulations qui vont suivre.


640 IF N>S3 THEN RM -64:M M-

65Ù IP N>3l THEN N=t -32:M M-

S6O IP N>I5 THEN N=î -Î6:M H-

670 IP N>7 THEN N=N 8:M=M 16

680 IP N>3 THEN N=N 4:H=M 32

690 IP N>l THEN N-N ."::M = M 64

700 IP N>O THEN M=M 128

710 RETURN

720 REM [c)l997 Patrick GOEDLLS

Le programme ADL.BAS ne doit être considéré que comme

le code source de ADL.EXF, exécutable compilé qui, seul,

devra être utilisé en pratique, à partir de l'invite du DOS ou

éventuellement dans une « fenêtre » Windows 95.

Cela pour des raisons de configuration du port série, les

interpréteurs comme GWBASIC ne supportant pas cer

taines options dont nous avons dû faire usage.

Ce logiciel lit tout simplement le contenu de la zone de lec

ture de n'importe quelle carte compatible {bancaire ou

France Télécom), et sauvegarde celui-ci, sous forme binaire,

dans un fichier texte nomme ADL.CAR.


l-e décryptage de ces données sera confié, dans un deuxiè

me temps, au programme DECADL,BAS dont une version

compilée, DECADL.i\X!\, esl également fournie sur la dis

quette.

S3


5 5


Figure 2.7.

Un exemple de

décryptage de

la zone de lecture.

La figure 2.7 montre ce que cela peut donner; sur un

, exemple réel dont nous avons volontairement occulté les

• parties trop personneLles.

Figure 2.8.

Un exemple de

lecture de la zone

de travail.

Le logiciel ADT.EXE (version compilée de ADT.BAS) per

met d'aller beaucoup plus loin, entendons par là d'accéder

au contenu de la zone de travail qui, nous le savons, est

protégé par le code confidentiel ou < PIN ».

Avant de créer le fichier ADT.CAR (dont le format est le

même que celui d'ADL.CAR), il demande au porteur de la

carte de bien vouloir lui communiquer son code confiden

tiel à quatre chiffres (le transcodage en quatre octets sera

automatiquement effectue), ainsi que l'adresse de début de

la zone de travail (ADT).

Cette dernière information est tout simplement fournie par

DECADL.BAS.

252 octets sont alors lus, ce qui suffit très largement, et affi

chés sur l'écran sous la forme reproduite à la figure 2.8.

56


Création du fichier ADT.HEX

Il suffit alors de lancer DECADT.BAS (ou bien

DECADT.EXE) pour décrypter le « relevé de compte » enre

gistré dans ADT.CAR.

Pour cela, le programme s'enquiert de l'exposant •• de la

carte, valeur numérique fournie là encore par

DECADL.BAS et qui précise tout simplement si les mon

tants sont enregistrés en francs ou en centimes.

La figure 2 . u reproduit un extrait d'un tel < relevé de comp

te », précis au centime prés puisque lu sur une carte dont

l'exposant est égal à 3.

Figure 2.9.

Un exemple île

dt't ryptjgi' du

" relevé de compte ».


Les pistes

magnétiques

sont également

intéressantes à lit

C O M M E N T L I R E L E S P I S T E S M A G N É T I Q U E S

» Même si cela affaiblit considérablement leur sécurité, cer-

;; taines cartes à microprocesseur sont munies, en plus, de

s pistes magnétiques reproduisant au moins en partie le

contenu de la puce.

-, Tel est notamment le cas des cartes bancaires internatio-

! nales, situation qui se prolongera fatalement tant que la

! puce ne sera pas adoptée à l'échelon mondial.

Mais les cartes « nationales » sont également concernées,

I puisque les automates français doivent bien accepter les

cartes purement magnétiques de nos visiteurs étrangers.

j La figure 2.10 montre comment sont placées les trois pistes

internationales dites ISO 1, ISO 2, et ISO 3. Les pistes sup

plémentaires T2 et T3, que l'on trouvait autrefois surtout au

dos des cartes bancaires VISA, ont aujourd'hui disparu.

I Chacune de ces pistes peut être encodée selon un principe

fort simple, dont la figure 2.11 donne le détail.

Chaque trait vertical correspond à une inversion de magné

tisation, parfaitement visible à la loupe si on fait agir sur la

piste un produit " révélateur magnétique ».


Li densité d'enregistrement peut être de 75 ou 210 bpi (bits

par pouce), et on peut inscrire soit des caractères alphanu

mériques à 7 bits (ASCII), soil des données numériques

codées sur 5 bits (avec parité).

Compte tenu de la longueur de la carte (environ 85 mm), on

arrive ainsi à une limite de 74 caractères pour la piste ISO I

(dite aussi •• IATA > car utilisée couramment par les compa

gnies aériennes), 40 caractères pour la piste ISO 2 ou •• ABA >`

(largement employée par les banques) et 107 caractères pour

la piste ISO 3 dont l'affectation est plus ou moins libre.

C'est évidemment bien peu par rapport à une carte à micro

processeur moderne, mais pas ridicule pour autant en com

paraison des 256 bits (et non pas caractères !) d'une télécar

te à puce.

Bien qu'il soit à la rigueur possible de décoder visuellement

(surtout à 75 bpi) le contenu d'une piste préalablement

révélée, il est infiniment plus pratique de se servir d'un lec

teur spécialisé.

5 9

Figure 2.10.

Les caractéristiques

magnétiques,

Figure 2.11.

Le codage des bits

sur les pistes

magnétiques.


Notre Ouvrage Gird"- magnétiques et PC, paru dans cette

même collection, explique de A jusqu'à Z comment mettre

en œuvre des lecteurs du commerce ou de récupération, et

même comment construire son propre lecteur-encodeur à

partir de matériaux courants.

De quoi pousser l'exploration des pistes magnétiques aussi

loin sinon plus que celle des puces...

P O U R A L L E R P L U S L O I N . . .

Après la carte bancaire, nos lecteurs souhaiteront très cer

tainement exercer leurs talents sur d'autres catégories de

cartes à microprocesseur : cartes ` SIM » pour téléphones

portables, porte-monnaie élecIroniques, cartes santé, etc.

Avant de développer, peut-être, leur propre « boîte à outils »

pour telle ou telle famille de cartes, ils devront partir « à

l'aventure •• dans une puce a priori totalement inconnue.

La première étape consiste à faire parler la « réponse au

reset », à l'aide des logiciels ATR.EXE et DECATR.EXE de

notre ouvrage Cartes il puce, Initiation et applications (édition

avec disquette).

Si la carte supporte bien le protocole " T=O », alors il faudra

déterminer sa « classe ISO ».

s. Là encore, deux programmes déjà publies dans notre précé

dent ouvrage s'en chargeront en quelques minutes : CLAS-

SINV.EXE si la carte est à « convention inverse », ou

CLASSDIR.EXE si sa réponse au reset révèle qu'elle est à

[ convention directe.

À ce stade, on pourrait commencer à essayer au hasard

quelques instructions plus ou moins classiques, mais il est

infiniment préférable de tenter de déterminer automatique

ment l'ensemble de son jeu d'instructions.

C'est beaucoup plus simple qu'on pourrait le croire, puis-

; qu'il suffit la plupart du temps d'exécuter 0P1NV.EXE (en

^ convention inverse) ou OPDIR.EXE (en convention directe),

: respectivement obtenus par compilation des sources

OPINV.BASet OPDIR.BAS.

6 0

A L A D E C O U V E R T E D E L A C A R T E B A N C A I R E £

61

b2



6 3

Tous les codes opération possibles sont essayés systémati

quement, associés à la classe ISO préalablement déterminée

et, afin d'éviter tout •< accident », à des paramètres •• réfé

rence » et •• longueur » aussi invraisemblables que possible

(FFFFli et FFh respectivement).

Il est logique de commencer l'exploration à partir du code

opération OOh, mais le programme permet de commencer

n'importe où entre OOh et FFh. Cela permettra de « sauter »

facilement les codes qui pourraient entraîner le blocage de

la carte en mode « mutisme » (une réaction courante des

cartes BULL CP8).


L'exploration complète prend un peu moins de cinq

minutes, pendant lesquelles un bip sonore signale tout code

opération identifié. Il est alors vivement conseillé de le

noter...

À titre d'illustration, voici les listes d'opcodes que nous

avons pu dresser de cette façon pour quelques cartes cou

rantes.

• Carte de téléphone GSM : 04, 20, 24, 26, 28, 2C, 32, 44 ,88 , A2, A4, BO, B2, B8, BE, CO, D6, DA, DC, E0, E4, F2, FA.

• Forte-monnaie électronique « MONDEX » :

20 ,22 , 24, 32, 34, 36, 38, 3C, 3E, 44, 46, 48, 4A, 4C, 4E, 50,

52 ,54 , 56, 70 ,72 , 74, 76, 80 ,82 , 84, 86, F6.

• Porte-monnaie électronique " PROTON » :

10,14, 1C, 20, 50, A0, A4, A8, BO, B2, C0, C4, DO, D4, D6.

• Carte « COS » Gemplus :

20, 22, 24, 26 ,28 , A2, B0, B2, B4, D0, D4, D8, E0, F0, F2.

Il reste ensuite à déterminer la fonction et la syntaxe de

chaque instruction ainsi identifiée, la comparaison avec des

« dictionnaires > d'opcodes existants rendant souvent de

fiers services.

On pourra essayer, avec prudence, certaines instructions

avec différentes " références " (OOOOh donne souvent des

résultais), puis avec différentes longueurs.

Si la carte répond par un compte-rendu commençant par

6Bh, on saura que la référence essayée n'est pas supportée.

Si le compte-rendu commence par 67h, on saura cette fois

que c'est la longueur qui est incorrecte.

Même si cela peut paraître trop beau pour être vrai, beau

coup de cartes indiquent, dans le second octet du compte-

rendu, quelle est la bonne longueur ! 67 20, par exemple,

signifierait que la longueur attendue par cette instruction

est 2Oh, autrement dit 32 octets.

En principe, la longueur n'est ainsi contrôlée que si la réfé

rence {ou « adresse ••) est déjà correcte.

6 4

A L A D E C O U V E R T E D E L A C A R T E B A N C A I R E £

6 5

À vrai dire, il semble bien que la carte commence très logi

quement par tester la classe ISO, puis l'opcode, la référence,

et enfin la longueur et signale seulement la première irré

gularité rencontrée.

Lorsqu'on commencera à y voir un peu plus clair, il sera

temps de commencer à tenter de lire des blocs d'octets à

des adresses potentiellement intéressantes.

En présence de cartes reconnaissant l'instruction de lecture

b Oh, on pourra ainsi se servir du programme

LECTiNV.EXE (convention inverse) ou de LECTDIR.EXE

(convention directe) dont voici les codes source.


- 6 6 -


67


Bien entendu, il serait facile de modifier la ligne 250, puis de recompiler le programme, pour utiliser n'importe quel autre opcode reconnu comme déclenchant une opération de lecture.

Évolution technique aidant, on se trouvera aussi confronté,

de temps à autre, à des cartes plus ou moins incompatibles

avec les logiciels qu'on aura pris l'habitude d'utiliser.

Il faudra alors les modifier plus ou moins profondément, ou

bien en développer carrément de nouveaux.

DIALINV.BAS, par exemple, est une variante de INVER

SE. BAS qui présente l'avantage de supporter de nouvelles

générations de cartes (par exemple le porte-monnaie élec

tronique MONDEX).

10 REM — DIALINV.BAS —

2D KEY OFF:CLS

6 8


69


7 0

A L A D E C O U V E R T E D E L A C A R T E B A N C A I R E X

INVERSE.BAS transmettait les commandes à la carte octet

par octet, au fur et a mesure de leur frappe au clavier.

Même si cette façon de procéder a toujours sa raison d'être,

ne serait-ce que pour surveiller les réactions de la carte à

fk des sollicitations un peu « spéciales », certaines cartes

;;i récentes imposent un délai particulièrement court entre

deux octets successifs.

£ DIALINV.BAS (et sa variante DIALDIR.BAS pour les cartes

• C à convention directe) règle ce problème en mémorisant les

M1 octets frappés et en les envoyant à la carte, en une seule

fois, dès l'appui sur le « retour cbariot ».

; Sans revenir sur des explications déjà fournies dans notre

précédent ouvrage, rappelons que pour des raisons de

configuration du port série, les sources BASIC de ces pro

grammes ne doivent pas être utilisées directement.

i II faut impérativement se servir des versions compilées {$ (DIALINV.EXE et D1ALDIR.EXE, fournies sur la disquette) I en les exécutant directement à partir de l'invite du DOS ou I dans une « fenêtre » Windows (seulement sur les PC suffi-I samment rapides).

JFE Les codes source seront cependant utiles à ceux de nos lec-

I teurs qui souhaiteraient apporter des modifications de leur

J! cru à nos programmes (qu'ils n'hésitent pas, alors, à nous

71


1 Les microprocesseurs des cartes à puce 9

À la découverte

de la carte bancaire 37

UN MINI SYSTÈME

3 DE DÉVELOPPEMENT Un adaptateur RS232 pour carte asynchrone 74

Un petit analyseur de protocole 78

Un petit simulateur de carte 82

Une carte à puce expérimentale à PIC16CXX 88

4 Les télécark`s ou cartes synchrones 107


X-J e car te à m i c r o p r o c e s s e u r a s y n c h r o n e n 'est f i n a l e m e n t r i e n d ' a u t r e q u ' u n p e t i t s y s t è m e m i c r o - i n f o r m a t i q u e , avec m é m o i r e e t u n i t é cen t ra le , c a p a b l e d e c o m m u n i q u e r avec son l ec teur p a r u n e l i a i s o n sér ie b i d i r e c t i o n n e l l e .

•


À condition de faire l'impasse sur une bonne partie des sub

tilités de la norme ISO 7816-3, celles-là mêmes que ne peut

en aucune façon se permettre d'ignorer un développeur

d'applications sensibles, on peut considérer que le fonction

nement d'une carte asynchrone se résume la plupart du

temps à des échanges d'octets à 9 600 bauds.

11 est évidemment fort tentant de chercher à interfacer

cartes à microprocesseur, lecteurs, et ports RS232 de PC

pour faire de l'analyse de protocole ou même, il suffit

d'oser, de la simulation.

U N A D A P T A T E U R R S 2 3 2 P O U R C A R T E

A S Y N C H R O N E

On pourra s'étonner du fait que le petit montage dont la figure 3.1 dévoile le schéma ne supporte que quatre des six à huit contacts dont dispose normalement un connecteur de carte à puce.

En réalité, les cartes asynchrones n'utilisent dans leur

immense majorité que six contacts, dont un affecté à une

L'adaptateur RS232 S tension de programmation V p p que nous n'avons pas

achevé. M besoin de gérer dans notre contexte.

74

U N M I N I S Y S T È M E D E D É V E L O P P E M E N T ^ 3

Plus surprenante est peut-être l'absence de L

d'horloge, mais elle s'explique tort bien : le PC cadence son

port série à 9 600 bauds à partir de sa propre horloge inter

ne, ce qui lui permet d'ignorer superbement le signal CLK

provenant du lecteur.

Ce n'est évidemment guère orthodoxe vis-à-vis de la norme

ISO (qui prévoit des possibilités de changement de fréquen

ce d'horloge et de rythme de modulation), mais l'expérien

ce montre que c'est acceptable dans la grande majorité des

cas susceptibles de nous intéresser.

La pièce maîtresse du montage est un circuit intégré MAX232 tjuî, alimenté par le + 5 volts venant du lecteur de cartes, reconstitue les niveaux + 12 V et - 12 V compatibles avec le port RS232.

Un cavalier mobile est prévu pour régler le problème des

rares lecteurs ne fournissant pas assez de courant pour ali

menter le montage (diode Led ne s'éclairant pas, et /ou lec

teur signalant une carte en court-circuit).

En pareil cas, on retirera le cavalier et on branchera une ali

mentation 5 volts séparée entre le strap de masse (pôle -) et

le picot relié à la broche 16 du MAX 232 (pôle +).

Le cavalier, pour sa part, sera « rangé » sur le picot restant,

celui allant au contact ÎSOI de la carte à puce.

Figure 3.1.

Le schéma de

l'adaptateur RS232.

75


Cette façon de procéder interdit l'application d'une tension

d'alimentation externe quand le cavalier est en place, et

assure par conséquent la protection du lecteur de cartes

contre une telle fausse manœuvre.

Le MAX232 est secondé par un CD4OO7, chargé de multi

plexer sur l'unique ligne d'entrée-sortie (bidirectionnelle)

de ia carte, les données circulant séparément sur les lignes

TXD et RXD de la RS232 : cela laisse supposer qu'après

avoir servi passivement d'analyseur de protocole, le même

montage pourra, le moment venu, simuler au moins par

tiellement une carte à microprocesseur !

Cette configuration matérielle reconstitue en effet aussi

fidèlement que possible la structure à drain ouvert des cartes

à puce normalisées.

Converti lui aussi en niveaux RS232, le signal de remise à

zéro de la carte (RESET) est relayé vers le PC par la ligne

DCD (Carrier Detttt) du port série : cela permettra au logi

ciel de détecter les demandes de remise à zéro formulées

par le lecteur de cartes, voire même d'y repeindre s'il n'y a

pas de vraie carte pour le faire.

Assemblé sur un petit circuit imprimé dont la figure 3.2 fournit le tracé, le montage est muni de deux connecteurs à câbler selon la figure 3.3 :

• une embase DI59 femelle destinée à venir s'enficher, directement ou par l'intermédiaire d'un adaptateur DB4-DB25, dans le port COM1: du l`C (attention, n'utiliser en aucun cas une embase mâle et un cordon double femelle : employer plutôt, si nécessaire, un cordon mâle-femelle dit rallonge de moniteur) ;

Figure 3.2.

Le circuit imprimé de

l'adaptateur RS232.

7 6

U N M I N I S Y S T E M E D E D E V E L O P P E M E N T

un connecteur HE10 femelle compatible avec l'ensemble Figure 3.3.

des éléments de la boîte il outils pour cartes à puce décrite Plan de câblage de

dans notre ouvrage "Cartes à puce, Initiation et applications- l'adaptateur RS232.

paru dans cette même collection : connecteurs de cartes,

fausses cartes en circuit imprimé, et bien entendu lecteur

de cartes.

Il est naturellement vital que la correspondance de brocha

ge soit assurée entre tous ces éléments. Ce sera automati

quement le cas si on sertit des fiches HE10 mâles à dix

contacts dans le même sens sur un morceau de câble en

nappe à dix conducteurs, et si on utilise en tant que récep

tacles des tronçons de barrettes sécables à picots carrés cou

dés.

En effet l'ergot de détrompage des fiches HE10 viendra

alors buter sur le circuit imprimé en cas de tentative

d'insertion dans le mauvais sens.

Liste des composants

1 circuit intégré MAX 232,

1 circuit intégré CD4007,

1 LED rouge 5 mm,

4 condensateurs chimiques 1 uF 25 V (1 axial, 3 radiaux),

1 condensateur 0,1 pF 63 V,

1 résistance 5,6 kil t / 4 W ,

1 embase DB9 femelle coudée pour circuit imprimé,

1 barrette sêcable à double rangée de picots carrés coudés,

1 fiche HE10 à 10 contacts supplémentaire pour le cordon,

1 cavalier de court-circuit (2,54 mm).

— 7 7 —


U N P E T I T A N A L Y S E U R D E P R O T O C O L E

I Que ne donnerait-on pas, parfois, pour savoir ce que peu-

$i vent bien se dire les cartes à puce et les lecteurs dans les-

Aussi surprenant que cela puisse paraître, ce petit montage

et quelques lignes de BASIC suffisent pour espionner une

carte bancaire, de téléphone (PASTEL ou CSM) ou bien, et

c'est plus amusant encore, de télévision à péage.

Toujours plus fort, on peut même songer à simuler, dans

des limites raisonnables, le dialogue ainsi intercepté !

Bien entendu, nous ne prenons la liberté d'écrire ces lignes que parce que nous avons pu vérifier qu'une telle démarche tie remet nullement en cause la sécurité des applications carte correctement protégées.

L'un des buts de ce livre est précisément de permettre à nos lecteurs de se faire une idée personnelle sur la question : après tout, on croit ce qu'on voit, n'est-ce pas ?

Une bonne plate-forme d'expérimentation de cartes asyn

chrones comprendra, outre le présent montage, un lecteur

de cartes à puce (figure 2.2) connecté à son propre compa

tible PC.

Il sera en effet prudent de ne songer, que dans un deuxième

temps, à s'attaquer à des équipements disponibles à domi

cile tels que Minitel à lecteur de cartes, téléphone portable

CSM, ou décodeur de télévision.

quels on les introduit ?

ses accessoires.

L'analyseur

de protocole et

HIIHI HMH HMMMfllHHHHl l HK3IEXIEiiQi 5

Figure 3.4.

Le fracé du cuivre

de la » fausse carte »

AFNOR.

• Il faut donc en principe deux micro-ordinateurs pour mani-

\ puler confortablement, mais l'un d'entre eux (de préférence

1 celui affecté à l'analyseur) pourra sans problème être un

Jf vieil XT à 8086 ou encore un portable.

m Sur le plan matériel, l'adaptation est extrêmement simple :

I il suffit de sertir une troisième fiche HE10 à dix contacts,

II toujours dans le même sens, à peu près au milieu d'un cor-pi don reliant un connecteur de carte (figure 2.4) à une fausse

H carre en circuit imprimé de 8 /10 mm, telle que celle dont la pi figure 3.4 reproduit le tracé (puce en position AFNOR).

. V On branchera, c'est évident, cette troisième fiche sur le pré-

M sent montage.

H La vraie carte à puce (carte bancaire ou PASTEL de préfé-

i! rence périmée) étant maintenant insérée dans le connecteur

M relié au cordon, il suffit d'introduire à sa place lafaitsse carte

m dans le lecteur dont on désire étudier le comportement :

I tout se retrouve fort simplement connecté en parallèle.

Y& À condition d'avoir été lancé avant toute émission de

I demande de reset de la carte par le lecteur (donc en pre-

I mier), un très simple logiciel suffit pour afficher (en hexa-

I décimal) tous les octets circulant entre te lecteur et la carte.

$$î 10 REM ESPINV.EAS •20 KEY OFF:CLS H 30 PRINT"ESPINV (c) 1995,97 Patrick GUEULLE

I Espion de cartes à convention inverse*

40 OPEN "COMl: 9600,e,S,2 " AS #1 50 E = INP(&H3FE) AND 128 7 9

U N M I N I S Y S T E M E D E D E V E L O P P E M E N T , 3


8 0


Deux versions distinctes ont été développées : ESPINV.BAS

pour les cartes à convention inverse, et ESPDIR.BAS pour

les cartes à convention directe.

En pratique, on se servira des versions compilées

ESP1NV.EXE et ESPD1R.EXE qui sont fournies sur la dis

quette de ce livre, en complément des codes source.

On remarquera dans ESPINV.BAS une routine de transcoda

ge d'octets qui permute, à la réception, les bits de poids fort

avec ceux de poids faible, tout en les complémentant. C'est

ce qu'on appelle une conversion en « convention ISO inverse

> , les cartes à puce de ce type communiquant bit de poids

fort en tête et « 1 » logique représenté par un niveau bas.

Déclenchant un retour à la ligne dès que le flot de données

s'interrompt, même brièvement, ce programme permet

dans une certaine mesure de distinguer la provenance de

tel ou tel groupe d'octets (venant du lecteur ou de la carte).

A i e stade de uns investigations, il est commode île piloter

le lecteur par un logiciel mettant à contribution un maxi

mum de fonctions des cartes bancaires, le plus indiqué

étant naturellement notre programme INVERSE.EXE.

I.e petit logiciel CB2PIN.BAS permettrait même, le cas échéant, de remonter au code confidentiel en partant des huit octets interceptés lors de leur transmission : à n'utiliser donc qu'à bon escient...


U N P E T I T S I M U L A T E U R D E C A R T E

Parmi toute la panoplie d'outils dont disposent les dévelop-

I peurs d'applications cartes à puce, l'émulateur de cartes

figure en bonne place.

Qu'il soit autonome ou connecté à un PC, cet instrument

ï équipé d'une fausse carte en circuit imprimé est en principe

capable de se faire passer pour n'importe quelle carte à

puce iisiiihliivin; autrement dit à microprocesseur.

Nous allons nous pencher ici sur un projet d'émulateur très

simplifié que nous baptiserons plutôt simulateur.

Piloté lui aussi par un compatible PC, il partagera avec

l'analyseur de protocole qui vient d'être décrit le même

j adaptateur RS232 dont nous avons pu apprécier la dérou-

5 tante simplicité.

Sur le plan matériel, un simulateur de cartes à puce peut en

effet être fort compliqué ou étonnamment simple, mais

U N M I N I S Y S T E M E D E D É V E L O P P E M E N T

dans les deux cas du logiciel spécifique doit naturellement

être écrit pour chaque carte qu'il s'agit de simuler. Les spé

cialistes appellent cela programmer un masque.

Faut-il donc en déduire qu'il suffit de réaliser un petit mon

tage électronique et d'écrire un peu de code pour se fabri

quer une vraie-fausse carte bancaire ou de télévision à péage ?

Nous n'irons évidemment pas jusque là !

En effet, toute carte à microprocesseur destinée à des applications sensibles doit en principe intégrer des fonctions cryptogra-

phiques basées sur des clefs secrètes qui ne peuvent en aucun cas être lues depuis l'extérieur de la carte (voir chapitre 1).

Sauf faute très lourde de l'émetteur d'une telle carte (dont il

porterait évidemment l'entière responsabilité), on considè

re donc communément comme impossible de percer le

mystère de la partie sécurisée des échanges de données

entre la carte et son lecteur.

Le simulateur de

carte prêt à être

raccordé au PC.

Émulateur de carte simplifié à l'extrême, le présent monta

ge va néanmoins vous permettre de reproduire, grâce à

votre PC, les parties pas trop secrètes des dialogues carte-

lecteur que vous aurez préalablement eu la bonne idée

d'intercepter : une façon comme une autre d'évaluer

jusqu'où on peut se permettre d'aller trop loin...

8 3


Électriquement, la mise en œuvre du simulateur est on ne

peut plus simple : réunir, grâce au câble ad hoc, une finisse

carte en circuit imprimé de 8 /10 au module RS232 que vous

avez en principe déjà réalisé.

Sans intercaler, cette fois, un quelconque connecteur de

carte, branchez le tout sur le port série COM1: d'un compa

tible PC. C'est tout !

On pourra avantageusement commencer les manipulations

avec le court logiciel CARS232.BAS, dont le>ôle se limite à

simuler une réponse au reset plausible, puis à afficher en

hexadécimal ce que le lecteur voudra bien transmettre

ensuite à la carte. Le lecteur se croira bel et bien en présen

ce d'une carte asynchrone, et le premier barrage sera franchi.

84


Nos lecteurs pourront alors pousser plus loin leurs investi

gations, en cherchant à simuler telle ou telle carte dont ils

connaissent plus ou moins bien le fonctionnement.

Quelques commentaires s'imposent quant à ce programme,

dont plusieurs éléments serviront debase à tous ceux qu'on

pourra être amené à écrire par la suite, en BASIC ou dans

un autre langage plus performant.

Ce sont essentiellement les mêmes que pour notre logiciel

ESPINV.BAS : ouverture du port série du PC en mode N

(c'est-à-dire sans bit de parité) mais avec deux bits de stop.

Là encore, la compilation sous TURBO-BASIC est intéres

sante, après avoir modifié les réglages en 96OQA&2

L'astuce utilisée pour que la version GWBASIC puisse tout

de même fonctionner en réception (ON ERROR, RESUME)

est inapplicable en sens inverse car les lecteurs de cartes

conformes à la norme ISO 7816 sont plus pointilleux : lors

qu'ils détectent une erreur de parité, ils envoient à la carte

un signal qui consiste en un niveau bas prolongé, puis

attendent une répétition du caractère considéré comme mal

reçu. Dans notre cas, il y aurait blocage !

Il faudra donc se limiter, dans la composition du message de

réponse au reset, â l'utilisation de caractères comportant un

nombre pair de bits à 1. C'est le cas, notamment, de la lettre A.

La routine des lignes 60 et 70 sert pour sa part à attendre

l'arrivée d'une demande de reset. On pourra la réutiliser

ailleurs dans les programmes, afin que la fnaU carte réagis

se correctement à des demandes de reset reçues en cours de

session et pas seulement au début. Cela peut arriver !

On remarquera aussi, comme dans le logiciel ESPINV.BAS,

une routine de conversion en convention ISO inverse utilisée

seulement en réception. A l'émission, nous avons directe

ment opéré la conversion lors de la construction du messa

ge de réponse au reset ; rien de plus simple grâce à la table


de la figure 3.5. La réaction normale d'un lecteur de cartes

recevant une réponse au reset qui lui donne satisfaction est

en général d'émettre une commande à destination de la

carte, à charge pour celle-ci d'y répondre.

Figure 3.5.

Une table de conversion

Nous arrivons bien évidemment là aux limites de ce premier petit programme : il va certes afficher l'ordre émanant du coupleur, mais ne pourra pas y répondre.

Grâce à notre analyseur de protocole, nous savons pourtant ce

que doit répondre la carte dans un certain nombre de situa

tions courantes, et c'est précisément cela qu'il est intéres

sant de reproduire.

À peine plus compliqué que les précédents, le programme

SIMU.BAS permet de reproduire, en GWBAS1C, quelques

fonctions de base d'une carte genre COS : reset, lecture de

deux octets DDDDh à l'adresse AAAAh, et présentation du

code confidentiel CCCCh à l'adresse BBBBh. Cela avec une

classe ISO égale à OOh.

U N M I N I S Y S T È M E D E D E V E L O P P E M E N T

220 H=255 230 IF N>I27 THEN N=N-128 M=M-1

240 IF N>63 THEN N=N-64:M M-2

250 IF N>3l THEN N=N-32:M M-4

260 T F H>I5 THEN N=N-I6:M M-B

270 IF N>7 THEN N=N-8:M=M 16

280 IF N>3 THEN N=N-4:M=M 32

290 IF N>l THEN N=H-2:M=M 64

300 IF N>O THEN M=M-128

310 DS HEXS(M)+" "

320 IF LEN(D$]<3 THEN D$= O'+DS

330 MS M$ + D$

Notons que les premiers octets de la réponse au reset simu

lée informent le lecteur que la carte fonctionne sous une

tension unique de 5 V (pas de V p p externe) et en convention

inverse.

Typiquement, on fera tourner ce petit programme sur un

premier PC équipé du simulateur, tandis qu'un second PC

sera muni du lecteur construit selon la figure 2.2.

Bien entendu, SIMU.BAS sera lancé avant le logiciel de pilo

tage du lecteur, ou tout au moins avant l'envoi à celui-ci


d'un quelconque ordre de mise sous tension de la carte.

0 importera que l'un des deux PC ne soit pas exagérément

I rapide par rapport à l'autre : si l'émulateur fonctionne par

exemple sur un vieil XT à 4,77 MHz, alors il est souhaitable

que le PC muni du lecteur ne tourne pas à plus de 8 MHz

(XT à 8 MHz, ou AT386SX25 sans turbo).

De nombreux hors-temps sont en effet prévus dans les

échanges de données entre carte et lectem>dont tout dépas

sement risquerait fort de bloquer la situation (compte-rendu

carte muette ou Coupleur muet). )

En tout état de cause, un logiciel aussi simplifié ne peut

I prétendre que simuler bien grossièrement, et surtout très partiellement, le fonctionnement fort complexe d'une carte

I à microprocesseur.

ne peut que se borner à montrer à nos lecteurs la voie à

suivre pour mettre au point leurs propres masques écrits

I dans le langage de leur choix, à commencer par l'assem

bleur si on souhaite se fabriquer une fausse, carte autonome à

partir d'un microcontrôieur courant.

U N E C A R T E À P U C E E X P É R I M E N T A L E À P I C 1 6 C X X

I Une carte à puce asynchrone (autrement dit à microproces

seur) n'est finalement rien d'autre qu'un microcontrôleur

Le côté composants

de la carte à PIC16CH4.

8 8

spécial monté dans ce boîtier bien particulier qu'est une carte Le côté cuivre

plastique munie de contacts conformes à la norme ÎSO 7816. de la carte

à P!CI6C84.

Aussi surprenant que cela puisse paraitre de prime abord, il

suffit de câbler un microcontrôleur DIP ou CMS sur un cir

cuit imprimé de 8 / 1 0 mm d'épaisseur pour fabriquer une

fallut' COTte â puce permettant déjà de fort intéressantes

manipulations, naturellement en tout bien tout honneur.

Les P1C16C71 et P1C16C84 de MICROCHIP se prêtent

admirablement à ce genre d'exercice, car nous allons

constater que l'émulation des fonctionnalités de base des

cartes asynchrones ne nécessite finalement que fort peu de

ressources, aussi bien matérielles que logicielles.

Le terme carte asynchrone couramment employé dit bien ce

qu'il veut dire, à savoir qu'une telle carte se contente de

recevoir et d'émettre tour à tour (en hulf-ituple.x) des octets

transmis en mode série asynchrone.

Le cadencement de ces transmissions est confié à un signal

d'horloge fourni a la carte par le lecteur dans lequel on

l'introduit, de telle façon que pour une fréquence d'horloge

de 3,58 MHz environ le rythme de modulation soit de 9 600

bits par seconde.

8 9


I Une seule et même ligne (le contact <• ! / O » de la carte) ser

vant à la fois au transfert d'octets en provenance de la carte

ou destinés à celle-ci, une configuration « OU câblé » est

nécessaire pour éviter tout risque de conflit matériel.

La figure 3.6 montre ainsi comment lecteur et carte dispo

sent tous deux d'elages de sortie à collecteur ouvert (ou à

drain ouvert), une résistance de rappel à Vcc devant être

prévue au moins du côté du lecteur.

Lorsque la ligne de transmission est au niveau haut (son

état de repos), le lecteur ou la carte peut imposer un niveau

bas (bit de start) pour indiquer qu'il commence à trans

mettre. 11 est alors de bon ton que l'autre protagoniste s'abs

tienne de transmettre en même temps, bien que ce genre de

conflit ne puisse en aucun cas avoir d'effets destructifs ni

d'un côté ni de l'autre.

Les paramétres de communication sont fixés par la norme

ISO 7816 : un bit de start, huit bits de données, un bit de

parité paire, et un bit de stop servant également d'indica

teur d'erreur de transmission (un niveau bas recouvrant le

bit de stop constitue une demande de réémission d'un octet

mal reçu).

Nous savons toutefois que deux variantes sont admises : la

convention ISO inverse (bit de poids fort en tête et 1 logique

représenté par un niveau bas), ou plus rarement la convention

ISO directe (poids faible en tète et 1 logique au niveau haut).

C'est la carte qui impose au lecteur l'une de ces deux

conventions, au début de l'émission de sa réponse au reset.

9 0

Figure 3.6.

L'agencement

des entrées-sorties en

« OU câblé ».

U N M I N I S Y S T È M E D E D E V E L O P P E M E N T , 3

Ce groupe d'octets, émis spontanément par la carte lors de

sa mise sous tension et/ou à réception d'un signai sur son

contact de reset, contient de multiples informations sur les

caractéristiques de la carte et permet ainsi au lecteur de s'y

adapter.

Bien entendu, la signification de chaque octet de la réponse

au reset est prévue dans la norme ISO 7816, à l'exception

toutefois des derniers caractères (dits MMMjMi) dont l'usage

est laissé à la discrétion du développeur de l'application.

Cinq contacts suffisent donc pour relier la carte â son lec

teur :

• la masse (CND), ou « ISO 5 » ;

• l'alimentation +5 V (Vcc) ou « ISO 1 » ;

• l'horloge (CLK) ou «ISO 3 » ;

• la ligne de données (I/O) ou « ISO 7 » ;

• l'entrée de reset (RST) ou - ISO 2 ».

Sur certaines cartes de technologie un peu ancienne (à

mémoire EPROM), un sixième contact peut être nécessaire

pour la tension de programmation (Vpp) ou » ISO 6 », tan

dis que deux contacts (ISO 4 et ISO 8) restent en réserve

pour de futurs usages (RFU).

Si le numérotage de ces contacts est imposé sans équivoque

par la norme ISO 7816, en revanche deux positionnements

sont possibles (ISO et AFNOR).

La figure 3.7 résume donc ce qu'il est vital de connaître

pour assurer la correspondance entre les contacts de la carte

et le connecteur du lecteur.

Figure 3.7.

L'affectation

des contacts selon

la norme fSO78l6,

8 RFU 7 I/O B Vpp 5 GND 4 RFU 3 CLK 2 RST 1 Vcc

91


Sur le plan logiciel, rien n'empêche théoriquement de développer un masque de carte asynchrone à partir du jeu d'ins-

: tructions de n'importe quel microcontrôleur.

Pour notre part, nous avons choisi de bénéficier de l'archi-

j tecture RISC rapide des PIC16CXX.

• Bien sûr, les 1024 mots d'EPROM, 36 octets de RAM, et 64

octets d'EEPROM d'un PIC16C84 paraîtront quelque peu : étriqués devant les 3 Ko de ROM, 128 octets de RAM, et 1

Ko d'EEPROM du 68HC055SC24 qui équipe, par exemple,

la dernière génération de Cartes Bancaires [masque M4 BO').

Il convient toutefois de remarquer que le code écrit pour les

PIC est sensiblement plus compact que celui destiné aux

processeurs conventionnels (dits CISC), et que rien n'inter

dit d'associer une EEPROM série externe à n'importe quel

PIC, 16C71 ou même 16C5X, voire de faire travailler deux

PIC en parallèle dans une même carte.

Mais de toute façon, bien des applications pas trop sensibles se

contentent d'une fraction seulement des possibilités des cartes : à microcalculateur conventionnelles, tandis qu'il n'entre nul

lement dans nos intentions d'expliquer ici comment fabriquer

une fausse carte bancaire ou de télévision à péage !

I Cela étant précisé, le mini système d'exploitation que nous

i avons développé pour les PIC16C71 et PIC16C84 (il tient

|1 dans une centaine de mots d'EPROM) suppose la réalisa-

I tion du schéma de la figure 3.8.

m Pourrait-on imaginer plus simple ?

Figure 3.8.

] .t très simple schém;i de la carte à PIC16CXX.

- 9 2 -

Les connexions de masse et d'alimentation rejoignent bien

entendu les contacts ISO correspondants, sans condensateur

de découplage (il n'y en a pas dans les vraies cartes à puce !),

et c'est l'entrée CLKIN qui reçoit directement le signa)

d'horloge fourni par le lecteur : pas besoin de quartz ni

même de réseau RC !

Le signal de reset attaque fort logiquement la broche/MCLR

(master clear) du PIC, tandis que nous avons retenu la

broche RA4 pour l'entrée-sortie série.

Cela en raison de ses caractéristiques électriques bien parti

culières qui, rappelées à la figure 3.9, se prêtent tout parti

culièrement à la réalisation d'un robuste OU câblé avec

l'entrée-sortie du lecteur.

Reste maintenant à construire pour de bon la fausse carte

destinée à nos expérimentations.

Deux tracés de circuit imprimé ont été étudiés : celui de la

figure 3.10 est porteur d'une puce de contact en position ISO

(européenne et donc la seule qui subsistera à terme) et celui

de la figure 3.12 d'une pua* AFNOR (condamnée à dispa

raître progressivement car franco-française).

Figure 3.9.

Sdiem.i equivalent de la br<x:he RA4 des PIC16C84/71.

Figure 3.10,

Le trace du

cuivre de la

« fausse carte » ISO

Figure 3.11.

Plan de

câblage de la

« fausse carte » ISO.

Figure 3.11

de la « fausse carte *

AFNOR.

9 4


figure 3.13.

Plan le câblage

de la « fausse

arte •• AFNOR.

Attention, le sens de montage du PIC est inverse d'une ver

sion à l'autre ; on positionnera donc attentivement le sup

port lii!i]ii que nous ne saurions trop recommander d'inter

caler entre la carte et le PIC.

Bien entendu, la gravure de ces /misses cartes doit se faire

sur de l'époxy présensibilisé de 8 / 1 0 (c'est un produit stan

dard du CIRCUIT IMPRIME FRANÇAIS), parfaitement

compatible avec les connecteurs prévus pour des cartes

épaisses de 0,76 mm.

En principe, les cartes ne pénètrent pas dans les lecteurs

assez loin pour que le PIC et son support puissent arriver

en butée, mais en cas de doute on peut toujours rallonger

un peu les cartes.

De toute façon, ne comptez pas sur nous pour vous faire réali

ser une carte pouvant être az alée par un distributeur de billets...

Ceux de nos lecteurs ayant déjà réalisé la boîte- à outils pour

cartes à puce décrite dans notre livre Cnr(<rs à puce, Initiation

et applications auront tout intérêt à graver plutôt (sur de

l'époxy d'épaisseur normale) le tout petit circuit imprimé

de la figure 3.14.

Figure 3.14.

Le tracé du cuivre

el le pi,m de l'alliage

de l'adaptateur

pour CI6CXX.

9 5


Équipé selon la figure 3.15 de l'habituel tronçon de barrette

sécable à double rangée de picots carrés coudés, pourra

être relié, par le non moins habituel cordon à deux connec

teurs HE10 à dix contacts, à toutes les fausses cartes

universelles déjà développées : ISO et AFNOR, bien sûr,

mais également SIM compatible avec certains téléphones

portables GSM.

Mais passons maintenant à la partie logicielle de cette étude :

Ce que nous pourrions appeler un peu pompeusement le

masque de notre fausse carte à puce a bien entendu été déve

loppé en langage assembleur, en l'occurrence à l'aide des

Ioutils présents dans le kit PICSTART 16B de Microchip.

Le listing est en fait le résultat de l'assemblage (les adresses

de branchement sont calculées) d'un fichier-source nommé

PICPUCE.ASM (fourni sur la disquette).

9 6

Figure 3.15.

Le tracé du cuivre

et le plan de câblage

de l'adaptateur pour

PIC16CXX.

U N M I N I S Y S T È M E D E D E V E L O P P E M E N T J

97

9 8



100

U N M I N I S Y S T È M E D E D E V E L O P P E M E N T , J

IL'opération d'assemblage avec MPALC produit également Figure 3.16.

un fichier 1NTELHFX nommé ITCPUCE.OBJ qui, reproduit L'assemblage

à la figure 3.17 et disponible sur la disquette, est directe- du logiciel

ment compatible avec le programmateur PICSTART de PICPUCE.ASM.

MICROCHIP. D20000000428D2

10000800831608148814831206166620323O9OOO6E

10001800A22090 0BOC283F3O8F2065308F20253090

1000280095200830952031309520043095206C3O8B

100038008F20903 08F2 0003 08F206A207E20BC30A7

100048009106031DA7287E2020309106031DA72 8AE

100058007E207E207E2002309106031DA728662080

10006800A220A220203095206A2 07E20AB30910665

10007800031DA72B7E20CD309106031DA7286620E2

10008800A22 0A22 090308F2 0003 08F206A207E206E

10009800BC309106031DA7287E20B0309106031DB1

1QOOA800A7287E2 07E207E20A220A2206620B03 0B5

1000BB009520CD3 09 520EF30952090308F2 000 3 0 5E

1000C800BF204B2883160512831208008316051605

1000D800831208008D008D09083 08E000512A220B9

1000E80003108DOD03180516031C0512A0208E0B96

1000F800742808009101051A9D289B20083090005B

100108000310910D0 51A1114A2209OOB842B9B2O2E

1001180091090800A2206E200516A2200516A2202B

1001280008006E200512A2200516A2200800223021

. ÎOOI38OOA32 8OE3OA32O7E28IB3OA32 8IC3O8FOO54

: 08014 800 8F0BA4 2 80O34A72846

: 00000001FF

Figure 3.17.

U fichier

INTEL-HEX

de programmation

du PIC.


• Il peut indifféremment être brûlé dans un PIC16C71 (ver-

£ sion effaçable aux UV) ou dans un PIC16C84 {à EEPROM),

Il car nos routines de démonstration ne font pas encore appel

lî à la mémoire EEPROM de ce dernier.

•ai Par contre, il est impératif de neutraliser le chien de garde

I (WDT) et le temporisateur de mise sous tension (PuT), et de

Figure 3.18. I mettre l'oscillateur en mode « XT ».

Préparation

de la programmation Cela en programmant les fusibles appropriés dans le menu

du PIC sous p! du logiciel de programmation MPSTART, conformément à

MPSTART. I la recopie d'écran de la figure 3.18.

I Bien entendu, nos lecteurs désireux de pousser plus loin ; leurs expérimentations (sous leur seule responsabilité !) en J écrivant leurs propres routines applicatives, auront tout ' intérêt à se pencher sur la lecture et l'écriture dans cette

moire non volatile, qui conservera son contenu lorsque I la carte sera retirée de son lecteur.

I Tel qu'U est publié, ce logiciel comprend toutes les routines

de base, soigneusement réglées souvent à un cycle d'horloge

près, permettant d'émettre une réponse au reset fixe, de rece

voir et émettre des octets, et de placer la carte dans un mode

de mutisme dont seule une mise hors tension ou un reset

volontaire pourront la faire sortir (c'est une fonction de

sécurité courante sur les vraies cartes à microprocesseur).

Bien entendu, ce masque comprend aussi toute une série de

is-programmes chargés d'opérations plus élémentaires, à

102

U N M I N I S Y S T È M E D E D E V E L O P P E M E N T , J

1 commencer par les deux routines qui reconstituent logiriel-

I lement l'UART de communication en série.

Loin de devoir être considéré comme une solution au ratais

`M par rapport à un UART matériel, ce choix d'un UART logi-

m ciel est courant dans le monde des cartes à puce car il pré

sente l'avantage d'économiser du silicium : on estime en

effet que la surface occupée par un UART sur la puce serait

m comparable à celle pouvant accueillir 1 500 octets de ROM,

soit pratiquement la totalité de la mémoire du PIC !

Mais un problème s'est naturellement posé quant à la ges-

? tion du bit de parité prévu par la norme : le jeu d'instruc

tions des PIC ne permettant pas d'assurer celle-ci de façon

simple, nous avons pris le parti (comme en GWBASIC !)

d'ignorer carrément, à la reception, le bit de parité ainsi que

l'éventuel signal d'erreur dont l'apparition est en pratique

exceptionnelle. Dans le programme, cela revient tout sim

plement à appeler une routine de temporisation déjà dispo

nible, d'une durée égale à celle du bit à sauter.

En emission, il n'était par contre pas question de faire ainsi

l'impasse sur un bit que contrôlent tous les lecteurs sérieux.

Parlant du principe que dans le cadre de nos manipulations

essentiellement expérimentales on connaît d'avance les Le programmateur

octets à transmettre, nous avons imaginé de prévoir deux PICSTART fourni

routines d'émission distincte-:. par Microchip.

1 0 3


L'une (label even) incorpore d'autorité un bit de parité à 1,

et l'autre (label odd) un bit de parité à 0.

On appellera donc soit l'une soit l'autre, selon que le

nombre de bits de l'octet à transmettre sera pair ou impair.

Naturellement, un bon exercice consisterait à élaborer une

routine de calcul automatique du bit de parité, mais il y a

probablement mieux à faire avec les ressources mémoire

restantes.

Intéressons nous maintenant aux exemples que nous avons

programmés à partir de ces routines de base, et qui devront

être exécutés dans l'ordre lors des essais de la fausse carte

sur le lecteur de la figure 2.2 piloté par le logiciel

INVERSE. BAS.

Le premier exemple fait tout simplement émettre à la carte

une réponse au reset en tout point identique à celle des

cartes bancaires les plus récentes (CP8 M4 BO' à mémoire

EEPROM) ;

3F 65 25 08 31 04 6C 90 00

Il ne s'agit nullement d'une provocation, mais d'un moyen

commode pour signaler au lecteur que notre carte travaille

en « convention inverse » et se contente d'un Vpp de 5 V,

sans pour autant nous fourvoyer dans les méandres de la

programmation d'une réponse au reset sur mesures.

Le second exemple, qui affecte à la carte une dusse ISO BCh

(celle des cartes BULL CP8) programme l'attente de la pré

sentation d'un code confidentiel de deux octets (ABCDh) à

une adresse quelconque.

On remarquera à cette occasion que, conformément à la

norme ISO, le lecteur commence par émettre un bloc de

cinq octets appelé eu-tête, indiquant seulement qu'il se pro

pose de présenter un code :

• BCh (classe ISO de la carte) ;

• 2Oh (code opération « présentation de code ») ;

• un premier octet d'adresse (poids fort) ;

• un second octet d'adresse (poids faible) ;

• un octet précisant la longueur du code (ici 2 octets, soit

O2h).


La carte doit immédiatement répondre par un Otttt de procé

dure identique au code opération de l'instruction présenta

tion de code (2Oh).

Notons que SI elle répondait 2lh (bit de poids faible à 1),

Cela signifierait qu'elle réclame l'application de la tension

Vpp.

Ce n'est qu'après avoir reçu cet octet que le lecteur envoie

les deux octets du code confidentiel, auxquels la carte

répond une dernière fois par les deux octets 9Oh et OOh,

compte-rendu caractéristique d'une opération exécutée avec

succès.

On remarquera qu'à la moindre erreur (classe ISO incorrec

te, code opération différent de 2Oh, code faux, etc.) le pro

gramme va boucler sur une routine (label error) de blocage

de la carte dans un farouche mutisme.

Une vraie carte émettrait plutôt un compte-rendu précisant

la nature de l'incident survenu, comportement que nos lec

teurs pourront essaver de programmer à titre d'exercice

(c'est très facile !)

On remarquera comment l'appel pur et simple de la routine

reç> sans exploitation de son octet de retour permet de sau

ter un octet auquel on ne s'intéresse pas.

Dans le cas présent, il s'agit des deux octets précisant

l'adresse à laquelle le code confidentiel doit être présenté.

La plupart du temps, on présente le code porteur (ou PIN) à

l'adresse OOOOh, mais on pourra vérifier que n'importe quel

le adresse fait ici l'affaire.

Si et senlement si le bon code a bien été présenté, la routine

suivante peut alors être exécutée, un nombre illimité de fois

tant que ne survient pas une irrégularité déviant le pro

gramme vers la boucle de mutisme.

Ce troisième exemple programme la carte pour qu'elle

émette les deux octets CDh et EFh (suivis d'un compte-

rendu 90 00) en réponse à toute demande de lecture de

deux octets (code opération BOh) à une adresse quelconque :

l3Ch ; BOh ; ADR1 ; ADR2 ; O2h


• Bien entendu, un bon exercice serait de spécifier une unique

Jj adresse à laquelle ces données pourraient être lues (huit

instructions seulement à ajouter !).

Les microcontrôleurs TIC pouvant être protégés contre la

relecture de leur programme, on arrive déjà avec très peu

de moyens à une fort bonne sécurité des données ainsi

B incluses dans le corps même du logiciel (et donc dans de la

mémoire EPROM).

; Pour lire ces deux octets, il faut en effet présenter un code

1 confidentiel de deux octets (256 x 256 soit 65 536 combinai

sons possibles), et éventuellement spécifier une adresse

exprimée elle aussi sur deux octets ; une aiguille dans une

: botte de foin, même si rien n'est encore prévu pour mémo

riser (dans un octet d'EEPROM) le nombre de tentatives de

présentation d'un code faux et bloquer définitivement la

carte après trois essais malheureux. Oui, avec un P1C16C84

ce serait étonnamment simple à mettre en œuvre !

Et puisque nous en sommes au chapitre de la sécurité, il est

temps de se livrer à une comparaison objective entre notre

carte expérimentale et les vraies cartes à microprocesseur.

Il doit être parfaitement clair que notre minisystème d'exploitation, même s'il peut bel et bien reproduire les comportements de base de n'importe quelle carte asynchrone, n'arrive pas à la cheville d'un masque de carte COS ou CPS.

U Une vraie carte à microprocesseur dispose, parallèlement à

une capacité mémoire nettement plus importante, de res-

j sources sécuritaires basées, entre autres, sur des algo

rithmes de cryptage permettant d'empêcher qu'on puisse

intercepter puis reproduire un dialogue entre la carte et son

lecteur.

Dépourvue de telles possibilités, notre carte à PIC est donc

relativement piratablc mais ne devrait en aucune façon pou-

'r voir servir â pirater une application correctement protégée.

106


1 Les microprocesseurs des cartes à puce 9

A la découverte z de la carte bancaire 37

% Un mini système de

o développement 73

LES TÉLÉCARTES

4 OU CARTES SYNCHRONES Un mini-lecteur ISO/AFNOR 108

Reconnaissance logicielle des types de puces 117

Télécartes et protection de logiciels 121

La T2G ou télécarte de seconde génération 124

Les cartes « EUROPÉENNES » 134


B i e n q u e n o u s a y o n s d e p u i s l o n g t e m p s a p p r i s à n o s l e c t e u r s

c o m m e n t l i r e e t écr i re d a n s les té lécar tes , i l n 'est a s s u r é m e n t pas

i n u t i l e d e r e v e n i r sur l a q u e s t i o n d a n s c e n o u v e l o u v r a g e .

B i e n des choses o n t e n e f f e t c h a n g é e n q u e l q u e s a n n é e s s e u l e m e n t ,

à c o m m e n c e r par l ' e m p l a c e m e n t des contacts , d é s o r m a i s en p o s i

t i o n I S O sur p r a t i q u e m e n t toutes les cartes à puce .

— 1 0 7

P C C A R T E S A P U C E

Parallèlement, de nombreux pays étrangers se sont « mis à Mi) la puce », et tout porte à croire que ce n'est que le début

d'une generalisation mondiale.

I Mais la micro-électronique a aussi évolué, et il nous faut

j compter maintenant avec les T2C (télécartes françaises de

seconde génération) et les cartes EUROCHIP dérivées de la

[ TELEFONKARTE allemande.

À côté de la « vieille » technologie EPROM NMOS des premières télécartes françaises (qu'il faut désormais appeler TIC), toujours fidèle au poste, au moins deux technologies EEPROM attendent donc que nous nous intéressions à

I elles...

U N M I N I - L E C T E U R I S O / A F N O R

Même si écrire dans les télécartes (de préférence vides

d'unités !) est toujours une expérience passionnante, bien

des applications fort intéressantes ne font appel qu'à leur

lecture.

Débarrassé des circuits servant à gérer la tension de pro

grammation Vpp nécessaire pour écrire dans les cartes â

mémoire EPROM, un lecteur de cartes à puce synchrones

pour PC devient un accessoire extrêmement simple, ali

menté par une pile très ordinaire.

Le lecteur de cartes

L E S T É L É C A R T E S O U C A R T E S S Y N C H R O N E S

Si le schéma de la figure 4.1 est bien évidemment compa- Figure 4.1.

tible avec les logiciels déjà publiés dans nos précédents Le schéma

ouvrages, il n'en comporte pas moins un certain nombre du lecteur de cartes

d'améliorations non négligeables. synchrones.

L'interconnexion des broches 9 et 10 de la fiche DB25 mâle

permet à nos logiciels les plus perfectionnés de reconnaître

automatiquement le port parallèle sur lequel est branché le

lecteur (LPT1 : ou LPT2:).

Facile à ajouter pour une dépense minime à n'importe quel

PC possédant encore un " slot » libre, un second port

Centronics permet en effet de profiter à la fois des services

du lecteur de cartes et de ceux de l'imprimante, sans •• gym

nastique " pénible avec les cordons.

La simple adjonction d'une diode entre les contacts 1 et 11

de cette même fiche rend par ailleurs le lecteur compatible

avec les cartes à ligne de données bidirectionnelle, ce qui est

notamment le cas des cartes « I2C ».

: Naturellement, le tracé du circuit imprimé de la figure 4.2

; exploite les deux jeux de contacts du connecteur (balais ISO

et AFNOR montés en parallèle).

1 0 9

):i Mais un tel lecteur est parfaitement capable d'écrire dans

$ | les cartes de seconde génération, dont la mémoire EEPROM

Il se contente d'une tension d'alimentation unique de 5 volts.


Figure 4L

Le circuit imprimé

du lecteur de cartes

synchrones.

Figure 4.3.

Plan de câblage

du lecteur de cartes

synchrones.

1 1 0 -

L E S T E L E C A R T E S O U C A R T E S S Y N C H R O N E S

I La disquette accompagnant cet ouvrage contient un puis-

sant logiciel intégré supportant la plupart des cartes cou

rantes, et évidemment compatible avec ce lecteur.

H 11 faut « installer » ce programme (CARTE5.EXE) avec l'uti-

I litaire 1NSTALL.EXE et la télécarte de votre choix en guise

de - clef logicielle ».

!frs Mais nous avons prévu également un court programme

H pouvant être considéré comme un « minimum vital », dont

I le principal avantage est une modularité qui ménage au

;: maximum les possibilités d'évolution future du système.

I l l

I» Tandis que les composants de l'alimentation 5 volts, câblés

selon le plan de la figure 4 3 , ont été optimisés pour assurer

une longue autonomie à une simple pile 9 volts alcaline

[ (une centaine d'heures environ de présence effective de

cartes dans le lecteur, ce qui est considérable).

1 .es dimensions de ce petit montage permettent une « mise

en boîte » commode dans la plupart des coffrets plastique

: de type calculatrice » avec logement de pile.

On y pratiquera simplement une fente d'introduction des

cartes en face du connecteur, un trou pour la Led témoin de

mise sous tension, et un autre pour le câble de liaison au PC.

Liste des composants

1 connecteur de cartes 1TT-CANNON.

j 1 régulateur 78LO5.

1 Led rouge.

1 diode IN 4148.

1 résistance 10 ft 1 /4 W.

J 1 résistance 3,9 kft 1/4 W.

I pile 9 V et son clip.

m 1 fiche DB25 mâle.

W\ 1 m (maximum) de câble souple 5 conducteurs.

1 boîtier « calculatrice » avec logement de pile 9 V.


1 1 2

L E S T E L E C A R T E S O U C A R T E S S Y N C H R O N E S f t

En effet, M1NILECT.BAS se contente de lire 256 bits consé

cutifs dans la carte préalablement remise à zéro {reset), mais

avec une possibilité de sauvegarde sur disque, dans le for

mat « .CAR " que nous avons défini et utilisé dans nos pré

cédents ouvrages sur la question. La compatibilité est donc

assurée !

Tel qu'il est présenté, M1NILECT.BAS attend le lecteur sur le port parallèle LPT1:, mais il suffit d'effacer sa ligne 40 pour pouvoir utiliser LPT2:.


ck GUEULLE"

Figure 4.4. Les possibilités

du logiciel T1G.BAS.


Strictement réservé aux télécartes françaises de première génération (code famille commençant par un zéro), le logiciel T1C.BAS peut venir décrypter les fichiers ainsi extraits des cartes lues par M1NILECT.BAS, pour en tirer un maximum d'informations dont la figure 4.4 montre un échantillonner.

On notera que la fonction « contrôle de parité » permet de

vérifier que le contenu de la « zone de fabrication •• (les 96

premiers bits protégés par le fameux « fusible > ) est vrai

semblable.

Un seul bit altéré (ce qui n'a rien d'impossible sur des

cartes vieilles de plus de dix ans et conservées dans de

mauvaises conditions) ferait échouer le test.

Le décodage du •< message d'authenticité vient pour sa

part compléter celui du numéro de série, dont il certifie en

quelque sorte l'origine puisqu'il est calculé selon une for

mule ultra-secrète...

L'affichage hexadécimal offre enfin une •• image " particu

lièrement compacte, et plus parlante pour certains que de

simples blocs de quatre bits.

Nous découvrirons plus loin dans ce chapitre l'équivalent

de ce logiciel pour les T2G et pour les cartes EUROCHIP,

tandis qu'il ne serait pas bien compliqué de développer des

versions spécifiques pour d'autres familles de cartes (par

exemple des télécartes étrangères a mémoire EPROM).

La disquette d'accompagnement de cet ouvrage contient

d'ailleurs une sélection de véritables fichiers » CAR per

mettant de commencer à expérimenter même sans lecteur

ni cartes !

R E C O N N A I S S A N C E L O G I C I E L L E D E S T Y P E S

D E P U C E S

Bien que les collectionneurs de télécartes appellent volontiers " puce » le •• micronu>dule », ce n'est pas cela, la puce électronique proprement dite, cette fameuse mémoire dans laquelle sont emmagasinées les unités !

Petit carré de silicium d'environ un millimètre de côté seulement, le véritable cœur des cartes à puce est en réalité collé au dos de ce groupe de six ou huit contacts.

117


Noyée dans l'épaisseur du plastique de la carte, la puce

mémoire reste donc le plus souvent invisible.

On la devine plus ou moins au verso des cartes à pastilles

» transparentes, marron ou blanches, mais pas sur les cartes

à pastille noire ou sans pastille du tout.

Sur certains spécimens, notamment de fabrication

Sehlumberger, la résine transparente est suffisamment limpide

pour qu'on arrive à voir plus ou moins correctement la puce.

11 apparaît ainsi que toutes les télécartes ne sont pas équi

pées du même modèle de puce silicium, dont de patientes

recherches nous ont permis de mettre en évidence au moins

trois versions.

La plus ancienne est facilement reconnaissable aux grandes

lettres <` ET » (cinq centièmes de millimètre de haut...) ins

crites dans l'angle d'une vaste surface sombre pratiquement

visible à l'œil nu.

Il faut par contre un microscope pour arriver â lire la date

du masque (1983) gravée vers le centre de cette puce ET

1001 : les chiffres sont hauts d'à peine 20 microns, c'est-à-

dire de même pas deux centièmes de millimètre !

Plus récente et concurrente, la puce « TMS 3561 « de Texas

Instruments porte la date de masque 1986. Un peu plus

I,a puce de télécarte

ET 1001 vue au

microscope

, 1 8


petite que la puce HT [001, elle est facilement identifiable

(au microscope) par le logo de la marque (un T et un I

imbriqués) gravé dans un coin.

On la rencontre couramment sur certaines séries de télé

cartes de fabrication SCHLUMBERCER ou SOLAIC, mais

nous n'en avons par contre jamais trouvé encore dans des

cartes GEMPLUS. Cela pourrait être une conséquence des

liens historiques de la firme avec SC.S-Thomson.

Mais la puce la plus commune, celle qui équipe la plupart

des télécartes fabriquées aujourd'hui et qui ne sera sans

doute détrônée que par la T2G, est la « TS 1001 ` , précisé

ment de marque SGS-Thomson (date de masque 1987).

C'est la plus petite des trois (et donc sans doute la plus éco

nomique à fabriquer car la surface coûte cher), et elle res

semble fort à une ET 1001 de laquelle on aurait éliminé

toute la place perdue.

Il est intéressant de remarquer que les puces Texas et SGS-

Thomson ne réagissent pas tout à fait de la même manière

aux opérations de lecture.

Les puces Texas présentent le bit lu sur le contact ÎSO7 juste

après le front montant de l'impulsion d'horloge, tandis que

les puces SGS-Thomson attendent pour ce faire le retour à

zéro du signal d'horloge.

I.,i puœde télécarte

TMS 3561 vue au

1 1 9


l ]ar ailleurs, la puce SGS-Thomson ne peut être lue qu'en

présence d'un Vpp d'au moins 5 volts, alors que celle de

Texas Instruments tolère que celui-ci soit à zéro.

Il n'en fallait pas davantage pour que nous imaginions un

petit algorithme de reconnaissance de puces, qui se traduit

en pratique par le programme TEXAS.BAS.

Mais nous l'avons également incorporé dans notre logiciel

CARTES.EXE, car son intérêt est évident pour les collec

tionneurs : la présence d'une puce plutôt que d'une autre à

l'intérieur de certaines variétés de télécartes peut en effet

dans certains cas constituer une rareté de grande valeur !


T É L É C A R T E S E T P R O T E C T I O N D E L O G I C I E L S

Si notre logiciel CARTES.EXE est muni d'une protection

contre la copie par télécarte-clef, c'est surtout à titre de

démonstration de ce que l'on peut obtenir par des moyens

l. somme toute fort simples.

À vrai dire, toute personne disposant de l'utilitaire INS

TALL.EXE peut créer autant de copies qu'elle possède de

télécaries pouvant servir de clefs.

En revanche, CARTES EXE installé sur une disquette (ou un

disque dur) ne contenant pas (ou plus) INSTALL.EXE ne

pourra être lancé qu'en présence de la seule télécarte-clef

ayant servi â son installation.

Chacun pourra protéger selon le même principe (mais avec

un algorithme légèrement différent) ses propres pro

grammes compilés sous TURBO-BASIC grâce à l'utilitaire

PROTECT.BAS.

121


La marche à suivre est simple : il faut incorporer le module

de protection l'ROTECE.BAS dans le code source du logi

ciel à protéger (écrit en C`.WBASIC), en faisant en sorte qu'il

soit exécuté en tout premier lieu lors d'un RUN.

1 REM PROTEGE.BAS

2 DSF SEG=O: KEY OFF

3 Sl=PEEK(6H4O8).256*PEEK{&H4O9>

4 S2 = PEEKUH4OA ) - t256*PEEK[&H4OB)

5 OUT S2,0:E2=S2+1

6 IF IINP(E2) AND 64) <> 0 THEN S=Sl:GOTO 15

7 OUT S2 , I 2 8

8 IF (INP(E2) AND 64] <> 64 THEN S=Sl:GOTO 15

9 S = S2

15 E=S + 1

20 DIM N(256):DIM M(256>

30 CLS:PRINT"LOGICIEL PROTEGE PAR TELECARTE"

40 PRINT`===="" = = = " = = ======="===== = ="

41 PRINT" [C)I992,I995 Patrick GUEULLE": PRINT

45 IF S=S2 THEN PRINT" (lecteur sur LPT2:)"

46 IF S=Sl THEN PRINT" (lecteur sur LPT1 : ) "

47 GOStlB 5000

50 CLS:FOR F=l TO 10

55 PRINT"CARTE-CLEF RECONNUE, EXECUTION

AUTORISEE*

60 PRINT:NEXT F

4999 END

5000 PRINT:PRINT"Insérer la carte-clef,

puis presser ENTER"

5010 BEEP:INPUT ZS:CLS:KK$=`"

5020 OUT S,25O:OUT S,248

^ t n * . i m i l / Ê

Cela fait, on compilera le tout sous TURBO-BASIC de façon

à obtenir un fichier " .EXE », dont il n'est d'ailleurs pas

interdit de diminuer la taille à l'aide du shareware LZEXE,

ou d'un compacteur du commerce tel que SHRINKER de

BLINKinc.

Ce même exécutable pourra être copié directement sur

toutes les disquettes que l'on se propose de distribuer, mais

il ne fonctionnera pas sans un • fichier secret » élaboré par

PROTECT.BAS.

Ledit fichier sera préparé a partir de la télécarte qu'on four

nira en tant que clef (accompagnée du lecteur ad Iwc), ou

dont on montera la puce dans un « dongle » maison (voir

notre ouvrage Montages à composants programmables dans

cette même collection).

Imaginons que le logiciel à protéger, déjà compilé (par

exemple PROTEGE.EXE) est stocké avec PROTECT.EXE

(version compilée de PROTECT.BAS) sur un disque placé

dans le lecteur B.

Pour produire une version protégée sur une disquette pla

cée dans le lecteur A, on fera successivement les opérations

suivantes à partir de A :

• 1. COPY B:PROTEGE.EXE

• 2. B:PROTECT

123

L E S T E L E C A R T E S O U C A R T E S S Y N C H R O N E S * ±


Bien entendu, on insérera une télécarte dans le lecteur

approprié lorsque PROTECT.EXL ; le demandera, puis on

rangera celle-ci avec la disquette qui lui est maintenant liée,

sur laquelle un fichier supplémentaire nommé •• Î995.(c) »

s'est trouvé créé.

Lors de chacun de ses lancements, le logiciel protégé

demandera l'introduction de la télécarte-clef dans son lec

teur, la lira, et comparera son contenu â son • image » cryp

tée contenue dans le fichier secret. S'il y a concordance,

alors le logiciel s'exécutera normalement, mais dans le cas

contraire seul un message d'erreur s'affichera.

Bien entendu, chacun pourra apporter des modifications de

son cru à l'algorithme utilisé par PROTECT.BAS, à condi

tion de faire exactement de même dans le module de pro

tection du logiciel à protéger.

Le plus simple est d'intervenir au niveau du OU exclusif,

mais on pourrait aussi songer à utiliser un fichier caché, ou

toute autre astuce personnelle.

L A T 2 G O U T E L E C A R T E D E S E C O N D E

G É N É R A T I O N

|i Depuis 1983, l'industrie des semi-conducteurs a considéra

blement évolué.

La technologie NMOS, qui sert encore à produire les puces des actuelles télécartes (TIC), est arrivée au seuil de l'obso-

: lescence et devrait être progressivement abandonnée par les fabricants.

FRANCE TELECOM a donc imaginé dès l%9 de passer en

I CMOS, quitte à profiter de l'occasion pour améliorer les

fonctionnalités du produit sans pour autant en augmenter

I le prix de revient.

I Après une phase d'expérimentation « terrain » sur 100 000

cartes fin 1993, l'adaptation de l'ensemble du parc de publi

phones â carte est maintenant achevée.

Exécutée à l'insu de la plupart des usagers, cette opération

se traduira pourtant un jour ou l'autre par la péremption

j des TIC encore en circulation, bien que celles-ci ne portent

`, aucune date limite de validité et que leur utilisation ait été

' payée d'avance...

124

L E S T E L E C A R T E S O U C A R T E S S Y N C H R O N E S 4Jfc

1 2 5

li' remplacement de I'<U`UIL`IIO mémoire EPROM par une

EEPROM spécifique développée en partenariat avec SGS-

Thomson permet de concilier une simplification du matériel

{six contacts au lieu de huit, pas de Vpp externe), avec une

plus grande souplesse du produit.

Il est par exemple possible de préprogrammer certaines

T2G pour qu'elles ne puissent servit à appeler qu'un seul et

unique numéro.

Réinscriptible (et donc peut-être un jour rechargeable ?), la

T2G peut contenir des milliers d'unités.

\ Elle serait donc d'ores et déjà apte à supporter la taxation

à la seconde •> qui, il faut l'espérer, sera un jour appliquée

aussi aux cabines publiques.

Grâce à un mécanisme d'authe tification par » certificat »

et calcul de signature à partir de clefs secrètes internes, la

T2G est également plus sûre que la T1G dont les possibilités

latentes de •• clonage introduisent, dit-on, un sérieux point

faible dans la sécurité du système.

Rien d'étonnant donc à ce que les caractéristiques tech

niques détaillées des T2G soient tenues secrètes.

Aimablement fournies par SGS-Thomson, les informations

que nous allons néanmoins dévoiler ici s, rapportent dont

au composant ST 1333, celui équipant les T2G s'appelait

pour sa part ST 1332 ou ST 1303.


fort heureusement, les différences apparaissent sufhsam-

yï ment minimes pour ne pas nous gêner dans nos tentatives

de lecture, voire même d'écriture.

La figure 4.5 reproduit la cartographie mémoire du ST 1333,

à partir de laquelle nous avons mené nos investigations.

• Le résultat de celles-ci est reproduit, sous toutes réserves, à

(1) Code service : 0000= T2G STANDARD, 1001=T2G EUROSTAR. etc.

(2) N'dectef?

(3) Pouvoir financier : 120 unités-1 100 (12), 50 unltes=OIOI (5),

5 ou 10 unités: 0001 (1), etc.

(4) Compteurs xi etx8 : Bit de droite toujours à 1.

(5) 0 pendant la vie de la carte, écriture avec retenue efface le certificat.

(6) Fusibles?

17} Seulement sur T2G récentes (sinon, repique ligne précédente] Répertoire de numéro(s)

Figure 4.b.

Le contenu suppose

de la T2G.

1 2 6 -


PROTOCOLE 6 CONTACTS' : T2G. GPM2S6

La figure 4.7 montre en effet que le protocole de communication employé (dit « à 6 contacts ») est compatible avec celui des T1G. Simplement, une micro-instruction de comparaison de bit semble taire son apparition. Il n'est pas interdit de penser que celle-ci pourrait avoir un rapport avec la procédure île sécurisation cryptogi-aphique au sujet de laquelle nous n'avons pu apprendre que fort peu de choses.

Elle s'apparenterait à la fois au DES et au RSA, par le biais

d'une « signature • de 4 bits et d'une « clef secrète

d'authentification » de 64 bits, illisible de l'extérieur

puisque - masquée » par des « 1 ». Elle utiliserait aussi une

mémoire RAM * fantôme », accessible en écriture par les

adresses 0 â .11, et lisible aux adresses 192 à 223, ou 224 à

255. L'écriture dans cette RAM entraîne en effet une altéra

tion de la signature (adresses 256 à 259).

D'un autre côté, des logiciels d'analyse 1res spécifiques vont

devoir être mis en œuvre, car les unités sont comptabilisées

d'une façon radicalement différente.

Apres le • rode l'ro 1 lectron • a 16 hits qui paraît pour

l'instant être commun à toutes les T2G (8l4Oh), on trouve

48 bits abritant notamment le numéro de série de la carte et

son « pouvoir financier » (indication codée du nombre

Figure 4.7. Le jeu de

« mien M SI rue lions suppose de la T2G.

127

Il apparaît immédiatement que l'espace adressable est plus

vaste que celui des T1G (le compteur d'adresses ne « fait le

tour »• qu'à 512).

La /.one la plus intéressante â lire coïncide toutefois avec les

256 premiers bits, ce qui signifie qu'on pourra se servir du

même format de fichiers « .CAR », et dans une certaine

mesure des mêmes lecteurs et des mêmes logiciels de lectu

re (M1NILECT.BAS et naturellement CARTES.EXE).


1 2 8

d'unités dont elle a été chargée, Ofifa pour 50 unités ou OCh

pour 120 unités).

Suivent 40 bits organist's en « compteurs » de huit bits chacun.

Grâce à un « plan de comptage » inspiré du principe des

bouliers, ces 40 bits pourraient théoriquement permettre de

comptabiliser jusqu'à 32767 unités !

En effet, la technologie EEPROM présente cette particulari

té remarquable d'être " réinscriptible » : un « 0 » peut être

transformé en « 1 », mais un « 1 » peut tout aussi bien être

transformé en « 0 ».

Dans le cas de la T2G, on peut librement transformer, de l'extérieur, des « 0 » en « 1 » pour consommer des unités. Mais c'est la carte elle-même, sous le contrôle de sa logique interne, qui a le privilège de remettre à « 0 » des bits qui étaient à « 1 ».

Bien entendu, cette manœuvre n'étant pas, dans l'état actuel

des choses, destinée à recharger la carte, il faut débiter ici

ce que l'on crédite là.

Chaque bit d'un compteur donné ayant une valeur, expri

mée en unités, huit fois plus forte que celle d'un bit du

compteur qui le suit dans l'ordre des adresses, l'astuce

consiste à mettre simultanément un bit à « 1 » dans un

compteur et huit bits à <` 0 » dans le compteur suivant.

En pratique, trois compteurs seulement sont suffisants pour

des T2G de 120 unités : un » par 1 », un - par 8 », et un

« par 64 ••.

Notons toutefois que le bit de droite des deux compteurs de

poids faible est invariablement positionné à 1.

Notre logiciel T2G HAS applique le mécanisme ainsi défini

pour déterminer le crédit d'une carte à partir du fichier

« .CAR » lu dans celle-ci.


Bien entendu, nous en avons également incorporé les fonc

tionnalités (en mieux !) dans CARTES.EXE.


Rien ne garantit toutefois la pérennité de ces programmes

si d'aventure des T2G spéciales devaient être développées â

l'occasion d'une éventuelle adaptation des publiphones à la

« taxation à la seconde », ou bien si la France finissait par se

rallier à un quelconque projet de •• télécarte européenne ».

On peut suivre le processus de comptage sur les deux

" images-carte » de la figure 4.8, qui correspondent respec

tivement à une T2G de 50 unités neuve, et â une T2G 50

épuisée.

Pour plus de clarté, nous avons repéré les différents comp

teurs, dont deux demeurent pour l'instant au repos.

L'un (actuellement toujours à zéro) servira fort probable

ment un jour à compter « par 512 », tandis que le compor

tement du second est plus curieux.

Pendant la phase d'utilisation de la carte, nous y avons tou

jours trouvé sept bits à 1 et un bit à 0 (celui de gauche).

Il semblerait cependant que celui-ci passe à 1 lorsque la der

nière unité se trouve consommée, du moins sur les T2G les

plus récentes.

Simultanément, le certificat •> occupant les bits 112 à 127

semblerait être remis à zéro.

Figure 4.8.

Deux « images-carre

de T2G lues avec

M1NILECT.BAS.


GttUÉM cartes très proches des T2G disposent d'une procédure comparable permettant de les recharger en unités, un nouveau certificat étant inscrit à cette occasion pour authentifier l'opération.

Un bit étant alors écrit dans un compteur spécial, dit « de

rechargements », il est bien tentant de faire le rapprochement.

Le plus surprenant est qu'avec une carte réputée aussi sûre,

on prenne ainsi la peine (ou le risque ?) d'effacer un certifi

cat périmé, manœuvre qui permet à n'importe qui d'écrire

n'importe quoi à sa place...

À partir de l'adresse 256, c'est-à-dire au-delà de ce que lit normalement un logiciel destiné aux T1G, on trouve une

signature » à quatre bits qui change spontanément dès qu'un quelconque bit est modifié dans la carte, y compris dans sa RAM « fantôme ».

Grâce à son « module de sécurité » se présentant lui-même

sous la forme d'une carte à puce, le publiphone serait

capable de « prédire •• à tout moment la signature que va

émettre la télécarte.

Bien entendu, toute discordance entre ce qui est attendu et ce qui est effectivement reçu serait interprétée comme une anomalie, autrement dit comme une tentative de fraude même s'il ne s'agit que d'un mauvais contact électrique. Notons toutefois qu'une signature aléatoire aurait tout de même une chance sur seize d'être reconnue comme exacte, puisque quatre bits ne peuvent déterminer que seize combinaisons distinctes.

Sans espérer percer tous les secrets de cette signature cryp

tographique, il est intéressant d'observer comment sa

valeur évolue. On remarquera par exemple que son chan

gement n'est pas immédiat, mais qu'il semble se faire à

l'occasion du passage par zéro du compteur d'adresses.

Le petit programme SIGNT2C.BAS, par exemple, suffit pour procéder à quelques observations.

1 3 1


Les résultats obtenus semblent confirmer que même si on

ne modifie en rien le contenu de la carte, la signature chan

ge bien à chaque " tour " du compteur, avec évidemment

des répétitions puisque la signature ne peut prendre que

seize valeurs distinctes.

Cette particularité pourrait fort bien permettre d'utiliser

une T2G épuisée comme un générateur de clefs rudimentai-

re pour toutes sortes d'applications cryptographiques

simples.

La " clef maîtresse " pourrait alors être changée de temps à

autre en écrivant un bit dans la zone des compteurs ou du

certificat.


1 3 3

Dans les mêmes parages que la clef, quelques bits (quatre ?)

reproduiraient aussi l'état de « fusibles » internes liés aux

différentes étapes de la vie de la carte, depuis sa <• person

nalisation » jusqu'à sa phase finale d'utilisation.

Un peu plus loin se trouvent les « flags anti-arrachement ». Ces bits servent à éviter toute perte d'unités pour l'utilisateur de la carte s'il retire celle-ci avant la fin d'un processus de o retenue ».

A chaque bit des compteurs par 64 » et « par 8 » corres

pond un bit ou « flag » occupant la même position dans

l'un des deux registres « anti-arrachement ».

Normalement à 0, le flag est mis à 1 en même temps que la

retenue, mais il est remis à 0 en même temps que le comp

teur de poids inférieur.

Si la carte est « arrachée » entre ces deux opérations, le flag

reste bien évidemment à 1 et autorise, lors de la prochaine

insertion de la carte, la remise à zéro du compteur sans ins

cription d'une retenue.

D'un point de vue comptable, l'incident est alors clos.

Il est possible de faire jouer ce mécanisme, qui n'intervient

normalement qu'à titre tout à fait exceptionnel, en écour-

tant volontairement l'impulsion servant à exécuter une opé

ration d'écriture avec retenue (logiciel MAMPT2G.BAS de

l'édition avec disquette de notre ouvrage Cartes à puce,

initiation et applications).

Est-il besoin de préciser que les flags anti-arrachement ne

peuvent être mis à 1 que par la logique interne de la carte,

et en aucun cas sur un ordre provenant de l'extérieur ?

En poursuivant l'exploration de la mémoire des T2G

récentes, on trouve enfin une zone (de 320 â 367) dans

laquelle il est possible d'écrire librement (transformation de

O e n l ) .

Certaines cartes proches de la T2G supportent également

l'effacement dans cette zone (transformation de 1 en 0).

11 semblerait que cette partie de la mémoire soit destinée à

accueillir un ou deux numéros de téléphone que la télécar

te permettrait d'appeler de façon automatique.


En principe, l'espace adressable des T1G se termine ici,

mais le compteur d'adresses ne i fait le lour •> qu'à 512. La

lecture de la zone située entre les deux n'est donc probable

ment pas significative, bien que des groupes de 1 et de 0

puissent y être observés.

LES C A R T E S « E U R O P É E N N E S »

Venue à la carte à puce plusieurs années après la France,

l'Allemagne a pu bénéficier d'une technologie plus moder

ne pour sa Telefonkarte.

Déjà munie d'une mémoire EEI'ROM, sa puce Siemens qui

possède maintenant de nombreux équivalents, préfigurait

• déjà notre T2G (mais sans sécurisation cryptographique).

Sa dernière version en date, dite « Eurochip -, intègre cette

fois des fonctions sécuritaires qui n'ont apparemment rien à

envier à celles de la T2G.

Toujours d'origine Siemens (avec une seconde source chez

Philips), cette puce est progressivement adoptée par les

principaux pays européens (Allemagne, Pays-Bas, Suisse,

Grande-Bretagne, etc.)

Il est fort tentant de voir dans l'Eurochip une réplique aux

ambitions internationales de ta T2G, exclusivement fabri

quée par SGS-Thomson, voire même une forme de

revanche sur l'avance française en matière de cartes à puce.

1 3 4

compatible avec

la Telefonkarte.


Mais après tout, pas une seule T1G française ne semble

avoir été équipée de la puce Siemens compatible, tandis que

SGS-Thomson s'est fort bien placé sur le marché de la

Telefonkarte.

Ceci explique peut-être cela...

La similitude de la première Telefonkarte avec la T2G est évidente au niveau de la cartographie de la figure 4.9, tout au moins au niveau de ses 104 premiers bits puisque l'ancêtre de l'Eurochip n'en contient pas davantage.

Simplement, le compteur de « poids fort » (D5) ne possède

que cinq bits, ce qui limite théoriquement les possibilités de

comptage à 25 160 unités (les fabricants ne commettraient-

ils pas une grossière erreur d'arithmétique en annonçant

20 480 ?)

Les trois bits ainsi exclus de la /one de comptage sont deux

bits de test (b65 et b66), et un bit servant de « verrou » en

fin de personnalisation (b64) : en quelque sorte un

" fusible logiciel.

Le protocole de communication est par contre sensiblement

différent de celui de la T2G ou même de la T1G et, il faut

bien le reconnaître, plus conforme aux normes ISO.

Celles-ci n'en étaient en effet qu'à leurs balbutiements lors

du lancement des premières télécartes françaises, avec les

quelles la T2G se doit de maintenir un certain degré de

compatibilité matérielle.

1 3 5

Figure 4.9.

Cartographie

mémoire de la

Telefonkarte.


Une puce Armel

compatible avec

la Telefonkarte.

On constate à la figure 4.10 qu'il s'agit d'un protocole « 5

contacts », et que la carte est du type « vierge à 1 » : pour y

consommer des unités, on y transforme des « 1 » en « 0 ».

Attention ! Ce protocole est incompatible avec les modali

tés de reset de la TIC, et la lecture sera donc décalée d'un

bit si on se sert des mêmes logiciels (M1NILECT.BAS ou

CARTES.EXE). Il suffit de le savoir, et d'en tenir compte si

nécessaire.

Figure 4.10. Le jeu de micnvins-trucuons « de la TELEFONKARTE

PHOTOCOUE '5 CONTACTS' : EUROCHIP

Pour les applications les plus critiques, on se tournera de

préférence vers les logiciels plus spécifiques fournis dans

notre ouvrage Cartes à puer. Initiation cl applications (édition

avec disquette).

Le principe de comptage, toujours basé sur la technique du

" boulier », fait appel à une préprogrammation des comp

teurs lors de l'émission de la carte, de telle façon oue tous


leurs bits se retrouvent à « 0 » une fois le crédit de la carte

épuisé.

En l'absence de toute sécurisation cryptographique, c'était

encore le moyen le plus sûr pour éviter les rechargements

frauduleux...

Les deux < images-carte » de la figure 4.11 se composent

toujours des 256 bits que nous avons pris l'habitude de lire.

Le contenu utile de la carte y figure en double, puisque le

compteur d'adresses « fait le tour » au bout de 128 impul

sions d'horloge. Cette particularité permet de reconnaître

les cartes les plus anciennes, car elle n'affecte pas les puces

plus récentes.

On remarquera une mise à contribution de quatre comp

teurs seulement sur les cinq disponibles.

La raison est simple : on compte des unités monétaires

(pfennigs en Allemagne, pence au Royaume-Uni ou à

Guernesey, etc.) et non plus des unités téléphoniques.

Ainsi, une Telefonkarte de 40 unités contient en réalité

1 200 Pf, c'est-à-dire 12 DM. Dans de telles conditions, le

passage à une « taxation à la seconde » n'est évidemment

plus qu'une simple formalité.

Figure 4.11.

Deux « images-carte »

de Telefonkarte.


i d'unités dont elle .1 été chargée, O5h pour 50 unités ou OCh

î pour 120 unités).

I Suivent 40 bits organisés en compteurs > de huit bits chacun.

1 Grâce à un « plan de comptage » inspiré du principe des

I bouliers, ces 40 bits pourraient théoriquement permettre de

i comptabiliser jusqu'à 32767 unités !

En effet, la technologie EEPROM présente cette particulari

té remarquable d'être réinscriptible » : un •< 0 > peut être

transformé en 1 », mais un « 1 » peul tout aussi bien être

: transformé en « 0 ».

! Dans le cas de la T2G, on peut librement transformer, de

l'extérieur, des « 0 » en « 1 » pour consommer des unités.

I Mais c'est la carte elle-même, sous le contrôle de sa logique

interne, qui a le privilege de remettre à - 0 » des bits qui

étaient à « 1 ».

Bien entendu, cette manœuvre n'étant pas, dans l'état actuel

\ des choses, destinée à recharger la carte, il faut débiter ici

e que l'on crédite là.

j Chaque bit d'un compteur donné ayant une valeur, expri-

; mée en unités, huit fois plus forte que celle d'un bit du

compteur qui le suit dans l'ordre des adresses, l'astuce

consiste à mettre simultanément un bit à » 1 » dans un

compteur et huit bits à « 0 » dans le compteur suivant.

En pratique, trois compteurs seulement sont suffisants pour ! des T2G de 120 unités : un « par 1 », un « par 8 », et un

« par 64 ».

Notons toutefois que le bit de droite des deux compteurs de

poids faible est invariablement positionné à 1.

: Notre logiciel T2G.BAS applique le mécanisme ainsi défini

pour déterminer le crédit d'une carte à partir du fichier

• .CAR > lu dans celle-ci.


CARTES.EXE fait naturellement de même tout en détermi

nant, autant que possible, la nationalité de la carte, son

fabricant, et la devise dans laquelle elle fonctionne.

Bien que largement compatible au niveau des compteurs

d'unités (tous à 8 bits), la nouvelle carte Eurochip affiche

une structure mémoire plus complexe.

La figure 4.12 montre que, d'après la documentation

Siemens, le contenu utile de la mémoire se compose de 237

bits répartis entre des zones de ROM (dont 16 bits pro

grammés par masque), de PROM, et d'Eh'I'ROM.

Nos investigations personnelles, résumées à la figure 4.13,

mettent cependant en évidence une zone à écriture libre

située de 320 à 383, le compteur d'adresses « faisant le

tour » à 512.

Il est donc clair que des zones inutilisées doivent être

imbriquées entre les zones utiles.

y a là matière à de passionnantes recherches, car les

« petits secrets •> de !'Eurochip font l'objet de la plus extrê

me discrétion.

Il semblerait même que chaque pays utilisant des télécartes Eurochip bénéficie d'une version personnalisée du composant, présentant un certain nombre de particularités ultrasecrètes, notamment sur le plan cryptographique.

Figure 4.12.

Cartographie

de l'Eurochip

d'après

Siemens.


1 4 0

Figure 4.13.

Les résultats

d'une exploration

La pute Siemens

d'une carte F.uruchip


1 Les microprocesseurs

des cartes â puce 9

2 À la découverte

de la carte bancaire 37

3 Un mini système de développement 73

4 Les télécartes ou

cartes synchrones 107

5 LA DISQUETTE DU LIVRE Organisation de la disquette 142

Installation de la disquette 148

Mode d'emploi de CARTES.EXE 149

L a d i s q u e t t e a c c o m p a g n a n t cet o u v r a g e est l e f r u i t d e p l u s i e u r s

a n n é e s de pa t i en tes recherches m e n é e s avec p a s s i o n a u t o u r de ces

ob je ts f a s c i n a n t s q u e sont les cartes à p u c e .

C e t t e b i b l i o t h è q u e d e log ic ie ls u n i q u e e n son g e n r e r e g r o u p e les

d i f f é r e n t s p r o g r a m m e s d u p r é s e n t o u v r a g e , e t u n c e r t a i n n o m b r e

d ' a u t r e s f i ch ie rs in téressants ou u t i l es .

La toute d e r n i è r e é d i t i o n d e n o t r e l i v r e Cartes à puce, Initiation et

applications, d o n t ce v o l u m e c o n s t i t u e La s u i t e l o g i q u e , b é n é f i c i e

é g a l e m e n t d e cette f o r m u l e .

1 4 1


I Nous ne craignons pas d'affirmer qu'une telle somme

d'informations et d'outils donne au possesseur de nos deux

• ouvrages les moyens d'aller, moyennant un peu d'imagina

tion, jusqu'au bout de ce que l'amateur peut raisonnable-

; ment espérer apprendre et entreprendre sur les cartes à

i puce en tous genres.

O R G A N I S A T I O N D E L A D I S Q U E T T E

Cette disquette a été composée de façon à être utilisable sur

la plupart des compatibles PC équipes d'un lecteur • haute

densité » (1,44 Mo), mais beaucoup des logiciels qu'elle

contient peuvent fonctionner, au ralenti, sur les matériels

les plus anciens (8088 à 4,77 MHz), à condition d'être copiés

sur une disquette compatible.

Voici ce que doit contenir la disquette originale :

T2G BAS 1 039 30/10/97 \2 : 30 T2G.BAS

CARS232 BAS 873 05/03/95 18: 56 CARS232.BAS

CB2PIN BAS 706 05/03/95 18: 51 CB2PIN.BAS

EURO BAS 331 05/03/95 19: 07 EURO.BAS

MINILECT BAS 1 262 08/04/95 9: :22 MINILECT.BAS

MODULO BAS 284 2 6/03/95 11! 16 MODULO.BAS

PIN2CB BAS 695 05/03/95 18: 50 PIN2CB.BAS

PROTECT BAS : : M 27/03/95 9 :4l PROTECT.BAS

PROTEGE BAS 1 222 27/03/95 9: :37 PROTEGE.BAS

RSA BAS 4 2 2 26/03/95 17: 24 RSA.BAS

SIMU BAS 1 044 05/03/95 1B: 57 SIMU.BAS

T1G BAS 3 328 05/03/95 18: 43 T1G.BAS

TEXAS BAS 905 08/04/95 9: 35 TEXAS.BAS

XOR BAS 226 26/03/95 11: 08 XOR.BAS

ADL BAS 2 188 07/05/97 9 :45 ADL.BAS

ADT BAS 2 710 07/05/97 9: :44 ADT.BAS

DECADL BAS 3 698 24/04/97 9:27 DECADL.BAS

DECADT BAS 1 1 1 6 25/04/97 10: :4l DECADT.BAS

DIALINV BAS 1 5SD 06/01/98 7 :49 DIALINV.BAS

ESPDIR BAS 5B7 22/04/97 9 :24 ESPDIR.BAS

ESPINV BAS 839 22/04/97 9 :53 ESPINV.BAS

LECTDIR BAS 2 285 07/05/97 9 :5O LECTDIR. BAS

LECTINV BAS 2 573 07/05/97 9 :49 LECTINV.BAS

SIGNT2G BAS 85B 24/05/95 18 :22 SIGNT2G.BAS

DIALDIR BAS 1 292 06/01/98 7 : 52 DIALDIR.BAS

OPDIR BAS 1 514 05/01/98 17 :I2 OPDIR.BAS

OPINV BAS 1 827 05/01/98 17 :ll OPINV.BAS

INSTALL EXE 30 733 05/04/95 16:28 INSTALL.EXE

— • — — i l r -

L A D I S Q U E T T E D U L I V R E £ J

1 4 3


Tous les programmes pour PC sont fournis en GWBASIC

(fichiers .HAS), et une grande partie d'entre eux également sous

une forme directement exécutable sous IK >S (fichiers .EXE).

Dans toute la mesure du possible, on utilisera de préférence cette seconde forme, quitte à revenir à la source BASIC en cas de problème particulier.

Les programmes destinés au microcontrôleur PIC 16CS4

sont fournis sous la forme de leur code source (fichiers

.ASM), et de deux formes différentes de fichiers destinés à

la programmation du composant.

Les fichiers ,OBj sont plutôt destinés au programmateur

P1CSTART 16B de Microchip, tandis qu'on se servira de

préférence des fichiers HEX avec le très simple program

mateur construit d'après les plans de notre ouvrage

Composants électroniques programmables sur PC.

Tous les circuits imprimés dont les tracés sont reproduits

dans le livre sont également présents sur la disquette, sous

la forme de fichiers .PCB compatibles avec le logiciel

BOARDMAKER.

Rappelons que le CD-ROM de notre ouvrage Logiciels PC

pour l'électronique contient une version limitée de BOARD

MAKER permettant de charger, visualiser, modifier à

volonté, et réimprimer ces fichiers, mais pas de les enregis

trer sur disque.

Quelques <> images-carte » sont aussi fournies (fichiers

.CAR) afin de permettre à chacun d'essayer nos logiciels

avant même de disposer d'un lecteur ou de cartes.

ALM1.CAR à ALM4.CAR proviennent de quatre télécartes

allemandes neuves, vides, et entamées, tandis que

CUERN1.CAR et CUERN2.CAR ont été lus dans deux

cartes de Guernesey (une vide et une entamée), compatibles

avec la technologie allemande (Telefonkarte).

MALTE.CAR et IRLANDE.CAR correspondent pour leur

part à deux cartes de ces pays respectifs (même technologie

que les TIC françaises, mais avec un codage différent).

L A D I S Q U E T T E D U L I V R E

HOLA.CAR et PASVIDE.CAR ont été lus dans deux télé

cartes françaises dotées d'un « code famille » différent : O3h

pour PASVIDE.CAR, et O4h pour HOLA .CAR.

A l'heure où nous écrivons ces lignes, on rencontre des

codes allant jusqu'à O7h, et seul le passage définitif â la T2G

semble pouvoir arrêter cette irrésistible progression liée à

l'énc*mité des volumes émis.

T2GA.CAR et T2G5.CAR proviennent précisément de deux

télécartes de seconde génération ayant participé à l'expéri

mentation » terrain `> de 1993.

L'une est neuve, tandis que l'autre contient encore 5 unités

sur les 30 dont elle avait été chargée en usine.

Enfin, MOBIL.CAR est l'image d'une carte de lavage de

voitures telle qu'on en utilise dans les stations service

MOBIL ou BP, et qui existe en 12 et 24 unités (autrefois 10

et 20). La technologie utilisée (SOLAIC) est celle des T1G.

ALM1.CAR


I R L A N D E . C A R :

1 0 1 1 1 0 1 0 1 0 0 0 0 0 1 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 1 0

L A D I S Q U E T T E D U L I V R E 3

0100 oooo 0001 1001

1110 0000

0000 0000

0000 0000

0000 0000

0000 0000

0000 0001

1010 0111

0000 0000

0000 0000

0000 0000

0000 0000

0000 0000

1100 1101

0001 0001

0000 0000

0000 0000

0000 0000

0000 0000

0000 0000

0100 1010

0011 1100

0000 0000

0000 0000

0000 0000

0000 0000

0000 0000

MALTE.CAR

1011 1101

0000 0000

1000 1000

1111 1111

1111 1111

0000 0000

0000 0000

0000 0000

1000 0011

0001 0101

1001 0100

1111 1111

1111 1111

0000 0000

0000 0000

0000 0000

0001 0000

1010 0100

0001 0001

1111 1111

1111 1111

0000 0000

0000 0000

0000 0000

0110 0010

0101 1010

0101 0100

1111 1111

1111 1100

0000 0000

0000 0000

0000 0000

MOBIL.CAR

1000 1000

0011 1100

1010 0001

0000 0000

0000 0000

0000 0000

0000 0000

0000 0000

1000 0000

0111 0101

0000 0000

0000 0000

0000 0000

0000 0000

0000 0000

0000 0000

0010 0000

1000 0010

0000 0000

0000 0000

0000 0000

0000 0000

0000 0000

0000 0000

0000 0010

0010 0100

0000 0001

0000 0000

0000 0000

0000 0000

0000 0000

0000 0000

PASVIDE.C;

1100 1011

1011 1011

1100 0011

1111 1111

1111 1111

0000 0000

0000 0000

0000 0000

0000 0011

0101 0110

0100 1111

1111 1111

1111 1111

0000 0000

0000 0000

0000 0000

1001 0000

0110 0111

0001 0000

1111 1111

1111 1111

0000 0000

0000 0000

0000 0000

0100 0001

0000 0010

0000 0110

1111 1111

1110 0000

0000 0000

0000 0000

0000 0000

T2G5.CAR :

1000 0001

1000 0010

0000 0000

0111 1111

1111 1111

1111 1111

0000 0000

0100 0000

0100 0101

0000 0000

1111 1111

1111 1111

1111 1111

0000 0000

0010 00D0

0110 0000

0011 1111

0101 0011

1111 1111

1111 1111

0000 0000

0000 0000

0000 0101

0011 1111

1000 0010

1111 1111

1111-1111

0000 0000

147

Pour finir, nous avons recopié sur la disquette un document

p d'un exceptionnel intérêt pour nos lecteurs les plus avertis.

Lisible au moyen du logiciel gratuit Acrobat Render (notam-

l ment disponible sur le CD-ROM Wanadoo de France

Télécom), CARDSPEC.PDF reproduit dans son intégralité la

spécification « EMV » des futures cartes de paiement.

Aimablement offert par VISA sur son site internet, ce docu-

H ment en anglais de 187 pages abondamment illustrées

Il reprend notamment les principales dispositions de la

I norme ISO 7816.

M Précisons que sa reproduction est expressément autorisée,

M selon les termes et conditions que chacun pourra consulter

• dans le fichier texte CARDSPEC.(C}.

I N S T A L L A T I O N D E L A D I S Q U E T T E

Bien que tous les programmes BASIC de la disquette soient

utilisables immédiatement, une procédure d'installation

I très simple est nécessaire pour rendre exécutable le logiciel

CARTES.EXE.

. Cette manœuvre nécessite l<i réalisation préalable d'un lec

teur de télécartes (par exemple celui décrit au chapitre 4),

pour « lier » la disquette à une télécarte « clef » librement

choisie dans votre collection personnelle.

Nous vous demandons de considérer cette installation

comme une démarche volontaire, revêtant une signification

1 4 8



i juridique précise : l'engagement formel de n'en faire des

copies que pour votre usage personnel.

Toute reproduction de la disquette originale non accompa

gnée de la télécarte-clef ayant servi à son installation sera

donc réputée être une copie illégale, exposant son détenteur

aux poursuites prévues par la Loi.

L'installation doit être exécutée de la façon suivante :

• Un lecteur de télécartes approprié étant connecté à un port

parallèle du PC (LPT1: ou LPT2:), lancer l'utilitaire « INS

TALL.EXE » en frappant INSTALL à partir de la disquette

originale NON PROTEGEE EN ÉCRITURE.

" Introduire une télécarte quelconque dans le lecteur dès que

le logiciel le demandera, et presser ENTER. Au bout de

quelques secondes, un message de copyright doit apparaî

tre sur l'écran. Sache? que sa réplique est maintenant ins

crite sur la disquette, que vous pouvez à nouveau protéger

en écriture avant d'en faire éventuellement une copie de

sauvegarde réservée à votre usage personnel.

• Essayez maintenant de lancer CARTES.EXE en frappant

CARTES, et introduise/ votre télécarte-clef à la demande

du logiciel.

En cas de problême (message CARTE-CLEF NON

RECONNUE » ou autre message d'erreur), vérifiez soi

gneusement le lecteur en exécutant, sous GWBASIC, MINI-

I IX I HAS.

Si le défaut ne concerne que CARTES.EXE, recommencez

l'installation avec une autre télécarte.

Une fois l'installation réussie, il est souhaitable de copier

, intégralement la disquette dans un répertoire du disque

dur, ou au moins sur une disquette de travail.

Attention ! Ne tentez pas de copier CARTES.EXE seul, il ne

fonctionnerait pas.

M O D E D ' E M P L O I D E C A R T E S . E X E

I Ce puissant logiciel concrétise toute l'expérience qu'il nous a été possible de réunir, au moment où nous écrivons ces


lignes, en matière de lecture de télécartes françaises et

étrangères, il n'a donc rien de définitif !

11 doit être associé à un lecteur de cartes synchrones tel que celui décrit au chapitre 4, et installé selon la procédure qui vient d'être décrite.

Bien entendu, La télécarte-clef devra être présentée lors de

chacun de ses lancements (on la rangera donc de préférence

avec le livre).

•î Surtout destiné aux collectionneurs et aux curieux de tout

poil, ce programme n'est pas prévu pour écrire dans les télé

cartes. Ce genre d'opération nécessite l'usage d'un lecteur

plus complexe et d'un logiciel spécifique, tous deux décrits

dans notre ouvrage Cartes à puce, initiation et applications.

\ Dans son état actuel, CARTES.EXE supporte les familles de

cartes synchrones suivantes :

• Cartes EPROM 256 bits < CPM256 » : télécartes françaises

« T1G », télécartes de nombreux pays étrangers, cartes di

verses (lavage de voitures, stationnement, cinéma, etc.) ;

• T2G françaises de 50 et 120 unités ;

• Cartes européennes et Eurochip (Allemagne, Pays-Bas,

Suisse, Guernesey, Grande-Bretagne, certaines cartes pri

vées, etc.)

:'. Chaque fois que les informations en notre possession l'ont

|. permis, nous avons prévu l'identification automatique du

pays et la lecture du nombre d'unités disponibles.

; Lorsque cela n'a pas été possible (les cartes d'Espagne et de Croatie, notamment, sont plus difficiles à faire parler...) nous avons pris le parti d'afficher ce qui pouvait tout de même l'être.

En tout état de cause, l'option « Affichage binaire et hexa »

permet d'examiner une « image-carte » brute, non décodée,

• dont chacun pourra tenter de percer les éventuels mystères.

| Très utiles, les options « Sauvegarde sur disque » et « Chargement du disque » permettent d'enregistrer sur

\ disque dur ou sur disquette n'importe quelle image-carte pouT la relire et la décrypter de nouveau ultérieurement, même si on ne dispose plus Je la carie originale.


Si une imprimante est connectée en même temps que le lec

teur (sur un autre port parallèle), la fonction •< sauvegarde •>

permet d'imprimer une image-carte binaire en spécifiant

PRN en tant que nom de fichier (rien ne sera alors enregis

tré sur le disque).

Le cas échéant, les images-carte sauvegardées sur disque

peuvent être modifiées à l'aide d'un éditeur de texte puis

rechargées. Cela permet notamment de simuler des

consommations d'unités ou de reconstituer des images de

cartes neuves à partir de cartes épuisées, pour la plus gran

de satisfaction des collectionneurs.

Les options « Contrôle de parité (TIC françaises seule

ment) et Vérification d'une carte » sont utiles pour détecter

les cartes dont le contenu a changé par rapport à leur image

précédente ; consommation d'unités, bien sûr, mais éven

tuellement altération du contenu de leur mémoire.

On chargera évidemment, depuis le disque, l'image de réfé

rence avant d'appeler la fonction de vérification et d'intro

duire la carte à vérifier.

Les incontournables des passionés de l'électronique

EN VENTE CHEZ VOTRE LIBRAIRE HABITUEL

Code 023990


Code 0 4 2 8 6 6




Code 0 4 1 7 6 4



Code 0 4 2 6 4 7

Imprimerie A ` Graphiques du Perche 2K24ll Meiiucé. Dép&l légal : juin 1998 — N" d'Imprimeur 981013

1" dépôt légal : 3e Irimesire 1995

PC et Cartes à Puce Même si vous savez déjà lire et écrire dans les cartes à puce, ce livre va vous expliquer comment aller beaucoup plus loin !

Avec l'aide de votre PC, vous allez par exemple pouvoir lire le « relevé de compte » de votre carte bancaire ou savoir si on l'a utilisée à votre insu, et même décrypter les échanges de données entre les cartes et leurs lecteurs.

Vous apprendrez également à fabriquer vos propres cartes et à les programmer depuis le PC.

Et lorsque vous aurez réalisé les montages décrits et utilisé les logiciels réunis sur la disquette, les nouvelles télécartes françaises ou étrangères n'auront plus guère de secrets pour vous, que vous soyez ou non collectionneur.

CONFIGURATION RECOMMANDÉE

3 I

WÊ mm « . ! I , I - ! . ' U W I

C o d e O 4 3 8 8 6 ISBN 2 10 0 0 3 8 8 6 9

pc et carte a puce

Documents