ES3061620T3 - Secure token wallet and electronic transaction system - Google Patents

Secure token wallet and electronic transaction system

Info

Publication number
ES3061620T3
ES3061620T3 ES23020403T ES23020403T ES3061620T3 ES 3061620 T3 ES3061620 T3 ES 3061620T3 ES 23020403 T ES23020403 T ES 23020403T ES 23020403 T ES23020403 T ES 23020403T ES 3061620 T3 ES3061620 T3 ES 3061620T3
Authority
ES
Spain
Prior art keywords
token
wallet
version
secure
new
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
ES23020403T
Other languages
English (en)
Inventor
Hupel Lars
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.)
Giesecke and Devrient Advance52 GmbH
Original Assignee
Giesecke and Devrient Advance52 GmbH
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 Giesecke and Devrient Advance52 GmbH filed Critical Giesecke and Devrient Advance52 GmbH
Application granted granted Critical
Publication of ES3061620T3 publication Critical patent/ES3061620T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/223Payment schemes or models based on the use of peer-to-peer networks
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827Use of message hashing
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829Payment protocols; Details thereof insuring higher security of transaction involving key management
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/389Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification

Landscapes

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

Abstract

Una billetera de tokens segura (11-14) de un sistema de transacciones, que comprende: un token (21) del sistema de transacciones, donde una versión del token (21) es una versión inicial del token; y una unidad de gestión de intercambio de tokens (29) para intercambiar tokens en transacciones. Una versión del token para la billetera de tokens segura (11-14) puede cambiarse de la versión inicial del token a una nueva versión del token. La billetera de tokens segura (11-14) está configurada para cambiar (47) la versión del token para la billetera de tokens segura (11-14), si se detecta la nueva versión del token (46) en una transacción (45). (Traducción automática con Google Translate, sin valor legal)

Description

