ES2876926T3 - Protección de datos de cadena de bloques utilizando cifrado homomórfico - Google Patents
Protección de datos de cadena de bloques utilizando cifrado homomórfico Download PDFInfo
- Publication number
- ES2876926T3 ES2876926T3 ES18867272T ES18867272T ES2876926T3 ES 2876926 T3 ES2876926 T3 ES 2876926T3 ES 18867272 T ES18867272 T ES 18867272T ES 18867272 T ES18867272 T ES 18867272T ES 2876926 T3 ES2876926 T3 ES 2876926T3
- Authority
- ES
- Spain
- Prior art keywords
- random number
- account
- balance
- blockchain
- transaction
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/008—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving homomorphic encryption
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
- H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/08—Randomization, e.g. dummy operations or using noise
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/16—Obfuscation or hiding, e.g. involving white box
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Power Engineering (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Storage Device Security (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Un método (800) implementado por computadora realizado por un nodo de consenso de una red (102) de cadena de bloques, que comprende: recibir (802), de una primera cuenta: una copia firmada digitalmente de lo siguiente: un valor de compromiso de un monto de transacción asociado con una transferencia de saldo de la primera cuenta a una segunda cuenta generado en base a un primer número aleatorio, además del valor de compromiso, un segundo número aleatorio cifrado utilizando una clave pública de la primera cuenta, un tercer número aleatorio cifrado utilizando una clave pública de la segunda cuenta, una o más pruebas de rango, y un conjunto de valores generados en base a uno o más números aleatorios seleccionados; verificar (804) una firma digital correspondiente a la copia firmada digitalmente utilizando una clave pública de la primera cuenta correspondiente a una clave privada utilizada para generar la firma digital; determinar (806) que una o más pruebas de rango prueban que el monto de transacción es mayor que cero y menor o igual que un saldo de la primera cuenta; determinar (808) si el primer número aleatorio, el segundo número aleatorio y el tercer número aleatorio son iguales en base al conjunto de valores; y en respuesta a determinar que el primer número aleatorio, el segundo número aleatorio y el tercer número aleatorio son iguales, actualizar (810) el saldo de la primera cuenta y un saldo de la segunda cuenta en base al monto de la transferencia de saldo; en donde el segundo número aleatorio y el tercer número aleatorio se cifran en base a un esquema de cifrado homomórfico, HE, determinista que tiene propiedades lineales de HE(a + b) = HE(a) * HE(b) y HE(ab) = HE(b)a, donde a y b son texto plano utilizado para HE.
Description
DESCRIPCIÓN
Protección de datos de cadena de bloques utilizando cifrado homomórfico
ANTECEDENTES
Las redes de cadena de bloques, que también pueden denominarse sistemas de cadena de bloques, redes de consenso, redes de sistemas de libro de contabilidad distribuido o cadena de bloques, permiten a las entidades participantes almacenar datos de forma segura e inmutable. Una cadena de bloques se puede describir como un sistema de libro de contabilidad de transacciones, y se almacenan múltiples copias del libro de contabilidad en la red de cadena de bloques. Los tipos de ejemplo de cadenas de bloques pueden incluir cadenas de bloques públicas, cadenas de bloques autorizadas y cadenas de bloques privadas. Una cadena de bloques pública está abierta para que todas las entidades utilicen la cadena de bloques y participen en el proceso de consenso. Una cadena de bloques autorizada es similar a una cadena de bloques pública, pero está abierta solo para entidades con permiso para unirse. Se proporciona una cadena de bloques privada para una entidad particular, que controla de forma centralizada los permisos de lectura y escritura.
Las cadenas de bloques se utilizan en redes de criptomonedas, que permiten a los participantes realizar transacciones para comprar/vender bienes y/o servicios utilizando una criptomoneda. Una criptomoneda común incluye Bitcoin. En las redes de criptomonedas, los modelos de mantenimiento de registros se utilizan para registrar transacciones entre usuarios. Los modelos de mantenimiento de registros de ejemplo incluyen el modelo de salida de transacciones no gastadas (UTXO) y el modelo de saldo de cuenta. En el modelo UTXO, cada una de las transacciones gasta la salida de transacciones anteriores y genera nuevas salidas que se pueden gastar en transacciones posteriores. Se realiza un seguimiento de las transacciones no gastadas de un usuario y el saldo que posee el usuario se calcula como la suma de todas las transacciones no gastadas del usuario. En el modelo de saldo de la cuenta, el saldo de la cuenta de cada uno de los usuarios se registra como un estado global. Para cada una de las transacciones, se verifica el saldo de una cuenta de gastos para asegurarse de que sea mayor o igual al monto de la transacción. Esto es comparable a la banca tradicional.
Un libro de contabilidad de cadena de bloques incluye una serie de bloques, cada uno de los cuales contiene una o más transacciones ejecutadas en la red. Cada uno de los bloques puede ser análogo a una página del libro mayor, mientras que la cadena de bloques en sí es una copia completa del libro mayor. Las transacciones individuales se confirman y se añaden a un bloque, que se añade a la cadena de bloques. Las copias del libro de contabilidad de cadena de bloques se replican en todos los nodos de la red. De esta manera, existe un consenso global sobre el estado de la cadena de bloques. Además, la cadena de bloques está abierta para que la vean todos los nodos, al menos en el caso de las redes públicas. Para proteger la privacidad de los usuarios de cadena de bloques, se pueden implementar tecnologías de cifrado.
Según el modelo de cuenta, los esquemas de compromiso se pueden utilizar para ocultar valores con los que ambas partes de una transacción se comprometen. Los esquemas de compromiso pueden surgir de la necesidad de que las partes se comprometan con una elección o valor, y luego comuniquen ese valor a las otras partes involucradas. Por ejemplo, en un compromiso de Pedersen interactivo, la parte A puede comprometerse con un monto t de transacción enviando un valor PC(r, t) de compromiso que se genera en base al valor raleatorio. Se genera el valor de compromiso y la parte B solo puede revelar el monto t de transacción obteniendo el número r aleatorio.
BF Franga, "Homomorphic Mini-blockchain Scheme", XP055624506, 24 de abril de 2015, describe un esquema de criptomonedas en base al esquema de mini-cadena de bloques y compromisos homomórficos ideados con el objetivo de mejorar la privacidad de la mini-cadena de bloques. Franga también describe una comparación del esquema con Bitcoin con respecto a la capacidad de resistir el análisis de cadena de bloques.
RESUMEN
La invención se define en las reivindicaciones adjuntas. Las implementaciones de la presente divulgación incluyen métodos implementados por computadora para la verificación de privacidad protegida de transacciones de cadena de bloques sin confirmación del usuario, interacción y revelación de montos de transacciones o saldos de cuentas. Más particularmente, las implementaciones de la presente divulgación están dirigidas a validar transacciones entre usuarios de cadena de bloques en base a esquemas de compromiso y cifrado homomórfico sin revelar el monto de transacción, saldos de cuentas o números aleatorios para generar compromisos con otros nodos de cadena de bloques.
En algunas implementaciones, las acciones incluyen recibir, desde una primera cuenta, una copia firmada digitalmente de un valor de compromiso de un monto de transacción a ser transferido desde la primera cuenta a una segunda cuenta generada en base a un primer número aleatorio, un segundo número aleatorio cifrado utilizando una clave pública de la primera cuenta, un tercer número aleatorio cifrado utilizando una clave pública de la segunda cuenta, una o más pruebas de rango y un conjunto de valores generados en base a uno o más números aleatorios seleccionados; verificar una firma digital correspondiente a la copia firmada digitalmente utilizando una clave pública
de la primera cuenta correspondiente a una clave privada utilizada para generar la firma digital; determinar que una o más pruebas de rango prueban que el monto de transacción es mayor que cero y menor o igual que el saldo de la primera cuenta; determinar si el primer número aleatorio, el segundo número aleatorio y el tercer número aleatorio son iguales en base al conjunto de valores; y actualizar el saldo de la primera cuenta y el saldo de la segunda cuenta en base al monto de la transferencia de saldo si el primer número aleatorio, el segundo número aleatorio y el tercer número aleatorio son iguales. Otras implementaciones incluyen sistemas, aparatos y programas informáticos correspondientes, configurados para realizar las acciones de los métodos, codificados en dispositivos de almacenamiento informáticos.
Cada una de estas y otras implementaciones puede incluir opcionalmente una o más de las siguientes características: el valor de compromiso se genera utilizando un esquema de compromiso que es homomórfico; el esquema de compromiso es un esquema de compromiso de Pedersen; el segundo número aleatorio y el tercer número aleatorio se cifran en base a un esquema de cifrado homomórfico (HE) determinista que tiene propiedades lineales de HE(a b) = HE(a) * HE(b) y HE(ab) = HE(b)a, donde a y b son texto plano utilizado para HE; el método implementado por computadora de la reivindicación 4, en donde los números aleatorios seleccionados están representados por r1 y t1, y los números aleatorios seleccionados se utilizan para generar r2 y t2, donde r2 = r1 + xr, t2 = ti + xt, donde r1 y ti representa uno o más números aleatorios seleccionados, r es el primer número aleatorio, t es el monto de la transferencia de saldo, x es un valor de resumen; el conjunto de valores está además generado en base a T1, T1 ’ y T1 ’’, donde T1 = gr1ht1, T1’ = HE_A(r1), T1’’ = HE_B(r1), donde g y h son generadores de una curva elíptica, y en donde HE_A(r1) se genera en base a HE de r1 utilizando la clave pública de la primera cuenta y HE_B(r1) se genera en base a HE de r1 utilizando la clave pública de la segunda cuenta, y en donde x se genera en base a resumir T1, T1’ y T1’’ ; se determina que el primer número aleatorio, el segundo número aleatorio y el tercer número aleatorio son iguales en base a las propiedades de HE determinista; el primer número aleatorio, el segundo número aleatorio y el tercer número aleatorio se determinan que son el mismo si gr2ht2 = TxT1, HE_A(r2) = T’xT1’ y HE_B(r2) = T’’xT1’’, donde T = grht, T’ = HE_A(r) y T’’ = HE_B(r), y en donde HE_A(r) y HE_A(r2) se generan en base a h E de r y r2, respectivamente, utilizando la clave pública de la primera cuenta, HE_B(r) y HE_B(r2) se generan en base a HE de r y r2 utilizando la clave pública de la segunda cuenta; T, T’ y T’’ forman un texto cifrado del monto t de transacción; y la actualización del saldo de la primera cuenta y el saldo de la segunda cuenta se realiza en base al cifrado homomórfico.
La presente divulgación también proporciona uno o más medios de almacenamiento legibles por computadora no transitorios acoplados a uno o más procesadores y que tienen instrucciones almacenadas en los mismos que, cuando se ejecutan por el uno o más procesadores, hacen que el uno o más procesadores realicen operaciones de acuerdo con implementaciones de los métodos proporcionados en el presente documento.
La presente divulgación proporciona además un sistema para implementar los métodos proporcionados en el presente documento. El sistema incluye uno o más procesadores y un medio de almacenamiento legible por computadora acoplado al uno o más procesadores que tienen instrucciones almacenadas en los mismos que, cuando se ejecutan por el uno o más procesadores, hacen que el uno o más procesadores realicen operaciones de acuerdo con implementaciones de los métodos proporcionados en el presente documento.
Se aprecia que los métodos de acuerdo con la presente divulgación pueden incluir cualquier combinación de los aspectos y características descritos en el presente documento. Es decir, los métodos de acuerdo con la presente divulgación no se limitan a las combinaciones de aspectos y características descritas específicamente en el presente documento, sino que también incluyen cualquier combinación de los aspectos y características proporcionados.
Los detalles de una o más implementaciones de la presente divulgación se establecen en los dibujos adjuntos y la descripción a continuación. Otras características y ventajas de la presente divulgación resultarán evidentes a partir de la descripción y los dibujos, y de las reivindicaciones.
DESCRIPCION DE LOS DIBUJOS
La FIG. 1 representa un entorno de ejemplo que puede utilizarse para ejecutar implementaciones de la presente divulgación.
La FIG. 2 representa una arquitectura conceptual de ejemplo de acuerdo con implementaciones de la presente divulgación.
La FIG. 3 representa un método de ejemplo de validación de privacidad protegida de una transacción de cadena de bloques en base a cifrado homomórfico de acuerdo con implementaciones de la presente divulgación.
La FIG. 4 representa una transacción de cadena de bloques de ejemplo en base a cifrado homomórfico de acuerdo con implementaciones de la presente divulgación.
La FIG. 5 representa otro método de ejemplo de validación de privacidad protegida de una transacción de cadena de bloques en base a cifrado homomórfico de acuerdo con implementaciones de la presente divulgación.
La FIG. 6 representa otro ejemplo de transacción de cadena de bloques en base a cifrado homomórfico de acuerdo con implementaciones de la presente divulgación.
La FIG. 7 representa un proceso de ejemplo que puede ejecutarse de acuerdo con implementaciones de la presente divulgación.
La FIG. 8 representa otro proceso de ejemplo que puede ejecutarse de acuerdo con implementaciones de la presente divulgación.
Los símbolos de referencia similares en los diversos dibujos indican elementos similares.
DESCRIPCIÓN DETALLADA
Las implementaciones de la presente divulgación incluyen métodos implementados por computadora para la verificación de privacidad protegida de transacciones de cadena de bloques sin confirmación del usuario, interacción y revelación de montos de transacciones o saldos de cuentas. Más particularmente, las implementaciones de la presente divulgación están dirigidas a validar transacciones entre usuarios de cadena de bloques en base a esquemas de compromiso y cifrados homomórficos (HE) sin revelar el monto de transacción, saldos de cuentas o números aleatorios para generar compromisos con otros nodos de cadena de bloques.
Para proporcionar un contexto adicional para las implementaciones de la presente divulgación, y como se introdujo anteriormente, las redes de cadena de bloques, que también pueden denominarse redes de consenso (p. ej., compuestas por nodos de igual a igual), sistema de libro de contabilidad distribuido o simplemente cadena de bloques, permiten que las entidades participantes realicen transacciones de forma segura e inmutable y almacenen datos. Una cadena de bloques se puede proporcionar como una cadena de bloques pública, una cadena de bloques privada o una cadena de bloques de consorcio. Las implementaciones de la presente divulgación se describen con más detalle en el presente documento con referencia a una cadena de bloques pública, que es pública entre las entidades participantes. Sin embargo, se contempla que las implementaciones de la presente divulgación se puedan realizar en cualquier tipo apropiado de cadena de bloques.
En una cadena de bloques pública, el proceso de consenso está controlado por nodos de la red de consenso. Por ejemplo, cientos, miles, incluso millones de entidades pueden participar en una cadena de bloques pública, cada una de las cuales opera al menos un nodo en la cadena de bloques pública. En consecuencia, la cadena de bloques pública puede considerarse una red pública con respecto a las entidades participantes. En algunos ejemplos, la mayoría de las entidades (nodos) deben firmar cada uno de los bloques para que el bloque sea válido y se añada a la cadena de bloques. Un ejemplo de cadena de bloques pública incluye la cadena de bloques utilizada en la red Bitcoin, que es una red de pago de igual a igual (red de criptomonedas). Aunque el término cadena de bloques se hace referencia comúnmente a la red de Bitcoin, como se utiliza en el presente documento, cadena de bloques generalmente se refiere a libros de contabilidad distribuidos sin una referencia particular a la red de Bitcoin.
En general, una cadena de bloques pública soporta transacciones públicas. Una transacción pública se comparte con todos los nodos dentro de la cadena de bloques y el libro de contabilidad de la cadena de bloques se replica en todos los nodos. Es decir, todos los nodos están en perfecto estado de consenso con respecto a la cadena de bloques. Para lograr un consenso (p. ej., un acuerdo para la adición de un bloque a una cadena de bloques), se implementa un protocolo de consenso dentro de la red de la cadena de bloques. Un ejemplo de protocolo de consenso incluye, sin limitación, prueba de trabajo (POW) implementado en la red Bitcoin.
Las implementaciones de la presente divulgación se describen con más detalle en el presente documento en vista del contexto anterior. Más particularmente, y como se introdujo anteriormente, las implementaciones de la presente divulgación están dirigidas a validar transacciones entre usuarios de cadena de bloques en base a esquemas de compromiso y HE sin revelar el monto de transacción, los saldos de cuenta o los números aleatorios para generar los compromisos a otros nodos de cadena de bloques.
De acuerdo con las implementaciones de la presente divulgación, las transacciones de cadena de bloques se pueden validar y registrar en una cadena de bloques (libro de contabilidad) en base al compromiso sin revelar el saldo de cuenta de transacción, el monto de transacción o el número aleatorio utilizado para generar el compromiso. Se puede utilizar un esquema de compromiso, tal como el compromiso de Pedersen (PC), para generar un compromiso de un monto de transacción utilizando un número aleatorio. El monto de transacción y el número aleatorio se pueden cifrar utilizando HE probabilístico o determinista. El monto de transacción y el número aleatorio también se pueden utilizar para generar un conjunto de valores como pruebas para validar la transacción en base a las propiedades de HE. Un nodo de cadena de bloques puede utilizar el compromiso de la transacción, el monto de transacción cifrado, el número
aleatorio cifrado y las pruebas para verificar si la transacción es válida sin que se revele el saldo de cuenta, el monto de transacción o el número aleatorio.
La FIG. 1 representa un entorno 100 de ejemplo que puede utilizarse para ejecutar implementaciones de la presente divulgación. En algunos ejemplos, el entorno 100 de ejemplo permite a las entidades participar en una cadena 102 de bloques pública. El entorno 100 de ejemplo incluye sistemas 106, 108 informáticos y una red 110. En algunos ejemplos, la red 110 incluye una red de área local (LAN), red de área amplia (WAN), el Internet o una combinación de las mismas, y conecta sitios web, dispositivos de usuario (p. ej., dispositivos informáticos) y sistemas de servidor. En algunos ejemplos, se puede acceder a la red 110 a través de un enlace de comunicaciones cableado y/o inalámbrico.
En el ejemplo representado, los sistemas 106, 108 informáticos pueden incluir cada uno cualquier sistema informático apropiado que permita la participación como un nodo en la cadena 102 de bloques pública. Los dispositivos informáticos de ejemplo incluyen, sin limitación, un servidor, una computadora de escritorio, una computadora portátil, un dispositivo de computadora tableta y un teléfono inteligente. En algunos ejemplos, los sistemas 106, 108 informáticos alojan uno o más servicios implementados por computadora para interactuar con la cadena 102 de bloques pública. Por ejemplo, el sistema 106 informático puede alojar servicios implementados por computadora de una primera entidad (p. ej., el usuario A), tal como un sistema de gestión de transacciones que utiliza la primera entidad para gestionar sus transacciones con una o más entidades (p. ej., otros usuarios). El sistema 108 informático puede alojar servicios implementados por computadora de una segunda entidad (p. ej., el usuario B), tal como un sistema de gestión de transacciones que utiliza la segunda entidad para gestionar sus transacciones con una o más de otras entidades (p. ej., otros usuarios). En el ejemplo de la FIG. 1, la cadena 102 de bloques pública se representa como una red de nodos de igual a igual, y los sistemas 106, 108 informáticos proporcionan nodos de la primera entidad y la segunda entidad, respectivamente, que participan en la cadena 102 de bloques pública.
La FIG. 2 representa una arquitectura 200 conceptual de ejemplo de acuerdo con implementaciones de la presente divulgación. La arquitectura 200 conceptual de ejemplo incluye una capa 202 de entidad, una capa 204 de servicios alojados y una capa 206 de cadena de bloques pública. En el ejemplo representado, la capa 202 de entidad incluye tres entidades, Entidad_1 (E1), Entidad_2 (E2) y Entidad_3 ( E3), teniendo cada una de las entidades un respectivo sistema 208 de gestión de transacciones.
En el ejemplo representado, la capa 204 de servicios alojados incluye interfaces 210 de cadena de bloques para cada uno de los sistemas 208 de gestión de transacciones. En algunos ejemplos, un sistema 208 de gestión de transacciones respectivo se comunica con una interfaz 210 de cadena de bloques respectiva a través de una red (p. ej., la red 110 de la FIG. 1) utilizando un protocolo de comunicación (p. ej., protocolo de transferencia de hipertexto seguro (HTTPS)). En algunos ejemplos, cada una de las interfaces 210 de cadena de bloques proporciona una conexión de comunicación entre un sistema 208 de gestión de transacciones respectivo y la capa 206 de cadena de bloques. Más particularmente, cada una de las interfaces 210 de cadena de bloques permite a la respectiva entidad realizar transacciones registradas en una red 212 de cadena de bloques de la capa 206 de cadena de bloques. En algunos ejemplos, la comunicación entre una interfaz 210 de cadena de bloques y la capa 206 de cadena de bloques se realiza utilizando llamadas a procedimientos remotos (RPC). En algunos ejemplos, las interfaces 210 de cadena de bloques "alojan" nodos de cadena de bloques para los respectivos sistemas 208 de gestión de transacciones. Por ejemplo, las interfaces 210 de cadena de bloques proporcionan la interfaz de programación de aplicaciones (API) para acceder a la red 212 de cadena de bloques.
Como se describe en el presente documento, la red 212 de cadena de bloques se proporciona como una red de igual a igual que incluye una pluralidad de nodos 214 que registran información de manera inmutable en una cadena 216 de bloques. Aunque se representa esquemáticamente una única cadena 216 de bloques, se proporcionan múltiples copias de la cadena 216 de bloques y se mantienen a través de la cadena de bloques 212. Por ejemplo, cada uno de los nodos 214 almacena una copia de la cadena 216 de bloques. En algunas implementaciones, la cadena 216 de bloques almacena información asociada con transacciones que se realizan entre dos o más entidades que participan en la cadena de bloques pública.
La FIG. 3 representa un método 300 de ejemplo de validación de privacidad protegida de una transacción de cadena de bloques en base a HE de acuerdo con implementaciones de la presente divulgación. A alto nivel, el método 300 de ejemplo se realiza por un nodo A 302 de usuario, un nodo B de usuario (no mostrado en la FIG. 3) y un nodo 304 de cadena de bloques, también denominado un nodo de consenso. Se puede realizar una transacción, tal como una transferencia de valor, desde el nodo A 302 de usuario al nodo B de usuario. Para proteger la privacidad de la cuenta, el nodo A 302 de usuario puede generar un compromiso de un monto t de transacción utilizando un esquema de compromiso, tal como PC, en base a un número r aleatorio. El compromiso generado utilizando PC se puede expresar como PC(r, t). El nodo A 302 de usuario también puede cifrar el número aleatorio utilizando HE en base a una clave pública del nodo B de usuario. Esto puede expresarse como HE(r). Un texto cifrado del monto t de transacción, expresado como (PC(r, t), HE(r)) se puede transmitir al nodo B de usuario. Después de recibir el texto cifrado, el nodo B de usuario puede descifrar el número r aleatorio utilizando una clave privada. El nodo B de usuario puede utilizar el número r aleatorio para descifrar el monto t de transacción. Para probar la validez de la transacción, el nodo 304 de cadena de bloques puede comparar el número aleatorio en el compromiso y el número aleatorio cifrado utilizando HE. Si los números aleatorios coinciden, el nodo 304 de cadena de bloques determina que la transacción es válida sin
conocimiento de los datos de transacción. Más detalles del método 300 de ejemplo se discuten en la siguiente descripción de la FIG. 3.
En 306, el nodo A 302 de usuario genera un valor de compromiso de un monto de transacción en base a un primer número aleatorio y cifra, en base a HE, un segundo número aleatorio utilizando una clave pública del nodo A 302 de usuario, y un tercer número aleatorio utilizando una clave pública del nodo B de usuario. El primer número aleatorio, el segundo número aleatorio y el tercer número aleatorio pueden ser el mismo número r aleatorio utilizado para generar un compromiso de un monto t de transacción utilizando un esquema de compromiso. En algunas implementaciones, el esquema de compromiso puede tener una forma exponencial doble, tal como el PC. Utilizando el PC como un ejemplo no limitante, el valor de compromiso generado por el primer número r aleatorio se puede expresar como PC(r, t) = grht, donde g y h pueden ser generadores de una curva elíptica, PC(r, t) es una multiplicación escalar de puntos de curva y t es el monto de transacción que se compromete. Debe entenderse que también se pueden utilizar otros esquemas de compromiso en base a HE, tal como Okamoto-Uchiyama (OU) HE y Boneh-Goh-Nissim HE para generar el valor de compromiso.
El cifrado del segundo número r aleatorio cifrado utilizando la clave pública del nodo A 302 de usuario puede expresarse como HE_A(r). El cifrado del tercer número r aleatorio cifrado utilizando la clave pública del nodo B de usuario puede expresarse como HE_B(r).
En algunas implementaciones, el cifrado HE de clave pública puede ser un HE determinista que se puede obtener a partir de esquemas de HE probabilísticos, tal como Paillier HE, Benaloh HE, OU HE, Naccache-Stern HE, Damgard-Jurik HE o Boneh-Goh-Nissim HE, estableciendo el número aleatorio en un valor fijo. En algunas implementaciones, para la presente divulgación se pueden utilizar esquemas HE deterministas que satisfacen las propiedades lineales que HE(a b) = HE(a) HE(b) y HE(ab) = HE(b)a, donde a y b son texto plano utilizado para HE.
En algunos ejemplos, T = PC(r, t), T' = HE_A(r) y T" = HE_B(r), y el texto cifrado del monto de transacción se puede expresar como (T, T’ y T’’). Se puede determinar que la transacción es válida, si se cumplen las condiciones de ejemplo. Primero, el monto t de transacción es mayor o igual a 0 y menor o igual al saldo s_A de cuenta del nodo A 302 de usuario. En segundo lugar, la transacción se firma digitalmente mediante la clave privada del nodo A 302 de usuario para demostrar que la transacción está autorizada por el nodo A 302 de usuario. En tercer lugar, el número r aleatorio en el compromiso PC(r, t) es el mismo que el r cifrado en el texto cifrado HE_A(r) y HE_B(r) utilizando las claves públicas del nodo A 302 de usuario y el nodo B de usuario, respectivamente.
En algunas implementaciones, el texto cifrado también se puede separar como un texto cifrado de un monto (?) enviado, que se puede expresar como (PC (r', t'), HE_A(r')), y un texto cifrado de un monto (í") recibido, que se puede expresar como (PC(r", t''), HE_B(r")). En tales casos, el monto t ’ enviado también debe determinarse para que sea el mismo que el monto t ’’ recibido para validar la transacción.
En 308, el nodo 302 A de usuario genera una o más pruebas de rango. En algunas implementaciones, las pruebas de rango pueden incluir una prueba RP1 de rango, para mostrar que el monto t de transacción es mayor o igual a cero, y una prueba RP2 de rango para mostrar que el monto t de transacción es menor o igual a un saldo de cuenta del nodo A de usuario.
En 310, el nodo A 302 de usuario genera un conjunto de valores utilizando HE en base a uno o más números aleatorios seleccionados. El conjunto de valores, denotado como Pf, puede incluir pruebas utilizadas para demostrar que el número r aleatorio en el compromiso PC(r, t) es el mismo que el r cifrado en el texto cifrado HE_A(r) y HE_B(r) utilizando el claves públicas del nodo A 302 de usuario y del nodo B de usuario, respectivamente. En algunas implementaciones, se pueden seleccionar dos números r1 y ti aleatorios para calcular otro conjunto de textos cifrados de ti denotados como (T1, T1’, T1’’), donde T1 = gr1hr1, T1’ = HE_A(r1), T1’’ = HE_B(r1). Se pueden calcular dos pruebas r2 y t2 adicionales como r2 = r1 xr, t2 = t1 xt, donde x es el resumen de T1, T1’ y T1’’. El conjunto de valores se puede denotar como P f = (T1, T1’, T1’’, r2, t2).
En 312, el nodo A 302 de usuario utiliza su clave privada para firmar digitalmente el texto cifrado (T, T’, T’’), el texto cifrado (T1, T1’, T1’’), r2, t2, las pruebas RP1 y RP2 de rango y las claves públicas del nodo A 302 de usuario y del nodo B de usuario. La firma digital añadida por el nodo A 302 de usuario puede utilizarse para mostrar que la transacción está autorizada por el nodo A 302 de usuario. Se envía la copia firmada digitalmente a la red de cadena de bloques en 314.
En 316, el nodo 304 de cadena de bloques verifica la firma digital utilizando una clave pública del nodo A 302 de usuario. El nodo 304 de cadena de bloques puede ser un nodo de consenso que puede probar la validez de las transacciones en la red de cadena de bloques. Si el nodo 304 de cadena de bloques no puede verificar la firma digital del nodo A 302 de usuario utilizando la clave pública, se puede determinar que la firma digital es incorrecta y se puede denegar la transacción. En algunas implementaciones, el nodo 304 de cadena de bloques también puede incluir un mecanismo anti-doble gasto. El nodo 304 de cadena de bloques puede verificar si la transacción ya se ha ejecutado o registrado. Si la transacción ya se ha ejecutado, la transacción se puede rechazar. De lo contrario, la validación de la transacción puede continuar.
En 318, el nodo 304 de cadena de bloques verifica una o más pruebas de rango. Por ejemplo, la prueba RP1 de rango se puede utilizar para demostrar que el monto t de transacción es mayor o igual a cero y la prueba RP2 de rango se puede utilizar para probar que el monto t de transacción es menor o igual a un saldo de cuenta del nodo A 302 de usuario.
En 320, el nodo 304 de cadena de bloques determina que el primer número aleatorio, el segundo número aleatorio y el tercer número aleatorio son iguales en base al conjunto de valores. En algunas implementaciones, la determinación incluye determinar si las condiciones de ejemplo g r2 h t2 = TxT 1, HE_A(r2) = T’xT 1 ’ y HE_B(r2) = T’’xT 1 ’’ son verdaderas en base a las propiedades de HE determinista, como se discutió anteriormente. Si es verdadero, se puede indicar que el número aleatorio en el compromiso es el mismo que los números aleatorios cifrados homomórficamente utilizando las claves públicas del nodo A 302 de usuario y del nodo B de usuario, y la transacción es válida.
En 322, el nodo 304 de cadena de bloques actualiza los saldos de cuenta del nodo A 302 de usuario y del nodo B de usuario. Las actualizaciones de saldo se pueden realizar en base a las propiedades de HE sin revelar los saldos de cuenta del nodo A 302 de usuario o del nodo B de usuario. La actualización de los saldos de cuenta se describe con más detalle en el presente documento con referencia a la FIG. 4.
La FIG. 4 representa una transacción 400 de cadena de bloques de ejemplo en base a HE de acuerdo con implementaciones de la presente divulgación. Como se muestra en la transacción 400 de cadena de bloques de ejemplo, un nodo A 402 de usuario transfiere un monto t de transacción a un nodo B 406 de usuario. Antes de la transacción, el nodo A 402 de usuario tiene un saldo de cuenta de s_A, y el nodo B 406 de usuario tiene un saldo de cuenta de s_B.
Utilizando los esquemas de cifrado y el proceso de transacción descritos en el presente documento con referencia a la FIG. 3 como ejemplo, el saldo s_A de cuenta se puede cifrar utilizando un número r_A aleatorio en base a PC, y el número r_A aleatorio se puede cifrar en base a HE. El texto cifrado del saldo s_A de cuenta se puede expresar como (S_A, S’_A) = (g r_A h s_A , HE_A(r_A)), donde g y h pueden ser generadores de una curva elíptica para generar el PC del saldo s_A de cuenta. De manera similar, un saldo s_B de cuenta del nodo B 406 de usuario se puede cifrar utilizando un número r_B aleatorio en base a PC. El texto cifrado del saldo s_B de cuenta se puede expresar como (S_B, S'_B) = (g r_ B h s_ B , HE_A(r_B)).
En 404, el nodo A 402 de usuario puede añadir firma digital a las pruebas utilizadas para validar la transacción y enviar la copia firmada digitalmente a la red 408 de cadena de bloques. Como se describió anteriormente con referencia a la FIG. 3, las pruebas pueden incluir el texto cifrado de monto (T, T’, T’’) de transacción, la una o más pruebas (RP1, RP2) de rango y otras pruebas (T1, T1’, T1’’, r2, t2).
Después de la transacción, el saldo de cuenta del nodo A 402 de usuario se puede expresar como s_A - 1, y el saldo de cuenta del nodo B 406 de usuario se puede expresar como s_B f", donde t' es el monto enviado por el nodo A 402 de usuario y t'' es el monto recibido por el nodo B de usuario. El texto cifrado del saldo de cuenta del nodo A 402 de usuario después de la transacción se puede expresar como (S_A / T, S’_A / T’) y el texto cifrado del saldo de cuenta del nodo B 406 de usuario después de la transacción se puede expresar como (S_B * T, S’_B * T’’). Dado que S_A, S’_A, S_B, S’_B, T, T’, T’’ se cifran cada uno utilizando HE con forma exponencial doble, la suma y la resta se pueden realizar en su forma cifrada sin descifrar los valores de texto sin formato.
La FIG. 5 representa otro método 500 de ejemplo de validación de privacidad protegida de una transacción de cadena de bloques en base a HE de acuerdo con implementaciones de la presente divulgación. A alto nivel, el método 500 de ejemplo lo realiza un nodo A 502 de usuario, un nodo B de usuario (no mostrado en la FIG. 5) y un nodo 504 de cadena de bloques, que puede denominarse nodo de consenso. Se puede realizar una transacción, tal como una transferencia de valor, desde el nodo A 502 de usuario al nodo B de usuario. Para proteger la privacidad de cuenta, el nodo A 502 de usuario puede generar un compromiso del monto t de transacción utilizando un esquema de compromiso tal como PC en base a un número r aleatorio. El compromiso generado utilizando PC se puede expresar PC(r, t). El nodo A 502 de usuario también puede cifrar el monto tde transacción y el número r aleatorio utilizando HE que tiene una forma exponencial doble, tal como la OU.
Se puede enviar un texto cifrado del monto t de transacción a la red de cadena de bloques. Después de recibir el texto cifrado, el nodo 504 de cadena de bloques puede determinar si el número r aleatorio oculto en PC coincide con el número r aleatorio cifrado en OU utilizando las claves públicas del nodo A 502 de usuario y el nodo B de usuario, respectivamente. Además, el nodo 504 de cadena de bloques puede determinar si el monto t de transacción oculto en PC coincide con el monto t de transacción cifrado en OU utilizando las claves públicas del nodo A 502 de usuario y del nodo B de usuario, respectivamente. Si tanto los números aleatorios como los montos de transacción coinciden, el nodo 504 de la cadena de bloques puede determinar que la transacción es válida con conocimiento cero de los datos de transacción.
En 506, el nodo A 502 de usuario genera un valor de compromiso de un primer monto de transacción en base a un primer número aleatorio, y el primer monto de transacción y el primer número aleatorio cifrados utilizando una clave
pública del nodo A 502 de usuario. Un segundo monto de transacción y un segundo número aleatorio se cifran utilizando una clave pública del nodo B de usuario. El primer monto de transacción y el segundo monto de transacción pueden ser el mismo monto t. El primer número aleatorio y el segundo número aleatorio pueden ser el mismo número r aleatorio utilizado para generar un compromiso del monto t de transacción utilizando un esquema de compromiso. En algunas implementaciones, el esquema de compromiso puede tener una forma exponencial doble, tal como el PC. Utilizando el PC como ejemplo, el valor de compromiso generado por el primer número r aleatorio se puede expresar como PC(r, t) = grht, donde g y h pueden ser generadores de una curva elíptica, PC(r, t) es una multiplicación escalar de puntos de curva y t es el monto de transacción que se compromete. Debe entenderse que también se pueden utilizar otros esquemas de compromiso en base a HE, tal como OU HE y Boneh-Goh-Nissim HE para generar el valor de compromiso.
El nodo A 502 de usuario también puede cifrar el primer número aleatorio y el primer monto de transacción utilizando la clave pública del nodo A 502 de usuario, y cifrar el segundo número aleatorio y el segundo monto de transacción utilizando la clave pública del nodo B de usuario. En algunas implementaciones, el cifrado de los números aleatorios y los montos de transacción pueden ser en base a HE probabilístico, tal como OU. Utilizando OU como ejemplo, el cifrado del primer número aleatorio y el primer monto de transacción utilizando la clave pública del nodo A 502 de usuario se puede expresar como OU_A(r) = u1rv1y1, y OU_A(t) = u1tv1y2, respectivamente, donde u1 y vi son generadores en la curva elíptica, e y1 e y2 son números aleatorios utilizados para generar OU_A(r) y OU_A(t). El segundo número aleatorio cifrado y el segundo monto de transacción se pueden expresar como OU_B(r) = u2rv2z1 y OU_B(t) = uZv2z2, respectivamente, donde u2 y v2 son generadores en la curva elíptica, y z1 y z2 son números aleatorios utilizados para generar OU_B(r) y OU_B(t), respectivamente. El OU probabilístico satisface la propiedad de que OU(a + b) = OU(a) * OU(b), donde a y b son el texto plano utilizado para OU.
El texto cifrado del monto tde transacción se puede expresar como (PC(r, t), OU_A(r), OU_A(t), OU_B(r), OU_B(t)). Se puede determinar que la transacción es válida si se cumplen las siguientes condiciones de ejemplo. Primero, el monto t de transacción es mayor o igual a 0 y menor o igual que el saldo s_A de cuenta del nodo A 502 de usuario. En segundo lugar, la transacción se firma digitalmente utilizando la clave privada del nodo A 502 de usuario para probar que la transacción está autorizada por el nodo A 502 de usuario. En tercer lugar, el número r aleatorio en el compromiso PC(r, t) es el mismo que el r cifrado en el texto cifrado OU_A(r) y OU_B(r) utilizando las claves públicas del nodo A 502 de usuario y del nodo B de usuario, respectivamente. En cuarto lugar, el monto t de transacción en el compromiso PC(r, t) es el mismo que el t cifrado en el texto cifrado OU_A(t) y OU_B(t) utilizando las claves públicas del nodo A 502 de usuario y del nodo B de usuario, respectivamente.
En algunas implementaciones, el texto cifrado también se puede separar como un texto cifrado de un monto (f) enviado, que se puede expresar como (PC(r',t'), OU_A(r), OU_A(f)), y un texto cifrado de un monto (t') recibido, que puede expresarse como (PC(r”,t”), OU_B(r'), OU_B(t')). En tales casos, el monto t' enviado también debe determinarse que sea igual al monto t" recibido para validar la transacción.
En 508, el nodo 502 A de usuario genera una o más pruebas de rango. En algunas implementaciones, las pruebas de rango pueden incluir una prueba RP1 de rango, para mostrar que el monto t de transacción es mayor o igual a cero, y una prueba RP2 de rango para mostrar que el monto t de transacción es menor o igual a un saldo de cuenta del nodo A de usuario.
En 510, el nodo A 502 de usuario genera un conjunto de valores utilizando HE en base a uno o más números aleatorios seleccionados. El conjunto de valores denotados como P f puede incluir pruebas utilizadas para demostrar que el número r aleatorio en el compromiso PC(r, t) es el mismo que el r cifrado en el texto cifrado OU_A(r) y OU_B(r), y el monto f de transacción en el compromiso PC(r, t) es el mismo que el t cifrado en el texto cifrado OU_A(t) y OU_B(t). En algunas implementaciones, se pueden seleccionar cuatro números r*, t*, z1* y z2* aleatorios para calcular otro conjunto de textos cifrados denotados como (C, D, E), donde C = g^ tí", D = uZ* v2z1* y E = u2*v2z2\ donde g, h, u2 y v2 son generadores de una curva elíptica. Se pueden calcular cuatro pruebas a, b, c, y d adicionales como a = r* xr, b = t* xt, c = z1* xz1 y d = z2* xz2, donde x es una función de resumen de g, h, u2, v2, C, D y E. El conjunto de valores se puede denotar como P f = (C, D, E, a, b, c, d).
En 512, el nodo A 502 de usuario usa su clave privada para firmar digitalmente el texto cifrado (PC(r, t), OU_A(r), OU_A(t), OU_B(r), OU_B(t)), las pruebas RP1 y RP2 de rango y el conjunto P / de valores. La firma digital añadida por el nodo A 502 de usuario puede utilizarse para mostrar que la transacción está autorizada por el nodo A 502 de usuario. Se envía la copia firmada digitalmente a la red de cadena de bloques en 514.
En 516, el nodo 504 de cadena de bloques verifica la firma digital utilizando una clave pública del nodo A 502 de usuario. El nodo 504 de cadena de bloques puede ser un nodo de consenso que puede probar la validez de las transacciones en la red de cadena de bloques. Si el nodo 504 de cadena de bloques no puede verificar la firma digital utilizando la clave pública del nodo A de usuario, se puede determinar que la firma digital es incorrecta y se puede denegar la transacción. En algunas implementaciones, el nodo 504 de cadena de bloques también puede incluir un mecanismo anti-doble gasto. El nodo 504 de cadena de bloques puede verificar si la transacción ya se ha ejecutado o registrado. Si la transacción ya se ha ejecutado, la transacción se puede rechazar. De lo contrario, la validación de la transacción puede continuar.
En 518, el nodo 504 de cadena de bloques verifica una o más pruebas de rango. Por ejemplo, la prueba RP1 de rango se puede utilizar para demostrar que el monto t de transacción es mayor o igual a cero y la prueba RP2 de rango se puede utilizar para probar que el monto t de transacción es menor o igual a un saldo de cuenta de nodo A 502 de usuario.
En 520, el nodo 504 de cadena de bloques determina si el primer monto de transacción es el mismo que el segundo monto de transacción y si el primer número aleatorio es el mismo que el segundo número aleatorio en base al conjunto de valores. En algunas implementaciones, la determinación incluye determinar si g a h b = CTx, u2 a v2 c = DZ_B1x y u2 b v2 d = EZ_B2x, donde T = gh t es el valor de compromiso del primer monto t de transacción, Z_B1 = u2 r v2 z1 , Z_B2 = u2v2 z2 , y en donde z1 y z2 son números aleatorios utilizados para cifrar el segundo monto de transacción y el segundo número aleatorio en base al esquema HE probabilístico. Si es verdadera, se puede indicar que el número aleatorio y el monto de transacción en el compromiso son, respectivamente, los mismos que los números aleatorios y los montos de transacción cifrados homomórficamente utilizando la clave pública del nodo A 502 de usuario y del nodo B de usuario, y la transacción es válida.
En 522, el nodo 504 de cadena de bloques actualiza los saldos de cuenta del nodo A 502 de usuario y del nodo B de usuario. Las actualizaciones de saldo de cuenta se pueden realizar en base a las propiedades de HE sin revelar los saldos de cuenta del nodo A 502 de usuario y/o del nodo B de usuario.
La FIG. 6 representa otra transacción 600 de cadena de bloques de ejemplo en base a HE de acuerdo con implementaciones de la presente divulgación. Como se muestra en la transacción 600 de ejemplo, un nodo A 602 de usuario transfiere un monto t de transacción a un nodo B 606 de usuario. Antes de la transacción, el nodo A 602 de usuario tiene un saldo de cuenta de s_A y el nodo B 606 de usuario tiene un saldo de cuenta de s_B.
En algunos ejemplos, el saldo s_A de cuenta se puede ocultar utilizando un número r_A aleatorio en base a PC utilizando los esquemas de cifrado y el proceso de transacción descritos en el presente documento con referencia a la FIG. 5. El número r_A aleatorio y el saldo de cuenta se pueden cifrar en de base a OU. El texto cifrado del saldo s_A de cuenta se puede expresar como (S_A, R_A, Q_A) = (g r_A h s_A , OU_A(r_A), OU_A(s_A)), donde g y h pueden ser generadores de una curva elíptica para generar el PC del saldo s_A de cuenta. De manera similar, un saldo s_B de cuenta del nodo B 606 de usuario se puede cifrar utilizando un número r_B aleatorio en base a PC. El texto cifrado del saldo s_B de cuenta se puede expresar como (S_B, S’_B) = (g r_ B h s_ B , OU_B(r_B), OU_B(s_B)).
En 604, el nodo A 602 de usuario puede añadir una firma digital a las pruebas utilizadas para validar la transacción y enviar la copia firmada digitalmente a la red 608 de cadena de bloques. Como se describe en el presente documento con referencia a la FIG. 5, las pruebas pueden incluir el texto cifrado del monto (PC(r, t), OU_A(r), OU_A(t), OU_B(r), OU_B(t)) de transacción, una o más pruebas (RP1, RP2) de rango y otras pruebas (C, D, E, a, b, c, d).
Después de la transacción, el saldo de cuenta del nodo A 602 de usuario se puede expresar como s_A - 1 y el saldo de cuenta del nodo B 606 de usuario se puede expresar como s_B t. El texto cifrado del saldo de cuenta del nodo A 602 de usuario después de la transacción se puede expresar como (S_A / T, R_A / Y_A1, Q_A / Y_A2), donde Y_A1 = OU_A(r) e Y_A2 = OU_A(t). El texto cifrado del saldo de cuenta del nodo B 606 de usuario después de la transacción se puede expresar como (S_B * T, R_B * Z_B1, Q_B * Z_B2), donde Z_B1 = OU_B(r) y Z_B2 = OU_B(t). Dado que S_A, S_B, R_A, R_B, Q_A, Q_B, Y_A1, Y_A2, Z_B1, Z_B2 y T se cifran utilizando HE con forma exponencial doble, la suma y la resta se pueden realizar en su forma cifrada sin descifrar los valores de texto plano.
La FIG. 7 representa un proceso 700 de ejemplo que puede ejecutarse de acuerdo con implementaciones de la presente divulgación. Para mayor claridad de presentación, la descripción que sigue describe generalmente el método 700 en el contexto de las otras figuras en esta descripción. Sin embargo, se entenderá que el proceso 700 de ejemplo puede realizarse, por ejemplo, mediante cualquier sistema, entorno, software y hardware, o una combinación de sistemas, entornos, software y hardware, según sea apropiado. En algunas implementaciones, los pasos del proceso 700 de ejemplo se pueden ejecutar en paralelo, en combinación, en bucles o en cualquier orden.
En 702, un nodo de consenso recibe, de una primera cuenta, una copia firmada digitalmente de un valor de compromiso de un monto de transacción que se transferirá desde la primera cuenta a una segunda cuenta generada en base a un primer número aleatorio. El nodo de consenso también puede recibir de la primera cuenta, un segundo número aleatorio cifrado utilizando una clave pública de la primera cuenta, un tercer número aleatorio cifrado utilizando una clave pública de la segunda cuenta, una o más pruebas de rango y un conjunto de valores generados utilizando HE en base a uno o más números aleatorios seleccionados. En algunas implementaciones, el valor de compromiso se genera utilizando un esquema de compromiso en base a HE. En algunas implementaciones, el segundo número aleatorio y el tercer número aleatorio se cifran en base al esquema HE determinista.
En algunas implementaciones, el conjunto de valores está representado por (T1, T1’, T1 ’’, r2, t2), donde r2 = r1 xr, t2 = t1 xt, donde r1 y t1 representan el uno o más números aleatorios seleccionados y r representa el primer número aleatorio, t representa el monto de la transferencia de saldo. En algunos ejemplos, T1 = g r1 h t1 , T1’ = HE_A(r1), T1’’ = HE_B(r1), donde g y h son generadores de una curva elíptica, HE_A(r1) se genera en base a HE de r1 utilizando la
clave pública de la primera cuenta, y HE_B(r1) se genera en base a HE de r1 utilizando la clave pública de la segunda cuenta. En algunos ejemplos, x se genera en base a resumir T1, T1 ’ y T1
En 704, el nodo de consenso verifica una firma digital correspondiente a la copia firmada digitalmente utilizando una clave pública de la primera cuenta correspondiente a una clave privada utilizada para generar la firma digital.
En 706, el nodo de consenso determina si una o más pruebas de rango prueban que el monto de la transferencia de saldo es mayor que cero y menor o igual que un saldo de la primera cuenta.
En 708, el nodo de consenso determina si el primer número aleatorio, el segundo número aleatorio y el tercer número aleatorio son iguales en base al conjunto de valores. En algunas implementaciones, el primer número aleatorio, el segundo número aleatorio y el tercer número aleatorio se determina que son iguales si gr2ht2 = TxT 1, HE_A(r2) = T’*T 1 ’ y HE_B(r2) = T’’xT1’’, donde T = grht es el valor de compromiso del monto de la transferencia de saldo, T’= HE_A(r) y T’’ = HE_B(r), HE_A(r) se genera en base a HE de r utilizando la clave pública de la primera cuenta, HE_B(r) se genera en base a HE de r utilizando la clave pública de la segunda cuenta, HE_A(r2) se genera en base a HE de r2 utilizando la clave pública de la primera cuenta y HE_B(r2) se genera en base a HE de r2 utilizando la clave pública de la segunda cuenta, x se genera en base a resumir g, h, T1, T1’ y T1’’. En algunas implementaciones, T, T’ y T’’ forman el texto cifrado del monto t de transacción.
En 710, el nodo de consenso actualiza el saldo de la primera cuenta y el saldo de la segunda cuenta en base al monto de transacción, si el primer número aleatorio, el segundo número aleatorio y el tercer número aleatorio son iguales. En algunas implementaciones, la actualización del saldo de la primera cuenta y del saldo de la segunda cuenta se realiza en base a HE.
La FIG. 8 representa otro proceso 800 de ejemplo que se puede ejecutar de acuerdo con implementaciones de la presente divulgación. Para mayor claridad de presentación, la descripción que sigue describe generalmente el proceso 800 de ejemplo en el contexto de las otras figuras en esta descripción. Sin embargo, se entenderá que el proceso 800 de ejemplo puede realizarse, por ejemplo, mediante cualquier sistema, entorno, software y hardware, o una combinación de sistemas, entornos, software y hardware, según sea apropiado. En algunas implementaciones, los pasos del proceso 800 de ejemplo se pueden ejecutar en paralelo, en combinación, en bucles o en cualquier orden.
En 802, un nodo de consenso recibe, de una primera cuenta, una copia firmada digitalmente de un valor de compromiso de un primer monto de transacción para una transferencia de una primera cuenta a una segunda cuenta. En algunos ejemplos, la copia firmada digitalmente del valor de compromiso se genera en base a un primer número aleatorio. El nodo de consenso también recibe el primer monto de transacción y el primer número aleatorio cifrados utilizando una clave pública de la primera cuenta, un segundo monto de la transferencia de saldo y un segundo número aleatorio cifrados utilizando una clave pública de la segunda cuenta, una o más pruebas de rango y un conjunto de valores generados utilizando HE en base a uno o más números aleatorios seleccionados. En algunas implementaciones, el valor de compromiso se genera utilizando el esquema de PC. En algunas implementaciones, el primer monto de la transferencia de saldo y el primer número aleatorio se cifran utilizando la clave pública de la primera cuenta en base a un algoritmo HE probabilístico. En algunos ejemplos, el segundo monto de la transferencia de saldo y un segundo número aleatorio se cifran utilizando la clave pública de la segunda cuenta en base al algoritmo HE probabilístico. En algunas implementaciones, el algoritmo HE probabilístico es un algoritmo HE de Okamoto-Uchiyama.
En algunas implementaciones, el conjunto de valores está representado por (C, D, E, a, b, c, d), donde a = r* xr, b = t* xt, c = z1* xz1 y d = z2* xz2, donde r*, t*, z1*y z2*representan uno o más números aleatorios seleccionados, r representa el primer número aleatorio, t representa el primer monto de la transferencia de saldo, C = g 'h , D = u2r*v2z1\ E = u2tv2z2\ g, h, u2 y v2 son generadores de una curva elíptica y x se genera en base resumir C, D y E.
En 804, el nodo de consenso verifica una firma digital correspondiente a la copia firmada digitalmente utilizando una clave pública de la primera cuenta correspondiente a una clave privada utilizada para generar la firma digital.
En 806, el nodo de consenso determina si una o más pruebas de rango prueban que el monto de la transferencia de saldo es mayor que cero y menor o igual que un saldo de la primera cuenta.
En 808, el nodo de consenso determina si el primer monto es el mismo que el segundo monto y si el primer número aleatorio y el segundo número aleatorio son iguales en base al conjunto de valores. En algunas implementaciones, el primer monto y el segundo monto se determina que son iguales y se determina que el primer número aleatorio y el segundo número aleatorio son iguales, si gahb = CTx, u2av2c = DZ_B1x y u2bv2d = EZ_B2x, donde T = grht es el valor de compromiso del monto de la transferencia de saldo, Z_B1 = u2rv2z1, Z_B2 = u2tv2z2. En algunos ejemplos, z1 y z2 son números aleatorios que se utilizan para cifrar el segundo monto de transacción y el segundo número aleatorio en base al esquema HE probabilístico.
En 810, el nodo de consenso actualiza un saldo de la primera cuenta y un saldo de la segunda cuenta en base al primer monto de la transferencia de saldo, si el primer monto y el segundo monto son iguales, y el primer número
aleatorio y el segundo el número aleatorio son el mismo. En algunas implementaciones, la actualización del saldo de la primera cuenta y de un saldo de la segunda cuenta se realiza en base a HE.
Las implementaciones de la materia objeto descrita en esta memoria descriptiva se pueden implementar para obtener ventajas o efectos técnicos particulares. Por ejemplo, las implementaciones de la presente divulgación permiten que el saldo de cuenta y el monto de transacción de los nodos de la cadena de bloques sean privados durante las transacciones. El destinatario de la transferencia de fondos no necesita confirmar la transacción o utilizar un número aleatorio para verificar un compromiso, la validación de transacción puede ser no interactiva. Un nodo de cadena de bloques puede validar la transacción en base a HE y esquemas de compromiso para permitir una prueba de conocimiento cero.
La metodología descrita permite mejorar la seguridad de cuenta/datos de diversos dispositivos informáticos móviles. El saldo de las cuentas y los montos de transacción se pueden cifrar en base a HE y ocultar mediante esquemas de compromiso. Como tal, un nodo de consenso puede actualizar los saldos de cuenta en el libro de contabilidad después de la transacción en base a las propiedades de HE sin revelar el saldo de cuenta real de la cuenta. Debido a que no es necesario enviar el número aleatorio a un destinatario para confirmar la transacción, se puede reducir el riesgo de fuga de datos y se necesitan menos recursos de cálculo y de memoria para gestionar el número aleatorio.
Las implementaciones y las operaciones descritas en esta memoria descriptiva se pueden implementar en circuitería electrónica digital, o en software, firmware o hardware de computadora, incluidas las estructuras descritas en esta memoria descriptiva o en combinaciones de una o más de ellas. Las operaciones pueden implementarse como operaciones realizadas por un aparato de procesamiento de datos sobre datos almacenados en uno o más dispositivos de almacenamiento legibles por computadora o recibidos desde otras fuentes. Un aparato de procesamiento de datos, computadora o dispositivo informático puede incluir aparatos, dispositivos y máquinas para procesar datos, incluyendo, a modo de ejemplo, un procesador programable, una computadora, un sistema en un chip, o múltiples o combinaciones de los anteriores. El aparato puede incluir circuitería lógica de propósito especial, por ejemplo, una unidad central de procesamiento (CPU), una matriz de puertas programables en campo (FPGA) o un circuito integrado de aplicación específica (ASIC). El aparato también puede incluir código que crea un entorno de ejecución para el programa informático en cuestión, por ejemplo, código que constituye el firmware del procesador, una pila de protocolo, un sistema de gestión de bases de datos, un sistema operativo (por ejemplo, un sistema operativo o una combinación de sistemas), un entorno de ejecución multiplataforma, una máquina virtual o una combinación de uno o más de ellos. El aparato y el entorno de ejecución pueden realizar diversas infraestructuras de modelos informáticos diferentes, tales como servicios web, informática distribuida e infraestructuras informáticas en malla.
Un programa informático (también conocido, por ejemplo, como programa, software, aplicación de software, módulo de software, unidad de software, secuencia de comandos o código) se puede escribir en cualquier forma de lenguaje de programación, incluidos los lenguajes compilados o interpretados, los lenguajes declarativos o procedimentales y se puede implementar en cualquier forma, incluso como un programa autónomo o como un módulo, componente, subrutina, objeto u otra unidad adecuada para su uso en un entorno informático. Un programa se puede almacenar en una porción de un archivo que contiene otros programas o datos (por ejemplo, una o más secuencias de comandos almacenadas en un documento de lenguaje de marcado), en un solo archivo dedicado al programa en cuestión, o en múltiples archivos coordinados (por ejemplo, archivos que almacenan uno o más módulos, subprogramas o porciones de código). Un programa informático se puede ejecutar en una computadora o en múltiples computadoras que están ubicadas en un sitio o distribuidas en múltiples sitios e interconectadas por una red de comunicaciones.
Los procesadores para la ejecución de un programa informático incluyen, a modo de ejemplo, microprocesadores tanto de uso general como especial, y uno o más procesadores de cualquier tipo de computadora digital. Generalmente, un procesador recibirá instrucciones y datos desde una memoria de solo lectura o una memoria de acceso aleatorio o ambas. Los elementos esenciales de una computadora son un procesador para realizar acciones de acuerdo con instrucciones y uno o más dispositivos de memoria para almacenar instrucciones y datos. Por lo general, un ordenador también incluirá, o se acoplará de forma operativa para recibir datos desde o transferir datos a, o ambos, uno o más dispositivos de almacenamiento masivo para almacenar datos. Un ordenador se puede integrar en otro dispositivo, por ejemplo, un dispositivo móvil, un asistente digital personal (PDA), una consola de juegos, un receptor del sistema de posicionamiento global (GPS) o un dispositivo de almacenamiento portátil. Los dispositivos adecuados para almacenar las instrucciones y los datos del programa informático incluyen pero no limitan memorias no volátiles, medios y dispositivos de memoria, incluyendo, a modo de ejemplo, dispositivos de memoria de semiconductores, discos magnéticos y discos magneto-ópticos. El procesador y la memoria se pueden complementar por, o incorporar en, circuitos lógicos de propósito especial.
Los dispositivos móviles pueden incluir teléfonos, equipos de usuario (UE), teléfonos móviles (por ejemplo, teléfonos inteligentes), tabletas, dispositivos para llevar puestos (por ejemplo, relojes inteligentes y gafas inteligentes), dispositivos implantados dentro del cuerpo humano (por ejemplo, biosensores, implantes cocleares), u otros tipos de dispositivos móviles. Los dispositivos móviles se pueden comunicar de forma inalámbrica (por ejemplo, utilizando señales de radiofrecuencia (RF)) con diversas redes de comunicación (descritas a continuación). Los dispositivos móviles pueden incluir sensores para determinar las características del entorno actual del dispositivo móvil. Los sensores pueden incluir cámaras, micrófonos, sensores de proximidad, sensores GPS, sensores de movimiento,
acelerómetros, sensores de luz ambiental, sensores de humedad, giroscopios, brújulas, barómetros, sensores de huellas dactilares, sistemas de reconocimiento facial, sensores de RF (por ejemplo, radios Wi-Fi y celulares), sensores térmicos u otros tipos de sensores. Por ejemplo, las cámaras pueden incluir una cámara orientada hacia delante o hacia atrás con lentes móviles o fijas, un flash, un sensor de imagen y un procesador de imágenes. La cámara puede ser una cámara de megapíxeles que puede capturar detalles para el reconocimiento facial y/o del iris. La cámara, junto con un procesador de datos y la información de autenticación almacenada en la memoria o a la que se accede de forma remota, puede formar un sistema de reconocimiento facial. El sistema de reconocimiento facial o uno o más sensores, por ejemplo, micrófonos, sensores de movimiento, acelerómetros, sensores GPS o sensores RF, se pueden utilizar para la autenticación del usuario.
Para proporcionar interacción con un usuario, las implementaciones se pueden implementar en una computadora que tenga un dispositivo de visualización y un dispositivo de entrada, por ejemplo, una pantalla de cristal líquido (LCD) o una pantalla de diodo orgánico emisor de luz (OLED)/realidad virtual (VR)/realidad aumentada (AR) para visualizar información al usuario y una pantalla táctil, un teclado y un dispositivo señalador mediante el cual el usuario puede proporcionar entrada a la computadora. También se pueden utilizar otros tipos de dispositivos para permitir interacción con un usuario; por ejemplo, la retroalimentación proporcionada al usuario puede ser cualquier forma de retroalimentación sensorial, por ejemplo, retroalimentación visual, retroalimentación auditiva o retroalimentación táctil; y la entrada del usuario se puede recibir de cualquier forma, incluida la entrada acústica, de voz o táctil. Además, una computadora puede interactuar con un usuario enviando documentos a y recibiendo documentos desde un dispositivo que se utiliza por el usuario; por ejemplo, enviando páginas web a un navegador web en el dispositivo cliente de un usuario en respuesta a las solicitudes recibidas desde el navegador web.
Las implementaciones se pueden implementar utilizando dispositivos informáticos interconectados por cualquier forma o medio de comunicación de datos digital cableado o inalámbrico (o una combinación de los mismos), por ejemplo, una red de comunicaciones. Ejemplos de dispositivos interconectados son un cliente y un servidor generalmente remotos entre sí que normalmente interactúan a través de una red de comunicaciones. Un cliente, por ejemplo, un dispositivo móvil, puede realizar transacciones por sí mismo, con un servidor, o a través de un servidor, por ejemplo, realizando transacciones de compra, venta, pago, entrega, envío o préstamo, o autorizando las mismas. Tales transacciones pueden ser en tiempo real, de manera que una acción y una respuesta sean próximas temporalmente; por ejemplo, un individuo percibe que la acción y la respuesta ocurren sustancialmente simultáneamente, la diferencia de tiempo para una respuesta después de la acción del individuo es menos de 1 milisegundo (ms) o menos de 1 segundo (s), o la respuesta es sin retardo intencional considerando limitaciones de procesamiento del sistema.
Los ejemplos de redes de comunicaciones incluyen una red de área local (LAN), una red de acceso por radio (RAN), una red de área metropolitana (MAN) y una red de área amplia (WAN). La red de comunicaciones puede incluir todo o una parte de Internet, otra red de comunicación o una combinación de redes de comunicaciones. La información se puede transmitir en la red de comunicaciones de acuerdo con diversos protocolos y estándares, incluidos evolución a largo plazo (LTE), 5G, IEEE 802, Protocolo de Internet (IP) u otros protocolos o combinaciones de protocolos. La red de comunicaciones puede transmitir datos de voz, de vídeo, biométricos o de autenticación, u otra información entre los dispositivos informáticos conectados.
Las características descritas como implementaciones separadas pueden implementarse, en combinación, en una sola implementación, mientras que las características descritas como una sola implementación pueden implementarse en múltiples implementaciones, por separado o en cualquier subcombinación adecuada. Las operaciones descritas y reivindicadas en un orden particular no deben entenderse como que requieren que el orden particular, ni que todas las operaciones ilustradas deban realizarse (algunas operaciones pueden ser opcionales). Según corresponda, se puede realizar multitarea o procesamiento en paralelo (o una combinación de multitarea y procesamiento en paralelo).
Claims (11)
1. Un método (800) implementado por computadora realizado por un nodo de consenso de una red (102) de cadena de bloques, que comprende:
recibir (802), de una primera cuenta:
una copia firmada digitalmente de lo siguiente:
un valor de compromiso de un monto de transacción asociado con una transferencia de saldo de la primera cuenta a una segunda cuenta generado en base a un primer número aleatorio, además del valor de compromiso, un segundo número aleatorio cifrado utilizando una clave pública de la primera cuenta,
un tercer número aleatorio cifrado utilizando una clave pública de la segunda cuenta,
una o más pruebas de rango, y
un conjunto de valores generados en base a uno o más números aleatorios seleccionados;
verificar (804) una firma digital correspondiente a la copia firmada digitalmente utilizando una clave pública de la primera cuenta correspondiente a una clave privada utilizada para generar la firma digital;
determinar (806) que una o más pruebas de rango prueban que el monto de transacción es mayor que cero y menor o igual que un saldo de la primera cuenta;
determinar (808) si el primer número aleatorio, el segundo número aleatorio y el tercer número aleatorio son iguales en base al conjunto de valores; y
en respuesta a determinar que el primer número aleatorio, el segundo número aleatorio y el tercer número aleatorio son iguales, actualizar (810) el saldo de la primera cuenta y un saldo de la segunda cuenta en base al monto de la transferencia de saldo; en donde
el segundo número aleatorio y el tercer número aleatorio se cifran en base a un esquema de cifrado homomórfico, HE, determinista que tiene propiedades lineales de HE(a b) = HE(a) * HE(b) y HE(ab) = HE(b)a, donde a y b son texto plano utilizado para HE.
2. El método (800) implementado por computadora de la reivindicación 1, en donde el valor de compromiso se genera utilizando un esquema de compromiso que es homomórfico.
3. El método (800) implementado por computadora de la reivindicación 2, en donde el esquema de compromiso es un esquema de compromiso de Pedersen.
4. El método (800) implementado por computadora de una cualquiera de las reivindicaciones 1 a 3, en donde los números aleatorios seleccionados están representados por r1 y t1, y los números aleatorios seleccionados se utilizan para generar r2 y t2, donde r2 = r1 xr, t2 = ti xt, donde r1 y ti representan uno o más números aleatorios seleccionados, r es el primer número aleatorio, t es el monto de la transferencia de saldo, x es un valor de resumen.
5. El método (800) implementado por computadora de la reivindicación 4, en donde el conjunto de valores se genera adicionalmente en base a T1, T1 ’ y T1 ’’, donde T1 = grIht1, T1 ’ = HE_A(r1), T1’’ = HE_B(r1), donde g y h son generadores de una curva elíptica, y en donde HE_A(r1) ser genera en base a HE de r1 utilizando la clave pública de la primera cuenta y HE_B(r1) se genera en base a HE de r1 utilizando la clave pública de la segunda cuenta, y en donde x se genera en base resumir T1, T1 ’ y T1’’.
6. El método (800) implementado por computadora de la reivindicación 5, en donde el primer número aleatorio, el segundo número aleatorio y el tercer número aleatorio se determina que son iguales en base a las propiedades de HE determinista.
7. El método (800) implementado por computadora de la reivindicación 5, en donde se determina que el primer número aleatorio, el segundo número aleatorio y el tercer número aleatorio son iguales si gr2ht2 = TxT1, HE_A(r2) = T’x T1’ y HE_B(r2) = T’’x T1 ’’, donde T = grht, T’ = HE_A(r) y T’’ = HE_B(r), y donde HE_A(r) y HE_A(r2) se generan en base a HE de r y r2, respectivamente, utilizando la clave pública de la primera cuenta, HE_B(r) y HE B(r2) se generan en base a HE de r y r2 utilizando el clave pública de la segunda cuenta.
8. El método (800) implementado por computadora de la reivindicación 7, en donde T, T’ y T’’ forman un texto cifrado del monto t de transacción.
9. El método (800) implementado por computadora de la reivindicación 1, en donde la actualización del saldo de la primera cuenta y del saldo de la segunda cuenta se realiza en base a cifrado homomórfico.
10. Un medio de almacenamiento legible por computadora no transitorio acoplado a uno o más procesadores y que tiene instrucciones almacenadas en los mismos que, cuando se ejecutan por el uno o más procesadores, hacen que el uno o más procesadores realicen operaciones de acuerdo con el método (800) de una o más de las reivindicaciones 1-9.
11. Un sistema que comprende:
un dispositivo informático; y
un dispositivo de almacenamiento legible por computadora acoplado al dispositivo informático y que tiene instrucciones almacenadas en el mismo que, cuando se ejecutan por el dispositivo informático, hacen que el dispositivo informático realice operaciones de acuerdo con el método (800) de una o más de las reivindicaciones 1-9.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2018/114421 WO2019072269A2 (en) | 2018-11-07 | 2018-11-07 | PROTECTION OF BLOCK CHAIN DATA USING A HOMOMORPHIC ENCRYPTION |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2876926T3 true ES2876926T3 (es) | 2021-11-15 |
Family
ID=66100026
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES18867272T Active ES2876926T3 (es) | 2018-11-07 | 2018-11-07 | Protección de datos de cadena de bloques utilizando cifrado homomórfico |
Country Status (16)
Country | Link |
---|---|
US (1) | US10615960B2 (es) |
EP (1) | EP3545640B1 (es) |
JP (1) | JP6767580B2 (es) |
KR (1) | KR102348768B1 (es) |
CN (1) | CN110546667B (es) |
AU (1) | AU2018348319B2 (es) |
BR (1) | BR112019008151A2 (es) |
CA (1) | CA3041161C (es) |
ES (1) | ES2876926T3 (es) |
MX (1) | MX2019004662A (es) |
PH (1) | PH12019500877A1 (es) |
PL (1) | PL3545640T3 (es) |
RU (1) | RU2708344C1 (es) |
SG (1) | SG11201903552PA (es) |
TW (1) | TWI718585B (es) |
WO (1) | WO2019072269A2 (es) |
Families Citing this family (45)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10644876B2 (en) * | 2017-01-20 | 2020-05-05 | Enveil, Inc. | Secure analytics using homomorphic encryption |
US11196541B2 (en) | 2017-01-20 | 2021-12-07 | Enveil, Inc. | Secure machine learning analytics using homomorphic encryption |
US10873568B2 (en) | 2017-01-20 | 2020-12-22 | Enveil, Inc. | Secure analytics using homomorphic and injective format-preserving encryption and an encrypted analytics matrix |
US11777729B2 (en) | 2017-01-20 | 2023-10-03 | Enveil, Inc. | Secure analytics using term generation and homomorphic encryption |
US10693627B2 (en) | 2017-01-20 | 2020-06-23 | Enveil, Inc. | Systems and methods for efficient fixed-base multi-precision exponentiation |
US11507683B2 (en) | 2017-01-20 | 2022-11-22 | Enveil, Inc. | Query processing with adaptive risk decisioning |
WO2019216949A1 (en) * | 2018-05-08 | 2019-11-14 | Visa International Service Association | Sybil-resistant identity generation |
CN109359971B (zh) | 2018-08-06 | 2020-05-05 | 阿里巴巴集团控股有限公司 | 区块链交易方法及装置、电子设备 |
CN109359974B (zh) * | 2018-08-30 | 2020-10-30 | 创新先进技术有限公司 | 区块链交易方法及装置、电子设备 |
US10902133B2 (en) | 2018-10-25 | 2021-01-26 | Enveil, Inc. | Computational operations in enclave computing environments |
US10817262B2 (en) | 2018-11-08 | 2020-10-27 | Enveil, Inc. | Reduced and pipelined hardware architecture for Montgomery Modular Multiplication |
MX2019008738A (es) | 2018-12-21 | 2019-09-09 | Alibaba Group Holding Ltd | Proteccion de datos de cadenas de bloques basada en modelo de cuenta generica y cifrado homomorfico. |
CA3044907C (en) | 2018-12-29 | 2022-05-03 | Alibaba Group Holding Limited | Blockchain-based system and method for concealing sender and receiver identities |
DE102019002732A1 (de) * | 2019-04-15 | 2020-10-15 | Giesecke+Devrient Gesellschaft mit beschränkter Haftung | Verfahren zum direkten Übertragen von elektronischen Münzdatensätzen zwischen Endgeräten sowie Bezahlsystem |
US11444776B2 (en) * | 2019-05-01 | 2022-09-13 | Kelce S. Wilson | Blockchain with daisy chained records, document corral, quarantine, message timestamping, and self-addressing |
CN110675255B (zh) * | 2019-08-30 | 2021-04-02 | 创新先进技术有限公司 | 在区块链中并发执行交易的方法和装置 |
EP3861676A1 (en) * | 2019-10-21 | 2021-08-11 | Google LLC | Verifiable consent for privacy protection |
CN110766400B (zh) * | 2019-10-22 | 2023-01-13 | 全链通有限公司 | 基于区块链的交易记录处理方法、记账节点及介质 |
CN111078787B (zh) * | 2019-11-11 | 2023-07-21 | 重庆邮电大学 | 一种基于随机数映射的区块链共识方法 |
CN111104968B (zh) * | 2019-12-02 | 2023-04-18 | 北京理工大学 | 一种基于区块链的安全svm训练方法 |
CN113055177B (zh) * | 2019-12-27 | 2022-08-16 | 深圳市迅雷网络技术有限公司 | 区块链系统及数值信息传输方法、系统、装置、介质 |
CN113128999B (zh) * | 2019-12-31 | 2024-04-12 | 航天信息股份有限公司 | 一种区块链隐私保护方法及装置 |
CN113065951A (zh) * | 2020-01-02 | 2021-07-02 | 苏州同济区块链研究院有限公司 | 基于区块链的交易方法、系统、装置、设备及介质 |
US12099997B1 (en) | 2020-01-31 | 2024-09-24 | Steven Mark Hoffberg | Tokenized fungible liabilities |
SG11202012924WA (en) | 2020-02-03 | 2021-01-28 | Alipay Hangzhou Inf Tech Co Ltd | Blockchain-based trustable guarantees |
SG11202013137TA (en) | 2020-02-03 | 2021-01-28 | Alipay Hangzhou Inf Tech Co Ltd | Blockchain-based trustable guarantees |
WO2020098838A2 (en) | 2020-02-03 | 2020-05-22 | Alipay (Hangzhou) Information Technology Co., Ltd. | Blockchain-based trustable gurantees |
SG11202012925RA (en) | 2020-02-03 | 2021-01-28 | Alipay Hangzhou Inf Tech Co Ltd | Blockchain-based trustable guarantees |
CN113826134B (zh) | 2020-02-03 | 2024-05-28 | 支付宝(杭州)信息技术有限公司 | 基于区块链的可信保函 |
WO2020098833A2 (en) | 2020-02-03 | 2020-05-22 | Alipay (Hangzhou) Information Technology Co., Ltd. | Blockchain-based trustable gurantees |
DE102020104906A1 (de) * | 2020-02-25 | 2021-08-26 | Giesecke+Devrient Gesellschaft mit beschränkter Haftung | Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit |
CN111523891B (zh) * | 2020-04-23 | 2023-11-24 | 腾讯科技(深圳)有限公司 | 基于区块链的信息加密方法、装置、设备及存储介质 |
EP3844654B1 (en) | 2020-06-08 | 2023-05-17 | Alipay Labs (Singapore) Pte. Ltd. | Blockchain-based document registration for custom clearance |
CN111936995A (zh) | 2020-06-08 | 2020-11-13 | 支付宝实验室(新加坡)有限公司 | 海关清关数据的分布式存储 |
SG11202102366SA (en) | 2020-06-08 | 2021-04-29 | Alipay Labs Singapore Pte Ltd | User management of blockchain-based custom clearance service platform |
CN111989663B (zh) | 2020-06-08 | 2024-07-16 | 支付宝实验室(新加坡)有限公司 | 基于区块链的智能合约池 |
EP3844699A4 (en) | 2020-06-08 | 2021-08-18 | Alipay Labs (Singapore) Pte. Ltd. | BLOCKCHAIN-BASED PROCESSING OF IMPORT CLEARANCE DATA |
WO2020169126A2 (en) | 2020-06-08 | 2020-08-27 | Alipay Labs (singapore) Pte. Ltd. | Managing user authorizations for blockchain-based custom clearance services |
US20220083683A1 (en) * | 2020-09-11 | 2022-03-17 | Transparent Financial Systems, Inc. | Distributed self-governing computer network to correlate blockchain and private computer system transactions method, apparatus, and system |
US11601258B2 (en) | 2020-10-08 | 2023-03-07 | Enveil, Inc. | Selector derived encryption systems and methods |
US11588617B2 (en) * | 2020-11-01 | 2023-02-21 | The Toronto-Dominion Bank | Validating confidential data using homomorphic computations |
CN113159762B (zh) * | 2021-01-28 | 2024-04-09 | 武汉天喻信息产业股份有限公司 | 基于Paillier和博弈论的区块链交易方法 |
CN112769542B (zh) * | 2021-04-12 | 2021-06-11 | 富算科技(上海)有限公司 | 基于椭圆曲线的乘法三元组生成方法、装置、设备及介质 |
CN113821789B (zh) * | 2021-09-26 | 2023-06-23 | 北京邮电大学 | 基于区块链的用户密钥生成方法、装置、设备及介质 |
CN114092242A (zh) * | 2021-11-03 | 2022-02-25 | 支付宝(杭州)信息技术有限公司 | 基于范围证明实现隐私交易的方法和系统 |
Family Cites Families (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8744077B2 (en) * | 2008-10-28 | 2014-06-03 | International Business Machines Corporation | Cryptographic encoding and decoding of secret data |
EP2495908A4 (en) * | 2009-10-29 | 2017-07-19 | Mitsubishi Electric Corporation | Data processing device |
US8630422B2 (en) * | 2009-11-10 | 2014-01-14 | International Business Machines Corporation | Fully homomorphic encryption method based on a bootstrappable encryption scheme, computer program and apparatus |
US8861716B2 (en) * | 2010-03-30 | 2014-10-14 | International Business Machines Corporation | Efficient homomorphic encryption scheme for bilinear forms |
US8731199B2 (en) * | 2012-09-28 | 2014-05-20 | Sap Ag | Zero knowledge proofs for arbitrary predicates over data |
FR3001848B1 (fr) * | 2013-02-01 | 2015-01-09 | Morpho | Procede de chiffrement homomorphe pour le ou exclusif et calcul securise d'une distance de hamming |
US10083310B1 (en) * | 2013-03-13 | 2018-09-25 | Hrl Laboratories, Llc | System and method for mobile proactive secure multi-party computation (MPMPC) using commitments |
JP2017527192A (ja) * | 2014-09-30 | 2017-09-14 | 株式会社東芝 | 1つまたは複数の計量デバイスから2つ以上の第3者へデータを配布する準同形ベースの方法 |
US20160162897A1 (en) * | 2014-12-03 | 2016-06-09 | The Filing Cabinet, LLC | System and method for user authentication using crypto-currency transactions as access tokens |
US9875370B2 (en) * | 2015-03-26 | 2018-01-23 | Microsoft Technology Licensing, Llc | Database server and client for query processing on encrypted data |
US11062303B2 (en) * | 2015-06-08 | 2021-07-13 | Blockstream Corporation | Cryptographically concealing amounts transacted on a ledger while preserving a network's ability to verify the transaction |
US10713731B2 (en) * | 2016-07-22 | 2020-07-14 | Nec Corporation | Method for secure ledger distribution and computer system using secure distributed ledger technology |
CN106548330B (zh) * | 2016-10-27 | 2018-03-16 | 上海亿账通区块链科技有限公司 | 基于区块链的交易验证方法及系统 |
CN106571905B (zh) * | 2016-11-02 | 2019-05-17 | 南京邮电大学 | 一种数值型数据同态保序加密方法 |
WO2018087836A1 (ja) * | 2016-11-09 | 2018-05-17 | 株式会社日立製作所 | ブロックチェーン取引システムおよびブロックチェーン取引方法 |
CN106549749B (zh) * | 2016-12-06 | 2019-12-24 | 杭州趣链科技有限公司 | 一种基于加法同态加密的区块链隐私保护方法 |
WO2018115567A1 (en) * | 2016-12-19 | 2018-06-28 | Nokia Technologies Oy | Method and apparatus for private data transfer between parties |
CN106845960B (zh) * | 2017-01-24 | 2018-03-20 | 上海壹账通区块链科技有限公司 | 基于区块链的安全交易方法及系统 |
US10277395B2 (en) * | 2017-05-19 | 2019-04-30 | International Business Machines Corporation | Cryptographic key-generation with application to data deduplication |
CN107294698B (zh) * | 2017-07-25 | 2019-11-26 | 西安电子科技大学 | 单密文同态计算的全同态加密方法 |
CN108021821A (zh) * | 2017-11-28 | 2018-05-11 | 北京航空航天大学 | 多中心区块链交易隐私保护系统及方法 |
CN108764874B (zh) * | 2018-05-17 | 2021-09-07 | 深圳前海微众银行股份有限公司 | 基于区块链的匿名转账方法、系统及存储介质 |
CN109584055B (zh) * | 2018-09-20 | 2020-07-03 | 阿里巴巴集团控股有限公司 | 基于区块链的交易方法、装置和汇出方设备 |
EP3542336B1 (en) * | 2018-11-07 | 2021-01-27 | Advanced New Technologies Co., Ltd. | Blockchain data protection based on account note model with zero-knowledge proof |
CN110073633B (zh) * | 2018-11-07 | 2023-03-31 | 创新先进技术有限公司 | 使用同态加密的区块链数据保护 |
WO2019072265A2 (en) * | 2018-11-07 | 2019-04-18 | Alibaba Group Holding Limited | BLOCK CHAIN SYSTEM SUPPORTING PUBLIC AND PRIVATE TRANSACTIONS WITH ACCOUNT MODELS |
-
2018
- 2018-11-07 SG SG11201903552PA patent/SG11201903552PA/en unknown
- 2018-11-07 PL PL18867272T patent/PL3545640T3/pl unknown
- 2018-11-07 CN CN201880004283.3A patent/CN110546667B/zh active Active
- 2018-11-07 CA CA3041161A patent/CA3041161C/en active Active
- 2018-11-07 AU AU2018348319A patent/AU2018348319B2/en active Active
- 2018-11-07 JP JP2019521714A patent/JP6767580B2/ja active Active
- 2018-11-07 EP EP18867272.9A patent/EP3545640B1/en active Active
- 2018-11-07 RU RU2019111912A patent/RU2708344C1/ru active
- 2018-11-07 BR BR112019008151A patent/BR112019008151A2/pt not_active IP Right Cessation
- 2018-11-07 KR KR1020197011580A patent/KR102348768B1/ko active IP Right Grant
- 2018-11-07 ES ES18867272T patent/ES2876926T3/es active Active
- 2018-11-07 WO PCT/CN2018/114421 patent/WO2019072269A2/en unknown
- 2018-11-07 MX MX2019004662A patent/MX2019004662A/es unknown
-
2019
- 2019-04-22 PH PH12019500877A patent/PH12019500877A1/en unknown
- 2019-04-22 US US16/390,626 patent/US10615960B2/en active Active
- 2019-07-15 TW TW108124843A patent/TWI718585B/zh active
Also Published As
Publication number | Publication date |
---|---|
CN110546667A (zh) | 2019-12-06 |
SG11201903552PA (en) | 2019-05-30 |
CA3041161C (en) | 2021-10-12 |
TWI718585B (zh) | 2021-02-11 |
BR112019008151A2 (pt) | 2019-09-10 |
AU2018348319B2 (en) | 2020-10-01 |
KR102348768B1 (ko) | 2022-01-06 |
US20190253235A1 (en) | 2019-08-15 |
MX2019004662A (es) | 2019-08-21 |
CN110546667B (zh) | 2023-08-18 |
PH12019500877A1 (en) | 2019-12-02 |
EP3545640A4 (en) | 2020-01-08 |
JP2019537348A (ja) | 2019-12-19 |
RU2708344C1 (ru) | 2019-12-05 |
TW202019123A (zh) | 2020-05-16 |
EP3545640A2 (en) | 2019-10-02 |
JP6767580B2 (ja) | 2020-10-14 |
KR20200054129A (ko) | 2020-05-19 |
AU2018348319A1 (en) | 2020-05-21 |
US10615960B2 (en) | 2020-04-07 |
PL3545640T3 (pl) | 2021-10-18 |
WO2019072269A3 (en) | 2019-09-12 |
CA3041161A1 (en) | 2019-04-18 |
EP3545640B1 (en) | 2021-04-07 |
WO2019072269A2 (en) | 2019-04-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2876926T3 (es) | Protección de datos de cadena de bloques utilizando cifrado homomórfico | |
ES2881319T3 (es) | Protección de datos de cadena de bloques mediante cifrado homomórfico | |
ES2880458T3 (es) | Protección de datos de cadena de bloques basada en un modelo de cuenta genérico y un cifrado homomórfico | |
ES2863559T3 (es) | Protección de datos de cadena de bloques en base al modelo de billete de cuenta con prueba de conocimiento cero | |
CN111602161B (zh) | 基于通用账户模型和同态加密的区块链数据保护 |