Segurança Blockchain¶

Os sistemas blockchain falham nos limites. Uma assinatura pode ser matematicamente válida e ainda autorizar um roubo. Um contrato pode executar exatamente como escrito enquanto viola a suposição econômica que seus desenvolvedores pretendiam codificar. Uma ponte pode executar contratos corretos e ainda falhar porque chaves de validação suficientes foram comprometidas. O trabalho de segurança começa nomeando o ativo, a autoridade que pode movê-lo, e cada suposição entre a intenção de um usuário e a transição final do estado.

Esta seção segue esses limites do usuário para dentro. Começa com chaves, frases de recuperação, phishing, assinaturas e aprovações de tokens. Em seguida, cobre falhas de contrato, ordens de transação, pontes, atualizações, auditorias e verificação formal. Os capítulos descrevem ataques o suficiente para explicar a falha da engenharia e sua mitigação. Eles não fornecem instruções operacionais para direcionar sistemas vivos.

Um modelo de ameaça de trabalho¶

Um modelo de ameaça responde a quatro perguntas antes de alguém escolher uma ferramenta:

O que deve permanecer protegido? Chaves privadas, autoridade de retirada, controle de governança, integridade de preços, invariantes contábeis, disponibilidade e dados confidenciais do usuário são ativos diferentes.
Quem pode atuar? Usuários, administradores, validadores, sequenciadores, relés, operadores de oráculos, contratos externos, frontends comprometidos e atacantes têm capacidades diferentes.
Em que se deve confiar? Código, hardware, estado do navegador, DNS, serviços off-chain, sinais multisig, chaves de atualização, feeds de dados e incentivos econômicos podem estar dentro do limite de confiança.
Como é que o fracasso aparece? O roubo é apenas um resultado. Os fundos podem ser congelados, a contabilidade pode derivar, as retiradas podem tornar-se insolvente, a governança pode empatar, ou um serviço pode devolver dados obsoletos enquanto parece saudável.

O mesmo componente pode ser seguro sob um modelo e inseguro sob outro. Um único administrador pode ser aceitável para um protótipo local e imprudente para um contrato que detenha depósitos públicos. Um preço ponderado em tempo pode resistir à manipulação de um bloco, mas permanecer errado durante uma luxação prolongada do mercado. As reivindicações de segurança precisam da suposição anexada.

Capítulos¶

Roubo de Chave Privada: como a autoridade de assinatura é copiada, abusada e contida
Roubo de Frase de Sementes: por que uma frase de recuperação é um segredo mestre portátil
Phishing: como os atacantes substituem a interface, o destino ou solicitam a aprovação de um usuário
Assinaturas Maléficas: criptografia válida ligada ao significado hostil
Ataques de aprovação: autoridade simbólica persistente e os limites da revogação
Reentrância: fluxo de controle externo antes da liquidação da contabilidade interna
Controle de acesso: papéis, caminhos de administração, inicialização e menos privilégio
Insetos Inteiros e Precisão: unidades, sentido de arredondamento, truncamento e deriva contabilística
Manipulação do Oracle: quando um contrato confia num preço que um atacante pode mover
Flash Empréstimo Ataca: capital atômico como um amplificador em vez de uma causa raiz
Execução frontal: visibilidade da transação e ordenação adversarial
MEV: valor extraído através da inclusão, exclusão e ordenação
Explorações da Ponte: compromisso de sinal, falha de verificação e replay entre cadeias
Riscos de atualização: lógica mutável, compatibilidade de armazenamento e autoridade concentrada
Auditoria inteligente de contratos: o que uma revisão pode encontrar e o que não pode provar
Verificação formal: provando propriedades de um modelo contra uma especificação escrita

Outras leituras¶

← Anterior: Starknet · Voltar ao Conteúdo Completo · Próximo: Chave privada Roubo →