Na palavra "criptografia", alguns se lembram da senha do Wi-Fi, um cadeado verde ao lado do endereço do site favorito e o quão difícil é entrar no correio de outra pessoa. Outros se lembram de uma série de vulnerabilidades dos últimos anos com abreviações de fala (DROWN, FREAK, POODLE ...), logotipos elegantes e um aviso atualizando urgentemente o navegador.

A criptografia cobre tudo isso, mas a essência é diferente. A linha inferior é entre simples e complexo. Algumas coisas são fáceis de fazer, mas difíceis de recuperar: por exemplo, quebrar um ovo. Outras coisas são fáceis de fazer, mas difíceis de recuperar quando falta uma parte crucial crucial: por exemplo, abrir uma porta trancada quando a “parte crítica” é a chave. A criptografia estuda essas situações e como usá-las na prática.

Nos últimos anos, a coleção de ataques criptográficos se transformou em um zoológico de logotipos chamativos cheios de fórmulas de artigos científicos e criou uma sensação sombria geral de que tudo está quebrado. Mas, de fato, muitos dos ataques são baseados em vários princípios gerais, e as infinitas páginas de fórmulas geralmente se resumem a idéias fáceis de entender.

Nesta série de artigos, examinaremos vários tipos de ataques criptográficos, com ênfase em princípios básicos. Em termos gerais e não exatamente nessa ordem, mas informaremos o seguinte:

• Estratégias básicas: força bruta, análise de frequência, interpolação, downgrade e protocolos cruzados.
  
• Vulnerabilidades da marca: FREAK, CRIME, POODLE, DROWN, Logjam.
  
• Estratégias avançadas: ataques do Oracle (ataque de Woden, ataque de Kelsey); método de encontro no meio (meet-in-the-middle), ataque de aniversários, viés estatístico (criptoanálise diferencial, criptoanálise integral, etc.).
  
• Ataques de terceiros 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 Polyg - Hellman, peneira numérica, ataque de Wiener, ataque de Bleichenbacher.

Este artigo em particular cobre o material acima até o ataque de Kelsey.

Estratégias básicas

Os seguintes ataques são simples no sentido de que podem ser quase completamente explicados sem detalhes técnicos especiais. Explicamos cada tipo de ataque nos termos mais simples, sem nos aprofundarmos em exemplos complexos ou casos de uso avançados.

Alguns desses ataques perderam principalmente relevância e não são usados ​​há muitos anos. Outros são veteranos, eles ainda se interessam regularmente por desenvolvedores de sistemas de criptografia desavisados ​​no século XXI. Podemos assumir que a era da criptografia moderna começou com o advento do IBM DES - a primeira cifra que resistiu a todos os ataques nesta lista.

Força bruta simples

O esquema de criptografia consiste em duas partes: 1) uma função de criptografia que recebe uma mensagem (texto sem formatação) em combinação com uma chave e cria uma mensagem criptografada - texto cifrado; 2) uma função de descriptografia que pega um texto cifrado e uma chave e cria texto sem formatação. Tanto a criptografia quanto a descriptografia devem ser fáceis de calcular com a chave - e difíceis sem ela.

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

Observe que existem duas suposições implícitas. Primeiramente, sabemos como executar a descriptografia, ou seja, como o sistema de criptografia funciona. Essa é uma suposição padrão ao discutir a criptografia. Ocultar os detalhes da implementação da cifra dos invasores pode parecer uma medida de segurança adicional, mas assim que o invasor descobre esses detalhes, essa segurança extra é invisível e irreversivelmente perdida. Este é o princípio de Kerchhoffs : cair nas mãos do inimigo não deve causar transtornos.

Em segundo lugar, assumimos que a chave correta é a única chave que levará a uma descriptografia razoável. Essa também é uma suposição razoável; é executado se o texto cifrado for muito maior que a chave e for bem lido. Como regra, é isso o que acontece no mundo real, com exceção de grandes chaves impraticáveis ou outras fraudes, que devem ser deixadas de lado (se você não gosta que descartamos as explicações, consulte o Teorema 3.8 aqui ).

Diante do exposto, surge uma estratégia: verifique todas as chaves possíveis. Isso é chamado de força bruta, e esse ataque é garantido para funcionar contra todas as cifras práticas - no final. Por exemplo, força bruta é suficiente para decifrar a cifra de César , uma cifra antiga, onde a chave é uma letra do alfabeto, o que implica um pouco mais de 20 chaves possíveis.

Infelizmente para os criptoanalistas, aumentar o tamanho da chave protege contra a força bruta. À medida que o tamanho da chave aumenta, o número de chaves possíveis aumenta exponencialmente. Com tamanhos de chave modernos, uma força bruta simples não é de todo prática. Para entender o que queremos dizer, vamos usar o supercomputador mais rápido conhecido em meados de 2019: o IBM's Summit , com desempenho máximo da ordem de 10 ¹⁷ operações por segundo. Hoje, um tamanho típico de chave é de 128 bits, o que significa ^2.128 combinações possíveis. A enumeração de todas as chaves exige que o supercomputador da Summit tome cerca de 7800 vezes a idade do universo.

A força bruta deve ser considerada uma curiosidade histórica? De maneira alguma: é um ingrediente necessário no livro de receitas da criptoanálise. Raramente são encontradas cifras tão fracas que podem ser quebradas apenas com um ataque inteligente, sem o uso da força em um grau ou outro. Muitos hacks bem-sucedidos usam o método algorítmico primeiro para enfraquecer a cifra de destino e depois executar a força bruta.

Análise de frequência

A maioria dos textos não é sem sentido. Por exemplo, nos textos em inglês há muitas letras 'e' e artigos 'the'; em arquivos binários - muitos bytes nulos como espaço reservado entre informações. Análise de frequência é qualquer ataque que explora esse fato.

Um exemplo canônico de uma cifra vulnerável a esse ataque é uma cifra de substituição simples. Nesta cifra, a chave é uma tabela com a substituição de todas as letras. Por exemplo, 'g' é substituído por 'h', 'o' por j; portanto, a palavra 'go' se transforma em 'hj'. Essa cifra é difícil à força bruta simples, pois existem tantas tabelas de pesquisa possíveis. Se você estiver interessado em matemática, o tamanho efetivo da chave é de cerca de 88 bits: este
$$$log_2 (26!)$ . Mas a análise de frequência geralmente faz o trabalho rapidamente.

Considere o seguinte texto cifrado processado com uma cifra de substituição simples:

  XDYLY ALY FEIA XDWNKE WN DYAJYN E YALXD DGLAXWG XDAN ALY FLYAUX GR WN OGQL ZDWBGEGZDO 

Como Y é comum, inclusive no final de muitas palavras, podemos assumir provisoriamente que esta é a letra e :

  XDeLe ALGL UGLe XDWNKE WN DEAJEN AND ALXD DGLAXWG XDAN ALe FLeAUX GR WN OGQL ZDWBGEGZDO 

O par XD é repetido no início de algumas palavras. Em particular, a combinação de XDeLe implica explicitamente a palavra this or there , então continuamos:

  O GLOBO MAIS VELHO DO MUNDO E GANHANDO DIREITO DA DGLAtWG DO QUE ALGUM FLUOU GR GR WN OGQL ZDWBGEGZDO 

