Clever Geek Handbook

Cómo cargamos una tarjeta bancaria de un iPhone en un llavero



Cada año, más y más empresas están mostrando interés en proyectos relacionados con Internet de las cosas ( IoT ). 



En este artículo, hablaré sobre la plataforma IoT que hemos creado, cómo cargar tarjetas bancarias en dispositivos portátiles, explorar las capacidades del marco Core NFC iOS y el posible esquema de fraude usando teléfonos inteligentes con NFC.



El artículo puede ser útil para gerentes de producto, tecnólogos, desarrolladores de iOS, ingenieros de control de calidad que se dedican a pagos móviles, así como para cualquier persona interesada en la tecnología fintech para ampliar sus horizontes.



¡Hola, Habr!



Mi nombre es Maxim. He estado haciendo desarrollo industrial desde 2005. Trabajo en Wallet desde 2013, y desde 2015 he estado ayudando al negocio de la compañía a desarrollar nuevos servicios fintech como jefe de división.



En Wallet, nuestro equipo ha lanzado muchos productos innovadores. Esta es una de las primeras tarjetas bancarias totalmente virtuales del mundo en un teléfono inteligente con la posibilidad de pago sin contacto (un año antes del lanzamiento de Apple Pay en Rusia y mucho antes del lanzamiento de Apple Card), y la primera tarjeta de transporte , y la primera tarjeta de fan , y la primera tarjeta de campus en un teléfono inteligente. ...



El año pasado, junto con Mastercard, lanzamos el servicio Wallet PayEs el único servicio en el mundo que, a diferencia de sus contrapartes, funciona independientemente del fabricante del teléfono inteligente o del sistema operativo. Por ejemplo, Pay Wallet funciona en teléfonos inteligentes Huawei que carecen de los servicios de Google.



Expresiones de gratitud



Kolya Ashanin , quien me motivó a escribir el artículo y me ayudó durante su preparación para su publicación.



Sasha Pryimak, quien, bajo mi supervisión, llevó a cabo la investigación descrita en el artículo.



Además, muchas gracias por su participación y apoyo:

Katya Turkina, Anton Davydov, Lesha Ershov, Dasha Alekseenko.



Plataforma de IoT



En este momento, mi equipo y yo estamos trabajando en el lanzamiento de una plataforma de Internet de las cosas que podrá complementar y expandir la experiencia existente de uso del servicio Pay e introducir el pago (y otros servicios de identificación) en aquellas cosas que generalmente llevamos con nosotros: los llamados dispositivos portátiles. 



El Internet de las cosas es un concepto de objetos físicos familiares equipados con tecnologías para interactuar con el entorno externo o entre sí. 



En este concepto, los casos de uso familiares de las cosas se reconstruyen mediante la automatización.



Un ejemplo de dispositivos portátiles son los relojes inteligentes, las pulseras de fitness, los anillos y los llaveros.



Si antes una persona usaba un anillo por belleza o simbolismo, ahora, en el concepto de Internet de las cosas, el anillo sirve como un instrumento de pago, un pase de control de acceso., control remoto para otros dispositivos inteligentes, etc. Así, aparecen nuevos casos de uso convenientes para lo familiar.



Las cosas inteligentes son ahora una tendencia mundial. Esto se evidencia en los datos estadísticos recopilados por varias agencias mundiales (ver enlaces al final del artículo). 



En este artículo, quiero utilizar el ejemplo de nuestra investigación en el desarrollo de una plataforma de IoT para decirle en qué tareas está trabajando la dirección fintech de la aplicación Wallet, qué problemas enfrentamos y cómo usamos tecnologías probadas de la industria de las tarjetas para crear nuevos productos.



Para empezar, describiré brevemente y en palabras sencillas las tecnologías en las que se basa nuestra plataforma. Si está interesado en leer más sobre estas tecnologías, habrá enlaces al final del artículo. 



  1. , Secure Element — , 5-20 . , -, , - , . , SIM-, . ( ).



    , — . , .
  2. GlobalPlatform Card Specification — , .
  3. TSM  (Trusted Service Manager) — . .
  4. EMV — ( ), . , - , , .


Estos son los principales escenarios para la interacción de un teléfono inteligente con el dispositivo en sí, que colocamos en nuestra plataforma (en todos los escenarios, el usuario controla el dispositivo portátil a través de la interfaz de la aplicación móvil en el teléfono inteligente): 



