El estándar EMV: romper, arreglar, verificar
David Basin, Ralf Sasse y Jorge Toro-Pozo
Departamento de Ciencias de la Computación, ETH Zurich
{ cuenca, ralf.sasse, jorge.toro}@inf.ethz.ch
Resumen —EMV es el protocolo estándar internacional para
pago con tarjeta inteligente y se utiliza en más de 9 mil millones de tarjetas en todo el mundo. A
pesar de la seguridad anunciada por el estándar, anteriormente se han descubierto varios
problemas, derivados de fallas lógicas que son difíciles de detectar en la extensa y compleja
especificación de EMV, con más de 2000 páginas.
Formalizamos un modelo simbólico integral de EMV en Tamarin, un veri fi cador de
protocolo de última generación. Nuestro modelo es el primero que admite un análisis
detallado de todas las garantías de seguridad relevantes que EMV pretende ofrecer.
Usamos nuestro modelo para identificar automáticamente fallas que conducen a dos
ataques críticos: uno que defrauda al titular de la tarjeta y otro que defrauda al
comerciante. En primer lugar, los delincuentes pueden usar la tarjeta Visa sin contacto
de la víctima para compras de alto valor, sin conocer el PIN de la tarjeta. Creamos una
arXiv: 2006.08249v1 [cs.CR] 15 de junio de 2020
aplicación de Android de prueba de concepto y demostramos con éxito este ataque en
terminales de pago del mundo real. En segundo lugar, los delincuentes pueden engañar
a la terminal para que acepte una transacción inofensiva, que el banco emisor debería
rechazar más tarde, una vez que el delincuente se haya llevado los bienes. Este ataque
es posible para implementaciones siguiendo el estándar, aunque no lo probamos en
terminales reales por razones éticas. Finalmente, proponemos y verificamos mejoras al
estándar que previenen estos ataques, así como cualquier otro ataque que viole las
propiedades de seguridad consideradas. Las mejoras propuestas se pueden
implementar fácilmente en los terminales y no afectan las tarjetas en circulación.
Términos del Índice —EMV; seguridad de pago; Fraude de tarjeta de credito; Visa;
Omisión de PIN; autenticación; análisis formal
Yo NTRODUCCIÓN
EMV, que lleva el nombre de sus fundadores Europay, Mastercard y Visa, es el estándar
mundial para el pago con tarjeta inteligente, desarrollado a mediados de la década de 1990.
A diciembre de 2019, más del 80% de todas las transacciones con tarjeta presente a nivel
mundial utilizan EMV, llegando hasta el 98% en muchos países europeos. Los bancos
tienen un fuerte incentivo para adoptar EMV debido a la cambio de responsabilidad, lo que
libera a los bancos que utilizan el estándar de cualquier responsabilidad por disputas de
pago. Si la transacción en disputa fue autorizada por un PIN, entonces el consumidor
(terminología EMV para el cliente de tarjeta de pago) es responsable. Si en su lugar se
utilizó una firma en papel, se le cobrará al comerciante.
EMV: 20 años de vulnerabilidades
Además del cambio de responsabilidad, la aceptación global de EMV también se
atribuye a su seguridad anunciada. Sin embargo, la seguridad de EMV ha sido
cuestionada en numerosas ocasiones. Ataques de intermediario (MITM) [1], clonación
de cartas [2], [3], ataques de degradación [3], ataques de retransmisión [4] - [7] y
skimming de cartas [8], [9 ] son todos ejemplos de aprovechamientos exitosos de las
deficiencias del estándar. El ataque MITM informado por Murdoch et al. [ 1] se cree
que fue utilizado por delincuentes en 2010-11.
en Francia y Bélgica para realizar transacciones fraudulentas por ca. 600.000
euros [10]. La falla subyacente de Murdoch et al. El ataque es que la respuesta de
la tarjeta a la solicitud de verificación del PIN de la terminal no está autenticada.
Algunos de los problemas de seguridad identificados son el resultado de
implementaciones defectuosas del estándar. Otros surgen de fallas lógicas cuyas
reparaciones requerirían cambios en toda la infraestructura de EMV. Identificar tales
fallas está lejos de ser trivial debido a la complejidad del flujo de ejecución de EMV,
que es altamente flexible en términos de modos de autenticación de tarjetas, métodos
de verificación de titulares de tarjetas y autorizaciones en línea / fuera de línea. Esto
plantea la cuestión de cómo podemos explorar sistemáticamente todos los fl ujos
posibles y mejorar el estándar para evitar otros veinte años de ataques.
Enfoque adoptado: romper, arreglar, verificar
En este artículo nos centramos en la debilidad y las mejoras del diseño del
protocolo EMV. Presentamos un modelo formal e integral para el análisis simbólico de
la seguridad de EMV. Nuestro modelo está escrito en Tamarin [11], [12], una
herramienta de verificación de última generación que se ha utilizado para estudiar
numerosos protocolos del mundo real, incluyendo TLS 1.3 [13] y autenticación 5G
[14]. Tamarin admite la verificación del protocolo en presencia de adversarios
poderosos y muchas sesiones de protocolo simultáneas sin límites.
Nuestro modelo admite el análisis de todas las propiedades que deben mantenerse en
cualquier transacción EMV. Una descripción informal de las tres propiedades más
relevantes es la siguiente:
1) El banco acepta transacciones aceptadas por la terminal: No trans-
La acción aceptada por el terminal puede ser rechazada por el banco.
2) Autenticación al terminal: Todas las transacciones aceptadas
por el terminal son autenticados por la tarjeta y, si se autoriza en línea,
el banco.
3) Autenticación al banco: Todas las transacciones aceptadas por
el banco está autenticado por la tarjeta y el terminal.
Nuestro modelo considera fielmente los tres roles presentes en una sesión EMV:
el banco, el terminal y la tarjeta. Los modelos simbólicos anteriores fusionan la
terminal y el banco en un solo agente [15] - [17]. Esta fusión implica incorrectamente
que el terminal puede verificar todas las pruebas criptográficas producidas por la
tarjeta que el banco puede. Esto es incorrecto ya que la tarjeta y el banco
comparten una clave simétrica que solo ellos conocen.
Utilizando nuestro modelo, identificamos una violación crítica de las propiedades de
autenticación mediante el protocolo sin contacto de Visa: el método de verificación del
titular de la tarjeta utilizado en una transacción, si lo hay, no está autenticado ni protegido
criptográficamente contra
modi fi cación. Desarrollamos una aplicación de Android de prueba de concepto que
aprovecha esto para omitir la verificación del PIN montando un ataque
man-in-the-middle que instruye al terminal que no se requiere la verificación del PIN
porque la verificación del titular de la tarjeta se realizó en el dispositivo del
consumidor (por ejemplo, un teléfono móvil). Esto permite a los delincuentes utilizar
cualquier tarjeta Visa robada para pagar bienes caros sin el PIN de la tarjeta. En
otras palabras, ¡el PIN es inútil en transacciones sin contacto de Visa!
Hemos probado con éxito nuestro ataque de omisión de PIN en terminales del
mundo real para una serie de transacciones con tarjetas de la marca Visa, como
Visa Credit, Visa Electron y V Pay. Por ejemplo, realizamos una transacción de ca. $
190 en una terminal atendida en una tienda real. Como ahora es común que los
consumidores paguen con sus teléfonos inteligentes, el cajero no puede distinguir
las acciones del atacante de las de cualquier titular legítimo de la tarjeta. Por
razones éticas, realizamos todas nuestras pruebas con nuestras propias tarjetas de
crédito / débito. Sin embargo, destacamos que el ataque funciona para cualquier
tarjeta Visa que posea el atacante, en particular con tarjetas robadas.
Nuestro análisis simbólico también revela que, en una transacción sin contacto sin
contacto con una tarjeta Visa o una tarjeta Mastercard antigua, la tarjeta no autentica
en el terminal el criptograma de aplicación (AC), que es una prueba criptográfica
producida por la tarjeta de la transacción que la terminal no puedo verificar (solo el
emisor de la tarjeta puede hacerlo). Esto permite a los delincuentes engañar al
terminal para que acepte una transacción inútil no auténtica.
Más adelante, cuando el adquirente envíe los datos de la transacción como parte
del registro de compensación, el banco emisor detectará el criptograma incorrecto,
pero el delincuente ya se ha ido con los bienes. No probamos este ataque en
terminales reales por razones éticas, ya que esto defraudaría al comerciante.
Contribuciones
Primero, presentamos un modelo simbólico comprensivo del
Estándar EMV que tiene en cuenta los 3 métodos de autenticación de datos of fl
métodos (SDA, DDA y CDA), VerPIN de 5 titulares de tarjetas, PIN en línea y CDCVM),
ine (sin PIN, PIN de texto sin formato, autorizaciones cifradas of fl ine (of fl ine y
los 2 tipos de Transacción de transacciones sin contacto (Visa y Mastercard). Nuestro
online), y los 2 tipos (principales) considera los tres roles presentes en una
modelo es el análisis detallado de todas las propiedades de seguridad relevantes.
transacción, y admite
terminales reales, un práctico ataque que permite a los atacantes acceder al PIN de la
En segundo lugar, identificamos y demostramos, por primera vez, que realizamos compras
tarjeta. También identificamos un ataque que permite transacciones inútiles sin
fraudulentas de alto valor, sin conocimiento de cómo robar bienes de manera efectiva engañando a
autenticidad. Nuestros ataques demuestran que el fraude no es necesariamente el
las terminales para que acepten que el cambio de responsabilidad de EMV debería anularse porque
resultado de un comportamiento negligente de
los consumidores o comerciantes de tarjetas de crédito.
Finalmente, en base a nuestro Tamarin automático a gran escala,
análisis apoyado de las propiedades de seguridad fundamentales de EMV,
identificamos las configuraciones EMV que garantizan
actas. En base a estas con fi guraciones, proponemos soluciones que se
pueden implementar en los terminales de pago y descartar brechas de
seguridad.
Tenga en cuenta que nuestro enfoque está en el diseño de EMV, no en las implementaciones
en sí mismas. De esta manera, podemos poner fin a la carrera de armamentos de penetrar y
parchear, donde los atacantes continuamente encuentran y explotan las debilidades del protocolo.
Por supuesto, esto es solo una parte del panorama general, ya que los atacantes aún pueden
aprovechar las debilidades de implementación; pero es una parte sustancial y también es un
requisito previo para cualquier esfuerzo de "pila completa" para desarrollar formalmente un
protocolo verificado, hasta el nivel de código
Organización
En la Sección II describimos el trabajo relacionado, centrándonos en análisis de
seguridad EMV anteriores. En la Sección III proporcionamos antecedentes sobre el
protocolo EMV. En la Sección IV presentamos nuestro modelo formal de EMV, centrándonos
en cómo modelamos las numerosas configuraciones de EMV y cómo de fi nimos y
analizamos sus propiedades de seguridad. En la Sección V presentamos los resultados de
este análisis. Más adelante, en la Sección VI, describimos una aplicación de Android que
desarrollamos y usamos para mostrar que nuestros hallazgos de Tamarin pueden
convertirse en ataques del mundo real. Como resultado de nuestro análisis, sugerimos
mejoras a los terminales que garantizan transacciones seguras. Sacamos conclusiones en la
Sección VII.
Consideraciones éticas
Realizamos todas nuestras pruebas utilizando nuestras propias tarjetas de crédito / débito.
Además, hemos notificado a Visa de los ataques descubiertos.
II. R EXALTADO W ORK
Dada su importancia financiera, no es sorprendente que el estándar EMV se haya
estudiado ampliamente. Repasamos aquí los trabajos relacionados más relevantes.
Este trabajo anterior se refiere a fallas de implementación o fallas de protocolo
descubiertas mediante el análisis de partes seleccionadas y posiblemente
simplificadas del
Especificación EMV. Por el contrario, nuestro análisis integra toda la verificación y
las diferentes con fi guraciones para la autenticación de tarjetas, modelo de tarjetahabiente.
autorización de transacciones en un solo diseño simbólico de errores relevantes,
Esto proporciona una base no solo para descubrir todos
pero también produce pruebas de corrección. en los métodos de verificación del
En 2010, Murdoch et al. [ 1] identificó una falla grave Es decir, la respuesta de
titular de la tarjeta (CVM) of fl ine de EMV. la solicitud no está autenticada. Por lo
la tarjeta a la verificación del PIN del terminal (MITM) podría responder con la éxito
tanto, un terminal man-in-the-middle solicitaría verificación para. El PIN ficticio podría
Mensaje para alguna El PIN se bloqueará para que no llegue a la tarjeta, que
indicar que el CVM elegido era una firma en papel o que normalmente no tenía CVM
luego asumirá que se requiere. Todos los pasos posteriores se llevarían a cabo
y la transacción sería aceptada.
Aunque Murdoch et al. El ataque viene con cierta infraestructura, estos
Desafíos de ingeniería, como miniaturizar el MITM como se observa en la
desafíos parecen haber sido superados Francia y Bélgica [10]. Nuestro análisis
mencionada falsificación de tarjetas de crédito en ataque, aún existen en tarjetas
demuestra que este
antiguas que no soportan ni asimétricas
criptografía ni verificación de PIN en línea (consulte la Sección VA). Desafortunadamente,
muchas tarjetas modernas que admiten ambas funciones siguen siendo vulnerables a nuestro
propio ataque de omisión de PIN, que presentamos en este documento.
Poco después, De Ruiter y Poll [15] dieron un modelo ProVerif [18] de una
variante del protocolo de contacto EMV. Resumen más de 700 páginas de especi fi
caciones EMV en 370 líneas de código F #, que transforman al lenguaje ProVerif
utilizando la herramienta FS2PV [19]. Su análisis no identifica el ataque de [1]
porque la selección del CVM por parte del terminal está demasiado simplificada
para optar siempre por el PIN de texto plano sin formato. Esto hace que la tarjeta
siempre espere una solicitud de verificación de PIN, con el PIN correcto, antes de
continuar con la transacción.
Algunas de las fallas de EMV también se han identificado a partir de estudios empíricos
en el campo [3], [8], [9]. Por ejemplo, los investigadores del Reino Unido, junto con los
consumidores insatisfechos a los que se les negó el reembolso por denuncias de fraude,
tuvieron acceso a los registros bancarios de las transacciones en disputa. Esto, junto con la
ingeniería inversa de algunos cajeros automáticos, reveló implementaciones defectuosas de
EMV. Notaron que los números supuestamente impredecibles generados por algunas
terminales eran en realidad bastante predecibles, lo que permitía a los delincuentes pre-juego
pagos y utilizar los datos recuperados para compras posteriores [8].
Enlace et al. [ 8] también observó que un ataque previo al juego aún es posible
incluso si el generador de números aleatorios del terminal funciona correctamente. En
este caso, el juego previo consiste en que el atacante reemplaza el nonce generado por
el terminal por uno usado en una transacción anterior entre el atacante y la tarjeta de la
víctima.
Los modelos simbólicos consideran el modelo de amenaza Dolev-Yao [20], donde el
adversario solo conoce el conocimiento público, los datos enviados a través de la red y el
resultado de las funciones públicas sobre la entrada conocida. El adversario también es un
atacante activo, que puede modificar, bloquear e inyectar datos en la red. En este modelo,
sin embargo, se supone que los generadores de números aleatorios son sólidos, es decir,
no se pueden predecir los números aleatorios. Por lo tanto, los ataques de este tipo
generalmente no forman parte de un análisis simbólico que examina la especificación (no
la implementación) en busca de errores lógicos. Nuestro análisis, por tanto, no descubre
Bond et al. ataques de [8]. Sin embargo, tenga en cuenta que es posible incorporar
generadores aleatorios débiles y canales comprometidos en modelos simbólicos, como se
describe en [21].
La seguridad del protocolo sin contacto EMV también se ha cuestionado
varias veces. Por ejemplo, Roland y Langer [3] detectaron un ataque de
degradación que explota las
MagStripe modo, un modo de autenticación heredado que se mantiene para
compatibilidad con versiones anteriores. Demostraron que un teléfono móvil compatible
con Near Field Communication (NFC) puede recopilar todos los códigos de autenticación
que una tarjeta podría producir en respuesta a todos los desafíos potenciales de un
terminal. Por lo tanto, una tarjeta de clonación precargada con los códigos se puede
utilizar para pagos fraudulentos. Este ataque es factible porque el modo MagStripe
reduce el grupo de números impredecibles del terminal a solo 1000 valores. En este
documento no consideramos el modo MagStripe porque se supone que los generadores
aleatorios son sonido (como se explicó anteriormente) y este modo ha quedado obsoleto
en muchos países del mundo.
Otros ataques demostrados contra el pago sin contacto EMV
Los protocolos de ment son bien conocidos ataques de retransmisión [ 4], [6], [7]. Los trabajos [4],
[7] sugieren el uso de protocolos de límite de distancia [22], [23] como contramedida a tales
ataques. Aunque el límite de distancia previene los ataques de retransmisión, solo Mastercard
parece inclinarse a usarlo. Los ataques de retransmisión generalmente se ignoran porque
presumiblemente solo son factibles para transacciones pequeñas, ya que las transacciones más
grandes requieren la verificación del titular de la tarjeta.
En 2014, Emms et al. [ 9] observó que algunas tarjetas de crédito Visa sin contacto
emitidas en el Reino Unido eliminan la verificación del PIN para transacciones en
monedas extranjeras. Los autores desarrollaron una implementación de prueba de
concepto del ataque, donde falsificaron una transacción de casi un millón de dólares
estadounidenses. Reproducimos los experimentos de [9], pero todas las tarjetas modernas
que probamos solicitaron la verificación del PIN para transacciones de gran valor tanto en
moneda nacional como extranjera.
Existen varios modelos simbólicos que muestran los protocolos EMV sin
contacto [16], [17], [24] - [26]. Todos ellos se enfocan en verificar la proximidad
entre la tarjeta y el terminal. También consideran el terminal y el banco como
un solo agente y, en consecuencia, no observan el ataque previo al juego [3].
Galloway y Yunusov [27] presentaron recientemente un ataque de intermediario
que también elude la verificación del PIN de Visa. Su ataque es similar al nuestro en
que modifica un mensaje de la tarjeta que indica al terminal que la verificación del
titular de la tarjeta se realizó en el dispositivo del consumidor. En contraste con
nuestro ataque, el ataque de Galloway y Yunusov también modi fi ca un mensaje de
origen terminal en el que se codifica la solicitud de verificación del titular de la tarjeta.
De acuerdo con la definición de criptograma (genérica) de EMV, dicho mensaje debe
protegerse contra modificaciones. Su ataque funciona porque los criptogramas
patentados de Visa no impiden tal modificación, o al menos no los implementados por
las tarjetas que probaron. Curiosamente y preocupante, nuestro propio ataque
demuestra que el mas fuerte El criptograma propuesto por EMV aún no es suficiente
para verificar correctamente al titular de la tarjeta. Los detalles se dan en la Sección
VI.
III. EMV D DESCRIPCIÓN
La especificación EMV tiene más de 2000 páginas divididas en varios libros.
Además, muchas de las declaraciones en estos
Los libros son bastante complejos y hacen referencia a otros libros. En esta sección damos
una descripción detallada del estándar. Dada su complejidad, la creación de esta
especificación y su modelo formal en Tamarin fue una empresa importante que requirió
más de seis meses de trabajo a tiempo completo. Nuestra metodología incluyó no solo leer
cuidadosamente el estándar, sino también verificar y eliminar la ambigüedad de sus
declaraciones con datos de más de 30 registros de transacciones del mundo real que
obtuvimos usando la aplicación de Android que desarrollamos, que se describe en
secciones posteriores.
Una transacción EMV consta de una serie de intercambios de comando / respuesta
de la Unidad de datos de protocolo de aplicación (APDU) y se puede dividir en cuatro
fases:
1) Inicialización: la tarjeta y el terminal acuerdan la aplicación
cación que se utilizará para la transacción e intercambiar datos estáticos, como los
registros de la tarjeta que contienen información
 sobre la tarjeta y el banco emisor (o simplemente el banco de ahora en adelante, a
menos que se especifique lo contrario).
2) Autenticación de datos of fl ine (ODA): el terminal realiza
una validación de la tarjeta basada en PKI. Una vez que la tarjeta ha
proporcionado al terminal el índice de la Autoridad de Certificación (CA), el
certificado PK del banco emitido por la CA y el certificado PK de la tarjeta emitida
por el banco, el terminal valida la firma de la tarjeta en los detalles de la
transacción.
3) Verificación del titular de la tarjeta: el terminal determina si
la persona que presenta la tarjeta es el titular legítimo. Esto se hace
mediante un método que tanto la tarjeta como el terminal admiten. El
método más común es la verificación en línea del PIN cifrado, en el que
el terminal envía (un cifrado) el PIN ingresado al banco para su
verificación. La tarjeta no está involucrada.
4) Autorización de transacción (TA): la transacción está determinada
clinado fuera de línea, aceptado fuera de línea o enviado al banco emisor para
autorización en línea.
En la Figura 1 se muestra una descripción general del fl ujo de transacciones EMV completo y a
continuación se proporcionan los detalles de cada fase.
A. Inicialización
El primer paso de una transacción EMV es la selección de la aplicación. El
terminal emite el SELECCIONE comando con la cadena 1PAY.SYS.DDF01 (en
bytes), que se refiere al entorno del sistema de pago de contacto (PSE), o
2PAY.SYS.DDF01 para contactless. La tarjeta responde con la secuencia de
identificadores de aplicación (AID). En la respuesta, la tarjeta también puede
solicitar la Lista de objetos de datos de procesamiento (PDOL), que es una lista de
datos de transacciones de origen terminal. El PDOL generalmente incluye la
cantidad, el código de país, la moneda, la fecha, el tipo de transacción y el número
aleatorio UN de la terminal (llamado Número impredecible en la terminología de
EMV).
El terminal emite el OBTENGA OPCIONES DE PROCESAMIENTO
comando junto con los datos PDOL, si lo solicita la tarjeta. La tarjeta responde
con el Perfil de intercambio de aplicaciones de 2 bytes (AIP, que indica los
métodos de autenticación admitidos y si se admite la verificación del titular de
la tarjeta) y el Localizador de archivos de aplicación (AFL, que apunta a una
lista de archivos y registros que el terminal debe leer). la tarjeta). El terminal
luego aprende estos registros usando el
LEER REGISTRO mando. Los registros suelen incluir:
• el Número de cuenta principal (PAN, comúnmente conocido como el número de
tarjeta), la fecha de vencimiento de la tarjeta y otros datos estáticos;
• el índice de la CA utilizada, el certificado emitido por la CA de la PK del
banco y el certificado PK de la tarjeta emitida por el banco, si la tarjeta admite
cifrado asimétrico;
• la primera y segunda listas de objetos de datos de gestión de riesgos de tarjetas
(CDOL1 y CDOL2, respectivamente), que normalmente incluyen el PDOL y otros
datos de transacciones; y
• la lista de CVM compatibles.
Del índice de la CA, el terminal recupera el PK de la CA de una base de
datos interna y luego verifica el certificado del banco. Posteriormente, del
certificado del banco, la terminal
adquiere el PK del banco y verifica el certificado de la tarjeta, si corresponde.
Finalmente, el terminal adquiere el PK de la tarjeta a partir del certificado de la tarjeta.
B. Autenticación de datos of fl ine
Para la Autenticación de datos of fl ine (ODA), también conocida como Autenticación
de tarjeta, existen tres métodos:
1) Autenticación de datos estáticos (SDA): la tarjeta suministra el
terminal con los Datos de autenticación estáticos firmados (SSAD), que es
la firma del banco en los datos estáticos de la tarjeta como el PAN, la fecha
de vencimiento de la tarjeta y, opcionalmente, el AIP. El método SDA evita
la modificación de los datos estáticos de la tarjeta, pero no evita la
clonación.
2) Autenticación dinámica de datos (DDA): el terminal trans-
mits el AUTENTIFICACIÓN INTERNA comando cuyo
payload es la lista de objetos de datos dinámicos (DDOL). El DDOL debe
contener el número impredecible de la terminal. En respuesta a este
desafío, la tarjeta transmite los datos de autenticación dinámica firmados
(SDAD), que son la firma de la tarjeta en los datos dinámicos de la tarjeta
(un número nuevo NC) y el DDOL recibido. El método DDA protege contra
la modi fi cación de los datos de la tarjeta y la clonación.
3) Autenticación dinámica de datos combinada (CDA): esto es
similar a la DDA pero incluye los detalles de la transacción en la SDAD, por
ejemplo, el monto de la transacción.
C. Verificación del titular de la tarjeta
Un método de verificación del titular de la tarjeta (CVM) puede ser una firma en papel,
verificación con PIN, CVM de dispositivo de consumidor (CDCVM) o una combinación de
estos. Para la verificación del PIN, existen tres métodos específicos:
1) PIN de texto plano sin formato ( o simplemente PIN simple): la terminal
envía el VERIFICAR comando junto con el PIN introducido y la tarjeta
responde con el mensaje de éxito 9000 si el PIN es correcto o el mensaje de
error 63C X, donde el digito X es el número de intentos restantes. Cuando no
quedan intentos, es decir, x = 0, entonces la tarjeta debe responder con el
mensaje de PIN bloqueado 6983 a cualquier posterior VERIFICAR
peticiones.
2) PIN cifrado de fl ine ( o simplemente PIN cifrado): el
terminal envía el OBTENGA EL RETO comando y la tarjeta responde con
un número aleatorio. Entonces el terminal emite el VERIFICAR comando
cuya carga útil es una encriptación, con el PK de la tarjeta, del PIN
ingresado y el número aleatorio recibido, y el relleno aleatorio generado
por el terminal. Tras la recepción, la tarjeta descifra la carga útil y
responde en consecuencia, utilizando los mensajes descritos en el
método de PIN simple.
3) PIN cifrado en línea ( o simplemente PIN en línea): la tarjeta
no está involucrado. En cambio, el terminal envía el PIN ingresado
encriptado al banco emisor, cuando solicita la autorización de la
transacción.
El CVM de dispositivo de consumidor está diseñado para ser realizado por
dispositivos como teléfonos móviles, que autentican al titular de la tarjeta mediante
huellas dactilares o reconocimiento facial. Cómo el terminal y el dispositivo conducen
CDCVM está fuera de EMV
 Tarjeta Terminal Banco

