ES2607495T3 - Testigo móvil - Google Patents

Testigo móvil Download PDF

Info

Publication number
ES2607495T3
ES2607495T3 ES14199297.4T ES14199297T ES2607495T3 ES 2607495 T3 ES2607495 T3 ES 2607495T3 ES 14199297 T ES14199297 T ES 14199297T ES 2607495 T3 ES2607495 T3 ES 2607495T3
Authority
ES
Spain
Prior art keywords
user
service provider
shared secret
activation code
mobile
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES14199297.4T
Other languages
English (en)
Inventor
Dragoljub Nesic
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Verisec AB
Original Assignee
Verisec AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Verisec AB filed Critical Verisec AB
Application granted granted Critical
Publication of ES2607495T3 publication Critical patent/ES2607495T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/065—Continuous authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un método para establecer un secreto compartido entre un primer y un segundo dispositivo (1, 2) sin ninguna confianza compartida entre dicho primer y segundo dispositivo, para el uso de servicios proporcionados por un proveedor de servicios (3') a un usuario (4) de dicho segundo dispositivo (2), caracterizado por que, a) dicho usuario (4) de dicho segundo dispositivo (2) está identificado (11) por dicho proveedor de servicios (3), b) dicho segundo dispositivo (2) solicita (12) y recibe un código de activación desde dicho primer dispositivo (1), c) dicho usuario (4) de dicho segundo dispositivo envía (13) dicho código de activación a dicho proveedor de servicios (3), d) dicho proveedor de servicios (3) envía (14) dicho código de activación a dicho primer dispositivo (1), e) dicho primer dispositivo (1) confirma dicho código de activación y genera y almacena dicho secreto compartido (15), f) dicho primer dispositivo (1) genera una referencia para dicho secreto compartido y transfiere (16) dicha referencia y secreto compartido a dicho segundo dispositivo (2), g) dicho primer dispositivo (1) transfiere (19) dicha referencia a dicho proveedor de servicios (3), y h) dicho proveedor de servicios (3) almacena (110) dicha referencia y asocia dicha referencia a dicho usuario (4).

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Testigo movil Campo de la invencion
La presente invencion se refiere a un metodo para establecer un secreto compartido entre un primer y un segundo dispositivo sin ninguna confianza compartida entre el primer y segundo dispositivo, para el uso de servicios proporcionados por un proveedor de servicios a un usuario de dicho segundo dispositivo.
La presente invencion tambien se refiere a un sistema adaptado para establecer un secreto compartido de acuerdo con el metodo inventivo.
La presente invencion tambien se refiere a productos de programa informatico a traves de los cuales pueden realizarse los metodos inventivos y a un medio legible por ordenador que lleva un producto de programa informatico inventivo.
Descripcion de los antecedentes de la tecnica
Es conocido usar autenticacion de dos factores y contrasenas de un solo uso para proteger servicios de acceso proporcionados por los proveedores de servicio de una manera segura, donde los usuarios normalmente usan contrasenas fijas, a menudo seleccionadas de modo que son faciles de recordar.
Los proveedores de servicios, de aplicaciones web o en la nube y redes corporativas requieren un sistema basado en norma abierta que no les bloquee a trabajar con una tecnologfa y proveedor propietarios, pero que proporcione una amplia diversidad de dispositivos de autenticacion, basados tanto en hardware como software, autenticadores moviles, SMS OTP y mas.
Los usuarios cada vez acceden mas a aplicaciones que se ejecutan en la nube y los proveedores desean mantener el control de la autenticacion de estas aplicaciones.
Es necesario que se aprovisione a los que entran con cuentas de usuario y contrasenas para las aplicaciones en la nube, y es necesario que se interrumpa el acceso a los que abandonan esas mismas aplicaciones.
Puede mencionarse tambien que existe un algoritmo conocido para autenticacion de desaffo-respuesta desarrollado por la Iniciativa para la Autenticacion Abierta (OATH) denominado OCRA: Algoritmo de Desaffo-Respuesta de OATH.
La publicacion de patente US 2011/0197266 A1 muestra que los metodos y sistemas para autenticacion de usuario segura que usan un OTP implican, por ejemplo, pre-almacenar una aplicacion de OTP en un primer dispositivo informatico para generar un valor de OTP valido para el usuario en respuesta a recibir entrada de un valor de PIN valido del usuario, no se almacena parte del valor de PIN valido en el primer dispositivo informatico y pre-almacenar en un servidor de extremo trasero el valor de PIN valido y un secreto compartido valido para el usuario. Tras recibir la entrada de un valor de PIN pretendido del usuario, se sintetiza dinamicamente un secreto compartido pretendido en el primer dispositivo informatico mediante la aplicacion de OTP basandose en el valor de PIN pretendido del usuario y se genera un valor de OTP pretendido en el primer dispositivo informatico. Cuando se recibe la entrada del valor de OTP pretendido mediante el servidor de extremo trasero en un intento para registrarse en el servidor de extremo trasero desde un segundo dispositivo informatico, el servidor de extremo trasero calcula criptograficamente una ventana de valores de OTP, y se permite el inicio de sesion en el servidor de extremo trasero desde el segundo dispositivo informatico si la ventana calculada de valores de OTP corresponde al valor de OTP recibido.
Sumario de la presente invencion
Problemas
El uso de autenticacion de dos factores y contrasenas de un solo uso con contrasenas fijas es un problema puesto que estas contrasenas pueden piratearse facilmente y puesto que son una pesadilla para que los usuarios las recuerden; y por lo tanto los usuarios eligen contrasenas facilmente recordadas que son intrmsecamente debiles. Los usuarios tambien tienden a reusar las mismas contrasenas a traves de multiples aplicaciones, por lo tanto si se piratea la seguridad para una aplicacion; la seguridad tambien puede comprometerse en muchos otros lugares.
Es un problema gestionar el acceso de usuario; es necesario que tenga lugar en una localizacion y bajo poltticas de gobernabilidad corporativas. Es un problema que los usuarios puedan tener acceso a secretos corporativos en multiples aplicaciones en la nube simplemente porque alguien haya olvidado eliminar sus cuentas de usuario de estos sistemas.
5
10
15
20
25
30
35
40
45
50
55
60
65
Es por lo tanto un problema conseguir una experiencia de Inicio de sesion sencillo para web, amigable para el usuario para usuarios de modo que una vez iniciado sesion puedan moverse entre multiples aplicaciones de web a traves de la misma sesion de explorador sin tener que iniciar sesion una y otra vez.
Es un problema tambien compartir servicios con socios y proveedores y establecer federacion de identidad con un ajuste de configuracion sencillo que permita a usuarios autenticados acceder de manera ininterrumpida a aplicaciones de los socios y que los socios puedan acceder a las suyas.
Es un problema aprovechar el verdadero potencial de un dispositivo movil en el campo. Un proveedor de servicios desea que sus usuarios puedan autenticar y firmar transacciones en sus dispositivos moviles de una manera segura. Requieren autenticacion de canal separado y firma de transaccion para evitar amenazas como ataques de hombre en el explorador (MIB), de hombre en el medio (MIM) y de suplantacion de identidad.
Para hacer esto necesitaran un sistema que pueda aprovisionar a los dispositivos moviles con claves secretas para autenticacion y firma. Necesitaran establecer una sesion de SSL encriptada con el dispositivo, recuperar informacion unica acerca del punto de extremo para evitar la amenaza de la clonacion del dispositivo y desearan asegurar que la verificacion del PIN, generacion de clave, indicacion de tiempo de firma y otras acciones se hagan en el lado del servidor, reduciendo de esta manera la dependencia sobre el entorno de seguridad del mismo dispositivo movil.
Es tambien un problema crear un flujo de trabajo mas eficaz que envfe transacciones predecibles de los dispositivos moviles de los usuarios para firma, en lugar de depender de que los usuarios inicien sesion de manera activa en una aplicacion para realizar estas actividades.
El enfoque tradicional limitado a gestion de identidad simplemente no es suficiente en el mundo interconectado de hoy en dfa. Es un problema que las contrasenas fijas ya no sean suficiente seguras para proteger bienes e informacion valiosa. Las organizaciones tanto en el sector corporativo como publico necesitan una solucion de autenticacion segura que permita un numero ilimitado de usuarios, aplicaciones y dispositivos a un coste fijo. La solucion tambien tiene que ser no intrusiva de modo que pueda integrarse con integraciones complejas con sistemas existentes.
Una y otra vez el espacio de identificacion y transaccion en lmea relacionado con los individuos que acceden a servicios financieros y otros, el crecimiento exponencial de los dispositivos conectados en red presenta otra area de problema. La identidad de tales dispositivos conectados asf como la integridad de las aplicaciones que los ejecutan, y la capacidad de estos dispositivos para cometer transacciones en su propio nombre o en nombre de un individuo u organizacion presenta un problema similar al anteriormente descrito - los sistemas actuales tfpicamente se basan en algun tipo de contrasena almacenada en tales dispositivos y usada de manera repetitiva para autenticar el dispositivo o confirmar transacciones con un proveedor de servicios.
Los sistemas en los que, por ejemplo, un “frigonfico inteligente” necesita comunicar con un servicio de reabastecimiento automatizado, un “vehmulo inteligente” necesita comunicar con un servicio de vigilancia o de reparacion, una camara de velocidad necesita comunicar con un sistema de monitorizacion de trafico, todos tienen el requisito de identificar de manera segura el dispositivo asf como para que dicho dispositivo pueda cometer transacciones con un proveedor de servicios conectado en red.
Similar a los telefonos moviles anteriormente mencionados, es un problema aprovisionar tales dispositivos con claves secretas para autenticacion, es decir asegurar la identidad de un dispositivo cuando se conecta a un servicio en lmea, y firmar, es decir cometer de manera segura transacciones con un proveedor de servicios en lmea, particularmente a la luz del enrome numero de tales dispositivos. Excluyendo las plataformas informaticas, un hogar tfpico de hoy en dfa puede tener una variedad de dispositivos que requieren acceso en lmea - sin embargo el numero de dispositivos que estaran mas o menos permanentemente conectados a una red esta creciendo a diario, requiere un metodo que sea mucho mas sencillo y mucho mas seguro que almacenar una contrasena estatica en el dispositivo.
Solucion
Con el fin de resolver uno o mas de los problemas anteriormente mencionados, y desde el punto de vista de un metodo para establecer un secreto compartido entre un primer y un segundo dispositivo sin ninguna confianza compartida entre el primer y segundo dispositivo, para el uso de servicios proporcionados por un proveedor de servicios a un usuario del segundo dispositivo, la presente invencion ensena un metodo donde:
a) un usuario del segundo dispositivo se identifica por el proveedor de servicios,
b) el segundo dispositivo solicita y recibe un codigo de activacion desde el primer dispositivo,
c) el usuario del segundo dispositivo envfa el codigo de activacion al proveedor de servicios,
d) el proveedor de servicios envfa el codigo de activacion al primer dispositivo,
e) el primer dispositivo confirma el codigo de activacion y genera y almacena el secreto compartido,
f) el primer dispositivo genera una referencia para el secreto compartido y transfiriere la referencia y el secreto
5
10
15
20
25
30
35
40
45
50
55
60
65
compartido al segundo dispositivo,
g) el primer dispositivo transfiriere la referencia al proveedor de servicios, y
h) el proveedor de servicios almacena la referencia y asocia la referencia al usuario.
Se propone que el usuario se identifique por el proveedor de servicios a traves de una relacion previamente establecida, que, como un ejemplo, puede ser a traves de un metodo fuera de banda, tal como una visita personal o un correo certificado.
La informacion generada aleatoriamente unica o espedfica de hardware puede incluirse en la solicitud del codigo de activacion, informacion que puede usarse para proteger la transferencia del secreto compartido.
Se propone que la solicitud incluya informacion seleccionada por el usuario conocida por el usuario, tal como un codigo PIN, donde la informacion seleccionada por el usuario esta disponible para detectar uso no autorizado del secreto compartido.
Para el fin de evitar uso no autorizado del segundo dispositivo debido a perdida, robo, etc., se propone que la informacion seleccionada por el usuario se almacene en el primer dispositivo, no estando disponible por lo tanto localmente en el segundo dispositivo.
La presente invencion ensena que el primer y segundo dispositivo validan mutuamente el secreto compartido antes de la transferencia de la referencia al proveedor de servicios.
Se propone que el segundo dispositivo inicie una interrogacion periodica del primer dispositivo para el secreto compartido siguiendo la etapa b), interrogacion que se termina en la finalizacion de la etapa f).
Se propone tambien que el proveedor de servicios inicie una interrogacion periodica del primer dispositivo para la referencia siguiendo la etapa d), interrogacion que se termina en la finalizacion de la etapa g).
Con el fin de proporcionar escalabilidad la presente invencion ensena que el primer dispositivo puede establecer un secreto compartido con mas de un segundo dispositivo, que el segundo dispositivo puede establecer un secreto compartido con mas de un primer dispositivo, y que el primer dispositivo puede proporcionar el uso de secretos compartidos establecidos a mas de un proveedor de servicios.
Debena entenderse que el primer dispositivo y el proveedor de servicios pueden ser dos unidades ffsicas separadas o dos unidades logicas separadas en una y la misma unidad ffsica.
La presente invencion tambien se refiere a un sistema adaptado para establecer un secreto compartido entre un primer y un segundo dispositivo sin ninguna confianza compartida entre dicho primer y segundo dispositivo, para el uso de servicios proporcionados por un proveedor de servicios a un usuario del segundo dispositivo. La presente invencion ensena espedficamente que,
a) el segundo dispositivo esta adaptado para posibilitar que un usuario se identifique por el proveedor de servicios,
b) el segundo dispositivo esta adaptado para solicitar y recibir un codigo de activacion desde el primer dispositivo,
c) el proveedor de servicios esta adaptado para recibir el codigo de activacion desde el usuario del segundo dispositivo,
d) el proveedor de servicios esta adaptado para enviar el codigo de activacion al primer dispositivo,
e) el primer dispositivo esta adaptado para confirmar el codigo de activacion y generar y almacenar el secreto compartido,
f) el primer dispositivo esta adaptado para generar una referencia para el secreto compartido y para transferir la referencia y el secreto compartido al segundo dispositivo,
g) el primer dispositivo esta adaptado para transferir la referencia al proveedor de servicios, y
h) el proveedor de servicios esta adaptado para almacenar la referencia y para asociar la referencia al usuario.
El proveedor de servicios puede estar adaptado para identificar el usuario a traves de una relacion previamente establecida o a traves de un metodo fuera de banda, tal como una visita personal o un correo certificado.
El segundo dispositivo puede estar adaptado para incluir informacion generada aleatoriamente o espedfica de hardware unico en la solicitud del codigo de activacion, y el primer dispositivo puede estar adaptado para usar esta informacion para proteger la transferencia del secreto compartido.
Se propone que el segundo dispositivo este adaptado para incluir informacion seleccionada por el usuario conocida por el usuario en la solicitud, donde la informacion seleccionada por el usuario esta disponible para el primer dispositivo para detectar uso no autorizado del secreto compartido.
5
10
15
20
25
30
35
40
45
50
55
60
65
Para evitar el uso no autorizado del segundo dispositivo, tal como en el caso de perdida, robo, etc., se propone que el primer dispositivo este adaptado para almacenar la informacion seleccionada por el usuario de modo que la informacion seleccionada por el usuario no este disponible localmente en el segundo dispositivo.
La presente invencion ensena que el primer y segundo dispositivo pueden estar adaptados para validar mutuamente el secreto compartido antes de la transferencia de la referencia al proveedor de servicios.
Se propone que siguiendo la etapa b) el segundo dispositivo esta adaptado para iniciar una interrogacion periodica del primer dispositivo para el secreto compartido, interrogacion que se termina en la finalizacion de la etapa f).
Se propone tambien que siguiendo la etapa d) el proveedor de servicios esta adaptado para iniciar una interrogacion periodica del primer dispositivo para la referencia, interrogacion que se termina en la finalizacion de la etapa g).
Para posibilitar escalabilidad se propone que el primer dispositivo este adaptado para establecer un secreto compartido con mas de un segundo dispositivo, que el segundo dispositivo este adaptado para establecer un secreto compartido con mas de un primer dispositivo, y que el primer dispositivo este adaptado para proporcionar el uso de secretos compartidos establecidos a mas de un proveedor de servicios.
El primer dispositivo y el proveedor de servicios pueden ser dos unidades ffsicas separadas o dos unidades logicas separadas en una y la misma unidad ffsica.
La presente invencion tambien se refiere a un producto de programa informatico que comprende codigo de programa informatico, que, cuando se ejecuta mediante un dispositivo, posibilita que el dispositivo realice las etapas de un primer dispositivo de acuerdo con el metodo inventivo.
La presente invencion tambien se refiere a un producto de programa informatico que comprende codigo de programa informatico, que, cuando se ejecuta mediante un dispositivo, posibilita que el dispositivo realice las etapas de un segundo dispositivo de acuerdo con el metodo inventivo.
La presente invencion tambien se refiere a un producto de programa informatico que comprende codigo de programa informatico, que, cuando se ejecuta mediante un dispositivo, posibilita que el dispositivo realice las etapas de un proveedor de servicios de acuerdo con el metodo inventivo.
La presente invencion tambien se refiere a un medio legible por ordenador que lleva codigo de programa informatico de acuerdo con uno cualquiera de los productos de programa informatico inventivos.
Ventajas
Las ventajas de la presente invencion es que proporciona una familia de productos en las areas de autenticacion de usuarios, aprovisionamiento de credenciales IDP (Proveedor de Identidad) en la nube, SSO de Web y firma de transaccion movil, y estos productos pueden implementarse facilmente como una aplicacion de autenticacion y firma de transaccion para diferentes dispositivos tales como dispositivos iOS y Android.
Excepto para las aplicaciones moviles la invencion puede implementarse como aparatos ffsicos o virtuales integrados en una plataforma de desarrollo comun, por ejemplo, con un sistema operativo basado en Linux consolidado. La invencion proporciona productos que son faciles de usar, desarrollar y mantener, que superan a la competencia y proporcionan tecnologfa de la siguiente generacion a precio muy competitivo.
Aunque el aparato de autenticacion tfpicamente reside detras de un cortafuegos, los otros aparatos estan orientados a la nube. Para facilidad de desarrollo y reducir el ciclo de ventas estos aparatos pueden desplegarse en un servidor “multi-version”, que significa que el aparato relevante puede conectarse con conmutadores de licencia como y cuando el cliente los requiera.
En un flujo de trabajo que requiere multiples autorizaciones, por ejemplo gran valor de transaccion en tesorena y banca comercial, la presente invencion podna usarse para enviar solicitudes de autorizacion secuencialmente a los diferentes dispositivos moviles de los gestores, reduciendo drasticamente el tiempo de transaccion y tara administrativa.
La presente invencion proporciona un acceso seguro de gestion de servidor de autenticacion fuerte de la siguiente generacion para redes corporativas. Esta basado en un modelo unico de precios donde los costes son independientes del numero de usuarios, que posibilita que los clientes tomen un enfoque ilimitado que incluye todos los empleados, socios y clientes en el sistema, conectandolos a cualquier aplicacion usando una amplia gama de dispositivos.
5
10
15
20
25
30
35
40
45
50
55
60
65
Breve descripcion de los dibujos
Un metodo, dispositivo y producto de programa informatico de acuerdo con la presente invencion se describiran ahora en detalle con referencia a los dibujos adjuntos, en los que:
La Figura 1 La Figura 2 La Figura 3 La Figura 4 La Figura 5 La Figura 6
es la ilustracion esquematica y simplificada que muestra el aprovisionamiento de un secreto compartido,
es un diagrama de secuencia que explica el protocolo realizado por las interacciones entre una aplicacion de testigo movil, un servidor de aprovisionamiento y una aplicacion de banca en lmea, es un diagrama de estado que muestra los estados a traves de los que pasa un servidor de aprovisionamiento cuando maneja un aprovisionamiento de testigo,
es un diagrama de estado que muestra los estados a traves de los que pasa un testigo movil cuando maneja un aprovisionamiento de testigo,
es una ilustracion esquematica y simplificada del uso de un secreto compartido en un proceso de transaccion, y
es un diagrama de secuencia que explica el protocolo realizado por las interacciones entre la aplicacion de testigo movil 2', el servidor de aplicacion movil 1' y la aplicacion de banca en lmea 3
Descripcion de las realizaciones actualmente preferidas
La presente invencion se describira ahora con referencia a la figura 1 que muestra el aprovisionamiento de un secreto compartido, que en la descripcion se denominara un testigo movil. La seccion 'casos de uso' trata sobre el procedimiento desde un punto de vista del usuario final, mientras que la 'vista general de sistema' proporciona una descripcion tecnica en profundidad.
En las siguientes realizaciones ejemplares el primer dispositivo 1 se ejemplifica mediante un servidor de aprovisionamiento 1 y un servidor de transaccion 1', y el segundo dispositivo 2 se ejemplifica mediante un dispositivo movil 2 con una aplicacion de testigo movil 2'. El proveedor de servicios 3 se ejemplifica mediante una aplicacion de banca en lmea 3, que puede accederse por medio de un ordenador personal 2”. Un usuario 4 puede acceder a la aplicacion de banca en lmea 3 a traves del ordenador personal 2” y a la aplicacion de testigo movil 2' a traves del dispositivo movil 2. Debena entenderse que el ordenador personal 2” puede ser cualquier tipo de dispositivo informatico disponible para el usuario 4 y que el dispositivo movil 2 puede ser cualquier tipo de dispositivo movil disponible para el usuario 4. Debena entenderse tambien que el ordenador personal 2” y el dispositivo movil 2 pueden ser uno y el mismo dispositivo donde la aplicacion de banca en lmea 3 y la aplicacion de testigo movil 2' puede accederse y ejecutarse simultaneamente como dos aplicaciones separadas.
Casos de uso
La Figura 1 ilustra un escenario en el que se supone que el testigo o secreto compartido se ha de usar para banca en lmea; el aprovisionamiento para clientes distintos de los bancos tendna una forma algo diferente.
Son posibles dos casos: un usuario existente, que ya tiene credenciales registrados con el banco, desea empezar a usar un testigo movil, y un nuevo usuario esta configurando una cuenta bancaria y desea obtener un testigo movil.
El primer caso es el mas sencillo de los dos, puesto que trata con un usuario existente 4 que ya tiene credenciales con el banco 3' y los usa para acceder a la aplicacion de banca en lmea 3 para realizar pagos en lmea y similares. La misma aplicacion se usa durante aprovisionamiento de testigo movil.
Las etapas que el usuario toma son como sigue:
- El usuario 4 inicia sesion en la aplicacion de banca en lmea 3 con un nombre de usuario y contrasena estatica.
- Siguiendo las instrucciones en la aplicacion de banca en lmea, el usuario 4 instala la aplicacion de testigo 2' en
su telefono movil 2.
- Se genera un codigo de activacion, se envfa a la aplicacion movil 2' y se presenta en la pantalla, se lee o se hace conocer para el usuario 4 de alguna otra manera adecuada por medio del telefono movil 2.
- El usuario 4 escribe el codigo de activacion en una pagina apropiada en la aplicacion de banca en lmea 3.
- En este punto, el usuario 4 configura el PIN que de ahora en adelante se usara para acceder a la aplicacion de
testigo 2'.
- Se aprovisiona el testigo y el usuario observa un mensaje de confirmacion tanto en la aplicacion de banca en lmea 3 como en la aplicacion de testigo 2'.
El segundo caso se refiere a un nuevo usuario 4, que desea obtener un testigo movil al mismo tiempo que abre una cuenta bancaria.
Las etapas que el usuario toma son como sigue:
5
10
15
20
25
30
35
40
45
50
55
60
65
- El usuario 4 recibe un codigo de activacion de un solo uso para acceder a la aplicacion de banca en lmea 3. Este codigo es unicamente usable para aprovisionamiento de testigo movil, no para el uso normal de la aplicacion.
a) El codigo de activacion puede recibirse a traves de varios canales, de acuerdo con la eleccion del banco 3' y/o el usuario final 4:
b) entregarse a la direccion local del usuario por correo. En este caso el codigo es valido durante un periodo de tiempo mas largo, tal como cinco o diez dfas.
c) Si el numero de telefono movil del usuario esta registrado con el banco, el codigo puede entregarse por SMS. En este caso el codigo es valido durante un periodo de tiempo mas corto, por ejemplo unos pocos minutos.
d) Si la direccion de correo electronico del usuario esta registrada con el banco, el codigo puede entregarse mediante correo electronico. De manera similar a SMS, en este caso el codigo es valido para un periodo de tiempo mas corto.
- El usuario 4 accede a la aplicacion de banca en lmea 3 y sigue las instrucciones para descargar la aplicacion de testigo 2'. El resto del procedimiento es el mismo que para usuarios del banco existentes.
La arquitectura de sistema e interacciones entre componentes del sistema se describiran ahora en mas detalle.
Inicialmente se describira el aprovisionamiento de testigo.
El usuario 4 navega 11 a una aplicacion de banca en lmea 3. En este punto se le instruye como instalar e iniciar una aplicacion de testigo movil 2'. Se le instruye tambien leer un codigo de activacion desde la aplicacion de testigo movil 2' y escribirlo en la aplicacion de banca en lmea 3 para confirmacion.
Despues de que el usuario enciende la aplicacion de testigo movil 2', solicita 12 un codigo de activacion desde un servidor de aprovisionamiento 1.
a. la aplicacion de testigo movil 2' envfa una solicitud para un codigo de activacion, que incluye identificadores generados aleatoriamente o, si estan disponibles, espedficos de hardware, tales como IMEI, numero de telefono etc.
b. el servidor de aprovisionamiento 1 genera un codigo de activacion, lo almacena junto con la informacion espedfica de hardware y devuelve el codigo de activacion a la aplicacion de testigo movil.
i. El codigo de activacion reside en el servidor de aprovisionamiento 1 hasta la finalizacion del proceso de aprovisionamiento. Si el aprovisionamiento de testigo no se ha completado dentro de un intervalo de tiempo establecido, tal como 5 minutos, el codigo de activacion se borra automaticamente.
c. la aplicacion de testigo movil 2' hace el codigo de activacion disponible para el usuario 4, por ejemplo presentandolo para que el usuario 4 lo lea.
d. la aplicacion de testigo movil 2' tambien empieza a interrogar el servidor de aprovisionamiento 1 para una semilla de testigo. El servidor de aprovisionamiento 1 responde con un mensaje de 'semilla no disponible' hasta que se verifica el codigo de activacion a traves de la aplicacion de banca en lmea 3.
El usuario 4 introduce 13 el codigo de activacion en la aplicacion de banca en lmea 3.
La aplicacion de banca en lmea 3 envfa 14 el codigo de activacion al servidor de aprovisionamiento 1.
a. El servidor de aprovisionamiento 1 verifica el codigo de activacion
b. La aplicacion de banca en lmea 3 empieza a interrogar al servidor de aprovisionamiento 1 para informacion sobre si el testigo esta personalizado. El servidor de aprovisionamiento 1 responde con 'testigo no personalizado'.
El servidor de aprovisionamiento 1 genera 15 una semilla de testigo por sf mismo, o por medio de un modulo de seguridad de hardware 5 donde los requisitos de regulacion, de polttica de seguridad o de auditona asf lo postulan, para asegurar buena aleatoriedad de la semilla de testigo.
a. La semilla de testigo puede encriptarse de dos maneras diferentes, generando de esta manera dos encriptaciones de semilla.
i. Se encripta una semilla de testigo usando una clave de transporte derivada de la informacion espedfica de hardware y un secreto compartido entre la aplicacion de testigo movil 2' y el servidor de aprovisionamiento 1.
La semillaHSi de testigo se usara para enviar de manera segura la semilla de testigo a la aplicacion de testigo movil 2'.
5
10
15
20
25
30
35
40
45
50
55
60
65
ii. Una semilla de testigo puede encriptarse tambien con una clave de transporte desde un componente de validacion OATH/OCRA 6.
La semillaoATH/ocRA de testigo se usara para enviar de manera segura la semilla de testigo al componente de validacion de OATH/OCRA.
b. Se obtiene un numero de serie de testigo desde el componente de validacion de OATH/OCRA.
c. Tanto la semillaHsi de testigo como la semillaATH/OCRA de testigo juntas con el numero de serie de testigo se graban en el servidor de aprovisionamiento 1.
La semillaHsi se envfa 16 a la aplicacion de testigo movil 2' junto con el numero de serie de testigo; la aplicacion de testigo movil 2' estaba interrogando la semilla de testigo todo el tiempo.
La aplicacion de testigo movil 2' envfa 17 una solicitud para verificacion de una contrasena de un solo uso al servidor de aprovisionamiento 1.
a. Despues de recibir la semilla de testigo, la aplicacion de testigo movil 2' la desencripta.
b. la aplicacion de testigo movil 2' genera una contrasena de un solo uso
c. la aplicacion de testigo movil 2' envfa la contrasena de un solo uso y el numero de serie de testigo al servidor de aprovisionamiento 1 para verificacion.
El servidor de aprovisionamiento 1 recibe la solicitud de verificacion de contrasena de un solo uso.
a. El servidor de aprovisionamiento 1 envfa 18 la solicitud de verificacion (OTP+ numero de serie de testigo+ semillaOATH/OCRA de testigo+detalles de testigo) a un componente de validacion OATH/OCRA 6.
b. El componente de validacion de OATH/OCRA 6' senaliza su aprobacion al servidor de aprovisionamiento 1, y la respuesta se reenvfa a la aplicacion de testigo movil 2'.
c. La aplicacion de testigo movil 2' ahora esta personalizada satisfactoriamente.
La interrogacion de la aplicacion de banca en lmea 3 se responde ahora 19 con un mensaje de aprovisionamiento de testigo satisfactorio que contiene el numero de serie de testigo. Se notifica al usuario de que el proceso de aprovisionamiento esta finalizado.
La aplicacion de banca en lmea 3 asocia 110 el usuario 4 con el numero de serie de testigo en el repositorio del usuario del banco 7.
Es posible requerir que el usuario 4 establezca un secreto compartido entre el servidor de aprovisionamiento 1 y la aplicacion de testigo movil 2' en el comienzo del proceso de aprovisionamiento, por ejemplo con uso de codigo de QR o codigo introducido por el usuario. Este secreto compartido se usana para proteger los datos intercambiados entre las dos partes. Tambien, mas tarde, durante los procesos de transaccion este secreto podna usarse tambien para las mismas razones como se han mencionado anteriormente. Este secreto se mantendna en la aplicacion de testigo movil 2' encriptado bajo un PIN que unicamente conoce el usuario.
La Figura 2 es un diagrama de secuencia que explica el protocolo realizado por las interacciones entre la aplicacion de testigo movil MT 2', el servidor de aprovisionamiento PS 1 y aplicacion de banca en lmea BOA 3.
La Figura 3 es un diagrama de estado que muestra los estados a traves de los que pasa el servidor de aprovisionamiento cuando maneja un aprovisionamiento de testigo.
La Figura 4 es un diagrama de estado que muestra los estados a traves de los que pasa el testigo movil cuando maneja un aprovisionamiento de testigo.
El proceso de una validacion de transaccion se describira ahora. Este proceso puede referirse a que el usuario 4 este intentando iniciar sesion en una aplicacion de banca en lmea 3 o para validar una transaccion que se esta realizando a traves de la misma aplicacion. Las etapas que el usuario toma son como sigue:
- El usuario explora la aplicacion de banca en lmea 3 e introduce sus credenciales de usuario o solicita que se realice una transaccion.
- La aplicacion de banca en lmea 3 instruye al usuario 4 a que inicie la aplicacion de testigo movil 2' en su telefono 2.
- La aplicacion de testigo movil 2' recibe informacion con respecto a la transaccion en cuestion y se requiere que el usuario 4 confirme la accion.
La Figura 5 muestra la arquitectura de sistema e interacciones entre componentes del sistema, donde se ilustra el proceso de transaccion con todos los detalles relevantes.
5
10
15
20
25
30
35
40
45
50
55
60
65
El usuario 4 intenta iniciar sesion 51 en la aplicacion de banca en lmea 3 o si ya ha iniciado sesion intenta realizar una transaccion.
La aplicacion de banca en lmea 3 obtiene el nombre de usuario del usuario y lo mapea 52 a un numero de serie en un repositorio de cuentas de usuario local 7.
La aplicacion de banca en lmea 3 envfa 53 un mensaje al servidor de aplicacion movil 1', mensaje que contiene:
a. Numero de serie del usuario
b. Texto de transaccion - (por ejemplo “Transferir 1000 euros a numero de cuenta xxxxxxxxxxxx”)
El servidor de aplicacion movil 1' responde 54 con una referencia de transaccion (TRREF) que es una referencia generada aleatoriamente unica para la transaccion. Esta referencia identifica ineqmvocamente cada transaccion y sirve como un id de sesion.
a. Despues de esta etapa la aplicacion de banca en lmea 3 pide continuamente al servidor de aplicacion movil 1' el estado de la transaccion con una referencia de transaccion TRREF.
b. el servidor de aplicacion movil 1' informa a la aplicacion de banca en lmea 3 sobre cualquier cambio del estado.
La aplicacion de banca en lmea 3 pide 55 al usuario que inicie su aplicacion de testigo movil 2'.
La aplicacion de testigo movil 2' cuando se enciende pide al usuario que introduzca el PIN que el usuario elige durante el aprovisionamiento de la aplicacion de testigo movil 2'. Este PlN se usa para proteger datos confidenciales mantenidos en el dispositivo movil. De esta manera no hay datos sensibles en texto sin cifrar presentes en la memoria o almacenamiento del dispositivo.
a. La verificacion de PIN no se realiza en la aplicacion de testigo movil 2', sino en el servidor de aplicacion movil 1'. Cuando se introduce el PIN, se usa para desencriptar los datos sensibles.
b. Estos datos, incluso aunque pudieran estar incorrectos, se usan en el resto de la verificacion de la transaccion.
c. Esto conducira a fallo de verificacion de transaccion y un usuario tendna que repetir el proceso.
d. Si el PIN se introduce de manera erronea demasiadas veces la aplicacion de testigo movil 2' puede borrar todos los datos y el usuario 4 debena pasar a traves del proceso de aprovisionamiento de nuevo. El servidor de aplicacion movil 1' tambien puede bloquear que una instancia de este tipo de la aplicacion de testigo movil 2' funcione de nuevo hasta que se vuelva a aprovisionar que, a su vez, requiere probar la identidad del usuario 4 de nuevo.
e. Despues de que se introduce el PIN correcto la aplicacion de testigo movil 2' pide 56 al servidor de aplicacion movil 1' si hay transacciones pendientes. Este mensaje contiene el numero de serie del usuario, un desaffo nuevamente generado y respuesta apropiada. Esta respuesta se introduce para mitigar la posibilidad de que un atacante lea los datos de la transaccion.
El servidor de aplicacion movil 1' verifica 57 el par desaffo-respuesta con el componente de validacion de OATH/OCRA 6. Si la verificacion es satisfactoria a continuacion se envfa 58 la referencia de transaccion TRREF y el texto de transaccion a la aplicacion de testigo movil 2'.
La aplicacion de testigo movil 2' calcula una RESPUESTA y la envfa 59 junto con la referencia de transaccion recibida TRREF.
El servidor de aplicacion movil 1' verifica 510 el par desaffo-respuesta con el componente de validacion de OATH/OCRA 6.
Si el componente de validacion de OATH/OCRA 6 verifica la respuesta el servidor de aplicacion movil 1' notifica 511, 512 a la aplicacion de testigo movil 2' y a la aplicacion de banca en lmea 3 que la transaccion fue satisfactoria.
Se propone que la comunicacion entre el servidor de aplicacion movil 1' y la aplicacion de banca en lmea 3 y la aplicacion de testigo movil 2' se proteja por el uso del protocolo de TLS.
Se propone tambien que si durante el proceso de aprovisionamiento se establecio un secreto compartido entre el servidor de aprovisionamiento 1 y la aplicacion de testigo movil 2', entonces este podna usarse para proteger datos intercambiados entre estas partes.
La Figura 6 es un diagrama de secuencia que explica el protocolo realizado por las interacciones entre la aplicacion de testigo movil MT 2', el servidor de aplicacion movil MAS 1' y la aplicacion de banca en lmea BOA 3.
En las realizaciones ejemplares el uso de un servidor de aprovisionamiento, servidor de aplicacion movil, un componente de validacion OATH/OCRA y un modulo de seguridad de hardware se han mostrado como
componentes separados, sin embargo, debena entenderse que tanto el servidor de aprovisionamiento 1 como el servidor de aplicacion movil 1' pueden incluir la funcion de uno o ambos del componente de validacion de OATH/OCRA 6 y el modulo de seguridad de hardware 5 y que uno y el mismo servidor puede funcionar tanto como un servidor de aprovisionamiento 1 como un servidor de aplicacion movil 1'. En las reivindicaciones el primer 5 dispositivo se describe como que comprende todas estas funciones. El experto en la materia entiende que el primer dispositivo puede realizarse a traves de uno o varios servidores a traves de los que estos servidores y funciones se hacen disponibles tanto a traves de funciones internas como servicios externos.
En las realizaciones ejemplares se ha usado un banco en lmea para ejemplificar un proveedor de servicios, sin 10 embargo, debena entenderse que la expresion “proveedor de servicio” incluye cualquier tipo de proveedor donde se requiera el acceso protegido al servicio, tal como aplicaciones de web o en la nube donde se requiere una identificacion segura de un usuario, cualquier tipo de transaccion economica, y acceso a material protegido y redes corporativas.
15 Se entendera que la invencion no esta restringida a las realizaciones ejemplares anteriormente descritas e ilustradas de las mismas y que pueden realizarse modificaciones dentro del alcance de la invencion como se define mediante las reivindicaciones adjuntas.

