ES2971660T3 - Procedimiento para llevar a cabo una transacción, terminal, servidor y programa informático correspondiente - Google Patents

Procedimiento para llevar a cabo una transacción, terminal, servidor y programa informático correspondiente

Info

Publication number
ES2971660T3
ES2971660T3 ES19172647T ES19172647T ES2971660T3 ES 2971660 T3 ES2971660 T3 ES 2971660T3 ES 19172647 T ES19172647 T ES 19172647T ES 19172647 T ES19172647 T ES 19172647T ES 2971660 T3 ES2971660 T3 ES 2971660T3
Authority
ES
Spain
Prior art keywords
transaction
certification
payment
data
code
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
ES19172647T
Other languages
English (en)
Inventor
Pierre Quentin
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.)
Banks and Acquirers International Holding SAS
Original Assignee
Banks and Acquirers International Holding SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Banks and Acquirers International Holding SAS filed Critical Banks and Acquirers International Holding SAS
Application granted granted Critical
Publication of ES2971660T3 publication Critical patent/ES2971660T3/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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/353—Payments by cards read by 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/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3226—Use of secure elements separate from 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/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in 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/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of 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/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/352—Contactless payments by cards
    • 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/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4018—Transaction verification using the card verification value [CVV] associated with the card
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • 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/321—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wearable 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/63—Location-dependent; Proximity-dependent

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La invención se refiere a un método para procesar una transacción de un terminal de comunicación (ComT), solicitando a un servidor (SrvT), a través de una red de comunicación, la implementación de 'una transacción que involucra el uso de datos de pago, un proceso implementado dentro de la comunicación Terminal. Según la invención, dicho método comprende: - una etapa de emisión (10), al medio de pago cuyos datos se utilizan para la transacción, una solicitud para obtener un código de certificación (ReqCCert); - una etapa de recepción (20), de dicho medio de pago, de dicho código de certificación (CCert);- un paso de insertar (30) dicho código de certificación (CCert), dentro de una estructura de datos de transacción (SDTr);- un paso de transmitir (40) el estructura de datos de transacción (SDTr) a dicho servidor;- y cuando el código de certificación recibido por dicho servidor es válido, una etapa de recepción (50) d' datos representativos de la validación (ValT) de la transacción por dicho servidor. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Procedimiento para llevar a cabo una transacción, terminal, servidor y programa informático correspondiente
1. Sector de la invención
La invención se refiere a la seguridad de los pagos. Más concretamente, la invención se refiere a la seguridad de los pagos realizados utilizando un terminal de comunicación portátil, tal como un teléfono inteligente, una tableta o incluso un reloj inteligente. En consecuencia, este tipo de pago recibe el nombre de pago móvil. Aún más específicamente, un objetivo de la presente técnica es aumentar el nivel de seguridad de una transmisión de datos en el marco de un pago móvil realizado con un terminal de comunicación portátil (por ejemplo, un teléfono inteligente o una tableta) y una tarjeta de pago.
2. Técnica anterior
En general, los pagos en línea, de los cuales los pagos móviles representan, por un lado, un tipo particular y, por otro, una parte cada vez mayor de los pagos que se realizan cada día en todo el mundo, se pueden realizar a través de proveedores de pago, tales como Paypal™, o a través de organizaciones bancarias tradicionales, mediante una tarjeta bancaria de pago.
Sin embargo, los pagos en línea se caracterizan por una tasa de fraude relativamente alta. En Francia, se estima que aproximadamente el 5 % de los pagos en línea realizados en Internet son fraudulentos. Este cinco por ciento de pagos fraudulentos representan aproximadamente el treinta y tres por ciento del coste total del fraude. Por consiguiente, es necesario disponer de medios, por un lado, para identificar los intentos de fraude y, por otro lado, para bloquear estos intentos.
Uno de los problemas de las transacciones móviles es que se realizan en modo de «tarjeta no presente» (es decir, CNP, «Card Non Present» en inglés). En este modo, puesto que ningún dispositivo es responsable de verificar la integridad de la tarjeta (tal como, por ejemplo, un terminal de pago), no es posible verificar que el titular de la tarjeta posea el código PIN necesario para validar una transacción: la tarjeta de pago no se utiliza para realizar la transacción. Solo se introducen los datos introducidos en la tarjeta. Los estafadores pueden robar estos datos para completar transacciones, posiblemente utilizando otras aplicaciones comerciales, como parte de otros pagos móviles. Por cierto, el terminal de comunicación del usuario (que comprende todos los datos de las tarjetas de pago utilizadas por el usuario) también puede ser robado, dando al ladrón acceso a todos los datos del usuario y permitiendo al ladrón realizar transacciones fraudulentas.
Por lo tanto, para proteger las transacciones realizadas en modo de CNP, se han propuesto sistemas y procedimientos para resolver estos problemas de fraude. Estos procedimientos plantean problemas de comodidad para el usuario u otros problemas de seguridad. Por ejemplo, este es el procedimiento descrito en el documento de patente WO2012053780. En este documento, se describen un sistema y un procedimiento de verificación. Más concretamente, se describen un procedimiento y un sistema que utilizan información sobre la dirección MAC de un terminal cliente. Durante una transacción que implica un pago, se implementa un procedimiento de autenticación en el que la dirección MAC del terminal utilizado por el usuario que desea realizar un pago se compara con una dirección MAC de referencia, definida u obtenida por el servidor del banco, cuyo servidor debe autorizar un pago o una transacción.
Este procedimiento, aunque potencialmente interesante es, no obstante, poco práctico. De hecho, por un lado, este procedimiento requiere que el usuario utilice siempre el mismo dispositivo para realizar un pago (excepto que estén definidos varios dispositivos autorizados para realizar una transacción). Por otro lado, existen muchos procedimientos para falsificar la dirección MAC de un periférico. Más concretamente, el procedimiento descrito en el documento WO2012053780 se basa en obtener una dirección MAC desde un navegador web. Sin embargo, un pirata informático que desee obtener la dirección MAC de un usuario no tendrá dificultades para obtenerla al introducir los detalles de la tarjeta de crédito del usuario, por ejemplo, mediante un procedimiento que consiste en presentarse ante el servidor del comerciante (o el editor de la aplicación utilizada para el pago). Por lo tanto, el procedimiento del documento WO2012053780 no parece muy útil, puesto que la información adicional (la dirección MAC del dispositivo de transacción) sería tan vulnerable como las demás. Por lo tanto, el procedimiento descrito tendría pocas posibilidades de hacer segura realmente la transacción.
También hay otros procedimientos disponibles. Algunos implican proporcionar al usuario números de tarjetas bancarias únicos. Estos números se proporcionan en función de las necesidades del cliente. Este procedimiento es interesante pero no elimina la posibilidad de que el usuario utilice su propia información de tarjeta para realizar transacciones. Otros procedimientos, actualmente muy utilizados, consisten en transmitir un mensaje del tipo de SMS al cliente que está realizando una transacción, para asegurarse de que es el titular de la tarjeta. En el momento de la transacción, el usuario debe introducir una contraseña enviada en el SMS. Por lo tanto, el banco se asegura con una probabilidad razonable de que la persona que realiza la transacción es el usuario. Este procedimiento tiene dos inconvenientes: por un lado, requiere que el usuario proporcione su número de teléfono al banco antes de cualquier transacción y de manera segura; por otro lado, este procedimiento solo funciona si el banco del cliente es también el banco que gestiona la transacción en nombre del comerciante, lo que no es necesariamente el caso, especialmente en el extranjero, precisamente donde se lleva a cabo gran parte del fraude. Por lo tanto, el procedimiento mencionado anteriormente no es muy eficaz en este caso.
También se conocen otros procedimientos, por ejemplo, a partir de los documentos US2016/063480 A1, EP3319031 A1, US2014/136350 A1 y WO2010/070539 A1.
3. Compendio de la invención
El procedimiento propuesto por los inventores no plantea estos problemas de la técnica anterior. De hecho, se propone un procedimiento para localizar a un usuario que realiza un pago móvil.
Más concretamente, la invención se refiere a un procedimiento para llevar a cabo una transacción, tal como el procedimiento de la reivindicación 1.
Por lo tanto, la invención permite validar una transacción (tal como un pago móvil) sobre la base de un código específico, el código de certificación, que se obtiene del medio de pago cuyos datos se utilizan para permitir la realización del pago móvil.
Dicho código de certificación depende de un valor que no está necesariamente vinculado al propio medio de pago, lo que permite aumentar la seguridad de este código de certificación.
Según una característica concreta, el parámetro de certificación pertenece al grupo que comprende:
- un parámetro de una función para crear dicho código de certificación;
- un valor representativo de un identificador de un comerciante;
- un valor representativo de un identificador de terminal de comunicación;
- un valor representativo de la transacción;
- un valor representativo de una fecha y/o una hora de la transacción.
Por lo tanto, el código de certificación se crea de una manera única, para la transacción en curso. Por consiguiente, el código de certificación no puede ser reutilizado por segunda vez (reproducción) en el contexto de otra transacción que llevaría a cabo un defraudador.
Según una característica concreta, dicha etapa de introducir dicho código de certificación, dentro de una estructura de datos de transacción, comprende una etapa de seleccionar, de entre una pluralidad de campos disponibles, un campo existente específico.
Por lo tanto, en lugar de agregar un campo dedicado a recibir el código de certificación, la técnica permite seleccionar, dentro de los campos disponibles, un campo específico en el que se introduce el código de certificación.
Dicho campo específico es el campo dedicado a recibir el código de verificación (CVV).
Por lo tanto, en lugar de utilizar el código de verificación (CVV) (estático) para poder validar que el propietario del medio de pago conoce bien todos los datos adjuntos, los inventores proponen reemplazar este código por el código de certificación (que es dinámico y, por lo tanto, más seguro), sin que sea necesario modificar la estructura de datos transmitida a través de la red de comunicación.
Según una realización concreta, el parámetro de certificación comprende un dato representativo de un identificador de dicho terminal de comunicación y un dato representativo de una hora de la transacción.
Según una realización concreta, el código de certificación es representativo de una operación de cifrado realizada por dicho medio de pago, realizándose dicha operación de cifrado por medio de una comunicación de tipo NFC entre dicho terminal de comunicación de usuario y dicho medio de pago.
Según otro aspecto, la invención también se refiere a un servidor para procesar una transacción, tal como el servidor de la reivindicación 5.
Según otro aspecto, la invención también se refiere a un terminal de comunicación tal como el terminal de comunicación de la reivindicación 6.
Según una implementación preferida, las diferentes etapas de los procedimientos según la invención se implementan mediante uno o varios programas de software o programas informáticos, que comprenden instrucciones de software destinadas a ser ejecutadas por un procesador de datos de un módulo de retransmisión según la invención y que están concebidas para controlar la ejecución de las diferentes etapas de los procedimientos.
En consecuencia, la invención también se refiere a un programa que puede ser ejecutado por un ordenador o por un procesador de datos, comprendiendo este programa instrucciones para controlar la ejecución de las etapas de un procedimiento tal como el mencionado anteriormente.
Este programa puede utilizar cualquier lenguaje de programación y estar en forma de código fuente, código objeto o código intermedio entre el código fuente y el código objeto, tal como en una forma parcialmente compilada o en cualquier otra forma deseable.
La invención también se refiere a un soporte de información legible por un procesador de datos, y que comprende instrucciones de un programa tal como el mencionado anteriormente.
El soporte de información puede ser cualquier entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el soporte puede incluir un medio de almacenamiento, tal como una ROM, por ejemplo un CD ROM o una ROM de circuito microelectrónico, o incluso un medio magnético de grabación, por ejemplo, un soporte móvil (tarjeta de memoria) o un disco duro.
Por otro lado, el soporte de información puede ser un soporte transmisible tal como una señal eléctrica u óptica, que puede ser transmitida a través de un cable eléctrico u óptico, por radio o por otros medios. En concreto, el programa según la invención puede estar cargado en una red de tipo Internet.
Alternativamente, el soporte de información puede ser un circuito integrado en el que está incorporado el programa, estando adaptado el circuito para ejecutar el procedimiento en cuestión o para ser utilizado en la ejecución del mismo.
Según una realización, la invención se implementa por medio de componentes de software y/o hardware. En este contexto, el término «módulo» puede corresponder en este documento tanto a un componente de software como a un componente de hardware o a un conjunto de componentes de hardware y software.
Un componente de software corresponde a uno o varios programas informáticos, uno o varios subprogramas de un programa o, de manera más general, a cualquier elemento de un programa o software capaz de implementar una función o un conjunto de funciones, según lo que se describe a continuación para el módulo en cuestión. Dicho componente de software es ejecutado por un procesador de datos de una entidad física (terminal, servidor, pasarela, enrutador, etc.) y es capaz de acceder a los recursos de hardware de esta entidad física (memorias, medios de registro, buses de comunicación, tarjetas electrónicas de entrada/salida, interfaces de usuario, etc.).
Del mismo modo, un componente de hardware corresponde a cualquier elemento de un conjunto de hardware (o hardware) capaz de implementar una función o un conjunto de funciones, según lo que se describe a continuación para el módulo en cuestión. Se puede tratar de un componente de hardware programable o un componente con un procesador integrado para ejecutar software, por ejemplo, un circuito integrado, una tarjeta inteligente, una tarjeta de memoria, una tarjeta electrónica para ejecutar un firmware, etc.
Obviamente, cada componente del sistema descrito anteriormente utiliza sus propios módulos de software.
Las diversas realizaciones mencionadas anteriormente se pueden combinar entre sí para implementar la invención.
4. Figuras
Otras características y ventajas de la invención resultarán más claramente evidentes con la lectura de la siguiente descripción de una realización preferente de la invención, dada como un simple ejemplo ilustrativo y no limitativo, y los dibujos adjuntos, en los que:
- la figura 1 describe una realización del procedimiento de realización de transacción;
- la figura 2 describe una realización obtenida a partir del procedimiento de realización de transacción;
- la figura 3 ilustra una arquitectura de un servidor capaz de implementar un procedimiento de realización de transacción;
- la figura 4 ilustra una arquitectura de un cliente capaz de implementar un procedimiento de realización de transacción;
5. Descripción de una realización
5.1. Resumen del principio de la invención
Tal como se explicó anteriormente, se descubrió que las soluciones actuales no permitían garantizar necesariamente que el pago móvil que se realiza proviene del titular del medio de pago (de una tarjeta de pago, por ejemplo) cuyos datos se utilizan. El objetivo del procedimiento propuesto es garantizar que, al utilizar los datos del medio de pago en modo de CNP (es decir, introduciendo los datos de pago en un formulario o utilizando los datos de pago en su forma textual para crear una transacción), en el contexto de un pago móvil, todavía sea posible obtener una certificación de la presencia del medio de pago. En resumen, el objetivo es pasar de un modo de CNP (uso textual de los datos de pago) a un modo en el que se verifique la presencia del medio de pago sin cambiar radicalmente los hábitos del usuario y con total discreción.
Para ello, se modifican las etapas que conducen a la validación de la transacción. En al menos una realización del procedimiento propuesto, además de (o en lugar de) los datos de la tarjeta de pago (nombre, número, fecha, código de verificación visual (CVV)), se obtiene un dato transmitido por el propio medio de pago, de manera independiente y complementaria. En un modo básico, estos datos transmitidos por el medio de pago consisten en una firma digital de algunos de los datos almacenados allí.
Por lo tanto, el principio general de la presente técnica se basa en la implementación de un terminal de comunicación que comprende medios para obtener datos (tal como, por ejemplo, un procesador o un circuito que comprende un microprocesador de tratamiento) de un medio de pago (entendiéndose que es, por ejemplo, una tarjeta de pago y/u otro dispositivo de comunicación que comprende una función de pago). Más específicamente, en al menos una realización, un medio para obtener datos de un medio de pago es en forma de un módulo de comunicación sin contacto, siendo dicho módulo más específicamente un módulo de comunicación de campo cercano (Near Field Communication, NFC, en inglés). Este módulo recibe, desde un procesador del terminal de comunicación, una instrucción o un comando para obtener datos sin contacto. Puede ser un comando de carácter general. Además, este módulo está conectado a una antena sin contacto. Esta antena sin contacto se utiliza para transmitir una señal al medio de pago y para recibir una señal de este medio de pago. Para ello, por ejemplo, se implementa una aplicación instalada en el terminal de comunicación, que comprende medios para detectar campos para introducir datos de medios de pago.
Un medio de pago sin contacto se presenta, por ejemplo, en forma de una tarjeta de pago (o tarjeta de crédito o débito), que comprende una antena de tipo de NFC(«comunicación de campo cercano»);comprendiendo esta antena medios para transmitir datos a un receptor, cuando recibe, de este receptor, una solicitud en este sentido (la solicitud adopta la forma de una señal electromagnética, por ejemplo). La antena, denominada antena sin contacto, se puede conectar a un procesador. Este procesador puede ser, por ejemplo, el chip de la tarjeta inteligente o un procesador adicional integrado en el sustrato de la tarjeta (al igual que la antena). Por cierto, un medio de pago sin contacto también se puede presentar en forma de un terminal de comunicación (un segundo terminal de comunicación), que está equipado con medios de transmisión de datos sin contacto y posiblemente con una aplicación destinada específicamente a transmitir datos que sean equivalentes o idénticos a los datos de tarjeta de pago. Una aplicación de este tipo puede ser, por ejemplo, una aplicación bancaria, instalada en el terminal de comunicación, y que almacena estos datos de manera segura. En este caso, por ejemplo, la técnica se implementa conectando este segundo terminal de comunicación al primer terminal de comunicación. Una implementación de este tipo es totalmente factible en la medida en que muchas personas disponen a la vez de una tableta y de un teléfono inteligente, disponiendo el teléfono inteligente de una aplicación «bancaria», por ejemplo instalada en un entorno seguro, mientras que la tableta es utilizada de manera más general y más libre por varias personas del hogar, sin que esta tableta contenga datos confidenciales.
Un caso general de utilización es el siguiente:
- mediante una aplicación «comercial» instalada en el terminal de comunicación (aplicación específica para un comerciante o aplicación genérica del tipo de «navegador»), el usuario desea realizar la compra de un producto o servicio;
- al validar el pedido, el usuario debe proporcionar datos que permitan el pago (nombre, número, fecha, CVV):
estos datos son introducidos, por ejemplo, por el propio usuario (en los campos de entrada previstos para este fin) o incluso «automáticamente» mediante una aplicación de pago (por ejemplo, Google Pay™, Samsung Pay™, Apple Pay ™, alojando estas aplicaciones de manera segura los datos de pago proporcionados por el usuario) o incluso una aplicación bancaria;
- un módulo de aplicación específico, integrado o separado de la posible aplicación de pago utilizada, detecta la necesidad de pago y requiere que el usuario coloque su medio de pago (sin contacto) cerca de la interfaz sin contacto correspondiente del terminal de comunicación (situada por regla general en la parte posterior del terminal de comunicación);
- el procedimiento para hacer segura la presente técnica se implementa por consiguiente, basándose en un diálogo (que se describe a continuación) entre el medio de pago (MP) y el terminal de comunicación (ComT), y un servidor de transacciones (SrvT): una primera etapa de este procedimiento da como resultado la obtención de un dato concreto proporcionado por el medio de pago, denominándose ese dato código de certificación; el código de certificación, obtenido del medio de pago del usuario, se utiliza, en una segunda etapa del procedimiento, para certificar que la transacción es realizada por el usuario con el medio de pago «en mano», y no solo con los datos del medio de pago (por ejemplo, los datos introducidos en la tarjeta de pago).
Este procedimiento de seguridad descrito en relación con la figura 1 comprende:
- una etapa de envío (10), al medio de pago cuyos datos se utilizan para la transacción, de una solicitud para obtener un código de certificación (ReqCCert);
- una etapa de recepción (20), desde dicho medio de pago, de dicho código de certificación (CCert);
- una etapa de introducción (30) de dicho código de certificación (CCert), dentro de una estructura de datos de transacción (SDTr):
- una etapa de transmisión (40) de la estructura de datos de transacción (SDTr) a dicho servidor;
- y, cuando el código de certificación recibido por dicho servidor es válido, una etapa de recepción (50) de un dato representativo de la validación (VaIT) de la transacción por parte de dicho servidor.
Los datos utilizados para la transacción comprenden, por consiguiente, además de los datos habituales (nombre, número, fecha de validez), un dato adicional (código de certificación) directamente enviado desde el propio medio de pago. Estos datos se transmiten, a través de las interfaces habituales, al servidor (SrvT) encargado de procesar la transacción. El tratamiento de la transacción comprende una fase complementaria que consiste en verificar que el código de certificación recibido se ajusta al código de certificación esperado. Por lo tanto, esta verificación es llevada a cabo por un servidor que tiene los datos criptográficos necesarios para la verificación de la firma. Por consiguiente, es, por regla general, el servidor del banco el que proporciona los datos utilizados por el medio de pago (por lo tanto, más bien el servidor bancario del usuario). Sin embargo, el proveedor de servicios de pago (el banco) puede delegar en terceros de confianza estas operaciones de validación de las transacciones y, por lo tanto, puede autorizar a otro servidor (otra entidad) a realizar estas operaciones en su nombre.
Según un ejemplo concreto que no forma parte de la presente invención, la creación del código de certificación se implementa mediante el medio de pago explicado en relación con la figura 2. El medio de pago recibe (X10), desde el terminal de comunicación, una solicitud de establecimiento de un código de certificación La transmisión de esta solicitud sigue a un primer intercambio (X00) (protocolo de enlace) entre el terminal de comunicación y el medio de pago, durante el cual se pueden intercambiar los parámetros de seguridad de la transacción (ParSec). Al recibir la solicitud para establecer un código de certificación, el medio de pago utiliza uno o varios datos del medio de pago (PayDat) para generar (X20) un código de certificación, que se protege mediante la utilización de un secreto mantenido al menos un mes (o incluso como máximo) por el propio medio de pago. El código de certificación se transmite entonces al terminal de comunicación para que pueda añadirlo a los datos transmitidos al servidor (a través de una red de comunicación) a la que está conectado el terminal de comunicación. Por lo tanto, el establecimiento del código de certificación se lleva a cabo según al menos un dato del medio de pago.
Según este ejemplo concreto, el código de certificación puede ser generado, mediante el propio medio de pago, de varias maneras diferentes. Por ejemplo, el medio de pago puede generar una firma digital de los datos de pago (nombre, número, fecha, CVV) y transmitir esta firma al terminal de comunicación. Los datos se firman, por ejemplo, con una clave privada de la tarjeta. Los datos (nombre N1, número N2, fecha D, criptograma C) se concatenan, por ejemplo, (N1 | N2 | D | C) para formar una cadena de caracteres CC, en la que se aplica una operación criptográfica, utilizando la clave privada (KPriv) del medio de pago. Esta clave privada (KPriv) solo la conserva el medio de pago.
En la realización de la invención, el código de certificación no es el único dato que permite validar la transacción. En esta realización, los datos que validan o no la transacción son un identificador codificado del terminal de comunicación del usuario, un identificador que es «codificado» por el medio de pago, para producir un código de certificación para el terminal de comunicación. El código de certificación del terminal de comunicación desde el que se realiza la transacción se obtiene de este modo de una operación realizada por el medio de pago (tarjeta de pago sin contacto). El código de certificación del terminal de comunicación se convierte en la información utilizada para emitir la autorización de transacción (es decir, para validar que se puede llevar a cabo una transacción). Esta realización presenta varias ventajas. En primer lugar, esta realización permite evitar los problemas de recuperar el importe de la transacción (un importe que no está necesariamente disponible a nivel del propio terminal). En segundo lugar, dicha implementación permite al servidor (bancario), al recibir el código de certificación del terminal de comunicación, descifrar este último utilizando la clave pública del medio de pago, y verificar que el identificador del terminal de comunicación corresponde a un identificador «autorizado» por el servidor (bancario o de transacción), lo que permite añadir un nivel adicional de seguridad. En general, el terminal de comunicación puede configurar el código de certificación (y, por lo tanto, utilizar un parámetro de certificación que transmite al medio de pago), para hacer que el medio de pago sea único (es decir, no se pueda utilizar por segunda vez). Más concretamente, entre los parámetros de certificación que permiten conferir unicidad al código de certificación, cabe mencionar:
- un parámetro de una función para crear dicho código de certificación: este parámetro permite determinar, por ejemplo, el orden de concatenación de los datos bancarios, o bien este parámetro puede proporcionar una función para asociar datos bancarios;
- un valor representativo de un identificador de un comerciante: este valor lo puede proporcionar el comerciante o el editor de la aplicación en la que se inicia el pago;
- un valor representativo de un identificador de terminal de comunicación: como se ha explicado anteriormente, este valor puede ser, por ejemplo, representativo de un identificador de tarjeta SIM o USIM;
- un valor representativo de la transacción, tal como el importe de esta transacción;
- un valor representativo de una fecha y/o una hora de la transacción.
- un valor aleatorio, que permite crear el código de certificación según un parámetro proporcionado por el propio terminal de comunicación o por el servidor de transacciones; en este último caso, el servidor de transacciones transmite el número aleatorio al terminal de comunicación para permitir la comparación posterior del código de certificación y evitar la reproducción.
- una combinación de los parámetros mencionados anteriormente, según las realizaciones.
Por lo tanto, el establecimiento del código de certificación se lleva a cabo en función de al menos un dato del medio de pago y/o de un dato del terminal de comunicación. Este o estos parámetros se pueden generar con un intercambio adicional con el servidor de transacciones para que este último pueda tener los parámetros utilizados para generar el código de certificación y, en consecuencia, para verificarlo. De nuevo, ventajosamente, el o los parámetros son la totalidad o una parte del resultado de un intercambio previo (apretón de manos) que tiene lugar entre el terminal de comunicación y el servidor de transacciones. Este protocolo de enlace permite determinar los procedimientos de intercambio entre el terminal de comunicación y el servidor. Proporciona datos seguros (tales como las claves de sesión, por ejemplo). A partir de estas claves de sesión, se pueden obtener algunos de los parámetros anteriores (valor aleatorio, función de creación de códigos de certificación, etc.). La ventaja es garantizar que el código de certificación no pueda ser reproducido para otra transacción.
El código de certificación, creado por el medio de pago utilizado para llevar a cabo la transacción (tarjeta de pago, segundo terminal de comunicación), es introducido por el terminal de comunicación en una estructura de datos de transacción. La introducción va precedida de una etapa de selección, entre una pluralidad de campos disponibles, de un campo existente específico. Según otra característica, el campo específico en el que se introduce el código de certificación es el campo dedicado a recibir el código de verificación visual (CVV). Por lo tanto, en lugar de exigir al usuario que introduzca este código (introducción que puede ser un problema, especialmente en ciertos sitios que tienen poco en cuenta la seguridad de los datos), este campo se utiliza para introducir el código de certificación. En otras realizaciones, el código de certificación se transmite al mismo tiempo que el «token» que representa la identificación de los datos bancarios del usuario que realiza el pago. Para que conste, la «tokenización» consiste en reemplazar un dato por otro sin que exista ninguna relación entre ambos. El «token» (o token) se utiliza en lugar de datos confidenciales (por ejemplo, el número (PAN) de la tarjeta bancaria), por lo que es este token el que está expuesto a las amenazas y no los datos confidenciales (por lo tanto, no el PAN). Al mismo tiempo, se configura una base de datos para almacenar la correspondencia entre los datos y sus correspondientes tokens, una base que se denomina «base de tokenización». En el caso del uso de un «token», este se registra en el terminal de comunicación, por ejemplo, utilizando los mecanismos descritos en la siguiente realización.
A continuación se presenta una implementación del principio descrito anteriormente. Esta implementación no es en modo alguno limitativa y es posible cualquier otra implementación que comprenda las mismas características que las descritas. Es obvio que todas las características y realizaciones descritas en el presente documento pueden ser combinadas sin que sea necesario describir todas las combinaciones posibles.
5.2. Descripción de una realización
En esta realización, un código de certificación obtenido se utiliza durante el pago utilizando el terminal de comunicación desde el que se lleva a cabo la transacción, siendo producido este código por la tarjeta de pago sin contacto del usuario. Para producir este código de certificación, se invita al usuario a colocar (acercarse) a su tarjeta de pago sin contacto en la parte posterior de su terminal de comunicación.
Por su parte, el terminal de comunicación comprende un elemento de seguridad (SE, «Secure Element», en inglés) y/o un entorno de ejecución seguro (TEE, «Trusted Execution Environment», en inglés) que incluye una aplicación específica (del tipo «Contactless Registry Event Listener» -CREL , en inglés, o su equivalente según el entorno). Por lo tanto, en esta realización, se considera que el terminal de comunicación aloja, al menos a través del elemento seguro (SE) (o un TEE y/o USIM, SIM, UICC), al menos una aplicación de «bajo nivel» encargada de gestionar los datos de pago (activación/desactivación de las tarjetas de pago). El elemento seguro tiene una interfaz de comunicación con un controlador de comunicación sin contacto, que está conectado con la antena sin contacto del terminal de comunicación. En esta realización, se implementa una aplicación de consulta (APPINT) dentro del elemento seguro. Esta aplicación de consulta es llamada por una aplicación de pago de sistema operativo abierto (Android™, iOS™, etc.). La Aplicación de pago gestiona el tratamiento, desde la aplicación de bajo nivel, de los datos necesarios para la implementación de un pago (por ejemplo, la introducción de los datos «nombre», «número», «fecha», «ccv» en los campos previstos para este fin). En paralelo o sucesivamente, la aplicación de pago exige, de la aplicación de consulta, la obtención de un código de certificación. Para solicitar este código, la aplicación de consulta puede tener parámetros predefinidos o recibir parámetros mediante la aplicación de pago.
Tras la notificación de la aplicación de pago, el usuario coloca la tarjeta de pago sin contacto cerca de la antena sin contacto. La aplicación de consulta requiere que el código de certificación se obtenga transmitiendo un comando apropiado a la tarjeta de pago, que realiza la operación solicitada, según los parámetros que se transfieren en la solicitud para obtener el código de certificación. En esta realización, se utilizan dos parámetros: un valor que representa el identificador del terminal y un valor representativo de la hora de la transacción. Por ejemplo, estos dos valores representativos se concatenan y se transmiten a la tarjeta de pago en la solicitud para obtener el código de certificación. Los valores representativos pueden ser, por ejemplo, un hash del valor original, una contracción de este valor original o una extracción de una parte del mismo. También puede ser el valor original como tal. Esto se determina en función del tamaño de los datos disponibles para la configuración en la solicitud de obtención del código de certificación.
La tarjeta de pago calcula, a continuación, el código de certificación, según los parámetros transmitidos, y devuelve este código de certificación al terminal de comunicación. Más concretamente, el controlador de comunicación sin contacto recibe y transmite, por ejemplo a través de una interfaz HCl(«interfaz de controlador principal» «Host Controller Interface», en inglés),el código de certificación a la aplicación de consulta que, dependiendo de las implementaciones operativas, transmite ella misma este código de certificación a la aplicación de pago (o a la aplicación del comerciante). A continuación, el código de certificación es introducido en la estructura de datos de la transacción, que se transmite a través de la red de comunicación al servidor, o bien se introduce en una respuesta de tipo «http» (por ejemplo, a través de servicios AJAX seguros), que se envía al servidor (en línea) del comerciante o al servidor bancario del comerciante (del comerciante).
Tal como ya se ha indicado anteriormente, el terminal desde el que se realiza la transacción no es un terminal de pago (en el sentido de un terminal en el que se introduce la tarjeta bancaria y en el que se introduce un código PIN). Es un terminal tal como una tableta o un teléfono inteligente y no un terminal de pago como los instalados en los comercios.
Por lo tanto, en esta realización, el procedimiento implementado comprende, a nivel del terminal de comunicación:
- una etapa de envío, al medio de pago cuyos datos se utilizan para la transacción, de una solicitud para obtener un código de certificación;
- una etapa de recepción, desde dicho medio de pago, de dicho código de certificación;
- una etapa de introducción de dicho código de certificación, dentro de una estructura de datos de transacción;
- una etapa de transmisión de la estructura de datos de transacción a dicho servidor; y
- y cuando el código de certificación recibido por dicho servidor es válido, una etapa de recepción de un dato representativo de la validación de la transacción por parte de dicho servidor.
Cuando el código de certificación corresponde a al menos un código de certificación esperado, una etapa de entrega de un dato representativo de una validación de transacción a una entidad.
El dato representativo de la validación de una transacción puede ser proporcionado a continuación para validar la transacción bancaria (esta validación de una transacción bancaria se lleva a cabo al mismo tiempo que los demás parámetros y valores que entran en el procedimiento de validación, por supuesto) a otra entidad (tal como, por ejemplo, un servidor bancario, cuando la propia transacción es procesada por un servidor de transacciones).
Por lo tanto, el procedimiento permite comparar el código de certificación producido por el medio de pago (la tarjeta de pago NFC) con un código de certificación esperado. El formato del código de identificación esperado del código de certificación puede ser definido por el banco del usuario, de manera automática o estática. Para una definición estática, los tipos y la naturaleza de los parámetros se determinan de antemano durante la codificación de la aplicación de consulta de bajo nivel (por ejemplo). Para una definición dinámica, estos parámetros se intercambian entre el terminal de comunicación del usuario y el servidor apropiado (servidor de transacciones o servidor bancario).
5.3. Servidor de transacciones
En al menos una realización, el procedimiento descrito se implementa por medio de un servidor de transacciones, presentado en relación con la figura 3. Dicho servidor puede, a elección, ser implementado por una organización bancaria, un proveedor de servicios de pago o un proveedor de servicios que actúe como intermediario entre una o varias establecimientos bancarios o establecimientos de pago.
Dicho servidor de gestión comprende una memoria 31, una unidad de tratamiento 32 equipada, por ejemplo, con un microprocesador, y controlada por el programa informático 33, que implementa el procedimiento según la invención. En al menos una realización, la invención se implementa en forma de un servidor bancario, de un sistema de pago. Un servidor de este tipo comprende:
- medios para recibir una solicitud de transacción, que proviene al menos parcialmente del terminal de comunicación, que comprende al menos un identificador de datos de pago (token) y/o los propios datos bancarios, todos acompañados de un código de certificación; estos medios pueden adoptar la forma de una interfaz de conexión (I) a una o varias redes de comunicación. Pueden ser interfaces de software o interfaces de hardware (tales como tarjetas de red o módulos de hardware de comunicación de red).
- medios de obtención de un dato de verificación de código de certificación para el medio de pago utilizado para la transacción; estos medios pueden adoptar la forma de una interfaz de conexión (I) a una o varias redes de comunicación. Pueden ser interfaces de software o interfaces de hardware (tales como tarjetas de red o módulos de hardware de comunicación de red); también pueden adoptar la forma de una base de datos de tokenización, cuando esta técnica se utiliza para realizar pagos.
- medios de determinación de un código de certificación actual asociado a los datos recibidos en la solicitud de transacción: por ejemplo, se trata de un medio para calcular un código de certificación actual a partir de los datos recibidos: en caso de recibir un token, se trata de recuperar los datos bancarios asociados a este token y, basándose en estos y en los parámetros conocidos de calcular el código de certificación;
- medios de comparación de los códigos de certificación entre sí, según los datos bancarios conocidos por el usuario;
- medios de proporcionar una autorización de transacción a una entidad (servidor bancario, por ejemplo) cuando dicha comparación es positiva. Estos medios pueden adoptar la forma de una interfaz para conectarse a una o varias redes de comunicación. Pueden ser interfaces de software o interfaces de hardware (tales como tarjetas de red o módulos de hardware de comunicación de red).
En al menos una realización, dicho servidor también comprende medios para obtener al menos una información de un terminal de comunicación que se supone que está en posesión del usuario cuya transacción se desea validar. En esta realización, este servidor puede, por ejemplo, transmitir una solicitud para obtener esta información, al terminal de comunicación. Para ello, puede utilizar varias técnicas, siendo la primera, por ejemplo, la transmisión de un mensaje de tipo SMS a una aplicación instalada en el terminal (véase Aplicación y Terminal de comunicación), para validar la transacción con respecto a un identificador de terminal de comunicación conocido y autorizado.
Cuando es posible, el código de certificación es el resultado de un cálculo realizado con la clave privada del medio de pago (por ejemplo, la clave privada de la tarjeta sin contacto) y los datos de este código de certificación cifrado se descifran utilizando la clave pública de la tarjeta, en posesión del servidor bancario y/o del servidor de transacciones que utiliza la presente técnica. Por lo tanto, cuando el servidor descifra el código de certificación recibido desde el terminal móvil, está en condiciones de verificar que los datos obtenidos mediante este descifrado corresponden realmente a los datos esperados.
5.4. Dispositivo para la puesta en práctica de la invención
En relación con la figura 4, se presenta una arquitectura simplificada de un dispositivo móvil capaz de transmitir su posición. Dicho servidor de gestión comprende una memoria 41, una unidad de tratamiento 42 equipada, por ejemplo, con un microprocesador, y controlada por el programa informático 43, que implementa el procedimiento según la invención. En al menos una realización, la invención se implementa en forma de una aplicación móvil instalada en un dispositivo móvil en posesión del usuario. Un dispositivo móvil de este tipo comprende:
- medios de envío hacia el medio de pago cuyos datos se utilizan para la transacción, de una solicitud para obtener un código de certificación;
- medios de recepción, desde dicho medio de pago, de dicho código de certificación;
- medios de introducción de dicho código de certificación, dentro de una estructura de datos de transacción;
- medios de transmisión de la estructura de datos de transacción a dicho servidor; y
- medios de recepción de un dato representativo de la validación de la transacción por parte de dicho servidor.
Estos medios adoptan la forma de una aplicación de software específica, o incluso de componentes de hardware dedicados, tal como un elemento de seguridad (SE) o un entorno de ejecución seguro. El elemento de seguridad puede tener la forma de una tarjeta Sim, USim, UICC o incluso un componente de seguridad específico, injertado en la placa base del terminal de comunicación. Más concretamente, en al menos una realización, estos medios adoptan la forma de varios componentes de hardware a los que se añaden varios componentes de software. Más concretamente, los medios para transmitir la solicitud para obtener el código de certificación están incluidos en un componente seguro que incluye un acceso más o menos directo a un controlador de emisión/recepción de campo electromagnético cercano de tipo NFC, lo que permite consultar directamente un medio de pago compatible con NFC. Este componente seguro es responsable de determinar, al menos parcialmente, un parámetro para calcular el código de certificación. Los otros componentes del terminal de comunicación se han descrito en relación con la realización propuesta.

