CAMPO DE LA INVENCIÓN

La presente invención se engloba dentro de los sistemas de autenticación entre dos partes para realizar una operación que se lleva a cabo mediante un diálogo no presencial.

ANTECEDENTES DE LA INVENCIÓN

Actualmente hay muchos sistemas de autenticación que hacen uso de los teléfonos inteligentes (smartphones) como dispositivo que soporta la aplicación que debe ser utilizada por una de las partes que se autentican con dicho sistema. Estos smartphones están siendo actualmente el objetivo principal de nuevas técnicas de fraude de suplantación de personalidad, como el Phishing, Pharming y Man in the Middle, que usan técnicas de ingeniería social, y un variado malware (keyloggers, stealers, ZeuS Man in the Mobile -MitMo-, SpyEye, etc) que también afectan de forma importante a la seguridad de las aplicaciones de autenticación que se ejecutan sobre estos teléfonos inteligentes. Los delincuentes, aplicando estas técnicas llegan incluso a poder hacerse con una copia de la aplicación que se está utilizando para autenticarse de forma que, posteriormente, suplantando la personalidad del propietario del Smartphone puede cometer el fraude.

En recientes estudios se observa que los sistemas de seguridad en uso no sólo no consiguen la disminución de fraudes en internet por la suplantación de personalidad, sino que el número de fraudes que se cometen cada año va aumentando.

Según últimas informaciones, los móviles se están confirmando como el objetivo favorito de los 'hackers'. Entre enero y junio de 201 1 se produjo un aumento del 'malware' en móviles del 273% respecto al mismo periodo de 2010, mientras que el crecimiento global de nuevas amenazas fue del 16%. Estas cifras se desprenden del último informe de G Data Security Labs, que asegura que el crecimiento de los terminales móviles y sus carencias en materia de seguridad los convierte en los nuevos objetivos favoritos. "Con el 'malware' para móviles, los cibercriminales han descubierto un nuevo modelo de negocio", ha explicado el responsable de G Data Security Labs, Ralf Benzmüller. "Desafortunadamente, podemos decir que estamos asistiendo al nacimiento de un nuevo y potencial mente muy lucrativo nicho de mercado para los cibercriminales y esperamos un continuo crecimiento del "malware' mobile' de aquí a finales de año", ha añadido.

Entre las técnicas usadas por los delincuentes para cometer los fraudes destacan:

Los keylogger.

Es un tipo de software o un dispositivo hardware específico que una vez instalado en un PC o dispositivo similar, se encarga de registrar las pulsaciones que se realizan en el teclado para posteriormente memorizarlas en un fichero o enviarlas a través de internet. Suele usarse como malware del tipo daemon, permitiendo que otros usuarios tengan acceso a contraseñas importantes, como los números de una tarjeta de crédito, u otro tipo de información privada que se quiera obtener. Se dice que se puede utilizar un teclado virtual para evitar esto, ya que sólo requiere clics del ratón. Sin embargo, las aplicaciones más nuevas también registran screenshots (capturas de pantalla) al realizarse un click, que anulan la seguridad de esta medida.

El Phishing:

Ocurre cuando en un diálogo no presencial, generalmente entre una empresa y un cliente, el delincuente suplanta la personalidad de la empresa para que el cliente piense que está hablando con su empresa y así el cliente, pensando que está hablando con su empresa, le entregue los datos con los que se autentica frente a dicha empresa. Posteriormente el delincuente usa estos datos para dialogar con la empresa suplantando al cliente y así poder cometer el fraude.

El Man In The Middle (MITM)

Ocurre cuando el delincuente, haciendo uso de las técnicas adecuadas, consigue interceptar y modificar cuando lo considera oportuno cualquiera de los mensajes que están intercambiándose, generalmente una empresa y su cliente, a lo largo de un diálogo no presencial.

Zeus Mitmo: Man in the Mobile

Tiene su aplicación en aquellos casos en los que la solución de autenticación se basa en el envío de un SMS al móvil del cliente para informarle de los datos que la empresa ha recibido del cliente en su solicitud de ejecución de operación y, también para que el cliente conozca la clave de un único uso (OTP, del inglés One Time Password) que el cliente debe usar para confirmar la operación. Este es el caso de muchas entidades bancarias que, aparte de la clave de firma o tarjeta de coordenadas necesaria para autorizar una transferencia, hacen uso de una segunda fase de autenticación. Ésta suele realizarse mediante el envío de un código a través de SMS al teléfono móvil del cliente, que deberá introducir en la página del banco para realizar la transferencia satisfactoriamente.

El fraude se comete cuando el delincuente, por medio de un troyano instalado en el móvil del cliente consigue interceptar el SMS recibido y enviarlo a su teléfono. Así. si por medio de un MITM o cualquier otra combinación de técnicas ha conseguido suplantar al cliente y enviar a la empresa una solicitud de operación en su beneficio, sucederá que el cliente no va a saberlo y, además, en el SMS interceptado le va a llegar al delincuente la clave OTP que va a necesitar para confirmar dicha operación.

Se puede afirmar que cada vez habrá más métodos para la interceptación de

SMS.

Como ya se ha comentado, la presencia de los teléfonos inteligentes o smartphones, con el aumento de la conectividad y la disponibilidad de la información, están provocando que los desarrolladores de códigos maliciosos enfoquen sus amenazas en los dispositivos móviles. Así, una parte importante del nuevo malware tiene como objetivo el Smartphone y así podemos encontrarnos con troyanos que son capaces de:

detectar el tecleo de un PIN y enviarlo a un delincuente;

llegar a enviar a un tercero toda una aplicación con sus ficheros;

interceptar los SMS y enviarlos al móvil de un delincuente.

