Hoje, apenas os preguiçosos não escreveram sobre a tecnologia blockchain, criptomoedas e como isso é legal. Mas este artigo não elogiará esta tecnologia, falaremos sobre suas deficiências e formas de eliminá-las.

Enquanto trabalhava em um dos projetos da Altirix Systems, surgiu a tarefa de confirmação segura e resistente à censura de dados de uma fonte externa ao blockchain. Foi necessário confirmar as alterações nos registros do terceiro sistema e, a partir dessas alterações, executar uma ou outra ramificação na lógica do contrato inteligente. A tarefa à primeira vista é bastante trivial, mas quando a situação financeira de uma das partes participantes no processo depende do resultado da sua implementação, surgem requisitos adicionais. Em primeiro lugar, trata-se de uma confiança abrangente num tal mecanismo de validação. Mas primeiro as primeiras coisas.

O problema é que a blockchain em si é uma entidade autônoma e fechada, de modo que os contratos inteligentes dentro da blockchain não sabem nada sobre o mundo exterior. Ao mesmo tempo, os termos dos contratos inteligentes estão frequentemente relacionados com informações sobre coisas reais (atrasos de voos, taxas de câmbio, etc.). Para que os contratos inteligentes funcionem corretamente, as informações recebidas de fora do blockchain devem ser confiáveis ​​e verificadas. Este problema é resolvido com o uso de oráculos como Town Crier e DECO. Esses oráculos permitem que um contrato inteligente na rede blockchain confie em informações de um servidor web confiável; podemos dizer que estes são provedores de informações confiáveis.

Oráculos

Imagine que um contrato inteligente transfere 0.001 BTC para sua carteira Bitcoin se o seu clube de futebol favorito vencer a Copa da Rússia. No caso de uma vitória real, o contrato inteligente precisa transferir informações sobre qual clube venceu, e aqui surgem vários problemas: onde obter essas informações, como transferi-las com segurança para o contrato inteligente e como garantir que as informações recebido no contrato inteligente é válido e realmente coincide com a realidade?

Quando se trata da fonte de informação, pode haver 2 cenários: conectar um contrato inteligente a um site confiável onde as informações sobre os resultados da partida são armazenadas centralmente, e a segunda opção é conectar vários sites ao mesmo tempo e então selecionar informações da maioria das fontes. que fornecem os mesmos dados. Para verificar a veracidade das informações são utilizados oráculos, por exemplo o Oraclize, que utiliza TLSNotary (TLS Notary Modification to Comprove the Authenticity of Data). Mas há informações suficientes no Google sobre Oraclize, e há vários artigos sobre Habré.Hoje falarei sobre oráculos que usam uma abordagem um pouco diferente para transmitir informações: Town Crier e DECO. O artigo fornece uma descrição dos princípios de funcionamento de ambos os oráculos, bem como uma comparação detalhada.

Pregoeiro da cidade

Town Crier (TC) foi apresentado pelo IC3 (The Initiative for CryptoCurrencies and Contracts) em 2016 no CCS'16. A ideia principal do TC: transferir informações de um site para um contrato inteligente e garantir que as informações entregues pelo TC sejam as mesmas do site. TC usa TEE (Trusted Execution Environment) para autenticar a propriedade dos dados. A versão original do TC descreve como trabalhar com Intel SGX.
Town Crier consiste em uma parte dentro do blockchain e uma parte dentro do próprio sistema operacional - TC Server.

O Contrato TC está no blockchain e atua como front-end para o TC. Aceita solicitações do CU (contrato inteligente do usuário) e retorna uma resposta do Servidor TC. Dentro do Servidor TC existe um Relay, que estabelece uma conexão entre o enclave e a Internet (tráfego bidirecional) e conecta o enclave ao blockchain. Enclave contém progencl, que é o código que faz solicitações do blockchain e retorna mensagens para o blockchain com uma assinatura digital, progencl contém parte do código do contrato inteligente e essencialmente executa algumas de suas funções.

