DPKI: Abordando as desvantagens da PKI centralizada por meio de Blockchain

Os certificados digitais são uma das ferramentas auxiliares mais conhecidas que ajudam a proteger os dados nas redes públicas. No entanto, a principal desvantagem dessa tecnologia também é conhecida: os usuários são forçados a confiar implicitamente nas autoridades de certificação que emitem certificados digitais. Andrey Chmora, diretor de tecnologia e inovações da ENCRY, sugeriu uma nova abordagem para a construção de uma infra-estrutura de chave pública (PKI) para eliminar as desvantagens existentes usando a tecnologia de contabilidade distribuída (blockchain).
Vamos começar com o básico.

Se você já conhece o básico da infraestrutura de chave pública existente e suas principais desvantagens, fique à vontade para rolar para baixo até a descrição do que sugerimos alterar.





Então, como uma infraestrutura de chave pública descentralizada funcionará na prática? Vamos nos aprofundar na tecnologia que patenteamos em 2018 e considerar o nosso melhor know-how.

Suponha que exista um indivíduo que possua um conjunto de chaves públicas, em que cada chave seja um tipo de transação armazenada em um razão. Como verificar se todas essas chaves realmente pertencem a um determinado proprietário sem uma autoridade de certificação? Para resolver essa tarefa, podemos criar uma transação nula para armazenar as informações sobre o proprietário e sua carteira eletrônica (das quais é debitada uma taxa de comissão pela adição de uma transação ao razão). Uma transação nula é uma espécie de "âncora" para conectar as próximas transações junto com os dados sobre chaves públicas. Cada transação desse tipo contém uma estrutura de dados especializada chamada "notificação".

A notificação é um conjunto de dados estruturados de campos funcionais que armazena informações sobre a chave pública do proprietário e garante a persistência dessa chave, adicionando-a a um dos registros relacionados no razão distribuído.

A próxima pergunta óbvia é como formar uma transação nula? Uma transação nula, como todas as transações subseqüentes, é uma agregação de seis campos de dados. Para formar uma transação nula, usamos o par de chaves pública / privada para a carteira eletrônica. Esse par de chaves pública / privada é criado quando o usuário cria sua carteira a partir da qual será debitada a taxa de comissão pela adição de uma transação nula ao razão e pelas operações subseqüentes com notificações.


Figura 3. Criando uma transação nula

A Figura 3 mostra como um resumo da chave pública da carteira eletrônica é formado usando a função hash SHA256 e, em seguida, a função hash RIPEMD160. Aqui, o RIPEMD160 é responsável por representar dados com o tamanho de compilação de até 160 bits. É muito importante, pois os livros contábeis são bancos de dados caros. A própria chave pública está incluída no quinto campo. O primeiro campo contém dados que vinculam uma determinada transação à anterior. Na transação nula, diferentemente de todas as outras transações, esse campo está vazio. O segundo campo contém dados para verificação da conectividade da transação. Por uma questão de brevidade, nos referiremos aos dados no primeiro e no segundo campos como "vincular" e "verificação", respectivamente.


Figura 4. Ligação e verificação de transações

Os dados nesses campos podem ser formados usando o hash iterativo, como mostrado na Figura 4 acima, para vincular a segunda e a terceira transações.
Os dados nos cinco primeiros campos são autenticados com o DS gerado usando a chave privada da carteira eletrônica. E isso é tudo - a transação agora pode ser adicionada ao pool e, após uma verificação bem-sucedida (como mostra a Figura 5 ), ao razão.


Figura 5. Verificação da transação nula

Agora, essa transação pode ser usada para "conectar" as próximas transações. Vamos dar uma olhada na Figura 6 para ver como todas as transações não nulas são formadas.


Figura 6. Criando uma transação não nula

A primeira coisa que você pode notar é uma infinidade de pares de chaves públicas / privadas. Além do já familiar par de chaves público / privado de carteira eletrônica, também usamos pares de chaves comuns e de serviço.