El primer escenario es la interacción con dispositivos portátiles activos. Los dispositivos activos son dispositivos portátiles que tienen su propia batería (por ejemplo, una batería). Como regla general, la cosa tiene su propio sistema operativo y hay un módulo BLE para comunicarse con un teléfono inteligente. El fabricante del dispositivo proporciona SDK y claves de acceso para interactuar con el elemento de seguridad. 



Así funcionan todos los relojes inteligentes y las pulseras de fitness con función de pago sin contacto. Todo es sencillo y claro: lo tomamos y lo hacemos. 



El segundo escenario es más interesanteEs la interacción con dispositivos portátiles pasivos. Los dispositivos portátiles se denominan dispositivos pasivos que no tienen su propia batería. Estos dispositivos están alimentados por un campo magnético externo en el que deben colocarse. Puede ser el campo electromagnético de un lector de terminal sin contacto o la antena NFC de un teléfono inteligente. Por lo tanto, las tarjetas bancarias sin contacto se pueden llamar con seguridad dispositivos portátiles pasivos. 



El problema es que necesita cargar su tarjeta bancaria en un dispositivo portátil pasivo desde una aplicación en su teléfono inteligente.



Rompemos (condicionalmente) este escenario según el tipo de smartphones:



  1. Cualquier teléfono inteligente sin NFC
  2. Teléfono inteligente Android con NFC
  3. iPhone con NFC


Para el primer tipo, utilizaremos un lector externo ubicado en terminales especiales de personalización. En definitiva, el terminal de personalización y la aplicación móvil en el smartphone están conectados al mismo backend que sincroniza a ambos clientes. El token se carga a través del terminal de personalización y el usuario ve el resultado en la interfaz de la aplicación móvil.



La implementación del terminal de personalización puede ser diferente: puede ser el mismo teléfono inteligente del usuario conectado a un lector de tarjetas inteligentes externo a través de BLE o USB, o puede ser un dispositivo externo autónomo (una computadora completa con un lector conectado, acceso a Internet y software de control) ...



Para el segundo tipo (Android con NFC), la implementación es clara. En este caso, el teléfono inteligente se puede utilizar como terminal, alimentar el dispositivo pasivo desde la antena NFC y cargar un token de tarjeta bancaria en él.



En nuestro estudio, describiré en detalle cómo trabajamos en el tercer tipo de teléfonos inteligentes (iPhones con NFC). Como dispositivos portátiles, utilizamos llaveros de ISBC , el socio con el que estamos lanzando el piloto.



Propósito del estudio



¿Podemos permitir que el usuario de iOS Wallet cargue su tarjeta bancaria en un dispositivo portátil adjuntándola al iPhone?



Es decir:



  1. El usuario en la aplicación "Wallet" ingresa los datos de su tarjeta bancaria
  2. El usuario apoya un dispositivo portátil contra la parte posterior de un iPhone
  3. La tarjeta bancaria se carga en el dispositivo portátil.


En consecuencia, la tarea técnica es determinar si es posible cargar una tarjeta bancaria en un elemento de seguridad externo (elemento seguro) utilizando un iPhone normal y su antena NFC , a través del protocolo ISO / IEC 7816 (T = CL). 



Tareas adicionales:



  1. Obtenga ATR (Answer To Reset) del chip sin quitarlo del lector
  2. Obtenga el UID (Identificador único) del chip


Estos datos pueden ser útiles ya que a menudo se utilizan para identificar el chip en los sistemas de los proveedores de servicios y diversificar las claves a partir de los datos confidenciales de las aplicaciones del chip.



Que tenemos:



  • iPhone 8 con iOS 13.5
  • Pruebe el dispositivo portátil: llavero ISBC con un chip JCOP 3 EMV P60 integrado y subprogramas cargados de NXP :

    PPSE y un subprograma que implementa M / Chip Advance - Pago de especificación de tarjeta y almacenamiento de datos v1.1;
  • claves del chip del dominio de seguridad del emisor.


Decisión



Al principio, descompondremos la tarea principal, es decir, determinaremos los pasos necesarios para convertir un llavero completamente ordinario (bueno, casi) en un medio de pago completo:



  1. Establecer una conexión entre el chip y el módulo NFC del iPhone
  2. Instalación de los applets de Mastercard M / Chip Advance y PPSE en el chip
  3. Personalizar applets 


Establecer una conexión



Es aquí donde hablaremos de las características del framework Core NFC agregado en iOS 13.

Por cierto, en iOS 14 no se han producido cambios significativos con respecto al tema del artículo, por lo que todo lo descrito es relevante para ella.