Este hecho hace pensar que, a partir de ahora, todos los métodos de autenticación que actualmente utilizan un smartphone, por ejemplo, con algoritmos de generación de OTP o recepción de OTP en un SMS, son susceptibles de ser vulnerados y deben ser actualizados para evitar estas nuevas técnicas de fraude.

Actualmente existen ya en el mercado una gran variedad de sistemas de autenticación, que utilizan distintos medios y procedimientos, para lograr la autenticación de operaciones entre dos partes que dialogan de una forma no presencial.

Así, existen sistemas que usan una o dos claves OTP. Pero en este tipo de sistemas, si un intruso, por medio de reiterados intentos, llegar a teclear la OTP correcta puede llegar a vulnerar el sistema. Igualmente, un usuario de este sistema puede sufrir un ataque de Phishing/Pharming en tiempo real, en cuyo caso la operación fraudulenta puede ser completada ya que si un intruso se hace con la primera clave OTP y la usa antes de que caduque su validez, tal intruso podrá conectarse a la empresa haciéndose pasar por el cliente.

También existen sistemas que usan dos claves OTP y una fija. En este caso un intruso puede hacerse con la clave fija de un cliente por medio de un Phishing/Pharming previo. Y en tal caso, puede llevar a cabo un ataque de denegación de servicio al poder pedir de forma reiterada su acceso al sistema ya que con ello está obligando al sistema de la empresa a que le conteste con el envío de una OTP con lo que esto supone en cuanto a consumo de recursos.

También existen sistemas que usan tres claves OTP.

Por su parte, los sistemas que usan la firma electrónica también son vulnerables. Así, por ejemplo, una página cargada bajo SSL cuyo certificado digital provenga de una entidad de confianza (que el navegador cargue sin emitir errores) y en la que aparezca el famoso 'candado' no puede ser considerada segura. (Fraude online, con firma digital y SSL, en el que el usuario firma digitalmente a ciegas el hash SHA-256 de un fichero cuyo contenido no controla. Técnicamente, al firmar el resumen unívoco del fichero con un certificado reconocido, lo firmado adquiere validez legal; junio 2009, Security By Default).

Otros sistemas usan, como único medio de autenticación, la tarjeta de coordenadas. Pero en estos sistemas un usuario atacado por un phishing, puede proporcionar las claves almacenadas en su tarjeta de coordenadas. En este caso un troyano puede estar grabando la información que se visualiza en la pantalla o la que el usuario teclea. O también por medio de un phishing pueden hacerse con una o más claves de la tarjeta y posteriormente, a base de reiterados intentos de operar, pueden llegar a conseguir que la clave solicitada por el banco coincida con la que tiene el delincuente y así cometer el fraude.

La limitación más importante del uso de la tarjeta de coordenadas (claves) es el bajo número de valores que puede aportar obligando a la reutilización de estas claves. Este es el origen de su mayor vulnerabilidad.

También el servicio de confirmación de una operación por medio de SMS plantea problemas. Así, es posible que el delincuente después de robar la clave fija de acceso de un cliente al portal de su empresa, entre al portal y acceda al perfil del cliente para modificar su número de teléfono móvil poniendo el suyo; o también es posible que consiga interceptar sus SMS, por lo que el fraude es posible.

DESCRIPCIÓN DE LA INVENCIÓN

La invención se refiere a un sistema de autenticación mutua de una operación según la reivindicación 1 . Realizaciones preferidas del sistema se definen en las reivindicaciones dependientes.

La invención se refiere a un sistema de autenticación mutua de una operación entre una primera parte y una segunda parte basado en un diálogo durante el que dichas primera y segunda partes intercambian un número predeterminado de claves de un solo uso, en el que:

dichas primera y segunda partes están biunívocamente identificadas entre ellas mediante un primer identificador y un segundo identificador;

dichas primera y segunda partes están en comunicación por medio de dos o más canales de comunicación diferentes;

- dicha primera parte dispone de un primer dispositivo, un segundo dispositivo en el que reside una primera aplicación de autenticación y un tercer dispositivo;

dicha segunda parte dispone de un servidor central de autenticación en el que reside una segunda aplicación de autenticación asociada a dicha primera aplicación de autenticación;

- teniendo cada uno de los segundo y tercer dispositivos unas primera y segunda tablas de claves, respectivamente, y teniendo el servidor central de autenticación una tercera tabla de claves asociada, con una correspondencia biunívoca, al primer identificador de la primera parte;

en el que:

- dicha tercera tabla tiene un número de filas preestablecido e igual al número de filas de las primera y segunda tablas,

- dicha tercera tabla contiene en cada fila al menos todas las claves de un solo uso que se van a intercambiar y utilizar en el sistema durante la operación, siendo dicha tercera tabla la única que contiene todas las claves que van a ser intercambiadas y usadas ;

- dichas primera y segundas tablas tienen cada una de ellas una parte de todas las claves de un solo uso que se van a intercambiar y utilizar en el sistema durante la operación de autenticación, teniendo entre dichas primera y segunda tablas todas las claves, siempre en una misma fila; en el que:

la primera parte obtiene una primera clave a usar en la operación mediante su segundo dispositivo;

la primera parte envía mediante su primer dispositivo por un primer canal de comunicación al servidor central de autenticación de la segunda parte esta primera clave junto con su primer identificador y junto con unos datos de dicha operación; el servidor central de autenticación verifica que dicha primera clave recibida coincide con la contenida en la fila en uso de su tercera tabla asociada al primer identificador, y si es correcta envía por un segundo canal de comunicación al primer o segundo dispositivos de la primera parte un mensaje, encabezado por el segundo identificador, que contiene una segunda clave, al menos una tercera clave y datos de la operación, cuyo mensaje está encriptado con una quinta clave, estando dichas segunda, tercera y quinta claves situadas en la misma fila que dicha primera clave en la tercera tabla;

