ES2632795T3 - Sistema de pago - Google Patents

Sistema de pago Download PDF

Info

Publication number
ES2632795T3
ES2632795T3 ES12718316.8T ES12718316T ES2632795T3 ES 2632795 T3 ES2632795 T3 ES 2632795T3 ES 12718316 T ES12718316 T ES 12718316T ES 2632795 T3 ES2632795 T3 ES 2632795T3
Authority
ES
Spain
Prior art keywords
application
payment
user device
icc
session key
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
ES12718316.8T
Other languages
English (en)
Inventor
Stuart Fiske
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 Europe Ltd
Original Assignee
Visa Europe Ltd
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=44071994&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=ES2632795(T3) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Visa Europe Ltd filed Critical Visa Europe Ltd
Application granted granted Critical
Publication of ES2632795T3 publication Critical patent/ES2632795T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/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/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/326—Payment applications installed on the mobile devices
    • G06Q20/3263—Payment applications installed on the mobile devices characterised by activation or deactivation of payment capabilities
    • 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/326—Payment applications installed on the mobile devices
    • G06Q20/3265—Payment applications installed on the mobile devices characterised by personalisation for use
    • 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/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/12—Card verification
    • G07F7/122—Online card verification
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/12—Card verification
    • G07F7/127—Card verification in which both online and offline card verification can take place
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Abstract

