Publicación técnica
Desarrollo para EMV, Parte I
ID TECH fabrica y comercializa una amplia variedad de dispositivos de pago, casi todos los cuales, hoy en día, son compatibles con «tarjetas chip» (o «tarjetas inteligentes»). Los pagos realizados con una tarjeta chip se denominan genéricamente «EMV con contacto» o, en ocasiones, simplemente «EMV». (EMV, por supuesto, son las siglas de Europay, MasterCard y Visa; el consorcio de marcas de tarjetas.)
En términos del sector, una transacción EMV es aquella que cumple con los requisitos de la especificación de cuatro volúmenes Especificaciones EMV de Tarjetas con Circuito Integrado para Sistemas de Pago (disponible en https://www.emvco.com/). Asimilar esta especificación requiere tiempo. Al estar compuesta por cuatro volúmenes, se trata de una especificación bastante extensa. No obstante, ID TECH se esfuerza por convertir la «compatibilidad con EMV» en un objetivo fácil de alcanzar para los desarrolladores, ofreciendo una variedad de herramientas, SDK, demostraciones y otros recursos gratuitos diseñados para acelerar el tiempo de comercialización de los integradores de POS y de quienes necesiten una rápida cumplimiento EMV»..
EMV: ¿Por dónde empezar?
La mayoría de los nuevos clientes de ID TECH cuentan con un buen nivel técnico. Aun así, hay mucha variación en el grado de conocimiento sobre EMV que los clientes aportan a un proyecto nuevo. La mayoría conoce muy bien los sistemas de pago en el contexto de los MSR (lectores de banda magnética). Algunos ya han trabajado antes con EMV, pero desconocen el sin contacto EMV. Otros son nuevos en el propio EMV.
Como punto de referencia, solemos recomendar a los integradores que consulten el white paper gratuito de ID TECH titulado Transacciones EMV con el Universal SDK. La primera mitad de este white paper de 25 páginas es un repaso del flujo de eventos EMV. Los eventos principales de ese flujo pueden resumirse de la siguiente manera:
En cada etapa de este proceso, el lector de tarjetas se comunica con el chip de la tarjeta inteligente utilizando protocolos de muy bajo nivel definidos en la norma ISO-7816. Casi toda la lógica del lector de tarjetas para ello está aislada en lo que se conoce como kernel EMV Level 2. En otras palabras, está fuera del alcance del desarrollador de la aplicación de pago, quien solo debe preocuparse de enviar comandos al kernel (y no a la propia tarjeta). Incluso esto es una pequeña imprecisión. En realidad, el desarrollador de la aplicación de pago enviará comandos al lector; y el lector gestionará las interacciones subyacentes necesarias con el kernel, que, a su vez, interactuará con la tarjeta.
Comunicación con el lector
¿Cómo se envían comandos al lector? Hay dos opciones:
- Establecer conectividad con el lector (normalmente mediante USB o RS-232) y enviarle comandos de firmware directamente. O bien:
- Utilizando un SDK de lenguaje de alto nivel, escribir código (en C/C++, C#, Objective-C, Java o Swift) que aproveche la biblioteca SDK adecuada de ID TECH para emitir los comandos de firmware subyacentes.
El segundo método suele ser más sencillo, ya que requiere relativamente poco tiempo dominar las API de lenguaje de alto nivel del Universal SDK de ID TECH (además, te proporcionamos mucho código de ejemplo sobre el que construir). El inconveniente de la opción n.º 2 es que tiende a vincular tu aplicación a un único lenguaje de desarrollo y sistema operativo. Con la opción n.º 1, la elección del lenguaje (y del SO) depende de ti, pero tendrás que aprender la API de comandos de firmware (a nivel de bytes) del dispositivo en cuestión y gestionar tú mismo todos los aspectos de conectividad.
Independientemente de si decides comunicarte directamente con el lector de tarjetas (mediante conexión serie, utilizando comandos de firmware en bruto) o mediante la conectividad integrada y los comandos de alto nivel del Universal SDK, es importante entender que una transacción EMV (y aquí me refiero al EMV con contacto tradicional, no al sin contacto) se desarrolla en tres etapas. En la jerga del Universal SDK, nos referimos a estas etapas como Start Transaction, Authenticate Transaction y Complete Transaction. (Cada una tiene un método o función correspondiente en el USDK.) Desde el punto de vista del flujo del programa, esto significa que el kernel devuelve el control al llamador dos veces durante el flujo de la transacción: una primera vez, tras la finalización de Start Transaction; y una segunda, tras Authenticate Transaction (pero antes de Complete Transaction). Estos puntos de pausa tienen implicaciones importantes para el flujo de datos, porque, entre otras cosas, se devuelven distintos TLV (tripletas tag-length-value) tras cada fase de la transacción, y es importante capturar los TLV que necesites en el momento en que estén disponibles, ya que podrían no estarlo en una fase posterior. Ejemplo típico: el tag 57 (datos de Track 2) está disponible al final de Start Transaction (pero no al final de Complete Transaction).
Criptogramas en EMV
Uno de los elementos de datos más importantes en cualquier transacción EMV es el Application Cryptogram que se devuelve en el tag 9F26. Una sesión EMV con contacto suele producir dos criptogramas (el 9F26 se devuelve dos veces): uno antes de Complete Transaction y otro después. El evento que solicita a la tarjeta la generación del criptograma se denomina petición Gen AC (Generate Application Cryptogram).
La razón por la que estos criptogramas son importantes es que constituyen la prueba irrefutable de que una tarjeta chip auténtica y legítima estuvo físicamente presente en una determinada transacción. (También certifican los valores de datos concretos que se generaron durante esa transacción.) En el momento del Gen AC, el kernel L2 presenta a la tarjeta chip una lista de objetos de datos (que contiene datos específicos de la transacción en curso), y la tarjeta chip responde utilizando su clave privada (conocida únicamente por el chip) para firmar esos datos y producir un artefacto digital infalsificable (un criptograma de 8 bytes) que da fe de la legitimidad de la tarjeta y de los datos. La legitimidad del criptograma puede ser verificada por la autoridad en línea que en última instancia autorizará la transacción (o la rechazará, según corresponda). Por eso se inventaron las tarjetas chip y por eso existe EMV. Los datos de la banda magnética son fáciles de falsificar. Los criptogramas generados bajo demanda por un chip, no.
En mi próxima publicación, continuaremos esta conversación analizando qué tipos de criptogramas puede generar la tarjeta, qué significan, qué debe hacer con ellos el desarrollador de la aplicación de pago y cómo influyen en el éxito o el fracaso de una transacción. ¡No te pierdas la Parte II!
¿Tienes dudas sobre las transacciones EMV? ¿Sobre lectores de tarjetas? ¿Tecnología sin contacto? ¿Carteras digitales? Ponte en contacto con nuestros expertos: