Hoje em dia, apenas os preguiçosos não escreveram sobre a tecnologia blockchain, criptomoedas e o quão incrível isso é. Mas neste artigo não haverá exaltação dessa tecnologia, em vez disso, abordaremos suas desvantagens e as soluções para elas.

Durante o trabalho em um dos projetos da Altyriks Systems, surgiu a tarefa de confirmação de dados de uma fonte externa para o blockchain que fosse segura e resistente à censura. Era necessário confirmar as mudanças nos registros de um terceiro sistema e, com base nessas mudanças, executar uma ou outra ramificação na lógica do contrato inteligente. A princípio, a tarefa parece bastante trivial, mas quando o resultado de sua execução afeta a situação financeira de uma das partes envolvidas no processo, surgem requisitos adicionais. Antes de tudo, é necessário ter confiança total em um mecanismo de validação como esse. Mas vamos por partes.

O problema é que o blockchain é, por si só, um objeto autônomo e fechado, então os contratos inteligentes dentro do blockchain não sabem nada sobre o mundo exterior. Ao mesmo tempo, as condições dos contratos inteligentes frequentemente estão ligadas a informações sobre coisas reais (atraso de voo, taxa de câmbio, etc.). Para que os contratos inteligentes funcionem corretamente, as informações obtidas de fora do blockchain devem ser confiáveis e verificadas. Esse 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 verificado, pode-se dizer que eles são fornecedores de informações confiáveis.

Oráculos

Imagine que um contrato inteligente realiza a transferência de 0,001 btc para sua carteira bitcoin caso seu clube de futebol favorito vença a Copa da Rússia. Em caso de vitória real, o contrato inteligente precisa receber informações sobre qual clube venceu, e aqui surgem uma série de problemas: de onde obter essas informações, como transmiti-las de forma segura para o contrato inteligente e como garantir que as informações recebidas pelo contrato inteligente realmente correspondem à realidade?

Na questão da fonte de informação, podem existir dois cenários: conectar um contrato inteligente a um site confiável, onde as informações sobre os resultados das partidas são armazenadas de forma centralizada, ou a segunda opção — conectar vários sites e então selecionar informações da maioria das fontes que fornecem dados iguais. Para garantir a precisão das informações, são utilizados oráculos, como o Oraclize, que usa o TLSNotary (uma modificação do TLS para provar a autenticidade dos dados). No entanto, há bastante informação sobre o Oraclize no Google, e no Habr há vários artigos, hoje eu falarei sobre oráculos que utilizam uma abordagem um pouco diferente para a transmissão de informações: Town Crier e DECO. O artigo descreve os princípios de funcionamento de ambos os oráculos, bem como uma comparação detalhada.

Town Crier

O Town Crier (TC) foi apresentado pelo IC3 (The Initiative for CryptoCurrencies and Contracts) em 2016 na CCS'16. A ideia principal do TC: transmitir informações de um site para um contrato inteligente e garantir que as informações entregues pelo TC sejam as mesmas que as do site. O TC utiliza TEE (Trusted Execution Environment) para a autenticidade da propriedade dos dados. Na versão original do TC, é descrito o trabalho com o Intel SGX.
O Town Crier é composto por uma parte dentro da blockchain e uma parte dentro do próprio sistema operacional — o TC Server.

O TC Contract está na blockchain e atua como a interface do front end para o TC. Ele recebe solicitações do CU (contrato inteligente do usuário) e retorna a resposta do TC Server. Dentro do TC Server está o Relay, que estabelece a conexão entre o enclave e a rede internet (tráfego bidirecional) e conecta o enclave à blockchain. O enclave contém progencl, que representa o código que executa solicitações da blockchain e retorna mensagens para a blockchain com a assinatura digital; o progencl contém parte do código do contrato inteligente e efetivamente executa algumas de suas funções.

O enclave Intel SGX pode ser visto como uma biblioteca comum com API, funcionando por meio de ecall. O ecall transfere o controle para o enclave. O enclave executa seu código até que seja concluído ou ocorra uma exceção. Para chamar funções definidas fora do enclave, são utilizados ocall. O ocall é executado fora do enclave e é tratado como uma chamada não confiável. Após a execução do ocall, o controle retorna ao enclave.

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

A parte do Relay inclui a Client Interface, TCP e Blockchain Interface. A Client Interface é necessária para a atestação do código do enclave e comunicação com o cliente. O cliente envia um pedido de atestação usando ecall e recebe um timestamp, assinado por skTC, junto com o att (assinatura de atestação), que é então confirmado pelo Intel Attestation Service (IAS), enquanto o timestamp é verificado por um serviço de tempo confiável. A Blockchain Interface verifica os pedidos recebidos e coloca transações na blockchain para a entrega de datagrams. Geth é o cliente oficial do Ethereum e permite que o Relay interaja com a blockchain através de chamadas RPC.