la primera parte recibe el mensaje encriptado, verifica que el segundo identificador es correcto, y el segundo dispositivo lo desencripta con la quinta clave contenida en la fila a usar de su primera tabla y verifica que la segunda clave recibida coincide con la de la misma fila de su primera tabla; si dicha segunda clave es correcta, la segunda parte queda autenticada frente a la primera parte y el segundo dispositivo presenta a la primera parte los datos de la operación recibidos en dicho mensaje para que los verifique; si la primera parte da su conformidad a estos datos el segundo dispositivo proporciona a la primera parte dicha al menos tercera clave recibida en dicho mensaje;

mediante la segunda tabla contenida en su tercer dispositivo la primera parte obtiene al menos una cuarta clave localizada en la misma fila que dicha al menos tercera clave de su segunda tabla;

la primera parte envía desde su primer dispositivo al servidor central de autenticación de la segunda parte dicha al menos cuarta clave junto con el primer identificador y la primera clave; la segunda parte verifica que dicha al menos cuarta clave recibida coincide con la contenida en la fila en uso de su tercera tabla; y si es correcta el servidor central de autenticación envía una confirmación de operación realizada con éxito al primer dispositivo.

Mediante el sistema de autenticación que se acaba de definir se consigue invalidar cualquiera de las técnicas de fraude mencionadas anteriormente, aún cuando una de las partes utilice un teléfono móvil o smartphone para soportar la primera aplicación de autenticación ya que:

Utiliza claves de un único uso (OTP) de forma que si se captan no sirven para ser reutilizadas.

· La autenticación es mutua y la primera parte nunca entrega su clave de autenticación final a la segunda parte antes de que ésta se haya autenticado.

Los mensajes intercambiados en el diálogo viajan por un canal de comunicación diferente al usado para recibir el mensaje origen de su contenido de forma que se dificulta la interceptación y seguimiento de todos los mensajes que componen el diálogo.

La autenticación y autorización de una operación requiere de la primera parte una confirmación de los datos que la segunda parte ha recibido en su solicitud de ejecución de operación, de forma que la primera parte conoce exactamente qué es lo que está autorizando.

· Los mensajes que la segunda parte envía a la primera parte viajan encriptados con un código de un solo uso, de forma que aunque un delincuente lo intercepte no puede podrá interpretarlo ni manipularlo.

Los mensajes que la segunda parte envía a la primera parte van autenticados con una clave de un solo uso (OTP), de forma que no pueden haber sido enviados por cualquier otra persona o parte que suplante a la que debiera ser su verdadero emisor.

El segundo dispositivo -que preferiblemente es un teléfono móvil (smartphone) o similar- no dispone de todas las claves que se intercambian en el proceso de autenticación, siendo necesario para ello disponer del tercer dispositivo - preferiblemente una tarjeta de claves- que lo complementa y que es quien proporciona la/s clave/s que le faltan a ese segundo dispositivo. Este tercer dispositivo no dispone de comunicación con ningún otro dispositivo que pueda facilitar la entrada de malware y el acceso a su contenido. De esta forma, aunque un delincuente por medio de malware introducido en el segundo dispositivo consiga copiar la aplicación de autenticación, no le servirá de nada pues no podrá finalizar ninguna operación de autenticación al carecer de las claves que residen en el tercer dispositivo.

En el sistema de la invención preferiblemente se entiende por parte a cada uno de los entes (personas o máquinas) que dialogan entre sí por su interés en un mismo negocio. El servidor central de autenticación de la segunda parte preferiblemente contiene tantas terceras tablas como diferentes primeras partes quieran realizar operaciones de autenticación con la segunda parte, siendo cada tercera tabla distinta para cada una de estas primeras partes.

Preferiblemente la segunda aplicación de autenticación residente en dicho servidor central de autenticación tiene un contador de filas indicativo de cuál es la última fila de la tercera tabla que ha sido usada, y en el que dicho contador de filas es incrementado en una unidad cada vez que el servidor central de autenticación envíe al segundo dispositivo de la primera parte el mensaje encriptado originado como respuesta a la aceptación como válida de la primera clave recibida de la primera parte.

De forma similar, la primera aplicación de autenticación residente en dicho segundo dispositivo preferiblemente tiene un contador de filas indicativo de cuál es la última fila de la primera tabla que ha sido usada, y en el que dicho contador de filas es incrementado en una unidad cada vez que la primera aplicación de autenticación acepte como auténtico dicho mensaje encriptado recibido de la segunda parte.

Durante una operación puede darse un problema en el que la segunda parte envíe a la primera parte dicho mensaje encriptado y que, por cualquier circunstancia, no llegue a ser procesado correctamente por la aplicación de autenticación del segundo dispositivo. En este caso la primera tabla de la primera parte queda desincronizada con la tercera tabla de la segunda parte en cuanto a cuál ha sido la última fila de claves usada. Esto es debido a que el contador de filas usadas de la tercera tabla, al enviar el servidor central de autenticación el mensaje encriptado, es incrementado en una unidad mientras que la aplicación de autenticación del segundo dispositivo, al no procesar correctamente dicho mensaje encriptado no incrementa su contador de filas usadas en la primera tabla. Por este motivo sucede que para la siguiente operación de autenticación la segunda Parte espera recibir de la primera la primera clave de la siguiente fila, mientras que la aplicación de autenticación del segundo dispositivo, al no haber incrementado su contador de filas usadas de la primera tabla TA1 , está indicando a la primera parte que utilice la primera clave V1 de la fila anterior.

Para solucionar este problema el sistema objeto de la invención, en una realización preferida incluye un proceso de sincronización para sincronizar los contadores de fila de dichas primera y tercera tablas; este proceso de sincronización es ejecutable en respuesta a que el servidor central de autenticación verifique que la primera parte solicita una operación de autenticación utilizando un valor de la primera clave correspondiente a la fila anterior a la indicada por el contador de filas usadas de la tercera tabla.

