Catégorie : credit cards

Attaque sur carte sans contact

Un petit retour sur le workshop de la Nuit du Hack.

La démonstration principale de ce workshop était une attaque sur les cartes sans contact. Celles-ci proposent de payer en sans contact à une distance d’une dizaine de centimètre du lecteur. Ce paiement ne nécessite pas de saisir son code PIN. Il est cependant limité à des transactions d’un montant maximal de 20€ et à 4 transactions consécutives. Après il faut passer en mode contact pour réaliser une transaction.

Description de l’attaque

L’idée est de réaliser un proxy permettant de faire une transaction à distance.

explain

Le téléphone est un téléphone NFC qui permet de réaliser des transactions en sans contact. Celui-ci est relié par un réseau, par exemple un réseau internet, à un lecteur de carte sans contact. Ce lecteur dans le schéma est représenté à droite à coté du personnage en costume. Il est relié à un ordinateur afin de pouvoir être accessible depuis un réseau.

Nous aurions aussi pu utiliser un autre téléphone NFC à la place du couple PC – lecteur sans contact. Cependant je n’avais à ma disposition qu’un seul téléphone NFC.

L’attaque consiste à réaliser un proxy passif afin de réaliser un paiement à l’aide d’une carte qui ne se trouve pas à proximité du lecteur. Puisque la technologie est sans contact, cela peut être réalisé à l’insu de la cible.

Réalisation

Afin de réaliser cette attaque, un téléphone Nexus S a été utilisé. Ce téléphone possède une puce NFC et permet l’installation de l’application simply tap avec une cyanogen mod 9.1. Cette application permet d’avoir accès à l’antenne NFC du téléphone depuis une application android. Le but premier est de réaliser des services de paiement en cloud.

Dans notre cas, au lieu d’interroger un cloud, nous interrogeons un lecteur distant afin de dialoguer directement avec une carte sans contact.

Démonstration :


Attaque par proxy par oversimple

Comment s’en protéger

Pour s’en protéger, c’est assez simple il suffit de mettre sa carte dans un étui en fer. Il existe des portes feuilles blindés qui font très bien l’affaire.

Bibliographie

SimplyTapp NFC Payment System Debuts with CyanogenMod 9.1
emulating pki smart card with cm9.1
NFC Proxy

Espionner une transaction Monéo

La carte Monéo

La carte Monéo est un porte monnaie électronique. La spécificité d’un porte monnaie électronique est que l’argent n’est pas présent directement sur la carte.

Pour la Monéo, il est nécessaire de présenter votre carte bancaire. Une transaction est effectuée de la même manière que si vous retiriez de l’argent en liquide. Cet argent est alors inscrit sur la carte Monéo. Monéo propose un service de chargement en ligne. Nous allons en profiter pour observer la manière dont fonctionne le chargement d’une telle carte.

L’espion de carte à puce

L’espion fonctionne à partir d’un microprocesseur Microchip PIC32MX512L. Pour plus de détails sur le développement :

Le protocole ISO7816 a été implémenté afin de pouvoir obtenir des traces qui ressemblent à ceci :

T=1:

ATR : 3BE800008131FE454A434F505632343194
Term (S-block):
00C101 FC 3C
Card (S-block):
00E101 FC 1C
Term (I-block):
00000C 00A4040007A0000000041010 0F
Card (I-block):
000025 6F218407A0000000041010A516500A4F56455253494D504C45BF0C07636172647370799000 C3
Term (I-block):
004005 00C0000041 C4

T=0:

ATR : 3B 66 00 00 90 D1 02 01 20 B1 
Term (CLA INS P1 P2 P3):
00 A4 04 0C 06 
Card (Ack):
A4 
Term (UDC):
A00000006900
Card (SW): 
9000
Term (CLA INS P1 P2 P3):
00 B2 01 BC 16
Card (ACK UDR SW): 
B2 9250003840106021502D15091207010250455552011C 9000

