ES2818623T3 - Gestión de comunicaciones entre nodos de consenso y nodos cliente - Google Patents

Gestión de comunicaciones entre nodos de consenso y nodos cliente Download PDF

Info

Publication number
ES2818623T3
ES2818623T3 ES18866296T ES18866296T ES2818623T3 ES 2818623 T3 ES2818623 T3 ES 2818623T3 ES 18866296 T ES18866296 T ES 18866296T ES 18866296 T ES18866296 T ES 18866296T ES 2818623 T3 ES2818623 T3 ES 2818623T3
Authority
ES
Spain
Prior art keywords
public key
node
consensus node
consensus
nodes
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES18866296T
Other languages
English (en)
Inventor
Dong Pan
Xuebing Yan
Shenglong Chen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced New Technologies Co Ltd
Original Assignee
Advanced New Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Advanced New Technologies Co Ltd filed Critical Advanced New Technologies Co Ltd
Application granted granted Critical
Publication of ES2818623T3 publication Critical patent/ES2818623T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • 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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • 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/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • 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/083—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) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • 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
    • 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/321—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 a third party or a trusted authority
    • 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/40—Network security protocols
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Prostheses (AREA)

Abstract

Un método implementado por ordenador para aislar, por un lado, las comunicaciones entre un nodo de consenso (302a) y otro nodo de consenso (302a) y, por otro lado, las comunicaciones entre el nodo de consenso (302a) y un nodo cliente (302b), que comprende: generar (502), por el nodo de consenso (302a), una solicitud de firma de certificado, es decir, una CSR; enviar (504) la CSR a una primera autoridad certificadora, es decir, una CA (304a); recibir (506) a) un primer certificado de clave pública del nodo de consenso de la primera CA en respuesta a la CSR, y b) un primer certificado de clave pública del otro nodo de consenso, en donde el primer certificado de clave pública del otro nodo de consenso es emitido por la primera CA (304a); enviar (508) la CSR a una segunda CA (304b); recibir (510) a) un segundo certificado de clave pública del nodo de consenso de la segunda CA (304b) en respuesta a la CSR, y b) un segundo certificado de clave pública del nodo cliente, en donde el segundo certificado de clave pública del nodo cliente es emitido por la segunda CA (304b); configurar (512), en el nodo de consenso (302a), un primer almacén de confianza que incluye el primer certificado de clave pública del nodo de consenso y el primer certificado de clave pública del otro nodo de consenso, en donde el nodo de consenso está configurado para usar los primeros certificados de clave pública para comunicarse con el otro nodo de consenso y; configurar (512), en el nodo de consenso, un segundo almacén de confianza que incluye el segundo certificado de clave pública del nodo de consenso y el segundo certificado de clave pública del nodo cliente, en donde el nodo de consenso está configurado para usar los segundos certificados de clave pública para comunicarse con el nodo cliente.

Description

