ES3038459T3 - Key generation in secure electronic payment systems - Google Patents

Abstract

En un sistema de pago electrónico seguro, se genera una clave obteniendo datos únicos de transacción relacionados con una transacción. Estos datos únicos comprenden una pluralidad de bits; se normalizan dichos bits según un formato de normalización predeterminado; se genera la clave aplicando una función de generación de claves predeterminada a los datos únicos de transacción normalizados; se genera una clave de cifrado basada en dichos datos; se utiliza una segunda función de derivación de claves predeterminada; se obtienen datos adicionales asociados al identificador de transacción; y se descifran los datos adicionales obtenidos utilizando la clave de cifrado generada. Se describen métodos y aparatos para generar la clave. En algunas implementaciones, los datos únicos de transacción incluyen datos de alta y baja varianza; los datos de alta varianza presentan una mayor varianza entre transacciones que los de baja varianza, y la pluralidad de bits normalizados comprende al menos los bits de los datos de alta varianza. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Generación de claves en sistemas de pago electrónico seguro

Campo técnico

La presente invención se refiere a métodos, aparatos y programas informáticos para generar una clave en un sistema de pago electrónico seguro.

Antecedentes

Los sistemas de pago electrónico requieren que varias partes puedan compartir datos entre sí de forma segura para realizar una transacción electrónica. Por ejemplo, para realizar una transacción en un sistema de pago con tarjeta, el minorista (‘comerciante’), el banco del minorista (‘adquirente’), el proveedor de la tarjeta (‘esquema’) y el banco del cliente (‘emisor’) deben poder comunicarse entre sí de forma segura. Para ello, el comerciante, el adquirente, el esquema y el emisor deben recibir previamente claves de cifrado seguras, en un proceso denominado aprovisionamiento de claves. También se pueden proporcionar certificados a las partes para su autenticación.

Se requiere una infraestructura dedicada, por ejemplo, en forma de un sistema de gestión de claves o una autoridad de certificación, para distribuir de forma segura la información de seguridad necesaria, como claves y certificados, a las distintas partes del sistema de pago electrónico. Como resultado, aumenta el coste y la complejidad de implementar un sistema de pago electrónico seguro. Por lo tanto, existe en la técnica la necesidad de un método mejorado que permita que los dispositivos de un sistema de pago electrónico se comuniquen entre sí de forma segura y compartan datos de forma segura.

El documento WO 2016/063089 A1 describe un método para proteger mensajes de transacción mediante cifrado de identificadores de transacción utilizando un secreto compartido derivado de operaciones criptográficas.

La invención se realiza en este contexto.

Sumario de la invención

De acuerdo con un primer aspecto de la presente invención, se proporciona un método para generar una clave en un sistema de pago electrónico seguro, comprendiendo el método obtener datos de transacción únicos relacionados con una transacción, comprendiendo los datos de transacción únicos una pluralidad de bits, normalizar la pluralidad de bits de los datos de transacción de acuerdo con un formato de normalización predeterminado, generar un identificador de transacción para identificar de forma única la transacción entre una pluralidad de transacciones mediante aplicación de una primera función de derivación de claves predeterminada a los datos de transacción únicos normalizados, generar una clave de cifrado basada en los datos de transacción únicos normalizados, utilizando una segunda función de derivación de claves predeterminada, obtener datos adicionales asociados con el identificador de transacción y descifrar los datos adicionales obtenidos utilizando la clave de cifrado generada.

En algunas realizaciones según el primer aspecto, la pluralidad de bits que son normalizados comprende un subconjunto de un número total de bits incluidos en los datos de transacción únicos. En algunas realizaciones, los datos de transacción únicos incluyen datos de alta varianza y datos de baja varianza, teniendo los datos de alta varianza una mayor varianza entre transacciones que los datos de baja varianza, y la pluralidad de bits que son normalizados comprende al menos los bits de los datos de alta varianza. Por ejemplo, en algunas realizaciones, el sistema de pago electrónico es un sistema de pago con tarjeta EMV, y los datos de alta varianza comprenden al menos una primera pluralidad de bits incluidos en un campo de Criptograma de aplicación ARQC y/o una segunda pluralidad de bits incluidos en un campo de Número impredecible. En otras realizaciones, el sistema de pago electrónico puede ser un sistema de pago 3D Secure, y los datos de alta varianza pueden comprender al menos una primera pluralidad de bits incluidos en un campo de XID. En otra realización, el sistema de pago electrónico es un sistema de pago 3D Secure, y los datos de alta varianza comprenden al menos una primera pluralidad de bits incluidos en un campo de XID.

En algunas realizaciones según el primer aspecto, la primera función de derivación de claves predeterminada y/o la segunda función de derivación de claves predeterminada se seleccionan de entre una pluralidad de funciones de derivación de claves disponibles.

En algunas realizaciones según el primer aspecto, la clave de cifrado se genera en un primer dispositivo del sistema de pago electrónico seguro, y obtener los datos adicionales comprende recibir la clave de cifrado del primer dispositivo, en un segundo dispositivo, y recibir los datos adicionales de un tercer dispositivo en el segundo dispositivo, en donde la clave de cifrado recibida del primer dispositivo se utiliza para descifrar los datos adicionales en el segundo dispositivo. Por ejemplo, en algunas realizaciones, la clave de cifrado puede utilizarse para descifrar los datos adicionales en el segundo dispositivo generando una clave privada a partir de la clave de cifrado en el segundo dispositivo y utilizando la clave privada para descifrar los datos adicionales.

