ES2887258T3 - Procedimiento para realizar una autenticación de dos factores - Google Patents

Procedimiento para realizar una autenticación de dos factores Download PDF

Info

Publication number
ES2887258T3
ES2887258T3 ES18705313T ES18705313T ES2887258T3 ES 2887258 T3 ES2887258 T3 ES 2887258T3 ES 18705313 T ES18705313 T ES 18705313T ES 18705313 T ES18705313 T ES 18705313T ES 2887258 T3 ES2887258 T3 ES 2887258T3
Authority
ES
Spain
Prior art keywords
data
client
authentication
server
data carrier
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
ES18705313T
Other languages
English (en)
Inventor
Volker Stöhr
Frank-Michael Kamm
Nils Gerhardt
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.)
Giesecke and Devrient Mobile Security GmbH
Original Assignee
Giesecke and Devrient Mobile Security GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient Mobile Security GmbH filed Critical Giesecke and Devrient Mobile Security GmbH
Application granted granted Critical
Publication of ES2887258T3 publication Critical patent/ES2887258T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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/321—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 involving a third party or a trusted authority
    • H04L9/3213—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 involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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
    • 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/3234—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 involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • 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/3271—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 challenge-response
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Procedimiento para realizar una autenticación de dos factores entre un cliente y una parte de confianza, que comprende los siguientes pasos: - realización (1) de una autenticación entre el cliente y la parte de confianza; - transmisión (2) de datos adicionales de autenticación de la parte de confianza al cliente; - solicitación (4) de un desafío de servidor por parte del cliente de un servidor token; - transmisión (5) del desafío del servidor del servidor token al cliente; - realización (6) de un intercambio de datos entre el cliente y un soporte de datos, en el que el cliente recibe datos de autenticación de soporte de datos del soporte de datos, en el que los datos de autenticación de soporte de datos se calculan al menos parcialmente utilizando datos del desafío de servidor, - transmisión (7) de datos de autenticación del cliente al servidor token, en el que los datos de autenticación comprenden los datos del intercambio de datos entre el cliente y el soporte de datos, los datos de autenticación de soporte de datos, así como los datos adicionales de autenticación; - verificación (8) de los datos de autenticación por parte del servidor token, por lo que se proporciona la prueba de que el soporte de datos estuvo presente físicamente en el intercambio de datos entre el cliente y el soporte de datos; - generación (10) de una respuesta de autenticación en el servidor token; - transmisión (11) de la respuesta de autenticación del servidor token al cliente; y - transmisión (12) de la respuesta de autenticación del cliente a la parte de confianza y verificación (13) de la respuesta de autenticación por la parte de confianza.

Description