Preferiblemente dicho número predeterminado de claves de un solo uso (o claves OTP) intercambiadas entre dichas primera y segunda partes es al menos cuatro, usándose, además, la quinta clave usada para encriptación.

Preferiblemente el primer dispositivo de la primera parte es un PC, aunque también podría ser un teléfono móvil, cajero automático, Terminal Punto de Venta, o cualquier otro dispositivo con capacidades equivalentes, que pueda solicitar y realizar operaciones de forma no presencial que, por ello, requieran de una autenticación mutua de las partes que intervienen.

El servidor central de autenticación de la segunda parte preferiblemente es un dispositivo hardware/software que contiene una aplicación de autenticación par actuar como servidor central de autenticación del sistema para la segunda parte. Preferiblemente tiene capacidad de proceso y comunicación por uno o más canales de comunicación, de forma que puede intercambiar información con el primer y segundo dispositivos de la primera parte y ejecutar la operativa definida por el sistema.

El segundo dispositivo de la primera parte preferiblemente es un dispositivo con capacidad de proceso y comunicación que puede intercambiar información con el servidor central de autenticación de la segunda parte por uno o más canales de comunicación, recibiendo de forma automática o semiautomática información sobre la operación de autenticación previamente solicitada desde el primer dispositivo y la forma en la que debe continuarse ejecutando la operativa definida por el sistema. El segundo dispositivo dispone de una aplicación de autenticación para la gestión de las comunicaciones, gestión de la primera tabla y soporte de la operativa del sistema.

Los resultados de los tratamientos son comunicados al servidor central de autenticación o, según el caso, directamente a la primera parte por otro medio, preferiblemente para su visualización en una pantalla de dicho segundo dispositivo que, preferentemente, es un teléfono móvil.

El tercer dispositivo es preferiblemente un dispositivo fácilmente portable para la primera parte. Preferentemente es una tarjeta de claves en la que está impresa la segunda tabla. También puede ser un token, cuya misión dentro del sistema es la de permitir a la primera parte la consulta de la segunda tabla que almacena. Se caracteriza porque no dispone de capacidad de comunicación con ningún otro dispositivo que pueda facilitar la entrada de malware y el acceso a su contenido.

Dicho tercer dispositivo también puede ser una tarjeta de claves de doble tabla en la que están impresas dos segundas tablas, cada una por una cara de la tarjeta de claves.

En este caso de tarjeta de claves de doble tabla:

dicho mensaje encriptado contiene al menos dos terceras claves situadas en la misma fila que dicha primera clave en la tercera tabla que son proporcionadas por el segundo dispositivo a la primera parte si ésta da su conformidad a los datos de la operación recibidos también en dicho mensaje;

mediante dichas segundas tablas la primera parte obtiene al menos dos cuartas claves localizadas cada una en la misma filas que dichas al menos dos terceras claves, respectivamente, de sus segundas tablas;

la primera parte envía desde su primer dispositivo al servidor central de autenticación de la segunda parte dichas al menos dos cuartas claves junto con el primer identificador y la primera clave; verificando la segunda parte que dichas al menos dos cuartas claves recibidas coinciden con las de su tercera tabla; y si son correctas el servidor central de autenticación envía una confirmación de operación realizada con éxito al primer dispositivo.

El mensaje encriptado con la quinta clave preferiblemente es un mensaje SMS enviado directamente al segundo dispositivo.

Alternativamente dicho mensaje encriptado con la quinta clave es un mensaje enviado al primer dispositivo de la primera parte quien, tras procesar dicho mensaje y formatearlo, lo reenvía al segundo dispositivo por uno de los canales de comunicación posibles entre dichos primer y segundo dispositivos, en una operación automática o semiautomática con intervención de la primera parte.

Dicho mensaje encriptado puede ser enviado desde el servidor central de autenticación al segundo dispositivo a través de Internet.

La transmisión del mensaje entre el primer dispositivo y el segundo dispositivo de la primera parte puede realizarse mediante el uso de códigos QR (Quick Response barcode, es un sistema para almacenar información en una matriz de puntos o en un código de barras). De esta forma, cuando el primer dispositivo recibe el mensaje lo transforma en un código QR que es presentado en pantalla, y que el segundo dispositivo capta para su posterior tratamiento.

El número de filas preestablecido de la tercera tabla es preferiblemente igual al número de autenticaciones que se desea poder realizar entre dichas primera y segunda partes usando dicha tercera tabla.

En resumen, el sistema de autenticación se construye haciendo uso de cuatro dispositivos físicos o lógicos -el primer dispositivo, el segundo dispositivo, el tercer dispositivo y el servidor central de autenticación- con las capacidades descritas en la invención; dos aplicaciones de autenticación - la primera aplicación de autenticación instalada en el segundo dispositivo y la segunda aplicación de autenticación instalada en el servidor central de autenticación- que realizan la operativa descrita en la invención para cada una de ellas; tres tablas de claves, creadas según se ha detallado en la descripción de la invención, y dos partes -la primera parte y la segunda parte- que realizan una operación de autenticación entre ellas siguiendo el procedimiento de autenticación de la invención.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

Para complementar la descripción que se está realizando y con objeto de ayudar a una mejor comprensión de las características del invento, de acuerdo con un ejemplo preferente de realización práctica del mismo, se acompaña como parte integrante de dicha descripción, un juego de dibujos en donde con carácter ilustrativo y no limitativo, se ha representado lo siguiente:

En la Figura 1 se muestra un esquema del flujo de mensajes y operaciones de los dispositivos del sistema de autenticación de la invención.

La Figura 2 muestra un esquema de las relaciones entre las tablas TB3, TA1 y TA2.