En algunas realizaciones, obtener los datos adicionales comprende recuperar los datos adicionales asociados con el identificador de transacción a partir de un almacenamiento configurado para almacenar una pluralidad de conjuntos de datos adicionales, cada uno asociado con un identificador de transacción diferente. Además, en algunas realizaciones, generar el identificador de transacción comprende combinar los datos de transacción únicos normalizados con la clave de cifrado para obtener datos combinados y aplicar la primera función de derivación de claves predeterminada a los datos combinados para generar el identificador de transacción.

De acuerdo con un segundo aspecto de la presente invención, se proporciona un medio de almacenamiento legible por ordenador dispuesto para almacenar instrucciones de programa informático que, cuando son ejecutadas, realizan un método de acuerdo con el primer aspecto.

De acuerdo con un tercer aspecto de la presente invención, se proporciona un aparato para generar una clave en un sistema de pago electrónico seguro, comprendiendo el aparato un módulo de normalización de datos configurado para obtener datos de transacción únicos relacionados con una transacción, comprendiendo los datos de transacción únicos una pluralidad de bits, y normalizar la pluralidad de bits de los datos de transacción de acuerdo con un formato de normalización predeterminado, un generador de claves configurado para generar un identificador de transacción para identificar de forma única la transacción entre una pluralidad de transacciones mediante aplicación de una primera función de derivación de claves predeterminada a los datos de transacción únicos normalizados, y generar una clave de cifrado basada en los datos de transacción únicos normalizados, utilizando una segunda función de derivación de claves predeterminada, y una unidad de descifrado configurada para obtener datos adicionales asociados con el identificador de transacción y descifrar los datos adicionales obtenidos utilizando la clave de cifrado generada.

De acuerdo con un cuarto aspecto de la presente invención, se proporciona un aparato para generar una clave en un sistema de pago electrónico seguro, comprendiendo el aparato uno o más procesadores para ejecutar instrucciones de programa informático y memoria dispuesta para almacenar instrucciones de programa informático que, cuando son ejecutadas por los uno o más procesadores, hacen que el aparato obtenga datos de transacción únicos relacionados con una transacción, comprendiendo los datos de transacción únicos una pluralidad de bits, normalice la pluralidad de bits de los datos de transacción según un formato de normalización predeterminado, genere un identificador de transacción para identificar de forma única la transacción entre una pluralidad de transacciones mediante aplicación de una primera función de derivación de claves predeterminada a los datos de transacción únicos normalizados, genere una clave de cifrado basada en los datos de transacción únicos normalizados, utilizando una segunda función de derivación de claves predeterminada, obtenga datos adicionales asociados con el identificador de transacción y descifre los datos adicionales obtenidos utilizando la clave de cifrado generada.

Breve descripción de los dibujos

A continuación se describirán realizaciones de la presente invención, solo a modo de ejemplo, con referencia a los dibujos adjuntos, en los que:

la figura 1 ilustra un sistema de pago electrónico seguro que comprende una pluralidad de entidades, según una realización de la presente invención;

la figura 2 ilustra un aparato para generar una clave de identificador (ID) y una clave privada a partir de datos de transacción únicos en un sistema de pago electrónico seguro, según una realización de la presente invención;

la figura 3 ilustra un aparato para generar una clave de ID y una clave privada a partir de datos de transacción únicos en un sistema de pago electrónico seguro, según una realización de la presente invención;

la figura 4 es un diagrama de flujo que muestra un método para cifrar y almacenar datos en un sistema de pago electrónico seguro, según una realización de la presente invención;

la figura 5 es un diagrama de flujo que muestra un método para acceder a datos cifrados en un sistema de pago electrónico seguro, según una realización de la presente invención;

la figura 6 ilustra un aparato para acceder a datos cifrados en un sistema de pago electrónico seguro, según una realización de la presente invención; y

la figura 7 ilustra un aparato para acceder a datos cifrados en un sistema de pago electrónico seguro, según una realización de la presente invención.

Descripción detallada

En la siguiente descripción detallada, solo se han mostrado y descrito ciertas realizaciones ejemplares de la presente invención, a modo de ilustración. Como comprenderán los expertos en la materia, las realizaciones descritas pueden modificarse de diversas maneras, sin apartarse del alcance de la presente invención. Por consiguiente, los dibujos y la descripción deben considerarse ilustrativos y no restrictivos. Los mismos números de referencia designan elementos similares a lo largo de la memoria descriptiva. En los dibujos que ilustran aparatos, los recuadros redondeados se usan para indicar elementos funcionales, mientras que los recuadros cuadrados indican datos de entrada/salida. Dependiendo de los requisitos de cada realización, los elementos funcionales de cada aparato específico pueden implementarse en hardware o software.

Con referencia a la Fig. 1, se ilustra un sistema de pago electrónico seguro que comprende una pluralidad de entidades, según una realización de la presente invención. En esta realización, el sistema de pago electrónico seguro es un sistema de pago con tarjeta configurado según el estándar técnico EMV. El estándar EMV se utiliza en una amplia gama de sistemas de pago electrónico seguro, como sistemas de pago con chip y PIN y sin contacto basados en tarjetas de pago, teléfonos inteligentes u otros dispositivos de pago tokenizados. Sin embargo, debe entenderse que la presente invención no se limita a su uso con el estándar EMV y, en otras realizaciones, los principios desvelados en el presente documento pueden aplicarse a otros tipos de sistemas de pago electrónico seguro, como los sistemas de pago basados en servicios de mensajería.

