El Programa de Autenticación con 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 banca en línea y telefónica. También fue adoptado por Visa como Autenticación de Código de Acceso Dinámico (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 a los que su banco les ha emitido un lector CAP pueden insertar su tarjeta con chip y PIN ( EMV ) en el lector CAP para participar en uno de los varios protocolos de autenticación admitidos . 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 sea exitosa. 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 lo habilita ingresando el PIN. Luego se presiona un botón para seleccionar el tipo de transacción. La mayoría de los lectores tienen dos o tres tipos de transacciones disponibles para el usuario bajo una variedad de nombres. Algunas implementaciones conocidas son:
Los tipos de transacciones mencionados anteriormente se implementan utilizando uno de dos modos. Uno de estos modos tiene dos formas en las que puede operar, lo que crea tres modos distintos, aunque no se los nombra de esta manera en la especificación.
El modo 1 suena muy parecido a un uso específico del modo 2 con TDS, pero hay una diferencia fundamental. En la operación del modo 1, los datos de la transacción (cantidad 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, mientras que el modo 2 incluye sus datos de la transacción en un paso sucesivo en lugar de incluirlos en el paso de cálculo del criptograma. Si no fuera por esta diferencia, entonces 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 confirma la cancelación de una transacción de pago EMV ficticia, que incluye los datos introducidos por el usuario. Este mensaje de confirmación contiene un código de autenticación de mensajes (normalmente CBC-MAC / Triple DES ) que se genera 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 suponen 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 únicamente después de que se haya introducido el PIN correcto. Esto proporcionó a los diseñadores del CAP una forma de crear una prueba criptográfica sólida de que una tarjeta EMV activada por PIN está presente y ha visto algunos datos de entrada determinados, sin tener que añadir ninguna función de software nueva a las tarjetas EMV que ya están 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 básicamente 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 determinado por el registro del Indicador de autenticación del emisor (IAI) almacenado en la tarjeta (esto se establece por emisor, aunque si un emisor lo desea, se puede establecer de forma aleatoria 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 (esencialmente, la posición absoluta de los bits es irrelevante, un bit en el IAI que sea 0 significa que el bit correspondiente en la respuesta de la tarjeta se descartará en lugar de simplemente establecerse en 0). Finalmente, el valor se convierte de binario a un número decimal y se muestra al usuario. A continuación se proporciona un ejemplo truncado:
El proceso del 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 16 ) o el formato de plantilla de mensaje de respuesta más complejo 2 (id. 77 16 ) que divide los datos ARQC en valores TLV separados que deben reensamblarse secuencialmente para que coincidan con los del formato 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 al seleccionar responder e ingresar un número de 00000000 se generará de hecho una respuesta de identificación válida. Sin embargo, lo que es más preocupante es que si un banco emite una solicitud de respuesta, al usar el modo de firma con el mismo número y un importe de 0,00 ¤ se generará nuevamente un resultado válido, lo que crea la posibilidad de que un estafador ordene a un cliente que realice una respuesta de desafío de "prueba" por un importe de 0,00 ¤ que, de hecho, el estafador usará para verificar un comando de respuesta con el fin de agregarse como beneficiario en la cuenta de la víctima; estos ataques se pudieron llevar a cabo contra bancos que usaban dispositivos de autenticación fuertes que no cancelaban actividades hasta que se ingresaba 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, que implementaban la funcionalidad de separación de dominio segura que cumple con la nota de aplicación de MasterCard de octubre de 2010. [ aclaración necesaria ] De manera similar, por supuesto; un banco que implementa el comando de identificación hace posible 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 en la tarjeta que en otras transacciones EMV. Por lo tanto, al igual que en un cajero automático o terminal POS, al ingresar un PIN incorrecto tres veces seguidas en un lector CAP, se bloqueará la tarjeta.
La especificación CAP original fue diseñada 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 separada para las transacciones CAP. Las dos aplicaciones pueden compartir ciertos datos, como el PIN, mientras que otros datos no se comparten en casos en los que solo es aplicable a una aplicación (es decir, datos de gestión de riesgo de terminal para EMV) o ventajas de tenerlos separados (es decir, contador de transacciones, de modo que las transacciones EMV y CAP incrementen contadores separados que se puedan verificar con mayor precisión). El lector también lleva datos específicos de la implementación, algunos de los cuales pueden ser anulados por valores en 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 se ajustan a 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 utilizar en un lector de tarjetas emitido por un banco diferente. [ cita requerida ]
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, destacando una serie de vulnerabilidades en el protocolo y la variante británica tanto de lectores como de tarjetas. Se encontraron numerosas debilidades. Los investigadores de la Universidad de Radboud encontraron una vulnerabilidad en el ABN AMRO e.dentifier2 holandés, que permite a un atacante ordenar a un lector conectado por USB que firme transacciones maliciosas sin la aprobación del usuario. [5]
La mayoría de los principales bancos de Bélgica (incluidos Belfius , BNP Paribas Fortis , ING y KBC Bank ) ofrecen un lector de tarjetas de este tipo. Se utiliza para dos propósitos principales:
El dispositivo está equipado con un puerto USB opcional, estas dos operaciones se pueden utilizar sin conectar el cable a una computadora.
Era el método más utilizado para pagar en línea, ofreciendo un método de verificación similar al PIN en los POS. Desde la amplia aceptación de los teléfonos inteligentes, los bancos ofrecen una alternativa utilizando una aplicación local en el teléfono, utilizando un código QR para escanear o utilizando la popular aplicación Itsme
El dispositivo también es compatible con la tarjeta de identificación electrónica belga para acceder a servicios gubernamentales como declaración de impuestos, información sobre seguros médicos, desempleo, etc. Estos servicios también están generalmente disponibles a través de Itsme.
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 su uso ú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 el uso de este software para operaciones financieras reales puede conllevar algunos riesgos. De hecho, la ventaja de utilizar un lector independiente es aislar la tarjeta bancaria del malware que pueda estar alojado en el PC. Al utilizarlo en un lector no seguro se corre el riesgo de que un keylogger 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 realizar su propia transacción.