MX2015002928A

MX2015002928A - Metodo y sistema para verificar una peticion de acceso.

Info

Publication number: MX2015002928A
Application number: MX2015002928A
Authority: MX
Inventors: Boris Taratine; Matthew Johnson; Simon Peter Rust; Andrew Warren Rounds
Original assignee: Visa Europe Ltd
Priority date: 2012-09-06
Filing date: 2013-09-06
Publication date: 2015-06-02
Also published as: US9830447B2; ES2590678T3; US20150178494A1; MX2015002929A; GB2505678A; AU2013311424A1; EP2893484B1; CN104798083A; KR102202547B1; US20190213321A1; CA2884005C; GB2505532A; KR102177848B1; CN104769602B; WO2014037741A1; HK1208278A1; GB201215951D0; US10282541B2; CA2884005A1; US20140068739A1

Abstract

La presente invención se refiere a un sistema para verificar una petición para acceso a los datos, el sistema comprende un primer módulo (20) y un segundo módulo (30). El primer módulo (20) está arreglado para generar una contraseña, y el segundo módulo (30) está arreglado para recibir una contraseña asociada con una petición para datos, validar la contraseña recibida, y permitir acceso a los datos solicitados. El sistema es tal que entonces el primero y segundo módulos (20,30) comparten un secreto que ha sido personalmente asignado a este, el secreto compartido es para uso en la generación y validación de tal contraseña. Además, el primer módulo (20) está desconectado de manera comunicativa del segundo módulo (30).

Description

MÉTODO Y SISTEMA.PARA VERIFICAR UNA PETICIÓN DE ACCESO CAMPO DE LA INVENCIÓN La presente invención se refiere a un método y sistema para verificar una petición de acceso, y es particularmente, pero no exclusivamente adecuado para verificar una petición para acceso a los datos o servicios o activos.

ANTECEDENTES DE LA INVENCIÓN La demanda para acceso a los datos confidenciales o específicos del usuario (o activos o servicios) está aumentando. Por ejemplo, proporcionar acceso a una cuenta de bancos y permitir la transferencia de dinero de tal cuenta debe ser restringido a usuarios autorizados tales como un titular de la cuenta. Típicamente, los usuarios son autentificados cuando solicitan acceso a los datos por medio de credenciales que identifican la persona que solicita acceso a los datos. El acceso remoto a los datos presenta problemas particulares debido a que la persona que solicita los datos, activos o servicios está típicamente en una ubicación física diferente a aquella de la parte que responde a la petición. Como un resultado es un difícil para la parte que atiende la petición para saber si la entidad que hace la petición es a) quién dice ser, b) autorizada para usar el dispositivo desde donde se origina la petición y c) está en posesión del dispositivo desde donde se origina la petición.

Típicamente, cuando una cuenta se ha configurado entre una persona y una parte tal como un proveedor de datos, la persona establecerá las credenciales mencionadas antes para uso por el proveedor de datos para identificar y autentificar a la persona para peticiones futuras. Tales credenciales pueden incluir información que identifica personalmente al párroco (por ejemplo, información que permite la identificación personal (PII, por sus siglas en inglés)) y un secreto (por ejemplo, una contraseña) para uso en la verificación de la identidad de la persona. También es ahora común que el proveedor de datos requerirá que la persona se registra ella misma como el propietario de un dispositivo usado para acceder a los datos. La asociación registrada ente el dispositivo y el propietario del dispositivo puede ser usada por el proveedor de datos como un factor de validación adicional. Por ejemplo, en el caso de que un proveedor de datos reciba una petición para acceso a una cuenta en beneficio de una persona particular a partir de un dispositivo particular que no es el dispositivo registrado por la persona, el proveedor de datos puede determinar confiar que la petición se hizo por la persona registrada para la cuenta.

Puede ser relativamente fácil para una persona desear acceder a datos a partir de un proveedor de datos en beneficio de otra persona quien tiene una cuenta con tal proveedor de datos para obtener sus credenciales de usuario (es decir, PII, ID de Usuario y contraseña) mediante la adquisición de mercados en linea de sombras criminales y posteriormente acceder de manera fraudulenta a los datos de otra persona. Adicionalmente, son posibles de forma remota los dispositivos de control y acceso, y de este modo solicitar datos en beneficio del propietario registrado de estos dispositivos. A menudo no es posible determinar si la petición se hace por un usuario quién está en una posesión física del dispositivo o si la petición se hace de manera remota por un usuario que usa otro dispositivo para de manera remota controlar el dispositivo a partir del cual se hace la petición.

Las contraseñas de un solo uso (OTP, por sus siglas en inglés), son comúnmente usadas para aliviar estos problemas: un servidor de autentificación asigna personalmente una clave de generación de OTP al propietario registrado de un dispositivo, la clave de generación de OTP es para uso en la generación y validación de OTPs. Un servidor de autentificación típicamente mantiene cientos o miles de claves de generación de OTP, cada una tiene que ser personalmente asignada a, o registrada con respecto de, una persona diferente. El servidor de autentificación configura un testigo de OTP en la posesión del propietario registrado con su clave de generación de OTP asignada. Estos testigos de OTP pueden, por ejemplo, usar la clave de generación de OTP para generar una contraseña diferente cada vez que una nueva contraseña es solicitada por el usuario registrado o como otro ejemplo, puede usar la clave de generación de OTP para generar nuevas contraseñas a intervalos de tiempo regulares.

Con el fin de acceder a los datos restringidos del usuario mediante un dispositivo, un usuario proporciona la OTP generada por el testigo de OTP al proveedor de datos junto con las credenciales que identifican personalmente al propietario del dispositivo. Típicamente, el proveedor de datos entonces identificará al propietario del dispositivo y transmitirá en la OTP recibida al servidor de autentificación. El servidor de autentificación esperará la clave de generación de OTP asociada con la persona identificada y usará la clave para determinar si la OTP recibida corresponde a la OTP que podría haber sido/fue generada por el testigo de OTP mantenido por el propietario del dispositivo. El servidor de autentificación entonces indicará al proveedor de datos si la OTP recibida es válida. Si la OTP correcta se envió al proveedor de datos, entonces puede determinarse que el usuario del dispositivo está en posesión del testigo de OTP. Sin embargo, los servidores de autentificación son vulnerables a comprometerse de este modo facilitando la distribución no autorizada a otras entidades y permitir a cualquier persona con acceso (ilegitimo) a una clave de generación de OTP distribuida para acceder datos en beneficio de la persona asociada con tal clave.

El documento US 7,721,107 describe un método particular para verificar si el usuario de un dispositivo es un humano. En el método descrito un usuario de un dispositivo que solicita acceso a una OTP es presentado con "instrucciones de interacción" mediante una primera área de una interfaz de usuario del dispositivo. En un ejemplo, el usuario es instruido para ingresar una serie de números en una segunda área de la interfaz del usuario; en otro ejemplo, el usuario es instruido para realizar una acción física, tal como trazado de una curva dentro de una segunda área de la interfaz del usuario (por ejemplo, una pantalla de toque). El dispositivo entonces determina si el usuario ha ingresado los números correctos/trazado la curva correcta etc., y, si asi es, el dispositivo proporciona la OTP solicitada al usuario. Sin embargo como el módulo que presenta las instrucciones de interacción y el módulo que procesa la respuesta de usuario a las instrucciones de interacción están conectados de manera comunicativa, un usuario podría ser capaz de hacer la conexión al dispositivo y de este modo ser capaz de autentificarse de manera fraudulenta el mismo en el dispositivo mediante el acceso de las instrucciones de interacción y respondiendo a ellas de manera apropiada.

BREVE DESCRIPCIÓN DE LA INVENCIÓN De conformidad con un primer aspecto de la presente invención, se proporciona un sistema para uso en la verificación de una petición para acceso a los datos, el sistema comprende: un primer módulo arreglado para generar una contraseña y salida a la contraseña generada mediante una interfaz del primer módulo; un segundo módulo arreglado para recibir una contraseña asociada con la petición para datos, validar la contraseña recibida, y permitir acceso a los datos solicitados, en donde tal contraseña recibida se recibe mediante una interfaz del segundo módulo y corresponde a la contraseña generada por el primer módulo, en donde el primero y segundo módulos comparten un secreto que ha sido personalmente asignado al primero y segundo módulos para uso en la generación y validación de tal contraseña, y, en donde el primer módulo está desconectado de manera comunicativa del segundo módulo.

El secreto compartido permite al segundo módulo determinar si una contraseña recibida de un usuario del segundo módulo se iguala con una contraseña que ha sido generada por el primer módulo, y de este modo permite al segundo módulo validar la contraseña recibida. Como este secreto es personalmente asignado al primero y segundo módulos (es decir, existe un mapeo uno a uno entre el secreto y el módulo para generar la contraseña y también un mapeo uno a uno entre el secreto y el módulo para validad la contraseña), entonces en el caso de que el secreto esté comprometido, solamente estos dos módulos necesitan ser reconfigurados con un nuevo secreto. Esto es contrario al sistema de OTP conocido descrito en la sección de antecedente, en la cual una clave de OTP dada es personalmente asociada a una persona, en lugar de a un par de módulos, y se mantiene a un servidor de validación de OTP. El cual mantiene muchas diferentes claves de OTP para muchas personas diferentes. Esto resulta en una relación uno o muchos entre el servidor de validación de OTP y los dispositivos que usan la clave de OTP para generar contraseñas. Tal es el caso, si el servidor de validación de OTP está comprometido, los datos pueden ser accesados en beneficio de una persona cuya clave se mantiene por el servidor de validación mediante cualquier dispositivo que usa tal clave de OTP de la persona para controlar el acceso a los datos, activos o servicios. Como la clave de OTP típicamente será almacenada tanto en un número de testigos de OTP como también en el servidor de autentificación, establecer una nueva clave de OTP puede ser casi pesado en el servidor de autentificación, ya que el servidor de autentificación es requerido para tanto reasignar tal persona a una nueva clave de generación de OTP y configurar una serie de testigos de OTP con la nueva clave de generación de OTP.

Ventajosamente, tal segundo módulo está arreglado para validar las contraseñas asociadas con un módulo adicional con el cual ha sido apareado durante un proceso de configuración en el cual un secreto es asignado al segundo módulo y el módulo adicional. El módulo adicional puede ser un módulo de una tercera parte y en este caso, el secreto puede estar asociado con un usuario particular quién se conoce por la tercera parte. El segundo módulo es por lo tanto capaz de usar el secreto para verificar si el usuario del segundo módulo es el usuario conocido por la tercera parte.

En un arreglo, tal primer módulo y tal segundo módulo son pates compuestas de un dispositivo. En este caso, si un usuario del segundo módulo es capaz de recuperar una contraseña del primer módulo e ingresar en el segundo módulo, es muy probable que el usuario del segundo módulo esté en posesión del primer módulo, y por lo tanto también esté en posesión del segundo módulo. De este modo, si el segundo módulo valida una contraseña recibida de un usuario del segundo módulo, es muy probable que el usuario esté en posesión del segundo módulo. En otras palabras, es probable que el usuario del dispositivo no esté controlando el dispositivo de manera remota.

En una modalidad tal primer módulo, tal segundo módulo están integrados dentro del dispositivo. Por ejemplo, los módulos podrían compartir una batería.

En un arreglo, tal dispositivo tiene un identificador de dispositivo único y tales contraseñas generadas y recibidas son generadas y validadas en dependencia del identificador de dispositivo único. Esto proporciona aseguramiento adicional de que el usuario del segundo módulo está en posesión del dispositivo.

Ventajosamente, tal secreto compartido es almacenado en un elemento de seguridad del segundo módulo. Esto previene a un usuario del segundo módulo acceder al secreto usado para validar contraseñas recibidas con el fin de determinar la contraseña que podría ser generada por el primer módulo.

En una modalidad, tal secreto compartido es almacenado en un elemento de seguridad del primer módulo. Esto previene a un usuario del primer módulo acceder al secreto usado para generar contraseñas.

En un arreglo, el segundo módulo es arreglado para enviar datos para uso permitiendo acceso a los datos solicitados, con ello permitir acceso a los datos solicitados. Esto es particularmente útil en el caso de que los datos solicitados se mantengan externamente por una tercera parte, o en el caso específico de que las contraseñas sean generadas y validadas en dependencia del tiempo, pero el segundo módulo no tiene un reloj que es sincronizado con el reloj de un primer módulo.

En una modalidad, el primer módulo es arreglado para generar tal contraseña generada en respuesta a una entrada relacionada con tal petición para acceso a los datos.

