Não é segredo que uma das ferramentas auxiliares comumente utilizadas, sem as quais a proteção de dados em redes abertas é impossível, é a tecnologia de certificados digitais. Porém, não é segredo que a principal desvantagem da tecnologia é a confiança incondicional nos centros emissores de certificados digitais. O Diretor de Tecnologia e Inovação da ENCRY Andrey Chmora propôs uma nova abordagem para organizar infraestrutura de chave pública (Infraestrutura de chave pública, PKI), que ajudará a eliminar as deficiências atuais e que utiliza tecnologia de contabilidade distribuída (blockchain). Mas primeiro as primeiras coisas.
Se você estiver familiarizado com o funcionamento de sua infraestrutura de chave pública atual e conhecer suas principais deficiências, poderá pular para o que propomos alterar abaixo.
O que são assinaturas e certificados digitais?A interação na Internet sempre envolve a transferência de dados. Todos temos interesse em garantir que os dados sejam transmitidos de forma segura. Mas o que é segurança? Os serviços de segurança mais procurados são confidencialidade, integridade e autenticidade. Para tanto, são utilizados atualmente métodos de criptografia assimétrica, ou criptografia com chave pública.
Comecemos com o fato de que para utilizar esses métodos, os sujeitos da interação devem ter duas chaves individuais emparelhadas - pública e secreta. Com a ajuda deles, são fornecidos os serviços de segurança mencionados acima.
Como é alcançada a confidencialidade da transferência de informações? Antes de enviar os dados, o assinante remetente criptografa (transforma criptograficamente) os dados abertos usando a chave pública do destinatário, e o destinatário descriptografa o texto cifrado recebido usando a chave secreta emparelhada.
Como é alcançada a integridade e autenticidade das informações transmitidas? Para resolver este problema, foi criado outro mecanismo. Os dados abertos não são criptografados, mas o resultado da aplicação da função hash criptográfica - uma imagem “comprimida” da sequência de dados de entrada - é transmitido de forma criptografada. O resultado desse hashing é chamado de “resumo” e é criptografado usando a chave secreta do assinante remetente (“a testemunha”). Como resultado da criptografia do resumo, é obtida uma assinatura digital. Ele, juntamente com o texto não criptografado, é transmitido ao assinante destinatário (“verificador”). Ele descriptografa a assinatura digital na chave pública da testemunha e a compara com o resultado da aplicação de uma função hash criptográfica, que o verificador calcula de forma independente com base nos dados abertos recebidos. Se corresponderem, isso indica que os dados foram transmitidos de forma autêntica e completa pelo assinante remetente e não modificados por um invasor.
A maioria dos recursos que trabalham com dados pessoais e informações de pagamento (bancos, seguradoras, companhias aéreas, sistemas de pagamento, bem como portais governamentais, como o serviço fiscal) utilizam ativamente métodos de criptografia assimétrica.
O que um certificado digital tem a ver com isso? É simples. Tanto o primeiro como o segundo processos envolvem chaves públicas e, como desempenham um papel central, é muito importante garantir que as chaves realmente pertencem ao remetente (a testemunha, no caso da verificação de assinatura) ou ao destinatário, e não são substituído pelas chaves dos invasores. É por isso que existem certificados digitais para garantir a autenticidade e integridade da chave pública.
Observação: a autenticidade e integridade da chave pública são confirmadas exatamente da mesma forma que a autenticidade e integridade dos dados públicos, ou seja, por meio de assinatura digital eletrônica (EDS).
De onde vêm os certificados digitais?Autoridades de certificação confiáveis, ou Autoridades de Certificação (CAs), são responsáveis pela emissão e manutenção de certificados digitais. O requerente solicita a emissão de um certificado à AC, passa pela identificação no Centro de Registo (CR) e recebe um certificado da AC. A CA garante que a chave pública do certificado pertence exatamente à entidade para a qual foi emitido.
Se você não confirmar a autenticidade da chave pública, um invasor durante a transferência/armazenamento dessa chave poderá substituí-la pela sua própria. Se a substituição ocorrer, o invasor poderá descriptografar tudo o que o assinante remetente transmite ao assinante receptor ou alterar os dados abertos a seu critério.
Os certificados digitais são usados sempre que a criptografia assimétrica estiver disponível. Um dos certificados digitais mais comuns são os certificados SSL para comunicação segura através do protocolo HTTPS. Centenas de empresas registradas em diversas jurisdições estão envolvidas na emissão de certificados SSL. A maior parte recai sobre cinco a dez grandes centros confiáveis: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
CA e CR são componentes da PKI, que também inclui:
- Diretório aberto – um banco de dados público que fornece armazenamento seguro de certificados digitais.
- Lista de certificados revogados – um banco de dados público que fornece armazenamento seguro de certificados digitais de chaves públicas revogadas (por exemplo, devido ao comprometimento de uma chave privada emparelhada). Os sujeitos da infraestrutura podem acessar esse banco de dados de forma independente ou podem usar o Online Certification Status Protocol (OCSP) especializado, que simplifica o processo de verificação.
- Usuários de certificado – sujeitos de PKI atendidos que celebraram um contrato de usuário com a CA e verificam a assinatura digital e/ou criptografam dados com base na chave pública do certificado.
- seguidores – assuntos de PKI atendidos que possuem uma chave secreta emparelhada com a chave pública do certificado e que firmaram um contrato de assinante com a CA. O assinante pode ser simultaneamente usuário do certificado.
Assim, as entidades confiáveis da infraestrutura de chave pública, que incluem CAs, CRs e diretórios abertos, são responsáveis por:
1. Verificação da autenticidade da identidade do requerente.
2. Perfil do certificado de chave pública.
3. Emissão de um certificado de chave pública para um requerente cuja identidade tenha sido confirmada de forma confiável.
4. Altere o status do certificado de chave pública.
5. Fornecimento de informações sobre o status atual do certificado de chave pública.
Desvantagens da PKI, quais são elas?A falha fundamental da PKI é a presença de entidades confiáveis.
Os usuários devem confiar incondicionalmente na CA e na CR. Mas, como mostra a prática, a confiança incondicional acarreta sérias consequências.
Nos últimos dez anos, registaram-se vários escândalos importantes nesta área relacionados com a vulnerabilidade das infra-estruturas.
— em 2010, o malware Stuxnet começou a se espalhar online, assinado usando certificados digitais roubados da RealTek e JMicron.
- Em 2017, o Google acusou a Symantec de emitir um grande número de certificados falsificados. Naquela época, a Symantec era uma das maiores CAs em termos de volumes de produção. No navegador Google Chrome 70, o suporte para certificados emitidos por esta empresa e seus centros afiliados GeoTrust e Thawte foi interrompido antes de 1º de dezembro de 2017.
As CAs foram comprometidas e, como resultado, todos sofreram — as próprias CAs, bem como os usuários e assinantes. A confiança nas infra-estruturas foi minada. Além disso, os certificados digitais podem ser bloqueados no contexto de conflitos políticos, o que também afetará o funcionamento de muitos recursos. Era exatamente isso que se temia há vários anos na administração presidencial russa, onde em 2016 discutiram a possibilidade de criar um centro de certificação estadual que emitiria certificados SSL para sites no RuNet. A situação atual é tal que até mesmo os portais estatais na Rússia certificados digitais emitidos pelas empresas americanas Comodo ou Thawte (subsidiária da Symantec).
Há outro problema - a questão autenticação primária (autenticação) de usuários. Como identificar um usuário que entrou em contato com a CA com solicitação de emissão de certificado digital sem contato pessoal direto? Agora isso é resolvido situacionalmente, dependendo das capacidades da infraestrutura. Algo é retirado dos registos abertos (por exemplo, informações sobre pessoas colectivas que solicitam certificados); nos casos em que os requerentes são pessoas singulares, podem ser utilizadas agências bancárias ou correios, onde a sua identidade é confirmada através de documentos de identificação, por exemplo, um passaporte.
O problema da falsificação de credenciais para fins de falsificação de identidade é fundamental. Notemos que não existe uma solução completa para este problema por razões teóricas da informação: sem ter informações confiáveis a priori, é impossível confirmar ou negar a autenticidade de um determinado assunto. Em regra, para verificação é necessária a apresentação de um conjunto de documentos que comprovem a identidade do requerente. Existem muitos métodos de verificação diferentes, mas nenhum deles oferece garantia total da autenticidade dos documentos. Por conseguinte, a autenticidade da identidade do requerente também não pode ser garantida.
Como essas deficiências podem ser eliminadas?Se os problemas da PKI no seu estado actual podem ser explicados pela centralização, então é lógico supor que a descentralização ajudaria a eliminar parcialmente as deficiências identificadas.
A descentralização não implica a presença de entidades confiáveis - se você criar infraestrutura descentralizada de chave pública (Infraestrutura descentralizada de chave pública, DPKI), então nem CA nem CR serão necessários. Vamos abandonar o conceito de certificado digital e usar um registro distribuído para armazenar informações sobre chaves públicas. No nosso caso, chamamos de registro um banco de dados linear que consiste em registros individuais (blocos) vinculados por meio da tecnologia blockchain. Em vez de certificado digital, introduziremos o conceito de “notificação”.
Como será o processo de recebimento, verificação e cancelamento de notificações no DPKI proposto:
1. Cada requerente apresenta um pedido de notificação de forma autónoma, através do preenchimento de um formulário durante o registo, após o qual cria uma transação que fica armazenada num pool especializado.
2. A informação sobre a chave pública, juntamente com os dados do titular e outros metadados, é armazenada num registo distribuído, e não num certificado digital, cuja emissão numa PKI centralizada é da responsabilidade da AC.
3. A verificação da autenticidade da identidade do requerente é realizada posteriormente pelos esforços conjuntos da comunidade de utilizadores do DPKI, e não pelo CR.
4. Somente o proprietário de tal notificação pode alterar o status de uma chave pública.
5. Qualquer pessoa pode acessar o livro-razão distribuído e verificar o status atual da chave pública.
Nota: A verificação comunitária da identidade de um requerente pode parecer pouco fiável à primeira vista. Mas devemos lembrar que hoje em dia todos os utilizadores de serviços digitais deixam inevitavelmente uma pegada digital, e este processo só continuará a ganhar impulso. Cadastros eletrônicos abertos de pessoas jurídicas, mapas, digitalização de imagens de terreno, redes sociais - todas essas são ferramentas disponíveis ao público. Eles já são usados com sucesso durante investigações tanto por jornalistas quanto por agências de aplicação da lei. Por exemplo, basta recordar as investigações do Bellingcat ou da equipa de investigação conjunta JIT, que estuda as circunstâncias da queda do Boeing da Malásia.
Então, como funcionaria na prática uma infra-estrutura descentralizada de chaves públicas? Detenhamo-nos na descrição da própria tecnologia, que patenteado em 2018 e nós legitimamente consideramos isso nosso know-how.
Imagine que existe algum proprietário que possui muitas chaves públicas, onde cada chave é uma determinada transação que fica armazenada no registro. Na ausência de uma CA, como você pode entender que todas as chaves pertencem a esse proprietário específico? Para resolver este problema, é criada uma transação zero, que contém informações sobre o proprietário e sua carteira (da qual é debitada a comissão pela colocação da transação no registro). A transação nula é uma espécie de “âncora” à qual serão anexadas as seguintes transações com dados sobre chaves públicas. Cada transação contém uma estrutura de dados especializada, ou em outras palavras, uma notificação.
A notificação é um conjunto estruturado de dados constituído por campos funcionais e que inclui informação sobre a chave pública do titular, cuja persistência é garantida pela colocação num dos registos associados do registo distribuído.
A próxima questão lógica é como é formada uma transação zero? A transação nula – como as subsequentes – é uma agregação de seis campos de dados. Durante a formação de uma transação zero, o par de chaves da carteira (chaves públicas e secretas emparelhadas) está envolvido. Este par de chaves surge no momento em que o usuário cadastra sua carteira, da qual será debitada a comissão pela colocação de uma transação zero no cadastro e, posteriormente, pelas operações com notificações.
Conforme mostrado na figura, um resumo da chave pública da carteira é gerado pela aplicação sequencial das funções hash SHA256 e RIPEMD160. Aqui o RIPEMD160 é responsável pela representação compacta dos dados, cuja largura não excede 160 bits. Isto é importante porque o registro não é um banco de dados barato. A própria chave pública é inserida no quinto campo. O primeiro campo contém dados que estabelecem uma conexão com a transação anterior. Para uma transação zero, este campo não contém nada, o que o distingue das transações subsequentes. O segundo campo contém dados para verificar a conectividade das transações. Para resumir, chamaremos os dados do primeiro e segundo campos de “link” e “check”, respectivamente. O conteúdo desses campos é gerado por hashing iterativo, conforme demonstrado pela ligação da segunda e terceira transações na figura abaixo.
Os dados dos primeiros cinco campos são certificados por uma assinatura digital eletrônica, que é gerada a partir da chave secreta da carteira.
É isso, a transação nula é enviada para o pool e após verificação bem-sucedida é inserida no registro. Agora você pode “vincular” as seguintes transações a ele. Vamos considerar como as transações diferentes de zero são formadas.
A primeira coisa que provavelmente chamou sua atenção é a abundância de pares de chaves. Além do já familiar par de chaves de carteira, são usados pares de chaves comuns e de serviço.
Uma chave pública comum é a razão pela qual tudo começou. Esta chave está envolvida em vários procedimentos e processos que se desenrolam no mundo exterior (transações bancárias e outras, fluxo de documentos, etc.). Por exemplo, uma chave secreta de um par comum pode ser usada para gerar assinaturas digitais para vários documentos - ordens de pagamento, etc., e uma chave pública pode ser usada para verificar esta assinatura digital com a posterior execução destas instruções, desde que seja é válido.
O par de serviços é emitido para o sujeito DPKI registrado. O nome deste par corresponde à sua finalidade. Observe que ao formar/verificar uma transação zero, as chaves de serviço não são utilizadas.
Vamos esclarecer novamente o propósito das chaves:
- As chaves da carteira são usadas para gerar/verificar uma transação nula e qualquer outra transação não nula. A chave privada de uma carteira é conhecida apenas pelo proprietário da carteira, que também é proprietário de muitas chaves públicas comuns.
- Uma chave pública comum tem finalidade semelhante a uma chave pública para a qual um certificado é emitido em uma PKI centralizada.
- O par de chaves de serviço pertence ao DPKI. A chave secreta é emitida para entidades registradas e é usada na geração de assinaturas digitais para transações (exceto para transações zero). Público é usado para verificar a assinatura digital eletrônica de uma transação antes de ser lançada no registro.
Assim, existem dois grupos de chaves. O primeiro inclui chaves de serviço e chaves de carteira – elas só fazem sentido no contexto do DPKI. O segundo grupo inclui chaves comuns - seu escopo pode variar e é determinado pelas tarefas do aplicativo em que são usadas. Ao mesmo tempo, o DPKI garante a integridade e autenticidade das chaves públicas comuns.
Nota: O par de chaves de serviço pode ser conhecido por diferentes entidades DPKI. Por exemplo, pode ser igual para todos. É por esta razão que ao gerar a assinatura de cada transação diferente de zero, são utilizadas duas chaves secretas, uma das quais é a chave da carteira - ela é conhecida apenas pelo dono da carteira, que também é dono de muitas chaves comuns. chaves públicas. Todas as chaves têm seu próprio significado. Por exemplo, sempre é possível comprovar que a transação foi registrada no cadastro por um sujeito DPKI cadastrado, uma vez que a assinatura também foi gerada em uma chave de serviço secreto. E não pode haver abusos, como ataques DOS, porque o proprietário paga por cada transação.
Todas as transações que seguem o zero são formadas de maneira semelhante: a chave pública (não a carteira, como no caso da transação zero, mas a partir de um par de chaves comum) é executada por meio de duas funções hash SHA256 e RIPEMD160. É assim que os dados do terceiro campo são formados. O quarto campo contém informações de acompanhamento (por exemplo, informações sobre o status atual, datas de expiração, carimbo de data/hora, identificadores de algoritmos criptográficos usados, etc.). O quinto campo contém a chave pública do par de chaves de serviço. Com a sua ajuda, a assinatura digital será então verificada e replicada. Justifiquemos a necessidade de tal abordagem.
Lembre-se de que uma transação é inserida em um pool e armazenada lá até ser processada. O armazenamento em um pool está associado a um certo risco - os dados da transação podem ser falsificados. O proprietário certifica os dados da transação com uma assinatura digital eletrônica. A chave pública para verificação desta assinatura digital é indicada explicitamente em um dos campos da transação e posteriormente inserida no registro. As peculiaridades do processamento de transações são tais que um invasor pode alterar os dados a seu critério e depois verificá-los usando sua chave secreta, além de indicar uma chave pública emparelhada para verificar a assinatura digital na transação. Se a autenticidade e a integridade forem garantidas exclusivamente por meio de assinatura digital, tal falsificação passará despercebida. Porém, se, além da assinatura digital, existir um mecanismo adicional que garanta tanto o arquivamento quanto a persistência da informação armazenada, a falsificação poderá ser detectada. Para isso, basta inserir no registro a chave pública genuína do proprietário. Vamos explicar como isso funciona.
Deixe o invasor falsificar os dados da transação. Do ponto de vista de chaves e assinaturas digitais, são possíveis as seguintes opções:
1. O invasor coloca sua chave pública na transação enquanto a assinatura digital do proprietário permanece inalterada.
2. O invasor cria uma assinatura digital em sua chave privada, mas deixa a chave pública do proprietário inalterada.
3. O invasor cria uma assinatura digital em sua chave privada e coloca uma chave pública emparelhada na transação.
Obviamente, as opções 1 e 2 não têm sentido, pois sempre serão detectadas durante a verificação da assinatura digital. Apenas a opção 3 faz sentido, e se um invasor criar uma assinatura digital em sua própria chave secreta, ele será forçado a salvar uma chave pública emparelhada na transação, diferente da chave pública do proprietário. Esta é a única maneira de um invasor impor dados falsificados.
Suponhamos que o proprietário possua um par fixo de chaves – privada e pública. Deixe os dados serem certificados por assinatura digital utilizando a chave secreta deste par, e a chave pública é indicada na transação. Suponhamos também que esta chave pública tenha sido previamente inserida no registro e sua autenticidade tenha sido verificada de forma confiável. Então uma falsificação será indicada pelo fato de a chave pública da transação não corresponder à chave pública do registro.
Para resumir. Ao processar os primeiros dados de transação do proprietário, é necessário verificar a autenticidade da chave pública inserida no registro. Para isso, leia a chave do registro e compare-a com a verdadeira chave pública do proprietário dentro do perímetro de segurança (área de relativa invulnerabilidade). Se a autenticidade da chave for confirmada e a sua persistência for garantida no momento da colocação, então a autenticidade da chave da transação subsequente pode ser facilmente confirmada/refutada comparando-a com a chave do registo. Em outras palavras, a chave do registro é usada como amostra de referência. Todas as outras transações do proprietário são processadas de forma semelhante.
A transação é certificada por uma assinatura digital eletrônica - é aqui que são necessárias chaves secretas, e não uma, mas duas ao mesmo tempo - uma chave de serviço e uma chave de carteira. Graças ao uso de duas chaves secretas, o nível de segurança necessário é garantido - afinal, a chave secreta do serviço pode ser conhecida por outros usuários, enquanto a chave secreta da carteira é conhecida apenas pelo proprietário do par de chaves comum. Chamamos essa assinatura de duas teclas de assinatura digital “consolidada”.
A verificação de transações não nulas é realizada por meio de duas chaves públicas: a carteira e a chave de serviço. O processo de verificação pode ser dividido em duas etapas principais: a primeira é a verificação do resumo da chave pública da carteira, e a segunda é a verificação da assinatura digital eletrônica da transação, a mesma consolidada que foi formada por meio de duas chaves secretas ( carteira e serviço). Se a validade da assinatura digital for confirmada, após verificação adicional a transação será registrada no registro.
Pode surgir uma questão lógica: como verificar se uma transação pertence a uma cadeia específica com a “raiz” na forma de uma transação zero? Para tanto, o processo de verificação é complementado com mais uma etapa – verificação de conectividade. É aqui que precisaremos dos dados dos dois primeiros campos, que até agora ignoramos.
Vamos imaginar que precisamos verificar se a transação nº 3 realmente vem depois da transação nº 2. Para fazer isso, usando o método de hash combinado, o valor da função hash é calculado para os dados do terceiro, quarto e quinto campos da transação nº 2. Em seguida, é realizada a concatenação dos dados do primeiro campo da transação nº 3 e do valor combinado da função hash obtido anteriormente para os dados do terceiro, quarto e quinto campos da transação nº 2. Tudo isso também é executado por meio de duas funções hash SHA256 e RIPEMD160. Se o valor recebido corresponder aos dados do segundo campo da transação nº 2, a verificação será aprovada e a conexão será confirmada. Isto é mostrado mais claramente nas figuras abaixo.
Em termos gerais, a tecnologia para gerar e inserir uma notificação no cadastro é exatamente assim. Uma ilustração visual do processo de formação de uma cadeia de notificações é apresentada na figura a seguir:
Neste texto, não nos deteremos nos detalhes, que sem dúvida existem, e voltaremos a discutir a própria ideia de uma infraestrutura descentralizada de chaves públicas.
Assim, como o próprio requerente apresenta o pedido de registro de notificações, que ficam armazenadas não na base de dados da CA, mas no cadastro, devem ser considerados os principais componentes arquitetônicos do DPKI:
1. Cadastro de notificações válidas (RDN).
2. Cadastro de notificações revogadas (RON).
3. Cadastro de notificações suspensas (RPN).
As informações sobre chaves públicas são armazenadas em RDN/RON/RPN na forma de valores de função hash. É importante notar também que podem ser registros diferentes, ou cadeias diferentes, ou mesmo uma cadeia como parte de um único registro, quando informações sobre o status de uma chave pública comum (revogação, suspensão, etc.) são inseridas no quarto campo da estrutura de dados na forma do valor do código correspondente. Existem muitas opções diferentes para a implementação arquitetônica do DPKI, e a escolha de uma ou outra depende de vários fatores, por exemplo, critérios de otimização como o custo da memória de longo prazo para armazenamento de chaves públicas, etc.
Assim, o DPKI pode revelar-se, se não mais simples, pelo menos comparável a uma solução centralizada em termos de complexidade arquitetónica.
A questão principal permanece - Qual registro é adequado para implementar a tecnologia?
O principal requisito do registro é a capacidade de gerar transações de qualquer tipo. O exemplo mais famoso de livro-razão é a rede Bitcoin. Mas ao implementar a tecnologia descrita acima, surgem certas dificuldades: as limitações da linguagem de script existente, a falta de mecanismos necessários para processar conjuntos arbitrários de dados, métodos para gerar transações de tipo arbitrário e muito mais.
Nós da ENCRY tentámos resolver os problemas acima formulados e desenvolvemos um registo que, na nossa opinião, apresenta uma série de vantagens, nomeadamente:
- suporta vários tipos de transações: pode trocar ativos (ou seja, realizar transações financeiras) e criar transações com uma estrutura arbitrária,
- os desenvolvedores têm acesso à linguagem de programação proprietária PrismLang, que oferece a flexibilidade necessária na resolução de diversos problemas tecnológicos,
- é fornecido um mecanismo para processar conjuntos de dados arbitrários.
Se adotarmos uma abordagem simplificada, ocorre a seguinte sequência de ações:
- O requerente se cadastra no DPKI e recebe uma carteira digital. O endereço da carteira é o valor hash da chave pública da carteira. A chave privada da carteira é conhecida apenas pelo requerente.
- O sujeito registrado recebe acesso à chave secreta do serviço.
- O sujeito gera uma transação zero e a verifica com uma assinatura digital utilizando a chave secreta da carteira.
- Se for formada uma transação diferente de zero, ela é certificada por uma assinatura digital eletrônica por meio de duas chaves secretas: uma carteira e uma de serviço.
- O sujeito envia uma transação para o pool.
- O nó da rede ENCRY lê a transação do pool e verifica a assinatura digital, bem como a conectividade da transação.
- Se a assinatura digital for válida e a conexão for confirmada, ele prepara a transação para entrada no cadastro.
Aqui o registro atua como um banco de dados distribuído que armazena informações sobre notificações válidas, canceladas e suspensas.
É claro que a descentralização não é uma panaceia. O problema fundamental da autenticação primária do utilizador não desaparece em lado nenhum: se actualmente a verificação do requerente é efectuada pelo CR, então no DPKI propõe-se delegar a verificação aos membros da comunidade e utilizar a motivação financeira para estimular a actividade. A tecnologia de verificação de código aberto é bem conhecida. A eficácia dessa verificação foi confirmada na prática. Recordemos novamente uma série de investigações de alto nível realizadas pela publicação online Bellingcat.
Mas, em geral, surge a seguinte imagem: DPKI é uma oportunidade para corrigir, se não todas, pelo menos muitas das deficiências da PKI centralizada.
Assine nosso Habrablog, planejamos continuar a cobrir ativamente nossa pesquisa e desenvolvimento e seguir , se não quiser perder outras novidades sobre os projetos ENCRY.
Fonte: habr.com