Quando se fala em "criptografia", alguns lembram de sua senha de WiFi, do ícone de cadeado verde ao lado do endereço de seu site favorito e de como é difícil acessar o e-mail de outra pessoa. Outros recordam a sequência de vulnerabilidades dos últimos anos com siglas impactantes (DROWN, FREAK, POODLE…), logotipos sofisticados e a urgência de atualizar o navegador.

A criptografia abrange tudo isso, mas a essência está em outro lugar. A essência está na fina linha entre o simples e o complexo. Algumas coisas são fáceis de fazer, mas difíceis de reverter: por exemplo, quebrar um ovo. Outras coisas são fáceis de realizar, mas complicadas de desfazer quando falta uma pequena parte crucial: como abrir uma porta trancada, quando a "parte crucial" é a chave. A criptografia estuda essas situações e as formas de aplicá-las na prática.

Nos últimos anos, a coleção de ataques criptográficos se transformou em um zoológico de logotipos chamativos, repletos de fórmulas de artigos científicos, e gerou uma sensação geral de que tudo está quebrado. Mas, na realidade, muitos desses ataques são baseados em alguns princípios comuns, e páginas intermináveis de fórmulas frequentemente se resumem a ideias simples de entender.

Nesta série de artigos, examinaremos diferentes tipos de ataques criptográficos, com foco nos princípios fundamentais. De forma geral, e não exatamente nesta ordem, abordaremos o seguinte:

Estratégias básicas: força bruta, análise de frequência, interpolação, decretação e protocolos cruzados.
"Vulnerabilidades de marca": FREAK, CRIME, POODLE, DROWN, Logjam.
Estratégias avançadas: ataques de oráculo (ataque de Waterner, ataque de Kelsey); o método meet-in-the-middle, ataque do "aniversário", viés estatístico (análise criptográfica diferencial, análise criptográfica integral etc.).
Ataques por canais laterais e seus parentes próximos, métodos de análise de falhas.
Ataques à criptografia de chave pública: raiz cúbica, broadcast, mensagem relacionada, ataque de Coppersmith, algoritmo de Pollard-Hellman, crivo numérico, ataque de Wiener, ataque de Bleichenbacher.

Este artigo específico cobre o material mencionado até o ataque de Kelsey.

Estratégias básicas

Os seguintes ataques são simples no sentido de que podem ser praticamente totalmente explicados sem muitos detalhes técnicos. Vamos explicar cada tipo de ataque em termos simples, sem nos aprofundar em exemplos complicados ou em usos avançados.

Alguns desses ataques se tornaram obsoletos e não foram utilizados há muitos anos. Outros, por outro lado, são veteranos e ainda atacam regularmente desenvolvedores de sistemas criptográficos desavisados no século 21. Pode-se considerar que a era da criptografia moderna começou com o IBM DES — o primeiro ciframento que resistiu a todos os ataques desta lista.

Força bruta simples

O esquema de criptografia consiste em duas partes: 1) uma função de criptografia que aceita uma mensagem (texto simples) em combinação com uma chave e, em seguida, cria uma mensagem criptografada - texto cifrado; 2) uma função de descriptografia que aceita o texto cifrado e a chave e cria o texto simples. Tanto a criptografia quanto a descriptografia devem ser facilmente computáveis com a chave - e difíceis sem ela.

Suponha que vemos o texto cifrado e tentamos descriptografá-lo sem qualquer informação adicional (isso é chamado de ataque 'apenas texto cifrado'). Se de alguma forma encontrarmos a chave correta, podemos facilmente verificar se ela realmente é correta, se o resultado for uma mensagem razoável.

Observe que existem duas suposições implícitas aqui. Primeiro, que sabemos como realizar a descriptografia, ou seja, como a criptossistema funciona. Essa é uma suposição padrão ao discutir criptografia. Ocultar os detalhes da implementação da cifra de um invasor pode parecer uma medida de segurança adicional, mas assim que um invasor descobrir esses detalhes, essa segurança extra é perdida de forma invisível e irreversível. Assim é o princípio de Kerckhoffs: a captura do sistema pelo inimigo não deve causar inconvenientes.

Em segundo lugar, presumimos que a chave correta é a única que levará a uma descriptografia razoável. Essa também é uma suposição razoável; ela se mantém se o texto cifrado for muito mais longo que a chave e legível. Na maioria das vezes, isso é verdade no mundo real, exceto por chaves enormes e impraticáveis ou ou outras manipulações, que são melhores deixadas de lado. (se você não está satisfeito com nossas explicações, consulte o teorema 3.8 aqui).

Dado o exposto, surge uma estratégia: verificar cada possível chave. Isso é chamado de brute force, e esse tipo de ataque funciona garantidamente contra todos os cifrados práticos — no final. Por exemplo, brute force é suficiente para quebrar a cifra de César, uma cifra antiga, onde a chave é uma letra do alfabeto, o que implica em pouco mais de 20 chaves possíveis.

Infelizmente para os criptoanalistas, aumentar o tamanho da chave protege bem contra brute force. À medida que o tamanho da chave cresce, o número de chaves possíveis aumenta exponencialmente. Com os tamanhos de chave modernos, o simples brute force é completamente impraticável. Para entender o que queremos dizer, vamos considerar o supercomputador mais rápido conhecido até meados de 2019: Summit da IBM, com um desempenho de pico em torno de 10¹⁷ operações por segundo. Hoje, o comprimento típico da chave é de 128 bits, o que significa 2¹²⁸ combinações possíveis. Para testar todas as chaves, o supercomputador Summit precisaria de um tempo que é aproximadamente 7800 vezes superior à idade do universo.

Deveríamos considerar o brute force uma curiosidade histórica? De forma alguma: é um ingrediente necessário no livro de receitas de criptoanálise. Raramente encontramos cifras tão fracas que possam ser quebradas apenas com ataques inteligentes, sem o uso de força de alguma forma. Muitos ataques bem-sucedidos usam primeiro um método algorítmico para enfraquecer a cifra alvo e, em seguida, aplicam brute force.

Análise de frequência

A maioria dos textos não é incompreensível. Por exemplo, em textos em inglês, há muitas letras ‘e’ e artigos ‘the’; em arquivos binários – muitos bytes nulos como preenchimento entre fragmentos de informação. A análise de frequência é qualquer ataque que utiliza esse fato.

Um exemplo canônico de cifra vulnerável a esse ataque é a simples cifra de substituição. Nesta cifra, a chave é uma tabela que substitui todas as letras. Por exemplo, ‘g’ é substituído por ‘h’, ‘o’ por ‘j’. Portanto, a palavra ‘go’ se torna ‘hj’. Essa cifra é difícil de ser quebrada por brute force simples, pois existem muitas tabelas de substituição possíveis. Se você está interessado na matemática, o comprimento eficaz da chave é de cerca de 88 bits: isso
. Mas a análise de frequência geralmente resolve rapidamente a tarefa.

Vamos considerar o seguinte texto cifrado, processado por um simples cifrado de substituição:

XDYLY ALY UGLY XDWNKE WN DYAJYN ANF YALXD DGLAXWG XDAN ALY FLYAUX GR WN OGQL ZDWBGEGZDO

Como Y aparece com frequência, inclusive no final de muitas palavras, podemos presumir preliminarmente que esta é a letra e:

XDeLe ALe UGLe XDWNKE WN DeAJeN ANF eALXD DGLAXWG XDAN ALe FLeAUX GR WN OGQL ZDWBGEGZDO