Além disso, suponha que L corresponda a r , A - a e assim por diante. Você provavelmente terá que fazer várias tentativas, mas, comparado à força bruta total, esse ataque restaura o texto de origem o mais rápido possível:

  há mais coisas no céu e na terra do que os sonhados em sua filosofia 

Para alguns, a solução para esses "criptogramas" é um hobby fascinante.

A idéia da análise de frequência é mais fundamental do que parece à primeira vista. E isso se aplica a cifras muito mais complexas. Ao longo da história, vários projetos de cifras tentaram resistir a esse ataque usando a "substituição polialfabética". Aqui, no processo de criptografia, a tabela de substituição de letras muda de maneiras complexas, mas previsíveis, que dependem da chave. Todas essas cifras já foram consideradas difíceis de decifrar; e, no entanto, uma análise de frequência modesta acabou derrotando todos eles.

A cifra polialfabética mais ambiciosa da história, e provavelmente a mais famosa, foi a cifra Enigma na Segunda Guerra Mundial. Era relativamente complexo em comparação com seus antecessores, mas como resultado de um trabalho longo e árduo, os criptoanalistas britânicos o decifraram usando análise de frequência. Obviamente, eles não conseguiram desenvolver um ataque elegante, como mostrado acima; eles tiveram que comparar pares conhecidos de textos abertos e criptografados (o chamado "ataque de texto sem formatação") e até mesmo instigar os usuários do Enigma a criptografar determinadas mensagens com a análise do resultado ("ataque baseado no texto sem formatação selecionado"). Mas isso não facilitou o destino dos exércitos derrotados de inimigos e submarinos afundados.

Após esse triunfo, a análise de frequência desapareceu da história da criptoanálise. As cifras da era digital moderna são projetadas para trabalhar com bits, não com letras. Mais importante, essas cifras são projetadas com uma compreensão sombria do que mais tarde ficou conhecido como lei de Schneier : qualquer pessoa pode criar um algoritmo de criptografia que ele próprio não pode decifrar. Não basta que o sistema de criptografia pareça complicado: para provar seu valor, ele deve passar por uma análise de segurança implacável de muitos analistas de criptografia que farão todo o possível para decifrar a cifra.

Cálculos preliminares

Tome a cidade hipotética de Precom Heights com uma população de 200.000 habitantes. Em cada casa da cidade, existem objetos de valor em média US $ 30.000, mas não mais de US $ 50.000. O mercado de segurança em Precom foi monopolizado pela ACME Industries, que produz as lendárias fechaduras da classe Coyote (tm). Segundo a análise de especialistas, apenas uma máquina hipotética muito complexa pode quebrar uma trava da classe Coyote, cuja criação requer cerca de cinco anos e investimento de US $ 50.000. A cidade é segura?

Provavelmente não. No final, um criminoso bastante ambicioso aparecerá. Ele argumentará assim: “Sim, incorrerei em grandes custos iniciais. Cinco anos de expectativa do paciente e US $ 50.000, mas, depois de terminar o trabalho, terei acesso a toda a riqueza desta cidade . Se eu jogar minhas cartas corretamente, esse investimento será recompensado muitas vezes. ”

Da mesma forma, na criptografia. Os ataques contra uma cifra específica estão sujeitos a uma análise implacável dos custos e benefícios. Se a proporção for favorável, o ataque não ocorrerá. Mas os ataques que atacam imediatamente muitas vítimas em potencial quase sempre valem a pena e, nesse caso, a melhor prática de design é assumir que eles começaram desde o primeiro dia. Temos essencialmente uma versão criptográfica da lei de Murphy: "Tudo o que pode realmente quebrar o sistema irá quebrá-lo".

O exemplo mais simples de um sistema de criptografia vulnerável a um ataque com cálculos preliminares é uma cifra com um algoritmo constante sem o uso de uma chave. Esse foi o caso da cifra de César , que simplesmente desloca cada letra do alfabeto três letras para frente (a tabela está em loop, de modo que a última letra do alfabeto é criptografada com a terceira). Aqui, novamente, o princípio de Kerchhoffs se manifesta: assim que o sistema é invadido, ele é invadido para sempre.

O conceito é simples. Mesmo um desenvolvedor iniciante de sistema de criptografia provavelmente está ciente da ameaça e se prepara adequadamente. Se você observar a evolução da criptografia, esses ataques não são adequados para a maioria das cifras, começando com as primeiras versões aprimoradas da cifra de César, até o declínio das cifras polialfabéticas. Tais ataques retornaram apenas com o advento da era moderna da criptografia.

Esse retorno é devido a dois fatores. Primeiramente, finalmente, surgiram sistemas de criptografia bastante complexos, onde a possibilidade de exploração após hackers não era óbvia. Em segundo lugar, a criptografia é tão difundida que milhões de leigos tomam decisões todos os dias sobre onde e quais partes da criptografia serão reutilizadas. Demorou algum tempo até que os especialistas percebessem os riscos e disparassem o alarme.

Lembre-se do ataque com pré-computações: no final do artigo, consideraremos dois exemplos criptográficos da vida real, onde desempenhou um papel importante.

Interpolação

Aqui está o famoso detetive Sherlock Holmes, realizando um ataque com interpolação ao infeliz Dr. Watson:

Eu imediatamente adivinhei que você veio do Afeganistão ... Meus pensamentos eram os seguintes: “Essa pessoa é um médico por tipo, mas tem uma influência militar. Então, um médico militar. Acabara de chegar dos trópicos - seu rosto está escuro, mas esse não é um tom natural de sua pele, já que seus pulsos são muito mais brancos. O rosto emaciado, obviamente, sofreu muito e sofreu a doença. Ele foi ferido na mão esquerda - ele a mantém imóvel e um pouco artificial. Onde, sob os trópicos, um médico britânico poderia sofrer dificuldades e se machucar? Claro, no Afeganistão. ” Toda a linha de pensamento não levou um segundo. E então eu disse que você veio do Afeganistão e ficou surpreso.

De cada evidência individualmente, Holmes poderia extrair muito pouca informação. Ele poderia chegar a sua conclusão apenas examinando-os todos juntos. O ataque de interpolação funciona da mesma forma, explorando os pares conhecidos de textos abertos e criptografados obtidos como resultado da aplicação da mesma chave. Observações separadas são extraídas de cada par, o que nos permite tirar uma conclusão geral sobre a chave. Todas essas conclusões são vagas e inúteis até que subitamente atinjam uma massa crítica e levem à única conclusão possível: não importa quão incrível seja, deve ser verdade. Depois disso, a chave é aberta ou o processo de descriptografia se torna tão maduro que pode ser duplicado.

Ilustramos com um exemplo simples como a interpolação funciona. Suponha que desejemos ler o diário pessoal de nosso inimigo, Bob. Ele criptografa todos os números em seu diário com a ajuda de um sistema criptográfico simples, sobre o qual aprendeu com um anúncio na revista "Mockery of cryptography". O sistema funciona da seguinte maneira: Bob seleciona dois números que ele gosta: $$$M$ e $$$N$ . A partir de agora, para criptografar qualquer número $$$x$ ele calcula $$$Mx + N$ . Por exemplo, se Bob escolheu $$$M = 3$ e $$$N = 4$ então a figura $$$2$ criptografado como $$$3 * 2 + 4 = 10$ .