Le chargement Monéo

A l’aide de l’espion, nous observons un chargement de Monéo de dix euros effectué sur internet.

Celui ci se décompose en deux parties, la première partie est une lecture des informations de la carte, numéro de PAN, solde etc…

Ensuite un série de commandes est exécutée de cla E0 et d’instructions 30.
La classe E0 nous indique alors qu’il s’agit d’une carte supportant jusqu’à 16 canaux logiques (16 pointeurs de fichier) et que la commande inclus du Secure Messaging.

Edition après le commentaire de SV :

Une petite remarque en passant: CLA = E0 signifie surtout que le bit de poids fort est à 1 donc l’instruction (et la classe) sont propriétaires. La norme ISO/IEC 7816 ne s’applique donc pas pour interpréter l’octet CLA (en particulier les 16 canaux).

Autrement dit, le chargement est protégé par un calcul de MAC. Le mac faisant 8 octets de long, on peut vraisemblablement penser à du 3-DES.

Term (CLA INS P1 P2 P3):
E0 30 00 00 1C 
Card (ACK):
30 
Term (UDC):
00000000001000000000000000007001070600018820121121192244
Card (SW)
6139 
Term (CLA INS P1 P2 P3):
00 C0 00 00 39 
Card (ACK UDR SW):
C0 010005010010000021108888866666001000315D110004010010000100000030000000000000000000000000000000000DCE86FF2230D6A91B 9000
Term (CLA INS P1 P2 P3):
E0 30 80 00 35
Card (ACK):
30 
Term (UDC):
10000501001000250001700107060000000000018820121121192244010000003000000000000000000000000DAE7D69BE5F4394EA 
Card (UDR):
610D 
Term (CLA INS P1 P2 P3):
00 C0 00 00 0D 
Card (ACK UDR SW):
C0 11000501001000003110000000 9000

Conclusion

On retrouve dans la dernière UDC la date de la transaction ainsi que le montant. La sécurité du mécanisme repose la génération des macs par le serveur. Ceci est un système sécurisé à condition que les algorithmes cryptographiques soient correctement implémentés.

Interroger une carte à puce avec Java et un lecteur PC/SC

Utiliser la librairie smartcardio de java

La librairie smartcardio permet de comuniquer entre un lecteur pcsc et une application java.
Ceci peut ouvrir la voie à des applications sécurisées par carte à puce. Les cartes à puce permettent de stocker des clés cryptographiques de manière sûre.

Pour l’installation des drivers PC/SC direction cet article : http://oversimple.fr/espionner-une-transaction-avec-carte-a-puce/

Utilisation de la librairie dans eclipse

De base la librairie n’est pas accessible. Pour contourner ce problème, copier le code ci dessous dans une classe java :

/**
 * @param args
 */
public static void main(String[] args) {
	try {
		/* Affiche la liste des lecteurs PCSC */
		TerminalFactory factory = TerminalFactory.getDefault();
		List terminals = factory.terminals().list();
		System.out.println("Terminals: " + terminals);
 
		/* Selectionne le premier lecteur */
		CardTerminal terminal = terminals.get(0);
 
		/* Etablit la connection avec la carte */
		Card card = terminal.connect("*"); 
		/* '*' Laisse le programme choisir le mode de communication */
		System.out.println("card: " + card);
		CardChannel channel = card.getBasicChannel();
 
		// disconnect
		card.disconnect(false);
	} catch (CardException e) {
		e.printStackTrace();
	}
}

Vous devriez avoir l’erreur suivante.

Pour y parer, suivez les étapes décrites ci dessous :

On supprime alors la librairie java.

It’s OverSimple isn’t it?

Espionner une transaction avec carte à puce

La suite de l’article d’introduction sur la réalisation d’un espion pour carte à puce.
Afin de rendre les choses plus explicites on commence par un petit schéma :

Diagramme en boite de l'espion
Diagramme de l’espion de carte à puce