DESCRIPCIÓN
Gestión de comunicaciones entre nodos de consenso y nodos cliente
Antecedentes
Las redes de cadena de bloques, que también pueden denominarse sistemas de cadena de bloques, redes de consenso, redes de sistemas de contabilidad distribuida (DLS) o cadena de bloques, permiten que las entidades participantes almacenen datos de manera segura e inalterable. Una cadena de bloques se puede describir como un libro mayor de contabilidad de transacciones y múltiples copias de la cadena de bloques se almacenan en la red de cadena de bloques. Los tipos ilustrativos de cadena de bloques pueden incluir cadena de bloques públicas, cadena de bloques de consorcio y cadena 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 de consorcio es una cadena de bloques donde el proceso de consenso está controlado por un conjunto de nodos preseleccionados. Se proporciona una cadena de bloques privada para una entidad en particular que controla de manera centralizada los permisos de lectura y escritura.
El sistema de cadena de bloques de consorcio puede incluir nodos de consenso y nodos cliente (o usuarios) que usan la red del consorcio. Por un lado, los nodos de consenso se comunican con otros nodos de consenso para llegar a un consenso. Por otro lado, los nodos de consenso se comunican con los nodos cliente para aceptar y agregar nuevas transacciones a los bloques. En algunos casos, los nodos de consenso también se comunican con redes de nodos preseleccionados de un sistema de consorcio u otros sistemas centrales con diferentes niveles de seguridad. Como tal, se pueden establecer límites para diferentes tipos de comunicaciones para proteger la privacidad y seguridad de los datos.
El documento CN107592293 describe un método para la comunicación entre nodos en una cadena de bloques. El documento CN107592292 describe una red de cadena de bloques de consorcio que usa listas de confianza de la Autoridad de Certificación de acuerdo con las cuales los nodos pueden autenticarse entre sí de acuerdo con sus respectivos certificados.
Resumen
La invención se define en las reivindicaciones adjuntas. Las implementaciones de la presente descripción están dirigidas a gestionar las comunicaciones entre nodos de consenso y las comunicaciones entre los nodos de consenso y los nodos cliente. Más particularmente, las implementaciones de la presente descripción están dirigidas a configurar certificados raíz emitidos por las respectivas autoridades certificadoras (CA) para comunicaciones entre nodos de consenso y entre los nodos de consenso y los nodos cliente, de manera que los nodos cliente no puedan acceder a los mensajes de consenso comunicados entre los nodos de consenso.
En algunas implementaciones, las acciones incluyen generar, mediante un nodo de consenso, una solicitud de firma de certificado (CSR); enviar la CSR a una primera autoridad certificadora (CA); recibir un primer certificado de clave pública del nodo de consenso de la primera CA en respuesta a la CSR, y un primer certificado de clave pública de uno o más nodos de consenso distintos emitidos por una primera o más CA; enviar la CSR a una segunda CA; recibir un segundo certificado de clave pública del nodo de consenso de la segunda CA en respuesta a la CSR, y un segundo o más certificados de clave pública de uno o más nodos cliente emitidos por una segunda o más CA; y configurar, en el nodo de consenso, un primer almacén de confianza que incluye el primer certificado de clave pública y el primero o más certificados de clave pública del uno o más nodos de consenso distintos, y un segundo almacén de confianza que incluye el segundo certificado de clave pública y el segundo o más certificados de clave pública del uno o más nodos cliente. 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: determinar la primera o más CA y la segunda o más CA; recibir certificados raíz de la primera o más CA y la segunda o más CA; y verificar los certificados raíz con base en las claves públicas correspondientes de la primera o más CA y la segunda o más CA; en donde la CSR incluye la clave pública y la información que se incluirá en el primer certificado de clave pública o el segundo certificado de clave pública; en donde la CSR está firmado digitalmente por el nodo de consenso mediante el uso de una clave privada; en donde al menos una de una porción del primero o más certificados de clave pública está autofirmada por los nodos de consenso correspondientes, o una porción del segundo o más certificados de clave pública está autofirmada por los nodos cliente correspondientes; generar un certificado autofirmado de la clave pública mediante el uso de una clave privada correspondiente del nodo de consenso; y configurar, en el nodo de consenso, la clave privada del nodo de consenso y el certificado autofirmado; en donde el primer certificado de clave pública, el primero o más certificados de clave pública, el segundo certificado de clave pública y el segundo o más certificados de clave pública son certificados de seguridad de la capa de transporte (TLS).
La presente descripción también proporciona uno o más medios de almacenamiento legibles por ordenador no transitorios acoplados a uno o más procesadores y que tienen instrucciones almacenadas en ellos, las cuales, cuando son ejecutadas 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 la presente descripción.
La presente descripción proporciona, además, un sistema para implementar los métodos proporcionados en la presente descripción. El sistema incluye uno o más procesadores, y un medio de almacenamiento legible por ordenador acoplado al uno o más procesadores que tiene instrucciones almacenadas en él, las cuales, cuando son ejecutadas 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 la presente descripción.
Se aprecia que los métodos de acuerdo con la presente descripción pueden incluir cualquier combinación de los aspectos y características descritos en la presente descripción. Es decir, los métodos de acuerdo con la presente descripción no se limitan a las combinaciones de aspectos y características descritas específicamente en la presente descripción, 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 descripción se establecen en los dibujos adjuntos y la descripción más abajo. Otras características y ventajas de la presente descripción resultarán evidentes a partir de la descripción y los dibujos, y de las reivindicaciones.
Descripción de los dibujos
La Figura 1 representa un entorno ilustrativo que se puede usar para ejecutar implementaciones de la presente descripción.
La Figura 2 representa un ejemplo de arquitectura conceptual de acuerdo con implementaciones de la presente descripción.
La Figura 3A representa un proceso ilustrativo de configuración de comunicaciones entre nodos de consenso de acuerdo con implementaciones de la presente descripción.
La Figura 3B representa un proceso ilustrativo de configuración de comunicaciones entre nodos de consenso y nodos cliente de acuerdo con implementaciones de la presente descripción.
La Figura 4 representa configuraciones ilustrativas para comunicaciones entre nodos de consenso y nodos cliente de acuerdo con implementaciones de la presente descripción.
La Figura 5 representa un método ilustrativo para gestionar las comunicaciones de nodos de consenso y nodos cliente de acuerdo con implementaciones de la presente descripción.
Los símbolos de referencia similares en los diversos dibujos indican elementos similares.
Descripción detallada
Las implementaciones de la presente descripción están dirigidas a gestionar las comunicaciones entre nodos de consenso y las comunicaciones entre los nodos de consenso y los nodos cliente. Más particularmente, las implementaciones de la presente descripción están dirigidas a configurar certificados raíz emitidos por las respectivas autoridades certificadoras (CA) para comunicaciones entre nodos de consenso y entre los nodos de consenso y los nodos cliente, de manera que los nodos cliente no puedan acceder a los mensajes de consenso comunicados entre los nodos de consenso.
En algunas implementaciones, las acciones incluyen generar, mediante un nodo de consenso, una solicitud de firma de certificado (CSR); enviar la CSR a una primera autoridad certificadora (CA); recibir un primer certificado de clave pública del nodo de consenso de la primera CA en respuesta a la CSR, y un primer certificado de clave pública de uno o más nodos de consenso distintos emitidos por una primera o más CA; enviar la CSR a una segunda CA; recibir un segundo certificado de clave pública del nodo de consenso de la segunda CA en respuesta a la CSR, y un segundo o más certificados de clave pública de uno o más nodos cliente emitidos por una segunda o más CA; y configurar, en el nodo de consenso, un primer almacén de confianza que incluye el primer certificado de clave pública y el primero o más certificados de clave pública del uno o más nodos de consenso distintos, y un segundo almacén de confianza que incluye el segundo certificado de clave pública y el segundo o más certificados de clave pública del uno o más nodos cliente.
Para proporcionar un contexto adicional para las implementaciones de la presente descripción, y como se introdujo anteriormente, redes de cadena de bloques, que también pueden denominarse redes de consenso (por ejemplo, compuestas por nodos de punto a punto), sistema de contabilidad distribuida o simplemente cadena de bloques, permiten que las entidades participantes realicen transacciones de manera segura e inalterable 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 descripción se describen con más detalle en la presente descripción 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 descripción se puedan realizar en cualquier tipo apropiado de cadena de bloques.
En una cadena de bloques de consorcio, el proceso de consenso está controlado por un conjunto autorizado de nodos, uno o más nodos que se operan mediante una entidad respectiva (por ejemplo, una empresa). Por ejemplo, un consorcio de diez (10) entidades (por ejemplo, empresas) puede operar un sistema de cadena de bloques de consorcio, cada una de las cuales opera al menos un nodo en el DLS de consorcio. En consecuencia, el sistema de cadena de bloques de consorcio puede considerarse una red privada con respecto a las entidades participantes. En algunos ejemplos, cada entidad (nodo) debe firmar cada bloque para que el bloque sea válido y se agregue a la cadena de bloques. En algunos ejemplos, al menos un subconjunto de entidades (nodos) (por ejemplo, al menos 7 entidades) debe firmar cada bloque para que el bloque sea válido y se agregue a la cadena de bloques. Un ejemplo de sistema de cadena de bloques de consorcio incluye Quorum, desarrollado por JP Morgan Chase & Co., de Nueva York, Nueva York. Quorum se puede describir como una infraestructura de cadena de bloques autorizada y centrada en las empresas, diseñada específicamente para casos de uso financiero. Quorum se basa en Go Ethereum, el código base para la cadena de bloques Ethereum, que es proporcionado por la Fundación Ethereum de Zug, Suiza. En general, un sistema de cadena de bloques de consorcio admite transacciones entre entidades que participan, con permiso, en el sistema de cadena de bloques de consorcio. Una transacción se comparte con todos los nodos dentro del sistema de cadena de bloques de consorcio, porque la cadena de bloques se replica en todos los nodos. Es decir, todos los nodos están en perfecto estado de consenso con respecto al cadena de bloques. Para lograr un consenso (por ejemplo, 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 cadena de bloques de consorcio. Un ejemplo de protocolo de consenso incluye, sin limitación, prueba de trabajo (POW) implementado en la red Bitcoin.
Las implementaciones de la presente descripción se describen con más detalle en la presente descripción en vista del contexto anterior. Más particularmente, y como se introdujo anteriormente, las implementaciones de la presente descripción están dirigidas a configurar certificados raíz emitidos por las respectivas CA para las comunicaciones entre nodos de consenso y entre los nodos de consenso y los nodos cliente, de manera que los nodos cliente no puedan acceder a los mensajes de consenso comunicados entre los nodos de consenso.
La Figura 1 representa un entorno ilustrativo 100 que puede usarse para ejecutar implementaciones de la presente descripción. En algunos ejemplos, el entorno ilustrativo 100 permite a las entidades participar en una cadena de bloques pública 102. El entorno ilustrativo 100 incluye los sistemas informáticos 106, 108 y una red 110. En algunos ejemplos, la red 110 incluye una red de área local (LAN), una red de área amplia (WAN), Internet o sus combinaciones, y conecta sitios web, dispositivos de usuario (por ejemplo, dispositivos informáticos) y sistemas back-end. En algunos ejemplos, se puede acceder a la red 110 a través de un enlace de comunicaciones por cable y/o inalámbrico.
En el ejemplo representado, los sistemas informáticos 106, 108 pueden incluir, cada uno, cualquier sistema informático apropiado que permita la participación como un nodo en el sistema de cadena de bloques de consorcio 102, para almacenar transacciones en una cadena de bloques 104. Los dispositivos informáticos ilustrativos incluyen, sin limitación, un servidor, un ordenador de escritorio, un ordenador portátil, un dispositivo informático de tableta y un teléfono inteligente. En algunos ejemplos, los sistemas informáticos 106, 108 alojan uno o más servicios implementados por ordenador para interactuar con el sistema de cadena de bloques de consorcio 102. Por ejemplo, el sistema informático 106 puede albergar servicios implementados por ordenador de una primera entidad (por ejemplo, el usuario A), como un sistema de gestión de transacciones que la primera entidad usa para gestionar sus transacciones con una o más entidades distintas (por ejemplo, otros usuarios). El sistema informático 108 puede alojar servicios implementados por ordenador de una segunda entidad (por ejemplo, el usuario B), tal como un sistema de gestión de transacciones que la segunda entidad usa para gestionar sus transacciones con una o más entidades distintas (por ejemplo, otros usuarios). En el ejemplo de la Figura 1, el sistema de cadena de bloques de consorcio 102 se representa como una red de nodos de punto a punto, y los sistemas informáticos 106, 108 proporcionan los nodos de la primera entidad y la segunda entidad, respectivamente, los cuales participan en el sistema de cadena de bloques de consorcio 102.
La Figura 2 representa un ejemplo de arquitectura conceptual 200 de acuerdo con implementaciones de la presente descripción. La arquitectura conceptual ilustrativa 200 incluye una capa 202 de entidad, una capa de servicios alojados 204 y una capa de cadena de bloques 206. En el ejemplo representado, la capa de entidad 202 incluye tres entidades, Entidad_1 (E1), Entidad_2 (E2) y Entidad_3 (E3), cada entidad que tiene un respectivo sistema de gestión de transacciones 208.
En el ejemplo representado, la capa de servicios alojados 204 incluye interfaces de cadena de bloques 210 para cada sistema de gestión de transacciones 208. En algunos ejemplos, un sistema de gestión de transacciones 208 respectivo se comunica con una interfaz de cadena de bloques 210 respectiva a través de una red (por ejemplo, la red 110 de la Figura 1) mediante el uso de un protocolo de comunicación (por ejemplo, protocolo seguro de transferencia de hipertexto (HTTPS)). En algunos ejemplos, cada interfaz de cadena de bloques 210 proporciona una conexión de comunicación entre un sistema de gestión de transacciones 208 respectivo y la capa de cadena de bloques 206. Más particularmente, cada interfaz de cadena de bloques 210 permite a la entidad respectiva realizar transacciones registradas en un sistema de cadena de bloques de consorcio 212 de la capa de cadena de bloques 206. En algunos ejemplos, la comunicación entre una interfaz de cadena de bloques 210 y la capa de cadena de bloques 206 se realiza mediante el uso de llamadas a procedimiento remoto (RPC). En algunos ejemplos, la interfaz de cadena de bloques 210 “aloja” nodos de consenso para los respectivos sistemas de gestión de transacciones 208. Por ejemplo, las interfaces de cadena de bloques 210 proporcionan la interfaz de programación de aplicaciones (API) para acceder al sistema de cadena de bloques de consorcio 212.
Un sistema cadena de bloques puede incluir nodos de consenso y nodos cliente. Los nodos de consenso pueden participar en el proceso de consenso. Los nodos cliente pueden usar el sistema cadena de bloques, pero no participan en el proceso de consenso. En algunas implementaciones, los nodos de consenso pueden participar en el proceso de consenso mientras usan el sistema cadena de bloques para otros fines. En algunas implementaciones, los nodos de consenso pueden comunicarse con los nodos cliente, de manera que los usuarios pueden usar los nodos cliente para enviar transacciones a la cadena de bloques. Los nodos de consenso también pueden comunicarse entre sí para llegar a un consenso con el fin de agregar las transacciones de los nodos cliente a la cadena de bloques.
En algunas implementaciones, las comunicaciones entre nodos de consenso y las comunicaciones entre los nodos de consenso y los nodos cliente se pueden realizar con base en protocolos criptográficos, como el protocolo de seguridad de la capa de transporte (t Ls ), para garantizar la seguridad de las comunicaciones.
Para mejorar la privacidad y administrar los datos a los que pueden acceder diferentes nodos, las comunicaciones entre los nodos de consenso se pueden aislar de las comunicaciones entre los nodos de consenso y los nodos cliente. En algunas implementaciones, el aislamiento se puede realizar mediante la formación de diferentes almacenes de confianza TLS de certificados de clave pública de diferentes nodos. Los certificados de clave pública pueden ser emitidos por las respectivas autoridades certificadoras (CA) para las comunicaciones entre nodos de consenso y las comunicaciones entre los nodos de consenso y los nodos cliente.
La Figura 3A representa un proceso ilustrativo 300a para configurar comunicaciones entre nodos de consenso 302a, de acuerdo con implementaciones de la presente descripción. Los nodos de consenso 302a se pueden implementar mediante el uso de cualquier dispositivo electrónico apropiado, como un ordenador, un teléfono inteligente o un servidor, conectado a la red cadena de bloques.
En 306a, los nodos de consenso 302a identifican una o más CA 304a en las que se puede confiar. En algunas implementaciones, las CA pueden ser entidades que emiten certificados de clave pública. Los certificados de clave pública se pueden usar para certificar la propiedad de claves públicas por parte de los sujetos nombrados del certificado. Los sujetos nombrados pueden ser las propias CA u otras entidades que deseen que se certifiquen sus claves públicas. Las claves públicas de propiedad de y autofirmadas por las CA pueden convertirse en certificados raíz. En algunos casos, al menos una porción de los nodos de consenso 302a se pueden identificar como CA. En tales casos, esos nodos de consenso pueden autofirmar sus claves públicas para generar certificados de clave pública. En algunos casos, los certificados de clave pública generados con base en los protocolos TLS se pueden denominar certificados TLS.
En 308a, las CA 304a preparan sus claves privadas y certificados autofirmados. Los certificados autofirmados pueden ser el certificado raíz de las CA de sus correspondientes claves públicas.
En 310a, las CA 304a envían los certificados autofirmados a los nodos de consenso 302a. En algunas implementaciones, los certificados autofirmados pueden incluir firmas digitales de las CA 304a firmadas mediante el uso de sus correspondientes claves privadas. Como tal, los nodos de consenso 302a pueden verificar que los certificados son emitidos por las CA 304a mediante el uso de las claves públicas de las claves públicas de las CA 304a.
En 312a, los nodos de consenso 302a generan solicitudes de firma de certificado (CSR). Las CSR son bloques de texto codificado que se entregan a las CA 304a cuando solicitan certificados TLS. En algunos ejemplos, las CSR pueden contener información que se incluirá en los certificados TLS, como un nombre de la organización, un nombre común (nombre de dominio), la localidad y el país. Las CSR también pueden contener las claves públicas que se incluirán en los certificados TLS. Los nodos de consenso 302a pueden crear las claves privadas cuando crean las CSR y usar las claves privadas para firmar las CSR correspondientes.
En 314a, los nodos de consenso 302a envían las CSR a las CA 304a. En 316a, las CA 304a generan certificados de clave pública para los nodos de consenso 302a en respuesta a las CSR. Las CA 304a pueden verificar si las firmas digitales correspondientes a las CSR son correctas a partir de los nodos de consenso 302a, antes de generar los certificados de clave pública para los nodos de consenso 302a.
En 318a, las CA 304a envían el certificado de clave pública a los nodos de consenso 302a. Las CA 304a pueden enviar los certificados de clave pública a todos los nodos de consenso 302a en la red cadena de bloques. Como tal, cada nodo de consenso 302a puede tener una copia de los certificados de clave pública de todos los demás nodos de consenso 302a en la red.
En 320a, los nodos de consenso 302a configuran almacenes de confianza, claves privadas y certificados autofirmados. Los almacenes de confianza se pueden usar para almacenar certificados TLS de CA 304a confiables. Al recibir y verificar los certificados TLS de las CA confiables, los nodos de consenso 302a pueden usar las claves públicas certificadas para cifrar mensajes y comunicarse de manera segura con otros nodos de consenso en la red. En algunas implementaciones, los nodos de consenso 302a también pueden generar certificados de clave pública autofirmados mediante el uso de una clave privada correspondiente de los nodos de consenso 302a correspondientes. La clave privada también se puede usar para descifrar mensajes de otros nodos en la red de cadena de bloques cifrados mediante el uso de la clave pública del nodo de consenso 302a correspondiente.
En algunas implementaciones, la red cadena de bloques se puede configurar de manera que las comunicaciones entre nodos de consenso y las comunicaciones entre los nodos de consenso y los nodos cliente estén aisladas. Es decir, los nodos cliente no pueden acceder a los datos comunicados entre los nodos de consenso y los nodos de consenso no pueden acceder a los datos comunicados entre otros nodos de consenso y sus nodos cliente conectados. En algunos ejemplos, los nodos de consenso que realizan el consenso pueden solicitar certificados TLS de un primer conjunto de CA, y los pares de nodo de consenso/nodo cliente que se comunican entre sí pueden solicitar certificados TLS de CA diferentes del primer conjunto de CA, o no lo realizan el cifrado de clave pública de sus datos.
La Figura 3B representa un proceso ilustrativo 300b para configurar comunicaciones entre los nodos de consenso y los nodos cliente 302b de acuerdo con las implementaciones de la presente descripción.
En 306b, los nodos de consenso y los nodos cliente 302b identifican una o más CA 304b diferentes de las CA 304a identificadas en el proceso ilustrativo 300a discutido anteriormente con referencia a la Figura 3A. En algunas implementaciones cada par de nodo de consenso/nodo cliente puede identificar una CA diferente, de manera que sus comunicaciones pueden aislarse de otras. En algunas implementaciones cada nodo cliente y el nodo de consenso con el que se comunica pueden formar una red a pequeña escala e identificar una o más Ca no usadas por otros nodos cliente o los nodos de consenso 302a para el consenso. En algunos casos, al menos una porción de los nodos de consenso y los nodos cliente 302b pueden identificarse a sí mismos como CA. En tales casos, esos nodos de consenso pueden autofirmar sus claves públicas para generar certificados de clave pública, siempre que los certificados no estén autofirmados por los nodos de consenso 302a para las comunicaciones con otros nodos de consenso en el proceso ilustrativo 300a.
En 308b, las CA 304b preparan sus claves privadas y certificados autofirmados. Los certificados autofirmados pueden ser los certificados raíz de las CA de sus correspondientes claves públicas.
En 310b, las CA 304b envían los certificados autofirmados a los nodos de consenso y los nodos cliente 302b. En algunas implementaciones, los certificados autofirmados pueden incluir las firmas digitales de las CA 304b firmadas mediante el uso de sus respectivas claves privadas. Como tal, los nodos de consenso y los nodos cliente 302b pueden verificar que los certificados son emitidos por las CA 304b mediante el uso de las claves públicas de las CA 304b.
En 312b, los nodos de consenso y los nodos cliente 302b generan las CSR. Los nodos de consenso y los nodos cliente 302b pueden crear las claves privadas cuando crean las CSR y usar las claves privadas para firmar las CSR correspondientes.
En 314b, los nodos de consenso y los nodos cliente 302b envían las CSR a las CA 304b. En 316b, las CA 304b generan certificados de clave pública para los nodos de consenso y los nodos cliente 302b en respuesta a las CSR. Las CA 304b pueden verificar si las firmas digitales correspondientes a las CSR son correctas antes de generar los certificados de clave pública para los nodos de consenso.
En 318b, las CA 304b envían el certificado de clave pública a los nodos de consenso y los nodos cliente 302b. En algunas implementaciones, diferentes CA pueden enviar certificados de clave pública a diferentes pares de nodo(s) de consenso/nodo cliente para formar un almacén de confianza de certificados a pequeña escala. Como tal, cada par de nodos cliente puede tener certificados de clave pública del (de los) nodo(s) de consenso emitidos por diferentes CA para garantizar la privacidad de las comunicaciones.
En 320b, los nodos de consenso y los nodos cliente 302b configuran almacenes de confianza, claves privadas y certificados autofirmados. Debido a que diferentes nodos cliente pueden tener diferentes almacenes de confianza de certificados TLS para comunicaciones cifradas, y los nodos de consenso pueden tener su propio almacén de confianza de certificados TLS para comunicaciones cifradas, la privacidad de los datos de las comunicaciones realizadas por las diferentes partes puede protegerse.
La Figura 4 representa un sistema de cadena de bloques ilustrativo 400 y una configuración para las comunicaciones entre los nodos de consenso y los nodos cliente de acuerdo con las implementaciones de la presente descripción. En un nivel alto, el sistema de cadena de bloques ilustrativo 400 incluye cuatro nodos de consenso: nodo 1302, nodo 2 304, nodo 3306 y nodo 4308. Tres nodos cliente, cliente 1310, cliente 2 312 y cliente 3314, están conectados a los nodos de consenso. El cliente 1310 está conectado al nodo 1310 y el nodo 2 312, el cliente 2312 está conectado al nodo 3306 y el cliente 3314 está conectado al nodo 4308. Los nodos de consenso pueden comunicarse con los nodos cliente, de manera que los usuarios pueden enviar transacciones desde los nodos cliente a los nodos de consenso. Los nodos de consenso pueden comunicarse entre sí para ejecutar un proceso de consenso para agregar las transacciones de los nodos cliente a la cadena de bloques.
Para las comunicaciones entre los nodos de consenso, el nodo 1402, el nodo 2404, el nodo 3406 y el nodo 4408 pueden obtener, cada uno, una réplica de la cadena de bloques de un almacén de confianza A. El almacén de confianza A puede incluir certificados TLS del nodo 1402, el nodo 2404, el nodo 3406 y el nodo 4408 emitidos por un primer conjunto de CA. En algunas implementaciones, los nodos de consenso pueden ser las CA para autofirmar sus correspondientes certificados de clave pública. El nodo 1402, el nodo 2404, el nodo 3406 y el nodo 4408 también pueden configurarse con sus respectivas claves privadas y certificados autofirmados. Como tal, las comunicaciones entre el nodo 1402, el nodo 2404, el nodo 3406 y el nodo 4408 pueden basarse en certificados TLS del almacén de confianza A.
El cliente 1410 está conectado para la comunicación con el nodo 1402 y el nodo 2404. El cliente 1410, el nodo 14 02 y el nodo 2404 pueden obtener, cada uno, una réplica de la cadena de bloques de un almacén de confianza B. El almacén de confianza B puede incluir certificados TLS del cliente 1410, el nodo 1402 y el nodo 2404 emitidos por un segundo conjunto de CA. Nuevamente, los certificados TLS pueden autofirmarse siempre que la autoridad que firma sea diferente de la autoridad usada para firmar los certificados TLS para aislarse de otras comunicaciones. El cliente 1410, el nodo 1402 y el nodo 2404 también pueden configurarse con sus respectivas claves privadas y certificados autofirmados. Como tal, las comunicaciones entre el cliente 1410 y el nodo 1402, y entre el cliente 1 410 y el nodo 2404 pueden basarse en certificados TLS del almacén de confianza B.
En algunas implementaciones, aunque el nodo 1402 y el nodo 2404 mantienen tanto el almacén de confianza A como el almacén de confianza B, solo pueden comunicarse entre sí con base en los certificados TLS del almacén de confianza A. Ellos no pueden comunicarse con base en los certificados TLS del almacén de confianza B. En consecuencia, el cliente 1410 no puede ver los mensajes de consenso comunicados entre el nodo 1402 y el nodo 2 404.
El cliente 2412 está conectado para la comunicación con el nodo 3406. El cliente 2412 y el nodo 3406 pueden obtener, cada uno, una réplica de la cadena de bloques de un almacén de confianza C. El almacén de confianza C puede incluir certificados TLS del cliente 2412 y el nodo 3406 emitidos por un tercer conjunto de CA. El cliente 2 412 y el nodo 3406 también pueden configurarse con sus respectivas claves privadas y certificados autofirmados. Como tal, las comunicaciones entre el cliente 2412 y el nodo 3406 pueden basarse en certificados TLS del almacén de confianza C.
El cliente 3414 está conectado con el nodo 4408. Las comunicaciones entre el cliente 3414 y el nodo 4408 no están cifradas. Como tal, el cliente 3 414 no necesita mantener certificados de clave pública para las comunicaciones. Sin embargo, el cliente 3414 puede asumir el riesgo de robo de identidad, como otros nodos que pretenden ser el cliente 3414 para comunicarse con el nodo 4408.
La Figura 5 representa un proceso ilustrativo 500 para gestionar las comunicaciones del nodo de consenso y el nodo cliente de acuerdo con implementaciones de la presente descripción. Para claridad de presentación, la descripción que sigue generalmente describe el proceso ilustrativo 500 en el contexto de las otras figuras en esta descripción. Sin embargo, se entenderá que el proceso ilustrativo 500 se puede llevar a cabo, por ejemplo, por cualquier sistema, entorno, software y hardware, o una combinación de sistemas, entornos, software y hardware, según sea apropiado. En algunas implementaciones, varias etapas del proceso ilustrativo 500 se pueden ejecutar en paralelo, en combinación, en bucles o en cualquier orden.
En 502, un nodo de consenso genera una CSR. En algunas implementaciones, antes de generar la CSR, el nodo de consenso puede identificar una primera o más CA, y una segunda o más CA. El nodo de consenso también puede recibir certificados raíz de la primera o más CA, y la segunda o más CA, y verificar los certificados raíz con base en las respectivas claves públicas de la primera o más CA y la segunda o más CA. En algunas implementaciones, la CSR incluye la clave pública y la información que se incluirá en el primer certificado de clave pública o el segundo certificado de clave pública. En algunas implementaciones, la CSR está firmada digitalmente por el nodo de consenso mediante el uso de una clave privada.
En 504, el nodo de consenso envía la CSR a una primera CA.
En 506, el nodo de consenso recibe un primer certificado de clave pública del nodo de consenso de la primera CA en respuesta a la CSR, y un primer o más certificados de clave pública de uno o más nodos de consenso distintos emitidos por la primera o más CA. En algunas implementaciones, al menos una de una porción del primero o más certificados de clave pública está autofirmada por los nodos de consenso correspondientes, o una porción del segundo o más certificados de clave pública está autofirmada por los nodos cliente correspondientes.
En 508, el nodo de consenso envía la CSR a una segunda CA. En algunas implementaciones, al menos una de una porción del primero o más certificados de clave pública está autofirmada por los nodos de consenso correspondientes, o una porción del segundo o más certificados de clave pública está autofirmada por los nodos cliente correspondientes.
En 510, el nodo de consenso recibe un segundo certificado de clave pública del nodo de consenso de la segunda CA en respuesta a la CSR, y un segundo o más certificados de clave pública de uno o más nodos cliente emitido por una segunda o más CA.
En 512, el nodo de consenso configura un primer almacén de confianza y un segundo almacén de confianza. El primer almacén de confianza incluye el primer certificado de clave pública y el primero o más certificados de clave pública del uno o más nodos de consenso distintos. El segundo almacén de confianza incluye el segundo certificado de clave pública y el segundo o más certificados de clave pública del uno o más nodos cliente.
En algunas implementaciones, el nodo de consenso puede generar un certificado autofirmado de la clave pública mediante el uso de una clave privada correspondiente del nodo de consenso. El nodo de consenso también puede configurar la clave privada del nodo de consenso y el certificado autofirmado.
En algunas implementaciones, el primer certificado de clave pública, el primero o más certificados de clave pública, el segundo certificado de clave pública y el segundo o más certificados de clave pública son certificados TLS.
Las implementaciones y las operaciones descritas en esta descripción pueden implementarse en circuitos electrónicos digitales, o en software, firmware o hardware de ordenador, incluidas las estructuras descritas en esta descripción o en combinaciones de una o más de ellas. Las operaciones pueden implementarse como operaciones realizadas por un aparato de procesamiento de datos en datos almacenados en uno o más dispositivos de almacenamiento legibles por ordenador o recibidos de otras fuentes. Un aparato de procesamiento de datos, ordenador o dispositivo informático puede abarcar aparatos, dispositivos y máquinas para procesar datos, incluyendo, a modo de ejemplo, un procesador programable, un ordenador, un sistema en un chip, o múltiples, o combinaciones, de lo anterior. El aparato puede incluir circuitos lógicos de propósito especial, por ejemplo, una unidad central de procesamiento (CPU), una matriz de puertas lógicas programable 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 protocolos, un sistema de gestión de base de datos, un sistema operativo (por ejemplo, un sistema operativo o una combinación de sistemas operativos), un entorno de tiempo 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, infraestructuras distribuidas de computación y de computación en cuadrícula.
Un programa de ordenador (también conocido, por ejemplo, como un programa, software, aplicación de software, módulo de software, unidad de software, script o código) puede escribirse en cualquier forma de lenguaje de programación, incluidos los lenguajes compilados o interpretados, los lenguajes declarativos o de procedimiento, y se puede implementar de cualquier forma, incluso como un programa independiente o como un módulo, componente, subrutina, objeto u otra unidad adecuada para su uso en un entorno informático. Un programa puede almacenarse en una porción de un archivo que contiene otros programas o datos (por ejemplo, uno o más scripts almacenados en un documento de lenguaje de marcado), en un único 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 de ordenador se puede ejecutar en un ordenador o en múltiples ordenadores que están ubicados en un sitio o distribuidos en múltiples sitios e interconectados por una red de comunicación. Los procesadores para la ejecución de un programa informático incluyen, a modo de ejemplo, tanto microprocesadores de propósito general como especiales, y cualquiera o más procesadores de cualquier tipo de ordenador digital. Generalmente, un procesador recibirá instrucciones y datos de una memoria de solo lectura o una memoria de acceso aleatorio o ambas. Los elementos esenciales de un ordenador son un procesador para realizar acciones de acuerdo con las instrucciones y uno o más dispositivos de memoria para almacenar instrucciones y datos. En general, un ordenador también incluirá, o estará acoplado operativamente para recibir datos o transferir datos a, o ambos, uno o más dispositivos de almacenamiento masivo para almacenar datos. Un ordenador puede integrarse 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 instrucciones y datos de programas de ordenador incluyen memoria no volátil, medios y dispositivos de memoria, que incluyen, a modo de ejemplo, dispositivos de memoria semiconductores, discos magnéticos y discos magnetoópticos. El procesador y la memoria pueden complementarse o incorporarse en un circuito lógico 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 portátiles (por ejemplo, relojes inteligentes y anteojos inteligentes), dispositivos implantados dentro del cuerpo humano (por ejemplo, biosensores, implantes cocleares) u otros tipos de dispositivos móviles. Los dispositivos móviles pueden comunicarse de forma inalámbrica (por ejemplo, mediante el uso de señales de radiofrecuencia (RF)) con varias redes de comunicación (descritas más abajo). 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 digitales, sistemas de reconocimiento facial, sensores de RF (por ejemplo, Wi-Fi y radios celulares), sensores térmicos u otros tipos de sensores. Por ejemplo, las cámaras pueden incluir una cámara hacia adelante o hacia atrás con lentes móviles o fijas, un flash, un sensor de imagen y un procesador de imagen. La cámara puede ser una cámara de megapíxeles capaz de capturar detalles para reconocimiento facial y/o 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 usar para la autenticación del usuario.
Para proporcionar interacción con un usuario, las implementaciones se pueden implementar en un ordenador que tiene 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 de emisión de luz (OLED)/realidad virtual (VR)/realidad aumentada (AR) para visualizar información al usuario y una pantalla táctil, teclado y un dispositivo señalador mediante el cual el usuario puede proporcionar una entrada al ordenador. También se pueden usar otros tipos de dispositivos para proporcionar 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 puede recibirse en cualquier forma, incluida la entrada acústica, de voz o táctil. Además, un ordenador puede interactuar con un usuario al enviar documentos a y recibir documentos de un dispositivo que usa el usuario; por ejemplo, al enviar páginas web a un navegador web en el dispositivo cliente del usuario en respuesta a solicitudes recibidas del navegador web.
Las implementaciones se pueden implementar mediante el uso de dispositivos informáticos interconectados por cualquier forma o medio de comunicación de datos digitales por cable o inalámbrica (o sus combinaciones), por ejemplo, una red de comunicación. Ejemplos de dispositivos interconectados son un cliente y un servidor generalmente remotos entre sí que típicamente interactúan a través de una red de comunicación. 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, al realizar transacciones de compra, venta, pago, entrega, envío o préstamo, o al autorizar estas. Dichas transacciones pueden ser en tiempo real, de manera que una acción y una respuesta son temporalmente próximas; por ejemplo, un individuo percibe que la acción y la respuesta se producen de manera sustancialmente simultánea, la diferencia de tiempo para una respuesta después de la acción del individuo es de menos de 1 milisegundo (ms) o menos de un 1 segundo (s), o la respuesta es sin demora intencional tomando en consideración las limitaciones de procesamiento del sistema.
Los ejemplos de redes de comunicación incluyen una red de área local (LAN), una red de acceso de radio (RAN), una red de área metropolitana (MAN) y una red de área amplia (WAN). La red de comunicación puede incluir todo o una porción de Internet, otra red de comunicación o una combinación de redes de comunicación. La información se puede transmitir en la red de comunicación de acuerdo con varios protocolos y estándares, incluyendo Evolución a largo plazo (LTE), 5G, IEEE 802, Protocolo de Internet (IP) u otros protocolos o combinaciones de protocolos. La red de comunicación puede transmitir datos de voz, video, 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 implementaciones múltiples, por separado o en cualquier subcombinación adecuada. Las operaciones descritas y reclamadas en un orden en particular no deben entenderse como que requieren que el orden en particular, ni que todas las operaciones ilustradas deben realizarse (algunas operaciones pueden ser opcionales). Según corresponda, se pueden realizar tareas múltiples o procesamiento paralelo (o una combinación de tareas múltiples y procesamiento paralelo).

Claims (9)

  1. REIVINDICACIONES
    i. Un método implementado por ordenador para aislar, por un lado, las comunicaciones entre un nodo de consenso (302a) y otro nodo de consenso (302a) y, por otro lado, las comunicaciones entre el nodo de consenso (302a) y un nodo cliente (302b), que comprende:
    generar (502), por el nodo de consenso (302a), una solicitud de firma de certificado, es decir, una CSR; enviar (504) la CSR a una primera autoridad certificadora, es decir, una CA (304a);
    recibir (506)
    a) un primer certificado de clave pública del nodo de consenso de la primera CA en respuesta a la CSR, y b) un primer certificado de clave pública del otro nodo de consenso, en donde el primer certificado de clave pública del otro nodo de consenso es emitido por la primera CA (304a);
    enviar (508) la CSR a una segunda CA (304b);
    recibir (510)
    a) un segundo certificado de clave pública del nodo de consenso de la segunda CA (304b) en respuesta a la CSR, y
    b) un segundo certificado de clave pública del nodo cliente, en donde el segundo certificado de clave pública del nodo cliente es emitido por la segunda CA (304b);
    configurar (512), en el nodo de consenso (302a), un primer almacén de confianza que incluye el primer certificado de clave pública del nodo de consenso y el primer certificado de clave pública del otro nodo de consenso, en donde el nodo de consenso está configurado para usar los primeros certificados de clave pública para comunicarse con el otro nodo de consenso y;
    configurar (512), en el nodo de consenso, un segundo almacén de confianza que incluye el segundo certificado de clave pública del nodo de consenso y el segundo certificado de clave pública del nodo cliente, en donde el nodo de consenso está configurado para usar los segundos certificados de clave pública para comunicarse con el nodo cliente.
  2. 2. El método implementado por ordenador de la reivindicación 1, que comprende, además:
    determinar la primera CA (304a) y la segunda CA (304b);
    recibir certificados raíz de la primera CA (304a) y la segunda CA (304b); y
    verificar los certificados raíz con base en las claves públicas correspondientes de la primera CA (304a) y la segunda CA (304b).
  3. 3. El método implementado por ordenador de la reivindicación 1, en donde la CSR incluye la clave pública y la información a incluir en el primer certificado de clave pública del nodo de consenso o el segundo certificado de clave pública del nodo de consenso.
  4. 4. El método implementado por ordenador de la reivindicación 2, en donde el nodo de consenso firma digitalmente la CSR mediante el uso de una clave privada.
  5. 5. El método implementado por ordenador de la reivindicación 1, en donde el primer certificado de clave pública del otro nodo de consenso está autofirmado por el otro nodo de consenso, o el segundo certificado de clave pública del nodo cliente está autofirmado por el nodo cliente.
  6. 6. El método implementado por ordenador de la reivindicación 1, que comprende, además:
    generar un certificado autofirmado de la clave pública mediante el uso de una clave privada correspondiente del nodo de consenso; y
    configurar, en el nodo de consenso, la clave privada del nodo de consenso y el certificado autofirmado.
  7. 7. El método implementado por ordenador de la reivindicación 1, en donde el primer certificado de clave pública del nodo de consenso, el primer certificado de clave pública del otro nodo de consenso, el segundo certificado de clave pública del nodo de consenso y el segundo certificado de clave pública del nodo cliente son certificados de seguridad de la capa de transporte, es decir, TLS.
  8. 8. Un medio de almacenamiento legible por ordenador no transitorio acoplado a uno o más procesadores y que tiene instrucciones almacenadas en el mismo, que, cuando son ejecutadas por el uno o más procesadores, hacen que uno o más procesadores realicen operaciones de acuerdo con el método de una o más de las reivindicaciones 1-7.
  9. 9. Un sistema que comprende:
    un dispositivo informático; y
    un dispositivo de almacenamiento legible por ordenador acoplado al dispositivo informático y que tiene instrucciones almacenadas en el mismo, que, cuando son ejecutadas por el dispositivo informático, hacen que el dispositivo informático realice operaciones de acuerdo con el método de una o más de las reivindicaciones 1-7.