[0001] DESCRIPCIÓN
[0002] Cartera de tokens segura y sistema de transacciones electrónicas
[0003] La invención se refiere a una cartera de tokens segura, a un sistema de transacciones electrónicas que comprende una cartera de tokens segura y a un método en dicho sistema de transacciones electrónicas, especialmente un sistema de transacciones de moneda digital.
[0004] Los tokens, también denominados monedas electrónicas o conjuntos de datos de monedas, pueden representar cualquier valor monetario, en particular, una moneda digital, preferiblemente una moneda digital de un banco central, abreviada CBDC. Las transacciones de tokens electrónicos y/o el almacenamiento de los tokens deben ser seguros y, por lo tanto, deben desarrollarse medios para proteger la confidencialidad y/o la integridad y la disponibilidad de los datos de los tokens intercambiados y/o almacenados. Esto es especialmente cierto para transacciones de pagos electrónicos y transacciones de pagos asociadas y almacenamientos de pagos en los que cada token tiene un valor monetario vinculado. Por lo tanto, se utilizan carteras de tokens seguras para intercambiar los tokens.
[0005] Existen distintos tipos de carteras de tokens. Los tipos de carteras de tokens más relevantes en la actualidad son las carteras de tokens de hardware y las carteras de tokens alojadas. Ejemplos de carteras de tokens de hardware son tarjetas inteligentes, memorias USB seguras, tarjetas SIM, elementos NFC seguros o etiquetas seguras sin contacto. Las carteras de tokens alojadas son proporcionadas por (o alojadas en) una unidad proveedora de servicios de cartera. De forma típica, la unidad proveedora de servicios de cartera incluye una pluralidad de carteras simbólicas alojadas, que pueden ser propiedad de distintos participantes del sistema de transacciones. El documento WO 2023/011758 A1 se refiere a una unidad proveedora de servicios de cartera mejorada que comprende una pluralidad de carteras de tokens alojadas de un sistema de transacciones que comprende un registro de tokens.
[0006] Es conocido que las carteras de tokens seguras deben cambiarse o actualizarse si las medidas de seguridad cambian a lo largo de los años. De forma típica, las carteras de tokens de hardware se intercambiarían y las carteras de tokens alojadas se actualizarían. Por ejemplo, en el campo de las tarjetas SIM o NFC se utilizan parcialmente las actualizaciones remotas.
[0007] Para una cartera de tokens, se ha propuesto ahora que un código de cartera de la cartera de tokens y el token utilizado en la cartera de tokens puedan actualizarse de forma independiente entre sí. Por ejemplo, el código de cartera puede mejorarse sin actualizar el token o el token puede actualizarse sin la adaptación del código de cartera.
[0008] Los documentos US 11704660 B2 y US 2021/287207 A1 se refieren a un método que proporciona automáticamente un nuevo dispositivo móvil mediante la transferencia de un token desde el dispositivo actual al nuevo dispositivo móvil. Puede crearse un nuevo token distinto al token inicial, en donde el token inicial se utiliza para actualizar una tabla de mapeo de dispositivo a token para el nuevo token.
[0009] El documento CN 108234133 A se refiere a la actualización de una cartera mediante la sustitución de su clave. US 2013/268437 A1 se refiere a la actualización de widgets dentro de una cartera de interfaz de usuario cuando hay una versión superior disponible. Una versión de tiempo de ejecución mínima puede identificar la versión mínima requerida de la plataforma de cartera y una versión puede identificar la versión del widget. US 2015/032627 A1 se refiere a la actualización de tokens. Un módulo de gestión del ciclo de vida de un token puede eliminar, activar, desactivar, renovar y actualizar un token. US 2018/293574 A1 se refiere a la actualización de la lógica de verificación de una cartera de firmas múltiples mediante un módulo de actualización. El módulo de actualización está configurado para actualizar la variable lógica de verificación en la cartera actualizable del esquema de verificación a la dirección lógica de verificación y transmitir el resultado de la actualización de la variable lógica de verificación a la red Ethereum.
[0010] Según un objeto de la invención, una cartera de tokens y/o un sistema de transacciones electrónicas deberán estar provistos de una seguridad mejorada, preferiblemente el rendimiento se mantendrá o incluso mejorará.
[0011] Los objetivos identificados anteriormente se resuelven con las características de las reivindicaciones de patente independientes. Otras realizaciones ventajosas se describen en las reivindicaciones de patente dependientes. Según un aspecto de la presente invención, se proporciona una cartera de tokens segura de un sistema de transacciones, que comprende:
[0012] - un token del sistema de transacciones, en donde una versión simbólica del token es una versión inicial del token; y - una unidad de gestión de intercambio de tokens para el intercambio de tokens en las transacciones.
[0013] La versión de token para (de) la cartera de tokens segura puede cambiarse de la versión de token inicial a una nueva versión de token. La cartera de tokens segura está configurada para cambiar la versión de token para (de) la cartera de tokens segura, si se detecta la nueva versión de token en una transacción.
[0014] En otras palabras, una transacción desencadena automáticamente el cambio de la versión de token de la cartera de tokens segura. La propia cartera de tokens segura determina si cambiar o no la versión del token. Una ventaja bastante inesperada del presente enfoque es que aumenta la seguridad en el sistema de transacciones. El período de tiempo de coexistencia de ambas versiones del token en el sistema puede reducirse significativamente. El período de coexistencia puede requerir modificaciones y/o medidas y/o servicios que sean aceptables o requeridos temporalmente. Por lo tanto, la seguridad del sistema de transacciones puede verse afectada por tales medidas temporales. La cartera de tokens segura proporcionada ya admite al menos ambas versiones, la versión de token inicial y la nueva versión de token (en la que podría admitir una o más versiones de token adicionales). Sin embargo, usa la versión inicial del token al menos hasta que detecte la nueva versión del token en la transacción. En primer lugar, (el período de tiempo se reduce y) la seguridad se incrementa, ya que la cartera de tokens segura utiliza la versión de token inicial (hasta que la cartera de tokens segura la cambia) y, en segundo lugar, porque el cambio de versión de token basado en transacciones propaga el cambio de versión de token más rápido que un cambio de versión de token basado en actualizaciones.
[0015] Preferiblemente, la cartera de tokens segura comprende además un elemento de datos de la versión de token actual, que indica la versión de token utilizada actualmente de la cartera de tokens segura.
[0016] Por lo tanto, el elemento de datos de la versión de token actual puede cambiarse independientemente del token o tokens de la cartera de tokens segura. En alternativas o variantes, cada token puede comprender un elemento de datos de versión de token, que indica la versión de token del token. Sin embargo, la versión de token de un token puede derivarse del token (por ejemplo, derivarse de la longitud total, de la longitud del elemento de datos, de la existencia o del contenido de un elemento de datos).
[0017] De forma alternativa o adicional, la cartera de tokens segura puede comprender un elemento de datos de versiones de tokens admitidas, que indique las versiones de tokens admitidas por la cartera de tokens segura. La cartera de tokens segura admite al menos la versión inicial y la nueva versión de token.
[0018] En variantes preferidas, la cartera de tokens segura detecta, en una fase de preparación de la transacción con otra cartera de tokens (en la etapa de detección), que la otra cartera de tokens ya utiliza la nueva versión de tokens y/o recibe información de la versión de token de la otra cartera de tokens. La cartera de tokens segura puede detectar la nueva versión del token en la fase de preparación de la transacción. La transacción comprende preferiblemente al menos la fase de preparación y una fase posterior de intercambio de token. Preferiblemente, la cartera segura detecta que la información de versión del token de la otra cartera recibida de la otra cartera corresponde a la versión del nuevo token. En la fase de preparación de la transacción, la cartera y la otra cartera pueden intercambiar mutuamente su información de la versión de token.
[0019] En una transacción se intercambian uno o más tokens. En la transacción pueden recibirse uno o más tokens, o pueden enviarse uno o más tokens, o pueden recibirse uno o más tokens y pueden enviarse uno o más tokens. En particular, se reciben uno o más tokens desde otra cartera de tokens en la cartera de tokens segura y/o se envían uno o más tokens desde la cartera de tokens segura a otra cartera de tokens.
[0020] Como se ha indicado anteriormente, la cartera segura admite al menos las dos versiones de token, pero puede admitir tres o más versiones de token distintas. En el sistema de transacciones, pueden utilizarse dos, tres o más versiones de token distintas en paralelo.
[0021] En las variantes mejoradas, las versiones de los tokens pueden compararse, preferiblemente mediante sustracción o comparación de valores, para determinar una versión más nueva de las versiones de token comparadas. Preferiblemente, la versión de token es un valor de versión de token, ordenándose las versiones de token por valor. El formato de la versión del token, especialmente en la información de la versión del token y/o el elemento de datos de la versión del token actual, admite la comparación. La cartera de tokens segura puede comparar, preferiblemente restar, la información de la versión del token recibido con la versión de la cartera de tokens segura, almacenada opcionalmente en el elemento de datos de la versión del token actual, por lo que la (más) nueva versión del token es simplemente detectable. La versión del token puede codificarse en uno, dos o más bytes. Preferiblemente, la versión del token está codificada mediante números. Como ejemplo únicamente, si la versión del token se codificara en dos bytes, una versión inicial del token podría ser 1.2 o 2.1 (formateada como “0x010x02” o “0x020x01”) y una nueva versión del token podría ser 2.1 o 2.3 (formateada como “0x020x01” o “0x020x03”), pudiendo restarse los valores en la comparación. Otros ejemplos que permiten la sustracción podrían basarse, por ejemplo, en valores de versión de token ordenados por valor, valores de versión de token secuenciales o codificación de un solo bit en un byte de la versión de token.
[0022] Los tokens de la versión nueva e inicial difieren en al menos un elemento de datos del token, especialmente en la longitud y/o en el formato y/o en el contenido y/o en la existencia del mismo. Por lo tanto, un elemento de datos existente (tal como una firma) en la nueva versión del token puede, por ejemplo, tener una nueva longitud (tal como la longitud de la nueva firma) y/o puede tener un formato interno distinto (tal como un nuevo formato interno) y/o puede tener un contenido distinto (tal como un nuevo algoritmo de firma utilizado). Además, puede faltar un elemento de datos existente en el formato inicial (tal como el tipo de token) (con o sin sustitución) o puede añadirse un nuevo elemento de datos (tal como el valor de enmascaramiento o el emisor del token) en la nueva versión del token.
[0023] En variantes ventajosas, la cartera de tokens segura está configurada para utilizar únicamente la versión inicial del token en las transacciones antes de la etapa de cambio. Por lo tanto, la cartera de tokens segura usa la versión de token inicial, que preferiblemente se almacena en el elemento de datos de la versión de token actual, en transacciones antes de la etapa de cambio. Pueden haberse utilizado versiones de token antiguas anteriormente, pero ahora utiliza únicamente la versión inicial del token en transacciones, especialmente en la recepción y envío de tokens. De forma adicional o alternativa, la cartera de tokens segura está configurada para utilizar únicamente la nueva versión de token en las transacciones, al menos después de la transacción o después de la etapa de cambio. La versión de token de la cartera de tokens segura determina preferiblemente al menos la versión de token de los tokens enviados por la cartera de tokens segura.
[0025] Debe tenerse en cuenta que la nueva versión del token podría denominarse versión del token más reciente y la versión del token inicial podría denominarse versión del token más antigua. Antes de la versión inicial del token, es posible que se hayan utilizado otras versiones antiguas del token y/o, después de la nueva versión del token, pueden utilizarse otras versiones de token más recientes en el futuro. Además, en el sistema de transacciones puede existir o puede haber existido una versión de token intermedia, que es más reciente que la versión de token inicial, pero más antigua que la nueva versión de token. Además, debe tenerse en cuenta que la versión de token siempre se cambia preferiblemente a una versión (más) reciente del token. Por lo tanto, la cartera de tokens segura no cambiará (volverá) a una versión de token, que sea más antigua que la versión de token inicial. En otras palabras, la versión de token de la cartera de tokens segura puede cambiarse irreversiblemente hacia versiones (más) recientes del token.
[0027] La cartera de tokens segura puede configurarse para actualizar la unidad de gestión de intercambio de tokens. Una unidad de gestión de intercambio de tokens iniciales para intercambiar tokens iniciales en transacciones puede actualizarse a una nueva unidad de gestión de intercambio de tokens para intercambiar nuevos tokens o tokens iniciales en transacciones. Preferiblemente, la cartera de tokens segura utiliza la versión de token inicial después de la etapa de actualización de la unidad de gestión de intercambio de tokens y/o antes de la etapa de cambiar la versión de token actual.
[0029] Preferiblemente, la cartera de tokens segura está configurada para convertir uno o más tokens de la cartera de tokens segura de la versión de tokens inicial a la nueva versión de tokens, especialmente después de la transacción. Una vez detectada la nueva versión, la cartera segura de tokens convertirá sus tokens. La conversión de los tokens puede realizarse dentro de la transacción y/o después de la transacción. Por ejemplo, en la transacción, puede enviarse un token de la versión de token inicial desde la cartera de tokens segura y, después de la transacción, se convierten uno o más tokens de la cartera de tokens segura. En otros ejemplos, puede recibirse (y almacenarse) un token de la nueva versión de token en la cartera de tokens segura de la transacción. La conversión del token puede realizarse después de la transacción (variante preferida) o en la transacción (variante menos preferida). En otro ejemplo, la cartera de tokens segura envía un nuevo token (de la nueva versión del token) en la transacción. La conversión del token se realiza para al menos el nuevo token que se va a enviar (o todos los tokens) en la transacción, pero podría realizarse para uno o más tokens adicionales después de la transacción.
[0031] La cartera de tokens segura puede configurarse para utilizar una o más de las siguientes tres opciones para convertir el token. El token podría convertirse creando un token de la nueva versión, registrando el token creado de la nueva versión en el sistema de transacciones enviando una solicitud de sustitución de registro al registro de token, solicitando la solicitud de sustitución de registro la sustitución del token de la versión inicial, que está registrado, por el registro del token creado de la nueva versión. El registro de token es preferiblemente un registro de referencia de token. El token también puede convertirse internamente en la cartera de tokens segura de la versión inicial a la nueva versión. Además, el token podría convertirse enviando el token de la versión inicial a una unidad de intercambio del sistema de transacciones y recibiendo el token de la nueva versión de la unidad de intercambio.
[0033] Como ya se ha mencionado anteriormente, existen distintos tipos de carteras de tokens. En el sistema de transacciones, pueden existir carteras de tokens de distintos tipos de carteras de tokens. La cartera de tokens segura puede ser una cartera de hardware, una cartera de dispositivo o una cartera alojada. El presente enfoque es más favorable para las carteras de hardware y posiblemente incluso para las carteras de dispositivos (o un sistema de transacciones que comprende una pluralidad respectiva de las mismas). La cartera de tokens segura puede ser una cartera de hardware. Ejemplos de carteras de hardware típicas son las tarjetas inteligentes, las tarjetas SIM, las memorias USB, los elementos RFID o los tokens de bluetooth u otros tipos de soportes de datos portátiles seguros. Las carteras de hardware solo comprenden una interfaz de comunicación local (es decir, no una interfaz de comunicación remota, por ejemplo, para Internet o comunicación móvil). De forma típica están configuradas para requerir temporalmente medios de comunicación remotos externos. La cartera de tokens segura puede ser una cartera de dispositivo. La cartera de dispositivos incluirá medios de comunicación remotos (por ejemplo, para Internet y/o redes de comunicación móvil). En la cartera del dispositivo, los tokens y/o la unidad de gestión de tokens se proporcionan preferiblemente en un elemento seguro dedicado del dispositivo, tal como un elemento NFC, un módulo SIM o TPM integrado o incorporado (módulo de plataforma fiable) o en un entorno de ejecución fiable (TEE) separado del dispositivo. Además, la cartera de tokens segura puede ser una cartera alojada de una unidad proveedora de servicios de cartera. La unidad proveedora de servicios de cartera comprende preferiblemente una pluralidad de carteras de cliente alojadas y/o una cartera de proveedor de servicios alojada y/o una unidad de gestión de intercambio de tokens para la unidad proveedora de servicios de cartera, es decir, una unidad de gestión de intercambio de tokens común para al menos la pluralidad de carteras de clientes alojadas, y/o el elemento de datos de la versión de token actual para la unidad proveedora de servicios de cartera. Para obtener más detalles sobre una unidad proveedora de servicios de cartera o para carteras de tokens alojadas, pueden consultarse los documentos WO 2023/011758 A1 o WO 2023/011759 A1.
[0034] En variantes preferidas, los tokens del sistema de transacciones se registran en un registro de token, más preferiblemente en un registro de referencia de token. El registro de token registra el token del sistema de transacciones. Sin embargo, no incluye el token. El propio token se almacena en la cartera de tokens. El registro de token puede utilizar una referencia de token para registrar el token. El emisor de token, preferiblemente un banco, más preferiblemente un banco central, puede solicitar el registro de nuevos tokens en el registro y/o la eliminación de los tokens del registro. A diferencia del emisor del token, las carteras de tokens solo pueden solicitar la sustitución de un token en el registro de token. Una solicitud de sustitución de token solicita el registro de uno o más tokens registrados para ser sustituidos por un registro de uno o más tokens a registrar. Una solicitud de sustitución de token puede incluir la o las referencias) de token del uno o más tokens registrados y la o las referencias de token de uno o más tokens a registrar.
[0035] En el sistema de transacciones, las carteras de tokens pueden crear uno o más tokens nuevos en una transacción basándose en uno o más tokens almacenados. Las carteras de tokens pueden sustituir a uno o más tokens almacenados por uno o más tokens nuevos creados, si el valor monetario total de estos tokens no cambia (al menos la suma de los valores monetarios debe ser igual para los tokens almacenados y creados). Por ejemplo, puede crearse un nuevo token que tenga el valor monetario requerido para la transacción. Un token puede dividirse en tokens y/o los tokens pueden fusionarse en uno o varios tokens. Para obtener más detalles relacionados con dichas solicitudes de división y/o fusión y/o sustitución de tokens, se hace referencia ilustrativa a los documentos WO 2020/212331 A1 o WO 2023/011756 A1. Los datos de registro, que normalmente incluyen una solicitud de registro para los nuevos tokens creados en la transacción, pueden formar un elemento de datos adicional de un token.
[0036] En variantes, la cartera de tokens segura comprende además al menos uno de los siguientes elementos de datos de la cartera:
[0037] - un ID de cartera, que identifique de forma exclusiva la cartera en el sistema de transacciones; y/o
[0038] - una clave de autenticación de la cartera; y/o
[0039] - un certificado de cartera, preferiblemente para el ID de cartera y/o la clave de autenticación de cartera; y/o - una versión del código que indica la versión del código de la unidad de gestión de intercambio de tokens.
[0040] El token puede ser un token de activo. El token puede ser un token de moneda. El token puede ser un token emitido por un banco central, tal como una CBDC. El token puede ser un token de moneda digital de otros emisores comerciales. En variantes preferidas, el token comprende al menos uno de los siguientes elementos de datos de token: un secreto de token, tal como una clave secreta de un par de claves de token y tokens individuales que comprenden la clave secreta de token y una clave pública de token; y/o un valor de token monetario; y/o datos de registro para registrar el token en el registro de token; y/o una referencia de token, preferiblemente derivada del secreto de token, tal como la clave pública de token del par de claves de tokens individuales; y/o una firma, preferiblemente del registro de token, que confirme el registro de token y/o del emisor de token; y/o un tipo de token.
[0041] En otro aspecto de la presente solución, se proporciona un sistema de transacciones electrónicas, preferiblemente un sistema de moneda digital de un banco central, que comprende: al menos una cartera de tokens segura como se ha descrito anteriormente y un registro de token, preferiblemente un registro de referencias de token. El sistema puede adaptarse adicionalmente como se ha descrito anteriormente.
[0042] El sistema de transacciones incluye preferiblemente una primera pluralidad de carteras de tokens seguras, que son carteras de hardware y/o carteras de dispositivos, y/o una segunda pluralidad de carteras de tokens seguras, que son carteras de tokens alojadas. La segunda pluralidad de carteras de tokens seguras está alojada en una o en una multitud de unidades de proveedores de servicios de cartera.
[0043] El sistema de transacciones puede incluir una unidad de intercambio del sistema de transacciones configurada para recibir tokens de la versión inicial (o una o más versiones anteriores) procedentes de una cartera de tokens segura y enviar los tokens de la nueva versión a la cartera de tokens segura.
[0044] El sistema de transacciones puede incluir además una unidad emisora de tokens. La unidad emisora de tokens puede configurarse para enviar solicitudes de creación y/o solicitudes de eliminación al registro de token para emitir tokens en el sistema de transacciones o, respectivamente, para eliminar tokens del sistema de transacciones. La unidad emisora de tokens puede recibir los tokens de la versión inicial para su eliminación de la o las unidades proveedoras de servicios de cartera y/o de la unidad de intercambio.
[0045] En particular, el sistema de transacciones y/o el registro de token admiten temporalmente al menos las dos versiones de token, la nueva versión de token y la versión de token inicial, en paralelo. Un período de coexistencia comienza cuando una primera cartera de tokens de las carteras de tokens del sistema de transacciones almacena un token de la versión (más) reciente y finaliza cuando se suspende el uso de tokens de la versión inicial de token. Por lo tanto, existe un punto de inicio de coexistencia y un punto final de coexistencia. En el punto final de coexistencia, es posible que algunas carteras de tokens sigan almacenando un token de la versión inicial. Antes de que comience una coexistencia, todas las carteras utilizan tokens de la versión inicial (o de versiones anteriores).
[0046] Otro aspecto más de la presente solución es un método en un sistema de transacciones electrónicas, en el que se intercambian tokens en transacciones, comprendiendo el método:
[0047] - proporcionar una pluralidad de carteras de tokens seguras, almacenando cada una de ellas uno o más tokens de una versión de token inicial y admitiendo el uso de tokens de la versión de token inicial y tokens de al menos una nueva versión de token; y
[0048] - cambiar la versión de token utilizada en las carteras de tokens,
[0049] en donde cada una de las carteras de tokens seguras está configurada para cambiar la versión de token para la cartera de tokens segura de la versión de token inicial a la nueva versión de token, si se detecta la nueva versión de token en una transacción.
[0050] El método para actualizar la versión de token en la cartera de tokens segura y/o el sistema de transacciones puede adaptarse adicionalmente como se ha descrito anteriormente.
[0051] Además, el emisor del token y/o la unidad o unidades proveedoras de servicios de cartera pueden iniciar el período de coexistencia indicando en la transacción el uso de la nueva versión, por ejemplo, enviando un token de la nueva versión y/o enviando la información de la versión de token correspondiente en la transacción. Preferiblemente, al inicio de la coexistencia, el emisor del token y/o la unidad o unidades proveedoras de servicios de cartera realizan una multitud de transacciones que activan el cambio de versión. En particular, cuando se realiza una transacción que desencadena un cambio de versión con una o más unidades proveedoras de servicios de cartera, la versión de token para la multitud de carteras alojadas de las respectivas unidades proveedoras de servicios de cartera se cambia al principio del período de coexistencia. De forma adicional o alternativa, las transacciones entre las carteras alojadas (de proveedores de servicios) de las unidades proveedoras de servicios de cartera y las carteras de hardware y/o las carteras de dispositivos pueden provocar el cambio de versión en las carteras de hardware y/o en las carteras de dispositivos.
[0052] A continuación, la invención o realizaciones adicionales y ventajas de la invención se explican con más detalle basándose en los dibujos, en donde los dibujos describen solo realizaciones de la invención. Al menos los elementos dibujados con líneas discontinuas se consideran elementos opcionales.
[0053] Los dibujos no deben considerarse fieles a escala y los elementos individuales de los dibujos pueden mostrarse de forma exageradamente grande o exageradamente simplificada.
[0054] La Figura 1 muestra múltiples carteras de tokens de un sistema de transacciones conocido.
[0055] La Figura 2 muestra una realización de ejemplo de una cartera de tokens segura.
[0056] La Figura 3 muestra los elementos de datos de un token.
[0057] La Figura 4 ilustra un método realizado en una realización de ejemplo de una cartera de tokens segura.
[0058] La Figura 5 muestra un registro de tokens que comprende tokens de distintas versiones de tokens.
[0059] La Figura 6 muestra una unidad de proveedor de servicios de cartera que comprende carteras de tokens alojadas. La Figura 1 muestra un ejemplo de un sistema de transacciones, que comprende una pluralidad de carteras 11-14 de tokens y un registro 10 de tokens. Los tokens del sistema de transacciones son preferiblemente tokens de moneda digital. El registro 10 de tokens registra el token del sistema de transacciones. Sin embargo, los tokens del sistema de transacciones se almacenan en las carteras 11-14 de tokens. Los tokens se intercambiarán entre las carteras 11-14 en las transacciones del sistema de transacciones.
[0060] El sistema incluye una primera pluralidad de carteras 11 de token de hardware. Cada uno de ellas incluye su unidad de gestión de intercambio de tokens, pero solo tiene medios de comunicación locales (no mostrados). Una segunda pluralidad de carteras 14, 17 de tokens de dispositivo comprende medios de comunicación remotos (no mostrado). De forma típica, el dispositivo 17 comprende los medios de comunicación remotos y una cartera segura dedicada 14 incluye los tokens y, opcionalmente, una unidad de gestión de intercambio de tokens. La unidad de gestión de intercambio de tokens puede proporcionarse en el dispositivo 17. Puede existir una multitud de unidades 16 proveedoras de servicios de cartera en el sistema. Cada unidad 16 proveedora de servicios de cartera comprende una tercera pluralidad de carteras 12 de tokens de cliente alojadas y una o más carteras 13 de proveedores de servicios alojadas. La unidad 16 proveedora de servicios de cartera puede comprender una unidad de gestión de intercambio de tokens común (o compartida) (no mostrada), que es común para (o compartida por) al menos las carteras 12 de tokens de clientes alojadas de la unidad 16 proveedora de servicios de cartera.
[0061] En la presente solución, los distintos tipos de cartera mostrados en la Figura 1 pueden utilizarse o no y el registro 10 de tokens puede formar parte del sistema de transacciones.
[0062] La Figura 2 ilustra detalles de una cartera 20 de tokens segura, que podría ser cualquiera de las carteras 11-14 de tokens. La cartera 20 de tokens segura comprende uno o más tokens 21 del sistema de transacciones.
[0063] En el ejemplo de la Figura 2, la cartera 20 de tokens segura comprende un elemento 25 de datos de la versión de token actual que indica una versión de token de la cartera 20 de tokens segura. La cartera 20 de tokens segura puede utilizar una primera versión de token, que se denomina versión de token inicial, y al menos una segunda versión de token más nueva, que se denomina versión de token (más) nueva. Por lo tanto, la cartera 20 de tokens segura admite más de una versión de tokens. Sin embargo, inicialmente solo utiliza y almacena los tokens 21 de la versión inicial del token.
[0064] La cartera 20 de tokens segura puede comprender además los elementos 22-27 de datos y puede comprender el código 29. No solo debido a los distintos tipos de cartera, los elementos 22-27 de datos y el código 29 son opcionales. Por ejemplo, el token 21 podría comprender un elemento de datos de la versión del token actual del token o la versión actual del token se deriva del token, por ejemplo, por su longitud, codificación o ..., si solo es necesario, de modo que el elemento 25 de datos de la versión del token actual de la cartera de tokens segura pueda o no almacenarse. En otro ejemplo, una cartera de tokens alojada puede o no comprender el código 29 de cartera, ya que las carteras alojadas podrían compartir el código de cartera de la unidad proveedora de servicios de cartera.
[0065] La cartera 20 de tokens segura puede comprender un elemento 26 de datos de versiones de tokens admitidas. Almacenaría la información sobre qué versiones de token están admitidas. El elemento 26 de datos de versiones de token admitidas indica, por lo tanto, que se admiten al menos la versión de token inicial y la nueva versión de token. Para el código 29 de cartera, puede almacenarse una versión del código de cartera en un elemento 27 de datos separado de la cartera de tokens de almacenamiento 20.
[0066] Un ID 22 de cartera identifica de forma única la cartera 20 de tokens segura en el sistema de transacciones. Una o más claves 24 de cartera de la cartera 20 de tokens segura pueden tener un certificado 23 asociado. La clave o claves 24 de cartera son preferiblemente una o varias claves secretas de cartera de un par o pares de claves individuales de cartera, comprendiendo el par de claves la clave secreta de cartera y una clave pública de cartera. Además, pueden almacenarse en la cartera uno o más certificados 23 de terceros. Además, la cartera puede comprender un certificado 23 de identificación de cartera para el ID de cartera y/o el ID de cartera puede formar parte del certificado 23 de cartera. Una clave 24 de autenticación de cartera y/o una clave 24 de firma de cartera son preferiblemente claves privadas de un par de claves públicas, que comprenden una clave pública y la clave privada. Una primera clave 24 de cartera (par) podría ser una clave de autenticación, utilizada en transacciones para autenticar la cartera 20 de tokens segura hacia la otra cartera de la transacción.
[0067] Ahora se explican brevemente ejemplos de distintas versiones de tokens con referencia a la Figura 3. La Figura 3 ilustra detalles de un token 30, que podría ser cualquiera de los tokens 21 de la Figura 2. El token 30 comprende elementos 31-36 de datos del token.
[0068] En la variante mostrada en la Figura 3, el token 30 comprende un secreto 31 de token, un valor 32 de token y una referencia 33 de token. El token 30 puede comprender de forma opcional y/o temporal datos 36 de registro de token. Es posible que sea necesario cambiar una versión del token utilizada en el sistema de transacciones. Por ejemplo, un nuevo escenario de ataque, como la computación cuántica, adquiere relevancia para el algoritmo criptográfico del sistema de transacciones, tal como curvas elípticas o RSA o incluso AES. Por lo tanto, en el futuro se utilizará un algoritmo criptográfico nuevo o adaptado. El algoritmo criptográfico nuevo o adaptado es más resistente en el escenario de ataque. Puede ser adecuado, por ejemplo, aumentar la longitud del secreto de token. Con respecto a la computación cuántica, un algoritmo criptográfico existente, como un algoritmo basado en curvas elípticas, por ejemplo, ECDSA, o un algoritmo basado en RSA, puede ser sustituido por un algoritmo postcuántico, por ejemplo, un esquema de firma basado en redes reticulares, como FALCON (firmas compactas basadas en redes rápidas de Fourier sobre NTRU) o ML-DSA (algoritmo de firma digital basado en redes modulares) o un esquema ECDSA adaptado.
[0069] En consecuencia, por ejemplo, la longitud del secreto 31 de token puede cambiar (aumentar o disminuir) y/o el contenido del secreto de token puede cambiar (por ejemplo, de la clave ECDSA a la clave FALCON). La referencia 33 de token puede o no depender del secreto 31 de token y, por lo tanto, también podría cambiar.
[0070] Por lo tanto, los tokens de la versión nueva e inicial pueden diferir, por ejemplo, en al menos un elemento de datos de token, especialmente en la longitud del elemento de datos y/o en el formato del elemento de datos y/o en el contenido del elemento de datos y/o en la existencia del elemento de datos. De forma alternativa o adicional, el formato del token puede cambiar, por ejemplo, de una estructura fija de los elementos de datos del token a una estructura TLV (etiqueta/longitud/valor) con una etiqueta por elemento de datos en el token.
[0071] Volviendo a la Figura 3, el token 30 podría comprender además una firma 34 de token y/o un tipo 35 de token como elementos de datos adicionales. El token 30 podría comprender teóricamente un elemento de datos de la versión del token. Sin embargo, en la Figura 3 y en las siguientes se asume que este elemento de datos de token no es necesario. El valor 32 de token indica el valor monetario del token 30. El secreto 31 de token y la referencia 33 de token son elementos de datos de token individuales de token. La referencia 33 de token identifica de forma única el token en el sistema de transacciones. El secreto 31 de token se utiliza para crear una firma, por ejemplo, para una solicitud de sustitución de token enviada al registro de token. En variantes preferidas, un par de claves pública individual-token comprende el secreto 31 de token (como la clave privada del par de claves) y la referencia 33 de token (como la clave pública del par de claves). En particular, la referencia 33 de token puede calcularse a partir del secreto 31 de token. La firma 34 de token podría ser una firma generada por el registro del token, por ejemplo, al registrar el token 30, o por el emisor del token, por ejemplo, al emitir el token. Podría utilizarse un tipo 35 de token, por ejemplo, para identificar al emisor del token, si existen múltiples emisores en el sistema de transacciones, o si existen tokens de propósito especial, por ejemplo, para el pago en un contexto específico, en el sistema de transacciones.
[0072] Los datos 36 de registro de token pueden almacenarse para el token hasta que se envíen al registro de token. Los datos 36 de registro de token pueden incluir una solicitud más de sustitución de registro de token. Los datos 36 de registro de token se generan normalmente en transacciones fuera de línea y pueden intercambiarse como parte del token en transacciones adicionales (fuera de línea). Se proporcionan ejemplos de posibles detalles de tales solicitudes, por ejemplo, en WO 2023/011756 A1.
[0073] La Figura 4 ilustra las etapas 41-49 de un método en el que se cambia la versión de token de una cartera 11-14 de tokens segura.
[0074] La cartera de tokens segura inicialmente usa 41, una versión inicial de token. Por lo tanto, los tokens almacenados en la cartera de tokens segura son tokens de la versión inicial del token. Además, en un intercambio de tokens con otra cartera de tokens del sistema de transacciones, la cartera de tokens segura intercambiará (enviará y/o recibirá) uno o más tokens de la versión inicial de token. El elemento 25 de datos de la versión actual, utilizado preferiblemente, almacena la información de la versión de token de la versión del token inicial.
[0075] En particular, si la cartera de tokens segura es una cartera 11 de hardware (o una cartera 14 de dispositivos), la cartera de tokens segura, cuando se proporciona/emite, normalmente ya admite la versión de token inicial y la nueva versión de token. Por lo tanto, su código 29 de cartera ya es compatible con ambas versiones de token. De forma típica para carteras alojadas 12, 13 y para carteras 11 de hardware y/o carteras 14 de dispositivos, se producirá opcionalmente una etapa de actualización 42 del código 29 de cartera. En la etapa de actualización 42, el código de cartera, opcionalmente, si se utilizan los elementos de datos, también se actualizan la versión 27 del código de cartera y/o las versiones 26 de token soportadas. Sin embargo, el token seguro seguirá utilizando 43 la versión inicial del token. Por lo tanto, el elemento 25 de datos de la versión del token actual no se actualizará.
[0076] En una transacción 45, si la cartera de tokens segura detecta 46 la versión (más) nueva de token, cambia 47 la versión de token de la versión inicial a la nueva versión de token. La nueva versión de token de la cartera de tokens segura puede almacenarse en el elemento 25 de datos de la versión de token actual.
[0077] Preferiblemente, las carteras de tokens de una transacción, la cartera de tokens segura y otra cartera de tokens (segura), intercambian mutuamente su información de versión de tokens. Si la información de la versión de token recibida es más reciente que la versión de token (actual) de la cartera de tokens segura y está admitida, la cartera de tokens segura (o la otra cartera de tokens segura) cambiará 47 la versión de token de su versión de token inicial a la versión de token más reciente detectada en la transacción.
[0078] En la etapa 46, la cartera de tokens segura compara su versión de token actual con la versión de token recibida. La cartera de tokens segura no cambiará a versiones de tokens más antiguas. Además, en la etapa 47, la cartera de tokens segura puede comparar la versión de token más reciente con la versión de token admitida. La cartera de tokens segura no cambiará a versiones de tokens no admitidas.
[0079] De este modo, se selecciona el formato de la versión del token para permitir la comparación automática. La información de la versión del token almacenada en el elemento 25 de datos de la versión del token actual , la información de la versión del token recibida y, opcionalmente, la información de la versión del token en las versiones 26 de token admitidas se formatean en consecuencia. La versión del token puede almacenarse, por ejemplo, en uno o más bytes, en donde solo un bit se establece en 1. Por lo tanto, pueden codificarse ocho versiones por byte (0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80). Las versiones de token más recientes tienen uno de los bits más alto establecido en 1. Preferiblemente, la información de distintas versiones del token puede compararse mediante sustracción. En una opción preferida, la información de la versión del token incluye al menos dos bytes (n bytes), en donde el byte más bajo puede ignorarse en la comparación de versiones admitidas. Las versiones de token soportadas se codifican en n-1 bytes. Por ejemplo, la versión del token “0x010x03” o “0x010x020x02” es más reciente que la versión inicial del token “0x01 0x02” o “0x01 0x02, 0x01”, pero los dos bytes superiores relevantes para las versiones de token compatibles “0x01” o “0x010x02” son idénticos. Por lo tanto, la versión 26 de token admitida puede incluir una o más entradas de información de la versión de token admitida y/o un rango de información de versión de token abreviada para indicar un rango de versiones de token admitidas.
[0081] Una vez que la cartera 11-14 de tokens segura haya cambiado 47 su versión de token por la nueva versión de token, la cartera de tokens segura utilizará 49 la nueva versión de token (no solo en la transacción 45). Los tokens 21 de la cartera 11-14 de tokens segura tienen que convertirse 48 desde la versión de token inicial a la nueva versión de token. La conversión 48 puede realizarse en la transacción 45 o después de la transacción 45. Por ejemplo, si las carteras de tokens seguras reciben uno o más tokens de la nueva versión de tokens en la transacción 45, los tokens almacenados de la versión inicial pueden convertirse más adelante. Si la cartera de tokens segura envía uno o más tokens de la nueva versión de tokens en la transacción 45, al menos esos (o todos) los tokens se han convertido previamente 48. Sin embargo, pueden convertirse más adelante, después de la transacción 45, tokens adicionales de la cartera de tokens segura.
[0083] Pueden utilizarse al menos tres variantes distintas para la conversión. En una primera variante, el token puede simplemente convertirse internamente de la versión inicial del token a la nueva versión del token. En una segunda variante, la cartera segura de tokens utiliza una solicitud de sustitución de token al registro de tokens para la conversión. La cartera de tokens segura crea internamente uno o más tokens de la nueva versión de token y envía una solicitud de sustitución al registro de token, solicitando al registro de token que sustituya el registro de uno o más tokens de la versión inicial de la cartera de tokens segura por un registro de los uno o más tokens creados de la nueva versión de token. Se dan ejemplos de posibles detalles de tales solicitudes, por ejemplo, en los documentos WO 2020/212331 A1 o WO 2023/011756 A1. En una tercera variante, la cartera de tokens segura utiliza un servicio de intercambio o conversión de tokens para la conversión. La cartera de tokens segura envía uno o más tokens de la versión inicial de token al servicio de intercambio o conversión de token y recibe de vuelta uno o más tokens de la nueva versión de tokens como corresponda. El servicio de intercambio o conversión de tokens será proporcionado preferiblemente por un servicio externo de intercambio o conversión de tokens. Para las carteras 12, 13 de tokens alojadas de una unidad 16 proveedora de servicios de cartera, puede utilizarse un servicio de intercambio o conversión de tokens de la unidad 16 proveedora de servicios de cartera, como se explicará con más detalle con respecto a la Figura 6 a continuación.
[0085] La Figura 5 muestra un registro 10 de token en un período de coexistencia, en el que se utilizan tokens de una nueva versión de token y tokens de una versión de token inicial en el sistema de transacciones. El registro 10 de token ilustrado en la Figura 5 es un registro de referencias de token. Almacena las referencias 51 de token para los tokens de la versión de token inicial y las referencias 52 de token para los tokens de la nueva versión de token. Al menos el valor monetario del token respectivo se almacena junto con las referencias 51, 52 de token. Solo un emisor de tokens (no mostrado) del sistema de transacciones puede crear o eliminar tokens en el sistema de transacciones. En consecuencia, en el registro de token, las solicitudes 53-55 de creación o eliminación del registro de token enviadas al registro de token solo se aceptarán las procedentes del emisor de tokens. De forma típica, la firma del emisor de un token se comprueba en este sentido. Las carteras pueden enviar solicitudes 56 -58 de sustitución de(referencia) de token al registro 10 de token.
[0087] En el período de coexistencia, el emisor del token enviará las solicitudes 54 de creación y/o las solicitudes 55 de eliminación para los tokens de la nueva versión del token. En consecuencia, las referencias 52 de token se añadirán o eliminarán del registro 10 de tokens. Sin embargo, en el período de coexistencia, el emisor del token no enviará solicitudes de creación de tokens de la versión de token inicial, sino solicitudes 53 de eliminación para los tokens de la versión de token inicial. Las referencias 51 de token de los tokens de la versión de token anterior se eliminarán entonces del registro 10 de tokens según se solicite. En el período de coexistencia, el registro de tokens acepta solicitudes 56 de sustitución de tokens que solicitan el sustitución de registro de tokens de la versión inicial de token únicamente, solicitudes 57 de sustitución de tokens que solicitan la sustitución de registro de tokens de la versión inicial de tokens por tokens de la nueva versión de token y solicitudes 58 de sustitución de tokens que solicitan la sustitución de registro de tokens de la nueva versión de token únicamente.
[0089] Antes del período de coexistencia, el registro 10 de token solo aceptaba solicitudes 53 de creación y/o solicitudes de eliminación para tokens de la versión de token inicial y solicitudes 56 de sustitución de token para tokens de la versión de token inicial. Tras el período de coexistencia, el registro 10 de token ya no aceptará las solicitudes 56, 57 de sustitución de tokens. Sin embargo, aceptará además las solicitudes 53 de eliminación del emisor del token, al menos hasta que se hayan eliminado todas las referencias 51 de token para tokens de la versión inicial del token.
[0090] La Figura 6 muestra una unidad 16 proveedora de servicios de cartera que comprende múltiples carteras 12, 13 de tokens alojadas seguras. Se indican las transacciones 61 - 63 para las carteras 12, 13 de tokens. El cambio de versión del token que desencadena las transacciones 61, 62 y las transacciones normales 63 (que no activan un cambio de versión del token) se describirán con más detalle a continuación.
[0091] La unidad 16 proveedora de servicios de cartera comprende un elemento 25 de datos de versión de token actual de la unidad 16 proveedora de servicios de cartera, que es la versión de token para al menos las carteras 12 de clientes alojadas y, en al menos un ejemplo analizado ahora, también para las carteras 13 de proveedores de servicios alojadas.
[0092] La unidad 16 proveedora de servicios de cartera puede comprender una unidad 69 de gestión de intercambio de tokens (o código de cartera). Este código 69 de cartera se utiliza para al menos las carteras 12 de cliente alojadas y, opcionalmente, también para la(s) cartera(s) 13 de proveedore(s) de servicios alojadas. Por lo tanto, se requiere una única actualización del código de cartera para el código 69 de cartera de la unidad 16 proveedora de servicios de cartera para todas las carteras alojadas 12, 13.
[0093] En el sistema de transacciones, el emisor de token puede iniciar el período de coexistencia. El emisor de token podría iniciar por ejemplo, el cambio de las versiones del token, por ejemplo, después de que la mayoría de las carteras 11-14 de token seguras del sistema de transacciones, preferiblemente más del 70 % de las carteras de hardware y de dispositivo, admitan la nueva versión del token (mediante actualizaciones o reemisiones de cartera).
[0094] Preferiblemente, el emisor de los tokens utiliza los tokens de la nueva versión en al menos una o varias transacciones 61 que activan cambios con las unidades 16 proveedoras de servicios de cartera. La cartera 13 de proveedor de servicios alojada segura, detecta, mediante el código 69 de cartera, la nueva versión del token en la transacción 61, por ejemplo, en la información de versión de token recibida de la cartera de emisor de token. Sin embargo, ahora se cambia la versión del token (no solo para una única cartera de token, sino) para la unidad 16 proveedora de servicios de cartera. El elemento 25 de datos de la versión de token actual de la unidad 16 proveedora de servicios de cartera se cambia de la versión de token inicial a la nueva versión de token. En consecuencia, se ha cambiado la versión de token de todas las carteras 12, 13 de tokens alojadas de la unidad 16 proveedora de servicios de cartera. Los tokens de estas carteras 12, 13 de tokens alojadas se convertirán como se ha descrito anteriormente.
[0095] Al enviar una multitud, x, de transacciones desencadenantes a x unidades 16 proveedoras de servicios de cartera, comprendiendo cada una de las cuales más de y carteras de token alojadas, al principio del período de coexistencia, x*y carteras ya han cambiado la versión del token.
[0096] Las transacciones posteriores 62 de las carteras 12, 13 de tokens alojadas con carteras 11, 14 de tokens seguras externas que aún utilizan la versión de token inicial provocarán un cambio adicional en la versión de token.
[0097] En una transacción 63 posterior (normal) entre la cartera 13 de proveedores de servicios alojados y la cartera 12 de clientes alojada, se utilizará el token de la nueva versión del token (pero no se activa ningún cambio). Como se ilustra además en la Figura 6, la cartera 14 de tokens de dispositivo ya ha cambiado la versión del token debido a la transacción 62, de modo que posteriormente una transacción normal 63 entre la cartera del proveedor de servicios alojados 13 y la cartera 14 de tokens de dispositivo intercambia tokens de la nueva versión del token.
[0098] Por último, la Figura 6 ilustra además que la unidad 16 proveedora de servicios de cartera puede comprender una unidad 65 de intercambio (o conversión) de tokens. La unidad 65 de intercambio (o conversión) de tokens puede proporcionar un servicio 67 de intercambio (o conversión) para las carteras externas 11, 14, 66 o internamente para las carteras alojadas 12, 13 de la unidad 16 proveedora de servicios de cartera. Como se ha descrito anteriormente, una cartera 11-14, 66 de tokens segura puede enviar tokens de la versión de tokens inicial y recibir tokens de vuelta de la nueva versión de token. Un uso interno de la unidad 65 de intercambio (o conversión) de tokens puede permitir que las carteras 12, 13 de tokens alojadas envíen o reciban tokens de la versión de tokens inicial en transacciones con otras carteras que no admitan la nueva versión de tokens. No obstante, el servicio 67 de intercambio de tokens se proporcionará únicamente durante el período de coexistencia.
[0099] Señales de referencia
[0100] 10 registro de referencia de tokens
[0101] 11 cartera de tokens de hardware
[0102] 12, 13 carteras de tokens alojadas
[0103] 14 cartera de tokens de dispositivo
[0104] 16 unidad proveedora de servicios de cartera
[0105] 17 dispositivo
[0106] 20 cartera
[0107] 21 token
[0108] 22 ID de cartera
[0109] 23 certificado de cartera
[0110] 24 clave de cartera
[0111] 25 versión de token actual
[0112] 26 versiones del token admitidas
[0113] 27 versión de código de cartera
[0114] 29 código de cartera
[0115] 30 token
[0116] 31 secreto de token
[0117] 32 valor de token
[0118] 33 referencia de token
[0119] 34 firma de token
[0120] 35 tipo de token
[0121] 36 datos de registro
[0122] 41, 43 uso de versión de token inicial
[0123] 42 actualizar código de cartera
[0124] 45 intercambio de token
[0125] 46 detectar una nueva versión de token
[0126] 47 cambiar versión actual de token
[0127] 48 convertir token(s)
[0128] 49 uso de nueva versión de token
[0129] 51 referencia de token - versión inicial
[0130] 52 referencia de token - versión nueva
[0131] 53, 55 eliminar referencia de token
[0132] 54 crear referencia de token
[0133] 56 sustituir versión inicial por inicial
[0134] 57 sustituir versión inicial por nueva
[0135] 58 sustituir versión nueva por nueva
[0136] 61, 62 transacción que provoca cambios de versión de token
[0137] 63 transacción
[0138] 65 unidad de conversión de token
[0139] 67 servicio de conversión de token
[0140] 69 código de cartera

