Autor: Dr. Shunfan(Shelven) Zhou, pesquisador principal da Rede Phala e um dos autores do white paper Phala, trabalha com pesquisa de segurança há mais de 7 anos. Ele é o principal autor de An Ever-evolving Game: Evaluation of Real-world Attacks and Defenses in Ethereum Ecosystem, USENIX Security Symposium 2020 e outros artigos sobre análise de programas.

Abstrato

Em 30 de novembro, o especialista em segurança Andrew Miller apontou que as vulnerabilidades do Intel SGX causaram grandes riscos à segurança de projetos como o Secret Network, que tem gerado amplas discussões na comunidade. O Intel SGX, a implementação de TEE mais amplamente adotada, também é usado pelos trabalhadores off-chain da Phala. No entanto, a Phala utiliza um novo design de sistema que reduz a superfície de ataque e mitiga as consequências de possíveis ataques. Nossa equipe de desenvolvimento considera os impactos de tais vulnerabilidades no Phala controláveis.

Este artigo explicará aos leitores:

• Por que as vulnerabilidades ÆPIC Leak e MMIO minaram a segurança da Secret Network
• As razões pelas quais Phala usa Secure Enclave (TEE)
• Como Phala garante que não será comprometido por vulnerabilidades SGX
• Mecanismos de segurança futuros

1. O que causou a vulnerabilidade no Secret Network?

• Hardware com vulnerabilidades não corrigidas ( ÆPIC Leak e MMIO Vulnerabilities , anunciado pela Intel em 9 de agosto de 2022) foi autorizado a ingressar na Rede Secreta e operar nós. A equipe secreta congelou o registro depois que o whitehat relatou esse problema;
• A mesma chave mestra de descriptografia na rede secreta é compartilhada em todos os nós.

2. O que os invasores podem conseguir?

Como eu cito dehttps://sgx.fail: “Essas vulnerabilidades podem ser usadas para extrair a semente de consenso, uma chave mestra de descriptografia para as transações privadas na Rede Secreta. A exposição da semente de consenso permitiria a divulgação retroativa completa de todas as transações privadas do Secret-4 desde o início da cadeia.”

3. A Rede Phala é afetada pelas mesmas vulnerabilidades?

Não. O Phala adota o controle de acesso no registro do nó (chamado de ' trabalhador' em Phala) e no gerenciamento da hierarquia de chaves, que abordarei posteriormente.

Recursos :

• https://scrt.network/blog/notice-successful-resolution-of-xapic-vulnerability
• https://sgx.fail/

Por que Phala precisa do Secure Enclave (TEE)

Phala é uma nuvem de computação sem permissão que permite que qualquer computador ingresse como trabalhadores, portanto, nosso modelo de ameaça é que nenhum trabalhador não é confiável por padrão. Pessoas mal-intencionadas operando como trabalhadores podem tentar:

• espreitar os dados dos utilizadores;
• forneça resultados de execução falsos ou não faça nenhum cálculo;
• fornecem serviços de baixa qualidade, como redução do desempenho da CPU ou bloqueio do acesso à rede.

Secure Enclave fornece importantes promessas de segurança baseadas em hardware, incluindo:

• Confidencialidade : todos os valores da memória são criptografados;
• Integridade da execução : ninguém pode corromper a exatidão da execução, mesmo que controle o sistema operacional e o computador físico;
• Atestado remoto : os usuários podem verificar remotamente o hardware e o software em execução no Secure Enclave.

Esses recursos servem como base de confiança para que possamos “emprestar” o poder do computador das pessoas. Vale a pena notar que, como uma nuvem de computação, os valores centrais do Phala são a execução correta dos programas dos usuários e a privacidade dos dados do usuário. Isso diferencia o Phala de outros projetos que focam apenas na confidencialidade.

A Phala pode usar prova de conhecimento zero, computação multipartidária ou criptografia totalmente homomórfica como seus operadores?

A resposta é não, sim e sim, pois essas soluções funcionam de maneiras diferentes.

• No caso do ZKP, o usuário faz sua própria execução e apenas fornece a comprovação na cadeia de que realmente realizou o trabalho. Este não é o caso de computação em nuvem em que você delega sua computação a outras pessoas;
• O MPC divide as tarefas em diferentes partes, portanto, nenhum dos executores pode saber a entrada original ou a saída final;
• O FHE permite que os executores calculem diretamente com o texto cifrado, para que não possam conhecer os dados dos usuários.

Controle de Acesso no Cadastro de Trabalhadores

Juntar-se a Phala como trabalhador envolve dois pré-requisitos:

• Os trabalhadores devem fornecer hardware com suporte Secure Enclave. Atualmente, suportamos apenas Intel SGX, mas nossa investigação sobre AMD-SEV mostrou que também é compatível com nosso sistema atual;
• Os trabalhadores executam programas não modificados construídos pelo Phala, incluindo o nó Phala e o pRuntime off-chain (abreviação de Phala Runtime) .

