ES2894899T3 - Procedimiento de refuerzo de la seguridad de procesamiento de datos de transacciones, terminal y programa de ordenador correspondiente - Google Patents

Procedimiento de refuerzo de la seguridad de procesamiento de datos de transacciones, terminal y programa de ordenador correspondiente Download PDF

Info

Publication number
ES2894899T3
ES2894899T3 ES16195082T ES16195082T ES2894899T3 ES 2894899 T3 ES2894899 T3 ES 2894899T3 ES 16195082 T ES16195082 T ES 16195082T ES 16195082 T ES16195082 T ES 16195082T ES 2894899 T3 ES2894899 T3 ES 2894899T3
Authority
ES
Spain
Prior art keywords
data
payment
communication terminal
processing
cac
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
ES16195082T
Other languages
English (en)
Inventor
Hiba Koudoussi
Rémi Geraud
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.)
Worldline MS France
Original Assignee
Ingenico Group SA
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 Ingenico Group SA filed Critical Ingenico Group SA
Application granted granted Critical
Publication of ES2894899T3 publication Critical patent/ES2894899T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/34User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327Short range or proximity payments by means of M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327Short range or proximity payments by means of M-devices
    • G06Q20/3278RFID or NFC payments by means of M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/401Transaction verification
    • G06Q20/4014Identity check for transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/401Transaction verification
    • G06Q20/4018Transaction verification using the card verification value [CVV] associated with the card
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00Business processing using cryptography
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

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

Abstract

Procedimiento de refuerzo de la seguridad de procesamiento de datos de transacciones, procedimiento puesto en práctica en el seno de un terminal de comunicación (TC) que comprende un módulo de procesamiento de datos de transacciones (ModT), comprendiendo dicho procedimiento: - una etapa de detección (100), por parte del módulo de procesamiento (ModT), de una presentación de al menos una zona de introducción (ZoS) relativa a un dato de medio de pago; - una etapa de activación (110), por parte del módulo de procesamiento (ModT), de un módulo de lectura de datos sin contacto (ModSC); - una etapa de obtención (120), por parte del módulo de lectura de datos sin contacto (ModSC), de al menos un dato de medio de pago con origen en un medio de pago; estando caracterizado dicho procedimiento por comprender: - una etapa de generación (125), por parte del módulo de procesamiento (ModT), de un código de autenticación actual (CAC), comprendiendo dicha etapa de generación una etapa de cálculo de una función de apareamiento bilineal simétrico en función de un dato de identificación (IdTerm) del terminal de comunicación y de un dato de autenticación (AuthU) de un usuario al que está asociado dicho terminal de comunicación, que suministra el código de autenticación actual (CAC); - una etapa de provisión (130), a dicha al menos una zona de introducción (ZoS), de al menos un dato de medio de pago obtenido anteriormente y de dicho código de autenticación actual (CAC) generado.

Description