O enclave Intel SGX pode ser considerado uma biblioteca compartilhada com uma API executada via ecall. Ecall transfere o controle para o enclave. O enclave executa seu código até sair ou até que ocorra uma exceção. ocall é usado para chamar funções definidas fora do enclave. Ocall é executado fora do enclave e tratado como uma chamada não confiável por ele. Depois que ocall for executado, o controle será retornado ao enclave.

Na parte do Enclave, um canal seguro é configurado com um servidor web, o próprio enclave realiza um handshake TLS com o servidor alvo e realiza todas as operações criptográficas internamente. A biblioteca TLS (mbedTLS) e o código HTTP reduzido foram exportados para o ambiente SGX. Além disso, o Enclave contém certificados CA raiz (uma coleção de certificados) para verificar os certificados de servidores remotos. O Request Handler aceita uma solicitação de datagrama no formato fornecido pelo Ethereum, descriptografa-o e analisa-o. Em seguida, ele gera uma transação Ethereum contendo o datagrama solicitado, assina-o com o skTC e transmite-o ao Relay.

A parte Relay inclui Interface do Cliente, TCP, Interface Blockchain. A Interface do Cliente é necessária para certificar o código do enclave e se comunicar com o cliente. O cliente envia uma solicitação de atestado usando ecall e recebe um carimbo de data/hora assinado pelo skTC junto com att (assinatura de atestado). Em seguida, att é verificado usando o Intel Attestation Service (IAS) e o carimbo de data/hora é verificado por um serviço de horário confiável. A Interface Blockchain verifica solicitações recebidas e coloca transações no blockchain para entrega de datagramas. Geth é um cliente oficial do Ethereum e permite que o Relay interaja com o blockchain por meio de chamadas RPC.

Trabalhando com o TEE, o TC permite executar vários enclaves em paralelo, aumentando em 3 vezes a velocidade de processamento da informação. Se com um enclave em execução a velocidade era de 15 tx/s, então com 20 enclaves em execução paralela a velocidade aumenta para 65 tx/s; para comparação, a velocidade operacional máxima na blockchain Bitcoin é de 26 tx/s.

DECO

DECO (Decentralized Oracles for TLS) foi apresentado no CCS'20, trabalha com sites que suportam conexões TLS. Garante a confidencialidade e integridade dos dados.
DECO com TLS usa criptografia simétrica, de modo que o cliente e o servidor web possuem chaves de criptografia e o cliente pode falsificar os dados da sessão TLS, se desejar. Para resolver este problema, a DECO utiliza um protocolo de handshake de três vias entre o provador (contrato inteligente), o verificador (oracle) e o servidor web (fonte de dados).

A forma como o DECO funciona é que o verificador recebe um dado D e confirma ao verificador que D veio do servidor TLS S. Outro problema é que o TLS não assina os dados e é difícil para o cliente TLS provar que o os dados foram recebidos exatamente do servidor correto (dificuldade de proveniência).

O protocolo DECO usa chaves de criptografia KEnc e KMac. O cliente envia uma solicitação Q ao servidor web, a resposta do servidor R vem em formato criptografado, mas o cliente e o servidor possuem o mesmo KMac e o cliente pode falsificar a mensagem TLS. A solução da DECO é “ocultar” o KMac do cliente (provador) até que este responda ao pedido. Agora o KMac está dividido entre provador e verificador - KpMac e KvMac. O servidor recebe KMac para criptografar a resposta usando a operação de parte chave KpMac ⊕ KvMac = KMac.

Ao estabelecer um handshake triplo, a troca de dados entre cliente e servidor será realizada com garantia de segurança.