Ventajosamente, el primer módulo es arreglado para generar una contraseña subsecuente en respuesta a una entrada subsecuente relacionada con una petición para acceso a los datos, la contraseña subsecuentemente generada es diferente de una contraseña previamente generada. De este modo, si un usuario remoto observa (mediante una interfaz del segundo módulo por ejemplo) una contraseña ingresada por un usuario quién está en posesión de tanto el primero como segundo módulos, el usuario remoto no será capaz de reutilizar la contraseña observada con el fin de acceder a datos adicionales, conforme la validez de la contraseña habrá expirado.

Alternativamente, el primer módulo es arreglado para generar contraseñas a intervalos de tiempo regulares, cada contraseña generada sucesivamente es diferente de una contraseña previamente generada. En este caso, una contraseña particular generada es solamente válida por un periodo de tiempo predeterminado, y por lo tanto un usuario remoto quién ha observado una contraseña ingresada por un usuario quién está en posesión tanto del primero como segundo módulos no será capaz de reutilizar tal contraseña fuera del periodo de tiempo predeterminado.

En un arreglo, tales contraseñas son generadas y validadas en dependencia de al menos tal secreto compartido y el tiempo actual.

En un arreglo particular, el primer módulo comprende un primer reloj para uso en la generación de una contraseña y el segundo módulo comprende un segundo reloj para uso en la validación de una contraseña recibida, el primero y segundo relojes son sincronizados.

En un arreglo diferente, el primer módulo comprende un reloj para uso en la generación de una contraseña y el segundo módulo es arreglado para recibir una marca de tiempo para uso en la validación de una contraseña recibida, la marca de tiempo es recibida de una tercera parte que tiene un reloj que es sincronizado con el reloj del primer módulo. Esto tiene la ventaja de que el segundo módulo no se requiere para tener un reloj sincronizado con el primer reloj.

En un arreglo alternativo adicional, el primer módulo comprende un reloj para uso en la generación de una contraseña y el segundo módulo es arreglado para recibir una marca de tiempo para uso en la validación de una contraseña recibida, y tales datos enviados por el segundo módulo para uso permiten el acceso a los datos que se envían a una tercera parte que tiene un reloj sincronizado con el reloj del primer módulo y comprende una indicación de la marca de tiempo usado para validar tal contraseña recibida. Esto tiene la ventaja de que el segundo módulo no se requiere para tener un reloj sincronizado con el primer reloj.

En una modalidad, tales datos enviados por el segundo módulo para uso permiten el acceso a los datos que comprenden datos indicativos de una determinación de que la contraseña recibida es válida. El segundo módulo puede comprender una interfaz de usuario y ser arreglado para recibir la petición para acceso a los datos de un usuario del segundo módulo mediante tal interfaz de usuario.

En un arreglo, el segundo módulo es además arreglado para recibir información mediante la interfaz de usuario del segundo módulo que personalmente identifica un humano, y tales datos enviados por el segundo módulo para uso permiten el acceso a los datos que comprenden datos que personalmente identificar tal humano.

De conformidad con un segundo aspecto de la presente invención, se proporciona un método para verificar una petición para acceso a los datos, el método comprende: generar en un primer módulo una contraseña y hacer salir la contraseña generada mediante una interfaz del primer módulo; recibir en un segundo módulo una contraseña asociada con la petición para datos mediante una interfaz del segundo módulo, tal secreto recibido corresponde a la contraseña generada por el primer módulo, validar en el segundo módulo tal contraseña recibida, y permitir el acceso a los datos solicitados en el segundo módulo, en donde el primero y segundo módulos comparten un secreto que ha sido personalmente asignado al primero y segundo módulos para uso en la generación y validación de tal contraseña, y en donde el primer módulo está desconectado de manera comunicativa del segundo módulo.

De conformidad con un tercer aspecto de la presente invención, se proporciona un sistema para uso en la verificación de una petición para datos recibidos en un dispositivo como una petición que se origina de un humano en posesión del dispositivo, el sistema comprende: un primer módulo arreglado para generar una contraseña y salida a la contraseña generada mediante una interfaz del primer módulo; un segundo módulo arreglado para recibir una contraseña asociada con la petición para datos y validar la contraseña recibida, y permitir acceso a los datos, en donde tal contraseña recibida se recibe mediante una interfaz del segundo módulo y corresponde a la contraseña generada por el primer módulo, en donde el primer módulo y el segundo módulo son partes compuestas del dispositivo, y en donde el primer módulo está desconectado de manera comunicativa del segundo módulo.

Se apreciará que, como el primero y segundo módulos son desconectados de manera comunicativa de entre si, si un usuario del segundo módulo es capaz de recuperar la contraseña generada por el primer módulo, es probable que el usuario del segundo módulo esté en posesión del primer módulo. Además, si el primero y segundo módulos son partes compuestas de un dispositivo único, entonces si el usuario del segundo módulo está en posesión del primer módulo, entonces tal usuario debe también estar en posesión del segundo módulo. Cuando la contraseña generada por el primer módulo es exhibida mediante una interfaz de usuario del primer módulo y se recibe mediante una interfaz de usuario del segundo módulo, el segundo módulo es capaz de determinar a un nivel razonable de confianza que la petición para acceso a los datos es originada de un humano quién está en posesión del dispositivo. Esto es debido a que, como el primer módulo está desconectado de manera comunicativa del segundo módulo, no existen medios para transferir automáticamente la contraseña generada por el primer módulo al segundo módulo y de este modo la contraseña tiene que ser leída de un usuario interface del primer módulo y entrar de manera manual mediante la interfaz de usuario del segundo módulo.

De manera conveniente, tal primer módulo y tal segundo módulo están integrados dentro del dispositivo.

En un arreglo, el primero y segundo módulos comparten un secreto para uso en la generación y validación de tal contraseña. En este caso, el segundo módulo puede ser capaz de determinar si una contraseña recibida de un usuario del segundo módulo se iguala con una contraseña que ha/podría haber sido generada por el primer módulo sin tener que usar una tercera parte.

En un arreglo alternativo, el segundo módulo es arreglado para enviar la contraseña recibida a una tercera parte y recibir una indicación de la tercera parte que la contraseña recibida es válida, con ello validando la contraseña recibida. En este caso, el segundo módulo no se requiere para ser configurado con un secreto.

En un arreglo alternativo adicional, el segundo módulo es arreglado para validar la contraseña recibida comparando la contraseña recibida a una contraseña generada por un tercer módulo.

En una modalidad, el primer módulo es arreglado para generar tal contraseña en respuesta a una entrada relacionada con tal petición para acceso a los datos.

Ventajosamente, el primer módulo es arreglado para generar una contraseña subsecuente en respuesta a una entrada subsecuente relacionada con una petición para acceso a los datos, la contraseña subsecuentemente generada es diferente de una contraseña previamente generada.

En una modalidad alternativa, el primer módulo es arreglado para generar contraseñas a intervalos de tiempo regulares, cada contraseña generada sucesivamente es diferente de una contraseña previamente generada.

De conformidad con un cuarto aspecto de la presente invención, se proporciona un método para verificar una petición para datos recibidos en un dispositivo como una petición que se origina de un humano en posesión del dispositivo, el método comprende: generar en un primer módulo una contraseña y hacer salir la contraseña generada mediante una interfaz del primer módulo; recibir en un segundo módulo una contraseña asociada con la petición para datos mediante una interfaz del segundo módulo, tal secreto recibido corresponde a la contraseña generada por el primer módulo; validar en el segundo módulo la contraseña recibida; y permitir el acceso a los datos en el segundo módulo, en donde el primer módulo y el segundo módulo son partes compuestas del dispositivo, y en donde el primer módulo está desconectado de manera comunicativa del segundo módulo.

Características y ventajas adicionales de la invención llegarán a ser aparentes a partir de la siguiente descripción de modalidades preferidas de la invención, dado por medio del ejemplo solamente, lo cual se hace con referencia a los dibujos acompañantes.

BREVE DESCRIPCIÓN DE LAS FIGURAS La Figura 1 muestra un diagrama de bloque de un sistema de conformidad con una modalidad de la presente invención; La Figura 2 muestra esquemáticamente un método de conformidad con una modalidad de la presente invención; La Figura 3 muestra un diagrama de bloque de un sistema de conformidad con una modalidad de la presente invención; La Figura 4 muestra esquemáticamente un método de conformidad con una modalidad de la presente invención; La Figura 5 muestra esquemáticamente un método de conformidad con una modalidad de la presente invención; La Figura 6 muestra esquemáticamente un método de conformidad con una modalidad de la presente invención; y, La Figura 7 muestra esquemáticamente un método de conformidad con una modalidad de la presente invención.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN Modalidades de la invención están relacionadas con la determinación de si se permite acceso a los datos, activos o servicios solicitados. La Figura 1 muestra un diagrama de bloque de un sistema 10 de conformidad con una modalidad de la presente invención. El sistema 10 comprende un primer módulo 20 y un segundo módulo 30. El primer módulo 20 es arreglado para generar contraseñas, y el segundo módulo 30 es arreglado para recibir contraseñas de un usuario del sistema 10 y validar las contraseñas recibidas. Mientras no sea esencial, en una modalidad, el primero y segundo módulos 20,30 cada uno comprende una interfaz de usuario respectiva 21,31. Las interfaces de usuario 21,31 típicamente comprenden al menos una entrada o salida. Una entrada de una interfaz de usuario de un dispositivo puede ser, por ejemplo, un teclado, un ratón, una pantalla de toque, un micrófono o cualquier otro componente que permite al usuario proporcionar una entrada al dispositivo. Una salida de una interfaz de usuario de un dispositivo puede ser, por ejemplo, una pantalla, un altavoz, o cualquier otro componente capaz de dar salida a la información del dispositivo a un usuario de la interfaz de usuario. La interfaz de usuario 21 del primer módulo 20 está configurada para proporcionar una contraseña generada a un usuario del primer módulo 20 y la interfaz de usuario 31 del segundo módulo 30 está configurada para recibir una contraseña de un usuario del segundo módulo 30. En la presente modalidad, el primer módulo 20 y el segundo módulo 30 son dispositivos separados que son colectivamente configurados para determinar si es probable que una petición para acceso a los datos es originada de un usuario en posesión del segundo módulo 30. Como un ejemplo, los dos módulos 20,30 pueden ser manufacturados y vendidos en conjunto, y en la posesión de una persona particular. El segundo módulo 30 puede, en un ejemplo, ser un dispositivo inalámbrico (o un componente de un dispositivo inalámbrico). En un arreglo, el primero y segundo módulos 20,30 pueden ser componentes de un dispositivo inalámbrico único.

El segundo módulo 30 puede operar bajo el control de un usuario quién está en posesión del segundo módulo 30 mediante la interfaz de usuario 31 del segundo módulo 30 o puede operar bajo el control de una entidad remota que tiene enlaces de comunicaciones al segundo módulo 30. El primer módulo 20 puede ser controlado mediante la interfaz de usuario 21 del primer módulo 20 y está desconectado de manera comunicativa del segundo módulo 30, como se describirá en más detalle abajo, y por lo tanto no puede ser controlado mediante la interfaz de usuario 31 del segundo módulo 31.

El segundo módulo 30 puede ser una parte compuesta de un dispositivo que almacena datos confidenciales asociados con una persona particular solamente. Como un ejemplo particular, el segundo módulo 30 puede almacenar claves criptográficas restringidas al usuario para desencriptar datos. Adicionalmente o alternativamente, el segundo módulo 30 puede proporcionar o facilitar acceso a los datos confidenciales que son almacenados externamente por una tercera parte. En este último caso, la tercera parte puede solamente permitir acceso a los datos si se determina que los datos están siendo proporcionados a una persona particular (en otras palabras, los datos pueden ser restringidos al usuario). Como se discute anteriormente, antes de que una tercera parte otorgue acceso a los datos restringidos al usuario mediante un dispositivo particular, la tercera parte puede requerir que el propietario de un dispositivo registre una asociación entre el dispositivo y el propietario. En este caso, la tercera parte puede entonces solamente enviar datos, lo cual se pretende sea recibido por una persona particular, al dispositivo que está asociado con tal persona. En el presente ejemplo, el segundo módulo 30 puede tener una asociación registrada con una persona particular, y de este modo el acceso a los datos que se pretenden por el propietario del segundo módulo 30 puede ser accedido mediante el segundo módulo 30 solamente.

