Autenticar transacciones, no a las personas

Buenas,

Me declaro seguidor de Schneier por múltiples razones. Una de las muchas es que este hombre es bastante claro cuando emite opinión, y tiene la poco común habilidad de generar una conversación entre 300 personas con un post de una línea. Algo que muchos ya quisiéramos para nosotros :)

Cualquiera que siga a este señor se habrá dado cuenta de que lleva años (al menos desde 2005) haciendo críticas constructivas sobre la poca utilidad de la doble autenticación en banca en línea y en general, en cualquier actividad en Internet que requiera autenticación fuerte. También es frecuente ver a Bruce criticando que la seguridad se acabe delegando en los usuarios, porque al igual que para cierto segmento de usuarios con conocimiento suficiente y con un mínimo perfil tecnológico los mecanismos para advertir el fraude (alertas al móvil, correos avisando de transacciones, etc.) funcionan francamente bien, para el resto de los mortales no sucede igual. Basta con no tener informado el móvil o no tener acceso frecuente al correo para que estos mecanismos pierdan su utilidad.

La doble autenticación ha sido atacada ya en numerosas ocasiones, unas veces de manera sofisticada (con ataques man in the middle) y otras de manera cutre, pero efectiva (troyanizando una máquina y forzando a que, por ejemplo, el usuario introduzca todas las cifras de su tarjeta de coordenadas). En el mismo ensayo que cité antes, Schneier vaticinó que los primeros adoptantes experimentarían mejoras en los niveles de fraude consumado, ya que los atacantes irían a por los blancos más fáciles, pero que al final los atacantes irían ampliando sus miras. No se equivocaba.

Buscar posibles soluciones para paliar los problemas que supone la creciente sofisticación del malware, y que por consiguiente los sistemas de doble autenticación sean cada vez el objetivo de los ataques, puede parecer imposible, pero no lo es. Una manera de abordar el problema ya la documentamos recientemente, empleando autenticadores EMV. Pero hay una manera mucho más sencilla y económica de dificultar al máximo los quebrantos en entornos financieros en línea: los mTANs para autenticar transacciones.

La última experiencia que tengo a nivel usuario con mTANs (Mobile Transaction Authentication Number) es la que ha implementado Openbank cuando se invocan transferencias a cuentas que no son propias. Una reacción comprensible y normal, y que yo personalmente alabo, ya que Openbank no usa autenticación de doble factor, y la única protección que ofrece a la clave de operaciones es solicitar fragmentos de la misma, lo cual, ante un troyano, hace sonar las sirenas: son 8 posiciones, y tarde o temprano, se repiten. Este método de confirmación sólo funciona ya para traspasos entre cuentas propias, es decir, para autorizar transacciones que no salen de la entidad ni del ámbito del usuario.

La idea de un mTAN es muy sencilla, y muy efectiva. Se trata de generar un identificador único para cada transacción en particular que es enviado al usuario por un canal alternativo, usualmente, un mensaje SMS. La ventaja de un mTAN es que está asociado a un movimiento concreto de una manera íntima, siendo usualmente generado por la infraestructura de banca a distancia teniendo en consideración cuenta origen, cuenta destino, importe, divisa, tipo de operación, fecha y hora. En cristiano: un mTAN es un código de autorización que sólo es válido para una transacción que esté definida por esos parámetros.

Para entendernos y explicarlo de una manera muy sencilla, imaginaos que queremos transferir 100 euros de nuestra cuenta del banco 1 a nuestra cuenta del banco 2. La aplicación de banca a distancia generará un código teniendo en cuenta todos los parámetros, y asociará a la transacción un código que es enviado al usuario por SMS (por ejemplo, Ej54Ke8732w). El usuario tiene que usar ese número y volverlo a introducir en la aplicación de banca a distancia como única manera de autenticar la transacción. En caso de no introducirlo, o introducirlo de una manera incorrecta, la transacción simple y llanamente, no se realizará.

¿Y cuál es la ventaja? Los troyanos financieros están diseñados para para atacar la parte más débil de la cadena, y esa suele ser el usuario. El uso de mTANS cubre perfectamente este escenario, ya que si un troyano interceptase la mTAN y tratase de modificarla, la transacción quedaría anulada. Quizás logren tu usuario y tu contraseña, y puedan ver si tienes pasivo o no, cuáles son tus sitios favoritos para deslizar la tarjeta o cuáles son tus preferencias como inversor, pero a priori no pueden robarte el dinero. Otro tema es que con la información sustraída se presenten en la puerta de tu casa y te extorsionen en vivo y en directo, como ya ha sucedido alguna vez. Afortunadamente, estos escenarios no son los frecuentes, y no deberíamos temer por ellos.