En la presente realización, el sistema de pago electrónico comprende un aparato de comerciante 100, un aparato de adquirente 101, un aparato de esquema 102, un aparato de emisor 103 y un aparato de intermediario 104. Los diversos aparatos de la Fig. 1 pueden comunicarse mediante cualquier conexión adecuada, como interfaces de red cableadas o inalámbricas. Por ejemplo, el aparato de comerciante 100 puede ser un dispositivo de punto de venta electrónico (EPOS) y los aparatos de adquirente, esquema, emisor e intermediario 101, 102, 103, 104 pueden ser servidores operados por las respectivas partes. Aquí, los términos ‘comerciante’, ‘adquirente’, ‘esquema’ y ‘emisor’ se utilizan en el sentido convencional para designar diferentes entidades en un sistema EMV. En la presente realización, el intermediario es un tercero que media entre el comerciante y otros dispositivos, como un dispositivo cliente que pertenece al cliente.

En el sistema mostrado en la Fig. 1, una transacción se inicia cuando un cliente envía una solicitud de compra a un comerciante utilizando una tarjeta bancaria EMV sin contacto, por ejemplo, en persona en una tienda física o en línea a través del sitio web del comerciante. Durante el proceso de transacción, el dispositivo de EPOS del comerciante 100, junto con la tarjeta de pago del cliente, crea un mensaje que se utilizará finalmente para dar instrucciones al emisor para que transfiera fondos de la cuenta del cliente al adquirente. Este mensaje contiene varios campos inmutables que permanecen inalterados mientras el mensaje se pasa de forma segura entre partes de confianza, del comerciante al emisor de la tarjeta. Los datos contenidos en los campos inmutables se denominan en adelante ‘datos inmutables’. Dado que los datos inmutables no cambian al pasarse el mensaje de una parte a otra, todas las partes del sistema de pago con acceso al mensaje pueden acceder a los mismos datos inmutables.

Como se muestra en la Fig. 1, el aparato de comerciante 100 comprende un generador de claves 110 y una unidad de cifrado de datos 120. El generador de claves 110 está configurado para recibir los datos inmutables y aplicar funciones predefinidas de normalización y derivación de claves a los datos inmutables para generar un identificador y una clave privada para la transacción actual. En la presente realización, el identificador es una clave de ID que comprende un número de 256 bits que, a efectos prácticos, se puede asumir como único. Sin embargo, en otras realizaciones, se puede utilizar una forma diferente de identificador, por ejemplo, un identificador único universal (UUID) de 128 bits.

La función de derivación de claves puede ser cualquier algoritmo unidireccional adecuado capaz de generar una clave a partir de los datos inmutables, como una función hash criptográfica o un cifrado por bloques. En general, tanto la clave de ID como la clave privada pueden denominarse claves. Por ejemplo, la clave de iD puede utilizarse como clave en una base de datos clave-valor para recuperar datos almacenados (‘valor’) asociados con la clave de ID (‘clave’). La clave privada puede utilizarse para el cifrado o descifrado, por lo que puede denominarse clave de cifrado. Si bien en la presente realización las claves se generan a partir de datos inmutables en una transacción EMV, en otras realizaciones, las claves pueden generarse a partir de datos de transacción adecuados relacionados con una transacción en cualquier sistema de pago electrónico.

Como se muestra en la Fig. 1, la unidad de cifrado de datos 120 utiliza la clave privada generada por el generador de claves 110 para cifrar uno o más documentos. Los documentos pueden comprender cualquier dato relacionado con la transacción, incluyendo datos distintos del mensaje original de la transacción y datos inmutables. Por ejemplo, en algunas realizaciones, los datos cifrados por la unidad de cifrado de datos 120 pueden incluir datos proporcionados al cliente por el comerciante tras la finalización exitosa de la transacción, como un recibo de pago electrónico o contenido digital que el cliente ha comprado mediante la transacción.

Las funciones de normalización y derivación de claves que utiliza el generador de claves 110 están predefinidas, es decir, se definen antes de que se realice la transacción. De esta manera, cualquier parte de confianza del sistema de pago electrónico seguro que tenga acceso a los datos inmutables y conozca las funciones predefinidas de normalización y derivación de claves puede derivar la misma o mismas claves que el comerciante 100 para acceder a los datos originales. Al mismo tiempo, se puede impedir que otros terceros accedan a los datos y los descifren. Por lo tanto, el comerciante 100 puede cifrar los documentos, asociarlos con la clave de ID y enviar los documentos cifrados a un tercero, como el intermediario 104.

En la presente realización, el intermediario 104 puede almacenar datos cifrados relacionados con una pluralidad de transacciones en una base de datos, en la que cada conjunto de datos cifrados está asociado con la clave de ID de la transacción respectiva, y puede recuperar los datos cifrados para una transacción específica a petición de otra entidad que incluya la clave de ID de la transacción. La clave de ID permite al intermediario 104 identificar de forma única los datos para una transacción específica entre la pluralidad de conjuntos de datos cifrados almacenados en la base de datos. Sin embargo, dado que el intermediario 104 no tiene acceso a los datos inmutables, el intermediario 104 no puede descifrar los datos del comerciante. Este enfoque permite al comerciante 100 compartir de forma segura cualesquiera datos necesarios con otras partes de confianza, como el cliente, el adquirente, el esquema o el emisor, a través de un tercero intermediario (por ejemplo, el intermediario 104) sin comprometer la seguridad de los datos. Al mismo tiempo, dado que los datos existentes de la transacción se utilizan para derivar las claves que se utilizan para cifrar e identificar los datos protegidos, no es necesario distribuir claves ni certificados adicionales a las partes de confianza.

