ES2626064T3 - Procedimiento y sistema para autenticar a un usuario que utiliza un dispositivo móvil y por medio de certificados - Google Patents

Procedimiento y sistema para autenticar a un usuario que utiliza un dispositivo móvil y por medio de certificados Download PDF

Info

Publication number
ES2626064T3
ES2626064T3 ES13826744.8T ES13826744T ES2626064T3 ES 2626064 T3 ES2626064 T3 ES 2626064T3 ES 13826744 T ES13826744 T ES 13826744T ES 2626064 T3 ES2626064 T3 ES 2626064T3
Authority
ES
Spain
Prior art keywords
user
entity
module
mobile device
authentication
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
ES13826744.8T
Other languages
English (en)
Inventor
Gergely VANCZÁK
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.)
MICROSEC SZAMITASTECHNIKAI FEJLESZTO ZRT
Original Assignee
MICROSEC SZAMITASTECHNIKAI FEJLESZTO ZRT
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 MICROSEC SZAMITASTECHNIKAI FEJLESZTO ZRT filed Critical MICROSEC SZAMITASTECHNIKAI FEJLESZTO ZRT
Application granted granted Critical
Publication of ES2626064T3 publication Critical patent/ES2626064T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/77—Graphical identity

Abstract

Procedimiento para autenticar a un usuario (10) en una entidad (16), que comprende las etapas de - detectar, por medio de un módulo de contacto (20) de la entidad (16), un contacto del usuario (10) realizado en un navegador de un terminal (12), y - enviar, por medio del módulo de contacto (20), una dirección de red de un módulo de autenticación (24) de la entidad (16) a un dispositivo móvil (14) del usuario (10) en un mensaje de autenticación, caracterizado por - utilizar un mensaje de tipo cola de mensajes como el mensaje de autenticación, dicho mensaje se envía por medio de un módulo (26) de cola de mensajes correspondiente a la entidad (16), y un acuse de recibo firmado con una clave del usuario (10) se envía desde el dispositivo móvil (14) al módulo de contacto (20) después de que el mensaje de tipo cola de mensajes es recibido por el dispositivo móvil (14) que está conectado al módulo (26) de cola de mensaje, - verificar la aceptabilidad de un certificado de entidad del módulo de autenticación (24) por medio del dispositivo móvil (14) en base a la dirección de red, y verificar la aceptabilidad de un certificado de usuario del dispositivo móvil (14) por medio del módulo de autenticación (24), y - en caso de que el certificado de entidad y el certificado de usuario sean aceptables, autenticar al usuario (10) en la entidad (16) estableciendo un canal de comunicación (114, 120, 122, 124) entre el dispositivo móvil (14) y el módulo de autenticación (24), mientras que en caso de que el certificado de entidad o el certificado de usuario no sean aceptables, rechazar al usuario (10) en la entidad (16).

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Procedimiento y sistema para autenticar a un usuario que utiliza un dispositivo movil y por medio de certificados SECTOR TECNICO
La invention se refiere a un procedimiento y un sistema adaptados para autenticar a un usuario que posee un dispositivo movil en una entidad, en particular en un banco.
ANTECEDENTES DE LA TECNICA
En la actualidad, el volumen de transacciones bancarias en llnea esta aumentando extraordinariamente. El numero de fraudes relacionados con datos de tarjetas bancarias tambien esta aumentando, lo que plantea un serio reto para preservar la integridad de los sistemas de pago en llnea.
Estos fenomenos generan una gran demanda para la mejora continua de sistemas de pago y otros sistemas que requieren autenticacion de usuario de alto nivel. Por lo tanto, la tecnica anterior contiene diversas soluciones para mejorar la seguridad de dichos sistemas.
En el documento US 2011/0270751 A1 se da a conocer un sistema y un procedimiento de autenticacion para autenticacion de dos factores. El sistema segun el documento comprende un servidor de provision de servicios, un terminal adaptado para utilizar el servidor, un dispositivo movil, y, de forma opcional, un servidor, adaptado para almacenar varios datos de identification, que se conecta tanto al dispositivo movil como al servidor de provision de servicios. Segun el documento US 2011/0270751 A1 el codigo QR que se muestra en el terminal y se escanea por medio del dispositivo movil comprende un denominado identificador de la transaction o ID de sesion, as! como la direction del servidor de provision de servicios. La denominada "petition de autenticacion" que se muestra en el codigo QR, puede ser recibida por el usuario mediante capturar una imagen de la pantalla del terminal utilizando la camara del dispositivo movil, o en un mensaje de correo electronico. Para conseguir la identificacion mediante el servidor de provision de servicios, el dispositivo movil pasa datos de identificacion al servidor de provision de servicios directamente o desde el servidor que almacena datos de identificacion.
En el documento US 2012/0240204 A1 se da a conocer un sistema para autenticar a un usuario en el que el usuario recibe los datos necesarios para la autenticacion por medio del escaneo de un codigo QR, u otro codigo de barras apropiado, con su dispositivo movil desde un terminal conectado a un servidor de provision de servicios, en el que el servidor de provision de servicios utiliza asimismo los datos recibidos del usuario para generar el codigo QR. Los datos son enviados al dispositivo movil de forma cifrada y son descodificados por el dispositivo. El usuario utiliza estos datos para la autenticacion en el servidor de autenticacion conectado al servidor de provision de servicios. El servidor de autenticacion verifica los datos recibidos aplicando una base de datos de datos de identificacion, y, dependiendo del resultado de la verification, autentica o rechaza al usuario.
En el documento US 2012/0166309 A1 se da a conocer un sistema en el que se utiliza un terminal y un dispositivo movil para transacciones bancarias. El terminal y el dispositivo movil se comunican utilizando codigos de barras, por ejemplo, codigos QR. La solution dada a conocer en el documento US 2012/0166309 A tiene la desventaja de que no se aplica comunicacion de datos cifrados para transferir datos, y que en los codigos QR se incluyen datos confidenciales. Por consiguiente, el codigo QR incluye los datos de la transaccion (numero de tarjeta, importe a transferir, numero de cuenta, etc.) en cada ocasion. Dado que cualquiera que use una aplicacion apropiada puede leer los codigos QR, los datos confidenciales incluidos en los mismos tambien son accesibles para cualquiera.
Segun el documento US 2012/0166309 A1, los datos a confirmar (que constituyen information confidencial) se transfieren por medio de la pantalla de un primer dispositivo a un segundo dispositivo (por ejemplo, a un dispositivo movil desde un terminal), lo que significa que se pueden pasar datos falsos al segundo dispositivo en caso de que el primer dispositivo se vea comprometido. Si el usuario tiene prisa, confirmando de forma rutinaria la transaccion en el dispositivo movil, puede confirmar a ciegas el proceso en el que estan implicados los datos falsos. Sin comunicacion de datos cifrados se puede acceder a y obtener toda la informacion confidencial sobre la red, y la informacion puede utilizarse posteriormente para fraudes (por ejemplo, para cometer un fraude CNP (tarjeta no presente, Card Not Present)) sin conocimiento del usuario.
Una grave desventaja de las soluciones citadas anteriormente es que implican la transferencia de datos confidenciales (aunque a veces en forma cifrada) entre los componentes individuales del sistema de autenticacion. Por lo tanto es posible que los datos sean capturados en la red por un atacante, que puede a continuation falsificar los datos capturados.
Se describe un proveedor de firmas conectado a un dispositivo movil y a un proveedor de servicios en el documento titulado "3.2 Using mobile devices for digital signatures" ("3.2 Utilization de dispositivos moviles para firmas digitales") por Zoltan Faigl, Sandor Imre, and Balazs Budai (Az m-kormanyzat biztonsagi kerdesei es leheto'segei, Hlradastechnika, vol. LX., no. 3, pag. 30-31, 2005.) Segun el documento, la clave de firma y el algoritmo son
5
10
15
20
25
30
35
40
45
50
55
60
65
almacenados por el proveedor de firmas, y el propio dispositivo movil se identifica en el proveedor de firmas, por ejemplo utilizando un codigo PIN.
Se dan a conocer sistemas de autenticacion basados en el escaneo de codigos QR en los documentos US 2012/0005076 A1, US 2012/0066501 A1 y US 2012/0203646 A1. Segun el documento US 2012/0066501 A1 el sistema se compone de un dispositivo movil adaptado para escanear un codigo QR, un terminal y un sistema de provision de servicios, la autenticacion basada en codigos QR se aplica en un sistema para firmas digitales segun el documento US 2012/0203646 A1. En el documento US 2012/0116972 A1 se da a conocer un sistema de pago electronico que comprende un sistema de gestion de firmas.
En el documento US 2007/0130463 se da a conocer un sistema de autenticacion que, ademas del dispositivo movil y el sistema de provision de servicios, comprende un denominado "sistema de autenticacion y claves" capaz por ejemplo de sincronizar claves. En los documentos US 2011/0296191 A1 y US 2011/0314371 A1 se dan a conocer sistemas que permiten la firma digital mediante multiples partes. Asimismo, en los documentos WO 2005/067402 A2, WO 2009/080999 A2 y US 2011/219427 A1 se dan a conocer sistemas para firma digital. En el documento WO 2010/056969 A2 se da a conocer un sistema que utiliza mensajes cortos (SMS) para transacciones en llnea. Se describe una utilizacion a modo de ejemplo del protocolo MQTT en J. M. Robinson, J. G. Frey, A. J. Stanford-Clark, A. D. Reynolds, B. V. Bedi: Sensor Networks and Grid Middleware for Laboratory Monitoring (Redes de sensores y software intermedio de red para monitorizacion de laboratorios), actas de la primera conferencia internacional de ciencia virtual y computation de red (e-Science'05), Computer Society, IEEE.
En vista de las soluciones conocidas, existe una demanda para la mejora de procedimientos y sistemas de autenticacion conocidos, con el fin de aumentar la protection y seguridad de dichos procedimientos y sistemas.
DESCRIPCION DE LA INVENCION
El objetivo principal de la invention es proporcionar un procedimiento, segun la reivindicacion 1, y un sistema, segun la reivindicacion 13, que carezcan de las desventajas de las soluciones de la tecnica anterior en el mayor grado posible.
Un objetivo adicional de la invencion es proporcionar un procedimiento y un sistema que puedan autenticar a un usuario con mayor seguridad, y de proteger los datos confidenciales en mayor medida en comparacion con soluciones conocidas.
Segun la invencion, los inventores han reconocido la ventaja del hecho de que los dispositivos moviles disponibles comercialmente son capaces de ejecutar aplicaciones (por ejemplo, navegadores) que permiten al dispositivo movil llevar a cabo una autenticacion basada en certificados por ejemplo, de tipo X.509. Por lo tanto es posible aplicar la tecnologla PKI (infraestructura de claves publicas, Public Key Infraestructure) para iniciar sesion de forma segura en paginas web que requieren autenticacion bidireccional (preferentemente de tipo SSL (Secure Sockets Layer, capa de conexiones seguras)), en las que el dispositivo movil y la pagina web se identifican mutuamente utilizando sus certificados X.509 respectivos. PKI es una tecnologla criptografica que permite la comunicacion segura sobre redes publicas no seguras y proporciona identification de usuario fiable. Tal como se define mediante el protocolo de criptografla de SSL, se deberlan aplicar certificados de clave publica que cumplan el estandar X.509, para cifrar las claves simetricas utilizadas durante el establecimiento del canal SSL; los certificados basados en otros estandares no se pueden aplicar.
Basandose en la posibilidad de realizar la autenticacion utilizando los denominados dispositivos moviles inteligentes por medio de estos certificados, el procedimiento y el sistema segun la presente invencion ofrecen soluciones que hacen mas economicos, mas seguros y mas eficientes los procesos empresariales que requieren autenticacion de dos factores. El sistema y el procedimiento segun la invencion ofrecen asimismo una solution para la firma digital autentica de contratos en llnea, utilizando el dispositivo movil de la parte firmante de una manera directa o indirecta para autorizar los documentos.
Por medio del procedimiento y el sistema segun la invencion, aplicando un proceso de autenticacion basado en certificados residentes en dispositivos moviles, se puede implementar una autenticacion basada en PKI muy potente, que es una de las soluciones de autenticacion mas seguras y mas eficientes de hoy en dla.
Segun la invencion se puede conseguir el nivel maximo de seguridad cuando la clave privada perteneciente al certificado residente en el dispositivo movil existe solamente en una unica instancia, es decir, se genera preferentemente en el propio dispositivo movil. La forma en que se generan y gestionan las claves es muy importante para el nivel de seguridad alcanzable mediante procesos basados en claves. Los dispositivos que ejecutan ioS (sistema operativo de iPhone) tienen una herramienta integrada, el SCEP (protocolo de inscription de certificados simple), que es perfectamente capaz de generar claves, y de enviar las peticiones de certificados al proveedor de certification autenticado utilizando una contrasena negociada previamente. Para conseguir el maximo nivel de seguridad posible, las funciones del SCEP se deben implementar preferentemente en plataformas moviles que ejecuten otros sistemas operativos.
5
10
15
20
25
30
35
40
45
50
55
60
65
En el procedimiento y el sistema, segun la invencion, un certificado de autenticacion (preferentemente de tipo X.509) emitido por un proveedor de certificacion registrado al propietario del dispositivo movil esta disponible en el dispositivo movil, perteneciendo la clave privada al certificado que se ha generado preferentemente en el propio dispositivo movil.
El procedimiento y el sistema, segun la invencion, se basan en la autenticacion aplicando certificados residentes en los dispositivos moviles. La autenticacion se lleva a cabo aplicando el protocolo de transferencia de datos HTTP, preferentemente por medio de un canal SSL. Las caracterlsticas del protocolo SSL estan reguladas mediante el estandar RFC 6l0l.
La solucion, segun la invencion, reduce de forma significativa la posibilidad de fraudes en llnea, y reduce los riesgos de la utilization no autorizada de tarjetas bancarias. La utilization de dispositivos moviles inteligentes de la manera especificada por la invencion reduce los costes de los procedimientos existentes de autenticacion de dos factores (SMS, autentificador). La aplicacion del procedimiento y el sistema, segun la invencion, alivia la desconfianza de los usuarios hacia la banca en llnea, y disminuye de forma significativa las perdidas financieras derivadas de los fraudes.
Dado que la solucion, segun la invencion, no implica en modo alguno la manipulation y el almacenamiento de datos de tarjetas bancarias durante el proceso de autenticacion de transacciones (de tarjetas) bancarias en llnea, el estandar de la industria PCI DSS (estandar de seguridad de datos para la industria de tarjetas de pago) no es relevante para la misma. Sin embargo, la solucion, segun la invencion, cumple los requisitos de seguridad bancarios determinados en PCI DSS.
Los objetivos de la invencion se pueden conseguir mediante el procedimiento segun la reivindicacion 1 y el sistema segun la reivindicacion 13. Se definen realizaciones preferentes de la invencion en las reivindicaciones dependientes.
BREVE DESCRIPCION DE LOS DIBUJOS
Se describen a continuation realizaciones preferentes de la invencion a modo de ejemplo, haciendo referencia a los siguientes dibujos, en los que
la figura 1 es un diagrama de bloques que muestra una realization del procedimiento y el sistema, segun la invencion,
la figura 2 es un diagrama de bloques que muestra otra realizacion del procedimiento y el sistema, segun la invencion,
la figura 3 es un diagrama de bloques de otra realizacion mas del procedimiento y el sistema, segun la invencion, y la figura 4 muestra los componentes de la realizacion del procedimiento y el sistema mostrados en la figura 3. MODOS PARA LLEVAR A CABO LA INVENCION
Los dibujos adjuntos muestran componentes tanto del procedimiento como del sistema, segun la invencion. En lo que sigue, se describira en primer lugar el procedimiento segun la invencion, haciendo referencia a algunos componentes del sistema. El sistema, segun la invencion, se describira asimismo en una section posterior.
La figura 1 muestra una realizacion del procedimiento, segun la invencion, por medio de un diagrama de bloques. El procedimiento, segun la invencion, esta adaptado para autenticar a un usuario -10- en una entidad -16-. En el contexto de la presente memoria descriptiva, el termino "entidad" se utiliza para hacer referencia a una empresa, organization, institution financiera, estado, o individuo. Tal como se mostrara mas adelante en relation con las realizaciones, la autenticacion puede tener muchos objetivos. La autenticacion puede requerirse para confirmar un inicio de sesion del usuario en una entidad, para autorizar una transaction bancaria, o para identificar a un usuario para generar una firma digital. Por supuesto, el procedimiento de autenticacion segun la invencion puede aplicarse para otros objetivos.
En el transcurso del procedimiento segun la invencion, un contacto del usuario -10- realizado en un navegador de un terminal -12- es detectado por medio de un modulo de contacto -20- de la entidad -16- (un modulo que permite ponerse en contacto con la entidad -16-), y una direction de red del modulo de autenticacion -24- de la entidad -16- se envla por medio del modulo de contacto -20- a un dispositivo movil -14- del usuario -10- en un mensaje de autenticacion. Basandose en la direccion de red, el dispositivo movil -14- es capaz de ponerse en contacto con el modulo de autenticacion -24-. Dado que el dispositivo movil -14- se asigna a un usuario especlfico, la entidad -16- puede enviar el mensaje de autenticacion al usuario dado -10-.
5
10
15
20
25
30
35
40
45
50
55
60
65
El dispositivo movil -14- es preferentemente un dispositivo movil inteligente, por ejemplo un telefono inteligente o una tableta. Un certificado, emitido por un proveedor -18- de certificacion aceptado por la entidad -16- esta disponible en el dispositivo movil -14-. El certificado tiene una clave privada de usuario de una longitud, por lo menos, de 1024 bits, preferentemente una longitud de 2048 bits, e identifica inequlvocamente al usuario -10-. La clave privada se genera preferentemente en el dispositivo movil -14-, lo que implica que no existe ninguna copia de la clave.
Despues de que el mensaje de autenticacion ha sido enviado, se ejecutan las siguientes etapas en el procedimiento segun la invencion. La aceptabilidad de un certificado de entidad del modulo de autenticacion -24- se verifica por medio del dispositivo movil -14- basandose en la direccion de red, y la aceptabilidad de un certificado de usuario del dispositivo movil -14- se verifica por medio del modulo de autenticacion -24-, y en caso de que el certificado de entidad y el certificado de usuario sean aceptables, el usuario -10- se autentica en la entidad -16- estableciendo un canal de comunicacion entre el dispositivo movil -14- y el modulo de autenticacion -24-, mientras que en caso de que el certificado de entidad o el certificado de usuario no sean aceptables, el usuario -10- es rechazado en la entidad -16-.
En la realizacion del procedimiento, segun la invencion, que se muestra en la figura 1, la etapa de verificar la
aceptabilidad del certificado de entidad comprende verificar por medio del dispositivo movil -14- la validez del
certificado de entidad en un proveedor de certificacion de entidad, y la fiabilidad del proveedor de certificacion de entidad se verifica por medio del dispositivo movil -14-. En caso de que el certificado del modulo de autenticacion -24- se haya emitido por un proveedor de certificacion que el dispositivo movil -14- considera "no fiable", el dispositivo movil -14- interrumpe el contacto con el modulo de autenticacion -24-. En esta realizacion del
procedimiento, la etapa de verificar la aceptabilidad del certificado de usuario comprende verificar por medio del
modulo de autenticacion -24- la validez del certificado de usuario en el proveedor de certificacion de usuario, y la fiabilidad del proveedor de certificacion de usuario. En la realizacion, segun la figura 1, tanto el proveedor de certificacion de usuario como el proveedor de certificacion de entidad estan implementados como el proveedor -18- de certificacion. En la realizacion de la figura 1, el modulo de autenticacion -24- y el proveedor -18- de certificacion se conectan mediante un canal de comunicacion -116- que, a modo de ejemplo, se implementa mediante internet. No es necesario que los certificados del dispositivo movil -14- y el modulo de autenticacion -24- esten emitidos por el mismo proveedor de certificacion. En caso de que el proveedor de certificacion de usuario sea diferente del proveedor de certificacion de entidad, a continuacion el dispositivo movil -14- y el modulo de autenticacion -24- comprueban mutuamente la fiabilidad del proveedor de certificacion del otro.
En la realizacion mostrada en la figura 1, el proveedor de certificacion de entidad corresponde a la clave privada de la entidad del modulo de autenticacion -24-, y el certificado de entidad es firmado por el proveedor de certificacion de entidad, el proveedor de certificacion de usuario corresponde a la clave privada del usuario del dispositivo movil -14-, y el certificado de usuario es firmado por el proveedor de certificacion de usuario.
En caso de que tanto el certificado de entidad como el certificado de usuario sean aceptables, se establece una conexion bidireccional basada en certificados, preferentemente un canal de comunicacion de tipo SSL bidireccional, entre el dispositivo movil y el modulo de autenticacion. Antes de establecer el canal de comunicacion, los certificados se verifican mutuamente (comprobacion de fiabilidad y revocacion utilizando los protocolos OCSP (protocolo de estado de certificados en llnea) o CRL (lista de revocacion de certificados)), a lo que sigue una denominada operacion de mutuo acuerdo. Entre el dispositivo movil y el modulo de autenticacion no tiene lugar ningun intercambio de datos relacionado con datos confidenciales antes de verificar los certificados.
Habitualmente se crea un canal de comunicacion SSL unidireccional entre el terminal -12- y el modulo de contacto -20-, lo que significa que solo el modulo de contacto -20- se identifica en el dispositivo movil -14- con su certificado cuando se establece el canal. La razon por la que el modulo de contacto -20- y el modulo de autenticacion -24- no estan combinados en un unico modulo, segun la invencion, es que un unico modulo dado -es decir, la pagina web correspondiente al modulo- es capaz de establecer una conexion (canal de comunicacion) SSL unidireccional o bien bidireccional. Dado que los modulos conocidos (paginas web) que requieren autenticacion establecen una conexion SSL unidireccional con el usuario, -lo que implica que no se requiere que los usuarios se autentiquen por si mismos utilizando un certificado de usuario, ya que esto harla imposible utilizar un PC o terminal arbitrario para realizar las tareas diarias-, la manera mas conveniente de extender las soluciones existentes es implementar una autenticacion basada en certificados utilizando un modulo independiente, el modulo de autenticacion, que se integra en sistemas conocidos. Al contrario de los terminales utilizados para realizar tareas administrativas diarias, el dispositivo movil del usuario es un dispositivo de utilizacion privada, y por lo tanto el certificado que se puede asignar a este se puede aplicar para una autenticacion SSL bidireccional.
Se crea una conexion SSL unidireccional cuando se establece una conexion HTTPS entre un cliente (navegador) y un servidor web, se requiere que solo el servidor web debe identificarse utilizando su certificado, que es preferentemente un certificado de servidor web SSL de tipo X.509 de clave publica emitido al propio dominio del servidor web, y se firma preferentemente mediante un proveedor de certificacion fiable por ambas partes. El cliente se conectara al servidor web solo si el certificado del servidor web se puede atribuir a un certificado del proveedor de certificacion fiable, y el certificado del servidor web es valido (no ha caducado, no se ha revocado ni se ha suspendido).
5
10
15
20
25
30
35
40
45
50
55
60
65
Se crea una conexion SSL bidireccional cuando se establece una conexion HTTPS entre un cliente (navegador) y un servidor web, se requiere que ambas partes (cliente y servidor web) se identifiquen utilizando sus propios certificados, que son preferentemente certificados de servidor web, as! como certificados X.509 de clave publica. El cliente se conectara al servidor web solo si el certificado del servidor web se puede atribuir a un certificado de un proveedor de certificacion fiable, y el certificado del servidor web es valido (no ha caducado, no se ha revocado ni se ha suspendido). Asimismo, el servidor web solo permite al cliente conectarse si el certificado de autenticacion del cliente ha sido emitido por una parte fiable, y es valido (no ha caducado, no se ha revocado ni se ha suspendido).
Segun la invencion, la conexion entre el dispositivo movil -14- y el modulo de autenticacion -24- se crea solamente despues de que los certificados del dispositivo movil -14- y el modulo de autenticacion -24- se han verificado mutuamente. Segun soluciones de la tecnica anterior, la creacion del canal de comunicacion requiere como mucho la verificacion del certificado del modulo de autenticacion correspondiente mediante el dispositivo movil. Sin embargo, para establecer un canal de comunicacion suficientemente seguro entre el dispositivo movil y el modulo de autenticacion no es suficiente verificar la fiabilidad del servidor de autenticacion mediante el dispositivo movil. Ademas de eso, tambien se debe verificar la fiabilidad del cliente mediante el servidor de autenticacion. Hasta hace poco, los dispositivos moviles en funcionamiento no estaban preparados para esta verificacion, es decir, los dispositivos moviles no admitlan conexiones basadas en certificados. Tal como se ha mencionado anteriormente, los dispositivos que ejecutan iOS soportan la utilizacion de certificados, pero en dispositivos moviles que ejecutan otros sistemas operativos, tales como Android, es necesario instalar una aplicacion dedicada. La solucion que actualmente esta mas extendida en el mundo de la banca implica la utilizacion de contrasenas de una solo utilizacion.
Segun el documento US 2012/0240204 A1, el canal de comunicacion entre el dispositivo movil y el servidor de autenticacion se establece despues de que el servidor de autenticacion ha sido verificado por el cliente. Despues de eso, los datos de autorizacion reales que otorgan el permiso al usuario se intercambian a traves del canal, y estos datos se aplican para identificar al cliente y para confirmar la transaccion.
Frente a esto, en el procedimiento segun la invencion, la autenticacion se lleva a cabo como una consecuencia del establecimiento del canal de comunicacion, es decir, el proceso de establecimiento del canal de comunicacion comprende la autenticacion.
El procedimiento de autenticacion, segun la invencion, es mas ventajoso que la solucion de la tecnica anterior segun el documento US 2012/0240204 A1, ya que la solucion descrita en el mismo no incluye la verificacion del cliente mediante el servidor de autenticacion del banco antes de que se establezca el canal de comunicacion. Esta deficiencia de la solucion, segun el documento US 2012/0240204 A1, puede ser explotada por un atacante como sigue.
Al tomar el control del PC del cliente, o introduciendose a traves de la red entre el PC y el servidor del proveedor de servicios (que es equivalente al modulo de contacto de la invencion), segun el documento, un atacante puede sustituir el URL (localizador uniforme de recursos), es decir, la direccion de red del servidor de autenticacion que tiene un certificado SSL valido y fiable que esta comprendido en el codigo QR, por su propia direccion de red que puede parecerse en gran medida al URL real del servidor de autenticacion. Por lo tanto, segun la solucion descrita en el documento, el dispositivo movil considerara el servidor de autenticacion falso (el servidor del atacante) como fiable, ya que puede tener un certificado valido (cualquiera puede obtener un certificado SSL para su propio dominio). Despues de establecer satisfactoriamente el canal de comunicacion HTTPS unidireccional con el servidor falso, el cliente envla los datos de autorizacion (OTP, PIN, datos firmados con clave, etc.) al servidor del atacante. El atacante puede establecer a continuacion la conexion SSL unidireccional con el servidor de autenticacion real, y puede enviar los datos de autorizacion especificados por el cliente, aprovechandose por lo tanto de los mismos.
Por el contrario, en el procedimiento segun la invencion, el dispositivo movil -14- tambien tiene que presentar un certificado valido al modulo de autenticacion -24- para que se establezca el canal de comunicacion. Es decir, se tiene que establecer una conexion SSL bidireccional entre el dispositivo movil y el modulo de autenticacion, que impide el ataque "de intermediario" descrito anteriormente como sigue. En caso de que, de la manera descrita anteriormente, el atacante envle una direccion de red falsa al dispositivo movil -14- en un mensaje de autenticacion como la direccion de red del modulo de autenticacion, acepta del dispositivo movil los certificados de autenticacion emitidos por el mismo proveedor de certificacion fiable, por ejemplo para establecer una conexion, por ejemplo, un canal de comunicacion HTTPS, y el atacante puede obtener los datos de autorizacion indirectos del usuario despues de que se ha establecido el canal del comunicacion. Sin embargo, el atacante no puede aprovecharse de los datos de autorizacion obtenidos, dado que no se puede conectar al modulo de autenticacion real suplantando al usuario (es decir, utilizando la clave privada del usuario y el certificado almacenado en el dispositivo movil), puesto que no posee la clave privada del usuario.
Por lo tanto, en el proceso descrito en el documento US 2012/0240204 A1 es suficiente sabotear un PC, por ejemplo un terminal (que puede estar situado, por ejemplo, en un cibercafe) para que un atacante adquiera la capacidad de atacar de forma relativamente facil el proceso de autorizacion. Sin embargo, en la solucion segun la invencion, el atacante no puede aprovecharse de los datos obtenidos en caso de que solo se vea comprometida una de las
5
10
15
20
25
30
35
40
45
50
55
60
65
partes.
En la realization mostrada en la figura 1, se inicia un contacto de inicio de sesion en el modulo de contacto -20- a traves de un canal de comunicacion -100-, y de este modo el terminal -12- muestra una interfaz de inicio de sesion de la entidad -16-. El canal de comunicacion -100- se puede establecer por ejemplo utilizando una red de internet.
En el procedimiento segun la invention, tanto el terminal -12- como el dispositivo movil -14- se conectan a internet de uno u otro modo (Wi-Fi, 3G, GPRS, etc.). Los procedimientos (servicios de entidad), segun las realizaciones de la invencion, se pueden llevar a cabo de tal modo que los usuarios y clientes accedan a modulos individuales de la entidad -16- sobre internet.
Segun la presente realizacion, el usuario -10- (que posee un dispositivo movil -14-) inicia sesion en primer lugar utilizando el navegador del terminal -12- en una pagina web principal de la entidad -16- (es decir, en el modulo de contacto -20-) que requiere una autenticacion sencilla basada en nombre/contrasena de inicio de sesion utilizando una conexion -preferentemente unidireccional- que utiliza el protocolo de transferencia de datos HTTPS.
Tras la autenticacion satisfactoria basada en nombre/contrasena de inicio de sesion la entidad -16- todavla no concede al usuario -10- acceso al modulo de contacto -20-. En lugar de ello, la entidad -16- devuelve la direction de red, es decir, el URL del modulo de autenticacion -24-. Por consiguiente, tanto el modulo de contacto -20- como el modulo de autenticacion -24- se pueden implementar como una pagina web respectiva. El usuario abre a continuation la pagina en la direccion de red del modulo de autenticacion -24- utilizando su dispositivo movil -14-. La conexion al modulo de autenticacion -24- requiere una clave privada -por ejemplo, de tipo RSA- y un certificado de autenticacion correspondiente -por ejemplo, de tipo X.509- emitido a nombre del usuario. Tanto la clave privada como el certificado se almacenan en el dispositivo movil. Tal como se presenta a continuacion, el enlace enviado por el modulo de contacto -20- comprende la direccion de red del modulo de autenticacion -24- (el URL de la pagina web del mismo:
https://<sitioweb-secundario>), y preferentemente el valor del identificador de la transaction perteneciente al inicio de sesion basado en nombre/contrasena de inicio de sesion realizado utilizando el modulo de contacto.
Por lo tanto, el URL requerido para autorizar la autenticacion se construye como:
https://<sitio-web-secundario>/?idtr=f(idtr)
donde
- f es una clave simetrica del banco/organizacion
- idtr es un identificador de la transaccion, y
- f(idtr) es el idtr cifrado utilizando f.
El cifrado del identificador de la transaccion se hace necesario solo en caso de que tambien se prevea ocultar el identificador de la transaccion (que puede ser un numero aleatorio).
El URL puede ser transferido al dispositivo movil -14- de maneras diferentes segun un ejemplo que no forma parte de la invencion. Por lo tanto, el URL se puede integrar en un mensaje de autenticacion como sigue.
Segun un ejemplo, el mensaje de autenticacion puede ser un codigo QR, en cuyo caso la direccion de red se envla al dispositivo movil -14- llevando a cabo las siguientes etapas: despues de que se ha especificado el par nombre de usuario/contrasena, el URL del modulo de autenticacion de la entidad -16- que esta solicitando la autenticacion basada en certificados del cliente SSL, as! como el identificador de la transaccion actual, se ponen a disposition del usuario mediante el modulo de contacto -20- en un codigo QR mostrado en la pantalla del terminal -12-. Por lo tanto, el codigo QR se pasa al terminal -12- mediante el modulo de contacto -20-; y a continuacion el codigo se muestra en la pantalla del terminal y se captura mediante el dispositivo de formation de imagenes del dispositivo movil -14-, y, por lo tanto, se transfiere al dispositivo movil -14-. De este modo, el mensaje de autenticacion es enviado al dispositivo movil -14- mediante el modulo de contacto -20-. Segun la figura 1, el codigo QR se envla al terminal -12- a traves de un canal de comunicacion -102-, por ejemplo sobre internet, y se transfiere a continuacion utilizando un canal de comunicacion -104-, es decir, tal como se ha descrito anteriormente, sacando una fotografla del codigo QR.
El mensaje del modulo de contacto -20- llega al dispositivo movil -14- como un mensaje de tipo MQ (Message Queue, cola de mensajes), preferentemente de tipo MQ-TT (transporte de telemetrla MQ). Las colas de mensajes implementan un protocolo de comunicacion aslncrono, lo que significa que el emisor y el receptor del mensaje no tienen que conectarse necesariamente a la cola de mensajes simultaneamente. El mensaje es enviado por el emisor a la cola de mensajes, donde se almacena y espera para la entrega hasta que el receptor lo recibe desde la cola de mensajes. Los mensajes recibidos mediante la cola de mensajes pueden estar limitados en tamano, y el tiempo de almacenamiento de un mensaje dado en la cola tambien puede estar limitado. Hay multiples tipos de protocolos MQ
5
10
15
20
25
30
35
40
45
50
55
60
65
(por ejemplo, AMQP, MQTT, STOMP), teniendo todos una serie de implementaciones diferentes (tales como IBM webSphere MQ, Apache ActiveMQ, RabbitMQ), pero la funcionalidad basica, en otras palabras, el almacenamiento de mensajes en una cola de entrega, es la misma.
MQTT es un denominado protocolo "peso pluma". Sus caracterlsticas mas importantes son que se puede implementar utilizando una cantidad minima de codigo y que tiene una demanda de ancho de banda extremadamente baja. Estas caracterlsticas lo hacen ideal para la comunicacion continua con dispositivos moviles.
El protocolo MQTT es utilizado por plataformas de mensajerla para comunicarse con servidores y recibir mensajes de los mismos, pero se aplica asimismo en marcapasos para la monitorizacion remota de la circulacion y la actividad cardlaca, para la monitorizacion y control de oleoductos, y para la monitorizacion automatizada del nivel de los rlos. El protocolo MQTT funciona asimismo sobre un canal SSL cifrado.
En ese caso, el dispositivo movil inteligente aplica una aplicacion de cliente apropiada para conectarse -por medio de un protocolo MQ implementado utilizando canales de comunicacion de direcciones diferentes -108-, -110- mostrados en la figura 1- a un modulo -26- de cola de mensajes de la entidad -16-. La conexion al modulo -26- de cola de mensajes normalmente se lleva a cabo aplicando alguna clase de autenticacion (tal como una autenticacion basada en nombre de usuario/contrasena). Los servidores utilizados para dar servicio al modulo de contacto -20- y al modulo de autenticacion -24- de la entidad -26- son capaces de enviar mensajes por medio del modulo -26- de cola de mensajes a los dispositivos moviles conectados -14-. La figura 1 muestra los canales de comunicacion bidireccional -106-, -112- utilizados para conectar el modulo de contacto -20- y el modulo -26- de cola de mensajes. En la realizacion mostrada en la figura 1, el modulo de autenticacion -24- es capaz indirectamente de enviar mensajes de tipo cola de mensajes (en lo que sigue: mensajes MQ) a traves del canal de comunicacion -118-.
Una caracterlstica ventajosa de la invencion que aplica mensajes de tipo cola de mensajes como mensajes de autenticacion es que los dispositivos moviles -14- pueden enviar una respuesta firmada de forma electronica (acuse de recibo), firmada con la clave de firma de los mismos, al modulo de contacto -20- despues de que es recibido (o leldo por el cliente) un mensaje de autenticacion enviado por la entidad. Esta solucion contempla que la entidad -16- siempre posee una prueba firmada de forma electronica (firmada utilizando la clave de usuario almacenada en el dispositivo movil) respecto de que el mensaje de autenticacion ha sido enviado. Por lo tanto, la entidad siempre tiene una prueba fehaciente que ayuda a evitar futuras disputas. El envlo automatico de acuses de recibo del mensaje de autenticacion no se resuelve segun soluciones conocidas.
Aplicando el modulo -26- de cola de mensajes, la entidad -16- se puede poner en contacto con los usuarios directamente, sin implicar a una tercera parte en el proceso -siempre que los usuarios inicien sesion en la aplicacion apropiada de la entidad utilizando sus dispositivos moviles. De este modo, puede hacerse necesario que el usuario/cliente envle acuses de recibo para los mensajes enviados por la entidad -16-. La aplicacion de la entidad se puede configurar de tal modo que el dispositivo movil deba enviar un acuse de recibo firmado de forma electronica al servidor de la entidad -16- que prueba de manera irrefutable que el mensaje ha sido recibido.
En un ejemplo que no forma parte de la invencion, el mensaje de autenticacion y el URL del modulo de autenticacion integrado en el mismo, se pueden transferir al dispositivo movil -14- utilizando un SMS (mensaje corto de texto). Los proveedores de servicios de SMS no garantizan el envlo y la entrega inmediata de los mensajes.
En un ejemplo que no forma parte de la invencion, el mensaje de autenticacion se puede transferir asimismo en un denominado "mensaje de envio automatizado". Los proveedores de servicios tampoco garantizan el envio y entrega inmediatos de los mensajes en el caso de los mensajes de envio automatizado. En un ejemplo que no forma parte de la invencion, se pueden utilizar asimismo mensajes de correo electronico para transferir el mensaje de autenticacion.
Se puede concebir asimismo una estructura de emergencia para la mensajeria, que significa que cuando un canal de mensajeria no esta disponible, se sustituira por el canal de mensajerla de preferencia secundaria. Para mostrar la estructura de emergencia, la figura 1 muestra los canales de comunicacion -102-, -104- adaptados para transferir el codigo QR, y tambien los canales de comunicacion -108-, -110-, -106- y -112- adaptados para transferir el mensaje MQ.
Despues de que se recibe el mensaje de autenticacion enviado en un mensaje MQ, el dispositivo movil -14- se conecta a la direccion de red recibida, en otras palabras, a la direccion de red del modulo de autenticacion -24- utilizando su clave privada y el certificado de autenticacion de tipo X.509 correspondiente. Segun la figura 1, esta conexion -la apertura de la direction de red del modulo de autenticacion -24--, se implementa utilizando un canal de comunicacion -114-. El canal de comunicacion -114- puede establecerse por ejemplo utilizando una red internet.
El modulo de autenticacion -24- realiza a continuation una comprobacion de revocation del certificado del cliente en el proveedor -18- de certification utilizando preferentemente OCSP o CRL. En caso de que el certificado perteneciente al dispositivo movil -14- sea invalido (se haya suspendido, revocado, o la comprobacion haya fallado), se devuelve un mensaje de error al dispositivo movil -14- a traves del canal de comunicacion -120-, y al modulo de
5
10
15
20
25
30
35
40
45
50
55
60
65
contacto -20- a traves del canal de comunicacion -118-.
En caso de que la entidad -16- se comunique con el dispositivo movil por medio de una conexion MQ, tambien se puede notificar al dispositivo movil la autenticacion fallida en un mensaje MQ enviado por medio de los canales de comunicacion -106-, -108-.
En caso de que el certificado residente en el dispositivo movil sea valido, y preferentemente si los datos incluidos en el mismo se han aceptado y el identificador de la transaccion indica una autenticacion satisfactoria mediante el modulo de contacto -20-, el modulo de autenticacion -24- envla al dispositivo movil -14- a traves del canal de comunicacion -120- un mensaje que indica una autenticacion satisfactoria. Al igual que el canal de comunicacion -114-, el canal de comunicacion -120- se implementa preferentemente utilizando la red internet. En caso de que la entidad -16- se comunique con el dispositivo movil -14- por medio de una conexion MQ, se notifica asimismo al dispositivo movil la autenticacion satisfactoria en un mensaje MQ. Como una ultima etapa despues de la autenticacion satisfactoria, el usuario inicia sesion mediante el modulo de contacto -20- de la entidad -16-.
La figura 1 puede mostrar asimismo una realization de este tipo del procedimiento de autenticacion segun la invention en el que es necesaria la autenticacion del usuario para aprobar una transaccion (por ejemplo, una transferencia bancaria). La realizacion de la invencion aplicada para esto se describe a continuation.
En un estado inicial de la etapa de aprobacion de la transaccion, el usuario -10- que tiene el dispositivo movil -14- inicia sesion en el modulo de contacto -20- de la entidad -16- en el navegador del terminal -12-. En la presente realizacion, la entidad -16- es preferentemente un banco. Se puede acceder a la interfaz en llnea del modulo de contacto -20- utilizando un canal de comunicacion HTTPS unidireccional. El usuario -10- que ha iniciado sesion, inicia una transaccion (por ejemplo, una transferencia de dinero), y rellena el formulario de la transaccion. En la siguiente pagina, el banco muestra la information sobre la transaccion a aprobar, y el usuario confirma los datos de la transaccion en el navegador de su ordenador.
A continuacion, el banco envla al dispositivo movil -14- la direction de red del modulo de autenticacion en un mensaje de autenticacion, y el usuario abre el mensaje utilizando su dispositivo movil -14-. De manera analoga a lo que se ha descrito anteriormente, se requiere la clave privada y el certificado perteneciente a la misma (almacenados en el dispositivo movil -14-) para conectarse al modulo de autenticacion -24- (la diferencia es que en esta realizacion el objetivo de la autenticacion que solicita el modulo de autenticacion -24- es la aprobacion de la transaccion). Analogamente a lo expuesto anteriormente, el enlace enviado por el modulo de contacto -20- comprende el URL (
https://<sitio-web-secundario>) del modulo de autenticacion -24-, as! como el valor del identificador de la transaccion perteneciente a la transaccion.
No se puede descifrar en absoluto ningun dato confidencial relacionado con la transaccion a partir del enlace enviado al dispositivo movil -14-, ya que este solo comprende el identificador de la transaccion, que incluso se puede cifrar utilizando la clave simetrica del banco.
Tambien en esta realizacion, el mensaje de autenticacion se transfiere al dispositivo movil -14- por medio del canal descrito anteriormente (mensaje MQ).
A continuacion, tambien de una manera similar a la anterior, el dispositivo movil -14- utiliza su clave privada y el certificado perteneciente a la misma para conectarse al modulo de autenticacion -24-, que lleva a cabo a continuacion una comprobacion de revocation en el certificado del cliente. En caso de que el certificado sea invalido (se haya suspendido, revocado, o la comprobacion haya fallado), se devuelve un mensaje de error al dispositivo movil -14- y al modulo de contacto -20-.
En caso de que el certificado sea valido, y preferentemente en caso de que el modulo de contacto -20- haya aceptado la autenticacion basandose en los datos comprendidos en el certificado y en el identificador de la transaccion (idtr), el modulo de autenticacion -24- devuelve al dispositivo movil -14- los datos de la transaccion en la siguiente etapa. En esta fase la transaccion todavla no ha sido aprobada en el dispositivo movil -14-.
En este momento el usuario puede revisar los datos de la transaccion. Segun una realizacion, el banco requiere que el cliente, preferentemente por medio de los modulos de autenticacion -24-, confirme algunos de los datos de la transaccion volviendo a introducirlos (por ejemplo, en caso de una transferencia bancaria, puede ser necesario tener que volver a introducir el importe a transferir y/o el numero de cuenta de destino). Si el cliente omite esta etapa en el dispositivo movil -14-, o introduce datos incorrectos, la transaccion fallara. En esta realizacion del procedimiento segun la invencion, se elimina el problema de la "aprobacion a ciegas", es decir, la posibilidad de que el cliente apruebe los datos de la transaccion sin comprobarlos realmente. El denominado ataque "de intermediario" se puede impedir asimismo aplicando esta realizacion del procedimiento: en caso de que el terminal -12- pase a estar controlado por un atacante, y los datos de la transaccion se falsifiquen utilizando la tecnica "de intermediario", el usuario no puede entonces confirmar ni siquiera accidentalmente la transaccion falsa por medio del enlace de aprobacion enviado por el banco. Este no es el caso para la introduction de contrasenas de una sola utilization enviadas en mensajes SMS, o contrasenas generadas utilizando autentificadores. (En el primer caso, no hay manera
5
10
15
20
25
30
35
40
45
50
55
60
65
de "forzar" al cliente a verificar los datos, dado que la solucion que implica SMS es pasiva).
En caso de que el banco se comunique con el dispositivo movil -14- a traves de una conexion MQ, el dispositivo movil es notificado asimismo de la aprobacion de la transaccion en un mensaje MQ.
En la etapa descrita anteriormente tambien es posible rechazar completamente la transaccion. Cuando se aplica una comunicacion basada en MQ, se envla un mensaje al dispositivo movil -14- que indica que la transaccion ha sido cancelada por el cliente.
En caso de una aprobacion satisfactoria, un rechazo, o si se ha alcanzado el llmite de tiempo para la aprobacion, el modulo de contacto -20- muestra un mensaje en el navegador del terminal -12- en el area de la interfaz de usuario correspondiente al modulo de contacto -20-.
En una realizacion, un usuario -10- solicita un servicio en el modulo de contacto -20- de la entidad -16- por medio del navegador del terminal -12- rellenando un formulario electronico, donde se requiere la firma mutua de un contrato por la entidad -16- y el usuario -10-. El contrato puede prepararse de forma dinamica en el modulo de contacto -20- de la entidad -16- o puede ser un contrato preparado previamente. Utilizando su propia clave de firma, el modulo de contacto -20- de la entidad -16- firma de forma electronica el contrato cumplimentado utilizando los datos introducidos por el usuario (cliente), y opcionalmente le proporciona una marca de tiempo certificada.
A continuacion, en caso de que el usuario -10- haya sido ya autenticado y haya iniciado sesion aplicando el procedimiento, segun la invencion, tal como se ha descrito anteriormente, el certificado de usuario es introducido por la entidad -16- en el documento producido de este modo, donde el certificado de usuario dispone de la clave de firma del usuario, y se obtiene en segundo plano desde el modulo -28- de provision de claves conectado a la entidad -16- utilizando informacion que identifica inequlvocamente al usuario en el modulo -28- de provision de claves. Para conseguir esto, la entidad -16- deberla saber que proveedor de claves proporciona la clave de firma aplicada actualmente del usuario -10- (el usuario -10- puede especificar esto previamente).
Por lo tanto, en esta realizacion se prepara un contrato a firmar por el usuario -10- y la entidad -16- utilizando los datos solicitados al usuario despues del inicio de sesion, y a continuacion el contrato se firma utilizando la clave de firma de la entidad -16- y la clave de firma del usuario -10-, estando esta ultima almacenada en el modulo -28- de provision de claves. La operacion de firma, realizada en el modulo -28- de provision de claves, es aprobada por el usuario -10- aplicando un certificado de autenticacion residente en el dispositivo movil -14-.
La figura 2 muestra una realizacion del procedimiento segun la invencion en la que se requiere la autenticacion llevada a cabo utilizando el procedimiento inventivo para preparar la firma digital del usuario. En esta realizacion la funcion del modulo de autenticacion es desempenada por el modulo -28- de provision de claves.
Segun la figura 2, es posible seleccionar el certificado de firmante del usuario -10- incluso cuando el usuario -10- accede de forma anonima al modulo de provision de claves -20- de la entidad -16- o despues de una autenticacion que no esta basada en certificados. En ese caso, el certificado de firmante es solicitado al modulo de provision de claves -26- no por la entidad -16- sino por el dispositivo movil -14- del usuario -10-.
En esta realizacion el modulo de contacto -20- se aplica para enviar la direccion de red (URL) del modulo -28- de provision de claves al dispositivo movil -14- en un mensaje de autenticacion de tal manera que se pueda realizar la operacion de firma. El parametro de direccion de red comprende la direccion de la entidad -16- donde el modulo de provision de claves -26- debe enviar el certificado de firmante del usuario -10-. A continuacion, el dispositivo movil -14- se redirige al modulo de contacto -20- de la entidad -16-, donde continua la operacion de firma.
La entidad -16- genera a continuacion un resumen criptografico del documento que se ha complementado con su certificado de firmante y preparado para ser firmado por el usuario -10-. El tipo del algoritmo de resumen criptografico aplicado (sha1, sha256, sha384, sha512) se deberla indicar preferentemente al inicio del valor del resumen criptografico generado. Por lo tanto, el documento a firmar que se identifica mediante el resumen criptografico ya comprende el certificado de firmante de la entidad -16-.
En la presente realizacion la funcion del modulo de autenticacion se lleva a cabo por el modulo -28- de provision de claves. Por consiguiente, el enlace a enviar al dispositivo movil -14- en el mensaje de autenticacion es generado por el modulo de contacto -20- como sigue. El enlace comprende la direccion del sitio web del modulo -28- de provision de claves que solicita el certificado de autenticacion (es decir, la direccion de red).
Los siguientes parametros GET se especifican en el URL:
• id: un identificador unico de la entidad -16- que conoce el modulo de provision de claves.
• par: los parametros que se cifran utilizando una clave simetrica (f) conocida por la entidad -16- y por el modulo -28-
5
10
15
20
25
30
35
40
45
50
55
60
65
de provision de claves.
o resumen criptografico: resumen criptografico del documento a firmar o idtr: identificador de la transaccion
o idusuario: un identificador unico del usuario -10-, que es conocido por la entidad -16- y por el modulo -28- de provision de claves, y
o de forma opcional, se pueden especificar asimismo parametros adicionales
https://<direccion del proveedor de claves>/?id=<id>&par=f(par)
Se debe destacar en este caso que los datos confidenciales, tales como el resumen criptografico, son enviados de forma cifrada. Se debe observar que la longitud del enlace generado no puede ser mayor de la que se podrla contener en el mensaje de autenticacion.
De manera similar a lo descrito anteriormente, el modulo de contacto -20- pone a disposicion del usuario -10- el enlace generado (la direccion de red) en un mensaje MQ. En caso de que se apliquen mensajes de tipo cola de mensajes, se utilizan los canales de comunicacion -100-, -102-, -104-, -106-, -108-, -110-, -112- mencionados anteriormente.
El usuario abre (por ejemplo en un navegador u otra aplicacion) el enlace recibido en un mensaje de tipo cola de mensajes. El enlace es recibido por el dispositivo movil en un mensaje MQ, y este envla un acuse de recibo firmado relacionado con el mensaje MQ recibido por medio del modulo -26- de cola de mensajes, utilizando la clave de firma almacenada preferentemente en el dispositivo movil -14-.
El enlace transferido de este modo al dispositivo movil -14- se abre en una aplicacion, habitualmente en un navegador -que admite autenticacion basada en certificados. La pagina web que aparece es la pagina web del modulo -28- de provision de claves que solicita la autenticacion basada en certificados.
A continuacion se lleva a cabo la autenticacion en el dispositivo movil -14- de la manera descrita anteriormente, utilizando un certificado, el modulo -28- de provision de claves, y tambien un canal de comunicacion -126- entre el modulo -28- de provision de claves y el proveedor -18- de certificacion. El modulo -28- de provision de claves realiza por lo tanto una comprobacion de revocacion en el certificado de usuario utilizando OCSP (protocolo de estado de certificados en llnea) o una CRL (lista de revocacion de certificados) en colaboracion con el proveedor -18- de certificacion. En caso de que el certificado sea invalido (se haya suspendido, revocado, o la comprobacion haya fallado), o si es valido pero no existe una clave de firma o una clave de cifrado correspondiente en el modulo -28- de provision de claves, el modulo -28- de provision de claves devuelve un mensaje de error al dispositivo movil -14- y al modulo de contacto -20-.
Si la autenticacion es satisfactoria, es decir, la verification del certificado bidireccional se ha realizado satisfactoriamente, la clave de firma del usuario -10- (almacenada en el modulo de almacenamiento de claves conectado al modulo -28- de provision de claves) es identificada de manera inequlvoca por el modulo de provision de claves -28- aplicando el certificado de usuario. El modulo de almacenamiento de claves se implementa preferentemente como un denominado HSM (modulo de seguridad hardware). En la siguiente etapa el modulo -28- de provision de claves lee de su base de datos la clave o la contrasena de cifrado simetrica que es comun con la entidad -16- utilizando el parametro "id" no cifrado que se envio previamente junto con el enlace, descifra el parametro GET cifrado, y lo utiliza para generar los otros parametros requeridos.
Utilizando la clave almacenada en el modulo HSM especificado y aplicando la autenticacion basada en certificados, el modulo de provision de claves firma el resumen criptografico desciframiento del parametro GET cifrado. A continuacion, el modulo -28- de provision de claves notifica a la entidad -16- especificada en el parametro GET a traves de una conexion HTTPS que posee un resumen criptografico para trasferirle, y que el resumen criptografico ha sido firmado por el usuario -10- de la entidad -16-.
Con el fin de poder recibir los datos firmados por el usuario, la entidad -16- tiene que demostrar al modulo -28- de provision de claves que la propia entidad -16- habla solicitado al usuario -10- que firmase el documento perteneciente al resumen criptografico.
Para ello, envla el resumen criptografico perteneciente al documento dado al modulo -28- de provision de claves incorporado en un documento (archivo txt, etc.) firmado con su propia clave. Es preferible especificar en el documento firmado de este modo la transaccion del usuario a la que pertenece el resumen criptografico dado.
El documento que comprende el resumen criptografico firmado por la entidad -16- es verificado por el modulo -28- de provision de claves. En caso de que se compruebe que la firma es valida y el resumen criptografico comprendido en
5
10
15
20
25
30
35
40
45
50
55
60
65
el documento firmado sea el mismo que el resumen criptografico pasado por el usuario -10- en el parametro GET, se demuestra que la firma del resumen criptografico habia sido solicitada por la entidad -16-, y por lo tanto el resumen criptografico no fue falsificado con esta. A continuacion, el modulo -28- de provision de claves pasa el resumen criptografico firmado por el usuario -10- a la entidad -16-. El resumen criptografico firmado de forma electronica por la entidad -16- es archivado por el modulo de provision de claves como evidencia. Utilizando este documento, en una ocasion posterior el modulo -28- de provision de claves puede probar que firmo utilizando la clave del usuario -10- un resumen criptografico perteneciente a un documento cuya firma se habia solicitado por una tercera parte, la entidad -16-.
A continuacion el usuario -10- es informado de la operation de firma satisfactoria o fallida mediante el modulo de contacto -20- preferentemente tanto por medio del terminal -12- como del modulo -26- de cola de mensajes (si existe un canal de comunicacion de ese tipo entre el banco/organizacion y el dispositivo movil del cliente).
Las etapas llevadas a cabo aplicando la presente realization se pueden resumir como sigue: se detecta un contacto para la firma de un documento por medio del modulo de contacto -20-; se prepara un contrato firmado por la entidad -16- y para firmar por el usuario -10- utilizando datos solicitados al usuario -10-; y se genera un resumen criptografico del contrato. En la presente realizacion, el modulo de autenticacion es el modulo -28- de provision de claves. Segun la presente realizacion, la direction de red del modulo de provision de claves -24- se envia a continuacion al dispositivo movil -14- del usuario -10- en un mensaje de autenticacion por medio del modulo de contacto -20-, y el resumen criptografico cifrado se envia asimismo en el mensaje de autenticacion. A continuacion, en caso de que el canal de comunicacion entre el dispositivo movil -14- y el modulo -28- de provision de claves se establezca satisfactoriamente (es decir, en caso de una autenticacion satisfactoria), el resumen criptografico cifrado y un identificador de la entidad -16- se envian al modulo -28- de provision de claves, la entidad -16- se identifica mediante el modulo -28- de provision de claves y el resumen criptografico cifrado se descifra por medio de la clave asignada a la entidad -16-, y el resumen criptografico se firma a continuacion utilizando la clave del usuario -10- disponible en el modulo -28- de provision de claves, y, verificando con la entidad -16- que el resumen criptografico se recibio desde la entidad -16-, el resumen criptografico se envia desde el modulo -28- de provision de claves a la entidad -16-.
Segun otra realizacion, el proceso de firma tambien se puede llevar a cabo firmando el resumen criptografico utilizando la clave de firma residente en el dispositivo movil inteligente del cliente. En este caso no es necesario un proveedor de claves externo, aunque el modulo de contacto -20- de la entidad -16- sigue siendo responsable de generar el documento a firmar en un formato apropiado apto para firma, de generar el resumen criptografico, y de insertar el resumen criptografico firmado y cerrar el documento cumplimentado.
En esta realizacion, el dispositivo movil -14- comunica con el modulo -28- de provision de claves por medio de canales de comunicacion -122- y -124-; estando dirigido el canal de comunicacion -122- desde el dispositivo movil -14- hacia el modulo -28- de provision de claves, y el canal de comunicacion -124- en el sentido inverso. El modulo -28- de provision de claves se conecta al modulo de contacto -20- por medio de canales de comunicacion -128- y -130-; estando dirigido el canal de comunicacion -128- desde el modulo -28- de provision de claves hacia el modulo de contacto -20-, y el canal de comunicacion -130- en el sentido inverso.
La realizacion detallada anteriormente implementa una funcionalidad de firma digital distribuida que permite tanto al usuario como a la entidad firmar los documentos (por ejemplo, contratos) que poseen. La caracteristica mas importante de un esquema de firma digital distribuido es que la entidad nunca posee la clave de firma privada del cliente que el cliente almaceno bien en un dispositivo movil inteligente o en una tercera parte fiable (en la realizacion descrita anteriormente, el modulo de provision de claves). Durante la operacion de creation de la firma, el documento a firmar es preparado por la entidad en un formato que cumple un estandar de firma digital (por ejemplo, XAdES, PAdES). La propia operacion de firma es realizada no por la entidad sino por el dispositivo movil del usuario, o por una tercera parte fiable (el modulo de provision de claves), despues de la autenticacion utilizando un certificado residente en el dispositivo movil. El dispositivo movil del usuario recibe solamente el resumen criptografico del documento a firmar que es generado por la entidad. El resumen criptografico se firma bien utilizando la clave privada del firmante almacenada en el dispositivo movil, o, despues de pasarla al modulo de provision de claves, utilizando la clave del hardware protegido HSM almacenada en el mismo. Dado que solo recibe el resumen criptografico, el modulo de provision de claves nunca estara en posesion del contenido de los documentos a firmar. El resumen criptografico firmado se devuelve a la entidad bien desde el dispositivo movil o desde el modulo de provision de claves, insertandolo la entidad en el documento sin finalizar que se ha preparado para la firma. La operacion de firma del cliente se completa de este modo, y la entidad puede insertar otras firmas o marcas de tiempo. Para cada etapa del proceso de firma, la entidad solicita una autenticacion basada en certificados a todas las partes. Ademas de proporcionar una identification segura del usuario, la aplicacion de la funcionalidad de firma de la entidad permite llevar a cabo una administration fiable en base a la firma electronica remota.
El procedimiento, segun la invention, se puede aplicar asimismo al desciframiento/descodificacion de documentos. En ese caso la operacion de desciframiento/descodificacion se reduce a una autenticacion realizada con el procedimiento segun la invencion.
En la presente realizacion, el usuario/cliente posee un documento cifrado, que recibio por ejemplo adjunto en un
5
10
15
20
25
30
35
40
45
50
55
60
65
mensaje de correo electronico, o de algun otro modo. En primer lugar, como etapa de contacto del proceso de desciframiento del documento, el usuario pasa (carga) el documento que se tiene que descifrar al modulo de contacto, es decir, por ejemplo, lo envla en un mensaje de correo electronico. A continuacion, el modulo de contacto extrae del documento cifrado cargado la clave simetrica aplicada para cifrar el documento. La clave simetrica ha sido cifrada utilizando el certificado de cifrado del usuario. El enlace que se va a enviar al dispositivo movil del usuario es generado por el modulo de contacto. De manera analoga al caso descrito anteriormente, el modulo de autenticacion es el modulo de provision de claves. El enlace comprende la direccion de red del modulo de autenticacion. Los siguientes parametros GET se especifican en el URL:
• id: un identificador de la entidad
• par: parametros que se cifran utilizando una clave simetrica (f) conocida por la entidad y el proveedor de claves: o clavecifrada: una clave simetrica cifrada utilizando el certificado de usuario
o idtr: un identificador de la transaccion
o idusuario: un identificador unico del usuario (por ejemplo, la direccion de correo)
https://<direccion del proveedor de claves>/?id=<id>&par=f(par)
El modulo de contacto envla el enlace generado al usuario en un mensaje de autenticacion. Abriendo el enlace utilizando su dispositivo movil, el usuario inicia una conexion con el modulo de provision de claves.
La autenticacion se lleva a cabo por medio de una conexion de internet utilizando el certificado de autenticacion residente en el dispositivo movil, as! como el certificado de entidad. En caso de una autenticacion satisfactoria, el modulo de provision de claves utiliza el certificado de usuario para identificar inequlvocamente la clave de desciframiento del usuario, que preferentemente se almacena en un modulo HSM. En la siguiente etapa el modulo de provision de claves lee de su base de datos la clave simetrica o, de forma opcional, la contrasena compartida con la entidad utilizando el parametro "id" no cifrado que identifica al modulo de contacto, descifra el parametro GET cifrado, y lo utiliza para generar los otros parametros requeridos. La clave simetrica cifrada, obtenida del parametro GET cifrado, se descifra utilizando la clave de desciframiento almacenada en el modulo HSM.
La clave simetrica descifrada se envla posteriormente por medio de una conexion HTTPS desde el modulo de provision de claves al modulo de contacto especificado en el parametro GET.
El modulo de contacto utiliza a continuacion la clave simetrica recibida del modulo de provision de claves para descifrar el documento del usuario, y hace que el documento se pueda descargar por medio de un enlace HTTPS. El enlace se envla al usuario bien por medio del terminal o en un mensaje de correo electronico. De este modo, el documento desciframiento se pone a disposicion del usuario.
Se muestra otra realizacion mas de la invencion en la figura 3. Segun esta realizacion la entidad -16- es un banco -25- emisor de tarjetas, y un contacto de un usuario -10- que presenta datos de una tarjeta de credito por medio del terminal -12- en una interfaz de pago de una tienda web, es detectado por medio del modulo de contacto -20- del banco -25- emisor de tarjetas a traves de un servidor -30- de la tienda web, un servidor -32- del proveedor de servicios bancarios de la tienda web, y un servidor -34- de una empresa de tarjetas de credito. En esta realizacion, se aplica un mensaje de tipo cola de mensajes como mensaje de autenticacion. La presente realizacion excluye la aplicacion de codigos QR como mensaje de autenticacion, ya que se aplica el terminal -12- para mostrar la interfaz de pago de la tienda web que no es capaz de mostrar un codigo QR.
Por lo tanto, en esta realizacion el usuario (cliente) -10- que posee el dispositivo movil -14- inicia una transaccion de pago con tarjeta en el navegador del terminal -12-. La informacion de la transaccion del pago con tarjeta introducida por el usuario en la interfaz de la tienda web se pasa por medio del servidor -32- del banco proveedor de servicios bancarios de la tienda web, y el servidor -34- de la empresa de tarjetas de credito, llegando finalmente al banco emisor de la tarjeta -25-.
El banco emisor de la tarjeta -25- verifica los datos relacionados con el pago con tarjeta: se asegura de que la tarjeta existe y tiene fondos, y que no se ha bloqueado. Si la verificacion es positiva, entonces antes de confirmar la transaccion, se envla un mensaje de autenticacion al usuario, notificandole que confirme el pago con tarjeta. El mensaje de autenticacion se puede enviar utilizando el protocolo MQ. En caso de que se envle un mensaje MQ, el dispositivo movil inteligente del titular de la tarjeta debe conectarse al modulo -26- de cola de mensajes del banco emisor de la tarjeta -25-.
El mensaje de autenticacion se aplica para enviar la direccion de red del modulo de autenticacion -24- al dispositivo movil -14-. El URL transferido no comprende ninguna informacion sobre el contenido de la transaccion con tarjeta, solo un identificador de la transaccion compuesto por numeros aleatorios, que puede ser utilizado para leer los datos
5
10
15
20
25
30
35
40
45
50
55
60
65
relacionados con la transaccion con tarjeta en el dispositivo movil -14- solo en caso de una autenticacion satisfactoria basada en certificados.
El URL de autenticacion que se envla en el mensaje de autenticacion y se aplica para confirmar la transaccion se construye como sigue:
https://<sitioweb-secundario>/?idtr=f(idtr)
donde
f es una clave simetrica del banco emisor
idtr es un identificador de la transaccion (tal como el identificador de una transaccion de pago con tarjeta) f(idtr) es el idtr cifrado utilizando f.
Despues de enviar el mensaje de autenticacion el dispositivo movil -14- utiliza su clave privada y el certificado que le pertenece para conectarse al modulo de autenticacion -24- del banco emisor de la tarjeta -25- que solicita la autenticacion basada en certificados, y que puede encontrarse en la ubicacion de red enviada en un mensaje MQ.
De manera similar a lo descrito anteriormente, el modulo de autenticacion -24- del banco emisor de la tarjeta -25- realiza una comprobacion de revocacion en el certificado del cliente (residente en su dispositivo movil -14-) utilizando OC-SP o CRL. Ademas, el dispositivo movil -14- verifica el certificado del modulo de autenticacion -24-. En caso de que el certificado del dispositivo movil sea invalido (se haya suspendido, revocado, o la comprobacion haya fallado), se devuelve un mensaje de error al dispositivo movil inteligente. En caso de que el banco emisor de la tarjeta -25- se comunique con el dispositivo movil del cliente por medio de una conexion MQ, la autenticacion fallida se notifica asimismo al dispositivo movil en un mensaje MQ.
Si la confirmacion falla por algun motivo (debido a un certificado invalido, rechazo, o un llmite de tiempo), el mensaje de rechazo es enviado por el banco emisor al servidor -30- de la tienda web por medio del servidor -34- de la empresa de tarjetas de credito y el servidor -32- del proveedor de servicios bancarios. El resultado de la transaccion de pago con tarjeta aparece en la pantalla de visualization del terminal -12-.
En caso de que la autenticacion sea satisfactoria, y en caso de que los datos comprendidos en el certificado, y -en base al identificador de la transaccion con tarjeta- la autenticacion haya sido aceptada por el modulo de contacto -20- del banco emisor de la tarjeta -25-, el modulo de autenticacion -24- del banco emisor de la tarjeta -25- devuelve los datos de la transaccion con tarjeta al dispositivo movil -14-. En esta etapa la transaccion todavla no se ha aprobado en el dispositivo movil.
Despues de revisar la information relacionada con la transaccion de pago con tarjeta, el cliente puede confirmar o rechazar la transaccion de pago con tarjeta por medio del modulo de autenticacion -24- utilizando el dispositivo movil -14- (por ejemplo, el navegador del mismo).
En caso de que el banco emisor de la tarjeta -25- se comunique con el dispositivo movil por medio de una conexion MQ, tambien se notifica al dispositivo movil en un mensaje mQ la aprobacion satisfactoria de la transaccion, o que la transaccion ha fallado (debido a un rechazo).
El banco emisor de la tarjeta envla un aviso del evento de confirmacion o rechazo de la transaccion de pago con tarjeta del cliente al servidor del comerciante por medio de los sistemas de informacion de la empresa -34- de tarjetas de credito y del banco -32- proveedor de servicios. El resultado de la transaccion de pago con tarjeta aparece en la interfaz de usuario de la tienda web.
Segun la presente realization, en caso de que se establezca un canal de comunicacion entre el dispositivo movil -14- y el modulo de autenticacion -24-, los datos de pago de la tienda web se envlan al dispositivo movil -14-, y se recibe la informacion sobre la autorizacion o rechazo de los datos de pago del usuario -10-.
La realizacion de la figura 3 se muestra asimismo en la figura 4. Segun soluciones de la tecnica anterior el banco emisor de la tarjeta verifica los datos de la tarjeta y el estado de los fondos, y, en caso de una verification positiva, confirma la transaccion sin solicitar una confirmacion del titular de la tarjeta. Debido a la naturaleza del proceso de pago en llnea, en caso de que se vean comprometidos los datos de la tarjeta del cliente, el atacante puede hacer una utilization fraudulenta de la tarjeta sin que el cliente lo advierta, ya que la tarjeta sigue estando en poder del cliente.
El procedimiento de autenticacion segun la invention permite que el cliente confirme el pago utilizando un canal alternativo, disponiendo al mismo tiempo que, de los participantes del proceso de pago con tarjeta, solamente los servidores del banco emisor de la tarjeta -25- y el dispositivo movil del cliente se tienen que involucrar en el proceso de autenticacion. Otros componentes de la cadena no perciben que se esta llevando a cabo un segundo proceso de autenticacion en segundo plano. La cuestion clave es la manera en que el servidor del banco emisor de la tarjeta
5
10
15
20
25
30
35
40
45
50
55
establece la conexion con el dispositivo movil inteligente del cliente despues de que el servidor ha recibido los datos relacionados con la transaccion de pago en linea dada, ya que el Kmite de tiempo para la confirmacion es extremadamente corto. Las tecnicas de mensajeria que implican SMS o mensajes de envio automatizado pueden parecer una solucion obvia, pero ambas tienen las siguientes desventajas:
• Por su naturaleza, estas tecnicas no garantizan que el mensaje se envie inmediatamente, y que el dispositivo movil del cliente lo recibira en un tiempo corto. Ningun proveedor de SMS lo garantiza.
• En ambos casos, se requiere una tercera parte externa (tal como un proveedor de SMS) para transmitir los mensajes, lo que hace que el banco emisor dependa en gran medida de estas partes.
• Ninguna de estas soluciones proporciona ninguna prueba a la parte emisora (el banco emisor de la tarjeta) de que el mensaje solicitando confirmacion de la autorizacion se ha enviado realmente al cliente. Esto puede causar graves dificultades al banco emisor si se produce una disputa.
• La aplicacion de mensajes SMS puede causar importantes costes adicionales de las transacciones.
La invencion en la que el mensaje de autenticacion se transfiere en un mensaje MQ elimina estas desventajas. El banco emisor de la tarjeta -25- puede enviar un mensaje de manera sincrona al dispositivo movil conectado a traves del modulo -26- de cola de mensajes sin implicar a un proveedor de servicios externo. De manera analoga a una transaccion de transferencia bancaria, el mensaje comprende la direccion de red del modulo de autenticacion -24-, incluyendose como un parametro el identificador correspondiente a la transaccion con tarjeta en el mensaje. El mensaje MQ no comprende ningun dato sensible. La transaccion puede ser consultada, confirmada o rechazada en el dispositivo movil solamente despues de una autenticacion satisfactoria. La clave de firma residente en el dispositivo movil se puede aplicar al envio de un acuse de recibo del mensaje MQ recibido del banco emisor de la tarjeta. El acuse de recibo puede ser archivado por el sistema del banco emisor como una prueba de la transaccion.
Ademas de la banca en linea, la solucion segun la presente invencion puede ser aplicada para eliminar completamente los fraudes relacionados con la retirada de efectivo de ATM que son capaces de mostrar codigos QR.
En caso de perdida o robo del dispositivo movil, el proceso de bloqueo del dispositivo es el mismo que el proceso de bloqueo de tarjetas bancarias perdidas/robadas. En cuanto el usuario informa de la perdida o robo de su dispositivo movil, los certificados residentes en el dispositivo se revocan inmediatamente, de tal modo que no se puede confirmar ninguna transaccion adicional usandolos.
La solucion segun la invencion puede acelerar de forma significativa los procesos bancarios para los clientes. Los clientes que poseen dispositivos moviles involucrados en el procedimiento pueden autorizar contratos bancarios en el hogar, utilizando sus firmas digitales. Los certificados de autenticacion instalados en el dispositivo movil se pueden aplicar asimismo para la conexion a redes VPN. La solucion, segun la invencion, admite la confirmacion de transacciones que requieren multiples autorizadores.
Una realizacion de la invencion se refiere a un sistema para autenticar un usuario en una entidad. El sistema segun la invencion comprende un modulo de contacto -20- adaptado para detectar un contacto de un usuario -10- con la entidad -16-, un terminal -12- adaptado para recibir el contacto iniciado por el usuario -10- con el modulo de contacto -20-, un modulo de autenticacion -24- adaptado para autenticar al usuario -10-, y un dispositivo movil -14- adaptado para recibir una direccion de red del modulo de autenticacion -24- en un mensaje de autenticacion desde el modulo de contacto -20-. En el sistema, segun la invencion, el dispositivo movil esta adaptado para verificar la aceptabilidad de un certificado de entidad del modulo de autenticacion -24- en base a la direccion de red, y el modulo de autenticacion -24- esta adaptado para verificar la aceptabilidad de un certificado del dispositivo movil -14-, y en caso de que el certificado de entidad y el certificado de usuario sean aceptables, el usuario -10- es autenticado en la entidad -16- mediante el sistema estableciendo un canal de comunicacion entre el dispositivo movil -14- y el modulo de autenticacion -24-, mientras que en caso de que el certificado de entidad o el certificado de usuario no sean aceptables, el usuario -10- es rechazado en la entidad -16-.
Por supuesto, la invencion no se limita a las realizaciones preferentes descritas en detalle anteriormente, sino que son posibles otras variantes, modificaciones, cambios y desarrollos dentro del alcance de proteccion definido por las reivindicaciones.

Claims (13)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    REIVINDICACIONES
    1. Procedimiento para autenticar a un usuario (10) en una entidad (16), que comprende las etapas de
    - detectar, por medio de un modulo de contacto (20) de la entidad (16), un contacto del usuario (10) realizado en un navegador de un terminal (12), y
    - enviar, por medio del modulo de contacto (20), una direccion de red de un modulo de autenticacion (24) de la entidad (16) a un dispositivo movil (14) del usuario (10) en un mensaje de autenticacion,
    caracterizado por
    - utilizar un mensaje de tipo cola de mensajes como el mensaje de autenticacion, dicho mensaje se envla por medio de un modulo (26) de cola de mensajes correspondiente a la entidad (16), y un acuse de recibo firmado con una clave del usuario (10) se envla desde el dispositivo movil (14) al modulo de contacto (20) despues de que el mensaje de tipo cola de mensajes es recibido por el dispositivo movil (14) que esta conectado al modulo (26) de cola de mensaje,
    - verificar la aceptabilidad de un certificado de entidad del modulo de autenticacion (24) por medio del dispositivo movil (14) en base a la direccion de red, y verificar la aceptabilidad de un certificado de usuario del dispositivo movil (14) por medio del modulo de autenticacion (24), y
    - en caso de que el certificado de entidad y el certificado de usuario sean aceptables, autenticar al usuario (10) en la entidad (16) estableciendo un canal de comunicacion (114, 120, 122, 124) entre el dispositivo movil (14) y el modulo de autenticacion (24), mientras que en caso de que el certificado de entidad o el certificado de usuario no sean aceptables, rechazar al usuario (10) en la entidad (16).
  2. 2. Procedimiento, segun la reivindicacion 1, caracterizado por que
    - la etapa de verificar la aceptabilidad del certificado de entidad comprende verificar por medio del dispositivo movil (14)
    - la validez del certificado de entidad en un proveedor de certificacion de entidad (18), y
    - la fiabilidad del proveedor de certificacion de entidad (18),
    - la etapa de verificar la aceptabilidad del certificado de usuario comprende verificar por medio del modulo de autenticacion (24),
    - la validez del certificado de usuario en el proveedor de certificacion de usuario (18), y
    - la fiabilidad del proveedor de certificacion de usuario (18).
  3. 3. Procedimiento, segun la reivindicacion 2, caracterizado por que
    - el proveedor de certificacion de entidad (18) corresponde a una clave privada de la entidad del modulo de autenticacion (24), y el certificado de entidad es firmado por el proveedor de certificacion de entidad (18), y
    - el proveedor de certificacion de usuario (18) corresponde a una clave privada de usuario del dispositivo movil (14), y el certificado de usuario es firmado por el proveedor de certificacion de usuario (18).
  4. 4. Procedimiento, segun la reivindicacion 3, caracterizado por que la clave privada de usuario se genera en el dispositivo movil (14).
  5. 5. Procedimiento, segun las reivindicaciones 1 a 4, caracterizado por que la entidad (16) es un banco emisor de las tarjetas (25), y un contacto de un usuario (10) mediante el envlo de datos de una tarjeta de credito por medio del terminal (12) en una interfaz de pago de una tienda web se detecta por medio de un modulo de contacto (20) del banco emisor de la tarjeta (25) por medio de un servidor (30) de la tienda web, por medio de un servidor (32) de un proveedor de servicios bancarios de la tienda web, y por medio de un servidor (34) de una empresa de tarjetas de credito.
  6. 6. Procedimiento, segun la reivindicacion 5, caracterizado por que, en caso de que se establezca un canal de comunicacion entre el dispositivo movil (14) y el modulo de autenticacion (24), los datos de pago de la tienda web son enviados al dispositivo movil (14), y se recibe la information sobre la autorizacion o rechazo de los datos de pago por el usuario (10).
    5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
  7. 7. Procedimiento, segun cualquiera de las reivindicaciones 1 a 6, caracterizado por detectar, por medio del modulo de contacto (20), un contacto de inicio de sesion en el terminal (12) que muestra una interfaz de inicio de sesion de la entidad (16), y aceptar el inicio de sesion del usuario (10) en la entidad (16) en caso de que se establezca el canal de comunicacion (114, 120, 122, 124) entre el modulo de autenticacion (24) y el dispositivo movil (14).
  8. 8. Procedimiento, segun la reivindicacion 7, caracterizado por que, despues de que se ha llevado a cabo el inicio de sesion,
    - se prepara un contrato a firmar por el usuario (10) y la entidad (16) utilizando los datos solicitados al usuario (10), y
    - el contrato se firma con una clave de firma de la entidad (16) y con una clave de firma del usuario (10) extralda de un modulo de provision de claves (28).
  9. 9. Procedimiento, segun cualquiera de las reivindicaciones 1 a 6, caracterizado por que
    - se detecta un contacto para una firma de un documento por medio del modulo de contacto (20),
    - se prepara un contrato firmado por la entidad (16) y para firmar por el usuario (10) utilizando datos solicitados al usuario (10), y se genera un resumen criptografico del contrato,
    - el modulo de autenticacion es un modulo de provision de claves (28), y se envla una direccion de red del modulo de provision de claves (28) al dispositivo movil (14) del usuario (10) en un mensaje de autenticacion por medio del modulo de contacto (20), y el resumen criptografico se envla cifrado en el mensaje de autenticacion,
    - en caso de establecimiento del canal de comunicacion entre el dispositivo movil (14) y el modulo de provision de claves (28)
    - el resumen criptografico cifrado y un identificador de la entidad (16) se envlan al modulo de provision de claves (28),
    - la entidad (16) se identifica por medio del modulo de provision de claves (28), y el resumen criptografico cifrado se descifra por medio de una clave asignada a la entidad (16), y a continuacion el resumen criptografico se firma con una clave del usuario (10) que esta en poder del modulo de provision de claves (28), y
    - el resumen criptografico se envla a la entidad (16) desde el modulo de provision de claves (28) verificando con la entidad (16) que el resumen criptografico ha recibido de la entidad (16).
  10. 10. Procedimiento, segun cualquiera de las reivindicaciones 1 a 6, caracterizado por que
    - el modulo de contacto (20) detecta un contacto para el desciframiento de un documento, durante lo cual el usuario (10) envla un documento a descifrar al modulo de contacto (20),
    - el modulo de autenticacion es un modulo de provision de claves (28), y se envla una direccion de red del modulo de provision de claves (28) al dispositivo movil (14) del usuario (10) en un mensaje de autenticacion por medio del modulo de contacto (20), que comprende una clave simetrica cifrada que se cifra mediante una clave simetrica que es comun con la entidad (16),
    - en caso de establecerse un canal de comunicacion entre el dispositivo movil (14) y el modulo de provision de claves (28), el modulo de provision de claves (28)
    - identifica una clave de desciframiento del usuario (10) por medio del certificado de usuario,
    - por medio de un parametro que identifica el modulo de contacto (20), recupera de su base de datos la clave simetrica que es comun con la entidad (16), y genera la clave simetrica cifrada mediante el desciframiento por medio de la clave simetrica que es comun con la entidad (16),
    - descifra la clave simetrica cifrada por medio de la clave de desciframiento, y
    - envla la clave simetrica descifrada al modulo de contacto (20), y
    - el modulo de contacto (20) descifra el documento a decifrar por medio de la clave simetrica.
  11. 11. Procedimiento, segun cualquiera de las reivindicaciones 1 a 10, caracterizado por que el certificado es un certificado de tipo X.509.
  12. 12. Procedimiento, segun cualquiera de las reivindicaciones 1 a 11, caracterizado por que el canal de
    5
    10
    15
    20
    25
    30
    comunicacion es un canal de comunicacion SSL bidireccional.
  13. 13. Sistema para autenticar a un usuario (10) en una entidad (16), que comprende
    - un modulo de contacto (20) adaptado para detectar un contacto del usuario (10) con la entidad (16),
    - un terminal (12) adaptado para recibir el contacto iniciado por el usuario (10) con el modulo de contacto (20),
    - un modulo de autenticacion (24) adaptado para autenticar al usuario (10), y
    - un dispositivo movil (14) adaptado para recibir una direccion de red del modulo de autenticacion (24) en un mensaje de autenticacion desde el modulo de contacto (20),
    caracterizado por que
    - el sistema comprende ademas un modulo (26) de cola de mensajes correspondiente a la entidad (16), el mensaje de autenticacion es un mensaje de tipo cola de mensajes enviado por medio del modulo (26) de cola de mensajes, y el dispositivo movil (14) esta adaptado para enviar un acuse de recibo firmado con una clave del usuario (10) al modulo de contacto (20) despues de recibir el mensaje de tipo cola de mensajes, en el que el dispositivo movil (14) esta conectado al modulo (26) de cola de mensajes,
    - el dispositivo movil (14) esta adaptado para verificar la aceptabilidad de un certificado de entidad del modulo de autenticacion (24) en base a la direccion de red,
    - el modulo de autenticacion (24) esta adaptado para verificar la aceptabilidad de un certificado de usuario del dispositivo movil (14), y
    - en caso de que el certificado de entidad y el certificado de usuario sean aceptables, el sistema autentica al usuario (10) en la entidad (16) estableciendo un canal de comunicacion (114, 120, 122, 124) entre el dispositivo movil (14) y el modulo de autenticacion (24), mientras que en caso de que el certificado de entidad o el certificado de usuario no sean aceptables, el usuario (10) es rechazado en la entidad (16).
ES13826744.8T 2012-12-07 2013-12-06 Procedimiento y sistema para autenticar a un usuario que utiliza un dispositivo móvil y por medio de certificados Active ES2626064T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
HUP1200715 2012-12-07
HUP1200715 2012-12-07
PCT/HU2013/000118 WO2014087179A1 (en) 2012-12-07 2013-12-06 Method and system for authenticating a user using a mobile device and by means of certificates

Publications (1)

Publication Number Publication Date
ES2626064T3 true ES2626064T3 (es) 2017-07-21

Family

ID=89665945

Family Applications (1)

Application Number Title Priority Date Filing Date
ES13826744.8T Active ES2626064T3 (es) 2012-12-07 2013-12-06 Procedimiento y sistema para autenticar a un usuario que utiliza un dispositivo móvil y por medio de certificados

Country Status (12)

Country Link
US (1) US20160189147A1 (es)
EP (1) EP2929671B1 (es)
CN (1) CN104838629B (es)
BR (1) BR112015013079A2 (es)
CA (1) CA2893709C (es)
ES (1) ES2626064T3 (es)
HK (1) HK1212521A1 (es)
HU (1) HUE032102T2 (es)
PL (1) PL2929671T3 (es)
RU (1) RU2638741C2 (es)
SG (1) SG11201504061RA (es)
WO (1) WO2014087179A1 (es)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2901750A1 (es) * 2021-12-30 2022-03-23 Soluciones De Movilidad Espec S L Sistema y metodo para controlar el correcto uso de una plaza de aparcamiento

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015166216A1 (en) * 2014-05-02 2015-11-05 Barclays Bank Plc Transaction authentication
NL2011717C2 (en) * 2013-10-31 2015-05-04 Ubiqu B V A first entity, a second entity, an intermediate node, methods for setting up a secure session between a first and second entity, and computer program products.
US10096183B2 (en) * 2014-06-02 2018-10-09 Best Lockers, Llc Mobile kiosk for intelligent securable devices system
US9912648B2 (en) 2014-07-15 2018-03-06 Square, Inc. Two-factor authentication with push notification for a security code
US9736040B2 (en) * 2014-08-07 2017-08-15 International Business Machines Corporation Monitoring SMS messages related to server/customer interactions
US10142338B2 (en) 2014-09-12 2018-11-27 Id.Me, Inc. Systems and methods for online third-party authentication of credentials
US9705857B1 (en) * 2014-10-10 2017-07-11 Sprint Spectrum L.P. Securely outputting a security key stored in a UE
KR101652625B1 (ko) 2015-02-11 2016-08-30 주식회사 이베이코리아 온라인 웹사이트의 회원 로그인을 위한 보안인증 시스템 및 그 방법
US9727869B1 (en) 2015-06-05 2017-08-08 Square, Inc. Expedited point-of-sale merchant payments
JP6425816B2 (ja) * 2015-06-30 2018-11-21 フジツウ テクノロジー ソリューションズ インタレクチュアル プロパティ ゲーエムベーハー コンピュータ・ネットワーク・インフラストラクチャーにおいて外部コンピュータ・システムをブロック解除する方法、かかるコンピュータ・ネットワーク・インフラストラクチャーをもつ分散コンピュータ・ネットワークおよびコンピュータ・プログラム・プロダクト
US10169562B2 (en) * 2015-08-27 2019-01-01 International Business Machines Corporation Activity recognition to confirm secure authentication of a user
US10250590B2 (en) 2015-08-31 2019-04-02 Samsung Electronics Co., Ltd. Multi-factor device registration for establishing secure communication
CN105337987B (zh) * 2015-11-20 2018-07-03 同济大学 一种网络用户身份认证方法及系统
DE102015223078A1 (de) 2015-11-23 2017-05-24 Siemens Aktiengesellschaft Vorrichtung und Verfahren zum Anpassen von Berechtigungsinformationen eines Endgeräts
BR112018071137A8 (pt) * 2016-04-13 2023-04-18 Diebold Nixdorf Inc Aparelho, mídia de instruções legível em computador e método de videoconferência com um dispositivo de cliente
US10305901B2 (en) 2016-05-06 2019-05-28 Blackberry Limited System and method for multi-factor authentication
US10291604B2 (en) * 2016-06-03 2019-05-14 Docusign, Inc. Universal access to document transaction platform
CN106209383B (zh) * 2016-07-13 2019-08-23 广东商联支付网络技术有限公司 一种移动支付安全认证的方法及装置
US11430070B1 (en) 2017-07-31 2022-08-30 Block, Inc. Intelligent application of reserves to transactions
WO2018118029A1 (en) * 2016-12-20 2018-06-28 Hewlett-Packard Development Company, L.P. Authenticate a first device based on a push message to a second device
EP3340196A1 (de) * 2016-12-23 2018-06-27 Qbo Coffee GmbH Verfahren zum betrieb einer getränkezubereitungsmaschine, getränkezubereitungsmaschine und computerprogramm
US11763303B1 (en) 2017-03-10 2023-09-19 Wells Fargo Bank, N.A. Identity management service via a user-level token
US10721226B1 (en) 2017-03-10 2020-07-21 Wells Fargo Bank, N.A. User-level token for user authentication via a user device
US10645079B2 (en) * 2017-05-12 2020-05-05 Bank Of America Corporation Preventing unauthorized access to secured information systems using authentication tokens and multi-device authentication prompts
US10915900B1 (en) 2017-06-26 2021-02-09 Square, Inc. Interchange action delay based on refund prediction
IL253632B (en) 2017-07-24 2022-01-01 Sensepass Ltd A system and method for distance-based secure communication over an unsecured communication channel
US10693856B2 (en) * 2017-08-08 2020-06-23 Fmr Llc Automatic authentication switching in online live chat applications
KR102530441B1 (ko) * 2018-01-29 2023-05-09 삼성전자주식회사 전자 장치와 외부 전자 장치 및 이를 포함하는 시스템
TWI666908B (zh) * 2018-04-27 2019-07-21 來毅數位科技股份有限公司 密鑰管理方法及系統
CN108989441A (zh) * 2018-07-27 2018-12-11 京东方科技集团股份有限公司 一种信息交互系统及方法
CN110621028B (zh) * 2019-06-06 2022-12-20 珠海全志科技股份有限公司 配网方法及配网装置、电子设备
CN113508413A (zh) * 2019-06-18 2021-10-15 维萨国际服务协会 用于加密主账号(pan)支付流的跨境快速响应(qr)支付流
PT3767875T (pt) * 2019-07-16 2023-03-06 Lleidanetworks Serveis Telematics Sa Método para assinar eletronicamente contratos
US10963852B1 (en) 2019-09-23 2021-03-30 Capital One Services, Llc Secure file transfer system using an ATM
RU2731651C1 (ru) * 2019-11-08 2020-09-07 Публичное Акционерное Общество "Сбербанк России" (Пао Сбербанк) Способ и система авторизации пользователя
US11790722B2 (en) 2020-08-11 2023-10-17 Best Lockers, Llc Single-sided storage locker systems accessed and controlled using machine-readable codes scanned by mobile phones and computing devices
US11631295B2 (en) 2020-08-11 2023-04-18 ScooterBug, Inc. Wireless network, mobile systems and methods for controlling access to lockers, strollers, wheel chairs and electronic convenience vehicles provided with machine-readable codes scanned by mobile phones and computing devices
US11611631B2 (en) 2021-02-18 2023-03-21 Panduit Corp. Secure remotely controlled system, device, and method
CN113239379B (zh) * 2021-05-19 2022-02-11 郑州信大捷安信息技术股份有限公司 一种基于scep协议的国密证书签发方法和系统
HUP2100403A1 (hu) * 2021-11-24 2023-05-28 Otp Bank Nyrt Dokumentumhitelesítõ rendszer és eljárás
US11893070B2 (en) * 2022-02-08 2024-02-06 My Job Matcher, Inc. Apparatus and methods for expanding contacts for a social networking platform
CN115118439B (zh) * 2022-08-29 2023-01-20 北京智芯微电子科技有限公司 终端数字身份的校验方法及系统

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI980427A (fi) * 1998-02-25 1999-08-26 Ericsson Telefon Ab L M Menetelmä, järjestely ja laite todentamiseen
US6523672B2 (en) * 2001-07-25 2003-02-25 The Laitram Corporation Zero-back-pressure conveyor with inverted roller belt loop
JPWO2003015356A1 (ja) * 2001-08-08 2004-12-02 富士通株式会社 サーバ、移動通信端末、無線装置および通信システムにおける通信方法並びに通信システム
KR100648064B1 (ko) * 2004-01-14 2006-11-23 주식회사 케이티프리텔 인증용 무선 단말기 및 이를 이용한 전자 거래 시스템 및그 방법
US20070130463A1 (en) 2005-12-06 2007-06-07 Eric Chun Wah Law Single one-time password token with single PIN for access to multiple providers
JP2009140231A (ja) * 2007-12-06 2009-06-25 Sony Corp 通信システム及び通信端末装置
FR2958821A1 (fr) * 2007-12-11 2011-10-14 Mediscs Procede d'authentification d'un utilisateur
US8245044B2 (en) * 2008-11-14 2012-08-14 Visa International Service Association Payment transaction processing using out of band authentication
US10110631B2 (en) * 2009-02-12 2018-10-23 International Business Machines Corporation Introducing encryption, authentication, and authorization into a publication and subscription engine
EP2226966A1 (fr) 2009-03-03 2010-09-08 Gemalto SA Procédé d'établissement sécurisé d'un contrat multipartite virtuel matérialisable
US20120066501A1 (en) 2009-03-17 2012-03-15 Chuyu Xiong Multi-factor and multi-channel id authentication and transaction control
US20110270751A1 (en) 2009-12-14 2011-11-03 Andrew Csinger Electronic commerce system and system and method for establishing a trusted session
US20110219427A1 (en) * 2010-03-04 2011-09-08 RSSBus, Inc. Smart Device User Authentication
SG10201504580YA (en) 2010-06-11 2015-07-30 Docusign Inc Web-based electronically signed documents
US8660948B2 (en) 2010-07-02 2014-02-25 Qualcomm Incorporated System and method for managing transactions with a portable computing device
US20120116972A1 (en) 2010-11-10 2012-05-10 Electronic Check Clearing House Organization Electronic Payment Orders
US20120166309A1 (en) 2010-12-27 2012-06-28 Electronics And Telecommunications Research Institute Authentication system and authentication method using barcodes
US20120203695A1 (en) 2011-02-09 2012-08-09 American Express Travel Related Services Company, Inc. Systems and methods for facilitating secure transactions
US8763097B2 (en) 2011-03-11 2014-06-24 Piyush Bhatnagar System, design and process for strong authentication using bidirectional OTP and out-of-band multichannel authentication
US9710634B2 (en) * 2012-08-03 2017-07-18 Vasco Data Security, Inc. User-convenient authentication method and apparatus using a mobile authentication application

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2901750A1 (es) * 2021-12-30 2022-03-23 Soluciones De Movilidad Espec S L Sistema y metodo para controlar el correcto uso de una plaza de aparcamiento

Also Published As

Publication number Publication date
BR112015013079A2 (pt) 2017-07-11
RU2638741C2 (ru) 2017-12-15
RU2015126103A (ru) 2017-01-13
WO2014087179A1 (en) 2014-06-12
CA2893709A1 (en) 2014-06-12
SG11201504061RA (en) 2015-06-29
EP2929671B1 (en) 2017-02-22
HUE032102T2 (en) 2017-08-28
CN104838629A (zh) 2015-08-12
PL2929671T3 (pl) 2017-08-31
US20160189147A1 (en) 2016-06-30
HK1212521A1 (en) 2016-06-10
EP2929671A1 (en) 2015-10-14
CA2893709C (en) 2020-07-28
CN104838629B (zh) 2017-11-21

Similar Documents

Publication Publication Date Title
ES2626064T3 (es) Procedimiento y sistema para autenticar a un usuario que utiliza un dispositivo móvil y por medio de certificados
ES2887258T3 (es) Procedimiento para realizar una autenticación de dos factores
EP3175578B1 (en) System and method for establishing trust using secure transmission protocols
ES2644739T3 (es) Solicitud de certificados digitales
ES2266540T3 (es) Aparato metodo de certificacion de datos.
US9160732B2 (en) System and methods for online authentication
ES2381293B1 (es) Sistema y método de acreditación personal mediante dispositivo móvil.
ES2779750T3 (es) Sistema de firma electrónica para un documento electrónico que utiliza un circuito de autenticación de terceros
EP2485453A1 (en) System and methods for online authentication
US10147092B2 (en) System and method for signing and authenticating secure transactions through a communications network
US20110022835A1 (en) Secure Communication Using Asymmetric Cryptography and Light-Weight Certificates
BR102014023229A2 (pt) método para autenticação de transação de vários fatores utilizando dispositivos vestíveis
ES2431625T3 (es) Autentificación de datos personales en sistemas de telecomunicaciones
US20190007218A1 (en) Second dynamic authentication of an electronic signature using a secure hardware module
ES2923919T3 (es) Protección de una comunicación P2P
ES2773705T3 (es) Método para proporcionar firmas digitales seguras
ES2837138T3 (es) Procedimiento y sistema para la autentificación de un terminal de telecomunicación móvil en un sistema informático de servicio y terminal de telecomunicación móvil
AU2016228254A1 (en) System and methods for online authentication
EP2251812A1 (en) Transaction verification USB token
GB2475033A (en) Transaction Verification Token
ES2788976B2 (es) Sistema para el cifrado y autenticacion de comunicaciones con autenticacion mutua de los comunicantes
RU2636694C2 (ru) Способ организации защищённого обмена сообщениями
AU2015202677B2 (en) System and methods for online authentication
CN114401100A (zh) 一种区块链账号的跨应用平台登录方法和系统
Alenius et al. Online Banking Security