Trabalhando com TEE, o TC permite iniciar vários enclaves simultaneamente, aumentando assim a velocidade de processamento de informações em 3 vezes. Se com um enclave em funcionamento a velocidade era de 15 tx/sec, com 20 enclaves iniciados em paralelo, a velocidade sobe para 65 tx/sec; para comparação, a velocidade máxima de operação na blockchain do Bitcoin é de 26 tx/sec.

DECO

DECO (Oráculos Descentralizados para TLS) foi apresentado no CCS’20, funciona com sites que suportam conexão TLS. Garante a privacidade e a integridade dos dados.
O DECO com TLS utiliza criptografia simétrica, fazendo com que tanto o cliente quanto o servidor web tenham chaves de criptografia, e o cliente, se desejar, pode falsificar os dados da sessão TLS. Para resolver esse problema, o DECO utiliza um protocolo de handshake de três vias entre prover (smart contract), verifier (oráculo) e web-server (fonte de dados).

O princípio de funcionamento do DECO consiste em o verificador (prover) obter parte dos dados D e confirmar ao verificador (verifier) que D veio do servidor TLS S. Outro problema é que o TLS não assina os dados, e o cliente TLS enfrenta dificuldades para provar que os dados foram obtidos daquele servidor específico (dificuldade de proveniência).

No protocolo DECO, são utilizados chaves de criptografia KEnc e KMac. O cliente envia uma solicitação Q para servidor web, a resposta do servidor R chega de forma criptografada, mas tanto o cliente quanto o servidor possuem os mesmos KMac, permitindo que o cliente possa falsificar a mensagem TLS. A solução do DECO consiste em 'esconder' o KMac do cliente (prover), até que ele responda à solicitação. Agora, o KMac é dividido entre prover e verificador — KpMac e KvMac. O servidor recebe o KMac para criptografar a resposta usando a operação de partes da chave KpMac ⊕ KvMac = KMac.

Configurando um handshake de três vias, a troca de dados entre o cliente e o servidor será realizada com garantia de segurança.

Falando sobre sistemas de oráculos descentralizados, não se pode deixar de mencionar a Chainlink, que busca criar uma rede descentralizada de nós oráculos compatível com Ethereum, Bitcoin e Hyperledger, considerando a modularidade: cada parte do sistema pode ser atualizada. Para garantir a segurança, a Chainlink oferece a cada oráculo envolvido na tarefa emitir uma combinação de chaves (pública e privada). A chave privada é utilizada para gerar uma assinatura parcial, que contém sua solução para a solicitação de dados. Para obter uma resposta, é necessária a combinação de todas as assinaturas parciais dos oráculos da rede.

A Chainlink planeja realizar um PoC DECO inicial focado em aplicações financeiras descentralizadas, como Mixicles. No momento da redação deste artigo, saiu uma notícia na Forbes informando que a Chainlink adquiriu a DECO da Cornell University.

Ataques aos 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 smart contract malicioso em nós TEE.
   A essência do ataque: a transmissão de código de smart contract intencionalmente incorreto para o TEE, permitindo que um invasor que tenha acesso ao nó possa executar seu próprio smart contract (fraudulento) sobre dados decifrados. No entanto, os valores retornados estarão criptografados com a chave privada, e a única maneira de acessar esses dados é pela vazamento do texto criptografado durante a devolução/saída.
   A proteção contra este ataque consiste em verificar pela enclave a veracidade do código presente no endereço atual. Isso pode ser alcançado por meio de um esquema de endereçamento, onde o endereço do contrato é definido pela hash do código do contrato.

2. Mudanças no estado do contrato ciphertext vazam.
   O cerne do ataque: Os proprietários de nós onde os contratos inteligentes são executados têm acesso ao estado do contrato de forma criptografada fora do enclave. Um invasor que controla um nó pode comparar o estado do contrato antes e depois da execução da transação e pode determinar quais argumentos foram fornecidos e qual método específico do contrato inteligente foi utilizado, uma vez que o código do contrato inteligente e suas especificações técnicas são de domínio público.
   Proteção para garantir a confiabilidade do próprio nó.

3. Ataques de canal lateral.
   Um tipo especial de ataques que utiliza o monitoramento do acesso à memória e ao cache do enclave em vários cenários. Um exemplo desse tipo de ataque é o Prime and Probe.
   
   Sequência de execução do 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 de dados confidenciais da vítima (chaves criptográficas). A seleção da linha do cache ocorre com base no valor do keybit. No exemplo da figura, keybit = 0 e o endereço X é lido na linha de cache 2. Os dados armazenados em X são carregados no cache, substituindo os dados que estavam ali antes.
   • t2: O invasor verifica quais de suas linhas de cache foram substituídas — as linhas utilizadas pela vítima. Isso é feito medindo o tempo de acesso. Repetindo essa operação para cada keybit, o invasor obtém toda a chave.

