ES2856195T3 - Autenticación de inicio de sesión y de transacción segura y eficiente usando iPhones y otros dispositivos de comunicación móvil inteligentes - Google Patents

Autenticación de inicio de sesión y de transacción segura y eficiente usando iPhones y otros dispositivos de comunicación móvil inteligentes Download PDF

Info

Publication number
ES2856195T3
ES2856195T3 ES11775429T ES11775429T ES2856195T3 ES 2856195 T3 ES2856195 T3 ES 2856195T3 ES 11775429 T ES11775429 T ES 11775429T ES 11775429 T ES11775429 T ES 11775429T ES 2856195 T3 ES2856195 T3 ES 2856195T3
Authority
ES
Spain
Prior art keywords
application
user
pin
mobile communication
communication device
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
ES11775429T
Other languages
English (en)
Inventor
Ravi Ganesan
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.)
Payfone Inc
Original Assignee
Payfone Inc
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 Payfone Inc filed Critical Payfone Inc
Application granted granted Critical
Publication of ES2856195T3 publication Critical patent/ES2856195T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/42Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083Network architectures or network communication protocols for network security for authentication of entities using passwords
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/18Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/321Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3215Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a plurality of channels
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3226Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3234Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • H04W12/068Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56Financial cryptography, e.g. electronic payment or e-cash
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80Wireless

Abstract

Método de autenticación de un usuario de un dispositivo de comunicación móvil (600), que comprende: dirigir, mediante una primera aplicación (612) que se ejecuta en el dispositivo de comunicación móvil (600) y está en una sesión activa con una página de red (650), la transmisión, desde el dispositivo de comunicación móvil (600) hasta un servidor de seguridad (625), de una solicitud de autenticación del usuario en relación con (i) el inicio de sesión del usuario o (ii) la entrada del usuario en una transacción con el sitio de red (650); recibir, mediante una segunda aplicación (610) que se ejecuta en el dispositivo de comunicación móvil (600), la solicitud de autenticación del servidor de seguridad (625); dirigir, mediante la segunda aplicación (610), la presentación por parte del dispositivo de comunicación móvil (600) de la solicitud de autenticación recibida al usuario; recibir, mediante la segunda aplicación (610), una entrada del usuario al dispositivo de comunicación móvil (600) que indica que la autenticación solicitada debería continuar; dirigir, mediante la segunda aplicación (610) como respuesta a la entrada del usuario recibida, la transmisión, desde el dispositivo de comunicación móvil (600) hasta el servidor de seguridad (625), de una indicación de que la autenticación solicitada debería continuar; recibir, mediante la segunda aplicación (610) del servidor de seguridad (625), un número de identificación personal (PIN), como respuesta a la transmisión de la indicación de que la autenticación solicitada debería continuar; y dirigir, mediante la primera aplicación (612), la transmisión, desde el dispositivo de comunicaciones móviles (600) hasta el sitio de red (650), del PIN recibido por la segunda aplicación (610), para autenticar al usuario o la transacción en el sitio de red.

Description

