ES2912188T3 - Código de seguridad dinámico para una transacción de tarjeta - Google Patents

Código de seguridad dinámico para una transacción de tarjeta Download PDF

Info

Publication number
ES2912188T3
ES2912188T3 ES16306002T ES16306002T ES2912188T3 ES 2912188 T3 ES2912188 T3 ES 2912188T3 ES 16306002 T ES16306002 T ES 16306002T ES 16306002 T ES16306002 T ES 16306002T ES 2912188 T3 ES2912188 T3 ES 2912188T3
Authority
ES
Spain
Prior art keywords
user
security code
time
card
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES16306002T
Other languages
English (en)
Inventor
Emmanuelle Dottax
Paul Dischamp
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 ES2912188T3 publication Critical patent/ES2912188T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • 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/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/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4018—Transaction verification using the card verification value [CVV] associated with the card
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G06Q20/3265—Payment applications installed on the mobile devices characterised by personalisation for use

Landscapes

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

Abstract

Un método para generar un código de seguridad dinámico para una transacción de tarjeta realizada por un usuario que usa un dispositivo (10) electrónico de usuario separado de una tarjeta (35), usando la transacción de tarjeta detalles de tarjeta de la tarjeta (35), en donde el dispositivo electrónico de usuario almacena un identificador (ID), comprendiendo el método, en el dispositivo (10) electrónico de usuario: recibir una solicitud (82) de usuario para generar un código de seguridad dinámico; al recibir la solicitud (83) de usuario, enviar una solicitud (84) de tiempo a una fuente (50) de tiempo externa al dispositivo (10) electrónico de usuario; recibir, en respuesta a la solicitud de tiempo, un mensaje (87) que comprende un tiempo desde la fuente (50) de tiempo; determinar (88) una autenticidad del mensaje que contiene el tiempo; calcular (89) el código de seguridad dinámico en función del tiempo recibido en el mensaje y una clave (dCVV-clave_ID) almacenada en el dispositivo (10) electrónico de usuario; y hacer (90, 91) que el código de seguridad dinámico se visualice en una pantalla (14) del dispositivo electrónico de usuario, en donde el método comprende un proceso de inscripción preliminar que comprende, en el dispositivo (10) electrónico de usuario: recibir datos parciales sobre tarjetas emitidas a un usuario desde una entidad de autorización; recibir entrada de usuario que selecciona al menos una de las tarjetas; y enviar el identificador (ID) a la entidad (40) de autorización; en donde el identificador (ID) puede usarse para asociar la tarjeta seleccionada a la clave usada para calcular el código de seguridad.

Description