Proteção contra o ataque: O Intel SGX possui proteção contra ataques de canal lateral, que proíbe a monitoração de eventos relacionados ao cache, mas o ataque Prime and Probe ainda ocorrerá, pois o invasor observa os eventos do cache de seu próprio processo e compartilha o cache com a vítima.

Portanto, até o momento, não existe uma proteção confiável contra esse ataque.

Ataques do tipo Spectre e Foreshadow (L1TF), semelhantes ao Prime and Probe, também são conhecidos. Eles permitem a leitura de dados da memória cache através de canais laterais. Existe proteção contra a vulnerabilidade Spectre-v2, que atua contra esses dois ataques.

Em relação ao DECO, o handshake de três vias fornece garantia de segurança:

1. Prover Integrity: um prover comprometido não pode falsificar informações sobre a origem do servidor e não pode fazer o servidor aceitar solicitações inválidas ou responder incorretamente a solicitações válidas. Isso é alcançado através de padrões de solicitações entre o servidor e o prover.
2. Verifier Integrity: um verifier comprometido não pode fazer o prover receber respostas incorretas.
3. Privacidade: O verificador hackeado analisa apenas informações públicas (requisição, nome do servidor).

No DECO, apenas vulnerabilidades relacionadas à injeção de tráfego são possíveis. Inicialmente, durante o handshake triplo, o verificador pode estabelecer a identidade do servidor usando um fresh nonce. No entanto, após o handshake, o verificador deve confiar em indicativos de nível de rede (endereços IP). Assim, a conexão entre o verificador e o servidor deve ser protegida contra injeções de tráfego. Isso é alcançado utilizando um Proxy.

Comparação de oráculos

Town Crier é baseado em trabalhar com um enclave na parte do servidor, enquanto o DECO permite verificar a autenticidade da origem dos dados através de um handshake triplo e criptografando os dados com chaves criptográficas. A comparação dos dados dos oráculos foi feita com base nos seguintes critérios: desempenho, segurança, custo e praticidade.

Town Crier
DECO

desempenho
Mais rápido (0.6s para finalizar)
Mais lento (10.50s para finalizar o protocolo)

segurança
Menos seguro
Mais seguro

custo
Mais caro
Mais barato

praticidade
Requer hardware especial
Funciona com qualquer servidor que suporte TLS

Desempenho: Para trabalhar com DECO, é necessário configurar um handshake triplo. A configuração através de LAN leva 0.37 segundos, e para interações após o estabelecimento da conexão, o 2PC-HMAC (0,13 s para gravação) é eficaz. O desempenho do DECO depende dos conjuntos de cifras TLS disponíveis, do tamanho dos dados pessoais e da complexidade das provas para um aplicativo específico. Tomando como exemplo um aplicativo de opções binárias da IC3: a conclusão do protocolo através da LAN leva cerca de 10,50 s. Em comparação, o Town Crier leva cerca de 0,6 segundos para executar um aplicativo similar, ou seja, aproximadamente 20 vezes mais rápido que o DECO. Nas mesmas condições, o TC será mais rápido.

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

Custo: O custo do hardware que suporta a operação com Intel SGX é maior do que o custo de configuração do protocolo no DECO. Portanto, o TC é mais caro.

Praticidade: Para trabalhar com Town Crier, é necessário um hardware especial que suporte TEE. Por exemplo, Intel SGX é suportado em processadores da família Intel Core de sexta geração e modelos mais recentes. O DECO permite funcionar com qualquer hardware, embora haja uma configuração do DECO que utiliza TEE. O processo de configuração do handshake triplo no DECO pode levar algum tempo, mas isso não se compara às limitações de hardware do TC, tornando o DECO mais prático.

Conclusão

Ao considerar os dois oráculos separadamente e compará-los em quatro critérios, fica claro que o Town Crier perde para o DECO em três dos quatro pontos. O DECO é mais confiável em termos de segurança da informação, é mais barato e mais prático, embora a configuração do protocolo triplo possa levar algum tempo e tenha suas desvantagens, como operações adicionais com chaves de criptografia. O TC funciona mais rápido que o DECO, mas a vulnerabilidade associada ao ataque de canal lateral o torna suscetível à perda de privacidade. É importante considerar que o DECO foi apresentado em janeiro de 2020 e ainda não passou tempo suficiente para considerá-lo seguro. O Town Crier já sofreu ataques por 4 anos e passou por várias verificações, tornando seu uso justificável em muitos projetos.

Fonte: habr.com