Explorer les Livres électroniques
Catégories
Explorer les Livres audio
Catégories
Explorer les Magazines
Catégories
Explorer les Documents
Catégories
Affichage des articles dont le libellé est APDU. Afficher tous les articles Rubriques
APDU
(3)
ATR
(3)
Bases
(3)
Brochage
(3)
Crypto
(2)
Edito
(3)
samedi 30 juillet 2016 EMV
(1)
Gemalto
(1)
gscriptor
(2)
Lecteur
(1)
Liens
(2)
PCSC
(3)
PIC
(5)
Premier programme avec mon InfinityUSB Unlimited Présentation
(1)
Sans contact
(2)
Sécurité
Fonctionnement des
cartes à puce hybrides à
NFC
Nous avons vu dans un
précédent article
comment fonctionne une carte à puce
standard. C’est très intéressant de le
savoir, sauf que b...
Le logiciel est des plus simples : on choisit la carte à programmer (Silvercard pour moi), le fichier hex
à envoyer dans le PIC, éventuellement le fichier hex à envoyer dans l'EEPROM externe au PIC et on
clique sur "Write". La programmation dure environ 5 secondes, la led clignotant verte à ce seul S’abonner à
moment. Dans le cas où un fichier hex est à envoyer dans l'EEPROM externe, le logiciel commence
par charger dans le PIC un loader maison, s'adresse à lui comme intermédiaire pour écrire dans
Articles
l'EEPROM, et ensuite seulement écrit le PIC avec le fichier hex du PIC.
Commentaires
Inutile de dire que j'avais un fichier hex réfléchi tout prêt à injecter dans le PIC. C'est là que les ennuis
ont commencé. L'injection s'est très bien passé, par contre gscriptor sous Linux voyait ma carte
comme "non alimentée" (donc quasi morte pour lui). Aucune communication ne s'établissait avec la
carte. Membres
J'ai donc carrément injecté dans la Silvercard le fichier hex brut de fonderie original duquel j'avais tiré
les routines SEND et RECEIVE en ISO7816. C'était un fichier d'un vieux programme de piratage des
https://cartesapuce.blogspot.com/search/label/APDU 1/9
25/08/2021 Cartes à puce: APDU
cartes SECA MEDIAGUARD du début des années 2000. Après tout, c'est peut-être moi qui avait mal
Abonnés (1)
extrait les routines. Même topo avec ce fichier, carte non alimentée.
Là j'ai commencé à me dire que j'étais mal, parce qu'il faut absolument que je parte d'un programme
dans lequel les routines SEND et RECEIVE fonctionnent, car c'est de l'horlogerie, quasi impossible à S'abonner
écrire soit-même. Me voilà donc condamné à chercher sur le net un programme pour Silvercard dans
lequel les routines SEND et RECEIVE au format ISO7816 fonctionnent bien. Difficile à trouver car
maintenant tout le monde utilise des MIFARE ou autres cartes NFC.
Blogroll
Eh bien j'ai trouvé un vieux programme de déplombage de la chaine de TV italienne RAI qui date de
Avec ou Sans Contact
2004 et qui, une fois injecté dans ma Silvercard a envoyé un ATR à gscriptor, et avec lequel je Une économie digitale plus au
pouvais envoyer des APDU. Certes il répondait à chaque fois que l'APDU correspondait à une classe service des individus, la
non implémentée, mais la communication se faisait. Pour la première fois je communiquais avec ma transcription d’une conférence
Silvercard! passionnante autour des défis de
l’innovation post-covid
Je reprennais espoir car, quand on a un programme qui marche tout est différent. On a un angle
d'attaque. Problème tout de même : mon programme RAI fait 13 Ko compilé. Chercher les routines
SEND et RECEIVE là-dedans revient à chercher une aiguille dans une meule de foin.
Suivez moi sur Twitter
Bon, j'exagère un peu car, par définition, SEND et RECEIVE manipulent le bit 7 du registre PORTB
(car c'est sur ce bit que se fait la communication extérieure). En faisant une recherche sur ce critère,
j'ai assez vite isolé les 2 routines et je les ai extraites. Tweets de @CartesapuceAlan
Je les ai reprises dans un programme simple de mon cru, une espèce de "hello world" pour les cartes Alan Cartman
à puce : ce programme envoie le même ATR que la carte RAI puis passe dans une boucle infinie qui @CartesapuceAlan
lit 5 octets (ie 1 APDU : CLA INS P1 P2 Le) et renvoie systématiquement 90 00, quel que soit l'APDU
Après la loi travail passée a coups de
reçu. On ne peut pas faire plus simple comme programme.
49.3. lexpress.fr/actualite/poli…
Pour être franc, j'étais sûr que cela ne marcherait pas, ou du moins pas du premier coup. Sauf que
BINGO !!! mon programme marche parfaitement bien. Voici un petit échange entre mon programme 10 mai 2017
et gscriptor.
Alan Cartman
@CartesapuceAlan
10 mai 2017
Alan Cartman
@CartesapuceAlan
9 mai 2017
Alan Cartman
@CartesapuceAlan
9 mai 2017
Alan Cartman
Voici donc mon programme. C'est du brut de fonderie, le premier programme qui marche. A partir de @CartesapuceAlan
lui, je vais petit à petit monter une vraie application carte à puce.
Mort de rire lefigaro.fr/vox/monde/2017…
Al C t
https://cartesapuce.blogspot.com/search/label/APDU 2/9
25/08/2021 Cartes à puce: APDU
__CONFIG _BODEN_OFF & _CP_OFF & _WRT_ENABLE_OFF & _PWRTE_OFF & Alan Cartman
_WDT_OFF & _XT_OSC & _DEBUG_OFF & _CPD_OFF & _LVP_OFF
@CartesapuceAlan
9 mai 2017
ORG 0x0000
lexpress.fr/actualites/1/p…
Alan Cartman
MOVWF TRISB
@CartesapuceAlan
BCF STATUS,RP0
BOUCLE_SEND
9 mai 2017
CALL WAIT1
9 mai 2017
MOVWF TRISB
BOUCLE_RECEIVE
Alan Cartman a retweeté
BCF 0x3,0
Absurdie
BTFSC 0x6,7
@Absurdie
BSF 0x3,0
Pascal Didon
@DidonPascal
WAIT1 MOVLW 0x1a
7 mai 2017
https://cartesapuce.blogspot.com/search/label/APDU 3/9
25/08/2021 Cartes à puce: APDU
INIT
Alan Cartman a retweeté
BCF OPTION_REG,7 ; enable pull-ups
François Asselineau
CALL SEND
@UPR_Asselineau
MOVLW 0x0E
7 mai 2017
END
Alan Cartman
Publié par
Alan Cartman
à
23:38
Aucun commentaire:
@CartesapuceAlan
Libellés :
APDU,
ATR,
gscriptor,
PIC,
Silvercard Le petit cadeau de départ d'Hollande
lefigaro.fr/social/2017/05…
Pour cela nous allons utiliser un utilitaire livré dans le package pcsc-tools (sudo apt-get install pcsc-
tools) : gscriptor.
8 mai 2017
Connectons le lecteur de cartes à puce sur le port USB du PC et insérons y une carte à puce. Je
prends ici pour l'exercice une carte bancaire EMV périmée depuis 2014 que j'ai dans mes cartons Alan Cartman
(pour expérimenter, il vaut mieux avoir des cartes, c'est sûr). @CartesapuceAlan
Lançons gscriptor.
8 mai 2017
Alan Cartman a retweeté
Alesk!
@Alesk_G
“Élu produit de l’année”, ce titre
magnifique de @Lesjoursfr
https://cartesapuce.blogspot.com/search/label/APDU 4/9
25/08/2021 Cartes à puce: APDU
7 mai 2017
Ce petit programme, écrit en perl, est une simple interface graphique vers l'API PCSC. Sur la gauche
de la fenêtre on écrit un script, et on voit le résultat (dont la réponse de la carte) dans la fenêtre de Charger plus de
Tweets
droite.
Cliquons dans le menu "Reader / Connect" pour se connecter logiciellement à la carte à puce. Puis
faisons "Reader / Status".
Archives du blog
▼
2016
(18)
▼
août
(2)
Edito du 7 août 2016
On voit que la carte à puce a émis comme ATR lors de l'insertion : 3B 65 00 00 20 63 CB 6A 00. Le PCSCLite, c'est quand
premier octet étant 3B, on peut déjà en déduire qu'une carte bancaire EMV fonctionne en convention même un peu de la
directe. daube
►
juillet
(16)
Arrivé à ce stade, il faut connaitre les APDU supportés par la carte. Nous reviendrons dans un
prochain article sur une exploration plus poussée de la carte EMV. Comme il s'agit ici uniquement
pour l'instant de montrer comment utiliser gscriptor, nous allons simplement envoyer à la carte 1 type
d'APDU.
L'APDU que nous allons utiliser s'appelle (dans la doc EMV) GET CHALLENGE. Par cet APDU le
lecteur de carte demande à la carte de générer un nombre aléatoire de 8 octets. GET CHALLENGE
est utilisé dans la sécurité de la carte bancaire, c'est pourquoi cet APDU existe.
La bonne séquence à envoyer à la carte est : 00 84 00 00 08, c'est à dire CLA = 00, INS = 84, P1 =
P2 = 00, et Le = 08.
Commençons par envoyer 00 84 00 00 00 pour voir ce qui se passe (on tape le script à gauche et on
clique sur "Run").
On voit que la carte ramène 6C 08 (soit SW1 = 6C, SW2 = 08). gscriptor fait une interprétation de ce
code (basé sur les specs EMV) : mauvaise longueur Le, devrait être 08. En effet cet APDU demande
la génération d'une séquence aléatoire de 8 octets.
https://cartesapuce.blogspot.com/search/label/APDU 5/9
25/08/2021 Cartes à puce: APDU
On voit cette fois que la carte envoie 8 octets choisis (pseudo) aléatoirement : D1 03 7A 3A AD 25 A6
2C. La réponse de la carte se termine par 90 00 qui signifie que tout s'est bien passé.
On peut s'amuser à renvoyer cet APDU plusieurs fois, on aura toujours 8 nombres aléatoires
différents.
Voilà, inutile d'aller plus loin, gscriptor est vraiment un logiciel simplissime à utiliser. De toute façon
pour aller plus loin il faut bosser les specs EMV, sujet dont je suis loin d'avoir fait le tour.
Nous verrons dans un prochain article comment se passer de gscriptor pour dialoguer avec la carte,
en passant par un programme qu'on écrira en C et qui discutera directement avec la carte en passant
par l'API PCSC (ce que fait gscriptor en fait). On verra donc en quelque sorte l'envers du décors de
gscriptor.
Nous verrons également plus tard qu'il n'est pas très difficile de programmer une Silvercard pour
qu'elle soit capable de faire cette fonction de génération de 8 nombres aléatoires, comme le fait la
carte bancaire.
Publié par
Alan Cartman
à
19:28
Aucun commentaire:
Libellés :
APDU,
ATR,
gscriptor,
PCSC
La puce en elle-même est invisible car cachée derrière 8 connecteurs en métal conducteur.
https://cartesapuce.blogspot.com/search/label/APDU 6/9
25/08/2021 Cartes à puce: APDU
Historiquement les premières puces n'etaient que de simples mémoires. C'etait le cas de la carte à
puce objet du brevet de Roland Moreno ou des premières cartes téléphoniques Télécarte. Ces cartes
sont aujourd'hui dépassées et ne sont plus utilisées.
Sur les 8 connecteurs visibles, seuls 5 sont utilisés. Leur nom montre à quel point une carte à
puce est dépendante du lecteur dans lequel on l'insère, puisque celui-ci doit lui fournir
l'alimentation électrique (pattes VCC et VSS, généralement 5V) ainsi que l'horloge (patte Clock,
généralement à 3.5 Mhz). Le lecteur peut également faire rebooter la puce en mettant
brièvement la patte RESET à 0 (reset à chaud).
La communication entre la puce et le lecteur se fait en mode série, bit à bit, sur la patte
input/output. Faire une communication bi-directionnelle sur une seule patte a un avantage (une
seule patte utilisée) mais a deux défauts : la faible vitesse d'une part, et la gestion électrique de
la patte d'autre part. En effet, il est évident que si la puce cherche a y parler en y mettant du 5V
alors qu'au même moment le lecteur cherche aussi à y parler en y mettant du 0V, l'un des deux
va griller.
Pour éviter cela, le protocole T=0 qui est celui qui est quasiment le seul utilisé, prévoit que la
puce ne parle jamais tant qu'elle n'y est pas invitée par le lecteur. Le dialogue se fait selon la
séquence suivante :
1) Mise sous tension électrique de la puce par le lecteur et envoi permanent de l'horloge par le
lecteur vers la puce. La puce boote.
2) La puce émet une séquence d'octets appelée ATR (Answer To Reset, ou réponse à
l'initialisation). Il s'agit d'une séquence de 2 à 32 octets émis par la puce à 9600 bauds et qui est
censée donner au lecteur des informations sur le fonctionnement de la puce. Décrire l'ATR dans
son ensemble est assez compliqué (voir la page Wikipédia pour plus d'infos). L'octet le plus
important dans l'ATR est le premier : il vaut soit 0x3B pour dire que la puce fonctionne en
convention directe, soit 0x3F pour signaler que la puce fonctionne en convention inverse (voir
plus bas).
3) Une fois que la puce a envoyé son ATR, elle ne parle plus tant qu'elle n'y est pas invitée par
le lecteur. C'est donc le lecteur qui a la main sur la patte input/output. Quand le lecteur veut
intéragir avec la puce, il lui envoie un APDU (Application Protocol Data Unit), c'est à dire une
séquence de généralement 5 octets. Le premier octet est la classe (CLA) de la commande. Le
deuxième octet est l'instruction dans la classe (INS), les 3ème et 4ème octets sont les
paramètres P1 et P2 de l'instruction, et le 5ème octet est généralement la taille de la réponse
attendue.
https://cartesapuce.blogspot.com/search/label/APDU 7/9
25/08/2021 Cartes à puce: APDU
La classe sert à éventuellement mettre plusieurs applications dans la carte à puce. Avec l'octet
de classe, la carte sait à quelle application l'APDU s'adresse.
Prenons un exemple avec les anciennes cartes bancaires à puce B0 d'avant 2006, elles
réagissaient à la classe 0xBC et l'instruction pour lire une zone mémoire était 0xB0. Si l'on
voulait lire 16 octets de mémoire à partir de l'adresse 0x9F0 par exemple, il suffisait d'envoyer à
la carte l'APDU : BC B0 09 F0 10.
4) Quand la carte à puce a reçu un APDU, elle donne une réponse qui est formatée soit :
XX XX XX XX SW1 SW2, soit SW1 SW2, c'est à dire que la réponse se termine toujours par
deux octets qui donnent le statut de la réponse, avec éventuellement une réponse avant.
Les octets SW1 et SW2 relèvent de la pure convention. Une carte bancaire moderne EMV
renvoie 90 00 quand tout s'est bien passé, mais elle peut renvoyer autre chose si l'on demande
une info qui nécessite d'avoir présenté au préalable le code PIN par exemple.
Une fois que la carte à puce a donné sa réponse à l'APDU, elle libère électriquement la patte
input/output et elle attend patiemment un autre APDU.
Il est clair que la première chose à se procurer lorsqu'on veut expérimenter avec une carte à
puce c'est la liste des ADPU qu'elle connait et comment elle y répond.
La communication entre la carte à puce et le lecteur emprunte soit la convention directe, soit la
convention inverse. C'est la carte qui impose son mode de communication au lecteur.
Dans la convention directe, un niveau logique 1 est envoyé sur la patte input/output avec du +5V
et un niveau logique 0 avec du 0V. Par contre les bits de l'octet à transmettre sont émis du LSB
(less significant bit) vers le MSB (most significant bit).
Dans la convention inverse, un niveau logique 1 est envoyé sur la patte input/output avec du 0V
et un niveau logique 0 avec du +5V. Par contre les bits de l'octet à transmettre sont émis du
MSB vers le LSB.
Que ce soit en convention directe ou inverse, l'octet à transmettre est toujours précédé d'un bit
de start à 0, et suivi d'un bit de parité paire. Après la transmission d'un octet, la carte attend
l'équivalent de 2 bits de stop.
Ce genre de détails sur la transmission des bits est complètement transparent pour le
programmeur du côté du PC (c'est l'interface PCSC qui gère cela). Par contre pour le
programmeur dans la carte à puce, cela dépend. Je pense que dans une java card les classes
java fournies rendent également transparent cela. Par contre, et là j'en suis sûr, le programmeur
doit gérer ces aspects lorsqu'il programme une carte à puce à base de micro-contrôleur, comme
les wafer gold ou Silvercard.
Terminons sur ces quelques connaissances de base pour signaler que l'intégralité des aspects
normatifs liés aux cartes à puce (dimensions, caratéristiques électriques, protocoles de
communication, etc.) sont définis dans la norme ISO 7816.
Les premières cartes à puce à micro-processeur, comme la carte bleue bancaire B0 active
jusqu'en 2006 par exemple, ne connaissaient pas la notion de fichiers. Elles avaient un espace
mémoire, c'est tout, dont certaines zones étaient accessibles en lecture depuis le lecteur sans le
code PIN, et d'autres zones accessibles seulement après avoir présenté le code PIN à a carte.
Les cartes à puce modernes, comme la carte bancaire EMV ou la carte SIM des téléphones
cellulaires, ont maintenant la notion de fichiers. En plus des ADPU reconnus par la carte, il faut
donc aussi connaitre la liste des fichiers et leur contenu. A mon avis cette avancée ne sert
strictement à rien en terme de fonctionnalités. Je pense qu'il s'agit juste de complexifier le
fonctionnement de la carte pour compliquer le travail des pirates. En tout cas, en ce qui me
concerne, je ne compte pas utiliser cette notion de fichiers dans mes futurs développements
personnels à base de Silvercard.
Publié par
Alan Cartman
à
18:05
Aucun commentaire:
Libellés :
APDU,
ATR,
Bases,
Brochage
https://cartesapuce.blogspot.com/search/label/APDU 8/9
25/08/2021 Cartes à puce: APDU
Inscription à :
Articles (Atom)
1 3 4 4 6
https://cartesapuce.blogspot.com/search/label/APDU 9/9