A continuación, se describirán con más detalle métodos para generar la clave de ID y la clave privada con referencia a las Figs. 2 y 3. La figura 2 ilustra un aparato para generar una clave de ID y una clave privada a partir de datos de transacción únicos en un sistema de pago electrónico seguro, según una realización de la presente invención. En la presente realización, el aparato está incluido en el generador de claves 110 utilizado por el comerciante 100 en el sistema de la Fig. 1. Sin embargo, como se desprende de la siguiente descripción, en otras realizaciones, los pasos que intervienen en la generación de una clave (por ejemplo, una clave de ID o una clave privada) pueden realizarse en dispositivos físicamente separados, y no es necesario que todos los realice el mismo dispositivo.

El aparato 110 comprende un módulo de normalización de datos 211 y un generador de claves 212 que, conjuntamente, generan una clave maestra a partir de los datos inmutables. El módulo de normalización de datos 211 está configurado para obtener los datos inmutables y normalizar una pluralidad de bits de los datos de transacción según un formato de normalización predeterminado. Los datos inmutables pueden ser cualesquiera datos de transacción únicos, que son únicos de la transacción actual, y que están disponibles para cualquier parte de confianza que necesite poder derivar la clave privada y/o la clave de ID. Debe entenderse que, en este contexto, ‘únicos’ no implica necesariamente que la probabilidad de que se generen los mismos datos de transacción para diferentes transacciones sea exactamente cero, sino que ‘únicos’ debe interpretarse como que la probabilidad de que dos transacciones compartan los mismos datos de transacción es mínima, prácticamente insignificante. Como se ha explicado anteriormente, durante una transacción en un sistema de pago electrónico seguro, se pasa un mensaje entre las distintas partes involucradas en la transacción para dar instrucciones de pago. Este mensaje puede denominarse mensaje de transacción. Los datos de transacción únicos que se utilizan en la generación de claves se pueden tomar de bits del mensaje de transacción que son inmutables, en el sentido de que el valor de los bits no cambia a medida que el mensaje pasa de una parte a otra.

El módulo de normalización 211 está configurado para tomar como entrada los datos inmutables que se incluyen en el mensaje de transacción y reformatear los datos se acuerdo con un formato de normalización predefinido. En este contexto, la normalización se refiere al proceso de convertir información transmitida por los datos inmutables a una representación estandarizada. La normalización garantiza que los datos que se proporcionan a la función hash siempre se representen exactamente de la misma manera, independientemente del formato en que una entidad específica reciba los datos inmutables, de modo que la salida de la función hash sea la misma. Por ejemplo, una cadena ‘£12.23’ tiene el mismo significado (es decir, transmite la misma información) que ‘GBP 12.23’, pero ambas entradas de datos darían como resultado salidas diferentes al ser procesadas por la función hash 212 debido a los diferentes formatos de datos. El módulo de normalización 211 puede reformatear los datos inmutables según un formato estandarizado, por ejemplo, ‘GBP:1223’, lo que garantiza que la salida de la función hash 212 sea la misma independientemente del formato original de los datos inmutables. Además, en realizaciones en las que se utilizan bits procedentes de una pluralidad de campos diferentes en los datos de transacción para generar la clave, el proceso de normalización puede incluir un paso de organización de los campos en un orden predefinido.

En los sistemas de pago electrónico, el formato en el que se conservan los datos inmutables puede cambiar a medida que el mensaje de transacción se pasa de una entidad a la siguiente. Por lo tanto, la normalización garantiza que cada entidad con acceso a los datos inmutables pueda generar la misma clave. Por ejemplo, diferentes interfaces de pago pueden tomar los datos de diferentes formas, como una cadena ‘12.23’, o como un código hexadecimal en unidades menores (p. ej., 0x4C7), que también podría almacenarse como datos binarios o como una cadena.

En la presente realización, todos los bits de los datos inmutables se utilizan como entrada para el módulo de normalización 211 y el generador de claves 212. Alternativamente, en otras realizaciones, la pluralidad de bits que son normalizados puede comprender solo un subconjunto de un número total de bits que están incluidos en los datos de transacción únicos. Por ejemplo, en algunas realizaciones, los datos de transacción únicos incluyen datos de alta varianza y datos de baja varianza. En este caso, el término ‘datos de baja varianza’ se utiliza para referirse a bits entre los datos inmutables que tienen una mayor varianza entre transacciones que los demás bits de los datos inmutables, que a su vez pueden denominarse ‘datos de baja varianza’. En la presente realización, la pluralidad de bits que son normalizados por el módulo de normalización de datos 211 comprende al menos los bits de los datos de alta varianza. El uso de datos de alta varianza aumenta la seguridad, al dificultar que un tercero utilice un método de fuerza bruta para romper el cifrado adivinando diferentes valores de los datos inmutables. En algunas realizaciones, la pluralidad de bits que son normalizados por el módulo de normalización de datos 211 también puede incluir los bits de los datos de baja varianza. El uso de los datos de baja varianza, además de los datos de alta varianza, puede reducir aún más el riesgo de colisiones. En este caso, una ‘colisión’ se refiere a la generación de la misma clave a partir de los datos de transacción para dos o más transacciones independientes. Además, en algunas realizaciones, la pluralidad de bits que son normalizados por el módulo de normalización de datos 211 puede incluir solamente los bits de los datos de baja varianza, sin utilizar los bits de los datos de alta varianza.

