ES2803250T3 - Método y sistema de aprovisionamiento de datos de acceso a dispositivos móviles - Google Patents

Método y sistema de aprovisionamiento de datos de acceso a dispositivos móviles Download PDF

Info

Publication number
ES2803250T3
ES2803250T3 ES16789731T ES16789731T ES2803250T3 ES 2803250 T3 ES2803250 T3 ES 2803250T3 ES 16789731 T ES16789731 T ES 16789731T ES 16789731 T ES16789731 T ES 16789731T ES 2803250 T3 ES2803250 T3 ES 2803250T3
Authority
ES
Spain
Prior art keywords
mobile device
data
authentication code
computer
application
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
ES16789731T
Other languages
English (en)
Inventor
Glenn Powell
John Sheets
Kim Wagner
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.)
Visa International Service Association
Original Assignee
Visa International Service Association
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
Priority claimed from US14/707,788 external-priority patent/US10070310B2/en
Priority claimed from US14/935,091 external-priority patent/US10959093B2/en
Application filed by Visa International Service Association filed Critical Visa International Service Association
Priority claimed from PCT/US2016/026241 external-priority patent/WO2016178780A1/en
Application granted granted Critical
Publication of ES2803250T3 publication Critical patent/ES2803250T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • 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
    • 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/45—Structures or tools for the administration of authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Software Systems (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Finance (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Un método (500, 600) para el aprovisionamiento de datos de acceso a una segunda aplicación no confiable (20B) en un dispositivo móvil mediante el uso de una primera aplicación confiable (20A) en el dispositivo móvil, que comprende: recibir, por el dispositivo móvil, datos de autenticación del usuario en la primera aplicación confiable del dispositivo móvil, en donde los datos de autenticación del usuario se utilizan para autenticar al usuario del dispositivo móvil; transmitir (S102), por el dispositivo móvil, los datos de autenticación del usuario a un sistema informático de autorización, en donde el sistema informático de autorización valida los datos de autenticación transmitidos, y en el caso de validación correcta de los datos de autenticación, generar (S106) un código de autenticación y, a continuación, transmitir (S108) el código de autenticación a un ordenador de la entidad de validación; a continuación recibir (S110), por el dispositivo móvil, desde el sistema informático de autorización, el código de autenticación a través de la primera aplicación confiable, en donde el código de autenticación se deriva de los datos de acceso; y en donde los datos de acceso corresponden a los datos que el usuario del dispositivo móvil puede utilizar para acceder a un recurso o localización; a continuación proporcionar (S112), por el dispositivo móvil, el código de autenticación de la primera aplicación confiable a la segunda aplicación no confiable en el dispositivo móvil; a continuación, proporcionar (S116), por la segunda aplicación no confiable del dispositivo móvil, el código de autenticación al ordenador de la entidad de validación, en donde el ordenador de la entidad de validación verifica el código de autenticación proporcionado (S118) y en caso de verificación correcta del código de autenticación proporcionado, entonces obtiene los datos de acceso del código de autenticación; y recibir (S122), tras dicha verificación correcta, por la segunda aplicación no confiable del dispositivo móvil desde un ordenador servidor de aprovisionamiento en comunicación con el ordenador de la entidad de validación, los datos de acceso, en donde el código de autenticación comprende una primera porción que comprende información cifrada y una segunda porción que comprende información sin cifrar, la información sin cifrar que contiene información sobre cómo procesar la información cifrada, de manera que se pueda verificar la validez del código de autenticación.

Description

DESCRIPCIÓN
Método y sistema de aprovisionamiento de datos de acceso a dispositivos móviles
Antecedentes
Los teléfonos móviles pueden utilizar datos de acceso para obtener acceso a un recurso o a una localización. Por ejemplo, un teléfono móvil puede incluir datos que se transmiten a un dispositivo de acceso para permitir al usuario del teléfono móvil acceder a una habitación en un edificio, en otro ejemplo, el teléfono móvil puede tener datos de acceso tal como datos de las cuentas que pueden permitir al usuario del teléfono móvil acceder a una cuenta para obtener un artículo.
En muchos casos, un proveedor de recursos puede aprovisionar el teléfono móvil con los datos de acceso. Por ejemplo, un sistema de operador de edificios puede aprovisionar un teléfono móvil con datos que permitan a un usuario del teléfono móvil acceder a un edificio. En otro ejemplo, un banco puede aprovisionar el teléfono móvil con datos de acceso que permiten al usuario del teléfono móvil acceder a una cuenta en el banco. En esta situación particular, el proveedor de recursos puede verificar que el usuario del teléfono móvil es de hecho un usuario auténtico. Como resultado, la transmisión de datos de acceso al teléfono móvil es relativamente segura.
En algunos casos, los dispositivos móviles pueden contener aplicaciones que pueden realizar varias funciones y/o realizar funciones para más de un proveedor de recursos. En un ejemplo, una sola aplicación en un teléfono móvil que consiste en realizar múltiples funciones o realizar servicios para muchos proveedores de recursos puede no estar directamente relacionada con los proveedores de recursos asociados con esas funciones o servicios. Puede haber un problema de confianza en esta situación, ya que el proveedor de recursos puede no tener control sobre la aplicación única. Por ejemplo, si los datos de acceso que proporciona el proveedor de servicios son muy sensibles, el proveedor de servicios puede no tener un control total sobre ninguno de los elementos de seguridad de la aplicación móvil única. Además, si el usuario solicita que un proveedor de recursos proporcione datos de acceso al teléfono móvil del usuario, es posible que el usuario no haya confiado en que los datos de la única aplicación móvil estén seguros.
Además, en el mundo de hoy, muchas entidades diferentes tienen que cooperar para el aprovisionamiento de datos de acceso a un dispositivo móvil. Por ejemplo, con el fin de aprovisionar un teléfono móvil con datos de acceso para realizar transacciones en un punto de venta, es posible que se necesite una cooperación entre el fabricante del terminal, un proveedor de cartera digital, un banco, un operador de red móvil y un proveedor de servicios que envíen los datos de acceso al dispositivo móvil. Dado que muchas partes participan en el proceso de aprovisionamiento de datos de acceso, los datos de autenticación confidenciales y los datos de acceso pueden transmitirse entre las distintas entidades y, por lo tanto, pueden exponerse ataques de intermediarios o hackeo. También es difícil garantizar que los datos de acceso sensibles y otra información confidencial del usuario estén adecuadamente protegidos a medida que se produzca el proceso de aprovisionamiento.
El documento WO 2007/038896 A2 describe métodos y dispositivos para la autenticación del usuario. El documento EP 2,674,887 A1 describe un método para controlar un sistema de análisis. El "Handbook of applied cryptography", capítulo 13: Key Management Techniques, por Menezes A J, Van Oorshot P C, Vanstone S A (XP001525013) describe técnicas de gestión de claves para controlar la distribución, uso y actualización de claves criptográficas.
Las modalidades de la invención están dirigidas a métodos y sistemas de mejora de la seguridad de los datos. Las modalidades de la invención abordan estos y otros problemas, individual y colectivamente.
Breve resumen
La invención se define en las reivindicaciones independientes. Las modalidades particulares se establecen en las reivindicaciones dependientes. Algunas de las modalidades descritas en lo adelante no son modalidades de la invención de acuerdo con las reivindicaciones.
Las modalidades de la invención están dirigidas a métodos y sistemas que mejoran la seguridad cuando se aprovisionan con datos de acceso a un dispositivo móvil.
Una modalidad de la invención está dirigida a un método que incluye la recepción, por un ordenador de la entidad de validación, un código de autenticación. El método comprende además descifrar, por el ordenador de la entidad de validación, una porción cifrada del código de autenticación para obtener datos de acceso. El método también incluye iniciar, por el ordenador de la entidad de validación, el aprovisionamiento de los datos de acceso a un dispositivo móvil.
Otra modalidad de la invención está dirigida a un ordenador de la entidad de validación configurado para llevar a cabo el método descrito anteriormente.
Otra modalidad de la invención está dirigida a un método. El método incluye la recepción, por un dispositivo móvil, de los datos de autenticación del usuario en una primera aplicación del dispositivo móvil, y luego transmitir los datos de autenticación del usuario a un sistema informático de autorización. El método también incluye la recepción, por el dispositivo móvil, del sistema informático de autorización, de un código de autenticación a través de la primera aplicación. El código de autenticación puede derivarse de los datos de acceso. El código de autenticación se proporciona desde la primera aplicación a una segunda aplicación en el dispositivo móvil. A continuación, el dispositivo móvil proporciona el código de autenticación a un ordenador de la entidad de validación. El ordenador de la entidad de validación verifica el código de autenticación y obtiene los datos de acceso del código de autenticación. A continuación, puede indicar a un ordenador servidor de aprovisionamiento que proporcione los datos de acceso a la segunda aplicación del dispositivo móvil.
Otra modalidad de la invención está dirigida a un dispositivo móvil configurado para llevar a cabo el método descrito anteriormente.
Estas y otras modalidades se describen en más detalle a continuación, con referencia a las Figuras y la Descripción detallada.
Breve descripción de los dibujos
La Figura 1 muestra un diagrama de bloques de un sistema de acuerdo con una modalidad de la invención.
La Figura 2 muestra un diagrama de bloques de un dispositivo móvil de acuerdo con una modalidad de la invención. La Figura 3 muestra un diagrama de bloques de un ordenador de autorización de acuerdo con una modalidad de la invención.
La Figura 4 muestra un diagrama de bloques de un ordenador de la entidad de validación de acuerdo con una modalidad de la invención.
La Figura 5 muestra un diagrama de flujo que ilustra un método para proporcionar un código de autenticación a una segunda aplicación en un dispositivo móvil.
La Figura 6 muestra un diagrama de flujo que ilustra un método para el aprovisionamiento de datos de acceso a un dispositivo móvil.
La Figura 7 muestra un diagrama de bloques de un sistema y una secuencia de flujo que ilustra otra modalidad de la invención.
La Figura 8 muestra un diagrama de bloques de un sistema de acceso a edificios.
La Figura 9 muestra un diagrama de bloques de un sistema de procesamiento de transacciones que puede utilizar un dispositivo móvil con datos de acceso.
La Figura 10 muestra un diagrama de bloques de un ordenador.
Descripción detallada
Las modalidades de la invención pueden proporcionar una serie de mecanismos diferentes que pueden mejorar la seguridad al acceder a un recurso a través de una aplicación no confiable en un dispositivo móvil. En algunas modalidades, esto puede lograrse solicitando un código de autenticación a través de una aplicación confiable en el dispositivo móvil, en algunas modalidades, el código de activación puede incluir un elemento de datos de tiempo cifrado para que el código de activación esté limitado por tiempo. Un ordenador de la entidad de verificación puede utilizar el elemento de datos de tiempo para decidir si el código de activación aún es válido.
Algunas modalidades de la invención pueden incluir la recepción, por un dispositivo móvil, de datos de autenticación del usuario en una primera aplicación del dispositivo móvil. Una vez que la primera aplicación del dispositivo móvil recibe los datos de autenticación del usuario, se transmite a un sistema informático de autorización. A continuación, el sistema informático de autorización verifica los datos de autenticación. Después de verificar los datos de autenticación, puede generar y transmitir un código de autenticación a la primera aplicación del dispositivo móvil. Una vez que el dispositivo móvil recibe el código de autenticación, la primera aplicación del dispositivo móvil puede proporcionar el código de autenticación a una segunda aplicación en el dispositivo móvil mediante una segunda API de aplicación (interfaz de programación de aplicaciones). La segunda aplicación del dispositivo móvil puede entonces proporcionar el código de autenticación a un ordenador de la entidad de validación. Una vez que el ordenador de la entidad de validación verifica el código de autenticación, puede transmitir una instrucción a un ordenador servidor de aprovisionamiento para proporcionar los datos de acceso a la segunda aplicación en el dispositivo móvil.
En algunas modalidades, el código de autenticación puede ser un código de autenticación bancario móvil y la primera aplicación puede ser una aplicación bancaria móvil. El código de autenticación puede ser generado por un emisor una vez que el emisor haya autenticado o autorizado al consumidor con el fin de personalizar la información de la cuenta del consumidor a un dispositivo móvil. El código de autenticación se puede entregar a la parte que aprovisionará los datos de la cuenta al dispositivo móvil. Esa parte puede autenticar el código antes de realizar el proceso de aprovisionamiento.
Un flujo de proceso de alto nivel de acuerdo con una modalidad de la invención puede describirse de la siguiente manera. En primer lugar, un emisor valida la identidad del consumidor y confirma que el consumidor está autorizado a recibir información de la cuenta de pago en su dispositivo móvil. En segundo lugar, el emisor crea de manera segura el código de autenticación mediante el uso de su ordenador servidor. En tercer lugar, el emisor entrega el código de autenticación a su aplicación bancaria móvil en el dispositivo móvil del consumidor. En cuarto lugar, la aplicación bancaria móvil proporciona el código de autenticación a una aplicación del proveedor de cartera digital en el dispositivo móvil a través de una API (interfaz de programación de aplicaciones). La aplicación del proveedor de cartera digital en el dispositivo móvil proporciona el código de autenticación a un ordenador servidor de la cartera digital localizado de manera remota. En quinto lugar, el ordenador servidor de la cartera digital envía el código de autenticación a un ordenador de la entidad de validación, que puede iniciar el aprovisionamiento de datos de las cuentas de pago o activar la cuenta de pago en la aplicación del proveedor de cartera digital en el dispositivo móvil. Una vez que la aplicación del proveedor de cartera digital del dispositivo móvil está aprovisionada con los datos de la cuenta de pago, se puede permitir o autorizar que el dispositivo móvil realice transacciones de pago.
Antes de describir las modalidades detalladas de la invención, algunas descripciones de determinados términos pueden ser útiles.
Un "dispositivo móvil" puede comprender cualquier dispositivo electrónico que pueda transportarse y operarse por un usuario, que también puede proporcionar capacidades de comunicación remota a una red. Algunos ejemplos de capacidades de comunicación remota incluyen el uso de una red de telefonía móvil (inalámbrica), red de datos inalámbrica (por ejemplo, 3G, 4G o redes similares), Wi-Fi, Wi-Max o cualquier otro medio de comunicación que pueda proporcionar acceso a una red tal como Internet o una red privada. Los ejemplos de dispositivos móviles incluyen teléfonos móviles (por ejemplo, teléfonos celulares), PDA, tabletas, netbooks, ordenadores portátiles, reproductores de música personales, lectores especializados portátiles, dispositivos ponibles (por ejemplo, relojes), vehículos (por ejemplo, coches), etc. Un dispositivo móvil puede comprender cualquier hardware y software adecuado para realizar tales funciones, y puede incluir además múltiples dispositivos o componentes (por ejemplo, cuando un dispositivo tiene acceso remoto a una red mediante el anclaje a otro dispositivo - es decir, usar el otro dispositivo como retransmisor -ambos dispositivos se pueden considerar un único dispositivo móvil).
Los "datos de autenticación" pueden incluir cualquier dato adecuado para la autenticación de un usuario o dispositivo móvil. Los datos de autenticación pueden obtenerse de un usuario o de un dispositivo que opere el usuario. Los ejemplos de datos de autenticación obtenidos de un usuario pueden incluir PIN (números de identificación personal), contraseñas, etc. Los ejemplos de datos de autenticación que pueden obtenerse de un dispositivo pueden incluir números de serie del dispositivo, identificadores de elementos seguros de hardware, huellas dactilares, números de teléfono, números IMEI, etc.
Un "ordenador de la entidad de validación" puede ser cualquier ordenador adecuado que pueda validar datos. En las modalidades de la invención, los datos que se pueden validar pueden incluir un código de autenticación. Puede ser operado por una entidad de validación tal como una organización de pago, una red de procesamiento de pagos, una autoridad de tránsito, un sistema de construcción, un sistema de emisión de boletos, etc.
Un "ordenador servidor de aprovisionamiento" puede incluir cualquier ordenador adecuado que pueda aprovisionar los datos de acceso a un dispositivo.
Los "datos de acceso" pueden incluir cualquier dato adecuado que se pueda utilizar para acceder a un recurso o crear datos que puedan acceder a un recurso. En algunas modalidades, los datos de acceso pueden ser información de cuenta de una cuenta de pago. La información de la cuenta puede incluir un PAN, token de pago, fecha de caducidad, valores de verificación (por ejemplo, CVV, CVV2, dCVV, dCVV2), etc. En otras modalidades, los datos de acceso pueden ser datos que se pueden utilizar para activar los datos de la cuenta. Por ejemplo, en algunos casos, la información de la cuenta puede almacenarse en un dispositivo móvil, pero no se puede activar hasta que el dispositivo móvil reciba la información específica. Esta información específica puede caracterizarse como información de acceso en algunas modalidades. En otras modalidades, los datos de acceso pueden incluir datos que se pueden utilizar para acceder a una localización. Dicha información puede ser información de entradas para un evento, datos para acceder a un edificio, información sobre billetes de tránsito, etc.
Los "identificadores de referencia de datos de acceso" pueden incluir un identificador que pueda identificar los datos de acceso, pero no los datos de acceso reales en sí. Se puede utilizar un identificador de referencia de datos de acceso para identificar los datos de acceso en particular. Por ejemplo, un número de cuenta principal tal como 4000 81988298 1132 puede estar representada por un identificador de referencia de tal cuenta como XP28278978. En las modalidades de la invención, el identificador de referencia de cuenta no puede usarse para llevar a cabo una transacción, pero puede servir como mecanismo de seguridad para permitir que las distintas entidades actúen con respecto a la cuenta sin usar el número de cuenta real.
Una "aplicación" puede ser un programa informático que se utiliza para un fin específico.
Un "elemento de datos de tiempo" puede incluir datos relacionados con cualquier hora adecuada. Por ejemplo, un elemento de datos de tiempo puede ser una hora, fecha, mes, año o cualquier combinación adecuada de lo anterior. El elemento de datos de tiempo también puede derivarse de la fecha, hora, mes, año o cualquier combinación adecuada de lo anterior. Un elemento de datos de tiempo cifrado puede ser un elemento de datos que puede incluir una fecha, hora, mes, año cifrados y/o una combinación adecuada de lo anterior.
Un "dispositivo de acceso" puede ser cualquier dispositivo adecuado para obtener acceso a un recurso. Un dispositivo de acceso puede estar generalmente localizado en cualquier localización adecuada, tal como en la localización de un comerciante. Un dispositivo de acceso puede estar en cualquier manera adecuada. Algunos ejemplos de dispositivos de acceso incluyen los dispositivos POS, teléfonos celulares, PDA, ordenadores personales (PC), tabletas, lectores especializados portátiles, decodificadores, cajas registradoras electrónicas (ECR), cajeros automáticos (ATM), cajas registradoras virtuales (VCR), quioscos, sistemas de seguridad, sistemas de acceso, sitios Web, y similares. Un dispositivo de acceso puede utilizar cualquier modo de operación de contacto o sin contacto adecuado para enviar o recibir datos desde, o asociados a, un dispositivo de pago y/o un dispositivo móvil de usuario.
Un "mensaje de solicitud de autorización" puede ser un mensaje electrónico que se envía a una red de procesamiento de pagos y/o un emisor de una tarjeta de pago para solicitar autorización para una transacción. Un mensaje de solicitud de autorización de acuerdo con algunas modalidades puede cumplir con la norma ISO 8583, que es un estándar para los sistemas que intercambian información de transacciones electrónicas asociada a un pago realizado por un consumidor mediante el uso de un dispositivo de pago o una cuenta de pago. El mensaje de solicitud de autorización puede incluir un identificador de cuenta del emisor que puede estar asociado con un dispositivo de pago o una cuenta de pago. Un mensaje de solicitud de autorización puede comprender además elementos de datos adicionales correspondientes a "información de identificación", que incluye, a manera de ejemplo, un código de servicio, un CVV (valor de verificación de tarjeta), un dCVV (valor de verificación de tarjeta dinámico), una fecha de caducidad, etc. Un mensaje de solicitud de autorización puede comprender además "información de la acción de transacción", tal como cualquier información asociada a una transacción actual, tal como el importe de la transacción, identificador del comerciante, localización del comerciante, etc., así como también cualquier otra información que se pueda utilizar para determinar si se identifica y/o autoriza una transacción.
Un "mensaje de respuesta de autorización" puede ser un mensaje electrónico que responde a un mensaje de solicitud de autorización generado por una institución financiera emisora o una red de procesamiento de pagos. El mensaje de respuesta de autorización puede incluir, solo a manera de ejemplo, uno o más de los siguientes indicadores de estado: La transacción de aprobación se aprobó; rechazó -- la transacción no se aprobó; o llame al centro de respuestas en espera de más información, el comerciante debe llamar al número de teléfono de autorización de llamada gratuita. El mensaje de respuesta de autorización puede incluir además un código de autorización, que puede ser un código que un banco emisor de la tarjeta de crédito devuelve en respuesta a un mensaje de solicitud de autorización en un mensaje electrónico (ya sea directamente o a través de la red de procesamiento de pagos) al dispositivo de acceso del comerciante (por ejemplo, equipo POS) que indica la aprobación de la transacción. El código puede servir como prueba de autorización. Como se indicó anteriormente, en algunas modalidades, una red de procesamiento de pagos puede generar o reenviar el mensaje de respuesta de autorización al comerciante.
El término "ordenador servidor" es típicamente un ordenador poderoso o un clúster de ordenadores. Por ejemplo, el ordenador servidor puede ser una unidad central grande, un clúster de miniordenador o un grupo de servidores que funcionan como una unidad. En un ejemplo, el ordenador servidor puede ser un servidor de base de datos acoplado a un servidor web.
Un "procesador" puede referirse a cualquier dispositivo o dispositivos de cálculo de datos adecuados. Un procesador puede comprender uno o más microprocesadores que trabajan juntos para lograr una función deseada. El procesador puede incluir la CPU que comprende al menos un procesador de datos de alta velocidad adecuado para ejecutar componentes del programa para ejecutar solicitudes generadas por el usuario y/o el sistema. La CPU puede ser un microprocesador como Athlon de AMD, Duron y/o Opteron; IBM y/o PowerPC de Motorola; IBM y el procesador Cell de Sony; Celeron, Itanium, Pentium, Xeon y/o XScale de Intel; y/o los procesadores similares.
Una "memoria" puede ser cualquier dispositivo o dispositivo adecuado que pueda almacenar datos electrónicos. Una memoria adecuada puede comprender un medio legible por ordenador no transitorio que almacena instrucciones que pueden ejecutarse por un procesador para implementar un método deseado. Los ejemplos de memorias pueden comprender uno o más chips de memoria, unidades de disco, etc. Dichas memorias pueden funcionar mediante el uso de cualquier modo de funcionamiento eléctrico, óptico o magnético adecuado.
I. Sistemas
La Figura 1 muestra un diagrama de bloques de un sistema de acuerdo con una modalidad de la invención. La Figura 1 muestra un dispositivo móvil 10 en comunicación con un sistema informático de autorización 40, un ordenador servidor de aprovisionamiento 90, y un ordenador servidor de la cartera digital 60. El dispositivo móvil 10 puede almacenar una primera aplicación 20A y una segunda aplicación 20B. Un ordenador de la entidad de validación 80 está en comunicación con el ordenador servidor de aprovisionamiento 90 y el ordenador servidor de la cartera digital 60. El sistema informático de autorización 40 está en comunicación con el ordenador de la entidad de validación 80.
El ordenador servidor de aprovisionamiento 90 puede configurarse para aprovisionar el dispositivo móvil 10 con los datos de acceso. Puede incluir un procesador y un medio legible por ordenador que comprende un código que hace que el procesador realice cualquier método adecuado asociado con el aprovisionamiento del dispositivo móvil 10 con datos de acceso. También puede mantener una base de datos de direcciones (por ejemplo, una dirección de protocolo IP o de Internet o número de teléfono) para varios dispositivos móviles que se pueden aprovisionar con datos de acceso. El ordenador servidor de aprovisionamiento también puede mantener una base de datos de acceso a aprovisionar. Los datos de acceso a aprovisionar pueden haberse obtenido anteriormente por un emisor que opera el sistema informático de autorización 40 y/o un procesador de pagos que opera el ordenador de la entidad de validación 80.
El ordenador servidor de la cartera digital 60 puede configurarse para mantener una cartera digital asociada al usuario del dispositivo móvil 10 así como a otros usuarios. Una "cartera digital" puede almacenar información de perfil de usuario, información de pago (por ejemplo, PAN o números de cuenta principal, tokens de pago (es decir, sustitutos PAN), valores de verificación tales como CVV, etc.), información de cuentas bancarias, y/o similares, y puede usarse en diversas transacciones, tales como, pero sin limitarse a, comercio electrónico, redes sociales, transferencia de dinero/pagos personales, comercio móvil, pagos de proximidad, juegos y/o similares para compras minoristas, compras de artículos digitales, pagos de servicios públicos, compras de juegos o créditos de juegos de sitios web de juegos, transferencia de fondos entre usuarios y/o similares.
Cada una de las entidades de la Figura 1 puede comunicarse a través de cualquier canal de comunicación o red de comunicaciones adecuada. Una red de comunicaciones adecuada puede ser cualquiera o la combinación de lo siguiente: una interconexión directa; Internet; una red de área local (LAN); una red de área metropolitana (MAN); unas misiones operativas como nodos en la Internet (OMNI); una conexión personalizada segura; una red de área ancha (WAN); una red inalámbrica (por ejemplo, que emplea protocolos tales como, pero sin limitarse a un protocolo de aplicación inalámbrica (WAP), modo I y/o similares); y/o similares.
La Figura 2 muestra un diagrama de bloques de un dispositivo móvil 10 de acuerdo con una modalidad de la invención. En algunas modalidades, el dispositivo móvil 10 puede ser un dispositivo de pago que puede usarse para realizar pagos o un dispositivo que puede permitir a un usuario obtener acceso a una localización. El dispositivo móvil ilustrativo 10 puede comprender un medio legible por ordenador 10B que puede estar presente dentro del cuerpo 10H del dispositivo móvil 10. El medio legible por ordenador 10B puede estar en forma de memoria que almacena datos. En algunos casos, la memoria 10B también puede almacenar información tal como datos de acceso. En general, cualquiera de esta información puede ser transmitida por el dispositivo móvil 10 a otro dispositivo, mediante el uso de cualquier método adecuado, que incluye el uso de la antena 10A o el elemento sin contacto 10G. El cuerpo 10H puede estar en forma de carcasa de sustrato plástico u otra estructura.
El medio legible por ordenador 10B puede comprender un código, ejecutable por el procesador para implementar un método que comprende recibir datos de autenticación del usuario en una primera aplicación del dispositivo móvil; transmitir, por el dispositivo móvil, los datos de autenticación del usuario a un sistema informático de autorización; recibir, por el dispositivo móvil, del sistema informático de autorización, un código de autenticación a través de la primera aplicación; proporcionar, por el dispositivo móvil, el código de autenticación desde la primera aplicación a una segunda aplicación en el dispositivo móvil; proporcionar, por el dispositivo móvil, el código de autenticación a un ordenador de la entidad de validación, en donde el ordenador de la entidad de validación verifica el código de autenticación; y recibir, desde un servidor de aprovisionamiento, en comunicación con el ordenador de la entidad de validación, los datos de acceso. En algunas modalidades, el código de autenticación puede derivarse de los datos de acceso, de manera que el ordenador de la entidad de validación que recibe el código de autenticación puede simplemente descifrar el código de autenticación para obtener la información necesaria para aprovisionar el dispositivo móvil con los datos de acceso.
En algunas modalidades, el dispositivo móvil 10 puede incluir además un elemento sin contacto 10G, que típicamente se implementa en forma de un chip semiconductor (u otro elemento de almacenamiento de datos) con un elemento de transferencia inalámbrica asociada (por ejemplo, transmisión de datos), tal como una antena. El elemento sin contacto 10G puede acoplarse (por ejemplo, incorporarse dentro de) al dispositivo móvil 10 y los datos o instrucciones de control que se transmiten a través de una red móvil pueden aplicarse al elemento sin contacto 10G mediante una interfaz de elemento sin contacto (no se muestra). El elemento 10G sin contacto puede ser capaz de transferir y recibir datos mediante el uso de una capacidad de comunicación inalámbrica de corto alcance. Como se indicó anteriormente, el dispositivo móvil 10 puede comprender componentes para que sean tanto el dispositivo de interrogador (por ejemplo, que recibe datos) como el dispositivo interrogado (por ejemplo, que envía datos). Por lo tanto, el dispositivo móvil 10 puede ser capaz de comunicar y transferir datos o instrucciones de control a través de la red celular (o cualquier otra red inalámbrica adecuada, por ejemplo, Internet u otras redes de datos) y comunicaciones de corto alcance.
El dispositivo móvil 10 puede incluir además un procesador 10C (por ejemplo, un microprocesador) para procesar las funciones del dispositivo móvil 10 y una pantalla 10D para permitir a un consumidor ver los números de teléfono y otra información y mensajes. El dispositivo móvil 10 puede incluir además elementos de entrada 10E para permitir a un usuario introducir información en el dispositivo, un altavoz 10F para permitir al usuario escuchar comunicación de voz, música, etc., y un micrófono 10I para permitir al usuario transmitir su voz a través del dispositivo móvil 10. El dispositivo móvil 10 puede incluir además una antena 10A para la transferencia de datos inalámbrica (por ejemplo, transmisión de datos).
Una memoria 20 puede acoplarse al procesador 10C y puede almacenar una primera aplicación 20A y una segunda aplicación 20B. La memoria 20 puede estar en forma de uno o más dispositivos de memoria (por ejemplo, RAM, EEPROM, chips ROM), mediante el uso de cualquier modo adecuado de almacenamiento de datos. En algunas modalidades, la memoria 20 en el dispositivo móvil 10 puede incluir además un área de almacenamiento segura para almacenar datos confidenciales tales como credenciales de pago (números de cuenta, tokens de pago, valores de verificación, etc.) y datos de acceso. Por ejemplo, la memoria 20 puede ser parte de o puede contener un elemento seguro.
En algunas modalidades, la primera aplicación 20A es una aplicación que está específicamente asociada con el sistema informático de autorización 40 y generalmente es de confianza por la entidad que autoriza asociada con el sistema informático de autorización 40. La primera aplicación 20A puede ser, por ejemplo, una aplicación del emisor tal como una aplicación bancaria móvil. Dichas aplicaciones están generalmente diseñadas por la entidad que autoriza y pueden incluir medidas de seguridad de datos específicamente requeridas por la entidad que autoriza.
La segunda aplicación 20B puede estar asociada a una entidad tal como el ordenador servidor de la cartera digital 60. La entidad que autoriza generalmente confía menos en la segunda aplicación 20B que opera el ordenador de autorización, ya que la segunda aplicación 20B no fue desarrollada por la entidad que autoriza. Algunos ejemplos de aplicaciones pueden incluir aplicaciones de cartera digital, aplicaciones comerciales, aplicaciones de fitness y cualquier otra aplicación adecuada que pueda estar presente en el dispositivo móvil 10.
La Figura 3 muestra un diagrama de bloques de un sistema informático de autorización 40 de acuerdo con una modalidad de la invención. La Figura 3 muestra un ordenador servidor 40A y una base de datos de la cuenta 40B acoplada al ordenador servidor 40A.
La base de datos de la cuenta 40B puede contener cuentas de varios usuarios afiliados a la entidad de autorización asociada con el sistema informático de autorización. Por ejemplo, la entidad que autoriza puede ser un banco emisor y la base de datos 40B puede almacenar información de cuenta para cuentas de tarjetas de crédito y débito para sus clientes.
La base de datos 40B (así como cualquier otra base de datos descrita en la presente descripción) puede ser una base de datos convencional, tolerante a fallos, relacional, escalable y segura, tal como Oracle™ o Sybase™. La base de datos 1204 puede implementarse mediante el uso de varias estructuras de datos estándar, tal como una matriz, una función hash, una lista (vinculada), un archivo de texto estructurado (por ejemplo, XML), una tabla o similares. Dichas estructuras de datos pueden almacenarse en la memoria y/o en archivos (estructurados).
El ordenador servidor 40A puede comprender un procesador 41, que puede acoplarse a una memoria del sistema 42 y una interfaz de comunicación externa 43. Un medio legible por ordenador 44 también puede acoplarse operativamente al procesador 41.
El medio legible por ordenador 44 puede comprender una serie de módulos de software que incluyen un módulo de comunicación 44A, un módulo de cifrado 44B, un módulo de actualización de base de datos 44C, un módulo de generación de código de autenticación 44D, un módulo de autorización 44E, y un módulo de validación 44F.
El módulo de comunicación 44A puede comprender un código que hace que el procesador 41 genere mensajes, reenvíe mensajes, reformatee mensajes y/o se comunique de cualquier otra manera con otras entidades.
El módulo de cifrado 44B puede incluir cualquier algoritmo de cifrado adecuado para cifrar los datos en las modalidades de la invención. Los algoritmos de cifrado de datos adecuados pueden incluir DES, triple DES, AES, etc. También puede almacenar claves de cifrado que se pueden utilizar con tales algoritmos de cifrado. El módulo de cifrado 44B puede utilizar técnicas de cifrado simétrico o asimétrico para cifrar y/o verificar datos.
El módulo de actualización de la base de datos 44C puede funcionar junto con el procesador 41 para actualizar la información de la cuenta en la base de datos de la cuenta 40B.
El módulo de generación de código de autenticación 44D puede comprender el código informático, que cuando se ejecuta por el procesador 41, genera un código de autenticación. Los procesos de generación de código de autenticación específicos se describen en detalle a continuación.
El módulo de autorización 44E puede comprender el código que puede hacer que el procesador 41 evalúe los mensajes de solicitud de autorización para transacciones y determinar si las transacciones deben estar autorizadas. Tales transacciones pueden ser autorizadas o rechazadas en base a varios factores, que incluyen el nivel de fraude potencial y/o el importe de fondos o créditos asociados a las cuentas que se utilizan para realizar las transacciones.
El módulo de validación 44F puede comprender el código, que hace que el procesador 41 valide las credenciales de autenticación recibidas del dispositivo móvil de un usuario. El módulo de validación 44F puede incluir el código para hacer que el procesador 41 recupere los datos de la base de datos 40B y compararlo con los datos recibidos.
El medio legible por ordenador 44 puede comprender un código, ejecutable por el procesador para implementar un método que comprende: recibir, por un ordenador de autorización y desde un dispositivo móvil, datos de autenticación; validar, mediante el ordenador de autorización, los datos de autenticación; determinar, que los datos de autenticación son válidos, en respuesta a la determinación de que los datos de autenticación son válidos; crear un código de autenticación, en donde el código de autenticación comprende una primera porción que comprende información cifrada que comprende un elemento de datos de tiempo cifrado y una segunda porción que comprende información no cifrada, la información no cifrada es capaz de usarse para procesar la información no cifrada; y transmitir el código de autenticación al dispositivo móvil, en donde el código de autenticación se proporciona a un ordenador de la entidad de validación que inicia el aprovisionamiento de datos de acceso al dispositivo móvil.
La Figura 4 muestra un diagrama de bloques de un ordenador de la entidad de validación 80 de acuerdo con una modalidad de la invención. El ordenador de la entidad de validación 80 puede estar también en una red de procesamiento de pagos en algunas modalidades de la invención. El ordenador de la entidad de validación 80 puede comprender un procesador 81, que puede acoplarse a una memoria del sistema 82 y a una interfaz de comunicación externa 83. Un medio legible por ordenador 84 también puede acoplarse operativamente al procesador 81.
En algunas modalidades, el ordenador de validación 80 puede formar parte de una red de procesamiento de pagos que cambia la solicitud de transacción y las respuestas entre emisores y adquirientes. Una red de procesamiento de pagos puede ser una red de procesamiento de transacciones. Una red de procesamiento de transacciones puede procesar transacciones de pago u otros tipos de transacciones de acceso.
El medio legible por ordenador 84 puede comprender una serie de módulos de software, que incluye un módulo de comunicación 84A, un módulo de liquidación 44B, un módulo de validación de código 84C, un módulo de autorización 84D, y un módulo de cifrado 84E.
El módulo de comunicación 84A puede comprender un código que hace que el procesador 81 genere mensajes, reenvíe mensajes, reformatee mensajes y/o se comunique de cualquier otra manera con otras entidades.
El módulo de liquidación 84B puede comprender un código que hace que el procesador 81 resuelva transacciones entre varias entidades, que incluyen emisores y adquirientes.
El módulo de validación de código 84C puede comprender un código que hace que el procesador 81 analice un código de autenticación recibido para determinar si el código de autenticación recibido es válido. En algunas modalidades, el módulo de validación 84C puede obtener un código de autenticación recibido recientemente y puede descifrar (o trabajar con el módulo de cifrado 84E) cualquier dato cifrado. A continuación, puede recuperar un código de autenticación recibido anteriormente del sistema informático de autorización 40 y descifrar cualquier dato cifrado. Alternativamente, los datos recibidos del sistema informático de autorización 40 pueden ser los datos de acceso en sí (sin recibir el código de autenticación). Los datos descifrados del código de autenticación recibido pueden evaluarse y compararse con los datos de acceso recibidos anteriormente, o la información descifrada de un código de autenticación recibido anteriormente para determinar si hay una coincidencia (validando de esta manera el código de autenticación recibido). El módulo de validación de código 84C puede incluir además un código que hace que el procesador 81 reciba un código de autenticación, descifre una porción cifrada del código de autenticación para obtener datos de acceso e inicie el aprovisionamiento de los datos de acceso a un dispositivo móvil.
El módulo de autorización 84D puede comprender un código que puede hacer que el procesador 81 evalúe los mensajes de solicitud de autorización para transacciones y determine si las transacciones deben estar autorizadas. El módulo de autorización puede incluir además un código para enrutar o modificar los mensajes de solicitud y respuesta de autorización a medida que pasan entre varias partes, tales como emisores y adquirentes.
El módulo de cifrado 84E puede incluir cualquier algoritmo de cifrado adecuado para cifrar los datos en las modalidades de la invención. Los algoritmos de cifrado de datos adecuados pueden incluir DES, triple DES, AES, etc. También puede almacenar claves de cifrado que se pueden utilizar con tales algoritmos de cifrado. Las otras claves de cualquier par de clave correspondiente se pueden almacenar en el módulo de cifrado 44B en el sistema informático de autorización 40. El módulo de cifrado 84E puede utilizar técnicas de cifrado simétrico o asimétrico para cifrar y/o verificar datos.
II. Métodos
La Figura 5 muestra un diagrama de flujo que ilustra un método para proporcionar un código de autenticación a una segunda aplicación en un dispositivo móvil. La Figura 6 muestra un diagrama de flujo que ilustra un método para el aprovisionamiento de datos de acceso a un dispositivo móvil. Los métodos mostrados en la Figura 5-6 también pueden describirse con referencia al diagrama del sistema de la Figura 1. Aunque los métodos descritos específicamente a continuación pueden relacionarse con el procesamiento de pagos, las modalidades de la invención pueden aplicarse a otras áreas que no requieren pago.
Antes de la etapa S102, es posible que el usuario desee cargar los datos de acceso en la segunda aplicación 20B. En algunas modalidades, la segunda aplicación 20B puede ser una aplicación de cartera digital asociada con el ordenador servidor de la cartera digital 60. Los datos de acceso pueden ser datos de la cuenta de pago tales como datos de la cuenta de tarjeta de crédito o datos de activación que pueden usarse para activar los datos de la cuenta de pago que ya residen en el dispositivo móvil.
En las modalidades de la invención, el usuario puede iniciar el proceso de carga al iniciar o interactuar de cualquier otra manera con la primera aplicación 20A en el dispositivo móvil 10. La primera aplicación 20A puede ser una aplicación del emisor (por ejemplo, una aplicación bancaria móvil) asociada con el sistema informático de autorización 40. El sistema informático de autorización puede ser un sistema informático del emisor. En otras modalidades, la segunda aplicación 20B puede iniciarse por primera vez, y esto puede invocar o iniciar la primera aplicación 20A para que se inicie. Si la segunda aplicación 20B invoca la primera aplicación 20A para que se inicie, en algunas modalidades, la segunda aplicación 20B puede pasar un identificador de dispositivo móvil y/o un segundo identificador de aplicación a la primera aplicación 20A. Tales identificadores pueden usarse por entidades intermedias posteriores (por ejemplo, el sistema informático de autorización 40) para ayudar a identificar el dispositivo móvil que se va a aprovisionar (si la información del dispositivo no reside todavía en esas entidades intermedias).
Después de iniciar la primera aplicación 20A, la primera aplicación 20A puede presentar al usuario una opción para cargar un número de cuenta (por ejemplo, un número de cuenta de tarjeta de crédito) a la segunda aplicación 20B. Al hacerlo, la primera aplicación también puede pedir al usuario que introduzca los datos de autenticación del usuario y, opcionalmente, cualquier identificador de cuenta asociado con el número de cuenta que se cargará en la segunda aplicación 20B. Por ejemplo, la primera aplicación 20A puede pedir al usuario del dispositivo móvil 10 un PIN (número de identificación personal) o contraseña anteriormente identificada, y opcionalmente un nombre de usuario. Alternativa o adicionalmente, la primera aplicación 20A puede recopilar los datos de autenticación (por ejemplo, un número de serie, número de teléfono, huella digital, etc.) directamente desde el dispositivo móvil 10. En algunos casos, esto puede hacerse automáticamente o sin ninguna entrada o acción del usuario.
En la etapa S102, los datos de autenticación se transmiten desde el dispositivo móvil 10 y se reciben en el sistema informático de autorización 40. Los datos de autenticación pueden transmitirse desde el dispositivo móvil 10 al sistema informático de autorización 40 mediante el uso de cualquier formato de mensaje electrónico adecuado, que incluye un correo electrónico, un mensaje de servicio de mensajería corta (SMS), un mensaje de servicio de mensajería multimedia (MMS), un mensaje de solicitud de protocolo de transferencia de hipertexto (HTTP), un paquete de protocolo de control de transmisión (TCP), un envío de formularios web, etc. El mensaje puede dirigirse a cualquier localización adecuada, tal como una dirección de correo electrónico, un número de teléfono, una dirección de protocolo de Internet (IP) o un localizador uniforme de recursos (URL). Las otras comunicaciones que se describen con respecto a la Figura 1 pueden producirse de la misma manera o diferente.
En la etapa S104, el sistema informático de autorización 40 valida los datos de autenticación. Puede hacerlo recuperando los datos de autenticación anteriormente almacenados para el usuario y, a continuación, comparando los datos de autenticación recuperados con los datos de autenticación recibidos. Por ejemplo, el sistema informático de autorización 40 puede almacenar una contraseña, puede recibir la contraseña correspondiente del dispositivo móvil 10, y puede determinar si la contraseña almacenada coincide con la contraseña recibida. Si los datos de autenticación recibidos no coinciden con los datos de autenticación almacenados anteriormente, el sistema informático de autorización puede generar y transmitir un mensaje 40 al dispositivo móvil 10 indicando que los datos de autenticación introducidos son incorrectos.
En la etapa S106, si los datos de autenticación recibidos coinciden con los datos de autenticación almacenados anteriormente, el sistema informático de autorización 40 puede generar un código de autenticación.
El código de autenticación puede generarse de cualquier manera adecuada. El código de autenticación puede generarse mediante el uso de un proceso de cifrado. En algunas modalidades, el código de autenticación puede incluir una porción cifrada y una porción no cifrada. La porción no cifrada puede usarse para descifrar la porción cifrada. Además, la porción cifrada puede incluir el identificador de cuenta principal (PAN) del consumidor, una fecha y hora en que se generó el código de autenticación (un ejemplo de un elemento de datos de tiempo) o cuando el usuario fue validado por la entidad que autoriza, y un código de autorización específico generado por la entidad de autorización. Al cifrar la fecha y hora en que se generó el código de autenticación o cuando la entidad que autoriza validó el usuario, un ordenador de la entidad que valida el código de autenticación puede determinar si aún es válido. Los métodos específicos para generar códigos de autenticación de acuerdo con las modalidades de la invención se describen en más detalle a continuación. Además, al crear un código de autenticación con una porción cifrada y una porción no cifrada, el código de autenticación puede incluir información sobre cómo recuperar cualquier secreto presente en la porción cifrada. No son necesarias múltiples transmisiones de datos independientes para proporcionar información con respecto al descifrado de la información cifrada.
En la etapa S108, en algunas modalidades, después de generar el código de autenticación, se puede proporcionar al ordenador de la entidad de validación 80 mediante el uso de una ruta de comunicación separada de y no implica el dispositivo móvil 10, o el ordenador servidor de la cartera digital 60. El ordenador de la entidad de validación 80 puede almacenar el código de autenticación recibido en una base de datos. En otras modalidades, el ordenador de la entidad de validación puede recibir los datos de acceso y puede que no reciba el código de autenticación real.
En la etapa S110, el código de autenticación se transmite desde el sistema informático de autorización 40 a la primera aplicación 20A en el dispositivo móvil 10.
En la etapa S112, después de que la primera aplicación 20A del dispositivo móvil 10 reciba el código de autenticación, la primera aplicación 20A luego pasa el código de autenticación a la segunda aplicación 20B en el dispositivo móvil 10 a través de una API adecuada (interfaz de programación de aplicaciones).
En la etapa S114, después de que el código de autenticación se recibe por la segunda aplicación 20B, el dispositivo móvil 10 transmite entonces el código de autenticación al ordenador servidor de la cartera digital 60 mediante el uso de cualquier formato de mensaje electrónico adecuado.
En la etapa S116, después de que el ordenador servidor de la cartera digital 60 reciba el código de autenticación, el ordenador servidor de la cartera digital 60 transmite entonces el código de autenticación al ordenador de la entidad de validación 80 mediante el uso de cualquier formato de mensaje electrónico adecuado.
En la etapa S118, después de que el ordenador de la entidad de validación 80 recibe el código de autenticación, el ordenador de la entidad de validación 80 lo verifica. En algunas modalidades, el módulo de validación 84C en el ordenador de la entidad de validación 80 puede tomar el código de autenticación recibido recientemente y puede descifrar (o trabajar con el módulo de cifrado 84E) cualquier dato cifrado. A continuación, puede recuperar un código de autenticación recibido anteriormente del sistema informático de autorización 40 (almacenado en una base de datos) y descifrar cualquier dato cifrado. Los datos descifrados de los códigos de autenticación anteriormente almacenados y recibidos recientemente pueden compararse para determinar si el código de autenticación recibido actualmente y el código de autenticación almacenado anteriormente coinciden (validando de esta manera el código de autenticación recibido). En otras modalidades, los datos de acceso pueden haberse recibido anteriormente por el ordenador de la entidad de validación 80 del sistema informático de autorización 40. Estos datos de acceso pueden recuperarse de una base de datos y compararse con la información descifrada del código de autenticación recibido. Si hay una coincidencia, y si el código de autenticación es válido de cualquier otra manera (por ejemplo, dentro del periodo de tiempo predeterminado), se puede validar el código de autenticación recibido.
El ordenador de la entidad de validación 80 y el sistema informático de autorización 40 pueden compartir claves de cifrado simétricas que les permitan cifrar y descifrar códigos de autenticación o porciones de los mismos. En otras modalidades, el sistema informático de autorización y el ordenador de la entidad de validación pueden utilizar respectivamente una clave pública para cifrar una porción de un código de autenticación y una clave privada para descifrar la porción del código de autenticación. Si el código de autenticación recibido del sistema informático de autorización 40 no coincide con el código de autenticación recibido del ordenador servidor de la cartera digital 60, entonces se puede transmitir un mensaje al dispositivo móvil 10 indicando que la solicitud de aprovisionamiento ha fallado.
En la etapa S120, si el código de autenticación recibido es válido, el ordenador de la entidad de validación 80 inicia el proceso de aprovisionamiento. Esto se puede hacer de varias maneras. En algunos casos, el ordenador de la entidad de validación 80 puede transmitir un mensaje al ordenador servidor de aprovisionamiento 90 para solicitar que la segunda aplicación del dispositivo móvil se aprovisione con los datos de acceso solicitados por el usuario del dispositivo móvil 10. En otra modalidad, el ordenador servidor de aprovisionamiento 90 puede formar parte del ordenador de la entidad de validación 80 y el aprovisionamiento puede iniciarse sin la transmisión de ningún mensaje de instrucción de aprovisionamiento particular. Si se utiliza un mensaje de instrucción de aprovisionamiento, puede contener los detalles necesarios para aprovisionar el dispositivo móvil 10 con datos de acceso. Dichos detalles pueden incluir los datos de acceso en sí (si no se almacenan ya en el ordenador servidor de aprovisionamiento 90), la dirección (por ejemplo, número de teléfono) asociada con el dispositivo móvil 10 que se aprovisiona), cualquier dato que utilice el dispositivo móvil 10 que permita que el dispositivo móvil 10 acepte los datos de acceso, etc. El ordenador de la entidad de validación 80 y/o el ordenador servidor de aprovisionamiento 90 pueden haber recibido los datos de acceso del sistema informático de autorización 40 en algún momento en el pasado a través de una comunicación diferente. En algunas modalidades, como se explica a continuación, los datos de acceso pueden derivarse del código de autenticación.
En la etapa S122, el ordenador servidor de aprovisionamiento 90 transmite los datos de acceso a la segunda aplicación 20B en el dispositivo móvil 10 para su almacenamiento. En algunas modalidades, el ordenador servidor de aprovisionamiento 90 puede almacenar una clave de cifrado (por ejemplo, una clave ECC pública temporal) y el dispositivo móvil 10 puede almacenar otra clave de cifrado correspondiente. El ordenador servidor de aprovisionamiento 90 puede cifrar los datos de acceso antes de enviarlos al dispositivo móvil 10, y el dispositivo móvil 10 puede descifrar los datos de acceso cifrados tras su recepción. Una vez que el dispositivo móvil 10 recibe y almacena los datos de acceso, el dispositivo móvil 10 puede utilizarse posteriormente para realizar transacciones de pago mediante el uso de la segunda aplicación 20B y los datos de acceso que se aprovisionaron para ello. En algunos casos, los datos de acceso pueden almacenarse en un área segura (por ejemplo, un elemento seguro) en el dispositivo móvil 10.
El proceso descrito anteriormente puede utilizarse para proporcionar datos de acceso estático o dinámico a un dispositivo móvil. Si los datos de acceso son dinámicos, se pueden proporcionar al dispositivo móvil para cada transacción o para un número predeterminado de transacciones (por ejemplo, por cada 5-10 transacciones). Esto ayuda a garantizar que se reduzca el riesgo de fraude resultante de ataques de intermediarios.
La Figura 7 muestra un diagrama del sistema que ilustra los métodos de acuerdo con otras modalidades de la invención.
Antes de la etapa S202, es posible que un usuario desee aprovisionar datos de acceso en la segunda aplicación 20B. En algunas modalidades, la segunda aplicación 20B puede ser una aplicación de cartera digital asociada con el ordenador servidor de la cartera digital 60. Los datos de acceso pueden ser datos de la cuenta de pago tales como datos de la cuenta de tarjeta de crédito.
El usuario puede iniciar el proceso de aprovisionamiento al iniciar o interactuar de cualquier otra manera con la primera aplicación 20A en el dispositivo móvil 10. En algunas modalidades, esto puede hacerse sin ninguna interacción inicial con la segunda aplicación 20B. La primera aplicación 20A puede ser una aplicación del emisor (por ejemplo, una aplicación bancaria móvil) asociada con el sistema informático de autorización 40. El sistema informático de autorización puede ser un sistema informático del emisor. La segunda aplicación 20B puede ser una aplicación de cartera digital asociada con el ordenador servidor de la cartera digital 60.
Después de iniciar la primera aplicación 20A, la primera aplicación 20A puede presentar al usuario una opción para cargar un número de cuenta (por ejemplo, un número de cuenta de tarjeta de crédito) a la segunda aplicación 20B. Al hacerlo, la primera aplicación 20A también puede pedir al usuario que introduzca los datos de autenticación del usuario y, opcionalmente, cualquier identificador de cuenta asociado con el número de cuenta que se cargará en la segunda aplicación 20B. Por ejemplo, la primera aplicación 20A puede pedir al usuario del dispositivo móvil 10 un PIN identificado anteriormente (número de identificación personal) o contraseña, y un nombre de usuario. En algunos casos, el PIN o la contraseña y el nombre de usuario pueden ser simplemente la información de credenciales de usuario necesaria para acceder al sistema informático de autorización 40 con la primera aplicación 20A. Alternativa o adicionalmente, la primera aplicación 20A puede recopilar los datos de autenticación (por ejemplo, un número de serie, número de teléfono, huella digital, etc.) directamente desde el dispositivo móvil 10. En algunos casos, esto puede hacerse automáticamente o sin ninguna entrada o acción del usuario.
En la etapa S202, los datos de autenticación se transmiten desde el dispositivo móvil 10 y se reciben en el sistema informático de autorización 40. Los datos de autenticación pueden transmitirse desde el dispositivo móvil 10 al sistema informático de autorización 40 mediante el uso de cualquier formato de mensaje electrónico adecuado (como se describió anteriormente con respecto a la Figura 1). Las otras comunicaciones que se describen con respecto a la Figura 7 pueden producirse de la misma manera o diferente.
En la etapa S204, el sistema informático de autorización 40 valida los datos de autenticación. Puede hacerlo recuperando los datos de autenticación anteriormente almacenados para el usuario y, a continuación, comparando los datos de autenticación recuperados con los datos de autenticación recibidos. Por ejemplo, el sistema informático de autorización 40 puede almacenar una contraseña, puede recibir la contraseña correspondiente del dispositivo móvil 10, y puede determinar si la contraseña almacenada coincide con la contraseña recibida. Si los datos de autenticación recibidos no coinciden con los datos de autenticación almacenados anteriormente, el sistema informático de autorización puede generar y transmitir un mensaje 40 al dispositivo móvil 10 indicando que los datos de autenticación introducidos son incorrectos.
En la etapa S206, después el sistema informático de autorización 40 valida los datos de autenticación. El sistema informático de autorización 40 envía una respuesta de nuevo a la primera aplicación 20A en el dispositivo móvil 10.
En la etapa S207, la segunda aplicación 20B (y opcionalmente el ordenador servidor de la cartera digital 60) es consultada por la primera aplicación 20A para determinar si alguno de los datos de la cuenta que se almacenan por el sistema informático de autorización 40 ya se han aprovisionado a la segunda aplicación 20A en el dispositivo móvil 10. La primera aplicación 20A puede hacer esto enviando uno o más identificadores de referencia de datos de acceso tales como identificadores de referencia de cuenta que tiene para el usuario del dispositivo móvil 10 a la segunda aplicación S208 (y opcionalmente el ordenador servidor de la cartera digital 60). Los identificadores de referencia de la cuenta pueden asociarse con las cuentas que el usuario tiene con el emisor asociado con el sistema informático de autorización 40. Si la segunda aplicación 20B ha determinado que los datos de acceso (por ejemplo, datos de la cuenta de pago) asociados con uno o más identificadores de referencia de cuenta ya se aprovisionan en la segunda aplicación 20B en el dispositivo móvil 10, entonces la segunda aplicación 20B informa a la primera aplicación 20A de la misma. En algunas modalidades, la segunda aplicación 20B puede enviar cualquier identificador de referencia de cuenta asociado con los datos de la cuenta que ya se han suministrado a la segunda aplicación 20B de regreso a la primera aplicación 20A, que puede reenviarlos al sistema informático de autorización 40. Para mejorar la seguridad, la segunda aplicación 20B y el ordenador servidor de la cartera digital 60 no pueden utilizar los datos reales de la cuenta (por ejemplo, números de cuenta principal reales) para comunicarse, pero en su lugar puede utilizar los identificadores de referencia de la cuenta de pago para comunicarse.
En algunas modalidades, cuando la segunda aplicación 20B devuelve el uno o más identificadores de referencia de número de cuenta (u otro indicador del aprovisionamiento anterior de datos de la cuenta a la segunda aplicación 20A) a la primera aplicación 20A y al sistema informático de autorización 40, la segunda aplicación 20B (o el ordenador servidor de la cartera digital 60) puede enviar información específica de un dispositivo o evento adicional al sistema informático de autorización 40 a través de la primera aplicación 20A para garantizar que el código de autenticación que se genera eventualmente no pueda reproducirse por otro dispositivo de usuario. Esto se puede hacer al devolver uno o más identificadores de referencia de número de cuenta o en un momento diferente. Por ejemplo, la segunda aplicación 20B o el ordenador servidor de la cartera digital 60) pueden tener información específica del dispositivo tal como un identificador para el dispositivo móvil 10 o un identificador para la segunda aplicación 20A (por ejemplo, un identificador de cartera) y puede transmitir esta información (en texto sin cifrar o en formato hash o cifrado) a la primera aplicación 20A y luego al sistema informático de autorización 40. El identificador del dispositivo móvil 10 o la segunda aplicación 20A puede estar en cualquier manera adecuada (por ejemplo, cualquier longitud y/o número de caracteres adecuados). Los tipos de información específica del evento que pueden enviarse desde la segunda aplicación 20B o del ordenador servidor de la cartera digital 60 a la primera aplicación 20A y luego al ordenador de autorización 40 puede incluir marcas de tiempo y nonces. Dicha información puede enviarse desde la segunda aplicación 20B o del ordenador servidor de la cartera digital 60 a la primera aplicación 20A y el sistema informático de autorización 40 en formato de texto cifrado o sin cifrar.
Además, en algunas modalidades, para garantizar que el ordenador de la entidad de validación 80 sepa de cual dispositivo móvil 10 se originó la solicitud, la información específica del evento y/o específica del dispositivo puede firmarse con una clave criptográfica (por ejemplo, una clave privada criptográfica) que puede residir en una memoria (por ejemplo, un elemento seguro) en el dispositivo móvil 10. La información firmada puede entonces proporcionarse por la segunda aplicación 20B a la primera aplicación 20A, y luego al sistema informático de autorización 40.
De manera ilustrativa, la segunda aplicación 20B puede recuperar una clave criptográfica (por ejemplo, una clave privada) de un elemento seguro en el dispositivo móvil 10, y puede usarlo para firmar el evento específico o los datos específicos del dispositivo. Esto puede usarse posteriormente por el ordenador de la entidad de validación 80 para verificar que el dispositivo móvil 10 originó la solicitud de aprovisionamiento. En algunas modalidades, la verificación puede realizarse por el ordenador de la entidad de validación 60 mediante el uso de una clave pública (o una clave privada) asociada con la clave privada que firmó el evento o datos específicos del dispositivo. Por ejemplo, en algunas modalidades, los datos específicos del evento pueden ser un nonce, y el nonce puede estar firmado por una clave privada que reside en el elemento seguro del dispositivo móvil 10. La segunda aplicación 20B puede generar el nonce y puede recuperar la clave privada del elemento seguro del dispositivo móvil 10 para firmarlo. El nonce firmado puede entonces proporcionarse al sistema informático de autorización 40 solo o con el nonce para su inclusión en el código de autenticación generado posteriormente. Esto permitirá al ordenador de la entidad de validación 80 confirmar que la primera y segunda aplicaciones 20A, 20B interaccionan en el dispositivo móvil 10, y que la solicitud de aprovisionamiento procede del dispositivo móvil correcto 10.
En la etapa S208, después de que la primera aplicación 20A reciba los identificadores de referencia del número de cuenta de la segunda aplicación 20B, la primera aplicación 20A y/o el sistema informático de autorización 40 pueden entonces determinar qué datos de la cuenta aún no se han aprovisionado al dispositivo móvil 10. El sistema informático de autorización 40 puede entonces enviar opcionalmente los números de cuenta principal o alias de los números de cuenta principal que aún no se han aprovisionado en la segunda aplicación 20B a la primera aplicación 20A en el dispositivo móvil 10. Mientras esté en la primera aplicación 20A, el usuario puede seleccionar cualquiera de los números de cuenta principal presentados (o alias de los mismos) que aún no se han aprovisionado en la segunda aplicación 20A para que puedan aprovisionarse en la segunda aplicación 20A.
En la etapa S210, si los datos de autenticación recibidos coinciden con los datos de autenticación almacenados anteriormente y el sistema informático de autorización 40 ha determinado que hay datos de la cuenta que se van a aprovisionar, el sistema informático de autorización 40 puede generar un código de autenticación.
El código de autenticación puede generarse de cualquier manera adecuada. El código de autenticación puede generarse mediante el uso de un proceso de cifrado. En algunas modalidades, el código de autenticación puede incluir una porción cifrada y una porción no cifrada. La porción no cifrada puede incluir información que se puede utilizar para descifrar la porción cifrada y/o verificar que la información cifrada es válida o proviene de una fuente válida. Por ejemplo, la porción cifrada o no cifrada puede incluir la información específica del dispositivo y/o específica del evento descrita anteriormente, así como también la versión firmada digitalmente de esta información. Además, la porción cifrada puede incluir el identificador de cuenta principal (PAN) del consumidor, la fecha de caducidad, una fecha y hora en que se generó el código de autenticación (un ejemplo de un elemento de datos de tiempo) o cuando el usuario fue validado por la entidad que autoriza, y el código de autorización específico generado por la entidad de autorización. Al cifrar la fecha y hora en que se generó el código de autenticación o cuando la entidad que autoriza validó el usuario, un ordenador de la entidad que valida el código de autenticación puede determinar si aún es válido. Además, el código de autenticación puede incluir además (en formato cifrado) la información específica del dispositivo y/o específica del evento descrita anteriormente. La información específica del dispositivo y/o del evento firmada puede incluirse además en el código de autenticación (por ejemplo, en formato cifrado).
En otras modalidades, la información específica del dispositivo y/o del evento puede transmitirse con el código de autenticación, pero no se puede incluir en el código de autenticación en sí mismo cuando pasa del sistema informático de autorización 40 al ordenador de la entidad de validación 80.
Los métodos específicos para generar códigos de autenticación de acuerdo con las modalidades de la invención se describen en más detalle a continuación. Además, al crear un código de autenticación con una porción cifrada y una porción no cifrada, el código de autenticación puede incluir información sobre cómo recuperar cualquier secreto presente en la porción cifrada. No son necesarias múltiples transmisiones de datos independientes para proporcionar información con respecto al descifrado de la información cifrada.
En algunas modalidades, el código de autenticación se deriva de los datos de acceso. En algunas modalidades, el código de autenticación puede cifrar todos los datos de acceso de manera que el ordenador servidor de aprovisionamiento pueda obtener todos los datos de acceso del código de autenticación, y no tiene que obtener esta información por separado del sistema informático de autorización 40. Por ejemplo, el código de autenticación puede derivarse de al menos el número de cuenta principal y la fecha de caducidad asociada con el número de cuenta principal, y opcionalmente un valor de verificación tal como un valor CVV o CVV2. En tales modalidades, el código de autenticación puede recibirse y puede utilizarse para obtener el número de cuenta principal, la fecha de caducidad, el CVV y el CVV2. Debido a que todos los datos de acceso pueden derivarse del código de autenticación en algunas modalidades de la invención, el sistema informático de autorización 40 no necesita proporcionar los datos de acceso al ordenador de la entidad de validación 80 o al ordenador servidor de aprovisionamiento 90 en comunicaciones separadas. Esto es particularmente ventajoso, ya que esto reduce la comunicación que de cualquier otra manera sería necesaria entre el sistema informático de autorización 40 y el ordenador de la entidad de validación 80 y el ordenador servidor de aprovisionamiento 90. También resulta ventajoso, debido a que proporciona mayor seguridad para cualquier número de cuenta principal, ya que no es necesario transmitirlo.
Además de tener todos los datos de acceso que se incluyen dentro del propio código de autenticación, en algunas modalidades, cualquier información necesaria para suministrar los datos de acceso al dispositivo móvil 10 puede incluirse además en el código de autenticación. Dicha información puede ser una dirección IP, un número de teléfono, un ID de la cartera digital, un ID de la red de comunicaciones, etc.
Además, en el sistema de aprovisionamiento de acuerdo con las modalidades de la invención, el ordenador del sistema de autorización 40, el ordenador de la entidad de validación 80, y el ordenador servidor de la cartera digital 60 pueden ser operados por diferentes entidades. Aunque es relativamente sencillo tener un sistema informático autenticado a un usuario antes de aprovisionar un dispositivo móvil con datos de acceso, no es sencillo hacerlo cuando varias entidades diferentes participan en el proceso de aprovisionamiento. También es difícil garantizar que los datos de acceso sensibles y otra información confidencial del usuario estén adecuadamente protegidos a medida que se produzca el proceso de aprovisionamiento. Las modalidades de la invención pueden proteger los datos de acceso a medida que pasa entre las distintas entidades del sistema, a la vez que minimizan el número de comunicaciones que sería necesario para aprovisionar el dispositivo móvil 10 con los datos de acceso.
En la etapa S230, en algunas modalidades, después de generar el código de autenticación, se puede proporcionar al ordenador de la entidad de validación 80 mediante el uso de una ruta de comunicación separada de y no implica el dispositivo móvil 10, o el ordenador servidor de la cartera digital 60. El ordenador de la entidad de validación 80 puede almacenar el código de autenticación recibido en una base de datos. En otras modalidades, el ordenador de la entidad de validación puede recibir los datos de acceso y puede que no reciba el código de autenticación real. En otras modalidades, la etapa 230 puede ser opcional, si el ordenador de la entidad de validación 80 simplemente verifica que el código de autenticación recibido se recibió dentro de un período de tiempo válido y verifica que el código de autenticación recibido se originó desde el dispositivo móvil correcto 10.
En la etapa S212, el código de autenticación se transmite (por ejemplo, sobre el aire) desde el sistema informático de autorización 40 hasta la primera aplicación 20A en el dispositivo móvil 10.
En la etapa 214, después de que la primera aplicación 20A del dispositivo móvil 10 reciba el código de autenticación, la primera aplicación 20A pasa el código de autenticación a la segunda aplicación 20B en el dispositivo móvil 10 a través de una API adecuada (interfaz de programación de aplicaciones).
En la etapa S216, después de que el código de autenticación se recibe por la segunda aplicación 20B, el dispositivo móvil 10 transmite entonces el código de autenticación al ordenador servidor de la cartera digital 60 mediante el uso de cualquier formato de mensaje electrónico adecuado.
En la etapa S218, después de que el ordenador servidor de la cartera digital 60 reciba el código de autenticación, el ordenador servidor de la cartera digital 60 transmite entonces el código de autenticación al ordenador de la entidad de validación 80 mediante el uso de cualquier formato de mensaje electrónico adecuado.
En las etapas S212, S214, S216 y S218, se puede transmitir la información específica del dispositivo descrito anteriormente (por ejemplo, un identificador de aplicación de dispositivo y/o de cartera) y/o información específica del evento (por ejemplo, un nonce) junto con el código de autenticación al ordenador de la entidad de validación 80. En otras modalidades, la información específica del dispositivo y/o específica del evento puede transmitirse por separado del código de autenticación al ordenador de la entidad de validación 80. Estos datos pueden estar sin cifrar o cifrado, pero pueden usarse por el ordenador de la entidad de validación 80 confirmando que el código de autenticación procede del dispositivo móvil correcto 10.
En la etapa S220, después de que el ordenador de la entidad de validación 80 recibe el código de autenticación, el ordenador de la entidad de validación 80 lo verifica. En algunas modalidades, el módulo de validación 84C en el ordenador de la entidad de validación 80 puede tomar el código de autenticación recibido recientemente y puede descifrar (o trabajar con el módulo de cifrado 84E) cualquier dato cifrado. A continuación, puede recuperar un código de autenticación recibido anteriormente del sistema informático de autorización (almacenado en una base de datos) y descifrar cualquier dato cifrado. Los datos descifrados de los códigos de autenticación anteriormente almacenados y recibidos recientemente pueden compararse para determinar si el código de autenticación recibido actualmente y el código de autenticación almacenado anteriormente coinciden (validando de esta manera el código de autenticación recibido). En otras modalidades, los datos de acceso pueden haberse recibido anteriormente por el ordenador de la entidad de validación 80 del sistema informático de autorización 40. Estos datos de acceso pueden recuperarse de una base de datos y compararse con la información descifrada del código de autenticación recibido. Si hay una coincidencia, y si el código de autenticación es válido de cualquier otra manera (por ejemplo, dentro del periodo de tiempo predeterminado), se puede validar el código de autenticación recibido.
Además, el ordenador de la entidad de validación 80 también puede verificar el dispositivo firmado anteriormente descrito y/o los datos específicos del evento. Los datos específicos del dispositivo y/o evento pueden obtenerse del ordenador servidor de la cartera digital 60 junto con el código de autenticación. Por ejemplo, en algunas modalidades, como se indica anteriormente, el dispositivo y/o los datos específicos del evento pueden estar firmados por una clave de cifrado en un elemento seguro del dispositivo móvil 10. La firma digital resultante puede ser verificada por el ordenador de la entidad de validación 80 mediante el uso de una clave de cifrado correspondiente (por ejemplo, una clave pública) para garantizar que el dispositivo móvil correcto 10 se aprovisiona con datos de la cuenta.
El ordenador de la entidad de validación 80 y el sistema informático de autorización 40 pueden compartir claves de cifrado simétricas que les permitan cifrar y descifrar códigos de autenticación o porciones de los mismos. En otras modalidades, el sistema informático de autorización y el ordenador de la entidad de validación pueden utilizar respectivamente una clave pública para cifrar una porción de un código de autenticación y una clave privada para descifrar la porción del código de autenticación. Si el código de autenticación recibido del sistema informático de autorización 40 no coincide con el código de autenticación recibido del ordenador servidor de la cartera digital 60, entonces se puede transmitir un mensaje al dispositivo móvil 10 indicando que la solicitud de aprovisionamiento ha fallado.
Como se indicó anteriormente, en algunas modalidades, el código de autenticación puede contener (en formato cifrado) los datos de acceso que se aprovisionarán al dispositivo móvil 10. El descifrado del componente de información cifrada en el código de autenticación proporcionará al ordenador de la entidad de validación 80 y/o al ordenador servidor de aprovisionamiento 90 toda la información que necesita para proporcionar la segunda aplicación 20B en el dispositivo móvil 10 con los datos de acceso. Por tanto, no es necesario que el ordenador servidor de aprovisionamiento 90 reciba los datos de acceso del sistema informático de autorización 40. Esto reduce el número de transmisiones de datos necesarias para aprovisionar la segunda aplicación 20B con datos de acceso.
En la etapa S220, si el código de autenticación recibido del sistema informático de autorización 40 coincide con el código de autenticación recibido del ordenador servidor de la cartera digital 60, el ordenador de la entidad de validación 80 inicia entonces el proceso de aprovisionamiento. Esto se puede hacer de varias maneras. En algunos casos, el ordenador de la entidad de validación 80 puede transmitir un mensaje al ordenador servidor de aprovisionamiento 90 para solicitar que la segunda aplicación del dispositivo móvil se aprovisione con los datos de acceso solicitados por el usuario del dispositivo móvil 10. En otra modalidad, el ordenador servidor de aprovisionamiento 90 puede formar parte del ordenador de la entidad de validación 80 y el aprovisionamiento puede iniciarse sin la transmisión de ningún mensaje de instrucción de aprovisionamiento particular. Si se utiliza un mensaje de instrucción de aprovisionamiento, puede contener los detalles necesarios para aprovisionar el dispositivo móvil 10 con datos de acceso. Dichos detalles pueden incluir los datos de acceso en sí, la dirección (por ejemplo, número de teléfono) asociada con el dispositivo móvil 10 a aprovisionar), cualquier dato que utilice el dispositivo móvil 10 que permita al dispositivo móvil 10 aceptar los datos de acceso, etc.
En la etapa S222, el ordenador de la entidad de validación 30 transmite un mensaje al ordenador servidor de aprovisionamiento 90 para que inicie el proceso de aprovisionamiento. En la etapa 224, el ordenador servidor de aprovisionamiento 90 transmite los datos de acceso a la segunda aplicación 20B en el dispositivo móvil 10 para su almacenamiento. En algunas modalidades, el ordenador servidor de aprovisionamiento 90 puede almacenar una clave de cifrado (por ejemplo, una clave ECC pública temporal) y el dispositivo móvil 10 puede almacenar otra clave de cifrado correspondiente. El ordenador servidor de aprovisionamiento 90 puede cifrar los datos de acceso antes de enviarlos al dispositivo móvil 10, y el dispositivo móvil 10 puede descifrar los datos de acceso cifrados tras su recepción. El dispositivo móvil 10 puede entonces utilizarse para realizar transacciones de pago mediante el uso de la segunda aplicación 20B y los datos de acceso que se aprovisionaron para ello. En algunos casos, los datos de acceso pueden almacenarse en un área segura (por ejemplo, un elemento seguro) en el dispositivo móvil 10.
El proceso descrito anteriormente puede utilizarse para proporcionar datos de acceso estático o dinámico a un dispositivo móvil. Si los datos de acceso son dinámicos, se pueden proporcionar al dispositivo móvil para cada transacción o para un número predeterminado de transacciones (por ejemplo, por cada 5-10 transacciones). Esto ayuda a garantizar que se reduzca el riesgo de fraude resultante de ataques de intermediarios.
Una vez que el dispositivo móvil 10 se aprovisiona con datos de acceso, puede usarse para realizar una transacción de acceso. La Figura 8 ilustra un sistema que incluye un dispositivo móvil que se aprovisiona con datos de acceso y que puede permitir a un usuario acceder a una localización tal como un edificio. La Figura 9 ilustra un sistema de procesamiento de pagos que incluye un dispositivo móvil que se aprovisiona con datos de acceso y que permite a un usuario acceder a una cuenta para pagar un artículo o servicio a un comerciante.
La Figura 8 muestra un diagrama de bloques de un sistema de acceso a edificios. La Figura 8 muestra un dispositivo móvil 110 operado por un usuario 206. El dispositivo móvil 110 se ha aprovisionado con datos de acceso como se describió anteriormente. El dispositivo móvil 110 puede interactuar con el dispositivo de acceso 120 y pasar los datos de acceso al dispositivo de acceso 120. El dispositivo de acceso 120 puede verificar localmente los datos de acceso recibidos o puede comunicarse con un servidor de autenticación localizado remotamente (no se muestra). El servidor de autenticación de localización remota puede verificar que los datos de acceso son auténticos y que pueden transmitir una señal que indica esto al dispositivo de acceso 120. El dispositivo de acceso 120 puede entonces proceder a permitir al usuario 206 que entre al edificio 130.
La Figura 9 muestra un diagrama de bloques de un sistema de procesamiento de transacciones que puede utilizar un dispositivo móvil con datos de acceso. La Figura 9 muestra un usuario 206 que puede operar un dispositivo móvil 210. El usuario 206 puede utilizar el dispositivo móvil 210 para pagar un artículo o servicio a un comerciante. El comerciante puede operar un ordenador del comerciante 230 y/o un dispositivo de acceso 220. El comerciante puede comunicarse con un ordenador del emisor 260 a través de un ordenador del adquiriente 240 y una red de procesamiento de pagos 250.
Una red de procesamiento de pagos 250, puede incluir subsistemas de procesamiento de datos, redes y operaciones utilizadas para soportar y suministrar servicios de autorización, servicios de archivos de excepción y servicios de compensación y liquidación. Una red de procesamiento de pagos ilustrativo puede incluir VisaNet™. Una red de procesamiento de pagos tal como VisaNet™ puede procesar transacciones con tarjeta de crédito, transacciones con tarjeta de débito o cualquier otro tipo de transacción comercial. VisaNet™, en particular, incluye un sistema VIP (sistema de pagos integrados de Visa) que procesa solicitudes de autorización y un sistema Base II que realiza servicios de compensación y liquidación. La red de procesamiento de pagos puede utilizar cualquier red inalámbrica o por cable adecuada, que incluye Internet.
Un flujo de transacción de pago típico mediante el uso de un dispositivo móvil 210 en un dispositivo de acceso 220 (por ejemplo, localización de POS) puede describirse de la siguiente manera. Un usuario 206 presenta su dispositivo móvil 210 a un dispositivo de acceso 220 para pagar por un artículo o servicio. El dispositivo móvil 210 y el dispositivo de acceso 220 interactúan de manera que los datos de acceso desde el dispositivo móvil 210 (por ejemplo, PAN, un token de pago, valor(es) de verificación, fecha de caducidad, etc.) se reciben por el dispositivo de acceso 220 (por ejemplo, a través de interfaz de contacto o sin contacto). El ordenador del comerciante 230 puede entonces recibir esta información del dispositivo de acceso 220 a través de una interfaz de comunicación externa. El ordenador del comerciante 230 puede entonces generar un mensaje de solicitud de autorización que incluye la información recibida del dispositivo de acceso 220 (es decir, información correspondiente al dispositivo móvil 210) junto con información de transacción adicional (porejemplo, un importe de transacción, información específica del comerciante, etc.) y transmitir electrónicamente esta información a un ordenador del adquiriente 240. El ordenador del adquiriente 240 puede recibir, procesar y enviar el mensaje de solicitud de autorización a una red de procesamiento de pagos 250 para su autorización.
En general, antes de la ocurrencia de una transacción con tarjeta de crédito o débito, la red de procesamiento de pagos 250 tiene un protocolo establecido con cada emisor sobre cómo se autorizarán las transacciones del emisor. En algunos casos, tal como cuando el importe de la transacción está por debajo de un valor umbral, la red de procesamiento de pagos 250 puede configurarse para autorizar la transacción basándose en la información que tiene sobre la cuenta del usuario sin generar y transmitir un mensaje de solicitud de autorización al ordenador del emisor 260. En otros casos, tales como cuando el importe de la transacción está por encima de un valor umbral, la red de procesamiento de pagos 250 puede recibir el mensaje de solicitud de autorización, determinar el emisor asociado con el dispositivo móvil 210, y enviar el mensaje de solicitud de autorización para la transacción al ordenador del emisor 260 para su verificación y autorización. Una vez autorizada la transacción, el ordenador del emisor 260 puede generar un mensaje de respuesta de autorización (que puede incluir un código de autorización indicando que la transacción está aprobada o rechazada) y transmitir este mensaje electrónico a través de su interfaz de comunicación externa a la red de procesamiento de pagos 250. La red de procesamiento de pagos 250 puede entonces reenviar el mensaje de respuesta de autorización al ordenador del adquiriente 240, que a su vez puede transmitir el mensaje electrónico que comprende la indicación de autorización al ordenador del comerciante 230, y luego al dispositivo de acceso 220.
Al final del día o en algún otro intervalo de tiempo adecuado, se puede realizar un proceso de compensación y liquidación entre el ordenador del comerciante 230, el ordenador del adquiriente 240, la red de procesamiento de pagos 250 y el ordenador del emisor 260 en la transacción.
III. Generación de código de autenticación
El código de autenticación descrito anteriormente puede formatearse de cualquier manera adecuada. Por ejemplo, los datos utilizados para generar el código de autenticación se pueden proteger criptográficamente mediante cifrado. Se pueden utilizar muchos tipos diferentes de esquemas de cifrado. Cualquier esquema de clave adecuado se puede establecer entre las partes que crean y verifican el código de autenticación.
El código protegido criptográficamente puede codificarse según sea necesario para el transporte. Por ejemplo, en las modalidades de la invención, se pueden utilizar BASE-64, hexabinario u otros esquemas de codificación para transportar el valor en mensajes basados en texto. El esquema utilizado puede indicarse explícitamente en un mensaje que se utiliza para transportar el código de autenticación o puede ser implícito debido a acuerdos anteriores entre las partes involucradas.
Antes del cifrado, los datos pueden formatearse de acuerdo con un esquema predeterminado. Este formato puede contener información general aplicable a todos los usos y datos específicos del uso. En algunas modalidades, los datos pueden estructurarse con los siguientes datos antes de cifrar:
o Información de control: se ha utilizado la información de transporte al destinatario necesaria para procesar la información (por ejemplo, formato, codificación de caracteres)
o Dígitos o caracteres de aleatorización
o Longitud total de los datos específicos del uso
o Datos específicos del uso
o Rellenado (según sea necesario para el esquema criptográfico)
Los datos específicos del uso pueden formatearse de manera tal que el contenido de los datos sea evidente. Los datos específicos del uso pueden incluir un elemento de datos de tiempo cuando el código está sujeto a limitación temporal. El esquema de rellenado, si se utiliza, se identificará de la información de control.
A. Formato del código de autenticación
En algunas modalidades, el código de autenticación comprende dos partes principales, cada una de las cuales puede contener múltiples elementos. La primera parte puede incluir información de texto sin cifrar. La información de texto sin cifrar incluye información necesaria para procesar la información cifrada. La segunda parte puede incluir información cifrada. La información cifrada contiene datos protegidos proporcionados por la entidad que autoriza (por ejemplo, un emisor) para habilitar una entidad de validación (por ejemplo, un procesador de pagos o una autoridad de acceso) para verificar la autenticidad y validez del código de autenticación.
La primera y segunda partes se pueden concatenar para construir el código de autenticación. El código de autenticación puede recibirse en una primera aplicación y luego transmitirse a una segunda aplicación (por ejemplo, a través de una API del proveedor de la cartera digital) en un dispositivo móvil como un único elemento de datos. En algunas modalidades, el código de autenticación construido puede ajustarse al siguiente diseño, donde cada valor de componente está separado por un guion (-): type-version-keyindex-encryptedinformation
"Type" puede ser un componente de texto sin cifrar que identifica el tipo de código de autenticación presente. Por ejemplo, el tipo de código puede ser un código de aprovisionamiento de cuenta de pago, un código de acceso al edificio, un código de activación de cuenta de pago, etc. El "type" puede ser de cualquier forma adecuado, que incluye letras, números, símbolos, etc. Por ejemplo, un código de autenticación de activación bancaria móvil tiene la forma "MBAAC".
"Version" puede ser un componente de texto sin cifrar que especifica el formato o la versión del código de autenticación que fue construido por el emisor.
"Key index" puede ser un componente de texto sin cifrar que identifica la clave de cifrado de datos específica que se utilizó para cifrar el componente encryptedinformation. Este valor puede coordinarse entre la entidad de autorización y la entidad de validación. Puede expresarse como un entero positivo o como cualquier otro símbolo, carácter o identificador adecuado. En otras modalidades de la invención, se puede utilizar un "key name" en lugar de o además de un "key index" en el código de autenticación.
"Encrypted information" puede ser un componente que contiene varios elementos de datos que se formatean de acuerdo con una sintaxis específica en texto ASCII, encriptada y luego codificada en hexabinario antes de la inclusión en un campo de datos de código de autenticación. Cada uno de los elementos contenidos dentro del componente encryptedinformation puede utilizar una sintaxis de par de nombre/valor, con cada par de nombre/valor separado por un punto y coma. Los pares de nombre/valor pueden utilizar la siguiente sintaxis: name=value.
En algunas modalidades, los siguientes elementos de datos pueden incluirse dentro del componente encryptedinformation para crear un código de autenticación que se puede utilizar para aprovisionar una segunda aplicación en un dispositivo móvil con datos de la cuenta:
Figure imgf000017_0001
Los siguientes pueden ser datos de muestra, antes de cifrar:
pan= 1234567890123456;datetime=20140424221300;authcode=846932
pan=1234567890123456;datetime=20140424221400;authcode=8AC93Z
Los datos estructurados se cifran. Una vez cifrado, puede convertirse a formato hexBinario para incluirlo en el código de autenticación como el componente encryptedinformation.
En algunas modalidades, el componente encrypted information puede incluir todos los datos de acceso para que la información necesaria para aprovisionar el dispositivo móvil 10 esté presente cuando la información cifrada se descifre. Por ejemplo, puede incluir además una fecha de caducidad, además del número de cuenta principal. También puede incluir un valor de verificación tal como un valor CVV o CVV2. Además, para ayudar a evitar la reproducción o el reinicio del código de autenticación, se puede incluir información específica del dispositivo (por ejemplo, ID de dispositivo o ID de la cartera) o información específica del evento (por ejemplo, un nonce) en la información cifrada como se describió anteriormente.
B. Código de autenticación de muestra
La siguiente es una muestra de un código de autenticación construido. Tenga en cuenta que el componente encryptedinformation mostrado es un ejemplo, pero los códigos de autenticación pueden ser más cortos que el ejemplo mostrado a continuación.
MBAAC-1-1-7AF291 C91 F3ED4EF92C1D45EFF127C1F9ABC12347E
C. Parámetros clave de cifrado de zona
Las claves de cifrado de datos utilizadas para proteger componente encryptedinformation pueden ser claves simétricas triple-DES (TDEA) de doble longitud. Pueden utilizarse con el único propósito del cifrado de datos transitorios entre partes, y generalmente no son lo mismo que PIN, MAC u otras claves de cifrado específicas.
La(s) clave(s) utilizada(s) pueden transmitirse entre la entidad que autoriza y la entidad de validación mediante el uso de los esquemas de transporte y protección de clave convencionales antes de su uso.
D. Formato de bloque de cifrado
El componente encryptedinformation dentro del Código de autenticación puede formatearse mediante un esquema de bloqueo de cifrado. Un esquema de bloqueo puede ayudar a proteger el Código de autenticación de situaciones de ataque y puede proporcionar un método coherente para que el sistema receptor identifique los datos significativos en el/los bloque(s) de cifrado.
La siguiente sección describe la estructura y los parámetros de formato de los bloques de cifrado antes de cifrar. Cada uno de estos bloques de cifrado puede formatearse especialmente con una estructura coherente para facilitar el procesamiento y la seguridad adicional. El primer bloque puede contener información de control adicional que no está presente en los bloques restantes.
• Un campo de control (primer bloque solamente) - los campos de control pueden incluir cualquier dato utilizado para transmitir información al destinatario necesaria para procesar la información (por ejemplo, formateo, codificación de caracteres)
• Un segundo campo de control (primer bloque solamente)
• Dígitos o caracteres de aleatorización (primer bloque solamente).
• Un campo de longitud de datos de dos dígitos - incluye el número de dígitos o caracteres de datos que se van a cifrar (primer bloque solamente). Excluye los dígitos o caracteres de control, reservados, longitud, llenado y aleatorización
• Datos a cifrar -dígitos ASCII normales de 7 bits (segundo al último bloque) Contiene los caracteres de texto sin cifrar de los datos que se van a proteger en el encryptedinformation en un formato de caracteres ASCII - puede utilizar uno o más bloques de cifrado de 8 bytes (64 bits), según sea necesario para adaptarse a la longitud de los datos a proteger
• Las posiciones no utilizadas restantes pueden incluir caracteres de relleno según sea necesario
A continuación, se puede describir un proceso de formateo de bloque de cifrado ilustrativo.
Primer blo ue
Figure imgf000018_0001
Se undo al último blo ue
Figure imgf000018_0002
En el ejemplo anterior, C1 puede ser el campo de control 1. Este puede ser un valor binario tal como 00100000 (un blanco en formato de texto ASCII). C2 puede ser el campo de control 2. Este también puede ser un valor binario tal como 00100000 (un blanco en formato de texto ASCII). R puede ser un carácter de aleatorización. Puede contener un carácter ASCII aleatorio de 7 bits. L1 y L2 pueden indicar la longitud de los datos. L1 y L2 pueden incorporarse por dos dígitos ASCII de 7 bits que contienen la longitud (número de caracteres) de los datos presentes en el bloque de cifrado. Por ejemplo, L1 =00110010 (ASCII ’2’) y L2=00110110 (ASCII ’6’) indica que hay veintiséis caracteres. D puede ser datos del par nombre/valor (por ejemplo, un carácter ASCII de 7 bits). D/F puede ser un carácter de par de Nombre/Valor o de relleno. La designación de estos campos está determinada por el campo de longitud. F puede ser un carácter de relleno. F puede ser un valor binario tal como 00100001 ('!' en formato de texto ASCII).
Los bloques de cifrado se pueden cifrar mediante el uso de el algoritmo de cifrado Triple DES (TDEA) con el encadenamiento de bloque de cifrado (CBC) para producir los datos cifrados para su inclusión en el componente encryptedinformation del Código de autenticación. En algunas modalidades, el componente encryptedinformation se puede convertir a formato hexabinario, antes de la inclusión en el código de autenticación.
Se puede describir un ejemplo de bloques de cifrado (texto sin cifrar, antes del cifrado) de la siguiente manera. Se pueden formatear los siguientes datos para que se incluyan en el componente encryptedinformation: pan=1234567890123456;datetime=20140424221300;authcode=846932
Se pueden construir nueve bloques de cifrado de 64 bits con formato de texto sin cifrar (caracteres normales codificados en ASCII de 7 bits) antes del cifrado.
Bits 1-8 9 -16 17 -24 25 -32 33-40 4 1 - 48 49 - 56 57 -64
1er b lo q u e Z 0 S A 6 0
2 d0 b lo q u e P a n = 1 2 3 4
3 er b lo q u e 5 6 7 8 9 0 1 2
4 t0 b lo q u e 3 4 5 6 d a t
5*° b lo q u e e t i m e = 2 0
6 t0 b lo q u e 1 4 0 4 2 4 2 2
7 mo b lo q u e 1 3 0 0 a u t
8 vo b lo q u e h c 0 d e = 8 4
9 D io q u e O 9 3 2
La Figura 9 es un diagrama de bloques de alto nivel de un sistema informático que puede utilizarse para implementar cualquiera de las entidades o componentes descritos anteriormente. Los subsistemas mostrados en la Figura 9 están interconectados a través de un bus de sistema 775. Los subsistemas adicionales incluyen una impresora 774, un teclado 778, una memoria del sistema 772 y un monitor 776, que está acoplado al adaptador de pantalla 782. Periféricos y dispositivos de entrada/salida (I/O), que se acoplan al controlador de E/S 771. Por ejemplo, la interfaz externa 722 se pueden usar para conectar el aparato informático a una red de área amplia tal como Internet, un dispositivo de entrada de un ratón o un escáner, a través de un puerto de entrada/salida 777. La interconexión a través del bus del sistema 775 permite que el procesador central 773 se comunique con cada subsistema y controle la ejecución de instrucciones desde la memoria del sistema 772 o el/los dispositivo(s) de almacenamiento 779, así como también el intercambio de información entre subsistemas. La memoria del sistema 772 y/o el/los dispositivo(s) de almacenamiento pueden ser incorporarse por un medio legible por ordenador.
Las modalidades de la invención tienen varias ventajas. Por ejemplo, como se indicó anteriormente, en las modalidades de la invención, una aplicación no confiable puede aprovisionarse con datos de acceso realizando primero la solicitud de los datos de acceso mediante el uso de una primera aplicación confiable asociada a una entidad que autoriza. El usuario y la entidad que autoriza pueden estar seguros de que la solicitud de los datos de acceso es auténtica y no fraudulenta. Además, el uso del código de autenticación descrito anteriormente puede permitir a una parte distinta de la entidad que autoriza aprovisionar los datos de acceso. Por último, dado que el código de autenticación tiene una porción cifrada que es un elemento de datos de tiempo, y una parte sin cifrar que contiene información sobre cómo procesar la porción cifrada, el código de autenticación puede usarse por las distintas partes para verificar que la solicitud de aprovisionamiento es auténtica y válida.
Las modalidades de la invención tienen varias ventajas adicionales. Como se explicó anteriormente, en el sistema de aprovisionamiento de acuerdo con las modalidades de la invención, el ordenador del sistema de autorización, el ordenador de la entidad de validación y el ordenador servidor de la cartera digital pueden ser operados por diferentes entidades. Aunque es relativamente sencillo tener un sistema informático autenticado a un usuario antes de aprovisionar un dispositivo móvil con datos de acceso, no es sencillo hacerlo cuando varias entidades diferentes participan en el proceso de aprovisionamiento. También es difícil garantizar que los datos de acceso sensibles y otra información confidencial del usuario estén adecuadamente protegidos a medida que se produzca el proceso de aprovisionamiento. Las modalidades de la invención pueden proteger los datos de acceso a medida que pasa entre las distintas entidades del sistema, a la vez que minimizan el número de comunicaciones que sería necesario para aprovisionar el dispositivo móvil 10 con los datos de acceso. El código de autenticación que se utiliza para verificar que el dispositivo móvil 10 pueda recibir los datos de acceso, puede contener los datos de acceso en sí, eliminando de esta manera la necesidad de un sistema informático de autorización para comunicar por separado los datos de acceso al ordenador de la entidad de validación y/o al ordenador servidor de aprovisionamiento.
Debe entenderse que la presente invención como se describió anteriormente puede implementarse en forma de lógica de control mediante el uso de software informático de manera modular o integrada. En base a la descripción y las enseñanzas proporcionadas en la presente descripción, un experto en la técnica puede conocer y apreciar otras maneras y/o métodos para implementar la presente invención mediante el uso de hardware y una combinación de hardware y software.
Cualquiera de los componentes o funciones de software descritos en esta solicitud, puede implementarse como código de software para que se ejecute por un procesador con el uso de cualquier lenguaje de ordenador adecuado tal como, por ejemplo, Java, C++ o Perl que usan, por ejemplo, técnicas convencionales u orientadas a objetos. El código de software puede almacenarse como una serie de instrucciones o comandos en un medio legible por ordenador, tal como una memoria de acceso aleatorio (RAM), una memoria de solo lectura (ROM), un medio magnético tal como un disco duro o un disco flexible, o un medio óptico tal como un CD-ROM. Cualquiera de estos medios legibles por ordenador puede residir en o dentro de un solo aparato informático, y puede estar presente en o dentro de diferentes aparatos informáticos dentro de un sistema o red.
Aunque ciertas modalidades ilustrativas se han descrito en detalle y se muestran en los dibujos adjuntos, se entiende que tales modalidades son simplemente ilustrativas y no pretenden ser restrictivas de la amplia invención, y que esta invención no debe limitarse a las disposiciones y construcciones específicas mostradas y descritas, dado que otras modificaciones pueden producirse por los expertos en la técnica.
Como se usa en la presente descripción, el uso de "un", "una" o "el/los" pretende decir "al menos uno", a menos que se indique específicamente lo contrario