C T si

s = f (mk, ATC), NC aleatorio ONU al azar s = f (mk, ATC)

SELECCIONE, 1PAY.SYS.DDF01

AYUDA 1, AYUDA 2,. . . , AYUDA norte

SELECCIONE, AYUDA X

Etiquetas y longitudes de PDOL

OBTENGA OPCIONES DE PROCESAMIENTO, PDOL

AIP, AFL

LEER REGISTRO

PAN, expDate, ..., cert privCA ( B, pubB),

[ cert privB ( C, pubC, Lista CVM, AIP),]
Etiquetas y longitudes de CDOL, lista CVM

SSAD = firmar privB ( PAN, expDate, AIP)

Comienza la AOD
AUTENTICADO INTERNO, Naciones Unidas

SDAD = firmar privC ( NC, ONU)

[Veri fi cación of fl ine PIN]

GENERAR AC, CDOL1

TA comienza

X = 〈 PDOL, CDOL1 〉
AC = MAC s ( X, AIP, ATC, IAD)
T = h (X, CID, ATC, AC, IAD)
SDAD = firmar privC ( NC, CID, AC, [ T,] NACIONES UNIDAS)

CID, ATC, AC / SDAD, IAD PAN, AIP, X, ATC, IAD, AC [, aenc pubB ( ALFILER)]