Claims (29)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    REIVINDICACIONES
    1. Un metodo para establecer un secreto compartido entre un primer y un segundo dispositivo (1, 2) sin ninguna confianza compartida entre dicho primer y segundo dispositivo, para el uso de servicios proporcionados por un proveedor de servicios (3') a un usuario (4) de dicho segundo dispositivo (2), caracterizado por que,
    a) dicho usuario (4) de dicho segundo dispositivo (2) esta identificado (11) por dicho proveedor de servicios (3),
    b) dicho segundo dispositivo (2) solicita (12) y recibe un codigo de activacion desde dicho primer dispositivo (1),
    c) dicho usuario (4) de dicho segundo dispositivo envfa (13) dicho codigo de activacion a dicho proveedor de servicios (3),
    d) dicho proveedor de servicios (3) envfa (14) dicho codigo de activacion a dicho primer dispositivo (1),
    e) dicho primer dispositivo (1) confirma dicho codigo de activacion y genera y almacena dicho secreto compartido (15),
    f) dicho primer dispositivo (1) genera una referencia para dicho secreto compartido y transfiere (16) dicha referencia y secreto compartido a dicho segundo dispositivo (2),
    g) dicho primer dispositivo (1) transfiere (19) dicha referencia a dicho proveedor de servicios (3), y
    h) dicho proveedor de servicios (3) almacena (110) dicha referencia y asocia dicha referencia a dicho usuario (4).
  2. 2. Un metodo de acuerdo con la reivindicacion 1, caracterizado por que dicho usuario se identifica por dicho proveedor de servicios a traves de una relacion previamente establecida.
  3. 3. Un metodo de acuerdo con la reivindicacion 1, caracterizado por que dicho usuario se identifica por dicho proveedor de servicios a traves de un metodo fuera de banda, tal como una visita personal o un correo certificado.
  4. 4. Un metodo de acuerdo con cualquier reivindicacion anterior, caracterizado por que se incluye informacion unica generada aleatoriamente o espedfica de hardware en dicha solicitud de codigo de activacion, y por que dicha informacion se usa para proteger la transferencia de dicho secreto compartido.
  5. 5. Un metodo de acuerdo con cualquier reivindicacion anterior, caracterizado por que dicha solicitud incluye informacion seleccionada por el usuario conocida por dicho usuario, estando disponible dicha informacion seleccionada por el usuario para detectar el uso no autorizado de dicho secreto compartido.
  6. 6. Un metodo de acuerdo con la reivindicacion 5, caracterizado por que dicha informacion seleccionada por el usuario se almacena en dicho primer dispositivo.
  7. 7. Un metodo de acuerdo con cualquier reivindicacion anterior, caracterizado por que, antes de la transferencia de dicha referencia a dicho proveedor de servicios, dicho primer y segundo dispositivo validan mutuamente dicho secreto compartido.
  8. 8. Un metodo de acuerdo con cualquier reivindicacion anterior, caracterizado por, siguiendo la etapa b), dicho segundo dispositivo inicia una interrogacion periodica de dicho primer dispositivo para dicho secreto compartido, y termina dicha interrogacion en la finalizacion de la etapa f).
  9. 9. Un metodo de acuerdo con cualquier reivindicacion anterior, caracterizado por que, siguiendo la etapa d), dicho proveedor de servicios inicia una interrogacion periodica de dicho primer dispositivo para dicha referencia, y termina dicha interrogacion en la finalizacion de la etapa g).
  10. 10. Un metodo de acuerdo con cualquier reivindicacion anterior, caracterizado por que dicho primer dispositivo puede establecer un secreto compartido con mas de un segundo dispositivo.
  11. 11. Un metodo de acuerdo con cualquier reivindicacion anterior, caracterizado por que dicho segundo dispositivo puede establecer un secreto compartido con mas de un primer dispositivo.
  12. 12. Un metodo de acuerdo con cualquier reivindicacion anterior, caracterizado por que dicho primer dispositivo puede proporcionar el uso de secretos compartidos establecidos a mas de un proveedor de servicios.
  13. 13. Un metodo de acuerdo con cualquier reivindicacion anterior, caracterizado por que dicho primer dispositivo y dicho proveedor de servicios son dos unidades ffsicas separadas o dos unidades logicas separadas en una y la misma unidad ffsica.
  14. 14. Un sistema adaptado para establecer un secreto compartido entre un primer y un segundo dispositivo sin ninguna confianza compartida entre dicho primer y segundo dispositivo, para el uso de servicios proporcionados por un proveedor de servicios a un usuario de dicho segundo dispositivo, caracterizado por que,
    a) dicho segundo dispositivo esta adaptado para posibilitar que se identifique dicho usuario por dicho proveedor de servicios,
    5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    b) dicho segundo dispositivo esta adaptado para solicitar y recibir un codigo de activacion desde dicho primer dispositivo,
    c) dicho proveedor de servicios esta adaptado para recibir dicho codigo de activacion desde el usuario de dicho segundo dispositivo,
    d) dicho proveedor de servicios esta adaptado para enviar dicho codigo de activacion a dicho primer dispositivo,
    e) dicho primer dispositivo esta adaptado para confirmar dicho codigo de activacion y generar y almacenar dicho secreto compartido,
    f) dicho primer dispositivo esta adaptado para generar una referencia para dicho secreto compartido y para transferir dicha referencia y secreto compartido a dicho segundo dispositivo,
    g) dicho primer dispositivo esta adaptado para transferir dicha referencia a dicho proveedor de servicios, y
    h) dicho proveedor de servicios esta adaptado para almacenar dicha referencia y para asociar dicha referencia a dicho usuario.
  15. 15. Un sistema de acuerdo con la reivindicacion 14, caracterizado por que dicho proveedor de servicios esta adaptado para identificar dicho usuario a traves de una relacion previamente establecida.
  16. 16. Un sistema de acuerdo con la reivindicacion 14, caracterizado por que dicho proveedor de servicios esta adaptado para identificar dicho usuario a traves de un metodo fuera de banda, tal como una visita personal o un correo certificado.
  17. 17. Un sistema de acuerdo con una cualquiera de las reivindicaciones 14 a 16, caracterizado por que dicho segundo dispositivo esta adaptado para incluir informacion unica generada aleatoriamente o espedfica de hardware en dicha solicitud de codigo de activacion, y por que dicho primer dispositivo esta adaptado para usar dicha informacion para proteger la transferencia de dicho secreto compartido.
  18. 18. Un sistema de acuerdo con una cualquiera de las reivindicaciones 14 a 17, caracterizado por que dicho segundo dispositivo esta adaptado para incluir informacion seleccionada por el usuario conocida por dicho usuario en dicha solicitud, estando disponible dicha informacion seleccionada por el usuario para dicho primer dispositivo para detectar el uso no autorizado de dicho secreto compartido.
  19. 19. Un sistema de acuerdo con la reivindicacion 18, caracterizado por que dicho primer dispositivo esta adaptado para almacenar dicha informacion seleccionada por el usuario.
  20. 20. Un sistema de acuerdo con una cualquiera de las reivindicaciones 14 a 19, caracterizado por que dicho primer y segundo dispositivo estan adaptados para validar mutuamente dicho secreto compartido antes de la transferencia de dicha referencia a dicho proveedor de servicios.
  21. 21. Un sistema de acuerdo con una cualquiera de las reivindicaciones 14 a 20, caracterizado por que siguiendo la etapa b) dicho segundo dispositivo esta adaptado para iniciar una interrogacion periodica de dicho primer dispositivo para dicho secreto compartido, interrogacion que se termina en la finalizacion de la etapa f).
  22. 22. Un sistema de acuerdo con una cualquiera de las reivindicaciones 14 a 21, caracterizado por que siguiendo la etapa d) dicho proveedor de servicios esta adaptado para iniciar una interrogacion periodica de dicho primer dispositivo para dicha referencia, interrogacion que se termina en la finalizacion de la etapa g).
  23. 23. Un sistema de acuerdo con una cualquiera de las reivindicaciones 14 a 22, caracterizado por que dicho primer dispositivo esta adaptado para establecer un secreto compartido con mas de un segundo dispositivo.
  24. 24. Un sistema de acuerdo con una cualquiera de las reivindicaciones 14 a 23, caracterizado por que dicho segundo dispositivo esta adaptado para establecer un secreto compartido con mas de un primer dispositivo.
  25. 25. Un sistema de acuerdo con una cualquiera de las reivindicaciones 14 a 24, caracterizado por que dicho primer dispositivo esta adaptado para proporcionar el uso de secretos compartidos establecidos a mas de un proveedor de servicios.
  26. 26. Un sistema de acuerdo con una cualquiera de las reivindicaciones 14 a 25, caracterizado por que dicho primer dispositivo y dicho proveedor de servicios son dos unidades ffsicas separadas o dos unidades logicas separadas en una y la misma unidad ffsica.
  27. 27. Un producto de programa informatico que comprende codigo de programa informatico, que, cuando se ejecuta mediante un dispositivo, posibilita que dicho dispositivo realice las etapas de un primer dispositivo de acuerdo con una cualquiera de las reivindicaciones 1, 4, 5, 6, 7, 8, 10 o 12.
  28. 28. Un producto de programa informatico que comprende codigo de programa informatico, que, cuando se ejecuta mediante un dispositivo, posibilita que dicho dispositivo realice las etapas de un segundo dispositivo de acuerdo con una cualquiera de las reivindicaciones 1,4, 5, 7 u 11.
  29. 29. Un producto de programa informatico que comprende codigo de programa informatico, que, cuando se ejecuta mediante un dispositivo, posibilita que dicho dispositivo realice las etapas de un proveedor de servicios de acuerdo con una cualquiera de las reivindicaciones 1, 2, 3 u 8.
    5 30. Un medio legible por ordenador caracterizado por llevar codigo de programa informatico de acuerdo con una
    cualquiera de las reivindicaciones 27 a 29.