Quando se fala em sistema oracle descentralizado, não se pode deixar de mencionar o Chainlink, que visa criar uma rede descentralizada de nós oracle compatíveis com Ethereum, Bitcoin e Hyperledger, levando em consideração a modularidade: todas as partes do sistema podem ser atualizadas. Ao mesmo tempo, para garantir a segurança, a Chainlink oferece a cada oráculo participante da tarefa a emissão de uma combinação de chaves (públicas e privadas). A chave privada é usada para gerar uma assinatura parcial que contém sua decisão para a solicitação de dados. Para obter uma resposta é necessário combinar todas as assinaturas parciais dos oráculos da rede.

A Chainlink planeja conduzir um PoC DECO inicial com foco em aplicações financeiras descentralizadas, como o Mixicles. No momento em que este artigo foi escrito, surgiram notícias na Forbes de que a Chainlink adquiriu a DECO da Cornell University.

Ataques a oráculos

Do ponto de vista da segurança da informação, foram considerados os seguintes ataques ao Town Crier:

1. Injeção de código de contato inteligente não autorizado em nós TEE.
   A essência do ataque: transmitir um código de contrato inteligente deliberadamente incorreto ao TEE, assim, um invasor que obteve acesso ao nó poderá executar seu próprio contrato inteligente (fraudulento) nos dados descriptografados. No entanto, os valores retornados serão criptografados com uma chave privada, e a única maneira de acessar tais dados é vazando o texto cifrado no retorno/saída.
   A proteção contra este ataque consiste na verificação do enclave da exatidão do código localizado no endereço atual. Isto pode ser conseguido usando um esquema de endereçamento onde o endereço do contrato é determinado por hash do código do contrato.

2. Vazamento de alterações no texto cifrado do estado do contrato.
   A essência do ataque: os proprietários dos nós nos quais os contratos inteligentes são executados têm acesso ao estado do contrato de forma criptografada fora do enclave. Um invasor, tendo obtido o controle de um nó, pode comparar o estado do contato antes e depois da transação e determinar quais argumentos foram inseridos e qual método de contrato inteligente foi usado, uma vez que o próprio código do contrato inteligente e suas especificações técnicas estão disponíveis publicamente.
   Proteção para garantir a confiabilidade do próprio nó.

3. Ataques de canal lateral.
   Um tipo especial de ataque que utiliza o monitoramento da memória do enclave e do acesso ao cache em vários cenários. Um exemplo de tal ataque é Prime and Probe.
   
   Ordem de ataque:

   • t0: O invasor preenche todo o cache de dados do processo da vítima.
   • t1: A vítima executa código com acessos à memória que dependem dos dados confidenciais da vítima (chaves criptográficas). A linha de cache é selecionada com base no valor do keybit. No exemplo da figura, keybit = 0 e é lido o endereço X na linha de cache 2. Os dados armazenados em X são carregados no cache, deslocando os dados que estavam lá antes.
   • t2: O invasor verifica quais linhas de seu cache foram removidas – linhas usadas pela vítima. Isso é feito medindo o tempo de acesso. Ao repetir esta operação para cada keybit, o invasor obtém a chave inteira.

Proteção contra ataques: O Intel SGX possui proteção contra ataques de canal lateral que impede o monitoramento de eventos relacionados ao cache, mas um ataque Prime e Probe ainda funcionará porque o invasor monitora os eventos de cache de seu processo e compartilha o cache com a vítima.

Assim, no momento não existe uma proteção confiável contra este ataque.

Ataques como Spectre e Foreshadow (L1TF), semelhantes a Prime e Probe, também são conhecidos. Eles permitem que você leia dados da memória cache por meio de um canal de terceiros. É fornecida proteção contra a vulnerabilidade Spectre-v2, que funciona contra dois desses ataques.

Em relação ao DECO, o handshake triplo oferece garantia de segurança:

1. Integridade do provador: um provador hackeado não pode falsificar informações de origem do servidor e não pode fazer com que o servidor aceite solicitações inválidas ou responda incorretamente a solicitações válidas. Isto é feito através de padrões de solicitação entre o servidor e o provador.
2. Integridade do verificador: Um verificador hackeado não pode fazer com que o provador receba respostas incorretas.
3. Privacidade: O verificador hackeado examina apenas informações públicas (solicitação, nome do servidor).

No DECO, apenas vulnerabilidades de injeção de tráfego são possíveis. Primeiro, com um handshake triplo, o verificador pode estabelecer a identidade do servidor usando um novo nonce. Porém, após o handshake, o verificador deve contar com indicadores da camada de rede (endereços IP). Assim, a comunicação entre o verificador e o servidor deve ser protegida contra injeção de tráfego. Isso é conseguido usando proxy.

Comparação de oráculos

Town Crier baseia-se no trabalho com um enclave na parte do servidor, enquanto o DECO permite verificar a autenticidade da origem dos dados por meio de handshake triplo e criptografia de dados com chaves criptográficas. A comparação desses oráculos foi realizada segundo os seguintes critérios: desempenho, segurança, custo e praticidade.

Pregoeiro da cidade
DECO

atuação
Mais rápido (0.6s para terminar)
Mais lento (10.50s para finalizar o protocolo)

Segurança
Menos seguro
Mais seguro

custar
Mais caro
Mais barato

praticidade
Requer hardware especial
Funciona com qualquer servidor que suporte TLS

Speed: Para trabalhar com DECO é necessário um handshake triplo, na configuração via LAN leva 0.37 segundos, para interação após o estabelecimento da conexão 2PC-HMAC é efetivo (0,13 s por gravação). O desempenho do DECO depende dos conjuntos de cifras TLS disponíveis, do tamanho dos dados privados e da complexidade das evidências para uma aplicação específica. Usando o aplicativo de opções binárias do IC3 como exemplo: completar o protocolo via LAN leva cerca de 10,50 segundos. Em comparação, o Town Crier leva aproximadamente 0,6 segundos para concluir uma aplicação semelhante, o que é aproximadamente 20 vezes mais rápido que o DECO. Se todas as coisas forem iguais, o TC será mais rápido.

segurança: Os ataques ao enclave Intel SGX (ataques de canal lateral) funcionam e podem causar danos reais aos participantes do contrato inteligente. Em relação ao DECO, são possíveis ataques relacionados à injeção de tráfego, mas o uso de um proxy reduz esses ataques a nada. Portanto DECO é mais seguro.

de custo: O custo do equipamento que suporta Intel SGX é superior ao custo de configuração do protocolo no DECO. É por isso que o TC é mais caro.

Praticidade: Para trabalhar com o Town Crier, é necessário equipamento especial que suporte TEE. Por exemplo, Intel SGX é compatível com a família de processadores Intel Core de 6ª geração e posteriores. DECO permite trabalhar com qualquer equipamento, embora exista uma configuração DECO usando TEE. De acordo com o processo de configuração, o handshake triplo do DECO pode levar algum tempo, mas isso não é nada comparado à limitação de hardware do TC, então o DECO é mais prático.

Conclusão

Olhando para os dois oráculos separadamente e comparando-os em quatro critérios, fica claro que o Town Crier é inferior ao DECO em três dos quatro pontos. O DECO é mais confiável do ponto de vista da segurança da informação, mais barato e mais prático, embora a configuração de um protocolo tripartido possa levar algum tempo e tenha suas desvantagens, por exemplo, operações adicionais com chaves de criptografia. O TC é mais rápido que o DECO, mas as vulnerabilidades de ataques de canal lateral o tornam suscetível à perda de confidencialidade. Deve-se levar em conta que o DECO foi introduzido em janeiro de 2020 e não passou tempo suficiente para considerá-lo seguro. O Town Crier está sob ataque há 4 anos e passou por muitos testes, pelo que se justifica a sua utilização em muitos projetos.

Fonte: habr.com