Y = C.A. ⊕ pags 8 ( ARCO)

ARPC = MAC ′ s( Y)

CDOL2 = 〈 ARCO, ARPC,. . . 〉

GENERAR AC, CDOL2

X ′ = 〈 PDOL, CDOL1, CDOL2 〉

TC = MAC s ( X ′, AIP, ATC, IAD ′)
T ′ = h (X ′, CID ′, ATC, TC, IAD ′)
SDAD ′ = firmar privC ( NC, CID ′, TC, [ T ′,] NACIONES UNIDAS)

CID ′, ATC, TC / SDAD ′, IAD ′

IAD ′, TC

Fig. 1. Descripción general de la transacción EMV. Los mensajes discontinuos y los términos entre corchetes son opcionales, dependen de pasos previos o dependen de las elecciones de las partes. Para
simplificar, este gráfico solo muestra el flujo de ejecución en el que las respuestas de la tarjeta tienen el avance de éxito 9000.
Notación: ⊕ es OR exclusivo; F es una función unidireccional; ( privC, pubC), (privB, pubB), y ( privCA, pubCA) son los pares PKI de la tarjeta, el banco y
la CA, respectivamente; cert k ( cont) es el certi fi cado PKI en cont firmado con la clave privada k; firmar k ( metro) es la firma en metro con la llave k; aenc k ( metro)
es el cifrado asimétrico de metro con la llave k; MAC k ( metro) y MAC ′ k( metro) son MAC en metro con la llave k; pags si( metro) es el relleno derecho de metro con si
cero bytes.
alcance. Sin embargo, este método es la causa fundamental de uno de los nuevos
ataques que informamos en este artículo.
D. Autorización de transacción
La terminal puede decidir si rechaza la transacción fuera de línea, autoriza la
transacción fuera de línea o solicita la autorización en línea del banco emisor. Esta
decisión se toma en función de varias verificaciones, como el límite máximo de
oficina, por encima del cual las transacciones deben procesarse en línea.
El terminal envía el GENERAR CA comando a la tarjeta, junto con el
CDOL1. Este comando indica a la tarjeta que suministre el criptograma de
aplicación (AC) de 8 bytes que es:
• un criptograma de transacción (TC), si el terminal decidió aprobarlo sin
autorización,
• un criptograma de solicitud de autorización (ARQC), si el terminal
decidió la autorización en línea, o
• un criptograma de autenticación de aplicaciones (AAC), si el terminal
decidió rechazar la transacción.
El tipo de criptograma solicitado se codifica en la carga útil del comando.
Luego, la tarjeta emite el AC cuyo tipo puede ser el solicitado o un ARQC (que
obliga a la transacción a conectarse), o un AAC (que indica que la transacción
se rechazó). La tarjeta no puede generar un TC cuando se solicitó un ARQC.
El criptograma es un MAC calculado sobre los detalles de la transacción, el AIP y
el Contador de transacciones de la aplicación (ATC), que es un contador de 2 bytes
que se incrementa en cada transacción. La clave para este MAC es una clave de
sesión s derivado del ATC y una llave maestra simétrica mk compartido por el banco
y la tarjeta. Junto con el criptograma en sí, la tarjeta envía y [ una yo ∈ T Σ ( V).
otros datos, como los datos de información de criptograma de 1 byte
(CID), que indica el tipo de criptograma que se envía; el reglas ( o simplemente reglas). Una regla es un triple ( l, a, r), también por escrito el contador de transacciones
ATC, y si se solicitó CDA en el l - una →
carga útil del comando, los datos de autenticación dinámica firmados (SDAD). En
este caso, el SDAD es una firma en el número aleatorio NC de la tarjeta, el CID,
el criptograma, un hash de los detalles de la transacción y el UN del terminal.
Si la tarjeta responde con un TC y el CVM elegido no era un PIN en línea,
entonces se aprueba la transacción y el TC sirve como un acuerdo para indicarle
al banco que transfiera los fondos a la cuenta del comerciante.
Si la transacción debe ser autorizada en línea, el terminal reenvía al banco
los detalles de la transacción, el ARQC, y si la verificación del PIN en línea fue
el CVM seleccionado, el PIN ingresado. El banco autoriza o rechaza la
transacción devolviendo al terminal el Código de respuesta de autorización de
2 bytes (ARC, autorización / rechazo y más datos) y el Criptograma de
respuesta de autorización (ARPC). Este último es un MAC generado sobre el
OR exclusivo del ARC (relleno a 8 bytes) y el criptograma ARQC recibido,
utilizando la clave de sesión s. El terminal luego emite el
AUTENTICADO EXTERNO comando (o equivalentemente un segundo GENERAR También de fi nimos la función ginebras: P (R) → P (R)
CA) para informar a la tarjeta de la decisión del banco. La tarjeta construye la
respuesta de forma análoga a su respuesta a la (primera) GENERAR CA comando, instancia básica de una regla es la regla resultante de la sustitución de todas las variables por términos
solo que esta vez no se envía ningún ARQC, sino un TC o un AAC.
IV. METRO ODELING Y UNA NÁLISIS METRO Etodología
Para modelar y analizar el estándar EMV, utilizamos la herramienta de verificación
de protocolos Tamarin [11], [12]. Tamarin es un estado-
Verificador de modelos de última generación para la verificación del protocolo de seguridad.
Cuenta con un lenguaje expresivo para especificar protocolos, sus propiedades y adversarios,
así como poderosos procedimientos de inferencia para automatizar gran parte de la
verificación de protocolos. Primero proporcionamos algunos antecedentes sobre Tamarin y
luego presentamos las propiedades que analizamos y nuestra metodología de análisis.
A. Antecedentes de Tamarin
En la teoría subyacente de Tamarin, los mensajes criptográficos son
términos en un álgebra de términos ordenados ( S, ≤, T Σ ( V)) dónde S
es una especie de conjunto, ≤ una orden parcial en S, Σ es una firma, y V
es un conjunto infinito contable de variables. Por ejemplo, el término
pk k), con pk ∈ Σ, denota la clave pública asociada a la
llave privada k ∈ T Σ ( V). Del mismo modo, el término aenc k ( metro), con
aenc ∈ Σ, denota el cifrado asimétrico del mensaje
metro ∈ T Σ ( V) con la clave pública k ∈ T Σ ( V). Las propiedades algebraicas de las
funciones criptográficas se definen mediante ecuaciones
ciones sobre términos. Por ejemplo, adec k ( aenc pk k) ( m)) = m
especifica la semántica del descifrado asimétrico.
Tamarin modela el conjunto de ejecuciones de un protocolo como un sistema de transición
etiquetado (LTS). Los estados del LTS son conjuntos múltiples de
hechos, que formalizan los estados locales de los agentes que ejecutan el protocolo, el
conocimiento del adversario y los mensajes sobre el
red. Los hechos son de la forma F( una 1, una 2. . . , una norte) dónde F es un símbolo de una
firma sin clasificar Γ de símbolos predicados
La transición entre estados está determinada por transición
- r, dónde yo, a, y r son conjuntos de hechos. por
Por ejemplo, la siguiente regla especifica la transmisión del hash de un] r
[mensaje recibido:] [ ]
En( metro) - SentHash ( A.m) → - Estado1 ( A.m), Fuera( h (m)).
Esta regla establece que, si hay un término metro entrada en la red, luego actualice el
estado local de UNA a Estado1 ( A.m), eliminar metro
de la red y generar el término h (m) en la red, posiblemente para la recepción
por UNA socio de comunicación. La transición está etiquetada con SentHash ( A.m),
significa que UNA
envió el hash de metro.
En lo que sigue, dejemos F ser el universo de hechos y R el universo de las reglas.
Mientras PAGS(.) denota el conjunto de potencias de un conjunto, usamos METRO(.) para
referirse al poder multiset de un conjunto. Definimos la función lineal: M (F) → M (F) que
rinde todo lineal hechos a partir del conjunto múltiple de hechos de entrada. Los hechos
lineales anotan recursos que pueden consumirse solo una vez, como los mensajes en la
red. Los hechos que no son lineales se llaman
persistente y puede reutilizarse arbitrariamente a menudo sin consumirse.
que produce el conjunto de todos instancias terrestres del conjunto de reglas de entrada. Una
básicos es decir, términos
de T Σ). Además, deja A ⊆ R ser el conjunto de modelos de reglas globales
una red controlada por un adversario Dolev-Yao [20], así como la generación de
valores nuevos y aleatorios.
Un protocolo PAGS ⊆ R es un conjunto de reglas. El LTS asociado
es ( S, Λ, → -), dónde S = M (F), Λ = M (F), y →
S × Λ × S se define por:
una s ′ ⇐⇒ ∃ ( l, a, r) ∈ ginebras (P ∪ A).
s -→
l ⊆ s ∧ s ′ = ( s \ linear (l)) ∪ r.
La r,
Una transición consume los hechos lineales de l del estado actual, agrega los hechos de propiedad
a una transacción
Una ejecución de PAGS es una secuencia finita ( s 0, una 1, s 1,. . . , una norte, s norte)
una
tal que s 0 = ∅ y s yo - 1→ s- yo
yo para todos 1 ≤ yo ≤ norte. los
secuencia ( una 1,. . . , una norte) es un rastro de PAGS y el conjunto de todos PAGS las huellas se denotan trazas
(P). Se especifican las propiedades de seguridad
utilizando fórmulas lógicas de primer orden en trazas. Se pueden encontrar más detalles
sobre la sintaxis y la semántica de Tamarin en [11], [12].
B. Propiedades de seguridad
Como hemos visto, EMV involucra a tres partes: la con-
La tarjeta del consumidor, el terminal del comerciante y el titular de la tarjeta que se comunican
banco. Sus propiedades centrales de seguridad conciernen a las partes y al secreto de
entre sí, garantizan la información de la transacción, a continuación.
los datos sensibles. Formalizamos estas propiedades
La primera propiedad que examinamos es que el banco no rechazará ninguna
transacción aceptada por la terminal. Esta propiedad es particularmente relevante para
terminales con capacidad de fl ine, que normalmente no solicitan autorización en línea
para transacciones de bajo valor. Estos terminales pueden ser engañados si la propiedad
falla.
De fi nición 1 ( El banco acepta). Un protocolo PAGS satisface la propiedad de que el el banco
acepta transacciones aceptadas por la terminal Si por
cada α ∈ trazas (P):
∀ t, yo. TerminalAccepts ( t) ∈ α yo = ⇒
@ j. BankDeclines ( t) ∈ α j ∨ ∃ A, k. Honesto( UNA) ∈ α yo ∧ Compromiso( UNA)
∈ α k.
En nuestro modelo, el TerminalAccepts ( t) El hecho se agrega al seguimiento
solo si el terminal está satisfecho con la transacción
t y las pruebas criptográficas asociadas proporcionadas por la tarjeta. Es decir,
cuando el terminal emite un recibo de compra. los BankDeclines ( t) El hecho se
produce cuando el banco recibe una solicitud de autorización para la transacción con
un criptograma de aplicación incorrecto. La última línea descarta transacciones en las
que un agente, presuntamente honesto, se ha visto comprometido. Por ejemplo, un
banco que rechaza maliciosamente una transacción correcta no debe hacer que la
propiedad falle.
Nuestra segunda propiedad corresponde a la propiedad de autenticación
comúnmente conocida como acuerdo inyectivo [ 28], [29].
De fi nición 2 ( Autenticación a terminal). Un protocolo PAGS satisface autenticación
al terminal si por cada α ∈ trazas (P):
∀ T (, P, r, t, yo.
-⊆
Cometer( T, P, 〈 r, ′ Terminal ′, t 〉) ∈ α yo = ⇒
∃ j. Corriendo( P, T, 〈 r, ′ Terminal ′, t 〉) ∈ α j ∧
@ yo 2, T 2, PAGS 2.
)
Cometer( PAGS 2, T 2, 〈 r, ′ Terminal ′, t 〉) ∈ α yo ∧ yo 2 6 = yo 2 ∈ α k. ∨
∃ A, k. Honesto( UNA) ∈ α yo ∧ Compromiso( UNA)
y etiquetaanterior, con con
la transición ′ Terminal ′ ∈ T Σ yque
a. establece 〈〉 ∈ Σ, que la terminal T comete
siempre
t con su socio de comunicación PAGS , entonces tambien PAGS , en rol
r ∈ { ′ Tarjeta ′, ′ Banco ′} ⊆ T Σ, estaba corriendo el protocolo con T
y están de acuerdo en
t, o un agente, presuntamente honesto, ha sido
comprometidos. Además, hay una Cometer hecho para cada par de transacción
aceptada y agente de aceptación, lo que significa que se evitan los ataques de
reproducción.
Los hechos Cometer y Corriendo, introducidos en [28], se utilizan para especificar
propiedades de autenticación. UNA Cometer hecho representa la creencia de un agente
sobre el estado local de su socio de comunicación, mientras que Corriendo representa el
estado real del socio.
Por lo tanto, las propiedades de autenticación se expresan en términos de ocurrir siempre que el
pares coincidentes de tales hechos. En nuestros modelos, Cometer hechos cuando la
agente comprometido se encuentre en un estado satisfactorio.
transacción está lista para ser aceptada.
Nuestra tercera propiedad también es una propiedad de autenticación y es
muy similar al segundo, excepto que el agente que comete
es el banco. Es decir, la definición es la misma excepto
término básico ′ Terminal ′ es ahora ′ Banco ′ ∈ T Σ.
Otra propiedad relevante para el análisis de protocolo formal es
el secreto también conocido como confidencialidad). El secreto de un término X aguanta cuando X
no es conocido por el atacante. El conocimiento del atacante de un término X está escrito como KU
( X), dónde KU ∈ Γ es un símbolo de hecho definido por las reglas incorporadas de Tamarin que
modelan cómo el atacante adquiere conocimiento. La definición de secreto también asume que
los agentes involucrados no están comprometidos.
De fi nición 3 ( Secreto). Un protocolo PAGS satisface secreto Si por
cada α ∈ trazas (P):
∀ x, yo. Secreto( X) ∈ α yo = ⇒
@ j. KU ( X) ∈ α j ∨ ∃ A, k. Honesto( UNA) ∈ α yo ∧ Compromiso( UNA) ∈ α k.
En una transacción EMV, los términos que deben ser secretos incluyen
el número PIN, el PAN (es decir, el número de tarjeta) y las claves (es decir, claves
privadas y claves compartidas simétricas).
También consideramos otras propiedades como ejecutabilidad,
lo que permite evaluar si la ejecución de un protocolo alcanza un estado en el
que el banco y el terminal han aceptado una transacción y no se han producido
compromisos. Esto representa una verificación de cordura que muestra que el
protocolo modelado se comporta como se esperaba y permite ejecuciones de
protocolos sin la participación del adversario. Esto asegura que no haya errores
de modelado que harían inoperante el protocolo especificado y darían lugar a
resultados falsos.
De fi nición 4 ( Ejecutabilidad). Un protocolo PAGS es ejecutable Si
α ∈ rastros (P) existe tal que:
∃ t, C, B, nc, i, j, k, l.
Corriendo( C, nc, 〈 ′ Tarjeta ′, ′ Terminal ′, t 〉) ∈ α yo ∧
Cometer( nc, C, 〈 ′ Tarjeta ′, ′ Terminal ′, t 〉) ∈ α j ∧
Corriendo( C, B, 〈 ′ Tarjeta ′, ′ Banco ′, t 〉) ∈ α k ∧
Cometer( ANTES DE CRISTO, 〈 ′ Tarjeta ′, ′ Banco ′, t 〉) ∈ α l ∧
@ A, a. Compromiso( UNA) ∈ α a.
C. Metodología de análisis
Construimos nuestro modelo de una manera que tiene en cuenta todos los posibles fl
ujos e interacciones del protocolo, pero nos brinda un análisis estructurado de qué tipos
de ejecuciones son vulnerables a los ataques. Empezamos por formalizar el estándar
EMV en dos genérico
modelos:
1) uno para el Protocolo de contacto EMV, modelando el completo
espacio de ejecución de una transacción de contacto, y
2) uno para el Protocolo EMV sin contacto, modelando el
espacio de ejecución completo de una transacción sin contacto Mastercard [30] o
Visa [31].
Cada uno de estos dos modelos captura todas las ejecuciones posibles del
Entorno del sistema de pago correspondiente (con o sin contacto), incluidas las
transacciones simultáneas con diferentes tarjetas, terminales, tipos de
autenticación, métodos de verificación del titular de la tarjeta y todas las demás
configuraciones. Por ejemplo, el modelo de protocolo sin contacto permite
ejecuciones entre un terminal, que cree estar en una transacción Visa, y tres
tarjetas, que pueden ser diferentes a las tarjetas Visa. Claramente, si el sistema
puede alcanzar un estado en el que la transacción sea aceptada depende de los
mensajes reales y las pruebas criptográficas que reciben el terminal y el banco.
Tamarin exhibe una violación de propiedad al construir un rastro que
contradice la propiedad dada. Claramente, Tamarin no puede generar todos estos
rastros, ya que hay infinitos (simplemente agregando pasos no relacionados), si
existe alguno. Ejecutar Tamarin en los modelos genéricos, por lo tanto, conducirá
a una verificación exitosa o un rastro de ataque, violando la propiedad, con la
Tipo de tarjeta y método de autenticación "menos seguro", entre los que se encuentran
otros ajustes. Sin embargo, uno podría estar interesado, por ejemplo, en
la propiedad de autenticación ante el banco, específicamente la autenticación de datos
transacciones en las que la tarjeta usaba Combined Dynamic
(CDA, retiro de la Sección III-B) y la
El valor de la transacción fue alto, es decir, por encima del límite requerido por CVM.
Con esto en mente, empleamos una estrategia de modelado que
genera automáticamente modelos específicos de Tamarin a partir de los dos que usamos con fi
modelos genéricos. Para generar automáticamente los modelos específicos, de argumentos
guraciones de destino. Una configuración de destino es una opción para verificar las propiedades
que seleccionan las transacciones para las que queremos configurar, determinar lo que
de seguridad. Un modelo genérico y un ejemplo de destino, Visa DDA Low es un modelo de
llamamos un modelo de destino. Para el modelo de protocolo sin contacto (genérico) con los
destino generado a partir del
argumentos de destino:
• DDA: se refiere al método de autenticación de datos of fl ine
(conocido como rápido DDA en [31]), y
• Bajo: indica una transacción de bajo valor.
Automatizamos la generación de modelos de destino y el lector interesado
puede encontrar los detalles técnicos en el Apéndice A, así como en nuestras
teorías Tamarin y su README [32].
En nuestros modelos, consideramos que los siguientes datos de transacción deben
acordarse para las propiedades de autenticación (es decir, el término t en las de fi niciones de
la Sección IV):
• el Número de cuenta principal (PAN);
• el perfil de intercambio de aplicaciones (AIP);
• el método de verificación del titular de la tarjeta (CVM) utilizado;
• el Contador de transacciones de la aplicación (ATC);
• la entrada de datos del criptograma de aplicación (AC) ( X y X ′
en la Figura 1);
• el propio criptograma de aplicación (AC); y
• los datos de solicitud de emisor (IAD).
Tanto para los modelos con contacto como sin contacto, entre los controlados por el
terminal y la tarjeta (y viceversa) modelamos un canal
adversario Dolev-Yao, que puede escuchar, bloquear,
inyectar y modificar los datos transmitidos. Entre el banco y la terminal (y
viceversa) modelamos un canal seguro que ofrece autenticación y secreto.
Asumimos que las tarjetas Mastercard físicas tienen borrado el segundo bit del primer
byte de AIP. Este bit describe si se admite el CVM de dispositivo de consumo. Esta
suposición es razonable ya que solo las tarjetas "virtuales" (es decir, las tarjetas
registradas en aplicaciones móviles como ApplePay o Google Pay) tienen este bit
configurado. Tenga en cuenta que esto no significa que un adversario no pueda intentar
establecer este bit. Los AIP de Visa dependen de la transacción y la selección del CVM
del dispositivo de consumo no está determinada por el AIP, sino por los Calificadores de
transacciones con tarjeta (CTQ).
También asumimos que las terminales no completan transacciones sin contacto
de alto valor con tarjetas que (aparentemente) no admiten la verificación del titular
de la tarjeta. En tales transacciones, la práctica común de los terminales es
rechazar el intento e indicar al titular de la tarjeta que cambie a la interfaz de
contacto.
V. A NÁLISIS R ESULTADOS
Llevamos a cabo un análisis de seguridad automatizado a gran escala de tions:
40 configuraciones de EMV, que incluyen ambos tipos de análisis integral de
contact y contactless. Describimos los resultados de este
transacciones en esta sección y posteriormente muestran
cómo se pueden aprovechar algunos de estos defectos en ataques prácticos.
A. Resultados del análisis del protocolo de contacto EMV
Nuestros resultados de análisis para las 24 configuraciones de la EMV
El protocolo de contacto se resume en la Tabla I. Aunque existe una formalización y
No hay grandes sorpresas aquí, los resultados ilustran los bene fi cios que ambos
un análisis exhaustivos. En particular, los protocolos y los ataques que, hasta
redescubrimos, ataques conocidos al contacto, pero relativamente difíciles de llevar
donde sabemos, son nuevos, tienen una relevancia práctica limitada. Tenga en
a cabo en la práctica y, por lo tanto, resultados para el secreto de la mesa porque
cuenta que hemos omitido todos los modelos. Todos nuestros modelos y pruebas
son idénticos para
están disponibles en [32]. minal y la tarjeta y entre el banco y la tarjeta, en el
Nuestro análisis reveló desacuerdo, tanto entre los
 TABLA I
