Guia informal de modelos de ameaça, por Soatok
(soatok.blog)- Modelo de ameaça não termina em listar o que precisa ser protegido e quem é o atacante; ele só serve para orientar decisões de projeto quando também explicita relações entre ativos, premissas e até ameaças deliberadamente excluídas
- Um bom modelo trata os ativos não como uma lista, mas como um grafo, estreitando entradas, saídas e dependências dos componentes para verificar riscos e pressupostos
- Se uma premissa falha, os riscos aceitos também precisam ser revistos; o ataque Invisible Salamanders mostra um problema quando recursos de denúncia de abuso em E2EE entram em conflito com a premissa do AEAD de “uma única chave válida por mensagem”
- O caso do publickey.directory separa premissas, ativos, atores e estados de risco, mas não é perfeito; já o modelo de ameaça do Matrix v1.18 se parece mais com uma lista de tipos de ataque e deixa de fora criptografia e gestão de chaves
- A modelagem de ameaças ajuda a separar restrições de escolha tecnológica e riscos reais em temas como autenticação com passkeys, projeto de E2EE distribuído e debates sobre PQC, levando a decisões de projeto melhores
Perguntas que um modelo de ameaça precisa responder
- Um modelo de ameaça pode fazer parte de um processo formal de cibersegurança, mas também pode ser aplicado de forma informal na fase de projeto e arquitetura de um novo produto ou serviço
- No mínimo, ele precisa responder às seguintes perguntas
- O que está sendo protegido?
- Quem ou o que está tentando comprometer o que está sendo protegido?
- De que forma o atacante pode atacar?
- O que será feito para impedir esse ataque?
- Dá para chamar isso de modelo de ameaça só com essas quatro perguntas, mas na prática detalhes importantes costumam ficar de fora
- Perguntas adicionais necessárias incluem:
- Como os ativos protegidos se conectam entre si?
- Quais premissas estão sendo adotadas?
- Quais ameaças foram deliberadamente deixadas de fora?
- Como não é possível cobrir todos os ataques futuros, é preciso explicitar as ameaças excluídas
- Se as premissas estiverem erradas, o modelo fica incompleto, e a lista de riscos já aceitos também precisa ser reavaliada
- Um modelo de ameaça não deve ser um retrato estático de um momento específico, mas sim um documento vivo que é atualizado quando necessário
Problemas que surgem quando premissas falham
- O ataque Invisible Salamanders pode quebrar recursos de denúncia de abuso quando eles são introduzidos em alguns projetos de mensageria E2EE
- Esse ataque se cruza com premissas de esquemas AEAD como AES-GCM e ChaCha20-Poly1305
- Esses esquemas embutem a premissa de que existe uma única chave válida para uma determinada mensagem
- Se você introduz várias chaves válidas para uma mesma mensagem, ou cria confused deputies, você sai das garantias de segurança do algoritmo
- Escrever as premissas com clareza ajuda a identificar seus próprios unknown unknowns
- Não precisa ser perfeito, mas precisa deixar claro quais são as bases assumidas
Como começar a modelagem de ameaças
- Para fazer modelagem de ameaças profissionalmente, recomenda-se ler o Threat Modeling Manifesto
- Na prática, o ponto de partida é anotar rapidamente os 7 itens em um formato fácil de copiar e reutilizar
- Depois, desenha-se os componentes do sistema analisado em papel ou em uma ferramenta digital
- Se algum widget se comunica diretamente com outro, depende dele ou interage com ele, essa relação deve ser marcada
- A forma de representar as relações pode ser qualquer uma que seja mais útil para quem está fazendo o trabalho
- Depois de envolver o grafo inteiro em uma caixa, a ideia é ir estreitando essa caixa para focar em cada componente
- Em cada iteração, registram-se as entradas e saídas do componente
- Responde-se às 7 perguntas sempre que possível
- Depois de descer o quanto o nível de abstração permitir, faz-se um brainstorming sobre quais premissas estão sendo assumidas nas camadas que não foram investigadas mais a fundo
- Pode ser que um banco de dados não dependa da segurança de X25519 do mesmo jeito que um load balancer depende
- Se existir uma relação inadequada, como um banco de dados recebendo um feed RSS, isso deve ser registrado e, se possível, eliminado
O caso do publickey.directory
- O trabalho para oferecer transparência de chaves no Fediverse é acompanhado em publickey.directory
- Esse trabalho começou com a especificação public-key-directory-specification, que inclui um modelo de ameaça
- Esse modelo de ameaça é composto pelas seguintes seções
- Premissas
- Ativos
- Nomes de atores e papéis, incluindo atacantes e pessoas a serem protegidas
- Riscos e estados de risco
- Os estados de risco são divididos em quatro categorias
- Prevented by design: o ataque não funciona por causa do projeto
- Mitigated: o ataque não deve ter sucesso se as premissas estiverem corretas
- Addressable: há formas de mitigar, mas elas exigem esforço ou atenção, e os operadores precisam saber disso
- Open: é um risco que não pode ser mitigado ou que não será mitigado, então o ataque tem sucesso
- Mesmo esse modelo de ameaça não é perfeito
- Ele não conecta completamente, em um grafo fácil de ler por humanos, as relações entre ativos e atores
- A seção de riscos pode ter pontos cegos que não foram considerados
- Pode haver premissas importantes para a segurança do sistema que ficaram de fora
O contraste entre Matrix e Signal
- O Security Threat Model do Matrix v1.18 lista tipos de ataque como negação de serviço, spoofing, spam e espionagem
- Esse documento tem os seguintes problemas
- Ele se parece mais com uma lista de tipos de ataque
- Não há uma lista de premissas
- Não há uma lista de ativos nem relações entre ativos
- A lista de ataques é incompleta
- Embora o Matrix seja promovido como mensageiro E2EE, o modelo de ameaça não trata de criptografia nem de gestão de chaves
- O modelo de ameaça do Matrix não mudou muito desde a v1.1, apesar de, nesse meio-tempo, terem surgido divulgações de vulnerabilidades e dois ataques criptográficos adicionais de Lotte
- Ainda assim, o Matrix pelo menos tem um modelo de ameaça
- O Signal fornece especificações técnicas, mas deixa para o usuário deduzir o modelo de ameaça por conta própria
- Mesmo um modelo de ameaça ruim ainda é melhor do que não ter modelo de ameaça nenhum
Como um modelo de ameaça melhora o projeto
- Em segurança, é comum ouvir o ditado de que o defensor precisa acertar sempre, enquanto o atacante só precisa acertar uma vez
- Mas, se o defensor estiver suficientemente preparado, ele pode definir o terreno em que o atacante será obrigado a se mover
- Uma defesa em profundidade de verdade inclui entender bem o modelo de ameaça para empurrar o atacante para becos sem saída previsíveis
-
Prevenção de credential stuffing
- Credential stuffing é um ataque simples que continua sendo eficaz demais na prática
- A razão é que as pessoas reutilizam senhas
- Como é difícil para usuários memorizar várias senhas únicas e seguras, gerenciadores de senhas foram por um tempo uma mitigação razoável
- Hoje, passkeys são tratadas como uma opção melhor
- Passkeys são uma forma mais amigável de levar a autenticação a usar criptografia assimétrica
- No melhor cenário, usam-se tokens de segurança em hardware como SoloKeys ou YubiKeys
- No caso mais comum, isso é oferecido pelo sistema operacional ou por um gerenciador de senhas
- Para evitar credential stuffing e ataques simples parecidos, o projeto precisa incluir:
- a aplicação deve ser projetada para exigir passkeys
- o usuário deve poder registrar várias passkeys, ou pelo menos ser obrigado a cadastrar uma de backup
- deve existir um caminho de break glass para que um administrador adicione uma nova passkey para usuários que perderam todas as credenciais
- essa ação administrativa deve ficar registrada em logs de uma forma que o administrador não possa censurar
- se possível, não deve haver suporte algum a senha para autenticação
- senhas para derivação de chave criptográfica podem ser aceitáveis em outro contexto
- As passkeys tornam phishing impossível porque, no registro, a credencial fica criptograficamente vinculada ao nome de domínio
- Mesmo com custo de onboarding, as passkeys podem reduzir ainda mais a carga de suporte causada por credential stuffing e phishing
- Ao eliminar a expectativa irreal de que pessoas consigam memorizar segredos de alta entropia e nunca reutilizá-los, várias classes de ataque desaparecem e a usabilidade também melhora
- O texto cita a frase de Avi Douglen: “segurança sacrificada em nome da usabilidade sacrifica a segurança”
E2EE distribuído e modelos de ameaça
- Há duas propostas em discussão para E2EE em mensagens diretas
- a especificação ActivityPub E2EE, voltada a software do Fediverse, como DMs privadas do Mastodon
- projetos como a Germ Network, com objetivo parecido em ATProto e BlueSky
- Em algum momento, os dois projetos consideraram usar MLS como protocolo de gestão de chaves para conversas E2EE
- Em sistemas descentralizados, o MLS tem duas restrições importantes
- O MLS especifica um conceito abstrato chamado Authentication Service
- A segurança da ratcheting tree que sustenta os epochs do MLS depende da ordem das mensagens
- No ActivityPub, a primeira restrição pode ser tratada com transparência de chaves, mas ainda seria preciso especificar como lidar com vários KeyUpdate concorrendo entre vários servidores
- A situação em ATProto e BlueSky é mais complicada
- ATProto não tem instâncias como o Fediverse
- Em análise de segurança, ele quase precisa ser tratado como P2P
- Pode ser necessário um protocolo complexo que garanta ordem de mensagens em um sistema distribuído, como o algoritmo de consenso Raft
- Ou então será preciso pular o MLS e adotar E2EE pairwise, abrindo mão da abstração de grupos
- Se a meta de segurança é confidencialidade de mensagens entre usuários e a hospedagem também será distribuída, o design em estilo blockchain do ATProto cria um obstáculo para o uso dos protocolos padronizados e eficientes de acordo de chave em grupo disponíveis hoje
- A modelagem de ameaças consegue revelar esse tipo de restrição de projeto já na fase inicial de desenho
O papel da modelagem de ameaças no debate sobre PQC
- Em torno das construções híbridas pós-quânticas, a lista de discussão do grupo de trabalho de TLS da IETF está debatendo um RFC para estabelecer code points de ML-KEM não híbrido
- A discussão parte das seguintes premissas
- ML-KEM não é um projeto da NSA
- O principal autor é Peter Schwabe, que colaborou com Daniel J. Bernstein e com a biblioteca criptográfica NaCl, e vive na Alemanha
- Outros autores também estão em diferentes partes da Europa
- Como mostra o texto de Sophie Schmieg, a teoria da informação exclui a possibilidade de um backdoor em ML-KEM
- O ML-KEM foi escolhido após um esforço público, internacional e de 10 anos de padronização conduzido pelo NIST
- NIST, FIPS e NSA exigem ML-KEM e ML-DSA não híbridos em sistemas sigilosos
- O rascunho da IETF especifica ML-KEM não híbrido e o marca como Recommend=N
- O RFC de KEM híbrido deve ser marcado como Recommend=Y, o que significa que KEM híbrido continua sendo a opção preferida em relação ao não híbrido
- Um sistema configurado para sempre usar KEM híbrido não sofre perda de segurança mesmo que o RFC de ML-KEM seja publicado
- O Google Chrome já oferece suporte a ML-KEM não híbrido, e isso não vai mudar mesmo que a IETF não publique um RFC
- O efeito prático desse RFC é aliviar restrições processuais para organizações que precisam seguir CNSA 2.0, FIPS 140-3 ou regras semelhantes e necessitam de um número estável de RFC da IETF, e não apenas um Internet Draft
- Esse tipo de exigência pode ser especialmente comum em certas áreas que vendem para clientes governamentais
-
Diferença entre Hybrid PQ+ECDH e Pure PQ
- O risco enfrentado em KEM não é “quebrar a criptografia depois do Q-Day”, e sim Harvest Now, Decrypt Later
- Q-Day é usado como abreviação para o momento em que atacantes passarem a ter computadores quânticos relevantes para cripto
- Dividindo o risco:
- ECDH puro, sem PQ, é quebrado retroativamente no Q-Day
- PQ puro não é quebrado no Q-Day, assumindo que o algoritmo pós-quântico não colapse antes
- Hybrid PQ+ECDH funciona como hedge contra um colapso algorítmico antes do Q-Day, mas depois do Q-Day não oferece vantagem em relação ao Pure PQ
- Defender ECDH + ML-KEM implica reconhecer que, no longo prazo, ML-KEM é um algoritmo seguro
- Há duas razões principais para preferir híbrido
- ele é mais fácil de aceitar do que um algoritmo totalmente novo, o que acelera a adoção de PQ
- ele pode servir como proteção caso ML-KEM, ou a criptografia baseada em reticulados como um todo, sofra um colapso algorítmico
- Para fazer hedge de um jeito que também resista a computadores quânticos relevantes para cripto, seria necessário um híbrido PQ+PQ
- Se a prioridade for diversidade algorítmica, um híbrido de três vias com ML-KEM + HQC + ECDH seria uma afirmação mais honesta
- ML-KEM é um KEM baseado em reticulados e considerado resistente a ataques quânticos
- HQC é um KEM baseado em códigos e considerado resistente a ataques quânticos
- ECDH é a técnica usada hoje, mas vulnerável a ataques quânticos
- A modelagem de ameaças ajuda, nesse tipo de debate, a separar oposição ideológica de risco técnico real
Encerramento
- Há muitos guias na internet que tratam formalmente de modelos de ameaça e metodologias relacionadas
- O objetivo aqui é ter um teste de fumaça que permita filtrar rapidamente a qualidade e a eficácia de um documento de modelo de ameaça
- Um bom modelo de ameaça precisa ir além do que está sendo protegido, de quem ataca, de como ataca e de como se defende, expondo também relações entre ativos, premissas e riscos aceitos
1 comentários
Opiniões no Lobste.rs
“Falta de gentileza” é um motivo válido para denunciar comentários, mas se queremos tornar a internet técnica melhor, talvez devêssemos parar de consumir e de recomendar o tom agressivo que esse autor usa com frequência demais no blog. Talvez até valha considerar banir esse domínio
E também acho que um protocolo em que “tudo é um grafo” realmente deve ser tratado como um projeto de pesquisa. No fim, a conclusão acabou sendo: “droga, algoritmos de grafos são realmente muito difíceis de analisar”