Claims (7)

REIVINDICACIONES
1. Procedimiento de tratamiento de una transacción desde un terminal de comunicación (ComT), solicitando desde un servidor (SrvT), a través de una red de comunicación, la implementación de una transacción de pago que implica la utilización de datos de pago en modo tarjeta no presente, estando dichos datos de pago relacionados con una tarjeta de pago del tipo de «comunicación de campo cercano» o NFC, procedimiento implementado en el terminal de comunicación, comprendiendo el procedimiento:
- una etapa de determinación de un valor del parámetro de certificación, estando vinculado dicho parámetro de certificación a dicha transacción;
- una etapa de introducción del valor del parámetro de certificación en una solicitud para obtener un código de certificación (ReqCCert);
- una etapa de envío (10), mediante una comunicación de tipo NFC, a dicha tarjeta de pago, de la solicitud para obtener un código de certificación (ReqCCert);
- una etapa de recepción (20), a través de dicha comunicación de tipo NFC, desde dicha tarjeta de pago, de dicho código de certificación (CCert), que es generado por dicha tarjeta de pago y se establece según dicho parámetro de certificación, y al menos un dato de dicho terminal de comunicación, siendo creado dicho código de certificación exclusivamente para la transacción en curso;
- una etapa de introducción (30) de dicho código de certificación (CCert), dentro de una estructura de datos de transacciones (SDTr), comprendiendo dicha etapa de introducción (30) una etapa de selección, de entre una pluralidad de campos disponibles, un campo específico existente, dentro del cual se introduce dicho código de certificación (CCert), dentro del cual se introduce dicho código de certificación (CCert), siendo dicho campo específico el campo dedicado a recibir el código de verificación visual (CVV);
- una etapa de transmisión (40) de la estructura de datos de transacciones (SDTr) a dicho servidor;
- y cuando el código de certificación recibido por dicho servidor corresponde al menos a un código de certificación esperado, una etapa de recepción (50) de un dato representativo de la validación (VaIT) de la transacción por parte de dicho servidor.
2. Procedimiento de tratamiento de una transacción, según la reivindicación 1,caracterizado por que,el parámetro de certificación pertenece al grupo que comprende:
- un parámetro de una función de creación de dicho código de certificación;
- un valor representativo de un identificador de un comerciante;
- un valor representativo de un identificador de terminal de comunicación;
- un valor representativo de la transacción;
- un valor representativo de una fecha y/o una hora de la transacción.
3. Procedimiento de tratamiento de una transacción, según la reivindicación 1, caracterizado por que el parámetro de certificación comprende un dato representativo de un identificador de dicho terminal de comunicación y un dato representativo de una hora de la transacción.
4. Procedimiento de tratamiento de una transacción, según la reivindicación 1, caracterizado por que el código de certificación (CCert) es representativo de una operación de cifrado realizada por dicha tarjeta de pago, realizándose dicha operación de cifrado mediante una comunicación de tipo NFC entre dicho terminal de comunicación de usuario y dicha tarjeta de pago.
5. Servidor de tratamiento de una transacción de pago, que adopta la forma de un dispositivo electrónico conectado a una red de comunicación, comprendiendo dicho servidor:
- medios de recepción, procedentes de un terminal de comunicación, según la reivindicación 6;
- medios de recepción de una solicitud de transacción, que comprende al menos un dato que representa un pago en modo de tarjeta no presente que se realizará desde dicho terminal de comunicación y un código de certificación, estando dicho al menos un dato relacionado con una tarjeta de pago de NFC o «comunicación de campo cercano», y dicho código de certificación generado por dicha tarjeta de pago y establecido en función de un parámetro de certificación y al menos un dato de dicho terminal de comunicación, e introducido en dicha solicitud de transacción en el campo dedicado a recibir el código de verificación visual (CVV), creándose dicho código de certificación exclusivamente para la transacción en curso;
- medios para obtener un dato de verificación del código de certificación de la tarjeta de pago utilizada para la transacción;
- medios para determinar un código de certificación actual asociado a los datos recibidos en la solicitud de transacción;
- medios para comparar los códigos de certificación entre sí;
- medios para proporcionar una autorización de transacción a una entidad (servidor bancario, por ejemplo) cuando dicha comparación es positiva.
6. Terminal de comunicación que comprende medios de tratamiento de transacciones y medios para solicitar a un servidor (SrvT), a través de una red de comunicación, la ejecución de una transacción de pago, implicando la utilización de datos de pago en el modo de tarjeta no presente, siendo dichos datos relativos a una tarjeta de pago del tipo «comunicación de campo cercano» o NFC, comprendiendo el terminal de comunicación:
- medios de determinación de un valor de parámetro de certificación, estando vinculado dicho parámetro de certificación a dicha transacción;
- medios de introducción del valor del parámetro de certificación en una solicitud para obtener un código de certificación (ReqCCert);
- medios de envío (10), mediante una comunicación de tipo NFC, a dicha tarjeta de pago, de la solicitud para obtener un código de certificación (ReqCCert);
- medios de recepción (20), a través de dicha comunicación de tipo NFC, desde dicha tarjeta de pago, de dicho código de certificación (CCert), que es generado por dicha tarjeta de pago y se establece según dicho parámetro de certificación, y al menos un dato de dicho terminal de comunicación, siendo creado dicho código de certificación exclusivamente para la transacción en curso;
- medios de introducción (30) de dicho código de certificación (CCert), dentro de una estructura de datos de transacciones (SDT r), insertándose el código de certificación en el campo dedicado a recibir el código de verificación visual (CVV);
- medios de transmisión (40) de la estructura de datos de transacciones (SDTr) a dicho servidor;
- y medios de recepción (50) de un dato representativo de la validación (VaIT) de la transacción por parte de dicho servidor.
7. Producto de programa informático que puede ser cargado desde una red de comunicación y/o almacenado en un medio legible por ordenador y/o ejecutado mediante un microprocesador, caracterizado por que incluye instrucciones de código de programa para ejecutar un procedimiento para determinar la validez de un código de aplicación según una cualquiera de las reivindicaciones 1 a 4, cuando se ejecuta en un ordenador.
ES19172647T 2018-05-18 2019-05-03 Procedimiento para llevar a cabo una transacción, terminal, servidor y programa informático correspondiente Active ES2971660T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1854204A FR3081246B1 (fr) 2018-05-18 2018-05-18 Procede de realisation d'une transaction, terminal, serveur et programme d'ordinateur correspondant