Suponha que tenhamos notado em 28 de dezembro que Bob estava coçando algo em seu diário. Quando ele termina, nós o pegamos em silêncio e vemos a última entrada:

Data: 235/520

Caro Diário,

Hoje foi um bom dia. Após 64 dias, tenho um encontro com Alice, que mora no apartamento 843 . Eu realmente acho que ela pode ter 26 !

Como pretendemos seguir seriamente Bob em seu encontro (nesse cenário, temos 15 anos), é fundamental descobrir a data e o endereço de Alice. Felizmente, percebemos que o sistema de criptografia de Bob é vulnerável a um ataque de interpolação. Podemos não saber $$$M$ e $$$N$ , mas sabemos a data de hoje, por isso temos dois pares de "texto simples - texto cifrado". Ou seja, sabemos que $$$12$ criptografado em $$$235$ e $$$27$ - em $$$520$ . O que escrevemos:

$$

$$M ∗ 12 + N = 235$$

$$

$$M ∗ 27 + N = 520$$

Desde os 15 anos, já conhecemos o sistema de duas equações com duas incógnitas, o que nessa situação é suficiente para encontrar $$$M$ e $$$N$ sem problemas. Cada par "texto sem formatação-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 $$$M = 19$ e $$$N = 7$ (em $$$19x + 7 = 26$ $$$x = 1$ , então 26 no diário corresponde à palavra 'aquele', ou seja, “o mesmo” - aprox. por.) .

Os ataques de interpolação, é claro, não se limitam a exemplos tão simples. Cada sistema de criptografia, que se resume a um objeto matemático bem conhecido e a uma lista de parâmetros, corre o risco de um ataque de interpolação - quanto mais compreensível o objeto, maior o risco.

Os iniciantes costumam reclamar que a criptografia é "a arte de projetar o mais feio possível". Os ataques de interpolação provavelmente são os principais culpados. Bob pode usar um design matemático elegante ou manter a confidencialidade de uma data com Alice - mas, infelizmente, geralmente você não pode obter os dois. Isso ficará muito claro quando finalmente passarmos ao tópico de criptografia de chave pública.

Protocolo cruzado / downgrade

No filme “A Ilusão da Decepção” (2013), um grupo de ilusionistas tenta enganar todo o estado do magnata corrupto Arthur Tressler, do seguro. Para obter acesso à conta bancária de Arthur, os ilusionistas devem fornecer 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 se apresentar no palco, e não a participar de operações de inteligência. Portanto, eles escolhem a terceira opção: o cúmplice liga para o banco e finge ser Arthur. O banco faz várias perguntas para verificação da identidade, como o nome do tio e o nome do primeiro animal de estimação; nossos heróis recebem com facilidade essas informações de Arthur com a ajuda de engenharia social inteligente . A partir de agora, a excelente segurança da senha não importa mais.

(De acordo com uma lenda da cidade, que verificamos e confirmamos pessoalmente, o criptógrafo Eli Behem encontrou uma caixa de banco que insistia em fazer uma pergunta secreta. Quando o caixa perguntou o nome da avó de sua mãe, Beeham começou a ditar: "Capital X, pequena, três ... ").

É o mesmo na criptografia, se dois protocolos criptográficos forem usados ​​em paralelo para proteger o mesmo ativo, enquanto um é muito mais fraco que o outro. O sistema resultante se torna vulnerável a um ataque de protocolo cruzado quando um protocolo mais fraco é atacado para chegar ao prêmio sem tocar em um mais forte.

Em alguns casos complexos, não basta entrar em contato com o servidor usando um protocolo mais fraco, e é necessária a participação involuntária de um cliente legítimo. Isso pode ser organizado usando o chamado ataque de downgrade. Para entender esse ataque, suponha que nossos ilusionistas tenham uma tarefa mais difícil do que no filme. Suponha que um funcionário do banco (caixa) e Arthur tivessem algumas circunstâncias imprevistas, como resultado do qual houve esse diálogo:

Ladrão: Alô? Este é Arthur Tressler. Gostaria de redefinir minha senha.

Caixa: Ótimo. Dê uma olhada no seu livro de códigos secreto pessoal, página 28, palavra 3. Todas as seguintes mensagens serão criptografadas com essa palavra em particular como chave. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV ...

Cracker: Ei, ei, espere um minuto. Isso é realmente necessário? Não podemos simplesmente conversar como pessoas normais?

Caixa: Eu não aconselho fazer isso.

Cracker: Eu apenas ... escute, eu tive um dia ruim, ok? Eu sou um cliente VIP e não estou com vontade de me aprofundar nesses estúpidos livros de códigos.

Caixa: Bom. Se você insiste, Sr. Tressler. O que voce quer

Cracker: Por favor, gostaria de transferir todo o meu dinheiro para o Fundo Nacional de Vítimas Arthur Tressler.

(Pausa)

Caixa: Ok. Forneça seu código PIN para grandes transações.

Cracker: Meu o quê?

Caixa: a seu pedido pessoal, transações desse tamanho requerem um PIN para grandes transações. Este código foi fornecido a você ao abrir uma conta.

Biscoito: ... eu o perdi. Isso é realmente necessário? Você não pode simplesmente aprovar o acordo?

Caixa: Nenhum. Sinto muito, Sr. Tressler. Novamente, esta é a medida de segurança que você solicitou. Se desejar, podemos enviar um novo código PIN para a caixa de correio.

Nossos heróis adiam a operação. Eles ouvem várias transações importantes da Tressler, esperando ouvir um código PIN; mas cada vez que a conversa se transforma em uma tagarelice criptografada antes que algo interessante soe lá. Finalmente, um dia o plano é executado. Eles esperam pacientemente o momento em que Tressler deve concluir uma grande transação por telefone, ele se conecta à linha e então ...

Thressler: Olá. Gostaria de emitir uma transação remota, por favor.

Caixa: Ótimo. Dê uma olhada no seu livro de códigos secretos pessoais, na página ...

(O cracker pressiona o botão; a voz do caixa se transforma em um ruído inaudível).

Caixa: - # @ $ # @ $ # * @ $$ @ # * serão criptografados com esta palavra como chave. AAAYRR PLRQRZ MMNJK LOJBAN ...

Thressler: Desculpe, eu não entendi direito. Mais uma vez Qual página? Qual é a palavra?

Caixa: Esta é a página @ # $ @ # * $) # * # @ () # @ $ (# @ * $ (# @ *.

Thressler: O que?

Caixa: Palavra número vinte @ $ # @ $ #% # $.

Thressler: Sério! Já chega! Você e seu protocolo de segurança são algum tipo de circo. Eu sei que você pode apenas falar normalmente comigo.

Caixa: Eu não aconselho ...

Thressler: E eu não aconselho você a perder meu tempo. Não quero ouvir mais sobre isso até resolver os problemas com minha linha telefônica. Podemos organizar este acordo ou não?

Caixa: ... sim. Bom O que voce quer

Thressler: Gostaria de transferir US $ 20.000 para a Lord Business Investments, número da conta ...

Caixa: Só um momento, por favor. Este é um grande negócio. Forneça seu código PIN para grandes transações.

Thressler: O que? Ah, com certeza. 1234

