ES2553222T3 - Seguridad de autentificación 2CHK mejorada con transacciones de consulta - Google Patents

Seguridad de autentificación 2CHK mejorada con transacciones de consulta Download PDF

Info

Publication number
ES2553222T3
ES2553222T3 ES13801298T ES13801298T ES2553222T3 ES 2553222 T3 ES2553222 T3 ES 2553222T3 ES 13801298 T ES13801298 T ES 13801298T ES 13801298 T ES13801298 T ES 13801298T ES 2553222 T3 ES2553222 T3 ES 2553222T3
Authority
ES
Spain
Prior art keywords
user
firewall
network
website
company
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
ES13801298T
Other languages
English (en)
Other versions
ES2553222T1 (es
Inventor
Peter Tapling
Andrew Rolfe
Ravi Ganesan
Sally Sheward
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.)
Early Warning Services LLC
Original Assignee
Early Warning Services LLC
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 Early Warning Services LLC filed Critical Early Warning Services LLC
Publication of ES2553222T1 publication Critical patent/ES2553222T1/es
Application granted granted Critical
Publication of ES2553222T3 publication Critical patent/ES2553222T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/42—User authentication using separate channels for security data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • User Interface Of Digital Computer (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Método de operar un servidor de seguridad para ejecutar transacciones con pregunta a través de una red, que comprende: recibir, en el servidor de seguridad desde un dispositivo de red de usuario a través de la red, una solicitud de un usuario para activar un canal de comunicaciones seguro sobre la red entre el dispositivo de red de usuario y el servidor de seguridad; transmitir, mediante el servidor de seguridad en respuesta a la solicitud de activación recibida, un código de activación para entregar al usuario a través de otra red; recibir, en el servidor de seguridad del dispositivo de red de usuario a través de la red, un código de activación; comparar, en el servidor de seguridad, el código de activación recibido con el código de activación transmitido para validar el código de activación recibido; activar el canal de comunicaciones seguro basándose en la validación del código de activación recibido; recibir, en un servidor de seguridad de una red de empresa, que está también representado en la red, una pregunta que incluye una pregunta para el usuario, donde la respuesta correcta a la pregunta ha sido previamente acordada por el usuario y la empresa; transmitir, del servidor de seguridad al dispositivo de red de usuario a través del canal de comunicaciones seguro, la pregunta de la empresa recibida; recibir, en un servidor de seguridad del dispositivo de red de usuario a través del canal de comunicaciones seguro, una respuesta de usuario a la pregunta de empresa transmitida; y transmitir la respuesta de usuario recibida, del servidor de seguridad a la empresa para autentificar adicionalmente el usuario a la empresa.

Description

DESCRIPCIÓN
Seguridad de autentificación 2CHK mejorada con transacciones de consulta
Campo técnico
[0001] Esta invención se refiere a la seguridad y a la privacidad. Más particularmente, está relacionada con el inicio de sesión basado en la web y la autentificación de transacciones, incluyendo las firmas basadas en la web, el uso de dispositivos de complemento de hardware compatibles con ordenadores de sobremesa y/o portátiles y/o dispositivos inteligentes de comunicación móvil, como iPhones™ de Apple.
Antecedentes de la invención
[0002] La autentificación del usuario utilizando técnicas como contraseñas, contraseñas de un solo uso (OTP), tarjetas inteligentes de hardware o software, etc., ha demostrado ser demasiado débil y susceptible a ataques de intermediario (MITM) o ataques de intermediario en el navegador (MITB) o ha resultado demasiado complicada y cara. El uso de técnicas de inicio de sesión único como OpenID, FaceBook Connect, etc., solo empeora el problema, ya que, una vez que el atacante ha comprometido la cuenta maestra, puede entrar en todas las demás cuentas que dependen de ese inicio de sesión inicial. Además, el foco de los atacantes ha pasado de intentar descifrar 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 autentificación de la transacción, el acto de confirmar si la transacción vista en el servidor web de fondo es idéntica a la prevista por el usuario, sea aún más importante.
[0003] La autentificación fuera de banda (OOBA), una técnica mediante la cual se transmite una transacción al usuario, y la confirmación obtenida, utilizando 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 también es inconveniente y costosa para usarla con mucha frecuencia. Puede ser útil para las transacciones de mayor valor u ocasiones poco frecuentes como restablecimientos de contraseña, pero usarla para grandes cantidades de transacciones es demasiado costoso y complicado.
[0004] Recientemente, se ha desarrollado un nuevo sistema y protocolo de autentificación innovador para abordar algunos de estos problemas. En concreto, un sistema y protocolo, comúnmente conocido como "2CHK", puede proporcionar al usuario una OTP para permitir el inicio de sesión en un sitio web (es decir, la autentificación del usuario en el sitio web) o para firmar electrónicamente una transacción realizada con un sitio web, basándose en un secreto compartido entre el sitio web y el servidor de seguridad. De particular utilidad es el hecho de que el 2CHK proporciona la seguridad de las contraseñas de un solo uso, pero no requiere un secreto compartido por cada usuario que todos los sistemas y protocolos OTP anteriores han requerido.
[0005] Es común que, cuando los usuarios navegan por un sitio web de comercio electrónico, como el sitio web de un comercio, de un banco o de un corredor de bolsa, vean botones de pago como el proporcionado por PayPal. Cuando el usuario hace clic en esa funcionalidad de pago, generalmente interactúa directamente con el proveedor de pagos. Esto significa que el usuario no revela sus credenciales para autentificarse al proveedor de pagos del sitio de comercio electrónico. Esta es una característica importante que no está disponible cuando un usuario interactúa con el sitio de comercio electrónico utilizando una aplicación de teléfono inteligente que proporciona el sitio web. Por lo tanto, el 2CHK puede implementarse utilizando una aplicación de cliente segura separada, comúnmente conocida como el "cliente 2CHK", que tiene un canal de comunicaciones seguro independiente con un servidor de autentificación de fondo. El cliente 2CHK se puede implementar como software especializado en un dispositivo informático, o como una aplicación basada en navegador, o como una aplicación en un dispositivo de comunicaciones móviles, incluyendo un teléfono inteligente, como un iPhone.
[0006] Por ejemplo, el cliente 2CHK se puede usar para mostrar las transacciones del usuario, ya sea para informar al usuario de la transacción, para permitir que el usuario confirme/rechace la transacción y/o para proporcionar al usuario una firma de transacción, es decir, una OTP, que él/ella puede usar en otra aplicación, como una aplicación de sitio web de un comercio o de un banco, para autorizar la transacción. Además, el cliente 2CHK también puede proporcionar al usuario una OTP que se puede utilizar para iniciar sesión en diferentes sitios web u otras aplicaciones. Dependiendo de la implementación, el 2CHK puede usar cualquiera de dos métodos distintos para generar tales OTP. En uno de ellos el servidor de autentificación proporciona la OTP y en el otro el cliente 2CHK recibe la "semilla" durante la activación para que pueda generar las OTP sin ninguna conexión con el servidor de autentificación back-end.
[0007] El auge de los teléfonos inteligentes ha dado como resultado la llegada al mercado de elementos de hardware complementarios que se pueden conectar a los teléfonos inteligentes mediante varias interfaces. Al igual que se puede conectar una impresora a un ordenador utilizando un puerto y/o cable USB, también se pueden conectar dispositivos a los teléfonos inteligentes utilizando, por ejemplo, el conector de auriculares universal. Por lo tanto, el cliente 2CHK se ha adaptado para ejecutarse en dicho hardware complementario y, por lo tanto, para proporcionar una autentificación de inicio de sesión y una autorización de transacción eficientes y seguras utilizando hardware conectable compatible con dispositivos inteligentes de comunicación móvil y dispositivos informáticos personales con conexión a Internet.
[0008] US 2011/0029436 A1 revela un método y/o sistema para enviar anuncios personalizados y autentificar a un usuario involucrado en una transacción en línea. El usuario puede solicitar una contraseña de un único uso o permanente para iniciar una transacción financiera o para abrir una cuenta en línea. El usuario puede comunicarse con una institución financiera en un sitio web a través de un primer canal de comunicaciones como, por ejemplo, Internet. El sistema de anuncios personalizados puede enviar o transmitir a un usuario información de contraseña seleccionada que incluye una contraseña o código de acceso alfa- y/o numérico a través de un segundo canal de comunicaciones. El sistema de anuncios y autentificación puede recibir la solicitud del usuario a través de un primer canal de comunicaciones y, posteriormente, enviar la información de la contraseña más el anuncio seleccionado al usuario a través del segundo canal de comunicaciones. La contraseña se puede enviar al usuario a través de un canal de comunicaciones alternativo que es diferente del canal de comunicaciones principal que facilita la transacción en línea.
[0009] A partir de US 2012/0124651 A1 se conoce un aparato portátil que se puede conectar de forma desmontable y comunicativa a un dispositivo de red para comunicar las credenciales de autentificación o autorización de un usuario en relación con el usuario que inicia sesión o realiza una transacción con un sitio de red. El aparato incluye un puerto de comunicaciones para conectar y desconectar el aparato al y del dispositivo de red y para establecer un enlace de comunicaciones con el dispositivo de red cuando se conecta a este. Un procesador recibe un mensaje seguro del servidor de seguridad de red a través del puerto. El mensaje tiene un PIN para autentificar al usuario en el sitio de red y solo puede leerlo el aparato. El procesador, a través del puerto, transfiere el PIN recibido a una aplicación asociada con el sitio de red que se está ejecutando en el dispositivo de red o hace que el aparato muestre el PIN recibido para la transferencia manual a la aplicación asociada con el sitio de red.
[0010] US 2010/0174900 A1 sugiere un método implementado por ordenador para autentificar a un usuario utilizando un servidor de proveedor de servicios y un servidor de autentificación, en el que el usuario se comunica con al menos uno del servidor del proveedor de servicios y el servidor de autentificación utilizando un navegador de usuario. El método incluye solicitar, mediante el navegador del usuario, la autentificación con el servidor del proveedor de servicios. El método también incluye autentificar, usando el navegador del usuario, un canal de comunicaciones seguro con el servidor de autentificación. El método también incluye recibir, utilizando el navegador del usuario, un valor de Anclaje de preautentificación siguiente a partir del servidor de autentificación. El método incluye adicionalmente el almacenamiento temporal del valor de Anclaje de preautentificación siguiente en una cookie de navegador de usuario asociada con el navegador del usuario, donde el valor de Anclaje de preautentificación siguiente está protegido mediante el uso de la Política del mismo origen.
Objetivos de la invención
[0011] La presente invención está orientada a realizar mejoras adicionales en el sistema y protocolo 2CHK que pueden proporcionar una flexibilidad adicional en la implementación de la autentificación de inicio de sesión 2CHK y/o en la autorización de transacciones en dispositivos informáticos personales y dispositivos de comunicación móvil inteligentes como iPhones y iPads, incluyendo implementaciones con hardware complementario, y/o protección mejorada contra los atacantes.
[0012] Los objetos y ventajas adicionales y características novedosas de la presente invención resultarán evidentes para los expertos en la materia a partir de esta descripción, incluyendo la siguiente descripción detallada, así como mediante la puesta en práctica de la invención. Si bien la invención se describe a continuación con referencia a una o más formas de realización preferidas, debe entenderse que la invención no se limita a estas. Los expertos en la materia que tengan acceso a las enseñanzas del presente 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 en el presente documento y con respecto a los cuales la invención podría ser de gran utilidad.
Descripción resumida de la invención
[0013] De acuerdo con aspectos de la invención, un servidor de seguridad se utiliza para realizar transacciones de consulta a través de una red, como Internet, al recibir, desde un dispositivo de red de usuario a través de la red, una solicitud de un usuario para activar un canal de comunicaciones seguro a través de la red entre el dispositivo de red del usuario y el servidor de seguridad. En respuesta, el servidor de seguridad transmite un código de activación para enviar al usuario a través de otra red. Por ejemplo, el código de activación podría transmitirse a un servicio de autentificación fuera de banda que utiliza la red telefónica conmutada pública o la red celular para el envío de información. Tal servicio estaría preferiblemente representado en la red, aunque no es obligatorio. Por otro lado, el código de activación puede transmitirse de varias maneras al servicio de correo postal, un servicio de correo privado o un servicio de mensajería para entrega en mano o entrega auditiva directa al usuario, en cuyo caso estos servicios serían servicios de envío fuera de banda, ya que el código de autorización se enviaría al usuario fuera de la red, por ejemplo Internet.
[0014] A continuación, el servidor de seguridad recibe un código de activación del dispositivo de red del usuario a través de la red, compara el código de activación recibido con el código de activación transmitido para validar el código de activación recibido y activa el canal de comunicaciones seguro basándose en la validación del código de activación recibido.
[0015] En cualquier momento después de la activación, el servidor de seguridad puede recibir una consulta, incluyendo una pregunta para el usuario, de una empresa representada en la red, como un comercio, un banco o un corredor, etc. La respuesta correcta a la pregunta es la que ha sido previamente acordada por el usuario y la empresa. Por ejemplo, la pregunta de la empresa puede solicitar un secreto, como una contraseña de un solo uso o un testigo (token) de autentificación u otro tipo de secreto, compartido por el usuario y la empresa, por ejemplo una contraseña de usuario o información personal del usuario, por ejemplo la dirección de una casa, un número de teléfono, el nombre del mejor amigo, el apellido de soltera de la madre, la ciudad natal, el nombre de la escuela secundaria, etc. El servidor de seguridad transmite la consulta de la empresa recibida al dispositivo de red del usuario a través del canal de comunicaciones seguro y, en respuesta, recibe una respuesta del usuario a la consulta de la empresa transmitida desde el dispositivo de red del usuario a través del canal de comunicaciones seguro. El servidor de seguridad transmite la respuesta del usuario recibida al sitio de red de la empresa para autentificar el usuario ante la empresa.
[0016] Quizás valga la pena enfatizar en este punto que debe entenderse que el término "red" se usa en este documento de manera genérica para referirse a una red de comunicaciones digitales, de la que las redes de Internet públicas, las redes de área local o las redes privadas seguras son algunos tipos ejemplares. Muchas de las implementaciones de esta invención utilizarán un solo tipo de red para todos los canales de comunicación, por ejemplo Internet, mientras que otras implementaciones podrían usar múltiples tipos de redes diferentes para canales diferentes (por ejemplo, la "red" puede incluir múltiples redes de tipos diferentes con un canal proporcionado a través de una red de tipo privado, mientras que otro canal se proporciona a través de Internet). Por lo tanto, también se entenderá que la invención no requiere que se proporcionen los diferentes canales de comunicación a través de ningún tipo particular de red o a través del mismo tipo de red, sino que solo requiere que la transmisión del código de activación para su envío al usuario sea a través del canal que está fuera del tipo de red utilizado para los otros canales, particularmente los canales utilizados para las comunicaciones entre el usuario y el servidor de seguridad y entre el usuario y la empresa.
[0017] De acuerdo con otros aspectos de la invención, si se desea, el servidor de seguridad puede recibir, desde el sitio de red de la empresa, una notificación de que (i) la respuesta del usuario transmitida es aceptable o (ii) la respuesta del usuario transmitida es inaceptable o (iii) la empresa requiere una autentificación adicional del usuario. Si es así, el servidor de seguridad transmite la notificación recibida al dispositivo de red del usuario a través del canal de comunicaciones seguro.
[0018] Puede ser beneficioso en algunas implementaciones que el servidor de seguridad incorpore, por ejemplo, que tenga integrada, la consulta de la empresa recibida en al menos uno de un flujo de voz y una imagen, de modo que la consulta de la empresa transmitida sea la consulta de la empresa incorporada en al menos uno del flujo de voz y la imagen. Preferiblemente, el flujo de voz es un flujo de voz que tiene una voz reconocible por el usuario, por ejemplo la propia voz del usuario o la voz de una persona famosa, por ejemplo Franklin D. Roosevelt o John F. Kennedy, o Ronald Reagan, y la imagen es una imagen que tiene un fondo conocido por el usuario, como una imagen preseleccionada de, por ejemplo, la Mona Lisa.
[0019] Por lo tanto, debe entenderse que la información puede transmitirse de manera más segura a un usuario a través de una red incorporando información en un flujo de voz que tenga una voz reconocible por el usuario y/o una imagen con un fondo conocido por el usuario, y transmitiendo el flujo de voz y/o la imagen al usuario a través de la red.
[0020] También debe entenderse que el método será implementado típicamente por un servidor con uno o más puertos a través de los cuales se comunica a través de la red y un procesador con la lógica programada, típica pero no necesariamente un software ejecutable, para realizar lo descrito anteriormente.
[0021] También se puede utilizar un servidor de seguridad para realizar transacciones comerciales de forma segura entre un usuario y una empresa, como un comercio, un banco o un corredor, etc., a través de una red al recibir, desde un dispositivo de red de usuario a través de la red, una solicitud del usuario para activar un canal de comunicaciones seguro a través de la red entre el dispositivo de red del usuario y el servidor de seguridad. En respuesta, el servidor de seguridad transmite un código de activación para su envío al usuario a través de otra red.
[0022] En respuesta a la transmisión, el servidor de seguridad recibe un código de activación del dispositivo de red del usuario a través de la red, compara el código de activación recibido con el código de activación transmitido para validar el código de activación recibido y activa el canal de comunicaciones seguro basado en la validación del código de activación recibido. Por ejemplo, todas las comunicaciones posteriores entre el dispositivo de red del usuario y el servidor de seguridad pueden encriptarse con una clave criptográfica simétrica basada en el código de autorización, ya que tanto el usuario como el servidor de seguridad conocen este código en este momento.
[0023] Luego, el servidor de seguridad recibe, desde el dispositivo de red del usuario a través del canal de comunicaciones seguro, información de la transacción que incluye un identificador de una empresa con la que el usuario desea participar en la transacción y detalles de la transacción deseada. Se entenderá que la transacción puede ser prácticamente de cualquier tipo. Las transacciones comunes realizadas a través de redes como Internet incluyen, entre otras, transferencias de dinero desde una cuenta, compras de acciones o bonos y compras de productos o servicios. Los detalles de las transacciones para tales transacciones generalmente incluyen elementos tales como números de cuenta, códigos de productos, montos para transferir o pagar y otra información que se considere apropiada para detallar claramente la transacción con el fin de que no haya una disputa posterior entre el usuario y la empresa sobre lo que el usuario había autorizado. El servidor de seguridad transmite la información de la transacción a la empresa, que también está representada en la red, aunque esta transmisión puede ser a través de un tipo de red diferente de las transmisiones hacia y desde el usuario. Por ejemplo, las transmisiones hacia y desde la empresa pueden ser a través de otro canal de comunicaciones seguro establecido entre la empresa y el servidor de seguridad a través de una red privada virtual (VPN) o alguna red privada segura como la red del Departamento de Defensa de EE. UU. (DOD).
[0024] El servidor de seguridad puede recibir opcionalmente de la empresa, por ejemplo a través de dicho otro canal de comunicaciones seguro, una notificación de que (i) la transacción ha sido aceptada o (ii) la transacción ha sido rechazada o (iii) la empresa requiere autentificación adicional, como una firma de transacción válida, del usuario. Si la notificación recibida es una notificación de que la transacción ha sido aceptada o rechazada, el servidor de seguridad transmite la notificación recibida al dispositivo de red del usuario a través del canal de comunicaciones seguro.
[0025] Si la empresa requiere una firma de usuario válida en la transacción, el servidor de seguridad genera, en función de la información de la transacción recibida, una contraseña de un único uso para que el usuario la utilice como firma de la transacción, y transmite la contraseña de un único uso generada desde servidor de seguridad al dispositivo de red del usuario a través del canal de comunicaciones seguro. La contraseña de un solo uso se genera preferiblemente también en función de un secreto compartido por el servidor de seguridad y la empresa, pero que el usuario no conoce o que no está asociado a ningún usuario en particular. En cualquier caso, a su vez, el servidor de seguridad recibe, de la empresa, la confirmación de recepción por parte de la empresa de la transacción firmada válidamente procedente del usuario, y transmite la confirmación de que la empresa ha recibido la transacción firmada válidamente al dispositivo de red del usuario a través del canal de comunicaciones seguro. Por supuesto, entre la transmisión de la contraseña de un solo uso al dispositivo de red del usuario y la recepción de la empresa de la confirmación de la recepción de la transacción firmada válidamente, el dispositivo de red del usuario transmite la contraseña de un solo uso recibida del servidor de seguridad a la empresa, preferiblemente a través de la red. La invención se describe en las reivindicaciones adjuntas.
Breve descripción de los dibujos
[0026]
La Figura 1 representa componentes de un sistema de seguridad 2CHK, conforme a la presente invención. La Figura 2 representa un dispositivo informático de usuario de la figura 1, sin hardware complementario, conforme a la presente invención.
La Figura 3 representa un dispositivo informático de usuario de la figura 1, con hardware complementario conectado a él, conforme a la presente invención.
Forma(s) de realización preferida(s) de la invención
El sistema 2CHK
[0027] En referencia a la Figura 1, el sistema 2CHK incluye preferiblemente algunos o todos los siguientes:
• Un dispositivo informático de usuario 100, como un ordenador de sobremesa o portátil, un teléfono inteligente o una pizarra inteligente, que se puede conectar a una red, como Internet, y que tiene un medio de entrada 102, como un teclado, un teclado numérico, un ratón u otro medios para introducir las entradas del usuario, y una pantalla 105 capaz de mostrar (1) páginas asociadas con un sitio web, en lo sucesivo denominadas "página del sitio web", en una ventana 110, en lo sucesivo denominada "ventana del sitio web", (2) páginas asociadas con un servidor de seguridad en una ventana 120, en lo sucesivo denominada "ventana de seguridad", y (3) otras páginas asociadas con cualquiera de las diversas aplicaciones que pueden ejecutarse en el dispositivo informático del usuario en cualquier momento dado.
• Un sitio web 130, típicamente representado en la red por un servidor de sitio web, que es accesible para los usuarios a través de la red y en el que el usuario inicia sesión, o desea iniciar sesión, o realiza una transacción y opcionalmente incluye una interfaz de programación de aplicaciones (API) 35 y una API de lógica de administración de claves (KMLWS) 137. Debe entenderse que, en implementaciones prácticas, normalmente habría múltiples sitios web diferentes accesibles a través de la red.
• Un servidor de seguridad 140 que es accesible para los usuarios a través de la red y opcionalmente incluye una API de lógica de administración de claves (KMLS) 147.
• Un servidor de autentificación fuera de banda (OOB) 150, en lo sucesivo denominado el "servidor OOBA".
• Una autoridad de certificación (CA) 170.
• Un dispositivo de comunicación de usuario 160, como un dispositivo por cable, por ejemplo un teléfono fijo convencional o dispositivo móvil, por ejemplo un teléfono móvil o un teléfono inteligente, etc.
• Un canal de comunicaciones 132, establecido a través de la red, para comunicar información entre el sitio web 130 y la ventana del sitio web 110.
• Un canal de comunicaciones seguro opcional 134, establecido a través de la red o de otro modo, para comunicar directamente información entre el sitio web 130 y el servidor de seguridad 140.
• Un canal de comunicaciones 142, establecido a través de la red, para comunicar información entre el servidor de seguridad 140 y la ventana del sitio web 110.
• Un canal de comunicaciones seguro 144, establecido a través de la red, para comunicar información entre el servidor de seguridad 140 y la ventana de seguridad 120.
• Un canal de comunicaciones seguro 146, establecido a través de la red o de otro modo, para comunicar información entre el servidor de seguridad 140 y el servidor OOBA 150.
• Un canal de comunicaciones seguro 148, establecido a través de la red o de otro modo, para comunicar información entre el servidor de seguridad 140 y el CA 170.
• Un canal de comunicaciones 152, establecido a través de una red distinta a la red, para comunicar información entre el servidor OOBA 150 y el dispositivo de comunicación de usuario 160.
[0028] En referencia a la Figura 2, el dispositivo informático del usuario 100 incluye preferiblemente algunos o todos los siguientes:
• Una unidad central de procesamiento (CPU) 205.
• Dispositivos de comunicaciones de red (NCD) 206, como un módem y un puerto, para comunicarse con el sitio web 130 y el servidor de seguridad a través de la red
• Una aplicación de navegador web 207 capaz de ser ejecutada por la CPU 205 (1) para crear una ventana de navegador que sirve como la ventana del sitio web 110, y para generar y mostrar en la ventana del sitio web del navegador 110 páginas del sitio web transmitidas desde el sitio web 130 y otros sitios web (no mostrados) y (2) para crear una ventana emergente del navegador que sirve como la ventana de seguridad 120, y para generar y mostrar en la ventana emergente de seguridad 120 páginas transmitidas desde el servidor de seguridad 140. Las páginas del sitio web mostrado por el navegador 207 a veces pueden denominarse en lo sucesivo páginas web.
• Una aplicación de seguridad 210, que a veces puede denominarse en lo sucesivo la "aplicación de cliente 2CHK", capaz de ser ejecutada por la CPU 205 para crear la ventana de seguridad 120, y generar y mostrar en la ventana de seguridad 2CHK 120, páginas transmitidas desde el servidor de seguridad 140. La aplicación de seguridad 210 puede incluir un Cliente de lógica de administración de claves (KMLC) 213.
• Almacenamiento local, que puede implementarse en el almacenamiento de datos de una memoria y/o un disco duro, incluidos los almacenamientos privados 210a y 212a y el almacenamiento público 210b. • Una aplicación de sitio web 212, tal como una aplicación de un comercio o de un banco, capaz de ser ejecutada por la CPU 205 (1) para crear la ventana del sitio web 110, y para generar y mostrar en la ventana del sitio web 110 páginas del sitio web asociadas con el sitio web 130. Debe entenderse que en implementaciones prácticas podría haber múltiples aplicaciones de sitio web diferentes, cada una asociada con un sitio web diferente accesible a través de la red.
• Una aplicación de servicio de mensajes cortos (SMS) 214, que en lo sucesivo a veces se denominará "SMSA", para enviar y recibir recepción de mensajes de texto.
• Una aplicación de correo electrónico 216, para enviar y recibir correos electrónicos a través de la red. • Una aplicación de procesamiento de documentos 218, como Adobe Acrobat o Microsoft Word, capaz de ser ejecutada por la CPU 205 para generar y mostrar en una ventana (no mostrada) documentos creados o transmitidos, a través de la red, al dispositivo informático. Debe entenderse que, en implementaciones prácticas, podría haber múltiples aplicaciones de procesamiento de documentos diferentes.
• Una aplicación proxy, que a veces puede denominarse en lo sucesivo la "aplicación de cliente proxy 2CHK", capaz de ser ejecutada por la CPU 205 para crear un vehículo seguro para las comunicaciones entre una aplicación de seguridad que se ejecuta en hardware complementario y el servidor de seguridad 140.
• Un puerto 222 para conectar de manera comunicativa el dispositivo informático 100 al hardware complementario.
[0029] En referencia a la Figura 3, el hardware complementario 300, que se puede interconectar y desconectar comunicativamente respecto del dispositivo informático del usuario 100, preferiblemente incluye algunos o todos los siguientes:
• Una pantalla de visualización 302.
• Un medio de entrada 304, como un teclado, un teclado numérico, un ratón u otros medios para introducir las entradas del usuario.
• Una unidad central de procesamiento (CPU) 305.
• Una aplicación de seguridad 310, que a veces puede denominarse en lo sucesivo la "aplicación de cliente 2CHK", capaz de ser ejecutada por la CPU 305 para crear la ventana de seguridad 120 en la pantalla de visualización 302, y para generar y mostrar en la ventana de seguridad 120 páginas transmitidas desde el servidor de seguridad 140. La aplicación de seguridad 310 puede incluir una API 311 y un cliente de lógica de administración de claves (KMLC) 313.
• Almacenamiento local, que puede implementarse en el almacenamiento de datos de una memoria y/o un disco duro, incluyendo el almacenamiento privado 312.
• Un enlace de comunicaciones 320, como uno establecido, por ejemplo, a través de un cable USB, sistema de comunicación de campo cercano (NFC), Bluetooth o un conector para auriculares, etc., para transmitir información entre el puerto 222 del dispositivo informático del usuario 100 al que el hardware complementario 300 está conectado y el hardware complementario 300.
[0030] Como se ha indicado anteriormente, la ventana de seguridad 120 puede mostrarse en la pantalla 105 del dispositivo informático 100 en una ventana de seguridad emergente creada por la aplicación de navegador 207, o en una ventana de seguridad que no es del navegador creada por una aplicación de seguridad 210, es decir, el cliente 2CHK. La ventana de seguridad 120 también puede mostrarse en la pantalla 302 del hardware complementario 300 en una ventana de seguridad que no sea del navegador creada por una aplicación de seguridad 310, es decir, el cliente 2CHK. La aplicación de seguridad 210 puede implementarse en cualquiera de una variedad de factores de forma diferentes. Una variedad contempla que la ventana de seguridad 120 sea controlada por una aplicación de seguridad 210 en un dispositivo informático móvil, como un teléfono inteligente o una pizarra inteligente, por ejemplo por una aplicación de teléfono inteligente de cliente 2CHK. Otra contempla la ventana de seguridad 120 controlada por una aplicación de seguridad 210 en un dispositivo informático de mayor potencia, como un ordenador de sobremesa o portátil, por ejemplo por una aplicación de ordenador personal (PC) del cliente 2CHK. Otra más, como se ha señalado antes, contempla la ventana de seguridad 120 controlada por una aplicación de seguridad 210 ejecutada en hardware complementario específico o no específico 300, tal como una tarjeta inteligente, que tiene capacidades de comunicación. Como se comentará más adelante, estos factores de forma proporcionan capas adicionales de seguridad simplemente al ser independientes del PC del usuario que ejecuta el navegador. Se reconocerá que la implementación en el teléfono inteligente se realiza fácilmente porque el teléfono ya está personalizado y, de acuerdo con las técnicas descritas a continuación, la generación de la OTP se basa en el uso de un secreto compartido solo por el sitio web 130 y el servidor de seguridad 140 y, por lo tanto, el teléfono inteligente no necesita almacenar un secreto especial ni ejecutar software de OTP. Más bien, solo el sitio web 130 y el servidor de seguridad 140 necesitan compartir el secreto necesario y solo el servidor de seguridad 140 y el sitio web 130 necesitan generar las OTP requeridas para la autentificación de inicio de sesión del usuario y la firma de la transacción.
[0031] De acuerdo con algunos aspectos de la invención, la aplicación de seguridad o el cliente 2CHK 210 usa tanto el almacenamiento privado 210a como el almacenamiento público 210b, y la aplicación del sitio web 212 también usa el almacenamiento público 210b así como el almacenamiento privado 212a. Como se describirá con más detalle a continuación, la CPU 205 puede ejecutar la aplicación de seguridad 210 para interactuar con el servidor de seguridad 120 a través del canal de comunicaciones 142 y puede ejecutar el navegador o la aplicación de sitio web 212 para interactuar con el sitio web 130 a través del canal de comunicaciones 132 y el servidor de seguridad 120 a través del canal de comunicaciones 142.
[0032] Como se muestra en la Figura 3, la funcionalidad del cliente 2CHK puede estar disponible en hardware complementario especializado o no especializado 300 que se puede conectar de forma comunicativa, por ejemplo a través de un cable USB, un sistema de comunicación de campo cercano (NFC), Bluetooth o un conector para auriculares, etc., a un dispositivo informático, como un PC o un teléfono inteligente, de manera similar a otros elementos de hardware complementarios. El hardware complementario puede ser de cualquier tipo, incluyendo, por ejemplo, tarjetas inteligentes, un dispositivo de almacenamiento seguro, un dispositivo de visualización seguro o una fuente segura de información de identificación complementaria, como un almacenamiento de certificados, un lector biométrico o un almacenamiento protegido con huella digital, etc. También debe entenderse que el hardware complementario podría ser un teléfono inteligente que se puede conectar de manera comunicativa a un PC y que, en lugar de un ordenador de sobremesa, ordenador portátil o dispositivo móvil inteligente, cualquier dispositivo conectado a Internet, como una consola de videojuegos, un televisor, un reproductor de DVD, etc., podría ser sustituido por el dispositivo informático 100 y ser el punto intermedio que sirve como proxy o vehículo para el hardware complementario. La presencia de la funcionalidad de cliente 2CHK en el hardware complementario puede resultar en una seguridad aún mayor para la protección contra ataques en el propio dispositivo informático 100.
[0033] Al residir la funcionalidad del cliente 2CHK en el hardware complementario, el dispositivo informático 100 (ya sea un ordenador de sobremesa o portátil o un teléfono inteligente o una pizarra inteligente) básicamente actúa como un vehículo (o proxy) para transportar mensajes entre el servidor de seguridad 140 y el hardware complementario conectado al dispositivo informático 100. Es decir, el papel desempeñado por la aplicación de seguridad, es decir, el cliente 2CHK, 210 que se ejecuta en el dispositivo informático 100icubl ahora es desempeñado por la aplicación de seguridad, es decir, el cliente 2CHK, 310 que se ejecuta en el dispositivo complementario.
[0034] El hardware complementario 300 está conectado de forma desmontable al dispositivo informático 100 a través del puerto 222 y el enlace de comunicaciones 320. La aplicación de seguridad, es decir, el cliente 2CHK, 310 es ejecutable por la CPU 315 y tanto el almacenamiento privado 312 como el almacenamiento público 210b del usuario. La aplicación de seguridad, es decir, el cliente 2CHk , 310 interactúa con el servidor de seguridad 140 a través del canal de comunicaciones seguro 144, el proxy 220, el puerto 222 y el enlace de comunicaciones 320. La CPU 205 ejecuta la aplicación de proxy./vehículo 220 para servir, junto con el enlace de comunicaciones 320, el puerto 222 y el canal de comunicaciones 144, como un vehículo de comunicación seguro entre el servidor de seguridad 140 y la aplicación de seguridad 210. También sirve, junto con el enlace de comunicaciones 320 y el puerto 222, como un canal de comunicaciones entre la aplicación de seguridad 310 y el almacenamiento público 210b en el dispositivo informático 100. En consecuencia, las comunicaciones entre el servidor de seguridad 140 y la ventana de seguridad 120 no pueden ser leídas o manipuladas por el dispositivo informático 100 que sirve como "vehículo/proxy". Dicho de otra manera, los datos que pasan a través del dispositivo informático 100 al hardware complementario se encriptan o codifican de tal manera que solo puedan ser leídos por la aplicación de seguridad, es decir, el cliente 2CHK, 310 que se ejecuta en el hardware complementario.
Las operaciones del sistema 2CHK
[0035] Hay 5 fases diferentes de funcionamiento: (i) la configuración y personalización de la ventana de seguridad 120, que es un proceso temporal, (ii) la puesta en marcha o activación de la ventana de seguridad 120, ya sea una ventana de seguridad emergente o una ventana de seguridad 2CHK, que ocurre en intervalos periódicos, similar al inicio de sesión en un ordenador en cada uso, (iii) la autentificación de un sitio web 130 ante el usuario, cuando el usuario navega hasta llegar a un sitio web 130 que se autentifica a sí mismo ante el usuario a través del servidor de seguridad 140, (iv) la autentificación, por ejemplo, para fines de inicio de sesión, de un usuario a un sitio web 130 o aplicación de sitio web 212 por el servidor de seguridad 140, cuando el usuario navega hasta un sitio web 130 o activa una aplicación de sitio web 212, y (v) la autorización de transacciones o firma de transacciones, cuando el usuario navega hasta un sitio web 130 o usa una aplicación de sitio web 212 y desea realizar una transacción particular con el sitio web 130.
La fase de configuración y personalización
[0036] El usuario inicia su asociación con el sistema 2CHK a través de una fase de configuración y personalización, que es un proceso único. Para la configuración, el usuario visita un sitio de red alojado en el servidor de seguridad 140. Si se va a utilizar una aplicación de seguridad, es decir, un cliente 2CHK, 210 o 310 en la implementación, la aplicación de seguridad correspondiente se carga en el dispositivo informático del usuario 100 y se almacena en él o en el hardware complementario 300, típicamente en almacenamiento local, por ejemplo una memoria, un disco duro u otras opciones de almacenamiento local, disponibles en el dispositivo aplicable 100 o 300. Debe entenderse que, en algunas implementaciones, se utilizarán tanto la aplicación de seguridad 210 como la aplicación de seguridad 310 y, por lo tanto, deberán cargarse durante el proceso de configuración. El usuario selecciona una imagen de personalización. Esta imagen se almacena localmente en el dispositivo informático 100 del usuario utilizando cookies. En general, este es un evento único por usuario por cada dispositivo informático de usuario 100, y solo es necesario repetirlo si el usuario desea cambiar la imagen de personalización, o si el almacenamiento local se borra por alguna razón.
La fase de puesta en marcha y activación (Acceso al servidor de seguridad)
[0037] La activación generalmente se realizará de manera periódica, por ejemplo, una vez al día antes de que el usuario comience a navegar por la web. Dependiendo de la implementación, el usuario puede iniciar el proceso de activación manualmente o, alternativamente, el proceso de activación podría iniciarse automáticamente cuando el usuario visita un sitio web 130 que participa en el sistema 2CHK. A partir de entonces, el servidor de seguridad 140 activará la ventana de seguridad 120 basándose en la validación del usuario a través de OOBA a través del servidor de OOBA 150. Sin embargo, debe entenderse que otras formas de validación, que no sean OOBA, podrían usarse en esta fase, si se desea. Se reconocerá que otras formas de validación pueden proporcionar una integración más fácil del sistema 2CHK con las implementaciones de OTP existentes.
[0038] Usando lo que comúnmente se conoce como un modelo OOBA "abierto" para la puesta en marcha, el usuario activa preferiblemente la activación de la siguiente manera. Para validar el usuario ante el servidor de seguridad 140, o bien (1) el usuario introduce su número de teléfono, por ejemplo teléfono fijo, teléfono móvil o número de teléfono móvil inteligente, en la ventana de seguridad 120 mostrada por la aplicación de seguridad, es decir, el cliente 2CHK, 210 o 310, o la aplicación de navegador 207 (si la ventana de seguridad es una ventana emergente de seguridad del navegador), que se ejecuta en el dispositivo informático 100, por ejemplo, un ordenador de sobremesa o un teléfono inteligente, o hardware complementario 300, o bien (2) la aplicación de seguridad 210 o 310 o el navegador 207 obtienen el número directamente del dispositivo informático del usuario 100. El número de teléfono introducido u obtenido se transmite desde el dispositivo informático 100 al servidor de seguridad 140 a través del canal de comunicaciones 144 o desde el hardware complementario 300 al servidor de seguridad 140 a través del enlace de comunicaciones 320 y el canal 144.
[0039] El servidor de seguridad 140 comunica un código de seguridad de inicio de sesión al servidor OOBA 150 a través del canal de comunicaciones 146. El servidor OOBA 150 se comunica con el teléfono móvil, la pizarra inteligente o el teléfono 160 del usuario, a través del canal de comunicaciones 152, para proporcionar al usuario el código de seguridad de inicio de sesión para autentificar al usuario ante el servidor de seguridad 140. La transmisión por parte del servidor OOBA 150 del código de activación al usuario puede incluir, entre otros, mensajes de texto, llamadas de voz, correo electrónico o cualquier otro canal de comunicaciones que sea sustancialmente diferente del canal mediante el cual la aplicación de seguridad 210 o 310 o el navegador 207 o la ventana de seguridad 120 se comunican con el servidor de seguridad 140, lo que dificulta sustancialmente que ambos canales se vean comprometidos.
[0040] Si el canal de comunicaciones 152 es interactivo, lo que generalmente será el caso, el canal de comunicaciones 152 puede utilizarse opcionalmente para interactuar con el usuario para autentificarlo de manera más completa antes del envío del código de activación, al capturar información de autentificación adicional para comparar con información de identidad accesible por el servidor OOBA 150, incluidos, entre otros, secretos compartidos, información de ubicación geográfica e identificadores biométricos.
[0041] Se envía un hash con clave del código de seguridad, o el propio código de seguridad sin hash, al servidor de seguridad 140 a través de un canal de comunicaciones cifrado 144, y el enlace 320 si corresponde. Dicha validación del usuario al servidor de seguridad 140 se realiza, por supuesto, antes de que el servidor de seguridad 140 proporcione al usuario, a través de la ventana de seguridad 120, las credenciales necesarias para la autentificación en el sitio web 130, por ejemplo para iniciar sesión en el sitio web o para autorizar una transacción con el sitio web 130.
[0042] Por otro lado, si se utiliza lo que comúnmente se conoce como un modelo OOBA de "asociación" para la puesta en marcha, la activación es preferiblemente activada por, por ejemplo, el sitio web de una empresa 130, en lugar del usuario. En consecuencia, el usuario no tiene necesidad de introducir un número de teléfono en la aplicación de seguridad y, por lo tanto, no lo hace, por ejemplo el cliente 2CHK, 210 o 310 en el modelo de asociación OOBA. En cambio, el usuario inicia sesión en, por ejemplo, el sitio web 130 de una empresa utilizando un mecanismo de seguridad del sitio web 130 transmitido por la aplicación de navegador 207, o un mecanismo de seguridad de la aplicación del sitio web 212, como una combinación de identificador de usuario y contraseña. El usuario solicita la asociación 2CHK mediante la selección de una página web del sitio web 130 presentada por la aplicación de navegador 207 del usuario o la aplicación del sitio 212 web en la ventana del sitio web 110.
[0043] Por ejemplo, se le puede pedir al usuario que solicite la asociación 2CHK seleccionando información de identificación, incluyendo información de contacto, como una dirección o número de teléfono enmascarado/a, es decir, una dirección o número de teléfono que está disponible a priori para el sitio web 130, y que no se muestra completamente al usuario, por ejemplo 415.680.xxxx. En tal caso, el sitio web 130 envía una solicitud de asociación con un número de teléfono, por ejemplo un teléfono fijo, o un número de teléfono móvil, al servidor de seguridad 140 para su uso por el servidor de seguridad 140 en la autentificación y activación del usuario. Debe tenerse en cuenta que, si se desea, la información de contacto podría ser, en lugar de información para contactar con el usuario a través de una llamada telefónica, información para contactar con el usuario mediante entrega en mano, intercambio NFC/Bluetooth o consulta de autentificación basada en conocimientos (KBA), etc..., con la información de identificación aplicable, preferiblemente enmascarada, seleccionada por el usuario. Alternativamente, se le puede pedir al usuario que solicite la asociación de 2CHK simplemente haciendo clic en un cuadro de activación de 2CHK. En tal caso, el sitio web 130 puede, si lo desea, generar y enviar un código de activación de empresa al servidor de seguridad 140 para que el servidor de seguridad lo use para autentificar y activar al usuario.
[0044] El sitio web 130 o la aplicación del sitio web 212 transmite una solicitud de asociación, preferiblemente con la información de identificación, incluyendo la información de contacto seleccionada completa, por ejemplo el número de teléfono completo seleccionado, por ejemplo 415.680.0000, o información de identificación del usuario (no seleccionada por el usuario) y un código de activación de empresa, al servidor de seguridad 140 a través de los canales de comunicaciones 132 y 142 entre la ventana del sitio web 110 y el servidor de seguridad 140, o a través de un canal de comunicaciones seguro directo 134 entre el sitio web 130 y el servidor de seguridad 140, según corresponda.
[0045] A partir de este punto, el servidor de seguridad 140 procede de manera idéntica al modelo "abierto", con la excepción de que la información de identidad disponible, y quizás un código de activación, para la comparación OOBA ahora proviene tanto del servidor de seguridad como de la empresa. La información o el código de identidad es preferiblemente exclusivo de la solicitud aplicable para la empresa aplicable y se envía simultáneamente al usuario final, por ejemplo a través de la red telefónica conmutada pública (PSTN), y se almacena dentro del servidor de seguridad 140. El servidor de seguridad 140 espera a que una aplicación de seguridad, es decir, el cliente 2CHK, 210 o 310 proporcione el código de activación del servidor de seguridad, y el código de activación de la empresa si corresponde y, al recibir el/los código(s), vincula la aplicación de seguridad, es decir, el cliente 2CHK, 210 o 310 a la solicitud particular de, por ejemplo, el sitio web 130 de la empresa. Esto es, se envía un hash con clave del/de los código(s) de seguridad al servidor de seguridad 140 a través del canal de comunicaciones cifrado 144, y el enlace 320 si corresponde. Si el usuario es validado por el servidor de seguridad en función de los códigos recibidos, las comunicaciones adicionales entre el servidor de seguridad 140 y la aplicación de seguridad, es decir, el cliente 2CHK, 210 o 310 se cifran utilizando los códigos de activación, directa o indirectamente, de modo que el canal de comunicaciones 144 y el enlace 320, si corresponde, sean seguros. En este caso, por supuesto, dicha validación del usuario ante el servidor de seguridad 140 se realiza después de que el usuario haya proporcionado las credenciales necesarias para autentificarse en el sitio web 130, por ejemplo para iniciar sesión en el sitio web, pero antes de que el servidor de seguridad 140 proporcione al usuario, a través de la ventana de seguridad 120, las credenciales, transmitidas a través del canal de comunicaciones seguro 144, y el enlace 320, si corresponde, necesarios para autorizar una transacción con el sitio web 130.
[0046] La importancia de la asociación entre el usuario y la empresa con el sistema 2CHK es la vinculación a una cuenta/relación particular para una empresa particular. Por lo tanto, en este caso la empresa controla el proceso, al permitir o habilitar que la aplicación de seguridad, es decir, el cliente 2CHK, 210 o 310 se asocie a una cuenta particular.
[0047] Una vez que el usuario se valida a través de OOBA, la ventana de seguridad 120 se activa y ocupará una cantidad relativamente pequeña de espacio en el dispositivo informático del usuario 100 o el hardware complementario 300. El acto de iniciar la ventana de seguridad 120 también da como resultado que el servidor de seguridad 140 implante un objeto de sesión local, por ejemplo, una cookie de sesión, en el dispositivo informático del usuario 100 o hardware complementario 300. En este punto, el servidor de seguridad 140 tendrá un canal de comunicaciones seguro activo 144 abierto para el usuario que identifica mediante algún identificador de usuario, por ejemplo, el número de teléfono utilizado para la OOBA.
[0048] El cifrado de la información transmitida a través del canal de comunicaciones 144 se hace en dos niveles. Primero, todo el tráfico se ejecuta a través de SSL. En segundo lugar, todo el tráfico también se cifra en el nivel de la aplicación utilizando una clave derivada de la seguridad utilizada por el usuario para iniciar sesión en el servidor de seguridad 140. Cabe señalar que, ya que la ventana de seguridad 120 y el servidor de seguridad 140 se comunicarán a través de SSL, es altamente preferido que se usen certificados EV-SSL. Los certificados tanto SSL como EV-SSL son ampliamente conocidos y entendidos por los expertos en la materia.
[0049] En el caso de que el dispositivo informático 100 o el hardware complementario 300 sea un teléfono inteligente u otro dispositivo inteligente de comunicaciones móviles, pueden implementarse algunas operaciones, si se desea, para aprovechar ciertas características y capacidades comunes de los teléfonos inteligentes.
[0050] Por ejemplo, puede ser beneficioso para el servidor OOBA 150 transmitir el código de seguridad al usuario en un mensaje de texto. En tal caso, después de que el usuario reciba el mensaje de texto con el código de seguridad de inicio de sesión a través de la SMSA 214, puede introducir el código de seguridad de inicio de sesión recibido en la ventana de seguridad 120 presentada por la aplicación de seguridad 210, es decir, el cliente 2CHK, que se ejecuta en el teléfono inteligente 100, o mediante la aplicación de seguridad 310, es decir, el cliente 2CHK, que se ejecuta en el hardware complementario 300 conectado al teléfono inteligente 100, para iniciar sesión, es decir, validarse, en el servidor de seguridad 140. En algunas plataformas de teléfonos inteligentes, la aplicación de seguridad 210 puede configurarse, si se desea, para recuperar el código de seguridad de inicio de sesión de la secuencia de mensajes de texto entrantes y completar automáticamente el código de seguridad de inicio de sesión en la ventana de seguridad 120, lo que lo hace todavía más fácil para los usuarios.
[0051] En cualquier caso, el mensaje de retorno a la aplicación de seguridad, es decir, el cliente 2CHK, 210 o 310 del servidor de seguridad 140, si el código de seguridad reenviado es válido, es una cookie de sesión, un número aleatorio que se denomina "nonce-login" y un tiempo de vida (TTL). La cookie de sesión se almacena de forma privada, en el almacenamiento privado 210a o 312, según corresponda. El nonce-login y el TTL se almacenan públicamente en un portapapeles personalizado, la aplicación de seguridad o el portapapeles público del cliente 2CHK, que se crea dentro del almacenamiento público 210b. Cuando el usuario centra su atención en la aplicación de seguridad, es decir, el cliente 2CHK, 210 o 310, la aplicación de seguridad 210 siempre verifica el nonce y el TTL para asegurarse de que el TTL no haya expirado.
[0052] Una vez que el usuario ha iniciado sesión en el servidor de seguridad 140, puede comenzar a usar otras aplicaciones, como la aplicación del sitio web 212 o la aplicación de navegador 207, y volver a la aplicación de seguridad, es decir, el cliente 2CHK, 210 según sea necesario.
[0053] Como se ha descrito anteriormente, el usuario completa la activación en dos pasos, por ejemplo, (i) introduciendo el número de teléfono o móvil del usuario en la ventana de seguridad 120 presentada por la aplicación de seguridad 210 o 310 que se ejecuta en el dispositivo informático del usuario 100 o hardware complementario 300, según corresponda, y (ii) recibiendo un código de activación del servidor OOBA 150 en el número introducido por mensaje de voz o de texto, e introduciendo el código de activación recibido en la ventana de seguridad 120 para reenviarlo al servidor de seguridad 140. El paso (ii) sucede inmediatamente después del paso (i), y luego el usuario está listo para recibir transacciones a través del sistema 2CHK.
[0054] Sin embargo, podría surgir un problema potencial porque el servidor OOBA 150 envía el código de activación que recibe del servidor de seguridad 140 al número de teléfono (a través de mensajes de voz o de texto) sin saber nada sobre el número. Si bien esto no abre el sistema a ataques de suplantación, puede abrir el sistema a ataques molestos, por ejemplo cuando un atacante introduce el número de la pizzería con servicio a domicilio del lugar y un usuario posteriormente deniega, en lugar de aprobar, la transacción, por ejemplo el pedido de pizza, enviado por un sitio web, por ejemplo el de la pizzería con servicio a domicilio del lugar. Es decir, en un modelo abierto, un atacante podría introducir el número de teléfono del usuario en la aplicación de seguridad, es decir, el cliente 2CHK, 210 o 310 para comenzar la activación. Esto técnicamente no es un ataque, pero el usuario recibirá una llamada o un mensaje de texto molesto del servidor OOBA como resultado.
[0055] Al modificar el proceso de activación anterior de modo que los pasos de activación se realicen de manera escalonada, este problema potencial se puede mejorar. Más particularmente, al usar la activación escalonada, el usuario introduce el número de teléfono en la ventana de seguridad 120 presentada por la aplicación de seguridad 210 o 310 que se ejecuta en el dispositivo informático 100 del usuario o el hardware complementario 300, según corresponda, de la manera habitual. Sin embargo, en lugar de recibir inmediatamente un código de activación del servidor OOBA 150 en el número introducido, se notifica al usuario en el número introducido que está "casi activado" y que la activación se completará más tarde. Más tarde, cuando, por ejemplo, el sitio web 130 de una empresa desea enviar una transacción a un usuario identificado por un número de teléfono, el sitio web 130 del a empresa, por ejemplo, envía la transacción y el número de teléfono que identifica al usuario al servidor de seguridad 140. Si el servidor de seguridad 140 tiene ese número de teléfono (combo de dispositivo) en el estado "casi activado", primero envía un código de activación al servidor OOBA 150 para completar la activación del usuario de la manera normal. Una vez que se completa la activación, el servidor de seguridad 140 envía la transacción, a través del canal de comunicaciones 144, a la ventana de seguridad 120 en el dispositivo informático del usuario 100. Posteriormente, las transacciones posteriores se manejan de la manera habitual, ya que el usuario ahora está completamente activado, y no requerirá la finalización de la activación.
La fase de autentificación del sitio web
[0056] Un sitio web 130 que participa en el sistema 2CHK incrustará, en la página web que se está visitando mediante el navegador 207 o en la página del sitio web presentada por la aplicación 212 del sitio web, un código para acceder al sistema 2CHK. Por lo general, esto será en forma de código Javascript dentro de un iFrame. El código llegará al servidor de seguridad 140 con una solicitud, un acto que transfiere al servidor de seguridad 140 el objeto de sesión local previamente plantado.
[0057] El servidor de seguridad 140 comprueba una etiqueta de referencia o de origen de la solicitud del iFrame con una lista blanca y/o una lista negra conocida de sitios permitidos/prohibidos. Luego responde al iFrame y simultáneamente señala la ventana de seguridad 120 con la que se está comunicando. La señal consta de dos partes, primero una indicación de si el sitio web 130 es "bueno", "malo", o de si el servidor de seguridad 140 "no conoce" el sitio web 130. La segunda parte de la señal es una imagen aleatoria que se envía (si el sitio web 130 es legítimo) a la ventana de seguridad 120 y al iFrame. Para un sitio web legítimo 130, la ventana de seguridad del usuario 120 tendrá una señal visual (por ejemplo, una luz verde) de que el sitio web 130 es "bueno" y mostrará una imagen aleatoria. El iFrame también mostrará una señal visual similar y críticamente también mostrará la misma imagen aleatoria. Si el sitio web 130 estaba en una lista negra, la ventana de seguridad 120 mostrará una señal visual (por ejemplo, una luz roja) que indica que el sitio web 130 es "malo".
[0058] Los atacantes que intentan vencer al sistema 2CHK creando una ventana de seguridad falsa se ven frustrados porque no conocerán la imagen de personalización. Asimismo, un atacante que intente mostrar la señal visual en el iFrame no tendrá éxito, ya que desconoce la imagen aleatoria que se envía a la ventana de seguridad 120. Finalmente, un sitio web falsificado no podrá manipular la etiqueta de referencia o de origen al inspeccionarlo el navegador.
La fase de autentificación de usuario (por ejemplo, inicio de sesión en el sitio web)
[0059] Preferiblemente, durante el inicio, el usuario se autentifica ante el servidor de seguridad 140 usando una técnica OOBA realizada por el servidor OOBA 150, a petición del servidor de seguridad 140, para demostrar la posesión de un número de teléfono. Después de que esto haya ocurrido, el servidor de seguridad 140 está en condiciones de responder a las solicitudes de comprobación de identidad del usuario del sitio web 130. Para hacerlo, el servidor de seguridad 140 y cada sitio web respectivo 130 dentro del sistema 2CHK han acordado a priori un secreto compartido diferente para todos los usuarios que participan en el sistema 2CHK que visiten ese sitio web. Es decir, el servidor de seguridad y cada sitio web 130 tienen un secreto compartido que ningún usuario u otro sitio web conoce y que no está asociado a ningún usuario en particular.
[0060] Cuando el usuario se encuentra en un sitio web 130 o una aplicación de sitio web 312 que solicita autentificación, y el sitio web 130 o la aplicación de sitio web 212 comunica esta solicitud al servidor de seguridad 140, el servidor de seguridad 140 calcula una OTP de inicio de sesión, es decir, credenciales de inicio de sesión, en función del secreto compartido con ese sitio web 130 y, si se desea, alguna otra información. Por ejemplo, la OTP podría construirse basándose también en una marca de tiempo o un algoritmo de OTP basado en un contador, y el servidor de seguridad 140 comunicaría la hora o el valor del contador al sitio web 130 o la aplicación 212 del sitio web, o podría calcularse potencialmente de manera determinista utilizando alguna fórmula acordada previamente. El servidor de seguridad 140 transporta la OTP calculada a la aplicación de navegador 207 o la aplicación de seguridad 210, es decir, el cliente 2CHK, para mostrar en el usuario en la ventana de seguridad 120. El usuario introduce (por ejemplo, cortando, pegando o escribiendo) esta OTP de inicio de sesión mostrada en el área apropiada de la página del sitio web que solicita credenciales de usuario, que se muestran en el dispositivo informático del usuario 100 mediante el navegador 207 o la aplicación 212 del sitio web, para autentificar al usuario en el sitio web 130 o la aplicación 212 del sitio web.
[0061] Después de recibir la OTP de inicio de sesión introducida, el sitio web 130 autentifica al usuario volviendo a calcular la OTP utilizando el secreto que comparte con el servidor de seguridad 140. En consecuencia, el sistema 2CHK tiene todas las propiedades de seguridad de los sistemas OTP convencionales, pero tiene la tremenda ventaja de que no requiere un secreto compartido con cada usuario, y solo el servidor de seguridad 140 y los sitios web 130 necesitan secretos compartidos con el fin de generar OTP.
[0062] Por ejemplo, en una aplicación práctica, el usuario, utilizando el navegador 207 o la aplicación 212 del sitio web, introduce una solicitud en la ventana del sitio web 110 para acceder a cierta información en el sitio web 130. La solicitud se transmite desde la ventana del sitio web 110 al sitio web 130, a través de canal de comunicaciones 132. El servidor web 130 transmite esta solicitud al servidor de seguridad 140 a través de la aplicación de navegador 207 del usuario o la aplicación de sitio web 212 a través de los canales de comunicación 132 y 142, o a través del enlace de comunicaciones directa opcional 134 entre el sitio web 130 y el servidor de seguridad 140, según corresponda.
[0063] El servidor de seguridad 140 calcula una OTP de inicio de sesión, que a veces se denomina un número de identificación personal (PIN), para el inicio de sesión en el sitio web para autentificar al usuario en el sitio web 130. La OTP de inicio de sesión se calcula en función del secreto que el servidor de seguridad 140 comparte con ese sitio web en particular 130. Como se ha señalado anteriormente, este secreto compartido es desconocido para el usuario y no está asociado con el usuario ni con ningún otro usuario en particular. El servidor de seguridad 140 luego transmite esta OTP de inicio de sesión a la ventana de seguridad del usuario 120 a través del canal de comunicaciones seguro 144.
[0064] El usuario corta y pega o copia esta OTP de inicio de sesión en la página del sitio web que se muestra mediante el navegador web 207 o la aplicación 212 del sitio web en la ventana del sitio web 110 y la OTP de inicio de sesión se transmite al sitio web 130 a través del canal de comunicaciones 132.
[0065] El sitio web 130 calcula independientemente la contraseña de inicio de sesión utilizando el secreto que comparte con el servidor de seguridad 140, y la compara con la recibida del usuario. Si los dos coinciden, entonces el sitio web 130 puede estar seguro de que el servidor de seguridad 140 está autentificando al mismo usuario que ha solicitado acceso (es decir, no a otra persona que finge ser el usuario que ha interceptado la solicitud de camino al servidor de seguridad 140). Además, dado que el servidor de seguridad 140 muestra la OTP de inicio de sesión del usuario en un canal independiente 144, se obtiene la confirmación del usuario de la solicitud.
[0066] Cabe señalar que la aplicación de seguridad, es decir, el cliente 2CHK, 210 se puede programar para comunicarse con las otras aplicaciones, por ejemplo una aplicación de sitio web 212 o una aplicación que no es de navegador 218, utilizando el método más apropiado.
[0067] Una ventaja única de la implementación del teléfono inteligente es la capacidad de usar el almacenamiento público compartido, como los portapapeles públicos en el sistema operativo de los iPhones. En consecuencia, después de que el usuario confirme su deseo de acceder a la aplicación del sitio web 212, y el servidor de seguridad transmita una OTP de inicio de sesión, es decir, credenciales de autentificación de inicio de sesión del usuario, a la aplicación de seguridad 210 a través del canal de comunicaciones 144, la aplicación de seguridad transfiere la OTP de inicio de sesión a la aplicación del sitio web 212 utilizando el almacenamiento compartido 210b del teléfono inteligente. Sin embargo, debe entenderse que, si se desea, se le podría solicitar al usuario que copie manualmente la OTP de inicio de sesión desde la ventana de seguridad 120 a la página del sitio web que muestra la aplicación del sitio web 212, en lugar de que la OTP se complete automáticamente. En cualquier caso, después de que la OTP se haya completado en la página del sitio web que se muestra, cuando el usuario hace clic en "completar inicio de sesión", la aplicación del sitio web 212 envía la OTP de inicio de sesión al sitio web 130 a través del canal de comunicaciones 132.
[0068] El nonce-login y el TTL se pueden escribir de manera beneficiosa en la aplicación de seguridad, es decir, el cliente 2CHK, el portapapeles público 210 en el almacenamiento público 210b. La OTP de inicio de sesión también se puede escribir de manera beneficiosa en el portapapeles, utilizando el identificador del sitio web y la combinación de PIN, que a veces se denomina merchantid.PIN (PIN de identificación de comerciante). El merchantid.PIN se escribe sobre cualquier merchantid.PIN previamente escrito. También se debe tener en cuenta que la aplicación 212 del sitio web verifica si hay una aplicación de seguridad 210 pública que tenga una etiqueta de inicio de sesión con TTL válido para el usuario o asociado a cualquier usuario en particular. De lo contrario, informa al usuario de que no parece haber iniciado sesión en el sistema 2CHK.
[0069] En el caso de la autentificación de inicio de sesión, la aplicación de seguridad, es decir, el cliente 2CHK, 210 publica la información relacionada con el comerciante y la solicitud de autentificación en el servidor de seguridad 140. La publicación incluye el login-nonce. La aplicación 212 del sitio web sondea el portapapeles 210 de la aplicación de seguridad, es decir, el cliente 2CHK, para ver si hay un nuevo merchantid.PIN. Una vez que la aplicación del sitio web 212 lo localiza, realiza una publicación en el sitio web 130 de la cadena y la OTP de inicio de sesión. El sitio web 130 devolverá un mensaje de éxito o error, después de que haga su propia verificación de la OTP de inicio de sesión.
La fase de autorización de la transacción (por ejemplo, firma de transacción)
[0070] Cuando el sitio web 130 recibe una solicitud de transacción de un navegador de usuario 110 que desea confirmar, envía la información de la transacción al servidor de seguridad 140, ya sea a través del navegador de usuario 110, o mediante un canal de comunicaciones directo 134 entre el sitio web 130 y el servidor de seguridad 140, como se ha mencionado anteriormente. El servidor de seguridad 140 reenvía la información de la transacción a la ventana de seguridad del usuario 120, junto con una OTP de la transacción, es decir, la firma de la transacción, que servirá como la firma del usuario en la transacción. La OTP de la transacción es calculada por el servidor de seguridad 140 basándose en un secreto compartido entre el servidor de seguridad 140 y el sitio web 130 y en la información de la transacción y en otra información tal como una marca de tiempo o un algoritmo de OTP basado en contador, si se desea. Como se ha indicado anteriormente, el usuario no conoce el secreto compartido ni este está asociado con ningún usuario en particular. Es decir, no se requiere un secreto compartido por el usuario.
[0071] El usuario transfiere la OTP de esta transacción, es decir, la firma de la transacción, al sitio web 130 a través de la ventana del sitio web 110.
[0072] El sitio web vuelve a calcular la OTP de la transacción, es decir, la firma de la transacción y, si hay una coincidencia entre la OTP calculada por el sitio web 130 y la recibida desde la ventana del sitio web 110, el sitio web puede estar seguro de que el usuario ha confirmado la transacción.
[0073] En una aplicación práctica, el usuario, que está visitando el sitio web 130, selecciona una transacción de una página web del sitio web 130 que se muestra en la ventana del sitio web 110 por la aplicación del navegador 207 o la aplicación del sitio web 212, por ejemplo "Pagar a Alice $ 100", que se transmite desde la ventana del sitio web 110 al sitio web 130 a través del canal de comunicaciones 132. El sitio web 130 transmite esta transacción al servidor de seguridad 140, ya sea a través del navegador 207 del usuario a través de los canales de comunicación 132 y 142 o a través de un canal de comunicaciones directa 134 entre el sitio web 130 y el servidor de seguridad 140, según corresponda.
[0074] El servidor de seguridad 140 calcula una firma de transacción, es decir, una OTP de transacción, en función de (i) los detalles de la transacción (ii) el secreto que comparte con ese sitio web particular 130, y opcionalmente otra información. El servidor de seguridad 140 luego transmite esta firma de transacción a la ventana de seguridad 120 del usuario a través del canal de comunicaciones 144 y, si corresponde, el enlace de comunicaciones 320.
[0075] El usuario corta y pega o copia esta firma de transacción en una página del sitio web 130 que se muestra en la ventana del sitio web 110 por el navegador 207 o la aplicación 212 del sitio web, y la firma de la transacción se transmite al sitio web 130 a través del canal de comunicaciones 132. El sitio web 130 calcula de manera independiente la firma de la transacción utilizando (i) los detalles de la transacción (ii) el secreto que comparte con el servidor de seguridad 140 y, si corresponde, otra información, y la compara con la recibida del usuario. Si las dos firmas de transacción coinciden, entonces el sitio web 130 puede estar seguro de que el servidor de seguridad 140 había visto la misma transacción enviada (es decir, no una transacción manipulada en el trayecto hacia el servidor de seguridad 140) y, dado que el servidor de seguridad 140 muestra al usuario la transacción en un canal independiente 144, también se obtiene la confirmación del usuario de la transacción.
[0076] En resumen, la vinculación entre el usuario, el servidor de seguridad 140 que actúa como proveedor de identidad y el sitio web 130, que es la parte fiable en el caso de transacciones realizadas a través de una red, como la compra de un producto o la transferencia de dinero por un usuario en el sitio web, se fortalece significativamente. De nuevo, debe entenderse que el sistema tiene todas las propiedades de seguridad de las OTP, pero tiene la gran ventaja de que no requiere un secreto compartido con cada usuario, y solo el servidor de seguridad 140 y cada uno de los sitios web, como el sitio web 130, necesitan secretos compartidos con el fin de generar OTP utilizadas como firmas en las transacciones. Como también se ha señalado anteriormente, la OTP real también puede, si se desea, construirse en función de una marca de tiempo o un algoritmo de OTP basado en un contador (por ejemplo, algoritmos utilizados de tal manera que el servidor de seguridad 140 comunique la hora o el valor del contador al sitio web 130) o potencialmente puede calcularse de manera determinista utilizando alguna fórmula acordada previamente.
[0077] De nuevo en este caso, como se ha indicado anteriormente, en el caso de que el dispositivo informático 100 sea un teléfono inteligente u otro dispositivo inteligente de comunicaciones móviles, determinadas operaciones pueden, si se desea, implementarse para aprovechar algunas características y capacidades comunes del teléfono inteligente.
[0078] Una ventaja única de la implementación del teléfono inteligente es la capacidad de usar el almacenamiento público compartido, como los portapapeles públicos en el sistema operativo de los iPhones. En consecuencia, la aplicación del sitio web 212 publica la transacción en el servidor de seguridad 140 a través del canal de comunicaciones 142, y también solicita al usuario que autorice la transacción en la ventana de seguridad 120. Esto es similar a la redirección de un usuario a un sitio web de pagos, como PayPal ™, para autorizar una transacción. El servidor de seguridad 140 publica la transacción en la aplicación de seguridad, es decir, el cliente 2CHK, 210 a través del canal de comunicaciones 144 para su presentación al usuario. Después de que el usuario confirme su deseo de proceder con la transacción al servidor de seguridad 140, y el servidor de seguridad transmite la OTP de la transacción, es decir, la firma de la transacción, a la aplicación de seguridad, es decir, el cliente 2CHK, 210 a través del canal de comunicaciones 144, la aplicación de seguridad 210 transfiere la OTP de la transacción a la aplicación del sitio web 212 usando el almacenamiento compartido del teléfono inteligente 210b. Sin embargo, debe entenderse que, si se desea, se le podría solicitar al usuario que copie manualmente la OTP de la transacción desde la ventana de seguridad 120 a la página presentada en la ventana del sitio web que muestra la aplicación del sitio web 212, en lugar de que la OTP se complete automáticamente. En cualquier caso, después de que la OTP se haya completado en la página del sitio web que se muestra, cuando el usuario hace clic en "completar inicio de sesión", la aplicación del sitio web 212 envía la OTP de la transacción al sitio web 130 a través del canal de comunicaciones 132.
[0079] Al igual que con la OTP de inicio de sesión, la OTP de la transacción también se puede escribir de manera beneficiosa en el portapapeles, utilizando la combinación del identificador de comerciante del sitio web, es decir, merchantid, y el PIN. El merchantid.PIN se escribe sobre cualquier merchantid.PIN previamente escrito. También debe tenerse en cuenta que la aplicación 212 del sitio web verifica si hay una aplicación de seguridad, es decir, un cliente 2CHK, un portapapeles público 210 y, de ser así, sondea el portapapeles para ver si hay una nueva OTP de transacción. Una vez que la aplicación del sitio web 212 la localiza, publica una publicación en el sitio web 130. El sitio web 130 devolverá un mensaje de éxito o error, después de que haga su propia verificación de la OTP de la transacción.
[0080] Para proteger adicionalmente la integridad de la información de la transacción transmitida desde la aplicación de navegador del servidor de seguridad 207 o la aplicación de seguridad 210 o 310 para su visualización en la ventana de seguridad, la información de la transacción se puede enviar utilizando formularios de presentación que son difíciles de manipular sin detección, especialmente la detección de solo una parte de la información transmitida. En este sentido, las grabaciones de voz y las imágenes son mucho más difíciles de manipular que el texto.
[0081] Por ejemplo, sería muy difícil cambiar una grabación de voz realizada en el servidor de seguridad 140 que dice, en una voz específica reconocible para el usuario, la frase "Si acepta pagarle a John mil dólares, introduzca 34567" a "Si está de acuerdo en pagarle a Evan mil dólares, introduzca 34567", sin que el atacante tenga un software complejo de manipulación del habla y acceso a la misma voz reconocible por el usuario o conocimiento de esta. Si una voz específica, como una elegida por el usuario durante la configuración, o una imagen de fondo, se utiliza de manera constante en las interacciones con el usuario, el usuario detectará más fácilmente cualquier cambio.
[0082] De acuerdo con otro aspecto de la presente invención, los detalles de la transacción se presentan de una forma que el usuario puede entender pero que es más difícil de manipular que el texto puro. Por ejemplo, los detalles de la transacción pueden presentarse en la ventana de seguridad 110 como un flujo de voz de una voz reconocible por el usuario con los detalles de la transacción integrados, o como una imagen que utiliza un fondo reconocible por el usuario con los detalles de la transacción integrados en ella. Además, la información podría presentarse en la ventana de seguridad 110 como una presentación multimedia que incluye tanto un flujo de voz como una imagen como se ha descrito anteriormente. En tal caso, se requiere que el usuario extraiga, de la presentación, los detalles de la transacción antes de decidir si los detalles de la transacción presentados están de acuerdo con lo que el usuario entiende que son los detalles de la transacción. Además, el servidor de seguridad se puede configurar para presentar el contenido de varias maneras, por ejemplo, dependiendo del riesgo percibido o determinado, incluyendo solo texto, o solo una imagen, o solo una transmisión de voz, o en multimedia incluyendo una transmisión de imagen y voz, o en texto con una opción para multimedia, o en multimedia con una opción para texto, etc.
[0083] El sistema 2CHK también se puede adaptar para transacciones iniciadas por el usuario. Sin embargo, tales transacciones se limitan típicamente a usuarios con los que el sistema 2CHK tiene una asociación, es decir, un usuario que tiene una asociación preestablecida y actualmente activa con el servidor de seguridad 140. Las transacciones iniciadas por el usuario también se limitan típicamente a empresas con las que 2CHK el sistema tiene una asociación, es decir, una empresa que tiene una relación preestablecida y actualmente activa con el servidor de seguridad 140, tal como las empresas con las que el servidor de seguridad 140 comparte un secreto utilizado para generar OTP de inicio de sesión y/o transacción de 2CHK.
[0084] Más particularmente, en este modelo, el usuario final inicia una transacción con una empresa, por ejemplo, la entidad representada por el sitio web 130, a través de la aplicación de seguridad, es decir, el cliente 2CHk , 210 o 310. Para hacerlo, el usuario activa la aplicación de seguridad 210 o 310 en su dispositivo informático o hardware complementario como se ha descrito anteriormente.
[0085] Después de que la fase de activación se haya completado con éxito, el usuario puede seleccionar, por ejemplo, de una lista desplegable de empresas participantes disponibles en la ventana de seguridad 120, una empresa con la que le gustaría realizar una transacción. El usuario también selecciona, por ejemplo, de una lista desplegable disponible en la ventana de seguridad 120, un tipo de transacción que desea realizar, por ejemplo transferir dinero, obtener saldo, comprar un artículo, recibir información u obtener un cupón, etc. A continuación, el usuario introduce información relevante para ese tipo de transacción en la ventana de seguridad 120 y presiona enviar. Además de la identificación de la empresa y el tipo de transacción, la información relevante de la transacción podría ser, por ejemplo, (i) el monto por transferir, el número de cuenta de la cuenta desde la cual se transferirá el monto y a quién debe ser transferido; o (ii) el número de cuenta de la cuenta cuyo saldo se desea conocer; o (iii) el identificador del artículo que se comprará, su precio y la ubicación donde se entregará. La estructura del mensaje y el contenido pueden, por ejemplo, recogerse de un código de respuesta rápida (QR) o un escaneo NFC.
[0086] La información de transacción introducida se transmite a través del canal de comunicaciones 144 y, si corresponde, el enlace de comunicaciones 320 al servidor de seguridad 140. El servidor de seguridad luego reenvía esta información de transacción a, por ejemplo, el sitio web 130 la empresa apropiada, a través del canal de comunicaciones 134. En ciertas implementaciones, puede ser deseable que el servidor de seguridad también transmita información de riesgo relacionada con el usuario junto con la información de la transacción. En cualquier caso, se notifica a la empresa o se le ha informado previamente de que existe una asociación existente entre el usuario aplicable y el sistema 2CHK, por ejemplo, en función del uso continuo del usuario de la aplicación de seguridad, es decir, el cliente 2CHK, 210 o 320 para autentificaciones de inicio de sesión y firmas de transacciones. Por lo tanto, de manera beneficiosa, una empresa recibe una solicitud de transacción en un mensaje estructurado con contenido reconocible de una entidad, es decir, el servidor de seguridad 140, que tiene una confianza (la asociación 2CHK), con el solicitante.
[0087] La empresa, por ejemplo el sitio web 130, puede aceptar o rechazar la solicitud de transacción, y devuelve el estado al servidor de seguridad 140 a través del canal de comunicaciones 134. El servidor de seguridad 140 pasa el mensaje de estado a la aplicación de seguridad, es decir, el cliente 2CHK, 210 o 310, a través del canal de comunicaciones 144 y, si corresponde, el enlace de comunicaciones 320. La aplicación de seguridad presenta el mensaje de estado al usuario en la ventana de seguridad 120.
[0088] Si se desea, por ejemplo el sitio web 130 de la empresa también puede solicitar autentificación adicional del usuario a través de OObA, KBA o la transacción de o Tp por mensajes de texto antes de aceptar o rechazar la solicitud de transacción. Si es así, el usuario (i) introduce, en la ventana de seguridad 120, la información solicitada (por ejemplo, la transacción de OTP recibida por el usuario a través del servidor OOBA 150 desde el servidor de seguridad 140 o en un mensaje de texto recibido directamente de, por ejemplo, el sitio web 130 de la empresa, o (ii) recibe la llamada telefónica directamente de la empresa. Si se introduce la OTP, se reenvía desde la ventana de seguridad 120 a través del servidor de seguridad 140 a, por ejemplo, el sitio web 130 de la empresa.
[0089] La empresa, por ejemplo su sitio web 130, determina si se completa o no la transacción en función de la OTP devuelta o en función del usuario que atiende la llamada telefónica, y devuelve el estado al servidor de seguridad 140 a través del canal de comunicaciones 134. El servidor de seguridad 140 pasa esta información de estado a la aplicación de seguridad, es decir, el cliente 2CHK, 210 o 310 para mostrarla en la ventana de seguridad 120.
Transacciones de consulta
[0090] Las transacciones de "consulta" se pueden realizar para proporcionar una confianza aún mayor de que un usuario es quien dice ser. Más particularmente, cualquier empresa puede enviar una transacción de "consulta", por ejemplo su sitio web 130, al servidor de seguridad 140, a través del canal de comunicaciones 134 o los canales 132 y 142, en cualquier momento posterior, es decir, después de las activaciones, para "reforzar", es decir, dar a la empresa en cuestión más confianza, en la asociación de identidad al solicitar al servidor de seguridad 140 que utilice el canal de comunicaciones seguro 144 para capturar información de autentificación adicional que la empresa puede comparar con la información de identidad accesible por el sitio web 130, incluidos, entre otros, secretos compartidos, información de ubicación geográfica e identificadores biométricos.
[0091] La empresa, por ejemplo su sitio web 130, puede enviar transacciones de informar/confirmar/firmar/consultar utilizando el número de teléfono del usuario, o un hash del mismo, como índice. Por lo tanto, se pueden usar múltiples asociaciones para reforzar la asociación de identificación.
[0092] Por ejemplo, en cualquier momento después de que el usuario haya sido validado por el servidor de seguridad 140 y se haya establecido el canal de comunicaciones seguro 144, el sitio web 130 puede transmitir una consulta al servidor de seguridad 140 a través del canal de comunicaciones seguro 134 o a través de los canales 132 y 142 hacerle al usuario una o más preguntas, como "¿cuál es su código postal?", “¿cuál es su color favorito?”, o “¿cuál es la contraseña de su empresa?” o alguna otra consulta o consultas que permita(n) a la propia empresa autentificar por separado al usuario que se comunica con el servidor de seguridad 140 a través del canal de comunicaciones seguro 144, en función de la información que la empresa conoce a través de su propia relación separada preexistente con el usuario. El servidor de seguridad 140 transmite la consulta de la empresa recibida al usuario a través del canal de comunicaciones seguro 144 para su presentación al usuario en la ventana de seguridad 120. El usuario introduce la respuesta a la consulta de la empresa presentada en la ventana de seguridad 120 y la aplicación de seguridad dirige la transmisión de la respuesta al servidor de seguridad 140 a través del canal de comunicaciones seguro 140. El servidor de seguridad 140 transmite además la respuesta recibida al sitio web 130 a través del canal de comunicaciones seguro 134 o a través de los canales 132 y 142. El sitio web 130 luego compara la respuesta recibida con la respuesta correcta a la consulta, que conoce para autentificar adicionalmente al usuario, es decir, para confirmar adicionalmente que el usuario es de hecho quien dice ser.
Flexibilidad de la arquitectura del sistema
[0093] El sistema puede implementarse en una arquitectura flexible que permite que los sitios web 130 soliciten o seleccionen el factor de forma apropiado para cualquier transacción dada. Por ejemplo, un usuario puede tener simultáneamente una ventana de seguridad 110 en dos o más tipos diferentes de dispositivos informáticos, por ejemplo ejecutada simultáneamente en su teléfono inteligente, ordenador de sobremesa y/o hardware complementario. Si bien la mayoría de las transacciones se pueden enviar a su ventana de seguridad del ordenador de sobremesa 110 (que es mucho más conveniente), las transacciones de mayor riesgo se pueden enviar a la ventana de seguridad de su teléfono inteligente 110. La transacción de mayor riesgo incluso se puede enviar a su hardware complementario.
[0094] Volviendo de nuevo a la Figura 1, como se muestra en ella, cada sitio web 130 tiene beneficiosamente una interfaz de programación de aplicaciones de seguridad (API) 135 operable desde él. Cuando el usuario se encuentra en cualquiera de los sitios web 130, puede usar la API de seguridad 135 para solicitar la autentificación de la transacción enviando una transacción encriptada al servidor de seguridad 140 a través de la ventana de seguridad 110.
[0095] Como se ha indicado anteriormente, la ventana de seguridad 110 puede implementarse en cualquiera de al menos tres factores de forma, (1) una ventana de seguridad emergente controlada por una aplicación de navegador 207 que se ejecuta en un dispositivo informático de sobremesa o portátil, que no requiere la descarga de ningún software, (2) una ventana de seguridad controlada por una aplicación de seguridad, es decir, un cliente 2CHK, 210 (a menudo denominada "aplicación de seguridad" 210) que se ejecuta en un teléfono inteligente u otro dispositivo inteligente de comunicaciones móviles, o en hardware complementario, y (3) una ventana de seguridad controlada por una aplicación de seguridad, el cliente 2CHK, 210 que se ejecuta en un dispositivo informático de sobremesa o portátil.
[0096] El mismo usuario puede utilizar beneficiosamente diferentes factores de forma en diferentes momentos. Por ejemplo, un usuario que tiene la aplicación de seguridad, es decir, el cliente 2CHK, 210 instalado en un dispositivo de sobremesa y lo usa la mayor parte del tiempo, puede usar una ventana de seguridad emergente del navegador mientras está en otro dispositivo de sobremesa (roaming). Para algunas transacciones de alto riesgo, el sitio web puede requerir mostrar la transacción en la ventana de seguridad 120 controlada por la aplicación de seguridad 210 que se ejecuta en el teléfono inteligente del usuario, mientras que la mayoría de las transacciones se muestran en la ventana de seguridad 120 controlada por la aplicación de seguridad 210 que se ejecuta en el dispositivo de sobremesa del usuario. A diferencia de un testigo lógico (soft token), la ventana de seguridad 120 o el cliente 2CHK, en sí mismo, no contiene ningún secreto de usuario. Dependiendo del factor de forma, la ventana de seguridad 120 puede iniciarse automáticamente para el usuario en el momento del arranque, o puede iniciarse manualmente haciendo clic en el icono de una aplicación, por ejemplo para la aplicación de seguridad, es decir, el cliente 2CHK, 210, que se ejecuta en el ordenador de sobremesa o teléfono inteligente, o en un marcador, por ejemplo para la versión emergente del navegador.
[0097] Como se ha comentado en detalle anteriormente, el usuario puede cortar y pegar o insertar de otra forma una OTP de inicio de sesión o una OTP de transacción que se muestra en la ventana de seguridad 120 en la ventana del sitio web 110 que muestra el navegador 207 o la aplicación del sitio web 212, que solicita la OTP. El usuario también puede señalar al servidor de seguridad 140 a través de la ventana de seguridad 120 que una transacción es válida/inválida, por ejemplo, confirmando que desea continuar o negándose a confirmar la transacción. Sin embargo, debe reconocerse que la ventana de seguridad 120 también puede usarse para mostrar simplemente al usuario la transacción. Por lo tanto, la ventana de seguridad 120 puede adoptar diferentes formas, por ejemplo, una que presenta al usuario una visualización de una transacción y proporciona al usuario una OTP para iniciar sesión o firmar una transacción en un sitio web, otra que presenta al usuario una visualización de una transacción y solicitud de la confirmación del usuario de una transacción y otra más que simplemente presenta al usuario una visualización de una transacción, sin que el usuario tenga que hacer nada más.
[0098] Los sitios web participantes 130 ejecutan beneficiosamente la API de seguridad 135 para realizar los siguientes pasos funcionales.
1. El sitio web 130 llama a la transaction_request () API (API de la solicitud de transacción), que devuelve la transaction_request cifrada. Además de la transacción en sí (que podría ser simplemente una solicitud de una OTP de transacción), el sitio web 130 indica si desea (i) simplemente mostrar la transacción al usuario o (ii) asegurarse de que el usuario haga clic en "Aceptar" en la ventana de seguridad 110, o de que proporcione alguna indicación correspondiente a que aprueba la transacción mostrada en la ventana de seguridad 110, u (iii) obtener una firma de transacción.
2. La transacción cifrada se publica luego en el servidor de seguridad 140, ya sea a través del navegador del usuario 207 o la aplicación de sitio web 212, o directamente a través de un canal de comunicaciones directo 134 entre el servidor de seguridad 140 y el sitio web 130.
3. El servidor de seguridad 140 descifra la transacción, verifica la autenticidad y luego dirige la visualización de la transacción al usuario en la ventana de seguridad 110. Como se ha indicado anteriormente, si se solicita una firma de transacción, el servidor de seguridad 140 computará la OTP de la transacción y también dirigirá su visualización al usuario en la ventana de seguridad 110.
4. El servidor de seguridad 140 prepara una respuesta de transacción transaction_response encriptada y la envía de vuelta al navegador 207 o a la aplicación del sitio web 212, en respuesta a la publicación original, que a su vez transmite la transaction_response encriptada al sitio web 130.
5. El sitio web 130 luego llama a la API de verificación de transacción transaction_verify()que devolverá el resultado a ese sitio web.
Gestión de clave criptográfica
[0099] El establecimiento de un canal de comunicaciones seguro, encriptado e independiente 144 entre la ventana de seguridad 120 en el dispositivo informático del usuario 100, por ejemplo el PC o dispositivo inteligente de comunicaciones móviles del usuario, y el servidor de seguridad 140 es central para el sistema 2CHK.
[0100] La generación de claves criptográficas se puede realizar de la siguiente manera. En algún momento después de que se active la ventana de seguridad 120, el KMLC 213 o 313 genera un par de claves privada/pública, por ejemplo Du/Pu y almacena la clave privada Du de forma segura (generalmente en la memoria), por ejemplo en el almacenamiento privado 210a o 312. El KMLC 213 o 313 envía la clave pública Pu al servidor de seguridad 140 a través del canal seguro 144 y, si corresponde, el enlace 320, donde la transmisión es interceptada por el KMLS 147. El KMLS 147 prepara un certificado digital ("Cert"), que incluye la clave pública del usuario Pu, y sucede una de dos cosas.
[0101] Si el KMLS 147 es capaz de actuar como una autoridad de certificación intermedia o raíz, firma el certificado y devuelve el certificado firmado a KMLC 213 o 313, que lo mantiene localmente (preferiblemente en la memoria), como el almacenamiento privado 210a o 312. Por ejemplo, el KMLS 147 podría firmar el Cert con la clave privada Ds de su par de claves privada/pública Ds/Ps, de modo que [Cert]Ds se devuelva a KMLC 213 o 313 a través del canal seguro 144 y, si corresponde, el enlace 320.
[0102] Por otro lado, si KMLS 147 actúa como una "autoridad de registro", reenvía la solicitud de certificación a través del canal de comunicaciones 148 a una autoridad de certificación externa 170, que crea el certificado y lo devuelve al KMLS 147 a través del mismo canal de comunicaciones. El KMLS 147 a su vez reenvía, a través del canal de comunicaciones 144, el certificado de regreso al KMLC 213 o 313, que lo mantiene localmente (preferiblemente en la memoria), por ejemplo en el almacenamiento privado 210a o 312. En tal caso, el Certificado se firmará por la autoridad certificadora con la clave privada Dca de su par de claves privada/pública Dca/Pca de modo que [Cert]Dca se devuelva al KMLS 147. El KMLS 147 luego reenvía el certificado firmado recibido, es decir [Cert]Dca, al KMLC 213 o 313, a través del canal seguro 144 y, si corresponde, el enlace 320.
[0103] En cualquier caso, es preferible que el certificado emitido tenga una vida relativamente corta, es decir, que sea temporal y coincida con la vida de la propia sesión 2CHK. Al simplificar la generación de claves coincidente con la activación, se evita la necesidad de almacenar certificados digitales y claves privadas localmente durante un período prolongado.
[0104] En algunas situaciones, como se comentará con más detalle a continuación, otras aplicaciones pueden requerir la clave privada y el certificado, por ejemplo el navegador 207 o una aplicación que no sea un navegador, por ejemplo un procesador de documentos, 218, en el mismo dispositivo informático 100. Si el sistema operativo subyacente admite almacenamientos de claves estándar, como lo hacen MS Windows™ o Apple MacOS™, se puede asignar al KMLC 213 o 313 la asignación de claves al almacenamiento de claves y su eliminación cuando sea apropiado.
[0105] Además de la generación de claves descrita anteriormente, a saber, claves asimétricas, adecuadas para la criptografía de claves públicas, el sistema de gestión de claves también puede generar y distribuir claves simétricas. Para ello es central una función Shared_Secret_Generator (), incorporada dentro de KMLS 147, que toma como entrada factores tales como UserlD (quizás la línea de teléfono fija del usuario o el número de teléfono móvil), un secreto de larga duración conocido solo por el servidor de seguridad 140, y otros parámetros diversos, y produce como salida el shared_secret K. Es importante tener en cuenta que, para un conjunto dado de entradas, el mismo secreto compartido se calculará de forma determinista. Las diferentes entidades autentificadas pueden solicitar al KMLS 147 que les proporcione la clave simétrica adecuada al proporcionarle al KMLS 147 los parámetros de entrada aplicables.
[0106] Hay que tener en cuenta que, dependiendo de la aplicación, la lógica de administración de claves puede utilizar una o ambas criptografías de clave asimétrica (es decir, pública) y capacidades de criptografía de clave simétrica descritas anteriormente.
[0107] A continuación se describen algunos ejemplos de cómo la administración de claves se puede superponer beneficiosamente a la arquitectura 2CHK.
[0108] Un primer ejemplo se refiere a la firma digital. En las aplicaciones que requieren firma digital, un usuario debe recibir una clave privada y un certificado digital, es decir, una asociación de la identidad del usuario y la clave pública certificada por una autoridad de certificación. El uso de dicha clave privada, que no es conocida por ningún tercero, incluido el servidor de seguridad, proporciona un fuerte no repudio que es necesario para algunas aplicaciones. Las siguientes firmas de convenciones industriales creadas con criptografía de clave pública se denominan "firmas digitales". Como entenderán los expertos en la materia y como se ha mencionado anteriormente, las firmas de transacciones que se basan en la criptografía simétrica subyacente con secretos compartidos, como las OTP de transacciones descritas anteriormente, generalmente se denominan "firmas electrónicas".
[0109] Otro ejemplo se refiere a la distribución de claves.
[0110] Otro ejemplo más está relacionado con el envío de documentos cifrados. Cuando se envía un archivo cifrado a un usuario, por ejemplo, un PDF del estado de una cuenta de valores, el usuario debe recibir la clave con la que se cifró el archivo.
[0111] En todos estos ejemplos, la administración de claves se suma directamente al costo del sistema y afecta indirectamente a la seguridad. Las claves deben generarse, distribuirse y mantenerse sincronizadas. Como las claves pueden perderse, dañarse o ser robadas, la administración de claves suele ser una fuente importante de costos y un punto de vulnerabilidad en el sistema.
[0112] Habiendo descrito el sistema de gestión de claves, incluyendo sus capacidades de generación de claves, estas tres aplicaciones de ejemplo proporcionarán una mejor comprensión sobre cómo hacer uso de las capacidades de gestión de claves.
[0113] El primer ejemplo aborda el uso del sistema 2CHK para la firma digital. Para ciertas aplicaciones, la firma digital usando criptografía de clave pública se considera más apropiada que la firma electrónica de transacciones. Para lograr la firma digital, el usuario final navega, usando el navegador 207 o la aplicación 212 del sitio web, y ejecuta una transacción con el sitio web 130. El sitio web 130 utiliza el KMLWS 137 para hacer una solicitud de firma de transacción con "firma digital" requerida. Esta solicitud se envía a través del canal de comunicaciones seguro back-end 134 al KMLS 147. La solicitud se envía desde el KMLS 147 al KMLC 213 o 313 a través del canal seguro 144 y, si corresponde, el enlace 320, con una indicación de que se requiere una firma digital. La firma de la transacción, es decir, la OTP de la transacción, la genera opcionalmente el servidor de seguridad 140 y se envía junto con la solicitud de firma digital a la aplicación de seguridad 213 o 313 para su visualización en la ventana de seguridad 120, a través del canal de conexión segura persistente 144 y, si corresponde, el enlace 320, y luego se muestra en el dispositivo informático del usuario 100, por ejemplo el PC o el teléfono inteligente del usuario, etc.
[0114] La ventana de seguridad 120 muestra al usuario la transacción como de costumbre, y opcionalmente requiere que el usuario copie la OTP de la transacción, es decir, la firma electrónica, en la ventana 110 que muestra la aplicación de navegador 207 o la aplicación de sitio web 212. En paralelo, el KMLC 213 o 313 calcula un hash en la transacción ("HashTran") y calcula una firma digital utilizando la clave privada del usuario Du, que se almacenó previamente en la memoria, con el resultado [HashTran]Du. Este proceso podría ocurrir de forma oculta o al pedirle al usuario que acepte firmar la transacción. En cualquier caso, la clave privada Du se aplica a la transacción hash [HashTran]. El hash firmado digitalmente de la transacción [HashTran]Du se envía, a través del canal de comunicaciones seguro 144 y, si corresponde, el enlace 320, desde el KMLC 213 o 313 al KMLS 147, junto con el certificado digital [Cert]Ds o [Cert]Dca.
[0115] El KMLS 147 puede realizar opcionalmente una validación de la firma aplicando la clave pública Pu del usuario a la firma digital [HashTran]Du para obtener HashTran y comparándola con un HashTran generado independientemente. Se realice o no la validación, el KMLS 147 reenvía la firma, es decir, [HashTran]Du, y el certificado, es decir, [Cert]Ds o [Cert]Dca, al KMLAPI 420 a través del canal seguro 234.
[0116] El KMLWS 137 puede volver a calcular el hash HashTran y verificar la firma utilizando la clave pública del usuario Pu incluida en el certificado digital, Cert. Por lo tanto, el KMLWS 137 aplica la clave pública del KMLS 147 Ps al [Cert] Ds, o la clave pública de la autoridad de certificación Pca al [Cert] Dca, para recuperar el Pu. Luego aplica el Pu recuperado a [HashTran] Du para recuperar el HashTran y lo compara con un HashTran generado independientemente para verificar la firma.
[0117] Hay que tener en cuenta que, en la descripción anterior, el hash se crea en el KMLC 213 o 313. Sin embargo, podría crearse con igual facilidad en el KMLWA 137 o el KMLS 147, aunque es probable que cada entidad vuelva a calcularlo para garantizar su autenticidad.
[0118] En este ejemplo, toda la transacción llega a la ventana de seguridad 120. Si, por otro lado, un documento debe firmarse utilizando este método, entonces es posible extender la funcionalidad para que el KMLC 213 o 313 confirme la clave privada y clave pública para los almacenamientos de claves disponibles en el dispositivo informático 100 del usuario, lo que haría que las claves estén disponibles para otras aplicaciones, por ejemplo navegadores o aplicaciones que no son navegadores, incluyendo las aplicaciones para teléfonos inteligentes. El KMLC 213 o 313 sería responsable de eliminar las claves de usuario del almacenamiento de claves en el momento apropiado.
[0119] En el segundo ejemplo, el sistema 2CHK se usa para la distribución de claves. Con frecuencia sucede que los datos se cifran y se reenvían al destinatario en un sistema de almacenamiento y reenvío, como el correo electrónico. Por ejemplo, las regulaciones requieren que los documentos, como los estados contables o los historiales médicos, se envíen encriptados si se envían como archivos adjuntos de correo electrónico. Muchas aplicaciones, por ejemplo WinZip™ y Acrobat Reader™ han incorporado capacidades de cifrado basadas en contraseña. Entonces surge la pregunta de cómo se envía la contraseña de descifrado al usuario. Un enfoque es acordar a priori una contraseña compartida. Los inconvenientes de este enfoque son que se puede usar una contraseña comprometida para descifrar muchos documentos, y también que es difícil requerir contraseñas complejas, ya que es probable que el usuario olvide la contraseña. A continuación, se describen tres enfoques del uso de la gestión de claves 2CHK para resolver este problema.
[0120] En el primer enfoque, un documento identificado de forma única, por ejemplo por un identificador de documento DocumentID único, se cifra con una clave derivada de un PIN, por ejemplo un PIN alfanumérico de ocho caracteres, por un sitio web 130 y luego se envía a un usuario, por ejemplo por correo electrónico. Para los fines de esta descripción, un DocumentID es un valor único asociado con combinaciones particulares de identificación del remitente, identificación del destinatario e identificación del documento. Cuando el usuario abre el documento utilizando alguna aplicación 218 que no es un navegador, normalmente una aplicación de software en su PC, por ejemplo WinZip ™ y Acrobat Reader ™, el programa envía una señal al sitio web 130 indicando que el usuario está intentando leer el documento en particular. Aunque la aplicación 218 podría ser el navegador 207, a los fines de esta descripción se supone que no es un software de navegador.
[0121] El sitio web 130 recupera el PIN con el que ese documento referenciado por DocumentID se cifró inicialmente, y luego usa el KMLWS 137 para enviar el PIN al servidor de seguridad 140 a través del enlace de comunicaciones 134. El servidor de seguridad 140, usando el KMLS 147, reenvía, a través del canal de comunicaciones 144 y, si corresponde, el enlace 320 el PIN al KMLC 213 o 313 y el PIN se muestra al usuario dentro de la ventana de seguridad 120.
[0122] El usuario copia el PIN en la aplicación 218 y el descifrado se realiza normalmente. Debe observarse que, en general, no se requieren cambios en la aplicación 218. La capacidad de activar un mensaje al sitio web 130 cuando se abre es una funcionalidad que ya está integrada en muchas aplicaciones (por ejemplo, Adobe Reader).
[0123] Un inconveniente del método anterior es que el sitio web 130 tiene que mantener una lista de documentos y de PIN.
[0124] Una forma de resolver este problema es utilizar un segundo método y obtener la clave con la que se cifra cada documento como resultado de una función, que toma como entrada el DocumentID y un secreto a largo plazo conocido solo por el sitio web 130. De esta manera, la clave se puede generar dinámicamente después de que el usuario intente abrir el documento como se describe en el primer método.
[0125] Un inconveniente del segundo método es que se supone que el sitio web 130 está disponible y en línea cuando se abre el documento. Como algunos de los sistemas que generan y distribuyen documentos son sistemas por lotes back-end, esta suposición puede no ser aplicable siempre.
[0126] En un tercer método, la capacidad de generación de secreto compartido de gestión de claves 2CHK se puede utilizar para resolver el problema de la siguiente manera.
[0127] El sitio web 130 envía al servidor de seguridad 140, ya sea uno a uno o más probablemente en un archivo por lotes, los DocumentlD que desea cifrar. Para los fines de esta descripción, se supondrá que el archivo contiene información del mensaje, como los ID del remitente y del destinatario. El KMLS 147 utiliza el generador de secreto compartido Shared_Secret_Generator () descrito anteriormente para calcular las claves de cifrado para cada DocumentID. Por ejemplo, la clave K1 para un DocumentID, K2 para otro DocumentID, K3 para otro DocumentID, etc. Estas claves son devueltas por el KMLS 147 al sitio web 130. El sitio web 130 encripta cada documento respectivo con la clave correspondiente y envía el documento cifrado, por ejemplo por correo electrónico, a los respectivos usuarios aplicables.
[0128] El usuario aplicable utiliza el otro software 218 de dispositivo de sobremesa para abrir el documento, lo que desencadena una solicitud de clave directamente al servidor de seguridad 140 a través de una conexión web segura (no mostrada). Debe observarse que esta es una conexión directa desde la aplicación que no es un navegador 218 al servidor de seguridad 140, y no a través de la ventana de seguridad 120.
[0129] Esta acción hace que el KMLS 147 use el Shared_Secret_Generator () para volver a calcular la clave de cifrado aplicable, por ejemplo K1, K2, K3, etc. La clave correspondiente se envía, a través del canal seguro 144 y, si corresponde, del enlace 320, al KMLC 213 o 313 y se muestra al usuario en la ventana de seguridad 120 para copiar en la ventana mostrada por el software que no es un navegador 218 como se ha descrito anteriormente.
[0130] Si bien lo anterior se ha descrito utilizando una aplicación de software que no es un navegador 218 (por ejemplo, Acrobat Reader), la misma funcionalidad se puede usar para aplicaciones web basadas en navegador.
Siembra de clave criptográfica
[0131] Cuando los usuarios reciben un autentificador de testigo (token), ya sea para un generador de contraseñas de un solo uso o un autentificador de transacciones, el testigo del usuario debe recibir una clave secreta compartida. Los expertos en la materia reconocerán que, en este contexto, la clave secreta compartida a menudo se caracteriza como una "semilla". La gestión de claves 2CHK descrita anteriormente también se puede utilizar para "sembrar" OTP y testigos de autentificación de transacciones. Las OTP y los autentificadores de testigo de autentificación de transacción requieren una clave que se almacena en el testigo y también se almacena en el sistema back-end. La administración de estas claves (que comúnmente se conocen como "semillas") conlleva costos y complejidad. Se puede utilizar la administración de claves 2CHK para simplificar enormemente este proceso.
[0132] Para los fines de esta descripción, se supone que un autentificador de testigos (no mostrado) se implementa como hardware, software o como una aplicación de teléfono móvil. El testigo comienza en un estado inactivo sin semilla presente (o se requiere una actualización de semilla). El usuario realiza una solicitud directamente desde la ventana de seguridad 120 o directamente desde el testigo al servidor de seguridad 140 a través del canal de comunicaciones 144 o a un sitio web externo 130 que solicita un evento de siembra. Se proporciona algún identificador único que identifica al usuario ante el servidor de seguridad 140 o el sitio web 130, según corresponda.
[0133] El KMLS 147 dentro del servidor de seguridad 140 usa el UserlD único y otra información, incluido el secreto a largo plazo conocido solo por el KMLS 147, como entradas en Shared_Secret_Generator () para generar una semilla única (es decir, clave) para ese usuario. Por ejemplo, la "siembra" de una semilla en el momento de cada activación puede incluir generar la semilla en función del número de teléfono del usuario (u otra ID) y un secreto conocido solo por el servicio 2CHK. Tal semilla, aunque se regenera en cada activación, tendrá el mismo valor cada vez que se genere. Sin embargo, la semilla podría generarse de forma que tenga un valor diferente en cada activación, mediante el uso de un algoritmo modificado en parte.
[0134] Esta semilla se envía de vuelta al KMLC 213 o 313 a través del canal seguro 244 y, si corresponde, el enlace 320, y luego se muestra al usuario en la ventana de seguridad 120. El usuario introduce la semilla en el testigo de aplicación de software o teléfono inteligente. Cabe señalar que la semilla real puede ser generada por una función que transforma la semilla que introduce el usuario. También se reconocerá que para el hardware esto solo funcionará si el testigo tiene un teclado, que la mayoría de los autentificadores de transacciones sí tienen.
[0135] Como variante de lo anterior, se observa que el autentificador de transacciones puede integrarse directamente en la aplicación de seguridad 210 o 310 como parte de la funcionalidad. Si bien a primera vista la justificación de esto puede no ser obvia, la compatibilidad con sistemas existentes como EMV/CAP proporciona la justificación de este enfoque. Esta distribución a petición de los autentificadores de transacciones simplifica enormemente los costos de aprovisionamiento.
[0136] Como se ha señalado anteriormente, la aplicación de seguridad, es decir, el cliente 2CHK, 310 en el hardware complementario también se puede "sembrar" para generar tokens de OTP utilizando las técnicas descritas anteriormente. Esto significa que las OTP ahora se pueden generar de forma segura en el hardware complementario incluso cuando ya no está conectado al dispositivo informático 100. Si bien las operaciones de siembra relacionadas con el hardware complementario 300 conectado al dispositivo informático 100 se han cubierto en detalle anteriormente, a continuación se describe cómo algunas de esas operaciones se pueden realizar con el hardware complementario 300 desconectado del dispositivo informático 100. Para los fines de esta descripción, se supone que un autentificador de token (no mostrado) se implementa como hardware, como software o como una aplicación de hardware complementario.
[0137] El token comienza en un estado inactivo sin semilla presente (o se requiere una actualización de semilla). Después de que el hardware complementario 300 se haya desconectado del dispositivo informático 100, la aplicación de seguridad, a saber el cliente 2CHK, 310 puede mostrar al usuario las semillas almacenadas, que habían sido recibidas con el hardware complementario 300 conectado al dispositivo informático 100, si se desea, en una ventana de seguridad 120 mostrada en la pantalla 302 del hardware complementario 300. El usuario puede introducir la semilla en el generador de token (no mostrado) que está ejecutando la CPU 305 del hardware complementario 300. De nuevo, se debe tener en cuenta que la semilla real puede ser generada por una función que transforma la semilla que introduce el usuario. También se reconocerá que para los generadores de token de hardware esto solo funcionará si el generador de token tiene un teclado, que la mayoría de los generadores de transacciones sí tienen.
[0138] Como se ha descrito anteriormente, la "siembra" de una OTP se realiza con una semilla en el momento de cada activación, es decir, durante la etapa de inicio y activación. Específicamente, la semilla, es decir, la clave, se genera en función del número de teléfono del usuario u otro identificador de usuario, y un secreto conocido solo por el servidor de seguridad 140. Esta semilla se regenera en cada activación, pero tendrá el mismo valor.
[0139] Un enfoque alternativo es generar la semilla en la asociación inicial, es decir, durante la fase de configuración y personalización, y almacenar la semilla, en su totalidad o en parte, de forma local y constante. Por lo tanto, en el enfoque alternativo, la semilla no es necesariamente regenerada, o regenerada en su totalidad, en cada nueva activación. Un beneficio principal de este enfoque es que, si un atacante usa el desvío de llamadas o algún otro mecanismo para secuestrar el número de teléfono del usuario y crea una nueva activación, el atacante no tendrá conocimiento de la semilla. Por lo tanto, si esa semilla se usa para generar una OTP de transacción, un atacante que no tenga esa semilla se verá frustrado.

Claims (8)

REIVINDICACIONES
1. Método de funcionamiento de un servidor de seguridad (140) para realizar transacciones de consulta a través de una red, que comprende:
recibir, en el servidor de seguridad desde un dispositivo de red de usuario (100) a través de la red, una solicitud de un usuario para activar un canal de comunicaciones seguro (144) a través de la red entre el dispositivo de red de usuario y el servidor de seguridad;
transmitir, por el servidor de seguridad en respuesta a la solicitud de activación recibida, un código de activación para enviar al usuario a través de otra red;
recibir, en el servidor de seguridad del dispositivo de red del usuario a través de la red, un código de activación; comparar, en el servidor de seguridad, el código de activación recibido con el código de activación transmitido para validar el código de activación recibido;
activar el canal de comunicaciones seguro en función de la validación del código de activación recibido; recibir, en el servidor de seguridad de un servidor de red que representa una empresa (130) a través de la red, una consulta que incluye una pregunta para el usuario, donde la respuesta correcta a la pregunta ha sido previamente acordada por el usuario y la empresa;
transmitir, desde el servidor de seguridad al dispositivo de red del usuario a través del canal de comunicaciones seguro, la consulta de la empresa recibida;
recibir, en el servidor de seguridad desde el dispositivo de red del usuario a través del canal de comunicaciones seguro, una respuesta del usuario a la consulta de la empresa transmitida; y
transmitir la respuesta del usuario recibida desde el servidor de seguridad al servidor de la red de la empresa a través de la red para autentificar adicionalmente al usuario ante la empresa.
2. Método según la reivindicación 1, en donde la otra red es una autentificación fuera de banda.
3. Método según la reivindicación 2, en donde la red de autentificación fuera de banda es una red telefónica.
4. Método según la reivindicación 1, en el que la pregunta de empresa solicita uno de los secretos compartidos por el usuario y la empresa (130) e información personal del usuario.
5. Método según la reivindicación 1, que comprende además:
incorporar, en el servidor de seguridad (140), la consulta de la empresa recibida en al menos uno de un flujo de voz y una imagen;
en donde la consulta de la empresa transmitida es la consulta de la empresa incorporada en al menos uno del flujo de voz y la imagen.
6. Método según la reivindicación 5, en donde el flujo de voz es un flujo de voz que tiene una voz reconocible por el usuario y la imagen es una imagen que tiene un fondo conocido por el usuario.
7. Método de funcionamiento de un servidor de seguridad (140) para realizar transacciones comerciales de forma segura entre un usuario y una empresa (130) a través de una red, que comprende:
recibir, en el servidor de seguridad desde un dispositivo de red de usuario (100) a través de la red, una solicitud del usuario para activar un canal de comunicaciones seguro (144) a través de la red entre el dispositivo de red de usuario y el servidor de seguridad;
transmitir, por el servidor de seguridad en respuesta a la solicitud de activación recibida, un código de activación para enviar al usuario a través de otra red;
recibir, en el servidor de seguridad del dispositivo de red del usuario a través de la red, un código de activación; comparar, en el servidor de seguridad, el código de activación recibido con el código de activación transmitido para validar el código de activación recibido;
activar el canal de comunicaciones seguro en función de la validación del código de activación recibido; recibir, en el servidor de seguridad desde el dispositivo de red del usuario a través del canal de comunicaciones seguro, información de la transacción que incluye un identificador de la empresa con la que el usuario desea entrar en la transacción y detalles de la transacción deseada;
transmitir la información de la transacción, desde el servidor de seguridad a un servidor de red que representa a la empresa en la red a través de otro canal seguro de comunicaciones (134) a través de la red; recibir, en el servidor de seguridad del servidor de red a través del otro canal de comunicaciones seguro, una notificación de que (i) la transacción ha sido aceptada o (ii) la transacción ha sido rechazada o (iii) la empresa requiere una autentificación adicional del usuario; y
si la notificación recibida es una notificación de que la transacción ha sido aceptada o rechazada, transmitir la notificación recibida del servidor de seguridad al dispositivo de red del usuario a través del canal de comunicaciones seguro.
8. Método según la reivindicación 7, que comprende además:
incorporar la información de la transacción en al menos uno de un flujo de voz que tiene una voz reconocible por el usuario y una imagen que tiene un fondo conocido por el usuario; y
transmitir al menos uno de entre el flujo de voz y la imagen al usuario a través de la red.
ES13801298T 2012-06-07 2013-05-06 Seguridad de autentificación 2CHK mejorada con transacciones de consulta Active ES2553222T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201213490715 2012-06-07
US13/490,715 US9716691B2 (en) 2012-06-07 2012-06-07 Enhanced 2CHK authentication security with query transactions
PCT/US2013/039684 WO2013184267A1 (en) 2012-06-07 2013-05-06 Enhanced 2chk authentication security with query transactions

Publications (2)

Publication Number Publication Date
ES2553222T1 ES2553222T1 (es) 2015-12-07
ES2553222T3 true ES2553222T3 (es) 2020-04-15

Family

ID=49712452

Family Applications (1)

Application Number Title Priority Date Filing Date
ES13801298T Active ES2553222T3 (es) 2012-06-07 2013-05-06 Seguridad de autentificación 2CHK mejorada con transacciones de consulta

Country Status (10)

Country Link
US (2) US9716691B2 (es)
EP (1) EP2859489B1 (es)
JP (1) JP6012125B2 (es)
AU (1) AU2013272184B2 (es)
CA (1) CA2875563C (es)
DE (1) DE13801298T1 (es)
ES (1) ES2553222T3 (es)
HK (1) HK1207714A1 (es)
SG (1) SG11201408025SA (es)
WO (2) WO2013184267A1 (es)

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9578664B1 (en) 2013-02-07 2017-02-21 Sprint Communications Company L.P. Trusted signaling in 3GPP interfaces in a network function virtualization wireless communication system
ES2754198T3 (es) * 2013-06-24 2020-04-16 Telefonica Digital Espana Slu Un método implementado por ordenador para mejorar la seguridad en los sistemas de autenticación/autorización y sus productos de programas informático
US9355235B1 (en) * 2013-12-06 2016-05-31 Emc Corporation Validating a user of a virtual machine for administrator/root access
US20160316311A1 (en) * 2013-12-13 2016-10-27 Nokia Technologies Oy Method and apparatus for provisioning an operational subscription
US9602501B1 (en) 2014-03-28 2017-03-21 Amazon Technologies, Inc. Bootstrapping user authentication
US9710640B1 (en) 2014-03-28 2017-07-18 Amazon Technologies, Inc. Bootstrapping authentication of second application via confirmation by first application
US10375063B2 (en) 2014-07-29 2019-08-06 Lexisnexis Risk Solutions Inc. Systems and methods for combined OTP and KBA identity authentication utilizing academic publication data
US9380057B2 (en) * 2014-07-29 2016-06-28 Lexisnexis Risk Solutions Inc. Systems and methods for combined OTP and KBA identity authentication
CN105450620B (zh) 2014-09-30 2019-07-12 阿里巴巴集团控股有限公司 一种信息处理方法及装置
US10757216B1 (en) 2015-02-20 2020-08-25 Amazon Technologies, Inc. Group profiles for group item recommendations
US11363460B1 (en) * 2015-03-03 2022-06-14 Amazon Technologies, Inc. Device-based identification for automated user detection
CN106200891B (zh) * 2015-05-08 2019-09-06 阿里巴巴集团控股有限公司 显示用户界面的方法、装置及系统
US9686240B1 (en) 2015-07-07 2017-06-20 Sprint Communications Company L.P. IPv6 to IPv4 data packet migration in a trusted security zone
DE102015214267A1 (de) * 2015-07-28 2017-02-02 Siemens Aktiengesellschaft Verfahren und System zum Erzeugen eines sicheren Kommunikationskanals für Endgeräte
CN106447323A (zh) 2015-08-05 2017-02-22 阿里巴巴集团控股有限公司 业务验证方法及装置
US9749294B1 (en) 2015-09-08 2017-08-29 Sprint Communications Company L.P. System and method of establishing trusted operability between networks in a network functions virtualization environment
KR101715504B1 (ko) * 2015-09-16 2017-03-14 성균관대학교산학협력단 색상 코드를 이용하여 otp 인증을 수행하는 방법 및 색상 코드를 이용하는 otp 인증 서버
MX2018003708A (es) * 2015-09-25 2018-09-21 Genetec Inc Registro seguro de dispositivo de seguridad para la comunicacion con servidor de seguridad.
US10542115B1 (en) 2015-10-01 2020-01-21 Sprint Communications Company L.P. Securing communications in a network function virtualization (NFV) core network
US9811686B1 (en) * 2015-10-09 2017-11-07 Sprint Communications Company L.P. Support systems interactions with virtual network functions in a trusted security zone
US9781016B1 (en) 2015-11-02 2017-10-03 Sprint Communications Company L.P. Dynamic addition of network function services
US10091193B2 (en) * 2015-12-30 2018-10-02 Mastercard International Incorporated One time passcode
US10778435B1 (en) * 2015-12-30 2020-09-15 Jpmorgan Chase Bank, N.A. Systems and methods for enhanced mobile device authentication
US20170257363A1 (en) * 2016-03-04 2017-09-07 Secureauth Corporation Secure mobile device two-factor authentication
US10521572B2 (en) 2016-08-16 2019-12-31 Lexisnexis Risk Solutions Inc. Systems and methods for improving KBA identity authentication questions
US10567387B1 (en) * 2016-09-13 2020-02-18 Symantec Corporation Systems and methods for managing computing device access to local area computer networks
US10250498B1 (en) 2016-10-03 2019-04-02 Sprint Communications Company L.P. Session aggregator brokering of data stream communication
US10348488B1 (en) 2017-08-25 2019-07-09 Sprint Communications Company L.P. Tiered distributed ledger technology (DLT) in a network function virtualization (NFV) core network
FR3071373B1 (fr) * 2017-09-21 2021-01-22 Onoff Telecom Procede de verification de la validite d’une ligne telephonique d’un utilisateur
US11392925B2 (en) * 2018-04-13 2022-07-19 Mastercard International Incorporated Method and system for contactless transmissions using off-the-shelf devices
US11641363B2 (en) * 2019-01-14 2023-05-02 Qatar Foundation For Education, Science And Community Development Methods and systems for verifying the authenticity of a remote service
US11847205B1 (en) 2020-10-26 2023-12-19 T-Mobile Innovations Llc Trusted 5G network function virtualization of virtual network function elements embedded on a system-on-chip

Family Cites Families (106)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5736932A (en) * 1996-07-03 1998-04-07 At&T Corp Security for controlled access systems
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
US6671672B1 (en) * 1999-03-30 2003-12-30 Nuance Communications Voice authentication system having cognitive recall mechanism for password verification
US6999943B1 (en) 2000-03-10 2006-02-14 Doublecredit.Com, Inc. Routing methods and systems for increasing payment transaction volume and profitability
JP5591431B2 (ja) 2000-05-25 2014-09-17 イーチャージ・コーポレーション セキュリティトランザクションプロトコル
KR100517302B1 (ko) * 2000-11-10 2005-09-27 엔티티 도꼬모 인코퍼레이티드 인증 시스템, 인증대행장치 및 단말장치
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 ワンタイムパスワード認証システム及び携帯電話及びユーザ認証サーバ
AU2002355530A1 (en) 2001-08-03 2003-02-24 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
US7493259B2 (en) * 2002-01-04 2009-02-17 Siebel Systems, Inc. Method for accessing data via voice
US20040010698A1 (en) * 2002-05-30 2004-01-15 Rolfe Andrew R. Digital certificate system incorporating voice biometric processing
US7370194B2 (en) * 2002-06-10 2008-05-06 Microsoft Corporation Security gateway for online console-based gaming
US20040210536A1 (en) 2002-12-18 2004-10-21 Tino Gudelj Cross-domain transactions through simulated pop-ups
SI21436A (sl) * 2003-02-04 2004-08-31 Renderspace - Pristop Interactive D.O.O. Sistem identifikacije za vstop v varovano področje
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
JP4778899B2 (ja) 2003-09-12 2011-09-21 イーエムシー コーポレイション リスクベース認証のためのシステムおよび方法
FR2861236B1 (fr) * 2003-10-21 2006-02-03 Cprm Procede et dispositif d'authentification dans un reseau de telecommunication utilisant un equipement portable
US8213438B2 (en) 2003-12-19 2012-07-03 Iwics Inc. Data transport protocol for a multi-station network
US20050149732A1 (en) * 2004-01-07 2005-07-07 Microsoft Corporation Use of static Diffie-Hellman key with IPSec for authentication
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
US8296562B2 (en) 2004-07-15 2012-10-23 Anakam, Inc. Out of band system and method for authentication
FI20050022A0 (fi) * 2005-01-10 2005-01-10 Nokia Corp Verkkoon pääsyn valvonta
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
US20060235795A1 (en) 2005-04-19 2006-10-19 Microsoft Corporation Secure network commercial transactions
US7386105B2 (en) * 2005-05-27 2008-06-10 Nice Systems Ltd Method and apparatus for fraud detection
US7734912B2 (en) * 2005-05-31 2010-06-08 Tricipher, Inc. Secure login using single factor split key asymmetric cryptography and an augmenting factor
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
EP1922632B1 (en) 2005-08-11 2014-05-07 SanDisk IL Ltd. Extended one-time password method and apparatus
JP2007102778A (ja) 2005-10-04 2007-04-19 Forval Technology Inc ユーザ認証システムおよびその方法
US8447700B2 (en) * 2005-10-11 2013-05-21 Amazon Technologies, Inc. Transaction authorization service
US20070283273A1 (en) 2005-10-24 2007-12-06 Woods Michael E System, Method, and Computer Program Product for Internet Tool
WO2007064877A2 (en) 2005-12-01 2007-06-07 Firestar Software, Inc. System and method for exchanging information among exchange applications
US9768963B2 (en) * 2005-12-09 2017-09-19 Citicorp Credit Services, Inc. (Usa) Methods and systems for secure user authentication
WO2007066542A1 (ja) 2005-12-09 2007-06-14 Hitachi Software Engineering, Co., Ltd. 認証システム及び認証方法
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
US8234696B2 (en) 2006-02-10 2012-07-31 Emc Corporation 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
US7552467B2 (en) 2006-04-24 2009-06-23 Jeffrey Dean Lindsay Security systems for protecting an asset
JP2007310678A (ja) 2006-05-18 2007-11-29 Nippon Telegr & Teleph Corp <Ntt> アリバイ証明システム及び方法及びアリバイサーバ及びプログラム
JP4719717B2 (ja) * 2006-06-27 2011-07-06 株式会社リコー 画像処理装置、画像処理方法及び画像処理プログラム
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
US20080052245A1 (en) 2006-08-23 2008-02-28 Richard Love Advanced multi-factor authentication methods
US7818216B2 (en) 2006-08-28 2010-10-19 Seraphim Lawhorn Transaction system with centralized data storage and authentication
US8424061B2 (en) * 2006-09-12 2013-04-16 International Business Machines Corporation Method, system and program product for authenticating a user seeking to perform an electronic service request
KR100786551B1 (ko) 2006-09-15 2007-12-21 이니텍(주) 복수 개의 방식에 의한 일회용 비밀번호의 사용자 등록,인증 방법 및 그러한 방법을 수행하는 프로그램이 기록된컴퓨터 판독 가능 기록 매체
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
US8151326B2 (en) 2006-12-08 2012-04-03 Core Mobility, Inc. Using audio in N-factor authentication
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
US7921221B2 (en) * 2007-01-22 2011-04-05 Minborg Invent I Goteborg Ab Method and apparatus for obtaining digital objects in a communication network
CN101675616A (zh) * 2007-02-05 2010-03-17 维杜普有限责任公司 用于传递赞助带外密码的方法和系统
JP4648420B2 (ja) 2007-03-12 2011-03-09 ヤフー株式会社 認証システム
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
US8078515B2 (en) 2007-05-04 2011-12-13 Michael Sasha John Systems and methods for facilitating electronic transactions and deterring fraud
US8056118B2 (en) * 2007-06-01 2011-11-08 Piliouras Teresa C Systems and methods for universal enhanced log-in, identity document verification, and dedicated survey participation
US20090093300A1 (en) 2007-10-05 2009-04-09 Lutnick Howard W Game of chance processing apparatus
WO2009039223A1 (en) * 2007-09-17 2009-03-26 Vidoop Llc Methods and systems for management of image-based password accounts
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
WO2009070430A2 (en) 2007-11-08 2009-06-04 Suridx, Inc. Apparatus and methods for providing scalable, dynamic, individualized credential services using mobile telephones
JP2009169476A (ja) * 2008-01-10 2009-07-30 Nippon Telegr & Teleph Corp <Ntt> 認証方法、認証システム、認証装置、プログラム
US8255971B1 (en) * 2008-03-03 2012-08-28 Jpmorgan Chase Bank, N.A. Authentication system and method
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
US8214890B2 (en) * 2008-08-27 2012-07-03 Microsoft Corporation Login authentication using a trusted device
US8245030B2 (en) 2008-12-19 2012-08-14 Nai-Yu Pai Method for authenticating online transactions using a browser
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
US8661258B2 (en) * 2009-10-23 2014-02-25 Vasco Data Security, Inc. Compact security device with transaction risk level approval capability
US8713325B2 (en) * 2011-04-19 2014-04-29 Authentify Inc. Key management using quasi out of band authentication architecture
US8458774B2 (en) * 2009-11-02 2013-06-04 Authentify Inc. Method for secure site and user authentication
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
US8745699B2 (en) 2010-05-14 2014-06-03 Authentify Inc. Flexible quasi out of band authentication architecture
US8549601B2 (en) 2009-11-02 2013-10-01 Authentify Inc. Method for secure user and site authentication
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
JP2011238036A (ja) * 2010-05-11 2011-11-24 Ikutoku Gakuen 認証システム、シングルサインオンシステム、サーバ装置およびプログラム
US9350708B2 (en) * 2010-06-01 2016-05-24 Good Technology Corporation System and method for providing secured access to services
KR101683292B1 (ko) * 2010-06-18 2016-12-07 삼성전자주식회사 Ｐｎ 라우팅 테이블을 이용한 개인 네트워크의 구성 장치 및 방법
US9883387B2 (en) * 2011-03-24 2018-01-30 Visa International Service Association Authentication using application authentication element
US8656465B1 (en) * 2011-05-09 2014-02-18 Google Inc. Userspace permissions service
US8595808B2 (en) * 2011-12-16 2013-11-26 Daon Holdings Limited Methods and systems for increasing the security of network-based transactions
US8959619B2 (en) * 2011-12-21 2015-02-17 Fleet One, Llc. Graphical image password authentication method
US8898766B2 (en) * 2012-04-10 2014-11-25 Spotify Ab Systems and methods for controlling a local application through a web page
US20140295956A1 (en) * 2012-05-23 2014-10-02 Cams, Llc Central account management system for user profiling
US8863260B2 (en) * 2012-06-07 2014-10-14 International Business Machines Corporation Enhancing password protection
US10025920B2 (en) * 2012-06-07 2018-07-17 Early Warning Services, Llc Enterprise triggered 2CHK association
US9741085B2 (en) * 2013-03-14 2017-08-22 Artificial Intelligence Research Group Limited System and method of encoding content and an image

Also Published As

Publication number Publication date
JP6012125B2 (ja) 2016-10-25
EP2859489A4 (en) 2016-01-13
CA2875563C (en) 2021-05-11
WO2013184266A2 (en) 2013-12-12
HK1207714A1 (en) 2016-02-05
CA2875563A1 (en) 2013-12-12
AU2013272184A1 (en) 2015-01-15
EP2859489A1 (en) 2015-04-15
EP2859489B1 (en) 2019-08-14
JP2015526784A (ja) 2015-09-10
US9716691B2 (en) 2017-07-25
US10033701B2 (en) 2018-07-24
SG11201408025SA (en) 2015-01-29
US20140041000A1 (en) 2014-02-06
DE13801298T1 (de) 2015-12-17
AU2013272184B2 (en) 2018-05-24
WO2013184267A1 (en) 2013-12-12
ES2553222T1 (es) 2015-12-07
US20130333008A1 (en) 2013-12-12

Similar Documents

Publication Publication Date Title
ES2553222T3 (es) Seguridad de autentificación 2CHK mejorada con transacciones de consulta
AU2013272182B2 (en) Enterprise triggered 2CHK association
US9832183B2 (en) Key management using quasi out of band authentication architecture
US9444809B2 (en) Secure and efficient authentication using plug-in hardware compatible with desktops, laptops and/or smart mobile communication devices such as iPhones™
US10057763B2 (en) Soft token system
US8893237B2 (en) Secure and efficient login and transaction authentication using iphones# and other smart mobile communication devices
JP5683746B2 (ja) 疑似帯域外認証アーキテクチャを用いる鍵管理
EP2873192B1 (en) Methods and systems for using derived credentials to authenticate a device across multiple platforms
Das et al. On the security of SSL/TLS-enabled applications
US8769289B1 (en) Authentication of a user accessing a protected resource using multi-channel protocol
WO2011161461A1 (en) Identity verification
Razumov et al. Ensuring the security of web applications operating on the basis of the SSL/TLS protocol
Umar An Authentication of Significant security for accessing Password through Network System
Nguyen SMS_OTP