O par XD se repete no início de várias palavras. Em particular, a combinação XDeLe claramente sugere a palavra these ou there, portanto, continuamos:

theLe ALe UGLe thWNKE WN heAJeN ANF eALth DGLAtWG thAN ALe FLeAUt GR WN OGQL ZDWBGEGZDO

Em seguida, presumimos que L -nó, e o outro — r, A — a e assim por diante. Provavelmente, será necessário fazer várias tentativas, mas em comparação com a força bruta completa, esse ataque recupera o texto original em um tempo muito curto:

there are more things in heaven and earth horatio than are dreamt of in your philosophy

Para alguns, resolver essas "criptogramas" é um passatempo interessante.

A ideia da análise de frequência é mais fundamental do que parece à primeira vista. E ela é aplicável a cifrados muito mais complexos. Ao longo da história, várias construções de cifrado tentaram se opor a esse tipo de ataque por meio da "substituição polialfabética". Aqui, durante o processo de cifragem, a tabela de substituição das letras muda de maneiras complexas, mas previsíveis, que dependem da chave. Todos esses cifrados foram considerados difíceis de quebrar na sua época; e, no entanto, a modesta análise de frequência acabou vencendo todos eles.

O cifrado polialfabético mais ambicioso da história e, provavelmente, o mais famoso foi o cifrado "Enigma" durante a Segunda Guerra Mundial. Era relativamente complexo em comparação com seus predecessores, mas após um trabalho longo e árduo, os criptanalistas britânicos o quebraram com a ajuda da análise de frequência. Claro, eles não conseguiram desenvolver um ataque elegante, como o mostrado acima; eles tiveram que comparar pares conhecidos de texto aberto e cifrado (o chamado "ataque baseado em textos abertos") e até provocar os usuários da "Enigma" a cifrar certas mensagens para analisar o resultado ("ataque baseado em texto aberto adaptado"). Mas isso não aliviou o destino das exércitos derrotados dos inimigos e dos submarinos afundados.

Após esse triunfo, a análise de frequências desapareceu da história da criptoanálise. Os cifrários da era digital moderna são criados para trabalhar com bits, e não com letras. O que é ainda mais importante, esses cifrários foram desenvolvidos com uma sombria compreensão do que mais tarde se tornou conhecido como a lei de Schneier: qualquer um pode criar um algoritmo de ciframento que ele mesmo não consiga quebrar. Não é suficiente que o sistema de ciframento pareça complexo: para provar seu valor, ele deve passar por uma implacável revisão de segurança de muitos criptoanalistas, que farão todo o possível para quebrar a cifra.

Cálculos preliminares

Vamos imaginar uma cidade hipotética chamada Prekom Heights, com uma população de 200.000 pessoas. Em cada casa da cidade, há bens valiosos, em média, de $30.000, mas não mais de $50.000. O mercado de segurança em Prekom é monopolizado pela ACME Industries, que produz as lendárias fechaduras de porta da classe Coyote ™. Segundo a análise de especialistas, a fechadura da classe Coyote só pode ser quebrada por uma máquina hipotética muito complexa, cujo desenvolvimento leva cerca de cinco anos e um investimento de $50.000. A cidade está segura?

Provavelmente não. Afinal, surgirá um criminoso suficientemente ambicioso. Ele pode raciocinar da seguinte forma: 'Sim, eu terei grandes despesas iniciais. Cinco anos de espera paciente e $50.000. Mas quando terminar o trabalho, terei acesso a toda a riqueza desta cidade.Se eu jogar bem minhas cartas, esse investimento se multiplicará várias vezes'.

De maneira similar, na criptografia. Os ataques contra um cifrário específico são submetidos a uma análise implacável de custos e benefícios. Se a relação for favorável, o ataque não ocorrerá. Mas os ataques que atuam imediatamente contra muitas vítimas potenciais quase sempre compensam, e nesse caso, a melhor prática de design é presumir que eles começaram desde o primeiro dia. Temos basicamente uma versão criptográfica da lei de Murphy: 'Tudo que realmente pode quebrar o sistema, quebrará o sistema'.

Um exemplo simples de um sistema criptográfico vulnerável a ataques com cálculos preliminares é o cifrário com algoritmo constante sem uso de chave. Foi assim que aconteceu com o cifrário de César., que simplesmente desloca cada letra do alfabeto três letras para frente (a tabela é circular, então a última letra do alfabeto é criptografada pela terceira). Aqui novamente se revela o princípio de Kerchoff: assim que o sistema é quebrado, ele está quebrado para sempre.

A concepção é simples. Mesmo um desenvolvedor iniciante de criptossistemas, provavelmente, perceberá a ameaça e se preparará adequadamente. Se observarmos a evolução da criptografia, tais ataques foram irrelevantes para a maioria dos cifradores, começando pelas primeiras versões melhoradas do Cifra de César, até o declínio dos cifradores polialfabéticos. Esses ataques só retornaram com a chegada da era moderna da criptografia.

Esse retorno é causado por dois fatores. Primeiro, finalmente surgiram criptossistemas complexos o suficiente, onde a possibilidade de exploração após a violação não era óbvia. Em segundo lugar, a criptografia se tornou tão amplamente disseminada que milhões de não profissionais tomavam decisões diariamente sobre onde e quais partes da criptografia reutilizar. Levou algum tempo até que os especialistas percebessem os riscos emergentes e soassem o alarme.

Lembre-se do ataque com pré-cálculos: no final do artigo, examinaremos dois exemplos criptográficos da vida real, onde ele desempenhou um papel importante.

Interpolação

Diante de você está o famoso detetive Sherlock Holmes, realizando um ataque com interpolação sobre o infeliz Dr. Watson:

Eu imediatamente percebi que você veio do Afeganistão… Meu raciocínio foi o seguinte: 'Esse homem é um médico, mas sua postura é militar. Portanto, um médico militar. Ele acabou de voltar dos trópicos — seu rosto é bronzeado, mas essa não é a tonalidade natural de sua pele, já que seus pulsos são muito mais claros. Seu rosto está desgastado, — evidentemente ele sofreu e enfrentou doenças. Ele foi ferido na mão esquerda — mantém-a imóvel e um pouco de maneira não natural. Onde poderia um médico militar inglês ter sofrido privações e ter sido ferido nos trópicos? Claro, no Afeganistão.' Todo o raciocínio não levou mais de um segundo. E assim eu disse que você vinha do Afeganistão, e você ficou surpreso.

De cada colmeia separadamente, Holmes pôde extrair muito pouca informação. Ele só pôde chegar à sua conclusão considerando todas juntas. Uma tentativa semelhante é a ataque por interpolação, que investiga pares conhecidos de texto claro e texto cifrado, obtidos através da aplicação da mesma chave. De cada par, são extraídas observações individuais que permitem fazer uma conclusão geral sobre a chave. Todas essas inferências são vagas e parecem inúteis, até que de repente atingem uma massa crítica e levam a uma única conclusão possível: por mais inacreditável que seja, deve ser verdadeira. Após isso, ou a chave é revelada, ou o processo de decifração torna-se tão refinado que pode ser replicado.

Vamos ilustrar com um exemplo simples como a interpolação funciona. Suponha que queremos ler o diário pessoal do nosso inimigo, Bob. Ele cifra cada número em seu diário usando um sistema criptográfico simples que ele conheceu através de um anúncio na revista 'Zombando da Criptografia'. O sistema funciona da seguinte forma: Bob escolhe dois números de sua preferência: e . A partir desse momento, para cifrar qualquer número , ele calcula . Por exemplo, se Bob escolheu e , então o dígito será cifrado como .