DESCRIPCIÓN
Código de seguridad dinámico para una transacción de tarjeta
Antecedentes
El uso fraudulento de tarjetas de pago, tal como tarjetas de crédito y débito, es un problema continuo. Las transacciones de Card not Present (tarjeta no presente - CNP) plantean un riesgo particularmente alto. Una transacción de CNP puede ser una transacción de pago realizada en línea, o una transacción de pago realizada por teléfono. En un caso más simple, una parte fraudulenta puede hacer una transacción fraudulenta adquiriendo solo el Primary Account Number (número de cuenta primaria - PAN) y la fecha de caducidad de la tarjeta de pago. Muchas tarjetas de pago ahora incluyen un Card Verification Value (valor de verificación de tarjeta - CVV) para mejorar la seguridad. El CVV se imprime en el panel de firma de una tarjeta, o en la parte frontal de la tarjeta. Sin embargo, a medida que el CVV es otro valor estático, es posible que una parte fraudulenta adquiera y use el CVV en una transacción de CNP.
Una forma de mejorar la seguridad es generar dinámicamente el código de seguridad. US 2014/0279555 A1 describe una tarjeta que puede generar dinámicamente un código de seguridad. La Figura 1 muestra una tarjeta de este tipo. La tarjeta 1 tiene una banda magnética 2, un panel 3 de firma y una pantalla 4 en miniatura. Cuando un usuario activa un botón 5 en la tarjeta, un procesador dentro de la tarjeta genera un código de seguridad y visualiza el código en la pantalla 4.
Si bien una tarjeta con un generador de código dinámico y una pantalla puede mejorar la seguridad, una desventaja de esta disposición es un mayor coste de las tarjetas.
Otras realizaciones y ejemplos de la técnica anterior pueden encontrarse en US-2011/225089 A1 y US-2016/148194 A1
Sumario
Un aspecto de la invención proporciona un método para generar un código de seguridad dinámico para una transacción de tarjeta como se define en la reivindicación 1.
Opcionalmente, al menos uno de: calcular el código de seguridad dinámico, y hacer que el código de seguridad dinámico se visualice, se realizan solo si el mensaje que comprende el tiempo se determina como auténtico.
El mensaje que comprende el tiempo puede comprender un Message Authentication Code (código de autentificación de mensaje - MAC), y determinar una autenticidad del mensaje puede comprender: calcular un código de autentificación de mensaje en el dispositivo electrónico usando una clave almacenada en el dispositivo electrónico; y comparar el código de autentificación de mensaje calculado con el código de autentificación de mensaje en el mensaje recibido.
El dispositivo electrónico puede almacenar un identificador (ID) y el método puede comprender: enviar una solicitud de tiempo a la fuente de tiempo, incluyendo la solicitud de tiempo el identificador.
El mensaje que comprende el tiempo puede comprender una firma digital y determinar una autenticidad del mensaje puede usar una clave pública de la fuente de tiempo.
El dispositivo electrónico puede ser capaz de calcular un código de seguridad dinámico para una pluralidad de tarjetas diferentes, el dispositivo electrónico puede almacenar una clave maestra, y calcular el código de seguridad dinámico puede comprender derivar una clave para una de las tarjetas seleccionadas usando la clave maestra. El cálculo del código de seguridad dinámico puede comprender derivar una clave para una de las tarjetas seleccionadas usando la clave maestra y un elemento de datos por tarjeta adicional recibido de una entidad de autorización.
El dispositivo electrónico puede ser capaz de calcular un código de seguridad dinámico para una pluralidad de tarjetas diferentes y el método puede comprender: hacer que el dispositivo electrónico visualice una invitación para una entrada de usuario para seleccionar una de la pluralidad de tarjetas; y enviar una solicitud para generar un código de seguridad dinámico para la tarjeta seleccionada.
Al menos la etapa de calcular el código de seguridad dinámico en base al tiempo puede realizarse mediante uno de: un elemento seguro en el dispositivo electrónico; o una partición segura de un procesador de propósito general del dispositivo electrónico.
Otro aspecto proporciona un dispositivo electrónico capaz de generar dinámicamente un código de seguridad para una transacción de tarjeta como se define en la reivindicación 10.
El al menos un procesador puede configurarse para realizar solo al menos uno de: calcular el código de seguridad dinámico; y hacer que se visualice el código de seguridad dinámico; si el mensaje que comprende el tiempo se determina como auténtico.
El dispositivo electrónico puede comprender uno de: un elemento seguro en el dispositivo electrónico que está configurado para calcular el código de seguridad dinámico; una partición segura de un procesador de propósito general del dispositivo electrónico que está configurado para calcular el código de seguridad dinámico.
El dispositivo electrónico puede ser uno de: un teléfono inteligente, una tableta, un ordenador personal.
El término “código de seguridad dinámico” significa que el código de seguridad no es estático, sino que cambia a lo largo del tiempo.
Una ventaja de al menos una realización es que se genera un código de seguridad dinámico sin la necesidad de una tarjeta más costosa con una pantalla (y una batería). En cambio, el dispositivo electrónico se usa para realizar las funciones que serían realizadas por la tarjeta. El dispositivo electrónico puede ser uno de: un teléfono, una tableta, un ordenador personal o un dispositivo similar.
Una ventaja de al menos una realización es que se genera un código de seguridad dinámico durante un tiempo particular. La determinación de una autenticidad del mensaje que contiene el tiempo puede evitar que una parte fraudulenta adquiera valores de código de seguridad para ocasiones futuras y use los códigos en un momento posterior.
La funcionalidad descrita aquí puede implementarse en hardware, software ejecutado por un aparato de procesamiento, o mediante una combinación de hardware y software. El aparato de procesamiento puede comprender un ordenador, un procesador, una máquina de estado, una matriz lógica o cualquier otro aparato de procesamiento adecuado. El aparato de procesamiento puede ser un procesador de propósito general que ejecuta software para hacer que el procesador de propósito general realice las tareas requeridas, o el aparato de procesamiento puede dedicarse a realizar las funciones requeridas. Otro aspecto de la invención proporciona instrucciones legibles por máquina (software) que, cuando son ejecutadas por un procesador, realizan cualquiera de los métodos descritos o reivindicados. Las instrucciones legibles por máquina pueden almacenarse en un dispositivo de memoria electrónica, disco duro, disco óptico u otro medio de almacenamiento legible por máquina. El medio legible por máquina puede ser un medio legible por máquina no transitorio. La expresión “medio legible por máquina no transitorio” comprende todos los medios legibles por máquina, excepto por una señal transitoria de propagación. Las instrucciones legibles por máquina pueden descargarse al medio de almacenamiento a través de una conexión de red.
Breve descripción de los dibujos
Se describirán realizaciones de la invención, solo a modo de ejemplo, con referencia a los dibujos adjuntos, en los que:
La Figura 1 muestra una tarjeta que puede generar dinámicamente un código de seguridad;
la Figura 2 muestra un sistema para realizar transacciones, tales como transacciones de CNP;
la Figura 3 muestra un método para inscribir una tarjeta en el sistema de la Figura 2;
la Figura 4 muestra un método para realizar una transacción y para generar dinámicamente un código de seguridad en el sistema de la Figura 2;
la Figura 5 muestra la preparación de un mensaje de tiempo en un servidor de tiempo;
la Figura 6 muestra la autentificación de un mensaje de tiempo en un dispositivo anfitrión;
la Figura 7 muestra el cálculo de un código de seguridad en un dispositivo anfitrión;
la Figura 8A muestra un ejemplo de datos almacenados en una entidad de autorización y un servidor de tiempo; la Figura 8B muestra un ejemplo de funcionalidad y datos almacenados en una entidad de autorización y un servidor de tiempo;
la Figura 8C muestra un ejemplo de funcionalidad y datos almacenados en un dispositivo anfitrión y una entidad de autorización;
la Figura 9 muestra la selección de una tarjeta en el dispositivo anfitrión;
la Figura 10A muestra otro método para inscribir una tarjeta en el sistema de la Figura 2;
la Figura 10B muestra otro método para inscribir una tarjeta en el sistema de la Figura 2;
la Figura 11 muestra una secuencia de ejemplo de dibujos de la interfaz de usuario en el dispositivo anfitrión;
la Figura 12 muestra esquemáticamente una posible implementación de un dispositivo anfitrión;
la Figura 13 muestra esquemáticamente una posible implementación de un dispositivo anfitrión con un elemento seguro.
Descripción detallada
La Figura 2 muestra un sistema para realizar transacciones. Una transacción utiliza detalles de una tarjeta 35. La tarjeta 35 puede ser una tarjeta de pago, tal como una tarjeta de débito o una tarjeta de crédito. El sistema de la Figura 1 puede usarse para transacciones de Card Not Present (tarjeta no presente - CNP). En una transacción de CNP, la tarjeta en sí no se presenta a un minorista durante la transacción. No hay comunicación entre un terminal de lector/pago de tarjeta en un comerciante y la tarjeta. En cambio, solo se usan detalles de tarjetas impresos en la tarjeta (p. ej., número de tarjeta, fecha de caducidad, código de seguridad) en la transacción. Un ejemplo de una transacción de CNP es una transacción telefónica entre un titular y un comerciante, con un titular que habla con un comerciante y proporciona vocalmente sus detalles de la tarjeta. Otro ejemplo de una transacción de CNP es una transacción en línea entre un titular y un comerciante, con un titular que ingresa sus detalles de la tarjeta en una forma de pago durante una sesión en línea con el comerciante, o el procesador de pago del comerciante. Las entidades mostradas en el sistema de la Figura 2 son: un dispositivo anfitrión 10, una tarjeta 35, un comerciante 45, una entidad 40 de autorización, un servidor 50 de tiempo y un usuario 60. El usuario 60 es una persona (p. ej., el titular) que desea realizar una transacción utilizando la tarjeta 35.
El dispositivo anfitrión 10 es un dispositivo electrónico que tiene una funcionalidad para generar dinámicamente un código de seguridad para una transacción y una pantalla 14 para visualizar el código de seguridad generado. El dispositivo anfitrión 10 puede ejecutar código 26 de software para generar el código de seguridad. El dispositivo anfitrión 10 se usa para proporcionar una funcionalidad similar de generación dinámica de un código de seguridad como una tarjeta del tipo mostrado en la Figura 1. Debido a que el dispositivo anfitrión 10 proporciona este código con generación de funcionalidad, la tarjeta 35 puede ser una tarjeta convencional sin una pantalla. El dispositivo anfitrión 10 tiene un área segura 11 para ejecutar el software 26 de generación de código y para almacenar las claves 27. El área segura 11 puede ser una partición más segura del procesamiento y almacenamiento de propósito general del dispositivo anfitrión 10, o puede ser un elemento seguro que está separado con respecto al procesamiento y almacenamiento de propósito general del dispositivo anfitrión 10. El ID 28 también se almacena dentro del área segura 11. Alternativamente, el ID puede almacenarse fuera del área segura 11. El dispositivo anfitrión 10 también puede almacenar, y ejecutar, una aplicación 25 que se comunica con la funcionalidad 26 de generación de código de seguridad, emite información para su presentación en la pantalla 14, y recibe entrada desde un dispositivo 13 de entrada de usuario.
El usuario 60 puede usar el dispositivo 10 para realizar una transacción de CNP. Un usuario puede usar dispositivo 10 para llamar, y hablar con un comerciante 45, o el usuario 60 puede usar software de navegador en el dispositivo 10 para realizar una transacción en línea con el comerciante 45. Esto se muestra por la ruta 32 de comunicación entre el dispositivo anfitrión 10 y el comerciante 45. En este caso, el dispositivo anfitrión 10 se usa para realizar la transacción de CNP con un comerciante 45 y para generar un código de seguridad. Opcionalmente, se usa otro dispositivo 30 para la transacción de CNP. Esto se muestra por la vía 31 de comunicación entre el dispositivo 30 y el comerciante 45. Por ejemplo, un usuario puede usar el dispositivo 30 para llamar, y hablar con un comerciante 45, o el usuario 60 puede usar software de navegador en el dispositivo 30 para realizar una transacción en línea con el comerciante 45. En este caso, el dispositivo anfitrión 10 solo se usa para generar un código de seguridad y no hay una ruta 32 de comunicación entre el dispositivo anfitrión 10 y el comerciante 45. La entidad 40 de autorización es una entidad responsable de aprobar transacciones, tales como un emisor de tarjetas, banco, procesador de pagos o entidad similar. Una red 48 conecta el dispositivo anfitrión 10 al comerciante 45, la entidad 40 de autorización y al servidor 50 de tiempo. Una red conecta el comerciante 45 a la entidad 40 de autorización.
El dispositivo anfitrión 10 almacena una primera clave (dCW-clave_ID) que se usa para generar el código de seguridad. El dispositivo anfitrión 10 también puede almacenar una segunda clave (clave-tiempoJD) que se usa para autentificar un mensaje que lleva información de tiempo que se recibe desde el servidor 50 de tiempo.
El dispositivo anfitrión 10 almacena un identificador (ID) que puede ser utilizado por otra entidad de red para seleccionar una clave apropiada cuando se comunica con el dispositivo 10. Por ejemplo, el servidor 50 de tiempo utiliza el ID para seleccionar una clave de tiempo apropiada cuando se envían mensajes de tiempo al dispositivo 10. La entidad 40 de autorización usa el ID para seleccionar una clave dCVV que es la misma que la clave (dCVV-clave_ID) usada en el dispositivo anfitrión 10 para calcular el código de seguridad. Como se describirá más detalladamente a continuación, la primera clave (dCVV-clave_ID) puede usarse directamente, o la primera clave puede usarse como una clave maestra para derivar una clave por tarjeta.
Ejemplos del dispositivo anfitrión 10 son un teléfono inteligente, una tableta, un ordenador personal (PC) o cualquier otro dispositivo informático adecuado. El dispositivo anfitrión 10 es capaz de realizar otras tareas además de realizar la generación de código de seguridad. Por ejemplo, el teléfono inteligente puede ejecutar aplicaciones para realizar una gama de otras tareas tales como mensajería, correo electrónico, aplicaciones de oficina. El dispositivo anfitrión 10 puede ser un dispositivo portátil o un dispositivo fijo. El dispositivo anfitrión 10 comprende un dispositivo 13 de entrada, tal como un teclado, ratón, pantalla táctil u otro dispositivo para recibir entrada del usuario. La pantalla 14 del dispositivo anfitrión 10 se usa para proporcionar información a un usuario, tal como avisos para entrada, el código generado, estado de generación de código, etc. El dispositivo anfitrión 10 puede proporcionar una graphical user interface (interfaz gráfica de usuario - GUI).
La entidad 40 de autorización almacena una o más claves que se usan para calcular localmente un código de seguridad. La entidad 40 compara el código de seguridad que se ha calculado con un código de seguridad recibido desde un dispositivo 10, 30 como parte de una transacción de CNP. Si los códigos de seguridad coinciden, entonces la transacción está sujeta a otros requisitos que se cumplen. Si los códigos de seguridad no coinciden, la transacción se rechaza. La entidad 40 de comerciante/autorización almacena datos que asocian el identificador ID con una tarjeta. El identificador ID se usa para recuperar una clave.
El servidor 50 de tiempo almacena una o más claves que se usan cuando se envían mensajes de tiempo al dispositivo anfitrión 10.
El dispositivo anfitrión 10 genera un código de seguridad en base a un tiempo. El código de seguridad generado tiene un período de validez limitado. Después de ese período, el código de seguridad ya no es válido y fallará una transacción que intenta usar un código de seguridad caducado. El servidor 50 de tiempo proporciona un tiempo. El dispositivo anfitrión 10 usa el tiempo recibido desde el servidor 50 de tiempo para generar el código de seguridad. Es ventajoso que el tiempo sea preciso, para evitar que una parte fraudulenta calcule un código de seguridad para un tiempo futuro. El servidor 50 de tiempo puede proporcionar un tiempo al dispositivo anfitrión 10 con información que permite que el dispositivo anfitrión 10 verifique la autenticidad del mensaje y, por lo tanto, el tiempo llevado por el mensaje. Como se describe más completamente a continuación, el dispositivo anfitrión 10 puede verificar la autenticidad de un mensaje que contiene el tiempo y puede no generar un código de seguridad si el mensaje no es auténtico.
Hay dos fases principales (etapas) del método: (i) una fase de inscripción, tal como se muestra en la Figura 3; y (ii) una fase de uso, tal como se muestra en la Figura 4. La fase de inscripción se realiza una vez por tarjeta. El efecto de la fase de inscripción consiste en inscribir un “emparejamiento” de la tarjeta con un dispositivo anfitrión. Esto permite que la entidad 40 de autorización calcule un código de seguridad apropiado para una transacción de CNP. La entidad de autorización sabrá qué dispositivo anfitrión está emparejado con una tarjeta, y puede usar una clave apropiada para generar el código de seguridad. La fase de inscripción puede repetirse si se emite una tarjeta nueva o de reemplazo al usuario. La fase de uso se realiza cada vez que un usuario requiere un código de seguridad para una transacción de CNP.
Un primer ejemplo de la fase de inscripción se muestra en la Figura 3, que no forma parte de la invención y está presente únicamente con fines ilustrativos. Este ejemplo requiere que el usuario introduzca datos de la tarjeta en el dispositivo anfitrión 10. Otros ejemplos de la fase de inscripción mostrada en las Figuras 10A y 10B (el ejemplo de la Figura 10A es una posible realización de la invención, el ejemplo de la Figura 10B no es según la invención y está presente únicamente con fines ilustrativos) evitan la necesidad de que el usuario introduzca datos de la tarjeta en el dispositivo anfitrión 10. El ejemplo de la fase de inscripción que se muestra en la Figura 3 usa el dispositivo anfitrión 10, la entidad 40 de autorización y el usuario 60. Una aplicación 25 en el dispositivo anfitrión hace que el dispositivo anfitrión proporcione una interfaz de usuario, tal como visualizando información visual (avisos, etc.) en la pantalla 14 del dispositivo anfitrión 10 y recibiendo entrada de usuario. En primer lugar, un usuario abre 71 la aplicación 25 en el dispositivo anfitrión 10. El usuario selecciona 72 una opción para inscribir una tarjeta. A continuación, el usuario ingresa los datos de la tarjeta para inscribir la tarjeta. Los datos de la tarjeta pueden comprender: un Primary Account Number (número de cuenta primaria - PAN) y una fecha de caducidad. El usuario puede leer los datos de la tarjeta en la parte frontal de la tarjeta. La aplicación 25 obtiene un identificador (ID) de la clave usada en el dispositivo anfitrión 10. Si la aplicación 25 todavía no conoce el ID, envía una solicitud 74 de ID al área segura 11. La aplicación 25 recibe, en respuesta, un ID desde el área segura 11. El ID identifica una o más de la clave de tiempo y la clave dCVV instalada en el dispositivo anfitrión 10. La aplicación 25 envía 76 los datos de la tarjeta (PAN, fecha de caducidad) y el ID a la entidad 40 de autorización. La entidad 40 de autorización almacena una asociación entre los datos de la tarjeta y el ID. El ID puede ser utilizado por la entidad 40 de autorización para buscar una clave apropiada para ese dispositivo 10 cuando se comunica con el dispositivo.
El dispositivo anfitrión 10 puede almacenar los datos de la tarjeta (PAN, fecha de caducidad) recibidos en 71. Alternativamente, el dispositivo anfitrión 10 puede no almacenar los datos de la tarjeta (PAN, fecha de caducidad) recibidos en 71 durante más tiempo de lo necesario para reenviar los datos en 76.
Un ejemplo de la fase de uso se muestra en la Figura 4. La fase de uso implica el dispositivo anfitrión 10, el comerciante 45, la entidad 40 de autorización, el servidor 50 de tiempo y el usuario 60. La fase de uso también utiliza el dispositivo anfitrión 10 para comunicarse con el comerciante 45, o un dispositivo 30 para comunicarse con el comerciante 45. El usuario comienza una transacción de CNP con un comerciante 45. La transacción puede ser una transacción telefónica, o una transacción en línea con un comerciante en línea o un proveedor de servicios. La transacción de CNP puede transferirse a una entidad 40 de autorización, tal como el procesador de pago del comerciante. Como parte de la transacción de CNP, se solicita al usuario que introduzca datos de la tarjeta tales como: PAN y fecha de caducidad de la tarjeta. El usuario ingresa estos datos en 80. La transacción de CNP también puede solicitar al usuario proporcionar otros datos sobre el titular, tal como uno o más de: nombre del titular, dirección del titular, código postal (código ZIP). La transacción de CNP solicita al usuario que introduzca un código de seguridad. El proceso de obtención del código se muestra en las Etapas 81 -91.
En primer lugar, un usuario abre 81 la aplicación 25 en el dispositivo anfitrión 10. El usuario solicita 82 la generación de un código de seguridad. El usuario puede interactuar con una aplicación 25 en el dispositivo anfitrión 10 para solicitar la generación de código. Por ejemplo, el usuario selecciona un icono mostrado en la interfaz de usuario en la pantalla 14 para generar un código de seguridad. La aplicación 25 envía una solicitud 83 de código al área segura 11 del dispositivo anfitrión 10. El código de seguridad se calcula para un punto particular en el tiempo. La aplicación 25 envía una solicitud 84 de tiempo al servidor 50 de tiempo. La solicitud 84 de tiempo incluye un identificador (ID) de la clave en el dispositivo anfitrión 10. El servidor 50 de tiempo recibe la solicitud 84 de tiempo y utiliza el ID para recuperar una clave apropiada para el dispositivo anfitrión 10. El servidor 50 de tiempo prepara un mensaje que incluye el tiempo actual. El mensaje incluye información que permite al receptor autentificar el mensaje. La autentificación se puede realizar de varias maneras. Un método adecuado para autentificar el mensaje es usar claves simétricas en el servidor 50 de tiempo y el dispositivo 10 y un Message Authentication Code (código de autentificación de mensaje - MAC). El servidor 50 de tiempo calcula un MAC que usa el contenido del mensaje y la clave específica del dispositivo como entradas. El MAC se añade al mensaje enviado al dispositivo 10. El MAC puede permitir que el dispositivo anfitrión 10 determine si otra parte ha manipulado el contenido del mensaje. El mensaje 86 de tiempo se envía al dispositivo anfitrión 10. La aplicación 25 recibe el mensaje 86 de tiempo y lo reenvía al entorno 11 de procesamiento seguro. La solicitud 84 de tiempo y el mensaje 86 de tiempo pueden comunicarse a través de cualquier red adecuada, tal como: una interfaz de local area network (red de área local -LAN); una interfaz de wide area network (red de área amplia - WAN); una interfaz inalámbrica (p. ej., WiFi, 2G, 3G, 4G); una interfaz por cable.
En 88, el área segura 11 determina si el mensaje de tiempo es auténtico. Por ejemplo, el área segura 11 puede calcular un MAC usando las mismas entradas que el servidor de tiempo, es decir, el contenido del mensaje (menos el MAC recibido) y la clave específica del dispositivo. Si el MAC calculado por el dispositivo anfitrión 10 es el mismo que el MAC en el mensaje recibido, se determina que el contenido del mensaje (es decir, el tiempo) es auténtico. En 89, el área segura 11 pasa a calcular el código de seguridad. El código de seguridad generado se envía 90 a la aplicación 25 y se reenvía a la interfaz de usuario, y se visualiza en la pantalla 14. El método solo puede proceder a calcular el código de seguridad dinámico en 89 si se determina que el mensaje que contiene el tiempo es auténtico. Si se determina que el mensaje que contiene el tiempo no es auténtico, el método no calcula el código de seguridad dinámico. El método puede devolver un mensaje de error a la aplicación 25, para su visualización en la pantalla 14.
Volviendo a la transacción de CNP, el usuario puede ver ahora el código de seguridad en la pantalla 14 del dispositivo 10. El usuario proporciona el código mostrado 92 al comerciante 45 o entidad 40 de autorización a través del dispositivo 30. La entidad 40 de autorización calcula independientemente el código de seguridad. La entidad 40 de autorización utiliza los datos de la tarjeta (p. ej., PAN, fecha de caducidad) para recuperar el ID del dispositivo anfitrión 10. La entidad 40 de comerciante/autorización utiliza entonces el ID para recuperar una clave específica del dispositivo. La entidad 40 de autorización calcula entonces el código de seguridad utilizando la clave específica del dispositivo. El código 92 de seguridad recibido del usuario se compara 94 con el código de seguridad calculado en 93. Si los códigos de seguridad coinciden, la transacción se aprueba. Si los códigos de seguridad no coinciden, la transacción no se aprueba. Se pueden usar otros criterios para alcanzar una decisión sobre si aprobar la transacción, tal como límite de crédito, patrones de gasto, ubicación de la transacción, etc. La Figura 4 muestra una entidad combinada de comerciante/autorización. Se entenderá que una transacción de CNP implicará típicamente alguna comunicación inicial entre el dispositivo 10/30 y el comerciante 45. La entidad 40 de autorización está involucrada cuando se necesita la autorización. El comerciante 45 puede poner en contacto la entidad de autorización 40 (p. ej., si la transacción se realiza mediante una llamada de voz) o el comerciante puede transferir la transacción a la entidad 40 de autorización (p. ej., durante una transacción en línea, antes o después de que un usuario haya entrado detalles de la tarjeta).
Se entenderá que las etapas del método pueden llevarse a cabo en cualquier orden adecuado, o simultáneamente cuando sea apropiado. Por ejemplo, la solicitud 83 de código de seguridad y el mensaje 87 de tiempo pueden enviarse al área segura 11 juntos, o la solicitud 83 de código de seguridad puede enviarse al área segura 11 posteriormente a lo que se muestra en la Figura 4.
Autentificación del mensaje de tiempo
Las Figuras 5 y 6 muestran un ejemplo de autentificación del mensaje de tiempo usando claves simétricas en el servidor 50 de tiempo y el dispositivo anfitrión 10. La Figura 5 muestra la funcionalidad en el servidor 50 de tiempo. Una función 113 de cálculo de MAC recibe el contenido del mensaje que se va a enviar 111 (incluyendo tiempo) y la clave específica del dispositivo (clave-tiempoJD) 112 como entradas. El MAC se calcula mediante la función 113 y la salida 114. El MAC 114 calculado se añade al mensaje 115 enviado al dispositivo 10.
La Figura 6 muestra la funcionalidad en el dispositivo anfitrión 10. Una función 123 de cálculo de MAC, similar al 113 en el servidor 50 de tiempo, recibe el mensaje desde el servidor 50 de tiempo y la clave 112 específica del dispositivo como entradas. El MAC se calcula mediante la función 123 y la salida 124. El dispositivo determina entonces si el MAC calculado por el dispositivo es igual al MAC calculado por el servidor de tiempo, es decir, MAC (dispositivo) = MAC (servidor de tiempo). Si el MAC calculado por el dispositivo anfitrión 10 es el mismo que el criptograma en el mensaje recibido, se determina que el contenido del mensaje (es decir, el tiempo) es auténtico. El servidor de tiempo y el dispositivo pueden utilizar un par de claves simétricas 112, 122 que tienen el mismo valor. El MAC se puede calcular sobre todo, o una parte de, el mensaje. El método puede usar una función de hash para calcular un hash, y la función 113 de cálculo de MAC puede calcularse en el hash. Un ejemplo de una función de hash adecuada es el Hash-based Message Authentication Code (Código de Autentificación de Mensajes basado en Hash - HMAC). Ejemplos de funciones basadas en cifrado de bloques adecuadas son cipher block chaining message authentication code (código de autentificación de mensajes cadena de bloques de cifrado - [CBC-MAC]) y Cipher-based Message Authentication Code (Código de Autentificación de mensajes basado en Cifrado - CMAC). Un ejemplo de un servicio de tiempo autentificado es el servicio proporcionado por el National Institute of Standards and Technology (Instituto Nacional de Estándares y Tecnología - NIST).
Otra forma de autentificar los mensajes de tiempo es mediante el uso de un par de claves asimétricas (clave privada, clave pública) y una firma digital. El servidor 50 de tiempo tiene una clave privada y una clave pública. El servidor de tiempo realiza un hash del mensaje y calcula una firma digital utilizando la clave privada del servidor de tiempo. El dispositivo anfitrión 10 decodifica la firma digital usando una clave pública del servidor 50 de tiempo y verifica si la firma decodificada coincide con un hash de los datos del mensaje. Si hay una coincidencia, se determina que el mensaje es auténtico. Este método requiere que el dispositivo anfitrión 10 almacene la clave pública del servidor de tiempo. Existen varias formas posibles de proporcionar la clave pública del servidor de tiempo al dispositivo anfitrión 10:
- la clave pública del servidor de tiempo se almacena de antemano, p. ej., en la personalización del área segura 11 o cuando primero se crea el software.
- la clave pública del servidor de tiempo se recibe en un momento posterior, durante una fase de “activación” . El dispositivo anfitrión 10 ya almacena una clave pública de una certification authority (autoridad de certificación -CA). La clave pública del servidor de tiempo se recibe como parte de un certificado. El dispositivo anfitrión 10 verifica la validez del certificado que contiene la clave pública del servidor de tiempo, utilizando la clave pública de la CA, antes de almacenar la clave pública del servidor de tiempo.
- la clave pública del servidor de tiempo nunca se almacena. La clave pública del servidor de tiempo se recibe (p. ej., como un certificado) con el mensaje de tiempo. El certificado se verifica como se ha explicado anteriormente. Esto permite más flexibilidad en la elección del servidor 50 de tiempo.
La Figura 7 muestra esquemáticamente la funcionalidad en el dispositivo 10 para calcular el código de seguridad. Una función 133 recibe el tiempo 131 (como se recibe desde el servidor 50 de tiempo) y la clave 132 específica del dispositivo (dCW-clave_ID) como entradas. La función 113 calcula el código de seguridad y emite el código 134 de seguridad.
Almacenamiento y cálculo de claves
Las Figuras 8A y 8B muestran algunos ejemplos de la entidad 40 de autorización y el servidor 50 de tiempo. En la Figura 8A, la entidad 40 de autorización almacena las claves 41 para los dispositivos que se requiere para comunicarse. La entidad 40 de autorización almacena asociaciones 42 entre datos de la tarjeta e identificadores recibidos de dispositivos anfitrión 10. Como se muestra en la Figura 3, durante una fase de inscripción, la entidad 40 de autorización recibe un identificador ID de un dispositivo y datos de la tarjeta (p. ej., PAN y fecha de caducidad). Los datos de la tarjeta se asocian con el identificador ID. El identificador ID se usa como un índice para buscar una clave 41 respectiva. Por ejemplo, ID1 se corresponde con dCVV-clave_ID1, ID2 se corresponde con dCVV-clave_ID2 y así sucesivamente. El servidor de tiempo almacena las claves 51 para los dispositivos que se requiere para comunicarse. El identificador ID recibido de un dispositivo anfitrión (p. ej., 84, Figura 4) se usa como índice para buscar una clave 51 respectiva. Por ejemplo, ID1 se corresponde con clave-tiempo_ID1, ID2 se corresponde con clave-tiempo_ID2 y así sucesivamente.
La Figura 8B muestra otro ejemplo de la entidad 40 de autorización y del servidor 50 de tiempo. En la Figura 8B, la entidad 40 de autorización almacena una clave maestra (dCVV-clave_maestra) y deriva una clave dCVV por dispositivo (dCVV-clave_ID):
dCVV-clave_ID = f(dCVV-clave_maestra, ID)
donde f(dCVV-clave_maestra, ID) es una función criptográfica con dCVV-clave_maestra e ID como entradas. Como en la Figura 8A, la entidad 40 de autorización almacena asociaciones 42 entre datos de la tarjeta e identificadores recibidos de dispositivos anfitrión 10. El identificador ID se usa para derivar una clave respectiva. Por ejemplo, dCVV-clave_ID1 se deriva mediante una función con dCVV-clave_maestra e ID1 como entradas, dCVV-clave_ID2 se deriva mediante una función con dCVV-clave_maestra e ID2 como entradas, y así sucesivamente. De manera similar, el servidor de tiempo almacena una clave maestra (clave-tiempo_maestra) y deriva una clave de tiempo por dispositivo (clave-tiempo_ID):
clave-tiempo_ID = f(clave-tiempo_maestra, ID)
donde f(clave-tiempo_maestra, ID) es una función criptográfica con clave-tiempo_maestra y el ID como entradas. El identificador ID se usa para derivar una clave respectiva. Por ejemplo, clave-tiempo_ID1 se deriva por una función con clave-tiempo_maestra y ID1 como entradas, clave-tiempo_ID2 se deriva por una función con clavetiempo_maestra y ID2 como entradas, y así sucesivamente.
Las Figuras 8A y 8B muestran ejemplos del servidor 50 de tiempo en donde se usan claves simétricas, y el servidor 50 de tiempo recupera una clave para un dispositivo anfitrión 10 particular. Si los mensajes de tiempo se autentifican usando un par de claves asimétricas (clave privada, clave pública), entonces el servidor 50 de tiempo almacena una clave privada, y opcionalmente almacena una clave pública que se envía al dispositivo anfitrión 10.
La Figura 8C muestra otro ejemplo del dispositivo anfitrión 10 y la entidad 40 de autorización. Este ejemplo puede usarse cuando el dispositivo anfitrión 10 se usa para generar códigos de seguridad para una pluralidad de tarjetas diferentes. En este ejemplo, el dispositivo anfitrión 10 utiliza la clave dCVV-clave_ID como clave maestra. El dispositivo anfitrión 10 deriva una clave dCVV por tarjeta usando la clave maestra y algún elemento de datos por tarjeta, denominado aquí “cardID” . El elemento de datos por tarjeta solo necesita ser suficiente para identificar de forma única la tarjeta con respecto a otras tarjetas en ese dispositivo. Por ejemplo, una primera tarjeta inscrita podría representarse mediante cardID1, con un valor “ 1” , una segunda tarjeta inscrita podría representarse mediante cardID2, con un valor “2” , o podría usarse algún otro esquema. El elemento de datos por tarjeta puede derivarse de datos de la tarjeta almacenados en la entidad 40 de autorización, tal como el PAN y la fecha de caducidad. Ventajosamente, el elemento de datos por tarjeta no contiene información sensible. La entidad 40 de autorización almacena asociaciones 42 entre datos de la tarjeta e identificadores (ID) recibidos de dispositivos anfitrión 10. Además, la entidad 40 de autorización almacena asociaciones 42 al cardID asignado a esa tarjeta. En el ejemplo ilustrado, la entidad de autorización almacena una asociación entre datos de la tarjeta e ID1, y también a cardID1. La clave dCVV por tarjeta se deriva mediante un proceso de dos etapas:
Etapa 1: dCVV-clave_ID = f (dCVV-clave_maestra, ID) Etapa 2: dCVV-clave_ID-tarjeta = f (dCVV-clave_ID, cardID) La Etapa 1 es la misma que en la Figura 8B. La Etapa 2 es una etapa adicional. La entidad 40 de autorización puede enviar el cardID al dispositivo anfitrión 10 durante la fase de inscripción. En cualquiera de los ejemplos anteriores, la entidad 40 de autorización y el servidor 50 de tiempo pueden almacenar la clave maestra en un Hardware Security Module (módulo de seguridad de hardware - HSM).
Múltiples tarjetas inscritas
La aplicación 25 y la función 26 de generación de código en el dispositivo anfitrión 10 pueden soportar una pluralidad de tarjetas. Por ejemplo, el usuario puede usar el dispositivo anfitrión para generar códigos de seguridad para una tarjeta de débito y para varias tarjetas de crédito. Cada tarjeta se inscribe de la manera mostrada en la Figura 3. La función 26 de generación de código es capaz de generar un código de seguridad para una tarjeta seleccionada de la pluralidad de tarjetas. La función 26 de generación de código usa una clave apropiada para cada una de las tarjetas. Una parte inicial de la fase de uso se modifica como se muestra en la Figura 9. Un usuario abre la aplicación 25. En 141, el usuario solicita la generación de un código de seguridad. La aplicación 25 provoca 142 que la interfaz de usuario muestre información sobre la pluralidad de tarjetas inscritas. En 143, un usuario selecciona una de las tarjetas mostradas. La aplicación 25 provoca 144 que la interfaz de usuario muestre la tarjeta seleccionada. La aplicación 25 envía una solicitud 145 de código de seguridad al área segura 11 para la tarjeta seleccionada. La aplicación 25 envía una solicitud 146 de tiempo al servidor de tiempo en 142. El método continúa de manera similar a lo mostrado en la Figura 4.
Inscripción sin almacenar datos de la tarjeta en el dispositivo anfitrión
El método de inscripción de tarjetas que se muestra en la Figura 3 requiere la introducción de datos de la tarjeta en el dispositivo anfitrión 10. Las Figuras 10A y 10B muestran dos ejemplos de inscripción de tarjeta que no requieren la introducción de datos de la tarjeta. La Figura 10A usa solo el dispositivo anfitrión 10. La Figura 10B usa el dispositivo anfitrión 10 y otro dispositivo 30. La entidad 40 de autorización (p. ej., bancaria o emisora de tarjetas) ya almacena detalles de tarjetas que se han emitido a un usuario. Los métodos mostrados en las Figuras 10A y 10b hacen uso de estos datos almacenados previamente. El ejemplo de la Figura 10B no forma parte de la invención y está presente únicamente con fines ilustrativos.
Haciendo referencia a la Figura 10A, un usuario abre 171 la aplicación 25 en el dispositivo anfitrión 10. El usuario selecciona 172 una opción para inscribir una tarjeta. La aplicación 25 se comunica con la entidad 40 de autorización. El inicio de sesión puede requerir que el usuario introduzca credenciales de inicio de sesión. La aplicación 25 solicita que la entidad de autorización envíe detalles de tarjetas emitidas al usuario. El proceso de inicio de sesión identifica al usuario. Los datos de la tarjeta se envían 176 mediante la entidad 40 de autorización. Sólo se envían datos de tarjeta parciales. El término “datos la tarjeta parciales” significa solo parte de los datos de la tarjeta, tales como solo los últimos cuatro dígitos de la tarjeta o tarjetas emitidas. Los datos de tarjeta parciales son suficientes para permitir que un usuario identifique la tarjeta, pero insuficientes para que una parte fraudulenta adquiera suficiente información para cometer fraude. El usuario selecciona, en 177, qué tarjeta o tarjetas se desean inscribir con este dispositivo anfitrión 10. La aplicación puede obtener el ID si todavía no tiene esta información. La aplicación 25 a la entidad 40 de autorización el ID del dispositivo y una indicación de la tarjeta o tarjetas seleccionadas a inscribir. La entidad 40 de autorización almacena 181 el ID y una asociación del ID a datos de la tarjeta, como se describe en las Figuras 8A-8C. En este ejemplo, no se introducen datos de la tarjeta por parte de un usuario o se almacenan en el dispositivo anfitrión 10. Durante el método de la Figura 10A, la entidad 40 de autorización puede enviar un elemento de datos por tarjeta al dispositivo anfitrión 10, para su uso en el cálculo de una clave por tarjeta a partir de una clave maestra.
En la Figura 10B, un usuario usa otro dispositivo, separado del dispositivo anfitrión 10, para inscribir una tarjeta con la entidad 40 de autorización. El usuario inicia sesión en la página web de su emisor de tarjeta (p. ej., un banco o compañía de la tarjeta de crédito). El inicio de sesión requerirá típicamente que el usuario introduzca credenciales de inicio de sesión que identifican al usuario. En 273, 274 el usuario selecciona una opción para inscribir una tarjeta con un dispositivo. Los datos de la tarjeta se envían 275 mediante la entidad 40 de autorización. Sólo se envían datos de tarjeta parciales. El usuario selecciona en 276, 277 qué tarjeta o tarjetas desea inscribir con este dispositivo anfitrión 10. La entidad 40 de autorización solicita el ID del dispositivo. El usuario solicita al dispositivo anfitrión 10 que visualice el ID, tal como abriendo la aplicación 25 y seleccionando una opción de “Visualizar ID” . El ID se visualiza en 280. El usuario introduce el ID en 281, y el dispositivo 10 envía 282 el ID a la entidad 40 de autorización. La entidad 40 de autorización almacena 283 el ID y una asociación del ID a datos de la tarjeta, como se describe en las Figuras 8A-8C. En este ejemplo, no se introducen datos de la tarjeta por parte de un usuario o se almacenan en el dispositivo anfitrión 10.
No almacenar detalles de la tarjeta tiene varias ventajas. Una ventaja es que una parte fraudulenta no puede obtener todos los detalles de la tarjeta necesarios para realizar una transacción de CNP desde el dispositivo anfitrión 10. Por lo tanto, incluso si un hacker burló la seguridad del dispositivo anfitrión 10, el mismo no obtendría los detalles de la tarjeta. Otra ventaja es que se reducen los requisitos de almacenamiento en el dispositivo anfitrión.
Interfaz de usuario
La Figura 11 muestra una secuencia de ejemplo de dibujos A-D de la interfaz de usuario en el dispositivo anfitrión 10. En el dibujo A, la interfaz de usuario muestra un icono 100 para la aplicación de generación de código de seguridad (dCVV). Cuando un usuario selecciona el icono 100, la aplicación de generación de código de seguridad comienza, y la interfaz de usuario cambia a la que se muestra en el dibujo B. Una ventana 102 visualiza dos opciones de alto nivel para la aplicación: inscribir una tarjeta 103; generar un código 104 de seguridad. En este ejemplo, se supone que el usuario selecciona la opción para generar un código de seguridad. La interfaz de usuario cambia a la que se muestra en el dibujo C. La ventana 102 visualiza un icono 106-108 para cada una de las tarjetas inscritas. En este ejemplo, se supone que el usuario selecciona la opción para generar un código de seguridad para la tarjeta con un PAN que termina en *6789. El dispositivo anfitrión 10 realiza el método mostrado en la Figura 4 (83­ 90) y la interfaz de usuario cambia a la que se muestra en el dibujo D. La ventana 102 visualiza el código 109 de seguridad. En este ejemplo, el código de seguridad es el número de tres dígitos “479” . La interfaz de usuario puede mostrar el código de seguridad durante un período de tiempo limitado, p. ej., 30 segundos.
En otros ejemplos, la secuencia de acciones de interfaz de usuario puede extenderse o truncarse. Por ejemplo, si solo se inscribe una tarjeta con la aplicación, la interfaz de usuario puede pasar directamente del dibujo B (Generar código) al dibujo D, sin la opción de seleccionar una tarjeta.
Dispositivo anfitrión
Las Figuras 12 y 13 muestran esquemáticamente dos implementaciones alternativas del dispositivo anfitrión 10. En ambas implementaciones hay un área segura 11. En la Figura 12, la funcionalidad de generación de código se realiza mediante un procesador 12 de propósito general del dispositivo. El procesador 12 de propósito general puede denominarse un Application Processor (procesador de aplicación - AP). El software 26 de generación de código y las claves 27 se almacenan en una partición segura del almacenamiento general 24, o en un almacenamiento separado. En la Figura 13, la funcionalidad de generación de código se realiza mediante un elemento seguro 210 en el dispositivo anfitrión 10. Un secure element (elemento seguro - SE) 210 puede comprender un procesador 212 y una memoria 214. El SE proporciona un entorno seguro de almacenamiento y ejecución que está separado del procesador 12 de propósito general. El acceso al SE está restringido. Por ejemplo, el acceso al SE puede estar restringido a mensajes de cierto tipo, o con ciertas propiedades. En la Figura 13, la memoria 214 dentro del SE almacena el código 26 de software para generar el código de seguridad y cualesquiera claves utilizadas por el código 26 de software. El SE también puede almacenar una clave usada para autentificar el mensaje de tiempo. En ambas Figuras 12 y 13, el dispositivo anfitrión 10 puede comprender un procesador 12 de propósito general, tal como un application processor (procesador de aplicación - AP). El procesador 12 puede comprender uno o más procesadores que pueden ser microprocesadores, microcontroladores o cualquier otro tipo adecuado de procesadores para ejecutar instrucciones. El procesador 12 está conectado a otros componentes del dispositivo a través de uno o más buses. Las instrucciones ejecutables por procesador pueden proporcionarse usando cualquier medio legible por ordenador, tal como almacenamiento 24. Las instrucciones ejecutables por procesador pueden comprender instrucciones para implementar la aplicación 25 descrita anteriormente. El almacenamiento 24 puede ser de cualquier tipo adecuado, tal como memoria no volátil (p. ej. Flash, Electrically Erasable Programmable Read Only Memory [memoria de Solo Lectura Programable Borrable Eléctricamente - EEPROM]), read-only memory (memoria de solo lectura - ROM), random access memory (memoria de acceso aleatorio - RAM), un dispositivo de almacenamiento de cualquier tipo, tal como un dispositivo de almacenamiento magnético u óptico. El dispositivo 10 comprende una o más interfaces 15 de red. La interfaz de red puede ser una o más de: una interfaz de local area network (red de área local - LAN); una interfaz de wide area network (red de área amplia - WAN); una interfaz inalámbrica (p. ej., wiFi, 2G, 3G, 4G); una interfaz cableada; o cualquier otra interfaz de red adecuada. La interfaz (15) de red puede usarse para enviar la solicitud (84, Figura 4) de tiempo y recibir el mensaje (86, Figura 4) de tiempo. El dispositivo 10 comprende un dispositivo 13 de entrada, tal como uno o más botones, un teclado, un dispositivo apuntador, una pantalla táctil. El dispositivo 10 comprende una pantalla 14.
En la Figura 13, el secure element (elemento seguro - SE) 210 puede ser un SE integrado. Un SE integrado puede ser un elemento de hardware separado en una placa de circuito del dispositivo anfitrión. Otras formas posibles de elemento seguro son: un SE como una tarjeta SIM-Universal Integrated Circuit Card (tarjeta de circuito integrado universal - UICC); un SE como una SIM-eUICC integrada; un SE como una SIM-iUICC integrada; un SE en una tarjeta separada, tal como una tarjeta segura digital (SD).
En la Figura 12, es posible dividir el entorno de procesamiento del procesador general 12 para proporcionar una partición segura. La partición segura puede usarse para ejecutar el código 26 de software de generación de código de seguridad. La división puede realizarse de diferentes maneras, tales como: un bloque IP de hardware específico integrado en el Sistema en Chip (SoC); un trusted execution environment (entorno de ejecución fiable - TEE), implementado por un hipervisor o un TEE como se define en la Plataforma Global.
Los ejemplos descritos anteriormente usan un identificador único ID en el dispositivo móvil para identificar una clave de autentificación de tiempo (clave-tiempoJD) y una clave de generación de código (dCW-clave_ID). En otros ejemplos, es posible usar un identificador por clave, es decir, un primer ID, ID1, para identificar una clave de autentificación de tiempo (clave-tiempo_ID1) y un segundo identificador, ID2, para identificar una clave de generación de código (dCVV-clave_ID).
En cualquiera de los ejemplos descritos anteriormente, una o más de las claves pueden instalarse durante una etapa de personalización del área segura 11 (p. ej., durante la fabricación del dispositivo electrónico 10), o una etapa de personalización de software que se distribuye al dispositivo electrónico. Alternativamente, una o más de las claves pueden instalarse en una etapa posterior durante un intercambio de comunicación entre el dispositivo electrónico 10 y un servidor.
Las etapas de los métodos descritos en la presente descripción pueden llevarse a cabo en cualquier orden adecuado, o simultáneamente cuando sea apropiado.