La doble autenticación, pese a no representar por sí misma la solución a los problemas, no debe ser menospreciada, ya que puede ser parte de un sistema donde, por ejemplo, usemos la tarjeta de coordenadas en autenticación de la persona y los mTANs para autenticar las transacciones. Es igualmente factible emplear mTANs para ambos procesos. No obstante, que nadie piense que los mTANs son la panacea. Hay casos documentados donde se vulnera el sistema atacando la fuente receptora de los mTANs, los teléfonos (SIM swap fraud), y sobre el tapete la posibilidad de comprometer el sistema de generación y validación de los mTANs es factible. Extremamente complicado, pero es una posibilidad. Dicho esto, remarcar que la autenticación de transacciones por mTANs no es un método invencible, pero desde luego, a día de hoy, son mucho más efectivos que limitarse a autenticar a los usuarios.

Explicado el mecanismo, sus pros y sus contras, debo forzosamente coincidir con Schneier: el camino a seguir es autenticar transacciones y no a las personas. Creo igualmente conveniente que es hora de dejar de confiar ciegamente en los dobles factores de autenticación como la solución a nuestros males. El crimen organizado no explota vulnerabilidades en la autenticación, con lo que la doble autenticación no parece la solución al problema. Adicionalmente, tal y como sostiene Schneier, el hecho de concentrar esfuerzos para autenticar usuarios y no a las transacciones provoca que al final las estrategias de defensa se basen en defenderse de tácticas criminales en concreto y no de la actividad criminal en sí. No creo que sea el camino ni para atajar el problema, ni para reducir su impacto.

La época donde la doble autenticación frenaba a los amigos de lo ajeno hace tiempo que ha terminado, y mi previsión es que durante 2010 notaremos incrementos en los ataques contra estros sistemas. No creo que se produzca un alza muy notoria, ya que siguen existiendo blancos fáciles que confían en la autenticación simple, y además, desarrollar esquemas de ataque complejos no es algo que se logre de un día para otro, pero creo que veremos desarrollarse a la industria del malware en este sentido. El tiempo me dará o quitará la razón :)

Un saludo,

Doble autenticación en banca a distancia basada en EMV

Hola,

Hace algún tiempo que quería someter a prueba a mi lector EMV de autenticación/autorización financiera. Es la primera vez que dispongo de un aparato de estas características, con lo que era menester dedicarle un ratito para ver cómo funciona, y poder decidir por mí mismo qué nivel de seguridad me ofrece el dispositivo.

Autenticador/Autorizador financiero EMV

autenticador autorizador abn

Esto que veis en pantalla es un autenticador/autorizador financiero basado en EMV y su correspondiente cable de conexión USB. Abajo aparece mi tarjeta financiera para banca a distancia, y en rojo está marcado el chip EMV.

Se trata del autenticador/autorizador e.dentifier2 con el que ABN AMRO provee a sus clientes. De manera contraria a lo que se puede pensar, el uso de este aparato para operar con la banca en línea no implica costes adicionales sobre la tarifa bancaria que hay que satisfacer (en mi caso, si no mal recuerdo, unos 32 euros anuales). Por lo que he podido ver, la mayoría de entidades en Holanda opera de una manera similar, en la que el cliente satisface una cantidad anual a modo de tarifa plana que suele incluir los costes de mantenimiento de los productos financieros básicos (cuenta a la vista y cuentas de ahorro), las operaciones frecuentes (transferencias nacionales e internacionales, OTEs, disposición de efectivo en autoservicios financieros y compras en terminales de comercio), la expedición y mantenimiento de al menos dos tarjetas financieras (EMV débito y crédito EMV), así como el uso del autenticador financiero para banca en línea.

El dispositivo tiene dos modos de operación: conectado a un sistema operativo vía USB, o bien uso autónomo, sin conexión alguna. En ambos casos es requisito para la operación que la tarjeta asociada a la banca en línea esté insertada en la ranura, ya que el alma mater del asunto es poder autenticar y autorizar el acceso y las operaciones mediante EMV.

autenticador y tarjeta financiera

Disculpad la calidad de la fotografía, pero la holografía de la tarjeta y el reflejo de la pantalla del dispositivo no son los mejores aliados de la nitidez. El funcionamiento es ligeramente distinto en cada caso. En el uso autónomo, el aparato puede generar una credencial de un sólo uso para la autenticación, así como OTPs para transaccionalidad (transferencias, órdenes de pago, etc.) mediante la introducción del PIN en el teclado numérico. El autenticador financiero está casado a nuestra cuenta, y a su vez, con la tarjeta financiera, con lo que si la introducción del PIN es correcta, el autenticador considerará que la tarjeta legítima está en la ranura, y que la persona que ha introducido el PIN es el propietario de la misma. En este modo de operación el número de cuenta, el número de tarjeta y las OTPs son introducidas por el usurio en los formularios HTTPS.