UNA RESULTADOS DEL NÁLISIS PARA EL EMV PROTOCOLO DE CONTACTO. UNA LL LOS MODELOS OBJETIVO TIENEN 55 REGLAS. T LAS ÚLTIMAS DOS COLUMNAS INDICAN, EN ESE ORDEN, EL NÚMERO DE LÍNEAS DE T CÓDIGO
AMARIN QUE COMPRENDE EL MODELO Y EL TIEMPO QUE NOS TIENE T ANÁLISIS AMARIN, USANDO 10 HILOS Y COMO MÁS 20 GB DE RAM POR MODELO, EN UN SERVIDOR DE COMPUTADORA EN EJECUCIÓN U BUNTU 16.04.3
CON DOS yo NTEL ( R) X EÓN( R) E5-2650 V 4 a 2.20 GH Z
UPC S (CON 12 CADA UNO) Y 256 GB DE RAM. T LOS MODELOS PARA LOS CUALES SE VERIFICARON LAS CUATRO PROPIEDADES ESTÁN DESTACADOS EN NEGRITA.

Propiedades
No. Modelo de destino LoC Hora
ejecutable el banco acepta auth. a la terminal auth. al Banco

1 Contacto SDA PlainPIN Contacto en línea X × ( 2) × ( 1,2) × ( 1) 758 13 min 07 s