Claims (13)

  1. REIVINDICACIONES
    i. Un método para generar un código de seguridad dinámico para una transacción de tarjeta realizada por un usuario que usa un dispositivo (10) electrónico de usuario separado de una tarjeta (35), usando la transacción de tarjeta detalles de tarjeta de la tarjeta (35), en donde el dispositivo electrónico de usuario almacena un identificador (ID), comprendiendo el método, en el dispositivo (10) electrónico de usuario: recibir una solicitud (82) de usuario para generar un código de seguridad dinámico; al recibir la solicitud (83) de usuario, enviar una solicitud (84) de tiempo a una fuente (50) de tiempo externa al dispositivo (10) electrónico de usuario;
    recibir, en respuesta a la solicitud de tiempo, un mensaje (87) que comprende un tiempo desde la fuente (50) de tiempo;
    determinar (88) una autenticidad del mensaje que contiene el tiempo;
    calcular (89) el código de seguridad dinámico en función del tiempo recibido en el mensaje y una clave (dCW-clave_ID) almacenada en el dispositivo (10) electrónico de usuario; y hacer (90, 91) que el código de seguridad dinámico se visualice en una pantalla (14) del dispositivo electrónico de usuario,
    en donde el método comprende un proceso de inscripción preliminar que comprende, en el dispositivo (10) electrónico de usuario:
    recibir datos parciales sobre tarjetas emitidas a un usuario desde una entidad de autorización; recibir entrada de usuario que selecciona al menos una de las tarjetas; y
    enviar el identificador (ID) a la entidad (40) de autorización;
    en donde el identificador (ID) puede usarse para asociar la tarjeta seleccionada a la clave usada para calcular el código de seguridad.
  2. 2. Un método según la reivindicación 1, en donde al menos uno de:
    calcular (89) el código de seguridad dinámico;
    hacer (90, 91) que el código de seguridad dinámico se visualice;
    solo se realizan si el mensaje que comprende el tiempo se determina como auténtico.
  3. 3. Un método según la reivindicación 1 o 2, en donde el mensaje (87) que comprende el tiempo comprende un código de autentificación de mensaje, MAC, y determinar una autenticidad del mensaje comprende:
    calcular un código de autentificación de mensaje en el dispositivo electrónico de usuario usando una clave (clave-tiempoJD) almacenada en el dispositivo electrónico de usuario; y comparar el código de autentificación de mensaje calculado con el código de autentificación de mensaje en el mensaje recibido.
  4. 4. Un método según una cualquiera de las reivindicaciones anteriores, en donde el dispositivo electrónico de usuario almacena un identificador (ID) y el método comprende:
    enviar una solicitud (84) de tiempo a la fuente (50) de tiempo, incluyendo la solicitud de tiempo el identificador (ID).
  5. 5. Un método según la reivindicación 1 o 2, en donde el mensaje (87) que comprende el tiempo comprende una firma digital y determinar una autenticidad del mensaje usa una clave pública de la fuente (50) de tiempo.
  6. 6. Un método según una cualquiera de las reivindicaciones anteriores, en donde el dispositivo electrónico de usuario es capaz de calcular (89) un código de seguridad dinámico para una pluralidad de tarjetas diferentes, el dispositivo (10) electrónico de usuario almacena una clave maestra, y calcular (89) el código de seguridad dinámico comprende derivar una clave para una de las tarjetas seleccionadas usando la clave maestra.
  7. 7. Un método según la reivindicación 6, en donde calcular (89) el código de seguridad dinámico comprende derivar una clave para una de las tarjetas seleccionadas usando la clave maestra y un elemento de datos por tarjeta adicional recibido de la entidad (40) de autorización.
  8. 8. Un método según una cualquiera de las reivindicaciones anteriores, en donde el dispositivo electrónico de usuario es capaz de calcular (89) un código de seguridad dinámico para una pluralidad de tarjetas diferentes y el método comprende:
    hacer que el dispositivo electrónico de usuario visualice una invitación para una entrada de usuario para seleccionar una de la pluralidad de tarjetas; y
    enviar una solicitud (83) para generar un código de seguridad dinámico para la tarjeta seleccionada.
  9. 9. Un método según una cualquiera de las reivindicaciones anteriores, en donde al menos la etapa de calcular (89) el código de seguridad dinámico en base al tiempo se realiza mediante uno de:
    un elemento seguro en el dispositivo electrónico de usuario;
    una partición segura de un procesador de propósito general del dispositivo electrónico de usuario.
  10. 10. Un dispositivo (10) electrónico de usuario capaz de generar dinámicamente un código de seguridad para una transacción de tarjeta, usando la transacción de tarjeta detalles de tarjeta de una tarjeta (35), estando separado el dispositivo (10) electrónico de usuario de la tarjeta (35), almacenando el dispositivo electrónico de usuario un identificador (ID), comprendiendo el dispositivo (10) electrónico de usuario:
    al menos un procesador (12, 212);
    almacenamiento (24, 214);
    una pantalla (14);
    un dispositivo (13) de entrada de usuario;
    en donde el al menos un procesador (12, 212) está configurado para:
    recibir una solicitud (83) de usuario para generar un código de seguridad dinámico; al recibir la solicitud (83) de usuario, enviar una solicitud de tiempo a una fuente de tiempo externa al dispositivo electrónico de usuario;
    recibir, en respuesta a la solicitud de tiempo, un mensaje (87) que comprende un tiempo desde la fuente de tiempo;
    determinar (88) una autenticidad del mensaje que contiene el tiempo;
    calcular (89) el código de seguridad dinámico en función del tiempo recibido en el mensaje y una clave (dCW-clave_ID) almacenada en el almacenamiento del dispositivo electrónico de usuario; y hacer (90, 91) que el código de seguridad dinámico se visualice en la pantalla (14) del dispositivo electrónico de usuario,
    en donde el al menos un procesador (12, 212) está configurado para realizar un proceso de inscripción preliminar que comprende:
    recibir datos parciales sobre tarjetas emitidas a un usuario desde una entidad de autorización; recibir entrada de usuario que selecciona al menos una de las tarjetas; y
    enviar el identificador (ID) a la entidad (40) de autorización;
    en donde el identificador (ID) puede usarse para asociar la tarjeta seleccionada a la clave usada para calcular el código de seguridad.
  11. 11. Un dispositivo electrónico de usuario según la reivindicación 10, en donde el al menos un procesador está configurado para realizar solo al menos uno de:
    calcular (89) el código de seguridad dinámico;
    hacer (90, 91) que el código de seguridad dinámico se visualice;
    si el mensaje que comprende el tiempo se determina como auténtico.
  12. 12. Un dispositivo electrónico de usuario según la reivindicación 10 u 11, que comprende uno de:
    un elemento seguro (210) en el dispositivo (10) electrónico de usuario que está configurado para calcular (89) el código de seguridad dinámico;
    una partición segura de un procesador (12) de propósito general del dispositivo electrónico de usuario que está configurado para calcular (89) el código de seguridad dinámico.
  13. 13. Un método según una cualquiera de las reivindicaciones 1 a 9, en donde el dispositivo (10) electrónico de usuario es uno de: un teléfono inteligente, una tableta, un ordenador personal.