ES14199297.4T 2013-12-20 2014-12-19 Testigo móvil Active ES2607495T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201361919230P 2013-12-20 2013-12-20
US201361919230P 2013-12-20

Publications (1)

Publication Number Publication Date
ES2607495T3 true ES2607495T3 (es) 2017-03-31

Family

ID=52396354

Family Applications (1)

Application Number Title Priority Date Filing Date
ES14199297.4T Active ES2607495T3 (es) 2013-12-20 2014-12-19 Testigo móvil

Country Status (3)

Country Link
US (1) US20150180849A1 (es)
EP (1) EP2894891B1 (es)
ES (1) ES2607495T3 (es)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150195594A1 (en) * 2014-01-07 2015-07-09 Viacom International Inc. Systems and Methods for Authenticating a User to Access Multimedia Content
CN104539701B (zh) * 2014-12-29 2018-04-27 飞天诚信科技股份有限公司 一种在线激活移动终端令牌的设备和系统的工作方法
FR3036574A1 (fr) * 2015-05-21 2016-11-25 Orange Chargement de profil d'abonnement dans une carte sim embarquee
US10382426B2 (en) * 2015-07-02 2019-08-13 Adobe Inc. Authentication context transfer for accessing computing resources via single sign-on with single use access tokens
US10243924B2 (en) * 2015-08-18 2019-03-26 Ricoh Company, Ltd. Service providing system, service providing method, and information processing apparatus
WO2017039686A1 (en) * 2015-09-04 2017-03-09 Ford Global Technologies, Llc System and method for contacting occupants of a remote vehicle using dsrc
CN106487785B (zh) * 2016-09-28 2019-07-23 武汉理工大学 一种基于移动终端的身份鉴别方法及系统
US10834231B2 (en) * 2016-10-11 2020-11-10 Synergex Group Methods, systems, and media for pairing devices to complete a task using an application request
CN111277574B (zh) * 2020-01-14 2022-05-17 杭州涂鸦信息技术有限公司 一种共享设备安全通信时效性离线秘钥生成方法及系统
EP4111719A1 (en) * 2020-02-24 2023-01-04 Bayerische Motoren Werke Aktiengesellschaft Method of providing a communication function in a user equipment
US11647015B2 (en) * 2020-07-30 2023-05-09 UiPath, Inc. Factor authentication for robotic processes

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6829596B1 (en) * 2000-05-23 2004-12-07 Steve Frazee Account/asset activation device and method
US7797544B2 (en) * 2003-12-11 2010-09-14 Microsoft Corporation Attesting to establish trust between computer entities
US9768963B2 (en) * 2005-12-09 2017-09-19 Citicorp Credit Services, Inc. (Usa) Methods and systems for secure user authentication
NO332479B1 (no) * 2009-03-02 2012-09-24 Encap As Fremgangsmåte og dataprogram for verifikasjon av engangspassord mellom tjener og mobil anordning med bruk av flere kanaler
US8763097B2 (en) * 2011-03-11 2014-06-24 Piyush Bhatnagar System, design and process for strong authentication using bidirectional OTP and out-of-band multichannel authentication