La Figura 3 muestra un esquema de las relaciones entre las tablas TB3, TA1 , TA21 y TA22 para el caso de uso de una tarjeta de claves de doble tabla.

La Figura 4 muestra un ejemplo de una tarjeta de claves de doble tabla.

REALIZACIÓN PREFERENTE DE LA INVENCIÓN

En el ejemplo de realización preferida de la invención, una persona o Parte A está conectada en su PC o primer dispositivo DSO, a una aplicación que su entidad bancaria o Parte B tiene para realizar operaciones en internet. Estas Parte A y Parte B están identificadas entre sí mediante respectivos identificadores IdA e IdB únicos y biunívocos.

La Parte A además dispone de un teléfono móvil como segundo dispositivo DA1 y una tarjeta de claves de doble tabla como tercer dispositivo DA2. La Parte B está representada por una aplicación en internet con un servidor central de autenticación SCA.

Esta Parte A tiene a su disposición dos tablas de claves, una primera tabla TA1 contenida en teléfono móvil DA1 y una segunda tabla TA2 contenida en la tarjeta de claves, que al ser en este caso una tarjeta de claves de doble tabla se desdobla en dos segundas tablas TA21 y TA22.

La Parte B, con la que quiere autenticarse la Parte A, dispone en el servidor central de autenticación SCA de una tercera tabla de claves TB3, diferente a las primera y segunda tablas TA1 y TA2 (o TA21 y TA22 en el caso de tarjeta de claves de doble tabla) pero totalmente relacionada con ellas por la lógica contenida en el sistema. Como se muestra en las figuras 2 y 3 y como se explicará detalladamente más adelante, la tercera tabla TB3 es la única que contiene todas las claves (primera, segunda, tercera, cuarta y quinta claves V1 , V2, V3, V4 y V5) que van a ser intercambiadas y usadas entre las partes a lo largo del proceso de autenticación, creándose las primera y segunda tablas TA1 y TA2 -o segundas tablas TA21 y TA22- a partir de la tercera tabla TB3, y complementándose para recoger todas las claves almacenadas en la TB3.

La tercera tabla de claves TB3, genérica, se compone de un número prefijado de filas, tantas como operaciones de autenticación se quiera poder realizar con ella. La aplicación de autenticación del servidor central de autenticación SCA que gestiona esta tercera tabla TB3 dispone de un contador que indica en todo momento cuál es la próxima fila de claves que debe ser usada en una operación de autenticación.

Para que la Parte A pueda intercambiar todas las claves requeridas por el proceso de autenticación es necesario que disponga de las primera y segunda tablas TA1 y TA2; si sólo se dispone de una de ellas será imposible llegar a finalizar el proceso.

El servidor central de autenticación SCA de la Parte B tiene almacenadas tantas terceras tablas TB3 como diferentes partes A quieran realizar operaciones de autenticación con la Parte B, y cada tercera tabla TB3 es distinta para cada una de estas Partes A, de forma que existe una relación uno a uno entre cada una de las Partes tipo A y tas terceras tablas TB3 gestionadas por el SCA.

Cada una de las terceras tablas TB3 tiene un identificador diferente y está directamente relacionado, de forma biunívoca, con el identificador IdA por el que el servidor central de autenticación SCA conoce a cada una de las Partes A que van a utilizar el sistema de autenticación objeto de la invención y aquí descrito.

Como se muestra en la figura 1 , cuando A quiere realizar una operación que debe ser autenticada, como por ej.: operación de identificación, transferencia de dinero, autorización de orden a ejecutar,... mediante su PC se conecta a la página web que la Parte B tiene para realizar operaciones en Internet. Inicia una solicitud de operación autenticada para la cual la aplicación le pide una clave.

Nota: en esta figura 1 se muestra con línea continua la comunicación realizada por una canal de comunicación automáticamente entre dispositivos, y con línea discontinua de puntos la comunicación realizada manualmente por Parte A.

La Parte A abre una aplicación de autenticación previamente cargada en el teléfono móvil (paso 100), y esta aplicación accede al contador de filas usadas, busca la nueva fila a usar en su tabla TA1 , localiza el valor de la primera clave V1 de la fila y lo presenta en pantalla (paso 200) para que sea usada en la solicitud de operación que la Parte A va a realizar desde su PC.

La Parte A teclea la primera clave V1 en su PC la cual es enviada al servidor central de autenticación SCA de la Parte B (paso 300) junto con el identificador IdA de la Parte A y unos datos de la operación a autenticar (mensaje M1 DSOSCA).

El servidor central de autenticación SCA recibe dicho mensaje M1 DSOSCA y accede a la tercera tabla de claves TB3 que corresponde al identificador IdA de la Parte A recibido. Consulta el contador de filas usadas de dicha tabla TB3 y accede a la fila a usar en esta operación de autenticación. Verifica que la primera clave V1 de dicha fila coincide con la que le ha llegado (operación OP1 DSOSCA). En el caso en que no haya coincidencia entre la primera clave V1 recibida y la que tiene en la fila a usar, el servidor central de autenticación SCA verifica si la primera clave V1 recibida coincide con la que corresponde a la fila anterior a la indicada por su contador de filas usadas de su tabla TB3 y, si es así, le propone realizar una operación de sincronización que pone los contadores de las tercera y primera tablas TB3 y TA1 con el mismo valor para que vuelvan a estar sincronizados; en el caso en que no haya coincidencia entre la primera clave V1 recibida y la que tiene en la fila a usar pero tampoco sea el caso anterior, el servidor central de autenticación SCA responde al PC indicando el problema detectado y finaliza la operación. En el caso en que sí haya coincidencia entre la primera clave V1 recibida y la que tiene en la fila a usar, el servidor central de autenticación SCA envía al dispositivo móvil DA1 de la Parte A (paso 400) un SMS (mensaje M1 SCADA1 ) que está encabezado por el segundo identificador IdB y que contiene los datos de la operación a autenticar junto con la primera clave V1 , una segunda clave V2 y unas terceras claves V31 y V32, donde todas estas claves son claves de la fila en uso, todo ello -salvo el segundo identificador IdB- encriptado con la quinta clave V5 de la fila en uso; incrementa en una unidad el contador de filas usadas de dicha tabla TB3; se queda en espera de recibir el mensaje necesario para finalizar la operación de autenticación iniciada.