ES18866296T 2018-11-07 2018-11-07 Gestión de comunicaciones entre nodos de consenso y nodos cliente Active ES2818623T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/114417 WO2019072267A2 (en) 2018-11-07 2018-11-07 COMMUNICATION MANAGEMENT BETWEEN CONSENSUS NODES AND CLIENT NODES

Publications (1)

Publication Number Publication Date
ES2818623T3 true ES2818623T3 (es) 2021-04-13

Family

ID=66100011

Family Applications (1)

Application Number Title Priority Date Filing Date
ES18866296T Active ES2818623T3 (es) 2018-11-07 2018-11-07 Gestión de comunicaciones entre nodos de consenso y nodos cliente

Country Status (16)

Country Link
US (2) US10887114B2 (es)
EP (1) EP3533178B1 (es)
JP (1) JP6768947B2 (es)
KR (1) KR102266206B1 (es)
CN (1) CN110383759B (es)
AU (1) AU2018347189B2 (es)
BR (1) BR112019008174A2 (es)
CA (1) CA3041159C (es)
ES (1) ES2818623T3 (es)
MX (1) MX2019004653A (es)
PH (1) PH12019500879A1 (es)
PL (1) PL3533178T3 (es)
RU (1) RU2713870C1 (es)
SG (1) SG11201903572YA (es)
WO (1) WO2019072267A2 (es)
ZA (1) ZA201902559B (es)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11172013B2 (en) 2019-01-31 2021-11-09 Open Text Corporation System and method for launching and connecting to a local server from a webpage
US12211032B2 (en) 2019-05-07 2025-01-28 Galaxy Digital Trading Llc Transferring digital assets possession over a unidirectional connection
US11245537B2 (en) * 2019-06-07 2022-02-08 Open Text Corporation System and method for a local server with self-signed certificates
CN110492997B (zh) * 2019-08-09 2020-12-01 华南理工大学 一种基于超级账本的加密系统、方法、装置和存储介质
US11283629B2 (en) 2019-10-10 2022-03-22 Red Hat, Inc. Automated replacement of renewable server certificates
US12099997B1 (en) 2020-01-31 2024-09-24 Steven Mark Hoffberg Tokenized fungible liabilities
KR20210121805A (ko) * 2020-03-31 2021-10-08 삼성전자주식회사 블록체인 기반의 pki 도메인에 속하는 전자 장치, 인증 기관 기반의 pki 도메인에 속하는 전자 장치, 및 이들을 포함하는 암호화 통신 시스템
CN111489159B (zh) * 2020-04-09 2024-03-15 腾讯科技（深圳）有限公司 数据处理方法、装置、计算机设备及介质
CN111858768B (zh) * 2020-07-27 2023-06-16 苏州区盟链数字科技有限公司 一种优化区块链可信节点与共识算法的装置
CN112560005B (zh) * 2020-12-01 2024-08-30 杭州趣链科技有限公司 身份可信服务系统、方法、电子设备和计算机可读介质
US12219062B2 (en) 2021-08-03 2025-02-04 Samsung Electronics Co., Ltd. Method and apparatus for managing non-fungible token for digital content
KR20230020262A (ko) * 2021-08-03 2023-02-10 삼성전자주식회사 디지털 컨텐츠에 대한 대체불가능 토큰을 관리하는 방법 및 장치
KR102777711B1 (ko) * 2021-11-16 2025-03-10 기초과학연구원 계층 구조에서 사용자 공개키 인증서 생성 방법, 인증을 위한 전자 서명 알고리즘 선택 방법, 및 상기 방법을 수행할 수 있는 장치
KR102800777B1 (ko) * 2023-12-19 2025-04-30 (주)드림시큐리티 분할된 키 기반 복수 노드의 서명 방법 및 장치

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7743248B2 (en) * 1995-01-17 2010-06-22 Eoriginal, Inc. System and method for a remote access service enabling trust and interoperability when retrieving certificate status from multiple certification authority reporting components
JP3890959B2 (ja) * 2001-11-22 2007-03-07 株式会社日立製作所 公開鍵証明書の生成システム及び検証システム
ATE366010T1 (de) * 2002-09-17 2007-07-15 Errikos Pitsos Verfahren und vorrichtung zur bereitstellung einer liste von öffentlichen schlüsseln in einem public-key-system
US7702902B2 (en) * 2004-06-25 2010-04-20 The Go Daddy Group, Inc. Method for a web site with a proxy domain name registration to receive a secure socket layer certificate
US7844816B2 (en) * 2005-06-08 2010-11-30 International Business Machines Corporation Relying party trust anchor based public key technology framework
US8898457B2 (en) * 2010-02-26 2014-11-25 Red Hat, Inc. Automatically generating a certificate operation request
US8627065B2 (en) * 2010-11-09 2014-01-07 Cleversafe, Inc. Validating a certificate chain in a dispersed storage network
US9021255B1 (en) * 2012-06-29 2015-04-28 Emc Corporation Techniques for multiple independent verifications for digital certificates
US8707027B1 (en) * 2012-07-02 2014-04-22 Symantec Corporation Automatic configuration and provisioning of SSL server certificates
KR101942412B1 (ko) 2014-05-08 2019-01-25 후아웨이 테크놀러지 컴퍼니 리미티드 증서 획득 방법 및 장치
US20170331896A1 (en) * 2016-05-13 2017-11-16 De La Rue International Limited Methods and systems for processing assets
US10700853B2 (en) * 2016-07-12 2020-06-30 International Business Machines Corporation Token identity and attribute management
KR101727525B1 (ko) * 2016-09-05 2017-04-17 주식회사 스케일체인 블록체인 기반 분산 저장 방법 및 이를 이용한 장치
US10382485B2 (en) * 2016-12-23 2019-08-13 Vmware, Inc. Blockchain-assisted public key infrastructure for internet of things applications
CN106789090B (zh) * 2017-02-24 2019-12-24 陈晶 基于区块链的公钥基础设施系统及半随机联合证书签名方法
CN108696348A (zh) * 2017-04-06 2018-10-23 中国移动通信有限公司研究院 一种实现ca互信的方法、装置、系统和电子设备
CN107392040B (zh) * 2017-04-28 2019-08-09 阿里巴巴集团控股有限公司 一种共识验证的方法及装置
CN107566337B (zh) * 2017-07-26 2019-08-09 阿里巴巴集团控股有限公司 一种区块链节点间的通信方法及装置
CN107592293A (zh) * 2017-07-26 2018-01-16 阿里巴巴集团控股有限公司 区块链节点间通讯方法、数字证书管理方法、装置和电子设备
CN107592292B (zh) * 2017-07-26 2019-08-09 阿里巴巴集团控股有限公司 一种区块链节点间通信方法及装置