Suponha que, em 28 de dezembro, percebemos que Bob está rabiscando algo em seu diário. Quando ele terminar, vamos pegá-lo discretamente e olhar a última entrada:

Data: 235/520
Caro diário,
Hoje foi um bom dia. Em 64 dias tenho um encontro com Alice, que mora no apartamento 843. Eu realmente acho que ela pode ser 26!

Como estamos muito sérios em seguir Bob em seu encontro (neste cenário temos 15 anos), é crucial saber a data, assim como o endereço de Alice. Felizmente, percebemos que o sistema criptográfico de Bob é vulnerável a ataques de interpolação. Podemos não saber e , mas sabemos a data de hoje, então temos dois pares de 'texto claro - texto cifrado'. Ou seja, sabemos que é cifrado como , e — em . O que vamos anotar:

Como temos 15 anos, já sabemos sobre o sistema de duas equações com duas incógnitas, o que nessa situação é suficiente para encontrar e sem muitos problemas. Cada par "texto em claro-texto - texto cifrado" impõe uma restrição à chave de Bob, e duas restrições juntas são suficientes para restaurar completamente a chave. No nosso exemplo, a resposta e (na , então 26 no diário corresponde à palavra ‘the one’, ou seja, "aquela" — nota do tradutor.

Ataques de interpolação, claro, não se limitam a exemplos tão simples. Cada sistema criptográfico que se reduz a um objeto matemático bem compreendido e uma lista de parâmetros está em risco de ataque por interpolação — quanto mais compreensível o objeto, maior o risco.

Os novatos muitas vezes reclamam que criptografia é "a arte de projetar o mais feio possível". Provavelmente, ataques de interpolação têm grande parte da culpa. Bob pode optar por usar um design matemático elegante ou manter a confidencialidade do encontro com Alice — mas infelizmente, geralmente não é possível obter os dois. Isso ficará extremamente claro quando finalmente abordarmos o tema da criptografia de chave pública.

Cross-protocol/downgrading

No filme "Ilusão do Engano" (2013), um grupo de ilusionistas tenta enganar e roubar toda a fortuna do corrupto magnata de seguros Arthur Tressler. Para acessar a conta bancária de Arthur, os ilusionistas devem ou apresentar seu nome de usuário e senha, ou fazê-lo aparecer pessoalmente no banco e participar do esquema.

Ambas as opções são muito difíceis; os caras estão acostumados a atuar no palco, não a participar de operações de serviços secretos. Assim, eles escolhem uma terceira alternativa: seu cúmplice liga para o banco e se passa por Arthur. O banco faz algumas perguntas para verificar a identidade, como o nome do tio e o nome do primeiro animal de estimação; nossos heróis facilmente obtêm essa informação de Arthur por meio de engenhosas técnicas de engenharia social.A partir desse momento, uma ótima segurança de senha não faz mais sentido.

(De acordo com uma lenda urbana que verificamos e confirmamos pessoalmente, o criptógrafo Eli Biham uma vez encontrou um caixa do banco que insistia na criação de uma pergunta secreta. Quando o caixa perguntou o nome da avó materna, Biham começou a ditar: "Maiúscula X, minúscula y, três...").

Assim como na criptografia, se para proteger um ativo é utilizado simultaneamente dois protocolos criptográficos, sendo um deles muito mais fraco que o outro, o sistema final se torna vulnerável a um ataque de cruzamento de protocolos, onde o protocolo mais fraco é atacado para chegar ao prêmio, sem tocar no mais forte.

Em alguns casos complexos, não basta apenas se conectar ao servidor por meio de um protocolo mais fraco, mas envolve a participação involuntária do cliente legítimo. Isso pode ser organizado através do que chamamos de ataque de degradação (downgrade). Para compreender este ataque, suponha que nossos ilusionistas tenham uma tarefa mais complicada do que no filme. Suponha que o funcionário do banco (caixa) e Arthur estejam enfrentando algumas circunstâncias imprevistas, resultando em um diálogo como este:

Hacker: Alô? Aqui é Arthur Tressler. Eu gostaria de recuperar minha senha.
Caixa: Ótimo. Por favor, olhe em seu livro pessoal de códigos secretos, página 28, palavra 3. Todas as mensagens seguintes serão criptografadas usando esta palavra específica como chave. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…
Hacker: Ei, ei, espere, espere. Isso é realmente necessário? Não podemos apenas falar como pessoas normais?
Caixa: Eu não recomendo que você faça isso.
Hacker: Eu só… escute, eu tive um dia péssimo, está bem? Sou um cliente VIP e não estou a fim de ficar revirando esses livros de códigos idiotas.
Caixa: Certo. Se você insiste, senhor Tressler. O que você deseja?
Hacker: Por favor, eu gostaria de transferir todo o meu dinheiro para o Fundo Nacional das Vítimas de Arthur Tressler.
(Pausa).
Caixa: Entendi. Por favor, forneça seu PIN para transações de grande valor.
Hacker: Meu quê?
Caixa: Por sua solicitação pessoal, transações desse tamanho exigem a inserção do PIN de grandes transações. Esse código foi fornecido a você ao abrir a conta.
Hacker:… Eu perdi. Isso é realmente necessário? Você não pode apenas aprovar a transação?
Caixa: Não. Peço desculpas, senhor Tressler. Novamente, é uma medida de segurança que você solicitou. Se preferir, podemos enviar um novo PIN para sua caixa de correio.

Nossos heróis adiam a operação. Eles escutam várias transações de grande porte de Tressler, esperando ouvir o código PIN; mas a cada vez a conversa se transforma em um barulho encriptado, antes que algo interessante seja revelado. Finalmente, em um belo dia, eles colocam o plano em ação. Eles esperam pacientemente pelo momento em que Tressler deve realizar uma grande transação por telefone, ele se conecta à linha e então…

Tressler: Olá. Gostaria de fazer uma transação remota, por favor.
Caixa: Ótimo. Por favor, olhe em seu livro pessoal de códigos secretos, na página…
(O hacker pressiona um botão; a voz do caixa se transforma em um ruído indistinto).
Caixa: — #@$#@$#*@$$@#* será encriptado com esta palavra como chave. AAAYRR PLRQRZ MMNJK LOJBAN…
Tressler: Desculpe, não entendi bem. Pode repetir? Em que página? Qual palavra?
Caixa: É a página @#$@#*$)#*#@()#@$(#@*$(#@*.
Tressler: O quê?
Caixa: A palavra número vinte @$#@$#%#$.
Tressler: Sério! Chega! Você e seu protocolo de segurança — isso é um circo. Eu sei que você pode simplesmente conversar normalmente comigo.
Caixa: Não aconselho…
Tressler: E eu não aconselho você a desperdiçar meu tempo. Não quero ouvir mais sobre isso até que seu problema de linha telefônica seja resolvido. Podemos fazer este negócio ou não?
Caixa:… sim. Certo. O que você deseja?
Tressler: Gostaria de transferir $20.000 para a empresa Lord Business Investments, número da conta…
Caixa: Um momento, por favor. É um grande negócio. Por favor, forneça seu código PIN para grandes transações.
Tressler: O quê? Ah, claro. 1234.

Aqui está o ataque na baixa. Um protocolo mais fraco de 'fale diretamente' foi previsto como opção uma última alternativa. E ainda estamos aqui.

Você pode perguntar quem em sã consciência projetaria um sistema real do tipo 'seguro, a menos que solicitado o contrário', como descrito acima. Mas assim como o banco fictício corre riscos para manter clientes que não gostam de criptografia, os sistemas, em geral, muitas vezes se inclinam às exigências que são indiferentes ou até francamente hostis à segurança.

Foi exatamente essa a história que aconteceu com o protocolo SSLv2 em 1995. O governo dos EUA há muito começou a ver a criptografia como uma arma, que deveria ser mantida longe de inimigos internos e externos. Fragmentos de código foram apropriadamente aprovados para exportação dos EUA, frequentemente sob a condição de que os algoritmos fossem deliberadamente enfraquecidos. A empresa Netscape, desenvolvedora do navegador mais popular, o Netscape Navigator, recebeu permissão para o SSLv2 apenas com uma chave RSA de 512 bits inicialmente vulnerável (e 40 bits para RC4).

No final do milênio, as regras foram suavizadas e o acesso à criptografia moderna tornou-se amplamente disponível. No entanto, clientes e servidores mantiveram durante muitos anos a 'criptografia de exportação' fraca devido à mesma inércia que mantém o suporte a qualquer sistema obsoleto. Os clientes acreditavam que podiam encontrar um servidor que não suportava nada além disso. Os servidores faziam o mesmo. Claro, o protocolo SSL dita que clientes e servidores nunca devem usar um protocolo fraco quando um melhor está disponível. Mas a mesma premissa se aplicava a Tressler e seu banco.

Essa teoria foi aplicada em dois ataques de grande repercussão, que abalaram a segurança do protocolo SSL em 2015, ambos descobertos por pesquisadores da Microsoft e INRIA. Primeiro, em fevereiro, foram divulgados detalhes do ataque FREAK, e três meses depois, outro ataque semelhante chamado Logjam, que discutiremos com mais detalhes quando abordarmos ataques à criptografia de chave pública.

Vulnerabilidade FREAK (também conhecido como 'Smack TLS') surgiu quando pesquisadores analisaram implementações de cliente/servidor TLS e descobriram um erro curioso. Nessas implementações, mesmo que o cliente não solicite o uso de criptografia de exportação fraca, se o servidor ainda responder com tais chaves — o cliente diz 'tudo bem' e muda para um conjunto de cifras fracas.

Na época, todos consideravam a criptografia de exportação como antiquada e proibida para uso, portanto, o ataque veio como um verdadeiro choque e afetou muitos domínios importantes, incluindo os sites da Casa Branca, do IRS (Serviço de Receita Federal dos EUA) e da NSA. Pior ainda, descobriu-se que muitos servidores vulneráveis otimizavam o desempenho reutilizando as mesmas chaves, em vez de criar novas para cada sessão. Isso permitiu que, após a degradação do protocolo, um ataque de pré-cálculo fosse realizado: quebrar uma chave permanecia relativamente caro (US$ 100 e 12 horas no momento da publicação), mas o custo prático de um ataque a uma conexão foi significativamente reduzido. Bastava quebrar a chave do servidor uma vez — e então descriptografar as conexões subsequentes a partir desse ponto.

E antes de seguir em frente, é necessário mencionar um ataque avançado...

Ataque do oráculo

Moxie Marlinspike é mais conhecido como o pai do aplicativo de mensageiria criptografada multiplataforma Signal; mas pessoalmente, gostamos de uma de suas inovações menos conhecidas — o princípio da maldição criptográfica (Cryptographic Doom Principle). Reescrevendo levemente, pode-se dizer assim: "Se um protocolo realiza qualquer operação criptográfica sobre uma mensagem de uma fonte potencialmente maliciosa e se comporta de maneira diferente dependendo do resultado, ele está fadado ao fracasso". Ou de uma forma mais contundente: "Não colete informações do inimigo para processamento, e se for necessário, pelo menos não mostre o resultado".

Deixemos de lado os estouros de buffer, injeções de comandos e afins; eles estão além do escopo desta discussão. A violação do "princípio da maldição" leva a comprometimentos sérios na criptografia, uma vez que o protocolo se comporta exatamente como deveria.

Como exemplo, vamos considerar uma construção fictícia com um cifrador de substituição vulnerável e, em seguida, demonstrar um ataque possível. Embora já tenhamos visto um ataque a um cifrador de substituição usando análise de frequência, isso não é apenas "outra maneira de quebrar o mesmo cifrador". Pelo contrário, os ataques do oráculo são uma invenção muito mais moderna, aplicável a diversas situações em que a análise de frequência falha, e veremos uma demonstração disso na próxima seção. Aqui, um cifrador simples foi escolhido apenas para tornar o exemplo mais fácil de entender.

Assim, Alice e Bob se comunicam usando uma cifra de substituição simples, utilizando uma chave conhecida apenas por eles. Eles têm um rigoroso controle sobre o comprimento das mensagens: o comprimento é exatamente 20 caracteres. Portanto, concordaram que se alguém quisesse enviar uma mensagem mais curta, deveria adicionar algum texto fictício ao final da mensagem para que ela tivesse exatamente 20 caracteres. Após alguma discussão, decidiram que aceitariam apenas os seguintes textos fictícios: a, bb, ccc, dddd etc. Assim, conhece-se o texto fictício de qualquer comprimento necessário.

Quando Alice ou Bob recebe uma mensagem, eles primeiro verificam se a mensagem tem o comprimento correto (20 caracteres) e se o sufixo é o texto fictício correto. Se não for o caso, respondem com uma mensagem de erro correspondente. Se o comprimento do texto e o texto fictício estiverem em ordem, o destinatário lê a própria mensagem e envia uma resposta criptografada.

Durante o ataque, o invasor se passa por Bob e envia mensagens falsas para Alice. As mensagens são totalmente sem sentido – o invasor não possui a chave e, portanto, não pode falsificar uma mensagem significativa. Mas, como o protocolo viola o princípio da impossibilidade, o invasor ainda pode enganar Alice para que ela revele informações sobre a chave, como mostrado abaixo.

Hacker: PREWF ZHJKL MMMN. LA
Alice: Texto fictício inválido.
Hacker: PREWF ZHJKL MMMN. LB
Alice: Texto fictício inválido.
Hacker: PREWF ZHJKL MMMN. LC
Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

O invasor não tem ideia do que Alice acabou de dizer, mas nota que o símbolo C deve corresponder a a, já que Alice aceitou o texto fictício.

Hacker: REWF ZHJKL MMMN. LAA
Alice: Texto fictício inválido.
Hacker: REWF ZHJKL MMMN. LBB
Alice: Texto fictício inválido.
Após várias tentativas…
Hacker: REWF ZHJKL MMMN. LGG
Alice: Texto fictício inválido.
Hacker: REWF ZHJKL MMMN. LHH
Alice: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

Novamente, o invasor não tem ideia do que Alice acabou de dizer, mas nota que H deve corresponder a b, já que Alice aceitou o texto fictício.

E assim por diante, até que o invasor descubra o valor de cada símbolo.

À primeira vista, o método se assemelha a um ataque baseado em texto claro escolhido. No final das contas, o atacante seleciona os textos criptografados, e o servidor os processa diligentemente. A principal diferença que torna esses ataques viáveis no mundo real é que o atacante não precisa acessar a decriptação real — uma resposta do servidor, mesmo que inofensiva, como "Texto falso incorreto", é suficiente.

Embora este ataque específico seja instrutivo, não devemos focar excessivamente nas particularidades do esquema de "texto falso", na criptossistema específica utilizada ou na sequência exata de mensagens enviadas pelo atacante. A ideia principal é como Alice reage de maneira diferente com base nas propriedades do texto claro, fazendo isso sem verificar se o texto criptografado correspondente realmente foi obtido de uma parte confiável. Assim, Alice permite que o atacante extraia informações secretas de suas respostas.

Nesse cenário, muitas coisas podem mudar. Os símbolos que Alice reage, ou a própria diferença em seu comportamento, ou até mesmo a criptossistema utilizada. Mas o princípio permanecerá o mesmo, e o ataque, em geral, continuará viável de uma forma ou de outra. A implementação básica deste ataque ajudou a identificar alguns erros de segurança que em breve discutiremos; mas antes, deve-se aprender algumas lições teóricas. Como usar esse "cenário de Alice" inventado em um ataque que possa funcionar em uma cifra moderna real? Isso é possível, mesmo que em teoria?

Em 1998, o criptógrafo suíço Daniel Bleichenbacher respondeu a essa pergunta afirmativamente. Ele demonstrou um ataque de oráculo em um amplamente utilizado criptossistema de chave pública RSA, utilizando um determinado esquema de mensagens. Em algumas implementações do RSA, o servidor responde com diferentes mensagens de erro, dependendo se o texto claro corresponde ao esquema ou não; isso foi suficiente para realizar o ataque.

Quatro anos depois, em 2002, o criptógrafo francês Serge Vaudenay demonstrou um ataque de oráculo, quase idêntico ao descrito acima no cenário de Alice — exceto que, em vez de um cifrado inventado, ele quebrou uma classe respeitável de cifras modernas que as pessoas realmente usam. Em particular, o ataque de Vaudenay visa cifras com tamanho de entrada fixo ('cifras de bloco') quando são usadas no chamado 'modo de criptografia CBC' e com um determinado esquema de preenchimento popular, basicamente equivalente ao do cenário de Alice.

Ainda em 2002, o criptógrafo americano John Kelsey — coautor Twofish — propôs vários ataques de oráculo em sistemas que comprimem mensagens e depois as criptografam. O mais notável entre eles foi um ataque que usou o fato de que muitas vezes é possível deduzir o comprimento original do texto aberto a partir do comprimento do texto criptografado. Em tese, isso permite a realização de um ataque de oráculo que recupera partes do texto aberto original.

A seguir, apresentamos uma descrição mais detalhada dos ataques de Vaudenay e Kelsey (daremos uma descrição mais detalhada do ataque de Bleichenbacher quando abordarmos os ataques à criptografia de chave pública). Apesar de todos os nossos esforços, o texto se torna um pouco técnico; portanto, se o que foi apresentado acima for suficiente para você, pule as duas seções seguintes.

Ataque de Vaudenay

Para entender o ataque de Vaudenay, primeiro precisamos falar um pouco mais sobre cifras de bloco e modos de criptografia. 'Cifra de bloco' é, como mencionado, uma cifra que aceita uma chave e uma entrada de comprimento fixo ('comprimento do bloco') e emite um bloco criptografado do mesmo comprimento. Cifras de bloco são amplamente utilizadas e consideradas relativamente seguras. O DES, agora aposentado, que é considerado a primeira cifra moderna, era uma cifra de bloco. Como mencionado acima, o mesmo se aplica ao AES, amplamente utilizado hoje.

Infelizmente, os cifradores em bloco têm uma fraqueza evidente. O tamanho típico do bloco é de 128 bits, ou 16 caracteres. É claro que a criptografia moderna exige trabalhar com dados de entrada de maior tamanho, e é aqui que entram os modos de criptografia. O modo de criptografia é, na essência, uma solução alternativa: é uma forma de aplicar um cifrador em bloco, que aceita dados de entrada apenas de um tamanho específico, a dados de entrada de tamanho arbitrário.

O Ataque de Waterner é focado no popular modo de operação CBC (Cipher Block Chaining, modo de encadeamento de blocos de texto cifrado). O ataque considera o cifrador em bloco básico como uma caixa preta mágica e impenetrável, contornando completamente sua segurança.

Aqui está um diagrama que mostra como funciona o modo CBC:

O sinal de mais contornado representa a operação XOR (ou exclusivo). Por exemplo, o segundo bloco de texto cifrado é obtido:

Executando a operação XOR no segundo bloco do texto original com o primeiro bloco do texto cifrado.
Cifrando o bloco resultante usando o cifrador em bloco, com a chave.

Como o CBC utiliza intensivamente a operação binária XOR, vamos aproveitar a oportunidade para relembrar algumas de suas propriedades:

Idempotência:
Comutatividade:
Associatividade:
Auto-inversibilidade:
Por byte: byte n de = (byte n de ) (byte n de )

Em geral, essas propriedades implicam que se tivermos uma equação envolvendo operações XOR e uma incógnita, ela pode ser resolvida. Por exemplo, se sabemos que com a incógnita e conhecidas e , podemos nos basear nas propriedades acima mencionadas para resolver a equação para . Aplicando XOR em ambos os lados da equação com , obtemos . Em breve, tudo isso se tornará muito relevante.

Entre o nosso cenário com Alice e o Ataque de Waterner, há duas pequenas diferenças e uma grande diferença. As duas pequenas:

No cenário, Alice esperava que os textos claros terminassem com os caracteres a, bb, ccc e assim por diante. No Ataque de Waterner, a vítima, ao contrário, espera que os textos claros terminem com N vezes o byte N (ou seja, hexadecimal 01 ou 02 02, ou 03 03 03 e assim por diante). É uma diferença puramente cosmética.
No cenário da Alice, era fácil dizer se Alice aceitou a mensagem, com a resposta "Texto fictício incorreto". No ataque de Vodené, é necessária uma análise mais detalhada, e a implementação precisa do lado da vítima é crucial; mas, para simplificar, vamos assumir que essa análise ainda é viável.

A principal diferença:

Como estamos usando diferentes sistemas criptográficos, a relação entre os bytes do texto cifrado controlados pelo invasor e os segredos (chave e texto plano) será, evidentemente, diferente. Portanto, o invasor terá que usar uma estratégia diferente ao criar textos cifrados e interpretar as respostas do servidor.

Essa é a principal diferença — o último fragmento do quebra-cabeça para entender o ataque de Vodené, então vamos pensar por um momento sobre por que e como um ataque oracle pode ser organizado no CBC.

Suponha que temos um texto cifrado CBC de 247 blocos e queremos descriptografá-lo. Podemos enviar mensagens falsas ao servidor, assim como antes podíamos enviar mensagens falsas para Alice. O servidor irá descriptografar as mensagens para nós, mas não mostrará a descriptografia — em vez disso, mais uma vez, como no caso de Alice, o servidor informará apenas um bit de informação: se o texto plano possui um preenchimento válido ou não.

Observe que, no cenário da Alice, tínhamos as seguintes relações:

$$display$$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key}) = text{plaintext}$$display$$