La aplicación de autenticación abierta en el teléfono móvil de la Parte A recibe el SMS, verifica el segundo identificador IdB, accede a la primera tabla de claves TA1 , consulta el contador de filas usadas de dicha tabla y accede a la fila que se está usando; desencripta el SMS con la quinta clave V5 de dicha fila y verifica que las primera y segunda claves V1 , V2 recibidas coinciden con los que tiene dicha fila (operación OP1 SCADA1 ). En el caso en que no haya coincidencia entre las primera y segunda claves V1 , V2 recibidas y las que tiene en la fila a usar la aplicación de autenticación del teléfono móvil, da por finalizada la operación indicando a la Parte A que ha existido un problema con el mensaje recibido de la Parte B y que se ponga en contacto con ella. En el caso en que sí haya coincidencia entre las primera y segunda claves V1 , V2 recibidas y las que tiene en la fila a usar la aplicación del móvil, la Parte B queda autenticada frente a la parte A y la aplicación de autenticación del teléfono móvil presenta en pantalla a la Parte A los datos de la operación recibidos en dicho mensaje para que la Parte A los autorice; si la Parte A da su conformidad a estos datos, la aplicación de autenticación del teléfono móvil proporciona a la Parte A las terceras claves V31 y V32 (paso 500) recibidas en el mensaje.

La Parte A busca en la tarjeta de claves de doble tabla (operación OP1 DA1 DA2) el valor V41 de la fila V31 de la tabla TA21 , y el valor V42 en la fila V32 de la tabla TA22 (paso 600).

La Parte A teclea estos valores V41 y V42 en su PC (operación OP1 DA2DSO), el cual los envía al servidor central de autenticación SCA (paso 700) para autenticar a la Parte A junto con el identificador IdA de la Parte A y la primera clave V1 usada previamente (mensaje M2DSOSCA). El servidor central de autenticación SCA de la Parte B verifica que los datos que le llegan son los correctos para la autenticación de la Parte A en curso (operación OP2DSOSCA); si son correctos, da por terminada la autenticación y comunica al PC su resultado (paso 800) con un mensaje M1 SCADSO que contiene el primer identificador IdA de la Parte A y el segundo identificador, junto con el resto de los datos de la operación y el indicador de que la operación ha sido autenticada correctamente.

El PC presenta el resultado de la operación de autenticación a la Parte A.

Este sistema de autenticación de operaciones, expuesto en el modo preferente de implementación, consigue que:

Aunque un delincuente "copie" la aplicación de autenticación del teléfono móvil de un usuario con sus tablas de claves, o robe el móvil, no pueda cometer ningún fraude ya que para finalizar la autenticación es necesario disponer también de la tarjeta de claves.

- Aunque un delincuente intercepte el SMS no podrá cometer los fraudes que se basan en su modificación en modo online ya que el SMS viaja encriptado.

No sea necesario utilizar un PIN para abrir la aplicación en el móvil ya que por sí sola, sin disponer de la tarjeta de claves, no puede realizar operaciones de autenticación.

- Sea posible en la encriptación/desencriptación de los mensajes que se intercambian ya que la aplicación de autenticación en el teléfono móvil dispone de claves para poder ser usadas fácilmente.

Las únicas dos operaciones de tecleo que tiene que realizar la Parte A se realizan en su PC, a cuyo manejo ya está acostumbrado.

Además, en el modo preferente de implementación de la invención, los dos dispositivos de claves manejados por el cliente le son familiares: teléfono móvil y tarjeta de claves.

El proceso de sincronización que la segunda aplicación de autenticación del servidor central de autenticación SCA propone cuando la Parte A ha solicitado una operación de autenticación utilizando un valor de la primera clave V1 que corresponde a la primera clave de la fila anterior a la indicada por su contador de filas usadas de su tercera tabla TB3, puede llevarse a cabo de la siguiente forma:

El servidor central de autenticación SCA envía al primer dispositivo DSO un mensaje indicándole que debe realizarse una operación de sincronización y que para ello debe utilizar una clave de sincronización que se le indica, la cual se corresponde con la quinta clave V5 de la fila indicada por el contador de próxima fila a usar de su tercera tabla TB3, con objeto de que el primer dispositivo DSO informe a la Parte A..

Una vez enviado el mensaje incrementa en una unidad el valor del contador. - La Parte A ve el mensaje recibido en su primer dispositivo DSO y pide a la primera aplicación de autenticación de su segundo dispositivo DA1 una operación de sincronización; ésta pide a la Parte A que le indique el valor de la clave de sincronización a tratar.

La primera aplicación de autenticación recibe el valor de dicha clave de sincronización, comprueba que coincide con el valor de la quinta clave V5 de la fila siguiente a la que apunta su contador y, si es así, pone como valor del contador el número de fila siguiente a la que contiene dicha quinta clave V5.

De esta forma, los contadores de las tercera y primera tablas TB3, TA1 tienen el mismo valor y vuelven a estar sincronizados.

A continuación se explican cómo se generan y la relación entre las primera, segunda (o segundas) y tercera tablas de claves que usa el sistema.

Como se muestra en la figura 2, cada fila de la tercera tabla TB3 se compone de seis o más celdas de datos, donde:

a. la primera celda TB3C1 contiene un número secuencial que indica el número de orden que tiene la fila dentro de la tabla partiendo del número 1.