Un método para autorizar una transacción de pago EMV entre un dispositivo de usuario (502; 600) y un terminal de punto de venta (504), siendo dicha transacción de pago EMV una que se autoriza como parte de la transacción de pago por un banco emisor (500), en el que dicho banco emisor (500) mantiene datos indicativos de una Clave Maestra de ICC correspondiente a una aplicación de pago aprovisionada al dispositivo de usuario (502; 600), teniendo la aplicación de pago un primer estado operativo en el que dicha aplicación de pago tiene permitido llevar a cabo dicha transacción de pago EMV, y un segundo estado operativo, diferente de dicho primer estado operativo, comprendiendo el método: en respuesta a la recepción de una clave de sesión generada por dicho banco emisor (500) basándose en dicha Clave Maestra de ICC, aprovisionar dicha aplicación de pago con la clave de sesión, mediante lo que se configura dicha aplicación de pago en dicho primer estado operativo; y posteriormente en respuesta a la recepción de la solicitud de un criptograma de aplicación en la aplicación de pago desde el terminal de punto de venta (504), usar la aplicación de pago para realizar un proceso de autorización, comprendiendo el proceso de autorización las etapas de: generar dicho criptograma de aplicación basándose en la clave de sesión recibida; y transmitir el criptograma de aplicación generado al terminal de punto de venta para verificación del mismo por el banco emisor (500) y autorización de la transacción de pago EMV.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Sistema de pago Campo de la invencion
La presente invencion se refiere al campo de los sistemas de pago electronico y proporciona metodos de y sistemas para la autorizacion de una transaccion de pago EMV entre un dispositivo de usuario y un terminal de punto de venta.
Antecedentes de la invencion
Los sistemas de pago electronico facilitan la transferencia electronica de dinero desde una cuenta a otra a traves de sistemas basados en ordenador. Para permitir un amplio uso de los sistemas de pago electronico, se usan comunmente tarjetas de circuitos integrados (ICC) aprovisionadas con aplicaciones de pago; estas proporcionan una alternativa al efectivo cuando se realizan compras. Una ICC es una tarjeta portatil que contiene circuitos integrados embebidos. Las ICC se emiten tipicamente por instituciones financieras, conocidas comunmente como bancos de emision o emisores, a sus clientes. Se ejecuta en la ICC una aplicacion de pago y contiene informacion en relacion con la cuenta mantenida por el cliente con el banco emisor.
La Figura 1 ilustra los componentes de un sistema de pago electronico convencional. Una ICC 102, emitida por el banco emisor 100, permite al usuario interactuar con un terminal 104 en un punto de venta (PoS) para realizar una compra de un comerciante. El terminal 104 notifica posteriormente los detalles de la transaccion al banco del comerciante 106, comunmente conocido como el banco adquiriente. La transaccion se fija posteriormente entre el banco emisor 100 y el banco adquiriente 106, y se dispone la apropiada transferencia de fondos.
La ICC 102 puede interrelacionarse con el terminal del PoS 104 a traves de tecnologfas via contacto o sin contacto. Las ICC con contacto son alimentadas por el terminal de PoS, y estan de acuerdo con la serie de normas ISO/IEC 7810 e ISO/IEC 7816. Las tarjetas sin contacto pueden ser auto-alimentadas, o alimentadas inductivamente por el terminal del PoS y de acuerdo con las normas IsO/IEC 14443 o ISO/IEC 15693.
Antes de que se complete la transaccion, el terminal del PoS 104 debe asegurarse de que la ICC 102 presentada es tanto genuina, como autorizada para completar la transaccion. La autenticacion de las ICC y la autorizacion de las transacciones se gestionan de acuerdo con protocolos de transaccion, que aseguran la interoperabilidad de un intervalo de las ICC y los terminales de PoS.
Muchos sistemas de pago electronico usan protocolos de transaccion EMV (Europay®, Mastercard®, Visa®), tal como se define por ejemplo en las especificaciones EMV 4.2 o las especificaciones sin contacto EMV para Sistemas de Pago, que estan publicamente disponibles y publicadas por EMVCo LLC. Se hace referencia a estos protocolos en el presente documento simplemente como “EMV”.
Para que una ICC pruebe su autenticidad al terminal de PoS, la ICC esta equipada con un cierto numero de parametros de datos, tales como certificados unicos y claves secretas que permiten que tenga lugar la validacion sin poner en riesgo el secreto de los datos. Estos parametros de datos se conocen colectivamente como claves de pago.
Los circuitos integrados embebidos en las ICC aprovisionadas con aplicaciones de pago consisten tfpicamente en elementos de procesamiento y memoria resistentes a falsificacion, que permiten que se almacenen en la tarjeta parametros de datos secretos, tales como un cierto numero de claves de pago descritas anteriormente, en tanto que se mantiene un alto grado de confianza de que los datos no pueden obtenerse externamente.
La resistencia a falsificacion puede proporcionarse por el uso de un criptoprocesador seguro en la ICC, que almacena instrucciones de programas y datos en forma cifrada, descifrandolos solamente en el interior del procesador cuando se ejecutan. Adicionalmente, el criptoprocesador puede embeberse con el empaquetado que emplea medidas de seguridad ffsicas, por ejemplo haciendo que los datos sean borrados del almacenamiento si se sondean por una fuente externa. Este entorno de procesamiento resistente a falsificacion se denomina comunmente como un elemento seguro.
Recientemente, se han realizado intentos para incorporar la funcionalidad de tarjetas de pago en otros dispositivos. Notablemente, ha habido esfuerzos para desplegar aplicaciones de pago sobre dispositivos de usuario, tales como telefonos moviles, equipados con tecnologfa inalambrica de corto alcance, tal como una antena de Comunicaciones de Campo Cercano (NFC), para emular una tarjeta de pago sin contacto. El protocolo de comunicacion NFC esta normalizado en ISO/IEC 18092.
Sin embargo, como las tarjetas de pago estandar, estos dispositivos han requerido convencionalmente un elemento seguro para almacenar y procesar los datos secretos necesarios, y mantener el nivel de seguridad requerido para
5
10
15
20
25
30
35
40
45
50
55
60
65
asegurar el secreto de los datos. Los elementos seguros pueden embeberse como parte del hardware del dispositivo, sobre una tarjeta de almacenamiento extrafole tal como una tarjeta Secure Digital (SD), o, en el caso de un dispositivo de telefoma movil, incorporado en la tarjeta del modulo de identidad de abonado (SIM). Otros metodos conocidos de proporcionar un elemento seguro han incluido la implementacion de un elemento seguro externo accesible a traves de una interfaz periferica, tal como una interfaz del Bus Serie Universal (USB), o a traves del protocolo de comunicacion inalambrica Bluetooth®.
Sin embargo, hay varias razones por la que un elemento seguro puede no estar disponible para su uso por una aplicacion de pago. En primer lugar, el dispositivo sobre el que se implementa la aplicacion de pago puede no estar equipado con dicho elemento seguro (o una interfaz mediante la que pueda accederse a un elemento seguro externo). En segundo lugar, la aplicacion de pago puede no tener permitido acceder al elemento seguro proporcionado, quizas debido a que la aplicacion de pago se implemento en el dispositivo posteriormente al elemento seguro.
En el caso de un dispositivo de telefoma movil, es posible entregar aplicaciones o actualizaciones a una SIM “por el aire” a traves del uso de una herramienta de aplicacion SIM (STK). Sin embargo, la provision de aplicaciones en esta forma requiere la cooperacion del operador de la red movil y una SIM adaptada y un dispositivo de telefoma movil, lo que no siempre es posible.
Por ello, es un objetivo de la presente invencion proporcionar metodos mejorados para proporcionar funcionalidad de tarjeta de pago en un dispositivo de usuario, mientras se minimiza cualquier inconveniente para el usuario del dispositivo y sin que requiera modificacion de la infraestructura EMV, o del hardware de PoS existente.
Se proporcionara ahora un breve sumario de los metodos convencionales relevantes para procesamiento de pagos electronicos para ayudar a la comprension de las realizaciones de la invencion.
Autenticacion de datos.
EMV proporciona para la autenticacion de una ICC credenciales de tarjeta a traves de una autenticacion de datos fuera de lmea. La autenticacion de datos fuera de lmea se lleva a cabo durante el procesamiento de la transaccion de pago EMV, y se denomina fuera de lmea dado que no hay comunicacion entre el terminal de PoS y los bancos adquiriente o emisor. La finalidad de la autenticacion de datos fuera de lmea es verificar que la ICC esta presentando un conjunto valido de credenciales, y usa un esquema de certificacion de clave publica en capas. Un esquema de certificacion usa firmas digitales para garantizar los datos firmados, y en particular una clave publica contenida dentro de el.
La firma se realiza basandose en un mecanismo de cifrado asimetrico, en el que los datos que se cifran, o “firman”, a traves del uso de una clave privada que pueden descifrarse usando una clave publica correspondiente, sin requerir o implicar ningun conocimiento de la clave privada original. Por ello, puede asumirse con seguridad que los datos firmados que pueden descifrarse con una clave publica dada se han codificado por la clave privada correspondiente. EMV aprueba el uso del algoritmo RSA como un mecanismo de cifrado asimetrico adecuado, tal como se describe en R. L. Rivest, A. Shamir, y L. Adleman - “A method for obtaining digital signatures and public key cryptosystems”, Communications of the ACM, vol. 21, 1978, pags. 120-126, y propone el uso de Criptograffa de Curva Elfptica para futuras especificaciones.
Como se ha mencionado anteriormente, el esquema de certificacion utilizado en EMV es un esquema en capas, en el que se usa una clave obtenida a partir de un primer certificado para descifrar un segundo certificado, y asf sucesivamente. Todos los datos necesarios para la verificacion de datos fuera de lmea se obtienen por el terminal en respuesta al envm de comandos READ RECORD a la ICC u otros comandos tales como GET PROCESSING OPTIONS (GPO). Los comandos READ RECORD se envfan al inicio del procesamiento de la transaccion o durante el procesamiento de la transaccion y se usan para leer todos los parametros de datos relativos a la transaccion desde la ICC. Estos parametros que se requieren durante el procesamiento de la transaccion se listan en un Localizador de Archivo de Aplicacion (AFL). El AFL es un archivo de datos almacenado en la ICC que lista todos los registros de datos almacenados en la ICC que puedan requerirse durante el procesamiento de la transaccion.
En respuesta a la recepcion de comandos READ RECORD u otros comandos (tal como el GPO anteriormente mencionado, la ICC envfa todos los registros que se identifican en el AFL al terminal. Los registros relevantes para autenticacion de datos fuera de lmea incluyen un fndice de Clave Publica de la Autoridad de Certificacion (CA), un Certificado de Clave Publica del Emisor, Numero de Cuenta Primaria (PAN) y Datos de Aplicacion Estatica Firmados o un Certificado de Clave Publica ICC dependiendo del metodo de autenticacion de datos fuera de lmea que se este empleando.
EMV proporciona varios metodos de autenticacion de datos fuera de lmea. Cuya eleccion depende de las capacidades tanto de la ICC como del terminal de PoS. El metodo mas simple es la Autenticacion Estatica de Datos (SDA), que es para su uso con las ICC que no soportan la generacion de firma digital. La generacion de firma digital
5
10
15
20
25
30
35
40
45
50
55
60
65
es requerida por EMV para transacciones sin contacto; por lo tanto la SDA no esta permitida para su uso con transacciones EMV sin contacto.
EMV tambien proporciona metodos que soportan generacion de firma dinamica, entre los que la Autenticacion Dinamica de Datos (DDA) es el mas simple. Adicionalmente, EMV proporciona un metodo denominado DDA rapido (fDDA) que se optimiza para transacciones sin contacto, y un metodo denominado CDA, que combina DDA con la etapa posterior de Generacion de Criptograma de Aplicacion (descrito a continuacion), para permitir que se completen ambas operaciones en paralelo.
La Figura 2 ilustra un diagrama de flujo de DDA de ejemplo de acuerdo con los protocolos de transaccion EMV conocidos.
En la etapa 200, el terminal lee datos de aplicacion desde la ICC mediante el envfo de comandos READ RECORD, tal como se ha descrito anteriormente.
En la etapa 202, el terminal usa el fndice de Clave Publica de la CA para identificar que Clave Publica de la CA se ha usado para firmar el Certificado de Clave Publica del Emisor, y por ello que Clave Publica de la CA correspondiente se requiere para descifrar el Certificado de Clave Publica del Emisor. La CA es una entidad criptografica altamente segura que firma unas claves publicas del emisor para garantizar su autenticidad. La CA debe ser de confianza tanto para el banco emisor como para el banco adquiriente para proporcionar confianza en los datos firmados.
El terminal mantiene un almacen local de Claves Publicas de la Autoridad de Certificacion, y usa el fndice de Clave Publica de la Autoridad de Certificacion obtenido desde la ICC para identificar el apropiado a usar en relacion con la aplicacion de pago. Habiendo identificado la Clave Publica de CA apropiada, el terminal usa esto para descifrar el Certificado de Clave Publica del Emisor en la etapa 204. El descifrado se realiza de acuerdo con el mecanismo de recuperacion apropiado para el esquema de cifrado que se uso para firmar el Certificado de Clave Publica del Emisor. Dado que EMV aprueba el uso del algoritmo rSa, el descifrado se realiza de acuerdo con los mecanismos de recuperacion de RSA apropiados basandose en la clave publica obtenida.
Los datos contenidos en el certificado de clave publica del emisor incluyen una clave publica del emisor y datos asociados, tal como un Identificador de Emisor, Fecha de Expiracion del Certificado, Numero de Serie del Certificado, Longitud de la Clave Publica del Emisor, Longitud del Exponente de la Clave Publica del Emisor, y Resultado Criptografico. Todos estos campos de datos se firman por la clave privada de CA, y por ello la validez de la informacion es garantizada por la CA.
En la etapa 206, el terminal realiza un cierto numero de comprobaciones para determinar si el certificado de clave publica del emisor se descifro apropiadamente, y si la informacion descifrada es valida. En primer lugar el terminal, compara el contenido de la cabecera, cola y parametros de datos de formato descifrados contra valores esperados conocidos. Se aplica entonces un algoritmo criptografico la concatenacion de los campos de datos en el Certificado de Clave Publica del Emisor (excluyendo el parametro Resultado Criptografico), la Clave Publica del Emisor restante y el Exponente de Clave Publica del Emisor. El resultado del algoritmo criptografico se compara entonces con el valor del Resultado Criptografico proporcionado en el Certificado de Clave Publica del Emisor.
Un algoritmo criptografico, es una operacion matematica de una direccion que se usa para generar un resultado de tamano fijo basandose en una entrada de datos de tamano grande o variable. El resultado depende de toda la entrada de datos, y es computacionalmente diffcil determinar los datos de las entradas que producinan un resultado dado. El EMV recomienda el uso del Algoritmo Criptografico Seguro (Secure Hash Algorithm (SHA-1)) como es se normaliza en ISO/IEC 10118-3.
El terminal comprueba entonces el Identificador del Emisor recuperado desde el Certificado de Clave Publica del Emisor contra las primeras 3-8 cifras del Numero de Cuenta Primaria lefda desde la ICC. El terminal comprueba tambien la fecha de expiracion del Certificado de Clave Publica del Emisor (expresado en terminos de un mes de expiracion y un ano de expiracion) contra la fecha actual para asegurarse de que no ha pasado el ultimo dfa del mes de expiracion, y que el Certificado de Clave Publica del Emisor es aun valido.
Si cualquiera de estas comprobaciones falla, entonces el proceso de autenticacion de datos fuera de lmea ha fallado. Sin embargo, si se pasan todas estas comprobaciones, entonces el terminal ha obtenido y verificado la Clave Publica del Emisor, que se usa para descifrar el certificado de Clave Publica de la ICC en la etapa 208.
Los datos contenidos en el Certificado de Clave Publica de la ICC incluyen la Clave Publica de la ICC y credenciales de la aplicacion de pago asociada, incluyendo el PAN, Fecha de Expiracion del Certificado, Numero de Serie del Certificado, Longitud de Clave Publica de la ICC, Longitud del Exponente de Clave Publica del ICC y Resultado Criptografico. Todos estos campos de datos se firman por la Clave Privada del Emisor, y por ello la validez de la informacion es garantizada por el emisor, cuya identidad ha sido garantizada a su vez por la Ca.
5
10
15
20
25
30
35
40
45
50
55
60
65
En la etapa 210, el terminal realiza un cierto numero de comprobaciones para determinar si el Certificado de Clave Publica de la ICC se descifro apropiadamente, y si la informacion descifrada es valida. En primer lugar el terminal comprueba el contenido de la cabecera, cola y parametros de datos de formato descifrados contra valores esperados conocidos.
El algoritmo criptografico se aplica entonces a la concatenacion de los campos de datos en el Certificado de Clave Publica de la iCc (excluyendo el Resultado Criptografico), el Resto de Clave Publica de la ICC, el Exponente de Clave Publica de la ICC y un conjunto de datos estaticos a ser autenticados, que se compone de una seleccion de otros archivos de datos almacenados en la ICC y recuperados al inicio del procesamiento de la transaccion, o durante el procesamiento de la transaccion, usando el comando READ RECORD. El resultado del algoritmo criptografico se compara entonces con el valor del Resultado Criptografico proporcionado en el Certificado de Clave Publica de la ICC.
Los registros de datos que componen los datos estaticos a ser autenticados se indican en el AFL mediante un valor de etiqueta espedfico. Solo se procesan aquellos registros que estan etiquetados como usados en la autenticacion de datos fuera de lmea. Los elementos de datos adicionales pueden identificarse como una Lista de Etiquetas de Autenticacion de Datos Estatica opcional contenida en la ICC. La inclusion de estos datos estaticos en la entrada criptografica permite que estos parametros de datos extra sean autenticados por un resultado criptografico verificado.
El terminal comprueba entonces el PAN desde el Certificado de Clave Publica de la ICC contra el PAN tal como se ve desde la tarjeta ICC en respuesta al comando READ RECORD. Tambien, se comprueba la Fecha de Expiracion del Certificado de la ICC (expresado en terminos de un mes de expiracion y un ano de expiracion) contra la fecha actual para asegurar que no ha pasado el ultimo dfa del mes de expiracion, y que el Certificado de Clave Publica de la ICC es aun valido.
Si cualquiera de estas comprobaciones falla, entonces ha fallado el proceso de autenticacion de datos fuera de lmea. Sin embargo, si se pasan todas estas comprobaciones, entonces el terminal ha obtenido y verificado la Clave Publica de la ICC, que se usa entonces para confirmar que la ICC esta equipada con la Clave Privada de ICC.
Esto se consigue dando instrucciones a la ICC para generar una firma digital mediante la firma de un conjunto de datos especificado usando la Clave Privada de ICC. El resultado se denomina Datos de Aplicacion Dinamicos Firmados. Los datos que deben firmarse por la ICC se definen en una Lista de Objetos de Datos Dinamica (DDOL). La ICC puede contener una DDOL, pero si no, se proporciona una DDOL por el terminal. Algunos datos definidos en la DDOL deben proporcionarse por el terminal, y otros parametros pueden leerse desde la ICC. Cualquier DDOL debe incluir el parametro del Numero Impredecible, que se genera por el terminal. La inclusion del numero impredecible asegura que los datos a ser firmados no pueden ser predichos, y por lo tanto que los datos de Aplicacion de Firma resultantes no pueden ser burlados mediante un precalculo del resultado.
En la etapa 212, el terminal solicita a la ICC aplicar su firma digital mediante el envm de un comando INTERNAL AUTHENTICATE. El comando INTERNAL AUTHENTICATE incluye un campo de datos que contiene los datos necesarios originados en el terminal que han de ser firmados por la ICC.
Los datos de Aplicacion Dinamica Firmados se transmiten al terminal en la etapa 214. En la etapa 216, el terminal usa la Clave Publica de ICC obtenida previamente para descifrar los Datos de Aplicacion Dinamica Firmados. Los datos contenidos en los Datos de Aplicacion Dinamica Firmados incluyen los Datos Dinamicos y un Resultado Criptografico.
De nuevo, en la etapa 218, el terminal realiza un numero comprobaciones para determinar si se descifraron apropiadamente los Datos de Aplicacion Dinamica Firmados, y si es valida la informacion descifrada. En primer lugar el terminal comprueba al contenido de la cabecera, cola y parametros de datos de formato descifrados contra valores esperados conocidos.
Se aplica entonces un algoritmo criptografico a la concatenacion de los campos de datos en los Datos de Aplicacion Dinamica Firmados (excluyendo el Resultado Criptografico) y los datos dinamicos a ser autenticados. El resultado del algoritmo criptografico se compara entonces con el valor del Resultado Criptografico proporcionado en los Datos de Aplicacion Dinamica Firmados.
Si cualquiera de estas comprobaciones falla, entonces ha fallado el proceso de autenticacion de datos fuera de lmea. Sin embargo, si se pasan todas estas comprobaciones, entonces el terminal ha verificado que la ICC tiene acceso a la Clave Privada de ICC, y el DDA tiene exito.
Sf, alternativamente, se usa SDA, las etapas de verificacion son las mismas tal como se muestra en la Figura 2 hasta la etapa 204, despues de lo que se usa en su lugar la Clave Publica del Emisor para descifrar los Datos de Aplicacion Estatica Firmados. Los datos contenidos en los Datos de Aplicacion Estatica Firmados incluyen un Codigo de Autenticacion de Datos y un Resultado Criptografico. Todos estos datos se firman por la Clave Privada
5
10
15
20
25
30
35
40
45
50
55
60
65
del Emisor, y por ello la validez de la informacion es garantizada por el Emisor, cuya identidad se ha garantizado a su vez por la Ca.
El terminal realiza de nuevo un cierto numero de comprobaciones para determinar si los Datos de Aplicacion Estatica Firmados se descifraron apropiadamente, y si la informacion descifrada es valida. En primer lugar el terminal comprueba el contenido de la cabecera, cola y parametros de datos de formato descifrados contra valores esperados conocidos.
Se aplica entonces un algoritmo criptografico a la concatenacion de los campos de datos en los Datos de Aplicacion Estatica Firmados, y al conjunto de datos estaticos a ser autenticado identificado por la AFL tal como se ha descrito anteriormente. El resultado del algoritmo criptografico se compara con el campo de Resultado Criptografico obtenido desde los Datos de Aplicacion Estatica Firmados. La inclusion de los datos estaticos en la entrada criptografica permite que estos parametros de datos sean autenticados por un resultado criptografico verificado.
Si se usa CDA en lugar de DDA, entonces las etapas de verificacion son las mismas que en la Figura 3 hasta la etapa 210, despues de lo que el terminal solicita un Criptograma de Aplicacion mediante el envm de un comando GENERATE AC a la ICC (tal como se define a continuacion), pero tambien solicita que sea firmado con una firma CDA. Esto permite que la firma digital sea verificada al mismo tiempo que el procesamiento del Criptograma de Aplicacion.
De acuerdo con algunas implementaciones del terminal de PoS, solo se proporciona soporte para autorizacion en lmea, y la etapa de autenticacion de datos fuera de lmea puede omitirse opcionalmente dado que la transicion siempre se enviara en lmea para autorizacion y la responsabilidad de la autenticacion puede pasarse tambien al banco emisor.
Generacion del criptograma de aplicacion
EMV proporciona autorizacion de transaccion a traves de la generacion de criptogramas de aplicacion. Dependiendo de que opciones se usen desde varias especificaciones de EMV, hay varios mecanismos disponibles para la generacion del criptograma se aplicacion. La generacion de criptogramas de aplicacion se describira en el presente documento segun las especificaciones EMV 4.2, sin embargo estara claro para un experto en la materia que son tambien adecuados mecanismos alternativos. A todo lo largo del procesamiento de la transaccion, el exito o fallo de ciertas comprobaciones y acciones, tales como los descritos anteriormente con relacion a la autenticacion de datos fuera de lmea, pueden registrarse en una cadena de Resultados de Verificacion del Terminal (TVR).
Los TRV se revisan durante el Analisis de Accion del Terminal, y basandose en su contenido, el terminal toma la decision preliminar acerca de si la transaccion debena aprobarse fuera de lmea, autorizarse en lmea, o rechazarse. La aprobacion fuera de lmea comprende la decision del terminal de que la transaccion puede tener lugar sin pedir permiso expreso desde el Banco Emisor. La autorizacion en lmea comprende el envrn de detalles de la transaccion al Banco Emisor para autorizacion antes de aprobar la transaccion. En algunas circunstancias, el terminal rechazara la transaccion fuera de lmea, antes de pedir la autorizacion desde el Banco Emisor.
La decision del apropiado curso de la accion a tomar por el terminal se realiza basandose en Codigos de Accion del Terminal (TAC) y Codigos de Accion del Emisor (IAC). Los TAC se programan dentro del terminal por el banco adquiriente, y definen las circunstancias bajo las que una traslacion debena aprobarse fuera de lmea, autorizarse en lmea, o rechazarse. Los IAC se implementan dentro de la ICC por el banco emisor, y definen tambien un conjunto de circunstancias bajo las que una transaccion debena aprobarse fuera de lmea, autorizarse en lmea o rechazarse. El terminal usa tanto los TAC como los IAC para tomar una decision preliminar sobre como procesar la transaccion.
La Figura 3 ilustra un diagrama de flujo del comando de Generacion de Criptograma de Aplicacion de ejemplo de acuerdo con los protocolos de transaccion de EMV.
El flujo comienza en la etapa 300 comparando el contenido del TVR con los TAC almacenados en el terminal y los IAC recuperados desde la ICC. Basandose en la comparacion, el terminal toma una decision preliminar acerca de si la transaccion debena aprobarse fuera de lmea, autorizarse en lmea, o rechazarse en la etapa 302.
Dependiendo del resultado de la decision tomada en la etapa 302, el terminal solicita un tipo espedfico de Criptograma de Aplicacion a ser generado mediante el envrn de un comando GENERATE AC a la ICC. Si el terminal decide rechazar la transaccion fuera de lmea, el comando GENERATE AC solicita un Criptograma de Autenticacion de la Aplicacion (AAC) en la etapa 304. Si el terminal decide intentar autorizar la transaccion en lmea, el comando GENERATE AC solicita un Criptograma de Solicitud de Autorizacion (ARQC) en la etapa 306. Si el terminal decide aprobar la transaccion fuera de lmea, el comando GENERATE AC solicita un Certificado de Transaccion (TC) en la etapa 308.
En respuesta al comando GENERATE AC enviado por el terminal, la ICC puede realizar su propia gestion de riesgos en la forma de Analisis de Accion de la Tarjeta. El analisis de accion de la tarjeta se realiza basandose en los
5
10
15
20
25
30
35
40
45
50
55
60
65
parametros determinados por el emisor y almacenados en la ICC. El resultado del Analisis de Accion de la Tarjeta puede elegir solamente un metodo de autorizacion, el mismo que el determinado por el terminal o mas estricto.
Si el terminal decide rechazar la transaccion fuera de lmea solicitando un AAC segun la etapa 304, la ICC debe responder con AAC en la etapa 310. Cualquier otra respuesta desde la ICC provocara que el procesamiento de la transaccion falle.
Si el terminal decide intentar enviar la transaccion en lmea para autorizacion por el banco emisor solicitando un ARQC segun la etapa 306, como un resultado del Analisis de Accion de la Tarjeta en la etapa 312, la ICC puede decidir responder con un ARQC en la etapa 314 segun solicitado, o elegir rechazar la transaccion fuera de lmea respondiendo con un AAC en la etapa 3l0. Una respuesta desde la ICC que comprenda un TC provocara que el procesamiento de la transaccion falle.
Si el terminal decide permitir la transaccion fuera de lmea solicitando un TC segun la etapa 308, como un resultado del Analisis de Accion de la Tarjeta en la etapa 312 la ICC puede decidir responder con un TC en la etapa 316 segun solicitado, elegir enviar la transaccion en lmea para autorizacion por el banco emisor respondiendo con un ARQC en la etapa 314, o elegir rechazar la transaccion respondiendo con un AAC en la etapa 310.
Si la ICC responde con un ARQC, el terminal intenta enviar esta al banco emisor para autorizacion en la etapa 318. Si el resultado del procedimiento de autorizacion en lmea es rechazar la transaccion, el terminal solicita un AAC en la etapa 320 mediante el envm de un segundo comando GENERATE AC, y el AAC es devuelto por la ICC en la etapa 310. Si el resultado del procedimiento de autorizacion en lmea es autorizar la transaccion, el terminal solicita un TC en la etapa 322 mediante el envrn de un segundo comando GENERATE AC, y el AAC es devuelto por la ICC en la etapa 316.
Alternativamente, si el procedimiento de autorizacion en lmea no puede completarse, el terminal vuelve al modo por omision tal como se define en el TAC/IAC, mediante el envfo de un segundo comando GENERATE AC que o bien solicita un AAC segun la etapa 320, que se devuelve por la ICC en la etapa 310, o bien un TC en la etapa 322, que se devuelve por la ICC en la etapa 316.
Una vez la ICC ha respondido con o bien un AAC o bien un TC segun las etapas 310 o 316 respectivamente, se completa el flujo del comando de Generacion del Criptograma de Aplicacion.
Para responder a un comando GENERATE AC remitido por el terminal, la ICC debe producir un Criptograma de Aplicacion. Un Criptograma de Aplicacion se produce basandose en datos enviados a la ICC en el campo de datos del comando GENERATE AC. Los datos a ser usados se especifican en una Lista de Objetos de Datos de Gestion de Riesgos de Tarjeta (CDOL), que se almacena en la ICC. La ICC almacena dos CDOL, uno para su uso con el primer comando GENERATE AC enviado en una transaccion dada, y el otro para ser usado si se envfa un segundo comando GENERATE AC.
El cifrado de los datos de aplicacion y la generacion del criptograma de aplicacion se preforma basandose en una Clave de Sesion de ICC de 16 bytes. Una Clave de Sesion de ICC es una clave unica generada por la ICC que es valida solo para uso con una transaccion. Cada Clave de Sesion de ICC se deduce de una Clave Maestra de ICC unica de 16 bytes, implementada con seguridad sobre la ICC por el banco emisor, y un Contador de Transaccion de Aplicacion (aTc) de 2 bytes. El ATC se emplea como dato de diversificacion, lo que asegura la variacion entre las Claves de Sesion de ICC usadas en cada transaccion.
La Figura 4 ilustra el proceso de deducir una Clave de Sesion de ICC a partir de una Clave Maestra de ICC 400 unica de acuerdo con los protocolos EMV.
Se usa el ATC 402 para crear datos de diversificacion izquierda 404 anadiendole un valor de datos hexadecimal “F0” y rellenando los restantes 5 bytes con ceros. De modo similar, los datos de diversificacion derecha 406 se generan anadiendo al valor ATC el valor de datos hexadecimal “0F” y rellenando los restantes 5 bytes con ceros.
La Clave de Sesion se genera en dos mitades mediante el uso del algoritmo Estandar de Descripcion de Datos Triple (3DES). El 3DES se especifica en ISO/IEC 18033-3, y se usa para cifrar una entrada de 8 bytes en una salida de texto cifrado de 8 bytes usando una clave secreta de 16 bytes.
Los 8 bytes mas a la izquierda de la clave de sesion 408 se generan mediante la aplicacion del algoritmo 3DES 410 a los datos de diversificacion izquierda 404, usando la Clave Maestra de ICC 400 como clave secreta. De modo similar, los 8 bytes mas a la derecha de la clave de sesion 412 se generan mediante la aplicacion del algoritmo 3DES 414 a los datos de diversificacion derecha 406, usando la Clave Maestra de ICC 400 como la clave secreta.
Los 8 bytes mas a la izquierda de la clave de sesion 408 y los 8 bytes mas a la derecha de la clave de sesion 412 se concatenan entonces para formar la Clave de Sesion de ICC 416.
5
10
15
20
25
30
35
40
45
50
55
60
65
La Clave de Sesion de ICC puede usarse entonces para generar un criptograma de aplicacion. Como se usa la clave de sesion para generar el criptograma aplicacion es espedfico del sistema de pago que este siendo implementado.
Si se selecciona CDA como el metodo para autenticacion de datos fuera de lmea (como se ha descrito previamente), el terminal solicitara criptogramas de aplicacion a ser firmados por la firma digital de la ICC, permitiendo que la autenticacion de datos fuera de lmea se realice simultaneamente con las etapas descritas anteriormente.
Los comandos usados en la generacion del criptograma de aplicacion pueden diferir de los descritos anteriormente dependiendo de cual de las opciones de entre las diversas especificaciones EMV se usa. Por ejemplo, en lugar de usar GENERATE AC, el procesamiento de pago requerido puede incorporarse en un comando alternativo, tal como el GPO.
La solicitud de patente de Estados Unidos US 2005/0156026 A1 describe la realizacion de transacciones de pago EMV de modo inalambrico usando un terminal movil.
La solicitud de patente de Estados Unidos US 2011/0038481 A1 describe un sistema de almacenamiento de claves jerarquico para circuitos electronicos, y explica dos enfoques para mejorar la proteccion de las claves contra intentos de piratena, concretamente (1) usando un mecanismo de deduccion de claves en el que solo se usan las claves deducidas de una clave maestra y (2) usando claves temporales transmitidas por un elemento distante.
Sumario de la invencion
De acuerdo con realizaciones de la presente invencion, se proporciona un metodo, aparato y software de ordenador para autorizar una transaccion EMV de acuerdo con las reivindicaciones adjuntas.
Mas espedficamente, en un primer aspecto de la presente invencion, se proporciona un metodo para autorizar una transaccion de pago EMV entre un dispositivo de usuario y un terminal de punto de venta, siendo dicha transaccion de pago EMV una que se autoriza como parte de la transaccion de pago por un banco emisor, en el que dicho banco emisor mantiene datos indicativos de una Clave Maestra de iCc correspondiente a una aplicacion de pago aprovisionada al dispositivo de usuario, teniendo la aplicacion de pago un primer estado operativo en el que dicha aplicacion de pago tiene permitido llevar a cabo dicha transaccion de pago EMV, y un segundo estado operativo, diferente de dicho primer estado operativo, comprendiendo el metodo:
en respuesta a la recepcion de una clave de sesion generada por dicho banco emisor basandose en dicha Clave Maestra de ICC, aprovisionar a dicha aplicacion de pago con la clave de sesion, mediante lo que se configura dicha aplicacion de pago en dicho primer estado operativo; y posteriormente en respuesta a la recepcion de la solicitud de un criptograma de aplicacion en la aplicacion de pago desde el terminal de punto de venta, usar la aplicacion de pago para realizar un proceso de autorizacion, comprendiendo el proceso de autorizacion las etapas de:
generar dicho criptograma de aplicacion basandose en la clave de sesion recibida; y
transmitir el criptograma de aplicacion generado al terminal de punto de venta para verificacion del mismo por el banco emisor y autorizacion de la transaccion de pago EMV.
Una aplicacion de pago puede referirse a software configurado de modo que sea capaz de controlar la comunicacion con un terminal de punto de venta de acuerdo con los protocolos de transaccion EMV. Un dispositivo de usuario puede relacionarse con un dispositivo portatil electronico que comprende hardware de ordenador. Un ejemplo de un dispositivo de usuario es un dispositivo de telefoma movil, tal como un telefono inteligente.
La clave maestra de ICC es una clave unica asociada con la aplicacion de pago, a partir de la que pueden deducirse las claves de sesion. Las claves de sesion son claves requeridas durante el procesamiento de la transaccion EMV, y cada clave de sesion es valida para su uso solamente con una unica transaccion. Un criptograma de aplicacion es un conjunto de datos cifrados usando una clave de sesion por una aplicacion de pago. Un criptograma de aplicacion es requerido por el terminal de punto de venta durante el procesamiento de una transaccion EMV.
Al mantener la Clave Maestra de ICC en el banco emisor, al contrario que en la tecnica anterior en la que la Clave Maestra de ICC se mantiene por la aplicacion de pago, y mediante la autorizacion de transacciones basandose en una clave de sesion deducida de la misma, las realizaciones de la presente invencion son capaces de reducir el riesgo asociado con un ataque exitoso sobre la aplicacion de pago. Un ataque exitoso contra la aplicacion de pago que almacena solo un numero limitado de claves de sesion conducina a credenciales de pago validas solo para una unica transaccion, o un numero limitado de transacciones, y por ello la efectividad de dicho ataque se reduce significativamente. Al reducir el riesgo asociado con un ataque exitoso sobre la aplicacion de pago, las realizaciones de la presente invencion facilitan la provision de la aplicacion de pago de tal manera que no requiera el uso de caractensticas de seguridad proporcionadas por un elemento seguro.
5
10
15
20
25
30
35
40
45
50
55
60
65
Preferentemente, el dispositivo de usuario comprende una primera parte de procesamiento y una segunda parte de procesamiento, comprendiendo la primera parte de procesamiento un primer entorno de aplicacion dentro de un elemento seguro y una segunda parte de procesamiento que comprende un segundo entorno de aplicacion externo al elemento seguro, y en el que la segunda parte de procesamiento comprende dicha aplicacion de pago.
Una parte de procesamiento puede referirse a la combinacion de componentes de computacion convencionales, tales como una unidad de procesamiento central, una memoria de acceso aleatorio y una memoria solo de lectura. Un entorno de aplicacion puede referirse a una vista logica de una parte de procesamiento en la que puede ejecutarse una aplicacion, compuesta por una combinacion de instrucciones de software. Un elemento seguro puede proporcionar una parte de procesamiento y entorno de aplicacion con caractensticas de seguridad de hardware adicionales, tales como resistencia a falsificacion, que puede proporcionarse por medio del uso de un criptoprocesador seguro. Un ejemplo de un elemento seguro es el proporcionado por una tarjeta del Modulo de Identidad de Abonado (SIM) con respecto a un dispositivo de telefoma movil.
Preferentemente, y en respuesta a un criterio predeterminado que es satisfecho, se aprovisiona una clave de sesion adicional a dicho dispositivo de usuario.
El criterio predeterminado puede comprender el numero de claves de sesion sin usar en el dispositivo de usuario que cae por debajo de un cierto valor, enviando el dispositivo de usuario una solicitud de mas claves de sesion o un penodo de tiempo predeterminado que transcurre desde la provision de la ultima clave de sesion. La provision de claves de sesion adicionales puede tener lugar a traves de una red de comunicaciones de conmutacion de paquetes tales como la Internet, una red de comunicaciones de conmutacion de circuitos, tales como una red de telefoma movil, o una combinacion de ambas.
El dispositivo de usuario puede comunicar con el terminal de punto de venta usando tecnologfas inalambricas de corto alcance, por ejemplo un protocolo de comunicacion de radiofrecuencia tal como la norma de Comunicaciones de Campo Cercano.
De acuerdo con aspectos adicionales de la presente invencion se proporciona un terminal de usuario o dispositivo adaptado para procesar una transaccion de pago EMV en conjunto con un terminal de punto de venta de acuerdo con el metodo anteriormente mencionado. Ademas se proporciona un programa de ordenador, o un conjunto de programas de ordenador que, cuando se ejecutan, hacen que un dispositivo de usuario realice el metodo anteriormente mencionado.
Aunque las realizaciones de la invencion son adecuadas para entornos de procesamiento que incluyen un elemento seguro, se apreciara que las realizaciones de la invencion pueden implementarse en un entorno que no tenga un elemento seguro, dado que la gestion y envfo de claves de acuerdo con las realizaciones descritas es independiente de la existencia de un elemento seguro.
Seran evidentes caractensticas y ventajas adicionales de la invencion a partir de la descripcion que sigue de realizaciones preferidas de la invencion, dadas solamente a modo de ejemplo, que se realiza con referencia a los dibujos adjuntos.
Breve descripcion de los dibujos
La Figura 1 muestra los componentes de un sistema de pago electronico convencional;
la Figura 2 muestra un diagrama de flujo de DDA de ejemplo de acuerdo con los protocolos de transaccion EMV conocidos;
la Figura 3 muestra un diagrama de flujo del comando de Generacion de Criptograma de Aplicacion de acuerdo con los protocolos de transaccion EMV conocidos;
la Figura 4 muestra el proceso de deducir una Clave de Sesion de ICC a partir de la Clave Maestra de ICC de acuerdo con los protocolos de transaccion EMV conocidos;
la Figura 5 muestra componentes de un sistema de pago electronico de acuerdo con una realizacion de la presente invencion; y
la Figura 6 muestra un diagrama de bloques funcional de un dispositivo de usuario configurado de acuerdo con una realizacion de la presente invencion; y
la Figura 7 muestra un diagrama de flujo del mensaje que ilustra un proceso de autorizacion en lmea de acuerdo con una realizacion de la presente invencion.
Descripcion detallada de la invencion
La Figura 5 ilustra los componentes de un sistema de pago electronico de acuerdo con una realizacion de la presente invencion.
El dispositivo de usuario 502 se aprovisiona con una aplicacion de pago asociada con un banco emisor 500. El usuario del dispositivo 502 puede interactuar con un terminal 504 de un PoS a traves del dispositivo de usuario 502
5
10
15
20
25
30
35
40
45
50
55
60
65
para realizar una compra desde un comerciante. El terminal de PoS 504 puede comunicar con el banco adquiriente 506, y la transaccion se fija posteriormente entre el banco emisor 500 y el banco adquiriente 506, una vez que se ha dispuesto la transferencia de fondos apropiada.
De acuerdo con realizaciones de la invencion, el dispositivo de usuario 502 puede comunicar con el terminal de PoS a traves de una interfaz de comunicacion sin contacto 508. Esta puede ser a traves de un protocolo de comunicacion inalambrica de corto alcance, tal como NFC.
El dispositivo de usuario 502 es adicionalmente capaz de comunicar con el banco emisor 500 a traves de la interfaz de comunicaciones 510. El medio de comunicacion usado para comunicaciones entre el banco emisor 500 y el dispositivo de usuario 502 depende de las capacidades del dispositivo de usuario. El dispositivo de usuario 502 puede comunicar con el banco emisor 500 a traves de Internet. Alternativamente, si el dispositivo de usuario 502 es un dispositivo de telefoma movil, el dispositivo de usuario puede comunicar con el banco emisor 500 a traves de la red de telefoma movil.
La Figura 6 ilustra componentes de ejemplo de un dispositivo de usuario de acuerdo con realizaciones de la presente invencion en las que el dispositivo de usuario comprende un dispositivo de telefoma movil.
El dispositivo de usuario 600 comprende hardware de computo convencional que incluye una parte de procesamiento 602, memoria solo de lectura 604, memoria de acceso aleatorio 606, y otro hardware estandar tal como un controlador de entrada/salida, controlador de pantalla, etc. (no mostrados). El dispositivo de usuario 600 comprende tambien hardware de telefoma movil espedfico que incluye la antena de telefoma 608, y la tarjeta SIM 610. La tarjeta SIM 610 constituye un entorno de procesamiento seguro en el dispositivo de usuario, tambien conocido como elemento seguro 612, e incorpora medidas de seguridad adicionales tales como resistencia a falsificacion. Los componentes descritos anteriormente son accesibles para la parte de procesamiento 602 a traves de una estructura de comunicacion interna, tal como un bus del sistema 614. La operacion e interaccion de estos componentes es bien conocida en la tecnica y por lo tanto no se cubrira con detalle adicional en el presente documento.
El dispositivo de usuario 600 incluye tambien hardware de comunicaciones inalambricas de corto alcance, incluyendo una antena inalambrica de corto alcance 616, que puede usarse para realizar una comunicacion sin contacto con el terminal de PoS, y puede ser una antena NFC.
Tfpicamente, en donde se han proporcionado antenas inalambricas de corto alcance hasta el momento en dispositivos de telefoma moviles conocidos, han sido controladas por la SIM 610, a traves de un canal de comunicacion dedicado 618, separado del bus del sistema 614. El canal de comunicacion dedicado 618, puede usar, por ejemplo, un Protocolo por Cable Simple para comunicacion.
De acuerdo con realizaciones de la presente invencion, la antena inalambrica de corto alcance es accesible desde un area fuera del elemento seguro 612, de aqrn en adelante conocida como el entorno de aplicacion estandar 620, por ejemplo a traves del bus del sistema 614.
El entorno de aplicacion estandar 620 comprende tambien una aplicacion de pago implementada en el dispositivo 600. La aplicacion de pago puede instalarse en el entorno de aplicacion estandar en el momento de la fabricacion del dispositivo, o bajo la supervision del banco emisor. Alternativamente la aplicacion de pago puede instalarse por el usuario final del dispositivo. Un usuario final puede instalar la aplicacion mediante la descarga de los archivos de instalacion en el dispositivo de usuario, por ejemplo a traves de Internet. Alternativamente un usuario puede instalar la aplicacion mediante la descarga de los archivos de instalacion primero en otro dispositivo, tal como en un ordenador personal, y cargando a continuacion los archivos en el dispositivo de usuario, por ejemplo a traves de una conexion USB. Tambien alternativamente, un usuario puede obtener los archivos de instalacion accediendo a un portal de aplicacion en el dispositivo de usuario, tal como el Apple® AppStore™, o el Android Market™, que facilitan una descarga e instalacion integradas de los archivos de aplicacion. La descarga de los archivos de instalacion facilitada por un portal de aplicacion puede proporcionarse a traves de una conexion de Internet disponible, o una provision a traves del aire (OTAP).
De acuerdo con realizaciones de la invencion, las claves de pago, que son necesarias para el uso de la aplicacion de pago, se proporcionan posteriormente a la instalacion de la aplicacion de pago, bajo el control del banco emisor. El equipamiento del dispositivo de usuario con las claves de pago en esta forma tiene el efecto de activar la aplicacion de pago, asociandola de ese modo con una cuenta en el banco emisor, y permitiendole llevar a cabo transacciones de pago EMV. Las claves de pago pueden almacenarse en un estado cifrado en una parte de memoria asociada con el entorno de aplicacion estandar tal como en la memoria solo de lectura 604 o en una memoria persistente alternativa usando, por ejemplo, la norma de cifrado avanzado (AES). La clave usada para cifrar y descifrar esas claves de pago puede almacenarse en la memoria persistente en el dispositivo 600, o puede deducirse de una entrada recibida desde el usuario, tal como una palabra clave introducida en el dispositivo, una plantilla introducida en la pantalla o mediante la entrada de datos biometricos tales como un escaner de huellas o un reconocimiento de caractensticas faciales.
5
10
15
20
25
30
35
40
45
50
55
60
65
De acuerdo con algunas realizaciones de la invencion, el entorno de aplicacion estandar 620 puede comprender adicionalmente un entorno de ejecucion de confianza (TEE), por ejemplo como se ha descrito por Global Platform Inc en “TEE System Architecture”, disponible en
www.globalplatform.org, y otras aplicaciones relacionadas. Un TEE permite la ejecucion segura de software o aplicaciones autorizadas mediante el almacenamiento y procesamiento de datos en una forma logicamente aislada, provocando que varias aplicaciones esten logicamente segregadas entre su Un TEE proporciona proteccion frente a ataques contra datos protegidos por software malicioso, pero no proporciona la proteccion ffsica de un elemento seguro, tal como componentes de procesamiento y memoria a prueba de falsificacion. En donde esta disponible un TEE en el dispositivo 600, al menos una parte de la aplicacion de pago puede almacenarse y/o ejecutarse en el TEE. Adicional o alternativamente, las claves de pago pueden almacenarse en el TEE. En donde las claves de pago se almacenan en un estado cifrado fuera del TEE, la clave que se usa para cifrar y descifrar las claves de pago puede almacenarse en el TEE.
Ademas, la aplicacion de pago se configura de modo que la Clave Maestra de ICC no se mantiene localmente en el dispositivo de usuario, y en su lugar se mantiene por una entidad remota tal como el banco emisor. El dispositivo de usuario se aprovisiona con una Clave de Sesion de ICC, generada por el banco emisor basandose en la Clave Maestra de ICC. La Clave de Sesion de ICC puede generarse por el banco emisor de acuerdo con, por ejemplo, el metodo descrito anteriormente en relacion con la Figura 4.
Se delega por lo tanto en el dispositivo de usuario tanto la responsabilidad como la capacidad para generar sus propias Claves de Sesion de iCc. Por ello un ataque con exito contra los datos cifrados almacenados en el dispositivo de usuario dara como resultado que un atacante obtiene una Clave de Sesion de ICC que es valida solo para una unica transaccion, no para un gran numero de transacciones como sena el caso si se obtuviera la Clave Maestra de ICC.
Dado que una Clave de Sesion de ICC es valida solamente para una unica transaccion, una vez que se ha usado para generar el (los) Criptograma(s) de Aplicacion requeridos durante una transaccion EMV simple, ya no es adicionalmente util para la aplicacion de pago. En algunas disposiciones, despues de que se haya completado una transaccion EMV, la Clave de Sesion de ICC se descarta, lo que puede implicar que el dispositivo de usuario purgue de su memoria la Clave de Sesion de ICC almacenada.
Una vez se ha usado la Clave de Sesion de ICC proporcionada para completar una transaccion de pago, la aplicacion de pago ya no esta equipada para completar una transaccion EMV, y de ese modo la aplicacion de pago puede considerarse que esta en un estado inoperativo. Esto es a diferencia del estado en el que esta la aplicacion de pago cuando no se usa la Clave de Sesion de ICC, cuando la aplicacion de pago puede considerarse que esta en un estado operativo. El descarte de la Clave de Sesion de ICC tal como se ha descrito anteriormente puede formar una condicion de activacion para la configuracion de la aplicacion de pago en el estado inoperativo.
Para impedir que la aplicacion de pago quede permanentemente inoperativa una vez se ha usado la Clave de Sesion de ICC proporcionada, las realizaciones de la presente invencion utilizan la interfaz de comunicaciones entre el dispositivo de usuario y el banco emisor para facilitar la provision de Claves de Sesion de ICC adicionales.
Dado el secreto de la informacion que se transfiere desde el banco emisor al dispositivo de usuario, la comunicacion debe llevarse a cabo de acuerdo con protocolos seguros. En una disposicion el banco emisor y el dispositivo de usuario se comunican a traves de Internet de acuerdo con un protocolo de mensajes seguro apropiado tal como el Protocolo de Transferencia de Hipertexto Seguro (HTTPS). En el caso del ejemplo actual, el banco emisor y el dispositivo de usuario pueden comunicar a traves de la red de telefoma movil, por ejemplo usando Acceso por Paquetes a Alta Velocidad (HSPA) y un protocolo de mensajes seguros apropiado, para recuperar las Claves de Sesion de ICC.
La recepcion de una nueva Clave de Sesion de ICC en el dispositivo de usuario puede hacer que la Clave de Sesion de ICC previamente almacenada se sobrescriba. Alternativamente, si la Clave de Sesion de ICC previamente usada se descarto despues de la finalizacion de una transaccion, la clave de sesion recibida de nuevo puede simplemente almacenarse.
En algunas disposiciones, el dispositivo de usuario se configura para mantener un almacen de multiples Claves de Sesion de ICC para reducir la frecuencia con la que deben aprovisionarse las Claves de Sesion de ICC al dispositivo de usuario. Esto permite al usuario completar multiples transacciones sin requerir un numero correspondiente de instancias de comunicacion entre el dispositivo de usuario y el banco emisor. Esto es particularmente ventajoso si se interrumpe la conexion entre el dispositivo de usuario y el banco emisor, dado que el usuario puede proseguir con varias transacciones durante este periodo. Cuando el dispositivo de usuario mantiene un almacen de multiples claves de sesion de ICC, una clave de sesion de ICC usada puede descartarse tal como se ha descrito anteriormente, marcarse como usada y por lo tanto no disponible para su uso en transacciones futuras, o simplemente eliminarse de un mdice mantenido de Claves de Sesion de ICC no usadas.
La provision de una nueva Clave de Sesion de ICC puede activarse por un cierto numero de diferentes condiciones. En primer lugar, el dispositivo de usuario puede supervisar el numero de Claves de Sesion de ICC no usadas
5
10
15
20
25
30
35
40
45
50
55
60
65
almacenadas en el dispositivo de usuario, y solicitar una nueva Clave de Sesion de ICC cuando todas las Claves de Sesion de ICC disponibles se hayan usado. En segundo lugar, el dispositivo de usuario puede anticipar el agotamiento de las Claves de Sesion de ICC disponibles, y solicitar una nueva Clave de Sesion de ICC cuando el numero de Claves de Sesion de ICC disponibles cae por debajo de un cierto umbral. Este metodo evita la situacion en la que se interrumpe el canal de comunicacion entre el dispositivo de usuario y el banco emisor cuando se uso la ultima Clave de Sesion de ICC, dejando al dispositivo de usuario sin ninguna Clave de Sesion de ICC valida para un procesamiento de transaccion posterior.
Adicionalmente, pueden aprovisionarse nuevas Claves de Sesion de ICC al dispositivo por el banco emisor sin requerir o que se realice una solicitud por parte del dispositivo de usuario. El banco emisor puede determinar el numero de las Claves de Sesion de ICC que se han usado cada vez que se envfa una transaccion en lmea para autorizacion explfcita por el emisor, y decide en consecuencia si debenan aprovisionarse Claves de Sesion de ICC adicionales. De acuerdo con algunas disposiciones, el banco emisor puede aprovisionar periodicamente nuevas Claves de Sesion de ICC al dispositivo de usuario, lo que se describira con detalle adicional a continuacion.
El emisor puede mantener un registro de cuando se ha aprovisionado cada Clave de Sesion de ICC al dispositivo de usuario para determinar cuanto tiempo hace que se ha aprovisionado una Clave de Sesion de ICC dada. Si la transicion se envfa en lmea para autorizacion, el emisor es capaz de limitar la vida util efectiva de las Claves de Sesion de ICC aprovisionadas mediante el rechazo de la autorizacion de transacciones que usen Claves de Sesion de ICC que se hayan aprovisionado al dispositivo de usuario antes de un cierto momento. En algunas disposiciones, el emisor puede utilizar una cantidad de tiempo de umbral cuando se determina si autorizar una transaccion, por ejemplo mediante el rechazo de autorizaciones de transacciones que usan un ARQC codificado usando una Clave de Sesion de ICC que se aprovisiono antes de una fecha definida por la cantidad de umbral. Puede hacerse referencia tambien a la cantidad de tiempo de umbral usada por el emisor cuando se determina si autorizar una transaccion como una vida util de las Claves de Sesion de ICC, desde que una Clave de Sesion de ICC se almacena en el dispositivo de usuario durante mas tiempo que esta cantidad de umbral no sera aceptada para cada autorizaciones en lmea.
El banco emisor puede supervisar la cantidad de tiempo que ha transcurrido desde la provision de una Clave de Sesion de ICC previamente aprovisionada y aprovisionar una nueva Clave de Sesion de ICC para el dispositivo de usuario en respuesta a la cantidad de tiempo que excede la cantidad de umbral. Alternativamente, el banco emisor puede anticipar la cantidad de tiempo que ha transcurrido desde la provision de una Clave de Sesion de ICC previamente aprovisionada que exceda la cantidad de umbral y aprovisionar una nueva Clave de Sesion de ICC al dispositivo de usuario antes de que haya pasado el umbral. Como se ha hecho notar anteriormente, en el caso en el que el dispositivo de usuario anticipe el agotamiento de las Claves de Sesion de ICC disponibles, esto tiene la ventaja de evitar la situacion en la que el canal de comunicacion entre el dispositivo de usuario y el banco emisor se interrumpe en el momento en el que ha transcurrido el umbral, lo que dejana en caso contrario al dispositivo de usuario sin una Clave de Sesion de ICC que usar en transacciones posteriores.
En otras disposiciones el dispositivo de usuario, o mas espedficamente la aplicacion de pago, puede supervisar la cantidad de tiempo que ha transcurrido desde que se provisiono la ultima Clave de Sesion de ICC para detectar cuando la cantidad de tiempo sobrepasa un valor de umbral localmente mantenido, y solicitar en respuesta una o mas nuevas Claves de Sesion de ICC desde el banco emisor. Este valor de umbral local puede ser el mismo que el valor usado en el banco emisor, o configurarse para ser mas corto, para evitar la situacion descrita anteriormente en la que el dispositivo de usuario puede quedarse sin una Clave de Sesion de ICC valida para su uso en transacciones posteriores.
Una nueva Clave de Sesion de ICC recibida en respuesta a una Clave de Sesion de ICC previamente aprovisionada que se acerca o excede su vida util, puede sobrescribir la Clave de Sesion de ICC previamente aprovisionada para asegurar que solo se usan Claves de Sesion de ICC que no han excedido su vida util en el procesamiento de transaccion posterior. En algunas disposiciones, la aplicacion de pago puede descartar Claves de Sesion de ICC que hayan estado almacenadas en el dispositivo de usuario durante mas tiempo que un valor de tiempo de umbral local. En disposiciones alternativas, las Claves de Sesion de ICC pueden mantenerse incluso despues de que haya pasado el umbral local, para su uso en transacciones fuera de lmea.
Para impedir que se rechacen por el emisor transacciones genuinas, el banco emisor puede aprovisionar al dispositivo de usuario con nuevas Claves de Sesion de ICC basandose en la cantidad de tiempo de umbral descrito anteriormente, asf como o en lugar de los criterios previamente descritos.
En algunas disposiciones las Claves de Sesion de ICC pueden cifrarse y almacenarse de modo que queden inaccesibles para la aplicacion de pago sin una entrada espedfica desde el usuario. En esta forma, las Claves de Sesion de ICC pueden ponerse a disposicion de la aplicacion de pago de una en una y tiene la ventaja de permitir que se implemente un nivel de seguridad extra en el dispositivo de usuario forzando al usuario a proporcionar la clave de cifrado, por ejemplo en la forma de una palabra clave, antes de liberar una Clave de Sesion de ICC para que quede disponible para la aplicacion de pago. Esta disposicion tiene la ventaja adicional tambien de requerir que cualquier ataque realizado contra las claves de pago cifradas almacenadas en el dispositivo de usuario descifre dos
5
10
15
20
25
30
35
40
45
50
55
60
65
partes de datos cifradas por separado, comprendiendo una las Claves de Sesion de ICC almacenadas, y comprendiendo la otra las claves de pago restantes. El descifrado de una Clave de Sesion de ICC y proporcionarla a la aplicacion de pago en esta forma tiene el efecto de configurar la aplicacion de pago en el estado operativo, permitiendole llevar a cabo una transaccion EMV.
La Figura 7 ilustra un diagrama de flujo de un mensaje para autorizaciones en lmea de acuerdo con una realizacion de la presente invencion. El proceso se inicia con el terminal de PoS 504 realizando un Analisis de Accion del Terminal (702) para determinar como autorizar la transaccion. Cuando se completa el Analisis de Accion del Terminal el terminal de PoS 504 envfa un comando GENERATE AC al dispositivo de usuario en la etapa 704. Para que se autorice una transaccion en lmea, el terminal 504 debe solicitar o bien un TC o bien un ARQC. En respuesta a la recepcion del comando GENERATE AC, el dispositivo de usuario realiza un Analisis de Accion de Tarjeta en la etapa 706 y responde con un Criptograma de Aplicacion en la etapa 708, que en este caso se supone que es un ARQC. Se genera un Criptograma de Aplicacion basandose en la Clave de Sesion de ICC anteriormente mencionada y en datos espedficos de la transaccion. En respuesta a la recepcion del Criptograma de Aplicacion, el terminal identifica el tipo de Criptograma de Aplicacion enviado por el dispositivo de usuario en la etapa 710 y dirige la ARQC al emisor en la etapa 712 para autorizacion de la transaccion.
El emisor examina entonces el ARQC en la etapa 714 para tomar una decision de si autorizar la transaccion. Opcionalmente, el emisor puede identificar que Clave de Sesion se uso para generar el ARQC, determinar la cantidad de tiempo que ha pasado desde que se aprovisiono la Clave de Sesion de ICC al dispositivo de usuario, y tomar la decision de si autorizar la transaccion en base a si la cantidad de tiempo excede la cantidad de umbral anteriormente mencionada.
El emisor informa de su decision al terminal de PoS en la etapa 716, y basandose en esa decision el terminal de PoS solicita un segundo Criptograma de Aplicacion al dispositivo de usuario en la etapa 720. Si el emisor decidio rechazar la transaccion, el terminal solicita un AAC desde el dispositivo de usuario. Si el emisor decidio autorizar la transaccion, el terminal solicita un TC desde el dispositivo de usuario. En respuesta a la recepcion de la solicitud de la etapa 720, el dispositivo de usuario genera un segundo Criptograma de Aplicacion en la etapa 722, y envfa este al terminal en la etapa 724. El Criptograma de Aplicacion se almacena por el terminal en la etapa 726, y se completa el proceso de autorizacion.
Por ello, realizaciones de la presente invencion son capaces de restringir la capacidad de uso de las claves de pago almacenadas en el dispositivo de usuario no solamente en base a un numero de usos, sino tambien a una cantidad de tiempo.
Como se ha explicado previamente, la viabilidad de una aplicacion de pago se basa en el mantenimiento de la confidencialidad de un cierto numero de claves de pago. Convencionalmente, las claves de pago se implementan en el ICC en el momento de la emision, y se fijan durante la vida util de la aplicacion de pago, que esta ffpicamente en la zona de los tres anos. Debido al uso del elemento seguro en metodos convencionales, puede suponerse con seguridad que las claves de pago no quedaran comprometidas dentro de la vida util de la aplicacion de pago.
Las aplicaciones de pago implementadas en un entorno de aplicacion estandar, tal como se contempla en realizaciones de la presente invencion, no se benefician de las medidas de proteccion mejoradas que puede proporcionar un elemento seguro para almacenamiento y procesamiento de las claves de pago. Las claves de pago se almacenan dentro del entorno de aplicacion estandar, por ejemplo en la ROM u otra parte de memoria persistente, y se cifran para ayudar a protegerlas contra ataques realizados contra el dispositivo de usuario con la intencion de comprometer las claves de pago. Alternativamente, para dispositivos que incluyen un TEE, las claves de pago pueden almacenarse en el TEE (tanto cifradas como sin cifrar).
Aunque el cifrado de las claves de pago proporciona un cierto nivel de proteccion contra estos ataques, esto no es equivalente al nivel de proteccion proporcionado por un elemento seguro. En particular, los datos almacenados en un entorno de aplicacion estandar son susceptibles de ataques tales como ataques de desbordamiento de memoria intermedia, modificacion del sistema operativo e intrusion ffsica, contra los que es inmune un elemento seguro. En donde las claves de pago se almacenan en un TEE, se proporciona un grado mas alto de proteccion de software, pero las claves de pago permanecen vulnerables a intrusion ffsica.
Sin embargo, limitando o restringiendo la utilidad de una o mas de las claves de pago proporcionadas, el riesgo asociado con un ataque exitoso sobre los datos cifrados puede reducirse a un nivel aceptable.
El metodo proporcionado por la presente invencion para limitar la utilidad de una o mas de las claves de pago se refiere a la Clave Maestra de ICC utilizada en la generacion de las Claves de Sesion de ICC para el proceso de Generacion del Criptograma de Aplicacion descrito anteriormente. Convencionalmente, en donde se proporciona la Clave Maestra de ICC dentro de la aplicacion de pago, la aplicacion de pago esta equipada para generar Claves de Sesion de ICC segun se requiera. La especificacion EMV 4.2 limita el numero de las Claves de Sesion de ICC que pueden generarse por una Clave Maestra de ICC a 65535, pero no proporciona ningun metodo para limitar la utilidad de la Clave Maestra de ICC mas alla de este nivel en una forma que pueda limitar suficientemente el riesgo de un
5
10
15
20
25
30
35
ataque con exito contra las claves de pago. Sin embargo, manteniendo la Clave Maestra de ICC en el banco emisor, y configurando la aplicacion de pago con un numero limitado de Claves de Sesion de ICC, las realizaciones de la presente invencion reducen el riesgo planteado por un ataque con exito.
Adicionalmente, limitando la vida util de las Claves de Sesion de ICC, las realizaciones de la invencion son capaces de reducir adicionalmente el riesgo asociado con un ataque con exito sobre las claves de pago. Una forma comun de ataque contra datos cifrados es conocida como un ataque por fuerza bruta. Un ataque por fuerza bruta implica la comprobacion de modo sistematico de un gran numero de posibles claves de cifrado con la intencion de eventualmente descubrir la clave correcta requerida para descifrar los datos. Al reducir la vida util valida de una o mas de las claves de pago a menos que un tiempo de descifrado por fuerza bruta predicho requerido para implementar un ataque de fuerza bruta con exito contra los datos cifrados, es posible hacer ineficaz el ataque por fuerza bruta. Esto es debido a que durante el tiempo que se requiere para que el ataque por fuerza bruta tenga exito, las claves de pago que se obtienen ya no seran validas en su totalidad, y por ello no se podran usar para completar con exito una transaccion de pago en lmea.
Para determinar un valor apropiado para la vida util de una Clave de Sesion de ICC, puede calcularse un tiempo de descifrado por fuerza bruta estimado para los datos cifrados en el dispositivo de usuario. Adicionalmente, pueden tomarse en consideracion vulnerabilidades de cualquier metodo usado para cifrar/descifrar las claves. Por ejemplo, una palabra clave debil (tal como una con pocos caracteres o compuesta de palabras del diccionario) puede conducir a un tiempo de descifrado por fuerza bruta estimado mas bajo. Como se ha descrito previamente, al configurar la vida util de las Claves de Sesion de ICC aprovisionadas a menos de un tiempo de descifrado por fuerza bruta predicho requerido para implementar un ataque con exito, es posible hacer ineficaz un ataque por fuerza bruta, dado que el ataque llevana mas tiempo que la vida util de la Clave de Sesion de ICC.
Las realizaciones anteriores han de entenderse como ejemplos ilustrativos de la invencion. Se conciben realizaciones adicionales de la invencion. Por ejemplo, el dispositivo de usuario puede comprender un dispositivo de telefoma movil capaz de comunicar con el banco emisor a traves de la red telefonica movil de acuerdo con uno o mas protocolos de comunicacion de red, tal como el acceso por paquetes de alta velocidad (HSPA) o CDMA2000. Adicionalmente, el dispositivo de usuario podna ser un dispositivo habilitado para Internet, capaz de comunicar con el banco emisor a traves de Internet de acuerdo con uno o mas protocolos de comunicacion basados en paquetes, tales como un protocolo apropiado para la serie de Protocolos de Internet (IP). Adicionalmente, el metodo de la presente invencion puede manejarse mediante la disposicion del dispositivo de usuario para comunicar con un agente del banco emisor, en lugar de con el banco emisor en sf, en el que el agente esta equipado con los datos necesarios requeridos para aprovisionar a la aplicacion de pago.

Claims (14)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    REIVINDICACIONES
    1. Un metodo para autorizar una transaccion de pago EMV entre un dispositivo de usuario (502; 600) y un terminal de punto de venta (504), siendo dicha transaccion de pago EMV una que se autoriza como parte de la transaccion de pago por un banco emisor (500), en el que dicho banco emisor (500) mantiene datos indicativos de una Clave Maestra de ICC correspondiente a una aplicacion de pago aprovisionada al dispositivo de usuario (502; 600), teniendo la aplicacion de pago un primer estado operativo en el que dicha aplicacion de pago tiene permitido llevar a cabo dicha transaccion de pago EMV, y un segundo estado operativo, diferente de dicho primer estado operativo, comprendiendo el metodo:
    en respuesta a la recepcion de una clave de sesion generada por dicho banco emisor (500) basandose en dicha Clave Maestra de ICC, aprovisionar dicha aplicacion de pago con la clave de sesion, mediante lo que se configura dicha aplicacion de pago en dicho primer estado operativo; y posteriormente
    en respuesta a la recepcion de la solicitud de un criptograma de aplicacion en la aplicacion de pago desde el terminal de punto de venta (504), usar la aplicacion de pago para realizar un proceso de autorizacion, comprendiendo el proceso de autorizacion las etapas de:
    generar dicho criptograma de aplicacion basandose en la clave de sesion recibida; y
    transmitir el criptograma de aplicacion generado al terminal de punto de venta para verificacion del mismo por el banco emisor (500) y autorizacion de la transaccion de pago EMV.
  2. 2. Un metodo de acuerdo con la reivindicacion 1, en el que la clave de sesion se aprovisiona al dispositivo de usuario (502; 600) por dicho banco emisor (500).
  3. 3. Un metodo de acuerdo con la reivindicacion 1 o 2, que comprende descartar dicha clave de sesion despues de completar la transaccion de pago EMV.
  4. 4. Un metodo de acuerdo con cualquier reivindicacion precedente que comprende configurar la aplicacion de pago en el segundo estado operativo en respuesta a finalizar la transaccion de pago EMV.
  5. 5. Un metodo de acuerdo con cualquier reivindicacion precedente, en el que, en respuesta a que se satisface un criterio predeterminado, se aprovisiona una clave de sesion adicional a dicho dispositivo de usuario (502; 600).
  6. 6. Un metodo de acuerdo con la reivindicacion 5, en el que el criterio predeterminado comprende uno o mas de entre:
    la aplicacion de pago esta configurada en el segundo estado operativo;
    recibir una solicitud de un tipo predeterminado, identificando dicha solicitud al menos el dispositivo de usuario (502; 600);
    el dfa, mes y ano mantenido por una entidad de provision de certificados que coincide con una fecha que corresponde a una cantidad de tiempo predeterminada que ha transcurrido desde el aprovisionamiento de la clave de sesion al dispositivo de usuario (502; 600); y
    el numero de claves de sesion almacenadas por el dispositivo de usuario (502; 600) cae por debajo de un valor predeterminado.
  7. 7. Un metodo de acuerdo con cualquier reivindicacion precedente en el que la clave de sesion es accesible por la aplicacion de pago en respuesta a la finalizacion de un proceso de autenticacion del usuario en el dispositivo de usuario (502; 600).
  8. 8. Un metodo acuerdo con cualquier reivindicacion precedente, en el que el dispositivo de usuario (600) comprende una primera parte de procesamiento y una segunda parte de procesamiento, comprendiendo la primera parte de procesamiento un primer entorno de aplicacion (610) dentro de un elemento seguro (612) y comprendiendo la segunda parte de procesamiento un segundo entorno de aplicacion (620) externo al elemento seguro (612), y en el que la segunda parte de procesamiento comprende dicha aplicacion de pago.
  9. 9. Un metodo de acuerdo con la reivindicacion 8, en el que el dispositivo de usuario comprende un dispositivo de comunicaciones movil y el elemento seguro comprende un Modulo de Identidad de Abonado (610).
  10. 10. Un metodo de acuerdo con la reivindicacion 8 o 9 en el que el segundo entorno de aplicacion comprende un Entorno de Ejecucion de Confianza.
  11. 11. El metodo de acuerdo con la reivindicacion 10 en el que dicha clave de sesion se almacena en dicho Entorno de Ejecucion de Confianza.
  12. 12. Un dispositivo de usuario (502; 600) para realizar una transaccion de pago EMV con un terminal de punto de venta (504), siendo dicha transaccion de pago EMV una que se autoriza como parte de la transaccion de pago por
    5
    10
    15
    20
    25
    un banco emisor (500), en el que dicho banco emisor (500) mantiene datos indicativos de una Clave Maestra de ICC, comprendiendo el dispositivo de usuario (502; 600) una aplicacion de pago, teniendo la aplicacion de pago un primer estado operativo en el que dicha aplicacion de pago esta habilitada para realizar dicha transaccion de pago EMV, y un segundo estado operativo, diferente a dicho primer estado operativo, y en el que la aplicacion de pago es sensible a la recepcion de una clave de sesion generada por dicho banco emisor (500) basandose en dicha Clave Maestra de ICC, mediante lo que queda configurado en dicho primer estado operativo y posteriormente se dispone para realizar un proceso de autorizacion, comprendiendo el proceso de autorizacion las etapas de:
    recibir una solicitud de un criptograma de aplicacion desde un terminal de punto de venta (504);
    en respuesta a la recepcion de la solicitud para el criptograma de aplicacion, generar dicho criptograma de
    aplicacion basandose en la clave de sesion recibida; y
    transmitir el criptograma de aplicacion generado al terminal de punto de venta (504) para verificacion del mismo por el banco emisor y autorizacion de la transaccion de pago EMV.
  13. 13. Un dispositivo de usuario de acuerdo con la reivindicacion 12 que comprende:
    una primera parte de procesamiento; y una segunda parte de procesamiento,
    en el que la primera parte de procesamiento comprende un primer entorno de aplicacion (610) dentro de un elemento seguro (612) y la segunda parte de procesamiento comprende un segundo entorno de aplicacion (620) externo al elemento seguro (612), en el que la segunda parte de procesamiento comprende dicha aplicacion de pago.
  14. 14. Un producto de programa informatico que comprende instrucciones que pueden implementarse por procesador que, cuando se ejecutan en un dispositivo de usuario (502; 600), realizan un metodo tal como se ha reivindicado en la reivindicacion 1.
ES12718316.8T 2011-04-05 2012-04-02 Sistema de pago Active ES2632795T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB201105765 2011-04-05
GBGB1105765.0A GB201105765D0 (en) 2011-04-05 2011-04-05 Payment system
PCT/GB2012/050737 WO2012136986A1 (en) 2011-04-05 2012-04-02 Payment system

Publications (1)

Publication Number Publication Date
ES2632795T3 true ES2632795T3 (es) 2017-09-15

Family

ID=44071994

Family Applications (1)

Application Number Title Priority Date Filing Date
ES12718316.8T Active ES2632795T3 (es) 2011-04-05 2012-04-02 Sistema de pago

Country Status (6)

Country Link
US (3) US11080693B2 (es)
EP (3) EP3910580A1 (es)
ES (1) ES2632795T3 (es)
GB (1) GB201105765D0 (es)
HK (1) HK1245484A1 (es)
WO (1) WO2012136986A1 (es)

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB201105765D0 (en) 2011-04-05 2011-05-18 Visa Europe Ltd Payment system
US8346672B1 (en) 2012-04-10 2013-01-01 Accells Technologies (2009), Ltd. System and method for secure transaction process via mobile device
CA2873804A1 (en) 2011-05-17 2012-11-22 Accells Technologies (2009), Ltd. System and method for performing a secure transaction
CN110111087B (zh) * 2011-08-30 2024-01-02 欧威环公司 用于授权利用不可预期密码的交易的系统和方法
CA2883318A1 (en) 2011-08-31 2013-03-07 Ping Identity Corporation System and method for secure transaction process via mobile device
KR101330867B1 (ko) * 2012-12-27 2013-11-18 신한카드 주식회사 결제 디바이스에 대한 상호인증 방법
JP6279217B2 (ja) * 2013-03-08 2018-02-14 株式会社東芝 Ｉｃカード、電子装置、及び携帯可能電子装置
WO2014153680A1 (en) * 2013-03-27 2014-10-02 Irdeto B.V. Protecting software application
US9276910B2 (en) * 2013-11-19 2016-03-01 Wayne Fueling Systems Llc Systems and methods for convenient and secure mobile transactions
RU2661910C1 (ru) 2013-12-02 2018-07-23 Мастеркард Интернэшнл Инкорпорейтед Способ и система для защищенной передачи сообщений сервиса удаленных уведомлений в мобильные устройства без защищенных элементов
CA2931093A1 (en) 2013-12-19 2015-06-25 Visa International Service Association Cloud-based transactions methods and systems
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
CA2884611C (en) * 2014-03-12 2024-04-16 Scott Lawson Hambleton System and method for authorizing a debit transaction without user authentication
MX356939B (es) * 2014-04-14 2018-06-20 Mastercard International Inc Metodo y sistema para generar una llave de almacenamiento avanzada en un dispositivo movil sin elementos de seguridad.
CN106465112A (zh) 2014-05-21 2017-02-22 维萨国际服务协会 离线认证
US10990941B1 (en) 2014-08-15 2021-04-27 Jpmorgan Chase Bank, N.A. Systems and methods for facilitating payments
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
FR3025341B1 (fr) * 2014-09-02 2016-12-30 Oberthur Technologies Securisation de cles de cryptage pour transaction sur un dispositif depourvu de module securise
US10275767B2 (en) 2014-10-21 2019-04-30 Mastercard International Incorporated Method and system for generating cryptograms for validation in a webservice environment
US10187363B2 (en) 2014-12-31 2019-01-22 Visa International Service Association Hybrid integration of software development kit with secure execution environment
US9781105B2 (en) 2015-05-04 2017-10-03 Ping Identity Corporation Fallback identity authentication techniques
DE102015006752A1 (de) * 2015-05-26 2016-12-01 Giesecke & Devrient Gmbh Applikationsauthentisierung
WO2017029596A1 (en) * 2015-08-14 2017-02-23 Mastercard International Incorporated Managing customer uniqueness in tokenised transaction systems
EP3131043A1 (en) * 2015-08-14 2017-02-15 Mastercard International Incorporated Managing customer uniqueness in tokenised transaction systems
EP3131042A1 (en) * 2015-08-14 2017-02-15 Mastercard International Incorporated Managing customer uniqueness in tokenised transaction systems
EP3185194A1 (en) * 2015-12-24 2017-06-28 Gemalto Sa Method and system for enhancing the security of a transaction
EP3185159A1 (en) * 2015-12-24 2017-06-28 Gemalto Sa Method and system for enhancing the security of a transaction
CN106997530B (zh) * 2016-01-25 2022-10-14 创新先进技术有限公司 基于移动终端卡模拟的信用支付方法及装置
EP3232399A1 (en) 2016-04-12 2017-10-18 Visa Europe Limited System for performing a validity check of a user device
CN111899026A (zh) 2016-06-20 2020-11-06 创新先进技术有限公司 一种支付方法和装置
AU2017295842A1 (en) 2016-07-11 2018-11-01 Visa International Service Association Encryption key exchange process using access device
US10679201B2 (en) 2016-11-04 2020-06-09 Nxp B.V. Personal point of sale (pPOS) device that provides for card present E-commerce transaction
US11315137B1 (en) 2016-12-29 2022-04-26 Wells Fargo Bank, N.A. Pay with points virtual card
US11423395B1 (en) 2016-12-29 2022-08-23 Wells Fargo Bank, N.A. Pay with points virtual card
US11514418B2 (en) * 2017-03-19 2022-11-29 Nxp B.V. Personal point of sale (pPOS) device with a local and/or remote payment kernel that provides for card present e-commerce transaction
US10762481B2 (en) 2017-03-21 2020-09-01 The Toronto-Dominion Bank Secure offline approval of initiated data exchanges
US11538030B2 (en) * 2017-08-24 2022-12-27 Clover Network, Llc. Distributing payment keys among multiple discrete devices in a point of sale system
US11921615B2 (en) 2017-12-21 2024-03-05 Mastercard International Corporation Computer-implemented methods, computer-readable media and electronic devices for processing test electronic transactions
US11481837B1 (en) 2018-04-12 2022-10-25 Wells Fargo Bank, N.A. Authentication circle management
US11386412B1 (en) 2018-04-12 2022-07-12 Wells Fargo Bank, N.A. Authentication circle management
US10943308B1 (en) 2018-05-03 2021-03-09 Wells Fargo Bank, N.A. Systems and methods for pervasive advisor for major expenditures
US11620623B2 (en) 2018-05-31 2023-04-04 Nxp B.V. Merchant transaction mirroring for personal point of sale (pPOS) for card present e-commerce and in vehicle transaction
US10581611B1 (en) * 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
SG11202102543WA (en) 2018-10-02 2021-04-29 Capital One Services Llc Systems and methods for cryptographic authentication of contactless cards
EP3654264A1 (en) * 2018-11-14 2020-05-20 Mastercard International Incorporated Credential management for mobile devices
CN110138552B (zh) * 2019-05-08 2021-07-20 北京邮电大学 多用户量子密钥供应方法及装置
US10701560B1 (en) * 2019-10-02 2020-06-30 Capital One Services, Llc Client device authentication using contactless legacy magnetic stripe data
US11704649B2 (en) * 2020-09-03 2023-07-18 Mastercard International Incorporated Contactless payment relay attack protection
US20230073560A1 (en) * 2021-09-08 2023-03-09 Capital One Services, Llc System and method for beacon-based action validation

Family Cites Families (149)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4933971A (en) 1989-03-14 1990-06-12 Tandem Computers Incorporated Method for encrypting transmitted data using a unique key
US5301231A (en) 1992-02-12 1994-04-05 International Business Machines Corporation User defined function facility
GB9309246D0 (en) 1993-05-05 1993-06-16 Esselte Meto Int Gmbh Rechargeable shelf edge tag
US5892900A (en) 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US6658568B1 (en) 1995-02-13 2003-12-02 Intertrust Technologies Corporation Trusted infrastructure support system, methods and techniques for secure electronic commerce transaction and rights management
US6317832B1 (en) 1997-02-21 2001-11-13 Mondex International Limited Secure multiple application card system and process
FR2760871B1 (fr) 1997-03-13 1999-04-16 Bull Cp8 Procede de stockage et d'exploitation d'une information sensible dans un module de securite, et module de securite associe
EP1023703B1 (en) * 1997-10-14 2004-06-09 Visa International Service Association Personalization of smart cards
DE19820422A1 (de) 1998-05-07 1999-11-11 Giesecke & Devrient Gmbh Verfahren zur Authentisierung einer Chipkarte innerhalb eines Nachrichtenübertragungs-Netzwerks
JP2000115153A (ja) 1998-09-30 2000-04-21 Fujitsu Ltd セキュリティ方法及びセキュリティ装置
US6725371B1 (en) 1999-06-30 2004-04-20 Intel Corporation Secure packet processor
JP3570311B2 (ja) 1999-10-07 2004-09-29 日本電気株式会社 無線ｌａｎの暗号鍵更新システム及びその更新方法
GB9929364D0 (en) 1999-12-10 2000-02-02 Microbar Security Limited Improvements in or relating to coding techniques
EP1473722B1 (en) 2000-01-14 2010-09-22 Panasonic Corporation System and method for mutual authentication thereby scrambling information for accessing a confidential data storage area
US20020049636A1 (en) 2000-04-11 2002-04-25 Griffin Carter H. System and method for generating and transmitting data keys to facilitate delivery, pick-up and other commercial transactions
EP2278538A1 (en) 2000-04-24 2011-01-26 Visa International Service Association Online payer authentication service
FR2811451B1 (fr) * 2000-07-07 2002-11-29 Thomson Multimedia Sa Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
US20020095580A1 (en) 2000-12-08 2002-07-18 Brant Candelore Secure transactions using cryptographic processes
US7044394B2 (en) 2003-12-17 2006-05-16 Kerry Dennis Brown Programmable magnetic data storage card
KR100641824B1 (ko) 2001-04-25 2006-11-06 주식회사 하렉스인포텍 대칭키 보안 알고리즘을 이용한 금융정보 입력방법 및 그이동통신용 상거래 시스템
US7996324B2 (en) 2001-07-10 2011-08-09 American Express Travel Related Services Company, Inc. Systems and methods for managing multiple accounts on a RF transaction device using secondary identification indicia
KR100420600B1 (ko) * 2001-11-02 2004-03-02 에스케이 텔레콤주식회사 아이알에프엠을 이용한 이엠브이 지불 처리방법
US7085386B2 (en) 2001-12-07 2006-08-01 Activcard System and method for secure replacement of high level cryptographic keys in a personal security device
WO2003058391A2 (en) 2001-12-26 2003-07-17 Vivotech, Inc. Wireless network micropayment financial transaction processing
US7051932B2 (en) 2001-12-26 2006-05-30 Vivotech, Inc. Adaptor for magnetic stripe card reader
US8909557B2 (en) 2002-02-28 2014-12-09 Mastercard International Incorporated Authentication arrangement and method for use with financial transaction
US7840812B1 (en) * 2002-05-24 2010-11-23 Access Systems Americas, Inc. Authentication of digital certificates used by portable computing devices
US7765281B1 (en) 2003-03-10 2010-07-27 Motive, Inc. Large-scale targeted data distribution system
KR100965437B1 (ko) 2003-06-05 2010-06-24 인터트러스트 테크놀로지즈 코포레이션 Ｐ2ｐ 서비스 편성을 위한 상호운용 시스템 및 방법
US7761374B2 (en) 2003-08-18 2010-07-20 Visa International Service Association Method and system for generating a dynamic verification value
US7636858B2 (en) 2003-12-11 2009-12-22 Intel Corporation Management of a trusted cryptographic processor
US7357309B2 (en) 2004-01-16 2008-04-15 Telefonaktiebolaget Lm Ericsson (Publ) EMV transactions in mobile terminals
US7882361B2 (en) 2004-02-05 2011-02-01 Oracle America, Inc. Method and system for accepting a pass code
US7681232B2 (en) 2004-03-08 2010-03-16 Cardlab Aps Credit card and a secured data activation system
US20050238174A1 (en) 2004-04-22 2005-10-27 Motorola, Inc. Method and system for secure communications over a public network
US20060041655A1 (en) 2004-05-06 2006-02-23 Marty Holloway Bi-directional remote control for remotely controllable apparatus
KR100646361B1 (ko) 2004-06-04 2006-11-23 에스케이 텔레콤주식회사 모바일 뱅킹용 아이씨 카드 내장 이동단말기를 이용한금융거래 시스템 및 방법
US7287692B1 (en) 2004-07-28 2007-10-30 Cisco Technology, Inc. System and method for securing transactions in a contact center environment
US7506812B2 (en) 2004-09-07 2009-03-24 Semtek Innovative Solutions Corporation Transparently securing data for transmission on financial networks
US20060093149A1 (en) 2004-10-30 2006-05-04 Shera International Ltd. Certified deployment of applications on terminals
EP1662788A1 (fr) 2004-11-24 2006-05-31 Nagravision SA Unité de traitement de données audio/vidéo numériques et méthode de contrôle d'accès audites données
US8700729B2 (en) 2005-01-21 2014-04-15 Robin Dua Method and apparatus for managing credentials through a wireless network
US7581678B2 (en) 2005-02-22 2009-09-01 Tyfone, Inc. Electronic transaction card
WO2007028048A2 (en) 2005-09-02 2007-03-08 Fair Isaac Corporation Systems and methods for detecting fraud
EP1934935A4 (en) 2005-09-28 2011-03-02 Visa Int Service Ass DEVICE, SYSTEM AND METHOD FOR REDUCING INTERACTION TIME FOR CONTACTLESS TRANSACTION
JP2009512018A (ja) 2005-10-06 2009-03-19 シー・サム，インコーポレイテッド トランザクションサービス
CA2531411C (en) 2005-12-23 2017-02-14 Bce Inc System and method for encrypting traffic on a network
US8290433B2 (en) 2007-11-14 2012-10-16 Blaze Mobile, Inc. Method and system for securing transactions made through a mobile communication device
US9065643B2 (en) * 2006-04-05 2015-06-23 Visa U.S.A. Inc. System and method for account identifier obfuscation
FR2901079A1 (fr) 2006-05-15 2007-11-16 Gemplus Sa Procede pour securiser une transaction par carte a puce, terminal d'ecriture pour securiser une telle transaction, et carte a puce securisee
US20080126260A1 (en) 2006-07-12 2008-05-29 Cox Mark A Point Of Sale Transaction Device With Magnetic Stripe Emulator And Biometric Authentication
GB2442249B (en) 2007-02-20 2008-09-10 Cryptomathic As Authentication device and method
US20080305769A1 (en) * 2007-06-08 2008-12-11 Nahum Rubinstein Device Method & System For Facilitating Mobile Transactions
US8355982B2 (en) 2007-08-16 2013-01-15 Verifone, Inc. Metrics systems and methods for token transactions
US20090048935A1 (en) 2007-08-16 2009-02-19 Microsoft Corporation Application program interface to manage gift cards and check authorizations
US8041338B2 (en) 2007-09-10 2011-10-18 Microsoft Corporation Mobile wallet and digital payment
US8095113B2 (en) 2007-10-17 2012-01-10 First Data Corporation Onetime passwords for smart chip cards
US10558961B2 (en) * 2007-10-18 2020-02-11 Wayne Fueling Systems Llc System and method for secure communication in a retail environment
US20090106138A1 (en) 2007-10-22 2009-04-23 Smith Steven E Transaction authentication over independent network
US20090159703A1 (en) 2007-12-24 2009-06-25 Dynamics Inc. Credit, security, debit cards and the like with buttons
US7922082B2 (en) 2008-01-04 2011-04-12 M2 International Ltd. Dynamic card validation value
FR2926382B1 (fr) * 2008-01-11 2010-02-26 Proton World Internat Nv Hierarchisation de cles cryptographiques dans un circuit electronique
CN101515319B (zh) 2008-02-19 2011-01-26 联想(北京)有限公司 密钥处理方法、密钥密码学服务系统和密钥协商方法
US20090216680A1 (en) 2008-02-26 2009-08-27 Battelle Energy Alliance, Llc Systems and Methods for Performing File Distribution and Purchase
US20090254479A1 (en) 2008-04-02 2009-10-08 Pharris Dennis J Transaction server configured to authorize payment transactions using mobile telephone devices
WO2009136404A2 (en) * 2008-04-17 2009-11-12 Atom Technologies Limited A system and method for implementing a secure transaction through mobile communicating device
US8200206B2 (en) 2008-04-21 2012-06-12 W2Bi, Inc. Virtual mobile and Ad/Alert management for mobile devices
US8041346B2 (en) 2008-05-29 2011-10-18 Research In Motion Limited Method and system for establishing a service relationship between a mobile communication device and a mobile data server for connecting to a wireless network
CN101593196B (zh) 2008-05-30 2013-09-25 日电（中国）有限公司 用于快速密文检索的方法、装置和系统
JP2010004390A (ja) 2008-06-20 2010-01-07 Toshiba Corp 通信装置、鍵サーバ及びデータ
TWI375447B (en) 2008-06-27 2012-10-21 Ind Tech Res Inst Multi-layer encryption and decryption system and method thereof
US20110276420A1 (en) * 2008-09-17 2011-11-10 Robert White Cash card system
AU2009293439B2 (en) * 2008-09-17 2013-01-17 Mastercard International, Inc. Off-line activation/loading of pre-authorized and cleared payment cards
US9026462B2 (en) 2008-09-30 2015-05-05 Apple Inc. Portable point of purchase user interfaces
US10839384B2 (en) 2008-12-02 2020-11-17 Paypal, Inc. Mobile barcode generation and payment
JP2010238274A (ja) 2009-03-30 2010-10-21 Sanyo Electric Co Ltd 光ピックアップ装置
WO2010127012A1 (en) 2009-04-28 2010-11-04 Mastercard International Incorporated Apparatus, method, and computer program product for providing a quality control mechanism for the contactless interface of a dual-interface card
US8602293B2 (en) 2009-05-15 2013-12-10 Visa International Service Association Integration of verification tokens with portable computing devices
US8534564B2 (en) 2009-05-15 2013-09-17 Ayman Hammad Integration of verification tokens with mobile communication devices
US8893967B2 (en) 2009-05-15 2014-11-25 Visa International Service Association Secure Communication of payment information to merchants using a verification token
SE0950411A1 (sv) 2009-06-04 2010-09-21 Accumulate Ab Metod för säkra transaktioner
US10748146B2 (en) 2009-06-16 2020-08-18 Heartland Payment Systems, Llc Tamper-resistant secure methods, systems and apparatuses for credit and debit transactions
US10454693B2 (en) 2009-09-30 2019-10-22 Visa International Service Association Mobile payment application architecture
US8523059B1 (en) 2009-10-20 2013-09-03 Dynamics Inc. Advanced payment options for powered cards and devices
CN102096972A (zh) 2009-12-15 2011-06-15 中国移动通信集团公司 一种基于用户终端完成联机支付的方法、系统及用户终端
US8998096B2 (en) 2010-04-01 2015-04-07 Coin, Inc. Magnetic emissive use of preloaded payment card account numbers
US9195926B2 (en) 2010-03-02 2015-11-24 Gonow Technologies, Llc Portable e-wallet and universal card
US10579995B2 (en) 2010-03-30 2020-03-03 Visa International Service Association Event access with data field encryption for validation and access control
US9189786B2 (en) 2010-03-31 2015-11-17 Mastercard International Incorporated Systems and methods for operating transaction terminals
US9208482B2 (en) 2010-04-09 2015-12-08 Paypal, Inc. Transaction token issuing authorities
US8380177B2 (en) 2010-04-09 2013-02-19 Paydiant, Inc. Mobile phone payment processing methods and systems
JP5433498B2 (ja) 2010-05-27 2014-03-05 株式会社東芝 暗号処理装置
FR2962571B1 (fr) 2010-07-08 2012-08-17 Inside Contactless Procede d'execution d'une application securisee dans un dispositif nfc
CA2958140C (en) 2010-08-12 2019-05-07 Mastercard International, Inc. Multi-commerce channel wallet for authenticated transactions
US9602849B2 (en) 2010-09-17 2017-03-21 Futurewei Technologies, Inc. Method and apparatus for scrub preview services
US20120284195A1 (en) 2011-05-04 2012-11-08 Mcmillen Glenn Curtiss Method and system for secure user registration
US20120089519A1 (en) 2010-10-06 2012-04-12 Prasad Peddada System and method for single use transaction signatures
US9965756B2 (en) 2013-02-26 2018-05-08 Digimarc Corporation Methods and arrangements for smartphone payments
US20120143707A1 (en) 2010-12-07 2012-06-07 Deepak Jain Executing Reader Application
US20120254041A1 (en) 2011-03-31 2012-10-04 Infosys Technologies Ltd. One-time credit card numbers
GB201105774D0 (en) 2011-04-05 2011-05-18 Visa Europe Ltd Payment system
GB201105765D0 (en) 2011-04-05 2011-05-18 Visa Europe Ltd Payment system
US8639938B2 (en) 2011-05-03 2014-01-28 International Business Machines Corporation Personal identification number security enhancement
SG195079A1 (en) 2011-06-03 2013-12-30 Visa Int Service Ass Virtual wallet card selection apparatuses, methods and systems
WO2012170895A1 (en) 2011-06-09 2012-12-13 Yeager C Douglas Systems and methods for authorizing a transaction
US9172539B2 (en) 2011-09-14 2015-10-27 Mastercard International Incorporated In-market personalization of payment devices
WO2013040684A1 (en) 2011-09-22 2013-03-28 Securekey Technologies Inc. Systems and methods for contactless transaction processing
US9721319B2 (en) 2011-10-14 2017-08-01 Mastercard International Incorporated Tap and wireless payment methods and devices
US8856640B1 (en) 2012-01-20 2014-10-07 Google Inc. Method and apparatus for applying revision specific electronic signatures to an electronically stored document
US20130212007A1 (en) 2012-02-10 2013-08-15 Protegrity Corporation Tokenization in payment environments
US10535064B2 (en) 2012-03-19 2020-01-14 Paynet Payments Network, Llc Systems and methods for real-time account access
US9842335B2 (en) 2012-03-23 2017-12-12 The Toronto-Dominion Bank System and method for authenticating a payment terminal
US10515359B2 (en) 2012-04-02 2019-12-24 Mastercard International Incorporated Systems and methods for processing mobile payments by provisioning credentials to mobile devices without secure elements
CN104272331B (zh) 2012-04-18 2017-06-23 谷歌公司 在不具有安全元件的情况下处理支付交易
US8990572B2 (en) 2012-04-24 2015-03-24 Daon Holdings Limited Methods and systems for conducting smart card transactions
US10445720B2 (en) 2012-07-31 2019-10-15 Worldpay, Llc Systems and methods for payment management for supporting mobile payments
US9361619B2 (en) 2012-08-06 2016-06-07 Ca, Inc. Secure and convenient mobile authentication techniques
US8955039B2 (en) 2012-09-12 2015-02-10 Intel Corporation Mobile platform with sensor data security
CN103530775B (zh) 2012-09-28 2020-11-03 深圳市可秉资产管理合伙企业（有限合伙） 用于提供可控的可信服务管理平台的方法和系统
US20140108241A1 (en) 2012-10-08 2014-04-17 NXT-ID, Inc. Method for Replacing Traditional Payment and Identity Management Systems and Components to Provide Additional Security and a System Implementing Said Method
US20140149285A1 (en) 2012-11-29 2014-05-29 International Business Machines Corporation Effecting payments via mobile phones
KR101316377B1 (ko) 2012-12-26 2013-10-08 신한카드 주식회사 결제 디바이스의 금융 칩 제어방법
KR101330867B1 (ko) 2012-12-27 2013-11-18 신한카드 주식회사 결제 디바이스에 대한 상호인증 방법
US20140244514A1 (en) 2013-02-26 2014-08-28 Digimarc Corporation Methods and arrangements for smartphone payments and transactions
DE102013003205A1 (de) 2013-02-26 2014-08-28 Giesecke & Devrient Gmbh Verfahren zur sicheren Zugangscode-Eingabe
US9022285B2 (en) 2013-03-01 2015-05-05 Looppay, Inc. System and method for securely loading, storing and transmitting magnetic stripe date in a device working with a mobile wallet system
WO2014152419A1 (en) 2013-03-15 2014-09-25 Mastercard International Incorporated Transaction-history driven counterfeit fraud risk management solution
CN103220270A (zh) 2013-03-15 2013-07-24 福建联迪商用设备有限公司 密钥下载方法、管理方法、下载管理方法及装置和系统
US20150012980A1 (en) 2013-03-15 2015-01-08 Waldemar Mikolajczyk Systems and methods for secure singular computing environment
GB201304764D0 (en) 2013-03-15 2013-05-01 Mastercard International Inc Method and apparatus for payment transactions
GB2512595A (en) 2013-04-02 2014-10-08 Mastercard International Inc Integrated contactless mpos implementation
US20160019512A1 (en) 2013-04-21 2016-01-21 SSI America INC. Transaction facilitation methods and apparatuses
US9118486B2 (en) 2013-05-21 2015-08-25 Cisco Technology, Inc. Revocation of public key infrastructure signatures
GB2514780A (en) 2013-06-03 2014-12-10 Mastercard International Inc Methods and apparatus for performing local transactions
WO2015026664A1 (en) 2013-08-20 2015-02-26 Mastercard International Incorporated Method and system for computing code management platform
US9786423B2 (en) 2013-10-28 2017-10-10 Massachusetts Institute Of Technology Method and apparatus for producing an asymmetric magnetic field
WO2015065323A1 (en) 2013-10-29 2015-05-07 Intel Corporation Flexible bootstrap code architecture
US9425968B2 (en) 2013-11-15 2016-08-23 Landis+Gyr Innovations, Inc. System and method for updating an encryption key across a network
US9037491B1 (en) 2013-11-26 2015-05-19 Square, Inc. Card reader emulation for cardless transactions
US9350774B2 (en) 2013-12-16 2016-05-24 Dropbox, Inc. Automatic sharing of digital multimedia
CA2931093A1 (en) 2013-12-19 2015-06-25 Visa International Service Association Cloud-based transactions methods and systems
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
GB2522905A (en) 2014-02-10 2015-08-12 Mastercard International Inc Management of multiple identities in a transaction infrastructure
CN106465112A (zh) 2014-05-21 2017-02-22 维萨国际服务协会 离线认证
US9717108B2 (en) 2014-06-20 2017-07-25 Visa International Service Association Midrange contactless transactions
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
US11620654B2 (en) 2014-12-04 2023-04-04 Mastercard International Incorporated Methods and apparatus for conducting secure magnetic stripe card transactions with a proximity payment device
US10116447B2 (en) 2015-02-17 2018-10-30 Visa International Service Association Secure authentication of user and mobile device
US10552620B2 (en) 2016-06-20 2020-02-04 Intel Corporation Technologies for trusted I/O protection of I/O data with header information

Also Published As

Publication number Publication date
EP3232410A1 (en) 2017-10-18
WO2012136986A1 (en) 2012-10-11
EP2695148A1 (en) 2014-02-12
US20230306419A1 (en) 2023-09-28
US20140040149A1 (en) 2014-02-06
HK1245484A1 (zh) 2018-08-24
EP3910580A1 (en) 2021-11-17
EP3232410B1 (en) 2021-06-16
US11080693B2 (en) 2021-08-03
US11694199B2 (en) 2023-07-04
GB201105765D0 (en) 2011-05-18
EP2695148B1 (en) 2017-05-10
US20210326870A1 (en) 2021-10-21

Similar Documents

Publication Publication Date Title
ES2632795T3 (es) Sistema de pago
US11847640B2 (en) Payment system for authorizing a transaction between a user device and a terminal
AU2021203184B2 (en) Transaction messaging
CN107925572B (zh) 软件应用程序到通信装置的安全绑定
ES2881873T3 (es) Procedimiento de protección de una ficha de pago
US8762742B2 (en) Security architecture for using host memory in the design of a secure element
CA2838763C (en) Credential authentication methods and systems
JP6743276B2 (ja) エンドツーエンド鍵管理のためのシステム及び方法
ES2877522T3 (es) Método y sistema para mejorar la seguridad de una transacción
KR101394147B1 (ko) 모바일에서 안전하게 인증서를 사용하는 방법