2 SDA PlainPIN Contacto en línea SDA X × ( 2) × ( 1,2) × ( 1) 761 11 min 39 s

3 OnlinePIN Contacto en línea SDA OnlinePIN X × ( 2) × ( 1,2) × ( 1) 758 13 min 02 s

4 Contacto en línea Contacto SDA NoPIN - - - - 731 11 min 48 s

5 Contacto en línea SDA NoPIN Contacto en X × ( 2) × ( 1,2) × ( 1) 752 8 min 21 s

6 línea Contacto SDA EncPIN Contacto en X × ( 2) × ( 1,2) × ( 1) 755 6 min 37 s

7 línea SDA EncPIN Contacto en línea DDA - - - - 758 12 min 21 s

8 PlainPIN Contacto en línea DDA PlainPIN - - - - 761 11 min 36 s

9 Contacto en línea Contacto con DDA X × ( 2) × ( 1,2) × ( 1) 766 13 min 48 s

10 Contacto con DDA NoPIN Contacto en línea X × ( 2) × ( 1,2) × ( 1) 769 12 min 20 s

11 DDA NoPIN Of fl ine Contacto DDA EncPIN X × ( 2) × ( 2) X 775 16 min 04 s

12 Contacto en línea DDA EncPIN Of fl ine - - - - 739 12 min 27 s

13 Contacto CDA PlainPIN Contacto en línea X × ( 2) × ( 2) X 769 12 min 15 s

14 CDA PlainPIN Of fl ine X × ( 2) × ( 2) X 772 8 min 43 s

15 X × ( 2) × ( 1,2) × ( 1) 766 14 min 07 s

dieciséis X × ( 2) × ( 1,2) × ( 1) 769 12 min 59 s

17 X X × ( 1) × ( 1) 763 1h55m31s

18 X X × ( 1) × ( 1) 766 14 min 10 s

19 Póngase en contacto con CDA Online PIN Online X X X X 781 6h03m05s

20 Póngase en contacto con CDA en línea PIN Of fl ine - - - - 739 12 min 15 s

21 Comuníquese con CDA NoPIN en línea X X X X 775 2h31m23s

22 Comuníquese con CDA NoPIN Of fl ine X X X X 778 12 min 16 s

23 Comuníquese con CDA EncPIN en línea X X × ( 1) × ( 1) 763 1h59m44s

24 Comuníquese con CDA EncPIN Of fl ine X X × ( 1) × ( 1) 766 14 min 00 s

Leyenda:

X : propiedad verificada × : propiedad falsificada -: no aplicable

(1): no está de acuerdo con la tarjeta del CVM utilizado (2): no está de acuerdo con la tarjeta del último AC

