BR112019008174A2 - método implementado por computador, meio de armazenamento legível por computador, não transitório e sistema - Google Patents

método implementado por computador, meio de armazenamento legível por computador, não transitório e sistema Download PDF

Info

Publication number
BR112019008174A2
BR112019008174A2 BR112019008174A BR112019008174A BR112019008174A2 BR 112019008174 A2 BR112019008174 A2 BR 112019008174A2 BR 112019008174 A BR112019008174 A BR 112019008174A BR 112019008174 A BR112019008174 A BR 112019008174A BR 112019008174 A2 BR112019008174 A2 BR 112019008174A2
Authority
BR
Brazil
Prior art keywords
public key
consensus
nodes
cas
certificates
Prior art date
Application number
BR112019008174A
Other languages
English (en)
Inventor
Pan Dong
Chen Shenglong
Yan Xuebing
Original Assignee
Alibaba Group Holding 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 Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Publication of BR112019008174A2 publication Critical patent/BR112019008174A2/pt

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/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/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/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

as implementações da presente invenção incluem gerar, por um nó de consenso, uma solicitação de assinatura de certificado (csr); enviar a csr para uma primeira autoridade de certificação (ca); receber um primeiro certificado de chave pública do nó de consenso a partir da primeira ca e um primeiro um ou mais certificados de chave pública emitidos por uma primeira uma ou mais cas. os nós de consenso também enviam a csr a uma segunda ca, recebem um segundo certificado de chave pública do nó de consenso a partir da segunda ca e um segundo um ou mais certificados de chave pública emitidos por uma segunda uma ou mais cas. o nó de consenso configura ainda um primeiro armazenamento confiável, incluindo o primeiro certificado de chave pública e o primeiro um ou mais certificados de chave pública, e um segundo armazenamento confiável, incluindo o segundo certificado de chave pública e o segundo um ou mais certificados de chave pública.

Description

