ES2819200T3 - Un método y sistema para proporcionar autenticación del acceso del usuario a un recurso informático a través de un dispositivo móvil utilizando múltiples factores de seguridad separados - Google Patents

Un método y sistema para proporcionar autenticación del acceso del usuario a un recurso informático a través de un dispositivo móvil utilizando múltiples factores de seguridad separados Download PDF

Info

Publication number
ES2819200T3
ES2819200T3 ES13801699T ES13801699T ES2819200T3 ES 2819200 T3 ES2819200 T3 ES 2819200T3 ES 13801699 T ES13801699 T ES 13801699T ES 13801699 T ES13801699 T ES 13801699T ES 2819200 T3 ES2819200 T3 ES 2819200T3
Authority
ES
Spain
Prior art keywords
token
user
mobile device
security token
portable security
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
ES13801699T
Other languages
English (en)
Inventor
Arnold Yau
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.)
HOVERKEY Ltd
Original Assignee
HOVERKEY Ltd
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=47560842&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=ES2819200(T3) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by HOVERKEY Ltd filed Critical HOVERKEY Ltd
Application granted granted Critical
Publication of ES2819200T3 publication Critical patent/ES2819200T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3215—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a plurality of channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
    • 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/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices
    • H04W12/55—Secure pairing of devices involving three or more devices, e.g. group pairing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/63—Location-dependent; Proximity-dependent

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Telephone Function (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un método de autenticación de un usuario para acceder a un recurso informático a través de un dispositivo móvil que comprende: almacenar una autorización de recursos cifrada; transmitir la autorización de recursos cifrados a al menos un dispositivo de token de seguridad portátil separado; en el al menos un dispositivo de token de seguridad portátil separado, descifrar la autorización de recursos cifrada y generar al menos parcialmente a partir de ella una respuesta de desbloqueo; transmitir en forma segura la respuesta de desbloqueo generada al dispositivo móvil; y proporcionar acceso a través del dispositivo móvil al recurso informático si la respuesta de desbloqueo requerida es válida; en el que se requiere que un usuario se autentique en el dispositivo móvil o en al menos un dispositivo de token de seguridad portátil separado, y la autenticación de usuario se valida en el al menos un dispositivo de token de seguridad portátil separado antes de que se envíe la respuesta de desbloqueo.

Description

DESCRIPCIÓN
Un método y sistema para proporcionar autenticación del acceso del usuario a un recurso informático a través de un dispositivo móvil utilizando múltiples factores de seguridad separados
1. Introducción
La presente solicitud se refiere a un método y sistema para autenticar a un usuario en un recurso informático al que se accede a través de un dispositivo móvil utilizando un token de seguridad portátil (por ejemplo, una tarjeta inteligente sin contacto o una pulsera), junto con un código que el usuario puede fácilmente recordar (por ejemplo, un código PIN). Este código proporciona un segundo factor de seguridad separado, preferiblemente independiente, que puede salvaguardar el recurso del ordenador incluso si el token de seguridad portátil y el dispositivo móvil se pierden o son robados juntos. Una realización preferida se refiere a proporcionar protección de datos y acceso seguro a aplicaciones y datos almacenados a los que se accede a través de un dispositivo móvil (como un teléfono o tableta) utilizando un token de hardware de comunicación de campo cercano (NFC) o un token de Bluetooth de corto alcance.
La autenticación segura de un usuario a través de un dispositivo móvil se está volviendo importante en dos situaciones diferentes: en primer lugar, para la autenticación del acceso del usuario a un recurso informático en el dispositivo móvil y, en segundo lugar, en un servidor remoto.
La mayoría de los sistemas existentes emplean el uso de una contraseña simple o PIN para autenticar al usuario. A pesar de la ubicuidad de los sistemas basados en contraseñas, tiene muchos problemas. la contraseña ideal es la que el usuario recuerda con facilidad. Sin embargo, para que las contraseñas sean seguras, deben ser largas y difíciles de predecir, lo que contradice el requisito anterior. Esto se ve exacerbado por la proliferación de contraseñas para la multitud de aplicaciones que un usuario usa normalmente, para las cuales las mejores prácticas de seguridad recomiendan que se utilicen diferentes contraseñas.
Además del acceso a las aplicaciones, algunos usuarios móviles desean garantizar un alto nivel de seguridad para los datos (incluidos archivos completos y datos contenidos en un archivo o una estructura de datos) en su dispositivo, frente a una serie de escenarios de amenazas externas. Por ejemplo, un usuario puede usar una aplicación en una tableta u otro dispositivo portátil que sincronice archivos con su P.C. de escritorio a través de un servicio de almacenamiento en línea (por ejemplo, Dropbox, Box.com [marcas comerciales]). Algunos de los archivos descargados pueden contener información confidencial, como documentos comerciales. El usuario desea protegerse contra la posibilidad de una violación de datos en caso de robo del dispositivo.
Una forma práctica de lograr esto hoy en día es habilitar el cifrado del dispositivo en el sistema operativo móvil, que utiliza una clave de cifrado derivada de la contraseña de la pantalla de bloqueo del dispositivo. Para máxima seguridad, esta contraseña debe ser larga y compleja. Sin embargo, usar una contraseña larga y compleja como contraseña para desbloquear la pantalla de bloqueo es extremadamente inconveniente para el usuario.
Debido a esto, la mayoría de los usuarios son reacios a usar una contraseña más complicada que un código PIN de 4 dígitos para desbloquear la pantalla de bloqueo. Un atacante experto podrá descifrar cualquier archivo almacenado en un dispositivo robado con métodos de ataque de fuerza bruta. Además, los datos confidenciales se descifran cada vez que se desbloquea el dispositivo, incluso cuando el usuario no está utilizando los datos, lo que aumenta el riesgo de una violación de datos de forma innecesaria.
Otro enfoque posible para el cifrado de datos es que la aplicación genere su propia clave de cifrado. El problema con este enfoque es que la clave tendría que estar protegida por una contraseña o derivada de ella por motivos de seguridad, o tendría que almacenarse dentro de la aplicación en forma de texto sin formato para su usabilidad. El primer enfoque hereda el mismo problema de complejidad de contraseña que el método de cifrado del dispositivo anterior, mientras que el segundo ofrece poca seguridad, ya que el atacante que podría comprometer los datos de texto sin formato podría leer fácilmente la clave de texto sin formato y descifrar los datos. Una forma de proporcionar un nivel adicional de seguridad a los usuarios de dispositivos móviles es exigir que el usuario también lleve un token físico portátil que se comunique con el dispositivo utilizando un sistema de comunicación inalámbrico, por ejemplo, Bluetooth o Bluetooth de baja energía (BLE). El dispositivo móvil comprueba de manera constante la presencia del token. Este token, cuando está presente dentro de un rango de varios metros del dispositivo móvil, verifica constantemente que el usuario está en verdad presente. Cuando el usuario abandona el token y el dispositivo pierde contacto, el dispositivo se protege contra cualquier acceso hasta que se recupere la comunicación con el token.
Nicholson, Corner and Noble describen un ejemplo de tal sistema en IEEE Transactions on Mobile Computing, Vol. 5 No 11 de noviembre de 2006, “Mobile Device Security Using Transient Authentication”. Hay una serie de desventajas de tal sistema. El canal de comunicaciones basado en difusión entre el token y el dispositivo móvil está sujeto a la escucha de un atacante que está dentro del rango cercano del token y el dispositivo. A pesar de estar cifrado, debido a los numerosos eventos de autenticación transitorios que tienen lugar entre el token y el dispositivo, el atacante tiene muchas oportunidades para criptoanalizar los mensajes de autenticación, así como para realizar análisis de tráfico sin siquiera tener que intentar un ataque criptoanalítico.
Un ladrón que roba el dispositivo móvil pero aún permanece dentro del alcance del token de seguridad que lleva el propietario del dispositivo podrá acceder a los recursos del dispositivo. El robo del dispositivo móvil y el token juntos inutiliza el sistema de seguridad.
En algunos otros sistemas existentes se ha proporcionado un nivel adicional de seguridad al exigir que un teléfono móvil con capacidad NFC o Bluetooth se autentique primero en la red móvil antes de ejecutar una aplicación. Luego, un token NFC/Bluetooth proporciona una clave asimétrica al teléfono que, a su vez, se autentica en un servicio de terceros al realizar una firma digital dentro del propio teléfono.
En el documento US-A-2011/0212707, se muestra un ejemplo genérico de tal sistema. Sin embargo, esto presenta una serie de desventajas. En particular, el cambio de la credencial de la aplicación requiere la reprogramación o el reemplazo del token; el número de credenciales de usuario aseguradas por el sistema está limitado por la (pequeña) capacidad de almacenamiento del token; y la pérdida del token plantea un riesgo directo de exposición de las credenciales del usuario. Además, las aplicaciones que se ejecutan en el dispositivo móvil y el servidor son capaces de hacer uso del sistema de seguridad descrito solo si se han programado específicamente para hacerlo. El sistema descrito no se puede utilizar con aplicaciones preexistentes.
Otro enfoque para la identificación de múltiples factores se describe en el documento US-A-2008/0289030. Aquí, un token sin contacto, tras la validación, se usa para permitir el acceso a las credenciales de autenticación aseguradas en el dispositivo móvil.
Esto tiene una serie de desventajas graves, incluida la necesidad de utilizar un almacenamiento seguro en el dispositivo. Normalmente, esto no está disponible para los desarrolladores de aplicaciones, ya que es mantenido y controlado por el fabricante del dispositivo (por ejemplo, teléfono móvil) o el proveedor del sistema operativo subyacente o un operador de red móvil. Además, es probable que no sea seguro hacer uso únicamente de un identificador de token como un medio para validar el token. Los token RFID normalmente se pueden leer con cualquier lector compatible y se pueden clonar con facilidad.
En el documento WO-A-2011/089423, se describe otro enfoque más. Describe un sistema en el que se utiliza la presencia de un token sin contacto para autorizar la ejecución de una función o aplicación segura, y está dirigido principalmente a usos de billetera móvil.
De nuevo, el sistema descrito tiene una serie de desventajas, principalmente que utiliza una forma de control lógico que es relativamente fácil de eludir.
De manera más general, en el entorno empresarial, existe un riesgo de seguridad significativo al permitir a los usuarios conectar dispositivos móviles a la red debido a una mayor probabilidad de acceso no autorizado a los datos (lo que lleva a la pérdida de la confidencialidad y/o integridad de los datos) como resultado de:
• códigos de acceso revelados inadvertidamente tales como PIN o códigos alfanuméricos, por ejemplo, de la navegación lateral,
• códigos de acceso fáciles de adivinar,
• dispositivos perdidos o robados que no están adecuadamente protegidos,
• uso no supervisado de dispositivos por un tercero,
• el sistema Hoverkey tiene como objetivo proporcionar soluciones para aplicaciones para contrarrestar estas amenazas.
Con las realizaciones de la presente divulgación, el usuario puede almacenar una clave maestra de alta capacidad criptográfica (128 bits o más en la actualidad) en el token de seguridad portátil, y esta clave puede usarse para proteger directamente la clave de cifrado de datos de una aplicación o una contraseña larga y compleja, de la que se puede derivar una clave de cifrado suficientemente larga y segura. Esto permite al usuario proteger cualquier dato almacenado en el dispositivo con una clave de cifrado muy fuerte. Si el dispositivo es robado, no es factible que cualquier atacante potencial descifre los datos cifrados en él sin el token asociado.
Las credenciales pueden almacenarse en el dispositivo móvil o, en forma remota, en la nube. El almacenamiento en la nube preferiblemente tiene las siguientes características:
• Las credenciales protegidas siempre se almacenan en la nube y se recuperan de la nube antes de su uso.
• El almacenamiento en caché local transparente es posible, pero no pretende ser un almacenamiento permanente (debe borrarse después de un período de tiempo de espera especificado).
• Si se pierde el dispositivo o el token, las credenciales pueden eliminarse con solo eliminar los archivos relevantes del servicio de almacenamiento en la nube para evitar un posible uso indebido.
• La sincronización de credenciales es posible entre dispositivos para el mismo usuario, lo que evita la necesidad de ingresar manualmente las mismas credenciales varias veces.
Menezes et al. divulgan en el “Handbook of Applied Cryptography”, 1997, CRC Press LLC, EE. UU., una reseña general de la criptografía como un estudio de técnicas matemáticas relacionadas con aspectos de la seguridad de la información tales como la confidencialidad, la integridad de los datos, la autenticación de entidades, y autenticación del origen de los datos.
El documento WO 2012/103584 A1 divulga la provisión de un token para autenticar dinámicamente a un usuario. El token incluye una memoria para almacenar datos seguros; un procesador para calcular las credenciales de autenticación del usuario basándose en los datos seguros y para construir una dirección de servidor basada en las credenciales de autenticación.
El documento GB 2423396 A revela un identificador que se lee de un token (por ejemplo, tarjeta inteligente, tarjeta SIM) y se utiliza para ubicar un registro en un almacén de datos (por ejemplo, un servidor remoto) que contiene datos de autenticación del usuario (por ejemplo, nombre de usuario, contraseña o máscara de bits). Los datos de autenticación del usuario se utilizan para autenticar al usuario. El acceso al token puede estar limitado por el uso de un PIN.
2. Antecedentes
2.1 Realizaciones y características preferibles de las mismas
La invención se define en las reivindicaciones independientes. En las reivindicaciones dependientes, se establecen realizaciones particulares. Algunas de las realizaciones descritas a continuación no son realizaciones de la invención según las reivindicaciones.
De acuerdo con la presente divulgación, se proporciona un método y sistema para autenticar el acceso a los recursos informáticos en un dispositivo móvil.
Según un primer aspecto, un método de autenticación de un recurso informático en un dispositivo móvil comprende: almacenar una autorización de recurso cifrada;
transmitir la autorización cifrada a un token de seguridad portátil separado; en el token, descifrar la autorización cifrada y generar, al menos parcialmente, una respuesta de desbloqueo;
transmitir en forma segura la respuesta de desbloqueo al dispositivo móvil;
requerir que un usuario se autentique por separado en el dispositivo móvil; y
desbloquear el recurso si la respuesta de desbloqueo requerida y la autenticación separada son válidas.
La respuesta de desbloqueo puede comprender una autorización simple, obtenida descifrando la autorización cifrada. La respuesta de desbloqueo puede comprender alternativamente una función (como un hash) de una autorización simple, obtenida descifrando la autorización cifrada, e información adicional. Por lo tanto, en un modo de uso, el token puede verificar y descifrar la autorización cifrada. Luego, en lugar de devolver una autorización simple al dispositivo, protegido por una sesión u otra clave de cifrado, el token puede realizar algunos cálculos sobre la autorización simple y posiblemente alguna otra información (por ejemplo, información basada en token), y devolver el resultado al dispositivo. Los ejemplos incluyen lo siguiente:
• Ejemplo 1: Firma digital: cálculo = función de firma digital, autorización simple = clave de firma privada; parámetro = hash del mensaje; salida = firma digital en el hash del mensaje
• Ejemplo 2: Derivación de clave: cálculo = función de derivación de clave; autorización simple = código maestro de derivación de claves; parámetros = información de contexto, longitud de salida; salida = clave derivada del código maestro
• Ejemplo 3: Reencriptación: cálculo = función de cifrado; autorización simple = clave de cifrado; parámetro = (otra) clave de cifrado; salida = la autorización simple cifrada con una clave diferente
La autorización puede comprender una contraseña, un PIN o una clave criptográfica.
La respuesta de desbloqueo puede transmitirse al dispositivo móvil bajo la protección de una clave de cifrado, como una clave de sesión.
El token puede almacenar credenciales de propiedad de usuario/token, y el descifrado del token se basa en las credenciales del usuario.
El método proporciona autenticación de dos factores (o de múltiples factores) al requerir que un usuario se autentique por separado en el dispositivo móvil, por ejemplo, mediante la validación de la autenticación en el dispositivo móvil en el token antes de enviar el código de desbloqueo. Preferiblemente, el método requiere una prueba de conocimiento del dispositivo (y en última instancia del usuario) antes de descifrar la autorización. Tal prueba de conocimiento puede incluir un PIN; una contraseña de muchos caracteres; un gesto de movimiento detectado por una cámara en el dispositivo; un gesto detectado por un panel táctil en el dispositivo, por ejemplo, un gesto que comprende patrones de deslizamiento que se ven comúnmente para desbloquear un teléfono con pantalla bloqueada; una secuencia de movimientos detectada por un giroscopio y/o acelerómetro del dispositivo; una contraseña hablada u otro sonido o secuencia de sonidos emitidos por el usuario; un patrón de toques realizados por el usuario en una carcasa del dispositivo, por ejemplo, que puede ser detectado por un micrófono del dispositivo; u otra prueba adecuada de conocimiento como será evidente para los expertos en la técnica.
En algunas realizaciones, un usuario puede autenticarse mediante información biométrica, por ejemplo, una huella digital o un escaneo del iris del usuario. Ventajosamente, el uso de una contraseña biométrica, como una huella dactilar, protege contra las escuchas de personas cercanas. También tiene la ventaja de que un usuario no tiene que recordar una contraseña o código.
La prueba podrá presentarse tras la autenticación mutua. Alternativamente, la autenticación del dispositivo puede ser completamente independiente de la autenticación del token.
Se puede ejecutar un servicio en el dispositivo móvil que controla las funciones criptográficas del dispositivo y el acceso al recurso. Se puede ejecutar un Applet en el token que proporciona funciones criptográficas del token. Las credenciales de usuario pueden ser generadas por el token y nunca dejar el token (o la aplicación ejecutándose en el token).
En algunas realizaciones, las credenciales de usuario se almacenan en una ubicación segura dentro del token, por ejemplo, donde la ubicación es proporcionada por hardware y/o software.
Preferiblemente, la autorización cifrada almacenada en el dispositivo móvil se puede descifrar solo con las correspondientes credenciales de usuario almacenadas en el token.
El método puede incluir verificar la integridad en el token mediante un código de autenticación de mensaje (MAC) recibido del dispositivo.
El método puede incluir la verificación de la integridad de la autorización cifrada en el token antes del descifrado. El dispositivo y el token pueden realizar una autenticación mutua criptográfica antes de la transmisión de la autorización cifrada.
El cifrado, el descifrado y/o la autenticación mutua pueden proporcionarse mediante criptografía de clave simétrica. En algunas realizaciones, la autenticación mutua puede proporcionarse mediante autenticación asimétrica. En tales realizaciones, la autenticación se puede realizar en ambas direcciones a través de dos pares de claves, un par de claves para cada dirección, de modo que cada uno de los dispositivos y token pueda identificar y autenticar al otro. En tales realizaciones, cada par de claves comprende una clave privada y una clave pública. Alternativamente, la autenticación puede realizarse cuando solo uno de los dispositivos está autenticado, por ejemplo, cuando algún otro aspecto del canal de comunicación proporciona la seguridad/autenticación adicional.
Un código de usuario puede pasarse del dispositivo al token y puede ser validado por el token antes de que tenga lugar la operación de descifrado.
El recurso puede comprender datos o una aplicación que se ejecuta o se almacena en el dispositivo móvil.
De acuerdo con otro aspecto se proporciona:
un dispositivo móvil;
un token que incluye almacenamiento de token para almacenar credenciales de usuario privadas, un sistema de comunicaciones de token y un procesador de token que proporciona funciones criptográficas;
y en el que, en uso, el sistema de comunicaciones del dispositivo transmite una autorización cifrada al token; se descifra en el token utilizando las credenciales de usuario; en donde el token genera, al menos parcialmente, una respuesta de desbloqueo, siendo transmitida en forma segura la respuesta de desbloqueo por el sistema de comunicaciones del token al dispositivo móvil; requerir que un usuario se autentique por separado en el dispositivo móvil; y desbloquear el recurso si la respuesta de desbloqueo requerida y la autenticación separada son válidas. El sistema de comunicaciones del dispositivo y el sistema de comunicaciones del token pueden comunicarse por aire, por ejemplo, mediante comunicación de campo cercano (NFC), Bluetooth o BLE. Alternativamente, el sistema de comunicaciones del dispositivo y el sistema de comunicaciones del token pueden comunicarse solo cuando el token está en contacto con el dispositivo a través de una interfaz física.
El sistema de comunicaciones del dispositivo puede enviar un código de usuario al token que es validado por el token antes de que tenga lugar la operación de descifrado.
El sistema de comunicaciones del dispositivo puede enviar un código de autenticación de mensaje (MAC) al token, que es validado por el token antes de que tenga lugar la operación de descifrado.
De acuerdo con otro aspecto, se proporciona:
un token de hardware para autenticar el acceso a un recurso informático a través de un dispositivo móvil, en donde el token comprende:
almacenamiento de token para el almacenamiento de una pluralidad de credenciales de usuario; un sistema de comunicaciones de token para comunicarse con un dispositivo móvil; un procesador de token que proporciona funciones criptográficas; y donde, en uso:
al recibir el sistema de comunicaciones de token una autorización cifrada, el procesador de token verifica la integridad y descifra la autorización cifrada y genera, al menos parcialmente, una respuesta de desbloqueo, y en el que el sistema de comunicaciones de token transmite en forma segura la respuesta de desbloqueo para su uso por un dispositivo móvil.
El dispositivo móvil puede comprender cualquier dispositivo de hardware móvil o portátil que sea capaz de ejecutar aplicaciones de usuario y manejar funciones de comunicación y criptográficas. Los dispositivos típicos incluyen teléfonos móviles, tabletas, ordenadores portátiles, teléfonos inteligentes, relojes inteligentes, gafas inteligentes, y similares. El token puede ser cualquier dispositivo portátil o token de hardware móvil que sea capaz de comunicarse (preferiblemente comunicación sin contacto) con un dispositivo móvil y que incluya almacenamiento y un sistema ejecutable que sea capaz de manejar comunicaciones y funciones criptográficas. Por ejemplo, el token puede ser un dispositivo móvil o portátil, como un teléfono inteligente, reloj inteligente, gafas inteligentes, teléfono móvil, tableta, ordenador portátil, o similar. En algunas realizaciones, el token y el dispositivo móvil son ambos teléfonos inteligentes móviles. En algunas realizaciones, el token puede comprender un llavero, una tarjeta inteligente NFC o un auricular inalámbrico.
El recurso informático protegido puede guardarse en la memoria o almacenamiento de un dispositivo o (donde una aplicación) puede mantenerse lista para su ejecución o puede estar ejecutándose en un entorno de ejecución. Con ese fin, el dispositivo puede incluir un almacenamiento, una memoria y un procesador.
En algunas realizaciones, el token será una tarjeta inteligente sin contacto, aunque serían igualmente posibles otros token que la persona sostenga, porte o lleve puesta. Los token adecuados pueden incluir un dispositivo portátil, como un anillo para llevar en el dedo del usuario, otra joya que lleve el usuario, un dispositivo incorporado en un reloj, cinturón, gafas, ropa, insignia, pulsera de fitness o cualquier otra cosa que lleve normalmente el usuario, o incluso un dispositivo incrustado debajo de la piel del usuario. En algunas realizaciones, el token puede coserse o fijarse a una prenda de vestir u otro accesorio que lleve el usuario. Las formas de realización en las que el usuario lleva el token son ventajosas, ya que es más probable que el usuario tenga el token portátil en su persona cuando sea necesario, y es menos probable que el usuario pierda el token que cuando el token es un artículo separado que debe llevarse, por ejemplo, en un bolso o billetera.
El token puede tener botón(es), área(s) sensible(s) al tacto u otros medios para permitir la retroalimentación/entrada manual o de otro usuario a través del token.
En algunas realizaciones, la clave maestra se almacena en el token en hardware y/o software dedicado a la función de proporcionar almacenamiento seguro. En algunas realizaciones, la clave maestra se almacena en el token en zonas seguras dedicadas proporcionadas por la arquitectura del hardware y/o software del dispositivo, por ejemplo, los dispositivos pueden utilizar tecnología ARMs TrustZone, una UICC (comúnmente conocida como tarjeta SIM) o un elemento seguro integrado. En algunas realizaciones, la propia clave podría almacenarse en un llavero seguro implementado por el sistema operativo y/u otro software presente en el dispositivo.
En algunas realizaciones, el token puede comprender un entorno de hardware y/o software seguro y confiable para el almacenamiento de la clave maestra y la ejecución de operaciones de cifrado y descifrado. Por ejemplo, el entorno seguro puede comprender un elemento seguro, un módulo de plataforma fiable, un entorno de cifrado fiable o cualquier otro entorno adecuado como resultará evidente para los expertos en la técnica. Ventajosamente, muchos dispositivos inteligentes comprenden tales entornos, por ejemplo, Samsung Galaxy S4.
El token portátil puede ser un dispositivo dedicado con el propósito de cifrar/descifrar credenciales de autenticación en forma segura, o puede ser un dispositivo que, además de otras funciones, posiblemente primarias, también proporciona cifrado/descifrado seguro de credenciales de autenticación.
En el caso de que el token comprenda un dispositivo que tenga otras funciones, este puede ser un dispositivo existente en posesión del usuario (por ejemplo, un teléfono inteligente) y, por lo tanto, tiene la ventaja de que el usuario no necesita recordar o modificar su comportamiento para llevar un token o dispositivo adicional.
La autenticación de la aplicación almacenada en el dispositivo puede comprender una contraseña o PIN de la aplicación. Las credenciales de usuario almacenadas en el token pueden comprender una clave criptográfica privada. Se prefiere que la comunicación entre el token y el dispositivo móvil utilice NFC, aunque también se podrían utilizar otros canales, incluidos Bluetooth, Bluetooth de baja energía (BLE) u otros tipos de comunicación por radiofrecuencia. También se prevén token que requieran contacto con el dispositivo móvil, incluidas tarjetas magnéticas y tarjetas de contacto eléctrico.
En algunas realizaciones, la comunicación entre el dispositivo móvil y el token portátil puede implementarse usando cualquier forma de comunicación que pueda ser suficientemente segura para la transmisión de credenciales de autenticación, como será evidente para los expertos en la técnica. Dicha comunicación podría incluir una red WiFi local, una conexión WiFi-Direct, un cable USB directo, una cámara frontal del dispositivo móvil y una pantalla del token (o viceversa) cuando se colocan uno frente al otro, una conexión infrarroja, frecuencias de audio usando un altavoz del dispositivo móvil y un micrófono del token (o viceversa), o cualquier otro medio de comunicación como será evidente para los expertos en la técnica.
Un sistema preferido comprende preferiblemente:
1. Uno o más dispositivos móviles
2. Un token NFC, Bluetooth o BLE programado para:
a) poder autenticarse mutuamente con cualquiera de los dispositivos del usuario
b) responder solo a los comandos emitidos por cualquiera de los dispositivos del usuario
c) realizar el cifrado y la protección de la integridad de los datos proporcionados por el dispositivo.
d) devolver los datos protegidos criptográficamente
e) realizar el descifrado y la verificación de la integridad de los datos previamente protegidos.
f) requerir la validación de un PIN de usuario antes de realizar operaciones de descifrado
3. Una aplicación de administración de contraseñas instalada en cada dispositivo móvil
4. Cualquier cantidad de aplicaciones de terceros protegidas por el sistema
De acuerdo con otro aspecto, se proporciona un método para autenticar a un usuario para que acceda a un recurso informático a través de un dispositivo móvil, que comprende:
almacenar una autorización de recursos cifrada;
transmitir la autorización cifrada a un token de seguridad portátil separado;
en el token, descifrar la autorización cifrada y generar, al menos parcialmente, una respuesta de desbloqueo; transmitir en forma segura la respuesta de desbloqueo al dispositivo móvil; y proporcionar acceso al recurso si la respuesta de desbloqueo requerida es válida;
en el que se requiere que un usuario se autentique en el dispositivo móvil y la autenticación en el dispositivo móvil se valida en el token antes de que se envíe la respuesta de desbloqueo.
De acuerdo con otro aspecto, se proporciona un sistema de autenticación de un usuario para acceder a un recurso informático a través de un dispositivo móvil con un token de seguridad portátil, que comprende:
un dispositivo móvil;
un token que incluye almacenamiento de token para almacenar credenciales de usuario privadas, un sistema de comunicaciones de token y un procesador de token que proporciona funciones criptográficas;
y en el que, en uso, el sistema de comunicaciones del dispositivo transmite una autorización cifrada al token; se descifra en el token utilizando las credenciales de usuario; en donde el token genera, al menos parcialmente, una respuesta de desbloqueo, siendo transmitida en forma segura la respuesta de desbloqueo por el sistema de comunicaciones del token al dispositivo móvil; y proporciona acceso al recurso si la respuesta de desbloqueo requerida es válida;
en el que se requiere que un usuario se autentique en el dispositivo móvil y la autenticación en el dispositivo móvil se valida en el token antes de que se envíe la respuesta de desbloqueo.
De acuerdo con otro aspecto, se proporciona un token de hardware para autenticar a un usuario para acceder a un recurso informático a través de un dispositivo móvil, que comprende:
almacenamiento de token para el almacenamiento de una pluralidad de credenciales de usuario; un sistema de comunicaciones de token para comunicarse con un dispositivo móvil; un procesador de token que proporciona funciones criptográficas; y en el que, en uso:
al recibir el sistema de comunicaciones de token una autorización cifrada, el procesador de token verifica la integridad y descifra la autorización cifrada y genera, al menos parcialmente, una respuesta de desbloqueo, en la que el sistema de comunicaciones de token transmite en forma segura la respuesta de desbloqueo para su uso por un dispositivo móvil, y en el que se requiere que un usuario se autentique en el dispositivo móvil y la autenticación en el dispositivo móvil se valida en el token antes de que se envíe la respuesta de desbloqueo.
De acuerdo con otro aspecto, se proporciona un método para autenticar a un usuario para que acceda a un recurso informático a través de un dispositivo móvil que comprende:
almacenar una autorización de recursos cifrada;
transmitir la autorización cifrada a al menos un dispositivo de token de seguridad portátil separado;
en el dispositivo token, descifrar la autorización cifrada y generar al menos parcialmente una respuesta de desbloqueo; transmitir en forma segura la respuesta de desbloqueo al dispositivo móvil; y proporcionar acceso al recurso si la respuesta de desbloqueo requerida es válida;
en el que se requiere que un usuario se autentique en el dispositivo móvil o en el dispositivo token, y la autenticación se valida en el dispositivo token antes de que se envíe la respuesta de desbloqueo.
De acuerdo con otro aspecto, se proporciona un sistema de autenticación de un usuario para acceder a un recurso informático a través de un dispositivo móvil con al menos un dispositivo de token de seguridad portátil, que comprende: un dispositivo móvil;
al menos un dispositivo de token que incluye almacenamiento de token para almacenar credenciales de usuario privadas, un sistema de comunicaciones de token y un procesador de token que proporciona funciones criptográficas; y en el que, en uso, el sistema de comunicaciones del dispositivo móvil transmite una autorización cifrada al dispositivo de token; se descifra en el dispositivo de token utilizando las credenciales del usuario; el dispositivo de token genera, al menos parcialmente, una respuesta de desbloqueo, siendo transmitida en forma segura la respuesta de desbloqueo por el sistema de comunicaciones de token al dispositivo móvil; y proporciona acceso al recurso si la respuesta de desbloqueo requerida es válida; en el que se requiere que un usuario se autentique en el dispositivo móvil o en el dispositivo token, y la autenticación se valida en el dispositivo token antes de que se envíe la respuesta de desbloqueo. De acuerdo con otro aspecto, se proporciona un dispositivo de token de hardware para autenticar a un usuario para acceder a un recurso informático a través de un dispositivo móvil, en el que el dispositivo de token comprende: almacenamiento de token para el almacenamiento de una pluralidad de credenciales de usuario; un sistema de comunicaciones de token para comunicarse con un dispositivo móvil; un procesador de token que proporciona funciones criptográficas; y donde, en uso:
al recibir el sistema de comunicaciones de token una autorización cifrada, el procesador de token verifica la integridad y descifra la autorización cifrada y genera, al menos parcialmente, una respuesta de desbloqueo, en la que el sistema de comunicaciones de token transmite en forma segura la respuesta de desbloqueo para su uso por un dispositivo móvil, y en el que se requiere que un usuario se autentique en el dispositivo móvil o en el dispositivo de token, y la autenticación se valida en el dispositivo de token antes de que se envíe la respuesta de desbloqueo.
En el caso de que un usuario se autentique en el dispositivo de token, se puede utilizar un dispositivo de token que comprenda una pantalla y/o un teclado integrado. Puede usarse una tarjeta inteligente, por ejemplo, las disponibles comercialmente como las producidas por NagraID. Alternativamente, el token puede ser un teléfono inteligente, reloj inteligente, tableta, o similar.
2.2 Nivel 1 de Hoverkey
Una realización preferida se incorpora preferiblemente dentro de un producto denominado Hoverkey. El diseño de Hoverkey está optimizado para facilitar la integración con aplicaciones móviles y aplicaciones web existentes, así como para facilitar su uso. Implementa un sistema seguro de almacenamiento y recuperación de credenciales de usuario (por ejemplo, contraseña), protegido mediante token NFC.
La presente solicitud se refiere particularmente a una realización que utiliza un diseño de seguridad específico, denominado en esta descripción como “nivel 1”. Las referencias al nivel 1 de Hoverkey (o Hoverkey L1) deben entenderse en consecuencia.
2.2.1 Concepto de seguridad
El concepto detrás de Hoverkey L1 está diseñado para funcionar con todas las aplicaciones existentes que autentican al usuario mediante una combinación de nombre de usuario y contraseña, aunque se pueden utilizar métodos de autenticación distintos de las contraseñas. Normalmente, sin ningún cambio en la aplicación a la que se accede, la tecnología simplemente reemplaza la entrada manual de la contraseña del usuario con un toque de un token NFC. Esta realización ofrece las siguientes ventajas:
• No se requieren cambios para el servidor de aplicaciones, lo que permite una fácil integración
• Los cambios en cualquier aplicación cliente existente se pueden implementar fácilmente mediante el uso de un componente Hoverkey.
• Mayor seguridad al permitir que la tecnología “recuerde” las contraseñas del usuario, lo que significa
■ El usuario puede elegir contraseñas más seguras (más largas y más “aleatorias”)
■ El usuario puede elegir una contraseña diferente para distintas cuentas sin el temor o la incomodidad de las contraseñas olvidadas
• Elimina la necesidad de ingresar contraseñas alfanuméricas en un teclado en pantalla, especialmente cuando se incluyen símbolos, que es lento y propenso a errores y sujeto a ataques de navegación por encima del hombro. 3. Descripción general
Las realizaciones de la presente divulgación se pueden llevar a la práctica de varias formas y ahora se describirá una realización específica, a modo de ejemplo, con referencia a los dibujos adjuntos, en los que:
Fig. 1 muestra la arquitectura de alto nivel Hoverkey L1;
Fig. 2 muestra la organización de la tarjeta Java y los applets
Fig. 3 muestra el protocolo de activación;
Fig. 4 muestra el método de agregar un nuevo dispositivo a una tarjeta activada;
Fig. 5a muestra el protocolo de registro para una aplicación web privada;
Fig. 5b muestra el protocolo de registro para una aplicación pública;
Fig. 6 muestra el protocolo de acceso por contraseña;
Fig. 7 muestra el proceso de cifrado de contraseña;
Fig. 8 muestra cifrado de recuperación de contraseña;
Fig. 9 muestra la jerarquía de claves; y
Fig. 10 muestra los estados del Applet y su secuencia.
3.1 Modelo de implementación
En un nivel alto, el modelo de implementación preferido de Hoverkey se resume a continuación:
• Cada usuario tiene uno o más dispositivos móviles habilitados para NFC, que pueden ser proporcionados por la empresa o propiedad del usuario.
• Cada usuario recibe un token de seguridad NFC único.
• Cada token NFC se puede emparejar con todos los dispositivos que pertenecen al mismo usuario.
Se toman los siguientes pasos para implementar una Hoverkey:
• Hoverkey compra token NFC en blanco a los revendedores
• Una vez recibida la prueba o la orden de compra, Hoverkey formatea los token NFC para el cliente o un emisor asociado.
• Al recibir el token NFC, el usuario invoca la función de activación
• El usuario luego configura sus aplicaciones habilitadas para Hoverkey con sus credenciales
3.2 Arquitectura
La arquitectura de alto nivel de Hoverkey L1 se ilustra en la Figura 1. Cada aplicación de desarrollador (aplicación 1, aplicación 2 y aplicación 3 en el diagrama) está integrada con el componente Hoverkey L1, lo que le permite comunicarse con el servicio Hoverkey a través de un protocolo de comunicación entre procesos (IPC).
En cada dispositivo móvil, hay una única instancia del servicio Hoverkey que acepta solicitudes de una aplicación y cuando se requiere una contraseña. El servicio Hoverkey recupera la contraseña en nombre de la aplicación a través de una serie de intercambios con el Applet Java Card a través de la interfaz NFC.
Las ventajas de utilizar un servicio incluyen:
• Elimina las claves de autenticación necesarias para compartir (para el acceso al Applet) entre aplicaciones
• No es necesario que las aplicaciones requieran permisos NFC
• Acceso centralizado y mediado al Applet que permite evitar el acceso simultáneo.
En la plataforma Android, los posibles mecanismos de IPC incluyen el método Intent para una integración simple y gruesa, o el método de Servicio Remoto usando el Lenguaje de Definición de Interfaz de Android (AIDL) para una integración fina y de bajo nivel.
Las contraseñas protegidas por Hoverkey son encriptadas por el Applet de la tarjeta al registrarse y almacenadas en el dispositivo móvil dentro de la aplicación Hoverkey. Cuando se requiere acceso, la aplicación registrada solicita la contraseña a través de la aplicación Hoverkey que, a su vez, solicita que el Applet descifre la contraseña.
3.3 Principales características de diseño de seguridad
• Activación y emparejamiento: un token de Hoverkey solo se puede utilizar con un dispositivo con el que se haya emparejado (en el momento de la activación). Cada dispositivo móvil solo puede emparejarse con un token. Cada token se puede emparejar con hasta cuatro dispositivos.
• Registro: para defenderse de aplicaciones maliciosas, las aplicaciones de terceros solo pueden usar los servicios de Hoverkey después de un proceso seguro de registro en el dispositivo. El acceso posterior con contraseña requiere prueba de registro previo.
• Dos factores: cada contraseña puede protegerse adicionalmente con un PIN elegido por el usuario para proporcionar una forma de autenticación de dos factores. Opcionalmente, se pueden proporcionar tres o más niveles de autenticación.
• Seguridad criptográfica: Hoverkey utiliza algoritmos y modos criptográficos estándar de la industria para proteger las contraseñas de los usuarios, respaldados por las mejores prácticas en la administración segura de claves.
• Seguridad de token: los token de Hoverkey se gestionan con seguridad durante todo su ciclo de vida para garantizar que los riesgos se minimicen en todas las etapas.
3.4 Uso de Hoverkey L1
Para utilizar Hoverkey L1, se siguen los siguientes pasos:
1. Una nueva organización de clientes solicita tarjetas Hoverkey L1 para sus usuarios móviles.
2. Hoverkey (o socio) genera un OrgID para el cliente.
a) Opcionalmente, se genera una clave de registro para el cliente si tiene la intención de desarrollar sus propias aplicaciones privadas, que se entrega al cliente o al desarrollador para que la incruste en sus aplicaciones.
3. Hoverkey formatea la cantidad requerida de tarjetas con OrgID, MasterAPIKey, Admin Key, User Authentication Key y PUK, y las envía al Cliente o al Desarrollador.
4. El equipo de desarrollo del cliente integra el componente Hoverkey en sus propias aplicaciones y las configura con su OrgID y RegKey durante el desarrollo.
5. El usuario instala la o las aplicaciones del cliente o desarrollador y la aplicación Hoverkey (de Google Play Store).
6. El usuario recibe un token (formateado) de Sys Admin y un correo electrónico de activación (que contiene una URL de activación).
7. El usuario activa el token desde la aplicación Hoverkey y establece un PIN:
a) La aplicación Hoverkey descarga un archivo de perfil de configuración
b) Se recuerda al usuario que elimine el correo electrónico de activación cuando se complete la activación.
8. Las aplicaciones de terceros se registran con la aplicación Hoverkey (normalmente con un nombre de usuario y contraseña, una vez para cada aplicación de cliente o desarrollador).
9. El usuario comienza a utilizar aplicaciones móviles habilitadas para Hoverkey.
10. El usuario puede emparejar dispositivos adicionales con el token hasta cuatro dispositivos.
a) Si se utiliza un servidor Hoverkey, los datos de la aplicación se pueden sincronizar desde el servidor
b) Todas las aplicaciones habilitadas para Hoverkey deben volver a registrarse en el nuevo dispositivo (según el paso 8).
4. Componentes del sistema
[4.1 Dispositivo móvil]
Hoverkey L1 es preferiblemente compatible con teléfonos inteligentes Android habilitados para NFC, aunque, por supuesto, otras plataformas son igualmente posibles.
4.2 Aplicación Hoverkey L1
Las siguientes subsecciones resumen las funciones proporcionadas por la aplicación Hoverkey L1.
1. Activación de token
a) Emparejamiento de token NFC con dispositivo móvil
b) Configuración de PIN en gestión de token
c) Cambio de PIN
d) Desbloqueo de PIN
e) Revocación de un token
2. Registro de la aplicación (configuración del nombre de usuario y la contraseña)
3. Gestión de aplicaciones
a) Cambio de contraseña
b) Dar de baja una aplicación
4.3 Aplicaciones móviles de terceros
• Incorporar el componente Hoverkey L1 de acuerdo con las pautas de implementación.
4.4 Token NFC
La Figura 2 muestra la organización del cable Java y los Applets.
El token NFC es un token sin contacto que admite especificaciones Java Card y GlobalPlatform. El token preferiblemente tiene un alto nivel de aprobación de seguridad bajo los esquemas de Criterios Comunes y/o FIPS. El producto inicial se implementa en el factor de forma de la norma ISO 7810 (tarjeta de crédito).
El token está diseñado para admitir múltiples Applets de Java Card. El sistema Hoverkey requiere la instalación de un Applet, dejando espacio en la tarjeta para Applets de terceros.
4.5 Servicio de almacenamiento de datos basado en la nube
Hoverkey admite la recuperación y sincronización de credenciales bajo demanda mediante un servicio de almacenamiento en la nube. Hay muchas implementaciones posibles de un servicio en la nube utilizando una variedad de protocolos y, de hecho, ya existen muchos.
Como mínimo, un servicio adecuado admite preferiblemente las siguientes funciones:
1. Identificación de un usuario con un identificador único
2. Almacenamiento de datos arbitrarios en el servidor en un archivo y directorio con nombres arbitrarios
3. Recuperación de datos almacenados previamente
Una implementación más preferible de un servicio de almacenamiento de credenciales de Hoverkey también proporciona:
1. Autenticación sólida del usuario
2. Comunicación con el dispositivo del usuario a través de un canal seguro
3. Medidas de alta disponibilidad
4. Gestión segura de las instalaciones
En la práctica, Hoverkey puede admitir servicios populares en la nube como DropBox o puede proporcionar su propio servicio personalizado para los usuarios de Hoverkey.
4.5.1 Applet de Hoverkey L1
El Applet implementa:
• El proceso de activación (también conocido como “personalización” en la terminología común de tarjetas inteligentes) que incluye:
• Emparejamiento de dispositivo/token
• Generación de clave de cifrado de contraseña (PEK)
• Configuración inicial del PIN de usuario
• Funciones de cifrado/descifrado de contraseña
• El protocolo de autenticación mutua criptográfica
El Applet de Hoverkey almacena y administra los siguientes objetos de datos:
Figure imgf000012_0001
4.5.2 Ciclo de vida del token
A continuación, se describe el ciclo de vida de un token NFC:
1. El distribuidor proporciona tarjetas a Hoverkey
2. Formateo de la tarjeta
a) Implementaciones de bajo volumen: Hoverkey formatea tarjetas y suministros para el Cliente o Desarrollador. b) Implementaciones de gran volumen: Hoverkey proporciona a una impresora de tarjetas de terceros de confianza:
• Gráficos superpuestos de tarjetas
• OrgID, MasterAPIKey y AdminKey
• Conjunto de claves de autenticación y PUK
3. El usuario activa la tarjeta
4. El token activado es:
a) revocado y reemplazado en caso de pérdida o robo
b) devuelto y reemplazado si se vuelve defectuoso
c) devuelto cuando el usuario abandona la organización del cliente
d) actualizado o reemplazado cuando un nuevo Applet o una nueva versión del Applet existente están disponibles para el usuario
5. Diseño de seguridad de alto nivel
5.1 Resumen
El usuario puede descargar la aplicación Hoverkey L1 desde Google Play Store y, por lo tanto, no tiene ninguna información específica del cliente durante la instalación.
Los token NFC son formateados por Hoverkey, que incluye la carga de datos del Cliente. Tras la activación, estos datos se transfieren a la aplicación Hoverkey L1 para permitir que las aplicaciones para desarrolladores se registren. Las aplicaciones para desarrolladores deben registrarse con el servicio Hoverkey (parte de la aplicación Hoverkey L1) antes de que se habiliten para NFC. El registro implica asegurar la contraseña del usuario con su token NFC (activado).
5.2 Cifrado de contraseña
La función principal de Hoverkey L1 es proporcionar almacenamiento y recuperación seguros de contraseñas. La contraseña está encriptada y su integridad protegida junto con sus metadatos. Cuando se requiere la contraseña, el PEK almacenado en el token NFC se utiliza para verificar y descifrar las contraseñas protegidas.
5.3 Mensajería segura a través de NFC
La especificación de la Plataforma Global (GP) admite el intercambio seguro de mensajes APDU entre la tarjeta y el terminal. GP admite tres niveles de seguridad de mensajería:
1. Solo autenticación de entidad
2. (1) anterior más protección de integridad
3. (2) anterior más protección de confidencialidad.
Hoverkey L1 admite mensajería segura de nivel 3 mediante el protocolo GP Secure Channel Protocol versión 2 (SCP02).
5.4 PIN
Con el fin de admitir un nivel de seguridad mejorado, Hoverkey L1 admite el uso adicional de un PIN que comparten todas las aplicaciones de terceros (ya que es un PIN validado dentro del Applet de token). El usuario debe configurar un PIN en la activación, pero cada aplicación de terceros puede tener su propia política sobre dónde se requiere un PIN para acceder.
El administrador del sistema puede hacer cumplir el requisito de un código PIN de usuario (para todas las aplicaciones) en la activación mediante el proceso de configuración.
6. Protocolos y procedimientos de seguridad
6.1 Activación
La Figura 3 muestra el protocolo de activación.
Condiciones previas
• AuthKey (simple u ofuscada) obtenida de la URL de activación
• Datos de configuración descargados al servicio Hoverkey a través de la URL de activación, que incluyen: políticas de requisitos de PIN
■ Datos de marca compartida
■ Configuración de informes
• El Applet está formateado con OrgID y MasterAPIKey y no se ha activado
Objetivos
• Establecer una clave de autenticación compartida (emparejamiento) entre el Applet y el servicio Hoverkey
• Generar y almacenar la clave de cifrado de contraseña (PEK) en el token
• Inicializar PIN de usuario
• Transferir OrgID y MasterAPIKey al servicio Hoverkey (para la validación de aplicaciones para desarrolladores) Pasos (refiriéndose a los números correspondientes establecidos en la Figura 3).
1. El servicio Hoverkey consulta el token para TokenID
2. AuthKey puede proporcionarse en texto plano o, para mayor seguridad, ofuscado con el TokenID.
a) Si está ofuscado, el servicio Hoverkey desofusca (desencripta) AuthKey con TokenID (como se muestra en la Figura 3)
b) Si está en texto sin formato, se omite el Paso 1 y el Paso 2 solo necesitará almacenar AuthKey (texto sin formato) 3. El servicio y el Applet realizan una autenticación mutua
4. El servicio envía una solicitud de activación, proporcionando un número aleatorio, PIN y DeviceID
5. Applet almacena PIN y DeviceID, y deriva PEK de Random
6. Applet devuelve TokenID, OrgID y MasterAPIKey. Estos son almacenados por el servicio Hoverkey, junto con RegKey después de derivar de MasterAPIKey.
7. El servicio regresa OK
8. Applet actualiza su estado a activado
9. Tras la activación exitosa, si el usuario no tiene más dispositivos para emparejar con su token, debe eliminar el correo electrónico de activación (y cualquier copia) de su cuenta de correo.
6.2 Agregar un nuevo dispositivo
La Figura 4 muestra el método de agregar un nuevo dispositivo a un token activado.
Condiciones previas
• El Applet ya ha sido activado (por otro dispositivo)
Objetivo
• Transferir OrgID y APIKey al servicio Hoverkey
Pasos (refiriéndose a los números correspondientes establecidos en la Figura 4)
1. El servicio Hoverkey recupera AuthKey del enlace proporcionado por el correo electrónico de activación
2. El servicio se autentica mutuamente con el Applet (ya activado)
3. El servicio proporciona un PIN para autenticarse en el Applet, junto con su propio DeviceID que se agregará 4. Applet valida el PIN, almacena DeviceID
5. Applet devuelve OrgID, MasterAPIKey y TokenID
6. El servicio almacena OrgID y APIKey, junto con RegKey después de derivar de MasterAPIKey.
7. Tras la activación exitosa, si el usuario no tiene más dispositivos para agregar (emparejar) su token, debe eliminar el correo electrónico de activación (y cualquier copia) de su cuenta de correo.
6.3 Registro de la aplicación
El propósito del registro es que la aplicación de terceros se autentique en la aplicación Hoverkey y, al mismo tiempo, proporcione a la aplicación Hoverkey las credenciales de usuario para su almacenamiento seguro.
Tras el registro exitoso, Hoverkey emite la aplicación de terceros con su APIKey aleatoria única para su posterior acceso a la API de Hoverkey (es decir, una APIKey incluso si está comprometida no será válida en un dispositivo diferente).
Hay dos métodos para el registro de aplicaciones:
1. Método de clave asimétrica, principalmente para aplicaciones públicas, es decir, aquellas disponibles en las tiendas de aplicaciones.
2. Método de clave simétrica, principalmente para aplicaciones privadas, es decir, aquellas desarrolladas internamente y distribuidas por medios no públicos.
Método de clave asimétrica
Un desarrollador de aplicaciones públicas que desee integrar Hoverkey en su aplicación debe obtener una clave de registro (RegKey) en forma de certificado, que está incrustado en la aplicación antes de su lanzamiento público. El certificado es emitido por Hoverkey y firmado con la clave privada de Hoverkey. La clave pública correspondiente está incrustada en la aplicación Hoverkey para verificar el certificado de la aplicación. La idea es que el certificado dé fe de varios atributos de la aplicación (que deben poder obtenerse en forma independiente del sistema operativo), lo que dificulta que una aplicación maliciosa se haga pasar por auténtica.
Atributos que deben certificarse incluyen (para la aplicación de Android):
• Su AppID única (nombre del paquete en Android cuya singularidad está garantizada si se descarga desde Play Store).
Método de clave simétrica
Una aplicación privada, es decir, una que no se implemente a través de la tienda de aplicaciones pública, utilizará un esquema de registro diferente. Dado que el desarrollador de la aplicación puede querer implementar sus aplicaciones en forma privada sin la participación de Hoverkey, empleamos un método alternativo que permite al desarrollador generar su propia RegKey (basada en claves simétricas).
La Figura 5 muestra el protocolo de registro. La Figura 5a ilustra el registro para una aplicación web privada y la Figura 5b ilustra el registro para una aplicación pública. Se aplica el mismo número de referencia a cada uno.
Condición previa
• El token NFC se ha activado correctamente (si no, la activación se invocará en el paso 2)
Objetivos
• Configurar el servicio Hoverkey para usar con esta aplicación
• Crear una contraseña protegida con token NFC para usar con los pasos del servicio Hoverkey (refiriéndose a los números establecidos en las Figuras 5a y 5b)
1. La aplicación se registra con OrgID (solo aplicación privada), APIKey, AppID, Política y la contraseña del usuario. En el caso de una aplicación pública, RegKey será un certificado firmado digitalmente. Para una aplicación privada, RegKey será una cadena de bytes pseudoaleatoria. Las políticas admitidas actualmente incluyen:
a) Si se requiere PIN para esta aplicación.
2. Hoverkey Service comprueba si se ha activado. Si está activado, valida la RegKey proporcionada por la aplicación. Para una aplicación pública, la clave de registro se valida mediante la clave pública de registro de la aplicación Hovkery. Para una aplicación privada, el OrgID proporcionado se verifica y RegKey se valida con el derivado de MasterAPIKey.
3. El servicio realiza la autenticación mutua con Applet. Además, Applet valida el DeviceID proporcionado por el Servicio.
4. El servicio envía la solicitud de cifrado de la contraseña, junto con la política y el PIN para su validación.
5. El Applet valida el PIN y cifra la contraseña y la política con PEK.
6. Para validar el cifrado exitoso, el Servicio envía una solicitud de descifrado con la contraseña cifrada, proporcionando Session PEKs (Session PEK ENC y Session PEK_MAC) y opcionalmente un PIN (según la política).
7. Applet descifra y devuelve la contraseña en texto plano, cifrada en SessionPEK.
8. El servicio descifra y verifica la contraseña de texto sin formato devuelta y devuelve el éxito a la aplicación.
9. El servicio guarda el ID de usuario, la política y la contraseña cifrada en el servidor de almacenamiento en la nube como AppID/DeviceID/credentials.dat.
6.4 Recuperación de contraseña
La Figura 6 muestra el protocolo de acceso por contraseña.
Condición previa
• La aplicación se ha registrado con el servicio Hoverkey y ha configurado una contraseña cifrada
• El Applet está en estado activado
Objetivo
• Recupera la contraseña especificada que ha sido protegida por el token NFC
• Opcionalmente, recupera la ID de usuario (si está almacenado)
Pasos (refiriéndose al número establecido en la Figura 6)
1. La aplicación envía el comando de solicitud de contraseña, proporcionando APIKey, AppID.
2. El servicio Hoverkey valida la solicitud.
3. El servicio obtiene la ID de usuario, la política y la contraseña cifrada de la aplicación al recuperar el archivo AppID/DeviceID/credencials.dat del almacenamiento en la nube y luego solicita un PIN al usuario.
4. El servicio se autentica mutuamente con Applet. Además, Applet valida la DeviceID proporcionado por el Servicio.
5. El servicio envía la contraseña cifrada al Applet para que la descifre, proporcionando claves de sesión (Session PEK_ENC y Session PEK_MAC) y un PIN.
6. Applet autentica y descifra la entrada y valida el PIN.
7. Applet devuelve la contraseña de texto sin formato cifrada bajo Session PEK y la integridad protegida con Session PEK_MAC.
8. La contraseña se descifra y se devuelve a la aplicación.
6.5 Cambio de contraseña para la aplicación
Para cambiar la contraseña de una aplicación, los servicios Hoverkey simplemente reemplazan la contraseña cifrada existente por una nueva, con los siguientes pasos:
1. Autenticación mutua, Applet valida DeviceID
2. Requiere PIN
3. El servicio envía una nueva contraseña y política
4. Applet devuelve una contraseña cifrada
6.6 Cambio de PIN
Para cambiar el PIN del token, se siguen los siguientes pasos:
1. Autenticación mutua, Applet valida DeviceID
2. Requiere PIN
3. El usuario ingresa nuevo PIN (dos veces).
4. Applet almacena nuevo PIN.
6.7 Dar de baja la aplicación
Eliminar la siguiente información de la aplicación:
(No se requiere el token de Hoverkey)
1. AppID
2. Cualquier contraseña encriptada
3. Cualquier nombre de usuario guardado
4. Política
6.8 Revocación del token NFC
Si se pierde el token, realice una vez con cada dispositivo asociado:
(No se requiere el token Hoverkey)
• Limpiar la clave de autenticación de la aplicación Hoverkey
• Borrar todas las contraseñas cifradas
• Restablecer la aplicación Hoverkey al estado preactivado
La aplicación Hoverkey también descarga una lista de ID de token revocados periódicamente, lo que le permite revocar el token si una entrada coincide con la que está emparejada.
6.9 Listar dispositivos
• Puede ser llevado a cabo
■ por cualquier dispositivo emparejado
■ autenticación mutua, Applet valida DeviceID o autenticación mutua con la clave de administración
■ o después de la autenticación mutua con la clave de administración
• No se requiere PIN
• Applet devuelve la lista de ID de dispositivo asociados
6.10 Revocación de un dispositivo
Por lo general, se lleva a cabo después de la lista de dispositivos, ya que no se espera que la aplicación Hoverkey recuerde la lista de ID de dispositivo.
• Puede realizarse desde cualquier dispositivo emparejado
• Autenticación mutua, Applet valida DeviceID
• Requiere PIN
• Elimina DeviceID del applet
6.11 Bloqueo de PIN
• Dentro del Applet, el PIN de usuario tiene un valor de PIN intentos restantes (PTR) asociado, inicializado a un número específico.
• El Applet también tiene un número fijo (5) claves de desbloqueo personal (PUK) de 8 dígitos, etiquetadas PUK1, PUK2, etc., que se generan y cargan aleatoriamente al formatear. Se proporciona una copia de los PUK de cada token al administrador del sistema. El Applet mantiene un único valor de intentos de desbloqueo restantes (UTR), inicializado a un número específico.
• Cada vez que el PIN se valida con éxito, PTR se restablece a su valor inicial.
• Cada vez que se detecta un PIN incorrecto, el PTR se reduce en uno.
• Si PTR llega a cero, el PIN de usuario se bloquea. El Applet también vuelve al servicio que PUK el usuario debe usar para desbloquear el PIN e intenta permanecer para ese PUK.
• Para desbloquear y restablecer el PIN, el usuario debe solicitar su código PUK a SysAdmin como se indica en la IU bloqueada con PIN o recuperando el estado del Applet (ver la Sección 0). Si es la primera vez que el usuario desbloquea el PIN, solicitará el código PUK1; la segunda vez requerirá PUK2, etc., es decir, cada código PUK solo se puede usar una vez.
• Si los códigos PUK del usuario están agotados, tan pronto como PTR llegue a cero nuevamente, el Applet se bloqueará. Se debe reemplazar el token NFC.
• Cada vez que se ingresa incorrectamente un PUK, el UTR disminuye. Si UTR llega a cero, el Applet se bloquea. Se debe reemplazar el token NFC.
6.12 Obtener el estado de Applet
• Puede realizarse desde cualquier dispositivo
• Si no está autenticado
■ Applet devuelve TokenID, estado de Applet
• Si está autenticado (con clave de autenticación o clave de administrador)
■ Si está en estado formateado: devuelve TokenID, estado de Applet, contador restante de intentos de PIN = Máx, índice PUK actual, contador restante de intentos PUK actual (esto puede no ser el máximo, ya que el Applet puede haberse restablecido a formateado, lo que no restablece el estado del PUK, es decir, los PUK usados se siguen usando). El índice PUK actual es el índice del código PUK que el usuario debe solicitar si el PIN actual se bloquea.
■ Si está en estado activado: devuelve TokenID, estado de Applet, contador restante de intentos de PIN, índice PUK actual, contador restante de intentos de PUK = Máx.
■ Si está en estado de PIN bloqueado: devuelve TokenID, estado de Applet, contador restante de intentos de PIN = 0, índice PUK actual, contador restante de intentos de PUK
■ Si está en estado bloqueado: devuelve TokenID = 0, estado del Applet.
6.13 Funciones de administración
Todas las funciones de esta sección requieren autenticación mutua con la clave de administrador.
6.13.1 Reformatear token
Para volver a formatear el token (por ejemplo, para emitirlo a un nuevo usuario)
• Autenticación mutua con clave de administrador
• Enviar comando de reformateo a:
■ Eliminar el PIN de usuario existente (y restablecer el contador de reintentos)
■ Eliminar las claves de protección de contraseña existentes PEK ENC, PEK_MAC
■ Restablecer el Applet al estado FORMATTED
■ (No restablecer los PUK; los PUK usados permanecen en uso)
6.13.2 Restablecimiento de PIN
Para que el administrador del sistema restablezca el PIN,
• Autenticación mutua con clave de administrador
• Enviar comando de restablecimiento de PIN con el nuevo PIN del usuario
■ (no requiere PUK)
6.14 Acceso de emergencia
6.14.1 Token NFC perdido/defectuoso
Para el acceso en línea de emergencia, el usuario puede simplemente iniciar sesión manualmente con su contraseña. Si el usuario no conoce/recuerda su contraseña (debido al uso de una contraseña compleja, por ejemplo), la función de restablecimiento de contraseña de la aplicación se puede utilizar para establecer una nueva contraseña (y también cambiar la contraseña protegida de Hoverkey).
6.14.2 PIN olvidado/bloqueado
Si la política de una aplicación requiere un PIN que el usuario no recuerda, podría:
• probar diferentes PIN hasta que se bloquee el PIN (si aún no lo ha hecho) y solicitar un PUK al administrador del sistema para desbloquear y restablecer el PIN.
• iniciar sesión manualmente si recuerda la ID de usuario y la contraseña (aunque tendrá que recuperar o restablecer el PIN eventualmente para continuar usando Hoverkey LI).
6.15 Sincronización de credenciales entre dispositivos
Condiciones previas:
• El usuario tiene dispositivos con IDs DeviceA y DeviceB respectivamente
• El token del usuario se ha activado y está listo para usar en ambos dispositivos
• El usuario ha registrado una aplicación con una ID AppX en DeviceA
• AppX no se ha registrado en DeviceB
Objetivo:
• Las credenciales de AppX para el usuario están disponibles para su uso en DeviceB
Pasos
1. En DeviceB, AppX se registra con Hoverkey Service utilizando el método de clave simétrica o asimétrica, pero sin proporcionar las credenciales del usuario.
2. El servicio recupera el archivo AppX/DeviceA/credentials.dat del almacenamiento en la nube.
3. El servicio carga el mismo archivo, sin alteraciones, que AppX/DeviceB/credentials.dat.
4. Las credenciales ya están listas para usarse en DeviceB.
7. Especificación criptográfica
7.1 Gestión de claves
Por motivos de seguridad, las claves utilizadas para cifrar y proteger la integridad de las contraseñas de usuario para el almacenamiento (generadas por el Applet en la activación) nunca abandonan el Applet (ni el token físico). Las claves de sesión también se utilizan (generadas por la aplicación Hoverkey) para cifrar y proteger la integridad de las contraseñas a través de NFC después del descifrado. Estos se limpian inmediatamente después de su uso.
7.2 Proceso de cifrado de almacenamiento de contraseña
La Figura 7 muestra el proceso de cifrado de contraseña.
Cifrado de contraseña para almacenamiento, para realizar por el Applet.
a) Combinar la política, la longitud de la contraseña y la contraseña recibida del dispositivo, aplicar relleno para alinear con la longitud del bloque de cifrado
2. Generar un vector de inicialización (IV) aleatorio de la longitud del bloque de cifrado de cifrado
3. Cifrar el bloque generado en el Paso 1 en modo CBC usando IV del Paso 2, usando la Clave PEK_ENC
4. Cifrar el IV con PEK_ENC en modo ECB
5. Calcular una MAC activada (salida del Paso 4 salida del Paso 3) utilizando una MAC basada en hash (HMAC) con la clave PEK_MAC
6. (Salida del paso 5 salida del paso 3 MAC del paso 4) se devuelve al dispositivo para su almacenamiento 7.3 Proceso de cifrado de recuperación de contraseña (sesión)
La Figura 8 muestra el cifrado de recuperación de contraseña.
Para ser realizado por Applet, después de la verificación del MAC, el descifrado del objeto cifrado proporcionado por el dispositivo y la validación del campo de política.
1. La contraseña de texto plano se rellena a la izquierda con un campo de longitud de dos bytes y a la derecha se rellena con bytes aleatorios para hacer el bloque más grande permitido (se ajusta a una R-APDU) cuyo tamaño es un múltiplo de la longitud del bloque de cifrado.
2. Pasos 2 a 5 según el Proceso de cifrado de almacenamiento de contraseñas, excepto que Session_PEK_ENC y Session_PEK_MAC se utilizan para el cifrado y la protección de la integridad.
7.4 Jerarquía de derivación de claves de registro de aplicaciones (clave simétrica)
La Figura 9 muestra la jerarquía de claves. Las claves se derivan utilizando el KDF basado en HMAC como se describe en la Publicación especial 800-108 del NIST, [: L. Chen, Recommendation for Key Derivation Using Pseudorandom Functions (Revised), NIST SP 800-108, October 2009, disponible en http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf. Este documento se incorpora como referencia. Claves de emisor
IssuerMasterKey = bytes aleatorios generados por claves de organización seguras de RNG
OrgID = OrgID único asignado
AppID = (globalmente) identificador de aplicación único
8. Estado del Applet de Hoverkey
La Figura 10 ilustra los estados del Applet y su secuencia.
Figure imgf000019_0001
continuación
Figure imgf000020_0001
9. Glosario
Figure imgf000020_0002
continuación
Figure imgf000021_0001

Claims (15)

REIVINDICACIONES
1. Un método de autenticación de un usuario para acceder a un recurso informático a través de un dispositivo móvil que comprende:
almacenar una autorización de recursos cifrada;
transmitir la autorización de recursos cifrados a al menos un dispositivo de token de seguridad portátil separado; en el al menos un dispositivo de token de seguridad portátil separado, descifrar la autorización de recursos cifrada y generar al menos parcialmente a partir de ella una respuesta de desbloqueo;
transmitir en forma segura la respuesta de desbloqueo generada al dispositivo móvil; y
proporcionar acceso a través del dispositivo móvil al recurso informático si la respuesta de desbloqueo requerida es válida; en el que se requiere que un usuario se autentique en el dispositivo móvil o en al menos un dispositivo de token de seguridad portátil separado, y la autenticación de usuario se valida en el al menos un dispositivo de token de seguridad portátil separado antes de que se envíe la respuesta de desbloqueo.
2. Un método de acuerdo con la reivindicación 1, en el que la respuesta de desbloqueo comprende una autorización simple, obtenida descifrando la autorización de recursos cifrada.
3. Un método de acuerdo con la reivindicación 1, en el que la respuesta de desbloqueo comprende una función de una autorización simple, obtenida al descifrar la autorización de recursos cifrada, e información adicional.
4. Un método de acuerdo con cualquiera de las reivindicaciones anteriores, en el que la respuesta de desbloqueo se transmite al dispositivo móvil bajo la protección de una clave de cifrado, como una clave de sesión.
5. Un método de acuerdo con cualquiera de las reivindicaciones anteriores, en el que el al menos un token de seguridad portátil separado almacena las credenciales de usuario, en donde el descifrado en el al menos un dispositivo de token de seguridad portátil separado se basa en las credenciales del usuario, en el cual, opcionalmente, las credenciales de usuario son generadas por el al menos un dispositivo de token de seguridad portátil separado y nunca dejan el al menos un dispositivo de token de seguridad portátil separado.
6. Un método de acuerdo con la reivindicación 5, en el que la autorización de recursos cifrados se puede descifrar únicamente con las correspondientes credenciales de usuario almacenadas en al menos un dispositivo de token de seguridad portátil separado.
7. Un método de acuerdo con cualquiera de las reivindicaciones anteriores, en el que el dispositivo móvil y el al menos un dispositivo de token de seguridad portátil separado realizan una autenticación mutua criptográfica antes de la transmisión de la autorización de recursos cifrados.
8. Un método de acuerdo con cualquiera de las reivindicaciones anteriores, en el que la autenticación del usuario en el dispositivo móvil es a través de información biométrica, por ejemplo, una huella dactilar y/o un patrón de iris.
9. Un sistema para autenticar a un usuario para que acceda a un recurso informático a través de un dispositivo móvil, que comprende un dispositivo móvil y al menos un dispositivo de token de seguridad portátil separado, que comprende medios para llevar a cabo el método de acuerdo con la reivindicación 1.
10. Un sistema de acuerdo con la reivindicación 9, en el que el al menos un dispositivo de token de seguridad portátil separado está configurado para transmitir la respuesta de desbloqueo al dispositivo móvil bajo la protección de una clave de cifrado, como una clave de sesión.
11. Un sistema de acuerdo con las reivindicaciones 9 o 10, en el que la autenticación del usuario se realiza mediante información biométrica, por ejemplo, una huella dactilar y/o un patrón de iris.
12. Un sistema de acuerdo con cualquiera de las reivindicaciones 9 a 11, en el que al menos un dispositivo de token de seguridad portátil separado está configurado para verificar la integridad de la autorización de recursos cifrados antes del descifrado.
13. Un sistema de acuerdo con cualquiera de las reivindicaciones 9 a 12, en el que el dispositivo móvil y el al menos un dispositivo de token de seguridad portátil separado están configurados para realizar una autenticación mutua criptográfica antes de la transmisión de la autorización de recursos cifrados.
14. Un sistema de acuerdo con cualquiera de las reivindicaciones 9 a 13, en el que el al menos un dispositivo de token de seguridad portátil separado está configurado para enviar la respuesta de desbloqueo solo con la confirmación positiva del usuario, por ejemplo, presionando un botón en el token.
15. Un sistema de acuerdo con una cualquiera de las reivindicaciones 9 a 14, en el que el al menos un dispositivo de token de seguridad portátil separado es proporcionado por cualquiera de un llavero, una insignia, una tarjeta inteligente NFC, un reloj, un anillo portátil, una pulsera de fitness, un auricular inalámbrico, una joya o un dispositivo informático móvil.
ES13801699T 2012-11-28 2013-11-27 Un método y sistema para proporcionar autenticación del acceso del usuario a un recurso informático a través de un dispositivo móvil utilizando múltiples factores de seguridad separados Active ES2819200T3 (es)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GBGB1221433.4A GB201221433D0 (en) 2012-11-28 2012-11-28 A method and system of providing authentication of user access to a computer resource on a mobile device
US13/706,307 US9135425B2 (en) 2012-11-28 2012-12-05 Method and system of providing authentication of user access to a computer resource on a mobile device
GB1303677.7A GB2496354B (en) 2012-11-28 2013-03-01 A method and system of providing authentication of user access to a computer resource via a mobile device using multiple separate security factors
PCT/GB2013/053138 WO2014083335A2 (en) 2012-11-28 2013-11-27 A method and system of providing authentication of user access to a computer resource via a mobile device using multiple separate security factors

Publications (1)

Publication Number Publication Date
ES2819200T3 true ES2819200T3 (es) 2021-04-15

Family

ID=47560842

Family Applications (1)

Application Number Title Priority Date Filing Date
ES13801699T Active ES2819200T3 (es) 2012-11-28 2013-11-27 Un método y sistema para proporcionar autenticación del acceso del usuario a un recurso informático a través de un dispositivo móvil utilizando múltiples factores de seguridad separados

Country Status (6)

Country Link
US (1) US9135425B2 (es)
EP (1) EP2926290B1 (es)
CN (1) CN105210073A (es)
ES (1) ES2819200T3 (es)
GB (2) GB201221433D0 (es)
WO (1) WO2014083335A2 (es)

Families Citing this family (65)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10181055B2 (en) 2007-09-27 2019-01-15 Clevx, Llc Data security system with encryption
US10102510B2 (en) 2012-11-28 2018-10-16 Hoverkey Ltd. Method and system of conducting a cryptocurrency payment via a mobile device using a contactless token to store and protect a user's secret key
US20140149742A1 (en) 2012-11-28 2014-05-29 Arnold Yau Method and system of providing authentication of user access to a computer resource via a mobile device using multiple separate security factors
CN105264487B (zh) * 2013-03-15 2018-09-07 美国邮政管理局 身份验证系统和方法
EP2804153B1 (en) * 2013-05-15 2018-11-21 Nxp B.V. Electronic lock, locking system and method of operating an electronic lock
AU2014292980A1 (en) 2013-07-24 2016-02-04 Visa International Service Association Systems and methods for interoperable network token processing
US20150039908A1 (en) * 2013-07-30 2015-02-05 Deutsche Telekom Ag System and Method for Securing A Credential Vault On A Trusted Computing Base
DE102014002378A1 (de) * 2013-08-07 2015-02-12 Ssp Europe Gmbh Speicherkommunikationssystem
EP2835756A1 (de) * 2013-08-07 2015-02-11 SSP Europe GmbH Speicherkommunikationssystem
US9264421B2 (en) * 2013-08-22 2016-02-16 Google Technology Holdings LLC Accessing a primary device using a wearable device and a wireless link
EP3078156A4 (en) 2013-10-11 2017-07-12 Visa International Service Association Network token system
US9639710B2 (en) 2013-12-23 2017-05-02 Symantec Corporation Device-based PIN authentication process to protect encrypted data
US9668140B2 (en) * 2013-12-30 2017-05-30 Cellco Partnership Devaluation of lost and stolen devices
US9483249B2 (en) * 2014-01-06 2016-11-01 Apple Inc. On-board applet migration
US9436455B2 (en) 2014-01-06 2016-09-06 Apple Inc. Logging operating system updates of a secure element of an electronic device
US11023890B2 (en) 2014-06-05 2021-06-01 Visa International Service Association Identification and verification for provisioning mobile application
FR3022053B1 (fr) * 2014-06-06 2018-02-02 Oberthur Technologies Procede d'authentification d'une premiere entite electronique par une seconde entite electronique et entite electronique mettant en œuvre un tel procede
US9934014B2 (en) 2014-08-22 2018-04-03 Apple Inc. Automatic purposed-application creation
CN104200176A (zh) * 2014-08-28 2014-12-10 电子科技大学 对智能移动终端中文件进行透明加解密的系统及方法
GB2529812A (en) * 2014-08-28 2016-03-09 Kopper Mountain Ltd Method and system for mobile data and communications security
US20160065374A1 (en) * 2014-09-02 2016-03-03 Apple Inc. Method of using one device to unlock another device
US10255422B1 (en) * 2014-09-15 2019-04-09 Apple Inc. Identity proxy for access control systems
DE102014219297A1 (de) * 2014-09-24 2016-03-24 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Authentisierungs-Stick
US9838274B2 (en) * 2014-11-19 2017-12-05 International Business Machines Corporation Method for enhancing security access to a node in a homogenous cloud computing environment
CN104468581B (zh) * 2014-12-10 2018-03-02 小米科技有限责任公司 登录应用程序的方法及装置
KR20160076371A (ko) 2014-12-22 2016-06-30 삼성전자주식회사 워크플로우를 처리하는 방법 및 이를 수행하는 모바일 디바이스
CN107111718B (zh) * 2014-12-22 2021-01-29 惠普发展公司，有限责任合伙企业 在移动设备与成像装置之间建立连接的方法、成像装置和移动设备
WO2016105044A1 (en) * 2014-12-22 2016-06-30 Samsung Electronics Co., Ltd. Method of establishing connection between mobile device and image forming apparatus, and image forming apparatus and mobile device for performing the method
EP3037954B1 (en) 2014-12-22 2019-02-20 HP Printing Korea Co., Ltd. Method of generating workform by using byod service and mobile device for performing the method
US9619636B2 (en) 2015-02-06 2017-04-11 Qualcomm Incorporated Apparatuses and methods for secure display on secondary display device
US9508071B2 (en) * 2015-03-03 2016-11-29 Mastercard International Incorporated User authentication method and device for credentials back-up service to mobile devices
US9674705B2 (en) * 2015-04-22 2017-06-06 Kenneth Hugh Rose Method and system for secure peer-to-peer mobile communications
NL2014742B1 (en) 2015-04-30 2017-01-18 Ubiqu B V A method, a computer program product and a qKey server.
CN105574425B (zh) * 2015-04-30 2018-06-15 宇龙计算机通信科技(深圳)有限公司 访问存储数据的方法及装置
US9967244B2 (en) 2015-10-14 2018-05-08 Microsoft Technology Licensing, Llc Multi-factor user authentication framework using asymmetric key
WO2017085545A1 (en) 2015-11-17 2017-05-26 Idee Limited Security systems and methods with identity management for access to restricted access locations
US9851806B2 (en) 2015-11-24 2017-12-26 International Business Machines Corporation Gesture recognition and control based on finger differentiation
US10122719B1 (en) 2015-12-31 2018-11-06 Wells Fargo Bank, N.A. Wearable device-based user authentication
WO2017123433A1 (en) * 2016-01-04 2017-07-20 Clevx, Llc Data security system with encryption
US20170200095A1 (en) * 2016-01-07 2017-07-13 International Business Machines Corporation Smart rerouting infrastructure for travelers
US10102524B2 (en) 2016-06-03 2018-10-16 U.S. Bancorp, National Association Access control and mobile security app
CN106452485B (zh) * 2016-07-13 2018-07-17 杭州致峰网络科技有限公司 智能穿戴设备的控制系统
DE102017000768A1 (de) * 2017-01-27 2018-08-02 Giesecke+Devrient Mobile Security Gmbh Verfahren zum Durchführen einer Zweifaktorauthentifizierung
FR3063365B1 (fr) * 2017-02-27 2019-04-05 Jacques GASCUEL Systeme d'authentification a cle segmentee
CN108881104A (zh) * 2017-05-08 2018-11-23 中国移动通信有限公司研究院 一种对应用程序进行验证的方法和设备
CN107294728B (zh) * 2017-06-19 2022-05-20 宁夏海纳仁东科技有限公司 一种用于密码解锁的智能手链
US10693644B2 (en) 2017-06-23 2020-06-23 International Business Machines Corporation Single-input multifactor authentication
GB2566107B (en) * 2017-09-05 2019-11-27 Istorage Ltd Methods and systems of securely transferring data
US10601592B2 (en) * 2017-09-08 2020-03-24 Kenneth Hugh Rose System and method trusted workspace in commercial mobile devices
US10387689B2 (en) * 2017-09-22 2019-08-20 Tocreo Labs, L.L.C. NFC cryptographic security module
US11868995B2 (en) * 2017-11-27 2024-01-09 Nok Nok Labs, Inc. Extending a secure key storage for transaction confirmation and cryptocurrency
EP3732599A4 (en) 2017-12-29 2021-09-01 Idee Limited SINGLE SIGN-ON (SSO) USING CONTINUOUS AUTHENTICATION
US11569998B2 (en) 2018-01-25 2023-01-31 Visa International Service Association Token offline provisioning
CN108512660B (zh) * 2018-03-28 2021-03-16 湖南东方华龙信息科技有限公司 虚拟卡的验证方法
US11184173B2 (en) 2018-08-24 2021-11-23 Powch, LLC Secure distributed information system
EP3661148B1 (en) 2018-11-28 2023-05-24 Nxp B.V. Location- and identity-referenced authentication method and communication system
US11533598B2 (en) * 2018-12-18 2022-12-20 Fisher Controls International, Llc Methods and apparatus to establish secure low energy wireless communications in a process control system
JP7273523B2 (ja) * 2019-01-25 2023-05-15 株式会社東芝 通信制御装置および通信制御システム
CN110059473A (zh) * 2019-03-21 2019-07-26 深圳壹账通智能科技有限公司 应用账户登录方法、装置、计算机设备及计算机存储介质
DE102019108049A1 (de) * 2019-03-28 2020-10-01 Pilz Gmbh & Co. Kg Zugriffssteuerungssystem zur Steuerung eines Zugriffs eines Nutzers auf eine oder mehrere Betriebsfunktionen einer technischen Anlage
US11159674B2 (en) 2019-06-06 2021-10-26 International Business Machines Corporation Multi-factor authentication of caller identification (ID) identifiers
US11153088B2 (en) * 2019-09-07 2021-10-19 Paypal, Inc. System and method for implementing a two-sided token for open authentication
US11556665B2 (en) * 2019-12-08 2023-01-17 Western Digital Technologies, Inc. Unlocking a data storage device
CN116527246A (zh) * 2021-11-19 2023-08-01 荣耀终端有限公司 数据保护方法及电子设备
CN115037452B (zh) * 2021-11-19 2023-09-12 荣耀终端有限公司 数据保护方法、系统及电子设备

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7353281B2 (en) * 2001-08-06 2008-04-01 Micron Technology, Inc. Method and system for providing access to computer resources
US7533264B2 (en) 2003-08-20 2009-05-12 Microsoft Corporation Custom security tokens
GB2423396A (en) * 2005-02-17 2006-08-23 Associated Network Solutions P Use of a token to retrieve user authentication information
EP1752937A1 (en) * 2005-07-29 2007-02-14 Research In Motion Limited System and method for encrypted smart card PIN entry
US8245292B2 (en) * 2005-11-16 2012-08-14 Broadcom Corporation Multi-factor authentication using a smartcard
US20070150736A1 (en) * 2005-12-22 2007-06-28 Cukier Johnas I Token-enabled authentication for securing mobile devices
US8079068B2 (en) * 2006-07-17 2011-12-13 Research In Motion Limited Management of multiple connections to a security token access device
US8639940B2 (en) * 2007-02-28 2014-01-28 Red Hat, Inc. Methods and systems for assigning roles on a token
US8646056B2 (en) 2007-05-17 2014-02-04 U.S. Cellular Corporation User-friendly multifactor mobile authentication
US8539233B2 (en) 2007-05-24 2013-09-17 Microsoft Corporation Binding content licenses to portable storage devices
US8528109B2 (en) 2007-10-09 2013-09-03 Microsoft Corporation Optimizing amount of data passed during software license activation
US10706402B2 (en) * 2008-09-22 2020-07-07 Visa International Service Association Over the air update of payment transaction data stored in secure memory
EP2182493A1 (en) * 2008-11-04 2010-05-05 Gemalto SA Remote user authentication using NFC
US20100332401A1 (en) 2009-06-30 2010-12-30 Anand Prahlad Performing data storage operations with a cloud storage environment, including automatically selecting among multiple cloud storage sites
WO2011050309A2 (en) * 2009-10-23 2011-04-28 Appsware Wireless, Llc System and device for consolidating sim, personal token, and associated applications
US20110246317A1 (en) * 2009-10-23 2011-10-06 Apriva, Llc System and device for facilitating a transaction through use of a proxy account code
US20110142234A1 (en) 2009-12-15 2011-06-16 Michael Leonard Rogers Multi-Factor Authentication Using a Mobile Phone
GB2476989A (en) 2010-01-19 2011-07-20 Proxama Ltd Activation of secure function in mobile computing device using authentication tag
CN102299797A (zh) 2010-06-23 2011-12-28 财团法人工业技术研究院 认证方法、密钥分配方法及认证与密钥分配方法
US20130214902A1 (en) * 2010-12-02 2013-08-22 Viscount Systems Inc. Systems and methods for networks using token based location
US20120297461A1 (en) * 2010-12-02 2012-11-22 Stephen Pineau System and method for reducing cyber crime in industrial control systems
AU2011200445B8 (en) 2011-02-03 2013-03-07 Idondemand Pty Ltd Method and apparatus for dynamic authentication

Also Published As

Publication number Publication date
GB201221433D0 (en) 2013-01-09
WO2014083335A3 (en) 2015-06-18
WO2014083335A4 (en) 2015-07-23
EP2926290B1 (en) 2020-06-17
GB2496354A (en) 2013-05-08
EP2926290A2 (en) 2015-10-07
CN105210073A (zh) 2015-12-30
WO2014083335A2 (en) 2014-06-05
GB201303677D0 (en) 2013-04-17
US20140149746A1 (en) 2014-05-29
GB2496354B (en) 2013-10-30
US9135425B2 (en) 2015-09-15

Similar Documents

Publication Publication Date Title
ES2819200T3 (es) Un método y sistema para proporcionar autenticación del acceso del usuario a un recurso informático a través de un dispositivo móvil utilizando múltiples factores de seguridad separados
US9210133B2 (en) Method and system of providing authentication of user access to a computer resource via a mobile device using multiple separate security factors
US20160005032A1 (en) Method and system of providing authentication of user access to a computer resource via a mobile device using multiple separate security factors
US10102510B2 (en) Method and system of conducting a cryptocurrency payment via a mobile device using a contactless token to store and protect a user's secret key
US10327142B2 (en) Secure short message service (SMS) communications
JP6818679B2 (ja) セキュアホストカードエミュレーションクレデンシャル
KR102308846B1 (ko) 복수의 장치로부터 데이터에 액세스하기 위한 시스템
US20160379220A1 (en) Multi-Instance Shared Authentication (MISA) Method and System Prior to Data Access
US9448949B2 (en) Mobile data vault
US20140365781A1 (en) Receiving a Delegated Token, Issuing a Delegated Token, Authenticating a Delegated User, and Issuing a User-Specific Token for a Resource
CN111034120B (zh) 基于身份信息的加密密钥管理
JP2009510644A (ja) 安全な認証のための方法及び構成
US20170026385A1 (en) Method and system for proximity-based access control
JP6476167B2 (ja) 自己認証デバイス及び自己認証方法
WO2013123453A1 (en) Data storage devices, systems, and methods
WO2017050152A1 (zh) 用于移动设备的密码安全系统及其密码安全输入方法
CN104821878A (zh) 用于确保数据交换的安全性的便携式安全设备、方法和计算机程序产品
Armando et al. Trusted host-based card emulation
JP2014135558A (ja) 情報移譲システム、情報移譲方法、情報移譲プログラム
KR101296402B1 (ko) 암호화된 시드를 이용한 모바일 오티피 장치의 등록 방법
KR101678789B1 (ko) 사용자 단말기 및 그것을 이용한 암호화된 데이터 공유 방법
KR101657932B1 (ko) 자체확장인증을 이용한 키관리 및 사용자 인증방법
Petrov et al. Wireless authentication using OPACITY protocol
KR20150090558A (ko) 인증서 제어시스템 및 그 방법
JP2015046080A (ja) 閲覧制御システム