Cuando el autenticador está conectado al sistema operativo vía USB, en vez de suministrar una clave OTP, el dispositivo lanza las peticiones directamente contra la aplicación de banca a distancia. El usuario no tiene que introducir dato alguno en los formularios HTTPS. Este modo de operación requiere la instalación de un software cliente que permite establecer la conversación entre el servidor de aplicaciones y la máquina del usuario. El software contiene, además de los componentes locales, una extensión específica para Firefox, y permite operar con el resto de los navegadores sin problema alguno. En esta modalidad, el usuario se autentica únicamente mediante la introducción del PIN en el teclado numérico, siendo el software cliente el que se comunica, en función de la operación procesada en el lector EMV, con el servidor de aplicaciones. Las transacciones se confirman igualmente con la introducción del PIN en el teclado del dispositivo.

Bloques de datos EMV

La gran ventaja que tiene EMV es que dota al medio de pago y a los lectores de capacidades criptográficas. Cuando introducimos el PIN en el dispositivo, éste consulta al chip EMV y realiza la verificación criptográfica del mismo. Es decir, el PIN no viaja en ningún caso y se valida en el propio dispositivo, siendo ésta su principal ventaja, ya que esto reduce drásticamente (prácticamente imposibilita) la captura ilegítima del dato más importante de una tarjeta: el PIN.

Una vez que el aparato dispone de la verificación positiva del PIN por parte del chip EMV, ya sólo es cuestión de enviar peticiones que están validadas de antemano. Para dotar de más seguridad a las transacciones, es frecuente que además del uso de un protocolo cifrado en la comunicación (TLSv1, en este caso), el bloque de datos esté igualmente cifrado por la aplicación de la criptografía EMV. Es decir, además de emplear un canal cifrado para la comunicación cliente-servidor, el propio paquete de datos está cifrado con la criptografía EMV. Para que nos entendamos, y perdonad por la simpleza del ejemplo, es como si eviásemos por un canal cifrado (SSH) un archivo también cifrado con algún algoritmo reversible, como por ejemplo, un fichero ZIP con clave, con lo que en caso de que el canal quedase comprometido, siempre queda la protección del cifrado intrínseco del fichero (que no es que sea brillante en el caso de un ZIP con clave, todo sea dicho)

Analizando el tráfico

Sobre el tapete el montaje es interesante, ya que permite construir una vía de comunicación cifrada entre cliente y servidor por el cual circularán los datos necesarios para poder operar en línea. Veamos cómo funciona el túnel en la realidad.

Basta con hacer una captura de tráfico para ver que las comunicaciones, como no podía ser de otro modo, son bidireccionales, siendo el puerto a la escucha en el lado del cliente el 10086, y el puerto de destino en el servidor de aplicaciones 443 (HTTPS)

Las comunicaciones desde el lado del cliente con dirección al servidor de aplicaciones son TLSv1 (con datos de aplicación cifrados siendo el puerto origen 10086 y el destino el 443) y las recibidas desde el servidor de aplicaciones son también TLSv1, con origen en 443 y destino 10086. Adjunto dos capturas con parte de la conversación TLSv1 en ambos sentidos, donde se puede apreciar el bloque de datos cifrado:

cliente servidor

servidor cliente

A poco que sigamos el flujo TCP de la conversación, veremos rápidamente que el cifrado hace que los datos intercambiados sean un completo galimatías:

flujo tcp

Vectores de ataque

Comprometer este sistema para el robo de credenciales y la operación ilegítima en banca a distancia se torna en exceso complicado. Nada en el mundo de la seguridad y la tecnología es 100% seguro, y por tanto, no debemos caer en el error de considerar que la doble autenticación criptográfica EMV es la panacea. Lo que no parece inadecuado es catalogar al método como muy interesante en cuanto a su seguridad, siendo, con mucha probabilidad, de los montajes más seguros que existen para operar en banca a distancia en la actualidad.

Los atacantes, aunque también dirigen sus esfuerzos a la doble autenticación (hemos hablado del tema en este blog, y recientemente el maestro Schneier hizo una reflexión al respecto), normalmente atacan primero los sistemas más débiles, como aquellos en los que la autenticación y la autorización de transacciones se realiza mediante usuario, clave y clave de operaciones (van quedando menos, pero quedan), o aquellos en las que se emplea una tarjeta de coordenadas como factor adicional. Habida cuenta de la complejidad del sistema EMV, en condiciones normales, los atacantes dirigirán sus esfuerzos a otros sistemas en los que puedan tener más éxito, y por tanto, rentabilizar sus resultados.