Publications (1)

Publication Number Publication Date
ES2971660T3 true ES2971660T3 (es) 2024-06-06

Family

ID=63036128

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19172647T Active ES2971660T3 (es) 2018-05-18 2019-05-03 Procedimiento para llevar a cabo una transacción, terminal, servidor y programa informático correspondiente

Country Status (5)

Country Link
US (1) US11620646B2 (es)
EP (1) EP3570238B1 (es)
CA (1) CA3042663A1 (es)
ES (1) ES2971660T3 (es)
FR (1) FR3081246B1 (es)

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7292999B2 (en) * 2001-03-15 2007-11-06 American Express Travel Related Services Company, Inc. Online card present transaction
US7020640B2 (en) * 2002-03-21 2006-03-28 Banana.Ch S.A. Method for certifying data containing a sequence of transactions
US7128274B2 (en) * 2005-03-24 2006-10-31 International Business Machines Corporation Secure credit card with near field communications
CN102257540A (zh) * 2008-12-19 2011-11-23 Nxp股份有限公司 增强智能卡使用
KR101327434B1 (ko) 2010-10-20 2013-11-20 비씨카드(주) 고객 단말기의 맥 어드레스 정보를 이용한 결제 방법 및 시스템
EP4131113A1 (en) * 2012-02-29 2023-02-08 Apple Inc. Method, device and secure element for conducting a secured financial transaction on a device
WO2014076584A2 (en) * 2012-11-14 2014-05-22 Savolainen Risto K System and method for secure mobile contactless payment
GB2508015A (en) * 2012-11-19 2014-05-21 Mastercard International Inc Method and apparatus for secure card transactions
US10592890B2 (en) * 2014-09-03 2020-03-17 Intel Corporation Methods and arrangements to complete online transactions
FR3020165B1 (fr) * 2014-04-18 2021-03-05 Compagnie Ind Et Financiere Dingenierie Ingenico Procede de traitement de donnees transactionnelles, dispositif et programme correspondant
US20150339659A1 (en) * 2014-05-23 2015-11-26 Miguel Ballesteros System And Method For Payment Credential-Based Mobile Commerce
EP3251067A4 (en) * 2015-01-27 2018-08-01 Ent. Services Development Corporation LP Virtual point of sale
TWI632514B (zh) * 2015-04-08 2018-08-11 財團法人工業技術研究院 數位交易方法、使用者裝置、服務提供端裝置與數位交易管理伺服系統
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
TWI652633B (zh) * 2018-03-02 2019-03-01 光陽工業股份有限公司 以車輛之儀表裝置進行電子付費之付費方法及系統
US10664830B1 (en) * 2018-12-18 2020-05-26 Capital One Services, Llc Devices and methods for selective contactless communication