Cuando el segundo módulo 30 comprende un módulo de comunicaciones, se apreciará que una persona no autorizada podría hacer una conexión con el segundo módulo 30 y controlar de manera remota el segundo módulo 30 para enviar una petición a la tercera parte que mantiene los datos confidenciales. Si el segundo módulo 30 puede determinar que la petición para acceso a los datos se hizo por un usuario en posesión del segundo módulo 30 o por un usuario remoto del segundo módulo 30, puede tomar una acción responsiva apropiada por ejemplo, denegando el uso adicional del segundo módulo 30 después de una determinación de que la petición se hizo por un usuario remoto.

Como se explicará ahora, las modalidades proporcionan un medio para realizar tal determinación. El primero y segundo módulos 20,30 están configurados con un secreto compartido que es para uso en tanto generación de contraseñas como validación de contraseñas. En particular, el primer módulo 20 comprende circuitos y/o software que es construido y configurado para generar una contraseña con base en el secreto, y el segundo módulo 30 comprende circuitos y/o software que es construido y configurado para determinar, con base en el secreto, si una contraseña recibida de un usuario del segundo módulo 30 se iguala con la contraseña que fue generada por el primer módulo 20. En la modalidad particular mostrada en la Figura 1, este secreto es personalmente asignado al primero y segundo módulos 20,30. En otras palabras, el secreto está asociado con el primero y segundo módulos 20,30 solamente. En un arreglo, el primero y segundo módulos 20,30 son resistentes a la manipulación, es decir, el secreto almacenado en el primero y segundo módulos 20,30 y el algoritmo usado para generar la contraseña no puede ser alterado.

En la presente modalidad, el sistema 10 está configurado para tal de manera que el primer módulo 20 está desconectado de manera comunicativa del segundo módulo 30. En otras palabras, el sistema 10 es construido y configurado de manera que no existen medios de comunicación (ya sea directamente o indirectamente) entre los dos módulos 20,30. En una modalidad particular, la comunicación entre los dos módulos 20,30 se previene por los módulos 20,30 siendo físicamente desconectados de entre sí. Se entenderá sin embargo, que los dos módulos 20,30 podrían ser físicamente conectados (es decir, integrados) mientras son desconectados de manera comunicativa por ejemplo, si no comparten algunos circuitos o interfaces de sistema comunes o comprenden cualquiera de otros medios de intercambio de información entre sí.

La Figura 2 muestra esquemáticamente un método ejemplar de conformidad con la presente modalidad. En este método, un usuario 35 del segundo módulo 30 hace una petición para acceso a los datos (etapa 40). La petición para acceso a los datos en la etapa 40 podría ser, por ejemplo, una petición para acceso a una página web restringida al usuario, una petición para acceso a información confidencial, o una petición para acceso a los datos para uso permitiendo acceso a un servicio. Se entenderá que, en general, los datos que el usuario 35 del segundo módulo 30 desea para tener acceso podrían ser datos almacenados en o generados por un componente del sistema 10, o podrían ser datos que son almacenados en o generado por una entidad que es externa al sistema 10 (por ejemplo una base de datos o servidor externos). Los datos que el usuario 35 del segundo módulo 30 desea para tener acceso pueden ser, por ejemplo, una página de red restringida alojada en un servidor, la cual es externa al sistema 10, y en este caso, el acceso a la página web puede ser permitido por el servidor enviando datos al segundo módulo 30. La información contenida en los datos enviados por el segundo módulo 30 será explicada en más detalle abajo.

En respuesta a la petición para acceso a los datos en la etapa 40, el segundo módulo 30 avisa al usuario para ingresar una contraseña que ha sido generada por el primer módulo 20. En este ejemplo, el usuario 35 del segundo módulo 30 es también el usuario 25 del primer módulo 20 (como se muestra esquemáticamente por las líneas punteadas en la Figura 2) y de este modo el usuario puede entonces causar (etapa 50) al primer módulo 20 para generar una contraseña mediante, por ejemplo, presionar un botón de la interfaz de usuario 21 del primer módulo o de otro modo para indicar al primer módulo 20 que se requiere una contraseña.

En respuesta, el primer módulo 20 usa el secreto que es personalmente asignado al primero y segundo módulos 20,30 para generar una contraseña, la cual es entonces proporcionada (etapa 60) al usuario 25 del primer módulo 20. La contraseña generada puede ser, por ejemplo, una serie de números, una serie de letras, una combinación de letras y caracteres o una imagen y puede, por ejemplo, ser presentada al usuario 25 del primer módulo 20 en una pantalla de la interfaz de usuario 21.

Alternativamente, el primer módulo 20 puede generar contraseñas (en dependencia con el secreto compartido) a intervalos de tiempo regulares y puede presentar automáticamente la contraseña más recientemente generada en la interfaz de usuario 21 del primer módulo 20.

En cualquier caso, como el usuario 35 del segundo módulo 30 es el usuario 25 del primer módulo 20, el usuario puede entonces ingresar (etapa 70) la contraseña generada por el primer módulo 20 en la interfaz de usuario 31 del segundo módulo 30. El segundo módulo 30 entonces usa el secreto que es personalmente asignado al primero y segundo módulos 20,30 para verificar si la contraseña recibida del usuario 35 del segundo módulo 30 es la misma como la contraseña que fue generada por el primer módulo 20. Después de validar la contraseña recibida, el segundo módulo 30 entonces permite el acceso a los datos solicitados (etapa 80).

Se apreciará que cuando una contraseña que es generada por el primer módulo 20 es ingresada en el segundo módulo 30, la contraseña debe haber sido previamente recuperada del primer módulo 20. Como el primer módulo 20 está desconectado de manera comunicativa del segundo módulo 30, es altamente probable que el usuario 35 es un humano quién está en posesión del primer módulo 20 asi como también el segundo módulo 30, y es por lo tanto capaz de recuperar la contraseña del primer módulo 20 e ingresar manualmente en el segundo módulo 30.

Ventajosamente, el primer módulo 20 y el segundo módulo 30 pueden cada uno comprender un elemento de seguridad respectivo 22,32 tal como una tarjeta SIM segura o una tarjeta de memoria segura, y el secreto que es personalmente asignado al primero y segundo módulos 20,30 es almacenado en los elementos de seguridad 22,32 del primero y segundo módulos 20,30. En otras palabras, el secreto que es personalmente asignado al primero y segundo módulos 20,30 es almacenado en partes del primero y segundo módulos 20,30 que no pueden ser accesadas por los usuarios 25,35 de estos módulos 20,30. En este caso, el secreto puede ser provisionado a los elementos de seguridad 22,32 del primero y segundo módulos 20,30 en manufactura y en una modalidad preferida, los elementos de seguridad 22,32 son manufacturados de manera separada a los otros componentes de los módulos 20,30 y de este modo la asociación entre los módulos 20,30 y el secreto almacenado en los elementos de seguridad 22,32 no pueden ser conocidos por cualquier entidad externa al sistema 10. Almacenar el secreto dentro de los elementos de seguridad 22,32 previene a un usuario 25,35 de cualquiera de los módulos 20,30 de encontrar el secreto y de este modo ser capaz de hacer funcionar la contraseña que necesita ser ingresada en el segundo módulo 30 con el fin de tener acceso a los datos solicitados y también previene a un usuario 25,35 de alterar el algoritmo para generar contraseñas, lo cual podría de este modo causar que el primer módulo 20 genere una respuesta falsa.

Una ventaja particular de la presente modalidad se origina a partir del hecho de que el secreto para generar y validar la contraseña es personalmente asignado al primero y segundo módulos 20,30. Más específicamente, debido a que existe un mapeo uno a uno entre el secreto y el módulo 30 que usa el secreto para validar la contraseña, y también un mapeo uno a uno entre el secreto y el módulo 20 que usa el secreto para generar la contraseña, entonces en el caso de que el secreto sea comprometido, los módulos 20,30 necesitan solamente ser reconfigurados con un nuevo secreto (que es nuevamente asignado personalmente a los módulos 20,30). Esto se puede lograr, por ejemplo, reemplazando los elementos de seguridad 22,32 de los módulos 20,30 con nuevos elementos de seguridad que tienen el nuevo secreto almacenado en este. Esto es contrario al sistema de OTP conocido descrito en la sección antecedente, en el cual una clave de OTP dada es personalmente asociada a un usuario particular en lugar de un par de módulos 20,30. En este sistema conocido, puede haber una relación uno a muchos entre la clave de OTP y el dispositivo que use la clave de OTP para generar una contraseña. Cualquiera que sea el caso, si una clave de OTP está comprometida, los datos pueden ser accesados en beneficio de tal usuario mediante cualquier dispositivo que usa la clave de OTP. Como la clave de OTP típicamente será almacenada tanto en un número de testigos de OTP como también en el servidor de autentificación, establecer una nueva clave de OTP puede ser casi pesado en el servidor de autentificación, ya que el servidor de autentificación es requerido para reasignar tanto una nueva clave de generación de OTP al usuario como configurar una nueva serie de testigos de OTP con la nueva clave de generación de OTP.

En un arreglo, el segundo módulo 30 es también apareado con un módulo anterior, tal como un módulo de una tercera parte, y es arreglado para validar contraseñas asociadas con tal módulo adicional. En este caso, el segundo módulo 30 puede haber sido apareado con el módulo adicional durante un proceso de configuración en el cual un secreto es asignado a tanto el segundo módulo 30 como el módulo adicional. Se entenderá que, en general, el segundo módulo 30 podría ser apareado con cualquier número de módulos adicionales.

Como se describe anteriormente, en la modalidad mostrada en la Figura 1, en la cual los dos módulos 20,30 son dispositivos separados, es posible que un usuario remoto del segundo módulo 30, quién no es el propietario registrado del segundo módulo 30, pero ha establecido un enlace de comunicación con el segundo módulo 30 y de este modo está controlando el segundo módulo 30 de manera remota, está en posesión del primer módulo 20. Por ejemplo, el usuario remoto puede haber robado el primer módulo 20. El usuario remoto podría pedir acceder a los datos mediante el enlace de comunicación y después recuperar una contraseña generada por el primer módulo 20 e ingresar esta en el segundo módulo 30 mediante el enlace de comunicación. En este caso, el segundo módulo 30 podría validar la petición para acceso a los datos y podría permitir al usuario remoto acceder a los datos. En otras palabras, un usuario remoto en posesión del primer módulo 20 podría ser no distinguible de un usuario registrado del segundo módulo 30 quién está en posesión de tanto el primero y segundo módulos 20,30 debido a que el usuario remoto será capaz de recuperar la contraseña del primer módulo 20 e ingresarla en el segundo módulo 30.

La Figura 3 muestra un diagrama de bloque de una modalidad particular que atiende este escenario. En este arreglo el primero y segundo módulos 20,30 son partes compuestas de un dispositivo único 90. Los módulos 20,30 puede ser físicamente separados dentro del dispositivo 90, o los módulos 20,30 pueden ser físicamente conectados (es decir, integrados) dentro del dispositivo 90. Ventajosamente, pueden compartir algunos componentes dentro del dispositivo 90, tal como la fuente de energía (no mostrada). En cualquier caso, el primero y segundo módulos 20,30 son desconectados de manera comunicativa con respecto a cada uno del otro dentro del dispositivo 90. Como se apreciará, cuando el primero y segundo módulos 20,30 son partes compuestas de un dispositivo único 90, si un usuario 35 del segundo módulo 30 está en posesión del primer módulo 20 (y puede por lo tanto recuperar 60 la contraseña generada por el primer módulo 20), tal usuario debe también estar en posesión del segundo módulo 30. Cuando la contraseña generada por el primer módulo 20 es exhibida mediante la interfaz de usuario 21, entonces cuando el primero y segundo módulos 20,30 son partes compuestas de un dispositivo único, el segundo módulo 30 puede determinar a un nivel mayor de confianza si la petición para acceso a los datos 40 se origina de un usuario quién está en posesión del dispositivo 90. Esto es debido a que, como no existen medios de comunicación (ya sea directamente o indirectamente) entre el primero y segundo módulos 20,30, no existen medios para automáticamente o de manera remota transferir la contraseña generada por el primer módulo 20 al segundo módulo 30 y de este modo la contraseña tiene que ser físicamente recuperada de la interfaz de usuario 21 y entrar de manera manual mediante la interfaz de usuario 31 del segundo módulo 30.