b. la segunda celda TB3C2 contiene la primera clave V1 consistente en un número aleatorio obtenido en el proceso de generación de esta tercera tabla TB3. Su longitud se adapta al nivel de seguridad que requiera el entorno donde se aplique el sistema de autenticación, pero se aconseja un mínimo de cuatro cifras. Se debe cumplir con el requisito de que un valor concreto de V1 sólo puede aparecer una vez dentro de una misma tabla.

c. la tercera celda TB3C3 contiene la segunda clave V2 consistente en un valor alfanumérico aleatorio obtenido en el proceso de generación de esta tercer tabla TB3. Su longitud se adapta al nivel de seguridad que requiera el entorno donde se aplique el sistema de autenticación, pero se aconseja un mínimo de cinco cifras.

d. la cuarta celda TB3C4 contiene la tercera clave V3 consistente en un número aleatorio comprendido entre cero y la cifra que expresa el número de filas de la segunda tabla TA2 (igual al número de filas de la tercera tabla TB3), obtenido en el proceso de generación de la tercera tabla TB3. Se debe cumplir con el requisito de que un valor concreto de V3 sólo puede aparecer una vez dentro de una misma tabla. e. la quinta celda TB3C5 contiene la cuarta clave V4 consistente en un número aleatorio obtenido en el proceso de generación de esta tercera tabla TB3. Su longitud se adapta al nivel de seguridad que requiera el entorno donde se aplique el sistema de autenticación, pero se aconseja un mínimo de cuatro cifras.

f. la sexta celda TB3C6 contiene la quinta clave V5 consistente en un valor alfanumérico aleatorio obtenido en el proceso de generación de esta tercera tabla TB3. Su longitud se adapta al nivel de seguridad que requiera el entorno donde se aplique el sistema de autenticación, pero se aconseja un mínimo de cinco cifras.

Puede existir una séptima y sucesivas celdas, siempre que el nivel de seguridad que requiera el entorno donde se aplique el sistema de autenticación aconseje la realización de encriptaciones más complejas de los mensajes recibidos y enviados desde el servidor central de autenticación. Todas estas claves contendrán un valor alfanumérico aleatorio (V6, V7, ...) obtenido en el proceso de generación de la tercera tabla TB3. Igualmente, su longitud se adaptará al nivel de seguridad que requiera el entorno donde se aplique el sistema de autenticación, pero se aconseja un mínimo de cinco caracteres alfanuméricos.

En el proceso de generación de cada una de estas terceras tablas TB3:

a. El identificador de cada una de las tablas a generar se crea libremente con el único condicionante de que dicho nombre sea único dentro del conjunto de tablas ya generadas.

b. Las únicas variables de entrada que deben ser fijadas para el proceso de generación son las de: el número de filas que se quiere tenga la tabla, el cual debe corresponderse con el número de autenticaciones que se desea puedan realizarse entre la Parte A y la Parte B usando dicha tabla; y la del número de columnas que se desea tenga la tabla, siendo cinco el mínimo número de columnas.

c. Para generar los números o cadenas de caracteres aleatorios el proceso de generación hace uso de algoritmos software de aleatorización. Dependiendo de los requisitos de seguridad a cumplir, estos algoritmos pueden utilizar variables creadas por dispositivos hardware.

Las primera y segunda tablas TA1 y TA2 se componen de un número prefijado de filas, tantas como tenga la tercera tabla TB3. El contenido de todas y cada una de las filas de las primera y segunda tablas TA1 y TA2 procede del existente en la misma fila de la tercera tabla TB3 y lo único que las diferencia reside en qué celdas de la tercera tabla TB3 están contempladas en las filas de la primera tabla TA1 y cuáles en la segunda tabla TA2.

Las filas de la primera tabla TA1 se componen de cuatro o más celdas de datos, donde:

a. la primera celda de la fila TA1 C1 contiene el número de fila (nnnn) de la tercera tabla TB3 de la que se van a extraer los datos que contiene la fila;

b. la segunda celda de la fila TA1 C2 contiene el mismo valor de la primera clave V1 que existe en la celda TB3C2 de la misma fila de la tercera tabla TB3;

c. la tercera celda TA1 C3 de la fila contiene el mismo valor de la segunda clave V2 que existe en la celda TB3C3 de la misma fila de la tercera tabla TB3;

d. la cuarta celda TA1 C4 de la fila contiene el mismo valor de la quinta clave V5 que existe en la celda TB3C6 de la misma fila de la tercera tabla TB3;

e. cuando existen una sexta y sucesivas celdas en la tercera tabla TB3, de la que procede la primera TA1 , estas celdas aparecen con el mismo contenido y secuencia, en todas las filas de la primera tabla TA1 .

La aplicación de autenticación del teléfono móvil que gestiona esta primera tabla TA1 dispone de un contador de filas que indica en todo momento cuál es la próxima fila de claves que debe ser usada en una operación de autenticación.

En la segunda tabla TA2:

a. la primera celda TA2C1 contiene el mismo número aleatorio de la tercera clave V3 que tiene la cuarta celda TB3C4 de la tercera tabla TB3.

b. la segunda celda TA2C2 contiene el número aleatorio de la cuarta clave V4 que tiene la quinta celda TB3C5 de la tercera tabla TB3.

En el caso de que el tercer dispositivo DA2 sea una tarjeta de claves de doble tabla, las primera, segunda y tercera tablas son ligeramente diferentes (véase figura 3).

En este caso hay que tener en cuenta que la segunda tabla TA2 queda sustituida por dos segundas tablas, TA21 y TA22. El número de filas de estas segundas tablas TA21 y TA22 viene limitado por el tamaño de la tarjeta de claves de doble tabla y se aconseja tengan un valor de 50 o 60 filas. Este valor tiene en cuenta en el proceso de generación de la tercera tabla TB3 ya que en este caso las celdas TB3C4 y TB3C5 de la tabla TB3 son sustituidas por las celdas TB3C41 , TB3C42 y TB3C51 , TB3C52, cuyo contenido es:

a. la celda TB3C41 , un número aleatorio V31 , comprendido entre cero y la cifra que expresa el número de filas de la tabla TA21 ;

b. la celda TB3C42, un valor alfanumérico aleatorio V41 cuya longitud se adapta a los requerimientos de nivel de seguridad del sistema, siendo aconsejable un mínimo de dos posiciones;

c. la celda TB3C51 , un número aleatorio V32, comprendido entre cero y la cifra que expresa el número de filas de la tabla TA22;

d. la celda TB3C52, un valor alfanumérico aleatorio V42 cuya longitud se adapta a los requerimientos de nivel de seguridad del sistema, siendo aconsejable un mínimo de tres posiciones.

En este caso de tarjeta de claves de doble tabla el número posible de filas de la tercera tabla TB3 viene limitado por el número de filas que tengan las segundas tablas TA21 y TA22, no debiendo superar a la cifra resultante de multiplicar el número de filas de TA21 x número de filas de TA22. Este requisito tiene la finalidad de que en las diferentes operaciones de autenticación que se puedan realizar con una misma tarjeta de claves nunca se repita el uso de una misma combinación de filas de las dos tablas. Es decir, se trata de que una vez usada una pareja de filas concreta, una de la tabla TA21 y otra de la tabla TA22 en una operación de autenticación ésta combinación de filas ya no pueda volver a ser usada, consiguiendo así que la cuarta clave formada por la serie de caracteres procedentes de V41 y V42 sea una clave de un solo uso (clave OTP) dentro de la operativa contemplada por el sistema objeto de la invención.

En este caso de tarjeta de claves de doble tabla el algoritmo que genera los valores V31 y V32 para una fila concreta de la tercera tabla TB3 controla que dicha pareja de valores no aparezca en ninguna de las filas generadas anteriormente para la misma tercera tabla TB3.

En este caso de tarjeta de claves de doble tabla, la columna TA1 C4 de la primera tabla TA1 queda sustituida por las columnas TA1 C41 y TA1 C42 que contienen, respectivamente, los valores de las columnas TB3C4 (V31 ) y TB3C6 (V32) de la tercera tabla TB3 de la que procede.

Como ya se ha indicado, en este caso la segunda tabla TA2 se descompone en dos segundas tablas, TA21 y TA22. La tabla TA21 contiene los valores de las columnas TB3C41 y TB3C42 de la tercera tabla TB3 de la que procede. La tabla TA22 contiene los valores de las columnas TB3C51 y TB3C52 de la tercera tabla TB3 de la que procede. En la figura 4 se muestra un posible ejemplo de tarjeta de claves de doble tabla.

En este ejemplo se usan 50 filas por tabla de forma que combinando las filas de las dos tablas se dispone de un total de 50x50=2.500 claves que pueden ser utilizadas. Al usuario se le solicita la clave de autenticación pidiéndole teclee las claves de dos identificadores, uno de la tabla A y otro de la tabla B. Dentro del sistema objeto de la invención los identificadores de las filas a usar se corresponde con los valores V31 y V32 de las tablas TA21 y TA22 respectivamente, y los valores asociados a estos identificadores de fila se corresponden con los valores V41 y V42 de las mismas tablas.

La Parte A es informada de qué claves de la tarjeta debe teclear para autenticar la operación, por medio de un mensaje como: "Claves a teclear: Fila A09 y fila B48".

En el PC o medio en el que esté realizando la operación (primer dispositivo DSO), se le solicita:

"Teclee las claves de:

la fila A: xxx (deberá teclear la clave de la fila A09)

la fila B: xxx" (deberá teclear la clave de la fila B48).

Gracias a esta tarjeta de claves de doble tabla se puede generar un volumen mucho mayor de claves que evite la necesidad de reutilización.

En el sistema de autenticación que se ha definido no existe riesgo de fraude ya que:

El sistema que utiliza las diferentes claves para la autenticación controla que estos valores no puedan ser usados más de una vez dentro de la operativa del sistema (claves OTP).

El canal por el que se comunica el identificador de qué clave de la tarjeta de claves debe ser usado en el proceso de autenticación es diferente al canal que se usa para aportar dicho valor.

El mensaje que comunica el identificador de la clave que debe ser usada en el proceso de autenticación viaja encriptado y autenticado.

De esta forma se consiguen las ventajas de los sistemas OTP y se evita también el que un malware instalado en uno de los canales pueda interceptar y manipular los mensajes o hacer un seguimiento de los identificadores y sus valores asociados. Como complemento y paso previo a la autenticación descrita, cuando una primera parte, Parte A, quiera utilizar el sistema de autenticación objeto de la invención, debe ponerse de acuerdo con la segunda parte, Parte B, para que le asigne una tercera tabla tipo TB3 y sus primera y segundas tablas TA1 y TA2, derivadas de ella. A partir de ese momento dichas tablas pueden ser tratadas por el servidor central de autenticación SCA y sus identificadores dentro del SCA están directamente relacionados de forma unívoca con el identificador IdA por el que el SCA conoce a dicha Parte A.

La primera tabla TA1 se entrega a la Parte A por medio de una descarga en su segundo dispositivo DA1 .

La segunda tabla TA2 se entrega a la Parte A en su tercer dispositivo DA2, siendo un token de seguridad, una tarjeta de claves -preferiblemente de doble cara, tablas TA21 y TA22-, o cualquier otro medio con capacidad para su almacenamiento y posterior consulta.

A la vista de esta descripción y juego de figuras, el experto en la materia podrá entender que las realizaciones de la invención que se han descrito pueden ser combinadas de múltiples maneras dentro del objeto de la invención.