Aqui está o ataque de queda. O protocolo mais fraco, "apenas fale diretamente", foi concebido como uma opção em caso de emergência. E ainda estamos aqui.

Você pode fazer a pergunta de quem, em sã consciência, projetará um sistema real como "seguro até que seja solicitado o contrário", descrito acima. Mas, assim como um banco fictício corre riscos para salvar clientes que não gostam de criptografia, também os sistemas como um todo costumam atender a requisitos indiferentes ou até hostis à segurança.

Essa é exatamente a história que aconteceu com o SSLv2 em 1995. O governo dos EUA há muito tempo começou a considerar a criptografia como uma arma mais bem mantida longe de inimigos externos e internos. Os fragmentos de código foram aprovados individualmente para exportação dos Estados Unidos, geralmente sujeitos a um enfraquecimento intencional do algoritmo. O Netscape, o desenvolvedor do navegador mais popular, o Netscape Navigator, recebeu permissão SSLv2 apenas com uma chave RSA inicialmente vulnerável de 512 bits (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, por muitos anos, clientes e servidores suportam criptografia de "exportação" enfraquecida devido à mesma inércia que mantém o suporte a qualquer sistema desatualizado. Os clientes pensaram que poderiam encontrar um servidor que não suporta mais nada. Servidores fizeram o mesmo. Obviamente, o SSL determina que clientes e servidores nunca devem usar um protocolo fraco quando o melhor estiver disponível. Mas a mesma premissa era válida para Tressler e seu banco.

Essa teoria encontrou aplicação em dois ataques de alto perfil que abalaram a segurança do protocolo SSL, um após o outro em 2015, ambos descobertos por pesquisadores da Microsoft e do INRIA . Primeiro, em fevereiro, os detalhes do ataque FREAK foram revelados e, três meses depois, outro ataque semelhante chamado Logjam, que discutiremos em mais detalhes quando abordarmos ataques à criptografia de chave pública.

Vulnerabilidade O FREAK (também conhecido como "Smack TLS") apareceu quando os pesquisadores analisaram a implementação do TLS cliente / servidor e encontraram um erro curioso. Nessas implementações, se o cliente nem solicitar uma criptografia de exportação fraca, mas o servidor ainda responder com essas chaves, o cliente diz "OK" e alterna para um conjunto fraco de cifras.

Naquela época, todos consideravam a criptografia de exportação desatualizada e proibida de usar, então o ataque foi um choque real e afetou muitos domínios importantes, incluindo os sites da Casa Branca, o escritório de impostos dos EUA e a NSA. Pior ainda, muitos servidores vulneráveis ​​otimizavam o desempenho reutilizando as mesmas chaves em vez de criar novas para cada sessão. Isso possibilitou, após a redução do protocolo, realizar um ataque com pré-computação: hackear uma chave permaneceu relativamente caro (US $ 100 e 12 horas no momento da publicação), mas o custo prático de atacar a conexão diminuiu significativamente. Basta pegar a chave do servidor uma vez e decifrar as cifras para todas as conexões subseqüentes a partir de agora.

E antes de prosseguir, precisamos mencionar um ataque avançado ...

Ataque Oracle

Moxie Marlinspike é mais conhecido como o pai do cross-platform Signal messenger;mas, pessoalmente, gostamos de uma de suas inovações menos conhecidas - o princípio da destruição criptográfica (Princípio da Perdição Criptográfica). Parafraseando um pouco, podemos dizer o seguinte: "Se o protocolo executar qualquer operação criptográfica em uma mensagem de uma fonte potencialmente maliciosa e se comportar de maneira diferente dependendo do resultado, ele estará condenado". Ou de uma forma mais nítida: "Não pegue as informações do inimigo para processamento e, se necessário, pelo menos não mostre o resultado".

Deixe de lado estouros de buffer, injeções de instruções e similares; eles estão além do escopo desta discussão. A violação do "princípio da desgraça" leva a uma séria invasão da criptografia devido ao fato de o protocolo se comportar exatamente como deveria.

Por exemplo, adote um design fictício com uma cifra de substituição vulnerável e demonstre um possível ataque. Embora já tenhamos visto um ataque a uma cifra de substituição usando análise de frequência, essa não é apenas “outra maneira de quebrar a mesma cifra”. Por outro lado, os ataques oraculares são uma invenção muito mais moderna, aplicável a muitas situações em que a análise de frequência falha, e veremos uma demonstração disso na próxima seção. Aqui, uma cifra simples é escolhida apenas para tornar o exemplo mais claro.

Então, Alice e Bob se comunicam usando uma cifra de substituição simples usando uma chave conhecida apenas por eles. Eles são muito rigorosos quanto ao tamanho das mensagens: o tamanho é exatamente de 20 caracteres. Portanto, eles concordaram que, se alguém quiser enviar uma mensagem mais curta, deverá adicionar algum texto fictício ao final da mensagem para que ele tenha exatamente 20 caracteres. Depois de alguma discussão, eles decidiram que só aceitaria o seguinte texto fictício: a, bb, ccc, dddd, etc. Assim, o conhecido texto fictício de qualquer comprimento desejado ...

Quando Alice ou Bob recebem a mensagem, eles primeiro verificam se a mensagem tem o tamanho correto (20 caracteres) e o sufixo é o texto fictício correto. Se não for esse o caso, eles responderão com a mensagem de erro correspondente. Se o tamanho 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 atacante finge ser Bob e envia mensagens falsas para Alice. Mensagens - absurdo completo - o atacante não possui uma chave e, portanto, não pode falsificar uma mensagem significativa. Mas como o protocolo viola o princípio da destruição, um invasor ainda pode prender Alice, para que ela revele informações sobre a chave, como mostrado abaixo.

: PREWF ZHJKL MMMN. LA

: .

: PREWF ZHJKL MMMN. LB

: .

: PREWF ZHJKL MMMN. LC

: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

, , , C a , .

: REWF ZHJKL MMMN. LAA

: .

: REWF ZHJKL MMMN. LBB

: .

…

: REWF ZHJKL MMMN. LGG

: .

: REWF ZHJKL MMMN. LHH

: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

Mais uma vez, o cracker não faz ideia do que Alice acabou de dizer, mas observa que H deve corresponder a b porque Alice aceitou o texto fictício.

E assim por diante, até o atacante descobrir o significado de cada personagem.

À primeira vista, o método se assemelha a um ataque com base no texto simples selecionado. No final, o atacante pega textos cifrados e o servidor os processa obedientemente. A principal diferença que torna esses ataques viáveis ​​no mundo real é que o invasor não precisa acessar a descriptografia real - apenas a resposta do servidor, mesmo tão inofensiva quanto o "Texto fictício errado", é suficiente.

Embora esse ataque em particular seja instrutivo, não se deve ficar muito focado nas especificidades do esquema de "texto fictício", no sistema de criptografia específico usado ou na seqüência exata de mensagens enviadas pelo invasor. A idéia principal é como Alice reage de maneira diferente com base nas propriedades do texto sem formatação e faz isso sem verificar se o texto criptografado correspondente é realmente recebido de uma parte confiável. Assim, Alice permite que um invasor extraia informações secretas de suas respostas.

Há muito o que mudar nesse cenário. Os personagens aos quais Alice reage, ou a própria diferença de comportamento, ou mesmo o sistema de criptografia usado. Mas o princípio permanecerá o mesmo, e o ataque como um todo permanecerá viável de uma forma ou de outra. A implementação básica desse ataque ajudou a detectar vários erros de segurança que abordaremos em breve; mas primeiro algumas lições teóricas devem ser aprendidas. Como usar esse "roteiro de Alice" fictício em um ataque capaz de trabalhar em uma cifra moderna moderna? Isso é possível, mesmo em teoria?

Em 1998, o criptógrafo suíço Daniel Bleichenbacher respondeu afirmativamente a essa pergunta. Ele demonstrou um ataque do oracle em um sistema de criptografia de chave pública RSA amplamente usado usando um esquema de mensagens específico. Em algumas implementações de RSA, o servidor responde com diferentes mensagens de erro, dependendo se o texto sem formatação corresponde ou não ao esquema; isso foi suficiente para lançar um ataque.

Quatro anos depois, em 2002, o criptógrafo francês Serge Vaudenay demonstrou um ataque do oráculo, quase idêntico ao descrito no script de Alice acima - exceto que, em vez de uma cifra fictícia, ele quebrou toda uma classe respeitável de cifras modernas que as pessoas realmente use. Em particular, o ataque de Wodene tem como alvo cifras com um tamanho fixo de entrada ("cifras de bloco") quando usadas no chamado "modo de criptografia CBC" e com um certo esquema de preenchimento popular, basicamente equivalente ao do script de Alice.

Também em 2002, o criptógrafo americano John Kelsey, co-autor de Twofish- propôs vários ataques oracle a sistemas que compactam mensagens e depois as criptografam. O mais notável entre eles foi o ataque, que usou o fato de que muitas vezes é possível derivar o tamanho original do texto sem formatação do comprimento do texto cifrado. Em teoria, isso permite um ataque do oráculo que restaura partes do texto simples original.

A seguir, fornecemos uma descrição mais detalhada dos ataques de Woden e Kelsey (forneceremos uma descrição mais detalhada do ataque de Bleichenbacher quando passarmos para ataques à criptografia de chave pública). Apesar de todos os nossos esforços, o texto se torna um pouco técnico; portanto, se as opções acima forem suficientes, pule as próximas duas seções.

Ataque de Woden

Para entender o ataque Woden, primeiro você precisa falar um pouco mais sobre as cifras de bloco e os modos de criptografia. Uma “cifra de bloco” é, como já mencionado, uma cifra que aceita uma chave e insere um determinado comprimento fixo (“comprimento do bloco”) e produz um bloco criptografado do mesmo comprimento. As cifras de bloco são amplamente utilizadas e são consideradas relativamente seguras. O DES agora aposentado, considerado a primeira cifra moderna, era irregular. Como mencionado acima, o mesmo se aplica à AES, hoje amplamente utilizada.

Infelizmente, as cifras de bloco têm uma fraqueza evidente. Um tamanho de bloco típico é de 128 bits ou 16 caracteres. Obviamente, a criptografia moderna exige o trabalho com dados de entrada maiores, e é aí que os modos de criptografia aparecem. O modo de criptografia é essencialmente um hack: é uma maneira de aplicar de alguma forma uma cifra de bloco, que aceita dados de entrada de apenas um determinado tamanho, para inserir dados de comprimento arbitrário.

O ataque Woden está focado no popular modo de operação CBC (Cipher Block Chaining, modo de acoplamento de bloco de texto cifrado). O ataque vê a cifra do bloco base como uma caixa preta mágica inexpugnável e ignora completamente sua segurança.

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





O sinal de mais circulado significa a operação XOR (OU exclusivo). Por exemplo, o segundo bloco de texto cifrado é recebido:

1. Executando uma operação XOR no segundo bloco de texto sem formatação com o primeiro bloco de texto cifrado.
   
2. Criptografe o bloco recebido usando uma cifra de bloco usando uma chave.

Como o CBC usa a operação binária do XOR de maneira tão intensa, vamos dedicar um momento para recuperar algumas de suas propriedades:

• Idempotência: $$$A \oplus 0 = A$
  
• Comutatividade: $$$A \oplus B = B \oplus A$
  
• Associatividade: $$$A \oplus (B \oplus C) = (A \oplus B) \oplus C$
  
• Auto-reversibilidade: $$$A \oplus A = 0$
  
• Byte-byte: Byte n de $$( A ⊕ B ) = (byte n de$(A \oplus B)$$$$A$ ) $$⊕ (byte n de$\oplus$$$$B$ )

Normalmente, essas propriedades implicam que, se tivermos uma equação que inclua operações XOR e uma desconhecida, ela poderá ser resolvida. Por exemplo, se sabemos que$$A ⊕ X = B com desconhecido$A \oplus X = B$$$X e famoso$X$$$$A$ e $$B , então podemos confiar nas propriedades acima para resolver a equação de$B$$$$X$ . Aplicando XOR em ambos os lados da equação com $$A temos$A$$$$X = A \oplus B$ .Em um momento, tudo isso se tornará muito relevante.

Existem duas pequenas diferenças e uma grande diferença entre nosso script de Alice e o ataque de Woden. Dois menores:

• No cenário de Alice esperar que a extremidade aberta no texto a, bb, ccce assim por diante. Em um ataque de Woden, a vítima espera que o texto simples termine N vezes com o byte N (ou seja, hexadecimal 01 ou 02 02 ou 03 03 03 e assim por diante). Esta é uma diferença puramente cosmética.
  
• No roteiro de Alice, era fácil dizer se Alice havia recebido a mensagem em resposta a "Texto fictício errado". No ataque de Woden, são necessárias mais análises e uma implementação precisa do lado da vítima é importante; mas, por brevidade, tomamos como certo que essa análise ainda é possível.

A principal diferença:

• , ( ), , . .

Essa é a principal diferença - a última peça do quebra-cabeça para entender o ataque de Woden, então vamos pensar por um momento sobre o porquê e como você pode organizar um ataque de oráculo na CBC.

Suponha que um texto cifrado na CBC de 247 blocos seja fornecido e desejemos descriptografá-lo. Podemos enviar mensagens falsas para o servidor, como antes, poderíamos enviar mensagens falsas para Alice. O servidor descriptografará as mensagens para nós, mas não exibirá a descriptografia - em vez disso, como no caso de Alice, o servidor reportará apenas um pouco de informação: em texto simples, o preenchimento é válido ou não.

Observe que no cenário de Alice, tivemos os seguintes relacionamentos:

$$

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

Chamamos isso de equação de Alice. Nós controlamos o texto cifrado; o servidor (Alice) mesclou informações vagas sobre o texto simples recebido; e isso nos permitiu exibir informações sobre o último fator - a chave. Por analogia, se conseguirmos encontrar uma conexão para o script CBC, também poderemos extrair algumas informações secretas.

Felizmente, existem realmente relacionamentos que podemos usar. Considere a saída da chamada final de descriptografia da cifra de bloco e designe esses dados como$$$W$ . Também denota blocos de texto sem formatação $$P 1 , P 2 , . . . e blocos de texto cifrado$P_1, P_2,...$$$$C_1,C_2,...$ . Dê uma outra olhada na tabela da CBC e observe que ela aparece:

$$

$$C_{246} \oplus W = P_{247}$$

Chamamos isso de "equação CBC".

No cenário de Alice, monitorando o texto cifrado e observando o vazamento de informações sobre o texto simples correspondente, conseguimos organizar um ataque que restaurou o terceiro termo da equação - a chave. No cenário da CBC, também controlamos o texto cifrado e observamos o vazamento de informações no texto simples correspondente. Se uma analogia se mantiver, podemos obter informações sobre$$$W$ .

Suponha que realmente restauramos $$W , então o que? Bem, podemos imprimir imediatamente todo o último bloco de texto sem formatação ($W$$$P 247 ) simplesmente digitando$P_{247}$$$C 246 (que possuímos) erecebemos$C_{246}$
$$W na equação CBC. Portanto, estamos otimistas sobre o plano geral de ataque e é hora de descobrir os detalhes. Prestamos atenção exatamente ao modo como o servidor vaza informações em texto simples. No script de Alice, ocorreu um vazamento porque Alice respondeu a mensagem correta apenas se$W$

$$SIMPLE_SUBSTITUTION(texto cifrado,chave)$\text{SIMPLE_SUBSTITUTION}(\text{ciphertext},\text{key})$terminou com uma linha a(ou bbassim por diante, mas as chances dessas condições serem acionadas acidentalmente eram muito pequenas). Da mesma forma com o CBC, o servidor aceita preenchimento se e somente se$$C 246 ⊕ W termina em hexadecimal. Então, vamos tentar o mesmo truque: enviar textos cifrados falsos com nossos próprios valores falsos$C_{246} \oplus W$01$$C 246 até o servidor aceitar o preenchimento. Quando o servidor aceita preenchimento para uma de nossas mensagens falsas, significa que:$C_{246}$

$$

$$C_{246} \oplus W = \text{ hex 01 }$$

Agora use a propriedade XOR byte:

$$

$$(\text{ } C_{246}) \oplus (\text{ }W) = \text{hex 01}$$

Conhecemos o primeiro e o terceiro membro. E já vimos que isso permite restaurar o membro restante - o último byte de$$$W$ :

$$

$$(\text{ } W) = (\text{ } C_{246}) \oplus (\text{hex 01})$$

Também nos fornece o último byte do bloco final de texto sem formatação através da equação CBC e da propriedade byte.

Poderíamos terminar com isso e ficar satisfeitos por atacarmos uma cifra teoricamente robusta. Mas, de fato, podemos fazer muito mais: podemos realmente restaurar o texto inteiro. Isso requer um certo truque, que não estava no script original de Alice e não está incluído nos pré-requisitos para um ataque do oráculo, mas ainda vale a pena explorar o método.

Para entendê-lo, observe primeiro que, como resultado da derivação do valor correto do último byte$$W temos uma nova habilidade. Agora, ao falsificar textos cifrados, podemos controlar o último byte do texto simples correspondente. Novamente, isso se deve à equação CBC e à propriedade byte:$W$

$$

$$(\text{ } C_{246}) \oplus (\text{ } W) = \text{ } P_{247}$$

Como agora conhecemos o segundo termo, podemos usar nosso controle do primeiro para controlar o terceiro. Nós apenas calculamos:

$$

$$(\text{ } C_{246}) = (\text{ } P_{247}) \oplus (\text{ } W)$$

Não podíamos fazer isso antes, porque ainda não tínhamos o último byte $$$W$ .

Como isso nos ajudará? Suponha agora que criaremos todos os textos cifrados para que nos textos simples correspondentes o último byte seja igual 02. Agora, o servidor aceita preenchimento apenas se o texto sem formatação terminar com 02 02. Como corrigimos o último byte, isso acontecerá apenas se o penúltimo byte de texto sem formatação também for 02. Continuamos a enviar blocos de texto cifrado falsos, alterando o penúltimo byte, até que o servidor aceite o preenchimento de um deles. Neste momento temos:

$$

$$(\text{ } C_{246}) \oplus (\text{ } W) = \text{hex 02}$$

E restauramos o penúltimo byte $$W exatamente o mesmo que restaurado por último. Continuamos da mesma maneira: corrigimos os dois últimos bytes de texto sem formatação, repetimos esse ataque pelo terceiro byte a partir do final do byte e assim por diante, finalmente restaurando completamente$W$03 03$$$W$ .

E o resto do texto? Observe que o valor$$W é realmente$W$$$BLOCK_DECRYPT(tecla,C247 )$\text{BLOCK_DECRYPT}(\text{key},C_{247})$ . Podemos colocar qualquer outro bloco $$C 247 , e o ataque ainda será bem sucedido. De fato, podemos pedir ao servidor para fazer$C_{247}$$$BLOCK_DECRYPT$\text{BLOCK_DECRYPT}$para qualquer dado. Neste ponto, o jogo acabou - podemos descriptografar qualquer texto cifrado (mais uma vez, dê uma olhada no diagrama de descriptografia da CBC para ver isso; e observe que o vetor IV está disponível ao público).

Este método em particular desempenha um papel crucial no ataque do oráculo, que encontraremos mais adiante.

Attack kelsey

John Kelsey, de mente fechada, estabeleceu os princípios subjacentes a muitos ataques possíveis, e não apenas os detalhes de um ataque específico a uma cifra específica. Seu artigo de 2002 é um estudo de possíveis ataques a dados compactados criptografados. Você pensou que, para realizar um ataque, apenas as informações não eram suficientes, que os dados foram compactados antes da criptografia? Acontece o suficiente.

Este resultado surpreendente é devido a dois princípios. Em primeiro lugar, existe uma forte correlação entre o comprimento do texto simples e o comprimento do texto cifrado; para muitas cifras, igualdade exata. Em segundo lugar, quando a compactação é executada, há também uma forte correlação entre o comprimento da mensagem compactada e o grau de "ruído" do texto simples, ou seja, a proporção de caracteres não repetidos (o termo técnico é "entropia grande").

Para ver o princípio em ação, considere dois textos simples:

Texto não criptografado 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Texto não criptografado 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Suponha que ambos os textos simples sejam compactados e depois criptografados. Você obtém dois textos cifrados resultantes e precisa adivinhar qual texto cifrado corresponde a qual texto simples:

Texto cifrado 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Texto cifrado 2: DWKJZXYU

A resposta é clara. Entre os textos simples, apenas o texto simples 1 pode ser compactado com o tamanho reduzido do segundo texto cifrado. Descobrimos sem saber nada sobre o algoritmo de compactação, a chave de criptografia ou mesmo a própria cifra. Comparado à hierarquia de possíveis ataques criptográficos, esse é um tipo de loucura.

Kelsey indica ainda que, sob certas circunstâncias incomuns, esse princípio também pode ser usado para conduzir um ataque do oráculo. Em particular, ele descreve como um invasor pode recuperar texto sem formatação secreto se forçar o servidor a criptografar dados de formulário (texto sem formatação, seguido por$$X enquanto ele controla$X$$$X e de alguma forma pode verificar a duração do resultado criptografado). Novamente, como em outros ataques de oráculos, temos a proporção:$X$

$$

$$\text{}(\text{}(\text{ , } X)) = \text{}$$

Novamente, controlamos um membro ( $$X ), vemos um pequeno vazamento de informações sobre outro membro (texto cifrado) e tentamos restaurar o último (texto simples). Apesar da analogia, essa é uma situação um tanto incomum em comparação com outros ataques oraculares que vimos.Para ilustrar como esse ataque pode funcionar, usamos o esquema de compressão fictício que acabamos de criar: TOYZIP. Ele procura por linhas de texto que já apareceram anteriormente no texto e as substitui por três bytes de espaço reservado que indicam onde encontrar uma instância anterior da linha e quantas vezes ela aparece lá. Por exemplo, uma stringpode ser compactada com umcomprimento de 13 bytes em comparação com os 15 bytes originais.Suponha que um invasor tente recuperar o texto sem formatação de um formulário$X$

helloworldhellohelloworld[00][00][05]

password=...onde a senha em si é desconhecida. De acordo com o modelo de ataque de Kelsey, um invasor pode pedir ao servidor para compactar e criptografar as mensagens de formulário (texto sem formatação, seguido por$$X ) onde$X$$$X é texto livre. Quando o servidor termina, ele relata a duração do resultado. O ataque é o seguinte:$X$

Cracker: Comprima e criptografe o texto sem formatação.

Servidor: comprimento do resultado 14.

Cracker: compactar e criptografar o texto sem formatação ao qual você adicionou password=a.

Servidor: Comprimento do Resultado 18.

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

Cracker: Comprima e criptografe o texto sem formatação ao qual você adicionou password=b.

Servidor: Comprimento do resultado 18.

Cracker: Por favor, comprima e criptografe o texto sem formatação ao qual você adicionou password=.

Servidor: Duração do resultado 17.

O cracker observa: [original 14] + [três bytes que foram substituídos password=c]. Isso pressupõe que o texto sem formatação original contenha uma sequência password=c. Ou seja, a senha começa com uma letrac

Cracker: Comprima e criptografe o texto sem formatação ao qual você adicionou password=a.

Servidor: Comprimento do Resultado 18.

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

Cracker: Comprima e criptografe o texto sem formatação ao qual você adicionou password=b.

Servidor: Comprimento do Resultado 18.

(... algum tempo depois ...)

Cracker: Comprima e criptografe o texto sem formatação ao qual você adicionou password=.

Servidor: Duração do resultado 17.

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

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

O leitor é perdoado por pensar que este é um exercício puramente acadêmico e que esse cenário de ataque nunca ocorrerá no mundo real. Infelizmente, como veremos em breve, na criptografia é melhor não prometer.

Vulnerabilidades da marca: CRIME, POODLE, DROWN

Finalmente, após um estudo detalhado da teoria, podemos ver como esses métodos são usados ​​em ataques criptográficos reais.

CRIME

Se o ataque atingir o navegador e a rede da vítima, algo será mais simples e algo mais complicado. Por exemplo, é fácil ver o tráfego da vítima: basta sentar com ela no mesmo café com Wi-Fi. Por esse motivo, as vítimas em potencial (ou seja, todos) geralmente são aconselhadas a usar uma conexão criptografada. Será mais difícil, mas ainda é possível executar solicitações HTTP em nome da vítima para algum site de terceiros (por exemplo, Google). O invasor deve atrair a vítima para uma página da web maliciosa com um script que fará a solicitação. O navegador da web fornecerá automaticamente o cookie de sessão apropriado.

Isso parece incrível. Se Bob tiver feito login evil.com, o script neste site pode solicitar ao Google que envie por e-mail a senha de Bob paraattacker@evil.com? Bem, em teoria, sim, mas realmente não. Esse cenário é chamado de ataque de falsificação de solicitação entre sites (CSRF) e era popular em meados dos anos 90. Hoje, se você evil.comtentar este truque, Google (ou qualquer local que se preze) geralmente respondem: "Bem, mas o seu CSRF token para esta transação será ... um ... . Por favor, repita este número. " Os navegadores modernos usam algo chamado política de mesma origem, segundo a qual os scripts no site A não obtêm acesso às informações enviadas pelo site B. Portanto, o script evil.comnão pode enviar solicitações google.com, mas não pode ler as respostas ou realmente conclua a transação.

Devemos enfatizar que, se Bob não usar uma conexão criptografada, todas essas proteções não terão sentido. Um invasor pode simplesmente ler o tráfego de Bob e restaurar o cookie de sessão do Google. Com esse cookie, ele simplesmente abrirá uma nova guia do Google sem sair de seu próprio navegador e personificará o Bob sem encontrar políticas irritantes da mesma origem. Mas, infelizmente para o cracker, isso está se tornando menos comum. A Internet como um todo há muito declara 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 prática comum reduzir a latência.

É aqui que o CRIME entra em cena .(Taxa de compressão Infoleak Made Easy, vazamento simples através da taxa de compressão). A vulnerabilidade revelada em setembro de 2012 pelos pesquisadores de segurança Juliano Rizzo e Thai Duong. Já examinamos toda a base teórica, o que nos permite entender o que eles fizeram e como. Um invasor pode forçar o navegador de Bob a enviar solicitações ao Google e, em seguida, ouvir respostas na rede local de forma compactada e criptografada. Portanto, temos:

$$

$$\text{-} = \text{}(\text{}(\text{ }))$$

Aqui, o cracker controla a solicitação e tem acesso ao sniffer de tráfego, incluindo o tamanho do pacote. O cenário fictício de Kelsey se tornou realidade.

Entendendo a teoria, os autores do CRIME criaram uma exploração que pode roubar cookies de sessão para uma ampla variedade de sites, incluindo Gmail, Twitter, Dropbox e Github. A vulnerabilidade afetou a maioria dos navegadores da web modernos, como resultado dos patches lançados que enterraram silenciosamente a função de compactação no SSL, para que não fosse mais usada. O único protegido contra a vulnerabilidade foi o venerável Internet Explorer, que nunca usou compactação SSL.

POODLE

Em outubro de 2014, a equipe de segurança do Google agitou a comunidade de segurança. Eles foram capazes de explorar a vulnerabilidade no protocolo SSL, corrigido há mais de dez anos.

Acontece que, embora os servidores executem o maravilhoso TLSv1.2, muitos deixaram o suporte ao SSLv3 obsoleto para compatibilidade com versões anteriores do Internet Explorer 6. Já falamos sobre ataques de downgrade, para que você possa imaginar o que está acontecendo. Sabotagem bem organizada do protocolo de handshake - e os servidores estão prontos para retornar ao bom e velho SSLv3, cancelando essencialmente os últimos 15 anos de pesquisa de segurança.

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

Transport Layer Security (TLS) — . [..] , , TLS. [..] TLS TLS. Netscape Communications "Secure Sockets Layer" SSL. , SSL , -. , SSL SSL 2 . , [..] 90-, « ». , , . SSLv2 , — , SSLv2 .

Após esses eventos, em 1996, a frustrada empresa Netscape redesenhou o SSL do zero. O resultado foi o SSL versão 3, que corrigiu vários problemas de segurança conhecidos de seu predecessor .

Felizmente para os crackers, "poucos" não significa "tudo". Em geral, o SSLv3 forneceu todos os componentes necessários para iniciar o ataque Woden. O protocolo usava uma cifra de bloco no modo CBC e um esquema de preenchimento inseguro (isso foi corrigido no TLS; portanto, ocorreu um ataque de downgrade). Se você se lembra do padrão de preenchimento em nossa descrição original do ataque Woden, o padrão SSLv3 é muito semelhante.

Mas, infelizmente para os crackers, "similar" não significa "idêntico". O esquema de preenchimento SSLv3 é "N bytes arbitrários seguidos pelo número N". Nessas condições, tente escolher um bloco imaginário de texto cifrado e percorra todos os estágios do esquema Wodene original: você descobrirá que o ataque extrai com êxito o último byte do bloco correspondente de texto sem formatação, mas não vai além. Decifrar todos os 16 bytes de texto cifrado é um grande truque, mas não é uma vitória.

Diante do fracasso, a equipe do Google recorreu à opção extrema: eles mudaram para um modelo de ameaça mais poderoso - o usado no CRIME. Supondo que o invasor seja um script iniciado na guia do navegador da vítima e possa extrair cookies de sessão, o ataque permanece impressionante de qualquer maneira. Embora o modelo mais amplo de ameaças seja menos realista, já vimos na seção anterior que esse modelo específico é viável.

Dadas essas capacidades mais poderosas do cracker, o ataque agora pode continuar. Observe que o invasor sabe onde o cookie de sessão criptografado é exibido no cabeçalho e controla o tamanho da solicitação HTTP que o precede. Portanto, ele pode manipular a solicitação HTTP para alinhar o último byte do cookie de acordo com o final do bloco. Agora, este byte é adequado para descriptografia. Você pode simplesmente adicionar um caractere à solicitação e o penúltimo byte de cookies permanecerá no mesmo local e adequado para seleção pelo mesmo método. O ataque continua dessa maneira até que o cookie seja completamente restaurado. Isso se chama POODLE: preenchendo o Oracle na criptografia herdada rebaixada, preenchendo o oracle com criptografia obsoleta reduzida.

Afogar

Como já mencionamos, o SSLv3 apresentava falhas, mas era fundamentalmente diferente de seu antecessor, pois o SSLv2 com vazamento era um produto de uma época diferente. Lá foi possível interromper a mensagem no meio: transformada em ; o cliente e o servidor podiam se encontrar na Internet, estabelecer confiança e trocar segredos diante dos olhos do atacante, que então fingia ser os dois com facilidade. Há também um problema com a criptografia de exportação, que mencionamos ao considerar o FREAK. Estes foram Sodoma criptográfico e Gomorra.

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 é usado em sistemas de segurança. Sim, os invasores não puderam mais fazer o downgrade das sessões TLS modernas para SSLv2, pois esse buraco foi fechado após FREAK e POODLE, mas eles ainda podem se conectar aos servidores e iniciar sessões SSLv2 por conta própria.

Você pergunta, o que nos importa o que eles fazem lá? Eles têm uma sessão vulnerável, mas isso não deve afetar outras sessões ou a segurança do servidor - certo? Bem, na verdade não. Sim, é assim que deve ser em teoria. Mas não - porque a geração de certificados SSL impõe uma certa carga, como resultado de muitos servidores usarem os mesmos certificados e, como resultado, as mesmas chaves RSA para conexões TLS e SSLv2. Pior, devido ao bug do OpenSSL nesta popular implementação de SSL, a opção "Desativar SSLv2" não funcionou.

Isso possibilitou um ataque de protocolo cruzado ao TLS chamado DROWN(Descriptografando o RSA com criptografia eletrônica obsoleta e enfraquecida, descriptografando o RSA usando criptografia desatualizada e fraca). Lembre-se de que isso não é o mesmo que um ataque de queda; um invasor não precisa agir como uma “pessoa do meio” e não precisa envolver um cliente para participar de uma sessão não segura. Os invasores simplesmente iniciam uma sessão SSLv2 insegura com o próprio servidor, atacam um protocolo fraco e restauram a chave do servidor privado RSA. Essa chave também é válida para conexões TLS e, a partir de agora, nenhuma segurança TLS a salvará de hackers.

Mas o hacking requer um ataque funcional contra o SSLv2, que permite restaurar não apenas o tráfego específico, mas também a chave do servidor secreto RSA. Embora essa seja uma produção complicada, os pesquisadores podem escolher qualquer vulnerabilidade que foi completamente fechada após o SSLv2. No final, eles encontraram uma opção adequada: o ataque de Bleichenbacher, que mencionamos anteriormente e que será explicado em detalhes no próximo artigo. O SSL e o TLS estão protegidos contra esse ataque, mas algumas funções aleatórias do SSL, combinadas com teclas de atalho na criptografia de exportação, possibilitaram uma implementação específica do DROWN .

No momento da publicação da vulnerabilidade DROWN, 25% dos principais sites da Internet eram afetados, e o ataque podia ser realizado com recursos modestos disponíveis, mesmo para hackers maliciosos. Foram necessárias oito horas de computação e US $ 440 para recuperar a chave do servidor RSA, e o SSLv2 mudou seu status de "obsoleto" para "radioativo".

Espere, e o Heartbleed?

Este não é um ataque criptográfico no sentido descrito acima; isso é um estouro de buffer.

Faça uma pausa

Começamos com alguns métodos básicos: força bruta, interpolação, downgrade, protocolo cruzado e pré-cálculo. Depois, examinaram uma técnica avançada, talvez o principal componente dos ataques criptográficos modernos: este é o ataque do oráculo. Lidamos com isso por algum tempo - e entendemos não apenas o princípio central, mas também os detalhes técnicos de duas implementações específicas: ataques de Wodene no modo de criptografia CBC e ataques de Kelsey em protocolos de criptografia com compressão preliminar.

Ao revisar ataques de downgrade e com cálculos preliminares, descrevemos brevemente o ataque FREAK, que usa os dois métodos, já que os sites de destino caem para chaves fracas e reutilizam as mesmas chaves. No próximo artigo, deixamos um ataque (muito semelhante) ao Logjam, direcionado a algoritmos de chave pública.

Em seguida, examinamos mais três exemplos da aplicação desses princípios. Em primeiro lugar, o crime e POODLE: dois ataques, que contou com a habilidade de um atacante para introduzir texto simples arbitrária ao lado do alvo em texto claro, e então aprender as respostas para o servidor e , em seguida , utilizando a metodologia da Oracle ataque, usar essa informação escassa para a recuperação parcial do texto simples. O CRIME seguiu o caminho do ataque de Kelsey à compactação SSL, enquanto o POODLE usou o ataque de Woden na CBC com o mesmo efeito.

Em seguida, voltamos nossa atenção para o ataque DROWN de protocolo cruzado, que estabelece uma conexão com o servidor usando o protocolo SSLv2 desatualizado e, em seguida, restaura as chaves secretas do servidor usando o ataque Bleichenbacher. Neste ponto, perdemos os detalhes técnicos deste ataque; como Logjam, ela terá que esperar até que estudemos minuciosamente os sistemas de criptografia de chave pública e suas vulnerabilidades.

No próximo artigo, falaremos sobre ataques avançados - como o método meet-in-the-middle, criptoanálise diferencial e o ataque de "aniversário". Faremos uma pequena incursão em ataques por meio de canais de terceiros e, em seguida, enfrentaremos a coisa mais deliciosa - sistemas de criptografia com uma chave pública.