En un arreglo, el secreto que es personalmente asignado al primero y segundo módulos 20,30 es una clave de generación de OTP y la contraseña que es generada por el primer módulo 20 es de este modo una contraseña de un solo uso (OTP). En esta modalidad, las contraseñas generadas subsecuentes por el primer módulo 20 son diferentes de las contraseñas previamente generadas, y cada contraseña generada es válida para un intento de autenticación solamente.

En un arreglo particular, la OTP generada es dependiente del tiempo y es válida por un periodo de tiempo predeterminado. En un arreglo alternativo, el primer módulo 20 puede generar una contraseña en dependencia de una contraseña previamente generada y una clave de generación de OTP.

En una modalidad particular de la presente invención, el primer módulo 20 comprende un reloj y la OTP es generada en dependencia del tiempo actual (es decir, el tiempo en el cual la OTP está siendo generada como medida por el reloj del primer módulo) y la clave de generación de OTP.

La OTP puede ser una función criptográfica de la clave de generación de OTP y el tiempo actual. En el caso de que el primer módulo 20 y el segundo módulo 30 son partes compuestas de un dispositivo 90, la OTP puede adicionalmente ser generada en dependencia con una ID de dispositivo personalmente asociado con el dispositivo 90. Tal dispositivo ID puede ser, por ejemplo, una función discontinua de la ID de la CPU del dispositivo 90, una función discontinua de una ID de GPU del dispositivo 90, o una combinación de los mismos. En este caso, la OTP puede ser una función criptográfica de la clave de generación de OTP, la ID del dispositivo y el tiempo actual. El tiempo actual se conocerá en la presente como el "tiempo de generación" TG, y se entenderá por haber sido medio con respecto al reloj del primer módulo 20. En este caso, una OTP particular generada puede solamente ser usada para validar una petición para acceso a los datos si se usa dentro de un periodo de tiempo predeterminado después del tiempo de generación TG.

En un arreglo, el segundo módulo 30 puede comprender un segundo reloj que es sincronizado con el reloj del primer módulo 20 (es decir, el "primer reloj"). Como el segundo módulo 30 a prueba de falsificaciones, el segundo reloj no puede ser alterado, y de este modo el segundo módulo 30 puede confiar que el segundo reloj es sincronizado con el primer reloj.

Después de recibir una contraseña de un usuario 35 del segundo módulo, el segundo módulo 30 usa el segundo reloj y la clave de generación de OTP para determinar si la contraseña recibida 70 del usuario 35 del segundo módulo 30 es la misma como una contraseña que ha/podria haber sido generada por el primer módulo 20 en un tiempo dentro de un tiempo predeterminado a partir del tiempo en el cual la contraseña fue recibida 70 por el segundo módulo 30. El tiempo en el cual la contraseña fue recibida 70 por el segundo módulo 30 se conocerá en la presente como el "tiempo de recepción" TR.

El método usado por el segundo módulo 30 para validar la contraseña recibida dependerá del método usado por el primer módulo 20 para generar la contraseña. Muchos de tales métodos son ya conocidos y el método especifico es considerado por estar fuera del alcance de la presente invención.

Si el segundo módulo 30 determina que la contraseña recibida se iguala con una OTP que ha/podria haber sido generada por el segundo módulo 30 en un tiempo TG que está dentro de un periodo predeterminado del tiempo de recepción TR, entonces el segundo módulo 30 valida la contraseña recibida, y puede de este modo determinar que es probable que la petición para acceso a los datos se origina de un usuario quién está en posesión del primer módulo 20 (y es por lo tanto no probable que esté en control remoto del segundo módulo 30). En el caso de que los datos solicitados sean almacenados en el segundo módulo 30 (o un dispositivo del cual el segundo módulo es un componente), el segundo módulo 30 entonces permite el acceso (etapa 80) a los datos solicitados. Alternativamente, el segundo módulo 30 puede ser configurado para solamente permitir a una persona particular (o un número de personas particulares) acceder a los datos, y en este caso, el segundo módulo 30 puede requerir que el usuario 35 del segundo módulo 30 ingrese credenciales (por ejemplo, una contraseña y nombre de usuario o un PIN) asociados con tal persona particular en el segundo módulo 30 antes de que se otorgue el acceso a los datos solicitados. Como un ejemplo particular, el usuario 35 del segundo módulo 30 puede haber solicitado acceso a un campo restringido mantenido en el elemento de seguridad 32 del segundo módulo 30. En este caso, si el segundo módulo verifica la contraseña recibida en la etapa 70 del usuario 35 del segundo módulo 30 y el usuario 35 suministra el PIN correcto asociado con la persona quién está permitida para tener acceso al archivo, entonces el segundo módulo 30 permite el acceso (etapa 80) a tal archivo.

El segundo módulo puede, en un arreglo, almacenar previamente contraseñas recibidas, y después de recibir una contraseña particular de un usuario 35 del segundo módulo 30, el segundo módulo 30 puede negar el acceso a los datos solicitados en asociación con tal contraseña particular si tal contraseña ha sido previamente recibida. De este modo, si un usuario 35 intenta replicar una OTP previamente validada (la cual fue generada por el primer módulo 20 en algún tiempo TG), el segundo módulo 30 rechazará tal OTP como una réplica de una OTP previamente recibida, aún si la OTP replicada es determinada por haber sido recibida dentro del tiempo predeterminado de TG (es decir, si el usuario 35 replica la OTP validad prontamente después que la OTP original fue recibida por el segundo módulo 30).

Como se mencionó anteriormente, cuando el primero y segundo módulos 20,30 son partes compuestas de un dispositivo 90, el primer módulo 20 puede generar contraseñas en dependencia de una ID de dispositivo del dispositivo 90. En este caso, un usuario 35 del segundo módulo 30 puede ser requerido para ingresar la ID del dispositivo en el segundo módulo 30 junto con la contraseña. El segundo módulo 30 puede entonces usar la ID del dispositivo proporcionado por el usuario 35, junto con el tiempo de recepción TR, para determinar si la contraseña recibida del usuario 35 es válida. El segundo módulo 30 puede también verificar de manera separada si la ID del dispositivo ingresado por el usuario 35 del segundo módulo 30 se iguala con la ID del dispositivo del dispositivo 90. En este caso, si la ID del dispositivo recibido del usuario 35 es incorrecto, el segundo módulo puede negar el acceso a los datos solicitados con respecto de si la contraseña recibida es válida. Requerir al usuario 35 proporcionar la ID del dispositivo único del dispositivo 90 incrementa la confianza, que el usuario 35 del segundo módulo 30 está en posesión del dispositivo 90. La ID del dispositivo podría alternativamente SER proporcionada al segundo módulo 30 por la aplicación que programa la interface del dispositivo 90. Esto proporciona algún aseguramiento adicional de que el segundo módulo 30 no ha sido robado y reemplazado en un dispositivo diferente.

En otro arreglo, en lugar de ser configurado con un reloj que es sincronizado con el reloj del primer módulo 20, el segundo módulo 30 puede preferiblemente tener acceso a una fuente de tiempo alternativo, la cual es externa al segundo módulo 30. Como un ejemplo particular, donde el primero y segundo módulos 20,30 son partes compuestas de un dispositivo 90, el segundo módulo 30 puede tener acceso a un reloj del dispositivo 90, y el reloj del dispositivo 90 puede ser usado como la fuente de tiempo. En este caso, después de recibir una contraseña de un usuario 35 del segundo módulo, el segundo módulo 30 puede obtener una marca de tiempo no de confianza (indicando el tiempo TR en el cual la contraseña fue recibida) a partir de la fuente de tiempo y puede usar la marca de tiempo no de confianza (junto con el secreto compartido y opcionalmente también una ID de dispositivo recibido del usuario 35 del segundo módulo 30) para validar la contraseña recibida como se describe anteriormente.

Por medio de clarificación, una fuente de tiempo no de confianza puede ser, por ejemplo, una fuente de tiempo que puede ser manipulada con o alterada sin el conocimiento del segundo módulo o una fuente de tiempo que proporciona marcas de tiempo no autentificadas las cuales pueden ser fácilmente replicadas. En el ejemplo particular anterior, el reloj del dispositivo 90 puede ser alterado por un usuario remoto, y por lo tanto que no se confia por el segundo módulo 30.

En este arreglo particular, una vez que el segundo módulo 30 ha validado una contraseña recibida, el segundo módulo 30 envía un mensaje que contiene la marca de tiempo usada para validar la contraseña recibida (es decir, la marca de tiempo que no se confía TR) a una tercera parte de confianza que tiene un reloj sincronizado con el reloj del primer módulo 20. La confianza puede haber sido establecida entre la tercera parte y el segundo módulo 30 por el intercambio de claves criptográficas para uso en la firma y de este modo autentificando mensajes enviados entre estos, como se discutirá en más detalle abajo.

Después de recibir el mensaje que contiene la marca de tiempo que no se confia, la tercera parte determina si el tiempo TR indicado por la marca de tiempo está dentro de un intervalo predeterminado del tiempo actual como medida por el reloj de la tercera parte. Si el tiempo TR es determinado por estar dentro del intervalo predeterminado del tiempo actual y el mensaje indica que la contraseña recibida por el segundo módulo 30 es válida, la tercera parte determina confiar que el usuario 35 del segundo módulo 30 está en posesión de tanto el primero y segundo módulos 20,30. Esto es debido a que, si el segundo módulo 30 ha validado positivamente una contraseña recibida usando la marca de tiempo TR, entonces el usuario 35 del segundo módulo 30 debe haber proporcionado una contraseña que podría haber sido generada por el primer módulo 20 en un tiempo TG que es cercano a TR. Sigue entonces que, si TR está cercano al tiempo actual, entonces TG debe también estar cercano al tiempo actual y de este modo se puede determinar que un usuario 35 del segundo módulo 30 debe haber proporcionado una contraseña que ha/podría haber sido generada por el primer módulo 20 en algún tiempo TG cercano al tiempo actual, y de este modo que el usuario 35 del segundo módulo 30 es probable que actualmente esté en posesión del primer módulo 20. Como no existe forma para transferir automáticamente una contraseña generada por el primer módulo 20 al segundo módulo 30, es muy probable que la persona en posesión del segundo módulo 20 también esté en posesión del primer módulo 30 y pueda de este modo transferir la contraseña generada por el primer módulo 20 al segundo módulo 30 manualmente.

Ventajosamente, si la tercera parte determina que la marca de tiempo TR no está dentro del intervalo predeterminado del tiempo actual, y por lo tanto se obtuvo de una fuente de tiempo que no está sincronizada con el reloj del primer módulo 20, la tercera parte puede invocar un procedimiento de resincronización para resincronizar la fuente de tiempo.

En el presente arreglo, la tercera parte de confianza entonces envía un mensaje al segundo módulo 30 lo cual indica si el tiempo TR está dentro del intervalo de tiempo predeterminado. Si el tiempo TR está dentro del intervalo de tiempo predeterminado, el segundo módulo 30 permite el acceso a los datos solicitados. Alternativamente, si el tiempo TR está fuera del intervalo de tiempo predeterminado, el segundo módulo niega el acceso a los datos solicitados.

El usuario 35 del segundo módulo 30 puede solicitar acceder a los datos que se mantengan externamente por una tercera parte de confianza. En este caso, la tercera parte puede tener acceso a un reloj que es sincronizado con el reloj del primer módulo 20, tal como un reloj que corre en tiempo universal. En el caso de que el segundo módulo 30 ha validado una contraseña recibida del usuario 35 del segundo módulo 30 (usando una marca de tiempo proporcionada por una fuente de tiempo que no se confia externa al segundo módulo 30 como se describe anteriormente), el segundo módulo 30 está configurado para enviar una petición para acceso a los datos a la tercera parte. La petición contiene tanto una indicación que una contraseña recibida por el segundo módulo 30 en asociación con una petición para acceso a los datos ha sido validada como también una marca de tiempo para indicar el tiempo TR (obtenido a partir de la fuente de tiempo que no se confía) que fue usado para validar la contraseña. Después de recibir la petición del segundo módulo 30, la tercera parte determina si el tiempo TR está dentro de un intervalo predeterminado del tiempo actual, como se describe anteriormente, y responsablemente ya sea envía los datos solicitados al segundo módulo 30 o niega el acceso.

