ES2878161T3 - Método de gestión de un procedimiento de un modo de emergencia de transacción y dispositivo asociado - Google Patents

Método de gestión de un procedimiento de un modo de emergencia de transacción y dispositivo asociado Download PDF

Info

Publication number
ES2878161T3
ES2878161T3 ES19175995T ES19175995T ES2878161T3 ES 2878161 T3 ES2878161 T3 ES 2878161T3 ES 19175995 T ES19175995 T ES 19175995T ES 19175995 T ES19175995 T ES 19175995T ES 2878161 T3 ES2878161 T3 ES 2878161T3
Authority
ES
Spain
Prior art keywords
procedure
transaction
pms
electronic device
emergency
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
ES19175995T
Other languages
English (en)
Inventor
Benoit Mouroux
Aghiles Adjaz
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.)
Idemia France SAS
Original Assignee
Idemia France 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 Idemia France SAS filed Critical Idemia France SAS
Application granted granted Critical
Publication of ES2878161T3 publication Critical patent/ES2878161T3/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/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
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2048—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share neither address space nor persistent storage
    • 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/3223—Realising banking transactions through 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
    • 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
    • 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/354—Card activation or deactivation
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Hardware Design (AREA)
  • Telephonic Communication Services (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Método de gestión de un procedimiento de emergencia de un modo de emergencia de transacción, que puede activarse en caso de ataque informático o de avería en una red de transacciones (120), puesto en práctica por un dispositivo electrónico (110) con capacidad para realizar una transacción según un modo normal o el modo de emergencia, comprendiendo dicho método las siguientes etapas: - recibir (F340, F455) una orden de activación (CA) de dicho procedimiento del modo de emergencia, que comprende un identificador del procedimiento y un primer dato cifrado, - verificar (F360) la orden de activación (CA), que comprende una verificación de dicho primer dato cifrado, - si la verificación de la orden es satisfactoria, activar (F370) el procedimiento (PMS) de emergencia, - tras la activación (F370) del procedimiento (PMS) de emergencia y después de una inicialización de una transacción entre el dispositivo electrónico (110) y un lector (130), enviar (F520) un mensaje (M2) a dicho lector (130) que comprende una petición de consulta (RQ) de un servidor (124) de modo normal de la red de transacciones (120), y - al recibir (F540) un mensaje (M3) que indica que la consulta del servidor (124) del modo normal ha fallado, enviar (F570) a dicho lector (130) un criptograma (CR) que comprende al menos una información sobre dicho procedimiento (PMS).

Description

DESCRIPCIÓN
Método de gestión de un procedimiento de un modo de emergencia de transacción y dispositivo asociado Antecedentes de la invención
La presente invención se refiere al campo de las transacciones realizadas por medio de un dispositivo electrónico y, más particularmente, se refiere a un método de gestión de un procedimiento de un modo de emergencia de transacción, que puede activarse en caso de ataque o de avería en una red de transacciones.
De manera conocida, numerosas transacciones bancarias se realizan en línea, por medio de un dispositivo electrónico, a través de una red bancaria electrónica.
La red bancaria electrónica es un objetivo para piratas informáticos que tienen motivaciones económicas o políticas. En efecto, un ataque informático a una red bancaria electrónica puede tener malas repercusiones económicas a escala nacional. Cuando el país es un país desarrollado en donde la mayor parte de las transacciones se realizan por vía electrónica, un ataque de este tipo normalmente puede paralizar la economía del país.
Además del coste económico, un ataque o una avería informáticos en una red bancaria electrónica tiene un impacto negativo sobre la experiencia de los usuarios de la red bancaria y sobre la reputación de una institución bancaria que usa la red bancaria.
Por tanto, existe la necesidad de una solución que permita mejorar la resistencia de las redes bancarias electrónicas, limitando el impacto negativo de un ataque informático sobre los usuarios y de la institución bancaria.
El documento US 2011/321173 describe un sistema de venta al por menor multimodal. El documento “ EMV Integrated Circuit Card Specifications For Payment Systems Book 3 Application Specification Version 4.3” (XP055527907), publicado el 1 de noviembre de 2011, describe una tarjeta con circuito integrado en el contexto de la norma EMV. El documento US 2008/076425 describe un método para gestionar recursos.
Objeto y resumen de la invención
La presente invención se refiere a un método de gestión de un procedimiento de emergencia de un modo de emergencia de transacción, que puede activarse en caso de ataque informático o de avería en una red de transacciones, puesto en práctica por un dispositivo electrónico con capacidad para realizar una transacción según un modo normal o el modo de emergencia, comprendiendo dicho método las siguientes etapas:
• recibir una orden de activación de dicho procedimiento de modo de emergencia, que comprende un identificador del procedimiento y un primer dato cifrado,
• verificar la orden de activación, que comprende una verificación de dicho primer dato cifrado,
• si la verificación de la orden es satisfactoria, activar el procedimiento de emergencia.
La activación de un procedimiento de un modo de emergencia, a nivel del cual el ataque o la avería no tiene ningún impacto, permite mejorar la resistencia de la red de transacciones. Esta activación permite limitar el impacto negativo de un ataque informático sobre los usuarios y la institución bancaria, pudiendo los usuarios seguir realizando operaciones por medio del procedimiento de emergencia.
En un modo de realización particular, el primer dato cifrado es un código de autenticación calculado en función de una clave privada, obteniéndose dicha clave privada usando el identificador de dicho procedimiento.
En un modo de realización particular, la etapa de verificación comprende una verificación de que el valor del identificador de dicho procedimiento es superior al valor de un identificador de procedimiento almacenado en el dispositivo electrónico.
En un modo de realización particular, el método comprende, tras la activación del procedimiento de emergencia y después de una inicialización de una transacción entre el dispositivo electrónico y un lector, una etapa de envío de un mensaje a dicho lector que comprende una petición de consulta de un servidor de modo normal de la red de transacciones.
En un modo de realización particular, el método comprende, al recibir un mensaje que indica que la consulta del servidor del modo normal ha fallado, una etapa de envío a dicho lector de un criptograma que comprende al menos una información sobre dicho procedimiento de las siguientes informaciones:
• una fecha de inicio de dicho procedimiento,
• una fecha de fin de dicho procedimiento,
• dicho identificador de dicho procedimiento,
• una indicación según la cual se genera dicho criptograma durante la puesta en práctica de dicho procedimiento. En un modo de realización particular, dicho mensaje recibido comprende una fecha de transacción, comprendiendo el método las siguientes etapas:
• verificar que la fecha de transacción está comprendida entre una fecha de inicio y una fecha de fin del procedimiento, • si la fecha de transacción es anterior a la fecha de inicio o posterior a la fecha de fin del procedimiento, desactivar dicho procedimiento.
En un modo de realización particular, el mensaje recibido comprende el importe de la transacción, comprendiendo el método las siguientes etapas:
• incrementar un contador de número de transacción,
• incrementar un contador de importe de transacción,
• si el contador de número de transacción incrementado es inferior a un valor umbral de número de transacción y si el contador de importe de transacción es inferior a un valor umbral de importe de transacción, una etapa de aceptación de la transacción.
En un modo de realización particular, el método comprende una etapa de autenticación de un usuario del dispositivo electrónico, poniéndose en práctica la etapa de verificación de la orden de activación si la etapa de autenticación es satisfactoria.
En un modo de realización particular, el método comprende una etapa de desactivación de dicho procedimiento, al recibir una orden de desactivación de dicho procedimiento.
La invención además se refiere a un dispositivo electrónico, con capacidad para poner en práctica un método tal como el que se ha descrito anteriormente.
En un modo de realización particular, las diferentes etapas del método de gestión se determinan mediante instrucciones de programas informáticos.
Por consiguiente, la invención también se refiere a un programa informático en un soporte de información (o soporte de grabación), siendo este programa susceptible de ponerse en práctica mediante un dispositivo electrónico o, de manera más general, en un ordenador, constando este programa de instrucciones adaptadas para la puesta en práctica de las etapas de un método de gestión tal como el que se ha definido anteriormente.
Este programa puede usar 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 de manera particular, o en cualquier otra forma deseable.
La invención también se refiere a un soporte de información (o soporte de grabación) legible por un dispositivo electrónico o, de manera más general, por un ordenador, y que consta de instrucciones de un programa informático tal como ha mencionado anteriormente.
El soporte de información puede ser cualquier entidad o dispositivo que pueda almacenar el programa. Por ejemplo, el soporte puede constar de un medio de almacenamiento, tal como una memoria no volátil regrabable (de tipo “ EEPROM” o “ Flash NAND” , por ejemplo), o tal como una “ ROM” , por ejemplo, un “CD ROM” o una “ ROM” de circuito microelectrónico, o incluso un medio de grabación magnético, por ejemplo, un disquete (“floppy disc” ) o un disco duro.
Por otra parte, el soporte de información puede ser un soporte transmisible tal como una señal eléctrica u óptica, que puede dirigirse a través de un cable eléctrico u óptico, por radio o mediante otros medios. En particular, el programa según la invención puede descargarse en una red de tipo Internet.
Como alternativa, el soporte de información puede ser un circuito integrado en donde está incorporado el programa, estando el circuito adaptado para ejecutar o para usarse en la ejecución del método en cuestión.
Breve descripción de los dibujos
Otras características y ventajas de la presente invención se desprenderán de la descripción realizada a continuación, con referencia a los dibujos adjuntos que ilustran un ejemplo de realización de la misma carente de cualquier carácter limitativo. En las figuras:
- las figuras 1 y 2 representan, de manera esquemática, sistemas de gestión conforme a unos ejemplos de unos modos de realización de la invención;
- las figuras 3 y 4 representan, en forma de organigrama, las principales etapas de fases de activación de métodos de gestión conforme a unos ejemplos de unos modos de realización de la invención;
- la figura 5 representa, en forma de organigrama, las principales etapas de una fase de pago de métodos de gestión conforme a unos ejemplos de unos modos de realización de la invención;
- la figura 6 representa, en forma de organigrama, las principales etapas de una fase de desactivación de métodos de gestión conforme a unos ejemplos de unos modos de realización de la invención;
- la figura 7 representa, de manera esquemática, los datos usados durante una etapa de generación de un criptograma de métodos de gestión conforme a unos ejemplos de unos modos de realización de la invención.
Descripción detallada de varias realizaciones
Las figuras 1 y 2 representan, de manera esquemática, sistemas 100 o 100' de gestión conforme a unos ejemplos de unos modos de realización de la invención, con capacidad para poner en práctica unos métodos de gestión conforme a unos ejemplos de unos modos de realización, por ejemplo, el método descrito con referencia a las figuras 2, 4 y 5 para el sistema 100 de la figura 1, o el método descrito con referencia a las figuras 3, 4 y 5 para el sistema 100' de la figura 2.
El sistema 100, 100' comprende un primer dispositivo electrónico 110, que presenta la arquitectura convencional de un ordenador. El primer dispositivo electrónico 110 comprende, concretamente, un procesador 112, una memoria de solo lectura 114 (de tipo “ ROM” ), una memoria no volátil regrabable 115 (de tipo “ EEPROM” o “ Flash NAND” , por ejemplo), una memoria volátil regrabable 116 (de tipo “ RAM” ) y una interfaz de comunicación 118.
En este ejemplo, la memoria de solo lectura 114 constituye un soporte de información (o de grabación) conforme a un modo de realización particular de la invención. En la memoria de solo lectura 114 está almacenado un programa informático P1 que permite al primer dispositivo electrónico 110 poner en práctica un método de gestión conforme a un ejemplo de un modo de realización de la invención, o al menos una parte de este método de gestión. En una variante, el programa informático P1 está almacenado en la memoria no volátil regrabable 115.
El primer dispositivo electrónico 110 tiene la capacidad de realizar una transacción según un modo normal de transacción o un modo de emergencia de transacción.
La expresión “ modo de transacción” designa en el presente documento un conjunto de reglas aplicadas durante la puesta en práctica de una transacción.
El modo normal de transacción es el modo de transacción usado por el dispositivo electrónico 110 en condiciones normales de uso. El conjunto de reglas aplicadas durante el uso del modo normal normalmente está definido en una especificación, por ejemplo, la especificación EMV.
El modo de emergencia de transacción es un modo de transacción usado en lugar del modo normal de transacción cuando no puede usarse el modo normal de transacción, normalmente en caso de ataque informático o de avería en la red de transacciones. El conjunto de reglas que pueden aplicarse durante el uso del modo de emergencia se describe a continuación, con referencia a las figuras 3 a 6.
Con el fin de realizar una transacción en modo normal o en modo de emergencia, el primer dispositivo electrónico 110 puede usar una aplicación para la realización de las transacciones, normalmente almacenada en la memoria de solo lectura 114 o en la memoria no volátil regrabable 115 del primer dispositivo electrónico 110. Una aplicación de este tipo es implementada, por ejemplo, por un operador de transacciones tal como una institución bancaria, normalmente una institución bancaria que gestiona una cuenta bancaria del usuario del primer dispositivo electrónico 110, pudiendo a continuación ser descargada esta aplicación por el primer dispositivo electrónico 110. La aplicación comprende normalmente el programa P1.
La aplicación puede comprender uno o varios datos asociados al modo de emergencia de entre los siguientes datos: un identificador de un procedimiento PMS del modo de emergencia,
una fecha de inicio de dicho procedimiento PMS,
una fecha de fin de dicho procedimiento PMS,
un valor umbral de un número de transacciones que pueden realizarse durante dicho procedimiento PMS,
un valor umbral de un importe total de transacción que puede cargarse durante dicho procedimiento PMS,
un contador de número de transacción,
un contador de importe de transacción.
La aplicación además puede comprender una primera clave dedicada al modo de emergencia, una segunda clave dedicada al modo de emergencia y/o un indicador de modo de emergencia que normalmente puede adoptar el valor “0” o “ 1 ” .
En una variante, estos datos están almacenados en la memoria de solo lectura 114 o en la memoria no volátil regrabable 115 del primer dispositivo electrónico 110, fuera de la aplicación.
El modo normal de transacción y el modo de emergencia de transacción normalmente se gestionan mediante servidores distintos de una red de transacciones 120, usando la red de transacción 120 una red de telecomunicaciones 126 y siendo, normalmente, una red bancaria electrónica.
Una red bancaria electrónica normalmente usa una red de telecomunicaciones privada 126, usada por al menos un operador de transacciones bancarias, pudiendo cada operador de transacciones bancarias ser una institución bancaria o un proveedor de servicios (que garantiza, por ejemplo, las compensaciones interbancarias). Las redes Visa o Mastercard son ejemplos de redes bancarias electrónicas.
El modo de emergencia de transacción está gestionado, concretamente, por al menos un servidor 122 de modo de emergencia de la red de transacciones, mientras que el modo normal de transacción está gestionado, concretamente, por un servidor 124 de modo normal de la red de transacciones.
Se realiza además una transacción por medio de un lector 130 asociado a la otra parte de la transacción (distinta del usuario del primer dispositivo electrónico 110). Normalmente, el lector 130 es un teléfono portátil, por ejemplo, de tipo “smartphone” , un ordenador de tipo tableta digital o un ordenador personal.
Por tanto, el sistema 100 o 100' además puede comprender el servidor 122 del modo de emergencia, el servidor 124 del modo normal y/o el lector 130.
El servidor 122 del modo de emergencia, el servidor 124 del modo normal y/o el lector 130 también pueden presentar la arquitectura convencional de un ordenador y entonces pueden constar, cada uno, concretamente de un procesador, una memoria de solo lectura (de tipo “ROM” ), una memoria no volátil regrabable (de tipo “ EEPROM” o “Flash NAND” , por ejemplo), una memoria volátil regrabable (de tipo “RAM” ) y una interfaz de comunicación.
Cada memoria de solo lectura puede constituir un soporte de grabación conforme a un ejemplo de un modo de realización de la invención, legible por el procesador asociado y en donde está grabado un programa informático conforme a un ejemplo de un modo de realización de la invención. En una variante, el programa informático está almacenado en la memoria no volátil regrabable asociada. El programa informático puede permitir la puesta en práctica de al menos una parte del método de gestión conforme a un ejemplo de un modo de realización de la invención.
Tal como se muestra en la figura 1, el primer dispositivo electrónico 110 es, por ejemplo, un terminal fijo o móvil tal como un teléfono portátil, por ejemplo, de tipo “smartphone” , un ordenador de tipo tableta digital o un ordenador personal.
El primer dispositivo electrónico 110 tiene entonces la capacidad de comunicarse con el servidor 122 del modo de emergencia a través de una primera red de telecomunicaciones 140, siendo esta primera red de telecomunicaciones 140 normalmente una red de largo alcance, tal como una red de Internet, una red Wifi o una red de telefonía fija o móvil (de tipo 3G, 4G, etc.).
Además, el primer dispositivo electrónico 110 y el lector 130 tienen la capacidad de comunicarse entre sí a través de la primera red de telecomunicaciones 140 o a través de una segunda red de telecomunicaciones 150. La segunda red de telecomunicaciones 150 es normalmente una red de corto alcance, tal como una red de NFC (siglas de “ Near Field Communication” en terminología anglosajona).
Además, el lector 130, el servidor 124 del modo normal y/o el servidor 122 del modo de emergencia tienen la capacidad de comunicarse entre sí a través de la red de telecomunicaciones 126 usada por la red de transacciones 120, denominándose en lo sucesivo esta red de telecomunicaciones 126 tercera red de telecomunicaciones 126.
En una variante, tal como se muestra en la figura 2, el primer dispositivo electrónico 110 puede ser una tarjeta inteligente (normalmente una tarjeta bancaria), por ejemplo, de formato ID-1 especificado en la norma ISO/IEC 7810, que presenta unas dimensiones de 85,6 milímetros por 53,98 milímetros por 0,76 milímetros.
El sistema 100' entonces puede comprender además un segundo dispositivo electrónico 160, siendo este segundo dispositivo electrónico 160 un terminal fijo o móvil tal como un teléfono portátil, por ejemplo, de tipo “ smartphone” , un ordenador de tipo tableta digital o un ordenador personal.
El primer dispositivo electrónico 110 y el segundo dispositivo electrónico 160 pueden comunicarse entre sí a través de una cuarta red de telecomunicaciones 170, siendo normalmente esta cuarta red de telecomunicaciones 170 una red de corto alcance, tal como una red de NFC. La cuarta red de telecomunicaciones 170 puede ser la misma red que la segunda red de telecomunicaciones 150 o una red distinta.
Además, el segundo dispositivo electrónico 160 tiene la capacidad de comunicarse con el servidor 122 del modo de emergencia a través de la primera red de telecomunicaciones 140. El segundo dispositivo electrónico 160 puede comprender una aplicación asociada con el operador de transacciones.
Además, el primer dispositivo electrónico 110 y el lector 130 tienen la capacidad de comunicarse entre sí a través de la primera red de telecomunicaciones 140, la segunda red de telecomunicaciones 150 o directamente por medio de contactos cuando se inserta el primer dispositivo electrónico 110 en el lector 130.
Además, el lector 130, el servidor 124 del modo normal y/o el servidor 122 del modo de emergencia tienen la capacidad de comunicarse entre sí a través de la tercera red de telecomunicaciones 126.
Las figuras 3, 5 y 6, así como las figuras 4, 5 y 6, representan métodos de gestión de un procedimiento de un modo de emergencia de transacción conforme a unos ejemplos de unos modos de realización de la invención.
La figura 3 representa una fase de activación de un método de gestión conforme a un ejemplo de un modo de realización de la invención, permitiendo esta fase de activación activar un procedimiento PMS de emergencia del modo de emergencia, normalmente en caso de ataque informático a la red de transacciones o de avería en la red de transacciones.
A continuación, en la descripción de la figura 3, se considera que dicha fase de activación se pone en práctica mediante el sistema 100 de gestión de la figura 1.
No obstante, el método puede ponerse en práctica mediante cualquier sistema de gestión que conste de un terminal con capacidad para realizar una transacción según el modo normal de transacción o el modo de emergencia de transacción. En una etapa 310, se detecta un ataque informático o una avería en la red de transacciones 120 (normalmente a nivel del servidor 124 del modo normal).
Entonces, el servidor 122 del modo de emergencia puede activar, en una etapa E320, el procedimiento PMS del modo de emergencia a nivel del servidor 122 del modo de emergencia, normalmente después de haber pedido una autorización de activación a una o varias personas responsables de tal activación.
El procedimiento de modo de emergencia es un procedimiento puesto en práctica durante un periodo predeterminado durante el cual no puede usarse el modo normal de transacción, debido a la avería o al ataque. Por tanto, cada procedimiento activado en la etapa E320 está asociado a una única avería o ataque detectado en la etapa 310.
A continuación, el servidor 122 del modo de emergencia puede determinar una orden de activación CA del procedimiento PMS del modo de emergencia (etapa E330). La orden de activación CA es normalmente una orden similar a las órdenes de secuencia de comandos definidas por la norma EMV, estando los parámetros de la orden de activación normalmente definidos por la norma ISO 7816. Esta orden de activación CA comprende un identificador del procedimiento PMS y un primer dato cifrado.
El identificador del procedimiento PMS permite identificar el procedimiento PMS del modo de emergencia de entre uno o varios otros procedimientos eventuales del modo de emergencia (asociados a otras averías o ataques). En efecto, se activa un nuevo procedimiento del modo de emergencia con cada detección de un nuevo ataque informático o de una nueva avería en la red de transacciones y, por tanto, con cada nueva puesta en práctica de la etapa 310. Por tanto, el identificador del procedimiento PMS es normalmente un número, incrementado con cada nueva puesta en práctica de la etapa 310.
El primer dato cifrado es normalmente un código de autenticación calculado en función de una clave privada, obteniéndose dicha clave privada usando el identificador del procedimiento PMS.
Por ejemplo, el código de autenticación es un código de autenticación de mensaje (“ MAC” siglas de “ Message Authentication Code” en terminología anglosajona). El código MAC puede calcularse usando una clave de sesión derivada a partir de la primera clave dedicada al modo de emergencia, usándose el identificador del procedimiento PMS como valor de derivación. La primera clave es normalmente una clave simétrica, usada para calcular la totalidad de los datos de la orden de activación CA.
La orden de activación CA además puede comprender uno o varios datos referentes al procedimiento PMS de emergencia de entre los siguientes datos:
• una fecha de inicio del procedimiento PMS,
• una fecha de fin del procedimiento PMS,
• un valor umbral de un número de transacciones que pueden realizarse durante dicho procedimiento PMS, • un valor umbral de un importe total de transacción que puede cargarse durante dicho procedimiento PMS.
La orden de activación CA comprende, por ejemplo, un campo CLA que define la clase de la instrucción, un campo INS que define la instrucción (siendo esta instrucción la activación del procedimiento PMS del modo de emergencia), unos campos P1 y P2 que definen parámetros de la instrucción, un campo LC que define la longitud de la orden de activación CA, un campo DATA que comprende el identificador del procedimiento PMS de emergencia y eventualmente uno o varios datos referentes al procedimiento PMS de emergencia anteriormente mencionados, y un campo MAC que comprende el primer dato cifrado.
A continuación, el servidor 122 del modo de emergencia puede enviar, en una etapa E340 y al primer dispositivo electrónico 110 (normalmente a la aplicación del primer dispositivo electrónico 110), a través de la primera red de telecomunicaciones 140, un primer mensaje M1 que comprende la orden de activación CA.
El primer mensaje M1 además puede comprender un mensaje de información destinado al usuario del primer dispositivo electrónico 110, que normalmente indica que el procedimiento PMS del modo de emergencia puede activarse en el primer dispositivo electrónico 110.
Al recibir F340 el primer mensaje M1, el primer dispositivo electrónico 110 puede visualizar el mensaje de información. El primer dispositivo electrónico 110 también puede autenticar al usuario del primer dispositivo electrónico 110 (etapa F350). La autenticación del usuario se pone en práctica, por ejemplo, por medio de un código de autenticación o de un dato biométrico del usuario.
En una etapa F360, el primer dispositivo electrónico 110 verifica la orden de activación CA recibida, poniéndose normalmente en práctica esta etapa E360 si se autentica al usuario. Esta etapa F360 de verificación comprende una verificación del primer dato cifrado.
Normalmente, el primer dispositivo electrónico 110 calcula un segundo dato cifrado y después compara este segundo dato cifrado con el primer dato cifrado. Si el segundo dato cifrado es idéntico al primer dato cifrado, se verifica el primer dato cifrado. Por tanto, el segundo dato cifrado normalmente es un código de autenticación calculado en función de una clave privada, obteniéndose dicha clave privada usando el identificador del procedimiento PMS, tal como el código MAC, calculado usando una clave de sesión derivada a partir de la primera clave dedicada al modo de emergencia, usándose el identificador del procedimiento PMS como valor de derivación.
Además, la etapa F360 de verificación puede comprender una verificación de que el valor del identificador de dicho procedimiento PMS es superior al valor del identificador de procedimiento almacenado en el primer dispositivo electrónico 110, que corresponde en esta fase del método a la detección anterior 310 de ataque informático o de avería en la red de transacciones.
La etapa F360 de verificación también puede comprender una verificación de que el procedimiento PMS no está ya activado.
Para más precisión, el primer dispositivo electrónico 110 verifica si el indicador del modo de emergencia no tiene el valor “ 1 ” . Esta verificación permite controlar un eventual ataque a nivel del primer dispositivo electrónico 110. En efecto, tal como se describe a continuación, la activación del procedimiento PMS puede comprender una reinicialización de uno o varios datos asociados al modo de emergencia, tales como, por ejemplo, el importe total de transacción. La verificación del indicador del modo de emergencia permite impedir varias reinicializaciones sucesivas maliciosas de estos datos.
Si la verificación de la orden de activación CA es satisfactoria, el primer dispositivo electrónico 110 activa el procedimiento PMS de emergencia a nivel del primer dispositivo electrónico 110 (etapa F370).
Esta etapa F370 de activación puede comprender una inicialización o una reinicialización de uno o varios datos almacenados por el dispositivo electrónico 110 y asociados al modo de emergencia. Por ejemplo:
• las fechas de inicio y de fin del procedimiento PMS almacenadas por el dispositivo electrónico 110 pueden actualizarse en función de las fechas de inicio y de fin del procedimiento PMS recibidas en la etapa F340,
• el contador de número de transacción y el contador de importe de transacción pueden ponerse a cero,
• el valor umbral de un número de transacciones y el valor umbral de un importe total de transacción almacenados por el dispositivo electrónico 110 pueden actualizarse en función del valor umbral de un número de transacciones y del valor umbral de un importe total de transacción recibidos en la etapa F340, y/o
• el identificador del procedimiento del modo de emergencia almacenado por el dispositivo electrónico puede actualizarse en función del identificador del procedimiento recibido en la etapa F340, y/o
• el valor del indicador del modo de emergencia se pone en “ 1 ” .
La figura 4 representa una variante de la fase de activación, puesta en práctica por el sistema 100' de la figura 2 o por cualquier sistema de gestión que conste de una tarjeta inteligente con capacidad para realizar una transacción según el modo normal de transacción o el modo de emergencia de transacción.
Esta variante de fase de activación difiere de la fase de activación descrita con referencia a la figura 3 en que el servidor 122 del modo de emergencia envía, en la etapa E440, el primer mensaje M1 al segundo dispositivo electrónico 160 (por ejemplo, a la aplicación del segundo dispositivo electrónico 160) a través de la primera red de telecomunicaciones 140. Por tanto, el servidor 122 del modo de emergencia puede poner en práctica las etapas E320 y/o E330 anteriormente descritas con referencia a la figura 3 tras la etapa 310 y antes de la etapa E440. Tras la recepción G440 del primer mensaje M1, el segundo dispositivo electrónico 160 puede visualizar el mensaje de información y/o autenticar al usuario del primer dispositivo electrónico 110 (etapa G450), normalmente por medio de un código de autenticación o de un dato biométrico del usuario.
A continuación, el segundo dispositivo electrónico 160 puede emitir una notificación solicitando al usuario que posicione el primer dispositivo electrónico 110 cerca del segundo dispositivo electrónico 160 de manera que puedan comunicarse a través de la tercera red de telecomunicaciones 170.
El segundo dispositivo electrónico 160 transmite la orden de activación CA en una etapa G455, a través de la cuarta red de telecomunicaciones 170, al primer dispositivo electrónico 110, poniéndose normalmente en práctica esta etapa G455 cuando se autentica al usuario. Entonces, el primer dispositivo electrónico 110 pone en práctica las etapas F360 y F370, anteriormente descritas con referencia a la figura 3.
La figura 5 representa una fase de pago de métodos de gestión conforme a unos ejemplos de unos modos de realización de la invención. Dicha fase de pago puede ponerse en práctica mediante el sistema 100 de la figura 1 o el sistema 100' de la figura 2, después de la fase de activación del procedimiento PMS del modo de emergencia de la figura 3 o de la figura 4. En una etapa H510, el lector 130 envía una primera orden CT1 de transacción, siendo normalmente esta primera orden CT1 la orden de “ Generar AC” . La primera orden CT1 de transacción normalmente se envía a través de la segunda red de telecomunicaciones 150.
Pueden intercambiarse varias otras órdenes entre el lector 130 y el primer dispositivo electrónico 110 antes del envío de la primera orden CT1 “ Generar AC” . La primera orden CT1 “ Generar AC” permite realizar la transacción y proporcionar un resultado.
La etapa H510 se pone en práctica cuando el usuario del primer dispositivo electrónico 110 desea realizar una transacción con el usuario del lector 130 y, por tanto, se envía tras una inicialización de una transacción entre el primer dispositivo electrónico 110 y el lector 130.
Tras la recepción F510 de la primera orden CT1 de transacción, el primer dispositivo electrónico 110 ejecuta dicha primera orden CT1 de transacción en una etapa F520.
Al estar activado el procedimiento PMS del modo de emergencia, el primer dispositivo electrónico 110 envía, durante la ejecución de la primera orden CT1 de transacción, un segundo mensaje M2 que comprende una petición de consulta RQ del servidor 124 del modo normal de transacción. El segundo mensaje M2 puede enviarse al lector 130, a través de la segunda red de telecomunicaciones 150.
El lector 130 recibe el segundo mensaje M2 (etapa H520) y después intenta conectarse al servidor 124 del modo normal enviando al servidor 124 del modo normal la petición de consulta RQ del mensaje M2 (etapa H530) a través de la tercera red de telecomunicaciones 126.
Al estar activado el procedimiento PMS del modo de emergencia, el servidor 124 del modo normal no responde a la petición de consulta RQ y falla el intento de conexión del lector 130 al servidor 124 del modo normal.
Entonces, el lector 130 envía, al primer dispositivo electrónico 110, normalmente a través de la segunda red de telecomunicaciones 150, un tercer mensaje M3 que comprende una segunda orden de transacción, y que puede comprender al menos un dato de transacción (etapa H540). La segunda orden es normalmente una orden “Generar AC” e indica que la conexión al servidor 124 del modo normal ha fallado.
Tras la recepción F540 del tercer mensaje M3, en una etapa F550, el primer dispositivo electrónico 110 ejecuta la segunda orden procediendo a al menos una verificación asociada con la transacción (etapa F550).
Cada verificación normalmente se basa en un dato de transacción del tercer mensaje M3, siendo el dato, por ejemplo, una fecha de la transacción o un importe de la transacción.
Por ejemplo, el primer dispositivo electrónico 110 verifica que la fecha de transacción está comprendida entre la fecha de inicio del procedimiento PMS y la fecha de fin del procedimiento PMS almacenadas en el primer dispositivo electrónico 110.
Si la fecha de transacción es anterior a la fecha de inicio o posterior a la fecha de fin del procedimiento PMS, el primer dispositivo electrónico 110 desactiva dicho procedimiento PMS, normalmente poniendo el indicador del modo de emergencia a “0” . A continuación, la transacción se trata en modo normal.
El primer dispositivo electrónico 110 también puede incrementar el contador de número de transacciones en una unidad.
A continuación, el primer dispositivo electrónico 110 puede verificar que el contador de número de transacción incrementado es inferior al valor umbral de número de transacción.
Si el contador de número de transacción incrementado es superior al valor umbral de número de transacción, el primer dispositivo electrónico 110 desactiva el procedimiento PMS del modo de emergencia, normalmente poniendo el indicador del modo de emergencia a “0” , y a continuación, la transacción se trata en modo normal.
El primer dispositivo electrónico 110 también puede incrementar el contador de importe de transacción, con el importe de la transacción del tercer mensaje M3, y después verificar que el contador de número de transacción incrementado es inferior al valor umbral de número de transacción y que el contador de importe de transacción es inferior a un valor umbral de importe de transacción.
Si el contador de importe de transacción incrementado es superior al valor umbral de importe de transacción, el primer dispositivo electrónico 110 desactiva el procedimiento PMS del modo de emergencia, normalmente poniendo el indicador del modo de emergencia a “0” , y a continuación la transacción se trata en modo normal.
En el caso en el que la o las verificaciones realizas son satisfactorias, el primer dispositivo electrónico 110 puede aceptar la transacción.
Tras la recepción del tercer mensaje M3, normalmente después de la puesta en práctica de la o las verificaciones, el primer dispositivo electrónico 110 puede generar un criptograma CR, en una etapa F560, generándose dicho criptograma CR por medio de la segunda clave dedicada al modo de emergencia, siendo normalmente dicha segunda clave simétrica.
El criptograma CR generado comprende al menos una información sobre el procedimiento PMS del modo de emergencia, de las siguientes informaciones sobre el procedimiento PMS del modo de emergencia:
• la fecha de inicio de dicho procedimiento PMS,
• la fecha de fin de dicho procedimiento PMS,
• el identificador de dicho procedimiento PMS,
• una indicación según la cual se genera dicho criptograma CR durante la puesta en práctica de dicho procedimiento PMS.
El criptograma CR se genera y se envía en caso de aceptación de la transacción, pero también en caso de rechazo de la transacción.
La figura 7 representa un ejemplo de datos D1 a D11 usados para la generación del criptograma. Los datos D1 a D8 proceden del lector 130 y los datos D9 a D11 son datos del primer dispositivo electrónico 110, tal como se define en el documento “ EMV 4.3, Book 2, 8.1.1” .
El dato D11, referente a la aplicación del primer dispositivo electrónico 110, comprende 32 bytes, estando reservados los bytes 18 a 32 para el operador de transacciones que ha implementado la aplicación, tal como se define en el documento “ EMV 4.3, Book 3, C7.2” . Estos bytes 18 a 32 comprenden una o varias informaciones de las informaciones sobre el procedimiento PMS tal como se describieron anteriormente.
Además, los bytes 4 a 8, del campo CVR (siglas de “ Card Verification Results” , en terminología anglosajona) del dato D11, pueden comprender una información sobre el tipo de criptograma, una información según la cual se rechaza la transacción (dato AAC), una información según la cual se acepta la transacción (dato TC), una indicación según la cual se genera dicho criptograma CR durante la puesta en práctica de dicho procedimiento PMS, etc. Normalmente, el valor “ RFU” en el campo “ CVR Byte 1” del campo CVR puede comprender una información según la cual se acepta la transacción en modo de urgencia.
A continuación, el primer dispositivo electrónico 110 envía al lector 130, normalmente a través de la primera red 140 o la segunda red 150, un cuarto mensaje M4 que comprende el criptograma CR y que además puede comprender una información según la cual se desarrolla la transacción durante el procedimiento PMS del modo de emergencia (etapa F570).
El lector 130 recibe el cuarto mensaje M4 (etapa H570) y graba el criptograma CR (etapa H580). En caso de validación de la transacción, el lector 130 transmite a la red de transacciones 120 (normalmente al servidor 124 del modo normal) informaciones referentes a la transacción después de la desactivación del procedimiento PMS del modo de emergencia, de manera que el servidor 124 del modo normal pueda tratar la transacción una vez que la red de transacciones 120 tenga la capacidad de funcionar de nuevo normalmente. Entonces, el servidor 124 del modo normal verifica el criptograma CR.
Tal como se muestra en la figura 6 , después de haber tratado la avería o el ataque, cuando la red de transacciones 120 tiene la capacidad de funcionar de nuevo normalmente, el servidor 122 del modo de emergencia desactiva, en una etapa E610, el procedimiento PMS del modo de emergencia.
El servidor 124 del modo normal tiene entonces capacidad para responder a peticiones de consulta tales como la petición de consulta RQ enviada por el lector 130 en la etapa H530.
Por tanto, tras la recepción I630 de la petición de consulta RQ enviada en la etapa H530, el servidor 124 del modo normal envía al lector 130 una orden de desactivación CDA del procedimiento PMS del modo de emergencia, normalmente a través de la tercera red de telecomunicaciones 126 (etapa I640), transmitiendo el lector 130 (etapa H640) dicha orden de desactivación CDA al primer dispositivo electrónico 110, normalmente a través de la segunda red de telecomunicaciones 150.
El primer dispositivo electrónico 110 recibe F640 la orden de desactivación CDA y después la ejecuta con el fin de desactivar el procedimiento PMS del modo de emergencia (etapa F650). A continuación, la transacción se trata entonces en modo normal.
La orden de desactivación CDA es normalmente una orden de secuencia de comandos similar a las órdenes de secuencia de comandos definidas por la norma EMV.
En una variante, cuando el servidor 122 del modo de emergencia desactiva el procedimiento PMS del modo de emergencia, el servidor 122 del modo de emergencia envía al primer dispositivo electrónico 110 la orden de desactivación CDA, normalmente a través de la primera red de telecomunicaciones 140. La orden de desactivación CDA puede enviarse al recibir la petición de consulta RQ o puede enviarse tras la desactivación del procedimiento PMS por el servidor 122 del modo de emergencia, aunque no haya ninguna transacción en curso referente al primer dispositivo electrónico 110.

Claims (11)

  1. REIVINDICACIONES
    i. Método de gestión de un procedimiento de emergencia de un modo de emergencia de transacción, que puede activarse en caso de ataque informático o de avería en una red de transacciones (120), puesto en práctica por un dispositivo electrónico (110) con capacidad para realizar una transacción según un modo normal o el modo de emergencia, comprendiendo dicho método las siguientes etapas:
    • recibir (F340, F455) una orden de activación (CA) de dicho procedimiento del modo de emergencia, que comprende un identificador del procedimiento y un primer dato cifrado,
    • verificar (F360) la orden de activación (CA), que comprende una verificación de dicho primer dato cifrado,
    • si la verificación de la orden es satisfactoria, activar (F370) el procedimiento (PMS) de emergencia,
    • tras la activación (F370) del procedimiento (PMS) de emergencia y después de una inicialización de una transacción entre el dispositivo electrónico (110) y un lector (130), enviar (F520) un mensaje (M2) a dicho lector (130) que comprende una petición de consulta (RQ) de un servidor (124) de modo normal de la red de transacciones (120), y
    • al recibir (F540) un mensaje (M3) que indica que la consulta del servidor (124) del modo normal ha fallado, enviar (F570) a dicho lector (130) un criptograma (CR) que comprende al menos una información sobre dicho procedimiento (PMS).
  2. 2. Método según la reivindicación 1, en donde el primer dato cifrado es un código de autenticación calculado en función de una clave privada, obteniéndose dicha clave privada usando el identificador de dicho procedimiento.
  3. 3. Método según la reivindicación 1 o 2, en donde la etapa de verificación (F360) comprende una verificación de que el valor del identificador de dicho procedimiento (PMS) es superior al valor de un identificador de procedimiento almacenado en el dispositivo electrónico (110).
  4. 4. Método según una cualquiera de las reivindicaciones 1 a 3, en donde la al menos una información sobre dicho procedimiento (PMS) del criptograma es una información de entre las siguientes informaciones:
    • una fecha de inicio de dicho procedimiento (PMS),
    • una fecha de fin de dicho procedimiento (PMS),
    • dicho identificador de dicho procedimiento (PMS),
    • una indicación según la cual se genera dicho criptograma (CR) durante la puesta en práctica de dicho procedimiento (PMS).
  5. 5. Método según una cualquiera de las reivindicaciones 1 a 4, en donde dicho mensaje (M3) recibido comprende una fecha de la transacción, comprendiendo el método las siguientes etapas:
    • verificar (F550) que la fecha de transacción está comprendida entre una fecha de inicio y una fecha de fin del procedimiento,
    • si la fecha de transacción es anterior a la fecha de inicio o posterior a la fecha de fin del procedimiento, desactivar dicho procedimiento.
  6. 6. Método según una cualquiera de las reivindicaciones 1 a 5, en donde el mensaje (M3) recibido comprende el importe de la transacción, comprendiendo el método las siguientes etapas:
    • incrementar un contador de número de transacción,
    • incrementar un contador de importe de transacción,
    • si el contador de número de transacción incrementado es inferior a un valor umbral de número de transacción y si el contador de importe de transacción es inferior a un valor umbral de importe de transacción, una etapa de aceptación de la transacción.
  7. 7. Método según una cualquiera de las reivindicaciones 1 a 6, que comprende una etapa de autenticación (F350, G450) de un usuario del dispositivo electrónico,
    poniéndose en práctica la etapa de verificación (F360) de la orden de activación (CA) si la etapa de autenticación (F350, G450) es satisfactoria.
  8. 8. Método según una cualquiera de las reivindicaciones 1 a 7, que comprende una etapa de desactivación (F650) de dicho procedimiento, al recibir (F640) una orden de desactivación (CDA) de dicho procedimiento (PMS).
  9. 9. Dispositivo (110) electrónico con capacidad para poner en práctica un método según una cualquiera de las reivindicaciones 1 a 8.
  10. 10. Programa informático (P1) que consta de instrucciones para la ejecución de las etapas del método según una cualquiera de las reivindicaciones 1 a 8, cuando dicho programa es ejecutado por un ordenador.
  11. 11. Soporte de grabación legible por ordenador en donde está grabado un programa informático (P1) que comprende instrucciones para la ejecución de las etapas del método según una cualquiera de las reivindicaciones 1 a 8.
ES19175995T 2018-06-08 2019-05-22 Método de gestión de un procedimiento de un modo de emergencia de transacción y dispositivo asociado Active ES2878161T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1855026A FR3082332B1 (fr) 2018-06-08 2018-06-08 Procede de gestion d'une procedure d'un mode de secours de transaction, et dispositif associe

Publications (1)

Publication Number Publication Date
ES2878161T3 true ES2878161T3 (es) 2021-11-18

Family

ID=63834123

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19175995T Active ES2878161T3 (es) 2018-06-08 2019-05-22 Método de gestión de un procedimiento de un modo de emergencia de transacción y dispositivo asociado

Country Status (5)

Country Link
US (1) US11640597B2 (es)
EP (1) EP3579588B1 (es)
ES (1) ES2878161T3 (es)
FR (1) FR3082332B1 (es)
PT (1) PT3579588T (es)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10511443B1 (en) * 2018-10-02 2019-12-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010027439A1 (en) * 1999-07-16 2001-10-04 Holtzman Henry N. Method and system for computerized form completion
US20080076425A1 (en) * 2006-09-22 2008-03-27 Amit Khetawat Method and apparatus for resource management
US8788428B2 (en) * 2010-06-28 2014-07-22 Dresser, Inc. Multimode retail system
US10956894B2 (en) * 2014-05-22 2021-03-23 Paypal, Inc. Offline bill splitting system
US11049096B2 (en) * 2015-12-31 2021-06-29 Paypal, Inc. Fault tolerant token based transaction systems
JP2018081643A (ja) * 2016-11-18 2018-05-24 キヤノン株式会社 認可サーバーおよびその制御方法、プログラム、並びに権限委譲システム
US11074573B2 (en) * 2017-10-27 2021-07-27 International Business Machines Corporation Processing mobile payments when disconnected from payment servers
EP3968668A4 (en) * 2019-05-29 2022-05-11 Guangdong Oppo Mobile Telecommunications Corp., Ltd. RESOURCE MANAGEMENT METHOD, DEVICE AND SERVER, AND COMPUTER STORAGE MEDIA

Also Published As

Publication number Publication date
US11640597B2 (en) 2023-05-02
FR3082332A1 (fr) 2019-12-13
EP3579588A1 (fr) 2019-12-11
EP3579588B1 (fr) 2021-03-24
US20190378114A1 (en) 2019-12-12
PT3579588T (pt) 2021-06-28
FR3082332B1 (fr) 2020-08-28

Similar Documents

Publication Publication Date Title
ES2894480T3 (es) Procedimiento para realizar la autenticación
CA3027909C (en) Authentication in ubiquitous environment
ES2680152T3 (es) Método y aparato de autenticación conveniente para el usuario usando una aplicación de autenticación móvil
US20170359180A1 (en) Authentication in ubiquitous environment
RU2523304C2 (ru) Доверенный администратор достоверности (tim)
RU2537795C2 (ru) Доверенный дистанционный удостоверяющий агент (traa)
US20130246281A1 (en) Service providing system and unit device
US10057254B2 (en) Mobile terminal for providing one time password and operating method thereof
ES2877522T3 (es) Método y sistema para mejorar la seguridad de una transacción
CN113570377B (zh) 一种校验方法、装置以及设备
KR20160101635A (ko) 보안 회로를 통한 데이터의 저장 및 이용
JP2012094146A (ja) 特に資源の利用に関する利用者の認証によって保護された関数の実行を制御する方法及びシステム
WO2018156384A1 (en) Determining legitimate conditions at a computing device
ES2878161T3 (es) Método de gestión de un procedimiento de un modo de emergencia de transacción y dispositivo asociado
CN108604280B (zh) 交易方法、交易信息处理方法、交易终端及服务器
JP6691582B2 (ja) ユーザー認証方法及び認証管理方法
US20170359358A1 (en) Method for making contactless transactions secure
ES2894035T3 (es) Procedimiento de envío de una información de seguridad y dispositivo electrónico adecuado para implementar un procedimiento de este tipo
KR102348823B1 (ko) 사용자가 소지한 금융 카드 기반 본인 인증 시스템 및 방법
CN108701304B (zh) 认证方法
EP3364329B1 (en) Security architecture for device applications
WO2016070295A1 (es) Método de autenticación de dos factores para aumentar la seguridad de las transacciones entre un usuario y un punto o sistema de transacción
TWI596547B (zh) Card application service anti-counterfeiting writing system and method based on multi-card combination
EP3975012A1 (en) Method for managing a pin code in a biometric smart card
WO2017112174A1 (en) Method and device for facilitating supply of a requested service