Início Tecnologia O que a maioria dos desenvolvedores de blockchain erram sobre a segurança...

O que a maioria dos desenvolvedores de blockchain erram sobre a segurança do tee e a privacidade do contrato inteligente

10
0

 

Resumo e I. Introdução

Ii. Um tour de raios

Iii. Metodologia de sistematização

4. Solução de camada um

V. Layer-Two Solution

Vi. Discussão

Vii. Desafios de pesquisa

Viii. Comentários e referências finais

Apêndice A. Principais gerentes

Apêndice B. Anonimato e confidencialidade

Apêndice C. Fundo

Apêndice D. Um protocolo de votação baseado em TCSC

Iii. Metodologia de sistematização

Para encontrar aspectos comuns (por exemplo, funcionalidade oferecida, modelo de design, modelo adversário), extraímos padrões de design recorrentes de publicações e projetos publicamente disponíveis, focando na sistematização e avaliação de propriedades desejáveis ​​(o principal alvo do TCSC) e possíveis armadilhas dos sistemas subjacentes. Nossa metodologia de sistematização segue a idéia em [52]: Classificação e avaliação. Primeiro, fazemos uma classificação para os sistemas atuais e depois definimos uma estrutura para avaliá -los. Os detalhes são apresentados como abaixo.

A. Classificação do sistema

Classificamos os sistemas existentes em duas categorias principais: solução de camada-one (L1) e solução de camada-dois (L2). A solução Layer-One executa o contrato dentro de uma camiseta no blockchain, exigindo que cada nó blockchain equipar um TEE. Em vez disso, a solução de camada dupla depalha os cálculos da blockchain. Ele executa a maioria dos cálculos de contrato inteligentes fora da cadeia. Para um entendimento claro, fazemos uma comparação do blockchain original (por exemplo, Ethereum), solução L1, L2 Solution. Como no tab.ii, o Ethereum executa contratos inteligentes (no EVM) e procedimentos de consenso na mesma máquina de nós distribuídos. Todas as operações de contrato e transação são verificáveis ​​publicamente devido à sua total transparência. A solução Layer-One executa essas operações (execução e consenso do contrato) na mesma máquina, mas as operações de contrato são separadas dos procedimentos de consenso. Por outro lado, a solução de camada duas faz com que ambos operem de forma independente. Os contratos são executados fora da rede blockchain, enquanto o consenso ocorre dentro de cada nó.

” alt=”” aria-hidden=”true” />Tabela II: uma comparação da solução Ethereum, L1 e L2Tabela II: uma comparação da solução Ethereum, L1 e L2

B. Propriedade desejável

Idealmente, a movimentação de execuções de contratos inteligentes para o TEES traz privacidade adicional, além de manter os benefícios originais dos sistemas blockchain. Portanto, identificamos as propriedades desejáveis ​​em duas categorias principais: Propriedade de preservação da privacidade e Blockchain intrínseco recurso.

Propriedade de preservação da privacidade. A propriedade da confidencialidade é o recurso mais distinto do TCSC.

A1. Especificação oculta. O código -fonte de um contrato inteligente está oculto durante a implantação e a subsequente sincronização e execução.

A2. Inserir privacidade. Os insumos alimentados em um contrato inteligente confidencial estão ocultos do público.

A3. Privacidade de saída. Os resultados retornados de um contrato inteligente confidencial devem ser mantidos em sigilo.

A4. Procedimento Privacidade. O procedimento de execução está oculto de partes não autorizadas. Um adversário não pode aprender o conhecimento da operação dentro de um tee.

A5. Abordar a desbaste. O pseudonimato de endereço não implica garantias de privacidade fortes [53]Assim, [54]. Esta propriedade impede um adversário para aprender a link de endereço observando as atividades dos usuários.

A6. Abordar o anonimato. A identidade do interlocutor do contrato (um usuário que invoca um contrato inteligente) está escondido de um conjunto de anonimato [24] (Veja o Apêndice B).

Recurso intrínseco blockchain. Contratos inteligentes assistidos por tee herdam recursos fornecidos pelos sistemas blockchain originais. Resumimos esses recursos da seguinte forma.

A7. Código imutabilidade. Depois que um contrato é implantado com sucesso, seu código -fonte não pode ser alterado.

A8. (Confidencial) Consistência do Estado. As execuções que acontecem em uma determinada altura da blockchain produzirão o mesmo resultado em diferentes nós.

A9. Interoperabilidade contratada. Um contrato inteligente pode chamar outro contrato e ser chamado por outros.