Claims (15)

1. REIVINDICACIONES
1. Una cartera (11-14) de tokens segura de un sistema de transacciones, que comprende:
- un token (21) del sistema de transacciones, en donde una versión de token del token (21) es una versión inicial del token; y
- una unidad (29) de gestión de intercambio de tokens para el intercambio de tokens en transacciones; en donde una versión de token para la cartera (11-14) de tokens segura puede cambiarse de la versión de token inicial a una nueva versión de token;
caracterizada por que
la cartera (11-14) de tokens segura está configurada para cambiar (47) la versión de token para la cartera (11-14) de tokens segura, si se detecta la nueva versión de token (46) en una transacción (45).
2. La cartera (11-14) de tokens segura de la reivindicación 1, en donde la cartera (11-14) de tokens segura comprende además un elemento (25) de datos de la versión de token actual, que indica la versión de token utilizada actualmente de la cartera (11-14) de tokens segura.
3. La cartera (11-14) de tokens segura de cualquiera de las reivindicaciones anteriores, en donde la cartera (11-14) de tokens segura, en una fase (46, 47) de preparación de la transacción con otra cartera,
- detecta que la otra cartera ya utiliza la nueva versión del token; y/o
- recibe una información de la versión del token de la otra cartera.
4. La cartera (11-14) de tokens segura de cualquiera de las reivindicaciones anteriores, en donde la cartera (11-14) de tokens segura está configurada para
antes de la etapa de cambio (47) utilizar únicamente la versión inicial del token en transacciones; y/o después de la transacción o después de la etapa de cambio (47) utilizar únicamente la nueva versión del token en transacciones.
5. La cartera (11-14) de tokens segura de cualquiera de las reivindicaciones anteriores, en donde
dos, tres o más versiones distintas de token pueden utilizarse en paralelo en el sistema de transacciones; las versiones del token pueden compararse para determinar una más nueva de las versiones de token comparadas; y/o
los tokens de la versión nueva e inicial difieren en al menos un elemento de datos del token, especialmente en la longitud y/o en el formato y/o en el contenido y/o en la existencia de los mismos.
6. La cartera (11-14) de tokens segura de cualquiera de las reivindicaciones anteriores, en donde la cartera (11-14) de tokens segura está configurada para actualizar (42) la unidad (29) de gestión de intercambio de tokens, en particular desde una unidad de gestión de intercambio de tokens inicial para intercambiar tokens iniciales en transacciones a la nueva unidad de gestión de intercambio de tokens para intercambiar nuevos tokens y, opcionalmente, tokens iniciales en transacciones, en donde la cartera (11-14) de tokens segura utiliza (43) preferiblemente la versión de token inicial después de la etapa de actualizar (42) y/o antes de la etapa de cambiar (47) la versión de token actual.
7. La cartera (11-14) de tokens segura de cualquiera de las reivindicaciones anteriores, en la que la cartera (11-14) de tokens segura está configurada para convertir (48) uno o más tokens (21) de la cartera (11-14) de tokens segura de la versión de token inicial a la nueva versión de token.
8. La cartera (11-14) de tokens segura de la reivindicación 7, en donde la cartera (11-14) de tokens segura se configura en la etapa de convertir (48) el token (21) para:
- crear un token de la nueva versión y registrar el token creado de la nueva versión en el sistema de transacciones enviando una solicitud de sustitución de registro al registro de tokens, solicitando la sustitución del token registrado de la versión inicial por el registro de tokens creado de la nueva versión; o
- convertir internamente el token desde la versión inicial a la nueva versión; o
- enviar el token de la versión inicial a una unidad (69) de intercambio del sistema de transacciones y recibir el token de la nueva versión desde la unidad (69) de intercambio.
9. La cartera (11-14) de tokens segura de cualquiera de las reivindicaciones anteriores, en la que la cartera (11-14) de tokens segura es una cartera (11) de hardware o una cartera (14) de dispositivo.
10. La cartera (11-14) de tokens segura de cualquiera de las reivindicaciones anteriores, en la que la cartera (11-14) de tokens segura es una cartera alojada (12, 13) de una unidad (16) proveedora de servicios de cartera; comprendiendo la unidad (16) proveedora de servicios de cartera preferiblemente:
- una pluralidad de carteras (12) de clientes alojadas, y/o
- una cartera (13) de proveedor de servicios alojada, y/o
- la unidad (69) de gestión de intercambio de tokens para la unidad (16) proveedora de servicios de cartera, y/o
- el elemento (25) de datos de la versión de token actual para la unidad (16) de proveedor de servicios de cartera.
11. La cartera (11-14) de tokens segura de cualquiera de las reivindicaciones anteriores, en donde los tokens del sistema de transacciones están registrados en un registro (10) de tokens.
12. La cartera (11-14) de tokens segura de cualquiera de las reivindicaciones anteriores, en donde la cartera (11-14) de tokens segura comprende además al menos uno de los siguientes elementos de datos de cartera: - un ID (22) de cartera, que identifica de forma única la cartera en el sistema de transacciones; y/o
- una clave (24) de autenticación de cartera; y/o
- un certificado (23) de cartera, preferiblemente para el ID (22) de cartera y/o la clave (24) de autenticación de cartera; y/o
- una versión (27) de código que indica la versión del código de la unidad de gestión de intercambio de tokens.
13. La cartera (11-14) de tokens segura de cualquiera de las reivindicaciones anteriores, en donde el token comprende al menos uno de los siguientes elementos de datos de tokens:
- un secreto (31) de token; y/o
- un valor (32) de token monetario; y/o
- datos (36) de registro para registrar el token en el registro de tokens; y/o
- una referencia (33) de token, preferiblemente derivada del secreto (31) de token; y/o
- una firma (34), preferiblemente del registro de token que confirme el registro del token y/o del emisor del token; y/o
- un tipo (35) de token.
14. Un sistema de transacciones electrónicas, que comprende:
- al menos una cartera (11-14) de tokens segura según cualquiera de las reivindicaciones anteriores 1 a 13; - un registro (10) de token, preferiblemente un registro de referencia de tokens.
15. Un método en un sistema de transacciones electrónicas, en el que los tokens se intercambian en transacciones, que comprende las etapas de:
- proporcionar una pluralidad de carteras de tokens (11-14), almacenando cada una de las carteras (11-14) de tokens uno o más tokens (21) de una versión de token inicial y admitir el uso de tokens de la versión de token inicial y tokens de al menos una nueva versión de token;
- cambiar la versión de token utilizada en las carteras (11-14) de tokens,
en donde cada una de las carteras (11-14) de token seguras está configurada para cambiar (47) la versión de token para la cartera (11-14) de token segura, si se detecta la nueva versión (46) de token en una transacción (45).
ES23020403T 2023-08-29 2023-08-29 Secure token wallet and electronic transaction system Active ES3061620T3 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP23020403.4A EP4517629B1 (en) 2023-08-29 2023-08-29 SECURE TOKEN WALLET AND ELECTRONIC TRANSACTION SYSTEM