Also Published As

Publication number Publication date
EP2894891B1 (en) 2016-10-26
EP2894891A2 (en) 2015-07-15
EP2894891A3 (en) 2015-11-04
US20150180849A1 (en) 2015-06-25

Similar Documents

Publication Publication Date Title
ES2607495T3 (es) Testigo móvil
US11012240B1 (en) Methods and systems for device authentication
US8973122B2 (en) Token based two factor authentication and virtual private networking system for network management and security and online third party multiple network management method
US9350548B2 (en) Two factor authentication using a protected pin-like passcode
US10897455B2 (en) System and method for identity authentication
ES2564128T3 (es) Un sistema implementado por ordenador para proporcionar a los usuarios acceso seguro a servidores de aplicaciones
ES2739896T5 (es) Acceso seguro a datos de un dispositivo
ES2596308T3 (es) Método y disposición para autenticación segura
CN101227468B (zh) 用于认证用户到网络的方法、设备和系统
Oppliger Microsoft. net passport: A security analysis
US20130185210A1 (en) Method and System for Making Digital Payments
US20170288873A1 (en) Network Authentication Of Multiple Profile Accesses From A Single Remote Device
EP3661154B1 (en) Authentication based on unique encoded codes
US20190312861A1 (en) System and method for grid-based one-time password
WO2016188335A1 (zh) 用户数据的访问控制方法、装置及系统
Alnahari et al. Authentication of IoT device and IoT server using security key
CN114024751B (zh) 一种应用访问控制方法、装置、计算机设备及存储介质
US20070204167A1 (en) Method for serving a plurality of applications by a security token
CN111488570A (zh) 认证方法及认证系统
Binu et al. A mobile based remote user authentication scheme without verifier table for cloud based services
Sanyal et al. A multifactor secure authentication system for wireless payment
Rastogi et al. Secured identity management system for preserving data privacy and transmission in cloud computing
Pavlovski et al. Unified framework for multifactor authentication
Yasin et al. Enhancing anti-phishing by a robust multi-level authentication technique (EARMAT).
CA2904646A1 (en) Secure authentication using dynamic passcode