DESCRIPCIÓN
Procedimiento para realizar una autenticación de dos factores
Campo técnico
La presente invención se refiere a un procedimiento para realizar una autenticación de dos factores entre un cliente y una parte de confianza.
Un cliente es, por ejemplo, un teléfono móvil, una tableta PC, un ordenador (PC) o similares. Una parte de confianza es, por ejemplo, un dispositivo como un host, un servidor o similares, que posibilita el acceso a un servicio, en particular una aplicación de software segura.
Se usa el U2F (Universal Second Factor, segundo factor universal) estándar de la industria para la autenticación de dos factores. La especificación U2F se gestiona por la alianza FIDO (Fast IDentity Online).
Estado de la técnica
La autenticación de dos factores se inicia por lo general en tanto que un proveedor de servicios (parte de confianza) solicita el nombre de usuario y opcionalmente la contraseña asociada como primer factor para la autenticación, en la que el nombre de usuario identifica al usuario y la contraseña autentica al usuario. El proveedor de servicios examina estos datos y, si los datos son correctos, inicia la verificación del segundo factor (propiedad) en forma de U2F.
En un primer paso, el proveedor de servicios (parte de confianza) envía un paquete de datos al ordenador del cliente, como por ejemplo un navegador web. Esto comprende un desafío, que son algunos datos seleccionados al azar, un identificador de aplicación (AppID) y un identificador de clave (KeyHandle), que se ha depositado durante el registro inicial.
El ordenador del cliente examina el identificador de aplicación, la complementa con datos adicionales, como por ejemplo un identificador de canal (Channel ID) y reenvía estos datos hash al equipo U2F. El equipo U2F puede ser, por ejemplo, un dongle USB con un botón.
El equipo U2F determina con la ayuda del identificador de clave (KeyHandle) la clave privada apropiada (kpriv) para esta sesión, y con esta firma los valores hash del identificador de aplicación y el desafío y forma así la respuesta de retorno firmada.
Adicionalmente, se integra un contador (Counter) en la respuesta para poder identificar equipos U2F duplicados. El ordenador del cliente, como por ejemplo el navegador web, reenvía estos datos al proveedor del servicio, que con la clave pública examina las firmas y los datos contenidos en ella y, si son correctos, concede el acceso.
El desafío con FIDO-U2F es que está diseñado para usarse en un PC o similares, en el que también se puede usar un dongle USB como segundo factor en una interfaz USB. Es posible presentar el segundo factor a través de NFC o Bluetooth, no obstante, en este caso se requieren autenticadores especiales, que por lo general se deben adquirir específica y exclusivamente para uso para FIDO.
No obstante, existe el deseo de poder efectuar una autenticación de dos factores, que sea conforme a FIDO-U2F, también en otros dispositivos electrónicos, como un teléfono móvil. En este sentido, todavía es un deseo poder utilizar como segundo factor un soporte de datos ya presente en el usuario con una interfaz sin contacto, como por ejemplo una tarjeta de crédito, en conexión con un teléfono móvil para realizar una autenticación de dos factores de acuerdo con FIDO-U2F. FIDO-U2F requiere el uso de curvas elípticas para la firma. Las tarjetas de crédito y las tarjetas de pago no presentan en general esta función. De forma alternativa se debe permitir el uso de RSA para firmar de acuerdo con FIDO-UAF. A este respecto, adicionalmente a la firma RSA, FIDO también requiere adicionalmente la generación de pares de claves RSA. Esta generación de claves RSA tomaría demasiado tiempo de computación en la tarjeta, de modo que el tiempo de ejecución no sería aceptable para el usuario y no se implementa en las tarjetas de crédito actuales.
De forma alternativa, la nueva tarjeta de identificación de BRD (nPA) se podría usar como segundo factor y vincularse al teléfono móvil a través de un enlace de radio. Sin embargo, la funcionalidad eID actualmente solo está activada en el 30-35 % de las tarjetas de identificación situadas en el campo. Además, la funcionalidad eID requiere la entrada adicional de una contraseña de seis dígitos en cada uso, que se debe introducir mientras que el nPA se mantiene en la interfaz NFC del teléfono móvil.
Las publicaciones WO 2016/044373 A1 y US 2014/189360 A1 representan el estado de la técnica relevante.
Descripción de la invención
La invención tiene el objetivo de poner a disposición un procedimiento para realizar una autenticación de dos factores entre un cliente y una parte de confianza, que resuelva los problemas conocidos del estado de la técnica y que posibilite utilizar un dispositivo para la autenticación U2F que ya posee el usuario. El procedimiento debe estar conformado de tal manera que incluso las instalaciones que no fueron diseñadas especialmente para aplicaciones FIDO se puedan usar como segundo factor sin que sea necesario el consentimiento del emisor (Issuer) del segundo factor y/o sin que la parte de confianza pueda reconocer una diferencia respecto al procedimiento FIDO estandarizado.
Este objetivo se consigue con un procedimiento de acuerdo con la reivindicación independiente 1. Configuraciones preferentes del procedimiento se pueden encontrar en las reivindicaciones dependientes.
La invención se basa en la idea básica de utilizar un soporte de datos, en particular una tarjeta EMV, como segundo factor de forma (U2F), con lo que el soporte de datos está en conexión a un servidor token a través de un cliente, por ejemplo un teléfono móvil. Entonces, el servidor token puede asumir - sin el requisito de tener que mantener una base de datos de usuarios - otros servicios, como por ejemplo una derivación de claves con uso intensivo de recursos.
En consecuencia, la invención se refiere a un procedimiento para realizar una autenticación de dos factores entre un cliente y una parte de confianza, que comprende los siguientes pasos: realización de una autenticación entre el cliente y la parte de confianza, transmisión de datos adicionales de autenticación de la parte de confianza al cliente; solicitación de un desafío de servidor (desafío EMV) por parte del cliente de un servidor token; transmisión del desafío del servidor del servidor token al cliente; realización de un intercambio de datos entre el cliente y un soporte de datos, en el que el cliente recibe datos de autenticación de soporte de datos del soporte de datos, en el que los datos de autenticación de soporte de datos se calculan al menos parcialmente utilizando datos del desafío de servidor, transmisión de datos de autenticación del cliente al servidor token, en el que los datos de autenticación comprenden los datos del intercambio de datos entre el cliente y el soporte de datos, en particular los datos de autenticación de soporte de datos, así como los datos adicionales de autenticación; verificación de los datos de autenticación por parte del servidor token; generación de una respuesta de autenticación en el servidor token; transmisión de la respuesta de autenticación del servidor token al cliente; y transmisión de la respuesta de autenticación del cliente a la parte de confianza y verificación de la respuesta de autenticación por la parte de confianza.
Con el procedimiento de acuerdo con la invención, es posible de manera especialmente ventajosa realizar una autenticación de dos factores utilizando el soporte de datos del usuario, en el que el soporte de datos no debe estar adaptado especialmente al uso en el procedimiento de autenticación de dos factores. Además, no es necesario realizar una verificación de PIN frente al soporte de datos, en particular, el soporte de datos EMV. Además, se puede utilizar ventajosamente un servidor token sencillo en el procedimiento, el cual se las arregla sin una base de datos de usuarios en la que están almacenados los datos de cada usuario. En consecuencia, se pueden ahorrar costes tanto en la selección del soporte de datos como también en la selección del servidor token. En particular, el aspecto de la simple selección del soporte de datos a usar en el procedimiento reduce el obstáculo de entrada para el usuario, ya que este simplemente puede usar uno de sus soportes de datos ya presentes en el procedimiento. Contrariamente a la designación habitual, la parte de confianza también se puede utilizar como instancia de confirmación frente a una instalación de servicio, como por ejemplo una tienda web, un servicio de correo electrónico, etc. La parte de confianza actúa entonces como un servicio de autenticación, también designado como autenticación como un servicio (AaaS), con lo que el servicio de autenticación asume de la autenticación (de dos factores) para la instalación de servicio.
De acuerdo con la invención, el cliente es un dispositivo como un teléfono móvil, una tableta PC, un PC o similares. La parte de confianza es un dispositivo como un host, un servidor o similares, que posibilita el acceso a un servicio, en particular una aplicación de software segura. Un ejemplo de una parte de confianza es un servicio web al que el usuario quisiera tener acceso, en particular una tienda web, un acceso bancario, una aplicación de correo electrónico o similar. Durante la autenticación entre el cliente y la parte de confianza se solicita, por ejemplo, un nombre de usuario y una contraseña.
Los datos de autenticación de soporte de datos son, por ejemplo, certificados que el cliente recibe del soporte de datos, por ejemplo, un certificado de emisor (Issuer) y/o un certificado específico del soporte de datos, así como datos que se determinan mediante un intercambio de datos entre cliente y soporte de datos utilizando datos del desafío del servidor. Por tanto, se puede asegurar que los datos de autenticación de soporte de datos también tienen en cuenta los contenidos del desafío del servidor. Los datos de autenticación de soporte de datos pueden comprender datos adicionales.
Los datos de autenticación que se transmiten del cliente al servidor token comprenden ventajosamente tanto datos del intercambio de datos entre el cliente y el soporte de datos, así incluso los datos de autenticación de soporte de datos, así como datos adicionales de autenticación de la autenticación entre el cliente y la parte de confianza. De este modo se asegura que el soporte de datos estuvo realmente presente durante el intercambio de datos entre el cliente y el soporte de datos en la recepción del desafío del servidor. La incorporación repetida de los datos de autenticación de soporte de datos en los datos de autenticación se nota inmediatamente, ya que los datos de autenticación de soporte de datos siempre se calculan dependiendo del desafío del servidor, con lo que el desafío del servidor se cambia con cada llamada. Por tanto, ventajosamente es posible evitar ataques de reproducción, ya que el servidor token recuerda el desafío del servidor generado al azar y lo usa para verificar los datos del soporte de datos.
De acuerdo con un modo de realización, al realizar la autenticación entre el cliente y la parte de confianza se transmite un KeyHandle, en particular una UserPrivateKey protegida contra el acceso no autorizado, en particular una UserPrivateKey encriptada, un desafío, en particular un desafío FIDO, y/o un AppID, en particular, un FIDO-AppID. En base a estos datos es posible calcular ventajosamente la respuesta de autenticación. De este modo se asegura que la respuesta de autenticación se calcule individualmente para cada autenticación de dos factores.
Además, la invención puede comprender el examen del AppID, con cuyo dispositivo se puede probar un segundo factor en la autenticación. Por tanto, ventajosamente se le informa al cliente de que, por ejemplo, se puede utilizar un soporte de datos como segundo factor (U2F). De esta manera se simplifica el proceso para el usuario.
De acuerdo con un modo de realización especialmente preferente, no se requiere ninguna entrada de PIN frente al soporte de datos para realizar el procedimiento, en particular para realizar el intercambio de datos. En su lugar, el soporte de datos (U2F) se puede autenticar frente al servidor token y el servidor token se puede autenticar, preferentemente, frente a la parte de confianza por medio de métodos criptográficos. No se requiere la verificación del PIN del soporte de datos frente al servidor token, no obstante, se puede prever de forma opcional. Si un documento de identificación, en particular la tarjeta de identidad alemana (nPA), se utiliza como soporte de datos, entonces siempre es necesaria una verificación del PIN frente al soporte de datos y también frente a la parte de confianza, es decir, una doble verificación del PIN, que eventualmente se puede percibir como molesta. Con las tarjetas EMV, la verificación del PIN no es absolutamente necesaria.
De acuerdo con otro modo de realización especialmente preferente de la invención, el desafío del servidor presenta, entre otras cosas, un número aleatorio. El número aleatorio puede estar conformado, por ejemplo, como un número de 4 bytes de longitud. Mediante el envío del número aleatorio al cliente, posteriormente es posible incluir el número aleatorio en los datos de autenticación de soporte de datos, por ejemplo, en forma de una firma. De este modo, el servidor token puede comprobar ventajosamente si el soporte de datos se "muestra" realmente al cliente.
Además, de acuerdo con un modo de realización preferente, para realizar el intercambio de datos entre el cliente y el soporte de datos se puede establecer una conexión sin contacto y/o con contacto entre el cliente y el soporte de datos. En consecuencia, es posible conectar el soporte de datos al cliente a través de una interfaz aérea. Para ello, se puede establecer preferentemente una conexión NFC entre el soporte de datos y el cliente, en tanto que el soporte de datos se mantiene, por ejemplo, contra una interfaz NFC del cliente (teléfono móvil/tableta PC). De forma alternativa, el soporte de datos se puede insertar con contacto en un lector de tarjetas del cliente (PC).
De acuerdo con otro aspecto de la invención, la verificación de los datos de autenticación por parte del servidor token puede proporcionar la prueba de que el soporte de datos estuvo presente físicamente durante el intercambio de datos entre el cliente y el soporte de datos. Los datos de autenticación se calculan teniendo en cuenta los datos de autenticación de soporte de datos. Los datos del desafío del servidor se incluyen en los datos de autenticación de soporte de datos. En consecuencia, la verificación de los datos de autenticación puede proporcionar ventajosamente la prueba de que el soporte de datos, es decir, el segundo factor (U2F), estuvo presente físicamente durante el intercambio de datos entre el cliente y el soporte de datos. De este modo se satisface un requisito esencial para la autenticación de dos factores.
De acuerdo con otro modo de realización, durante la verificación de los datos de autenticación por parte del servidor token, el servidor token puede desencriptar una clave de cliente a partir de los datos de autenticación en el caso de verificación exitosa, con lo que la clave de cliente se utiliza en la generación de la respuesta de autenticación. Una clave maestra del servidor token, que está almacenada de forma segura en el servidor token, así como los datos que proceden exclusivamente del soporte de datos, de la parte de confianza y del cliente, entran ventajosamente en la clave del cliente. Ventajosamente, la clave de cliente es una denominada clave de envoltura ENC/MAC y/o el KeyHandle, en el que entra la FIDO PrivKey encriptada. Por tanto, el servidor token se puede proporcionar ventajosamente de forma económica, ya que no se deben almacenar datos de usuario en el servidor token. Solo la clave maestra del servidor token se debe almacenar de forma segura en el servidor token, preferentemente en un módulo de seguridad de hardware HSM (Hardware Security Module).
De acuerdo con la invención está previsto un cliente que es adecuado para el uso en un procedimiento de acuerdo con las afirmaciones arriba mencionadas, en el que el cliente es un terminal móvil, una tableta PC y/o un PC. De acuerdo con estas configuraciones, es posible de manera especialmente ventajosa ejecutar un procedimiento de acuerdo con la invención.
Además, el procedimiento de acuerdo con la invención se puede ejecutar de manera especialmente ventajosa con un sistema que está concebido para el uso en un procedimiento de acuerdo con las afirmaciones arriba mencionadas.
De acuerdo con otro modo de realización, la autenticación del usuario no se realiza directamente entre el servidor token y la parte de confianza, sino a través de un servicio de autenticación conectado en el medio ("Servicio de Federación de Identidad"). En este caso, la parte de confianza solicita la autenticación del usuario en el servicio de autenticación a través de un protocolo de federación habitual en la industria (por ejemplo, OpenID Connect o SAML).
El servicio de autenticación solicitará entonces la autenticación del usuario con la ayuda del cliente, del servidor token y del soporte de datos. El proceso de autenticación se desarrolla como se describió anteriormente, no obstante, frente al servicio de autenticación y no frente a la parte de confianza. Después de una autenticación exitosa, el servicio de autenticación da fe de la autenticación frente a la parte de confianza, eventualmente complementa con otros datos de identidad o certificaciones específicas del usuario, que el servicio de autenticación puede realizar en base a sus datos de usuario almacenados.
En resumen, con el procedimiento de acuerdo con la invención es posible utilizar casi cualquier soporte de datos como segundo factor, en particular, las tarjetas EMV se pueden utilizar como segundo factor para FIDO-U2F. Los soportes de datos no deben disponer de las capacidades criptográficas requeridas para FIDO. Por lo tanto, para muchas personas se suprime la necesidad de adquirir y mantener un "2° dispositivo". Además, no se requiere el consentimiento del emisor del soporte de datos (emisor de la tarjeta) para ejecutar el procedimiento. Por tanto, el procedimiento se puede implementar sin un esfuerzo significativo.
El servidor token requerido no necesita una base de datos en la que se almacenen los datos del usuario/datos del cliente. En consecuencia, el servidor token es simple y económico. Solo es ventajoso un HSM para almacenar la clave maestra del servidor token.
El procedimiento de acuerdo con la invención es seguro contra troyanos en el cliente mediante el uso del desafío del servidor al calcular los datos de autenticación de soporte de datos.
Otra ventaja del procedimiento es que el soporte de datos solo se debe mantener cerca del cliente brevemente durante la realización del intercambio de datos entre el cliente y el soporte de datos. De este modo se mantiene baja la probabilidad de autenticaciones interrumpidas involuntariamente.
Breve descripción de los dibujos
La fig. 1 muestra esquemáticamente la secuencia de una autenticación de dos factores de acuerdo con la invención;
la fig. 2 muestra la secuencia de una autenticación de dos factores de acuerdo con la invención en una representación más detallada; y
la figura 3 muestra un diagrama de flujo que representa la autenticación de dos factores de acuerdo con la invención.
Descripción detallada de modos de realización de la invención
Modos de realización a modo de ejemplo de la invención se describen en detalle a continuación en referencia a las figs. 1-3. Los cambios en relación con el procedimiento descrito son posibles dentro del alcance de protección definido mediante las reivindicaciones.
La fig. 1 muestra esquemáticamente la secuencia de una autenticación de dos factores de acuerdo con la invención entre un cliente y una parte de confianza. Un cliente es, por ejemplo, un teléfono móvil, una tableta PC, un ordenador (PC) o similares. Una parte de confianza es, por ejemplo, un dispositivo como un host, un servidor o similares, que posibilita el acceso a un servicio, en particular una aplicación de software segura.
Se usa el U2F (Universal Second Factor, segundo factor universal) estándar de la industria para la autenticación de dos factores. La especificación U2F se gestiona por la alianza FIDO.
En el caso de la autenticación de dos factores de acuerdo con la invención, en primer lugar (paso 1) se realiza una autenticación entre el cliente y la parte de confianza. Esta se puede realizar, por ejemplo, mediante la introducción de un nombre de usuario y una contraseña en un navegador web.
En el siguiente paso 2 se transmiten datos adicionales de autenticación de la parte de confianza al cliente. Los datos adicionales de autenticación pueden ser, por ejemplo, un KeyHandle (FIDO), un desafío FIDO y un AppID (FIDO). Estos términos son bien conocidos por el estándar FIDO, por lo que se prescinde de una descripción aparte de la breve descripción de los términos a continuación.
El KeyHandle identifica y presenta la clave privada (UserPrivateKey) para la posterior autenticación del usuario frente a la parte de confianza en forma encriptada. El desafío es un desafío normal para una operación criptográfica, por ejemplo, un número aleatorio. El AppID identifica el servicio (web) con el que el usuario desea autenticarse.
En un paso 3 facultativo subsiguiente se puede verificar el AppID. Además, en el paso 3 se puede examinar de qué modo se puede comprobar el segundo factor (U2F). En el presente caso se supone que un soporte de datos está autorizado como segundo factor.
En un paso siguiente 4, el cliente solicita un desafío de servidor de un servidor token. Si el soporte de datos a utilizar es una tarjeta EMV, este desafío del servidor también se puede denominar desafío EMV. El desafío del servidor comprende un número aleatorio (número impredecible) que los proporciona el servidor token. El número aleatorio tiene, por ejemplo, al menos 4 bytes de longitud. El desafío del servidor se examina, en particular firma, por el soporte de datos en un paso posterior 6 (véase abajo). El servidor token puede verificar mediante la firma si el soporte de datos se ha presentado realmente al cliente. Dado que en el desafío del servidor está contenido el número aleatorio, se dificulta la posibilidad de un ataque de repetición por parte de un atacante. En el paso 4 se pueden transmitir datos adicionales de autenticación del cliente al servidor token en el marco de la solicitud del desafío del servidor. De forma alternativa, estos datos adicionales de autenticación se pueden transmitir en el paso 7 (véase abajo). Es irrelevante si los datos adicionales de autenticación se le transmiten al servidor token en el paso 4 y/o 7.
A continuación, el desafío del servidor se transmite desde el servidor token al cliente en otro paso 5.
Acto seguido, se realiza un intercambio de datos entre el cliente y el soporte de datos (paso 6). En el transcurso del intercambio de datos, el soporte de datos se conecta con el cliente, por ejemplo, sin contacto o con contacto. Los datos se intercambian entre el soporte de datos y el cliente. Por ejemplo, el cliente puede recibir al menos un certificado del soporte de datos, en particular un IssuerPKCert y un CardPKCert.
Además, en el paso 6, el cliente envía el desafío del servidor al soporte de datos, con lo que el soporte de datos calcula los datos de autenticación de soporte de datos y el desafío del servidor entra en el cálculo de los datos de autenticación de soporte de datos. Dado que el desafío del servidor entra en el cálculo de los datos de autenticación de soporte de datos, el número aleatorio del desafío del servidor también entra en el cálculo. De acuerdo con la invención, el cliente solo recibe los datos de autenticación de soporte de datos de parte del soporte de datos sin verificarlos, ya que de acuerdo con la invención la verificación en el servidor token (pasos 8-10) se realiza en un momento posterior. En un momento posterior del examen en el servidor token, ya no es necesario conectar el soporte de datos al cliente.
En un paso 7 subsiguiente se transmiten los datos de autenticación del cliente al servidor token, en el que los datos de autenticación comprenden los datos del intercambio de datos entre el cliente y el soporte de datos, en particular los datos de autenticación de soporte de datos, así como los datos adicionales de autenticación. Los datos que proceden del intercambio con el soporte de datos pueden comprender, por ejemplo, el IssuerPKCert, el CardPKCert y los datos de autenticación de soporte de datos. Los datos que proceden del intercambio con la parte de confianza pueden comprender el KeyHandle, un hash del AppID, así como un hash de los datos del cliente, con lo que los datos del cliente presentan el desafío original (FIDO).
Los datos de autenticación transmitidos al servidor token se verifican en el siguiente paso 8 por el servidor token. Durante el examen, el servidor token puede examinar el IssuerPKCert con la ayuda de una "clave pública del esquema de pago" presente, el CardPKCert con la ayuda de la "clave pública del emisor" ahora verificada y los datos de autenticación de soporte de datos con la ayuda de la ahora examinada "clave pública de la tarjeta".
Si todos los exámenes son exitosos, se asegura que los datos de autenticación de soporte de datos proceden de un soporte de datos real, por ejemplo una tarjeta EMV, o se han firmado, es decir, se ha presentado realmente el soporte de datos correspondiente. Al usar una tarjeta EMV, el servidor token se puede convencer, por ejemplo, de que los datos de número de cuenta principal, número de secuencia PAN (facultativo) y fecha de caducidad, que identifican de manera unívoca una tarjeta EMV, proceden de la tarjeta EMV utilizada. En este contexto, el servidor token ejecuta los pasos que realizaría el terminal en el caso de una transacción EMV conocida.
En el caso de una verificación exitosa, el servidor token desencripta una clave de cliente de los datos de autenticación en el siguiente paso facultativo 9. Para ello, el servidor token puede desencriptar, por ejemplo, la clave privada del usuario (también conocida como clave de cliente) que está contenida (junto con eventualmente otros datos) en el identificador de clave (véase arriba). La clave (simétrica) "KWrap", requerida para el desencriptado de KeyHandle, se puede derivar de los siguientes datos: Clave maestra (clave principal) del servidor token, número de cuenta personal (PAN), número de secuencia PAN (opcional), fecha de caducidad (opcional), otros datos (opcional). De acuerdo con una alternativa, la clave “KWrap” puede ser, por ejemplo, el resultado del encriptado o desencriptado de un valor hash a través de los datos de la tarjeta (PAN, número de secuencia PAN, fecha de caducidad, etc.).
Todos los datos relacionados con el usuario que se utilizan para la derivación de claves proceden del cliente, el soporte de datos o la parte de confianza. No es necesario mantener una base de datos de usuario en el servidor token. De este modo es posible configurar el servidor token fácilmente y, como resultado, configurarlo de manera más económica. Solo la clave maestra del servidor token a utilizar de acuerdo con un modo de realización preferente se debe almacenar de forma segura para garantizar la seguridad del procedimiento. Para ello se ofrece un HSM (módulo de seguridad de hardware).
A continuación, en el siguiente paso 10 se genera una respuesta de autenticación en el servidor token. La respuesta de autenticación sirve para confirmar la autenticidad del segundo factor (U2F), en el presente caso el soporte de datos. En el presente ejemplo de modo de realización, el mensaje de respuesta de autenticación (FIDO) se puede generar con la ayuda de la clave privada del usuario, en el que es una firma con ayuda de la clave privada del usuario a través de un hash (AppID), un hash (datos del cliente), en el que con este hash también se firma indirectamente el desafío FIDO original de la parte de confianza, un contador (contador de transacciones de la aplicación de la tarjeta EMV), etc.
Luego, la respuesta de autenticación se envía al cliente en un paso siguiente 11, eventualmente junto con otros datos, y desde allí se envía a la parte de confianza en otro paso 12. De forma alternativa, la respuesta de autenticación también se puede enviar directamente a la parte de confianza.
Entonces, la parte de confianza comprueba (paso 13) la respuesta de autenticación; en el ejemplo de modo de realización mencionado anteriormente, la parte de confianza examina la (firma de la) respuesta de autenticación (FIDO). Para ello, la parte de confianza usa la clave pública del usuario (clave del cliente). Esta verificación se puede realizar de acuerdo con el estándar FIDO y, por lo tanto, no se explica con más detalle.
La fig. 2 muestra la secuencia de una autenticación de acuerdo con la invención al utilizar una tarjeta EMV como soporte de datos. Una tarjeta EMV es por lo general una tarjeta de pago, que está conformada de acuerdo con la especificación EMV (Europay International, MasterCard y VISA). Las tarjetas EMV se especifican actualmente de tal manera que no pueden calcular las curvas elípticas que se utilizan en los sistemas criptográficos asimétricos y que se requieren para la autenticación FIDO-U2F.
Correspondientemente, el procedimiento de acuerdo con la invención es adecuado, entre otras cosas, al utilizar una tarjeta EMV (soporte de datos) como segundo factor (U2F), ya que la tarjeta EMV puede subcontratar el cálculo requerido de acuerdo con FIDO en cooperación con un servidor token.
En este contexto, la figura 2 muestra la secuencia a modo de ejemplo de una autenticación de dos factores de acuerdo con la invención, en la que un usuario intenta iniciar sesión en un navegador (cliente FIDO) en una página web de una parte de confianza. Los pasos mostrados en la fig. 2 corresponden esencialmente a los pasos ya explicados en la fig.
1, por lo que se prescinde de una descripción detallada repetida.
La fig. 3 muestra un diagrama de flujo que muestra la autenticación de dos factores de acuerdo con la invención, en el que se utiliza igualmente una tarjeta EMV como soporte de datos de forma análoga a la fig. 2. Las secuencias la fig.
3 corresponden esencialmente a las secuencias mostradas en las figs. 1 y 2, por lo que se prescinde de una nueva descripción.
Otro ejemplo de modo de realización es que un teléfono móvil, por ejemplo un teléfono inteligente, presenta una funcionalidad que también presenta una tarjeta EMV, como se describió anteriormente. Esta función se puede ejecutar, por ejemplo, en un elemento seguro (SE), por ejemplo, la tarjeta SIM, en un entorno de ejecución confiable (TEE), es decir, un entorno de tiempo de ejecución seguro para una aplicación, o en una emulación de tarjeta de host (HCE), es decir, una tecnología para la virtualización de tarjetas inteligentes en procedimientos de pago móviles basados en NFC, del teléfono móvil. Por tanto, el teléfono móvil presenta una función de tarjeta virtual.
El experto en la materia reconoce a partir de la descripción anterior que son posibles varios cambios en el procedimiento de acuerdo con la invención dentro del alcance de protección de las reivindicaciones.

