Programa de autenticación de chips

El Programa de Autenticación por Chip (CAP) es una iniciativa de MasterCard y una especificación técnica para el uso de tarjetas inteligentes bancarias EMV para autenticar usuarios y transacciones en la banca en línea y telefónica . También fue adoptado por Visa como Autenticación Dinámica por Código de Acceso (DPA). ^{[ 1 ]} La especificación CAP define un dispositivo portátil ( lector CAP ) con una ranura para tarjeta inteligente, un teclado numérico y una pantalla capaz de mostrar al menos 12 caracteres (por ejemplo, una pantalla de estrella ). Los clientes bancarios que hayan recibido un lector CAP de su banco pueden insertar su tarjeta con chip y PIN ( EMV ) en el lector CAP para participar en uno de los diversos protocolos de autenticación compatibles . CAP es una forma de autenticación de dos factores , ya que tanto una tarjeta inteligente como un PIN válido deben estar presentes para que una transacción se complete con éxito. Los bancos esperan que el sistema reduzca el riesgo de que los clientes desprevenidos ingresen sus datos en sitios web fraudulentos después de leer los llamados correos electrónicos de phishing . ^{[ 2 ]}

La especificación CAP admite varios métodos de autenticación. El usuario primero inserta su tarjeta inteligente en el lector CAP y la habilita ingresando el PIN. Luego, presiona un botón para seleccionar el tipo de transacción. La mayoría de los lectores ofrecen dos o tres tipos de transacción al usuario con diferentes nombres. Algunas implementaciones conocidas son:

Código/identificar

Sin necesidad de introducir ningún dato adicional, el lector CAP interactúa con la tarjeta inteligente para generar una contraseña decimal de un solo uso , que puede utilizarse, por ejemplo, para iniciar sesión en un sitio web bancario.

Respuesta

Este modo implementa la autenticación de desafío-respuesta , donde el sitio web del banco solicita al cliente que ingrese un número de "desafío" en el lector CAP y luego copie el número de "respuesta" que muestra el lector CAP en el sitio web.

Firmar

Este modo es una extensión del anterior, donde no solo se debe introducir en el lector CAP un valor de "desafío" aleatorio, sino también detalles cruciales de la transacción, como el valor transferido, la moneda y el número de cuenta del destinatario.

Los tipos de transacción mencionados anteriormente se implementan utilizando uno de dos modos. Uno de estos modos tiene dos formas en las que puede operar, creando tres modos distintos, aunque no se denominan así en la especificación.

Modo1

Este es el modo para transacciones monetarias normales, como una compra en línea a través de un comercio. El valor de la transacción y la moneda se incluyen en el cálculo del criptograma. Si la tarjeta no lo requiere o el terminal no lo admite, tanto el importe como la moneda se establecen en cero.

Modo2

Este modo puede ser útil para autenticar a un usuario sin que se realice ninguna transacción, como por ejemplo al iniciar sesión en un sistema de banca por internet. No se incluye ningún valor de transacción, moneda ni otros datos, lo que facilita enormemente el cálculo previo o la reutilización de estas respuestas.

Con firma de datos de transacción (TDS)

Este modo puede utilizarse para transacciones más complejas, como una transferencia de fondos entre cuentas. Se concatenan varios campos de datos relacionados con la transacción y, a continuación, se aplica una función hash utilizando un criptograma Modo 2 como clave para el algoritmo de hash. El hash resultante se utiliza en lugar del criptograma calculado en una operación Modo 2 que no sea TDS. ^{[ 3 ]}

El Modo 1 se asemeja mucho a un uso específico del Modo 2 con TDS, pero existe una diferencia crucial. En el Modo 1, los datos de la transacción (importe y tipo de moneda) se utilizan en el cálculo del criptograma, además de todos los valores utilizados en el Modo 2 sin TDS. En cambio, el Modo 2 incluye sus datos de transacción en un paso posterior, en lugar de incluirlos en el cálculo del criptograma. Si no fuera por esta diferencia, todas las operaciones podrían generalizarse como una sola operación con datos de transacción opcionales variables.

En los tres modos, el lector CAP solicita a la tarjeta EMV que emita un paquete de datos que confirme la cancelación de una transacción de pago EMV ficticia, la cual involucra los datos ingresados ​​por el usuario. Este mensaje de confirmación contiene un código de autenticación (normalmente CBC-MAC / Triple DES ) generado con la ayuda de una clave secreta específica de la tarjeta, almacenada de forma segura en la tarjeta inteligente. Estos mensajes de cancelación no representan ningún riesgo de seguridad para la aplicación de pago EMV habitual, pero pueden verificarse criptográficamente y son generados por una tarjeta EMV solo después de que se haya ingresado el PIN correcto. Esto proporcionó a los diseñadores del CAP una forma de crear una sólida evidencia criptográfica de que una tarjeta EMV activada por PIN está presente y ha procesado ciertos datos de entrada, sin necesidad de agregar nuevas funciones de software a las tarjetas EMV ya en uso.

Una tarjeta inteligente EMV contiene un contador de transacciones (normalmente de 16 bits) que se incrementa con cada pago o transacción CAP. La respuesta que muestra un lector CAP consiste esencialmente en las distintas partes de la respuesta de la tarjeta (Contador de Transacciones de la Aplicación, MAC, etc.), que luego se reduce a bits específicos según lo determine el registro del Indicador de Autenticación del Emisor (IAI) almacenado en la tarjeta (este se configura por emisor, aunque si un emisor lo desea, podría configurarse aleatoriamente para cada tarjeta siempre que se mantenga una base de datos del IAI de cada tarjeta). Finalmente, después de descartar los bits no deseados (la posición absoluta de los bits es irrelevante; un bit en el IAI que es 0 significa que el bit correspondiente en la respuesta de la tarjeta se descartará en lugar de simplemente establecerse en 0), el valor se convierte de binario a decimal y se muestra al usuario. A continuación se proporciona un ejemplo truncado:

1. El dispositivo CAP selecciona la aplicación EMV, lee la información IAI de la tarjeta y el usuario selecciona una acción a realizar (en este ejemplo, IAI será 111011011000 ₂ ).
2. Tras introducir correctamente el PIN, el dispositivo CAP envía el desafío 011100111010 ₂ como una transacción de criptograma de solicitud de autorización (ARQC).
3. La tarjeta inteligente da una respuesta de 110101110110 ₂ y el dispositivo CAP cancela la transacción falsa.
4. El dispositivo CAP utiliza la máscara IAI: 111011011000 ₂ para descartar bits; se descartan aquellos bits que corresponden a un 0 en la máscara.
5. Por lo tanto, la respuesta final es 1100110 ₂ o 102 en decimal.

El proceso en el mundo real es, por supuesto, algo más complejo, ya que la tarjeta puede devolver el ARQC en uno de dos formatos (ya sea el formato de plantilla de mensaje de respuesta simple tipo 1 (id. 80 ₁₆ ) o el formato de plantilla de mensaje de respuesta más complejo 2 (id. 77 ₁₆ ), que divide los datos ARQC en valores TLV separados que deben volver a ensamblarse secuencialmente para que coincidan con el formato de tipo 1.

En el modo de identificación, la respuesta depende únicamente de los bits requeridos del IAI, ya que el importe y el número de referencia se establecen en cero; esto también significa que seleccionar "responder" e introducir el número 00000000 generará una respuesta de identificación válida. Sin embargo, lo más preocupante es que, si un banco emite una solicitud de respuesta, usar el modo de firma con el mismo número y un importe de 0,00 € generará un resultado válido, lo que crea la posibilidad de que un estafador instruya a un cliente para que realice una respuesta de desafío de "prueba" por un importe de 0,00 €, que en realidad será utilizado por el estafador para verificar un comando de respuesta y así agregarse como beneficiario en la cuenta de la víctima. Estos ataques se podían llevar a cabo contra bancos que utilizaban dispositivos de autenticación robustos que no cancelaban las actividades hasta que se introducía un importe de al menos 0,01 €. ^{[ 4 ]} La probabilidad de este tipo de ataques se abordó en 2009 cuando se lanzaron nuevas generaciones de dispositivos, implementando una funcionalidad de separación de dominios segura que cumple con la nota de aplicación de MasterCard de octubre de 2010. De manera similar, por supuesto, un banco que implementa el comando de identificación permite que un estafador solicite a una víctima que realice una transacción de respuesta de "prueba" utilizando 00000000 como referencia, y luego podrá iniciar sesión con éxito en la cuenta de la víctima. ^{[ 4 ]}

Se utiliza el mismo contador de reintentos de PIN integrado en la tarjeta que en otras transacciones EMV. Por lo tanto, al igual que en un cajero automático o terminal de punto de venta, introducir un PIN incorrecto tres veces seguidas en un lector CAP bloqueará la tarjeta.

La especificación original de CAP se diseñó para utilizar transacciones EMV normales, de modo que la aplicación CAP pudiera implementarse sin actualizar el firmware de las tarjetas EMV existentes, si fuera necesario. La implementación preferida utiliza una aplicación independiente para las transacciones CAP. Ambas aplicaciones pueden compartir ciertos datos, como el PIN, mientras que otros datos no se comparten en los casos en que solo sean aplicables a una aplicación (por ejemplo, datos de gestión de riesgos del terminal para EMV) o cuando resulta ventajoso tenerlos separados (por ejemplo, el contador de transacciones, de modo que las transacciones EMV y CAP incrementen contadores independientes que se pueden verificar con mayor precisión). El lector también contiene datos específicos de la implementación, algunos de los cuales pueden ser sobrescritos por los valores de la tarjeta. Por lo tanto, los lectores CAP generalmente no son compatibles con tarjetas de diferentes bancos emisores.

Sin embargo, la mayoría de los bancos del Reino Unido que emiten lectores de tarjetas cumplen con un subconjunto CAP definido por APACS , lo que significa que, en la mayoría de los casos, las tarjetas emitidas por un banco del Reino Unido se pueden usar en un lector de tarjetas emitido por un banco diferente.

Los investigadores de la Universidad de Cambridge, Saar Drimer, Steven Murdoch y Ross Anderson, llevaron a cabo una investigación ^{[ 4 ]} sobre la implementación de CAP, describiendo varias vulnerabilidades en el protocolo y en la variante británica tanto de lectores como de tarjetas. Se encontraron numerosas debilidades. Investigadores de la Universidad de Radboud encontraron una vulnerabilidad en el dispositivo neerlandés ABN AMRO e.dentifier2, que permite a un atacante ordenar a un lector conectado por USB que firme transacciones maliciosas sin la aprobación del usuario. ^{[ 5 ]}

Existe ^{[ 9 ]} una implementación de software escrita en Python que admite el Modo 1, el Modo 2 y el Modo 2 con TDS para ser utilizada únicamente con fines educativos. La función de identificación (sin desafío) corresponde a la función m1 con el desafío "00000000".

Tenga en cuenta que usar este software para operaciones financieras reales puede conllevar ciertos riesgos. De hecho, la ventaja de usar un lector independiente es aislar la tarjeta bancaria del malware que podría estar presente en el ordenador. Usarla en un lector no seguro implica el riesgo de que un registrador de pulsaciones intercepte el PIN y que el malware del punto de venta acceda a los datos de la tarjeta, o incluso intercepte una transacción para modificarla o realizarla por su cuenta.

• 3-D Secure