CVM seleccionado para transacciones usando SDA o verificación de PIN fuera de línea
(simple o cifrada) (Tabla I, Observación 1).
Para las transacciones en las que el terminal realizó una verificación de PIN sin
errores, nuestro análisis identifica un rastro que representa el ataque de bypass de
PIN observado por primera vez por Murdoch et al. [ 1] para transacciones con
SDA. En este ataque, un hombre en el medio envía el éxito respuesta a la solicitud
de verificación del PIN del terminal. La solicitud real está bloqueada y, por lo tanto,
la tarjeta cree que no se requirió la verificación del PIN, por lo que el desacuerdo
entre el terminal y la tarjeta. El terminal reenvía la transacción al banco (ya sea
para la autorización en línea o para cobrar los fondos), lo que luego conduce al
desacuerdo entre el banco y la tarjeta.
Un requisito previo para que este ataque tenga éxito es que, incluso si el terminal
envía a la tarjeta el campo Resultados del método de verificación del titular de la tarjeta
(CVMR, etiqueta 9F34), que codifica la vista del terminal del CVM utilizado, y la tarjeta
detecta la falta de coincidencia con su propia vista del CVM utilizado, la tarjeta no no abortar
simple y un SSAD o un certificado PKI de una tarjeta que valida dicha lista de CVM.
la transacción. Este parece ser el caso en la práctica (aunque
La especificación de EMV no es explícita al respecto) y se ha probado con éxito con
tres tarjetas Mastercard diferentes utilizando nuestra aplicación de Android. Tales
pruebas, a pesar de que se realizaron sin contacto, nos dan un cierto grado de con fi
anza de que también ocurre con transacciones de contacto.
Nuestro análisis también muestra que todas las transacciones que utilizan SDA o
DDA son vulnerables a una modificación del criptograma de transacción (TC). Esto se
debe a que en ninguno de estos métodos la tarjeta autentica el TC en el terminal
(Tabla I, Observación 2).
En cuanto al secreto, los resultados son idénticos para todos los modelos. Las
claves (privadas y compartidas) son secretas, mientras que el PAN no lo es.
Curiosamente, nuestro análisis informa que el PIN no es secreto. Un ataque
man-in-the-middle entre la tarjeta y el terminal puede usar la clave privada de un
banco comprometido para producir los registros de la tarjeta necesarios para que el
terminal crea que el único CVM que admite la tarjeta es un PIN simple. Estos registros
(falsos) son dobles: una lista de CVM admitidos compuesta únicamente por un PIN
Por tanto, la terminal se degrada a
la verificación simple del PIN y, en consecuencia, el PIN ingresado por el titular de la tarjeta
puede ser interceptado y aprendido por el atacante. Sin embargo, este es un ataque no
trivial, ya que llevarlo a cabo en la práctica requiere que el atacante:
1) conoce la clave privada de un banco comprometido y
2) controla discretamente la interfaz de contacto del terminal.
Nuestro modelo considera que estas dos condiciones son posibles, al menos en teoría.
Sin embargo, en la práctica son bastante difíciles de conseguir. Observamos que un
solo banco comprometido es suficiente, y no es necesario que sea el que emitió la
tarjeta de la víctima.
Resumen: Demostramos que solo tres configuraciones del protocolo de contacto
EMV garantizan transacciones seguras en términos de las tres propiedades principales
que consideramos. Todas estas configuraciones usan CDA como método de
autenticación y están escritas en negrita en la Tabla I. En combinación con el PIN en
línea como método de verificación del titular de la tarjeta, la configuración de destino
resultante permite todas las transacciones (valor alto y bajo) y es segura. También es
el único de estos tres que comprueba efectivamente que la persona que presenta la
tarjeta es el titular legítimo de la tarjeta. En cambio, las otras dos con fi guraciones
delegan este cheque al cajero, por ejemplo, mediante firma en papel (cuya verificación
real está fuera del alcance de EMV). Esto hace que estas dos con fi guraciones no se
puedan utilizar para transacciones de alto valor en muchos países.
B. Resultados del análisis del protocolo EMV sin contacto
Los resultados de nuestro análisis para las 16 configuraciones del protocolo sin
contacto EMV se resumen en la Tabla II. Aquí Tamarin descubrió nuevos ataques
potencialmente valiosos.
Nuestro análisis muestra que el protocolo sin contacto de Mastercard
proporciona seguridad para todas las transacciones de alto valor. Durante las
transacciones que utilizan SDA o DDA, la tarjeta no autentica el criptograma de
aplicación (AC) en el terminal (Tabla II, Líneas 5, 7, 9 y 11, Observación 2). Por lo
tanto, durante de fl ine
En las transacciones que utilizan cualquiera de estos métodos, un intermediario
puede modificar el AC (o el criptograma de transacción debido a que está apagado),
lo que el terminal acepta dado que no puede verificar su corrección. La CA no
coincidente será detectada más tarde por el banco emisor. Esto viola ambas
propiedades formalizadas en las Definiciones 1 y 2.
Para nuestra sorpresa, todas las configuraciones del protocolo Visa sin contacto,
excepto una, no brindan seguridad (el protocolo se muestra en la Figura 2). Por
ejemplo, las transacciones autorizadas fuera de línea (Tabla II, Línea 3, Observación
2) se pueden abusar de manera similar al problema antes mencionado con
Mastercard. Particularmente críticas son las violaciones de autenticación en
transacciones de alto valor en modo EMV (Tabla II, Línea 2, Observación 1). Nuestro
análisis de Tamarin identifica un rastro de una transacción aceptada en la que ni el
terminal ni el banco están de acuerdo con la tarjeta en los Calificadores de
transacciones con tarjeta (CTQ). El CTQ es un campo de datos de la tarjeta que le
dice al terminal qué CVM se va a utilizar. La traza muestra que, mientras que la vista
de la tarjeta del CTQ es una solicitud de verificación del PIN en línea, la vista del
terminal indica que se realizó el CVM del dispositivo de consumo (CDCVM), lo que
hace que el terminal considere que el proceso de verificación del titular de la tarjeta se
ha completado con éxito. Esto es
posible porque no se ofrece protección criptográfica del CTQ. Esta falla es
crítica ya que permite que un atacante omita la verificación del PIN para
transacciones de alto valor con la tarjeta de la víctima, como se señaló en la
introducción.
En términos de secreto, los resultados son idénticos para todos los modelos y son los
esperados. Las claves (privadas y compartidas) y el PIN son secretos, mientras que el
PAN no lo es.
Resumen: Nuestro análisis veri fi ca que las transacciones con tarjetas Mastercard
compatibles con CDA que admiten la verificación del PIN en línea son seguras.
Afortunadamente, este es el tipo más común de tarjetas Mastercard que emiten los
bancos actualmente. En contraste, se encontraron fallas críticas en las configuraciones
comunes de tarjetas Visa que se utilizan actualmente. Estas fallas pueden convertirse
en ataques prácticos, que describimos en la siguiente sección.
VI. UNA TTACK Y re EFENSE
Nuestro análisis de la seguridad de EMV descubrió numerosos
deficiencias. Particularmente críticos son los problemas encontrados en EMV sin contacto,
debido a su relevancia práctica, dado que la manipulación del canal sin contacto del
terminal de la tarjeta a través de NFC es mucho más simple que la manipulación de este
canal a través del chip de contacto. En esta sección mostramos cómo un atacante puede
aprovechar estos problemas para realizar transacciones fraudulentas. También sugerimos
soluciones que conduzcan a transacciones sin contacto verificadas y seguras.
A. Configuración
Desarrollamos una aplicación de Android de prueba de concepto para demostrar el
impacto práctico de las deficiencias descubiertas por nuestro análisis formal. Nuestra
aplicación admite ataques de intermediario en la parte superior de un ataque de relevo [ 5] -
[7] arquitectura, que se muestra en la Figura 3. En esta arquitectura, el atacante emplea dos
dispositivos móviles: uno que ejecuta nuestra aplicación en Emulador de punto de venta
(POS) modo y el otro en emulador de tarjetas modo. Ambos dispositivos deben ser
compatibles con NFC y ejecutar Android 4.4 KitKat (API nivel 19) o posterior. El dispositivo
emulador de tarjeta debe ser compatible con la emulación de tarjeta basada en host (HCE)
de Android [34].
Para realizar los ataques, el emulador de POS debe mantenerse cerca de la tarjeta que
se va a atacar y el emulador de tarjeta debe mantenerse cerca de la terminal de pago. Los
dos emuladores se comunican de forma inalámbrica a través de un canal de conexión TCP /
IP a través de WiFi. Un ataque man-in-the-middle modifica, según corresponda:
• los comandos entrantes se leen desde el canal inalámbrico antes de
enviarlos a la tarjeta a través del canal NFC, y
• las respuestas de la tarjeta antes de transmitirlas al emulador de la tarjeta
a través del canal WiFi.
B. Pasar por alto la verificación del titular de la tarjeta
En una transacción sin contacto de Visa, la respuesta de la tarjeta a la OBTENGA
OPCIONES DE PROCESAMIENTO El comando lleva los cali fi cadores de
transacciones con tarjeta (CTQ). El CTQ es un campo de datos de 2 bytes que
indica al terminal qué método de verificación del titular de la tarjeta (CVM) debe
utilizarse. Como se explica en la Sección VB, nuestro análisis reveló que la tarjeta
no autentica el CTQ ni en el terminal ni en el banco (Tabla II,
 TABLA II
UNA NÁLISIS R ESULTADOS PARA EL EMV PROTOCOLO SIN CONTACTO. UNA LL LOS MODELOS OBJETIVO TIENEN 60 REGLAS. T LAS ÚLTIMAS DOS COLUMNAS INDICAN, EN ESO
ORDEN, EL NÚMERO DE LÍNEAS DE T CÓDIGO AMARIN QUE COMPRENDE EL MODELO Y EL TIEMPO QUE NOS TIENE T ANÁLISIS DE AMARIN EN UN
METRO C.A. si OK PAGS RO PORTÁTIL RUNNING MAC OS 10.15.4 CON UN Q UAD- C MINERAL yo NTEL C ORE YO 7 a 2,5 GH Z UPC Y 16 GB DE RAM. T EL MODELO (S) PARA
LAS CUATRO PROPIEDADES FUERON VERIFICADAS ESTÁN DESTACADAS EN NEGRITA.

Propiedades
No. Modelo de destino LoC Hora
ejecutable el banco acepta auth. a la terminal auth. al Banco

1 Visa EMV baja X X × ( 1) × ( 1) 822 2 min 02 s

2 Visa EMV alta X X × ( 1) × ( 1) 822 2 min 10 s

3 Visa DDA baja X × ( 2) × ( 2) X 832 5 min 49 s

4 Visa DDA alta X X X X 840 28 min 57 s

5 Mastercard SDA Online PIN bajo X × ( 2) × ( 2) X 830 4 min 36 s

6 Mastercard SDA Online PIN alto X X X X 839 12 min 36 s

7 Mastercard SDA NoPIN Bajo Mastercard SDA X × ( 2) × ( 2) X 824 4 min 27 s

(3)
8 NoPIN Alto Mastercard DDA OnlinePIN Bajo - - - - 792 53 s

9 X × ( 2) × ( 2) X 836 8 min 40 s

10 Mastercard DDA Online PIN alto X X X X 845 27 min 07 s

11 Mastercard DDA NoPIN Bajo Mastercard X × ( 2) × ( 2) X 830 8 min 22 s

(3)
12 DDA NoPIN Alto - - - - 798 1 min 02 s

13 Mastercard CDA OnlinePIN Low Mastercard CDA X X X X 845 22 min 00 s

14 OnlinePIN High Mastercard CDA NoPIN Low X X X X 845 44 min 00 s

15 X X X X 839 18 min 22 s

(3)
dieciséis Mastercard CDA NoPIN alto - - - - 798 1 min 13 s

Leyenda:

X : propiedad verificada × : propiedad falsificada -: no aplicable (1): no está de acuerdo con la tarjeta en el CVM utilizado

(2): no está de acuerdo con la tarjeta en el AC (3) las transacciones de alto valor sin CVM no se completan a través de la interfaz sin contacto

Línea 2, Observación 1). Nuestra aplicación aprovecha esto e implementa un ataque mando. El TTQ es parte de la Lista de objetos de datos de procesamiento (PDOL).
man-in-the-middle que: De acuerdo con el libro EMV Security and Key Management [33], el criptograma de
aplicación (AC) es un MAC calculado sobre los datos referenciados por las listas de
• borra el octavo bit del primer byte de CTQ, que dice el
objetos de datos de la tarjeta, a saber, el PDOL, el CDOL1 y el CDOL2, si
terminal que no requiere la verificación del PIN en línea; y
corresponde. Por tanto, este criptograma (genérico) debería defenderse de la
• establece el octavo bit del segundo byte de CTQ, que dice el
modificación del PDOL y del TTQ en particular. El criptograma propiedad de Visa no
terminal que se realizó el CVM del dispositivo de consumidor.
lo hace, como se indica en [27]. Claramente, nuestro ataque funciona incluso si el
Con nuestra aplicación, hemos llevado a cabo con éxito una serie de transacciones en el
TTQ está autenticado, ya que no necesita modificación.
mundo real sin PIN por encima del límite nacional requerido por CVM con tarjetas de crédito y
débito Visa. La Figura 4 muestra capturas de pantalla de nuestra aplicación y el registro de
transacciones que se muestra en la pantalla del emulador de POS corresponde a una de
esas transacciones. Otra diferencia notable entre nuestro ataque y el de [27] está en el lado de la
implementación. Su prototipo de ataque está compuesto por dos placas Raspberry Pi
cableadas. Esta configuración es bastante llamativa y no se puede utilizar fácilmente fuera
Nuestro ataque también debería funcionar para los núcleos sin contacto EMV 6 [35]
de un entorno de laboratorio. En contraste, nuestra implementación de prueba de concepto
(Discover) y 7 [36] (UnionPay), pero estos aún no se han probado. Para evitar defraudar
es una aplicación de teléfono de apariencia inocente que puede, y ha sido, fácil de usar en
a otros, todas nuestras pruebas se llevaron a cabo con nuestras propias tarjetas de
terminales atendidos en vivo. Además, a diferencia del ataque de Galloway y Yunusov, el
débito / crédito, y en todos los ataques se pagaron los bienes adquiridos en su totalidad.
nuestro no requiere que la tarjeta y el terminal de pago estén físicamente cerca. De hecho,
se puede ampliar nuestra aplicación para que el canal de retransmisión cubra incluso
Como se discutió en la Sección II, Galloway y Yunusov [27] presentaron
distancias en el extranjero. Sorprendentemente, Visa no ha mostrado ninguna intención de
recientemente en BlackHat Europe otro ataque man-in-the-middle que también pasa
corregir tales vulnerabilidades, como se indica en [27].
por alto la verificación del PIN de Visa. En contraste con nuestro ataque de bypass de
PIN, su ataque no borra el octavo bit del primer byte de CTQ. En cambio, borra el
séptimo bit del segundo byte de los Calificadores de transacción de terminal (TTQ).
Este bit le dice a la tarjeta si el terminal requiere verificación del titular de la tarjeta Observe que nuestro ataque, así como el de [27], supone que el dispositivo del
para la transacción. atacante está físicamente dentro de la proximidad NFC de la tarjeta de la víctima. Por lo
tanto, estos ataques se pueden llevar a cabo adquiriendo la tarjeta real (por ejemplo,
El TTQ es un campo de datos de origen terminal que se pasa a la tarjeta dentro de la robándola o encontrándola si se pierde) o manteniendo el emulador POS cerca de la
carga útil del OBTENGA OPCIONES DE PROCESAMIENTO tarjeta en el
 Tarjeta Terminal Banco

C T si

s = f (mk, ATC) ONU al azar s = f (mk, ATC)

NC aleatorio

SELECCIONE, 2PAY.SYS.DDF01

AYUDA 1, AYUDA 2,. . . , AYUDA norte

SELECCIONE, A000000003 ....

Etiquetas y longitudes de PDOL

PDOL = 〈 TTQ, cantidad, país, TVR,

moneda, fecha, tipo, ONU 〉

OBTENGA OPCIONES DE PROCESAMIENTO, PDOL

AC = MAC s ( PDOL, AIP, ATC, IAD)

d = 〈 ATC, ONU, monto, moneda, NC, CTQ, AIP 〉
SDAD = firmar privC ( re)

AIP, AFL, IAD, AC, CID, ATC, CTQ

LEER REGISTRO

PAN, expDate, ... [, cert privCA ( B, pubB),

cert privB ( C, pubC), SDAD, NC, CTQ]
PAN, AIP, PDOL, ATC, IAD, AC [, aenc pubB ( ALFILER)]

Y = C.A. ⊕ pags 8 ( ARCO)

ARPC = MAC ′ s( Y)
ARCO, ARPC

Fig. 2. El protocolo sin contacto de Visa. La solicitud del terminal para la verificación del titular de la tarjeta y la autorización en línea está codificada en el PDOL, específicamente en los Cali fi cadores de transacción del terminal (TTQ, etiqueta 9F66).
La respuesta de la tarjeta a las solicitudes TTQ está codificada en los Cali fi cadores de transacciones de tarjetas (CTQ, etiqueta 9F6C).
La entrada a la CA representada aquí incluye el PDOL completo según [33]; Los criptogramas patentados pueden utilizar menos objetos de datos [27].

Wifi C. Transacciones of fl ine no autenticadas

1 2 3 4
Para todas las transacciones de bajo valor de Visa y Mastercard con
Comandos APDU
autenticación of fl ine SDA o DDA, nuestro análisis Tamarin descubre un rastro que
viola la propiedad de que el banco acepta todas las transacciones aceptadas por
Respuestas APDU
NFC NFC terminales (Tabla II, Comentario 2). La traza representa una transacción en la que
el atacante modifica el criptograma de transacción (TC) antes de entregarlo al
Fig. 3. Un ataque de retransmisión al pago sin contacto, donde (1) es un terminal de pago, (4) es una terminal. El terminal llega a un estado en el que la transacción es aceptada dado
tarjeta sin contacto, y el equipo del atacante son los dispositivos (2) y (3), que son el emulador de tarjeta que los Datos de Autenticación Dinámica Firmados (SDAD), si son producidos y
y el Emulador POS, respectivamente.
devueltos por la tarjeta, pasan la verificación del terminal. Sin embargo, el banco
emisor debería rechazar la transacción posteriormente debido a un TC incorrecto.
Recuerde que el terminal solo puede verificar la corrección del SDAD pero no del
posesión de la víctima. TC ya que este último se verifica mediante una clave simétrica que solo la tarjeta y
Mastercard implementa la veri fi cación del titular de la tarjeta más en línea con la el banco conocen.
versión de contacto tradicional de EMV. El soporte de la tarjeta para el dispositivo de
consumidor CVM se define por el segundo bit del primer byte de AIP. Las tarjetas físicas
tienen este bit borrado. Por lo tanto, dado que el AIP está incluido en el criptograma, Esto constituye un ataque de "almuerzo gratis" en el sentido de que el delincuente
establecer este bit resultará en una transacción rechazada. puede comprar bienes o servicios de bajo valor sin que se le cobre en absoluto. Sin
embargo, es poco probable que esto sea un