En el ejemplo de un sistema EMV, el mensaje pasado entre partes de confianza durante una transacción incluye al menos 96 bits de datos de alta varianza, junto con varios cientos de bits adicionales de datos de varianza baja a media. Ejemplos de datos de alta varianza en un sistema EMV incluyen los bits contenidos en un campo de Criptograma de aplicación (ARQC) y los bits incluidos en un campo de Número impredecible. Por consiguiente, en una realización de la presente invención basada en EMV, el módulo de normalización de datos 211 puede configurarse para utilizar una primera pluralidad de bits del campo de ARQC y/o una segunda pluralidad de bits del campo de Número impredecible como datos de transacción únicos. Como otro ejemplo, en una realización de la presente invención basada en 3D Secure, el aparato de generación de claves 210 puede configurarse para derivar la clave basándose al menos en los datos incluidos en los campos de XID (identificador único de comerciante) y CAVV de un mensaje de autorización de pago que se pasa entre las partes de confianza. Por ejemplo, el valor de XID puede combinarse con el código de identificación del aceptador de tarjetas y los códigos de identificación de la institución adquirente para obtener datos de transacción únicos a nivel global. En un sistema basado en 3D Secure 2.0, el Valor de autenticación constituye datos de alta varianza que el aparato de generación de claves 210 puede utilizar para derivar la clave. El Valor de autenticación es un valor criptográfico que el sistema de autorización utiliza durante el procesamiento de la autorización para validar la integridad del resultado de autorización. La especificación actual de EMVCo 3D Secure v2.0 define el Valor de autenticación como un valor criptográfico de 20 bytes generado por transacción; sin embargo, cabe destacar que, en otras versiones del estándar, se podría definir un tamaño diferente para el campo de Valor de autenticación.

Los bits normalizados de los datos de transacción únicos se pasan entonces al generador de claves 212, que está configurado para generar una clave maestra mediante aplicación de una función de derivación de claves predeterminada a los bits normalizados de los datos de transacción. La función de derivación de claves predeterminada utilizada por el generador de claves 212 puede seleccionarse de entre una pluralidad de funciones de generación de claves disponibles, aplicando ciertas reglas. Por ejemplo, en algunas realizaciones, el generador de claves 212 puede estar provisto de antemano de una lista de funciones de derivación de claves predeterminadas y puede cambiar de utilizar una función de derivación de claves a la siguiente función de la lista cuando se cumple una determinada condición, por ejemplo, cuando la función anterior se ha utilizado varias veces o ha estado en uso durante un período determinado. Cabe destacar que los generadores de claves correspondientes utilizados por otros dispositivos del sistema de pago electrónico seguro también deben configurarse para aplicar las mismas reglas que el generador de claves 212 utilizado por el comerciante 100, a fin de garantizar que cada parte seleccione la misma función de derivación de claves y derive la misma clave. En otras realizaciones, el generador de claves 212 puede configurarse para utilizar siempre la misma función de derivación de claves cada vez. En algunas realizaciones, la propia función de derivación de claves puede transmitirse a un tercero junto con los datos que se han cifrado utilizando la clave derivada. Por ejemplo, en una realización, el aparato de comerciante 100 puede enviar la función de derivación de claves y los métodos de cifrado a un tercero en el sistema, junto con los datos cifrados.

El aparato 110 comprende además una función de derivación de claves 213 configurada para generar una clave de ID y una clave privada a partir de la clave maestra. La función de derivación de claves 213 puede configurarse para utilizar cualquier función unidireccional predeterminada adecuada para derivar tanto la clave de ID como la clave privada a partir de la clave maestra, por ejemplo, una función hash criptográfica. El uso de una función unidireccional garantiza que la clave privada no pueda derivarse de la clave de ID.

Haciendo referencia a la Fig. 3, se ilustra un aparato para generar una clave de ID y una clave privada a partir de datos de transacción únicos en un sistema de pago electrónico seguro, según una realización alternativa de la presente invención. En esta realización, el aparato 310 comprende un módulo de normalización de datos 311 y un generador de claves 312. El módulo de normalización de datos 311 y el generador de claves 312 de la presente realización son similares al módulo de normalización de datos 211 y al generador de claves 212 descritos anteriormente en relación con la Fig. 2, por lo que no se repetirá aquí una explicación detallada.

En la presente realización, la clave entregada a su salida por del generador de claves 312 se utiliza directamente como clave privada para cifrar o descifrar datos. Por ejemplo, la clave generada por el generador de claves 312 puede utilizarse para descifrar datos cifrados recuperados del intermediario 104 mediante la clave de ID. El generador de claves 312 utiliza una primera función de derivación de claves predeterminada, como una función hash, para generar la clave privada. El aparato 310 comprende además una segunda función de derivación de claves 313 configurada para generar la clave de ID. En la presente realización, los datos de entrada a la segunda función de derivación de claves se obtienen concatenando una copia de los datos normalizados entregados a su salida por el módulo de normalización de datos 311 con la clave privada generada por el generador de claves 312. Esto tiene el efecto de añadir sal(salf)a la clave privada, protegiéndola contra ataques de tabla de búsqueda y cualquier vulnerabilidad desconocida actualmente que, de otro modo, podría explotarse para determinar la función hash. Aunque en la presente realización los bits reordenados se concatenan con la clave privada, en otras realizaciones, se puede utilizar un método diferente para combinar los bits reordenados con la clave privada. Por ejemplo, en otra realización, los bits normalizados se pueden intercalar con los bits de la clave privada antes de introducirlos en la segunda función de derivación de claves 313.

En la realización mostrada en la Fig. 3, la salida de la primera función de derivación de claves 312 se utiliza como clave privada, y la salida de la segunda función de derivación de claves 313, que se deriva basándose en la salida de la primera función de derivación de claves 312, se utiliza como ID. Sin embargo, en otra realización, la salida de la primera función de derivación de claves 312 puede utilizarse como ID, y la salida de la segunda función de derivación de claves 313 puede utilizarse como clave privada.

En la Fig. 4 se ilustra un diagrama de flujo que muestra un método para cifrar y almacenar datos en un sistema de pago electrónico seguro, según una realización de la presente invención. Por ejemplo, el método puede ser utilizado por el comerciante 100 de la Fig. 1 para cifrar datos y enviar los datos cifrados al intermediario 104 para su almacenamiento.