A10. Alta disponibilidade. Um contrato inteligente é continuamente acessível sem o ponto único de falha.

A11. Execução descentralizada. Um contrato inteligente percorre a rede descentralizada.

A12. Execução automática. Um contrato inteligente pode ser executado automaticamente assim que as condições forem satisfeitas.

A13. Mecanismo de gás. As operações em execução no contrato inteligente serão cobradas com taxas de gás [2].

A14. Invocação explícita. Cada invocação será formatada como uma transação e armazenada no blockchain.

A15. Verificabilidade pública. O procedimento de execução e resultado do contrato são verificáveis ​​publicamente.

A16. Verificabilidade de consenso. O procedimento de consenso no estado (confidencial) é verificável publicamente.

C. Avaliação do sistema

Essencialmente, todos os sistemas TCSC compartilham o mesmo princípio: um O TEE lidará com os dados dos usuários. Depois disso, os dados criptografados fluem do Tee to Blockchain. O Tee desempenha um papel crucial. Assim, esta parte define uma estrutura para avaliar os sistemas blockchain subjacentes de quatro aspectos: Tee Host, Tee Security, Programa de teee Gerenciamento de teclas de tee. Essa estrutura visa identificar possíveis falhas e armadilhas de design com base no modelo de ameaças e no fluxo de trabalho de dados.

Modelo de ameaça. Nosso modelo de ameaça captura principalmente três tipos de atacantes, que são declarados da seguinte forma.

T1. Adversário do usuário (ativo/passivo). Um invasor pode controlar a rede entre usuários e tee host.

T2. Tee adversário (ativo/passivo). Um adversário pode controlar os hosts de TEE ou controlar a rede entre plataformas Tee e Blockchain.

T3. Adversário blockchain (ativo/passivo). Um adversário pode cair, modificar e atrasar as mensagens blockchain. Mas a maioria (ou dois terços) dos nós da blockchain é assumida como honesta.

Observe que os adversários não são necessariamente exclusivos. Em alguns casos, adversários em diferentes tipos podem colar.

Considerações de segurança. Esta seção define quatro métricas em relação à segurança do sistema de acordo com o fluxo de trabalho dos dados: abordagens para aprimorar a segurança de um host de TEE, contramedidas para mitigar problemas intrínsecos de Tee, métodos para evitar falhas ou bugs no programa dentro de camisetas e soluções para esclarecer o dilema da segurança do TEE.

Segurança do host Tee. Um TEE e sua interação com o ambiente externo (por exemplo, com usuários ou blockchain) são operados e controlados por um host (como um nó L1 Blockchain). Um host malicioso possui habilidades para abortar as execuções de um TEE, atrasar e modificar entradas ou até mesmo soltar qualquer mensagem de entrada ou saída. As métricas a seguir discutem as abordagens para melhorar a segurança do host.

P1. Mecanismo de punição do hospedeiro. Mecanismos de penalidade para reduzir o risco de fazer o mal por um anfitrião de tee.

P2. Mecanismo de incentivo do hospedeiro. Mecanismos de incentivo para promover um host Tee para se comportar honestamente.

P3. Tolerância a falhas do hospedeiro. Soluções para fazer sistemas operar continuamente, apesar do mau funcionamento ou falhas.

P4. Autenticação do host. Métodos para verificar a identidade e a capacidade de um host Tee.

Segurança do tee. Uma camiseta tem fraquezas inevitáveis. Por exemplo, um tee é vulnerável a ataques de canal lateral [55]Assim, [56]. Essas fraquezas inatas apresentam diretamente desafios severos ao design e implementação de sistemas de contrato assistidos por Tee. Esta parte define que a defesa se aproxima contra essas ameaças.

P5. Segurança de atestado de tee. Métodos para impedir que o serviço de atestado de tee seja anormalmente quebrado.

P6. Limitação da memória Tee. Métodos para otimizar o tamanho da memória para evitar o excesso de dados confidenciais.

P7. Ataques físicos do TEE. Abordagens para evitar ataques físicos, como a vulnerabilidade do espectro ou a vulnerabilidade de colapso [57].

P8. Timer de confiança. Abordagens para fornecer um cronômetro confiável ao executar uma camiseta.

Segurança do programa de tee. Mesmo uma camiseta é segura, como assumido, um bug do programa pode destruir a confidencialidade do contrato no mundo real. Esta parte se concentra nas medições para impedir que os programas de TEE de falhas ou bugs.

P9. Medição da carga de trabalho. A abordagem de medição da carga de trabalho para evitar um ataque de loop infinito.