Uma chave pública comum é a parte mais importante aqui. Essa chave é usada em vários procedimentos e processos do mundo circundante (como transações bancárias e outras, fluxo de documentos, etc.). Por exemplo, uma chave privada de um par de chaves pública / privada comum pode ser usada para a criação de um DS para vários documentos, como ordens de pagamento, enquanto a chave pública pode ser usada para a verificação do DS com a execução subseqüente destes. ordens.

Um par de chaves pública / privada de serviço é emitido para uma entidade DPKI registrada. O nome desse par de chaves pública / privada reflete claramente sua finalidade. Observe que as chaves de serviço não são usadas para geração / verificação de uma transação nula.

Só para esclarecer, vamos refinar os propósitos dessas chaves:

1. As chaves da carteira eletrônica são usadas para a geração e / ou verificação de transações nulas e não nulas. A chave privada da carteira eletrônica é conhecida apenas pelo proprietário da carteira eletrônica, que também possui o conjunto de chaves públicas comuns.
2. O objetivo de uma chave pública comum é o mesmo da chave pública para a qual um certificado na PKI centralizada é emitido.
3. O par de chaves pública / privada de serviço pertence à DPKI. Uma chave privada é emitida para as entidades registradas e é usada para criar um DS de todas as transações não nulas. Uma chave pública é usada para a verificação de um DS para transações antes de adicioná-las ao razão.

Assim, temos dois grupos de chaves. O primeiro grupo inclui chaves de serviço e chaves de carteira eletrônica que são elegíveis apenas na DPKI. O segundo grupo inclui chaves comuns que podem ser usadas para vários propósitos, dependendo de um determinado campo de aplicação. Ao mesmo tempo, o DPKI garante a integridade e autenticidade das chaves públicas comuns.

Nota: O par de chaves pública / privada de serviço pode ser divulgado a várias entidades DPKI. Em certos casos, o par pode ser o mesmo para todas as entidades. É por isso que a formação de uma assinatura para cada transação não nula requer duas chaves privadas, uma das quais é a chave da carteira eletrônica: essa chave é conhecida apenas pelo proprietário da carteira eletrônica que também possui o conjunto de chaves públicas comuns. Todas essas chaves têm certos propósitos. Por exemplo, sempre podemos provar que uma determinada transação foi incluída no razão por uma entidade DPKI registrada, pois a assinatura foi formada usando também uma chave privada de serviço. Além disso, isso evita ataques do DOS e outras atividades fraudulentas, porque o proprietário paga por cada transação.

Todas as transações que seguem uma transação nula são formadas da mesma forma: uma chave pública (de um par de chaves comum, não a chave da carteira eletrônica como para transações nulas) é processada usando duas funções de hash: SHA256 e RIPEMD160. É assim que os dados no terceiro campo são formados. O quarto campo contém informações adicionais (por exemplo, informações sobre o status atual, período de validade, registro de data e hora, IDs dos algoritmos criptográficos etc.). O quinto campo contém uma chave pública do par de chaves pública / privada de serviço. Essa chave é replicada, pois será usada para a verificação de um DS. Vamos provar que essa abordagem é necessária.

Cada transação é incluída no pool e armazenada lá até ser processada. No entanto, manter as transações no pool é arriscado, pois os dados da transação podem ser falsificados. O proprietário autentica os dados da transação usando um DS. A chave pública para a verificação desse DS é especificada explicitamente em um dos campos da transação e depois é incluída no razão. As transações são processadas de uma maneira que possivelmente permite que um invasor modifique os dados a seu critério, verifique-os com sua própria chave privada e especifique a chave pública correspondente para a verificação do DS diretamente na transação. Se a autenticidade e a integridade forem garantidas apenas usando um DS, essas falsificações poderão permanecer despercebidas. No entanto, estender um DS com um mecanismo adicional que fornece arquivamento e persistência das informações armazenadas ajudará a detectar essas falsificações. Tudo o que precisamos fazer é incluir a chave pública autêntica do proprietário no razão. Vamos ver como isso funciona.

Suponha que um invasor esteja tentando falsificar os dados da transação. Em termos de chaves e DS, são possíveis as seguintes opções:

1. O invasor coloca sua própria chave pública na transação, mantendo o DS do proprietário inalterado.
2. O invasor forma um novo DS usando sua própria chave privada, mantendo a chave pública do proprietário inalterada.
3. O invasor forma um novo DS usando sua própria chave privada e coloca a chave pública correspondente na transação.

É óbvio que as opções 1 e 2 são inúteis, pois a verificação do DS sempre detectará essas falsificações. A única opção que faz sentido é a opção 3: se o invasor criar um DS usando sua própria chave privada, será forçado a salvar a chave pública correspondente na transação, e essa chave será diferente da chave pública do proprietário. É a única maneira de o invasor impor seus dados falsificados.

Suponha que o proprietário tenha um par fixo de chaves públicas / privadas. Suponha que os dados sejam autenticados com um DS usando uma chave privada desse par enquanto a chave pública estiver especificada na transação. Suponha também que essa chave pública tenha sido incluída anteriormente no razão e tenha sido totalmente autenticada. A falsificação pode ser revelada pelo fato de a chave pública na transação não corresponder à chave pública no razão.

Vamos resumir. Ao processar dados da primeira transação do proprietário, devemos autenticar a chave pública incluída no razão. Para fazer isso, podemos ler a chave no razão e depois combiná-la com a chave pública autêntica do proprietário dentro do perímetro de segurança (área relativamente invulnerável). Se a chave colocada for autenticada e totalmente persistente, a chave da próxima transação também poderá ser facilmente autenticada, combinando-a com a chave do razão. Em outras palavras, a chave do razão é usada como referência. Todas as outras transações do proprietário serão processadas da mesma forma.

Cada transação é autenticada com um DS, e aqui precisamos das duas chaves privadas: a chave privada de serviço e a chave privada da carteira eletrônica. Com base nas duas chaves privadas, podemos garantir o nível de segurança desejado, já que a chave privada de serviço pode ser conhecida por outros usuários, enquanto a chave privada da carteira eletrônica é conhecida apenas pelo proprietário do par de chaves comum. Chamamos essa assinatura de duas chaves de DS "consolidado".

As transações não nulas são verificadas usando as duas chaves públicas: a chave da carteira eletrônica e a chave de serviço. (Figura 7)


Figura 7. Verificação de uma transação não nula

O processo de verificação consiste em duas etapas básicas: a primeira etapa inclui a verificação do resumo da chave pública da carteira eletrônica, enquanto a segunda etapa implementa a verificação do DS "consolidado" da transação formado usando as duas chaves privadas (ou seja, o e- chave da carteira e da chave de serviço). Quando o DS é autenticado, a transação correspondente, mediante verificação adicional, é incluída no razão.

No entanto, surge a seguinte pergunta: como verificar se uma determinada transação pertence a uma cadeia de transações específica que começa com uma transação nula? Para fazer isso, atualizamos o processo de verificação com mais uma etapa - a verificação da conectividade. Esta etapa exigirá dados dos dois primeiros campos que não usamos até o momento.

Suponha que precisamos verificar se a transação 2 é realmente seguida pela transação 3 . Para fazer isso, podemos usar o método de hash combinado para calcular os valores da função de hash para os dados nos terceiro, quarto e quinto campos. Podemos concatenar os dados do primeiro campo da transação nº 3 e o valor da função hash combinada calculada anteriormente para os dados nos terceiro, quarto e quinto campos da transação nº 2 . Todos esses valores são processados ​​usando as duas funções de hash: SHA256 e RIPEMD160. Se o valor resultante corresponder aos dados no segundo campo da transação nº 2 , a verificação será aprovada com êxito e a conectividade será comprovada. Isso é mostrado em mais detalhes nas figuras abaixo.




Figura 8, Figura 9. Verificação de ligação, exemplo de segunda e terceira transações

Em geral, formar e incluir uma notificação no razão é assim. O fluxo de trabalho da formação de uma cadeia de notificações é mostrado claramente na figura a seguir:


Figura 10. Estrutura e processamento da transação