En los ejemplos anteriores, el segundo módulo 30 puede almacenar OTPs previamente recibidas y puede invalidar cualquiera de las OTPs que han sido previamente recibidas. Esto es particularmente útil para situaciones en las cuales el segundo módulo 30 es simultáneamente accesado tanto por un usuario remoto 35 como un usuario 35 en posesión de tanto el primero como segundo módulos 20,30 (es decir, un usuario local 35). Asumiendo que el usuario remoto 35 intenta acceder a los datos replicando una OTP que fue previamente ingresada en el segundo módulo 30 por el usuario local 35, el segundo módulo 30 rechazará la OTP replicada como un duplicado. En un arreglo, el segundo módulo 30 puede almacenar un número limitado de OTPs previamente recibidas y, si una OTP particular, la cual ha sido previamente recibida por el segundo módulo 30 pero la cual no es más almacenada por el segundo módulo 30, es replicada, la tercera parte 100 es probable que rechace la OTP debido a que será asociada con una marca de tiempo que está fuera del intervalo predeterminado del tiempo actual.

Como se mencionó anteriormente, el mensaje que contiene la marca de tiempo usada por el segundo módulo 30 para validar una contraseña recibida puede ser firmado por el segundo módulo 30 (por ejemplo, usando una(s) clave(s) criptográfica(s)) asociadas con el segundo módulo 30 y la tercera parte), de este modo permitiendo a la tercera parte verificar el origen del mensaje. Esto significa que, si el usuario remoto 35 intenta alterar un mensaje enviado por el segundo módulo 30 que contiene una marca de tiempo que no se confia, la tercera parte reconocerá que el mensaje ha sido alterado debido a que no contendrá la firma correcta del segundo acceso, y negará el acceso a los datos solicitados asociados. Los mensajes que han sido alterados por algún otro que el remitente original son comúnmente referidos como "mensajes falsos".

Además, si la tercera parte de confianza está configurada para enviar un mensaje al segundo módulo 30 para indicar si una marca de tiempo recibida es válida, tal mensaje también puede ser firmado. Esto permite al segundo módulo 30 identificar mensajes enviados al segundo módulo 30 por una parte distinta a la tercera parte de confianza, lo cual no puede ser de confianza.

En otro arreglo, en lugar de obtener una marca de tiempo para uso en la validación de una contraseña recibida a partir de una fuente de tiempo que no se confia, el segundo módulo 30 puede obtener una marca de tiempo a partir de una tercera parte de confianza que tiene un reloj que es sincronizado con el reloj del primer módulo 20. Como en el ejemplo anterior, la tercera parte y el segundo módulo 30 pueden firmar y de este modo autentificar mensajes enviados entre estos usando claves criptográficas por ejemplo, y de este modo marcas de tiempo que son firmadas por la tercera parte pueden ser de confianzas por el segundo módulo 30. En un arreglo particular, después de recibir la petición para acceso a los datos en la etapa 40 de un usuario 35, el segundo módulo 30 puede enviar un mensaje a la tercera parte solicitando una marca de tiempo, y la tercera parte puede responder enviando un mensaje que contiene una marca de tiempo para indicar el tiempo en el cual la petición para una marca de tiempo fue recibida (como medida por el reloj de la tercera parte).

Si el segundo módulo 30 subsecuentemente recibe una contraseña del usuario 35 del segundo módulo 30, el segundo módulo 30 usa la marca de tiempo recibida, lo cual es asumido para indicar un tiempo cercano a TG, junto con la clave de generación de OTP y opcionalmente también una ID de dispositivo recibida del usuario 35 del segundo módulo 30, para determinar si la contraseña recibida corresponde a una contraseña que ha/podria haber sido generada por el primer módulo 20 en un tiempo dentro de un intervalo de tiempo predeterminado del tiempo indicado en la marca de tiempo recibida.

En un arreglo, si el segundo módulo 30 determina que la contraseña recibida corresponde a una contraseña que ha/podria haber sido generada por el primer módulo 20 en un tiempo dentro del intervalo predeterminado del tiempo indicado en la marca de tiempo recibida, el segundo módulo 30 envía un mensaje a la tercera parte confirmando la marca de tiempo usada para validar la contraseña, y la tercera parte hace una predeterminación de como el acceso a los datos de petición asociados debe ser permitido en dependencia de (a) si la marca de tiempo está dentro de un intervalo predeterminado del tiempo actual y (b) si la marca de tiempo se iguala con la marca de tiempo enviada por la tercera parte al segundo módulo 30. El mensaje puede ser firmado por el segundo módulo 30, y después de la recepción de este mensaje, la tercera parte puede también verificar si el mensaje es firmado por el segundo módulo 30 y puede negar el acceso a cualquiera de los datos que han sido solicitados por el segundo módulo 30 en asociación con un mensaje que contiene una marca de tiempo que no es firmada por el segundo módulo 30.

Es posible que un usuario remoto 35 del segundo módulo 30 pueda observar una OTP ingresada por un usuario en posesión de tanto el primero como segundo módulos 20,30 y puede también observar la marca de tiempo recibida de la tercera parte. Tal usuario remoto puede, en algún tiempo después, suministrar el segundo módulo 30 con la marca de tiempo observada y la OTP observada. En este caso, si el segundo módulo 30 no almacena previamente OTPs recibidas o solamente almacena un número predeterminado de OTPs previamente recibidas por ejemplo, el segundo módulo 30 puede validar la contraseña del usuario remoto. Sin embargo, como el segundo módulo 30 entonces envía la marca de tiempo usada para validar la contraseña a la tercera parte, la tercera parte es capaz de identificar tal marca de tiempo como estando fuera de la fecha y negará el acceso a los datos solicitados por consiguiente.

La siguiente descripción con referencia a las Figuras 4 a 6 expone un número de modalidades ejemplares específicas de la presente invención. En los siguientes ejemplos, el primero y segundo módulos 20,30 son partes compuestas de un dispositivo 90 y, como se describe anteriormente con referencia a la Figura 1 por ejemplo, son para uso en la generación y validación de OTPs respectivamente. El primero y segundo módulos 20,30 están también desconectados de manera comunicativa de entre si. En los siguientes ejemplos, el primero y segundo módulos 20,30 comparten una clave de generación de OTP que ha sido personalmente asignada al primero y segundo módulos 20,30. En cada ejemplo, el primer módulo 20 está configurado para generar OTPs como una función criptográfica del tiempo de generación (como medida por un reloj del primer módulo 20), la clave de generación de OTP, y un número de identificación de dispositivo único. En cada uno de los siguientes casos, el dispositivo 90 comprende dos interfaces de usuario separadas 21,31. La interfaz de usuario 21 del primer módulo 20 comprende un botón y una pantalla, el botón está configurado para causar al primer módulo para generar una contraseña y la pantalla es configurada para presentar una contraseña generada a un usuario 25 del primer módulo 20. La interfaz de usuario 31 del segundo módulo 30, por otro lado, comprende al menos una pantalla y un teclado.

La Figura 4 muestra esquemáticamente un método ejemplar para compartir claves criptográficas temporales entre un proveedor de servicios bancarios 101 y el segundo módulo 30 del dispositivo 90. En este ejemplo, el proveedor del servicio bancario 101 ha compartido temporalmente claves criptográficas con otro proveedor del servicio 102 (véase Figura 5) y junto con las claves criptográficas compartidas con el proveedor de servicio 102 y las claves criptográficas compartidas con el segundo módulo 30 son para uso en la autentificación y/o encriptación/desencriptación de mensajes enviados entre el segundo módulo 30 y el proveedor del servicio 102, como se discutirá en más detalle abajo.

El segundo módulo 30 y el proveedor del servicio bancario 101 ya han pre-asignado claves criptográficas para uso en la encriptación y autentificación de mensajes enviados entre estos, como se discute anteriormente. Además, el proveedor del servicio bancario 101 almacena una asociación entre el dispositivo 90 y un titular de la cuenta de banco particular.

En este ejemplo, el segundo módulo 30 no tiene un reloj que es sincronizado con el reloj del primer módulo 20 y el dispositivo 90 es registrado con el proveedor del servicio bancario 101.

El proveedor del servicio bancario 101 tiene un reloj que es sincronizado con el reloj del primer módulo 20 (por ejemplo, el reloj puede correr en tiempo universal). En este ejemplo particular, un usuario 35 del segundo módulo 30 del dispositivo 90 solicita (etapa 40) una clave criptográfica temporal del proveedor del servicio bancario 101. Cuando se solicita acceso a la clave criptográfica temporal, el usuario 35 del segundo módulo 30 puede ingresar información en el segundo módulo 30 que identifica al titular de la cuenta de banco particular con respecto de lo cual el usuario 35 desea obtener una clave criptográfica temporal.

Después de recibir la petición para una clave criptográfica temporal 40, el segundo módulo 30 envía un mensaje (etapa 130) al proveedor del servicio bancario 101 para indicar que una petición para acceso a una clave criptográfica temporal se ha hecho por un usuario 35 del dispositivo 90 y para indicar que el dispositivo 90 tiene módulos 20,30 para generar y validar contraseñas. Este mensaje (enviado en la etapa 130) informa al proveedor del servicio bancario 101 que el dispositivo 90 es capaz de determinar si la petición (en la etapa 40) para acceso a una clave criptográfica temporal se origina de un usuario en posesión física del dispositivo 90, y también avisa el proveedor del servicio bancario 101 para proporcionar (etapa 140) una marca de tiempo para indicar el tiempo actual como medida por el reloj del proveedor del servicio bancario 101. La marca de tiempo es firmada por el proveedor del servicio bancario 101 y de este modo el segundo módulo 30 puede confiar que la marca de tiempo fue recibida a partir del proveedor del servicio bancario de confianza 101 y por lo tanto que la marca de tiempo es de confianza y fue generada por un reloj que es sincronizado con el reloj del primer módulo 20.

El mensaje 130 también puede identificar el dispositivo 90 (y de este modo el titular de la cuenta del banco quién está asociado con el dispositivo 90) al proveedor del servicio bancario 101 por ejemplo, enviando la ID del dispositivo asociados con el dispositivo 90 al proveedor del servicio bancario 101.

Después de recibir el mensaje (en la etapa 140), el segundo módulo 30 avisa el usuario del segundo módulo para ingresar una contraseña que ha sido generada por el primer módulo 20 del dispositivo 90 y también la ID del dispositivo único del dispositivo 90. En este ejemplo particular, el usuario 35 del segundo módulo 30 está en posesión del dispositivo 90, y es por lo tanto también el usuario 25 del primer módulo 20. De este modo el usuario 25,35 del dispositivo 90 puede presionar el botón de la interfaz de usuario del primer módulo 20 y causar al primer módulo 20 para generar una OTP (etapa 50). El usuario 25 puede entonces recuperar la contraseña generada (etapa 60) a partir de la pantalla del primer módulo 20, y puede ingresar la contraseña recuperada junto con la ID del dispositivo del dispositivo 90 en la interfaz de usuario 31 del segundo módulo 30 (etapa 70).

Como se mencionó anteriormente, después de la recepción del mensaje 130, el proveedor del servicio bancario 101 envía un mensaje firmado (etapa 140) que contiene una marca de tiempo al segundo módulo 30. Este mensaje 140 puede incluir también un desafío para el usuario 25,35 del dispositivo 90. Como un ejemplo particular, el mensaje enviado en la etapa 140 puede desafiar al usuario 25,35 del dispositivo 90 para ingresar credenciales (tal como un nombre de usuario y un PIN) que ha sido pre-agregado entre el proveedor del servicio bancario 101 y el titular de la cuenta del banco asociada con el dispositivo 90. Esto tiene la ventaja de que el proveedor del servicio bancario 101 es capaz de verificar si el usuario 35 del segundo módulo 30 es el titular de la cuenta del banco asociada con el dispositivo 90 o si el usuario 35 es una persona diferente (quien puede haber robado el dispositivo 90, por ejemplo).

Después de la recepción de la contraseña y el dispositivo ID del usuario 35 del segundo módulo 30 (en la etapa 70), el segundo módulo 30 usa la marca de tiempo dentro del mensaje recibido en la etapa 140 para verificar la contraseña. En el presente arreglo, el segundo módulo verifica la contraseña recibida usando la marca de tiempo, la generación clave OTP que ha sido asignada al primero y segundo módulos 20, 30, y el dispositivo ID recibido del usuario 35 para determinar si la contraseña recibida coincide con cualquiera de las contraseñas que se puedan haber generado por el primer módulo 20 en el tiempo TG que es igual o cercano al tiempo proporcionado en la marca de tiempo recibida. La diferencia de tiempo máxima entre la marca de tiempo y TG por la cual el segundo módulo 30 podrá determinar una contraseña recibida para ser válida puede ser establecida por el segundo módulo 30 o del proveedor de servicios bancarios 101, y en este último caso, la diferencia de tiempo máxima se puede indicar por el segundo módulo 30 en el mensaje 140.