Claims (14)

REIVINDICACIONES
1. Procedimiento para realizar una autenticación de dos factores entre un cliente y una parte de confianza, que comprende los siguientes pasos:
- realización (1) de una autenticación entre el cliente y la parte de confianza;
-transmisión (2) de datos adicionales de autenticación de la parte de confianza al cliente;
- solicitación (4) de un desafío de servidor por parte del cliente de un servidor token;
- transmisión (5) del desafío del servidor del servidor token al cliente;
- realización (6) de un intercambio de datos entre el cliente y un soporte de datos, en el que el cliente recibe datos de autenticación de soporte de datos del soporte de datos, en el que los datos de autenticación de soporte de datos se calculan al menos parcialmente utilizando datos del desafío de servidor,
- transmisión (7) de datos de autenticación del cliente al servidor token, en el que los datos de autenticación comprenden los datos del intercambio de datos entre el cliente y el soporte de datos, los datos de autenticación de soporte de datos, así como los datos adicionales de autenticación;
-verificación (8) de los datos de autenticación por parte del servidor token, por lo que se proporciona la prueba de que el soporte de datos estuvo presente físicamente en el intercambio de datos entre el cliente y el soporte de datos;
- generación (10) de una respuesta de autenticación en el servidor token;
- transmisión (11) de la respuesta de autenticación del servidor token al cliente; y
- transmisión (12) de la respuesta de autenticación del cliente a la parte de confianza y verificación (13) de la respuesta de autenticación por la parte de confianza.
2. Procedimiento de acuerdo con la reivindicación 1, caracterizado por que al realizar de la autenticación entre el cliente y la parte de confianza, se transfiere un KeyHandle, en particular una UserPrivateKey, un desafío y/o un AppID.
3. Procedimiento de acuerdo con la reivindicación 1 o 2, caracterizado por que para realizar el procedimiento no se requiere la introducción de un PIN frente al el soporte de datos.
4. Procedimiento de acuerdo con una de las reivindicaciones anteriores, caracterizado por que el desafío de servidor presenta un número aleatorio.
5. Procedimiento de acuerdo con una de las reivindicaciones anteriores, caracterizado por que para realizar el intercambio de datos entre el cliente y el soporte de datos se establece una conexión sin contacto y/o con contacto entre el cliente y el soporte de datos.
6. Procedimiento de acuerdo con una de las reivindicaciones anteriores, caracterizado por que durante la verificación de los datos de autenticación por el servidor token, el servidor token desencripta (10) una clave de cliente a partir de los datos de autenticación, en particular los datos adicionales de autenticación, en el que la clave de cliente se utiliza en la generación de la respuesta de autenticación.
7. Procedimiento de acuerdo con una de las reivindicaciones anteriores, caracterizado por que no se almacenan datos de usuario en el servidor token.
8. Procedimiento de acuerdo con una de las reivindicaciones anteriores, caracterizado por que el servidor token genera la respuesta de autenticación con ayuda de los datos de usuario que proceden exclusivamente del cliente, el soporte de datos y/o la parte de confianza.
9. Procedimiento de acuerdo con una de las reivindicaciones anteriores, caracterizado por que para el intercambio de datos entre el cliente y el soporte de datos no es necesaria la verificación del PIN.
10. Procedimiento de acuerdo con una de las reivindicaciones anteriores, que comprende además el paso de la verificación de si se permite una autenticación de dos factores con el soporte de datos como segundo factor.
11. Uso de un terminal móvil, de una tableta PC o de un PC como cliente en un procedimiento de autenticación de dos factores de acuerdo con una de las reivindicaciones anteriores, en el que el cliente está concebido para ejecutar los pasos del cliente en el procedimiento.
12. Servidor token, concebido para el uso en un procedimiento de autenticación de dos factores de acuerdo con una de las reivindicaciones anteriores 1-10, en el que el servidor token está concebido para ejecutar los pasos del servidor token en el procedimiento.
13. Sistema que comprende un servidor token de acuerdo con la reivindicación 12 y concebido para ejecutar un procedimiento de autenticación de dos factores de acuerdo con una de las reivindicaciones anteriores 1-10.
14. Sistema de acuerdo con la reivindicación 13, que comprende un soporte de datos en forma de tarjeta EMV que está concebida para proporcionar datos de autenticación de soporte de datos a un cliente a través de una conexión sin contacto y/o con contacto, datos que se calculan al menos parcialmente utilizando datos de un desafío de servidor.
ES18705313T 2017-01-27 2018-01-29 Procedimiento para realizar una autenticación de dos factores Active ES2887258T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102017000768.3A DE102017000768A1 (de) 2017-01-27 2017-01-27 Verfahren zum Durchführen einer Zweifaktorauthentifizierung
PCT/EP2018/000041 WO2018137889A1 (de) 2017-01-27 2018-01-29 Verfahren zum durchführen einer zweifaktorauthentifizierung