Publications (1)

Publication Number Publication Date
ES3061620T3 true ES3061620T3 (en) 2026-04-06

Family

ID=87863347

Family Applications (1)

Application Number Title Priority Date Filing Date
ES23020403T Active ES3061620T3 (en) 2023-08-29 2023-08-29 Secure token wallet and electronic transaction system

Country Status (4)

Country Link
EP (1) EP4517629B1 (es)
ES (1) ES3061620T3 (es)
LT (1) LT4517629T (es)
WO (1) WO2025045501A1 (es)

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130332343A1 (en) * 2005-10-06 2013-12-12 C-Sam, Inc. Multi-tiered, secure mobile transactions ecosystem enabling platform comprising a personalization tier, a service tier, and an enabling tier
CN113469670B (zh) * 2013-07-24 2024-04-05 维萨国际服务协会 使用令牌确保数据传送风险的系统和方法
US11010758B2 (en) * 2017-04-10 2021-05-18 Aptus Health, Inc. Digital wallet notification systems and methods
CN108234133B (zh) * 2017-12-28 2020-12-15 中国人民银行数字货币研究所 数字货币钱包更换密钥的方法、系统
DE102019002731A1 (de) 2019-04-15 2020-10-15 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Gerät zum direkten Übertragen von elektronischen Münzdatensätzen an ein anderes Gerät sowie Bezahlsystem
CN110910140A (zh) * 2019-10-11 2020-03-24 平安壹钱包电子商务有限公司 智能合约的实现方法、前置服务器、客户端、设备及介质
US11704660B2 (en) * 2020-03-12 2023-07-18 Mastercard International Incorporated Systems and methods for token transfer between mobile computing devices
DE102021004020A1 (de) 2021-08-04 2023-02-09 Giesecke+Devrient Advance52 Gmbh Verfahren zum registrieren von token eines elektronischen transaktionssystems
DE102021004025A1 (de) 2021-08-04 2023-02-09 Giesecke+Devrient Advance52 Gmbh Münzverwaltungseinheit sowie Verfahren in einer Münzverwaltungseinheit
DE102021004022A1 (de) 2021-08-04 2023-02-09 Giesecke+Devrient Advance52 Gmbh Münzdepot-Verwaltungseinheit sowie Verfahren in einer Münzdepot-Verwaltungseinheit