Le micro-contrôleur va lire les niveaux logiques qui circulent sur les entrées/sorties de la carte à puce. Pour cela il est nécessaire d’utiliser une rallonge. La construction de cette rallonge est décrite dans l’article précèdent :

Plus tard, une interface de lecture, pour les humains, sera développée avec un écran LCD. Au cous du développement, nous aurons besoin de réaliser des transactions. Cette article va traiter de la mise en place de l’environnement de test et de la lecture des données d’une carte bancaire.
Notez que nous utilisons une carte bancaire mais que ceci aurait pu marcher avec n’importe quelle autre carte à puce.

Lecteur de carte à puce

Afin de dialoguer avec la carte à puce, nous utiliserons un lecteur de carte à puce de type PC/SC. Ces lecteurs sont des lecteurs pour PC qui se connectent en USB. Il existe des librairies pour faciliter l’utilisation de ces lecteurs en Java. J’ai acheté le mien sur le site de Monéo : Boutique Moneo

une fois branché, il est nécessaire d’installer les drivers du lecteur. Pour ma Debian cela donne ça :

$:sudo apt-get install libpcsclite1
$:sudo apt-get install libacsccid1
$:sudo apt-get install pcsc-tools

Pour vérifier que l’installation s’est bien déroulée, on insère une carte dans notre lecteur et on le lance dans un terminal :

$pcsc_scan
PC/SC device scanner
V 1.4.18 (c) 2001-2011, Ludovic Rousseau 
Compiled with PC/SC lite version: 1.7.4
Using reader plug'n play mechanism
Scanning present readers...
0: ACS ACR 38U-CCID 00 00
 
Mon Jun 11 20:03:00 2012
Reader 0: ACS ACR 38U-CCID 00 00
  Card state: Card inserted, 
  ATR: 3F 65 25 08 66 04 6C 90 00
 
ATR: 3F 65 25 08 66 04 6C 90 00
+ TS = 3F --> Inverse Convention
+ T0 = 65, Y(1): 0110, K: 5 (historical bytes)
  TB(1) = 25 --> Programming Param P: 5 Volts, I: 1 milliamperes
  TC(1) = 08 --> Extra guard time: 8