Entonces, en la decimotercera versión del sistema operativo de Apple, fue posible no solo leer datos de etiquetas NFC , como lo era en iOS 12 (pero no antes de iOS 11, antes, la interacción a través de NFC solo era posible dentro de Apple Pay), sino también escribirlos, y también se comunican en el lenguaje de comando APDU con cualquier chip que cumpla con uno de los siguientes estándares:





Para hacer esto , se han agregado dos nuevas clases a Core NFC : NFCNDEFReaderSession y NFCTagReaderSession .



El primero se usa para interactuar con las etiquetas NDEF y el segundo se usa para todo lo demás , respectivamente.



En nuestro caso, se trata de un chip que admite la especificación 2.2.1 de tarjeta de plataforma global y el estándar ISO / IEC 7816 , lo que significa que usaremos la segunda clase.



La documentación dice lo que debe hacer (además de escribir código, por supuesto) para comenzar a comunicarse con el chip de acuerdo con ISO 7816:





Pero debajo hay una restricción tan interesante: solo queremos "sentirlo", habiendo aprendido qué significa exactamente. Agregue una línea, por ejemplo, "Permitir conexión NFC" para la clave NFCReaderUsageDescription en el archivo info.plist . También funciona con cualquier otro valor de esta clave. 



Important

Core NFC doesn't support payment-related Application IDs.













[Aquí, en la columna de la izquierda, no la clave en sí, sino su descripción, XCode esconde los nombres formales]



A continuación, si queremos interactuar con el chip como con un dispositivo ISO / IEC 7816 , entonces en el valor de la clave com.apple.developer.nfc.readersession. iso7816.select-identifiers  especifica la lista de ID de todos los applets (Identificador de aplicación o AID), con los que interactuará la aplicación.                          





Vale la pena aclarar aquí que estos identificadores no son solo un conjunto aleatorio de caracteres.

Se trata de cadenas hexadecimales que contienen información sobre la aplicación a la que están asignadas.



Los AID pueden tener de 5 a 16 bytes de longitud (dos caracteres por línea = un byte). Consisten en dos partes, la primera identifica al proveedor de la aplicación (para Mastercard es "A000000004"), la segunda dice qué tipo de producto es este proveedor (para un producto llamado "Mastercard" es "1010" y, por ejemplo, para Maestro es "3060 "). 



Además, a veces se requiere poner información adicional en la AID, por ejemplo, si hay dos aplicaciones idénticas del mismo proveedor en el chip, pero para diferentes bancos. Para esto hay soporte para Long AID (o Extended AID). Siempre que la longitud del AID no exceda los 16 bytes, puede escribir cualquier cosa en él. Por ejemplo, tomamos Mastercard AID y al final le agregamos “TEST”, el resultado: “A0000000041010BB5445535401”.



El único AID que está fuera de la lista es "325041592E5359532E444446303101".

De hecho, esta es la habitual (solo en formato hexadecimal), como dicen, la cadena de texto plano "2PAY.SYS.DDF01". Este es el AID PPSE, que no es un subprograma de pago per se. Solo contiene los datos ambientales requeridos por las aplicaciones de pago.



Instalación de applets



Para instalar subprogramas en un chip, necesita una conexión segura (Protocolo de canal seguro o SCP); lo hicimos entre bastidores utilizando un lector PC / SC normal y la plataforma Cardsmobile TSM.



Sin embargo, incluso si no tiene ninguno de estos, puede intentar instalar su propio subprograma en un chip, solo uno virtual.



Necesitará cualquier IDE con soporte JCOP Shell y emulador JavaCard, por ejemplo este .



Cree un proyecto vacío, especifique la AID deseada (por ejemplo, 0000000000) y ejecútelo.



Entonces entendemos los pasos:



  1. / card

    Obtenga ATR, envíe SELECT sin ID para que se seleccione Card Manager;





  2. auth

    , ;



  3. ls ()

    , /;





  4. install [packageAID] [appletAID] [instanceAID]

    :



    packageAID — (Module), , «0000000000»

    appletAID — (Load File), , «000000000000»

    instanceAID — , , , «A0000000041010»;





  5. ls

    , :







De hecho, personalizar un applet es muy sencillo; todo lo que se requiere es cargar los datos de pago requeridos en él. Para hacer esto, necesita seleccionar el subprograma con el comando SELECT por su AID, establecer una conexión segura y enviar al subprograma seleccionado el comando STORE DATA con los datos dentro.