El método más simple para poder romper el montaje es tener en posesión PIN, la tarjeta y el lector. Es complejo por tanto que se de este escenario, pero no es descabellado. La utilización de EMV reduce aún más esta posibilidad, ya que la tarjeta debe ser original (la clonación de la banda no es suficiente). En caso de que un troyano financiero desviase el tráfico a su conveniencia en una sesión man-in-the-middle, los datos principales de la transacción (importe, cuenta origen y destino) están cifrados por el canal y por la frima del bloque de datos propia de EMV, con lo que en el hipotético caso de fuera capaz de detener el paquete, descifrarlo, modificarlo y luego reempaquetar respetando las firmas criptográficas (lo cual ya es harto complejo), todavía queda un último mecanismo de seguridad, ya que antes de procesarla, los datos de la transacción se envían al lector, y requieren la intervención del usuario para confirmar los datos pulsando la tecla OK del lector EMV, con lo que la modificación de la cuenta o el importe se haría notorio con sólo leer los contenidos de la pantalla.

Otro vector que no discutiré, ya que no está bajo el control de usuario, es el compromiso de la aplicación de banca a distancia. Si un atacante, una vez descifrado el bloque de datos en el servidor, es capaz de reformatear el bloque de datos introduciendo sus cuentas e importes desde la propia aplicación, poco o nada podemos hacer. Este escenario es complicado, ya que los servidores de banca suelen estar sujetos a una monitorización exhaustiva que debería poder detectar a tiempo estos ataques. No obstante, es una posibilidad, y en este caso los atacantes internos son los que están en posición ventajosa.

Ventajas

La ventaja más evidente es la seguridad del montaje, ya que reduce al mínimo las posibilidades de sufrir quebrantos a causa de ataques. En el modo no conectado estas condiciones de operación segura decrecen, ya que el usuario tiene que introducir su número de cuenta, de tarjeta y las respuestas OTP que le da el dispositivo en formularios HTTPS, lo cual abre la veda para troyanos que capturen las credenciales antes de ser sometidas al cifrado del canal, y se desvíe el tráfico a sesiones man-in-the-middle ilegítimas.

A nivel negocio, creo que estas soluciones colman las expectativas de los clientes con un perfil tecnológico avanzado, lo que abre las vías a futuras oportunidades de negocio en segmentos cualificados donde el conocimiento de la tecnología no sea un obstáculo.

Desventajas

La primera desventaja que es obvia y manifiesta, desde el punto de vista del cliente, es la necesidad de portar el dispositivo. Es ligero, pero no es precisamente algo que esté pensado para llevarlo en la cartera. Tampoco es posible usarlo conectado cuando se opera en banca a distancia desde un móvil o PDA, lo que fuerza al usuario a usarlo en la modalidad no conectado, con la consiguiente necesidad de introduccir en formularios HTTPS de datos.

Para las entidades la desventaja quizás derive de la mezcla del coste y el impacto que suele tener complicarle las cosas al cliente para usar un canal ya de por sí complejo para muchos. Aunque el uso del aparato es simple y está perfectamente documentado, todos sabemos que si ya le cuesta a muchos clientes usar una tarjeta de coordenadas, mejor no pensar en lo que les puede suponer usar un lector EMV portátil. Entiendo que para las entidades el uso de estos métodos dependerá del resultado de balancear el coste/beneficio con el perfil del cliente al que va dirigido. Otro eterno tema de discusión que complica bastante la cosas estriba en decidir si repercutir al cliente el coste (aumentando las comisiones, o generando una nueva comisión en concepto de uso de la tecnología) o asumirlo desde la cuenta de resultados sin incrementar el precio de los servicios que se estén cobrando (algo que no es frecuente, sobre todo existiendo métodos para operar en banca a distancia con menor coste operativo)

Por otro lado, la tasa de implantación de EMV en la eurozona es muy dispar, según se puede comprobar en un reciente informe de ENISA sobre el fraude en cajeros automáticos. En Holanda es del 100%, mientras que por ejemplo, en España es del 71%. Este dato no invita a pensar que veamos en el corto plazo este tipo de montajes en países con tasas inferiores al 80%, como Grecia, Bulgaria, Italia, Hungría, Polonia, Letonia, Lituania o Islandia, además de la ya mencionada nuestra querida patria del flamenco, la paella y la siesta :), quizás con la excepción de entidades que tradicionalmente se han mostrado como pioneras en la adopción y uso de la tecnología, aunque en estos tiempos que corren tampoco creo que encontremos el caldo de cultivo ideal para diseminar a gran escala estas soluciones. Además no perdamos de vista que el DNI electrónico sirve, más que de sobra, para realizar montajes criptográficos serios de autenticación y autorización en banca a distancia, con lo que no es nada improbable que los moviemientos vayan en esta dirección.

Si algún lector utiliza tecnologías similares en banca a distancia (tokens, otros mecanismos EMV, etc.), que no dude en contarnos su experiencia.

Un saludo,