Vamos chamar isso de "equação de Alice". Nós controlávamos o texto cifrado; o servidor (Alice) fornecia informações vagas sobre o texto plano recebido; e isso nos permitiu deduzir informações sobre o último fator — a chave. Analogamente, se conseguirmos encontrar uma relação semelhante para o cenário CBC, poderíamos extrair algumas informações secretas também lá.

Felizmente, existem realmente relações que podemos usar. Vamos considerar a saída da última chamada de descriptografia do cifrador de bloco e denotar esses dados como . Também denotemos os blocos de texto plano e os blocos de texto cifrado . Olhe novamente para o diagrama do CBC e observe o que acontece:

Vamos chamar isso de "equação CBC".

No cenário da Alice, controlando o texto cifrado e observando a vazamento de informações sobre o texto plano correspondente, conseguimos organizar um ataque que recuperou o terceiro membro da equação – a chave. No cenário CBC, também controlamos o texto cifrado e observamos vazamentos de informações sobre o texto plano correspondente. Se a analogia se aplica, poderemos obter informações sobre .

Suponhamos que realmente recuperamos , e então? Bem, então podemos imediatamente revelar todo o último bloco do texto plano (), simplesmente inserindo (que temos) e
o resultante na equação CBC.

Assim, estamos otimistas em relação ao plano geral do ataque, e é hora de trabalhar nos detalhes. Observamos de que forma exatamente ocorre a vazamento de informações sobre o texto plano no servidor. No cenário da Alice, a vazamento ocorreu porque Alice respondia com a mensagem correta apenas se $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ terminasse com a string a (ou bb, e assim por diante, mas as chances de uma ativação acidental dessas condições eram muito baixas). De maneira semelhante ao CBC, o servidor aceita o preenchimento se e somente se termina em hexadecimal. 01Então, vamos tentar o mesmo truque: enviar textos cifrados falsos com nossos próprios valores falsos , até que o servidor aceite o preenchimento.