(a) Emulador de tarjeta (b) Emulador POS
Fig. 4. Capturas de pantalla de nuestra aplicación. El emulador de tarjeta puede mostrar la firma del titular
de la tarjeta, en cuyo caso, debe coincidir con la firma del atacante. El registro que se muestra en el
emulador POS corresponde a una transacción real de ca. $ 190 en moneda local.
atractivo modelo de negocio para los delincuentes por dos razones. Primero, las
transacciones fraudulentas son de bajo valor. En segundo lugar, es probable que el
banco del criminal no ignore indefinidamente las quejas del comerciante defraudado.
Por razones éticas, no probamos este ataque ya que constituiría un fraude real.
D. Defensas contra ataques a Visa
Como se informó en la Sección VB, la configuración más común
ración del protocolo sin contacto Mastercard en las configuraciones de uso actuales, por
(es decir, CDA junto con el PIN en línea) es seguro. Los problemas de Visa se
otro lado, no lo son. Afortunadamente, Visa es la que describimos a continuación. Estos
pueden solucionar implementando los tres cambios que los bancos en una
cambios pueden ser realizados por Visa y afectar a las tarjetas actualmente en
cantidad razonable de tiempo y esfuerzo, sin
circulación.
El protocolo sin contacto de Visa [31] especifica ese especial (DDA) para
Los lectores de propósito pueden realizar la fi guración de Autenticación dinámica de
transacciones en línea. Este es de hecho el único conhold (Tabla II, Línea 4). Esta no
datos de este protocolo en las tres propiedades de seguridad, como lo indican nuestras
es una configuración común de diez terminales en vivo diferentes en diferentes
pruebas. Realizamos pruebas en más de ellos con esta configuración. Por lo tanto,
comercios, y ninguno de los ataques de derivación descritos en la Sección VI-B,
para evitar el PIN, los terminales deben usar DDA para transacciones en línea. Eso es
recomendamos que los terminales deben, para todas las transacciones:
todo
1) establezca el primer bit del primer byte de TTQ y
2) verificar el SDAD.
Si se implementan, estas dos medidas harían de alto valor
las transacciones se procesarán con la configuración segura de Visa.
Por supuesto, esto es asumiendo que las tarjetas utilizadas para tales
transacciones son capaces de producir firmas digitales, como las tarjetas
modernas. Además, para prevenir el ataque aéreo de la Sección VI-C,
proponemos que:
3a) todos los terminales establecen el octavo bit del segundo byte de TTQ para todos
actas; o
3b) 〈 NC, CID, AC, PDOL, ATC, CTQ, ONU, IAD, AIP 〉 es el
entrada a la SDAD, es decir, re en la Figura 2.
El ajuste 3 (a) hace que todas las transacciones se procesen en línea y es
preferible al 3 (b) porque el 3 (a) no requiere cambios en el estándar y por lo tanto no
afecta las tarjetas de consumidor en circulación. Además, las transacciones of fl ine
rara vez se admiten en la actualidad; ninguna de las transacciones que realizamos
durante nuestras pruebas fue autorizada fuera de servicio. Sin embargo, si la
capacidad de procesar ciertas transacciones de fline es imperativa (por ejemplo, en
sistemas de tránsito o parquímetros en la calle), entonces se necesitarían arreglos
más agresivos como el de 3 (b).
Hemos verificado los tres arreglos recomendados aquí. Juntos, se defienden de los
ataques informados en este documento, así como de cualquier otro ataque que intente
violar las propiedades de seguridad consideradas. Estos arreglos, a excepción de 3 (b),
se pueden implementar en el software / firmware de los terminales y, por lo tanto, son
atractivos en términos de implementación porque las actualizaciones de software de
los terminales deben ser significativamente menos costosas y más rápidas que otras
acciones más agresivas como el bloqueo. tarjetas en circulación y emisión de nuevas.
VII. C ONCLUSIONES
Hemos presentado un modelo formal de la última versión del estándar EMV que
presenta todos los métodos relevantes para la autenticación de datos, la verificación
del titular de la tarjeta y la autorización de transacciones. Usando la herramienta
Tamarin, realizamos un análisis formal, automático y a gran escala de este modelo,
descubriendo
numerosas fallas de seguridad. Estos defectos violan fundamentales sobre las
las propiedades de seguridad, como la autenticación y otras garantías, identifican las
transacciones aceptadas. También usamos nuestro modelo y probamos su
configuraciones de EMV que conducen a transacciones seguras,
exactitud.
Nuestro análisis reveló diferencias sorprendentes entre Visa y Visa, mostrando que
seguridad de los protocolos de pago sin contacto de Mastercard No encontramos
Mastercard es más segura que Visa. corriendo en tarjetas modernas. Nuestro análisis
problemas importantes con la versión del protocolo de Mastercard. Deficiencias derivadas
reveló solo menores y DDA) que parecen difíciles de explotar en la práctica. Por el
de los modos de autenticación más antiguos (SDA Visa tiene varios problemas críticos.
contrario, los informes conducen a ataques prácticos y graves, incluido un límite de PIN.
Las deficiencias que eludimos para transacciones que superan la verificación del titular de
Usando nuestra aplicación de Android de prueba de concepto, realizamos tiendas.
la tarjeta probaron con éxito este ataque en -transacciones mundiales en transacciones
Nuestro ataque muestra que el PIN es inútil para Visa. El cambio de los bancos a los
sin contacto.Como resultado, en nuestra opinión, la responsabilidad por dichas
consumidores o comerciantes no está justificado, salvo que el consumidor o
transacciones: Bancos, EMVCo, Visa o alguna entidad transacciones fraudulentas.
comerciante deba ser responsable de tal
 Como parte de nuestro análisis, sugerimos y verificamos las correcciones que los bancos y
Visa pueden implementar en terminales existentes para prevenir ataques actuales y futuros. La
buena noticia es que estos arreglos no requieren cambios en el estándar EMV en sí ni en las
tarjetas de consumo actualmente en circulación y, por lo tanto, pueden implementarse de manera
factible mediante actualizaciones de software.
R EFERENCIAS
[1] SJ Murdoch, S. Drimer, RJ Anderson y M. Bond, "Chip and PIN is broken", en 31 ° Simposio
de IEEE sobre seguridad y privacidad, S&P
2010, 16-19 de mayo de 2010, Berleley / Oakland, California, EE. UU., págs. 433–
446, 2010.
[2] TS Heydt-Benjamin, DV Bailey, K. Fu, A. Juels y T. O'Hare, “Vulnerabilities in first-generation
rfi d credit cards”, en Criptografía financiera y seguridad de datos, XI Conferencia
Internacional, FC
2007, y 1er Taller Internacional sobre Seguridad Usable, USEC 2007, Scarborough, Trinidad
y Tobago, 12-16 de febrero de 2007. Revised Selected Papers, págs. 2-14, 2007.
[3] M. Roland y J. Langer, "Clonación de tarjetas de crédito: un ataque combinado de pre-juego y
degradación en EMV sin contacto", en 7o Taller de USENIX sobre tecnologías ofensivas, WOOT
'13, Washington, DC, EE. UU., Agosto
13 de 2013, 2013.
[4] S. Drimer y SJ Murdoch, "Mantén a tus enemigos cerca: saltos de distancia contra ataques de
retransmisión de tarjetas inteligentes", en Actas del 16 ° Simposio de seguridad de USENIX,
Boston, MA, EE. UU., 6 al 10 de agosto de 2007,
2007.
[5] L. Francis, GP Hancke, K. Mayes y K. Markantonakis, "Práctico ataque de retransmisión en
transacciones sin contacto mediante el uso de teléfonos móviles NFC"
Archivo ePrint de criptología IACR, vol. 2011, pág. 618, 2011.
[6] L. Sportiello y A. Ciardulli, "Ataque por relevos de larga distancia", en Identi fi cación por
radiofrecuencia: cuestiones de seguridad y privacidad Noveno taller internacional, RFIDsec 2013,
Graz, Austria, 9-11 de julio de 2013, artículos seleccionados revisados, págs. 69–85, 2013.
[7] T. Chothia, FD García, J. de Ruiter, J. van den Breekel y M. Thompson, “Relay cost bounding
for contactless EMV payments”, en Criptografía financiera y seguridad de datos - XIX
Conferencia Internacional, FC
2015, San Juan, Puerto Rico, 26 al 30 de enero de 2015, Artículos seleccionados revisados, págs.
189–206, 2015.
[8] M. Bond, O. Choudary, SJ Murdoch, SP Skorobogatov y RJ Anderson, "Chip and skim:
Cloning EMV cards with the pre-play attack", en 2014 IEEE Symposium on Security and
Privacy, SP 2014, Berkeley, CA, EE. UU., 18-21 de mayo de 2014, págs. 49–64, 2014.
[9] M. Emms, B. Arief, L. Freitas, J. Hannon y APA van Moorsel, "Recolección de transacciones
en moneda extranjera de alto valor de tarjetas de crédito EMV sin contacto sin PIN", en Actas
de la Conferencia ACM SIGSAC de 2014 sobre seguridad informática y de comunicaciones,
Scottsdale, AZ, EE. UU., 3-7 de noviembre de 2014, págs. 716–726, 2014.
[10] H. Ferradi, R. Géraud, D. Naccache y A. Tria, "Cuando el crimen organizado aplica resultados
académicos: un análisis forense de un dispositivo de escucha en la tarjeta", J. Ingeniería
criptográfica, vol. 6, no. 1, págs. 49–59, 2016.
[11] S. Meier, B. Schmidt, C. Cremers y DA Basin, “The TAMARIN prover for the symbolic analysis
of security protocolos,” en Veri fi cación asistida por ordenador - 25ª Conferencia
Internacional, CAV 2013, San Petersburgo, Rusia, 13-19 de julio de 2013. Actas, págs.
696–701, 2013.
[12] B. Schmidt, S. Meier, CJF Cremers y DA Basin, “Análisis automatizado de protocolos Dif fi
e-Hellman y propiedades de seguridad avanzadas”, en 25o Simposio de Fundamentos de
Seguridad Informática del IEEE, CSF 2012, Cambridge, MA, EE. UU., 25-27 de junio de 2012, págs.
78–94, 2012.
[13] C. Cremers, M. Horvat, J. Hoyland, S. Scott y T. van der Merwe, "Un análisis simbólico
integral de TLS 1.3", en Actas de la Conferencia ACM SIGSAC de 2017 sobre seguridad
informática y de comunicaciones, CCS 2017, Dallas, TX, EE. UU., 30 de octubre - 3 de
noviembre de 2017,
págs. 1773–1788, 2017.
[14] DA Basin, J. Dreier, L. Hirschi, S. Radomirovic, R. Sasse y V. Stetler, "Un análisis formal de la
autenticación 5g", en Actas de la Conferencia ACM SIGSAC 2018 sobre seguridad
informática y de comunicaciones, CCS 2018, Toronto, ON, Canadá, 15-19 de octubre de
2018, págs. 1383-1396,
2018.
[15] J. de Ruiter y E. Poll, "Análisis formal del conjunto de protocolos EMV", en Teoría de la
seguridad y aplicaciones - Taller conjunto, TOSCA 2011, Saarbrücken, Alemania, 31 de marzo -
1 de abril de 2011, artículos seleccionados revisados, págs. 113-129, 2011.
[dieciséis]S. Mauw, Z. Smith, J. Toro-Pozo y R. Trujillo-Rasua, "Protocolos de límite de distancia: Veri fi
cación sin hora ni lugar", en 2018 IEEE Symposium on Security and Privacy, SP 2018, Actas,
21-23 de mayo de 2018, San Francisco, California, EE. UU., págs. 549–566, 2018.
[17] A. Debant, S. Delaune y C. Wiedling, "Un marco simbólico para analizar la proximidad física en
los protocolos de seguridad", en 38a Conferencia Anual de la IARCS sobre los fundamentos de
la tecnología del software y la informática teórica, FSTTCS 2018, del 11 al 13 de diciembre de
2018, Ahmedabad, India, págs. 29: 1–29: 20, 2018.
[18] B. Blanchet, "Un verificador de protocolo criptográfico eficiente basado en las reglas de Prolog", en 14o
Taller de fundamentos de seguridad informática de IEEE (CSFW-14 2001), 11-13 de junio de 2001,
Cape Breton, Nueva Escocia, Canadá,
págs. 82–96, 2001.
[19] K. Bhargavan, C. Fournet, AD Gordon y S. Tse, "Veri fi ed interop- erable implementations of
security Protocols", en XIX Taller de fundamentos de seguridad informática del IEEE,
(CSFW-19 2006), 5-7 de julio de 2006, Venecia, Italia, págs. 139-152, 2006.
[20] D. Dolev y AC Yao, "Sobre la seguridad de los protocolos de clave pública",
IEEE Trans. Teoría de la información, vol. 29, no. 2, págs. 198-207, 1983.
[21] DA Basin y C. Cremers, "Conoce a tu enemigo: comprometer a los adversarios en el análisis
de protocolos", ACM Trans. Inf. Syst. Secur., vol. 17, no. 2, págs. 7: 1–7: 31, 2014.
[22] T. Beth e Y. Desmedt, "Fichas de identificación - o: Resolviendo el problema del gran maestro
de ajedrez", en Advances in Cryptology - CRYPTO '90, 10th Annual International Cryptology
Conference, Santa Barbara, California, USA, 11-15 de agosto de 1990, Actas, págs. 169-177,
1990.
[23] S. Brands y D. Chaum, "Protocolos de límite de distancia (resumen ampliado)", en Advances
in Cryptology - EUROCRYPT '93, Workshop on the Theory and Application of of
Cryptographic Techniques, Lofthus, Noruega, 23-27 de mayo de 1993, Actas, págs. 344–359,
1993.
[24] T. Chothia, J. de Ruiter y B. Smyth, "Modelado y análisis de una jerarquía de ataques de salto
de distancia", en 27th USENIX Security Symposium, USENIX Security 2018, Baltimore, MD,
EE. UU., 15 de agosto al
17, 2018., págs. 1563-1580, 2018.
[25] S. Mauw, Z. Smith, J. Toro-Pozo y R. Trujillo-Rasua, "Post-collusion security and distance
bounding", en Actas de la Conferencia ACM SIGSAC de 2019 sobre seguridad informática y
de comunicaciones, CCS
2019, Londres, Reino Unido, 11-15 de noviembre de 2019., págs. 941–958, 2019.
[26] A. Debant y S. Delaune, "Veri fi cación simbólica de protocolos de límite de distancia", en Principios
de seguridad y confianza: octava conferencia internacional, POST 2019, celebrada como parte
de las conferencias conjuntas europeas sobre teoría y práctica del software, ETAPS 2019,
Praga, República Checa, del 6 al 11 de abril de 2019, actas, págs. 149-174, 2019.
[27] LA. Galloway y T. Yunusov, "Primer contacto: nuevas vulnerabilidades en los pagos sin
contacto", en Black Hat Europe 2019, 2019.
[28] G. Lowe, "Una jerarquía de especi fi cación de autenticación", en 10º Taller de fundamentos de
seguridad informática (CSFW '97), 10-12 de junio de 1997, Rockport, Massachusetts, EE. UU. págs.
31–44, 1997.
[29] C. Cremers y S. Mauw, Semántica operativa y verificación de protocolos de seguridad. Seguridad
de la información y criptografía, Springer,
2012.
[30] EMVCo, Especi fi caciones EMV sin contacto para sistemas de pago, Libro C-2, Especificación del
Kernel 2, Versión 2.8. Abril de 2019. EMVCo, Especificaciones EMV sin contacto para sistemas de
[31] pago, Libro C-3, Especificación del Kernel 3, Versión 2.8. Abril de 2019.
[32] Anónimo, "Un modelo Tamarin de EMV". https://github.com/EMVrace/ EMVerify, 2020.
Consultado: junio de 2020.
[33] EMVCo, “Especificaciones de tarjetas de circuito integrado EMV para sistemas de pago, Libro 2,
Seguridad y administración de claves, versión 4.3”, noviembre
2011.
[34] Google, "Descripción general de la emulación de tarjetas basada en host". https: // desarrollador.
android.com/guide/topics/connectivity/nfc/hce, 2019. Consultado: diciembre de 2019.
[35] EMVCo, Especi fi caciones EMV sin contacto para sistemas de pago, Libro C-6, Especificación del
Kernel 6, Versión 2.8. Abril de 2019. EMVCo, Especi fi caciones EMV sin contacto para sistemas
[36] de pago, Libro C-7, Especificación del Kernel 7, Versión 2.8. Abril de 2019.
UNA CRÓNIMOS
CAA Criptograma de autenticación de aplicaciones. 6
C.A. Criptograma de aplicación. 2, 6, 8–12
AFL Localizador de archivos de aplicaciones. 4
AYUDA Identificador de la aplicación. 4 1/* si (Visa)
AIP Perfil de intercambio de aplicaciones. 4, 6, 8, 12 2 regla Terminal_Commits_ARQC_Visa :
3 dejar PDOL = < TTQ, $ monto, país, moneda,
APDU Unidad de datos de protocolo de aplicación. 3, 12
fecha, tipo, ˜UN >
ARCO Código de respuesta de autorización. 6 4 / * si (DDA) AIP = < 'DDA' , datos > endif (DDA) * / / * si (EMV) AIP = < 'EMV' , datos >
ARPC Criptograma de respuesta de autorización. 6 5 endif (EMV) * / / * if valor (bajo) = 'Bajo' endif (bajo) * /
6
ARQC Criptograma de solicitud de autorización. 6
7 / * si valor (alto) = 'Alto' endif (alto) * / transacción = < ˜PAN, AIP, CVM, PDOL,
ATC Contador de transacciones de aplicaciones. 6, 8 8 ATC,
AC, IAD >
CDA Autenticación dinámica de datos combinada. 2, 4, 6, 8, 10, 9 en
10 [ Terminal_Received_AC_Visa ($ Terminal, $ Banco,
13
11 $ CA, Carolina del Norte, 'ARQC' , transacción, ˜channelID),
CDCVM Dispositivo de consumo CVM. 2, 4, 8, 10–12 12 ! Valor ($ cantidad, valor),
CDOL Lista de objetos de datos de gestión de riesgos de tarjetas. 4, 6, 11 13 Recv ($ Banco, $ Terminal,
14 < Canal ID, 'Visa' , '2' > , < 'ARCO' , ARPC > )
CID Datos de información del criptograma. 6
]
CTQ Calificadores de transacciones con tarjeta. 8, 10-12 15 - - [ TerminalAccepts (transacción),
CVM Método de verificación del titular de la tarjeta. 2–4, 6, 8–12, 15 dieciséis Confirmar (nc, ˜PAN,
17 < 'Tarjeta' , 'Terminal' , transacción > ),
CVMR Resultados del método de verificación del titular de la tarjeta. 9
18 Comprometer ($ Terminal, $ Bank,
19 < 'Banco' , 'Terminal' , transacción > ),
DDA Autenticación dinámica de datos. 2, 4, 8–10, 12, 13 20 Honesto ($ CA), Honesto ($ Bank),
21 Honesto ($ Terminal), Honesto (˜PAN) ] ->
DDOL Lista de objetos de datos dinámicos. 4
22 []
23 endif (Visa) * /
HCE Emulación de tarjeta basada en host. 10

IAD Datos de solicitud del emisor. 8 Fig. 5. Fragmento de código Tamarin del modelo de protocolo sin contacto EMV.

NFC Cerca de un campo de comunicación. 3, 10-12

• auth: de fi ne el método de Autenticación de datos of fl ine (ODA). Las

AOD Autenticación de datos de fl ine. 2, 4
instancias válidas son:

PAN Número de cuenta principal. 4, 7-10 - SDA,

PDOL Lista de objetos de datos de procesamiento. 4, 11, 12 - DDA,

POS Punto de venta. 10, 12 - CDA, y

PSE Entorno del sistema de pago. 4, 8 - EMV ( solo para transacciones sin contacto).

• CVM: de fi ne el método de verificación del titular de la tarjeta utilizado / - admitido. Las

SDA Autenticación de datos estáticos. 2, 4, 9, 10, 12, 13 instancias válidas son:
SDAD Datos de autenticación dinámica firmados. 4, 6, 12, 13
- No PIN,
SSAD Datos de autenticación estáticos firmados. 4, 9
- PlainPIN ( solo para transacciones de contacto),
- EncPIN ( PIN cifrado, solo para transacciones de contacto) y
ejército de reserva Autorización de transacción. 2, 4

TC Criptograma de transacciones. 6, 9, 10, 12

- OnlinePIN.
TTQ Calificadores de transacciones de terminal. 11-13
• valor: de fi ne el valor de la transacción sin contacto. Las instancias válidas
Naciones Unidas Número impredecible. 4, 6 son:

- Bajo ( por debajo del límite requerido por CVM), y

UNA PÉNDICE
- Alto ( por encima del límite requerido por CVM).
A. Generación de modelos de destino
• authz: de fi ne el tipo de autorización de la transacción de contacto. Las
Construimos el modelos de destino de las reglas de un modelo genérico, así como instancias válidas son:
reglas adicionales que producen el Cometer hechos utilizados para la (in) validación de - Desconectado, y
propiedades. Hemos escrito un - En línea.
Makefile script que genera los modelos de destino instalando las siguientes
La ejecución de hacer con una selección de instancias variables, la determinación de
variables:
una configuración objetivo genera el modelo objetivo y lo analiza con Tamarin. Para
• genérico: de fi ne el modelo genérico. Las instancias válidas son:
comprender cómo instrumentamos la generación automática de modelos de destino
- Contacto, y reales, considere el fragmento de código que se muestra en la Figura 5, tomado de
- Sin contacto. nuestro modelo genérico del protocolo sin contacto EMV.
• núcleo: de fi ne el núcleo de la transacción sin contacto. Las instancias válidas
son: Este fragmento de código es activado sin comentar), por lo que la regla se
- Tarjeta MasterCard, y convierte en parte del modelo de destino, si la configuración de destino incluye kernel
- Visa. = Visa. Además, dependiendo de
 1 regla Terminal_Commits_ARQC_Visa :
2 dejar PDOL = < TTQ, $ monto, país, moneda,
fecha, tipo, ˜UN >
3 AIP = < 'DDA' , datos >
4 valor = 'Alto'
5 transacción = < ˜PAN, AIP, CVM, PDOL, ATC,
AC, IAD >
6 en
7 [ Terminal_Received_AC_Visa ($ Terminal, $ Banco,
8 $ CA, Carolina del Norte, 'ARQC' , transacción, ˜channelID),
9 ! Valor ($ cantidad, valor),
10 Recv ($ Banco, $ Terminal,
11 < Canal ID, 'Visa' , '2' > , < 'ARCO' , ARPC > )
]
12 - - [ TerminalAccepts (transacción),
13 Confirmar (nc, ˜PAN,
14 < 'Tarjeta' , 'Terminal' , transacción > ),
15 Comprometer ($ Terminal, $ Bank,
dieciséis < 'Banco' , 'Terminal' , transacción > ),
17 Honesto ($ CA), Honesto ($ Bank),
18 Honesto ($ Terminal), Honesto (˜PAN) ] ->
19 []

Fig. 6. Fragmento de código Tamarin del modelo de destino Visa DDA High.

el resto de la configuración de destino, el AIP y el valor se activan. Por

ejemplo, si nuestra configuración de destino incluye
auth = DDA y valor = Alto, entonces la regla se convierte en la que se muestra en la
Figura 6. Esta (nueva) regla modela la aceptación por parte del terminal de una
transacción autorizada en línea y produce la correspondiente Cometer y TerminalAcepta
hechos.