# KRACK e Dragonblood: o que houve depois do WEP, e por que um aperto de mão provado seguro quebrou assim mesmo

> O aperto de mão de quatro vias do WPA2 fora analisado formalmente e declarado seguro. Em 2017 um pesquisador da KU Leuven o quebrou mesmo assim, fazendo um cliente reinstalar uma chave que já estava usando. Seu substituto, o WPA3, saiu em 2018 e foi quebrado pelo mesmo pesquisador em 2019. Nenhuma das falhas estava na cifra, e é essa a lição inteira.

Source: https://ronutz.com/pt-BR/learn/krack-and-the-wifi-handshake  
Updated: 2026-09-08

---

## Onde este artigo começa

A [história da família sem fio](https://ronutz.com/pt-BR/learn/wireless-family-history) cobre o WEP e a lição que ele ensinou, que foi a de que a falha não estava na cifra, e sim em como o protocolo a usava. Este artigo é o que veio depois, porque a mesma frase acaba descrevendo tudo o que se seguiu.

O WPA2 substituiu o WEP em 2004 e segurou a linha por treze anos. Seu aperto de mão de quatro vias - a troca em que um cliente e um ponto de acesso, ambos já de posse da chave derivada da senha da rede, acordam uma chave de sessão nova - fora examinado por criptógrafos e tinha provas formais de segurança por trás. A declaração de um fabricante durante a divulgação de 2017 disse com todas as letras: o aperto de mão fora matematicamente provado seguro pela comunidade científica.

Fora mesmo. E quebrou.

## O que o aperto de mão faz, e o que o KRACK fez com ele

Quatro mensagens. O ponto de acesso manda um número aleatório; o cliente manda o seu e uma prova de que conhece a chave compartilhada; o ponto de acesso confirma e, na mensagem três, manda o cliente instalar a chave de sessão que agora derivou; o cliente confirma na mensagem quatro.

A falha está no que acontece quando a mensagem quatro se perde. Rádio não é confiável, então o ponto de acesso retransmite a mensagem três, e o cliente - corretamente, segundo a especificação - a aceita e instala a chave de novo. É esse o ataque inteiro. Mathy Vanhoef, do grupo imec-DistriNet da KU Leuven, mostrou que um atacante ao alcance do rádio e posicionado entre os dois podia bloquear a mensagem quatro de propósito, forçar a retransmissão, e fazer o cliente **reinstalar uma chave que já estava usando**.

Reinstalar zera os contadores associados - o número de pacote de transmissão, que é o nonce, e o contador de repetição de recepção - de volta aos valores iniciais. E reutilizar nonce sob a mesma chave é a única coisa que a cifragem por baixo jamais pode fazer. Reutilize e o fluxo de chave pode ser recuperado.

O impacto dependia da cifra em uso, e a distinção importa operacionalmente. Contra o AES-CCMP, um atacante podia repetir e decifrar pacotes, mas não forjá-los - o bastante para sequestrar um fluxo TCP e injetar nele. Contra WPA-TKIP e GCMP, na palavra dos próprios pesquisadores, o impacto era catastrófico: os pacotes podiam ser repetidos, decifrados **e** forjados. A mesma técnica também quebrou o aperto de mão de chave de grupo, o PeerKey e o de transição rápida do 802.11r, e recebeu dez identificadores CVE distintos.

E havia o achado de implementação, que era pior que o de protocolo. Clientes Android e Linux usando certas versões do `wpa_supplicant` não reinstalavam a chave verdadeira quando enganados - instalavam uma **chave só de zeros**. Contra esses aparelhos o atacante não precisava recuperar fluxo de chave nenhum.

## Por que uma prova não impediu isso

Esta é a parte que vale levar a qualquer conversa sobre verificação formal, e é a versão sem fio do argumento que o [artigo sobre código perfeito](https://ronutz.com/pt-BR/learn/there-is-no-perfect-code) faz com o ScreenOS da Juniper.

As provas do aperto de mão de quatro vias eram provas sobre o aperto de mão: que um atacante que observa a troca não consegue derivar a chave de sessão, e que as duas partes terminam concordando na mesma. Tudo isso continuou verdadeiro. O que as provas não modelavam era a máquina de estados em volta do aperto de mão - o que uma implementação deveria fazer quando uma mensagem chega duas vezes. A especificação não proibia reinstalar uma chave, porque ninguém tinha feito a pergunta, e uma prova responde apenas à pergunta que lhe foi dada.

A conclusão correta não é que análise formal seja inútil. É que uma prova tem um escopo, que o escopo em geral é o protocolo e não o comportamento da implementação ao longo do tempo, e que a distância entre os dois é onde a indústria não para de achar coisas.

## A divulgação, que deu certo

O artigo foi submetido a revisão em 19 de maio de 2017. O CERT/CC notificou os fabricantes em 28 de agosto. A pesquisa veio a público em 16 de outubro, e o artigo foi apresentado na conferência da ACM em Dallas no começo de novembro. Quando veio a público, já havia correções para os principais sistemas operacionais, firmwares de roteador e conjuntos de chips, lançadas mais ou menos ao mesmo tempo.

Dois detalhes valem ser guardados. O próprio Vanhoef observou que, na publicação, os achados já tinham vários meses e que ele desde então encontrara técnicas mais fáceis que as do artigo - a versão publicada era, de propósito, não a mais afiada disponível. E a correção era retrocompatível: os clientes foram corrigidos para recusar reinstalar uma chave já em uso, o que significa que um cliente corrigido está seguro num ponto de acesso não corrigido. Essa propriedade é a razão de a resposta ter funcionado, e nem sempre está disponível.

## O WPA3, e o ano que ele durou

A Wi-Fi Alliance anunciou o WPA3 em 2018. Sua melhoria central era substituir o aperto de mão de chave pré-compartilhada pelo Simultaneous Authentication of Equals, conhecido como Dragonfly - uma troca de chaves autenticada por senha, projetada para que um atacante que capture um aperto de mão não possa levá-lo embora e rodar um ataque de dicionário offline contra ele. Era uma correção real e importante para uma fraqueza real e importante.

Em abril de 2019 Vanhoef, então na NYU Abu Dhabi, publicou de novo, com Eyal Ronen, da Universidade de Tel Aviv e da KU Leuven. O artigo, Dragonblood, achou várias classes de problema: ataques de rebaixamento contra o WPA3 em modo de transição, em que uma rede que aceita clientes WPA2 e WPA3 pode ser empurrada de volta ao aperto de mão antigo; um rebaixamento contra o próprio SAE; negação de serviço contra o ponto de acesso; contornos de autenticação em toda implementação do EAP-pwd relacionado que testaram; e, como resultado principal, canais laterais de tempo e de cache no método de codificação de senha que vazam o suficiente para permitir exatamente o ataque de dicionário offline que o projeto existia para impedir.

Dois detalhes são quase perfeitos demais. A sobrecarga de negação de serviço que exploraram era causada pelas defesas contra canais laterais de tempo conhecidos - uma contramedida criando um problema novo. E a avaliação deles sobre o processo, citada na cobertura, era que um processo de projeto mais aberto teria impedido ou esclarecido a possibilidade dos ataques de rebaixamento. As correções foram adotadas na norma.

## O que um profissional deve tirar disso

**Três gerações, três falhas, nenhuma delas na cifra.** A falha do WEP estava em como usava uma cifra de fluxo. O KRACK era uma máquina de estados aceitando uma retransmissão. O Dragonblood era uma codificação de senha vazando por tempo. A criptografia nunca foi a parte fraca, o que é boa razão para desconfiar de qualquer discussão de segurança que passe o tempo em comprimento de chave.

**O modo de transição é onde o ataque mora.** O WPA3 em modo de transição - aceitando clientes WPA2 para nada quebrar - é rebaixável, exatamente como os [ataques nomeados ao TLS](https://ronutz.com/pt-BR/learn/the-named-tls-attacks) mostram para todo protocolo que manteve uma opção mais fraca por compatibilidade. Se o parque de fato não tem aparelhos só WPA2, a configuração é WPA3 apenas; se tem, a posição honesta é que a rede está protegida no nível do WPA2 e deve ser planejada assim.

**Corrigir o cliente foi o controle que importou.** O KRACK era primordialmente uma correção do lado do cliente. Numa empresa, a população que nunca foi corrigida é a que se deve inventariar: coletores de mão, equipamentos médicos, controles prediais, impressoras, qualquer coisa cujo fabricante parou de lançar firmware. É a mesma população que a [era dos worms](https://ronutz.com/pt-BR/learn/the-worm-era) não para de identificar.

**E o processo funcionou, devagar e em público.** Um pesquisador achou, divulgou por um órgão coordenador, os fabricantes corrigiram antes da publicação, as correções entraram na norma, e o mesmo pesquisador então fez de novo com o substituto. Isso não é uma falha do sistema. É o sistema, e a alternativa - falhas achadas por gente que não publica - é do que trata o resto deste catálogo.

## Fontes

- [krackattacks.com, o site do próprio Mathy Vanhoef: o artigo "Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2" foi submetido a revisão em 19 de maio de 2017 e apresentado na conferência Computer and Communications Security em 1º de novembro de 2017; técnicas mais fáceis foram achadas depois da submissão, tornando triviais os ataques contra implementações que só aceitam retransmissões cifradas da mensagem 3; o wpa_supplicant v2.6 do Linux também é vulnerável à instalação de uma chave de cifragem só de zeros](https://www.krackattacks.com/)
- [Nota de vulnerabilidade VU#228519 do CERT/CC: as fraquezas constituem uma nova classe de ataque ao aperto de mão de quatro vias usado em todas as variantes de WPA e WPA2, chamada KRACK; é uma questão de toda a indústria, já que todo produto que implementa Wi-Fi é teoricamente vulnerável; os fabricantes foram notificados em 28 de agosto de 2017; uma declaração de fabricante na nota registra que o protocolo de quatro vias fora matematicamente provado seguro pela comunidade científica; nenhum dos ataques recupera a senha do WPA](https://www.kb.cert.org/vuls/id/228519)
- [Vanhoef e Piessens, o artigo da CCS 2017: o aperto de mão de quatro vias também transporta a chave temporal de grupo ao suplicante; um wpa_supplicant não modificado reinstala a chave ao receber uma mensagem 3 retransmitida](https://papers.mathyvanhoef.com/ccs2017.pdf)
- [Bruce Schneier, citando o resumo do artigo: o adversário engana a vítima para que reinstale uma chave já em uso manipulando e repetindo mensagens do aperto de mão, zerando o número de pacote de transmissão e o contador de repetição; o ataque também quebra os apertos de mão PeerKey, de chave de grupo e de Fast BSS Transition; contra o AES-CCMP o adversário pode repetir e decifrar mas não forjar pacotes, enquanto contra WPA-TKIP e GCMP o impacto é catastrófico e os pacotes também podem ser forjados](https://www.schneier.com/blog/archives/2017/10/new_krack_attac.html)
- [NowSecure: o ataque envolve interceptar e repetir a terceira mensagem do aperto de mão de quatro vias; Vanhoef identificou dez identificadores CVE distintos, de CVE-2017-13077 a CVE-2017-13088](https://www.nowsecure.com/blog/2017/10/17/new-mobile-risk-cracking-wi-fi-encryption-key-reinstallation-attacks-krack/)
- [Vanhoef e Ronen, Dragonblood, Cryptology ePrint Archive 2019/383 e IEEE Symposium on Security and Privacy 2020: uma análise sistemática do WPA3 e do EAP-pwd achando ataques de negação de serviço e de rebaixamento, vulnerabilidades severas em todas as implementações, canais laterais que permitem ataques de dicionário offline, e correções de projeto que estão sendo oficialmente adotadas; os resultados principais são ataques de canal lateral contra o método de codificação de senha do Dragonfly](https://eprint.iacr.org/2019/383)
- [wpa3.mathyvanhoef.com: as falhas de projeto se dividem em ataques de rebaixamento contra aparelhos com WPA3 e fraquezas no próprio aperto de mão Dragonfly; a auditoria revelou contornos de autenticação em todas as implementações do EAP-pwd e num cliente SAE; as ferramentas liberadas não são feitas para atacar a rede do vizinho](https://wpa3.mathyvanhoef.com/)
- [O artigo Dragonblood: a causa da alta sobrecarga do SAE, explorada para negação de serviço, são as defesas contra canais laterais de tempo conhecidos; um ataque de rebaixamento e dicionário funciona contra o WPA3 em modo de transição, e ataques específicos de implementação funcionam mesmo em redes só WPA3](https://papers.mathyvanhoef.com/dragonblood.pdf)
- [BleepingComputer, abril de 2019: Vanhoef, da NYU Abu Dhabi, e Ronen, da Universidade de Tel Aviv e da KU Leuven, descrevem ataques que se assemelham a ataques de dicionário e recuperam a senha abusando de vazamentos de canal lateral de tempo ou de cache que miram o método de codificação de senha do protocolo; um processo mais aberto teria impedido ou esclarecido a possibilidade de ataques de rebaixamento contra o modo de transição do WPA3](https://www.bleepingcomputer.com/news/security/wpa3-wi-fi-standard-affected-by-new-dragonblood-vulnerabilities/)