P10. Detecção de falhas. Técnicas formais usadas para a modelagem e verificação do código -fonte de contratos inteligentes para reduzir as vulnerabilidades.

Figura 2: Metodologia de sistematização. Delineamos os atuais sistemas de contrato inteligente confidenciais ao longo de dois eixos principais. Nos eixos horizontais, identificamos dois tipos de sistemas assistidos por tee de acordo com os caminhos da combinação. Nos eixos verticais, damos nossa estrutura de análise em três aspectos. A propriedade corresponde ao serviço confidencial de contrato inteligente, fornecendo as funcionalidades aos usuários finais. O modelo de ameaça e a consideração de segurança concentram-se em seus sistemas de blockchain subjacentes que suportam serviços de camada superior. Com esses dois eixos como nossa metodologia de pesquisa, apresentamos ainda mais as discussões relacionadas e os desafios abertos.Figura 2: Metodologia de sistematização. Delineamos os atuais sistemas de contrato inteligente confidenciais ao longo de dois eixos principais. Nos eixos horizontais, identificamos dois tipos de sistemas assistidos por tee de acordo com os caminhos da combinação. Nos eixos verticais, damos nossa estrutura de análise em três aspectos. A propriedade corresponde ao serviço confidencial de contrato inteligente, fornecendo as funcionalidades aos usuários finais. O modelo de ameaça e a consideração de segurança concentram-se em seus sistemas de blockchain subjacentes que suportam serviços de camada superior. Com esses dois eixos como nossa metodologia de pesquisa, apresentamos ainda mais as discussões relacionadas e os desafios abertos.

P11. Restrição de consulta do usuário. A restrição nas consultas dos usuários, com o objetivo de evitar vazamentos de dados resultantes da análise diferencial da privacia [58].

P12. Confirmação de dados da blockchain. Métodos para uma tee para verificar se os dados de entrada do blockchain foram confirmados para impedir o ataque de reversão [59].

P13. Conflitos de saída de tee. Métodos para evitar várias camisetas para produzir um resultado de conflito.

TEE TEGRADA SEGURANÇA. Várias chaves (cf. Apêndice A) estão envolvidas na execução do contrato, incluindo teclas internas do TEE, como a chave de atestado e as chaves de serviço do TEE para criptografia/descriptografia do estado. Como as chaves de serviço afetam diretamente a proteção dos estados do contrato, a principal avaliação de segurança nesta SOK se concentra principalmente na geração, troca e armazenamento da chave de serviço do TEE.

P14. Protocolo de chave distribuído. As chaves dos contratos confidenciais são gerenciadas por um protocolo distribuído.

P15. Protocolo de rotação -chave. O TEE substitui uma chave antiga por uma nova chave para a criptografia futura do contrato.

P16. Chave de contrato independente. Cada contrato está associado a uma chave única, independente do TEE.

P17. Chave de camiseta independente. Cada tee tem uma chave única e contratos diferentes compartilham a mesma chave.

Resumo da sistematização. O Classificação do sistema mostra uma visão geral dos sistemas TCSC. A propriedade desejável se concentra na avaliação do serviço de contrato fornecido por um sistema de blockchain assistido por tee. Modelo de ameaça descreve as ameaças potenciais e as suposições do sistema. Considerações de segurança Mostre o indicador de avaliação para os sistemas atuais assistidos por tee. Na seção seguinte IV-B e VB, tentamos responder às seguintes perguntas: (i) Quais são as armadilhas em potencial em cada aspecto de segurança; (ii) essas armadilhas têm impactos significativos na segurança; (iii) os designers/desenvolvedores consideram essas armadilhas e, portanto, apresentam remédios viáveis ​​em seus sistemas; (iv) Quais são os remédios e eles abordam os problemas acima. Observe que centenas de sistemas TCSC foram propostos na indústria e na academia. Uma análise exaustiva é indesejável e inviável. Selecionamos apenas os projetos que fornecem relatórios técnicos ou trabalhos acadêmicos acessíveis ao público.

Autores:

(1) Rujia Li, Universidade de Ciência e Tecnologia do Sul, China, Universidade de Birmingham, Reino Unido e este autor contribuiu igualmente para este trabalho;

(2) Qin Wang, CSIRO Data61, Austrália e este autor contribuíram igualmente para este trabalho;

(3) Qi Wang, Universidade de Ciência e Tecnologia do Sul, China;

(4) David Galindo, Universidade de Birmingham, Reino Unido;

(5) Mark Ryan, Universidade de Birmingham, Reino Unido.


fonte