DESCRIPCIÓN
Autenticación de inicio de sesión y de transacción segura y eficiente usando iPhones y otros dispositivos de comunicación móvil inteligentes
SOLICITUDES RELACIONADAS
[0001] Esta solicitud reivindica la prioridad basada en la solicitud de EE.UU. n.° de serie 61/327,723, presentada el 26 de abril de 2010. Esta solicitud se refiere a la solicitud pendiente n.° de serie 12/938,161, presentada el 2 de noviembre de 2010 y titulada "A NEW METHOD FOR SECURE SITE AND USER AUTHENTICATION", que reivindica la prioridad basada en la solicitud provisional de EE.UU. n.° de serie 61/257,207, presentada el 2 de noviembre de 2009 y titulada "Project Seal". Esta solicitud también está relacionada con la solicitud pendiente n.° de serie 13/006,806, presentada el 14 de enero de 2011 y titulada "A NEW METHOD FOR SECURE USER AND SITE AUTHENTICATION", que es una continuación de la solicitud pendiente n.° de serie 12/938,161. Esta solicitud también está relacionada con la solicitud pendiente n.° de serie 13/011,587, presentada el 21 de enero de 2011, y titulada "A NEW METHOD FOR SECURE USER AND TRANSACTION AUTHENTICATION AND RISK MANAGEMENT", que reivindica la prioridad basada en la solicitud provisional de EE.UU. n.° de serie 61/298,551, presentada el 27 de enero de 2010 y titulada "Authentication-The Game Changer". Esta solicitud también está relacionada con la solicitud n.° de serie 13/011,739, presentada el 21 de enero de 2011, y titulada "A NEW METHOD FOR SECURE USER AND TRANSACTION AUTHENTICATION AND RISK MANAGEMENT", que es una continuación parcial de la solicitud pendiente n.° de serie 13/011,587.
CAMPO TÉCNICO
[0002] Esta invención se refiere a la seguridad y la privacidad. Más particularmente, se refiere a la autenticación de transacciones basada en la web usando dispositivos de comunicación móvil inteligentes, como Apple iPhones™.
ANTECEDENTES DE LA INVENCIÓN
[0003] La autenticación del usuario mediante técnicas, tales como contraseñas, contraseñas de un solo uso (OTPs, por sus siglas en inglés), tarjetas inteligentes de hardware o software, etc., ha demostrado ser demasiado débil y susceptible a los ataques de man in the middle (MITM) o man in the browser (MITB), o bien ha resultado ser demasiado engorrosa y costosa. El uso de técnicas sencillas de inicio de sesión, tales como OpenID, FaceBook Connect, etc., solo empeora el problema, ya que una vez que el atacante ha comprometido la cuenta maestra, ahora pueden robar todas las demás cuentas que dependen de ese inicio de sesión inicial. Además, el enfoque de los atacantes ha pasado de intentar interrumpir el proceso de inicio de sesión a utilizar técnicas sofisticadas para entrar después del acto de inicio de sesión y atacar las transacciones que se realizan. Esto ha hecho que la autenticación de transacciones, el acto de confirmar si la transacción vista en el servidor web back end es idéntica a la prevista por el usuario, sea aun más importante.
[0004] La autenticación fuera de banda (OOBA, por sus siglas en inglés), una técnica por medio de la cual se transmite una transacción al usuario, y se obtiene la confirmación, usando una forma alternativa de comunicación, por ejemplo mediante una llamada telefónica de voz o un mensaje de texto, es una alternativa prometedora, pero es también inconveniente y difícil de usar con mucha frecuencia. Puede ser útil para las transacciones de mayor valor o eventos raros como restablecimiento de contraseñas, pero usarla para un gran número de transacciones es demasiado costoso e incómodo.
[0005] En el trabajo anterior (véanse las solicitudes relacionadas anteriormente identificadas), describimos una innovación que aborda algunos de estos problemas. Específicamente, introdujimos la noción del establecimiento de un servidor de seguridad que se comunica con una ventana emergente independiente en el escritorio del usuario que se usa para acceder a la página web. Describimos cómo este servidor de seguridad puede alertar al usuario, a través de comunicaciones a la ventana emergente, sobre la legitimidad de la página web en la que el usuario está navegando a través de su navegador. También describimos cómo esta ventana emergente puede proporcionar a un usuario una contraseña de un solo uso para permitir el inicio de sesión en la página web (es decir, la autenticación del usuario a la página web), en base a un secreto compartido entre la página web y el servidor de seguridad. De particular utilidad en esta invención fue que proporcionó la seguridad de contraseñas de un solo uso, pero no requirió un secreto compartido por usuario que todos los sistemas de contraseña de un solo uso habían requerido.
[0006] Cuando los usuarios navegan por una página web de comercio electrónico, es común que vean botones de pago como los proporcionados por Paypal. Cuando el usuario hace clic en esa funcionalidad de pago, el usuario suele estar interactuando directamente con el proveedor de pagos. Esto significa que el usuario no revela sus credenciales, para autenticarse ante el proveedor de pagos, a la página de comercio electrónico. Esto es una característica importante que ya no está disponible cuando un usuario está interactuando en la página de comercio electrónico usando una aplicación para teléfonos inteligentes que la página proporciona.
[0007] La US2008052180 (A1) describe un sistema de transacciones centralizado que incluye un servidor que se comunica con estaciones de trabajo cliente y dispositivos remotos. El sistema incluye un servidor que se comunica con un terminal, un dispositivo remoto y una estación de trabajo. Tanto los clientes como los vendedores acceden al servidor a través de una estación de trabajo para configurar y mantener información en el servidor y acceder a información del historial relacionada con las transacciones. El sistema es adecuado tanto para las transacciones en línea como para las transacciones en tiendas físicas, incluidas las transacciones de conveniencia. Un cliente posee un código de identificación que se presenta a un vendedor para una transacción. El vendedor envía el código de identificación a un servidor, que envía un código de autenticación a un dispositivo remoto en posesión del cliente. El cliente hace que el código de autenticación se envíe al servidor, que autentica al cliente para la transacción. El servidor aplica acuerdos previamente guardados por el cliente y la transacción se completa con el servidor proporcionando información de pago previamente guardada.
[0008] La US2010041391 (A1) describe un método o proceso que permite la recopilación de datos de dispositivos móviles y redes móviles usando tecnologías de filtración, compresión, encriptación, administración de memoria y administración de energía para recopilar métricas de dispositivos móviles en el dispositivo móvil, y luego transmitir estas métricas desde el dispositivo móvil hasta un servidor para que las procese el software de análisis.
[0009] El procesamiento de análisis también puede ocurrir directamente en el dispositivo móvil. Las políticas se determinan y configuran en el servidor de procesamiento para impulsar y controlar las métricas de dispositivos móviles capturadas, que pueden incluir, pero de forma no limitativa, uso de datos, uso de voz, ubicación del dispositivo móvil, patrones de celda, interacciones táctiles, análisis de comportamiento, rendimiento de batería, uso de CPU, uso de memoria, uso de red y similares.
[0010] La US2005135242 (A1) describe un método para operar una red de comunicación, donde la red comprende una pluralidad de estaciones que son capaces de transmitir datos y recibir datos entre sí, de modo que un mensaje que comprende una pluralidad de paquetes de datos se envía desde una estación de origen hasta una estación de destino a través de al menos una estación intermedia seleccionada de manera oportunista. El método hace uso de señales de sondeo transmitidas desde cada estación en un canal de sondeo seleccionado al que responden otras estaciones para indicar su disponibilidad como estaciones de destino o intermedias. Se envía un mensaje "Request to Send" con un mensaje "Clear to Send" devuelto por una estación disponible. La estación con datos para enviar selecciona de manera oportunista una estación disponible y la estación seleccionada usa un mensaje "Packet Acknowledge" para confirmar la recepción exitosa del paquete de datos transmitido. Un mensaje "End-to-End Acknowledge" es enviado por la estación de origen, directa o indirectamente, para confirmar la recepción de dichos paquetes de datos.
[0011] La US2008098225 (A1) describe un sistema y un método para proporcionar autenticación segura para el acceso a una página web u otra transacción segura. En una forma de realización, cuando un usuario accede a una página web, el servidor web identifica al usuario y envía una solicitud de autenticación al dispositivo móvil del usuario. El dispositivo móvil recibe las solicitudes de autenticación y envía la clave de autenticación de vuelta al servidor web. Al verificar la clave de autenticación, el servidor web concede el acceso al usuario.
[0012] La US2002004831 (A1) describe un sistema de autenticación o autorización para facilitar transacciones electrónicas que utilizan comunicaciones simultáneas o sustancialmente simultáneas en dos redes diferentes para verificar la identidad de un usuario. Cuando un usuario inicia sesión en una página, a través de internet, se utiliza un número de teléfono, ya sea guardado previamente u obtenido en tiempo real a partir del visitante, donde se puede llamar al visitante esencialmente de inmediato para configurar, a través de la red telefónica conmutada, otro enlace de comunicación. Donde el usuario tiene múltiples enlaces de comunicación disponibles, la llamada telefónica se realiza automáticamente a través del software de autenticación o autorización simultáneamente mientras el usuario está en línea. En el caso de que el usuario tenga un único enlace de comunicación, esta persona tendrá que cerrar la sesión temporalmente para recibir la llamada telefónica. La información de confirmación se proporciona a través de internet al usuario. La llamada telefónica realizada automáticamente solicita que el usuario retroalimente esta información de confirmación con fines de verificación. El número de teléfono al que se está llamando es adyacente al terminal de internet del usuario. La respuesta del usuario, a través de la red telefónica, se puede comparar con la información de confirmación transmitida originalmente para determinar si el proceso de autenticación o autorización debería continuar.
[0013] Las innovaciones descritas aquí amplían aun más nuestro trabajo anterior para proporcionar una autenticación de inicio de sesión y autorización de transacción eficientes y seguras utilizando dispositivos de comunicación móvil inteligentes.
OBJETIVOS DE LA INVENCIÓN
[0014] La presente invención está dirigida a proporcionar un protocolo de autenticación de inicio de sesión y de transacción mejorado que se implemente fácilmente en los dispositivos de comunicación móvil inteligentes, tales como iPhones e iPads.
[0015] Los objetos, las ventajas y características nuevas adicionales de la presente invención resultarán evidentes para los expertos en la técnica de esta divulgación, incluida la siguiente descripción detallada, así como mediante la práctica de la invención. Mientras que la invención se describe a continuación con referencia a la(s) forma(s) de realización preferida(s), se debe entender que la invención no está limitada a ella(s). Los expertos en la técnica que tengan acceso a las instrucciones de este documento reconocerán implementaciones, modificaciones y formas de realización adicionales, así como otros campos de uso, que están dentro del alcance de la invención, como se describe y reivindica aquí y con respecto a los cuales la invención podría ser de gran utilidad.
RESUMEN DE LA INVENCIÓN
[0016] El problema anteriormente mencionado se resuelve con las características de la reivindicación independiente. Las formas de realización adicionales son el objeto de las reivindicaciones dependientes. Según aspectos de la presente invención, se refieren a la autenticación de un usuario de un dispositivo de comunicación móvil, como un iPhone. Para hacerlo, una primera aplicación que se ejecuta en el dispositivo de comunicación móvil, como una aplicación de comercio electrónico de un comerciante o banco, dirige la transmisión, desde el dispositivo de comunicación móvil hasta un servidor de seguridad, de una solicitud de autenticación del usuario en relación con (i) el inicio de sesión del usuario en un sitio de red, como la página de internet del comerciante o del banco o (ii) la realización, por parte del usuario, de una transacción con dicho sitio de red, como la compra de un producto desde la página de internet del comerciante o la transferencia de fondos desde la página de internet del banco. Una segunda aplicación que se ejecuta en el dispositivo de comunicación móvil, que se denomina comúnmente la aplicación Hawk and Seal, pero que también se denomina a menudo en este caso Aplicación de Autenticación (AA), recibe la solicitud de autenticación del servidor de seguridad. La segunda aplicación dirige la presentación por parte del dispositivo de comunicación móvil, por ejemplo, en la pantalla táctil del iPhone, de la solicitud de autenticación recibida para el usuario. La segunda aplicación recibe luego una entrada del usuario al dispositivo de comunicación móvil, por ejemplo a través de la pantalla táctil del iPhone, que indica que la autenticación solicitada debería continuar. La segunda aplicación, como respuesta a la entrada recibida del usuario, dirige la transmisión, desde el dispositivo de comunicación móvil hasta el servidor de seguridad, de una indicación de que la autenticación solicitada debería continuar. Como respuesta, la segunda aplicación recibe, desde el servidor de seguridad, un número de identificación personal (PIN, por sus siglas en inglés). Este PIN podría caracterizarse como un PIN de inicio de sesión del sitio de red o un PIN de transacción, según corresponda. El PIN corresponde preferiblemente a un secreto compartido solo por el servidor de seguridad y el sitio de red, y no por el usuario. De la manera más preferible, el PIN se obtiene también a partir de otros factores, incluidos los que son exclusivos de la EDA y, en el caso de la autorización de una transacción, de una transacción particular, etc. Independientemente de cómo se obtenga el PIN, la primera aplicación dirige la transmisión, desde el dispositivo de comunicaciones móviles hasta el sitio de red, del PIN recibido por la segunda aplicación, para autenticar al usuario o a la transacción en el sitio de red.
[0017] Preferiblemente, la segunda aplicación almacena el PIN recibido en una memoria pública de datos, como la aplicación de portapapeles (pasteboard) personalizada, dentro del dispositivo de comunicaciones móviles. En tal caso, la primera aplicación recupera el PIN almacenado de la memoria pública de datos y el PIN recuperado es el PIN del que la primera aplicación dirige la transmisión al sitio de red. Una ventaja única de esta invención es su capacidad para utilizar memoria pública compartida, como portapapeles públicos en el sistema operativo de los iPhones. Sin embargo, alternativamente, la segunda aplicación podría simplemente transferir el PIN recibido de manera directa a la primera aplicación. En este caso, lo que puede ser ventajoso en determinadas aplicaciones, la primera aplicación no tiene necesidad de recuperar el PIN y el PIN del que la primera aplicación dirige la transmisión al sitio de red es el PIN que se le transmitió directamente mediante la segunda aplicación. Otra alternativa más es que la segunda aplicación dirija la presentación directa del PIN, en el dispositivo de teléfono móvil, por ejemplo en la pantalla táctil del iPhone, al usuario. En este último caso, el usuario introduce manualmente el PIN en la primera aplicación, por ejemplo en la pantalla táctil del iPhone. Por lo tanto, en este último caso, la primera aplicación tampoco tiene necesidad de recuperar el PIN y el PIN del que la primera aplicación dirige la transmisión al sitio de red es el PIN que se le introdujo mediante la segunda aplicación. Mientras que este último caso podría ser potencialmente beneficioso en determinadas implementaciones, generalmente se prefiere que la transmisión del PIN al sitio de red por parte de la primera aplicación se dirija sin que el PIN se presente al usuario, o que el usuario lo inserte en la primera aplicación.
[0018] Según aun otros aspectos preferidos de la invención, la memoria pública de datos también se puede usar para otros fines. Por ejemplo, la segunda aplicación puede almacenar información en la memoria pública de datos, lo que indica que existe o no existe una sesión activa entre la segunda aplicación y el servidor de seguridad. Si es así, después de que la primera aplicación reciba una solicitud del usuario para acceder al sitio de red o para entrar en una transacción con el sitio de red, la primera aplicación puede determinar, en base a la información de sesión activa almacenada, si existe o no una sesión activa. La primera aplicación solo dirigirá la transmisión de la solicitud de autenticación del usuario al servidor de seguridad solo si se determina que existe una sesión activa. De otro modo, la primera aplicación solicitará que el usuario active una sesión con el servidor de seguridad antes de continuar con la autorización de la transacción.
[0019] Beneficiosamente, la información almacenada que indica que existe o no existe una sesión activa incluye un número aleatorio y un tiempo de vida (TTL, por sus siglas en inglés). En tal caso, la segunda aplicación recibe un nuevo número aleatorio y un TTL nuevo del servidor de seguridad, con el PIN que recibe en respuesta a la transmisión de la indicación que debería continuar la autenticación solicitada. Luego, la segunda aplicación almacena, en la memoria pública de datos, el nuevo número aleatorio y el nuevo TTL como información actual que indica que existe o no existe una sesión activa entre la segunda aplicación y el servidor de seguridad.
[0020] Según otros aspectos ventajosos de la invención, la segunda aplicación también ayuda preferiblemente al usuario a iniciar sesión en el servidor de seguridad. Para hacerlo, la segunda aplicación recibe una solicitud del usuario para iniciar sesión en el servidor de seguridad. Esta solicitud podría, por ejemplo, ser iniciada por el usuario al intentar acceder al sitio de red del servidor de seguridad, por ejemplo, la página web de internet del servidor de seguridad. La segunda aplicación dirige la transmisión de la solicitud y un identificador de usuario, por ejemplo, el número de teléfono móvil del iPhone, desde el dispositivo de comunicación móvil hasta el servidor de seguridad. Una tercera aplicación que se ejecuta en el dispositivo de comunicación móvil, como una aplicación de mensajería de texto, recibe un mensaje, que incluye otro PIN, que podría caracterizarse como un PIN de inicio de sesión de seguridad, desde el servidor de seguridad como respuesta a la solicitud transmitida. La tercera aplicación dirige la visualización de este otro PIN mediante el dispositivo de comunicación móvil. La segunda aplicación recibe otra entrada de usuario, por ejemplo, introducida en la pantalla táctil del iPhone, incluido el otro PIN mostrado. La segunda aplicación dirige la transmisión del otro PIN recibido desde el dispositivo de comunicación móvil hasta el servidor de seguridad. Como respuesta, la segunda aplicación recibe desde el servidor de seguridad una cookie de sesión y una información de sesión activa que indica un periodo de tiempo durante el cual la sesión entre la segunda aplicación y el servidor de seguridad permanecerá activa. La segunda aplicación almacena (i) la cookie de sesión en una memoria privada de información accesible solo para la segunda aplicación y (ii) la información de la sesión activa en una memoria pública de datos, por ejemplo el portapapeles del iPhone, accesible para la segunda aplicación.
[0021] Según otras formas de realización de la presente invención, la funcionalidad anteriormente descrita se puede implementar en uno o más artículos de fabricación que incluyen un programa almacenado en algún tipo de medio de almacenamiento, de manera que el programa almacenado esté configurado para ser legible por un procesador y, de este modo, haga que el procesador funcione como se describió sustancialmente con anterioridad.
[0022] Por ejemplo, la segunda aplicación podría ser una aplicación de iPhone almacenada en la memoria del iPhone que recibe, desde un servidor de seguridad, una solicitud de autenticación del usuario en relación con (i) el inicio de sesión del usuario o (ii) la entrada del usuario en una transacción con un sitio de red. Si es así, la aplicación dirige una visualización, por parte del dispositivo de comunicación móvil, de la solicitud de autenticación recibida. Si, como respuesta, la aplicación recibe una entrada del usuario al dispositivo de comunicación móvil que indica que la autenticación solicitada debería continuar, dirige la transmisión, desde el dispositivo de comunicación móvil hasta el servidor de seguridad, de una indicación de que la autenticación solicitada debería continuar. Como respuesta a esta transmisión, la aplicación recibe un PIN desde el servidor de seguridad y pone el PIN recibido a disposición de otro programa ejecutable por el dispositivo de comunicaciones móviles, por ejemplo, almacenando el PIN recibido en una memoria pública de datos dentro del dispositivo de comunicación móvil, para facilitar, de este modo, la transmisión del PIN recibido desde el dispositivo de comunicación móvil hasta el sitio de red para autenticar, por lo tanto, al usuario o a la transacción en el sitio de red. Como se ha indicado anteriormente, el PIN corresponderá preferiblemente a un secreto compartido solo por el servidor de seguridad y el sitio de red, y no por el usuario.
[0023] Preferiblemente, la aplicación también hace que el procesador almacene, en la memoria pública de datos, información que indica que existe o no existe una sesión activa entre la aplicación y el servidor de seguridad. En cuyo caso, la solicitud de autenticación solo se recibe desde el servidor de seguridad si la información almacenada indica que existe una sesión activa. Si la información de sesión activa almacenada incluye un número aleatorio y un tiempo de vida (TTL), la aplicación también hace que el procesador funcione para recibir, desde el servidor de seguridad, un nuevo número aleatorio y un nuevo TTL con el PIN, y almacene, en la memoria pública de datos, esta nueva información como la información actual que indica si existe no una sesión activa entre la aplicación y el servidor de seguridad.
[0024] La aplicación también hará que el procesador funcione de manera beneficiosa para recibir una solicitud del usuario para iniciar sesión en el servidor de seguridad, y la transmisión directa de la solicitud y un identificador de usuario desde el dispositivo de comunicación móvil hasta el servidor de seguridad. La aplicación hace que el procesador funcione para recibir también otra entrada de usuario, incluido otro PIN, y para dirigir la transmisión, desde el dispositivo de comunicación móvil hasta el servidor de seguridad, del otro PIN recibido. Luego, la aplicación hace que el procesador funcione, como respuesta a la transmisión del otro PIN recibido, para recibir una cookie de sesión y una información de sesión activa desde el servidor de seguridad, lo que indica un periodo de tiempo durante el cual la sesión entre la aplicación y el servidor de seguridad permanecerá activa, y almacenar (i) la cookie de sesión en una memoria privada de información accesible solo para la aplicación y (ii) la información de sesión activa en una memoria pública de datos accesible para otros programas ejecutables por el iPhone.
[0025] Conforme a otra forma de realización más de la invención, un servidor de seguridad funciona para autenticar a un usuario de un dispositivo de comunicación móvil al recibir, desde una primera aplicación que se ejecuta en el dispositivo de comunicación móvil que está en una sesión activa con un sitio de red, una solicitud de autenticación del usuario en relación con (i) el inicio de sesión del usuario (ii) o la entrada del usuario en una transacción con el sitio de red. El servidor de seguridad transmite a una segunda aplicación, que se ejecuta en el dispositivo de comunicación móvil, la solicitud de autenticación recibida y, como respuesta, recibe, desde la segunda aplicación, una indicación de que la autenticación solicitada debería continuar. Como respuesta, el servidor de seguridad transmite luego, a la segunda aplicación, un PIN, que corresponde preferiblemente a un secreto compartido solo por el servidor de seguridad y el sitio de red, y no por el usuario, para autenticar al usuario en el sitio de red. Como se ha indicado anteriormente, este PIN podría caracterizarse como un PIN de inicio de sesión del sitio de red o un PIN de transacción, según corresponda. Además, el servidor de seguridad recibe preferiblemente la solicitud de autenticación del usuario desde la primera aplicación solo si existe una sesión activa entre la segunda aplicación y el servidor de seguridad.
[0026] Según otros aspectos preferidos de las operaciones del servidor de seguridad, el servidor de seguridad recibe, desde la segunda aplicación, una solicitud del usuario para iniciar sesión en el servidor de seguridad. Como respuesta, el servidor de seguridad transmite preferiblemente, a una tercera aplicación que se ejecuta en el dispositivo de comunicación móvil, una aplicación de mensajería de texto, un mensaje que incluye otro PIN. Este PIN podría caracterizarse como un PIN de inicio de sesión de seguridad, como se ha indicado anteriormente.
[0027] Posteriormente, el servidor de seguridad recibe el otro PIN transmitido desde la segunda aplicación, y autentica al usuario en base al otro PIN recibido. El servidor de seguridad transmite también, a la segunda aplicación, una cookie de sesión y una información de sesión activa que indica un periodo de tiempo durante cual la sesión entre la segunda aplicación y el servidor de seguridad permanecerá activa, en base a la autenticación del usuario.
[0028] Puede ser que valga la pena destacar que puede haber tres tipos de PINs. El primero es el PIN requerido para la activación inicial de la aplicación de seguridad que se ejecuta en el dispositivo de comunicación móvil, es decir, la aplicación que recibe PINs desde el servidor de seguridad. Este PIN a veces se ha caracterizado como el PIN de inicio de sesión de seguridad anterior. El segundo es un PIN de firma de la transacción que la aplicación del sitio de red que se ejecuta en el dispositivo de comunicaciones móviles obtiene de la aplicación de seguridad para autorizar una transacción. Este PIN a veces se ha caracterizado como el PIN de transacción anterior. El tercero es un PIN que la aplicación del sitio de red obtiene de la seguridad para iniciar sesión en el propio servicio del sitio de red. Este PIN a veces se ha caracterizado como el PIN de inicio de sesión del sitio de red anterior.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
[0029]
La figura 1 representa los componentes principales del sistema conforme a nuestro trabajo anterior inicial.
La figura 2 muestra el sistema aumentado con autenticación de usuario, en este caso, logrado usando autenticación fuera de banda, conforme a nuestro trabajo anterior inicial.
La figura 3 representa un registro de las actividades de la red que se pueden mantener y usar para el análisis de inteligencia de riesgo aumentado, conforme a las extensiones anteriores de nuestro trabajo anterior inicial.
La figura 4 representa los componentes principales del sistema conforme a otras extensiones anteriores de nuestro trabajo anterior inicial.
La figura 5 muestra el sistema aumentado con autenticación de usuario, en este caso, logrado usando autenticación fuera de banda, conforme a otras extensiones anteriores de nuestro trabajo anterior inicial.
La figura 6 representa un dispositivo de comunicación móvil inteligente conforme a la presente invención.
La figura 7 representa una arquitectura de red simplificada conforme a la presente invención.
La figura 8 representa una visualización asociada a un inicio de sesión inicial, que se presenta al usuario en un dispositivo de comunicación móvil inteligente mediante una aplicación de autenticación que se ejecuta en ese dispositivo conforme a la presente invención.
La figura 9 representa una visualización asociada a otro inicio de sesión o una autorización de la transacción, que se presenta al usuario en un dispositivo de comunicación móvil inteligente mediante una aplicación de autenticación que se ejecuta en ese dispositivo conforme a la presente invención.
La figura 10 representa otra visualización asociada al otro inicio de sesión o la autorización de la transacción, que se presenta al usuario en un dispositivo de comunicación móvil inteligente mediante una aplicación de autenticación que se ejecuta en ese dispositivo conforme a la presente invención.
La figura 11 representa una visualización asociada a la autorización de la transacción, que se presenta al usuario en un dispositivo de comunicación móvil inteligente mediante una aplicación del comerciante que se ejecuta en ese dispositivo conforme a la presente invención.
La figura 12 representa otra visualización asociada a la autorización de la transacción, que se presenta al usuario en un dispositivo de comunicación móvil inteligente mediante una aplicación del comerciante que se ejecuta en ese dispositivo conforme a la presente invención.
FORMA(S) DE REALIZACIÓN PREFERIDA(S) DE LA INVENCIÓN
Visión de conjunto
[0030] En el trabajo anterior hemos descrito cómo la entrada de un servidor de seguridad basado en red que tiene un canal independiente a una ventana emergente de usuario se puede usar junto con el navegador de un usuario y la página web que está visitando para proporcionar tanto la página web como la autenticación de usuario a través de un dispositivo de red de un solo usuario.
[0031] Luego mostramos cómo extender este concepto a la autenticación de transacciones. Específicamente, cuando una página web recibe una transacción desde un navegador de usuario, que desea confirmar, envía la información de la transacción al servidor de seguridad, que reenvía la información de la transacción a la ventana emergente del usuario junto con una firma de la transacción de un solo uso que se calcula en base a un secreto compartido entre el servidor de seguridad y el servidor web y en la información de la transacción. El usuario transfiere esta firma de la transacción de un solo uso al servidor web a través del navegador, y el servidor web puede recalcular la firma de la transacción de un solo uso, y si hay una coincidencia, puede asegurarse de que el usuario ha confirmado la transacción.
[0032] También mostramos cómo extender el concepto de una ventana emergente basada en navegador a diferentes factores de forma. Por ejemplo, la ventana emergente se puede implementar como una aplicación de teléfono inteligente, como una parte dedicada de la pantalla de un teléfono inteligente que se usa solo para este propósito, o podría implementarse como una tarjeta inteligente.
[0033] Además, mostramos cómo aprovechar el hecho de que la ventana emergente (o su sustituto) tiene un registro de cada inicio de sesión y transacción del usuario. Actualmente, los motores de riesgo observan la actividad del usuario en una página web dada para determinar un comportamiento sospechoso. O, en algunos casos, las redes de páginas web comparten dicha información. En otras palabras, se analizan datos de los sistemas back end. En nuestro sistema, el registro emergente del inicio de sesión de un usuario y el historial de la transacción del usuario proporciona una forma de front end centrado de usuario para capturar esta información y aumentar las capacidades de los motores de riesgo.
Nuestro trabajo anterior inicial
[0034] Anteriormente describimos una forma de realización preferida para la autenticación de transacciones con referencia a las figuras 1 y 2, que muestran un sistema que consta de los siguientes componentes:
• Un servidor de seguridad.
• Una ventana emergente en el escritorio del usuario.
• Un navegador en el escritorio del usuario.
• La página web en la que el usuario está realizando la transacción.
[0035] Tal y como se describió anteriormente, el usuario primero pasará por una fase de configuración y de personalización que es un proceso de un solo uso, y luego iniciará o activará la ventana emergente usando una técnica, como la autenticación fuera de banda. En este punto, el servidor de seguridad tendrá un canal de comunicación activo abierto al usuario que identifica, mediante algún identificador de usuario, por ejemplo, el número de teléfono usado para la autenticación fuera de banda. Además, la página web en la que el usuario está realizando transacciones y el servidor de seguridad habrían acordado previamente un secreto compartido.
[0036] El usuario que usa el navegador selecciona una transacción, por ejemplo, "Pagar a Alice 100$", que se transmite mediante el navegador al servidor web. El servidor web transmite esta transacción al servidor de seguridad a través del navegador del usuario. El servidor de seguridad calcula una firma de la transacción de un solo uso en función de (i) los detalles de la transacción y (ii) el secreto que comparte con esa página web particular. El servidor de seguridad transmite luego esta firma de la transacción de un solo uso a la ventana emergente del usuario. El usuario corta y pega o, de otro modo, copia esta firma de la transacción de un solo uso en el navegador web y la firma se transmite de vuelta a la página web. La página web calcula de forma independiente la firma de la transacción, usando (i) los detalles de la transacción y (ii) el secreto que comparte con el servidor de seguridad, y la compara con la recibida por parte del usuario. Si las dos firmas coinciden, el servidor web se puede asegurar de que el servidor de seguridad vio la misma transacción que envió (es decir, no una transacción manipulada en ruta al servidor de seguridad) y, dado que el servidor de seguridad le está mostrando al usuario la transacción en un canal independiente, se obtiene la confirmación del usuario de la transacción.
Extensiones anteriores de nuestro trabajo anterior inicial
[0037] En otra forma de realización preferida previamente descrita, mostramos cómo nuestro trabajo anterior con respecto a la autenticación, como el que se describió inmediatamente anteriormente, se puede extender al caso en el que la ventana emergente se implementa en una variedad de diferentes factores de forma. Una variedad contempla que la ventana emergente esté en una aplicación en un dispositivo móvil, otra contempla la ventana usando una parte dedicada del área de visualización de un dispositivo de red móvil personal, como un teléfono inteligente, y la última contempla la ventana emergente incorporada en hardware dedicado similar al de una tarjeta inteligente, que tiene capacidades de comunicación. En todos los casos, toda la funcionalidad se operará exactamente de la misma forma, excepto que el usuario pueda cortar y pegar las contraseñas de un solo uso usadas para la autenticación y, en su lugar, tendría que escribirlas en el navegador web que se opera en un dispositivo de red diferente. Estos factores de forma proporcionan capas adicionales de seguridad simplemente por ser independientes del ordenador de sobremesa del usuario que ejecuta el navegador.
[0038] En cualquiera de las formas de realización preferidas mencionadas anteriormente, cuando un usuario ejecuta múltiples inicios de sesión y transacciones, la ventana emergente o su sustituto tiene la capacidad de almacenar un historial o registro de estos eventos. Estos datos se pueden proporcionar a los motores de gestión de riesgo, que hoy en día solo tienen acceso a los patrones de actividad del usuario que observan en una o más páginas web.
[0039] En resumen, en extensiones de nuestro trabajo anterior, mostramos cómo fortalecer significativamente la unión entre el usuario, el servidor de seguridad que actúa como proveedor de identidad y la página web que es la parte de confianza en el caso de transacciones realizadas a través de una red, como la compra de un producto por parte de un usuario en la página web. Aquí, como en nuestro trabajo anterior, asumimos que el servidor de seguridad y la página web han acordado a priori un secreto compartido (el sistema se extiende fácilmente para usar criptografía de clave pública). Además, como se muestra en la figura 2, también asumimos que el usuario ha usado algún método, autenticación fuera de banda, por ejemplo, para autenticar al servidor de seguridad. Cuando el usuario desea realizar una transacción en una página web, como la compra de un producto ofrecido en la página web o la transferencia de fondos desde una cuenta bancaria, la página web comunicó los detalles de la transacción (como el tipo y la cantidad de la transacción), que se presentaron tanto en una página web mostrada al usuario a través del navegador del usuario como en una ventana emergente. Antes de continuar con la transacción, la página web requería autenticación y confirmación de la transacción, o lo que comúnmente se conoce como una firma del usuario en la transacción. Por lo tanto, la página web mostró adicionalmente un espacio en blanco para introducir la firma del usuario. Además, la página web también comunicó una solicitud de firma del usuario en la transacción identificada al servidor de seguridad. El servidor de seguridad calculó una contraseña de un solo uso en función (i) del secreto que comparte con la página web y (ii) de los detalles de la transacción correspondientes mostrados en la ventana emergente, y mostró la contraseña de un solo uso al usuario en la ventana emergente. El usuario introdujo (tal vez cortando y pegando) esta contraseña de un solo uso en la página web, que sirvió como firma del usuario en la transacción. La contraseña de un solo uso, es decir, la firma, se transmitió posteriormente a la página web. La página web confirmó la autenticidad de la firma al volver a calcular la contraseña de un solo uso del secreto que comparte con el servidor de seguridad y los detalles de la transacción. Aquí nuevamente, este sistema tiene todas las propiedades de seguridad de las contraseñas de un solo uso, pero tiene la tremenda ventaja de que no requiere un secreto compartido con cada usuario, y son solo el servidor de seguridad y las páginas web los que necesitan secretos compartidos para generar contraseñas de un solo uso utilizadas como firmas en las transacciones. Si se desea, la contraseña real de un solo uso también se puede construir en base a una marca de tiempo o un algoritmo OTP basado en contador (en la forma en que usamos estos algoritmos, el valor de tiempo o de contador debe ser comunicado por el servidor de seguridad a la página web; o potencialmente calculado usando de manera determinística alguna fórmula acordada).
Otras extensiones anteriores de nuestro trabajo anterior
[0040] También describimos previamente otra extensión que proporciona una aplicación que permite que la propia ventana emergente resida en el teléfono inteligente, la tarjeta inteligente u otro dispositivo de red móvil inteligente personal pequeño del usuario, en lugar de en el dispositivo de red, por ejemplo, un ordenador de sobremesa, que se usa para acceder a la página web correspondiente a través de su navegador. Mostramos, por ejemplo, cómo esto se logra fácilmente en un teléfono inteligente, porque el teléfono ya está personalizado y, de acuerdo con las técnicas anteriormente descritas, no necesita almacenar un secreto especial o ejecutar un software de contraseña de un solo uso. Por el contrario, solo la página web y el servidor de seguridad deben compartir el secreto requerido y solo el servidor de seguridad debe generar las contraseñas de un solo uso requeridas para la autenticación del usuario y la firma del usuario.
[0041] También describimos previamente una extensión que nos permite proporcionar análisis de inteligencia de riesgo aumentado. A este respecto, el análisis de riesgo convencional se basa en los datos de páginas webs. Sin embargo, debido al flujo de información, mostramos cómo se puede mantener fácilmente un registro de datos, como uno del tipo mostrado en la figura 3, para capturar las actividades del usuario mientras la ventana emergente estaba activa. El registro podría ser mantenido, por ejemplo, por la página web del servidor de seguridad, y el usuario puede acceder a este registro. Si lo desea, el usuario o el servidor de seguridad puede calcular el perfil de riesgo del usuario. Adicional, o alternativamente, los datos registrados se pueden reenviar a un motor de riesgo de terceros, donde se pueden combinar con los datos recibidos de las páginas webs visitadas por el usuario para que el motor de riesgo pueda proporcionar al usuario un análisis de inteligencia de riesgo aumentado.
[0042] En otra extensión más, describimos una forma de realización preferida que permite comunicaciones directas de solicitudes de autenticación y de información de la transacción entre la página web y el servidor de seguridad. Más particularmente, como se describe con referencia a las figuras 4 y 5, el usuario pasó primero por una fase de configuración y de personalización, que es un proceso de un solo uso, y luego inició o activó la ventana emergente usando una técnica como la autenticación fuera de banda. En este punto, el servidor de seguridad tenía un canal de comunicación activo o una sesión abierta al usuario que identificó mediante algún identificador de usuario, por ejemplo, el número de teléfono usado para la autenticación fuera de banda. Además, la página web en la que el usuario estaba realizando transacciones y el servidor de seguridad tenían un secreto compartido previamente acordado.
[0043] El usuario usó el navegador para seleccionar una transacción, por ejemplo "Pagar a Alice 100$", que fue transmitida por el navegador del usuario al servidor web. El servidor web transmitió esta transacción al servidor de seguridad a través de un enlace directo que se había establecido entre la página web y el servidor de seguridad (en lugar de a través del navegador del usuario). El servidor de seguridad calculó una firma de la transacción de un solo uso en función de (i) los detalles de la transacción y (ii) el secreto que compartió con esa página web particular. El servidor de seguridad luego transmitió esta firma de la transacción de un solo uso a la ventana emergente del usuario. El usuario cortó y pegó o, de otro modo, copió esta firma de la transacción de un solo uso en el navegador web y la firma se transmitió posteriormente a la página web. La página web calculó, de manera independiente, la firma de la transacción usando (i) los detalles de la transacción y (ii) el secreto que compartió con el servidor de seguridad, y la comparó con la recibido por parte del usuario. Si las dos firmas coinciden, entonces se le aseguró al servidor web que el servidor de seguridad vio la misma transacción que envió (es decir, no una transacción manipulada en ruta al servidor de seguridad) y, dado que el servidor de seguridad mostró al usuario la transacción en un canal independiente o una sesión, se obtuvo la confirmación del usuario de la transacción.
[0044] También describimos previamente cómo se puede implementar la ventana emergente en una variedad de diferentes factores de forma. Una variedad contempló que la ventana emergente estaba en una aplicación en un dispositivo móvil, otra contempló la ventana usando una parte dedicada del área de visualización de un dispositivo de red móvil personal, como un teléfono inteligente, y la última contempló la ventana emergente incorporada en hardware dedicado similar al de una tarjeta inteligente, que tiene capacidades de comunicación. En todos los casos, toda la funcionalidad funcionará exactamente de la misma forma, excepto que el usuario puede cortar y pegar las contraseñas de un solo uso usadas para la autenticación y, en su lugar, tendrá que escribirlas en el navegador web que opera en un dispositivo de red diferente. Estos factores de forma proporcionan capas adicionales de seguridad simplemente por ser independientes del ordenador de sobremesa del usuario que ejecuta el navegador.
Las presentes extensiones de nuestro trabajo anterior
[0045] Ahora extendemos nuestro trabajo anterior a iPhones™ y otros dispositivos de comunicación móvil inteligentes más sofisticados (que se denominarán a continuación teléfonos inteligentes o SPs). Más particularmente, describiremos un protocolo innovador que usa una autenticación cuasi fuera de banda (MQOOBA) en lugar de la autenticación cuasi fuera de banda (QOOBA) que hemos descrito previamente.
[0046] Conforme al presente protocolo, una aplicación MQOOBA SP, por ejemplo iPhone o iPad, (que se conoce comúnmente como la aplicación Hawk and Seal y a menudo se denomina a continuación la "Aplicación de Autenticación" (“Authentify™ Application”) o "AA") o elimina la necesidad y, por lo tanto, reemplaza a la ventana de QOOBA. La AA se puede usar:
1. Para interactuar con otras aplicaciones de teléfonos inteligentes (SPAs, por sus siglas en inglés), como aplicaciones bancarias en línea;
2. Para suministrar números de identificación personal (PIN) para la navegación web a través de un sistema de autenticación; y/o
3. Como base para los pagos por teléfono móvil a través de un sistema de pago.
Descripción de visión de conjunto
[0047] Ahora describiremos como la AA se puede usar para proporcionar un método de pago seguro junto con otras SPAs, y sin que las otras SPAs aprendan las credenciales de usuario del sistema de pago. También mostraremos cómo la AA se integra fácilmente en una aplicación bancaria en línea.
[0048] En el siguiente ejemplo, el SP tiene la AA y una aplicación de muestra para la memoria de eDuckies. Se supone que la AA y la aplicación de eDuckies (EDA, por sus siglas en inglés) no realizan múltiples tareas en este ejemplo. Cada una tiene almacenamiento privado que nadie más puede ver. La AA también tiene almacenamiento público que cualquier otra SPA puede ver.
[0049] El usuario abre la AA y e inicia sesión, quizás una vez al día. Por ejemplo, el usuario puede introducir su número de teléfono, por ejemplo el número de teléfono para el SP, o la AA puede rellenar automáticamente esta información dependiendo de la preferencia del usuario. Entre bastidores, la AA habla con el servidor de seguridad (también denominado a veces servidor de seguridad), que luego emite un PIN de entrada de inicio de sesión al usuario a través de un servicio de mensajes cortos (SMS, por sus siglas en inglés), que ahora se denomina comúnmente servicio de mensajes de texto.
[0050] El usuario recibe el mensaje de texto con el PIN de inicio de sesión e introduce el PIN de inicio de sesión recibido en la AA. En algunas plataformas de SP, la AA se puede configurar, si así lo desea, para recuperar el PIN del flujo de SMS entrante y rellenar automáticamente el PIN de inicio de sesión, lo que lo hace aun más fácil para los usuarios. Un equivalente privado de una cookie de sesión es almacenado por la AA, y será usado por la AA para autenticaciones posteriores al servidor autenticado para obtener PINs de transacción cuando estén disponibles. La AA también se comunica con SPAs usando el método más apropiado. Una ventaja única de esta invención es la capacidad de utilizar almacenamiento común público, como portapapeles públicos en el sistema operativo de los iPhones.
[0051] El usuario ha iniciado sesión ahora y una sesión de MQOOBA está activa. El usuario ahora puede comenzar a usar otras SPAs y volver a la AA cuando sea necesario.
[0052] En este ejemplo, el usuario ahora navega por la aplicación de eDuckies o EDA, y finalmente quiere realizar un pedido. A eDuckies le gustaría obtener la autorización de este pedido sin problemas. Sin embargo, sería inseguro permitir que el usuario proporcione credenciales de pago a la EDA.
[0053] Por consiguiente, la EDA publica la transacción en el servidor de seguridad, que aquí sirve como el sistema de pagos. La EDA también le pide al usuario que autorice la transacción en la AA. Esto es similar a un usuario que es redirigido a una página web de pagos, como PayPal™, para autorizar una transacción. El servidor de seguridad publicará la transacción en la AA para presentarla al usuario.
[0054] De vuelta a la AA, el usuario ve una transacción en espera, la obtiene y ve que parece legítima. Por consiguiente, el usuario autoriza la transacción. Se debe entender que la MQOOBA hace que sea extremadamente difícil para un atacante, incluso uno que de alguna manera haya colocado una aplicación de eDuckies maliciosa en el teléfono del usuario, poder falsificar esto. El PIN de MQOOBA se genera en base a un secreto compartido entre el servidor de seguridad y la página legítima del comerciante, como eDuckies, y la información de la transacción, etc., si corresponde.
[0055] Después de que el usuario autorice la transacción en la AA, de vuelta a la EDA, el usuario ve el PIN rellenado automáticamente para él. Entre bastidores, el PIN fue generado (usando la información de la transacción proporcionada por la EDA y el secreto compartido por el servidor de seguridad y eDuckies) por el servidor de seguridad y transferido desde el servidor de seguridad a la AA. La AA transfirió luego el PIN a la EDA en el SP del usuario usando el almacenamiento común. También debería entenderse que, si se desea, se le podría solicitar al usuario que copie manualmente el PIN de la AA a la EDA en vez de que el PIN se rellene automáticamente. En cualquier caso, una vez que se ha rellenado el PIN en la EDA, cuando el usuario hace clic en "completar autorización", la EDA envía el PIN a la página web de eDuckies. El servicio web de eDuckies volverá a calcular el PIN y le informará a la AA si era válida o no.
Descripción detallada
[0056] Como se ha mencionado anteriormente, la AA proporciona a un usuario un PIN de autorización de inicio de sesión y de transacción dinámico para páginas particulares de comerciantes y para transacciones particulares. La AA puede obtener estos PINs de la página web del servidor de seguridad, después de haber iniciado sesión desde la AA.
[0057] En resumen:
1. El usuario inicia sesión en la página web del servidor de seguridad.
2. Posteriormente, cuando el usuario se encuentra en una página del comerciante participante y necesita iniciar sesión o autorizar una transacción, se le solicita al usuario que proporcione un nuevo PIN.
3. El usuario luego va a la AA y esta le mostrará el nombre del comerciante, y la transacción y le proporcionará el PIN de autorización para la transacción.
[0058] Haciendo referencia ahora a la figura 6, se muestra un SP 600. El SP 600 incluye una CPU 605 y una pantalla de visualización 615. EL SP 600 también tiene varias SPAs ejecutables por la CPU 605 cargadas en la misma, incluida la AA 610, la EDA 612 y una aplicación SMS (SMSA) 614 para mensajería de texto. Como se muestra, la AA 610 usa tanto la memoria pública 610a como la memoria privada 610b, y la EDA 612 usa memoria pública 612a. Con referencia a la figura 7, la CPU 605 puede ejecutar la AA 610 para interactuar con el servidor de seguridad 625 y puede ejecutar la EDA 612 para interactuar con la página web de eDuckies 650 y el servidor de seguridad 625.
Inicio de sesión inicial del servidor de seguridad
[0059] Como se muestra en la figura 8, cuando se inicia la ejecución de la AA 610, provoca la visualización de un logotipo en el área A1 de la pantalla de visualización 615. La visualización en el área A1 solicita un identificador de usuario, como el número de teléfono, por ejemplo, un número de teléfono móvil, asociado al SP 600. Preferiblemente, al usuario se le ha permitido previamente seleccionar entre una opción manual, que si se selecciona requeriría que el identificador sea rellenado manualmente por el usuario, y una opción automática, que si se selecciona, serviría como una directiva a la AA 610 para rellenar previamente el espacio provisto en la visualización en el área A1 con el identificador de usuario correspondiente, por ejemplo el número de teléfono móvil del SP. (véase, en el caso del iPhone, http://arstechnica.com/apple/news/2009/01/iphone-dev-user-phonenumbers.ars).
[0060] Cuando el usuario hace clic en la flecha en el área A1, la AA provoca una publicación en el servidor de seguridad 625. El servidor de seguridad 625 devuelve una indicación de acuse de recibo a la AA 610 y, si se acusa recibo del mensaje, la AA 610 también provoca la presentación de lo que se muestra en el área A2 de la pantalla de visualización 615 representada en la figura 7. Como se indica en el área A2, si tiene éxito, el servidor de seguridad 625 SMS, es decir, texto, envía un PIN al usuario a la dirección de SMS del usuario. Activando la ejecución de la SMSA 614 por parte de la CPU 605, el usuario puede acceder a su cuenta de SMS y recuperar el PIN del mensaje SMS enviado por el servidor de seguridad. El usuario introduce luego el PIN en el espacio provisto en el área A2, por ejemplo, cortando y pegando el PIN del mensaje SMS. Después de introducir el PIN, el usuario hace clic en la flecha en el área A2 y la AA 610 envía un segundo mensaje de interfaz de programación de aplicaciones (API, por sus siglas en inglés) para publicar el PIN.
[0061] Como se muestra en la figura 8, el mensaje de regreso del servidor de seguridad 625, si tiene éxito, devuelve una cookie de sesión, un número aleatorio que llamamos "nonce-login" y un tiempo de vida (TTL), y la AA 610 provoca la visualización mostrada en el área A3 de la pantalla de visualización 615.
[0062] Debería tenerse en cuenta que, en lugar de una elección solo entre el relleno manual y automático, se le podría permitir al usuario, adicional o alternativamente, seleccionar o solicitar que inserte un nombre de usuario en el área A1 y una contraseña en el área A2. Debería entenderse que la elección entre manual y automático anteriormente descrita es solo una de las elecciones descritas aquí. Por lo tanto, a continuación se describirá otra elección entre manual y automático en el contexto de autorización de transacción y, más particularmente, con respecto a si un PIN diferente, que está asociado con una autorización de transacción, es transmitido por la AA a la EDA automáticamente o solo después de una entrada manual por parte del usuario.
[0063] haciendo referencia nuevamente a la figura 6, la cookie de sesión se almacena de forma privada, en la memoria privada 610b. El nonce-login y el TTL se almacenan públicamente en un portapapeles, el portapapeles público de la AA, que se crea en la memoria pública 610a (véase, en el caso del iPhone, portapapeles personalizados Ref: http://developer.apple.com/iphone/library/documentation/iPhone/Conceptual/iPho neOSProgrammingGuide/EventHandling/EventHandling.html#//apple ref/doc/uid /TP40007072-CH9-SW28). Cuando el usuario cambia su "enfoque" a la AA 610, la AA 610 siempre verifica el nonce y el TTL. Si se ha agotado el tiempo de espera del TTL, la AA hace que la visualización de lo que se muestra en el área A1 de la pantalla de visualización 615 de la figura 8 comience nuevamente el inicio de sesión en el servidor de seguridad 625.
Inicio de sesión en la página web y/o autorización de transacciones
[0064] Volviendo nuevamente a la figura 9, cuando el usuario se encuentra en alguna otra SPA, por ejemplo la EDA, o la página web y se le ha solicitado un PIN, ya sea con fines de inicio de sesión o de autorización de la transacción, el usuario se redirige a la AA, como se explicará más detalladamente con referencia a la figura 11. Para los propósitos de la descripción a continuación, asumiremos que el usuario está en la EDA. Junto con esta redirección, la EDA envía información al servidor de seguridad 625. Esta información incluye si se solicita el inicio de sesión o la autorización de la transacción, el nombre del comerciante, por ejemplo eDuckies, y, si se solicita la autorización de la transacción, el texto de la transacción. Si el servidor de seguridad tiene la capacidad de ENVIAR DE MANERA FORZADA la información a la AA, el servidor de seguridad 625 hace que se envíe esta información a la AA. La AA 610 provoca la visualización de la información enviada a ella por el servidor de seguridad 625 en el área A4 de la figura 10, o lo que se muestra en el área A1 de la figura 8 si se requiere volver a iniciar sesión en el servidor de seguridad 625. Para los propósitos de esta explicación, asumimos que se visualiza el área A4.
[0065] Alternativamente, si la AA no tiene capacidad de ENVIAR DE MANERA FORZADA, confiamos en que el usuario EXTRAIGA los datos. Este es el flujo que se muestra en las figuras. Cuando el usuario hace clic en la flecha en el área A3 de la figura 9, la AA provoca una publicación en el servidor de seguridad 625. La publicación incluye la cookie de sesión anteriormente descrita.
[0066] El servidor de seguridad 625 devuelve un mensaje de éxito o error. El mensaje de regreso siempre devuelve una bandera que indica el inicio de sesión o la autorización de la transacción, el nombre del comerciante, por ejemplo eDuckies, un nuevo nonce-login, un nuevo TTL y un PIN. Si es una autorización de transacción, también devuelve el texto de la transacción. Si tiene éxito, la AA provoca la visualización mostrada en el área A4 en la pantalla de visualización A4 de la figura 10.
[0067] Si el usuario hace clic en la señal de parada, el usuario vuelve a la pantalla mostrada en la figura 9. Preferiblemente, se envía una alarma al servidor de seguridad 625, a la EDA 612 y de allí a la página web del comerciante 650, y/o a alguna otra página web relacionada con la seguridad.
[0068] Por otro lado, si el usuario hace clic en la flecha mostrada en el área A4 de la pantalla de visualización 615, el nonce-login y el TTL se escriben en la memoria pública 610a del portapapeles público de la AA. El PIN de inicio de sesión o de transacción, según corresponda, también se escribe en el portapapeles, usando el identificador del comerciante y la combinación de PIN. El merchantid.PIN se escribe sobre cualquier merchantid.PIN anterior. Ahora, el usuario vuelve nuevamente a ver la visualización mostrada en la figura 9. Alternativamente, si la transferencia manual del PIN es la opción seleccionada, entonces al usuario se le mostrará el PIN dentro de la AA y el usuario tiene la responsabilidad de copiarlo de la AA a la EDA.
[0069] Quizás valga la pena enfatizar aquí que, conforme a nuestro trabajo anterior descrito con mayor detalle anteriormente, el PIN de inicio de sesión o de transacción es generado por el servidor de seguridad 625 en base a un secreto compartido por el servidor de seguridad y la página web, y no compartido con o conocido por el usuario. Además, si se solicita la autorización de la transacción, el PIN de transacción es generado por el servidor de seguridad 625 usando también información de la transacción.
[0070] Cabe señalar que la EDA comprueba si hay un portapapeles público de la AA con un login-nonce con TTL válido para el usuario. Si no es así, informa al usuario de que él/ella no parece haber iniciado sesión en la AA. Aquí hemos asumido que el usuario ha iniciado sesión y que la EDA ha determinado que el portapapeles público de la AA tiene un nonce válido.
[0071] Para los propósitos de esta descripción, asumiremos que la autorización de la transacción está involucrada. Pasando ahora a la figura 11, el usuario está en la EDA y se le presenta la información de la transacción mostrada en el área M1 de la pantalla de visualización 615. Cuando el usuario hace clic en la flecha mostrada en el área M1, se le redirige a la AA y la AA publica la información relacionada con el comerciante y la transacción en el servidor de seguridad 625. La publicación incluye el login-nonce. El servidor de seguridad 625 devuelve un éxito o un error. Si tiene éxito, entonces la AA presenta al usuario la visualización mostrada en el área M2 de la pantalla de visualización 615 representada en la figura 12. Si el usuario hace clic en la flecha mostrada en el área M2, se realiza el proceso de autorización de la transacción anteriormente descrito y el mensaje de regreso incluye una cadena.
[0072] Cuando el foco vuelve a la EDA, la EDA sondea la AA para ver si hay un nuevo merchantid.PIN. Una vez que la EDA lo localiza, hace una publicación en la página web de eDuckies de la CADENA y el PIN de autorización de la transacción. La página web devolverá un mensaje de éxito o error, después de que se realice su propia verificación del PIN. Cabe señalar que, si se elige la opción de transferencia de PIN manual, el usuario debe introducir el PIN de autorización de la transacción en la EDA.

Claims (8)

REIVINDICACIONES
1. Método de autenticación de un usuario de un dispositivo de comunicación móvil (600), que comprende:
dirigir, mediante una primera aplicación (612) que se ejecuta en el dispositivo de comunicación móvil (600) y está en una sesión activa con una página de red (650), la transmisión, desde el dispositivo de comunicación móvil (600) hasta un servidor de seguridad (625), de una solicitud de autenticación del usuario en relación con (i) el inicio de sesión del usuario o (ii) la entrada del usuario en una transacción con el sitio de red (650); recibir, mediante una segunda aplicación (610) que se ejecuta en el dispositivo de comunicación móvil (600), la solicitud de autenticación del servidor de seguridad (625);
dirigir, mediante la segunda aplicación (610), la presentación por parte del dispositivo de comunicación móvil (600) de la solicitud de autenticación recibida al usuario;
recibir, mediante la segunda aplicación (610), una entrada del usuario al dispositivo de comunicación móvil (600) que indica que la autenticación solicitada debería continuar;
dirigir, mediante la segunda aplicación (610) como respuesta a la entrada del usuario recibida, la transmisión, desde el dispositivo de comunicación móvil (600) hasta el servidor de seguridad (625), de una indicación de que la autenticación solicitada debería continuar;
recibir, mediante la segunda aplicación (610) del servidor de seguridad (625), un número de identificación personal (PIN), como respuesta a la transmisión de la indicación de que la autenticación solicitada debería continuar; y
dirigir, mediante la primera aplicación (612), la transmisión, desde el dispositivo de comunicaciones móviles (600) hasta el sitio de red (650), del PIN recibido por la segunda aplicación (610), para autenticar al usuario o la transacción en el sitio de red.
2. Método según la reivindicación 1, que comprende, además:
almacenar, mediante la segunda aplicación (610), el PIN recibido en una memoria pública de datos en el dispositivo de comunicaciones móviles (600); y
recuperar, mediante la primera aplicación (612), el PIN almacenado de la memoria pública de datos; donde la primera aplicación (612) dirige la transmisión del PIN recuperado.
3. Método según la reivindicación 2, donde:
el dispositivo de comunicación móvil (600) es un teléfono inteligente; y
la memoria pública de datos es un portapapeles adaptado.
4. Método según la reivindicación 1, donde la primera aplicación (612) dirige la transmisión del PIN sin que el usuario presente o inserte el PIN en la primera aplicación (612).
5. Método según la reivindicación 1, que comprende, además:
almacenar, mediante la segunda aplicación (610) en la memoria pública de datos, la información que indica que existe o no existe una sesión activa entre la segunda aplicación (610) y el servidor de seguridad (625); recibir, mediante la primera aplicación (612), una solicitud del usuario para acceder al sitio de red (650) o para entrar en una transacción con el sitio de red (650); y
determinar, mediante la primera aplicación (612) en base a la información de sesión activa almacenada, si existe o no una sesión activa;
donde la primera aplicación (612) dirige la transmisión, desde el dispositivo de comunicaciones móviles (600) hasta un servidor de seguridad (625), de la solicitud de autenticación del usuario solo si se determina que existe una sesión activa.
6. Método según la reivindicación 5, donde la información almacenada, que indica que existe o no existe una sesión activa, incluye un número aleatorio y un tiempo de vida (TTL), y que comprende, además:
recibir, mediante la segunda aplicación (610) del servidor de seguridad (625), un nuevo número aleatorio y un nuevo TTL con el PIN, como respuesta a la transmisión de la indicación de que la autenticación solicitada debería continuar; y
almacenar, mediante la segunda aplicación (610) en la memoria pública de datos, el nuevo número aleatorio y el nuevo TTL como información actual que indica que existe o no existe una sesión activa entre la segunda aplicación y el servidor de seguridad (625).
7. Método según la reivindicación 1, donde el PIN corresponde a un secreto compartido solo por el servidor de seguridad (625) y el sitio de red (650), y no por el usuario.
8. Método según la reivindicación 1, que comprende, además:
recibir, mediante la segunda aplicación (610), una solicitud del usuario para iniciar sesión en el servidor de seguridad (625);
dirigir, mediante la segunda aplicación (610), la transmisión de la solicitud y un identificador de usuario desde el dispositivo de comunicación móvil (600) hasta el servidor de seguridad (625);
recibir, mediante una tercera aplicación que se ejecuta en el dispositivo de comunicación móvil (600) desde el servidor de seguridad (625), un mensaje que incluye otro PIN, como respuesta a la solicitud transmitida; dirigir, mediante la tercera aplicación, la visualización, por parte del dispositivo de comunicación móvil (600), del otro PIN;
recibir, mediante la segunda aplicación (610), otra entrada del usuario que incluye el otro PIN visualizado; dirigir, mediante la segunda aplicación (610), la transmisión, desde el dispositivo de comunicación móvil (600) hasta el servidor de seguridad (625), del otro PIN recibido e introducido;
recibir, mediante la segunda aplicación (610) del servidor de seguridad (625), una cookie de sesión y la información de sesión activa que indica un periodo de tiempo durante el cual la sesión entre la segunda aplicación (610) y el servidor de seguridad (625) permanecerá activa, como respuesta a la transmisión del otro PIN; y
almacenar, mediante la segunda aplicación (610), (i) la cookie de sesión en una memoria pública de datos accesible solo para la segunda aplicación (610) y (ii) la información de sesión activa en una memoria pública de datos accesible para la segunda aplicación.
ES11775429T 2010-04-26 2011-04-13 Autenticación de inicio de sesión y de transacción segura y eficiente usando iPhones y otros dispositivos de comunicación móvil inteligentes Active ES2856195T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US32772310P 2010-04-26 2010-04-26
US13/081,067 US8719905B2 (en) 2010-04-26 2011-04-06 Secure and efficient login and transaction authentication using IPhones™ and other smart mobile communication devices
PCT/US2011/032271 WO2011136928A1 (en) 2010-04-26 2011-04-13 Secure and efficient login and transaction authentication using iphones and other smart mobile communication devices

Publications (1)

Publication Number Publication Date
ES2856195T3 true ES2856195T3 (es) 2021-09-27

Family

ID=44816912

Family Applications (1)

Application Number Title Priority Date Filing Date
ES11775429T Active ES2856195T3 (es) 2010-04-26 2011-04-13 Autenticación de inicio de sesión y de transacción segura y eficiente usando iPhones y otros dispositivos de comunicación móvil inteligentes

Country Status (8)

Country Link
US (2) US8719905B2 (es)
EP (2) EP2564308B1 (es)
JP (2) JP5595586B2 (es)
AU (1) AU2011245653B2 (es)
CA (1) CA2794589C (es)
ES (1) ES2856195T3 (es)
SG (1) SG184785A1 (es)
WO (1) WO2011136928A1 (es)

Families Citing this family (86)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8806592B2 (en) 2011-01-21 2014-08-12 Authentify, Inc. Method for secure user and transaction authentication and risk management
US8789153B2 (en) * 2010-01-27 2014-07-22 Authentify, Inc. Method for secure user and transaction authentication and risk management
US10581834B2 (en) 2009-11-02 2020-03-03 Early Warning Services, Llc Enhancing transaction authentication with privacy and security enhanced internet geolocation and proximity
US9172693B2 (en) * 2010-11-11 2015-10-27 Paypal, Inc. Quick payment using mobile device binding
FR2968795B1 (fr) * 2010-12-10 2013-01-18 Xiring Dispositif d'appairage dynamique
US8640213B2 (en) * 2011-02-07 2014-01-28 Symantec Corporation Method and system for automatic authentication
US8869279B2 (en) 2011-05-13 2014-10-21 Imperva, Inc. Detecting web browser based attacks using browser response comparison tests launched from a remote source
US8346672B1 (en) * 2012-04-10 2013-01-01 Accells Technologies (2009), Ltd. System and method for secure transaction process via mobile device
US9098678B2 (en) * 2011-09-15 2015-08-04 Verizon Patent And Licensing Inc. Streaming video authentication
US8862888B2 (en) * 2012-01-11 2014-10-14 King Saud University Systems and methods for three-factor authentication
US9237215B2 (en) * 2012-02-10 2016-01-12 Time Warner Cable Enterprises Llc Remote activation of mobile applications
US10318936B2 (en) 2012-03-07 2019-06-11 Early Warning Services, Llc System and method for transferring funds
US11593800B2 (en) 2012-03-07 2023-02-28 Early Warning Services, Llc System and method for transferring funds
US10970688B2 (en) 2012-03-07 2021-04-06 Early Warning Services, Llc System and method for transferring funds
US10395247B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc Systems and methods for facilitating a secure transaction at a non-financial institution system
US10078821B2 (en) 2012-03-07 2018-09-18 Early Warning Services, Llc System and method for securely registering a recipient to a computer-implemented funds transfer payment network
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
AU2013243768B2 (en) 2012-04-01 2017-12-21 Payfone, Inc. Secure authentication in a multi-party system
CN102710750B (zh) * 2012-05-10 2015-03-04 上海克而瑞信息技术有限公司 一种B/S系统与Ipad实现用户硬件绑定的方法与装置
US10025920B2 (en) * 2012-06-07 2018-07-17 Early Warning Services, Llc Enterprise triggered 2CHK association
FR2993382B1 (fr) * 2012-07-13 2015-07-03 Oberthur Technologies Entite electronique securisee pour l'autorisation d'une transaction
CN103685384A (zh) * 2012-09-12 2014-03-26 中兴通讯股份有限公司 防恶意骚扰的用户身份验证方法及装置
US20140081683A1 (en) * 2012-09-14 2014-03-20 Sap Ag Business process management for mobile portal clients
US10270748B2 (en) 2013-03-22 2019-04-23 Nok Nok Labs, Inc. Advanced authentication techniques and applications
US9305298B2 (en) 2013-03-22 2016-04-05 Nok Nok Labs, Inc. System and method for location-based authentication
US9887983B2 (en) 2013-10-29 2018-02-06 Nok Nok Labs, Inc. Apparatus and method for implementing composite authenticators
US9961077B2 (en) 2013-05-30 2018-05-01 Nok Nok Labs, Inc. System and method for biometric authentication with device attestation
GB2517732A (en) * 2013-08-29 2015-03-04 Sim & Pin Ltd System for accessing data from multiple devices
KR102091606B1 (ko) * 2013-10-30 2020-03-20 엘지전자 주식회사 단말기 및 그 제어 방법
JP6378870B2 (ja) * 2013-11-15 2018-08-22 株式会社野村総合研究所 認証システム、認証方法および認証プログラム
JP5543010B1 (ja) * 2013-12-20 2014-07-09 株式会社 ディー・エヌ・エー 所定のサーバに対してログインを要求するログイン要求装置及び方法、並びにこれらに用いられるプログラム
US9654469B1 (en) 2014-05-02 2017-05-16 Nok Nok Labs, Inc. Web-based user authentication techniques and applications
US9577999B1 (en) 2014-05-02 2017-02-21 Nok Nok Labs, Inc. Enhanced security for registration of authentication devices
US9749131B2 (en) 2014-07-31 2017-08-29 Nok Nok Labs, Inc. System and method for implementing a one-time-password using asymmetric cryptography
US10148630B2 (en) 2014-07-31 2018-12-04 Nok Nok Labs, Inc. System and method for implementing a hosted authentication service
US9455979B2 (en) 2014-07-31 2016-09-27 Nok Nok Labs, Inc. System and method for establishing trust using secure transmission protocols
US9875347B2 (en) 2014-07-31 2018-01-23 Nok Nok Labs, Inc. System and method for performing authentication using data analytics
KR102206533B1 (ko) 2014-08-05 2021-01-22 삼성전자주식회사 모바일 장치, 모바일 장치의 화면 표시 방법, 웨어러블 장치, 웨어러블 장치의 구동 방법 및 컴퓨터 판독가능 기록매체
US9736154B2 (en) 2014-09-16 2017-08-15 Nok Nok Labs, Inc. System and method for integrating an authentication service within a network architecture
US9953323B2 (en) 2014-09-23 2018-04-24 Sony Corporation Limiting e-card transactions based on lack of proximity to associated CE device
US9355424B2 (en) 2014-09-23 2016-05-31 Sony Corporation Analyzing hack attempts of E-cards
US9367845B2 (en) 2014-09-23 2016-06-14 Sony Corporation Messaging customer mobile device when electronic bank card used
US9292875B1 (en) 2014-09-23 2016-03-22 Sony Corporation Using CE device record of E-card transactions to reconcile bank record
US9317847B2 (en) 2014-09-23 2016-04-19 Sony Corporation E-card transaction authorization based on geographic location
US9202212B1 (en) 2014-09-23 2015-12-01 Sony Corporation Using mobile device to monitor for electronic bank card communication
US9378502B2 (en) 2014-09-23 2016-06-28 Sony Corporation Using biometrics to recover password in customer mobile device
US9646307B2 (en) 2014-09-23 2017-05-09 Sony Corporation Receiving fingerprints through touch screen of CE device
US9558488B2 (en) 2014-09-23 2017-01-31 Sony Corporation Customer's CE device interrogating customer's e-card for transaction information
US10262316B2 (en) 2014-09-23 2019-04-16 Sony Corporation Automatic notification of transaction by bank card to customer device
WO2016051353A1 (en) * 2014-09-30 2016-04-07 Eko India Financial Services Pvt. Ltd. System and ergonomically advantageous method for performing online secure transactions on trusted personal device
EP3013014A1 (en) 2014-10-21 2016-04-27 Gemalto Sa Method for accessing a service, corresponding first device, second device and system
JP2016116088A (ja) * 2014-12-15 2016-06-23 株式会社リコー 情報処理装置、情報処理方法、及びプログラム
DE102015000220A1 (de) * 2015-01-08 2016-07-14 Giesecke & Devrient Gmbh Verfahren zum sicheren Betreiben einer Computereinheit, Softwareapplikation und Computereinheit
US10878387B2 (en) 2015-03-23 2020-12-29 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10769606B2 (en) 2015-03-23 2020-09-08 Early Warning Services, Llc Payment real-time funds availability
US10832246B2 (en) 2015-03-23 2020-11-10 Early Warning Services, Llc Payment real-time funds availability
US10839359B2 (en) 2015-03-23 2020-11-17 Early Warning Services, Llc Payment real-time funds availability
US10748127B2 (en) 2015-03-23 2020-08-18 Early Warning Services, Llc Payment real-time funds availability
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US10963856B2 (en) 2015-07-21 2021-03-30 Early Warning Services, Llc Secure real-time transactions
US11037121B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11037122B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11386410B2 (en) 2015-07-21 2022-07-12 Early Warning Services, Llc Secure transactions with offline device
US10438175B2 (en) 2015-07-21 2019-10-08 Early Warning Services, Llc Secure real-time payment transactions
US11062290B2 (en) 2015-07-21 2021-07-13 Early Warning Services, Llc Secure real-time transactions
US11157884B2 (en) 2015-07-21 2021-10-26 Early Warning Services, Llc Secure transactions with offline device
US11151522B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US10956888B2 (en) 2015-07-21 2021-03-23 Early Warning Services, Llc Secure real-time transactions
US11151523B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
KR102149340B1 (ko) * 2015-12-31 2020-08-28 후아웨이 테크놀러지 컴퍼니 리미티드 검증 코드 획득 방법 및 장치, 그리고 단말기
AU2017218516B2 (en) * 2016-02-09 2021-03-11 Ergomotion, Inc. Ultra-compact profile actuation system for an adjustable bed
US10552823B1 (en) 2016-03-25 2020-02-04 Early Warning Services, Llc System and method for authentication of a mobile device
US10769635B2 (en) 2016-08-05 2020-09-08 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
US10637853B2 (en) 2016-08-05 2020-04-28 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
US11151566B2 (en) 2016-09-19 2021-10-19 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
CN106453352B (zh) * 2016-10-25 2020-04-17 电子科技大学 一种单系统多平台身份验证方法
US10237070B2 (en) 2016-12-31 2019-03-19 Nok Nok Labs, Inc. System and method for sharing keys across authenticators
US10091195B2 (en) 2016-12-31 2018-10-02 Nok Nok Labs, Inc. System and method for bootstrapping a user binding
US10659446B2 (en) 2017-06-13 2020-05-19 Salesforce.Com, Inc. Conversational authentication
US11868995B2 (en) 2017-11-27 2024-01-09 Nok Nok Labs, Inc. Extending a secure key storage for transaction confirmation and cryptocurrency
US10833859B2 (en) 2017-12-07 2020-11-10 International Business Machines Corporation Automating verification using secure encrypted phone verification
US11831409B2 (en) 2018-01-12 2023-11-28 Nok Nok Labs, Inc. System and method for binding verifiable claims
JP6973262B2 (ja) * 2018-04-18 2021-11-24 トヨタ自動車株式会社 車両向けサービス提供システム、車載装置およびコマンド送信方法
US10986079B2 (en) 2018-12-06 2021-04-20 Bank Of America Corporation System and method for hierarchical decisioning within a hybrid blockchain
US10944745B2 (en) 2018-12-06 2021-03-09 Bank Of America Corporation System and method for device and transaction authentication
US11792024B2 (en) 2019-03-29 2023-10-17 Nok Nok Labs, Inc. System and method for efficient challenge-response authentication

Family Cites Families (73)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08235114A (ja) 1995-02-28 1996-09-13 Hitachi Ltd サーバアクセス方法と課金情報管理方法
JPH11184818A (ja) * 1997-12-25 1999-07-09 Ntt Data Corp 認証システム及び方法、並びに同システムのためのクライアントマシン
JPH11338933A (ja) 1998-05-21 1999-12-10 Micro Cabin:Kk 通信取引における取引申込者の認証システム
IL128720A (en) 1999-02-25 2009-06-15 Cidway Technologies Ltd Method for confirming actions performed over the phone
US6934858B2 (en) 1999-12-15 2005-08-23 Authentify, Inc. System and method of using the public switched telephone network in providing authentication or authorization for online transactions
BR0111119A (pt) 2000-05-25 2004-06-22 Echarge Corp Protocolo de transação segura
JP2002152195A (ja) 2000-11-10 2002-05-24 Ntt Docomo Inc 認証サーバ、認証方法及び記録媒体
US6983381B2 (en) 2001-01-17 2006-01-03 Arcot Systems, Inc. Methods for pre-authentication of users using one-time passwords
JP2002259344A (ja) 2001-02-28 2002-09-13 Mitsubishi Electric Corp ワンタイムパスワード認証システム及び携帯電話及びユーザ認証サーバ
JP2002297939A (ja) 2001-03-30 2002-10-11 Casio Electronics Co Ltd 取引認証方法、取引認証システム及び取引認証プログラム
WO2002082387A1 (en) * 2001-04-04 2002-10-17 Microcell I5 Inc. Method and system for effecting an electronic transaction
US7013290B2 (en) 2001-08-03 2006-03-14 John Allen Ananian Personalized interactive digital catalog profiling
US20040030934A1 (en) 2001-10-19 2004-02-12 Fumio Mizoguchi User selectable authentication interface and universal password oracle
US20040093263A1 (en) * 2002-05-29 2004-05-13 Doraisamy Malchiel A. Automated Interview Method
US20040019564A1 (en) * 2002-07-26 2004-01-29 Scott Goldthwaite System and method for payment transaction authentication
US20040210536A1 (en) 2002-12-18 2004-10-21 Tino Gudelj Cross-domain transactions through simulated pop-ups
US8023958B2 (en) * 2003-03-05 2011-09-20 Qualcomm Incorporated User plane-based location services (LCS) system, method and apparatus
US7421732B2 (en) 2003-05-05 2008-09-02 Nokia Corporation System, apparatus, and method for providing generic internet protocol authentication
US8213438B2 (en) 2003-12-19 2012-07-03 Iwics Inc. Data transport protocol for a multi-station network
JP2005209083A (ja) 2004-01-26 2005-08-04 Japan Telecom Co Ltd サービスシステム、及びそれを用いた通信システム、通信方法
US20050172229A1 (en) 2004-01-29 2005-08-04 Arcot Systems, Inc. Browser user-interface security application
US20050254653A1 (en) 2004-05-14 2005-11-17 Proxim Corporation Pre-authentication of mobile clients by sharing a master key among secured authenticators
US20060002556A1 (en) 2004-06-30 2006-01-05 Microsoft Corporation Secure certificate enrollment of device over a cellular network
US8296562B2 (en) 2004-07-15 2012-10-23 Anakam, Inc. Out of band system and method for authentication
US20060168259A1 (en) 2005-01-27 2006-07-27 Iknowware, Lp System and method for accessing data via Internet, wireless PDA, smartphone, text to voice and voice to text
JP4667908B2 (ja) 2005-02-28 2011-04-13 三菱電機株式会社 クライアント端末及びシングルサインオンシステム
US20060235795A1 (en) 2005-04-19 2006-10-19 Microsoft Corporation Secure network commercial transactions
WO2006130616A2 (en) 2005-05-31 2006-12-07 Tricipher, Inc. Augmented single factor split key asymmetric cryptography-key generation and distributor
GB0519842D0 (en) * 2005-09-29 2005-11-09 Hewlett Packard Development Co Methods and apparatus for managing and using one-time pads
US7748031B2 (en) * 2005-07-08 2010-06-29 Sandisk Corporation Mass storage device with automated credentials loading
CN101495956B (zh) 2005-08-11 2012-03-07 晟碟以色列有限公司 扩展一次性密码方法和装置
JP2007102778A (ja) 2005-10-04 2007-04-19 Forval Technology Inc ユーザ認証システムおよびその方法
US20070283273A1 (en) 2005-10-24 2007-12-06 Woods Michael E System, Method, and Computer Program Product for Internet Tool
EP1955471A4 (en) 2005-12-01 2009-03-11 Firestar Software Inc SYSTEM AND METHOD FOR EXCHANGING INFORMATION BETWEEN EXCHANGE APPLICATIONS
EP1898333A4 (en) 2005-12-09 2009-09-23 Hitachi Software Eng AUTHENTICATION SYSTEM AND AUTHENTICATION PROCESS
US20070157304A1 (en) * 2006-01-05 2007-07-05 International Business Machines Corporation Method, apparatus and computer program product for automatic cookie synchronization between distinct web browsers
KR20070077569A (ko) 2006-01-24 2007-07-27 삼성전자주식회사 휴대폰을 이용한 일회용 패스워드 서비스 시스템 및 방법
WO2007089179A1 (en) * 2006-02-03 2007-08-09 Mideye Ab A system, an arrangement and a method for end user authentication
US9137012B2 (en) 2006-02-03 2015-09-15 Emc Corporation Wireless authentication methods and apparatus
WO2007095265A2 (en) 2006-02-10 2007-08-23 Rsa Security Inc. Method and system for providing a one time password to work in conjunction with a browser
US8434137B2 (en) 2006-03-22 2013-04-30 Gemalto Sa Method of securely logging into remote servers
US7912762B2 (en) * 2006-03-31 2011-03-22 Amazon Technologies, Inc. Customizable sign-on service
US7552467B2 (en) 2006-04-24 2009-06-23 Jeffrey Dean Lindsay Security systems for protecting an asset
US7562813B2 (en) * 2006-05-10 2009-07-21 First Data Corporation System and method for activating telephone-based payment instrument
US20080034216A1 (en) 2006-08-03 2008-02-07 Eric Chun Wah Law Mutual authentication and secure channel establishment between two parties using consecutive one-time passwords
US7818216B2 (en) 2006-08-28 2010-10-19 Seraphim Lawhorn Transaction system with centralized data storage and authentication
KR100786551B1 (ko) 2006-09-15 2007-12-21 이니텍(주) 복수 개의 방식에 의한 일회용 비밀번호의 사용자 등록,인증 방법 및 그러한 방법을 수행하는 프로그램이 기록된컴퓨터 판독 가능 기록 매체
US7979054B2 (en) 2006-10-19 2011-07-12 Qualcomm Incorporated System and method for authenticating remote server access
US8112817B2 (en) 2006-10-30 2012-02-07 Girish Chiruvolu User-centric authentication system and method
US8060916B2 (en) 2006-11-06 2011-11-15 Symantec Corporation System and method for website authentication using a shared secret
US20080120707A1 (en) 2006-11-22 2008-05-22 Alexander Ramia Systems and methods for authenticating a device by a centralized data server
US8468244B2 (en) 2007-01-05 2013-06-18 Digital Doors, Inc. Digital information infrastructure and method for security designated data and with granular data stores
US8332921B2 (en) 2007-01-12 2012-12-11 Wmware, Inc. Enhanced security for user instructions
IL190839A0 (en) 2007-04-15 2008-12-29 Ari Eliaz Method and system for monetary billing for the use of content services in internet sites, by sending sms messages from cellular phones
US20090031407A1 (en) * 2007-07-24 2009-01-29 Shaobo Kuang Method and system for security check or verification
US20090093300A1 (en) 2007-10-05 2009-04-09 Lutnick Howard W Game of chance processing apparatus
GB0718817D0 (en) 2007-09-26 2007-11-07 British Telecomm Password management
US8032939B2 (en) 2007-11-06 2011-10-04 Airtight Networks, Inc. Method and system for providing wireless vulnerability management for local area computer networks
US20090132813A1 (en) 2007-11-08 2009-05-21 Suridx, Inc. Apparatus and Methods for Providing Scalable, Dynamic, Individualized Credential Services Using Mobile Telephones
US8302167B2 (en) 2008-03-11 2012-10-30 Vasco Data Security, Inc. Strong authentication token generating one-time passwords and signatures upon server credential verification
US8024576B2 (en) 2008-03-31 2011-09-20 International Business Machines Corporation Method and system for authenticating users with a one time password using an image reader
CA2632793A1 (en) 2008-04-01 2009-10-01 Allone Health Group, Inc. Information server and mobile delivery system and method
US8136148B1 (en) 2008-04-09 2012-03-13 Bank Of America Corporation Reusable authentication experience tool
US8272038B2 (en) 2008-05-19 2012-09-18 International Business Machines Corporation Method and apparatus for secure authorization
US8528045B2 (en) 2008-07-22 2013-09-03 Next Access Technologies, Llc Methods and systems for secure key entry via communication networks
US20100041391A1 (en) 2008-08-12 2010-02-18 Anthony Wayne Spivey Embedded mobile analytics in a mobile device
US20120005483A1 (en) 2009-04-09 2012-01-05 Hydrabyte, Inc. Method for Image-Based Authentication
US8230231B2 (en) * 2009-04-14 2012-07-24 Microsoft Corporation One time password key ring for mobile computing device
US20100268831A1 (en) * 2009-04-16 2010-10-21 Microsoft Corporation Thin Client Session Management
US8769784B2 (en) 2009-11-02 2014-07-08 Authentify, Inc. Secure and efficient authentication using plug-in hardware compatible with desktops, laptops and/or smart mobile communication devices such as iPhones
US10049356B2 (en) * 2009-12-18 2018-08-14 First Data Corporation Authentication of card-not-present transactions
US9021507B2 (en) * 2009-12-29 2015-04-28 International Business Machines Corporation Dynamic use of data across multiple programs
US20110208801A1 (en) 2010-02-19 2011-08-25 Nokia Corporation Method and apparatus for suggesting alternate actions to access service content

Also Published As

Publication number Publication date
JP2014225880A (ja) 2014-12-04
US20140245401A1 (en) 2014-08-28
US8893237B2 (en) 2014-11-18
AU2011245653B2 (en) 2014-04-17
JP2013530440A (ja) 2013-07-25
EP2564308B1 (en) 2021-01-13
JP5595586B2 (ja) 2014-09-24
US8719905B2 (en) 2014-05-06
EP3840290A1 (en) 2021-06-23
AU2011245653A1 (en) 2012-08-30
EP2564308A1 (en) 2013-03-06
CA2794589C (en) 2016-01-26
EP3840290B1 (en) 2023-12-06
SG184785A1 (en) 2012-11-29
WO2011136928A1 (en) 2011-11-03
EP2564308A4 (en) 2017-11-15
CA2794589A1 (en) 2011-11-03
US20110265149A1 (en) 2011-10-27

Similar Documents

Publication Publication Date Title
ES2856195T3 (es) Autenticación de inicio de sesión y de transacción segura y eficiente usando iPhones y otros dispositivos de comunicación móvil inteligentes
US9832183B2 (en) Key management using quasi out of band authentication architecture
US10057763B2 (en) Soft token system
ES2553222T3 (es) Seguridad de autentificación 2CHK mejorada con transacciones de consulta
US9444809B2 (en) Secure and efficient authentication using plug-in hardware compatible with desktops, laptops and/or smart mobile communication devices such as iPhones™
CA2875503C (en) Enterprise triggered 2chk association activation
Van Damme et al. A PKI-based mobile banking demonstrator