Claims (14)

REIVINDICACIONES
1. Un método (500, 600) para el aprovisionamiento de datos de acceso a una segunda aplicación no confiable (20B) en un dispositivo móvil mediante el uso de una primera aplicación confiable (20A) en el dispositivo móvil, que comprende:
recibir, por el dispositivo móvil, datos de autenticación del usuario en la primera aplicación confiable del dispositivo móvil, en donde los datos de autenticación del usuario se utilizan para autenticar al usuario del dispositivo móvil;
transmitir (S102), por el dispositivo móvil, los datos de autenticación del usuario a un sistema informático de autorización, en donde el sistema informático de autorización valida los datos de autenticación transmitidos, y en el caso de validación correcta de los datos de autenticación, generar (S106) un código de autenticación y, a continuación, transmitir (S108) el código de autenticación a un ordenador de la entidad de validación; a continuación
recibir (S110), por el dispositivo móvil, desde el sistema informático de autorización, el código de autenticación a través de la primera aplicación confiable, en donde el código de autenticación se deriva de los datos de acceso; y en donde los datos de acceso corresponden a los datos que el usuario del dispositivo móvil puede utilizar para acceder a un recurso o localización; a continuación
proporcionar (S112), por el dispositivo móvil, el código de autenticación de la primera aplicación confiable a la segunda aplicación no confiable en el dispositivo móvil; a continuación,
proporcionar (S116), por la segunda aplicación no confiable del dispositivo móvil, el código de autenticación al ordenador de la entidad de validación, en donde el ordenador de la entidad de validación verifica el código de autenticación proporcionado (S118) y en caso de verificación correcta del código de autenticación proporcionado, entonces obtiene los datos de acceso del código de autenticación; y
recibir (S122), tras dicha verificación correcta, por la segunda aplicación no confiable del dispositivo móvil desde un ordenador servidor de aprovisionamiento en comunicación con el ordenador de la entidad de validación, los datos de acceso,
en donde el código de autenticación comprende una primera porción que comprende información cifrada y una segunda porción que comprende información sin cifrar, la información sin cifrar que contiene información sobre cómo procesar la información cifrada, de manera que se pueda verificar la validez del código de autenticación.
2. El método (500, 600) de acuerdo con la reivindicación 1, en donde el dispositivo móvil es un teléfono móvil.
3. El método (500, 600) de acuerdo con la reivindicación 1 o 2, en donde el ordenador de la entidad de validación es una red de procesamiento de transacciones.
4. El método (500, 600) de acuerdo con cualquier reivindicación anterior, en donde los datos de acceso comprenden una fecha de caducidad.
5. El método (500, 600) de acuerdo con cualquier reivindicación anterior, en donde la primera porción que comprende la información cifrada comprende un elemento de datos de tiempo cifrado.
6. El método (500, 600) de acuerdo con la reivindicación 5, en donde la segunda porción que comprende información sin cifrar comprende un índice de la clave, el índice de la clave es capaz de identificar una clave usada para descifrar la información cifrada.
7. El método (500, 600) de acuerdo con cualquier reivindicación anterior, en donde la primera porción que comprende la información cifrada comprende el número de cuenta principal del consumidor, una fecha y hora en la que se generó el código de autenticación, y un código de autorización generado por el sistema informático de autorización en formato cifrado.
8. El método (500, 600) de acuerdo con la reivindicación 7, en donde el ordenador de la entidad de validación verifica el código de autenticación mediante el uso de la información sin cifrar para descifrar la información cifrada, obtener el código de autorización del código de autenticación y comparar el código de autorización obtenido con un código de autorización obtenido del sistema informático de autorización.
9. El método (500, 600) de acuerdo con cualquier reivindicación anterior, en donde la información cifrada comprende además un nonce en forma cifrada.
10. El método (500, 600) de acuerdo con cualquier reivindicación anterior, en donde la información cifrada se formatea mediante un esquema de bloqueo de cifrado.
11. El método (500, 600) de acuerdo con cualquier reivindicación anterior, en donde la primera aplicación es una aplicación bancaria móvil y la segunda aplicación es una aplicación de cartera digital.
12. Un sistema para el aprovisionamiento de datos de acceso a una segunda aplicación no confiable (20B) en un dispositivo móvil (10) mediante el uso de una primera aplicación confiable en el dispositivo móvil (10), el sistema que comprende:
el dispositivo móvil (10);
un sistema informático de autorización (40);
un ordenador de la entidad de validación (80); y
un ordenador servidor de aprovisionamiento (90);
en donde cada uno de los dispositivos móviles (10), el sistema informático de autorización (40), el ordenador de la entidad de validación (80), y el ordenador servidor de aprovisionamiento (90) comprende un medio legible por ordenador no transitorio que comprende el ejecutable de código por el procesador respectivo configurado para implementar un método de acuerdo con cualquiera de las reivindicaciones anteriores.
13. El sistema de acuerdo con la reivindicación 12, el dispositivo móvil (10) que comprende, además:
una pantalla (10D) acoplada al procesador (10C).
14. El sistema de acuerdo con la reivindicación 12 o 13, el dispositivo móvil (10) que comprende además un elemento sin contacto (10G) acoplado al procesador (10C), el elemento sin contacto (10G) se configura para proporcionar los datos de acceso a un dispositivo de acceso.
ES16789731T 2015-05-07 2016-04-06 Método y sistema de aprovisionamiento de datos de acceso a dispositivos móviles Active ES2803250T3 (es)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201562158503P 2015-05-07 2015-05-07
US14/707,788 US10070310B2 (en) 2014-05-08 2015-05-08 Method and system for provisioning access data to mobile device
US14/935,091 US10959093B2 (en) 2014-05-08 2015-11-06 Method and system for provisioning access data to mobile device
PCT/US2016/026241 WO2016178780A1 (en) 2015-05-07 2016-04-06 Method and system for provisioning access data to mobile device