“MÉTODO IMPLEMENTADO POR COMPUTADOR, MEIO LEGÍVEL POR COMPUTADOR E SISTEMA PARA A REALIZAR UM MÉTODO”
Campo da Invenção [001] A presente invenção refere-se ao gerenciamento de comunicações entre nós de consenso e comunicações entre nós de consenso e nós clientes.
Antecedentes da Invenção [002] As redes de protocolo de confiança (blockchain), que também podem ser referidas como sistemas de protocolo de confiança, redes de consenso, redes de sistema de contabilidade distribuída (DLS) ou protocolo de confiança, permitem que as entidades participantes armazenem dados de forma segura e imutável. Um protocolo de confiança pode ser descrito como um livro-razão de transações e várias cópias do protocolo de confiança são armazenadas através da rede de protocolo de confiança. Exemplos de tipos de protocolos de confiança podem incluir protocolos de confiança públicos, protocolos de confiança de consórcio e protocolos de confiança privados. Um protocolo de confiança público está aberto para todas as entidades usarem o protocolo de confiança e participarem do processo de consenso. Um protocolo de confiança de consórcio é um protocolo de confiança onde o processo de consenso é controlado por um conjunto pré-selecionado de nós. Um protocolo de confiança privado é fornecido para uma entidade específica, que controla centralmente as permissões de leitura e gravação.
[003] O sistema de protocolo de confiança de consórcio pode incluir nós de consenso e nós clientes (ou usuários) que usam a rede de consórcio. Por um lado, os nós de consenso comunicam-se com outros nós de consenso para chegar a um consenso. Por outro lado, os nós de consenso se comunicam com os nós clientes para aceitar e adicionar novas transações aos blocos. Em alguns casos, os nós de consenso também se comunicam com
Petição 870190058524, de 25/06/2019, pág. 9/42
2/24 redes de nós pré-selecionados de um sistema de consórcio ou outros sistemas principais com diferentes níveis de segurança. Como tal, os limites podem ser definidos para diferentes tipos de comunicações para proteger a privacidade dos dados e a segurança.
Descrição da Invenção [004] As realizações da presente invenção destinam-se a gerir comunicações entre nós de consenso e comunicações entre nós de consenso e nós clientes. Mais particularmente, as realizações da presente invenção destinam-se a configurar certificados raiz emitidos pelas respectivas autoridades de certificação (CAs) para comunicações entre nós de consenso e entre nós de consenso e nós clientes, para que nós clientes não possam acessar mensagens de consenso comunicadas entre nós de consenso.
[005] Em algumas realizações, as ações incluem gerar, por um nó de consenso, uma solicitação de assinatura de certificado (CSR); enviar a CSR para uma primeira autoridade de certificação (CA); receber um primeiro certificado de chave pública do nó de consenso a partir da primeira CA em resposta à CSR, e um primeiro um ou mais certificados de chave pública de um ou mais outros nós de consenso emitidos por uma primeira uma ou mais CAs; enviar a CSR para uma segunda CA; receber um segundo certificado de chave pública do nó de consenso a partir da segunda CA em resposta à CSR, e um segundo um ou mais certificados de chave pública de um ou mais nós clientes emitidos por uma segunda uma ou mais CAs; e configurar, no nó de consenso, um primeiro armazenamento confiável, incluindo o primeiro certificado de chave pública e o primeiro um ou mais certificados de chave pública do um ou mais outros nós de consenso e um segundo armazenamento confiável, incluindo o segundo certificado de chave pública e o segundo um ou mais certificados de chave pública do um ou mais nós clientes. Outras realizações incluem sistemas, aparelhos e programas de computador correspondentes,
Petição 870190058524, de 25/06/2019, pág. 10/42
3/24 configurados para executar as ações dos métodos, codificados em dispositivos de armazenamento de computador.
[006] Estas e outras realizações podem incluir, opcionalmente, uma ou mais das seguintes características: determinar a primeira uma ou mais CAs e a segunda uma ou mais CAs; receber certificados raiz da primeira uma ou mais CAs e da segunda uma ou mais CAs; e verificar os certificados raiz com base nas chaves públicas correspondentes da primeira uma ou mais CAs e da segunda uma ou mais CAs; em que a CSR inclui a chave pública e informação a ser incluída no primeiro certificado de chave pública ou no segundo certificado de chave pública; em que a CSR é assinada digitalmente pelo nó de consenso usando uma chave privada; em que pelo menos uma parte do primeiro um ou mais certificados de chave pública são auto-assinados por nós de consenso correspondentes, ou uma parte do segundo um ou mais certificados de chave pública são auto-assinados por nós clientes correspondentes; gerar um certificado auto-assinado da chave pública usando uma chave privada correspondente do nó de consenso; e configurar, no nó de consenso, a chave privada do nó de consenso e o certificado auto-assinado; em que o primeiro certificado de chave pública, o primeiro um ou mais certificados de chave pública, o segundo certificado de chave pública e o segundo um ou mais certificados de chave pública são certificados de segurança de camada de transporte (TLS).
[007] A presente invenção também fornece um ou mais meios de armazenamento legíveis por computador, não-transitórios, acoplados a um ou mais processadores e tendo instruções armazenadas nele que, quando executadas por um ou mais processadores, fazem com que o um ou mais processadores executem operações de acordo com realizações dos métodos aqui fornecidos.
Petição 870190058524, de 25/06/2019, pág. 11/42
4/24 [008] A presente invenção fornece ainda um sistema para a realização dos métodos aqui fornecidos. O sistema inclui um ou mais processadores, e um meio de armazenamento legível por computador acoplado ao um ou mais processadores possuindo instruções armazenadas nele que, quando executadas pelo um ou mais processadores, fazem com que o um ou mais processadores executem operações de acordo com realizações dos métodos aqui fornecidos.
[009] É apreciado que os métodos de acordo com a presente invenção podem incluir qualquer combinação dos aspectos e características aqui descritos. Isto é, os métodos de acordo com a presente invenção não estão limitados às combinações de aspectos e características especificamente descritos aqui, mas também incluem qualquer combinação dos aspectos e características proporcionados.
[010] Os detalhes de uma ou mais realizações da presente invenção são apresentados nas figuras anexas e na descrição abaixo. Outras características e vantagens da presente invenção serão evidentes a partir da descrição e figuras, e das reivindicações.
Breve Descrição dos Desenhos [011] A Figura 1 representa um exemplo de ambiente que pode ser usado para executar realizações da presente invenção.
[012] A Figura 2 representa um exemplo de arquitetura conceituai de acordo com realizações da presente invenção.
[013] A Figura 3A representa um exemplo de processo de configuração de comunicações entre nós de consenso de acordo com realizações da presente invenção.
[014] A Figura 3B representa um exemplo de processo de configuração de comunicações entre nós de consenso e nós clientes de acordo com realizações da presente invenção.
Petição 870190058524, de 25/06/2019, pág. 12/42
5/24 [015] A Figura 4 representa um exemplo de configurações para comunicações entre nós de consenso e nós clientes de acordo com realizações da presente invenção.
[016] A Figura 5 representa um exemplo de método de gestão de comunicações de nós de consenso e de nós clientes de acordo com realizações da presente invenção.
[017] Símbolos de referência iguais nos vários desenhos indicam elementos iguais.
Descrição de Realizações da Invenção [018] As realizações da presente invenção destinam-se a gerir comunicações entre nós de consenso e comunicações entre nós de consenso e nós clientes. Mais particularmente, as realizações da presente invenção destinam-se a configurar certificados raiz emitidos pelas respectivas autoridades de certificação (CAs) para comunicações entre nós de consenso e entre nós de consenso e nós clientes, para que nós clientes não possam acessar mensagens de consenso comunicadas entre nós de consenso.
[019] Em algumas realizações, as ações incluem gerar, por um nó de consenso, uma solicitação de assinatura de certificado (CSR); enviar a CSR para uma primeira autoridade de certificação (CA); receber um primeiro certificado de chave pública do nó de consenso a partir da primeira CA em resposta à CSR, e um primeiro um ou mais certificados de chave pública de um ou mais outros nós de consenso emitidos por uma primeira uma ou mais CAs; enviar a CSR para uma segunda CA; receber um segundo certificado de chave pública do nó de consenso a partir da segunda CA em resposta à CSR, e um segundo um ou mais certificados de chave pública de um ou mais nós clientes emitidos por uma segunda uma ou mais CAs; e configurar, no nó de consenso, um primeiro armazenamento confiável incluindo o primeiro certificado de chave pública e o primeiro um ou mais certificados de chave pública do um ou mais
Petição 870190058524, de 25/06/2019, pág. 13/42
6/24 outros nós de consenso, e um segundo armazenamento confiável incluindo o segundo certificado de chave pública e o segundo um ou mais certificados de chave pública do um ou mais nós clientes.
[020] Para fornecer contexto adicional para realizações da presente invenção, e como introduzido acima, redes de protocolo de confiança, que também podem ser referidas como redes de consenso (por exemplo, compostas de nós peer-to-peer), sistema de contabilidade distribuída, ou simplesmente protocolo de confiança, permitem que as entidades participantes conduzam transações e armazenem dados de maneira segura e imutável. Um protocolo de confiança pode ser fornecido como um protocolo de confiança público, um protocolo de confiança privado ou um protocolo de confiança de consórcio. As realizações da presente invenção são aqui descritas em mais detalhe com referência a um protocolo de confiança público, que é público entre as entidades participantes. Está contemplado, no entanto, que as realizações da presente invenção podem ser realizadas em qualquer tipo apropriado de protocolo de confiança.
[021] Em um protocolo de confiança de consórcio, o processo de consenso é controlado por um conjunto autorizado de nós, um ou mais nós sendo operados por uma entidade respectiva (por exemplo, uma empresa). Por exemplo, um consórcio de dez (10) entidades (por exemplo, empresas) pode operar um sistema de protocolo de confiança de consórcio, cada uma das quais operando pelo menos um nó no consórcio DLS. Assim, o sistema de protocolo de confiança de consórcio pode ser considerado uma rede privada em relação às entidades participantes. Em alguns exemplos, cada entidade (nó) deve assinar todos os blocos para que o bloco seja válido e adicionado ao protocolo de confiança. Em alguns exemplos, pelo menos um sub-conjunto de entidades (nós) (por exemplo, pelo menos 7 entidades) deve assinar todos os blocos para que o bloco seja válido e adicionado ao protocolo de confiança. Um
Petição 870190058524, de 25/06/2019, pág. 14/42
7/24 exemplo de sistema de protocolo de confiança de consórcio inclui o Quorum, desenvolvido pela J.P. Morgan Chase & Co. de Nova Iorque, Nova Iorque. O Quorum pode ser descrito como uma infraestrutura de protocolo de confiança autorizada e focada na empresa, projetada especificamente para casos de uso financeiro. O Quorum é construído a partir do Go Ethereum, o código base do protocolo de confiança Ethereum, que é fornecido pela Fundação Ethereum de Zug, na Suíça.
[022] Em geral, um sistema de protocolo de confiança de consórcio suporta transações entre entidades participantes, com permissão, no sistema de protocolo de confiança de consórcio. Uma transação é compartilhada com todos os nós dentro do sistema de protocolo de confiança de consórcio, porque o protocolo de confiança é replicado em todos os nós. Ou seja, todos os nós estão em perfeito estado de consenso em relação ao protocolo de confiança. Para chegar a um consenso (por exemplo, acordo para a adição de um bloco a um protocolo de confiança), um protocolo de consenso é implementado dentro da rede de protocolo de confiança de consórcio. Um exemplo de protocolo de consenso inclui, sem limitação, prova de trabalho (POW) implementada na rede Bitcoin.
[023] As realizações da presente invenção são aqui descritas em maior detalhe tendo em vista o contexto acima. Mais particularmente, e como introduzido acima, as realizações da presente invenção destinam-se a configurar certificados raiz emitidos pelas respectivas CAs para comunicações entre nós de consenso e entre nós de consenso e nós clientes, de modo que os nós clientes não posam acessar mensagens de consenso comunicadas entre nós de consenso.
[024] A Figura 1 representa um exemplo de ambiente (100) que pode ser utilizado para executar realizações da presente invenção. Em alguns exemplos, o ambiente de exemplo (100) permite que entidades participem em
Petição 870190058524, de 25/06/2019, pág. 15/42
8/24 um protocolo de confiança público (102). O ambiente de exemplo (100) inclui sistemas de computação (106, 108) e uma rede (110). Em alguns exemplos, a rede (110) inclui uma rede de área local (LAN), rede de longa distância (WAN), a Internet ou uma combinação dos mesmos, e conecta web sites, dispositivos de usuário (por exemplo, dispositivos de computação) e sistema secundário (back-end). Em alguns exemplos, a rede (110) pode ser acessada através de uma conexão de comunicação com fio e/ ou sem fio.
[025] No exemplo descrito, os sistemas de computação (106, 108) podem incluir, cada um, qualquer sistema de computação apropriado que permita a participação como um nó no sistema de protocolo de confiança de consórcio (102), para armazenar transações em um protocolo de confiança (104). Exemplos de dispositivos de computação incluem, sem limitação, um servidor, um computador de mesa, um computador laptop, um dispositivo de computador tablete um telefone inteligente. Em alguns exemplos, os sistemas de computação (106, 108) hospedam um ou mais serviços implementados por computador para interagir com o sistema de protocolo de confiança de consórcio (102). Por exemplo, o sistema de computação (106) pode hospedar serviços implementados por computador de uma primeira entidade (por exemplo, usuário A), tal como um sistema de gestão de transações que a primeira entidade usa para gerenciar suas transações com uma ou mais outras entidades (por exemplo, outros usuários). O sistema de computação (108) pode hospedar serviços implementados por computador de uma segunda entidade (por exemplo, usuário B), tal como sistema de gestão de transação que a segunda entidade usa para gerenciar suas transações com uma ou mais outras entidades (por exemplo, outros usuários). No exemplo da Figura 1, o sistema de protocolo de confiança de consórcio (102) é representado como uma rede peer-to-peer de nós, e os sistemas de computação (106, 108)
Petição 870190058524, de 25/06/2019, pág. 16/42
9/24 fornecem nós da primeira entidade e segunda entidade, respectivamente, que participam no sistema de protocolo de confiança de consórcio (102).
[026] A Figura 2 representa um exemplo de arquitetura conceituai (200) de acordo com realizações da presente invenção. A arquitetura conceituai exemplificativa (200) inclui uma camada de entidade (202), uma camada de serviços hospedados (204) e uma camada de protocolo de confiança (206). No exemplo representado, a camada de entidade (202) inclui três entidades, Entidade_1 (E1), Entidade_2 (E2) e Entidade_3 (E3), cada entidade possuindo um respectivo sistema de gestão de transações (208).
[027] No exemplo representado, a camada de serviços hospedados (204) inclui interfaces de protocolo de confiança (210) para cada sistema de gestão de transação (208). Em alguns exemplos, um sistema de gestão de transação respectivo (208) se comunica com uma respectiva interface de protocolo de confiança (210) através de uma rede (por exemplo, a rede (110) da Figura 1) usando um protocolo de comunicação (por exemplo, protocolo de transferência de hipertexto seguro (HTTPS)). Em alguns exemplos, cada interface de protocolo de confiança (210) fornece uma conexão de comunicação entre um respectivo sistema de gestão de transação (208) e a camada de protocolo de confiança (206). Mais particularmente, cada interface de protocolo de confiança (210) permite que a respectiva entidade realize transações registradas em um sistema de protocolo de confiança de consórcio (212) da camada de protocolo de confiança (206). Em alguns exemplos, a comunicação entre uma interface de protocolo de confiança (210), e a camada de protocolo de confiança (206) é conduzida utilizando chamadas de procedimentos remotos (RPCs). Em alguns exemplos, as interfaces de protocolo de confiança (210) “hospedam” nós de consenso para os respectivos sistemas de gestão de transações (208). Por exemplo, as interfaces de
Petição 870190058524, de 25/06/2019, pág. 17/42
10/24 protocolo de confiança (210) fornecem a interface de programação de aplicativos (API) para o acesso ao sistema de protocolo de confiança de consórcio (212).
[028] Um sistema de protocolo de confiança pode incluir nós de consenso e nós clientes. Os nós de consenso podem participar do processo de consenso. Os nós clientes podem usar o sistema de protocolo de confiança, mas não participam do processo de consenso. Em algumas realizações, os nós de consenso podem participar do processo de consenso enquanto usam o sistema de protocolo de confiança para outros propósitos. Em algumas realizações, os nós de consenso podem se comunicar com os nós clientes, para que os usuários possam usar os nós clientes para enviar transações para o protocolo de confiança. Os nós de consenso também podem se comunicar uns com os outros para chegar a um consenso, a fim de adicionar as transações dos nós clientes ao protocolo de confiança.
[029] Em algumas realizações, as comunicações entre os nós de consenso e as comunicações entre os nós de consenso e os nós clientes podem ser realizadas com base em protocolos criptográficos, como o protocolo de segurança de camada de transporte (TLS), para garantir a segurança das comunicações.
[030] Para aumentar a privacidade e gerenciar dados que podem ser acessados por nós diferentes, as comunicações entre os nós de consenso podem ser isoladas das comunicações entre os nós de consenso e os nós clientes. Em algumas realizações, o isolamento pode ser feito formando diferentes armazenamentos confiáveis TLS de certificados de chave pública de diferentes nós. Os certificados de chave pública podem ser emitidos pelas respectivas autoridades de certificação (CAs) para comunicações entre os nós de consenso e comunicações entre os nós de consenso e os nós clientes.
Petição 870190058524, de 25/06/2019, pág. 18/42
11/24 [031] A Figura 3A representa um processo de exemplo (300a) para configurar comunicações entre nós de consenso (302a) de acordo com realizações da presente invenção. Os nós de consenso (302a) podem ser implementados usando qualquer dispositivo eletrônico apropriado, como um computador, um telefone inteligente ou um servidor, conectado à rede de protocolo de confiança.
[032] Em (306a), os nós de consenso (302a) identificam uma ou mais CAs (304a) que podem ser confiáveis. Em algumas realizações, as CAs podem ser entidades que emitem certificados de chave pública. Os certificados de chave pública podem ser usados para certificar a propriedade de chaves públicas pelos assuntos nomeados do certificado. Os assuntos nomeados podem ser as próprias CAs ou outras entidades que desejam que suas chaves públicas sejam certificadas. Chaves públicas pertencentes e auto-assinadas por CAs podem se tornar certificados raiz. Em alguns casos, pelo menos uma parte dos nós de consenso (302a) pode ser identificada como CAs. Nesses casos, esses nós de consenso podem auto-assinar suas chaves públicas para gerar certificados de chave pública. Em alguns casos, os certificados de chave pública gerados com base nos protocolos TLS podem ser chamados de certificados TLS.
[033] Em (308a), as CAs (304a) preparam suas chaves privadas e certificados auto-assinados. Os certificados auto-assinados podem ser o certificado raiz das CAs de suas chaves públicas correspondentes.
[034] Em (310a), as CAs (304a) enviam os certificados autoassinados para os nós de consenso (302a). Em algumas realizações, os certificados auto-assinados podem incluir assinaturas digitais das CAs (304a) assinadas usando suas chaves privadas correspondentes. Como tal, os nós de consenso (302a) podem verificar se os certificados são emitidos pelas CAs (304a) utilizando as chaves públicas das chaves públicas de CAs (304a).
Petição 870190058524, de 25/06/2019, pág. 19/42
12/24 [035] Em (312a), os nós de consenso (302a) geram solicitações de assinatura de certificado (CSRs). As CSRs são blocos de texto codificado que são fornecidos às CAs (304a) ao solicitar certificados TLS. Em alguns exemplos, as CSRs podem conter informações que serão incluídas nos certificados TLS, tal como um nome de organização, nome comum (nome de domínio), localidade e país. As CSRs também podem conter as chaves públicas a serem incluídas nos certificados TLS. Os nós de consenso (302a) podem criar as chaves privadas ao criar as CSRs e usar as chaves privadas para assinar as CSRs correspondentes.
[036] Em (314a), os nós de consenso (302a) enviam as CSRs para as CAs (304a). Em (316a), as CAs (304a) geram certificados de chave pública para os nós de consenso (302a) em resposta às CSRs. As CAs (304a) podem verificar se as assinaturas digitais correspondentes às CSRs estão corretas a partir dos nós de consenso (302a), antes de gerar os certificados de chave pública para os nós de consenso (302a).
[037] Em (318a), as CAs (304a) enviam o certificado de chave pública para os nós de consenso (302a). As CAs (304a) podem enviar os certificados de chave pública para todos os nós de consenso (302a) na rede de protocolo de confiança. Como tal, cada nó de consenso (302a) pode ter uma cópia dos certificados de chave pública de todos os outros nós de consenso (302a) na rede.
[038] Em (320a), os nós de consenso (302a) configuram armazenamentos confiáveis, chaves privadas e certificados auto-assinados. Os armazenamentos confiáveis podem ser usados para armazenar certificados TLS de CAs confiáveis (304a). Ao receber e verificar os certificados TLS das CAs confiáveis, os nós de consenso (302a) podem usar as chaves públicas certificadas para criptografar mensagens e comunicar com segurança com outros nós de consenso na rede. Em algumas realizações, os nós de consenso
Petição 870190058524, de 25/06/2019, pág. 20/42
13/24 (302a) também podem gerar certificados de chave pública auto-assinados usando uma chave privada correspondente dos nós de consenso correspondentes (302a). A chave privada também pode ser usada para decifrar mensagens de outros nós na rede de protocolo de confiança criptografada usando a chave pública do nó de consenso (302a) correspondente.
[039] Em algumas realizações, a rede de protocolo de confiança pode ser configurada de forma que as comunicações entre os nós de consenso e as comunicações entre os nós de consenso e os nós clientes sejam isoladas. Ou seja, os nós clientes não podem acessar os dados comunicados entre os nós de consenso, e os nós de consenso não podem acessar os dados comunicados entre outros nós de consenso e seus nós clientes conectados. Em alguns exemplos, os nós de consenso que realizam consenso podem solicitar certificados TLS a partir de um primeiro conjunto de CAs, e os pares de nó de consenso/ nó cliente que se comunicam entre si podem solicitar certificados TLS de CAs diferentes do primeiro conjunto de CAs ou não executar criptografia de chave pública de seus dados.
[040] A Figura 3B representa um exemplo de processo (300b) para configurar comunicações entre nós de consenso e nós clientes (302b) de acordo com realizações da presente invenção.
[041] Em (306b), os nós de consenso e nós clientes (302b) identificam uma ou mais CAs (304b) diferentes das CAs (304a) identificadas no processo de exemplo (300a) discutido acima com referência à Figura 3A. Em algumas realizações, cada par de nó de consenso/ nó cliente pode identificar uma CA diferente, de modo que suas comunicações podem ser isoladas de outras. Em algumas realizações, cada nó cliente e o nó de consenso com o qual ele se comunica podem formar uma rede de pequena escala e identificar uma ou mais CAs não utilizadas por outros nós clientes ou os nós de consenso (302a) para consenso. Em alguns casos, pelo menos uma parte dos nós de
Petição 870190058524, de 25/06/2019, pág. 21/42
14/24 consenso e os nós clientes (302b) podem se identificar como CAs. Nesses casos, esses nós de consenso podem auto-assinar suas chaves públicas para gerar certificados de chave pública, desde que os certificados não sejam autoassinados pelos nós de consenso (302a) para comunicações com outros nós de consenso no processo de exemplo (300a).
[042] Em (308b), as CAs (304b) preparam suas chaves privadas e certificados auto-assinados. Os certificados auto-assinados podem ser os certificados raiz das CAs de suas chaves públicas correspondentes.
[043] Em (310b), as CAs (304b) enviam os certificados autoassinados para os nós de consenso e os nós clientes (302b). Em algumas realizações, os certificados auto-assinados podem incluir as assinaturas digitais das CAs (304b) assinadas usando suas respectivas chaves privadas. Como tal, os nós de consenso e os nós clientes (302b) podem verificar que os certificados são emitidos pelas CAs (304b) utilizando as chaves públicas das CAs (304b).
[044] Em (312b), os nós de consenso e os nós clientes (302b) geram CSRs. Os nós de consenso e os nós clientes (302b) podem criar as chaves privadas ao criar as CSRs e usar as chaves privadas para assinar as CSRs correspondentes.
[045] Em (314b), os nós de consenso e os nós clientes (302b) enviam as CSRs para as CAs (304b). Em (316b), as CAs (304b) geram certificados de chave pública para os nós de consenso e nós clientes (302b) em resposta às CSRs. As CAs (304b) podem verificar se as assinaturas digitais correspondentes às CSRs estão corretas, antes de gerar os certificados de chave pública para os nós de consenso.
[046] Em (318b), as CAs (304b) enviam o certificado de chave pública para os nós de consenso e nós clientes (302b). Em algumas realizações, CAs diferentes podem enviar certificados de chave pública a
Petição 870190058524, de 25/06/2019, pág. 22/42
15/24 diferentes pares de nó(s) de consenso/ nó cliente para formar um armazenamento confiável de certificados de pequena escala. Como tal, cada par de nós cliente pode ter certificados de chave pública de nó(s) de consenso emitidos por CAs diferentes para garantir a privacidade das comunicações.
[047] Em (320b), os nós de consenso e os nós clientes (302b) configuram armazenamentos confiáveis, chaves privadas e certificados autoassinados. Como diferentes nós clientes podem ter diferentes armazenamentos confiáveis de certificados TLS para comunicações criptografadas, e os nós de consenso podem ter seu próprio armazenamento confiável de certificados TLS para comunicações criptografadas, a privacidade de dados das comunicações desempenhadas por diferentes partes pode ser protegida.
[048] A Figura 4 representa um exemplo de sistema de protocolo de confiança (400) e configuração para comunicações entre nós de consenso e nós clientes de acordo com realizações da presente invenção. Em um nível alto, o exemplo de sistema de protocolo de confiança (400) inclui quatro nós de consenso: nó 1 (302), nó 2 (304), nó 3 (306) e nó 4 (308). Três nós clientes, cliente 1 (310), cliente 2 (312) e cliente 3 (314), são conectados aos nós de consenso. O cliente 1 (310) está conectado ao nó 1 (310), e ao nó 2 (312), o cliente 2 (312) está conectado ao nó 3 (306), e o cliente 3 (314) está conectado ao nó 4 (308). Os nós de consenso podem comunicar com os nós cliente, para que os usuários possam enviar transações de nós clientes para nós de consenso. Os nós de consenso podem se comunicar uns com os outros para executar um processo de consenso para adicionar as transações dos nós clientes ao protocolo de confiança.
[049] Para comunicações entre os nós de consenso, o nó 1 (402), o nó 2 (404), o nó 3 (406) e o nó 4 (408) podem cada um obter uma réplica de protocolo de confiança de um armazenamento confiável (A). O armazenamento confiável (A) pode incluir certificados TLS do nó 1 (402), do nó
Petição 870190058524, de 25/06/2019, pág. 23/42
16/24 (404), do nó 3 (406) e do nó 4 (408) emitidos por um primeiro conjunto de CAs. Em algumas realizações, os nós de consenso podem ser as CAs para auto-assinar seus certificados de chave pública correspondentes. O nó 1 (402), o nó 2 (404), o nó 3 (406) e o nó 4 (408) também podem ser configurados com suas respectivas chaves privadas e certificados auto-assinados. Como tal, as comunicações entre o nó 1 (402), o nó 2 (404), o nó 3 (406) e o nó 4 (408) podem ser baseadas em certificados TLS do armazenamento confiável (A).
[050] O cliente 1 (410) está conectado para comunicação com o nó 1 (402) e o nó 2 (404). O cliente 1 (410), o nó 1 (402) e o nó 2 (404) podem cada um obter uma réplica de protocolo de confiança de um armazenamento confiável (B). O armazenamento confiável (B) pode incluir certificados TLS do cliente 1 (410), do nó 1 (402) e do nó 2 (404) emitido por um segundo conjunto de CAs. Novamente, os certificados de TLS podem ser auto-assinados desde que a autoridade de assinatura seja diferente da autoridade usada para assinar certificados TLS para que outras comunicações sejam isoladas. O cliente 1 (410), o nó 1 (402) e o nó 2 (404) também podem ser configurados com suas respectivas chaves privadas e certificados auto-assinados. Como tal, as comunicações entre o cliente 1 (410) e o nó 1 (402), e entre o cliente 1 (410) e o nó 2 (404), podem basear-se em certificados TLS do armazenamento confiável (B).
[051] Em algumas realizações, embora o nó 1 (402) e o nó 2 (404) mantenham o armazenamento confiável (A) e o armazenamento confiável (B), eles podem apenas comunicar entre si com base nos certificados TLS do armazenamento confiável (A). Eles não podem se comunicar com base nos certificados TLS do armazenamento confiável (B). Correspondentemente, o cliente 1 (410) não pode visualizar mensagens de consenso comunicadas entre o nó 1 (402) e o nó 2 (404).
[052] O cliente 2 (412) está conectado para comunicação com o
Petição 870190058524, de 25/06/2019, pág. 24/42
17/24 nó 3 (406). O cliente 2 (412) e o nó 3 (406) podem cada um obter uma réplica de protocolo de confiança de um armazenamento confiável (C). O armazenamento confiável (C) pode incluir certificados TLS do cliente 2 (412) e o nó 3 (406) emitido por um terceiro conjunto de CAs. O cliente 2 (412) e o nó 3 (406) também podem ser configurados com suas respectivas chaves privadas e certificados auto-assinados. Como tal, a comunicação entre o cliente 2 (412) e o nó 3 (406) pode ser baseada em certificados TLS do armazenamento confiável (C).
[053] O cliente 3 (414) está conectado com o nó 4 (408). As comunicações entre o cliente 3 (414) e o nó 4 (408) não são criptografadas. Como tal, o cliente 3 (414) não precisa de manter certificados de chave pública para comunicações. No entanto, o cliente 3 (414) pode assumir o risco de roubo de identidade, tal como outros nós fingindo ser o cliente 3 (414) para comunicar com o nó 4 (408).
[054] A Figura 5 representa um exemplo de processo (500) para gerir comunicações de nó de consenso e nó cliente de acordo com realizações da presente invenção. Para clareza de apresentação, a descrição que se segue descreve de modo geral o processo de exemplo (500) no contexto das outras figuras nesta descrição. No entanto, será entendido que o processo de exemplo (500) pode ser realizado, por exemplo, por qualquer sistema, ambiente, software e hardware, ou uma combinação de sistemas, ambientes, software e hardware, conforme apropriado. Em algumas realizações, várias etapas do processo de exemplo (500) podem ser executadas em paralelo, em combinação, em ciclos ou em qualquer ordem.
[055] Em (502), um nó de consenso gera uma CSR. Em algumas realizações, antes de gerar a CSR, o nó de consenso pode identificar uma primeira uma ou mais CAs e uma segunda uma ou mais CAs. O nó de consenso também pode receber certificados raiz da primeira uma ou mais CAs
Petição 870190058524, de 25/06/2019, pág. 25/42
18/24 e da segunda uma ou mais CAs, e verificar os certificados raiz com base nas respectivas chaves públicas da primeira uma ou mais CAs e da segunda uma ou mais CAs. Em algumas realizações, a CSR inclui a chave pública e as informações a serem incluídas no primeiro certificado de chave pública ou no segundo certificado de chave pública. Em algumas realizações, a CSR é assinada digitalmente pelo nó de consenso usando uma chave privada.
[056] Em (504), o nó de consenso envia a CSR para uma primeira CA.
[057] Em (506), o nó de consenso recebe um primeiro certificado de chave pública do nó de consenso a partir da primeira CA em resposta à CSR, e um primeiro um ou mais certificados de chave pública de um ou mais outros nós de consenso emitidos pelo primeira uma ou mais CAs. Em algumas realizações, pelo menos uma parte do primeiro um ou mais certificados de chave pública são auto-assinados por nós de consenso correspondentes, ou uma parte do segundo um ou mais certificados de chave pública são autoassinados por nós clientes correspondentes.
[058] Em (508), o nó de consenso envia a CSR para uma segunda CA. Em algumas realizações, pelo menos uma parte do primeiro um ou mais certificados de chave pública são auto-assinados por nós de consenso correspondentes, ou uma parte do segundo um ou mais certificados de chave pública são auto-assinados por nós clientes correspondentes.
[059] Em (510), o nó de consenso recebe um segundo certificado de chave pública do nó de consenso a partir do segundo CA em resposta à CSR, e um segundo um ou mais certificados de chave pública de um ou mais nós clientes emitidos por uma segunda uma ou mais CAs.
[060] Em (512), o nó de consenso configura um primeiro armazenamento confiável e um segundo armazenamento confiável. O primeiro armazenamento confiável inclui o primeiro certificado de chave pública e o
Petição 870190058524, de 25/06/2019, pág. 26/42
19/24 primeiro um ou mais certificados de chave pública do um ou mais outros nós de consenso. O segundo armazenamento confiável inclui o segundo certificado de chave pública e o segundo um ou mais certificados de chave pública do um ou mais nós clientes.
[061] Em algumas realizações, o nó de consenso pode gerar um certificado auto-assinado da chave pública usando uma chave privada correspondente do nó de consenso. O nó de consenso também pode configurar a chave privada do nó de consenso e o certificado auto-assinado.
[062] Em algumas realizações, o primeiro certificado de chave pública, o primeiro um ou mais certificados de chave pública, o segundo certificado de chave pública e o segundo um ou mais certificados de chave pública são certificados TLS.
[063] As realizações e as operações descrita neste relatório descritivo podem ser implementadas em circuitos eletrônicos digitais, ou em software de computador, firmware ou hardware, incluindo as estruturas divulgadas neste relatório descritivo ou em combinações de uma ou mais delas. As operações podem ser implementadas como operações realizadas por um aparelho de processamento de dados em dados armazenados em um ou mais dispositivos de armazenamento legíveis por computador ou recebidos de outras fontes. Um aparelho de processamento de dados, computador ou dispositivo de computação (120) pode englobar aparelhos, dispositivos e máquinas para processamento de dados, incluindo, por exemplo, um processador programável, um computador, um sistema em um chip ou vários, ou combinações, dos precedentes. O aparelho pode incluir circuitos lógicos de propósito especial, por exemplo, uma unidade de processamento central (CPU), uma rede de portas programáveis em campo (FPGA) ou um circuito integrado de aplicação específica (ASIC). O aparelho também pode incluir código que cria um ambiente de execução para o programa de computador em
Petição 870190058524, de 25/06/2019, pág. 27/42
20/24 questão, por exemplo, código que constitui firmware de processador, uma pilha de protocolos, um sistema de gestão de banco de dados, um sistema operacional (por exemplo, um sistema operacional ou uma combinação de sistemas operacionais), um ambiente de tempo de execução entre plataformas, uma máquina virtual ou uma combinação de um ou mais deles. O aparelho e ambiente de execução podem realizar várias infraestruturas de modelos de computação diferentes, tais como serviços da Web, computação distribuída e infraestruturas de computação em grade.
[064] Um programa de computador (também conhecido, por exemplo, como um programa, software, aplicativo de software, módulo de software, unidade de software, script ou código) pode ser escrito em qualquer forma de linguagem de programação, incluindo linguagens compiladas ou interpretadas, linguagens declarativas ou processuais, e pode ser implementado de qualquer forma, incluindo como um programa autônomo ou como um módulo, componente, sub-rotina, objeto ou outra unidade adequada para uso em um ambiente de computação. Um programa pode ser armazenado em uma parte de um arquivo que contém outros programas ou dados (por exemplo, um ou mais scripts armazenados em um documento de linguagem de marcação), em um único arquivo dedicado ao programa em questão ou em vários arquivos coordenados (por exemplo, arquivos que armazenam um ou mais módulos, subprogramas ou partes do código). Um programa de computador pode ser executado em um computador ou em vários computadores que estão localizados em um site ou distribuídos em vários sites e interconectados por uma rede de comunicação.
[065] Os processadores para execução de um programa de computador incluem, a título de exemplo, microprocessadores de propósito geral e especial, e qualquer um ou mais processadores de qualquer tipo de computador digital. Geralmente, um processador receberá instruções e dados
Petição 870190058524, de 25/06/2019, pág. 28/42
21/24 de uma memória apenas para leitura ou de uma memória de acesso aleatório ou de ambas. Os elementos essenciais de um computador são um processador para executar ações de acordo com as instruções e um ou mais dispositivos de memória para armazenar instruções e dados. Geralmente, um computador também incluirá, ou estará acoplado operacionalmente para receber dados de ou transferir dados para, ou ambos, um ou mais dispositivos de armazenamento em massa para armazenamento de dados. Um computador pode ser incorporado em outro dispositivo, por exemplo, um dispositivo móvel, um assistente digital pessoal (PDA), um console de jogos, um receptor de Sistema de Posicionamento Global (GPS) ou um dispositivo de armazenamento portátil. Dispositivos adequados para armazenar instruções e dados de programas de computador incluem memória não volátil, mídia e dispositivos de memória, incluindo, a título de exemplo, dispositivos de memória semicondutores, discos magnéticos e discos magneto-ópticos. O processador e a memória podem ser complementados por, ou incorporados em circuitos lógicos de propósito especial.
[066] Os dispositivos móveis podem incluir micro-telefones, equipamentos de usuário (UE), telefones celulares (por exemplo, telefones inteligentes), tablets, dispositivos usáveis (por exemplo, relógios inteligentes e óculos inteligentes), dispositivos implantados dentro do corpo humano (por exemplo, biossensores, implantes cocleares) ou outros tipos de dispositivos móveis. Os dispositivos móveis podem se comunicar sem fio (por exemplo, usando sinais de radiofrequência (RF)) a várias redes de comunicação (descritas abaixo). Os dispositivos móveis podem incluir sensores para determinar características do ambiente atual do dispositivo móvel. Os sensores podem incluir câmeras, microfones, sensores de proximidade, sensores GPS, sensores de movimento, acelerômetros, sensores de luz ambiente, sensores de umidade, giroscópios, bússolas, barômetros, sensores de impressões
Petição 870190058524, de 25/06/2019, pág. 29/42
22/24 digitais, sistemas de reconhecimento facial, sensores de RF (por exemplo, WiFi e rádio celulares), sensores térmicos ou outros tipos de sensores. Por exemplo, as câmeras podem incluir uma câmera voltada para frente ou para trás com lentes móveis ou fixas, um flash, um sensor de imagem e um processador de imagem. A câmera pode ser uma câmera megapixel capaz de capturar detalhes para reconhecimento facial e/ou de íris. A câmera, juntamente com um processador de dados e informações de autenticação armazenadas na memória ou acessadas remotamente, podem formar um sistema de reconhecimento facial. O sistema de reconhecimento facial ou um ou mais sensores, por exemplo, microfones, sensores de movimento, acelerômetros, sensores de GPS ou sensores de RF, podem ser usados para autenticação do usuário.
[067] Para proporcionar a interação com um usuário, formas de realização podem ser implementadas em um computador com um dispositivo de exibição e um dispositivo de entrada, por exemplo, um monitor de cristal líquido (LCD) ou monitor de diodo orgânico emissor de luz (OLED) / realidade virtual (VR) / realidade aumentada (AR) para exibir informações para o usuário e uma tela sensível ao toque, teclado e um dispositivo indicador pelo qual o usuário pode fornecer entrada de dados ao computador. Outros tipos de dispositivos também podem ser usados para fornecer interação com um usuário; por exemplo, a retroinformação fornecida ao usuário pode ser qualquer forma de retroinformação sensorial, por exemplo, retroinformação visual, retroinformação auditiva ou retroinformação tátil; e a entrada de dados do usuário pode ser recebida de qualquer forma, incluindo entrada de dados acústica, de fala ou tátil. Além disso, um computador pode interagir com um usuário enviando documentos para e recebendo documentos de um dispositivo que é usado pelo usuário; por exemplo, enviando páginas da web para um
Petição 870190058524, de 25/06/2019, pág. 30/42
23/24 navegador da web em um dispositivo cliente de um usuário em resposta a solicitações recebidas do navegador da web.
[068] As formas de realização podem ser implementadas usando dispositivos de computação interconectados por qualquer forma ou meio de comunicação de dados digitais com fio ou sem fio (ou combinação dos mesmos), por exemplo, uma rede de comunicação. Exemplos de dispositivos interconectados são um cliente e um servidor geralmente remotos entre si que normalmente interagem através de uma rede de comunicação. Um cliente, por exemplo, um dispositivo móvel, pode realizar transações em si, com um servidor ou através de um servidor, por exemplo, realizando transações de compra, venda, pagamento, entrega, envio ou empréstimo, ou autorizando as mesmas. Tais transações podem ser em tempo real, de modo que uma ação e uma resposta estejam temporariamente próximas; por exemplo, um indivíduo percebe a ação e a resposta ocorrendo substancialmente simultaneamente, a diferença de tempo para uma resposta após a ação do indivíduo é menor que 1 milissegundo (ms) ou menor que 1 segundo (s), ou a resposta é sem atraso intencional, considerando as limitações de processamento do sistema.
[069] Exemplos de redes de comunicação incluem uma rede de área local (LAN), uma rede de acesso via rádio (RAN), uma rede de área metropolitana (MAN) e uma rede de longa distância (WAN). A rede de comunicação pode incluir todo ou parte da Internet, outra rede de comunicação ou uma combinação de redes de comunicação. As informações podem ser transmitidas na rede de comunicação de acordo com vários protocolos e padrões, incluindo Evolução de Longo Prazo (LTE), 5G, IEEE 802, Protocolo Internet (IP) ou outros protocolos ou combinações de protocolos. A rede de comunicação pode transmitir dados de voz, vídeo, biométricos ou de autenticação ou outras informações entre os dispositivos de computação conectados.
Petição 870190058524, de 25/06/2019, pág. 31/42
24/24 [070] As características descritas como realizações separadas podem ser implementadas, em combinação, em uma única realização, enquanto as características descritas como uma realização única podem ser implementadas em várias realizações, separadamente ou em qualquer subcombinação adequada. As operações descritas e reivindicadas em uma ordem específica não devem ser entendidas como exigindo que a ordem específica, nem que todas as operações ilustradas sejam executadas (algumas operações podem ser opcionais). Conforme apropriado, a multitarefa ou o processamento paralelo (ou uma combinação de multitarefa e processamento paralelo) podem ser executados.