Quando o servidor aceita o preenchimento para uma de nossas mensagens falsas, isso significa que:

Agora usemos a propriedade byte a byte do XOR:

Sabemos o primeiro e o terceiro membro. E já vimos que isso permite recuperar o membro restante – o último byte de :

Isso também nos dá o último byte do bloco final do texto plano através da equação CBC e da propriedade byte a byte.

Poderíamos parar aqui e nos contentar em ter realizado um ataque a um cifrador teoricamente resistente. Mas, na verdade, podemos fazer muito mais: realmente podemos recuperar todo o texto. Isso requer um certo truque que não estava no cenário original da Alice e não faz parte das condições obrigatórias do ataque oráculo, mas o método ainda vale a pena ser estudado.

Para entendê-lo, primeiro observe que o resultado da dedução do valor correto do último byte Temos uma nova habilidade. Agora, ao manipular textos cifrados, podemos controlar o último byte do texto plano correspondente. Isso está relacionado à equação CBC e à propriedade byte a byte:

Como agora conhecemos o segundo termo, podemos usar nosso controle sobre o primeiro para gerenciar o terceiro. Nós simplesmente calculamos:

Antes, não podíamos fazer isso, porque não tínhamos o último byte. .

Como isso nos ajudará? Suponha que agora vamos criar todos os textos cifrados de forma que o último byte nos textos planos correspondentes seja 02. Agora, o servidor aceita o preenchimento apenas se o texto plano terminar com 02 02. Como corrigimos o último byte, isso só acontecerá se o penúltimo byte do texto plano também for igual a 02. Continuamos enviando blocos de texto cifrado falsificados, alterando o penúltimo byte, até que o servidor aceite o preenchimento para um deles. Nesse momento, obtemos:

E recuperamos o penúltimo byte da mesma forma que recuperamos o último. Continuamos assim: corrigimos os últimos dois bytes do texto plano para 03 03, repetimos esse ataque para o terceiro byte a partir do final e assim por diante, até que finalmente restauramos .

E quanto ao restante do texto? Note que o valor na verdade é $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Podemos colocar qualquer outro bloco em vez de , e o ataque ainda será bem-sucedido. De fato, podemos pedir ao servidor para fazer $inline$text{BLOCK_DECRYPT}$inline$ para quaisquer dados. Nesse momento, o jogo acabou - podemos descriptografar qualquer texto cifrado (dê mais uma olhada no diagrama de descriptografia do CBC para se certificar; e note que o vetor IV é público).

Este método específico desempenha um papel crucial no ataque do oráculo, que abordaremos mais tarde.

Ataque de Kelsey

John Kelsey, que tem um espírito semelhante ao nosso, expôs os princípios fundamentais que sustentam muitos ataques potenciais, e não apenas os detalhes específicos de um ataque a um determinado cifrador. Seu artigo de 2002 é um estudo sobre possíveis ataques a dados comprimidos e criptografados. Você pensou que para realizar um ataque era necessário mais do que apenas a informação de que os dados foram comprimidos antes da criptografia? Ao que parece, não é o caso.

Esse resultado surpreendente é causado por dois princípios. Primeiro, existe uma forte correlação entre o comprimento do texto aberto e o comprimento do texto cifrado; para muitos cifrados, a igualdade exata. Em segundo lugar, quando a compressão é realizada, também há uma forte correlação entre o comprimento da mensagem comprimida e o grau de "ruído" do texto aberto, ou seja, a proporção de caracteres não repetidos (termo técnico - "alta entropia").

Para ver o princípio em ação, consideremos dois textos abertos:

Texto aberto 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Texto aberto 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Suponha que ambos os textos abertos sejam comprimidos e, em seguida, cifrados. Você obtém dois textos cifrados resultantes e deve adivinhar qual texto cifrado corresponde a qual texto aberto:

Texto cifrado 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA
Texto cifrado 2: DWKJZXYU

A resposta é clara. Entre os textos abertos, apenas o texto aberto 1 poderia ser comprimido até o comprimento escasso do segundo texto cifrado. Descobrimos isso sem saber nada sobre o algoritmo de compressão, a chave de cifragem ou mesmo o próprio cifrado. Em comparação com a hierarquia de possíveis ataques criptográficos, isso é uma espécie de loucura.