Publications (1)

Publication Number Publication Date
ES2803250T3 true ES2803250T3 (es) 2021-01-25

Family

ID=61099079

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16789731T Active ES2803250T3 (es) 2015-05-07 2016-04-06 Método y sistema de aprovisionamiento de datos de acceso a dispositivos móviles

Country Status (4)

Country Link
EP (2) EP3292499B1 (es)
BR (1) BR112017023840A2 (es)
ES (1) ES2803250T3 (es)
RU (1) RU2017134975A (es)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10070310B2 (en) 2014-05-08 2018-09-04 Visa International Service Association Method and system for provisioning access data to mobile device
US11769144B2 (en) * 2017-06-02 2023-09-26 Apple Inc. Provisioning credentials for an electronic transaction on an electronic device
US11544710B2 (en) 2017-06-02 2023-01-03 Apple Inc. Provisioning credentials on multiple electronic devices
US11887080B2 (en) 2018-06-18 2024-01-30 First Data Corporation Instant digital issuance
US20190385164A1 (en) * 2018-06-18 2019-12-19 First Data Corporation Instant digital issuance
US11748744B2 (en) 2019-04-03 2023-09-05 First Data Corporation Source independent consistent tokenization
CN116542667A (zh) * 2020-01-07 2023-08-04 维萨国际服务协会 通用非接触式内核***和方法
CN114124432A (zh) * 2021-09-22 2022-03-01 的卢技术有限公司 一种基于html5技术的验证码趣味验证方法和***

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE527797T1 (de) * 2005-10-05 2011-10-15 Privasphere Ag Verfahren und einrichtungen zur benutzerauthentifikation
EP2674887B1 (en) * 2012-06-13 2020-01-01 F. Hoffmann-La Roche AG Controlling an analysis system of biological samples
GB2516412A (en) * 2013-05-03 2015-01-28 Vodafone Ip Licensing Ltd Access control

Also Published As

Publication number Publication date
BR112017023840A2 (pt) 2018-12-04
EP3292499A1 (en) 2018-03-14
EP3712792A1 (en) 2020-09-23
EP3712792B1 (en) 2022-06-29
EP3292499A4 (en) 2018-03-14
EP3292499B1 (en) 2020-06-03
RU2017134975A3 (es) 2019-10-18
RU2017134975A (ru) 2019-04-05

Similar Documents

Publication Publication Date Title
US11895491B2 (en) Method and system for provisioning access data to mobile device
US11710120B2 (en) Secure remote payment transaction processing including consumer authentication
US10959093B2 (en) Method and system for provisioning access data to mobile device
US11055694B2 (en) Secure remote payment transaction processing
ES2803250T3 (es) Método y sistema de aprovisionamiento de datos de acceso a dispositivos móviles
US11062306B2 (en) Secure remote payment transaction processing using a secure element
RU2710897C2 (ru) Способы безопасного генерирования криптограмм
JP2017537421A (ja) 支払いトークンのセキュリティを確保する方法
CN107636664B (zh) 用于向移动设备供应访问数据的方法、设备和装置