DESCRIPCIÓN
Procedimiento de refuerzo de la seguridad de procesamiento de datos de transacciones, terminal y programa de ordenador correspondiente
1. Campo
La invención se refiere al campo del procesamiento de transacciones. Más en particular, la técnica que se propone se refiere al campo del procesamiento de datos de transacciones de pago, debiéndose hacer seguros estos datos de transacciones de pago. De este modo, es un objeto de la presente técnica aportar un refuerzo de la seguridad en los intercambios de datos cuando se realiza una transacción. Todavía más concretamente, es un objeto de la presente técnica aumentar el nivel de seguridad de una transmisión de datos en el ámbito de un pago realizado con un terminal móvil inteligente (por ejemplo, un teléfono inteligente o una tableta) y una tarjeta de pago.
2. Técnica anterior
El documento US 2011/225090 A1 da a conocer un sistema y un procedimiento correspondiente para hacer más seguras y prácticas las compras en línea. Un módulo del lado del cliente puede leer la información de una tarjeta bancaria sin contacto y rellenar automáticamente los campos correspondientes en un formulario de pedido en línea. Para una mayor seguridad, se genera un código de autenticación actual dinámico en lugar del código estático CVV habitual. Dicha generación puede tomar en cuenta, entre otros, un identificador del terminal de comunicación.
La utilización de terminales móviles inteligentes (como, por ejemplo, teléfonos inteligentes -smartphone- o tabletas) no deja de progresar. Esta progresión queda asimismo ilustrada cuando se trata de realizar un pago, por ejemplo, en un sitio Internet de un comerciante. Así, el número de transacciones realizadas en un terminal móvil inteligente va aumentando día a día. Se pone de manifiesto que este número podría aumentar de manera aún más notable. Más específicamente, tradicionalmente se distinguen dos tipos de manera de realizar un pago en estos tipos de terminales.
El primero consiste en realizar un pago directamente en una aplicación específica para un comerciante dado. Por ejemplo, el comerciante dispone de una aplicación de comercio electrónico, que está instalada en el terminal del usuario. El mismo puede efectuar una compra seleccionando uno o varios bienes o servicios y efectuando un abono con tarjeta bancaria (introduciendo o seleccionando datos previamente introducidos en los campos de pago previstos al efecto).
Consiste el segundo tipo en acudir, con el concurso de un navegador (soporte lógico que permite realizar una navegación por un sitio Internet) a un sitio Internet del comerciante. El sitio Internet comprende, por ejemplo, una interfaz específica para los terminales móviles, con el fin de facilitar la navegación por pantallas de tamaño reducido. El usuario, cuando ha terminado la selección de sus bienes o servicios, realiza el pago. Esto implica en muchos casos la introducción, en el seno de la interfaz de pago, de los datos de tarjeta bancaria (nombre, número, fecha de caducidad y código de verificación (CVV)). Ahora bien, tal introducción, en el seno de una interfaz no dedicada específicamente para ello, puede ser problemática. En efecto, el tamaño combinado del pequeño tamaño de los caracteres presentados y de la ocultación, por el teclado virtual (teclado presentado en la pantalla del terminal), de aproximadamente una mitad de la superficie presentada en la pantalla, hace complicada para el usuario la introducción de los datos de tarjeta bancaria. Esto redunda en un reducido índice de conversión (índice de transformación del pedido en una verdadera compra).
Para facilitar el acto de compra, se utilizan dos soluciones: la primera solución consiste en registrar, en el seno de un servidor remoto, datos de tarjetas bancarias en una primera compra (esto se llama, en inglés, fase de “enrolment”). En esta primera solución, las operaciones llevadas a cabo consisten especialmente en asociar, con la cuenta de usuario existente, unos datos de tarjeta bancaria del usuario. De este modo, en su siguiente compra, el usuario estará en condiciones de seleccionar directamente estos datos ya introducidos para poder abonar sus compras. Esta solución es interesante, pero presenta la enorme desventaja de tener que proceder al registro de estos datos para cada comerciante: cada comerciante utiliza su propia base de datos y su propia arquitectura de gestión de cuentas de cliente. De este modo, el usuario debe introducir de todas maneras sus datos de tarjeta bancaria a partir del momento en que desee abonar una compra en línea, en un sitio web o en una aplicación que no ha utilizado con anterioridad.
La segunda solución consiste en utilizar las propiedades de ciertos navegadores: estos memorizan por sí mismos las entradas efectuadas por el usuario. Puesto que multitud de sitios de Internet utilizan campos de introducción de datos que llevan nombres idénticos, la función de memorización automática del navegador puede ser utilizada para introducir información en estos campos de una manera más rápida. Esta solución puede ser llevada a la práctica fácilmente, pero presenta varios problemas: esta solución está limitada a los sitios web; no todos los sitios web utilizan el mismo nombre para un campo de introducción dado; los sitios web normalmente utilizan, para el pago, una conexión cifrada (https) que no permite una introducción de este tipo.
De este modo, existe una necesidad de una solución simple, económica y rápida de introducción de los datos bancarios relativos a un pago que vaya a efectuarse. Por otro lado, existe una necesidad de una solución que, asimismo, sea segura. En efecto, uno de los problemas que se afrontan se sitúa, asimismo, en el dominio de la autenticación, tanto del usuario como del medio de pago. Es necesario, por tanto, disponer, de manera complementaria, de una solución que sea eficaz en cuanto a refuerzo de la seguridad.
3. Sumario
La presente técnica resuelve al menos algunos de los problemas de la técnica anterior. Más en particular, la técnica que se propone se refiere a un procedimiento de refuerzo de la seguridad de procesamiento de datos, con origen en un medio de pago sin contacto. Tal procedimiento comprende especialmente la adquisición automática de datos con origen en el medio de pago, por una parte y, por otra, el refuerzo de la seguridad en la transmisión y en el procesamiento de estos datos en el seno de una red de comunicación, con el fin de que sean procesados.
Así, la técnica se refiere a un procedimiento de refuerzo de la seguridad de procesamiento de datos de transacciones, procedimiento puesto en práctica en el seno de un terminal de comunicación que comprende un módulo de procesamiento de datos de transacciones. Tal procedimiento comprende:
- una etapa de detección, por parte del módulo de procesamiento, de una presentación de una zona de introducción relativa a un dato de medio de pago;
- una etapa de activación, por parte del módulo de procesamiento, de un módulo de lectura de datos sin contacto;
- una etapa de obtención, por parte del módulo de lectura de datos sin contacto, de al menos un dato de medio de pago con origen en un medio de pago;
- una etapa de provisión, a la zona de introducción, de al menos un dato de medio de pago obtenido anteriormente.
De este modo, la técnica que se propone permite simplificar de manera muy notable la introducción de los datos necesarios para la transacción. En efecto, el usuario se limita a presentar su medio de pago (sin contacto) al terminal de comunicación, con el fin de que el mismo sea leído y de que el módulo de procesamiento valore automáticamente los datos necesarios para el procesamiento.
Dependiendo de las formas de realización y de las necesidades, los datos obtenidos por el módulo de transacciones del terminal de comunicación son, por ejemplo, los apellidos, el nombre, el número de tarjeta bancaria, la fecha de caducidad, el código de verificación visual.
De acuerdo con una característica particular, el procedimiento de refuerzo de la seguridad de procesamiento comprende una etapa de generación, por parte del módulo de procesamiento, de un código de autenticación actual en función de una identificación del terminal de comunicación.
De acuerdo con una característica particular, la etapa de generación del código de autenticación actual comprende:
- una etapa de obtención de un dato de identificación del terminal de comunicación;
- una etapa de obtención de un dato de autenticación de dicho usuario al que está asociado dicho terminal de comunicación;
- una etapa de cifrado de dicho dato de identificación del terminal de comunicación y de dicho dato de autenticación de dicho usuario, que suministra el código de autenticación actual.
De acuerdo con una característica particular, el procedimiento de refuerzo de la seguridad de procesamiento comprende una etapa de provisión, en una zona de introducción seleccionada con anterioridad, de dicho código de autenticación actual.
De este modo, además de los datos usuales, habitualmente introducidos por el usuario en las zonas de introducción previstas al efecto (zona de apellidos, de nombre, de fecha de validez, de número de tarjeta), el procedimiento permite hacer segura la transacción introduciendo un dato calculado en el mismo seno del terminal. Este dato, en efecto, permite asegurar que la transacción se realiza en el seno de un terminal identificado.
De acuerdo con una característica particular, el código de autenticación actual se proporciona en una zona de introducción del código de verificación de tarjeta bancaria.
De este modo, la técnica que se propone no precisa de la puesta en práctica de una nueva zona de introducción. En efecto, al utilizar la zona de introducción del código de verificación (denominado asimismo, en inglés, “card verification code” o “card verification value”), no es útil desarrollar o volver a desarrollar nuevas aplicaciones y, en especial, nuevas aplicaciones de pago (por ejemplo, en los sitios Internet y/o en las aplicaciones de los vendedores).
Al término de la puesta en práctica de esta técnica, según esta última característica, los campos necesarios para el pago han sido introducidos de manera automática. Además, el campo código de verificación comprende el código de autenticación generado anteriormente. Por lo tanto, el usuario está en condiciones de validar el pago.
De acuerdo con una característica particular, este procedimiento comprende, adicionalmente, una etapa previa de obtención de un valor de ocurrencia de puesta en práctica del procedimiento de refuerzo de la seguridad de procesamiento y, cuando se trata de la primera ocurrencia de puesta en práctica del procedimiento, el procedimiento comprende una etapa de creación de un dato representativo de un enlace entre el terminal de comunicación y un servidor de procesamiento de transacciones.
De este modo, con la primera puesta en práctica del servicio, es posible establecer un enlace fuerte entre el terminal de comunicación y uno o varios servidores a cargo de la puesta en práctica de la transacción. Se trata, por ejemplo, de un servidor de un prestador de servicios de pago.
De acuerdo con una característica particular, la etapa de creación de un dato de autenticación de referencia entre el terminal de comunicación y un servidor de procesamiento de transacciones comprende:
- una etapa de obtención de un dato de identificación del terminal de comunicación;
- una etapa de obtención de un dato de autenticación de dicho usuario al que está asociado dicho terminal de comunicación;
- una etapa de cifrado de dicho dato de identificación del terminal de comunicación y de dicho dato de autenticación de dicho usuario, que suministra el dato representativo del enlace entre el terminal de pago y el servidor del prestador de servicios de pago;
- una etapa de transmisión de dicho dato de autenticación de referencia a un servidor del prestador de servicios de pago.
De acuerdo con otro aspecto, la presente técnica se refiere, asimismo, a un procedimiento de refuerzo de la seguridad de procesamiento de datos de transacciones, en el seno de un servidor.
De acuerdo con una característica particular, el procedimiento comprende, al recibir un servidor de procesamiento los datos procedentes de dicha al menos una zona de introducción, al menos una etapa de comparación entre al menos un dato transmitido en el seno de dicha zona de introducción y el dato de autenticación de referencia, que suministra una aserción de validación de la transacción.
De acuerdo con otro aspecto, la invención se refiere, asimismo, a un terminal de comunicación inteligente caracterizado por comprender un módulo de procesamiento de datos de transacciones y un módulo de obtención de datos sin contacto, caracterizado por que el módulo de procesamiento comprende:
- medios de detección, de una presentación de al menos una zona de introducción relativa a un dato de medio de pago;
- medios de activación, del módulo de lectura de datos sin contacto;
- medios de obtención, por parte del módulo de lectura de datos sin contacto, de al menos un dato de medio de pago con origen en un medio de pago;
- medios de provisión, a dicha al menos una zona de introducción, de al menos un dato de medio de pago obtenido anteriormente.
De acuerdo con una implementación preferida, las diferentes etapas de los procedimientos según la técnica que se propone se llevan a la práctica mediante uno o varios soportes lógicos o programas de ordenador, que comprenden instrucciones lógicas destinadas a ser ejecutadas por un procesador de datos de un módulo relevador según la técnica que se propone y que está diseñado para regir la ejecución de las diferentes etapas de los procedimientos.
En consecuencia, la técnica que se propone también está encaminada a un programa, susceptible de ser ejecutado por un ordenador o por un procesador de datos, incluyendo este programa instrucciones para regir la ejecución de las etapas de los procedimientos tal y como se ha mencionado anteriormente, cuando son ejecutados por un terminal y/o por un circuito integrado.
Este programa puede utilizar cualquier lenguaje de programación y presentarse en forma de código fuente, código objeto, o de código intermedio entre código fuente y código objeto, tal como en una forma compilada parcialmente, o en cualquier otra forma deseable.
La técnica que se propone también está encaminada a un soporte de información legible por un procesador de datos y que incluye instrucciones de un programa tal y como se ha 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 también un medio de grabación magnética, por ejemplo un disquete (floppy disc) o un disco duro, una memoria flash o una memoria de un medio de almacenamiento de otro tipo.
Por otra parte, el soporte de información puede ser un soporte transmisible, tal como una señal eléctrica u óptica, que se puede conducir a través de un cable eléctrico u óptico, por radio o por otros medios. El programa según la técnica que se propone se puede descargar en particular por una red de tipo Internet.
Alternativamente, el soporte de información puede ser un circuito integrado en el que va incorporado el programa, estando adaptado el circuito para ejecutar o para ser utilizado en la ejecución del procedimiento en cuestión.
De acuerdo con una forma de realización, la técnica que se propone se lleva a la práctica por medio de componentes de soporte lógico y/o de soporte físico. En esta línea, el término “módulo” puede corresponder, en este documento, tanto a un componente de soporte lógico, como a un componente de soporte físico o a un conjunto de componentes de soporte físico y lógico.
Un componente de soporte lógico corresponde a uno o varios programas de ordenador, uno o varios subprogramas de un programa o, de manera más general, a todo elemento de un programa o de un soporte lógico apto para llevar a la práctica una función o un conjunto de funciones, según lo descrito a continuación en relación con el módulo de que se trate. Tal componente de soporte lógico es ejecutado por un procesador de datos de una entidad física (terminal, servidor, pasarela, encaminador, etc.) y está posibilitado de acceso a los recursos de soporte físico de esta entidad física (memorias, soportes de grabación, buses de comunicación, tarjetas electrónicas de entrada/salida, interfaces de usuario, etc.).
De la misma manera, un componente de soporte físico corresponde a todo elemento de un conjunto de soporte físico (o hardware) apto para llevar a la práctica una función o un conjunto de funciones, según lo descrito a continuación en relación con el módulo de que se trate. Puede ser un componente de soporte físico programable o con procesador integrado para la ejecución de soporte lógico, por ejemplo un circuito integrado, una tarjeta chip, una tarjeta de memoria, una tarjeta electrónica para la ejecución de un microprograma (firmware), etc.
Por supuesto, cada componente del sistema anteriormente descrito lleva a la práctica sus propios módulos de lógica.
Las diferentes formas de realización antes mencionadas son combinables entre sí para la puesta en práctica de la técnica que se propone.
4. Figuras
Otras características y ventajas de la técnica que se propone se pondrán más claramente de manifiesto con la lectura de la siguiente descripción de una forma preferente de realización, dada a título de mero ejemplo ilustrativo y no limitativo, y de los dibujos que se acompañan, de los cuales:
la figura 1 expone un sinóptico del método general puesto en práctica para la introducción facilitada de los datos de pago en el seno de un formulario;
la figura 2 expone las etapas generales puestas en práctica en la creación, por parte del terminal de comunicación, de un código de autenticación actual;
la figura 3 expone las etapas puestas en práctica en la creación, por parte del terminal de comunicación, de un código de autenticación actual según una forma particular de realización;
la figura 4 expone las etapas puestas en práctica por un servidor de prestador de pago para validar un código de autenticación actual según una forma particular de realización;
la figura 5 describe sumariamente la arquitectura física de un terminal adaptado para llevar a la práctica la presente técnica; y
la figura 6 describe sumariamente la arquitectura física de un servidor adaptado para llevar a la práctica la presente técnica.
5. Descripción
5.1. Recapitulación del principio
El principio general de la presente técnica radica, por una parte, en la puesta en práctica de un terminal de comunicación inteligente, que comprende medios de obtención de datos con origen en un medio de pago. Más específicamente, un medio de obtención de datos con origen en un medio de pago se materializa en un módulo de comunicación sin contacto, siendo tal módulo, más específicamente, un módulo de comunicación de campo cercano (NFC). Este módulo recibe, por parte de un procesador del terminal de comunicación, una instrucción o un mandato de obtención de datos sin contacto. Puede ser un mandato de carácter general. Por otro lado, este módulo está unido a una antena sin contacto. Esta antena sin contacto sirve para emitir una señal con destino al medio de pago y para recibir una señal con origen en este medio de pago.
El principio general de la presente técnica radica, por una parte, en la puesta en práctica de una aplicación, instalada en el seno del terminal de comunicación inteligente, aplicación que comprende unos medios de detección y de rellenado de campos de introducción de datos de medios de pago.
Un medio de pago sin contacto se materializa, por ejemplo, en una tarjeta de pago (o tarjeta de crédito o tarjeta de débito), que comprende una antena de tipo NFC (“Near Field Communication”), comprendiendo esta antena unos medios de transmisión de datos hacia un receptor cuando recibe, por parte de este receptor, una petición en tal sentido (petición que adopta la forma, por ejemplo, de una señal electromagnética). La antena, denominada antena sin contacto, puede estar unida a un procesador. Este procesador puede ser, por ejemplo, el chip de la tarjeta chip o un procesador suplementario embebido en el substrato de la tarjeta (del mismo modo, por cierto, que la antena). Subsidiariamente, un medio de pago sin contacto puede materializarse, asimismo, en un terminal de comunicación (un segundo terminal de comunicación), el cual está provisto de medios de transmisión de datos sin contacto y, eventualmente, de una aplicación destinada específicamente a transmitir datos equivalentes o idénticos a datos de tarjeta de pago. Tal aplicación puede ser, por ejemplo, una aplicación bancaria, instalada en el seno del terminal de comunicación y que conserva estos datos de manera segura. En este caso, por ejemplo, la técnica se lleva a la práctica aplicando este segundo terminal de comunicación sobre el primer terminal de comunicación. Tal puesta en práctica es completamente concebible por cuanto que multitud de personas disponen a la vez de una tableta y de un teléfono inteligente, disponiendo el teléfono inteligente de la aplicación bancaria, en tanto que la tableta es utilizada de manera más general y más libre por varias personas del hogar, no estando destinada esta tableta a contener datos confidenciales.
Presentamos, en relación con las figuras 1 y 2, las diferentes etapas de puesta en práctica del procedimiento según la presente técnica, desde un punto de vista general. La puesta en práctica del procedimiento comprende, con anterioridad, la selección, en el seno de una aplicación o de un navegador, de uno o varios bienes o servicios que el usuario desea adquirir. El usuario, cuando ha seleccionado aquello que desea adquirir, pasa a la fase de pago. Esta fase de pago da comienzo con la presentación de una pantalla (página HTML o página de una aplicación) que comprende campos de introducción de datos de medio de pago (por ejemplo, datos de tarjeta bancaria). A partir de entonces, puede ser llevado a la práctica el procedimiento de la presente técnica. Este método general comprende, por una parte, un procedimiento puesto en práctica del lado del terminal de comunicación y, por otra, un procedimiento puesto en práctica del lado de un servidor (servidor del prestador de servicios de pago, por ejemplo, o servidor bancario directamente). A los efectos de la presente, los dos procedimientos se presentan de manera imbricada, con el fin de exponer un método de procesamiento lo más claro posible. Resulta obvio, no obstante, que estos procedimientos pueden ser llevados a la práctica de manera independiente. Presentamos el procedimiento general de procesamiento en relación con la figura 1.
En la presentación de la pantalla que comprende los campos de introducción de datos necesarios para el pago, un módulo de procesamiento (ModT) instalado en el seno del terminal de comunicación (TC) (por ejemplo, en forma de una aplicación particular):
- detecta (100) la presentación de estas zonas de introducción; para hacer esto, el módulo de procesamiento (ModT) pone en práctica una técnica particular que no es objeto de la presente;
- el módulo de procesamiento (ModT) activa (110) entonces el módulo de lectura de datos sin contacto (ModSC); de manera complementaria, el módulo de procesamiento (ModT) toma posesión de la presentación realizada en el terminal de comunicación; esta toma de posesión se realiza en forma de una interrupción de la aplicación solicitante (aplicación específica del vendedor o navegador); la aplicación solicitante queda “congelada” y el módulo de procesamiento (ModT) presenta, en transparencia, en resalte, por ejemplo, el logotipo de pago sin contacto, es presentado por el módulo de procesamiento (ModT);
- el usuario utiliza su medio de pago: el usuario aplica su medio de pago sobre el terminal de comunicación;
- el módulo de lectura de datos sin contacto (ModSC) obtiene (120) entonces, por mediación de una petición y de una respuesta del medio de pago, los datos necesarios para el pago. El número y la designación de estos datos varían en función de los requisitos reglamentarios y de las prácticas de los vendedores y de los prestadores de servicios de pago; típicamente, los datos obtenidos son: los apellidos, el nombre, la fecha de caducidad y el número de tarjeta bancaria y el código de verificación;
- el módulo de lectura de los datos sin contacto transfiere los datos obtenidos al módulo de procesamiento (ModT) del terminal de comunicación; el módulo de procesamiento (ModT) efectúa entonces un rellenado (130) de las zonas de introducción en función de los datos recibidos del medio de pago: el módulo de procesamiento (ModT) asigna los datos recibidos a las zonas identificadas anteriormente; el módulo de procesamiento (ModT), al mismo tiempo, devuelve el control a la aplicación solicitante y anula la presentación del logotipo de pago sin contacto (si el mismo está siendo presentado).
En una primera forma de realización de la presente técnica, basta con las operaciones efectuadas anteriormente. El usuario no tiene más que verificar y validar los datos introducidos. La continuación del proceso de pago es idéntica a la existente y la transacción sigue su curso de la manera habitual.
De manera complementaria, en otras formas de realización más seguras, se asegura que el terminal y el usuario que efectúa la operación de pago realmente están autorizados a hacerla. Tal forma de realización queda presentada especialmente en relación con las figuras 1 y 2. Para hacer esto, en estas formas de realización complementarias, el módulo de procesamiento (ModT) del terminal de comunicación pone en práctica una etapa de creación (125) de un código de autenticación actual (CAC). La creación de este código de autenticación actual (CAC) comprende las siguientes etapas:
- una etapa de obtención (125-1) de un dato de identificación del terminal de comunicación (IdTerm); tal dato de identificación, según las formas de realización, puede ser, por ejemplo, un número de serie, un IMSI (del inglés, por “International Mobile Subscriber Identity”), un IMEI (del inglés, por “International Mobile Equipment Identity”) u otro, o también una combinación de estos códigos;
- una etapa de obtención (125-2) de un dato de autenticación de dicho usuario (AuthU) al que está asociado dicho terminal de comunicación; tal dato de autenticación puede ser, dependiendo de la forma de realización, un dato biométrico (por ejemplo, una firma de una huella dactilar o de una huella de voz) o también un código de autenticación personal (de tipo código PIN);
- una etapa de cifrado (125-6) de dicho dato de identificación del terminal de comunicación y de dicho dato de autenticación de dicho usuario, que suministra el código de autenticación actual (CAC); esta etapa de cifrado, que se detalla en lo sucesivo, consiste en cifrar y/o en obtener un resumen (hash) de los datos obtenidos anteriormente y en producir con ellos un código de autenticación; por supuesto, de manera complementaria, los datos se cifran o someten a una obtención de resumen con una o varias claves de cifrado a disposición del módulo de procesamiento (ModT)s del terminal de comunicación del usuario.
El módulo de procesamiento (ModT), una vez que dispone del código de autenticación actual (CAC), proporciona este código de autenticación actual (CAC) a la aplicación solicitante. Esta provisión se puede efectuar de varias maneras (por ejemplo, rellenando un campo “código de autenticación” de la pantalla de introducción. De acuerdo con una forma ventajosa de realización, sin embargo, el código de autenticación ocupa el lugar del código de verificación “CVV”. De este modo, en sustitución del CVV, el cual puede ser obtenido en lectura sin contacto a partir del medio de pago (como anteriormente se ha indicado), este campo de introducción CVV se rellena con el código de autenticación actual (CAC). Ventajosamente, el modo de cálculo del código de autenticación actual comprende al menos una etapa de formateo, de modo que el tamaño del código de autenticación actual se corresponda con un tamaño aceptado por la zona de introducción referida al CVV. De este modo, no hay dificultad de inserción del CAC en la zona prevista para el CVV.
A partir de este momento, desde el punto de vista del prestador de servicios de pago, el proceso de validación de la transacción es un tanto diferente de aquel que usualmente se lleva a la práctica. En efecto, la validación, por parte del usuario, del formulario de introducción de los datos de pago provoca la transmisión (directa o indirecta: es decir, por mediación del servidor del comerciante) de estos datos de pago al servidor de procesamiento del prestador de servicios de pago. A partir de este momento, el servidor del prestador de servicios de pago (servidor PSP) pone en práctica las siguientes etapas:
- recepción de los datos de pago (que comprenden especialmente los datos introducidos automáticamente y el código de autenticación actual (CAC));
- control de la validez del código de autenticación actual (CAC); y
- cuando el código de autenticación actual (CAC) es válido, validación de la transacción;
- cuando el código de autenticación actual (CAC) es inválido, denegación de la transacción.
Dependiendo de las formas de realización, el control de la validez del código de autenticación actual (CAC) se lleva a la práctica de varias maneras diferentes:
- bien se compara directamente el código de autenticación actual (CAC) con un código de autenticación de referencia, recibido anteriormente por parte del usuario y del terminal de comunicación (por ejemplo, en la primera puesta en práctica del servicio, como se hace explícito en lo sucesivo); en este caso, se efectúa una simple comparación;
- o bien se utilizan los datos del código de autenticación actual (CAC) para decidir la validez de la transacción, con respecto a unos datos recibidos anteriormente -este aspecto se describe asimismo en lo sucesivo-.
Cuando se utilizan los datos del código de autenticación actual (CAC) para efectuar una validación de la transacción, se ponen en práctica las siguientes etapas:
- descifrado del código de autenticación actual (CAC); este descifrado se lleva a la práctica utilizando un secreto compartido entre el servidor del prestador de servicios de pago y el terminal de comunicación del usuario; este secreto ha sido compartido en una fase de inscripción frente al prestador de servicios de pago; una forma de realización de esta fase de inscripción y de compartición de datos queda descrita en lo sucesivo; - verificación de los datos descifrados: estos datos son, por ejemplo, el dato de identificación del terminal de comunicación y el dato de autenticación del usuario.
De este modo, la puesta en práctica de la técnica descrita permite, por una parte, facilitar las operaciones de pago en línea para los usuarios y, por otra, aportar un refuerzo complementario de la seguridad en estas operaciones de pago en línea.
En lo sucesivo, se describe una forma de realización de las operaciones de refuerzo de la seguridad. Resulta obvio, sin embargo, que esta forma de realización tan solo es ilustrativa de las operaciones de refuerzo de la seguridad que pueden realizarse. Más en particular, resulta obvio que, asimismo, se pueden llevar a la práctica otras formas de realización, basadas, por ejemplo, en la tenencia de pares de claves privadas/públicas por los diferentes involucrados (terminal de comunicación, servidor del prestador de servicios de pago) sin salir del ámbito planteado por la presente.
5.2. Descripción de una forma de realización
En esta forma de realización, se presenta la manera en que el servidor de procesamiento queda en posesión del soporte físico necesario para la posterior verificación del código de autenticación actual (CAC) (esta etapa se denomina etapa de inscripción).
En esta forma de realización, se presenta asimismo la manera en que el código de autenticación actual (CAC) es producido por el módulo de procesamiento (ModT) del terminal de comunicación. En esta forma de realización, se presenta asimismo la manera en que el servidor de procesamiento realiza la verificación de un código de autenticación actual (CAC).
Para hacer esto, se considera el dato de un apareamiento bilineal simétrico e - . G x G ^ H con un grupo H de pequeño tamaño. Cabe recordar que tal función verifica, para todo entero x, y y todo punto g, h de G:
e(gx, hy) = e(g,hy) x = e(gx,h)y = e(g,h)xy
e(g,h) = e(h, g)
Este apareamiento bilineal es utilizado tanto para la etapa de inscripción como para las posteriores etapas de verificación. Típicamente, el tamaño del grupo es de 128 bits. Tal grupo es considerado como de pequeño tamaño en consideración al tamaño usual de estos grupos (típicamente, 256 bits, e incluso 512 bits). Esto significa que, en esta aplicación, el grupo comprende números cuya longitud es de como máximo 128 bits. Este grupo comprende, por ejemplo, 2128 elementos: estos elementos no (necesariamente) son números. En la aplicación que se considera, por ejemplo, se trata de puntos de una curva elíptica. Aunque podría tratarse de cualquier objeto adaptado a la presente técnica.
En esta forma de realización, es posible utilizar un apareamiento de Tate que está definido en toda curva elíptica. Sin embargo, por motivos de seguridad y de prestaciones, es posible utilizar curvas de Barreto-Naehrig. Tal apareamiento bilineal puede calcular, por ejemplo, utilizando el algoritmo de Miller. Estos elementos se dan a título enunciativo. En efecto, podría ser adecuado cualquier apareamiento. Sin embargo, este apareamiento particular presenta la doble ventaja de la eficiencia (es uno de los más rápidos) y de la generalidad (se aplica en una gran mayoría de casos). 5.2.1. Inscripción frente al servidor de procesamiento
Llamamos T (T = idTerm, para mayor facilidad de notación) al dato de identificación proporcionado por el teléfono en la inscripción, y B (B = AuthU, para mayor facilidad de notación) al dato de autenticación proporcionado por el usuario. En la inscripción, el servidor de procesamiento transmite un elemento g del grupo H y el terminal de comunicación transmite, como respuesta, el dato constituido a partir de {gT,g B}.
Dicho de otro modo, la etapa de inscripción comprende, para el terminal de comunicación, en esta forma de realización:
- una etapa de recepción, con origen en el servidor de procesamiento, de un elemento g; típicamente, tal elemento es un entero del grupo H;
- una etapa de cálculo, por parte del módulo de procesamiento (ModT) del terminal de comunicación, del dato constituido a partir de {gT,gB};
- una etapa de transmisión, por parte del terminal de comunicación, del dato calculado anteriormente.
Este dato se registra en el seno del servidor de procesamiento. Queda asociado al terminal de comunicación del usuario.
5.2.2. Creación del código de autenticación actual (CAC) por parte del terminal de comunicación
La creación del código de autenticación actual (CAC) se describe en relación con la figura 3. Al igual que anteriormente, el módulo de procesamiento obtiene (125-1, 125-2) el dato de identificación del terminal (T) y el dato de autenticación del usuario (B). En la puesta en práctica del pago, el módulo de procesamiento efectúa una extracción (125-3) de un número aleatorio r; asimismo, el módulo de procesamiento efectúa (125-4) un marcado de la hora w, correspondiente a la hora de procesamiento de la transacción; el módulo de procesamiento calcula (125-5) asimismo la información de transacción v (como, por ejemplo, el importe y/o el lugar de la transacción y/o los participantes en la transacción). El módulo de procesamiento efectúa un cálculo del código de autenticación actual (CAC): CAC = {wrT, v r B}.
El código de autenticación actual (CAC), así como el nombre, el número de la tarjeta y la fecha de caducidad se transmiten al servidor de procesamiento. El nombre, el número de tarjeta y la fecha de caducidad, en esta transacción, pueden ser cifrados con CAC.
5.2.3. Verificación del código de autenticación actual (CAC) por el servidor de procesamiento
La verificación del código de autenticación actual (CAC) se describe en relación con la figura 4. Así, el servidor de procesamiento recibe CAC = {a,b} como código de verificación. Asimismo, el servidor de procesamiento recibe los demás datos de la transacción. El servidor de procesamiento, obrando en poder de T, el dato de identificación proporcionado por el teléfono en la inscripción, y B, el dato de autenticación proporcionado por el usuario, efectúa los siguientes cálculos:
- divide (200) a por la hora y comprueba que no ha recibido un mismo valor de a/w a lo largo de un período temporal predeterminado (es decir, la última hora, o los 10 últimos minutos, por ejemplo). Si esto ocurre, la transacción es anulada (210).
- en caso contrario, comprueba (220) que:
e(a/w,gB) = e(b/v,gT)
Si esta igualdad es cierta, entonces se valida (230) la transacción (y, en su caso, el nombre y el PAN se pueden descifrar con el concurso del CAC).
Por supuesto, esta forma de realización de la técnica se describe a título ilustrativo. En especial, queda descrita en el ámbito de una puesta en práctica para un pago en línea. Se da por supuesto que, asimismo, esta técnica puede aplicarse en otros tipos de pago y, especialmente, en pagos puestos en práctica en un pago directo en el establecimiento de un comerciante. En cuyo caso, el principio descrito sigue siendo el mismo: en lugar de introducir de manera automática, en una pantalla, datos de tarjeta bancaria, se realiza una transmisión directa de estos datos leídos a un servidor del comerciante, con el fin de que estos datos sean transmitidos y procesados como si se tratara de un pago realizado físicamente con una tarjeta bancaria en un terminal de pago físico del comerciante.
5.3. Otras características y ventajas
Se describe, en relación con la figura 5, un terminal de comunicación que comprende medios que permiten la ejecución del procedimiento descrito con anterioridad.
Por ejemplo, el terminal de comunicación comprende una memoria 51 constituida a partir de una memoria intermedia, poniendo en práctica una unidad de procesamiento 52, equipada, por ejemplo, con un microprocesador y pilotada por el programa de ordenador 53, las etapas necesarias para la obtención, para el rellenado, para el cifrado y para la transmisión de datos de procesamiento de transacciones.
Con la inicialización, las instrucciones de código del programa de ordenador 53 se cargan, por ejemplo, en una memoria, antes de ser ejecutadas por el procesador de la unidad de procesamiento 52. La unidad de procesamiento 52 recibe como entrada, por ejemplo, una pantalla o un formulario que ha de rellenarse. El microprocesador de la unidad de procesamiento 52 pone en práctica las etapas del procedimiento, según las instrucciones del programa de ordenador 53, para permitir la introducción de los datos a partir de un medio de pago sin contacto.
Para ello, el dispositivo de procesamiento comprende, aparte de la memoria intermedia 51, medios de identificación de las zonas de introducción de los datos de pago, medios de obtención de datos con origen en unos medios de pago sin contacto (como un módulo de lectura NFC), medios de obtención de soportes físicos de cifrado, medios de cifrado. Asimismo, el dispositivo de procesamiento comprende:
- medios de detección, de una presentación de al menos una zona de introducción relativa a un dato de medio de pago; tales medios se materializan, por ejemplo, en un módulo de detección particular;
- medios de activación, por parte del módulo de procesamiento, de un módulo de lectura de datos sin contacto;
tales medios se materializan, por ejemplo, en un circuito de conexión de dicho módulo;
- medios de obtención, por parte del módulo de lectura de datos sin contacto, de al menos un dato de medio de pago con origen en un medio de pago; estos medios se materializan en un módulo de interrogación de tarjeta bancaria, por ejemplo;
- medios de provisión, a dicha al menos una zona de introducción, de al menos un dato de medio de pago obtenido anteriormente; estos medios se materializan, por ejemplo, en un autómata de introducción.
Estos medios pueden estar pilotados por el procesador de la unidad de procesamiento 52 en función del programa de ordenador 53.
Se describe, en relación con la figura 6, un servidor de procesamiento que comprende medios que permiten la ejecución del procedimiento descrito con anterioridad.
Por ejemplo, el servidor de procesamiento comprende una memoria 61 constituida a partir de una memoria intermedia, poniendo en práctica una unidad de procesamiento 62, equipada, por ejemplo, con un microprocesador y pilotada por el programa de ordenador 63, las etapas necesarias para la puesta en práctica de las funciones de verificación de los datos de transacción.
Con la inicialización, las instrucciones de código del programa de ordenador 63 se cargan, por ejemplo, en una memoria, antes de ser ejecutadas por el procesador de la unidad de procesamiento 62. La unidad de procesamiento 62 recibe como entrada, por ejemplo, un conjunto de datos cifrados, que comprenden, por ejemplo, un código de autenticación actual (CAC). El microprocesador de la unidad de procesamiento 62 pone en práctica las etapas del procedimiento de procesamiento, según las instrucciones del programa de ordenador 63, para permitir el descifrado de los datos cifrados y la verificación del código de autenticación actual (CAC).
Para ello, el dispositivo comprende, aparte de la memoria intermedia 61, unos medios de obtención de clave de cifrado/descifrado; estos medios pueden materializarse en forma de un procesador o de un conjunto de recursos seguros que permiten hacer segura la introducción de la autorización. Asimismo, el dispositivo comprende medios de procesamiento criptográficos; estos medios de procesamiento comprenden, por ejemplo, un procesador de cifrado específico.
Estos medios pueden estar pilotados por el procesador de la unidad de procesamiento 62 en función del programa de ordenador 63.

Claims (7)

REIVINDICACIONES
1. Procedimiento de refuerzo de la seguridad de procesamiento de datos de transacciones, procedimiento puesto en práctica en el seno de un terminal de comunicación (TC) que comprende un módulo de procesamiento de datos de transacciones (ModT), comprendiendo dicho procedimiento:
- una etapa de detección (100), por parte del módulo de procesamiento (ModT), de una presentación de al menos una zona de introducción (ZoS) relativa a un dato de medio de pago;
- una etapa de activación (110), por parte del módulo de procesamiento (ModT), de un módulo de lectura de datos sin contacto (ModSC);
- una etapa de obtención (120), por parte del módulo de lectura de datos sin contacto (ModSC), de al menos un dato de medio de pago con origen en un medio de pago;
estando caracterizado dicho procedimiento por comprender:
- una etapa de generación (125), por parte del módulo de procesamiento (ModT), de un código de autenticación actual (CAC), comprendiendo dicha etapa de generación una etapa de cálculo de una función de apareamiento bilineal simétrico en función de un dato de identificación (IdTerm) del terminal de comunicación y de un dato de autenticación (AuthU) de un usuario al que está asociado dicho terminal de comunicación, que suministra el código de autenticación actual (CAC);
- una etapa de provisión (130), a dicha al menos una zona de introducción (ZoS), de al menos un dato de medio de pago obtenido anteriormente y de dicho código de autenticación actual (CAC) generado.
2. Procedimiento de refuerzo de la seguridad de procesamiento según la reivindicación 1, caracterizado por que el código de autenticación actual (CAC) se proporciona en una zona de introducción (ZoS) del código de verificación de tarjeta bancaria.
3. Procedimiento de refuerzo de la seguridad de procesamiento según la reivindicación 1, caracterizado por comprender, adicionalmente, una etapa previa de obtención de un valor de ocurrencia de puesta en práctica del procedimiento de refuerzo de la seguridad de procesamiento y, cuando se trata de la primera ocurrencia de puesta en práctica del procedimiento, el procedimiento comprende una etapa de creación de un dato representativo de un enlace entre el terminal de comunicación y un servidor de procesamiento de transacciones, llamado dato de autenticación de referencia.
4. Procedimiento de refuerzo de la seguridad de procesamiento según la reivindicación 3, caracterizado por que la etapa de creación del dato de autenticación de referencia entre el terminal de comunicación y un servidor de procesamiento de transacciones comprende:
- una etapa de obtención de un dato de identificación del terminal de comunicación;
- una etapa de obtención de un dato de autenticación de dicho usuario al que está asociado dicho terminal de comunicación;
- una etapa de cifrado de dicho dato de identificación del terminal de comunicación y de dicho dato de autenticación de dicho usuario, que suministra el dato de autenticación de referencia;
- una etapa de transmisión del dato de autenticación de referencia a un servidor de procesamiento.
5. Procedimiento de procesamiento según la reivindicación 3, caracterizado por comprender, al recibir un servidor de procesamiento los datos procedentes de dicha al menos una zona de introducción, al menos una etapa de comparación entre al menos un dato transmitido en el seno de dicha zona de introducción y el dato de autenticación de referencia, que suministra una aserción de validación de la transacción.
6. Terminal de comunicación inteligente (TC) caracterizado por comprender un módulo de procesamiento de datos de transacciones (ModT) y un módulo de obtención de datos sin contacto (ModSC), comprendiendo dicho módulo de procesamiento (ModT):
- medios de detección (100), de una presentación de al menos una zona de introducción (ZoS) relativa a un dato de medio de pago;
- medios de activación (110), del módulo de lectura de datos sin contacto (ModSC);
- medios de obtención (120), por parte del módulo de lectura de datos sin contacto (ModSC), de al menos un dato de medio de pago con origen en un medio de pago;
caracterizándose dicho módulo de procesamiento (ModT) por comprender:
- medios de generación (125), por parte del módulo de procesamiento (ModT), de un código de autenticación actual (CAC), comprendiendo dichos medios de generación unos medios de cálculo de una función de apareamiento bilineal simétrico en función de un dato de identificación (IdTerm) del terminal de comunicación y de un dato de autenticación (AuthU) de un usuario al que está asociado dicho terminal de comunicación, que suministra el código de autenticación actual (CAC);
- medios de provisión (130), a dicha al menos una zona de introducción (ZoS), de al menos un dato de medio de pago obtenido anteriormente y de dicho código de autenticación actual (CAC) generado.
7. Producto de programa de ordenador descargable desde una red de comunicación y/o almacenado en un soporte legible por ordenador y/o ejecutable por un microprocesador, caracterizado por comprender instrucciones de código de programa para la ejecución de un procedimiento de refuerzo de la seguridad de procesamiento según una de las reivindicaciones 1 a 5, cuando es ejecutado por un procesador.
ES16195082T 2015-10-27 2016-10-21 Procedimiento de refuerzo de la seguridad de procesamiento de datos de transacciones, terminal y programa de ordenador correspondiente Active ES2894899T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1560270A FR3042894B1 (fr) 2015-10-27 2015-10-27 Procede de securisation de traitement de donnees transactionnelles, terminal et programme d'ordinateur correspondant

Publications (1)

Publication Number Publication Date
ES2894899T3 true ES2894899T3 (es) 2022-02-16

Family

ID=55451281

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16195082T Active ES2894899T3 (es) 2015-10-27 2016-10-21 Procedimiento de refuerzo de la seguridad de procesamiento de datos de transacciones, terminal y programa de ordenador correspondiente

Country Status (5)

Country Link
US (1) US11625713B2 (es)
EP (1) EP3163487B1 (es)
CA (1) CA2946570C (es)
ES (1) ES2894899T3 (es)
FR (1) FR3042894B1 (es)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2881429C (en) 2012-02-29 2017-05-02 Mobeewave, Inc. Method, device and secure element for conducting a secured financial transaction on a device
FR3042894B1 (fr) * 2015-10-27 2018-10-12 Ingenico Group Procede de securisation de traitement de donnees transactionnelles, terminal et programme d'ordinateur correspondant
TWI630816B (zh) * 2017-02-07 2018-07-21 淡江大學 電子裝置、包含此電子裝置可見光身份辨識系統及其方法
CN112508552B (zh) * 2017-12-06 2024-07-09 创新先进技术有限公司 Nfc便携设备的写入、支付方法、装置以及设备
FR3083356B1 (fr) 2018-06-29 2020-09-11 Ingenico Group Procede de realisation d'une transaction, terminal, serveur et programme d'ordinateur correspondant

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5680610A (en) * 1995-01-19 1997-10-21 Unisys Corporation Method and apparatus for testing recovery scenarios in global transaction processing systems
US5805164A (en) * 1996-04-29 1998-09-08 Microsoft Corporation Data display and entry using a limited-area display panel
KR20030008182A (ko) * 2002-12-24 2003-01-24 학교법인 한국정보통신학원 겹선형쌍을 이용한 개인식별정보 기반의 은닉서명 방법
US8209744B2 (en) * 2008-05-16 2012-06-26 Microsoft Corporation Mobile device assisted secure computer network communication
US8814052B2 (en) * 2008-08-20 2014-08-26 X-Card Holdings, Llc Secure smart card system
US9026462B2 (en) * 2008-09-30 2015-05-05 Apple Inc. Portable point of purchase user interfaces
WO2010079559A1 (ja) * 2009-01-06 2010-07-15 日本電気株式会社 クレジット情報区間検出方法、クレジット情報区間検出装置及びクレジット情報区間検出プログラム
EP2256645A1 (en) * 2009-05-29 2010-12-01 Incard SA Method for producing at least a portion of a data visualization layout on a display of a device provided with at least a Smart Card, method for codifying a plurality of HTML instructions and corresponding system
US8615468B2 (en) * 2010-01-27 2013-12-24 Ca, Inc. System and method for generating a dynamic card value
AU2011224755A1 (en) * 2010-03-09 2012-09-27 Visa International Service Association System and method including dynamic verification value
CN102792325B (zh) * 2010-04-09 2017-09-01 维萨国际服务协会 用于安全地证实交易的系统和方法
US20120221474A1 (en) * 2011-02-24 2012-08-30 Skycore Llc Secure Electronic Ticketing using Mobile Communication Devices over the Internet
WO2013028901A2 (en) * 2011-08-23 2013-02-28 Visa International Service Association Authentication process for value transfer machine
US8313036B1 (en) * 2011-09-16 2012-11-20 Google Inc. Secure application directory
US20140074655A1 (en) * 2012-09-07 2014-03-13 David Lim System, apparatus and methods for online one-tap account addition and checkout
US8566601B1 (en) * 2012-09-12 2013-10-22 Zeutro Llc Systems and methods for functional encryption using a string of arbitrary length
US20140076967A1 (en) * 2012-09-18 2014-03-20 Rawllin International Inc. Mobile digital signature reader
US9514452B2 (en) * 2012-11-20 2016-12-06 Paypal, Inc. System and method for simplified checkout with payment float
FR3006782A1 (fr) * 2013-06-11 2014-12-12 France Telecom Procede et systeme de delegation d'un calcul d'une valeur de couplage bilineaire a un serveur de calcul
CN105122760B (zh) * 2013-11-06 2019-04-26 华为终端(东莞)有限公司 页面操作处理方法、装置及终端
US9780953B2 (en) * 2014-07-23 2017-10-03 Visa International Service Association Systems and methods for secure detokenization
US20160026997A1 (en) * 2014-07-25 2016-01-28 XPressTap, Inc. Mobile Communication Device with Proximity Based Communication Circuitry
US10333696B2 (en) * 2015-01-12 2019-06-25 X-Prime, Inc. Systems and methods for implementing an efficient, scalable homomorphic transformation of encrypted data with minimal data expansion and improved processing efficiency
US20160224973A1 (en) * 2015-02-01 2016-08-04 Apple Inc. User interface for payments
FR3042894B1 (fr) * 2015-10-27 2018-10-12 Ingenico Group Procede de securisation de traitement de donnees transactionnelles, terminal et programme d'ordinateur correspondant
KR20180009147A (ko) * 2016-07-18 2018-01-26 삼성전자주식회사 압력 입력을 이용한 사용자 인터페이스 제공 방법 및 이를 구현한 전자 장치
US11544699B2 (en) * 2017-08-31 2023-01-03 Jpmorgan Chase Bank, N.A. Systems and methods for mobile wallet payments
US20210174355A1 (en) * 2019-12-09 2021-06-10 Capital One Services, Llc Systems and methods for binding unique tokens with transaction parameters to authorize transactions

Also Published As

Publication number Publication date
EP3163487A1 (fr) 2017-05-03
CA2946570A1 (fr) 2017-04-27
FR3042894B1 (fr) 2018-10-12
US20170116609A1 (en) 2017-04-27
CA2946570C (fr) 2024-01-02
EP3163487B1 (fr) 2021-08-18
FR3042894A1 (fr) 2017-04-28
US11625713B2 (en) 2023-04-11

Similar Documents

Publication Publication Date Title
US12014354B1 (en) Systems and methods for a transaction card having a cryptographic key
JP6713081B2 (ja) 認証デバイス、認証システム及び認証方法
ES2894899T3 (es) Procedimiento de refuerzo de la seguridad de procesamiento de datos de transacciones, terminal y programa de ordenador correspondiente
CN108476227B (zh) 用于设备推送供应的系统和方法
ES2758658T3 (es) Sistema de pago
US20170308896A1 (en) Methods and apparatus for brokering a transaction
CN105745678B (zh) 包括消费者认证的安全远程支付交易处理
US8868902B1 (en) Characteristically shaped colorgram tokens in mobile transactions
EP1497947B1 (en) Mobile account authentication service
US20170163617A1 (en) Unique code for token verification
JP6704919B2 (ja) 支払いトークンのセキュリティを確保する方法
US20120191615A1 (en) Secure Credit Transactions
JP6498192B2 (ja) オンライン取引の検証ステップを安全にするための方法
US20140149294A1 (en) Method and system for providing secure end-to-end authentication and authorization of electronic transactions
ES2803250T3 (es) Método y sistema de aprovisionamiento de datos de acceso a dispositivos móviles
US20110087591A1 (en) Personalization Data Creation or Modification Systems and Methods
KR101414196B1 (ko) 근거리 무선 통신을 이용한 안전한 인증 서비스 시스템 및 방법
KR101236960B1 (ko) 모바일 일회용 안심클릭을 이용한 휴대단말기의 신용카드 결제 시스템 및 그 방법
US11880840B2 (en) Method for carrying out a transaction, corresponding terminal, server and computer program
ES2865380T3 (es) Método de realización de una transacción, terminal y programa informático correspondiente
EP3059703A1 (en) Method for retrieving by a payment server a funding permanent account number from a token payment account number
AU2009101171A4 (en) 3D security for mobile devices
KR101190745B1 (ko) 인터넷 otp 보안을 이용한 휴대단말기의 신용카드 결제 시스템 및 그 방법
ES2770087T3 (es) Procedimiento de procesamiento de datos transaccionales, dispositivo y programa correspondientes
US20170323302A1 (en) Security systems and methods