Primero, en el paso S401, se obtienen datos de transacción únicos. Durante el paso S401, los datos de transacción únicos pueden generarse o recibirse de otra entidad del sistema de pago electrónico seguro. Por ejemplo, cuando se implementa en el punto de venta del comerciante 100, los datos de la transacción pueden generarse en el paso S401 en relación con la tarjeta de pago. Alternativamente, cuando el método se implementa en otra entidad, como el adquirente 101, el esquema 102 o el emisor 103, los datos de transacción únicos pueden obtenerse del mensaje de transacción recibido.

A continuación, en el paso S402, un módulo de normalización de datos reordena una pluralidad de bits de los datos de transacción de acuerdo con un formato de normalización predeterminado, como se ha descrito anteriormente en relación con las Figs. 2 y 3. Luego, en el paso S403, un generador de claves genera una clave mediante aplicación de una función de derivación de claves predeterminada a los bits normalizados de los datos de transacción. En la presente realización, se lleva a cabo un paso adicional S404, en el que se utiliza una segunda función de derivación de claves predeterminada para derivar una clave privada y una clave de ID a partir de la clave maestra, como en la realización de la Fig. 2. Sin embargo, como se ha explicado anteriormente con referencia a la Fig. 3, en otras realizaciones, se puede omitir el paso de generar una clave privada y/o una clave de ID en S404, y la clave maestra se puede utilizar directamente como clave privada o como clave de ID.

Finalmente, en el paso S405, se cifran datos adicionales utilizando la clave privada derivada en el paso S404, y los datos cifrados se almacenan en asociación con la clave de ID derivada en el paso S404. En este caso, ‘datos adicionales’ se refiere a datos distintos de los datos de transacción únicos.

Haciendo referencia a la Fig. 5, se ilustra un diagrama de flujo que muestra un método para acceder a datos cifrados en un sistema de pago electrónico seguro, según una realización de la presente invención. El método mostrado en la Fig. 5 puede ser utilizado por otra entidad del sistema de pago electrónico seguro para acceder a datos que se han cifrado mediante el método mostrado en la Fig. 4. En los pasos S501 a S504, se derivan una clave privada y una clave de ID utilizando el mismo método que se ha descrito anteriormente en relación con los pasos S401 a S404 de la Fig. 4, y no se repetirá aquí una explicación detallada. De esta manera, se derivan la misma clave privada y la misma clave de ID en cada uno de los métodos de las Figs. 4 y 5. En el paso S505 de la Fig. 5, se utiliza la clave de ID para recuperar datos cifrados almacenados, y los datos cifrados recuperados se descifran entonces utilizando la clave privada.

Haciendo referencia a la Fig. 6, se ilustra un aparato para acceder a datos cifrados en un sistema de pago electrónico seguro, según una realización de la presente invención. En la presente realización, se utiliza un dispositivo cliente 605, por ejemplo, un teléfono inteligente perteneciente al cliente, para acceder a los datos cifrados conservados por un intermediario 604. El dispositivo cliente 605 recibe una clave maestra del aparato de emisor 603, que incluye un generador de claves 610 configurado para generar la clave maestra a partir de los datos de transacción únicos mediante una primera función de derivación de claves.

El dispositivo cliente 605 incluye un segundo generador de claves 613 configurado para aplicar una segunda función de derivación de claves para generar una clave privada y una clave de ID a partir de la clave maestra proporcionada por el emisor 603. El dispositivo cliente 605 transmite la clave de ID desde el intermediario 604, que recupera los datos cifrados asociados con la clave de ID de una base de datos conservada en el almacenamiento 604a y devuelve los datos cifrados al dispositivo cliente 605. El dispositivo cliente también comprende una unidad de descifrado 620 configurada para descifrar los datos recibidos del intermediario 604 utilizando la clave privada generada por el segundo generador de claves 613, para acceder a los datos originales sin cifrar.

En esta realización, la clave privada utilizada para descifrar los datos adicionales se genera por lo tanto en un dispositivo distinto de aquel en el que se genera la clave maestra. Este enfoque proporciona un elemento adicional de seguridad, ya que el dispositivo cliente 605 no necesita estar provisto de la primera función de derivación de claves y, por lo tanto, solo puede acceder a los datos originales sin cifrar una vez que el emisor 603 o alguna otra de las partes de confianza del sistema de pago electrónico seguro le haya proporcionado la clave maestra correspondiente.

Además, en algunas realizaciones, solo el comerciante 100 y el dispositivo cliente 605 pueden estar provistos de la segunda función de derivación de claves 613, y la segunda función de derivación de claves 613 puede ser desconocida incluso para las otras partes de confianza, como el adquirente 101, el esquema 102 y el emisor 103. Este enfoque permite que los datos adicionales se descifren únicamente en el dispositivo cliente 605 y se presenten al cliente, sin que la red financiera (adquirente, esquema y emisor) ni otros terceros puedan acceder a los datos descifrados. Esto proporciona un método mediante el cual el comerciante 100 puede enviar a un cliente de forma segura datos adicionales, como contenido digital, con cifrado de extremo a extremo, de modo que solo el cliente pueda recibir y acceder a los datos comercialmente sensibles de la transacción.