Claims (9)

  1. Reivindicações
    1. MÉTODO IMPLEMENTADO POR COMPUTADOR (500) para isolar as comunicações entre os nós de consenso (302a) e as comunicações entre os nós de consenso (302a) e os nós clientes (302b), caracterizado pelo fato de que compreende as etapas de:
    gerar (502), por um nó de consenso (302a), uma solicitação de assinatura de certificado (CSR);
    enviar (504) a CSR para uma primeira autoridade de certificação (CA);
    receber (506) um primeiro certificado de chave pública do nó de consenso (302a) a partir da primeira CA em resposta à CSR, e um primeiro ou mais certificados de chave pública de um ou mais outros nós de consenso (302a) emitidos por uma primeira uma ou mais CAs;
    enviar (508) a CSR para uma segunda CA;
    receber (510) um segundo certificado de chave pública do nó de consenso (302a) a partir da segunda CA em resposta à CSR, e um segundo um ou mais certificados de chave pública de um ou mais nós clientes (302b) emitidos por uma segunda uma ou mais CAs; e configurar (512), no nó de consenso (302a), um primeiro armazenamento confiável, incluindo o primeiro certificado de chave pública e o primeiro um ou mais certificados de chave pública do um ou mais outros nós de consenso (302a) e um segundo armazenamento confiável, incluindo o segundo certificado de chave pública e o segundo um ou mais certificados de chave pública do um ou mais nós clientes (302b).
  2. 2. MÉTODO IMPLEMENTADO POR COMPUTADOR (500), de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda as etapas de:
    determinar a primeira uma ou mais CAs e a segunda uma ou mais
    Petição 870190058524, de 25/06/2019, pág. 33/42
    2/3
    CAs;
    receber certificados raiz da primeira uma ou mais CAs e da segunda uma ou mais CAs; e verificar os certificados raiz com base nas chaves públicas correspondentes da primeira uma ou mais CAs e da segunda uma ou mais CAs.
  3. 3. MÉTODO IMPLEMENTADO POR COMPUTADOR (500), de acordo com a reivindicação 1, caracterizado pelo fato de que a CSR inclui a chave pública e informação a ser incluída no primeiro certificado de chave pública ou no segundo certificado de chave pública.
  4. 4. MÉTODO IMPLEMENTADO POR COMPUTADOR (500), de acordo com a reivindicação 2, caracterizado pelo fato de que a CSR é assinada digitalmente pelo nó de consenso (302a) utilizando uma chave privada.
  5. 5. MÉTODO IMPLEMENTADO POR COMPUTADOR (500), de acordo com a reivindicação 1, caracterizado pelo fato de que pelo menos uma parte do primeiro um ou mais certificados de chave pública são autoassinados por nós de consenso (302a) correspondentes, ou uma parte do segundo um ou mais certificados de chave pública são auto-assinados por nós clientes correspondentes.
  6. 6. MÉTODO IMPLEMENTADO POR COMPUTADOR (500), de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda as etapas de:
    gerar um certificado auto-assinado da chave pública usando uma chave privada correspondente do nó de consenso (302a); e configurar, no nó de consenso (302a), a chave privada do nó de consenso (302a) e o certificado auto-assinado.
  7. 7. MÉTODO IMPLEMENTADO POR COMPUTADOR (500),
    Petição 870190058524, de 25/06/2019, pág. 34/42
    3/3 de acordo com a reivindicação 1, caracterizado pelo fato de que o primeiro certificado de chave pública, o primeiro um ou mais certificados de chave pública, o segundo certificado de chave pública e o segundo um ou mais certificados de chave pública são certificados de segurança de camada de transporte (TLS).
  8. 8. MEIO LEGÍVEL POR COMPUTADOR, caracterizado pelo fato de que é acoplado a um ou mais processadores e possuindo instruções armazenadas nele que, quando executadas pelo um ou mais processadores, fazem com que o um ou mais processadores executem operações de acordo com o método, conforme definido em qualquer uma das reivindicações 1 a 7.
  9. 9. SISTEMA PARA A REALIZAR UM MÉTODO, caracterizado pelo fato de que compreende:
    um dispositivo de computação (120); e um dispositivo de armazenamento legível por computador acoplado ao dispositivo de computação (120) e possuindo instruções armazenadas nele que, quando executadas pelo dispositivo de computação (120), fazem com que o dispositivo de computação (120) execute operações de acordo com o método, conforme definido em qualquer uma das reivindicações 1 a 7.