Ahora volvamos a la lista de AID en el archivo info.plist: ¿por qué es necesario y cómo elige exactamente Core NFC con qué subprograma interactuar?



Se parece a esto:



  1. El programa recorre la lista de arriba a abajo;
  2. Para cada AID, genera y envía un comando SELECT;
  3. La AID del primer applet que respondió "9000" (el estado de una respuesta exitosa, aquí hay una lista de todas las respuestas posibles ) se registra en el campo initialSelectedAID de un objeto del tipo NFCISO7816Tag , que se coloca en la matriz de chips detectados


@available(iOS 13.0, *)

public protocol NFCISO7816Tag : NFCNDEFTag, __NFCTag {

   /**

    * @property initialSelectedAID The Hex string of the application identifier (DF name) selected by the reader when the tag is discovered.

    *                              This will match one of the entries in the «com.apple.developer.nfc.readersession.iso7816.select-identifiers»

    *                              in the Info.plist.

    */

   @available(iOS 13.0, *)

   var initialSelectedAID: String { get }


Además, puede seleccionar cualquier objeto de la matriz y utilizar el método sendCommand para enviar comandos APDU al subprograma seleccionado.



Ahora hablemos de esta limitación:

  

Core NFC doesn't support payment-related Application IDs.


Es decir, Core NFC no admite AID de pago, es decir, AID de combate con las que funcionan los terminales de pago.



Por supuesto, puede agregar una AID de pago a la lista info.plist, pero Core NFC la ignorará y no enviará un SELECT (por cierto, aquí hay una lista de todas las AID usadas ). Así es como Apple protege su tecnología Apple Pay, evitando que los desarrolladores externos accedan a cualquiera de las funciones de pago del iPhone (y todo lo relacionado con ella).



Soluciones alternativas



Lo primero que me viene a la mente es si es posible agregar a info.plist no el AID del applet de pago, sino el AID Card Manager (Card Manager es un conjunto de servicios dentro del sistema operativo del chip que gestionan la tarjeta, que se encargan de la administración y seguridad), de modo que luego enviarle manualmente el comando SELECT con la AID del applet deseado?



Aquí nos topamos con el primer error: Core NFC no permite enviar un comando SELECT que contenga una AID que no esté registrada en info.plist .



De acuerdo, agregamos A0000000041010, pero esto también es un error: Core NFC no permite enviar un comando SELECT que contenga una AID de pago, independientemente de si está en info.plist o no.



Veamos cómo funciona la restricción de ID.



En info.plist hemos especificado las siguientes AID: 



1. A000000001510000                        	- GlobalPlatform Card Manager AID
2. 325041592E5359532E444446303101      - Proximity Payment System Environment (PPSE) 
3. A0000000041010                             	- Mastercard Credit/Debit (Global)
4. A00000000401                                 	- Mastercard PayPass
5. A00000000410101213                    	- Mastercard Credit
6. A00000000410101215                    	- Mastercard Credit
7. A00000000410101214                    	-   AID                 
8. A00000000410101216                    	-   AID 
9. A0000000041010121F                    	-   AID 
10. A0000000041010BB5445535401 	        -   Long AID
11. A0000000041010BB5445535405 	        -   Long AID
12. A000000004101FBB5445535401 	        -    AID                
13. A000000004101F1213                    	-    AID                 
14. A00000000F1010                             	-    AID
15. A0000000040F                                     -    AID


Instalamos 14 subprogramas de pago con diferentes AID (elementos 2-11 - AID de pago) e intentamos enviar los comandos SELECT del administrador de tarjetas con cada uno de estos AID.



Números 12-15 respondidos .  



Resulta que la restricción se impone a un determinado prefijo AID, cuya presencia determina si es un identificador de pago o no.



Es una pena, pero este método ya no es válido.



La segunda opción de personalización proporcionada por GlobalPlatform es el comando INSTALL [para personalización].





Se envía al administrador de tarjetas y contiene la AID del subprograma que debe personalizarse.



Luego, puede enviar comandos de STORE DATA a Card Manager, que los reenviará a la aplicación de destino.



Pero hay una limitación. Para que un applet admita este tipo de personalización, debe implementar la interfaz org.globalplatform.Application .



Card Manager, al comando INSTALL [para personalización] con Mastercard Credit / Debit (Global) AID, que fue asignado al applet M / Chip Advance de NXP , respondió con el error "6985" (Condiciones de uso no satisfechas), lo



que significa que debe verificar si implementa ya sea la interfaz de la aplicación .



Para hacer esto, escribimos una aplicación ficticia simple que implementa esta interfaz. Como se esperaba, respondió "9000" en INSTALAR [para personalizar].



Pero cuando la Aplicación se eliminó de las interfaces implementadas por la aplicación, comenzó a responder a este comando "6985", como en el caso del subprograma M / Chip Advance.



Por tanto, el problema es precisamente que la aplicación NXP no implementa la interfaz necesaria para este tipo de personalización. Este método también desaparece.



Tareas adicionales