Haciendo referencia a la Fig. 7, se ilustra un aparato para acceder a datos cifrados en un sistema de pago electrónico seguro, según una realización de la presente invención. Al igual que en la realización de la Fig. 6, en la presente realización, un dispositivo cliente 705 recupera datos cifrados de una base de datos 704a almacenada en un intermediario 704, utilizando una clave de ID, y descifra los datos con una clave privada. Sin embargo, en la presente realización, el emisor 703 incluye un generador de claves 710 que está configurado para generar tanto la clave privada como la clave de ID y proporcionar al dispositivo cliente 705 la clave privada y la clave de ID generadas. El dispositivo cliente 705 envía entonces la clave de ID al intermediario 704 para recuperar los datos cifrados y utiliza una unidad de descifrado 720 para descifrar los datos devueltos por el intermediario 704.

Se han descrito realizaciones de la presente invención que permiten a las partes de un sistema de pago electrónico seguro compartir entre sí datos de forma segura sin necesidad de proporcionar claves adicionales, ya que cada parte puede derivar las claves necesarias de los datos de transacción existentes. Por ejemplo, los datos cifrados pueden almacenarse en un tercero intermediario para su posterior recuperación por parte del cliente. Este enfoque puede habilitar nuevas soluciones para la entrega de medios digitales como parte del proceso de pago con tarjeta. Por ejemplo, en una realización, un fotógrafo podría utilizar un método como el que se muestra en la Fig. 4 para cifrar fotos digitales de tal manera que el cliente pueda recuperar y acceder a las fotos utilizando únicamente los datos originales de transacción, sin tener que proporcionar ninguna información personal adicional para verificar su identidad, como su nombre o dirección de correo electrónico.

Además, aunque se han descrito realizaciones de la invención en relación con un sistema de pago basado en tarjeta EMV, debe entenderse que la invención no se limita a este tipo de sistema de pago electrónico seguro. En general, aspectos de la presente invención pueden aplicarse a cualquier tipo de sistema de pago electrónico seguro en el que se compartan datos de transacción únicos entre las partes del sistema, por ejemplo, datos inmutables de alta varianza compartidos por el comerciante y el agente de pago del cliente (emisor) en un sistema de pago en línea como 3D Secure.

Finalmente, se han descrito realizaciones de la invención en relación con la derivación de una clave privada y una clave de ID para compartir de forma segura datos cifrados entre partes. En otras realizaciones, los mismos principios descritos anteriormente en relación con la derivación de una clave privada y/o una clave de ID pueden utilizarse para generar una clave con un propósito diferente, por ejemplo, para aplicar cifrado simétrico a parte de los datos del mensaje de transacción. Esto puede proporcionar seguridad adicional al garantizar que, incluso si el mensaje de transacción fuera interceptado por un tercero, la parte cifrada del mensaje no podría descifrarse sin conocer la secuencia predeterminada y la función de derivación de claves predeterminada, necesarias para derivar la clave de cifrado simétrico. Además, en algunas realizaciones de la presente invención, el comerciante puede pasar datos al intermediario sin cifrado, por ejemplo, cuando el intermediario es de confianza para el comerciante. En estas realizaciones, la salida del generador de claves puede utilizarse como una clave de ID para que el intermediario pueda almacenar y posteriormente recuperar los datos recibidos del comerciante, sin generar por separado una clave privada para el cifrado.

En realizaciones de la presente invención, se deriva un ID de transacción a partir de datos únicos relacionados con una transacción. De esta manera, el ID de transacción y la clave de cifrado pueden derivarse de los datos de transacción que están disponibles para todos los esquemas de tarjetas y emisores. Este enfoque permite a un emisor, por ejemplo, recuperar datos para transacciones en situaciones en las que el emisor desconoce los identificadores del comerciante o del dispositivo de pago. Este escenario puede ocurrir cuando un dispositivo de pago tokenizado, como un teléfono inteligente, presenta un PAN (número de cuenta principal/número de tarjeta largo) al comerciante, que posteriormente se traduce en el esquema de tarjetas al PAN de la tarjeta del cliente, pasándose el PAN de la tarjeta del cliente al emisor. Por lo tanto, las realizaciones de la presente invención permiten vincular transacciones del lado del emisor al lado del comerciante sin que el emisor tenga acceso al PAN que se proporcionó al comerciante.

Adicionalmente, generar un identificador de transacción a partir de datos de transacción únicos permite que varios comerciantes participen en el sistema sin necesidad de coordinarse para evitar colisiones entre identificadores, ya que el identificador de transacción depende de datos de transacción únicos. Como ventaja adicional, dado que el identificador de transacción generado no identifica directamente a un comerciante, en realizaciones de la presente invención, los comerciantes pueden proporcionar datos de recibo (por ejemplo, a través de un tercero, como un proveedor de servicios de pago) de tal manera que no se pueda derivar información comercialmente sensible a través de los metadatos, como el número total de transacciones realizadas por el comerciante, las fechas y horas de las transacciones, etc. Por lo tanto, las realizaciones de la presente invención pueden garantizar la seguridad de la información comercialmente sensible de los comerciantes al almacenar datos adicionales para una transacción utilizando un identificador que se genera a partir de datos de transacción únicos para la transacción. Aunque ciertas realizaciones de la invención se han descrito en el presente documento con referencia a los dibujos, se entenderá que serán posibles muchas variaciones y modificaciones sin apartarse del alcance de la invención tal como se define en las reivindicaciones adjuntas.

Claims (14)

REIVINDICACIONES

1. Un método para generar una clave en un sistema de pago electrónico seguro, comprendiendo el método:

obtener (S501) datos de transacción únicos relacionados con una transacción, comprendiendo los datos de transacción únicos una pluralidad de bits;

normalizar (S502) los datos de transacción únicos de acuerdo con un formato de normalización predeterminado;

generar (S503) un identificador de transacción para identificar de forma única la transacción entre una pluralidad de transacciones mediante aplicación de una primera función de derivación de claves predeterminada a los datos de transacción únicos normalizados;