ES16306002T 2016-08-02 2016-08-02 Código de seguridad dinámico para una transacción de tarjeta Active ES2912188T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP16306002.3A EP3279848B1 (en) 2016-08-02 2016-08-02 Dynamic security code for a card transaction

Publications (1)

Publication Number Publication Date
ES2912188T3 true ES2912188T3 (es) 2022-05-24

Family

ID=56618109

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16306002T Active ES2912188T3 (es) 2016-08-02 2016-08-02 Código de seguridad dinámico para una transacción de tarjeta

Country Status (5)

Country Link
US (1) US11526880B2 (es)
EP (1) EP3279848B1 (es)
DK (1) DK3279848T3 (es)
ES (1) ES2912188T3 (es)
WO (1) WO2018024616A1 (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110610569A (zh) * 2019-09-20 2019-12-24 深圳中航信息科技产业股份有限公司 一种智能锁系统及其控制方法
US11961088B2 (en) * 2020-04-21 2024-04-16 Jpmorgan Chase Bank, N.A. System and method for providing temporal card verification value (CVV) for secure online transaction processing

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7584153B2 (en) * 2004-03-15 2009-09-01 Qsecure, Inc. Financial transactions with dynamic card verification values
WO2007149830A2 (en) * 2006-06-19 2007-12-27 Visa U.S.A. Inc. Portable consumer device configured to generate dynamic authentication data
US8359630B2 (en) * 2007-08-20 2013-01-22 Visa U.S.A. Inc. Method and system for implementing a dynamic verification value
US8577804B1 (en) * 2008-02-20 2013-11-05 Collective Dynamics LLC Method and system for securing payment transactions
US8364594B2 (en) * 2010-03-09 2013-01-29 Visa International Service Association System and method including security parameters used for generation of verification value
US20120153028A1 (en) * 2010-12-15 2012-06-21 Poznansky Amir Transaction Card with dynamic CVV
SG195079A1 (en) * 2011-06-03 2013-12-30 Visa Int Service Ass Virtual wallet card selection apparatuses, methods and systems
IN2015KN00466A (es) * 2012-08-03 2015-07-17 Vasco Data Security Int Gmbh
US10572873B2 (en) * 2013-02-15 2020-02-25 Mastercard International Incorporated Method and system for the transmission of authenticated authorization requests
US20160148194A1 (en) * 2013-03-14 2016-05-26 Nagraid Security, Inc. Radio Frequency Powered Smart, Debit and Credit Card System Employing a Light Sensor to Enable Authorized Transactions
US20140279555A1 (en) 2013-03-14 2014-09-18 Nagraid Security, Inc. Dynamically allocated security code system for smart debt and credit cards
US9947001B2 (en) * 2013-03-15 2018-04-17 Mastercard International Incorporated System and method for using multiple payment accounts using a single payment device
CN105684010B (zh) * 2013-08-15 2021-04-20 维萨国际服务协会 使用安全元件的安全远程支付交易处理
WO2015038551A1 (en) * 2013-09-10 2015-03-19 Visa International Service Association Mobile payment application provisioning and personalization on a mobile device
US11620654B2 (en) * 2014-12-04 2023-04-04 Mastercard International Incorporated Methods and apparatus for conducting secure magnetic stripe card transactions with a proximity payment device
EP3259877B1 (en) * 2015-02-17 2021-06-02 Visa International Service Association Methods and apparatus for secure authentication of user and mobile device

Also Published As

Publication number Publication date
EP3279848A1 (en) 2018-02-07
US20190172058A1 (en) 2019-06-06
US11526880B2 (en) 2022-12-13
DK3279848T3 (da) 2022-04-04
EP3279848B1 (en) 2022-03-23
WO2018024616A1 (en) 2018-02-08

Similar Documents

Publication Publication Date Title
US11895225B2 (en) Systems and methods for trustworthy electronic authentication using a computing device
CN110417797B (zh) 认证用户的方法及装置
ES2951585T3 (es) Autenticación de transacciones usando un identificador de dispositivo móvil
US9665868B2 (en) One-time use password systems and methods
US20160012430A1 (en) Hands-free offline communications
US20140143155A1 (en) Electronic payment method, system and device for securely exchanging payment information
EP3230935A1 (en) Systems and method for enabling secure transaction
US20150302409A1 (en) System and method for location-based financial transaction authentication
ES2741402T3 (es) Autenticación segura de titulares de tarjetas, incorporada en el dispositivo, que hace uso de datos biométricos
CN115358746A (zh) 包括消费者认证的安全远程支付交易处理
US20110087591A1 (en) Personalization Data Creation or Modification Systems and Methods
US20150161595A1 (en) Digital payment card presentation systems, methods, and apparatuses
JP2011059749A (ja) 生体認証システム、携帯端末、半導体素子、および情報処理サーバ
ES2912188T3 (es) Código de seguridad dinámico para una transacción de tarjeta
US20160253667A1 (en) Payment checkout within an application
ES2912594T3 (es) Código de seguridad dinámico para una transacción de tarjeta
US20170372306A1 (en) Payment by mobile device secured by f-puf
US20180240111A1 (en) Security architecture for device applications
ES2631002A2 (es) Dispositivo para facilitar transacciones financieras, procedimiento e instalación correspondientes
KR20190068851A (ko) 서버 장치의 동작 방법, 단말의 동작 방법 및 서버 장치
KR102652497B1 (ko) 스마트 카드를 이용한 did 인증 방법 및 스마트 카드 장치
ES2790883T3 (es) Servidor de autenticación para el control de acceso a un servicio
WO2024127253A1 (es) Método, aparato y sistema para la transferencia de datos
US20230129991A1 (en) Systems and methods for use in biometric-enabled network interactions
Sun A survey of payment token vulnerabilities towards stronger security with fingerprint based encryption on Samsung Pay