Also Published As

Publication number Publication date
WO2019072267A2 (en) 2019-04-18
EP3533178B1 (en) 2020-09-09
CA3041159A1 (en) 2019-04-18
AU2018347189B2 (en) 2020-07-23
PH12019500879A1 (en) 2019-11-25
CN110383759A (zh) 2019-10-25
JP6768947B2 (ja) 2020-10-14
RU2713870C1 (ru) 2020-02-07
US11108571B2 (en) 2021-08-31
CN110383759B (zh) 2022-05-10
JP2020503717A (ja) 2020-01-30
CA3041159C (en) 2021-12-07
SG11201903572YA (en) 2019-05-30
EP3533178A2 (en) 2019-09-04
US10887114B2 (en) 2021-01-05
MX2019004653A (es) 2019-08-05
KR20200054123A (ko) 2020-05-19
EP3533178A4 (en) 2019-09-25
US20210083885A1 (en) 2021-03-18
US20190253265A1 (en) 2019-08-15
AU2018347189A1 (en) 2020-05-21
KR102266206B1 (ko) 2021-06-21
ZA201902559B (en) 2019-12-18
PL3533178T3 (pl) 2021-01-11
WO2019072267A3 (en) 2019-07-25
BR112019008174A2 (pt) 2019-09-10

Similar Documents

Publication Publication Date Title
ES2818623T3 (es) Gestión de comunicaciones entre nodos de consenso y nodos cliente
US10848314B2 (en) Blockchain data processing methods, apparatuses, processing devices, and systems
US11107075B2 (en) Blockchain data processing methods, apparatuses, devices, and systems
ES2881319T3 (es) Protección de datos de cadena de bloques mediante cifrado homomórfico
ES2876926T3 (es) Protección de datos de cadena de bloques utilizando cifrado homomórfico
US20200136814A1 (en) Key data processing method and apparatus, and server
EP3701458A1 (en) Blockchain data processing methods, apparatuses, processing devices, and systems
US11113423B2 (en) FPGA hardware-based secure computing method and apparatus
JP2020501406A (ja) アカウントモデルの下でパブリックおよびプライベートトランザクションをサポートするブロックチェーンシステム
BR112019008140A2 (pt) método implementado por computador, meio de armazenamento legível por computador não transitório e sistema
HK40016606A (en) Method and system for managing communications among consensus nodes and client nodes
HK40016606B (zh) 管理共识节点和客户端节点之间的通信的方法和系统