Autores: prateek, roshan, siddhartha & linguine (Marlin), krane (Asula)Compilado por: Shew, REALM de Deus
Desde que a Apple anunciou a introdução de nuvens privadas e a NVIDIA ofereceu cálculos confidenciais nas GPUs, o Ambiente de Execução Confidencial (TEE) tornou-se cada vez mais popular. A garantia de sua confidencialidade ajuda a proteger os dados dos usuários (possivelmente incluindo chaves privadas), enquanto o isolamento garante que a execução de programas implantados sobre ele não seja adulterada - quer por humanos, outros programas ou sistemas operacionais. Portanto, não é surpreendente que o TEE seja amplamente utilizado na construção de produtos no campo da criptografia x IA.
Como qualquer nova tecnologia, TEE está a passar por um período de experimentação otimista. Este artigo tem como objetivo fornecer um guia conceitual básico para desenvolvedores e leitores em geral, para que possam compreender o que é TEE, o modelo de segurança de TEE, vulnerabilidades comuns e as melhores práticas de segurança ao usar TEE. (Nota: Para facilitar a compreensão do texto, substituímos intencionalmente os termos de TEE por palavras equivalentes mais simples).
O que é TEE
TEE é um ambiente isolado em um processador ou centro de dados, onde os programas podem ser executados sem interferência de qualquer outra parte do sistema. Para evitar interferências de outras partes, precisamos de uma série de designs, incluindo controle de acesso rigoroso, que controla o acesso de outras partes do sistema aos programas e dados dentro do TEE. Atualmente, o TEE está em toda parte, em telefones, servidores, PCs e ambientes de nuvem, tornando-o facilmente acessível e acessível.
O conteúdo acima pode parecer vago e abstrato, na verdade, a implementação do TEE em diferentes servidores e fornecedores de nuvem é diferente, mas o objetivo fundamental é evitar a interferência de outros programas no TEE.
A maioria dos leitores provavelmente usará informações de biometria para fazer login em dispositivos, como desbloquear um telefone com impressão digital. Mas como podemos garantir que aplicativos maliciosos, sites ou sistemas operacionais com jailbreak não possam acessar e roubar essas informações biométricas? Na verdade, além de criptografar os dados, os circuitos no dispositivo TEE simplesmente não permitem que nenhum programa acesse a área de memória e processador ocupada por dados sensíveis.
A carteira de hardware é outro exemplo de cenário de aplicação TEE. A carteira de hardware é conectada ao computador e se comunica com ele em uma sandbox, mas o computador não pode acessar diretamente as palavras mnemônicas armazenadas na carteira de hardware. Em ambos os casos acima, os usuários confiam que o fabricante do dispositivo pode projetar corretamente o chip e fornecer atualizações de firmware adequadas para impedir a exportação ou visualização de dados confidenciais dentro do TEE.
Modelo de segurança
Infelizmente, há muitos tipos de implementações de TEE, e essas diferentes implementações (IntelSGX, IntelTDX, AMDSEV, AWSNitroEnclaves, ARMTrustZone) exigem modelos de segurança independentes para análise de modelagem. No restante deste artigo, discutiremos principalmente IntelSGX, TDX e AWSNitro, porque esses sistemas TEE têm mais usuários e ferramentas de desenvolvimento totalmente disponíveis. Esses sistemas acima também são os sistemas TEE mais comuns dentro da Web3.
Em geral, o fluxo de trabalho do aplicativo implantado no TEE é o seguinte:
Os 'desenvolvedores' escreveram algum código, que pode estar aberto ou não
Em seguida, o desenvolvedor empacota o código no arquivo de imagem Enclave (EIF), que pode ser executado no TEE
EIF está hospedado em um servidor com sistema TEE. Em algumas situações, os desenvolvedores podem hospedar o EIF em um computador pessoal com TEE para fornecer serviços externos.
Os utilizadores podem interagir com as aplicações através de uma interface predefinida.
Obviamente, existem 3 riscos potenciais aqui:
Desenvolvedores: Qual é o propósito de preparar o código EIF? O código EIF pode não estar em conformidade com a lógica de negócios divulgada externamente pelo projeto e pode comprometer os dados de privacidade do usuário.
Servidor: O servidor TEE está a executar o ficheiro EIF conforme o esperado? Ou o EIF está realmente a ser executado dentro do TEE? O servidor também pode estar a executar outros programas dentro do TEE
Fornecedor: O design TEE é seguro? Existe alguma porta dos fundos que possa divulgar todos os dados dentro do TEE para o fornecedor?
Felizmente, agora o TEE tem soluções para eliminar os riscos mencionados, ou seja, Construções Reproduzíveis(Reproducible Builds) e Atteststations Remotas(Remote Atteststations).
Então, o que é construção repetível? O desenvolvimento de software moderno muitas vezes requer a importação de uma grande quantidade de dependências, como ferramentas externas, bibliotecas ou estruturas, etc. Esses arquivos de dependência também podem ter problemas de segurança. Agora, soluções como o npm usam o hash do código correspondente aos arquivos de dependência como identificador único. Quando o npm descobre que um arquivo de dependência não corresponde ao valor de hash registrado, ele pode considerar que o arquivo de dependência foi modificado.
A construção repetível pode ser considerada um conjunto de normas cujo objetivo é garantir que, independentemente do dispositivo em que o código é executado, desde que a construção seja feita de acordo com o processo pré-definido, o valor de hash será o mesmo. Claro, na prática, podemos usar outros produtos além do hash como identificadores, que chamamos de medição de código (.
O Nix é uma ferramenta comum para construção replicável. Depois que o código-fonte do programa é público, qualquer pessoa pode verificar o código para garantir que os desenvolvedores não inseriram conteúdo malicioso, e qualquer pessoa pode usar o Nix para construir o código e verificar se o artefato construído tem a mesma medição de código/hash que o artefato implantado pelo projeto no ambiente de produção. No entanto, como podemos saber o valor de medição de código do programa no TEE? Aqui entra em jogo o conceito de "prova remota".
Prova Remota é uma mensagem de assinatura do provedor da TEE (ambiente de execução confiável), que inclui métricas do código do programa, versão da plataforma TEE, etc. A prova remota permite que observadores externos saibam que um programa está sendo executado em um local seguro (TEE real da versão xx) que não pode ser acessado por ninguém.
A capacidade de construção repetida e a prova remota permitem que qualquer utilizador saiba o código real em execução no TEE e as informações de versão da plataforma TEE, impedindo assim que os desenvolvedores ou servidores ajam maliciosamente.
No entanto, no caso do TEE, ainda é necessário confiar no fornecedor. Se o fornecedor de TEE agir mal, ele pode falsificar a prova remota diretamente. Portanto, se o fornecedor for considerado um possível meio de ataque, evite depender apenas do TEE e é melhor combiná-lo com ZK ou um protocolo de consenso.
O encanto do TEE
Do nosso ponto de vista, as características TEE são especialmente populares, especialmente a facilidade de implantação para o agente de IA, principalmente pelos seguintes motivos:
Desempenho: O TEE pode executar o modelo LLM com desempenho e custo semelhantes aos de servidores convencionais. Enquanto o zkML requer uma grande quantidade de poder computacional para gerar provas zk do LLM.
Suporte para GPU: A NVIDIA oferece suporte à computação TEE em sua mais recente série de GPUs (Hopper, Blackwell, etc.).
Correção: Os LLMs são não determinísticos; inserir a mesma palavra-chave várias vezes resultará em resultados diferentes. Assim, vários nós (incluindo observadores que tentam criar provas de fraude) podem nunca chegar a um consenso sobre os resultados do LLM. Neste cenário, podemos confiar que o LLM em execução no TEE não pode ser manipulado por um atacante, e o programa dentro do TEE sempre é executado da forma como foi escrito, o que torna o TEE mais adequado para garantir a confiabilidade dos resultados de raciocínio do LLM do que o opML ou o consenso
Confidencialidade: Os dados no TEE não são visíveis para programas externos. Portanto, as chaves privadas geradas ou recebidas no TEE são sempre seguras. Essa característica pode ser usada para garantir aos usuários que qualquer mensagem assinada por essa chave é proveniente de programas internos do TEE. Os usuários podem confiar em hospedar suas chaves privadas no TEE e definir algumas condições de assinatura, e podem confirmar que as assinaturas provenientes do TEE atendem às condições de assinatura pré-definidas
**Conectividade: **Através de algumas ferramentas, os programas em execução no TEE podem acessar a Internet de forma segura (sem revelar consultas ou respostas ao servidor em execução no TEE, ao mesmo tempo em que garantem a recuperação correta dos dados para terceiros). Isso é muito útil para recuperar informações de API de terceiros e pode ser usado para terceirizar o cálculo a fornecedores de modelos confiáveis, mas proprietários.
Permissões de escrita: Ao contrário do esquema zk, o código em execução no TEE pode construir mensagens (sejam tweets ou transações) e enviá-las através da rede API e RPC.
**Amigável para os desenvolvedores: **Os frameworks e SDKs relacionados ao TEE permitem que as pessoas escrevam código em qualquer idioma e implantem facilmente programas no TEE, assim como em servidores de nuvem
Seja bom ou ruim, atualmente é difícil encontrar alternativas para muitos casos de uso de TEE. Acreditamos que a introdução de TEE amplia ainda mais o espaço de desenvolvimento de aplicativos on-chain, o que pode impulsionar a criação de novos cenários de aplicativos.
TEE não é uma bala de prata
Os programas em execução no TEE ainda são suscetíveis a uma série de ataques e erros. Assim como os contratos inteligentes, eles podem enfrentar uma série de problemas. Para facilitar, classificamos as possíveis vulnerabilidades da seguinte forma:
Desenvolvedor negligente
Vulnerabilidade em tempo de execução
Defeito de design de arquitetura
Problemas operacionais
Desleixo do desenvolvedor
Seja intencional ou não, os desenvolvedores podem comprometer a segurança dos programas no TEE por meio de códigos intencionais ou não intencionais. Isso inclui:
Código opaco: O modelo de segurança do TEE depende de verificação externa. A transparência do código é crucial para a verificação de terceiros externos.
Problemas com a medição de código: Mesmo que o código seja público, se não houver uma reconstrução do código por terceiros e uma verificação das métricas de código fornecidas pela prova remota, é semelhante a receber uma prova zk sem verificá-la.
Código inseguro: Mesmo que você tenha gerado e gerenciado corretamente as chaves dentro do TEE com todo o cuidado, a lógica contida no código pode vazar as chaves do TEE durante chamadas externas. Além disso, pode haver backdoors ou vulnerabilidades no código. Em comparação com o desenvolvimento tradicional de back-end, isso requer que o processo de desenvolvimento e auditoria de software atenda a padrões elevados, semelhantes ao desenvolvimento de contratos inteligentes.
Ataque à Cadeia de Suprimentos: O desenvolvimento de software moderno usa uma grande quantidade de código de terceiros. Os ataques à cadeia de suprimentos representam uma grande ameaça para a integridade do TEE.
Vulnerabilidades de tempo de execução
Os desenvolvedores, mesmo os mais cuidadosos, podem se tornar vítimas de vulnerabilidades em tempo de execução. Os desenvolvedores devem considerar cuidadosamente se algum dos seguintes itens pode afetar a segurança de seu projeto:
Código dinâmico: Nem sempre é possível manter todo o código transparente. Às vezes, o próprio caso de uso precisa executar dinamicamente o código opaco carregado no TEE durante a execução. Esse tipo de código pode vazar facilmente informações confidenciais ou violar invariâncias, por isso é crucial prevenir essa situação com muito cuidado.
Dynamic Data: Most applications use external APIs and other data sources during execution. The security model extends to include these data sources, which are on par with oracles in DeFi. Incorrect or outdated data can lead to disasters. For example, in the case of an AI Agent, excessive reliance on LLM services such as Claude.
Comunicação insegura e instável: TEE precisa ser executado dentro do servidor que contém os componentes TEE. Do ponto de vista da segurança, o servidor que executa o TEE é essencialmente um intermediário perfeito (MitM) entre o TEE e a interação externa. O servidor não só pode espiar as conexões externas do TEE e visualizar o conteúdo sendo enviado, mas também pode inspecionar IPs específicos, restringir conexões e injetar pacotes de dados nas conexões, com o objetivo de enganar uma das partes para que acredite que estão vindo de xx.
Por exemplo, em TEE, pode ser executado um mecanismo de correspondência de transações criptográficas que não consegue garantir uma ordenação justa (resistência a MEV), uma vez que o router/gateway/host ainda pode descartar, atrasar ou priorizar com base no endereço IP de origem dos pacotes de dados.
Defeito de Arquitetura
A pilha de tecnologia utilizada pelo aplicativo TEE deve ser tratada com cautela. Ao construir um aplicativo TEE, podem surgir os seguintes problemas:
Aplicações com uma grande superfície de ataque: A superfície de ataque de um aplicativo refere-se à quantidade de módulos de código que precisam de segurança total. O código com uma grande superfície de ataque é muito difícil de auditar e pode esconder bugs ou vulnerabilidades exploráveis. Isso frequentemente entra em conflito com a experiência do desenvolvedor. Por exemplo, em comparação com um programa TEE que não depende do Docker, um programa TEE que depende do Docker tem uma superfície de ataque muito maior. Em comparação com um programa TEE que utiliza um sistema operacional extremamente leve, os Enclaves que dependem de sistemas operacionais maduros têm uma superfície de ataque ainda maior.
Portabilidade e Atividade: Em Web3, os aplicativos devem ter resistência à censura. Qualquer pessoa pode iniciar um TEE e assumir o controle de participantes do sistema inativos, tornando os aplicativos dentro do TEE portáteis. O maior desafio aqui é a portabilidade das chaves. Alguns sistemas TEE possuem mecanismos de derivação de chaves, mas uma vez que se utiliza o mecanismo de derivação de chaves dentro do TEE, outros servidores não conseguem gerar localmente as chaves dos programas externos ao TEE, o que faz com que os programas TEE geralmente sejam limitados a uma única máquina, o que não é suficiente para manter a portabilidade.
Raiz de confiança insegura: Por exemplo, ao executar o Agente de IA em um TEE, como verificar se um determinado endereço pertence a esse Agente? Se isso não for cuidadosamente projetado, pode resultar em uma raiz de confiança real sendo um terceiro externo ou uma plataforma de custódia de chaves, em vez do próprio TEE.
Problemas de operação
Por último, mas não menos importante, existem algumas considerações práticas sobre como realmente operar um servidor que executa programas TEE:
Versão da plataforma insegura: A plataforma TEE recebe atualizações de segurança ocasionalmente, que são refletidas como a versão da plataforma no comprovante remoto. Se o seu TEE não estiver executando na versão segura da plataforma, os hackers podem roubar chaves do TEE usando vetores de ataque conhecidos. Pior ainda, seu TEE pode estar funcionando em uma versão segura da plataforma hoje, mas pode ser inseguro amanhã.
Sem segurança física: Apesar de todos os esforços, o TEE pode ser alvo de ataques de canal lateral, que geralmente exigem acesso físico e controle do servidor onde o TEE está localizado. Portanto, a segurança física é uma camada importante de defesa em profundidade. Um conceito relacionado é a prova de nuvem, onde você pode provar que o TEE está sendo executado em um centro de dados na nuvem, com garantias de segurança física.
Construir programas seguros de TEE
Dividimos nossas sugestões em vários pontos:
A solução mais segura
Medidas preventivas necessárias adotadas
Dependendo das recomendações do caso de uso
1. A solução mais segura: sem dependências externas
Criar aplicativos altamente seguros pode envolver a eliminação de dependências externas, como entrada externa, APIs ou serviços, reduzindo assim a superfície de ataque. Esse método garante que o aplicativo funcione de forma independente, sem interações externas que possam comprometer sua integridade ou segurança. Embora essa estratégia possa limitar a diversidade de recursos do programa, ela pode fornecer um alto nível de segurança.
Se o modelo for executado localmente, esse nível de segurança pode ser alcançado para a maioria dos casos de uso do CryptoxAI.
2. Medidas preventivas necessárias adotadas
Seja qual for a aplicação, estes são sempre necessários, independentemente de depender de recursos externos ou não!
Considere o aplicativo TEE como um contrato inteligente, não como um aplicativo back-end; mantenha uma frequência de atualização baixa e faça testes rigorosos.
A construção de programas TEE deve ser tão rigorosa quanto escrever, testar e atualizar contratos inteligentes. Assim como os contratos inteligentes, o TEE opera em um ambiente altamente sensível e imutável, onde erros ou comportamentos inesperados podem resultar em consequências graves, incluindo a perda total de fundos. Auditorias completas, testes abrangentes e as atualizações mínimas e cuidadosamente auditadas são essenciais para garantir a integridade e confiabilidade de aplicativos baseados em TEE.
Verificar código de auditoria e pipeline de construção
A segurança do aplicativo não depende apenas do código em si, mas também das ferramentas usadas no processo de construção. Um pipeline de construção seguro é crucial para evitar vulnerabilidades. TEE apenas garante que o código fornecido será executado conforme o esperado, mas não pode corrigir falhas introduzidas durante o processo de construção.
Para reduzir o risco, é necessário realizar testes e auditorias rigorosas no código para eliminar erros e evitar vazamentos de informações desnecessários. Além disso, a construção repetível desempenha um papel crucial, especialmente quando o código é desenvolvido por uma parte e utilizado por outra. A construção repetível permite que qualquer pessoa verifique se o programa executado dentro do TEE corresponde ao código-fonte original, garantindo transparência e confiabilidade. Sem uma construção repetível, é quase impossível determinar o conteúdo exato do programa executado dentro do TEE, o que compromete a segurança do aplicativo.
Por exemplo, o código-fonte do DeepWorm (um projeto que executa modelos de simulação de cérebro de vermes em TEE) é completamente aberto. Os programas executados no TEE são construídos de forma reprodutível usando pipelines Nix.
Usar bibliotecas auditadas ou verificadas
Ao lidar com dados sensíveis em programas TEE, utilize apenas bibliotecas auditadas para gerenciamento de chaves e processamento de dados privados. Bibliotecas não auditadas podem expor chaves e comprometer a segurança do aplicativo. Priorize dependências revisadas e focadas na segurança para manter a confidencialidade e integridade dos dados.
Prova sempre verificando do TEE
Os usuários que interagem com TEE devem verificar as provas remotas ou mecanismos de verificação gerados pelo TEE para garantir interações seguras e confiáveis. Sem essas verificações, o servidor pode manipular a resposta, tornando difícil distinguir entre a saída TEE real e os dados adulterados. As provas remotas fornecem evidências cruciais para a biblioteca de código e configuração executadas dentro do TEE, permitindo-nos determinar se o programa executado dentro do TEE corresponde ao esperado com base nas provas remotas.
A autenticação específica pode ser verificada on-chain (IntelSGX, AWSNitro) e validada off-chain usando provas de conhecimento-zero (IntelSGX, AWSNitro), ou pode ser verificada pelo próprio usuário ou por serviços de hospedagem (como t16z ou MarlinHub).
3. Dependendo do caso de uso, sugestão
Com base nos casos de uso e na estrutura da aplicação, as seguintes sugestões podem ajudar a tornar a sua aplicação mais segura.
Certifique-se de que a interação do usuário com o TEE seja sempre executada em um canal seguro
O servidor onde o TEE está localizado é essencialmente não confiável. Pode interceptar e modificar a comunicação. Em algumas situações, pode ser aceitável que o servidor leia os dados sem os modificar, enquanto em outras situações, mesmo a leitura dos dados pode ser inaceitável. Para mitigar esses riscos, é crucial estabelecer um canal de criptografia de ponta a ponta seguro entre o usuário e o TEE. No mínimo, certifique-se de que as mensagens contenham assinaturas para verificar sua autenticidade e origem. Além disso, os usuários precisam sempre verificar se o TEE fornece uma prova remota para verificar se estão se comunicando com o TEE correto. Isso garante a integridade e a confidencialidade da comunicação.
Por exemplo, Oyster pode suportar a emissão segura de TLS usando registros CAA e RFC8657. Além disso, ele fornece um protocolo TLS nativo chamado Scallop, que não depende do WebPKI.
Sabe-se que a memória TEE é transitória
A memória TEE é transitória, o que significa que quando a TEE é desligada, o seu conteúdo (incluindo chaves de criptografia) é perdido. Se não houver um mecanismo seguro para armazenar essas informações, dados críticos podem se tornar permanentemente inacessíveis, o que pode levar a problemas financeiros ou operacionais.
A rede de cálculo multipartidário (MPC) com sistemas de armazenamento descentralizados, como IPFS, pode ser utilizada como solução para este problema. A rede MPC divide a chave em vários nós, garantindo que nenhum nó individual possua a chave completa, ao mesmo tempo que permite que a rede reconstrua a chave quando necessário. Os dados criptografados com esta chave podem ser armazenados com segurança no IPFS.
Se necessário, a rede MPC pode fornecer chaves para um novo servidor TEE que execute a mesma imagem, desde que certas condições sejam cumpridas. Este método garante elasticidade e segurança robusta, mantendo a acessibilidade e confidencialidade dos dados, mesmo em ambientes não confiáveis.
Existe outra solução, ou seja, TEE encaminha transações relevantes para diferentes servidores MPC, os servidores MPC assinam e agregam as transações antes de as enviar para a cadeia de blocos. Este método é muito menos flexível e não pode ser usado para armazenar chaves de API, senhas ou qualquer dado arbitráio (sem um serviço de armazenamento de terceiros confiável).
Para casos de uso de segurança crítica, vale a pena tentar reduzir as dependências periféricas o máximo possível, mesmo que isso signifique sacrificar a experiência do desenvolvedor. Por exemplo, o Dstack vem com um kernel mínimo baseado em Yocto, que contém apenas os módulos necessários para o funcionamento do Dstack. Pode até valer a pena usar tecnologias mais antigas, como SGX (Superior a TDX), pois essa tecnologia não exige que o bootloader ou o sistema operacional sejam parte do TEE.
Isolamento físico
Ao isolar fisicamente o TEE de possíveis intervenções humanas, a segurança do TEE pode ser ainda mais reforçada. Embora possamos confiar na segurança física dos data centers ao hospedar servidores TEE e provedores de nuvem, projetos como Spacecoin estão explorando uma alternativa bastante interessante - o espaço. O artigo do SpaceTEE confia em medidas de segurança, como a medição do momento de inércia após o lançamento, para verificar se os satélites estão desviando do esperado ao entrar em órbita.
Múltiplos provadores de validade
Assim como o Ethereum depende da implementação de vários clientes para reduzir o risco de bugs que afetam toda a rede, o multiprovers utiliza diferentes abordagens de TEE para aumentar a segurança e a resiliência. Ao executar as mesmas etapas de cálculo em várias plataformas de TEE, a verificação múltipla garante que uma falha em uma implementação de TEE não comprometa todo o aplicativo. Embora esse método exija que o processo de cálculo seja determinístico, ou defina consenso entre diferentes abordagens de implementação de TEE em casos de não determinismo, ele também oferece vantagens significativas, como isolamento de falhas, redundância e verificação cruzada, tornando-o uma escolha sólida para aplicativos que exigem garantias de confiabilidade.
TEE has clearly become a very exciting field. As mentioned earlier, the ubiquity of AI and its continuous access to user-sensitive data means that large technology companies like Apple and NVIDIA are using TEE in their products and offering it as part of their products.
Por outro lado, a comunidade criptográfica sempre deu muita importância à segurança. À medida que os desenvolvedores tentam expandir os aplicativos e casos de uso on-chain, temos visto que o TEE se tornou popular como uma solução que oferece um equilíbrio correto entre funcionalidade e suposições de confiança. Embora o TEE não minimize a confiança como uma solução ZK completa, esperamos que o TEE se torne a maneira pela qual as empresas Web3 e as grandes empresas de tecnologia comecem a se integrar lentamente.
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Guia do Desenvolvedor para TEE
Autores: prateek, roshan, siddhartha & linguine (Marlin), krane (Asula)Compilado por: Shew, REALM de Deus
Desde que a Apple anunciou a introdução de nuvens privadas e a NVIDIA ofereceu cálculos confidenciais nas GPUs, o Ambiente de Execução Confidencial (TEE) tornou-se cada vez mais popular. A garantia de sua confidencialidade ajuda a proteger os dados dos usuários (possivelmente incluindo chaves privadas), enquanto o isolamento garante que a execução de programas implantados sobre ele não seja adulterada - quer por humanos, outros programas ou sistemas operacionais. Portanto, não é surpreendente que o TEE seja amplamente utilizado na construção de produtos no campo da criptografia x IA.
Como qualquer nova tecnologia, TEE está a passar por um período de experimentação otimista. Este artigo tem como objetivo fornecer um guia conceitual básico para desenvolvedores e leitores em geral, para que possam compreender o que é TEE, o modelo de segurança de TEE, vulnerabilidades comuns e as melhores práticas de segurança ao usar TEE. (Nota: Para facilitar a compreensão do texto, substituímos intencionalmente os termos de TEE por palavras equivalentes mais simples).
O que é TEE
TEE é um ambiente isolado em um processador ou centro de dados, onde os programas podem ser executados sem interferência de qualquer outra parte do sistema. Para evitar interferências de outras partes, precisamos de uma série de designs, incluindo controle de acesso rigoroso, que controla o acesso de outras partes do sistema aos programas e dados dentro do TEE. Atualmente, o TEE está em toda parte, em telefones, servidores, PCs e ambientes de nuvem, tornando-o facilmente acessível e acessível.
O conteúdo acima pode parecer vago e abstrato, na verdade, a implementação do TEE em diferentes servidores e fornecedores de nuvem é diferente, mas o objetivo fundamental é evitar a interferência de outros programas no TEE.
A maioria dos leitores provavelmente usará informações de biometria para fazer login em dispositivos, como desbloquear um telefone com impressão digital. Mas como podemos garantir que aplicativos maliciosos, sites ou sistemas operacionais com jailbreak não possam acessar e roubar essas informações biométricas? Na verdade, além de criptografar os dados, os circuitos no dispositivo TEE simplesmente não permitem que nenhum programa acesse a área de memória e processador ocupada por dados sensíveis.
A carteira de hardware é outro exemplo de cenário de aplicação TEE. A carteira de hardware é conectada ao computador e se comunica com ele em uma sandbox, mas o computador não pode acessar diretamente as palavras mnemônicas armazenadas na carteira de hardware. Em ambos os casos acima, os usuários confiam que o fabricante do dispositivo pode projetar corretamente o chip e fornecer atualizações de firmware adequadas para impedir a exportação ou visualização de dados confidenciais dentro do TEE.
Modelo de segurança
Infelizmente, há muitos tipos de implementações de TEE, e essas diferentes implementações (IntelSGX, IntelTDX, AMDSEV, AWSNitroEnclaves, ARMTrustZone) exigem modelos de segurança independentes para análise de modelagem. No restante deste artigo, discutiremos principalmente IntelSGX, TDX e AWSNitro, porque esses sistemas TEE têm mais usuários e ferramentas de desenvolvimento totalmente disponíveis. Esses sistemas acima também são os sistemas TEE mais comuns dentro da Web3.
Em geral, o fluxo de trabalho do aplicativo implantado no TEE é o seguinte:
Obviamente, existem 3 riscos potenciais aqui:
Felizmente, agora o TEE tem soluções para eliminar os riscos mencionados, ou seja, Construções Reproduzíveis(Reproducible Builds) e Atteststations Remotas(Remote Atteststations).
Então, o que é construção repetível? O desenvolvimento de software moderno muitas vezes requer a importação de uma grande quantidade de dependências, como ferramentas externas, bibliotecas ou estruturas, etc. Esses arquivos de dependência também podem ter problemas de segurança. Agora, soluções como o npm usam o hash do código correspondente aos arquivos de dependência como identificador único. Quando o npm descobre que um arquivo de dependência não corresponde ao valor de hash registrado, ele pode considerar que o arquivo de dependência foi modificado.
A construção repetível pode ser considerada um conjunto de normas cujo objetivo é garantir que, independentemente do dispositivo em que o código é executado, desde que a construção seja feita de acordo com o processo pré-definido, o valor de hash será o mesmo. Claro, na prática, podemos usar outros produtos além do hash como identificadores, que chamamos de medição de código (.
O Nix é uma ferramenta comum para construção replicável. Depois que o código-fonte do programa é público, qualquer pessoa pode verificar o código para garantir que os desenvolvedores não inseriram conteúdo malicioso, e qualquer pessoa pode usar o Nix para construir o código e verificar se o artefato construído tem a mesma medição de código/hash que o artefato implantado pelo projeto no ambiente de produção. No entanto, como podemos saber o valor de medição de código do programa no TEE? Aqui entra em jogo o conceito de "prova remota".
![])https://img.gateio.im/social/moments-de22e99c8194fa04f29ee5416aebcd03(
Prova Remota é uma mensagem de assinatura do provedor da TEE (ambiente de execução confiável), que inclui métricas do código do programa, versão da plataforma TEE, etc. A prova remota permite que observadores externos saibam que um programa está sendo executado em um local seguro (TEE real da versão xx) que não pode ser acessado por ninguém.
![])https://img.gateio.im/social/moments-e4900d340dd1c812355c38739632d2a6(
A capacidade de construção repetida e a prova remota permitem que qualquer utilizador saiba o código real em execução no TEE e as informações de versão da plataforma TEE, impedindo assim que os desenvolvedores ou servidores ajam maliciosamente.
No entanto, no caso do TEE, ainda é necessário confiar no fornecedor. Se o fornecedor de TEE agir mal, ele pode falsificar a prova remota diretamente. Portanto, se o fornecedor for considerado um possível meio de ataque, evite depender apenas do TEE e é melhor combiná-lo com ZK ou um protocolo de consenso.
O encanto do TEE
Do nosso ponto de vista, as características TEE são especialmente populares, especialmente a facilidade de implantação para o agente de IA, principalmente pelos seguintes motivos:
Seja bom ou ruim, atualmente é difícil encontrar alternativas para muitos casos de uso de TEE. Acreditamos que a introdução de TEE amplia ainda mais o espaço de desenvolvimento de aplicativos on-chain, o que pode impulsionar a criação de novos cenários de aplicativos.
TEE não é uma bala de prata
Os programas em execução no TEE ainda são suscetíveis a uma série de ataques e erros. Assim como os contratos inteligentes, eles podem enfrentar uma série de problemas. Para facilitar, classificamos as possíveis vulnerabilidades da seguinte forma:
Desleixo do desenvolvedor
Seja intencional ou não, os desenvolvedores podem comprometer a segurança dos programas no TEE por meio de códigos intencionais ou não intencionais. Isso inclui:
Vulnerabilidades de tempo de execução
Os desenvolvedores, mesmo os mais cuidadosos, podem se tornar vítimas de vulnerabilidades em tempo de execução. Os desenvolvedores devem considerar cuidadosamente se algum dos seguintes itens pode afetar a segurança de seu projeto:
Por exemplo, em TEE, pode ser executado um mecanismo de correspondência de transações criptográficas que não consegue garantir uma ordenação justa (resistência a MEV), uma vez que o router/gateway/host ainda pode descartar, atrasar ou priorizar com base no endereço IP de origem dos pacotes de dados.
Defeito de Arquitetura
A pilha de tecnologia utilizada pelo aplicativo TEE deve ser tratada com cautela. Ao construir um aplicativo TEE, podem surgir os seguintes problemas:
Problemas de operação
Por último, mas não menos importante, existem algumas considerações práticas sobre como realmente operar um servidor que executa programas TEE:
Construir programas seguros de TEE
Dividimos nossas sugestões em vários pontos:
1. A solução mais segura: sem dependências externas
Criar aplicativos altamente seguros pode envolver a eliminação de dependências externas, como entrada externa, APIs ou serviços, reduzindo assim a superfície de ataque. Esse método garante que o aplicativo funcione de forma independente, sem interações externas que possam comprometer sua integridade ou segurança. Embora essa estratégia possa limitar a diversidade de recursos do programa, ela pode fornecer um alto nível de segurança.
Se o modelo for executado localmente, esse nível de segurança pode ser alcançado para a maioria dos casos de uso do CryptoxAI.
2. Medidas preventivas necessárias adotadas
Seja qual for a aplicação, estes são sempre necessários, independentemente de depender de recursos externos ou não!
Considere o aplicativo TEE como um contrato inteligente, não como um aplicativo back-end; mantenha uma frequência de atualização baixa e faça testes rigorosos.
A construção de programas TEE deve ser tão rigorosa quanto escrever, testar e atualizar contratos inteligentes. Assim como os contratos inteligentes, o TEE opera em um ambiente altamente sensível e imutável, onde erros ou comportamentos inesperados podem resultar em consequências graves, incluindo a perda total de fundos. Auditorias completas, testes abrangentes e as atualizações mínimas e cuidadosamente auditadas são essenciais para garantir a integridade e confiabilidade de aplicativos baseados em TEE.
Verificar código de auditoria e pipeline de construção
A segurança do aplicativo não depende apenas do código em si, mas também das ferramentas usadas no processo de construção. Um pipeline de construção seguro é crucial para evitar vulnerabilidades. TEE apenas garante que o código fornecido será executado conforme o esperado, mas não pode corrigir falhas introduzidas durante o processo de construção.
Para reduzir o risco, é necessário realizar testes e auditorias rigorosas no código para eliminar erros e evitar vazamentos de informações desnecessários. Além disso, a construção repetível desempenha um papel crucial, especialmente quando o código é desenvolvido por uma parte e utilizado por outra. A construção repetível permite que qualquer pessoa verifique se o programa executado dentro do TEE corresponde ao código-fonte original, garantindo transparência e confiabilidade. Sem uma construção repetível, é quase impossível determinar o conteúdo exato do programa executado dentro do TEE, o que compromete a segurança do aplicativo.
Por exemplo, o código-fonte do DeepWorm (um projeto que executa modelos de simulação de cérebro de vermes em TEE) é completamente aberto. Os programas executados no TEE são construídos de forma reprodutível usando pipelines Nix.
Usar bibliotecas auditadas ou verificadas
Ao lidar com dados sensíveis em programas TEE, utilize apenas bibliotecas auditadas para gerenciamento de chaves e processamento de dados privados. Bibliotecas não auditadas podem expor chaves e comprometer a segurança do aplicativo. Priorize dependências revisadas e focadas na segurança para manter a confidencialidade e integridade dos dados.
Prova sempre verificando do TEE
Os usuários que interagem com TEE devem verificar as provas remotas ou mecanismos de verificação gerados pelo TEE para garantir interações seguras e confiáveis. Sem essas verificações, o servidor pode manipular a resposta, tornando difícil distinguir entre a saída TEE real e os dados adulterados. As provas remotas fornecem evidências cruciais para a biblioteca de código e configuração executadas dentro do TEE, permitindo-nos determinar se o programa executado dentro do TEE corresponde ao esperado com base nas provas remotas.
A autenticação específica pode ser verificada on-chain (IntelSGX, AWSNitro) e validada off-chain usando provas de conhecimento-zero (IntelSGX, AWSNitro), ou pode ser verificada pelo próprio usuário ou por serviços de hospedagem (como t16z ou MarlinHub).
3. Dependendo do caso de uso, sugestão
Com base nos casos de uso e na estrutura da aplicação, as seguintes sugestões podem ajudar a tornar a sua aplicação mais segura.
Certifique-se de que a interação do usuário com o TEE seja sempre executada em um canal seguro
O servidor onde o TEE está localizado é essencialmente não confiável. Pode interceptar e modificar a comunicação. Em algumas situações, pode ser aceitável que o servidor leia os dados sem os modificar, enquanto em outras situações, mesmo a leitura dos dados pode ser inaceitável. Para mitigar esses riscos, é crucial estabelecer um canal de criptografia de ponta a ponta seguro entre o usuário e o TEE. No mínimo, certifique-se de que as mensagens contenham assinaturas para verificar sua autenticidade e origem. Além disso, os usuários precisam sempre verificar se o TEE fornece uma prova remota para verificar se estão se comunicando com o TEE correto. Isso garante a integridade e a confidencialidade da comunicação.
Por exemplo, Oyster pode suportar a emissão segura de TLS usando registros CAA e RFC8657. Além disso, ele fornece um protocolo TLS nativo chamado Scallop, que não depende do WebPKI.
Sabe-se que a memória TEE é transitória
A memória TEE é transitória, o que significa que quando a TEE é desligada, o seu conteúdo (incluindo chaves de criptografia) é perdido. Se não houver um mecanismo seguro para armazenar essas informações, dados críticos podem se tornar permanentemente inacessíveis, o que pode levar a problemas financeiros ou operacionais.
A rede de cálculo multipartidário (MPC) com sistemas de armazenamento descentralizados, como IPFS, pode ser utilizada como solução para este problema. A rede MPC divide a chave em vários nós, garantindo que nenhum nó individual possua a chave completa, ao mesmo tempo que permite que a rede reconstrua a chave quando necessário. Os dados criptografados com esta chave podem ser armazenados com segurança no IPFS.
Se necessário, a rede MPC pode fornecer chaves para um novo servidor TEE que execute a mesma imagem, desde que certas condições sejam cumpridas. Este método garante elasticidade e segurança robusta, mantendo a acessibilidade e confidencialidade dos dados, mesmo em ambientes não confiáveis.
![])https://img.gateio.im/social/moments-429ced8c56f3dff6c933327cf8963516(
Existe outra solução, ou seja, TEE encaminha transações relevantes para diferentes servidores MPC, os servidores MPC assinam e agregam as transações antes de as enviar para a cadeia de blocos. Este método é muito menos flexível e não pode ser usado para armazenar chaves de API, senhas ou qualquer dado arbitráio (sem um serviço de armazenamento de terceiros confiável).
![])https://img.gateio.im/social/moments-37203038abc830a2f70f702c7eeb0e7b(
Reduzir a superfície de ataque
Para casos de uso de segurança crítica, vale a pena tentar reduzir as dependências periféricas o máximo possível, mesmo que isso signifique sacrificar a experiência do desenvolvedor. Por exemplo, o Dstack vem com um kernel mínimo baseado em Yocto, que contém apenas os módulos necessários para o funcionamento do Dstack. Pode até valer a pena usar tecnologias mais antigas, como SGX (Superior a TDX), pois essa tecnologia não exige que o bootloader ou o sistema operacional sejam parte do TEE.
Isolamento físico
Ao isolar fisicamente o TEE de possíveis intervenções humanas, a segurança do TEE pode ser ainda mais reforçada. Embora possamos confiar na segurança física dos data centers ao hospedar servidores TEE e provedores de nuvem, projetos como Spacecoin estão explorando uma alternativa bastante interessante - o espaço. O artigo do SpaceTEE confia em medidas de segurança, como a medição do momento de inércia após o lançamento, para verificar se os satélites estão desviando do esperado ao entrar em órbita.
Múltiplos provadores de validade
Assim como o Ethereum depende da implementação de vários clientes para reduzir o risco de bugs que afetam toda a rede, o multiprovers utiliza diferentes abordagens de TEE para aumentar a segurança e a resiliência. Ao executar as mesmas etapas de cálculo em várias plataformas de TEE, a verificação múltipla garante que uma falha em uma implementação de TEE não comprometa todo o aplicativo. Embora esse método exija que o processo de cálculo seja determinístico, ou defina consenso entre diferentes abordagens de implementação de TEE em casos de não determinismo, ele também oferece vantagens significativas, como isolamento de falhas, redundância e verificação cruzada, tornando-o uma escolha sólida para aplicativos que exigem garantias de confiabilidade.
![])https://img.gateio.im/social/moments-da3100eaa6119891428bb2346de3f57e(
Olhando para o futuro
TEE has clearly become a very exciting field. As mentioned earlier, the ubiquity of AI and its continuous access to user-sensitive data means that large technology companies like Apple and NVIDIA are using TEE in their products and offering it as part of their products.
Por outro lado, a comunidade criptográfica sempre deu muita importância à segurança. À medida que os desenvolvedores tentam expandir os aplicativos e casos de uso on-chain, temos visto que o TEE se tornou popular como uma solução que oferece um equilíbrio correto entre funcionalidade e suposições de confiança. Embora o TEE não minimize a confiança como uma solução ZK completa, esperamos que o TEE se torne a maneira pela qual as empresas Web3 e as grandes empresas de tecnologia comecem a se integrar lentamente.