Also Published As

Publication number Publication date
US20190354973A1 (en) 2019-11-21
EP3570238A1 (fr) 2019-11-20
US11620646B2 (en) 2023-04-04
CA3042663A1 (en) 2019-11-18
FR3081246B1 (fr) 2020-11-06
FR3081246A1 (fr) 2019-11-22
EP3570238B1 (fr) 2023-11-29

Similar Documents

Publication Publication Date Title
US11783061B2 (en) Embedding cloud-based functionalities in a communication device
US11240219B2 (en) Hybrid integration of software development kit with secure execution environment
ES2732564T3 (es) Sistema y procedimientos de aprovisionamiento de datos cifrados de servidor remoto
CN107925572B (zh) 软件应用程序到通信装置的安全绑定
US9922322B2 (en) Cloud-based transactions with magnetic secure transmission
KR102293822B1 (ko) 클라우드-기반 트랜잭션 방법 및 시스템
AU2015264124B2 (en) Offline authentication
JP6704919B2 (ja) 支払いトークンのセキュリティを確保する方法
US10158491B2 (en) Qualified electronic signature system, method and mobile processing terminal for qualified electronic signature
ES2951585T3 (es) Autenticación de transacciones usando un identificador de dispositivo móvil
JP2022508010A (ja) 非接触カードの暗号化認証のためのシステムおよび方法
ES2877522T3 (es) Método y sistema para mejorar la seguridad de una transacción
JP2016528613A (ja) オンライン取引の検証ステップを安全にするための方法
WO2016041235A1 (zh) 电子现金数据的授权处理方法、支付处理方法及虚拟卡
Crowe et al. Mobile Phone Technology:“Smarter” Than We Thought
US11880840B2 (en) Method for carrying out a transaction, corresponding terminal, server and computer program
Alliance Host card emulation (hce) 101
ES2971660T3 (es) Procedimiento para llevar a cabo una transacción, terminal, servidor y programa informático correspondiente
WO2018156382A1 (en) Security architecture for device applications
ES2865380T3 (es) Método de realización de una transacción, terminal y programa informático correspondiente
KR20230130039A (ko) 공개/개인 키 인증을 위한 디바이스들, 시스템들 및방법들
RU2736507C1 (ru) Способ и система создания и использования доверенного цифрового образа документа и цифровой образ документа, созданный данным способом