Also Published As

Publication number Publication date
EP4517629A1 (en) 2025-03-05
WO2025045501A1 (en) 2025-03-06
EP4517629B1 (en) 2025-12-31
LT4517629T (lt) 2026-02-25

Similar Documents

Publication Publication Date Title
US12602673B2 (en) Trustless physical cryptocurrency
KR101816650B1 (ko) 계정 등록의 간소화 서비스 및 사용자 인증 서비스를 제공하는 방법 및 이를 이용한 인증 서버
AU2019204723B2 (en) Cryptographic key management based on identity information
ES2833552T3 (es) Sistema y método para la protección de información
JP4036838B2 (ja) セキュリティ装置、情報処理装置、セキュリティ装置が実行する方法、情報処理装置が実行する方法、該方法を実行させるための装置実行可能なプログラムおよびチケット・システム
US8271791B2 (en) Long-term secure digital signatures
US20190207767A1 (en) Block chain supporting multiple one-way functions used for verification of blocks
CN101488856B (zh) 用于数字签名以及认证的系统及方法
EP3967019A1 (en) Transferring digital assets possession over a unidirectional connection
ES2733362T3 (es) Sistema y método de cifrado
US20050283601A1 (en) Systems and methods for securing a computer boot
KR101858653B1 (ko) 블록체인 데이터베이스 및 이와 연동하는 머클 트리 구조를 통해 모바일 아이디를 이용하여 사용자를 인증하는 방법, 단말 및 이를 이용한 서버
KR20190045753A (ko) 암호 화폐의 전자 지갑 생성 및 백업 방법 및 이를 이용한 단말 장치와 서버
EP3863218A1 (en) Information processing device, method and program
CN111492390A (zh) 用于数字货币的现金等价设备
US20170359358A1 (en) Method for making contactless transactions secure
CN111160879B (zh) 一种硬件钱包及其安全性提升方法和装置
ES3061620T3 (en) Secure token wallet and electronic transaction system
US20250165970A1 (en) A system and method for providing data privacy in a blockchain network
CN110648235A (zh) 一种基于可信计算环境tee的跨链资产转移方法
ES3015231T3 (en) Regaining an original card security code used in a card based transaction
ES2639556T3 (es) Procedimiento para la realización de transacciones
JP2003506771A (ja) スマートカード間の通信システム及び方法
KR101850705B1 (ko) 앱 방식을 이용한 교통카드 발급 및 운용 시스템 및 방법
US20250384430A1 (en) Hardware wallet and method to securely sign a transaction with a hardware wallet