BR112019008174A 2018-11-07 2018-11-07 método implementado por computador, meio de armazenamento legível por computador, não transitório e sistema BR112019008174A2 (pt)

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
BR112019008174A2 true BR112019008174A2 (pt) 2019-09-10

Family

ID=66100011

Family Applications (1)

Application Number Title Priority Date Filing Date
BR112019008174A BR112019008174A2 (pt) 2018-11-07 2018-11-07 método implementado por computador, meio de armazenamento legível por computador, não transitório e sistema

Country Status (16)

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

Families Citing this family (9)

* 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
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
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 苏州区盟链数字科技有限公司 一种优化区块链可信节点与共识算法的装置
CN112560005A (zh) * 2020-12-01 2021-03-26 杭州趣链科技有限公司 身份可信服务系统、方法、电子设备和计算机可读介质
KR20230020262A (ko) * 2021-08-03 2023-02-10 삼성전자주식회사 디지털 컨텐츠에 대한 대체불가능 토큰을 관리하는 방법 및 장치

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 株式会社日立製作所 公開鍵証明書の生成システム及び検証システム
DE60220959T2 (de) 2002-09-17 2008-02-28 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
JP6299047B2 (ja) 2014-05-08 2018-03-28 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． 証明取得方法及び装置
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 阿里巴巴集团控股有限公司 一种共识验证的方法及装置
CN107592292B (zh) * 2017-07-26 2019-08-09 阿里巴巴集团控股有限公司 一种区块链节点间通信方法及装置
CN107592293A (zh) 2017-07-26 2018-01-16 阿里巴巴集团控股有限公司 区块链节点间通讯方法、数字证书管理方法、装置和电子设备
CN107566337B (zh) 2017-07-26 2019-08-09 阿里巴巴集团控股有限公司 一种区块链节点间的通信方法及装置