• Informações de hardware
• Se o pRuntime está rodando dentro do SGX;
• As vulnerabilidades conhecidas de acordo com a versão atual de hardware e firmware. Com base nisso, a blockchain Phala rejeitará o hardware com vulnerabilidades na lista negra e atribuirá a cada trabalhador um nível de confiança .
• Informações do software
• O hash do binário do programa, que ajuda a garantir que o pRuntime não seja modificado;
• O layout da memória inicial do programa, portanto, seu estado inicial é determinado.

Além disso, nosso Tokenomic de ponta de suprimento incentiva o serviço de alta qualidade dos trabalhadores. Isso está fora do escopo deste artigo, mas você pode aprender mais em nossa página de tokennomics vinculada acima.

Gerenciamento de Hierarquia Chave

A primeira hierarquia de chaves do mundo para o sistema híbrido blockchain-TEE foi proposta pelo jornal Ekiden em 2019 e serve como base para o projeto Oasis. Como uma nuvem de computação, o Phala melhora esse design para torná-lo viável para uma rede de aproximadamente 100 mil nós. Também apresentamos um novo mecanismo, como a rotação de chaves, para melhorar ainda mais a robustez da nuvem.

Antes de nos aprofundarmos nos detalhes de nosso gerenciamento de chave de contrato, é importante que os leitores saibam que cada entidade em nosso sistema tem sua própria chave de identidade. Cada usuário tem sua conta, e cada trabalhador e porteiro (que são eleitos pelos trabalhadores) tem seu próprio par sr25519 WorkerKey , que é gerado dentro do pRuntime (também no SGX) e a chave privada nunca sai do SGX. A chave de identidade é usada para:

• Identificar a mensagem de uma entidade com assinatura;
• Estabeleça um canal de comunicação criptografado entre usuários, trabalhadores e porteiros com acordo de chave ECDH . Por padrão, qualquer comunicação entre quaisquer entidades é criptografada em Phala.

• Gatekeepers são trabalhadores de alto nível de confiança: eles são imunes a todas as vulnerabilidades SGX conhecidas;
• Ao contrário dos trabalhadores normais, os endpoints dos gatekeepers não são públicos e você não pode implantar contratos neles. Isso reduz o acesso remoto aos porteiros;
• Maiores quantias de apostas são exigidas dos porteiros para desencorajar o mau comportamento de seus operadores.

Por fim, quando um contrato é implantado em um cluster, ele é implantado em todos os funcionários desse cluster. Esses trabalhadores seguirão o processo determinístico e derivarão o ClusterKey para obter o mesmo ContractKey. Os ContractKeys são exclusivos para diferentes contratos.

Quais são as vulnerabilidades se certas chaves vazarem?

• Se um WorkerKey vazar, os invasores podem descriptografar todas as mensagens enviadas a ele, como o ClusterKey de seu cluster, que pode ser usado para acessar os ContractKeys desse cluster. Os invasores podem até se passar por um trabalhador para fornecer resultados falsos aos usuários. Essa atividade maliciosa pode ser detectada comparando os resultados de vários trabalhadores e, em seguida, a cadeia cortaria o trabalhador comprometido e confiscaria o PHA apostado desse trabalhador;
• Se um ContractKey vazar, os invasores podem descriptografar os estados e todas as entradas históricas desse contrato;
• Se um ClusterKey vazar, os invasores podem saber as informações acima de todos os contratos nesse cluster;
• Se a MasterKey vazar, todos os dados históricos vazarão.

• A Phala implementou a Rotação de Chaves para gatekeepers, o que significa que, com a permissão do Conselho, os gatekeepers podem atualizar a MasterKey e, correspondentemente, as ClusterKeys e as ContractKeys.
• Portanto, quando o pior caso acontecer, primeiro registraremos os novos gatekeepers com o hardware mais recente, cancelaremos o registro de todos os antigos (já que provavelmente estão vulneráveis) e mudaremos para uma nova MasterKey.

1. Use Computação Multipartidária para gerenciar MasterKey

2. Ativar atualização de cotações de RA

Uma vez que o contrato Phat não é atualmente suportado na rede principal, os trabalhadores só precisam enviar as cotações de RA uma vez durante o registro. Quando o Phat Contract for lançado, habilitaremos uma atualização regular das cotações de RA para que os trabalhadores vulneráveis ​​sejam cortados assim que novas vulnerabilidades forem relatadas e os trabalhadores não aplicarem os patches.

Por fim, gostaria de agradecer a Andrew Miller e à equipe de pesquisa de segurança, incluindo Christina Garman, Daniel Genkin, Stephan van Schaik e outros, por sua contribuição ao campo da segurança. Como disse Andrew, o objetivo de sua equipe é ajudar a melhorar a segurança e reduzir a ocorrência de acidentes de segurança. Sinceramente, espero ter discussões mais aprofundadas com pesquisadores de segurança para consolidar a infraestrutura confiável para o mundo Web3.