Publications (1)

Publication Number Publication Date
ES2887258T3 true ES2887258T3 (es) 2021-12-22

Family

ID=61226526

Family Applications (2)

Application Number Title Priority Date Filing Date
ES18705312T Active ES2894480T3 (es) 2017-01-27 2018-01-29 Procedimiento para realizar la autenticación
ES18705313T Active ES2887258T3 (es) 2017-01-27 2018-01-29 Procedimiento para realizar una autenticación de dos factores

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES18705312T Active ES2894480T3 (es) 2017-01-27 2018-01-29 Procedimiento para realizar la autenticación

Country Status (6)

Country Link
US (2) US11258777B2 (es)
EP (2) EP3574610B1 (es)
CN (1) CN110337797B (es)
DE (1) DE102017000768A1 (es)
ES (2) ES2894480T3 (es)
WO (2) WO2018137889A1 (es)

Families Citing this family (160)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11315114B2 (en) 2016-12-28 2022-04-26 Capital One Services, Llc Dynamic transaction card protected by multi-factor authentication
US10515361B2 (en) 2016-12-28 2019-12-24 Capital One Services, Llc Smart card secure online checkout
DE102017000768A1 (de) * 2017-01-27 2018-08-02 Giesecke+Devrient Mobile Security Gmbh Verfahren zum Durchführen einer Zweifaktorauthentifizierung
WO2019113553A1 (en) 2017-12-08 2019-06-13 Net-Thunder, Llc Automatically deployed information technology (it) system and method
US10546444B2 (en) 2018-06-21 2020-01-28 Capital One Services, Llc Systems and methods for secure read-only authentication
CN110932858B (zh) * 2018-09-19 2023-05-02 阿里巴巴集团控股有限公司 认证方法和系统
CN109218028B (zh) * 2018-09-19 2019-08-09 恒宝股份有限公司 一种在线签发eSIM证书的方法、装置及系统
US11216806B2 (en) 2018-09-19 2022-01-04 Capital One Services, Llc Systems and methods for providing card interactions
US10909527B2 (en) 2018-10-02 2021-02-02 Capital One Services, Llc Systems and methods for performing a reissue of a contactless card
CA3115084A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072670A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10733645B2 (en) 2018-10-02 2020-08-04 Capital One Services, Llc Systems and methods for establishing identity for order pick up
WO2020072474A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10771253B2 (en) 2018-10-02 2020-09-08 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10511443B1 (en) 2018-10-02 2019-12-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10607214B1 (en) 2018-10-02 2020-03-31 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
AU2019355110A1 (en) 2018-10-02 2021-04-08 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US11210664B2 (en) 2018-10-02 2021-12-28 Capital One Services, Llc Systems and methods for amplifying the strength of cryptographic algorithms
US10680824B2 (en) 2018-10-02 2020-06-09 Capital One Services, Llc Systems and methods for inventory management using cryptographic authentication of contactless cards
US10554411B1 (en) 2018-10-02 2020-02-04 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10581611B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
SG11202101171VA (en) 2018-10-02 2021-03-30 Capital One Services Llc Systems and methods for cryptographic authentication of contactless cards
US10565587B1 (en) 2018-10-02 2020-02-18 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10592710B1 (en) 2018-10-02 2020-03-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10748138B2 (en) 2018-10-02 2020-08-18 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
MX2021003217A (es) 2018-10-02 2021-05-12 Capital One Services Llc Sistemas y metodos para autentificacion criptografica de tarjetas sin contacto.
US10489781B1 (en) 2018-10-02 2019-11-26 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10582386B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10579998B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10949520B2 (en) 2018-10-02 2021-03-16 Capital One Services, Llc Systems and methods for cross coupling risk analytics and one-time-passcodes
JP7668209B2 (ja) 2018-10-02 2025-04-24 キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニー 非接触カードの暗号化認証のためのシステムおよび方法
US10630653B1 (en) 2018-10-02 2020-04-21 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10505738B1 (en) 2018-10-02 2019-12-10 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10542036B1 (en) 2018-10-02 2020-01-21 Capital One Services, Llc Systems and methods for signaling an attack on contactless cards
US10771254B2 (en) 2018-10-02 2020-09-08 Capital One Services, Llc Systems and methods for email-based card activation
SG11202101874SA (en) 2018-10-02 2021-03-30 Capital One Services Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072626A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
AU2019351825A1 (en) 2018-10-02 2021-04-15 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
DE102018008271A1 (de) * 2018-10-18 2020-04-23 Giesecke+Devrient Mobile Security Gmbh Absicherung einer P2P-Kommunikation
US10992670B1 (en) * 2018-11-12 2021-04-27 Amazon Technologies, Inc. Authenticating identities for establishing secure network tunnels
US10664830B1 (en) 2018-12-18 2020-05-26 Capital One Services, Llc Devices and methods for selective contactless communication
US11070548B2 (en) * 2018-12-21 2021-07-20 Paypal, Inc. Tokenized online application sessions
US20200226581A1 (en) 2019-01-11 2020-07-16 Capital One Services, Llc Systems and methods for touch screen interface interaction using a card overlay
US11641363B2 (en) * 2019-01-14 2023-05-02 Qatar Foundation For Education, Science And Community Development Methods and systems for verifying the authenticity of a remote service
US11037136B2 (en) 2019-01-24 2021-06-15 Capital One Services, Llc Tap to autofill card data
US10510074B1 (en) 2019-02-01 2019-12-17 Capital One Services, Llc One-tap payment using a contactless card
US11120453B2 (en) 2019-02-01 2021-09-14 Capital One Services, Llc Tap card to securely generate card data to copy to clipboard
US10467622B1 (en) 2019-02-01 2019-11-05 Capital One Services, Llc Using on-demand applications to generate virtual numbers for a contactless card to securely autofill forms
US10425129B1 (en) 2019-02-27 2019-09-24 Capital One Services, Llc Techniques to reduce power consumption in near field communication systems
US10523708B1 (en) 2019-03-18 2019-12-31 Capital One Services, Llc System and method for second factor authentication of customer support calls
US10984416B2 (en) 2019-03-20 2021-04-20 Capital One Services, Llc NFC mobile currency transfer
US10535062B1 (en) 2019-03-20 2020-01-14 Capital One Services, Llc Using a contactless card to securely share personal data stored in a blockchain
US10438437B1 (en) 2019-03-20 2019-10-08 Capital One Services, Llc Tap to copy data to clipboard via NFC
US10643420B1 (en) 2019-03-20 2020-05-05 Capital One Services, Llc Contextual tapping engine
US10970712B2 (en) 2019-03-21 2021-04-06 Capital One Services, Llc Delegated administration of permissions using a contactless card
US10467445B1 (en) 2019-03-28 2019-11-05 Capital One Services, Llc Devices and methods for contactless card alignment with a foldable mobile device
US11521262B2 (en) 2019-05-28 2022-12-06 Capital One Services, Llc NFC enhanced augmented reality information overlays
US10516447B1 (en) 2019-06-17 2019-12-24 Capital One Services, Llc Dynamic power levels in NFC card communications
US10871958B1 (en) 2019-07-03 2020-12-22 Capital One Services, Llc Techniques to perform applet programming
US11694187B2 (en) 2019-07-03 2023-07-04 Capital One Services, Llc Constraining transactional capabilities for contactless cards
US11392933B2 (en) 2019-07-03 2022-07-19 Capital One Services, Llc Systems and methods for providing online and hybridcard interactions
US12086852B2 (en) 2019-07-08 2024-09-10 Capital One Services, Llc Authenticating voice transactions with payment card
US10713649B1 (en) 2019-07-09 2020-07-14 Capital One Services, Llc System and method enabling mobile near-field communication to update display on a payment card
US10885514B1 (en) 2019-07-15 2021-01-05 Capital One Services, Llc System and method for using image data to trigger contactless card transactions
US10498401B1 (en) 2019-07-15 2019-12-03 Capital One Services, Llc System and method for guiding card positioning using phone sensors
US10832271B1 (en) 2019-07-17 2020-11-10 Capital One Services, Llc Verified reviews using a contactless card
US10733601B1 (en) 2019-07-17 2020-08-04 Capital One Services, Llc Body area network facilitated authentication or payment authorization
US11182771B2 (en) 2019-07-17 2021-11-23 Capital One Services, Llc System for value loading onto in-vehicle device
US11521213B2 (en) 2019-07-18 2022-12-06 Capital One Services, Llc Continuous authentication for digital services based on contactless card positioning
US10506426B1 (en) 2019-07-19 2019-12-10 Capital One Services, Llc Techniques for call authentication
US10541995B1 (en) 2019-07-23 2020-01-21 Capital One Services, Llc First factor contactless card authentication system and method
US11303629B2 (en) 2019-09-26 2022-04-12 Bank Of America Corporation User authentication using tokens
US11140154B2 (en) * 2019-09-26 2021-10-05 Bank Of America Corporation User authentication using tokens
US11329823B2 (en) 2019-09-26 2022-05-10 Bank Of America Corporation User authentication using tokens
EP4038587A4 (en) 2019-10-02 2023-06-07 Capital One Services, LLC CLIENT DEVICE AUTHENTICATION USING CONTACTLESS MAGNETIC STRIP DATA
US11861590B1 (en) * 2019-12-18 2024-01-02 Block, Inc. Identity verification using payment instrument(s)
US11651361B2 (en) 2019-12-23 2023-05-16 Capital One Services, Llc Secure authentication based on passport data stored in a contactless card
US10862540B1 (en) 2019-12-23 2020-12-08 Capital One Services, Llc Method for mapping NFC field strength and location on mobile devices
US11113685B2 (en) 2019-12-23 2021-09-07 Capital One Services, Llc Card issuing with restricted virtual numbers
US10657754B1 (en) 2019-12-23 2020-05-19 Capital One Services, Llc Contactless card and personal identification system
US11615395B2 (en) 2019-12-23 2023-03-28 Capital One Services, Llc Authentication for third party digital wallet provisioning
US10885410B1 (en) 2019-12-23 2021-01-05 Capital One Services, Llc Generating barcodes utilizing cryptographic techniques
US10733283B1 (en) 2019-12-23 2020-08-04 Capital One Services, Llc Secure password generation and management using NFC and contactless smart cards
US10853795B1 (en) 2019-12-24 2020-12-01 Capital One Services, Llc Secure authentication based on identity data stored in a contactless card
US10664941B1 (en) 2019-12-24 2020-05-26 Capital One Services, Llc Steganographic image encoding of biometric template information on a card
US11200563B2 (en) 2019-12-24 2021-12-14 Capital One Services, Llc Account registration using a contactless card
US10757574B1 (en) 2019-12-26 2020-08-25 Capital One Services, Llc Multi-factor authentication providing a credential via a contactless card for secure messaging
US10909544B1 (en) 2019-12-26 2021-02-02 Capital One Services, Llc Accessing and utilizing multiple loyalty point accounts
US11038688B1 (en) 2019-12-30 2021-06-15 Capital One Services, Llc Techniques to control applets for contactless cards
US11455620B2 (en) 2019-12-31 2022-09-27 Capital One Services, Llc Tapping a contactless card to a computing device to provision a virtual number
US10860914B1 (en) 2019-12-31 2020-12-08 Capital One Services, Llc Contactless card and method of assembly
US20210217024A1 (en) * 2020-01-15 2021-07-15 CrowdBlink Technologies, Inc. System and Method of Consolidating Identity Services
US11210656B2 (en) 2020-04-13 2021-12-28 Capital One Services, Llc Determining specific terms for contactless card activation
WO2021212001A1 (en) 2020-04-17 2021-10-21 Trusona, Inc. Systems and methods for cryptographic authentication
US11222342B2 (en) 2020-04-30 2022-01-11 Capital One Services, Llc Accurate images in graphical user interfaces to enable data transfer
US10915888B1 (en) 2020-04-30 2021-02-09 Capital One Services, Llc Contactless card with multiple rotating security keys
US10861006B1 (en) 2020-04-30 2020-12-08 Capital One Services, Llc Systems and methods for data access control using a short-range transceiver
US11823175B2 (en) 2020-04-30 2023-11-21 Capital One Services, Llc Intelligent card unlock
US11030339B1 (en) 2020-04-30 2021-06-08 Capital One Services, Llc Systems and methods for data access control of personal user data using a short-range transceiver
US10963865B1 (en) 2020-05-12 2021-03-30 Capital One Services, Llc Augmented reality card activation experience
US11063979B1 (en) 2020-05-18 2021-07-13 Capital One Services, Llc Enabling communications between applications in a mobile operating system
US11100511B1 (en) 2020-05-18 2021-08-24 Capital One Services, Llc Application-based point of sale system in mobile operating systems
US11062098B1 (en) 2020-08-11 2021-07-13 Capital One Services, Llc Augmented reality information display and interaction via NFC based authentication
US12165149B2 (en) 2020-08-12 2024-12-10 Capital One Services, Llc Systems and methods for user verification via short-range transceiver
US11482312B2 (en) 2020-10-30 2022-10-25 Capital One Services, Llc Secure verification of medical status using a contactless card
US11165586B1 (en) 2020-10-30 2021-11-02 Capital One Services, Llc Call center web-based authentication using a contactless card
US11373169B2 (en) 2020-11-03 2022-06-28 Capital One Services, Llc Web-based activation of contactless cards
US12021861B2 (en) * 2021-01-04 2024-06-25 Bank Of America Corporation Identity verification through multisystem cooperation
US11216799B1 (en) 2021-01-04 2022-01-04 Capital One Services, Llc Secure generation of one-time passcodes using a contactless card
US11682012B2 (en) 2021-01-27 2023-06-20 Capital One Services, Llc Contactless delivery systems and methods
US11792001B2 (en) 2021-01-28 2023-10-17 Capital One Services, Llc Systems and methods for secure reprovisioning
US11562358B2 (en) 2021-01-28 2023-01-24 Capital One Services, Llc Systems and methods for near field contactless card communication and cryptographic authentication
US11687930B2 (en) 2021-01-28 2023-06-27 Capital One Services, Llc Systems and methods for authentication of access tokens
US11438329B2 (en) 2021-01-29 2022-09-06 Capital One Services, Llc Systems and methods for authenticated peer-to-peer data transfer using resource locators
US11777933B2 (en) 2021-02-03 2023-10-03 Capital One Services, Llc URL-based authentication for payment cards
US11637826B2 (en) 2021-02-24 2023-04-25 Capital One Services, Llc Establishing authentication persistence
US11245438B1 (en) 2021-03-26 2022-02-08 Capital One Services, Llc Network-enabled smart apparatus and systems and methods for activating and provisioning same
US12143515B2 (en) 2021-03-26 2024-11-12 Capital One Services, Llc Systems and methods for transaction card-based authentication
US12160419B2 (en) 2021-04-15 2024-12-03 Capital One Services, Llc Authenticated messaging session with contactless card authentication
US11961089B2 (en) 2021-04-20 2024-04-16 Capital One Services, Llc On-demand applications to extend web services
US11935035B2 (en) 2021-04-20 2024-03-19 Capital One Services, Llc Techniques to utilize resource locators by a contactless card to perform a sequence of operations
US11902442B2 (en) 2021-04-22 2024-02-13 Capital One Services, Llc Secure management of accounts on display devices using a contactless card
US11354555B1 (en) 2021-05-04 2022-06-07 Capital One Services, Llc Methods, mediums, and systems for applying a display to a transaction card
US11831688B2 (en) * 2021-06-18 2023-11-28 Capital One Services, Llc Systems and methods for network security
US12301735B2 (en) 2021-06-18 2025-05-13 Capital One Services, Llc Systems and methods for contactless card communication and multi-device key pair cryptographic authentication
US12335412B2 (en) 2021-06-21 2025-06-17 Capital One Services, Llc Systems and methods for scalable cryptographic authentication of contactless cards
US12041172B2 (en) 2021-06-25 2024-07-16 Capital One Services, Llc Cryptographic authentication to control access to storage devices
US12061682B2 (en) 2021-07-19 2024-08-13 Capital One Services, Llc System and method to perform digital authentication using multiple channels of communication
US12495042B2 (en) 2021-08-16 2025-12-09 Capital One Services, Llc Systems and methods for resetting an authentication counter
US12062258B2 (en) 2021-09-16 2024-08-13 Capital One Services, Llc Use of a payment card to unlock a lock
EP4152125A1 (en) * 2021-09-21 2023-03-22 Thales Dis France SAS Icc reader
US11930014B2 (en) 2021-09-29 2024-03-12 Bank Of America Corporation Information security using multi-factor authorization
US12069173B2 (en) 2021-12-15 2024-08-20 Capital One Services, Llc Key recovery based on contactless card authentication
US12166750B2 (en) 2022-02-08 2024-12-10 Capital One Services, Llc Systems and methods for secure access of storage
US12354077B2 (en) 2022-06-23 2025-07-08 Capital One Services, Llc Mobile web browser authentication and checkout using a contactless card
US12596780B2 (en) 2022-06-27 2026-04-07 Capital One Services, LLC. Techniques to perform dynamic call center authentication utilizing a contactless card
US12511654B2 (en) 2022-08-08 2025-12-30 Capital One Services, Llc Systems and methods for bypassing contactless payment transaction limit
US12354104B2 (en) 2022-08-09 2025-07-08 Capital One Services, Llc Methods and arrangements for proof of purchase
US12505450B2 (en) 2022-08-17 2025-12-23 Capital One Services, Llc Systems and methods for dynamic data generation and cryptographic card authentication
US12289396B2 (en) 2022-08-18 2025-04-29 Capital One Services, Llc Parallel secret salt generation and authentication for encrypted communication
US12592828B2 (en) 2023-01-06 2026-03-31 Capital One Services, Llc System and method for parallel manufacture and verification of one-time-password authentication cards
US12147983B2 (en) 2023-01-13 2024-11-19 Capital One Services, Llc Systems and methods for multi-factor authentication using device tracking and identity verification
US20240283664A1 (en) * 2023-02-01 2024-08-22 Dashlane SAS Authentication with Cloud-Based Secure Enclave
US12519652B2 (en) 2023-02-24 2026-01-06 Capital One Services, Llc System and method for dynamic integration of user-provided data with one-time-password authentication cryptogram
US12592819B2 (en) 2023-02-28 2026-03-31 Capital One Services, Llc Membership account management using a contactless card
US12248832B2 (en) 2023-03-07 2025-03-11 Capital One Services, Llc Systems and methods for steganographic image encoding and identity verification using same
US12335256B2 (en) 2023-03-08 2025-06-17 Capital One Services, Llc Systems and methods for device binding authentication
US12591875B2 (en) 2023-03-10 2026-03-31 Capital One Services, Llc Systems and methods of contactless card as one authentication factor for multiple factor authentication
US12248928B2 (en) 2023-03-13 2025-03-11 Capital One Services, Llc Systems and methods of secure merchant payment over messaging platform using a contactless card
US12511640B2 (en) 2023-03-13 2025-12-30 Capital One Services, Llc Systems and methods of managing password using contactless card
US12124903B2 (en) 2023-03-16 2024-10-22 Capital One Services, Llc Card with a time-sensitive element and systems and methods for implementing the same
US12299672B2 (en) 2023-03-30 2025-05-13 Capital One Services, Llc System and method for authentication with transaction cards
US12499432B2 (en) 2023-04-06 2025-12-16 Capital One Services, Llc Techniques to perform operations with a contactless card when in the presence of a trusted device
US12591876B2 (en) 2023-04-07 2026-03-31 Capital One Services, Llc Systems and methods for launching a mobile application or a browser extension responsive to satisfying predetermined conditions
US12200135B2 (en) 2023-06-13 2025-01-14 Capital One Services, Llc Contactless card-based authentication via web-browser
US12505448B2 (en) 2023-08-09 2025-12-23 Capital One Services, Llc Systems and methods for fraud prevention in mobile application verification device enrollment process
US12511638B2 (en) 2023-09-07 2025-12-30 Capital One Services, Llc Assignment of near-field communications applets
US12580767B2 (en) 2023-10-31 2026-03-17 Capital One Services, LLC. Transmission of secure and authenticated data over a network
US12580752B2 (en) 2024-01-03 2026-03-17 Capital One Services, Llc Systems and methods for generating shared secret key for transaction cards
DE102024120103A1 (de) * 2024-07-15 2026-01-15 Giesecke+Devrient ePayments GmbH Verfahren zur Authentisierung einer Entität

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NO20061520L (no) 2006-04-04 2007-10-05 Telenor Asa Fremgangsmate og anordning for autentisering av brukere
WO2011017099A2 (en) * 2009-07-27 2011-02-10 Suridx, Inc. Secure communication using asymmetric cryptography and light-weight certificates
JP5865992B2 (ja) 2011-03-23 2016-02-17 インターデイジタル パテント ホールディングス インコーポレイテッド ネットワーク通信をセキュアにするためのシステムおよび方法
US9009793B2 (en) * 2011-03-31 2015-04-14 Infosys Limited Dynamic pin dual factor authentication using mobile device
AU2012301897B2 (en) * 2011-08-30 2017-04-13 Ov Loop Inc. Systems and methods for authorizing a transaction with an unexpected cryptogram
DE102011089580B3 (de) * 2011-12-22 2013-04-25 AGETO Innovation GmbH Verfahren zum Lesen von Attributen aus einem ID-Token
US9935953B1 (en) * 2012-11-06 2018-04-03 Behaviometrics Ab Secure authenticating an user of a device during a session with a connected server
GB201221433D0 (en) * 2012-11-28 2013-01-09 Hoverkey Ltd A method and system of providing authentication of user access to a computer resource on a mobile device
US9306754B2 (en) * 2012-12-28 2016-04-05 Nok Nok Labs, Inc. System and method for implementing transaction signing within an authentication framework
US9015482B2 (en) * 2012-12-28 2015-04-21 Nok Nok Labs, Inc. System and method for efficiently enrolling, registering, and authenticating with multiple authentication devices
WO2014176539A1 (en) 2013-04-26 2014-10-30 Interdigital Patent Holdings, Inc. Multi-factor authentication to achieve required authentication assurance level
US9363259B2 (en) 2013-05-23 2016-06-07 Symantec Corporation Performing client authentication using onetime values recovered from barcode graphics
US20150180869A1 (en) 2013-12-23 2015-06-25 Samsung Electronics Company, Ltd. Cloud-based scalable authentication for electronic devices
US9602508B1 (en) * 2013-12-26 2017-03-21 Lookout, Inc. System and method for performing an action based upon two-party authorization
US10142338B2 (en) * 2014-09-12 2018-11-27 Id.Me, Inc. Systems and methods for online third-party authentication of credentials
US9736154B2 (en) * 2014-09-16 2017-08-15 Nok Nok Labs, Inc. System and method for integrating an authentication service within a network architecture
US20180013782A1 (en) 2014-12-26 2018-01-11 Interdigital Patent Holdings, Inc. Continuous device/uicc based authentication for lte systems
EP3408988B1 (en) * 2016-01-25 2020-06-17 Telefonaktiebolaget LM Ericsson (publ) Method and apparatus for network access
CN106100848B (zh) * 2016-06-14 2019-02-05 东北大学 基于智能手机和用户口令的双因子身份认证系统及方法
US20180101850A1 (en) * 2016-10-12 2018-04-12 Microsoft Technology Licensing, Llc User and device authentication for web applications
US20180107813A1 (en) * 2016-10-18 2018-04-19 Plantronics, Inc. User Authentication Persistence
CN106789072A (zh) * 2016-12-26 2017-05-31 北京握奇智能科技有限公司 一种具有按键确认和nfc刷卡确认的fido设备及其工作方法
US10091195B2 (en) * 2016-12-31 2018-10-02 Nok Nok Labs, Inc. System and method for bootstrapping a user binding
DE102017000768A1 (de) * 2017-01-27 2018-08-02 Giesecke+Devrient Mobile Security Gmbh Verfahren zum Durchführen einer Zweifaktorauthentifizierung
US10505733B2 (en) * 2017-09-25 2019-12-10 Citrix Systems, Inc. Generating and managing a composite identity token for multi-service use
DE102018005038A1 (de) * 2018-06-25 2020-01-02 Giesecke+Devrient Mobile Security Gmbh Smartcard als Sicherheitstoken