Kelsey também observa que, em certas circunstâncias incomuns, esse princípio pode ser usado para executar um ataque de oráculo. Em particular, ele descreve como um invasor pode recuperar o texto aberto secreto se conseguir fazer o servidor cifrar dados de formulário (texto aberto, seguido de , enquanto controla e pode, de alguma forma, verificar o comprimento do resultado cifrado.

Novamente, como em outros ataques de oráculo, temos uma relação:

Novamente, controlamos um membro (), vemos uma pequena vazão de informações sobre o outro membro (texto cifrado) e tentamos recuperar o último (texto aberto). Apesar da analogia, isso é uma situação um pouco incomum em comparação com outros ataques de oráculo que vimos.

Para ilustrar como tal ataque pode funcionar, usamos um esquema fictício de compressão que acabamos de inventar: TOYZIP. Ele procura por linhas de texto que já apareceram anteriormente no texto e as substitui por três bytes preenchendo, que indicam onde encontrar uma instância anterior da linha e quantas vezes ela aparece lá. Por exemplo, a linha helloworldhello pode ser compactada em helloworld[00][00][05] comprimento de 13 bytes em comparação com o original de 15 bytes.

Suponha que um invasor esteja tentando recuperar o texto plano do formulário password=..., onde a própria senha é desconhecida. De acordo com o modelo de ataque de Kelsey, o invasor pode pedir ao servidor para compactar e, em seguida, criptografar as mensagens do formulário (texto plano seguido ), onde — de texto arbitrário. Quando o servidor termina, ele informa o comprimento do resultado. O ataque prossegue da seguinte forma:

Hacker: Por favor, compacte e criptografe o texto plano sem qualquer preenchimento.
Servidor: O comprimento do resultado é 14.
Hacker: Por favor, compacte e criptografe o texto plano ao qual foi adicionado password=a.
Servidor: O comprimento do resultado é 18.

O invasor observa: [original 14] + [três bytes que substituíram password=] + a

Hacker: Por favor, compacte e criptografe o texto plano ao qual foi adicionado password=b.
Servidor: O comprimento do resultado é 18.
Hacker: Por favor, compacte e criptografe o texto plano ao qual foi adicionado password=с.
Servidor: O comprimento do resultado é 17.

O invasor observa: [original 14] + [três bytes que substituíram password=c]. Isso sugere que o texto plano original contém a string password=c. Ou seja, a senha começa com a letra c

Hacker: Por favor, compacte e criptografe o texto plano ao qual foi adicionado password=сa.
Servidor: O comprimento do resultado é 18.

O invasor observa: [original 14] + [três bytes que substituíram password=с] + a

Hacker: Por favor, compacte e criptografe o texto plano ao qual foi adicionado password=сb.
Servidor: O comprimento do resultado é 18.

(… algum tempo depois…)

Hacker: Por favor, compacte e criptografe o texto plano ao qual foi adicionado password=со.
Servidor: O comprimento do resultado é 17.

O invasor observa: [original 14] + [três bytes que substituíram password=co]. Pela mesma lógica, o invasor conclui que a senha começa com as letras co

E assim por diante até que toda a senha seja recuperada.

É compreensível que o leitor pense que isso é um exercício puramente acadêmico e que tal cenário de ataque nunca ocorreria no mundo real. Infelizmente, como veremos em breve, na criptografia é melhor não fazer suposições.

Vulnerabilidades de marca: CRIME, POODLE, DROWN

Por fim, após uma análise detalhada da teoria, podemos ver como esses métodos são aplicados em ataques criptográficos reais.

CRIME

Se o ataque se concentra no navegador e na rede da vítima, algo será mais fácil e algo será mais difícil. Por exemplo, é fácil ver o tráfego da vítima: basta estar no mesmo café com ela com WiFi. Por essa razão, geralmente é recomendado que as potenciais vítimas (ou seja, todos) usem uma conexão criptografada. Será mais complicado, mas ainda assim possível, realizar requisições HTTP em nome da vítima para algum site externo (por exemplo, Google). O invasor deve atrair a vítima para uma página da web maliciosa com um script que fará a requisição. O navegador da web fornecerá automaticamente o cookie de sessão apropriado.

Isso parece surpreendente. Se Bob acessou evil.com, será que o script deste site pode simplesmente pedir ao Google para enviar a senha do Bob por e-mail para attacker@evil.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (Cross-Site Request Forgery, CSRF), e era popular por volta do meio dos anos 90. Hoje, se evil.com tentar esse truque, o Google (ou qualquer site respeitável) normalmente responderá: “Ótimo, mas seu token CSRF para esta transação será… hmmm… três trilhões e sete. Por favor, repita esse número”. Navegadores modernos aplicam algo chamado ‘política de mesma origem’ (same-origin policy), segundo a qual scripts no site A não têm acesso a informações enviadas pelo site B. Portanto, o script em evil.com pode enviar solicitações para google.com, mas não pode ler as respostas ou realmente concluir a transação.

Devemos enfatizar que se Bob não usa uma conexão criptografada, todas essas proteções são inúteis. Um invasor pode simplesmente ler o tráfego de Bob e recuperar a sessão do Google. Com esse cookie, ele simplesmente abrirá uma nova aba do Google, sem sair de seu próprio navegador, e se passará por Bob, sem enfrentar as incômodas políticas de mesma origem. Mas, infelizmente para o invasor, isso se torna cada vez mais raro. A Internet, como um todo, declarou guerra às conexões não criptografadas, e o tráfego de saída de Bob provavelmente é criptografado, quer ele goste ou não. Além disso, desde o início da implementação do protocolo, o tráfego também foi compactado antes da criptografia; era uma prática comum para reduzir a latência.

Aqui entra em cena CRIME (Compression Ratio Infoleak Made Easy, uma simples vazamento através da taxa de compressão). A vulnerabilidade, que foi demonstrada em setembro de 2012 pelos pesquisadores de segurança Giuliano Rizzo e Thai Duong. Já abordamos toda a base teórica que permite entender o que eles fizeram e como. O invasor pode fazer com que o navegador de Bob envie solicitações ao Google e, em seguida, monitorar as respostas na rede local em forma compactada e criptografada. Portanto, temos:

Aqui o invasor controla a solicitação e tem acesso a um sniffer de tráfego, incluindo o tamanho dos pacotes. O cenário fictício de Kelsey se tornou realidade.

Compreendendo a teoria, os autores do CRIME criaram um exploit que pode roubar cookies de sessão para uma ampla gama de sites, incluindo Gmail, Twitter, Dropbox e Github. A vulnerabilidade afetou a maioria dos navegadores da web modernos, resultando em patches que silenciosamente sepultaram a função de compressão no SSL, para que não fosse utilizada. O único protegido contra a vulnerabilidade foi o venerável Internet Explorer, que nunca usou compressão SSL.

POODLE

Em outubro de 2014, a equipe de segurança do Google causou alvoroço na comunidade de segurança. Eles conseguiram explorar uma vulnerabilidade no protocolo SSL que foi corrigida há mais de dez anos.

Aparentemente, embora servidores estejam executando o novíssimo TLSv1.2, muitos deixaram o suporte ao obsoleto SSLv3 por conta da compatibilidade retroativa com o Internet Explorer 6. Já falamos sobre ataques de retrocesso, então você pode imaginar o que estava acontecendo. Um sabotagem bem organizada do protocolo de handshake - e os servidores estão prontos para voltar ao velho SSLv3, basicamente anulando os últimos 15 anos de pesquisas em segurança.

Para contexto histórico, aqui está um breve resumo da história do SSL até a versão 2 por Matthew Green:

Transport Layer Security (TLS) é o protocolo de segurança mais importante na internet. [..] Quase cada transação que você realiza na internet depende do TLS. [..] Mas o TLS nem sempre foi TLS. O protocolo começou sua vida em Netscape Communications sob o nome de "Secure Sockets Layer" ou SSL. Há rumores de que a primeira versão do SSL era tão horrível que os desenvolvedores pegaram todas as impressões do código e enterraram em um local secreto no Novo México. Como consequência, a primeira versão pública do SSL é, na verdade, a versão SSL 2. Ela é bem assustadora, e [..] foi um produto dos anos 90, que os criptógrafos modernos consideram como "as idades sombrias da criptografia". Muitos dos ataques criptográficos mais horríveis que conhecemos hoje ainda não tinham sido descobertos. Como resultado, os desenvolvedores do protocolo SSLv2 tiveram que, essencialmente, tatear no escuro, e encontraram muitos monstros horripilantes — para desagrado deles e benefício nosso, uma vez que os ataques ao SSLv2 deixaram lições inestimáveis para a próxima geração de protocolos.

Após esses eventos, em 1996, a desapontada empresa Netscape reestruturou o protocolo SSL do zero. O resultado foi o SSL na versão 3, que corrigiu várias falhas de segurança conhecidas de seu antecessor..

Felizmente para os hackers, "várias" não significa "todas". No geral, o SSLv3 fornecia todos os blocos de construção necessários para realizar o ataque de Ваdené. O protocolo utilizava um algoritmo de cifragem em bloco no modo CBC com um esquema de preenchimento inseguro (que foi corrigido no TLS; portanto, surgiu a necessidade de um ataque de downgrade). Se você se lembra do esquema de preenchimento na nossa descrição original do ataque de Ваdené, o esquema do SSLv3 é bastante semelhante.

Mas, infelizmente para os hackers, "semelhante" não significa "idêntico". O esquema de preenchimento do SSLv3 consiste em "N bytes arbitrários, seguidos do número N". Tente, nessas condições, escolher um bloco imaginário de texto cifrado e passar por todas as etapas do esquema original de Ваdené: você descobrirá que o ataque consegue extrair com sucesso o último byte do bloco correspondente de texto claro, mas não avança além disso. Decifrar cada 16º byte do texto cifrado é um ótimo truque, mas não é uma vitória.

Enfrentando um fracasso, a equipe do Google optou por uma alternativa drástica: eles mudaram para um modelo de ameaça mais poderoso — aquele utilizado no CRIME. Assumindo que o atacante é um script executado na aba do navegador da vítima e pode extrair cookies de sessão, o ataque ainda se mantém impressionante. Embora o modelo de ameaça mais amplo seja menos realista, já vimos na seção anterior que este modelo específico é viável.

Considerando as capacidades mais poderosas do atacante, o ataque pode agora continuar. Lembre-se de que o invasor sabe onde o arquivo de sessão criptografado do cookie é exibido no cabeçalho e controla o comprimento do pedido HTTP que o precede. Portanto, ele é capaz de manipular o pedido HTTP para alinhar o último byte do cookie de acordo com o final do bloco. Agora, esse byte é adequado para decifração. Pode-se simplesmente adicionar um caractere à solicitação, e o penúltimo byte do cookie permanecerá no mesmo lugar e poderá ser ajustado pelo mesmo método. O ataque continua dessa forma até que o arquivo de cookie seja completamente restaurado. Isso é chamado de POODLE: Padding Oracle on Downgraded Legacy Encryption, oráculo de preenchimento sobre criptografia legado rebaixada.

DROWN

Como já mencionamos, o SSLv3 tinha suas falhas, mas era radicalmente diferente do seu antecessor, pois o SSLv2 com vulnerabilidades era um produto de outra era. Lá se poderia interromper a mensagem no meio: só aceitarei isso sobre meu cadáver transformava-se em aceitarei isso; cliente e servidor podiam se encontrar na internet, estabelecer confiança e trocar segredos diante dos olhos do invasor, que facilmente se passava por qualquer um dos dois. E havia também o problema da criptografia de exportação, que mencionamos ao discutir o FREAK. Era uma Sodoma e Gomorra criptográfica.

Em março de 2016, uma equipe de pesquisadores de várias áreas técnicas se reuniu e fez uma descoberta surpreendente: o SSLv2 ainda era utilizado em sistemas de segurança. Sim, os invasores não podiam mais rebaixar as sessões TLS modernas para SSLv2, pois essa brecha foi fechada após o FREAK e o POODLE, mas eles ainda podiam se conectar a servidores e iniciar sessões SSLv2 por conta própria.

Você pode perguntar: que nos importa o que eles estão fazendo? Eles têm uma sessão vulnerável, mas isso não deveria afetar outras sessões ou a segurança do servidor — certo? Bem, não exatamente. Sim, deveria ser assim em teoria. Mas não é — porque a geração de certificados SSL impõe uma certa carga, fazendo com que muitos servidores utilizem os mesmos certificados e, como resultado, as mesmas chaves RSA para conexões TLS e SSLv2. O que é ainda pior, por causa de um bug no OpenSSL, nessa implementação popular do SSL, a opção 'Desabilitar SSLv2' simplesmente não funcionava.

Isso possibilitou um ataque de protocolo cruzado ao TLS, que foi chamado de DROWN (Decrypting RSA with Obsolete and Weakened eNcryption, descriptografando RSA com criptografia obsoleta e enfraquecida). Vale lembrar que isso não é o mesmo que um ataque de downgrade; o invasor não precisa agir como um 'homem no meio' e não precisa envolver o cliente em uma sessão insegura. Os atacantes simplesmente iniciam uma sessão SSLv2 insegura com o servidor, atacam o protocolo fraco e recuperam a chave privada do servidor RSA. Esta chave também é válida para conexões TLS, e a partir desse momento, nenhuma segurança TLS poderá salvá-la de ser comprometida.

Mas, para a invasão, é necessária uma exploração funcional contra o SSLv2 que permita recuperar não apenas o tráfego específico, mas também a chave privada do servidor RSA. Embora isso seja uma tarefa complexa, os pesquisadores puderam escolher qualquer vulnerabilidade que tivesse sido completamente fechada após o SSLv2. No final, encontraram uma opção adequada: o ataque de Bleichenbacher, sobre o qual falamos anteriormente e explicaremos em detalhes no próximo artigo. SSL e TLS estão protegidos contra esse ataque, mas algumas funções aleatórias do SSL, juntamente com chaves curtas na criptografia de classe de exportação, tornaram possível uma implementação específica do DROWN.

Na data da publicação, 25% dos principais sites da internet eram suscetíveis a vulnerabilidades do DROWN, e a ataque poderia ser realizado com recursos modestos, disponíveis até mesmo para hackers individuais travessos. Para extrair a chave RSA do servidor, eram necessárias oito horas de computação e $440, e o SSLv2 mudou seu status de 'obsoleto' para 'radioativo'.

Espere, e quanto ao Heartbleed?

Isso não é um ataque criptográfico no sentido das descrições acima; é um estouro de buffer.

Vamos fazer uma pausa

Começamos com alguns métodos básicos: força bruta, interpolação, downgrade, protocolo cruzado e pré-cálculo. Então, revisamos uma técnica avançada, possivelmente o principal componente dos ataques criptográficos modernos: o ataque de oráculo. Passamos um bom tempo lidando com isso - e compreendemos não apenas o princípio subjacente, mas também os detalhes técnicos de duas implementações específicas: o ataque de Vaudenay ao modo de cifra CBC e o ataque de Kelsey aos protocolos de cifra com pré-compressão.

Ao revisar ataques de downgrade e com cálculos preliminares, resumimos o ataque FREAK, que utiliza ambos os métodos, uma vez que os sites-alvo são reduzidos a chaves fracas e depois reutilizam as mesmas chaves. Para o próximo artigo, deixamos o ataque Logjam (muito semelhante), que se concentra em algoritmos com chave pública.

Em seguida, examinamos mais três exemplos da aplicação desses princípios. Primeiro, CRIME e POODLE: dois ataques que se basearam na capacidade de um invasor injetar texto aberto arbitrário próximo ao texto aberto alvo e, em seguida, estudar as respostas do servidor e em seguida, utilizando a metodologia de ataque do oráculo, usar essas informações escassas para recuperar parcialmente o texto aberto. O CRIME seguiu o caminho do ataque Kelsey na compressão SSL, enquanto o POODLE utilizou uma variante do ataque Wadené em CBC com o mesmo efeito.

Em seguida, prestamos atenção ao ataque de protocolo cruzado DROWN, que estabelece uma conexão com o servidor através do antigo protocolo SSLv2 e depois recupera chaves secretas do servidor usando o ataque Bleichenbacher. Até o momento, omitimos os detalhes técnicos desse ataque; assim como o Logjam, ele precisará esperar até estudarmos bem os sistemas criptográficos com chave pública e suas vulnerabilidades.

No próximo artigo, falaremos sobre ataques avançados — como o método meet-in-the-middle, análise cripto diferencial e o ataque dos 'dias de nascimento'. Faremos uma breve incursão em ataques por canais laterais e, em seguida, nos concentraremos na parte mais intrigante — sistemas criptográficos com chave pública.

Fonte: habr.com