  1. Obtención del UID del chip

    Esto se puede hacer de una forma muy sencilla.

    Al comienzo de una sesión NFC , el módulo busca chips, los AID de los applets registrados en info.plist, y los agrega a una matriz.

    Después de eso, cualquiera de ellos se puede obtener desde allí, y si su tipo es NFCISO7816Tag , entonces tiene un campo identificador, que contiene el UID del chip. 



    /**
  * @discussion The hardware UID of the tag.
*/
var identifier: Data { get }


  2. Obtención de un chip ATR Pero parece que Core NFC no puede recibir ATR , porque no hay herramientas separadas para esto en el marco y no puede obtener ATR usando comandos APDU .



conclusiones



¿Qué hay en el fondo?



  1. ISO/IEC 7816 ( UID), Core NFC;
  2. , Apple ;
  3. , , iPhone, , Application — ;
  4. , AID — .


Respondiendo a la pregunta planteada al principio, ¿podemos darle al usuario de Wallet la oportunidad de cargar su tarjeta bancaria en el llavero adjuntándola al iPhone? No, esto todavía no es posible.



Como parte de la tarea, decidimos utilizar un lector BLE externo para cargar un token de tarjeta bancaria desde un iPhone en un dispositivo portátil pasivo.



Con suerte, en el futuro, Apple ampliará las capacidades de NFC Core para lograr esto y una variedad de otras tareas de tokenización y pago en aplicaciones de terceros. Sin embargo, noticias recientes indican que es poco probable que esto suceda en un futuro próximo.



Un efecto secundario del estudio



En el transcurso del trabajo, nació un posible esquema de fraude, que no se puede reproducir con los teléfonos inteligentes de Apple, pero es muy posible implementarlo a través de un teléfono inteligente Android con soporte NFC y tecnología Host Card Emulation.



La conclusión es: 



  • el primer smartphone se utilizará como terminal, es decir, se conectará a tarjetas bancarias e interactuará con sus applets de pago,
  • el segundo teléfono inteligente, como medio de pago (en el momento de la compra, se verá como un pago regular con un teléfono inteligente).


Con este esquema, puede crear una tarjeta bancaria en cadena - teléfono inteligente - teléfono inteligente - terminal de pago, a saber:



  1. El primer teléfono inteligente está conectado a cualquier tarjeta bancaria;
  2. El segundo se aplica al terminal de pago;
  3. El segundo teléfono inteligente emula una tarjeta bancaria enviando comandos APDU enviados por el terminal al primer teléfono inteligente;
  4. El primer teléfono inteligente transmite estos comandos a la tarjeta bancaria adjunta, transmitiendo sus respuestas al segundo teléfono inteligente;
  5. El segundo teléfono inteligente transmite las respuestas recibidas al terminal;
  6. Se ha realizado el pago.


Es decir, potencialmente un estafador puede poner un teléfono inteligente en su bolsillo y pagar la compra. ¡Ten cuidado!



Para evitar convertirse en víctima de un esquema tan fraudulento, puede, por ejemplo, transferir sus tarjetas bancarias a su teléfono inteligente y no llevar plástico con usted.



En lugar de una conclusión



Intenté escribir el artículo en un lenguaje sencillo, sin profundizar demasiado en la terminología del área temática. En él, describí uno de los proyectos innovadores en los que estamos trabajando, el área temática y un poco de investigación sobre las nuevas características del marco iOS Core NFC.



Cualquier comentario es bienvenido: preguntas, revisiones, comentarios, adiciones, críticas constructivas.



Enlaces útiles



Si está interesado en el tema descrito en el artículo, a continuación se muestran varios enlaces para un estudio más detallado:



  1. Libro de I. M. Goldovsky " Tarjetas de microprocesador bancario "

  2. Concepto de tokenización de pago EMV

  3. Artículos con análisis del mercado IoT: 



More articles:


All Articles