Muitas pessoas, ao mencionar o TEE de @NewtonProtocol , a primeira reação é: “a área de criptografia em hardware é segura o suficiente”, guardando a chave privada e a lógica do proxy dentro de um enclave da Intel SGX. Mas poucos fazem uma pergunta meio óbvia: na prova do TEE, afinal, o que exatamente está sendo provado?
A resposta é bem limitada. A autenticação remota só prova que um trecho específico de código foi carregado na área segura e que foi executado ali, sem que a memória tenha sido adulterada. Em outras palavras, o “selo” do TEE para você é: “o ambiente é confiável” e “o código está íntegro”. Porém, se o próprio código contiver uma lógica temporizada que, em certa altura de bloco, transfira todo o dinheiro para o endereço previamente definido pelo atacante, o TEE ainda assim executará obedientemente e gerará uma prova remota aparentemente perfeita, dizendo que está tudo normal.
Isso não se parece com as caixas-fortes do mundo real. No banco, ao abrir a caixa, os funcionários ainda precisam de duas pessoas presentes, além de haver monitoramento para verificar a intenção quadro a quadro. O TEE não tem capacidade de “análise de intenção”; na essência, ele é um robô fiel. A Newton pretende usar circuitos de ZK para verificar, fora do TEE, se cada etapa da operação do proxy excede alguma autoridade. À primeira vista parece uma dupla camada de segurança, mas se você desmontar cuidadosamente a lógica de verificação, vai perceber que o objeto da validação ZK também é a saída do código, e não a motivação do código. Enquanto o código malicioso estiver escondido dentro do que as regras permitem, ele nunca poderá ser marcado como violação.
$BTC
Atualmente, o que eu vejo é que a equipe usou a solução da Phala Cloud: o código é aberto e pode ser verificado. Mas código aberto não significa que todo mundo olhou, e muito menos que não exista estado oculto em uma máquina de estados. Pessoalmente, eu só consideraria entregar posições de estabilidade de médio e longo prazo quando, além das auditorias formais oficiais de segurança, pelo menos duas instituições independentes tiverem feito análise de intenção do código para o template de proxy padrão. Caso contrário, esse “selo de segurança” do hardware, para mim, acaba virando antes um rótulo de confiança que precisa de cautela.
#Newt $NEWT @NewtonProtocol
A resposta é bem limitada. A autenticação remota só prova que um trecho específico de código foi carregado na área segura e que foi executado ali, sem que a memória tenha sido adulterada. Em outras palavras, o “selo” do TEE para você é: “o ambiente é confiável” e “o código está íntegro”. Porém, se o próprio código contiver uma lógica temporizada que, em certa altura de bloco, transfira todo o dinheiro para o endereço previamente definido pelo atacante, o TEE ainda assim executará obedientemente e gerará uma prova remota aparentemente perfeita, dizendo que está tudo normal.
Isso não se parece com as caixas-fortes do mundo real. No banco, ao abrir a caixa, os funcionários ainda precisam de duas pessoas presentes, além de haver monitoramento para verificar a intenção quadro a quadro. O TEE não tem capacidade de “análise de intenção”; na essência, ele é um robô fiel. A Newton pretende usar circuitos de ZK para verificar, fora do TEE, se cada etapa da operação do proxy excede alguma autoridade. À primeira vista parece uma dupla camada de segurança, mas se você desmontar cuidadosamente a lógica de verificação, vai perceber que o objeto da validação ZK também é a saída do código, e não a motivação do código. Enquanto o código malicioso estiver escondido dentro do que as regras permitem, ele nunca poderá ser marcado como violação.
$BTC
Atualmente, o que eu vejo é que a equipe usou a solução da Phala Cloud: o código é aberto e pode ser verificado. Mas código aberto não significa que todo mundo olhou, e muito menos que não exista estado oculto em uma máquina de estados. Pessoalmente, eu só consideraria entregar posições de estabilidade de médio e longo prazo quando, além das auditorias formais oficiais de segurança, pelo menos duas instituições independentes tiverem feito análise de intenção do código para o template de proxy padrão. Caso contrário, esse “selo de segurança” do hardware, para mim, acaba virando antes um rótulo de confiança que precisa de cautela.
#Newt $NEWT @NewtonProtocol
你觉得代码动机能被审计吗
0%
你会盲信TEE的安全章吗
0%
双层保险真能防背锅吗
0%
0 Votos • Votação encerrada