Chip & Skim: Ataques de replay a tarjetas de crédito EMV

El mes pasado se hizo público el paper de "Chip & Skim: Clonning EMV with the pre-play attack" y lo tenía pendiente de lectura. Ayer saqué un poco de tiempo para poder leerlo y la verdad es que me ha encantado su lectura, ya que los dos métodos para atacar tarjetas de crédito EMV (Europay, MasterCard and Visa) que proponen son prácticos y realistas tanto en funcionamiento como en posibilidades, así que os voy a hablar un poco de ellos por aquí.

Figura 1: Chip and Skim: Cloning EMV cards with the pre-play attack

Antes de entender los dos ataques que proponen hay que fijarse en el gráfico que describe el flujo de verificación de una transacción entre un cardholder (el dueño de la tarjeta), un terminal de uso de la tarjeta (donde se pone el PIN) y el emisor de la tarjeta (el banco).

El resumen del flujo está en el siguiente diagrama. Si nos fijamos en el intercambio de mensajes se puede ver que tras la verificación inicial en la que se negocia entre el terminal y la tarjeta, llega el momento en el que se requiere del cardholder, es decir, del usuario, la verificación de que los datos de la transacción visualmente y la petición de autorización al issuer de la tarjeta firmando todo con el famoso PIN.

Figura 2: Flujo de mensajes y datos en una transacción EMV

Para ello, el terminal envía los datos de la Transacción "T", que además de llevar la cantidad, la moneda, la fecha y el terminal de venta, lleva un "número no-predecible" el famoso nonce o UN. Con estos datos el chip EMV genera el ARQC (Authorisation Request Cryptogram) que está formado por los datos de la transacción donde va el número nonce, cifrado a partir de las claves que se liberan del chip EMV tras la introducción del PIN que se envía al banco emisor - o a un procesador - de la tarjeta.

Éste valida la transacción y envía al terminal el ARPC (Authorisation Response Cryptogram) y el ARC (Authorisation Response Code), dando por buena la transacción y enviando a la tarjeta la respuesta para que quede constancia del resultado. 

Hasta aquí todo correcto, pero... ¿qué sucede si alguien malicioso es capaz de interceptar datos en alguna parte de la comunicación? ¿Podrá hacer creer al issuer o al terminal de que tiene una tarjeta de crédito EMV correcta cuando no la tiene? De eso va el trabajo que se ha publicado.

Ataque 1: El número nonce no es tan unpredictable

Tras mirar cómo se generan los números nonce en muchos terminales, resulta que la aleatoriedad en la criptografía sigue siendo un problema. Hace poco hablaba del paper que proponía usar la cámara de un smartphone para hacer lecturas de fotones en haces de luces y poder generar números aleatorios de buena calidad. En muchos de los terminales estudiados por este trabajo los números no eran impredecibles ni mucho menos, y muchos usaban contadores con incremento en base a números aleatorios, lo que hacía que no fuera difícil predecir o pre-computar todos los posibles casos.

Figura 3: Esquema de ataque de replay contra aleatoriedad débil.

Para ello, conocida toda la lista, el atacante podría interceptar el tráfico de petición de autorización al issuer, y con una tabla con todos los posibles UN (Unpredictable Number) y sus respuestas de autorización, dar al terminal el OK correcto para la transacción, lo que permitiría, por ejemplo, sacar dinero con una falsa tarjeta EMV. Por supuesto, este ataque solo es posible si se tienen capturadas las respuestas previamente y si se conoce - y es mala - la generación de números nonce del terminal. Si tenemos control de la conexión entre el terminal y el issuer, se puede probar hasta que se obtenga una pre-computada.

Ataque 2: Reutilización de números nonce

Este segundo ataque es todavía más curioso y peculiar, ya que es similar a los ataques que se producen en aplicaciones web cuando los datos que se van a utilizar para cargar el precio de un producto en una tienda se leen desde el cliente. La idea es que cuando el terminal envía el número aleatorio nonce a la tarjeta EMV para generar el ARQC, la tarjeta "maliciosa y falsa" reutiliza un ARQC anterior usando otro número nonce.

Figura 4: Ataque de replay reintroduciendo un ARQC con un UN ya validado

Si el terminal no tiene una verificación correcta de que se ha recibido el número UN correcto, el ARQC que enviará al issuer - al banco en este caso - será con el número enviado por el atacante que ya había sido validado previamente. El banco generará el ARPC correspondiente y el terminal dará por buena la transacción.

Conclusiones

Estos dos ataques se basan en re-usar paquetes ya utilizados previamente para conseguir replicar transacciones como si fueran nuevas. Son ataques complejos, pero realizables y que se basan en detalles técnicos no solventados de forma segura en algunos terminales de uso de las tarjetas EMV (Chip & PIN). Por supuesto, que te clonen una tarjeta EMV sigue siendo varios órdenes de magnitud más difícil que una tarjeta de banda magnética, pero no todos los sitios tienen soporte para EMV ni es totalmente imposible que uno de estos ataques se ponga en práctica por los amigos del fraude.

Hay que tener presente que muchas de las veces los clonadores de tarjetas son personas que tienen control con el terminal, así que... ¿por que no iban a poder hacer un ataque de red man in the middle y grabar todo el tráfico de las transacciones para hacer ataques de replay? Además, es mucho más sencillo de esconder, ya que el cable de red del terminal se conecta normalmente a algún sitio que no se ve. A ver si ponemos Latch a algunas tarjetas de crédito pronto.

Saludos Malignos!