Si el segundo módulo 30 determina que la contraseña recibida del usuario 35 del segundo módulo 30 es correcto, el segundo módulo 30 presenta la estimulación recibida en la etapa 140 en el mensaje que se ha enviado desde el proveedor de servicios bancarios 101 al segundo módulo 30 para el usuario 35 y el usuario 35 del segundo módulo 30 entonces responde (etapa 150) a esta estimulación.

Después de la recepción en la etapa 150, la respuesta a la estimulación, el segundo módulo 30 envía (etapa 160) un mensaje firmado indicando que una OTP recibida se encuentra ser válido, confirmando el tiempo de uso para verificar que la OTP recibida, y también que contiene la respuesta a la estimulación recibida (en la etapa 150) desde el usuario 35 del segundo módulo. En este ejemplo, la respuesta es encriptada.

Si, por otra parte, el segundo módulo 30 no valida exitosamente la contraseña recibida, el segundo módulo 30 envía un mensaje firmado (etapa 160) al proveedor de servicios bancarios 101 indicando que la OTP recibida se encontró ser inválida. En un arreglo particular, el mensaje enviado desde el segundo módulo 30 al proveedor de servicios bancarios 101 en la etapa 160 contiene los resultados de validación OTP, en la marca de tiempo, y una respuesta de estimulación, independiente si el resultado de validación es positivo o negativo. Esto asegura que los mensajes enviados en la etapa 160 son indistinguibles y no pueden proporcionar una parte no autorizada con información adicional para lanzar una navegación del ataque al servicio.

Si el mensaje enviado en la etapa 160 indica que la OTP recibida fue validado y si el tiempo usado para verificar la OTP recibida se iguala al tiempo indicado en la marca de tiempo enviado en la etapa 140 y está dentro de un intervalo determinado del tiempo actual, entonces el proveedor de servicios bancarios 101 determina si la respuesta al estímulo recibido en la etapa 150 desde el usuario 35 del segundo módulo es correcto. Por ejemplo en el caso que la estimulación es un requisito para el usuario 35 al ingresar un PIN que ha sido pre-convertido entre el proveedor de servicio bancario 101 y el titular de la cuenta de banco identificado (el cual está asociado con el dispositivo 90), el proveedor de servicio bancario 101 puede determinar si el PIN ingresado por el usuario 35 del segundo módulo 30 iguala el PIN del titular de la cuente bancaria identificado. Si el proveedor de servicio bancario 101 determina que la respuesta (a 150) a la estimulación es correcta, el proveedor de servicio bancario 101 puede enviar (etapa 120) la clave criptográfica temporal solicitada al segundo módulo 30, donde es entonces almacenada.

En una modalidad alternativa, el segundo módulo 30 puede ser pre-posicionado con un secreto para uso en la presentación a un estimulo para el usuario 35 del segundo módulo 30. Por ejemplo, el secreto puede ser un PIN asociado con el titular de la cuenta de banco asociado con el dispositivo 90, y en este caso, el segundo módulo 30 puede estimular al usuario 35 del segundo módulo 30 a ingresar el PIN. El segundo módulo 30 puede entonces usar el secreto para validar la respuesta al estimulo recibido del usuario 35 del segundo módulo 30 en la etapa 150, y puede indicar el resultado de la verificación al proveedor de servicio bancario 101 en la etapa 160.

Si en mensaje enviado en la etapa 160 desde el segundo módulo 30 indica que la OTP recibida desde el usuario 35 del segundo módulo no fue validad exitosamente o si el tiempo usado por el segundo módulo 30 está fuera del intervalo predeterminado del tiempo actual o no iguala el tiempo y fecha enviado a la etapa 140, el proveedor de servicio bancario 101 niega el acceso a la clave criptográfica temporal solicitada.

En un ejemplo alternativo, más bien el proveedor de servicio bancario 101 que genera y distribuye la clave criptográfica temporal, la clave criptográfica temporal puede ser generada por el proveedor de servicio 102 (véase Fig.5) y enviada al proveedor de servicio bancario 101, el cual entonces puede determinar si compartir esa clave con el segundo módulo 30 como en el caso si la clave criptográfica temporal es generada por el proveedor de servicio bancario 101. Alternativamente, la clave criptográfica temporal puede ser generada por el segundo módulo 30, y puede ser enviada al proveedor de servicio bancario 101 en el mensaje 130 por ejemplo. En este ordenamiento, el proveedor de servicio bancario 101 puede entonces compartir esa clave criptográfica temporal con un proveedor de servicio 102 si se determina que el usuario 35 del segundo módulo 30 ha ingresado correctamente una contraseña que fue generada por el primer módulo 20 en el segundo módulo 30.

La figura 5 muestra esquemáticamente etapas adicionales de conformidad con una modalidad de la presente invención, la cual se puede llevar a cabo por el proveedor de servicio 102 y el segundo módulo 30 una vez que el segundo módulo 30 ha recibido las claves criptográficas temporales del proveedor de servicio bancario 101. Como se menciona anteriormente, el dispositivo 90 es registrado con un proveedor de servicio bancario 101 como propiedad de un titular de cuenta bancaria particular y el proveedor de servicio bancario 101 comparte las claves criptográficas temporales con un proveedor de servicio 201, los cuales está asociados con el titular de la cuenta de banco. El proveedor de servicio 102 puede ya conocer al titular de la cuenta de banco el cual es el propietario registrado del dispositivo 90, y en este caso, cuando las claves criptográficas temporales son compartidas con el proveedor de servicio 102, el titular de la cuenta de banco que está asociado con aquellas claves es identificado por el proveedor de servicio 102. Alternativamente, si el titular de la cuenta de banco aún no es conocido por el proveedor de servicio 102, el proveedor de servicio bancario 101 puede enviar al proveedor de servicio 102 información para uso en la identificación y proporcionar un servicio al titular de la cuenta de banco cuando las cuentas criptográficas temporales asociadas se comparten.

En el presente ejemplo, un usuario 35 del segundo módulo 30 solicita (etapa 40) acceso a un servidor para uso en la realización de un pago o transferencia de fondos de la cuenta del titular de la cuenta de banco asociado con el dispositivo 90. En este ejemplo particular, el servidor es para uso en facilitar un pago persona a persona (P2P) por medio del dispositivo 90 de la cuenta del titular de la cuenta de banco asociado con el dispositivo 90. Cuando se requiere (etapa 40) acceso al servidor P2P, el usuario 35 del segundo módulo 30 puede ingresar información en el segundo módulo 30 que identifica al titular de la cuenta de banco con respecto del cual el usuario 35 quiere obtener servicios P2P.

La recibir la solicitud (etapa 40) del usuario 35 del segundo módulo 30, el segundo módulo 30 avisa al usuario 35 para ingresar una OTP generada por el primer módulo 20 del dispositivo 90 y también el dispositivo ID único del dispositivo 90. La recibir una contraseña del usuario 35, el segundo módulo 30 recupera una marca de tiempo desde un reloj del dispositivo 90, indicando el tiempo TR, medido por este reloj, en el cual la contraseña fue recibida por el segundo módulo 30. El segundo módulo entonces usa esta marca de tiempo, junto con la generación de clave OTP y el dispositivo ID recibido del usuario 35, para determinar si verifica la contraseña recibida. Como se discutió anteriormente, el reloj del dispositivo 90 no es de confianza por el segundo módulo 30 y asi en este caso, si el segundo módulo 30 determina que la contraseña recibida del usuario 35 del segundo módulo 30 iguala la contraseña que fue/habria sido generada por el primer módulo (es decir, el segundo módulo 30 válida la contraseña recibida), el segundo módulo envía un mensaje (etapa 180) al proveedor de servicio 102, el cual es encriptado y firmado usando las claves criptográficas temporales almacenadas en el segundo módulo 30, con ello se previene que los contenidos del mensaje sean descubiertos y permitiendo al proveedor de servicio 102 verificar el origen del mensaje (es decir, permitir al proveedor de servicio 102 verificar que el mensaje no ha sido manipulado). El mensaje enviado en la etapa 180 comprende una indicación que se ha realizado una solicitud de acceso al servidor P2P en nombre de un titular de cuenta bancaria particular; una indicación que el segundo módulo 30 del dispositivo 90 ha validado la contraseña recibida del usuario 35; y una indicación del tiempo (medido por un reloj del dispositivo 90) en el cual la contraseña fue recibida desde el usuario 35 del segundo módulo (es decir, el tiempo de recepción).

En la recepción de un mensaje que contiene un resultado de validación positivo del segundo módulo 30 (etapa 180), el proveedor de servicio 102 usa las claves criptográficas temporales que se comparte entre el proveedor de servicio bancario 101 y el proveedor de servicio 102 para verificar si el mensaje es firmado por la clave criptográfica temporal que se comparte entre el proveedor de servicio bancario 101 y el segundo módulo 30 (es decir, la clave criptográfica temporal asociada con el segundo módulo 30).

Si el proveedor de servicio 102 determina que el mensaje ha sido firmado usando la clave criptográfica temporal asociada con el segundo módulo 30, el proveedor de servicio 102 entonces usa un reloj que es sincronizado con el reloj del primer módulo 20 para determinar si el tiempo de recepción está dentro de un intervalo predeterminado del tiempo actual. El proveedor de servicio 102 puede también comparar la marca de tiempo recibida con las marcas de tiempo previamente recibidas desde el segundo módulo 30. Si el proveedor de servicio 102 determina que el tiempo de recepción está fuera del intervalo de tiempo predeterminado, o que la marca de tiempo es un duplicado de una marca de tiempo previamente recibida, el proveedor de servicio 102 niega el acceso al servidor P2P. Sin embargo, si el proveedor de servicio 102 determina que el tiempo de recepción está dentro del intervalo de tiempo predeterminado y no es un duplicado, el proveedor de servicio 102 permite acceso al servidor P2P (etapas 190 y 80) . Como se discutió anteriormente, en esta modalidad usando una fuente de tiempo no confiable para validar una contraseña recibida no presente un problema porque, a pesar que un usuario remoto 35 del segundo módulo 30 puede ser capaz de observar y repetir una combinación OTP-marca de tiempo correcta y con ello provocar que el segundo módulo 30 valide la contraseña repetida, el proveedor de servicio 102 puede rechazar la marca de tiempo repetida o fuera de tiempo y podrá denegar acceso a los datos solicitados asociados.

La figura 6 muestra esquemáticamente una modalidad alternativa de la presente invención en la cual, más bien una solicitud para acceder a los datos a ser recibidos en el segundo módulo 30 desde un usuario 35 del segundo módulo 30, una solicitud (etapa 200) para acceso a los datos es en su lugar recibida en el segundo módulo 30 desde una tercera parte 100. En particular, en este escenario, una tercera parte 100 desea determinar si existe un usuario 35 del segundo módulo 30 que está en posesión física del segundo módulo 30 y asi la tercera parte 100 envía un mensaje (etapa 200) al segundo módulo 30 indicando lo mismo. En la recepción de este mensaje, el segundo módulo 30 avisa (etapa 205) al usuario 35 del segundo módulo 30 a ingresar una contraseña que ha sido generada por el primer módulo 20 en el segundo módulo 30. Si sucede que hay un usuario 35 en posesión del segundo módulo 30, que también está en posesión del primer módulo 20, entonces este usuario 25, 35 puede (por medio de las etapas 50, 60 y 70) ingresar una contraseña generada por el primer módulo 20 en el segundo módulo 30.

En la recepción de una contraseña (etapa 70), el segundo módulo 30 usa cualquiera de los métodos resumidos anteriormente con referencia a las Figuras 1 a 5 para determinar si la contraseña recibida corresponde a la contraseña que fue generada por el primer módulo 20 y envía (etapa 210) una indicación de la validación del resultado a la tercera parte 100. La tercera parte podrá entonces determinar si confia que el usuario 35 del segundo módulo 30 está en posesión del segundo módulo 30 en dependencia con el resultado de validación (y opcionalmente también factores adicionales como se describe anteriormente).

Puede ser que la tercera parte desee verificar si una persona particular está en posesión del segundo módulo 30 y en este caso, el segundo módulo 30 puede presentar una estimulación al usuario 35 del segundo módulo 30 como se describe anteriormente con referencia a la Figura 4.