Also Published As

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

Similar Documents

Publication Publication Date Title
BR112019008174A2 (pt) método implementado por computador, meio de armazenamento legível por computador, não transitório e sistema
ES2872101T3 (es) Gestión de claves distribuidas para entornos de ejecución confiables
TWI695613B (zh) 使用同態加密的區塊鏈資料保護
TWI725793B (zh) 用於將分散識別符映射到真實世界實體的系統及方法
BR112019008151A2 (pt) método implementado por computador, meio de armazenamento legível por computador não transitório e sistema
BR112019008140A2 (pt) método implementado por computador, meio de armazenamento legível por computador não transitório e sistema
WO2019127278A1 (zh) 安全访问区块链的方法、装置、系统、存储介质及电子设备
ES2299506T3 (es) Metodo y aparato para modelo de servicio de aplicacion basada en web para gestion de la seguridad.
US8687805B2 (en) Context-aware based cryptography
CN111213350A (zh) 用于创建去中心化标识的系统和方法
CN111213147A (zh) 用于基于区块链的交叉实体认证的系统和方法
BR112019016474A2 (pt) método implementado por computador, meio de armazenamento não transitório legível por computador e sistema
BR112019008160A2 (pt) método implementado por computador executado por um nó de consenso de uma rede de cadeia de blocos, meio de armazenamento legível por computador não transitório e sistema
BR112019008171A2 (pt) método implementado por computador para validar as transações blockchain com base em modelos de conta, meio de armazenamento legível por computador e sistema
CN117561508A (zh) 可验证凭证的跨会话颁发
Prakasha et al. Automated user authentication in wireless public key infrastructure for mobile devices using Aadhar card
WO2019179240A1 (zh) 一种建立安全基础设施的方法、终端及装置
Banerjee et al. Token-Based Authentication Techniques on Open Source Cloud Platforms
Masud Kerberos-based authentication for OpenStack cloud infrastructure as a service
Kathrine et al. Efficient Biometric Template based Authentication Scheme for Grid Environment
Wahid et al. Verifiable Response in Heterogeneous Cloud Storage: An Efficient KDC Scheme
Kumar et al. An Authentication Scheme Based On Multiple Trusted Third Party

Legal Events

Date Code Title Description
B25A Requested transfer of rights approved

Owner name: ADVANTAGEOUS NEW TECHNOLOGIES CO., LTD. (KY)

B25A Requested transfer of rights approved

Owner name: ADVANCED NEW TECHNOLOGIES CO., LTD. (KY)

B350 Update of information on the portal [chapter 15.35 patent gazette]
B08F Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette]

Free format text: REFERENTE A 5A ANUIDADE.

B08K Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette]

Free format text: EM VIRTUDE DO ARQUIVAMENTO PUBLICADO NA RPI 2747 DE 29-08-2023 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDO O ARQUIVAMENTO DO PEDIDO DE PATENTE, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013.