+ Historical bytes: 66 04 6C 90 00
  Category indicator byte: 66 (proprietary format)
 
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3F 65 25 08 66 04 6C 90 00
3F 65 25 .. .. 04 6C 90 .0
	Carte Bancaire (Frenc

Si vous recevez une réponse du type, alors le driver pcsc est correctement installé.

Analyse de la réponse

L’ATR (Answer to reset) provient de la carte et nous indique quel protocole doit être utilisé aussi bien en terme de durée d’un caractère que de signification d’un niveau logique. Nous y reviendrons plus en détails lorsqu’il s’agira de programmer notre espion puisqu’il devra se caler sur le rythme de la transaction.

Dans le prochain article nous parlerons de l’échantillonnage à proprement parlé et nous montrerons comment se synchroniser avec les données de la carte.
Si vous souhaitez reproduire les échanges de l’article http://oversimple.fr/que-trouve-t-on-dans-une-carte-bancaire/ vous pouvez utiliser le programme gscriptor présent dans le paquetage pcsc-tool que vous venez de télécharger.

It’s oversimple, isn’t it?

Que trouve-t-on dans une carte bancaire?

Que peut on lire sur une carte bancaire?
En réalité, pas grand chose, en tout cas pas grand chose de clair. Nous allons retrouver les informations tel que le PAN présent sur la devanture,  votre nom ainsi que la date d’expiration. Concrètement, voici un log commenté d’une transaction avec carte bancaire. Le log a été obtenu en réalisant une transaction avec un lecteur PCSC et en utilisant l’outil :.

Je déconseille fortement d’utiliser votre carte bancaire pour faire ce test. Tout d’abord, nous ne savons pas si les données sont stockées avec cet outil. De plus ceci est totalement illégal. Avant d’utiliser ceci, nous avons supprimé les données sensibles de la carte.

On commence par sélectionner l’application bancaire présente sur la carte à notre disposition

00 A4 04 00 07 A0000000041010

Et la réponse commentée :

6F File Control Information (FCI) Template
 	84 Dedicated File (DF) Name
 	 	A0000000041010
 	A5 File Control Information (FCI) Proprietary Template
 	 	50 Application Label
 	 	 	O V E R S I M A P P
 	 	9F12 Application Preferred Name
 	 	 	O V E R S I M A P P
 	 	87 Application Priority Indicator
 	 	 	02
 	 	5F2D Language Preference
 	 	 	f r e n
 	 	9F11 Issuer Code Table Index
 	 	 	01
 	 	BF0C File Control Information (FCI) Issuer Discretionary Data
 	 	 	DF60 Unknown tag
 	 	 	 	0B28
 	 	 	9F4D Log Entry
 	 	 	 	0B28
90 00 : Successful

On demande ensuite le Get Processing Option. Cette commande initialise la transaction bancaire.
C’est à ce moment que les compteurs de transactions de la cartes sont incrémentés.

Terminal : 80 A8 00 00 02 8300

La carte répond

77 Response Message Template Format 2
 	82 Application Interchange Profile (AIP)
 	 	3800
 	94 Application File Locator (AFL)
 	 	08010201 10010300 18010201
90 00 : Successful

L’AIP décrit les paramètres de sécurité de la carte. Il sont décrit dans l’EMV Book 3.
L’AFL liste l’ensemble des enregistrement que l’on a le droit de lire dans la carte.

Lecture des records :

Terminal : 00 B2 01 0C 17

70 EMV Proprietary Template
 	57 Track 2 Equivalent Data
 	 	1122334455667788D15031111111111111111F
90 00 : Successful

Le track 2 equivalent data est une copie des données de la piste magnétique.
On a ici le PAN : 1122334455667788 et la date d’expiration 1503 (mars 2015).

Terminal : 00 B2 02 0C 17

70 EMV Proprietary Template
 	5F20 Cardholder Name
 	 	O V E R S I M P L E . F R
 	9F1F Track 1 Discretionary Data
 	 	0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
90 00 : Successful

Terminal : 00 B2 01 14 96

On retrouve à l’intérieur la clé publique de la banque signée par l’autorité de certification.
Dans le cas de notre carte, il s’agit de Mastercard.

Terminal : 00 B2 02 14 56

70 EMV Proprietary Template
 	8F Certification Authority Public Key Index
 	 	01
 	92 Issuer Public Key Remainder
 	 	94AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 	9F32 Issuer Public Key Exponent
 	 	03
 	9F47 Integrated Circuit Card (ICC) Public Key Exponent
 	 	03
 	9F48 Integrated Circuit Card (ICC) Public Key Remainder
 	 	BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
 	9F49 Dynamic Data Authentication Data Object List (DDOL)
 	 	9F3704
90 00 : Successful

On retrouve là encore des clés de signatures. Cependant on remarque aussi la présence
du tag 9F49 qui désigne les donnés que requiert la carte pour générer une signature RSA.
La carte demande dans cet exemple un nombre aléatoire de 4 octets.

Terminal : 00 B2 03 14 97

Ce record contient la clé publique de la carte signée par la banque.

Terminal : 00 B2 01 1C 58

70 EMV Proprietary Template
 	5F25 Application Effective Date
 	 	130301
 	5F24 Application Expiration Date
 	 	150330
 	5A Application Primary Account Number (PAN)
 	 	1122334455667788
 	5F34 Application Primary Account Number (PAN) Sequence Number
 	 	00
 	9F07 Application Usage Control
 	 	FF00
 	8E Cardholder Verification Method (CVM) List
 	 	000000000000000042514403010302031E031F03
 	9F0D Issuer Action Code – Default
 	 	B840FD8000
 	9F0E Issuer Action Code – Denial
 	 	0010000000
 	9F0F Issuer Action Code – Online
 	 	B860FD9800
 	5F28 Issuer Country Code
 	 	0250
 	9F4A Static Data Authentication Tag List
 	 	82
90 00 : Successful

La CVM list décrit la manière dont peut être authentifiée le porteur de la carte.
(Code pin, signature etc…)
Les action codes décrivent la politique de sécurité de la carte. Ainsi, c’est en fonction
de ces codes qu’elle choisit de refuser une transaction, d’aller en ligne demander à
sa banque ou bien de l’accepter directement sans aller en ligne.
Les cartes d’étudiants vont généralement systématiques interroger la banque alors que
les cartes plus haut de gamme se valident les transactions en offline.

Terminal : 00 B2 02 1C

70 EMV Proprietary Template
 	8C Card Risk Management Data Object List 1 (CDOL1)
 	 	9F02069F03069F1A0295055F2A029A039C019F37049F35019F45029F4C089F3403
 	8D Card Risk Management Data Object List 2 (CDOL2)
 	 	910A8A0295059F37049F4C08
 	9F08 Application Version Number
 	 	0002
90 00 : Successful

Le record qui va nous permettre de terminer la transaction. Dans celui se trouve
les donnés que la carte requiert pour générer le cryptogramme qui valide la
transaction.

70 EMV Proprietary Template
 	8C Card Risk Management Data Object List 1 (CDOL1)
 	 	9F02069F03069F1A0295055F2A029A039C019F37049F35019F45029F4C089F3403
 	8D Card Risk Management Data Object List 2 (CDOL2)
 	 	910A8A0295059F37049F4C08
 	9F08 Application Version Number
 	 	0002
90 00 : Successful

Dans le premier generate application cryptograme la carte demande 43 octets de donnés. Nous
les remplierons avec des zéros. Dans la réalité on y retrouve la date, le montant, etc…

80 AE 40 00 2B 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Nous indiquons que nous souhaitons approuver la transaction directement. La carte devrait répondre
qu’elle refuse la transaction car le code pin n’a pas était validé. Ceci n’est pas forcément vrai.
En effet, la carte peut répondre qu’elle accepte la transaction. La preuve ci dessous :

77 Response Message Template Format 2
 	9F27 Cryptogram Information Data
 	 	40
 	9F36 Application Transaction Counter (ATC)
 	 	0042
 	9F26 Application Cryptogram
 	 	1122334455667788
 	9F10 Issuer Application Data
 	 	4F56455253494D504C452E46520000000000
90 00 : Successful

Le cryptogram Information Data (CID) indique 40,  ce qui signifie que la carte a approuvé la
transaction. Bien entendu ceci ne marche que parce que nous avons judicieusement choisi
de mettre un montant égal à 0;
Il est inutile de penser que la sécurité des carte bancaires
est à remettre en question. Il est toujours bien plus facile de braquer le sac à main
d’une personne âgée que de pirater des cartes bancaires.

Espionner une transaction avec carte à puce

On aime bien les défis, et quand il s’agit de monter un projet, du hardware jusqu’à la couche applicative, on est toujours partant.
Nous étions à la recherche d’un outil capable de comprendre le protocole ISO7816. Cette norme est celle qui régit les transactions entre une carte à puce et un lecteur. Bien que cela existe sur le commerce, ils sont souvent réservés à des professionnels et donc hors de prix.

Associé à notre école, disposant de ressources assez intéressantes autour d’architecture à base de microcontroleurs pic32, il était tout à fait concevable de réaliser un espion bas niveau.

Conception

Afin de concevoir cet espion il est au préalable nécessaire de concevoir une sonde. Cette sonde a le format d’une carte à puce (à savoir le format ISO7816). On peut aussi trouver le schéma dans l’EMV Book 1. Celui ci sera réalisé sur un PCB dans la version finale.
Pour la phase de développement, j’ai choisi une platine de chez Selectronic : Carte d’étude SMARTCARD ISO7817 pastillée

A ce module s’ajoute un connecteur pour carte à puce : Connecteur pour carte à puce contact NO

On soude le tout et on obtient ceci :

Ce n’est pas très esthétique mais ça fonctionne correctement. Vous remarquerez les deux condensateurs de 47pif rajoutés entre les signaux à observer et la masse afin de filtrer les signaux que l’on va espionner.

La prochaine partie concernera la manière de mettre en place l’environnement de développement MPLAB X et l’environnement de simulation.

Hacking the NFC credit cards

On a pas mal entendu parler du soit disant fail de la technologie utilisée par les cartes sans contact.

Tout d’abord, revenons sur l’article publié par Korben. Quel ne fut pas notre étonnement de voir sur ce site, que nous suivons régulièrement (et passionnément), cet article. Entrons dans les détails d’une transaction, afin de comprendre pourquoi, il est impossible de dupliquer une carte bancaire aujourd’hui.

Les clés utilisées pour les transactions bancaires verrouillées avec des clés de chiffrement privé qui ne sont possédées que par la banque et la carte. Ces clés sont inaccessibles (à part pour la carte et la banque bien sur).

La question se pose quand à la possibilité d’obtenir des informations non confidentiels mais nuisibles à la vie privée des utilisateurs. Les informations disponibles ne sont rien d’autre que celles présentes en clair sur la carte. Donc plutôt que de pouvoir récupérer ces informations via un système complexe d’antenne NFC, pourquoi ne pas tout simplement se munir de bons yeux et lire par dessus l’épaule des utilisateurs. (Ou encore de bonnes oreilles et d’écouter le boulanger dire bonjour monsieur Dupont).

L’article de Renaud

Comme le souligne judicieusement les slides de la présentation, le protocole contactless est calqué tant au niveau protocolaire que du point de vue de l’application sur les principes « contact ». En fait, pour aller plus loin la spécification applicative qui décrit le processus de la transaction bancaire est totalement indépendant du protocole de communication utilisée. La norme ISO 7816 citée dans les slides est bien une référence, mais pour le protocole de communication contact. Pour la partie contact, inutile de chercher des informations dans cette norme, allez plutôt voir l’ISO 14443.

Après seulement 3 slides, je commence déjà à douter du sérieux et des connaissances de ce Renaud.

Un soucis sur les protocoles

Sans entrer dans les détails, l’attaque porte sur la possibilité de dupliquer les données publiques de la carte. Les plus malins d’entre vous aurons remarqué qu’il s’agit des données publiques. En gros, celles qui ne permettent pas de réaliser de fausse cartes. Les clés cryptographiques sont quant à elles bien gardées au chaud. De plus, ceci n’est vrai que si la personne ne possède pas plusieurs cartes de ce type. En effet, si plusieurs cartes sans contact sont présentes, il y a une collision et le lecteur est incapable d’identifier quels octets proviennent de quelles cartes. Pour faire de la lecture en masse dans une foule, çela pose déjà un assez gros problème.

Ensuite, les données présentes sur la piste magnétique sont aussi présentes dans l’application sans contact. Cette affirmation erronée vient d’une mauvaise compréhension des spécifications d’implémentations. En effet, les cartes sans contact proposent une version de paiement utilisant un mécanisme très similaire à celui des bandes magnétiques pour les petits paiements. Le mécanisme utilisé les CVC Track 2 et 3 qui sont des données équivalentes aux données que l’on trouve sur une piste magnétique. Cependant les données présentes dans la carte à puces ne sont pas les mêmes que sur la piste magnétique et ne sont pas valides pour des paiements par piste magnétique.

Source : Hacking the NFC credit cards for fun and debit 😉
Source : EMV Book 2 – Security and Key Management
Source : EMV Book 3 – Application Specification
Source : Korben

It’s over simple, isn’t it?