Neste artigo, não vamos nos aprofundar nos detalhes e voltar à discussão sobre o conceito de infraestrutura descentralizada para chaves públicas.

Portanto, como a entidade que faz a solicitação envia uma solicitação de registro de notificações armazenadas no razão, e não no banco de dados da CA, os principais componentes arquiteturais da DPKI são os seguintes:

1. Razão de notificações válidas (LVN)
2. Razão de notificações retiradas (LWN)
3. Razão de notificações suspensas (LSN).

As informações sobre chaves públicas são armazenadas no LVN / LWN / LSN como valores da função hash. Observe também que ele pode ser livros ou cadeias diferentes ou mesmo uma única cadeia como parte de um único livro, quando informações sobre o status de uma chave pública comum (retirada, suspensão, etc.) são adicionadas ao quarto campo do estrutura de dados como o valor do código correspondente. Existem muitas opções para a implementação arquitetônica do DPKI, dependendo de vários critérios de otimização, como custos para armazenamento de chaves públicas na memória a longo prazo, etc.

Assim, o DPKI pode ter a mesma ou mesmo menor complexidade arquitetônica em comparação com uma solução centralizada.

Então, a principal questão aqui é qual razão é mais adequada para implementar essa tecnologia?

O principal requisito para o razão é poder formar transações de qualquer tipo. O exemplo mais conhecido de um livro real é o Bitcoin. No entanto, a implementação da tecnologia acima para Bitcoin pode enfrentar certas dificuldades: limitações da linguagem de script existente, a falta de mecanismos necessários para processar conjuntos de dados arbitrários e métodos para gerar transações de tipos arbitrários, e assim por diante.

Na ENCRY, tentamos resolver os problemas acima e desenvolvemos um razão que, em nossa opinião, apresenta várias vantagens importantes:

• Suporte a vários tipos de transações: neste livro, você pode trocar ativos (ou seja, realizar transações financeiras) e formar transações de uma estrutura arbitrária
• Os desenvolvedores podem usar a linguagem de programação proprietária PrismLang, que é muito flexível na solução de vários problemas tecnológicos.
• O mecanismo implementado para processar conjuntos de dados arbitrários.

Simplificando, as seguintes etapas devem ser concluídas:

1. Uma entidade que faz a solicitação se registra na DPKI e obtém uma carteira eletrônica. O endereço da carteira eletrônica é um valor da função hash aplicada à chave pública da carteira eletrônica. A chave privada da carteira eletrônica é conhecida apenas pela entidade que faz a solicitação
2. No registro, a entidade obtém acesso à chave privada de serviço
3. A entidade forma uma transação nula e, em seguida, autentica seu DS usando a chave privada da carteira eletrônica
4. Ao formar uma transação não nula, a entidade deve autenticar seu DS usando duas chaves privadas: a chave da carteira eletrônica e a chave de serviço
5. A entidade envia a transação para o pool
6. O nó da rede ENCRY lê a transação do pool e verifica o DS e a conectividade da transação.
7. Se o DS for válido e a conectividade for comprovada, o nó preparará a transação para inclusão no razão.

Aqui, o razão serve como um banco de dados distribuído que armazena informações sobre notificações válidas, retiradas e suspensas.

Certamente, a descentralização não é uma solução única para todos. O principal problema com a autenticação do usuário principal ainda persiste: enquanto a entidade que faz a solicitação é atualmente verificada pela CA, o DPKI propõe delegar essa verificação aos membros da comunidade e motivá-los financeiramente. A tecnologia de verificação baseada em fontes públicas é comumente conhecida. A eficiência dessa verificação também foi comprovada na prática: várias investigações de alto nível conduzidas pela Bellingcat são bons exemplos disso.

Mas, em geral, temos certeza de que o DPKI é capaz de eliminar muitas, senão todas, desvantagens de uma PKI centralizada.

Sinta-se à vontade para assinar nosso blog sobre Habr , onde discutiremos nossas pesquisas e desenvolvimentos, e siga nosso Twitter para ficar atento a mais novidades sobre os projetos ENCRY.