generar (S504) una clave de cifrado basada en los datos de transacción únicos normalizados, utilizando una segunda función de derivación de claves predeterminada;

obtener (S505) datos adicionales asociados con el identificador de transacción, siendo los datos adicionales datos distintos de los datos de transacción únicos que se han almacenado en asociación con el identificador de transacción y cifrado utilizando la clave de cifrado; y

descifrar (S505) los datos adicionales obtenidos utilizando la clave de cifrado generada.

2. El método de la reivindicación 1, en el que la pluralidad de bits que son normalizados comprende un subconjunto de un número total de bits incluidos en los datos de transacción únicos.

3. El método de la reivindicación 2, en el que los datos de transacción únicos incluyen datos de alta varianza y datos de baja varianza, teniendo los datos de alta varianza una varianza entre transacciones mayor que los datos de baja varianza, y la pluralidad de bits que son normalizados comprende al menos los bits de los datos de alta varianza.

4. El método de la reivindicación 3, en el que el sistema de pago electrónico es un sistema de pago EMV, y los datos de alta varianza comprenden al menos una primera pluralidad de bits incluidos en un campo de Criptograma de aplicación ARQC y/o una segunda pluralidad de bits incluidos en un campo de Número impredecible.

5. El método de la reivindicación 3, en el que el sistema de pago electrónico es un sistema de pago 3D Secure, y los datos de alta varianza comprenden al menos una primera pluralidad de bits incluidos en un campo XID.

6. El método de la reivindicación 3, en el que el sistema de pago electrónico es un sistema de pago 3D Secure v2, y los datos de alta varianza comprenden al menos una primera pluralidad de bits incluidos en un campo Valor de autenticación.

7. El método de cualquiera de las reivindicaciones anteriores, en el que la primera función de derivación de claves predeterminada y/o la segunda función de derivación de claves predeterminada se seleccionan de entre una pluralidad de funciones de derivación de claves disponibles.

8. El método de cualquiera de las reivindicaciones anteriores, en el que la clave de cifrado se genera en un primer dispositivo del sistema de pago electrónico seguro, y obtener los datos adicionales comprende:

recibir la clave de cifrado del primer dispositivo, en un segundo dispositivo; y

recibir los datos adicionales de un tercer dispositivo, en el segundo dispositivo, en el que la clave de cifrado recibida del primer dispositivo se utiliza para descifrar los datos adicionales en el segundo dispositivo.

9. El método de la reivindicación 8, en el que utilizar la clave de cifrado para descifrar los datos adicionales en el segundo dispositivo comprende:

generar una clave privada a partir de la clave de cifrado en el segundo dispositivo; y

utilizar la clave privada para descifrar los datos adicionales.

10. El método de cualquiera de las reivindicaciones anteriores, en el que obtener los datos adicionales comprende:

recuperar los datos adicionales asociados con el identificador de transacción, desde un almacenamiento configurado para almacenar una pluralidad de conjuntos de datos adicionales, cada uno asociado con un identificador de transacción diferente.

11. El método de cualquiera de las reivindicaciones anteriores, en el que generar el identificador de transacción comprende:

combinar los datos de transacción únicos normalizados con la clave de cifrado para obtener datos combinados; y

aplicar la primera función de derivación de claves predeterminada a los datos combinados para generar el identificador de transacción.

12. Un medio de almacenamiento legible por ordenador dispuesto para almacenar instrucciones de programa informático que, cuando son ejecutadas, realizan un método según cualquiera de las reivindicaciones anteriores.

13. Aparato para generar una clave en un sistema de pago electrónico seguro, comprendiendo el aparato:

un módulo de normalización de datos configurado para obtener datos de transacción únicos relacionados con una transacción, comprendiendo los datos de transacción únicos una pluralidad de bits, y normalizar la pluralidad de bits de los datos de transacción de acuerdo con un formato de normalización predeterminado; un generador de claves (613) configurado para generar un identificador de transacción para identificar de forma única la transacción entre una pluralidad de transacciones mediante aplicación de una primera función de derivación de claves predeterminada a los datos de transacción únicos normalizados, y generar una clave de cifrado basada en los datos de transacción únicos normalizados, utilizando una segunda función de derivación de claves predeterminada; y

una unidad de descifrado (620) configurada para obtener datos adicionales asociados con el identificador de transacción y descifrar los datos adicionales obtenidos utilizando la clave de cifrado generada, en el que los datos adicionales son datos distintos de los datos de transacción únicos que se han almacenado en asociación con el identificador de transacción y cifrado utilizando la clave de cifrado.

14. Aparato para generar una clave en un sistema de pago electrónico seguro, comprendiendo el aparato:

uno o más procesadores para ejecutar instrucciones de programa informático; y memoria dispuesta para almacenar instrucciones de programa informático que, cuando son ejecutadas por los uno o más procesadores, hacen que el aparato:

obtenga datos de transacción únicos relacionados con una transacción, comprendiendo los datos de transacción únicos una pluralidad de bits;

normalice la pluralidad de bits de los datos de transacción de acuerdo con un formato de normalización predeterminado;

genere un identificador de transacción para identificar de forma única la transacción entre una pluralidad de transacciones mediante aplicación de una primera función de derivación de claves predeterminada a los datos de transacción únicos normalizados;

genere una clave de cifrado basada en los datos de transacción únicos normalizados, utilizando una segunda función de derivación de claves predeterminada;

obtenga datos adicionales asociados con el identificador de transacción; y

descifre los datos adicionales obtenidos utilizando la clave de cifrado generada,

en el que los datos adicionales son datos distintos de los datos de transacción únicos que se han almacenado en asociación con el identificador de transacción y cifrado utilizando la clave de cifrado.