A continuación se expone un aspecto alternativo de la presente invención. En una modalidad ejemplar de conformidad con este aspecto, un dispositivo 90 comprende un primer y segundo módulos 20, 30 los cuales están comunicativamente desconectadas entre si como en las modalidades previas descritas anteriormente con referencia a la Figura 1, por ejemplo. En otras palabras, el dispositivo 90 está construido y configurado de tal forma que no hay medios de comunicación (ya sea directamente o indirectamente) entre los dos módulos 20, 30. Los primero y segundo módulos 20, 30 pueden estar integrados dentro del dispositivo 90 o pueden tener circuitos y componentes completamente separados. El primer módulo 20 es de nuevo para usarse en la generación de contraseñas y el segundo módulo es nuevamente para usarse en la validación de contraseñas recibidas, las cuales pueden ser recibidas desde un usuario 35 del segundo módulo 30. El primer módulo 20 está configurado con un secreto y comprende circuitos y/o software que es construido y configurado para generar contraseñas en base al secreto. Sin embargo, a diferencia de los arreglos descritos previamente, este secreto no ha sido únicamente asignado al primero y segundo módulos 20, 30. En este arreglo, puede existir cualquier número de módulos configurados con el mismo secreto, el cual puede o no puede incluir el segundo módulo 30. En un ejemplo particular, el secreto puede estar asociado con una persona particular, y puede ser pre-posicionada en un número de módulos mantenidos por esta persona, cada uno de estos módulos son para usarse en la generación de contraseñas y para usarse en la determinación (hasta un nivel razonable de confianza) si una solicitud de acceso a los datos se hace por medio de uno de aquellos dispositivos originados desde un usuario en posesión del dispositivo 90.

Ya que los arreglos previamente descritos, en la recepción de una solicitud para acceso a datos (etapa 40) desde un usuario 35 del segundo módulo 30, el segundo módulo 30 está configurado para solicitar al usuario del segundo módulo 30 ingresa una contraseña generada por el primer módulo 20 del dispositivo 90.

En un arreglo, en respuesta a la recepción de una indicación que se ha hecho una solicitud para acceso a los datos (por ejemplo, en respuesta al usuario 25 del primer módulo 20 presionando un botón) el primer módulo 20 es configurado para usar el secreto asignado al primer módulo 20 para generar una contraseña y proporcionar la contraseña generada al usuario 25 del primer módulo 20. En un arreglo alternativo, el primer módulo 20 puede ser configurado para usar el secreto para generar contraseñas automáticamente a intervalos de tiempo regulares.

Si el usuario 35 del segundo módulo 30 está en posesión del dispositivo 90, entonces el usuario 35 es capaz de recuperar la contraseña desde el primer módulo 20 (por ejemplo, desde una pantalla del primer módulo 20) e ingresar la contraseña recuperada en el segundo módulo 30 del dispositivo 90 (por ejemplo, por medio de un teclado del segundo módulo 30).

El segundo módulo 30 puede ser un módulo de la forma que este módulo está pre-posicionado dentro del mismo secreto como el primer módulo 20, y en este caso, el segundo módulo 30 usa el secreto para determinar si la contraseña recibida desde el usuario 35 del segundo módulo 30 corresponde a una contraseña que fue/habria sido generada por el primer módulo 20 del dispositivo 90 (o cualquier otro módulo que usa este secreto para generar contraseñas). En este caso, el segundo módulo 30 puede usar cualquiera de los metodos exhibidos anteriormente (es decir, cualquiera de los métodos descritos anteriormente con referencia a las Figuras 1 a 5) para determinar si la contraseña recibida desde el usuario 35 del segundo módulo 35 corresponde a una contraseña que fue/habria sido generada por el primer módulo 20 del dispositivo 90. Como en los ordenamientos descritos anteriormente, el secreto compartido entre el primero y segundo módulos 20, 30 puede ser una clave de generación por OTP, y el primer módulo 20 puede generar OTP en dependencia con la clave de generación por OTP y el tiempo actual. En este caso, dependiendo si el segundo módulo tiene un reloj que está sincronizado con el reloj usado por el primer módulo 20 para generar la contraseña, el segundo módulo 30 puede usar cualquiera de los métodos exhibidos anteriormente.

Si el segundo módulo 30 determina que la contraseña recibida desde el usuario 35 del segundo módulo 30 corresponde a una contraseña que fue/habria sido generada por el primer módulo 20 del dispositivo 90, el segundo módulo válida la contraseña recibida.

La figura 7 muestra esquemáticamente un arreglo alternativo en el cual se usa el secreto por el primer módulo 20 para generar una contraseña que no es conocida por el segundo módulo 30, pero en lugar es compartida entre un servidor de autenticación 230 y el primer módulo 20. En este caso, un usuario 35 del segundo módulo 30 solicita acceso a los datos (etapa 40), y el segundo módulo 30 entonces avisa al usuario 35 para ingresar una contraseña generada por el primer módulo del dispositivo 90. Si el usuario 35 del segundo módulo 30 está en posesión del dispositivo 90 puede recuperar (etapa 60) una contraseña generada por el primer módulo 20 e ingresar (etapa 70) en el segundo módulo 30.

En este arreglo particular, para determinar si para validar la contraseña recibida, el segundo módulo 30 envía un mensaje (etapa 240) al servidos de autenticación 230 que contiene la contraseña recibida desde el usuario 35 del segundo módulo 30. Ventajosamente, el mensaje enviado a la etapa 240 puede ser firmado por la tercera parte 230 de manera que no puede ser falsificada, como se discutió en detalle anteriormente.

En la recepción del mensaje enviado a la etapa 240, el servidos de autenticación 230 usa el secreto que se comparte entre el servidor de autenticación y el primer módulo 20 para determinar si la contraseña recibida del usuario 35 del segundo módulo 30 corresponde a una contraseña que fue/habria sido generada por el primer módulo 20 del dispositivo 90. Como en el ejemplo previo, el secreto que es compartido entre el servidor de autenticación 230 y el primer módulo 20 puede ser una clave de generación OTP, y el primer módulo 20 puede ser configurado para generar OTP en dependencia con el tiempo actual (como se mide por un reloj del primer módulo) y la clave de generación OTP. En este caso, el servidor de autenticación puede tener un reloj que está sincronizado con el reloj del primer módulo 20 para uso en la validación de las contraseñas recibidas.

En un arreglo particular, el secreto que se comparte entre el servidor de autenticación 230 y el primer módulo 20 está asociado con una persona particular, y el servidor de autenticación almacena en asociación entre la persona particular y el secreto. En este caso, el mensaje enviado en la etapa 240 que contiene la contraseña recibida desde el usuario 35 del segundo módulo 30 también contiene información que únicamente identifica la persona asociada con el secreto al servidor de autenticación. El servidor de autenticación 230 puede guardar muchos secretos, cada una siendo asociado con una diferente persona, y asi el mensaje 240 permite al servidor de autenticación 230 determinar cual secreto se usa para determinar si la contraseña recibida desde el usuario 35 del segundo módulo 30 corresponde a una contraseña que fue/habria sido generada por el primer módulo 20 del dispositivo 90.

En este caso, si el servidor de autenticación 230 determina que la contraseña recibida desde el usuario 35 del segundo módulo 30 corresponde a una contraseña que fue/habria sido generada por el primer módulo 20, el servidor de autenticación 230 envía un mensaje (etapa 250) al segundo módulo 30 indicando que la contraseña recibida desde el usuario 35 del segundo módulo 30 es válida y en la recepción de este mensaje, el segundo módulo valida la contraseña recibida.

Por otra parte, si el servidor de autenticación 230 determina que la contraseña recibida desde el usuario 35 del segundo módulo 30 no corresponde a una contraseña que fue/habría sido generada por el primer módulo 20, el servidor de autenticación 230 envía un mensaje (etapa 250) al segundo módulo 30 indicando que la contraseña recibida desde el usuario 35 del segundo módulo 30 no es válida, y el segundo módulo invalida la contraseña recibida.

El secreto que se comparte entre el servidor de autenticación 230 y el primer módulo 20 puede alternativamente estar asociada con el primer módulo 20 solamente y el servidor de autenticación 230 puede almacenar en asociación entre el primer módulo 20 (o el dispositivo 90 del cual primer módulo 20 es un componente) y el secreto. En este caso, el mensaje enviado en la etapa 240 que contiene la contraseña desde el usuario 35 del segundo módulo 30 puede también contener información (por ejemplo, el dispositivo ID único) que solamente identifica el dispositivo 90.

Ventajosamente, el mensaje enviado en la etapa 250 puede ser firmado por la tercera parte 230 de forma que no pueda ser falsificado, como se discutió en detalle anteriormente.

En un arreglo alternativo, en la recepción de una contraseña desde el usuario 35 del segundo módulo 30, el segundo módulo 30 puede validar esta contraseña recuperando una contraseña de un tercer módulo que está configurada con el mismo secreto como el primer módulo 20. En este caso, el segundo módulo puede avisar al tercer módulo para que genere una contraseña usando este secreto. El segundo módulo puede entonces comparar la contraseña generada por el tercer módulo a la contraseña recibida desde el usuario 35 del segundo módulo 30, y puede validar la contraseña recibida desde el usuario 35 si existe correspondencia.

En un arreglo alternativo anterior, en el cual el primero y segundo módulos 20, 30 son partes compuestas del mismo dispositivo 90 y están comunicativamente desconectados entre si dentro de este dispositivo 90, la única (probablemente realista) manera del usuario 35 del segundo módulo 30 que es capaz de recuperar una contraseña del primer módulo 20 e ingresarla en el segundo módulo 30, es si el usuario 35 del segundo está en posesión del primer módulo 20. Por lo tanto se deduce que en este caso, el usuario 25 del primer módulo es muy probable que esté en posesión del dispositivo 90 y es por lo tanto un usuario humano. Asi, si el segundo módulo valida la contraseña recibida desde el usuario 35 del segundo módulo 30, el segundo módulo puede determinar hasta a un nivel muy alto de confianza que la solicitud para acceder a los datos originados de un humano el cual está en posesión del dispositivo 90 (y por lo tanto no es una entrada remota), y puede asi permitir el acceso a los datos solicitados. Permitiendo acceso a los datos solicitados puede incluir permitir el acceso a los datos restringidos mantenidos en el dispositivo 90 o, en el caso que los datos solicitados se mantienen por una tercera parte, puede incluir datos enviados a la tercera parte para uso al permitir el acceso a los datos solicitados.

Ventajosamente, en cualquiera de las modalidades anteriores, en el caso que los mensajes sean enviados entre el segundo módulo 30 y una tercera parte, cada uno de los mensajes es encriptado. Asi, si los mensajes son interceptados, la información contenida en estos no pueden ser extraídos y por lo tanto comprometidos. Se debe entender que, si los mensajes son también firmados, el orden en el cual el mensaje es encriptado y firmado podrá depender del algoritmo criptográfico particular usado y que en general, la encriptación y firma pueden ser aplicados al mensaje separadamente o en combinación.

Las modalidades anteriores son para entender como ejemplos ilustrativos de la invención. Se prevén modalidades adicionales de la invención. Por ejemplo, el segundo módulo 30 puede ser para uso en permitir el acceso a los datos, bienes o servicios cceelleebbrraaddooss oo suministrados por una pluralidad de terceras partes 100. También se debe entender que cualquiera de las características descritas en relación a cualquiera de una modalidad pueden también ser usadas solas, o en combinación con otras características descritas, y puede también ser usada en combinación con una o más características de cualquier otra de las modalidades, o cualquier combinación de cualquier otra de las modalidades. Además, también se pueden emplear equivalentes y modificaciones no descritas anteriormente sin apartarse del alcance de la invención, la cual se define en las reivindicaciones acompañantes.

Claims

REIVINDICACIONES Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes.

1. Un sistema para uso en la verificación de una petición para acceso a los datos, caracterizado porque el sistema comprende: un primer módulo arreglado para generar una contraseña y salida a la contraseña generada mediante una interfaz del primer módulo; un segundo módulo arreglado para recibir una contraseña asociada con la petición para datos, validar la contraseña recibida, y permitir acceso a los datos solicitados, en donde tal contraseña recibida se recibe mediante una interfaz del segundo módulo y corresponde a la contraseña generada por el primer módulo, en donde el primero y segundo módulos comparten un secreto que ha sido personalmente asignado al primero y segundo módulos para uso en la generación y validación de tal contraseña, y en donde el primer módulo está desconectado de manera comunicativa del segundo módulo.

2. Un sistema de conformidad con la reivindicación 1, caracterizado porque tal segundo módulo es arreglado para validar contraseñas asociadas con un módulo adicional con el cual ha sido apareado durante un proceso de configuración en el cual un secreto es asignado al segundo módulo y el módulo adicional.