Also Published As

Publication number Publication date
ES2894480T3 (es) 2022-02-14
EP3574625A1 (de) 2019-12-04
CN110337797A (zh) 2019-10-15
EP3574610B1 (de) 2021-07-28
US20190364032A1 (en) 2019-11-28
EP3574625B1 (de) 2021-09-01
WO2018137888A1 (de) 2018-08-02
US11258777B2 (en) 2022-02-22
EP3574610A1 (de) 2019-12-04
CN110337797B (zh) 2022-08-09
US20200127858A1 (en) 2020-04-23
US11184343B2 (en) 2021-11-23
WO2018137889A1 (de) 2018-08-02
DE102017000768A1 (de) 2018-08-02

Similar Documents

Publication Publication Date Title
ES2887258T3 (es) Procedimiento para realizar una autenticación de dos factores
US9860245B2 (en) System and methods for online authentication
US8943311B2 (en) System and methods for online authentication
CN106797311B (zh) 用于安全密码生成的系统、方法和存储介质
US8112787B2 (en) System and method for securing a credential via user and server verification
KR20090019576A (ko) 모바일 단말기 인증 방법 및 모바일 단말기 인증 시스템
AU2015202661B2 (en) System and methods for online authentication
AU2016228254A1 (en) System and methods for online authentication
AU2015202677B2 (en) System and methods for online authentication
HK1161007B (en) System and methods for online authentication
HK1161007A (en) System and methods for online authentication