Analyse des cartesà puces (téléphoniques et bancaires)
Auteur : Redrum
Zine : Rafale #1
Le domaine des cartes à puce est caractérisé par deux grand types
d'architecture:
-L'architecture synchrone ou télécartes
-L'architecture asynchrone
Les cartes synchrones:
Exemple d'utilisation: les cartes téléphoniques
I] Architecture
Une carte synchrone est une mémoire EPROM de 256 bits. Elle est caractérisée
par son horloge. En effet, la carte est cadencée par l'horloge interne du
terminal. Sans cette horloge, il est impossible d'accéder aux data de la carte.
Sur ses 256 bits, 96 sont cryptés (DES) et protégés en écriture.
Ce cryptage nous empèche le clone de la carte car la clef secrète, cryptée
sur 64 bits, est illisible de l'extérieur puisque "masquée" par des 1.
Lors de la lecture d'une télécarte, vous pourrez vous appercevoir qu'après
les 96 premiers bits, vous allez retrouver la zone de stockage de vos unités.
Les 0 correspondents aux unités grillés.
Exemple d'une carte T1G TOTALE
1100 0101 1000 0101 0000 0000 0000 0000 | C5 85 00 00
1010 0000 0011 1101 1001 0000 0100 0101 | A0 3D 90 45
0000 0000 0000 0000 0001 0001 0100 0001 | 00 00 11 41
0000 0010 0001 0001 0010 0100 0001 0010 | 02 11 24 12
1000 1010 0111 0001 0001 0110 1011 1111 | 8A 71 16 BF
1111 1000 0000 0000 0000 0000 0000 0000 | F8 00 00 00
1111 1111 1111 1111 1111 1111 1111 1111 | FF FF FF FF
1111 1111 1111 1111 1111 1111 1111 1111 | FF FF FF FF
Type de carte : Télécarte T1G 256 bits.
Zone ROM : [C5850000A03D904500001141]
Pays ou zone (41) : Carte lavage TOTAL.
N° de série possible : 04034629.
On remarque que cette carte est une T1G (télécarte de première génération) de
256 bits.
La zone ROM :
1100 0101 1000 0101 0000 0000 0000 0000 | C5 85 00 00
1010 0000 0011 1101 1001 0000 0100 0101 | A0 3D 90 45
0000 0000 0000 0000 0001 0001 0100 0001 | 00 00 11 41
correspond à la zone cryptée de la carte (soit 96 bits).
Le reste de la carte contient les unitées et le certificat (équivault à la
signature d'un programme)
II] Emulation
Emulateur t1g:
Les T1G sont les télécartes de première génération. Ces cartes ne sont
quasiment plus utilisées. On les retrouve notamment dans les cartes de lavages
TOTAL.
Il n'est pas utile que je développe/commente l'émulateur. Mais, même si ces
cartes ne sont plus utilisées, l'émulateur reste opérationnel et adaptable
(pour les cartes TOTAL, par exemple).
Emulateur (archive):
./Files/07/Emulateur_CPAT.rar
Emulateur t2g (télécartes de seconde génération):
L'émulateur T2G josephina à été créé il y a deux ans.
En effet, un bug avait été trouvé lors de la phase d'appel. La cabine ne
faisait pas de seconde authentification lors de lappel.
Le principe de l'émulateur consistait à faire la phase d'authentification
sur une vrai carte téléphonique puis, une foi cette phase terminée, de
basculer par un interrupteur (SWITCH) sur l'ASM du PIC (microcontroleur de
l'émulateur).
Cet émulateur ne fonctionne plus car d'autres phases d'authentifications ont
été ajoutés.
Réalisation de l'émulateur:
./Files/07/jospehina par redrum pour cardhack team.doc
Les cartes asynchrones
Exemple d'utilisation : Les cartes bancaires
Les cartes asynchrones sont aussi appellées "carte à micro-calculateur",
ou "cartes à microcontroleur".
En effet, l'architecture des actuelles puces asynchrones réunit une unitée
centrale 8 bits, de la mémoire ROM, RAM, EEPROM (ou EPROM), ainsi que des
ports d'entrée-sortie, exactement comme tout microcontroleur qui se respecte.
A l'heure actuelle, ces cartes ont de plus en plus de ressources securitaires.
Le dialogue des cartes asynchrones est défini à travers deux protocole,
le protocole t=0 et le protocole t=1
Actuellement, le cryptage utilisé par nos cartes bancaires est du type
RSA de l'ordre de 896bits. Voici l'évolution de la RSA ces dernières années:
Avant 1999 = 320 bits (qui a été cassée)
Avant 2001 = 512 bits (qui a été cassée)
Avant 2004 = 768 bits (des rumeurs mais non fondées sur son cassage)
2004 = 768 + 896 bits (les deux sont accouplés)
2005 = 896 bits
Ce système RSA repose sur un système de clé publique - clé privée. La clé
privée est connue de la banque. La VS (valeur sécuritaire de la carte),
calculée à partir de la clé privée de la banque (pour une carte bancaire),
est inconnue pour nous sans casser la clé publique de la RSA.
Pour casser la RSA, il faudrait trouver un multiple de deux nombres premier
tel qu’ils soient égaux à la clé publique.
Mathématiquement:
a*b= n
où a,b sont des nombres premier et n la clé publique
DESCRIPTION VAGUE DES DEUX PROTOCOLES
Notion essentielle (adaptation du livre de CHRISTIAN TAVERNIER)
échange de données
Une carte asynchrone fonctionne sur le principe d'émission et réceptions
d'octets.
ces octets sont structurés suivant deux protocoles, un protocole T=0 (CB
françaises) et un protocole T=1 (monéo (le porte monaie électronique!!)).
Il est intéréssant de comprendre le protocole T=1 avant le T=0.
De mon point de vue, si vous connaissez le protocole T=1, il ne vous suffira
alors que d'une simple modification pour comprendre le T=0
Le protocole T=1
Le protocole T=1 est un protocole qui échange des blocs structurés de la
manière suivante:
PROLOGUE | Information | Epilogue
_________________________________________________________________________
NAD | PCB | LEN | Données (APDU) | LRC
_________________________________________________________________________
1 octet | 1o | 1o | 0 à 254 octets | octet
- NAD est l'octet d'adresse de noeud. Le quarter (4 bits) de poids faible
contient l'adresse de l'émetteur du bloc et le quarter de poids fort l'adresse
du destinataire du bloc.
- PCB est un octet de contrôle du protocole. Il définit au moyen de ses deux
bits de poids forts b7 et b6, le type de bloc: superviseur (1,1), information
(0,0) ou réception prête (1,0);
- LEN est un octet indiquant la longueur du champ d'information qui suit ce
champ de prologue, exprimé en nombre d'octets.
Le champ suivant est le champs d'information. Il contient les données utiles
véhiculées par le bloc.
Le champ appelé épilogue est un octet de contrôle, appelé LRC. C'est le
résultat d'un OU exclusif de tous les octets qui précèdent
Les Données
Une commande APDU est structurée de la maière suivant:
CLA | INS | P1 | P2 | L
CLA, correspond à la Classe
INS est l'instruction de la CLaSS
P1 et P2 correspondent aux octets de données
L est la longueur du bloc (données qui vont être transmisent à la carte ou
attendues de la carte)
Exemple:
Pour une carte Bancaire:
- La classe BC est la section "maitresse"
- L'instruction 0E, de la classe BC, permet l'éffacement; l'instruction
20 permet la présentation du code Pin ou de la clée de déblocage de la carte
etc...
La liste des instructions utilisées par les cartes bancaire est présente dans
l'asm commenté (voir plus bas)
Les Réponses de la Carte
Une réponse APDU est définie par deux octets:
SW1 | SW2
-Si une commande n'est pas acceptée, la réponse sera:
R-APDU= SW1='6X'SW2
Liste des comptes rendu
6B 00 Référence incorrecte P1 et P2.
67 00 Longueur incorrecte.
6F 00 Diagnostique non précis.
62 81 Données incorrect.
62 82 Les données ont étaient changer pendant le lecture de celle-ci.
62 84 Sélection d’un fichier non valide.
65 01 Erreur de mémoire. En lecture ou en écriture.
68 00 Fonction non supportée.
6A 00 P1 et/ou P2 sont incorrectes.
6A 80 Les données enregistrées sont incorrectes.
6A 82 Fichier non trouvé.
6A 83 Enregistrement non trouvé.
6A 84 Mémoire insuffisante.
6A 87 P3 incorrecte pour les références P2 et P3.
6A 88 Informations non trouvées.
6C XX Longueur incorrecte.
-Si une commande est acceptée, la réponse sera alors
SW1-SW2= 90 00
Si vous avez déjà compris cela, vous pourrez vous amuser avec votre carte.
Le protocole T=0
Le protocole T=0 est nettement plus simple, puisque la seule chose apparente
qui le distingue du protocole T=1 est sur l'envoi des blocs. L'épilogue et
le prologue sont absents...
-exemple : lecture de la VA (Valeur d'Authentification) d'une CB
Il suffit d'envoyer cette commande à la carte:
BC B0 07 d0 50
BC <=> CLASS
B0 <=> Lecture d'octets
07 d0 <=> P1 P2 Soit: ADRESSE MEMOIRE 07 d0
50 <=> Longueur de bloc attendue en réponse
Allez voir la partie THEORIE sur les cartes bancaires, pour approfondir vos
connaissances. Essayez avec le logiciel Winexplorer les cripts proposés
---------
Venons-en au fait, nos carte bancaires actuelles sont développés sur le
protocole t=0
Les caractéristiques de nos Cartes Bancaires
Composition:
- La Puce (en position ISO) , qui contient, pour résumer,Une VA (valeur
d'authentification qui est calculé avec les info porteur), Une VS (valeur
sécuritaire, protégé par le système américain RSA. Cette VS est calculé avec
la clé privée + infos porteurs) , les infos porteurs et son programme en ROM.
-Encartés (sur le support plastique) <-- 16 chiffres + CVV2, date d'expiration,
nom + prénom
-Bande Magnétique <-- 2 tracks conformes à la norme ISO (qui seront détaillés
par la suite)
>>>>>La Puce<<<<<
LA PRATIQUE, les techniques de YESCARD, détournement
Notions indispensables sur le fonctionnement générale du système bancaure
français, pour ensuite comprendre la THEORIE
Aujourd'hui, il est seulement possible de faire des clones de Cartes Bancaires.
Deux types de clones sont possibles:
-- clone de CB pas en opposition
Votre clone ne passera pas sur tous les appareils. En effet, si il y a appel
à la banque, et que vous avez des sous sur votre conte, votre carte passera,
sauf si la fonction télépass est activée sur le TPE (terminaux de paiement
électronique). Certains tpe font cette vérification systématiquement, d'autres
à partir d'un certain montant (généralement 90 euros), et d'autres ne le font
jamais.
Le télépass c'est une fonction de la carte qui permet de crypter une trame
envoyée par le tpe afin d'obtenir une signature unique pour chaque cartes.
Cela permet au tpe de vérifier l'authenticité de la carte et de savoir si
il a affaire à une vraie carte ou à une fausse .
Si vous tombez sur un tpe qui ne fait pas cette vérification, alors vous êtes
gagnant
-- clone de CB en opposition; c’est ce point que je veux détailler avec vous:
Il existe en France beaucoup de TPE off, qui ne font appel à la banque qu'à
un certain plafond d'achat. Ce plafond est généralement fixé à 90 euros.
C'est à dire qu'avec un clone de carte en opposition, sur des tpe off
(tpe offline), vous pouvez faire des achats jusqu'à 90 euros avant que
le tpe ne fasse appel à la banque (et oui, si il ne fait pas appel, il ne
voit pas que la carte est une carte dérobée (ou trouvée bien sur :-p )..
Sur des tpe on (online) l'appel est immédiat et donc l'utilisation de
"fausse yescard" impossible. Les tpe off ont une mémoire de 2000 cartes
blacklistées et, une fois ce seuil atteint, la mémoire est Resetté pour
laisser place au blacklistage suivant. Donc en gros, vous attendez que
2000 cartes se soient écoulé dans le TPE avant de réutiliser votre bin dans
le magasin lol... Votre bin ne sera valide que 2 jours par département
(2 jours d'affilé) et qu'une foi par magasin (problème du blacklistage).
Bien sur, sur des clones de CB en opposition, vous aurez toujours le problème
du télépass détaillé précédemment. Il est absolument impossible de prendre
un clone de CB et d'en modifier les infos par des infos porteurs valides avec
hexworkshop (contrairement à ce que disent certains). En effet, vous pourrez
certes recalculer la VA mais pas la VS (pour cela il faudrait casser la RSA
afin d'en avoir la clé privée).... et donc, vous aurez un beau ticket qui va
sortir du tpe avec un triangle « attention!! » et marqué "appelez ce numéro
de toute urgence". Là, vous avez intérêt à courir.
Par ailleurs, il est aussi impossible, par le moyen d'une yescard, de casher
en distributeur car, celui-ci, fait une vérification entre la Bande Magnétique
et la puce.
Dans certains départements, des mises à jour ont été effectuées par les
banques sur les tpe ingenico... Cette mise à jour a pour effet de bloquer
les cartes piratées faites avec l'hex de dack18.
Il existe 2 remèdes à ma connaissance. Soit vous changez de départements,
soit vous trouvez l'hex de silver qui est censé marcher.
Donc pour conclure sur les clones de cartes en opposition, deux gros problème
se posent à vous :
-- résoudre le problème du télépass
-- casser la RSA
LA THEORIE
Un asm entièrement commenté
Pour comprendre cet ASM, je vous suggère de bien approfondire mon article sur
LES PROTOCOLES
./Files/07/dack1.6.asm
Cet ASM est à compiler et à programmer dans une carte de type GOLDWAFER
(16F84 + 24LC16). Il reconstitu le programme d'une CB, mais il ne gère
pas la certification télépass. Cet ASM est à programmer dans le PIC de
la GOLD. Dans la mémoire de celle-ci, vous programmerez le mapping.
Le mapping mémoire doit être sauvegarder en EEPROM (24LC16) à l'aide
de dackbox (ou autre). C'est un fichier BIN (extension .bin) qui contient
les infos porteurs (adld, VA, VS, numéro de série etc...).
Dans certains ASM, le mapping est directement intégré dans le PIC.
Du plus pour les initiés:
Lecture de la zone des pointeurs, adl, VA et VS d'une CB
Voici un bout de code qui vous permmettra d'aller lire quelques infos sur vos
CB actuelles.
C'est un VB script éxécutable par le logiciel Winexplorer (obligatoire):
Code:
'dump par Redrum
'dans le but de l'étude des cartes bancaires françaises
Sub Main()
Sc.Print(vbCr &"Lecture de la zone des pointeurs")
Sc.write("BC B0 09 C0 20")
Sc.Print(vbcr & "Bytes dans le buffer : " & Sc.BytesInBuffer & vbcr)
Sc.Read(1)
Sc.Read(32)
Sc.Read(2)
Sc.Print(vbCr &"Lecture à l'ADL")
Sc.write("BC B0 07 d0 00")
Sc.Print(vbcr & "Bytes dans le buffer : " & Sc.BytesInBuffer & vbcr)
Sc.Read(1)
Sc.Read(256)
Sc.Print(vbCr &"Valeur d'Authentification")
Sc.write("BC B0 07 d0 50")
Sc.Print(vbcr & "Bytes dans le buffer : " & Sc.BytesInBuffer & vbcr)
Sc.Read(1)
Sc.Read(50)
Sc.Print(vbcr &"Valeur Sécuritaire")
Sc.write("bc b0 08 38 00")
Sc.Print(vbcr & "Bytes dans le buffer : " & Sc.BytesInBuffer & vbcr)
Sc.Read(1)
Sc.Read(116)
End Sub
Vérification de votre Code Pin:
Information sur le transcodage du code PIN effectue par le TPE.
Quand on tape, sur le TPE, le code '1234' (par exemple),
le TPE effectue le traitement suivant:
- conversion de chaque chiffre en binaire sur 4 bits (0001 0010 0011 0100)
- rajout de 14 bits '1' a droite (0001 0010 0011 0100 11111111111111)
- groupe par 4 bits a partir de la droite (00 0100 1000 1101 0011 1111 1111 1111)
- reconvertir les groupes de 4 bits en hexa (0 4 8 D 3 F F F )
Les 4 octets hexa envoyes par le terminal seront donc 04 8D 3F FF.
Dialogue TPE <--> CB
TPE --> BC 20 00 00 04 ; Presentation code Pin
20 <-- CB ; pret pour reception code pin
TPE --> 04 8D 3F FF ; 4 byte code pin
90 00 <-- CB ; Code pin recu
Code:
Sub Main()
'Instruction BC 20 Présentation du code PIN
'EXECUTION DE LA DEMANDE DE CODE PIN
'INSPIRE DE L EMULATEUR TPE GEZEROLEE
'ESSAI COMPREHENSION REDRUM 2006
Sc.Print(vbCr &"Demande de code PIN")
Sc.write("BC 20 00 00 04")
Sc.Print(vbcr & "Bytes dans le buffer : " & Sc.BytesInBuffer & vbcr)
Sc.Read(1)
'Input code secret ici 1695 = 05 A5 3F FF
'0001 0110 1001 0100
'0001 0110 1001 0100 1111 1111 1111 11
'00 0101 1010 0101 0011 1111 1111 1111
'0 5 A 5 3 F F F
'05 A5 3F FF
Sc.write("05 A5 3F FF")
Sc.Read(2)
Sc.Print(vbCr &"ratification du code")
Sc.write("BC 40 00 00 00")
Sc.Print(vbcr & "Bytes dans le buffer : " & Sc.BytesInBuffer & vbcr)
Sc.Read(1)
Sc.Read(2)
End Sub
Voilà qui devrait suffir pour s'amuser pas mal avec les cartes à puces.
Le texte n'est pas fini, mais la partie sur les bandes magnétiques sera publiée
dans un prochaine numéro de Rafale.
Copyright 2006. Tous droits réservés