3. Un sistema de conformidad con las reivindicaciones 1 o reivindicación 2, caracterizado porque tal primer módulo y tal segundo módulo son partes compuestas de un dispositivo.

4. Un sistema de conformidad con la reivindicación 3, caracterizado porque tal primer módulo y tal segundo módulo están integrados dentro del dispositivo.

5. Un sistema de conformidad con la reivindicación 3 o reivindicación 4, caracterizado porque tal dispositivo tiene un identificador de dispositivo único y tales contraseñas generadas y recibidas son generadas y validadas en dependencia del identificador de dispositivo único.

6. Un sistema de conformidad con cualquiera de las reivindicaciones 1 a 5, caracterizado porque tal secreto compartido es almacenado en un elemento de seguridad del segundo módulo.

7. Un sistema de conformidad con cualquiera de las reivindicaciones 1 a 6, caracterizado porque tal secreto compartido es almacenado en un elemento de seguridad del primer módulo.

8. Un sistema de conformidad con cualquiera de las reivindicaciones 1 a 7, caracterizado porque el segundo módulo es arreglado para enviar datos para uso permitiendo acceso a los datos solicitados, con ello permitiendo acceso a los datos solicitados.

9. Un sistema de conformidad con cualquiera de las reivindicaciones 1 a 8, caracterizado porque el primer módulo es arreglado para generar tal contraseña generada en respuesta a una entrada relacionada con tal petición para acceso a los datos.

10. Un sistema de conformidad con la reivindicación 9, caracterizado porque el primer módulo es arreglado para generar una contraseña subsecuente en respuesta a una entrada subsecuente relacionada con una petición para acceso a los datos, la contraseña subsecuentemente generada es diferente de una contraseña previamente generada.

11. Un sistema de conformidad con cualquiera de las reivindicaciones 1 a 8, caracterizado porque el primer módulo es arreglado para generar una pluralidad de contraseñas, al menos una contraseña de la pluralidad de contraseñas es diferente de otra contraseña de la pluralidad de contraseñas, y proporcionar al menos una de las contraseñas generadas a un usuario mediante una interfaz del primer módulo.

12. Un sistema de conformidad con cualquiera de la reivindicación 10 o reivindicación 11, caracterizado porque tales contraseñas son generadas y validadas en dependencia de al menos tal secreto compartido y el tiempo actual.

13. Un sistema de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque el primer módulo comprende un primer reloj para uso en la generación de una contraseña y el segundo módulo comprende un segundo reloj para uso en la validación de una contraseña recibida, el primero y segundo relojes son sincronizados.

14. Un sistema de conformidad con cualquiera de la reivindicación 1 a la reivindicación 12, caracterizado porque el primer módulo comprende un reloj para uso en la generación de una contraseña y el segundo módulo es arreglado para recibir una marca de tiempo para uso en la validación de una contraseña recibida, la marca de tiempo es recibida de una tercera parte que tiene un reloj que es sincronizado con el reloj del primer módulo.

15. Un sistema de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque el segundo módulo comprende una interfaz de usuario y es arreglado para recibir la petición para acceso a los datos de un usuario del segundo módulo mediante tal interfaz de usuario.

16. Un sistema de conformidad con la reivindicación 15, caracterizado porque el segundo módulo es además arreglado para recibir información mediante la interfaz de usuario del segundo módulo que personalmente identifica un humano, y tales datos enviados por el segundo módulo para uso permiten el acceso a los datos que comprenden datos que personalmente identifican tal humano.

17. Un método para verificar una petición para acceso a los datos, caracterizado porque el método comprende: generar en un primer módulo una contraseña y hacer salir la contraseña generada mediante una interfaz del primer módulo; recibir en un segundo módulo una contraseña asociada con la petición para datos mediante una interfaz del segundo módulo, tal secreto recibido corresponde a la contraseña generada por el primer módulo; validar en el segundo módulo tal contraseña recibida; y permitir el acceso a los datos solicitados en el segundo módulo, en donde el primero y segundo módulos comparten un secreto que ha sido personalmente asignado al primero y segundo módulos para uso en la generación y validación de tal contraseña, y en donde el primer módulo está desconectado de manera comunicativa del segundo módulo.

18. Un método de conformidad con la reivindicación 17, caracterizado porque tal segundo módulo valida contraseñas asociadas con un módulo adicional con el cual ha sido apareado durante un proceso de configuración en el cual un secreto es asignado a tanto el segundo módulo como el módulo adicional.

19. Un método de conformidad con la reivindicación 17 o reivindicación 18, caracterizado porque tal primer módulo y tal segundo módulo son partes compuestas de un dispositivo.

20. Un método de conformidad con la reivindicación 19, caracterizado porque tal primer módulo y tal segundo módulo están integrados dentro del dispositivo.

21. Un método de conformidad con la reivindicación 19 o reivindicación 20, caracterizado porque tal dispositivo tiene un identificador de dispositivo único y tales contraseñas generadas y recibidas son generadas y validadas en dependencia del identificador de dispositivo único.

22. Un método de conformidad con cualquiera de las reivindicaciones 17 a 21, caracterizado porque tal secreto compartido es almacenado en un elemento de seguridad del segundo módulo.

23. Un método de conformidad con cualquiera de las reivindicaciones 17 a 22, caracterizado porque tal secreto compartido es almacenado en un elemento de seguridad del primer módulo.

24. Un método de conformidad con cualquiera de las reivindicaciones 17 a 23, caracterizado porque el segundo módulo envia datos para uso permitiendo acceso a los datos solicitados, con ello permitiendo acceso a los datos solicitados.

25. Un método de conformidad con cualquiera de las reivindicaciones 17 a 24, caracterizado porque el primer módulo genera tal contraseña generada en respuesta a una entrada relacionada con tal petición para acceso a los datos.

26. Un método de conformidad con la reivindicación 25, caracterizado porque el método comprende además generar en el primer módulo una contraseña subsecuente en respuesta a una entrada subsecuente relacionada con una petición para acceso a los datos, la contraseña subsecuentemente generada es diferente de una contraseña previamente generada.

27. Un método de conformidad con cualquiera de las reivindicaciones 17 a 24, caracterizado porque el método comprende generar una pluralidad de contraseñas, al menos una contraseña de la pluralidad de contraseñas es diferente de otra contraseña de la pluralidad de contraseñas, y proporcionar al menos una de las contraseñas generadas a un usuario mediante una interfaz del primer módulo.

28. Un método de conformidad con cualquiera de las reivindicaciones 26 a 27, caracterizado porque tales contraseñas son generadas y validadas en dependencia de al menos tal secreto compartido y el tiempo actual.

29. Un método de conformidad con cualquiera de las reivindicaciones 17 a reivindicación 28, caracterizado porque el primer módulo usa un primer reloj para generar una contraseña y el segundo módulo usa un segundo reloj para validar una contraseña recibida, el primero y segundo relojes son sincronizados.

30. Un método de conformidad con cualquiera de las reivindicaciones 17 a reivindicación 28, caracterizado porque el primer módulo usa un reloj para generar una contraseña y el segundo módulo usa una marca de tiempo recibida de una tercera parte que tiene un reloj que es sincronizado con el reloj del primer módulo para validar una contraseña recibida.

31. Un método de conformidad con cualquiera de las reivindicaciones 17 a 30, caracterizado porque el segundo módulo recibe la petición para acceso a los datos de un usuario del segundo módulo mediante una interfaz de usuario del segundo módulo.

32. Un método de conformidad con la reivindicación 31, caracterizado porque el segundo módulo recibe además información mediante la interfaz de usuario del segundo módulo que personalmente identifica un humano, y tales datos enviados por el segundo módulo para uso permiten el acceso a los datos que comprenden datos que personalmente identifican tal humano.

33. Un sistema para uso en la verificación de una petición para datos recibidos en un dispositivo como una petición que se origina de un humano en posesión del dispositivo, caracterizado porque el sistema comprende: un primer módulo arreglado para generar una contraseña y salida a la contraseña generada mediante una interfaz del primer módulo; un segundo módulo arreglado para recibir una contraseña asociada con la petición para datos y validar la contraseña recibida, y permitir acceso a los datos, en donde tal contraseña recibida se recibe mediante una interfaz del segundo módulo y corresponde a la contraseña generada por el primer módulo, en donde el primer módulo y el segundo módulo son partes compuestas del dispositivo, y en donde el primer módulo está desconectado de manera comunicativa del segundo módulo.

34. Un sistema de conformidad con la reivindicación 33, caracterizado porque tal primer módulo y tal segundo módulo están integrados dentro del dispositivo.

35. Un sistema de conformidad con la reivindicación 33 o reivindicación 34, caracterizado porque el primero y segundo módulos comparten un secreto para uso en la generación y validación de tal contraseña.

36. Un sistema de conformidad con la reivindicación 34 o reivindicación 35, caracterizado porque el segundo módulo es arreglado para enviar la contraseña recibida a una tercera parte y recibir una indicación de la tercera parte que la contraseña recibida es válida, con ello validar la contraseña recibida.

37. Un sistema de conformidad con la reivindicación 34 o reivindicación 35, caracterizado porque el segundo módulo es arreglado para validar la contraseña recibida comparando la contraseña recibida a una contraseña generada por un tercer módulo.

38. Un sistema de conformidad con cualquiera de la reivindicaciones 33 a 37, caracterizado porque el primer módulo es arreglado para generar tal contraseña en respuesta a una entrada relacionada con tal petición para acceso a los datos.

39. Un sistema de conformidad con la reivindicación 38, caracterizado porque el primer módulo es arreglado para generar una contraseña subsecuente en respuesta a una entrada subsecuente relacionada con una petición para acceso a los datos, la contraseña subsecuentemente generada es diferente de una contraseña previamente generada.

40. Un sistema de conformidad con cualquiera de la reivindicaciones 33 a 37, caracterizado porque el primer módulo es arreglado para generar una pluralidad de contraseñas, al menos una contraseña de la pluralidad de contraseñas es diferente de otra contraseña de la pluralidad de contraseñas, y proporcionar al menos una de las contraseñas generadas a un usuario mediante una interfaz del primer módulo.

41. Un método para verificar una petición para datos recibidos en un dispositivo como una petición que se origina de un humano en posesión del dispositivo, caracterizado porque el método comprende: generar en un primer módulo una contraseña y hacer salir la contraseña generada mediante una interfaz del primer módulo; recibir en un segundo módulo una contraseña asociada con la petición para datos mediante una interfaz del segundo módulo, tal secreto recibido corresponde a la contraseña generada por el primer módulo; validar en el segundo módulo la contraseña recibida; y, permitir el acceso a los datos en el segundo módulo, en donde el primer módulo y el segundo módulo son partes compuestas del dispositivo, y en donde el primer módulo está desconectado de manera comunicativa del segundo módulo.

42. Un método de conformidad con la reivindicación 41, caracterizado porque tal primer módulo y tal segundo módulo están integrados dentro del dispositivo.

43. Un método de conformidad con la reivindicación 41 o reivindicación 42, caracterizado porque el primero y segundo módulos comparten un secreto para uso en la generación y validación de tal contraseña.

44. Un método de conformidad con la reivindicación 41 o reivindicación 42, caracterizado porque el segundo módulo envía la contraseña recibida a una tercera parte y recibe una indicación subsecuente de la tercera parte que la contraseña recibida es válida, con ello validando la contraseña recibida.

45. Un método de conformidad con la reivindicación 41 o reivindicación 42, caracterizado porque el segundo módulo valida la contraseña recibida comparando la contraseña recibida con una contraseña generada por un tercer módulo.

46. Un método de conformidad con cualquiera de las reivindicaciones 41 a 45, caracterizado porque el primer módulo es generar tal contraseña en respuesta a una entrada relacionada con tal petición para acceso a los datos.

47 Un método de conformidad con la reivindicación 46, caracterizado porque el primer módulo genera una contraseña subsecuente en respuesta a una entrada subsecuente relacionada con una petición para acceso a los datos, la contraseña subsecuentemente generada es diferente de una contraseña previamente generada.

48. Un método de conformidad con cualquiera de las reivindicaciones 41 a 45, caracterizado porque el método comprende generar una pluralidad de contraseñas, al menos una contraseña de la pluralidad de contraseñas es diferente de otra contraseña de la pluralidad de contraseñas, y proporcionar al menos una de las contraseñas generadas a un usuario mediante una interfaz del primer módulo.