Quando você ouve a palavra “criptografia”, algumas pessoas se lembram da senha do WiFi, do cadeado verde ao lado do endereço de seu site favorito e de como é difícil acessar o e-mail de outra pessoa. Outros lembram uma série de vulnerabilidades nos últimos anos com abreviações reveladoras (DROWN, FREAK, POODLE...), logotipos elegantes e um aviso para atualizar seu navegador com urgência.

A criptografia cobre tudo, mas a essência noutro. A questão é que existe uma linha tênue entre o simples e o complexo. Algumas coisas são fáceis de fazer, mas difíceis de recompor, como quebrar um ovo. Outras coisas são fáceis de fazer, mas difíceis de recuperar quando falta uma parte pequena, importante e crucial: por exemplo, abrir uma porta trancada quando a “parte crucial” é a chave. A criptografia estuda essas situações e como elas podem ser utilizadas na prática.

Nos últimos anos, a coleção de ataques criptográficos transformou-se num zoológico de logotipos chamativos, repletos de fórmulas de artigos científicos, e deu origem a uma sensação geral sombria de que tudo está quebrado. Mas, na verdade, muitos dos ataques baseiam-se em alguns princípios gerais, e páginas intermináveis ​​de fórmulas são muitas vezes resumidas em ideias fáceis de entender.

Nesta série de artigos veremos os diferentes tipos de ataques criptográficos, com ênfase nos princípios básicos. Em termos gerais e não exatamente nesta ordem, mas abordaremos o seguinte:

• Estratégias básicas: força bruta, análise de frequência, interpolação, downgrade e protocolos cruzados.
• Vulnerabilidades de marca: FREAK, CRIME, POODLE, AFOGAMENTO, Impasse.
• Estratégias Avançadas: ataques de oráculo (ataque Vodenet, ataque Kelsey); método meet-in-the-middle, ataque de aniversário, viés estatístico (criptoanálise diferencial, criptoanálise integral, etc.).
• Ataques de canal lateral e seus parentes próximos, métodos de análise de falhas.
• Ataques à criptografia de chave pública: raiz cúbica, transmissão, mensagem relacionada, ataque Coppersmith, algoritmo Pohlig-Hellman, peneira numérica, ataque Wiener, ataque Bleichenbacher.

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

Estratégias Básicas

Os ataques a seguir são simples no sentido de que podem ser explicados quase completamente sem muitos detalhes técnicos. Vamos explicar cada tipo de ataque nos termos mais simples, sem entrar em exemplos complexos ou casos de uso avançados.

Alguns desses ataques tornaram-se obsoletos e não são usados ​​há muitos anos. Outros são veteranos que ainda se aproximam regularmente de desenvolvedores desavisados ​​de sistemas criptográficos no século XXI. Pode-se considerar que a era da criptografia moderna começou com o advento do IBM DES, a primeira cifra que resistiu a todos os ataques desta lista.

Força bruta simples

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

Vamos supor que vemos o texto cifrado e tentamos descriptografá-lo sem nenhuma informação adicional (isso é chamado de ataque somente de texto cifrado). Se, de alguma forma, encontrarmos magicamente a chave correta, poderemos facilmente verificar se ela está realmente correta se o resultado for uma mensagem razoável.

Observe que existem duas suposições implícitas aqui. Primeiramente, sabemos como realizar a descriptografia, ou seja, como funciona o criptossistema. Esta é uma suposição padrão quando se discute criptografia. Ocultar os detalhes de implementação da cifra dos invasores pode parecer uma medida de segurança adicional, mas uma vez que o invasor descubra esses detalhes, essa segurança adicional será perdida de forma silenciosa e irreversível. É assim que Princípio de Kerchhoff: O sistema caindo nas mãos do inimigo não deve causar transtornos.

Em segundo lugar, assumimos que a chave correta é a única que levará a uma descriptografia razoável. Esta também é uma suposição razoável; fica satisfeito se o texto cifrado for muito mais longo que a chave e for legível. Isso geralmente é o que acontece no mundo real, exceto enormes chaves impraticáveis ou outras travessuras que é melhor deixar de lado (se você não gosta que pulamos a explicação, consulte o Teorema 3.8 aqui).

Diante do exposto, surge uma estratégia: verificar todas as chaves possíveis. Isso é chamado de força bruta, e tal ataque certamente funcionará contra todas as cifras práticas – eventualmente. Por exemplo, a força bruta é suficiente para hackear Cifra de César, uma cifra antiga onde a chave é uma letra do alfabeto, implicando pouco mais de 20 chaves possíveis.

Infelizmente para os criptoanalistas, aumentar o tamanho da chave é uma boa defesa contra a força bruta. À medida que o tamanho da chave aumenta, o número de chaves possíveis aumenta exponencialmente. Com tamanhos de teclas modernos, a força bruta simples é completamente impraticável. Para entender o que queremos dizer, vamos pegar o supercomputador mais rápido conhecido em meados de 2019: Summit da IBM, com desempenho máximo de cerca de 1017 operações por segundo. Hoje, o comprimento típico da chave é de 128 bits, o que significa 2128 combinações possíveis. Para pesquisar todas as chaves, o supercomputador Summit precisará de um tempo aproximadamente 7800 vezes a idade do Universo.

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

Análise de frequência

A maioria dos textos não é algo sem sentido. Por exemplo, em textos em inglês existem muitas letras 'e' e artigos 'the'; em arquivos binários, existem muitos zero bytes como preenchimento entre informações. A análise de frequência é qualquer ataque que tire vantagem desse fato.

O exemplo canônico de uma cifra vulnerável a este ataque é a cifra de substituição simples. Nesta cifra, a chave é uma tabela com todas as letras substituídas. Por exemplo, 'g' é substituído por 'h', 'o' por j, então a palavra 'go' torna-se 'hj'. Essa cifra é difícil de aplicar à força bruta porque existem muitas tabelas de pesquisa possíveis. Se você estiver interessado em matemática, o comprimento efetivo da chave é de cerca de 88 bits: isso é
. Mas a análise de frequência geralmente realiza o trabalho rapidamente.

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

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

Desde Y ocorre com frequência, inclusive no final de muitas palavras, podemos assumir provisoriamente que esta é a letra e:

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

Casal XD repetido no início de várias palavras. Em particular, a combinação XDeLe sugere claramente a palavra these ou there, então vamos continuar:

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

Suponhamos ainda que L соответствует r, A - a e assim por diante. Provavelmente serão necessárias algumas tentativas, mas comparado a um ataque total de força bruta, este ataque restaura o texto original rapidamente:

há mais coisas no céu e na terra horatio do que sonha sua filosofia

Para alguns, resolver esses “criptogramas” é um hobby emocionante.

A ideia 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 conter tal ataque usando "substituição polialfabética". Aqui, durante o processo de criptografia, a tabela de substituição de letras é modificada de maneiras complexas, mas previsíveis, que dependem da chave. Todas essas cifras foram consideradas difíceis de quebrar de uma só vez; e ainda assim a modesta análise de frequência acabou derrotando todos eles.

A cifra polialfabética mais ambiciosa da história, e talvez a mais famosa, foi a cifra Enigma da Segunda Guerra Mundial. Era relativamente complexo em comparação com seus antecessores, mas depois de muito trabalho duro, os criptoanalistas britânicos o decifraram usando análise de frequência. É claro que eles não conseguiriam desenvolver um ataque elegante como o mostrado acima; eles tiveram que comparar pares conhecidos de texto simples e texto cifrado (o chamado "ataque de texto simples"), e até mesmo provocaram os usuários do Enigma a criptografar certas mensagens e analisar o resultado (o "ataque de texto simples escolhido"). Mas isso não facilitou em nada o destino dos exércitos inimigos derrotados e dos submarinos afundados.

Após este triunfo, a análise de frequência desapareceu da história da criptoanálise. As cifras na era digital moderna são projetadas para funcionar com bits, não com letras. Mais importante ainda, essas cifras foram projetadas com o entendimento obscuro do que mais tarde ficou conhecido como Lei de Schneier: Qualquer um pode criar um algoritmo de criptografia que ele próprio não possa quebrar. Não é suficiente para o sistema de criptografia parecia difícil: para provar o seu valor, deve passar por uma revisão de segurança implacável por muitos criptoanalistas que farão o seu melhor para quebrar a cifra.

Cálculos preliminares

Tomemos como exemplo a cidade hipotética de Precom Heights, com população de 200 habitantes. Cada casa na cidade contém em média US$ 000 em objetos de valor, mas não mais do que US$ 30. O mercado de segurança na Precom é monopolizado pela ACME Industries, que produz as lendárias fechaduras da classe Coyote™. De acordo com análises de especialistas, uma fechadura da classe Coyote só pode ser quebrada por uma máquina hipotética muito complexa, cuja criação requer cerca de cinco anos e um investimento de US$ 000 mil. A cidade é segura?

Provavelmente não. Eventualmente, um criminoso bastante ambicioso aparecerá. Ele raciocinará assim: “Sim, incorrerei em grandes custos iniciais. Cinco anos de espera de pacientes e US$ 50 mil. Mas quando terminar, terei acesso a toda a riqueza desta cidade. Se eu jogar bem as cartas, esse investimento se pagará muitas vezes.”

O mesmo se aplica à criptografia. Os ataques contra uma cifra específica estão sujeitos a uma análise implacável de custo-benefício. Se a relação for favorável, o ataque não ocorrerá. Mas os ataques que funcionam contra muitas vítimas potenciais ao mesmo tempo quase sempre compensam e, nesse caso, a melhor prática de design é presumir que começaram desde o primeiro dia. O que temos é essencialmente uma versão criptográfica da Lei de Murphy: “Qualquer coisa que possa realmente quebrar o sistema irá quebrar o sistema”.

O exemplo mais simples de um sistema criptográfico vulnerável a um ataque de pré-computação é uma cifra sem chave constante. Este foi o caso com Cifra de César, que simplesmente desloca cada letra do alfabeto três letras para frente (a tabela está em loop, então a última letra do alfabeto é criptografada em terceiro lugar). Aqui novamente o princípio de Kerchhoff entra em jogo: uma vez que um sistema é hackeado, ele é hackeado para sempre.

O conceito é simples. Mesmo um desenvolvedor novato de criptosistemas provavelmente reconhecerá a ameaça e se preparará adequadamente. Observando a evolução da criptografia, tais ataques foram inadequados para a maioria das cifras, desde as primeiras versões melhoradas da cifra de César até o declínio das cifras polialfabéticas. Tais ataques só retornaram com o advento da era moderna da criptografia.

Esse retorno se deve a dois fatores. Em primeiro lugar, finalmente surgiram criptossistemas suficientemente complexos, onde a possibilidade de exploração após hacking não era óbvia. Em segundo lugar, a criptografia tornou-se tão difundida que milhões de leigos tomavam decisões todos os dias sobre onde e que partes da criptografia reutilizar. Demorou algum tempo até que os especialistas percebessem os riscos e dessem o alarme.

Lembre-se do ataque pré-computação: no final do artigo veremos dois exemplos criptográficos da vida real onde ele desempenhou um papel importante.

Interpolação

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

Imediatamente adivinhei que você tinha vindo do Afeganistão... Minha linha de pensamento foi a seguinte: “Este homem é médico por natureza, mas tem porte militar. Então, um médico militar. Ele acabou de chegar dos trópicos - seu rosto é moreno, mas esse não é o tom natural de sua pele, pois seus pulsos são bem mais brancos. O rosto está abatido - obviamente ele sofreu muito e sofreu com doenças. Ele foi ferido na mão esquerda - ele a mantém imóvel e um pouco anormal. Onde, nos trópicos, um médico militar inglês poderia suportar dificuldades e ser ferido? Claro, no Afeganistão." Toda a linha de pensamento não durou nem um segundo. E então eu disse que você veio do Afeganistão e ficou surpreso.

Holmes conseguiu extrair muito pouca informação de cada evidência individualmente. Ele só poderia chegar à sua conclusão considerando todos eles juntos. Um ataque de interpolação funciona de forma semelhante, examinando pares conhecidos de texto simples e texto cifrado resultantes da mesma chave. De cada par são extraídas observações individuais que permitem tirar uma conclusão geral sobre a chave. Todas estas conclusões são vagas e parecem inúteis até que de repente atingem uma massa crítica e levam à única conclusão possível: por mais incrível que seja, deve ser verdade. Depois disso, a chave é revelada ou o processo de descriptografia torna-se tão refinado que pode ser replicado.

Vamos ilustrar com um exemplo simples como funciona a interpolação. Digamos que queremos ler o diário pessoal do nosso inimigo, Bob. Ele criptografa todos os números de seu diário usando um sistema criptográfico simples que aprendeu em um anúncio na revista "A Mock of Cryptography". O sistema funciona assim: Bob escolhe dois números de sua preferência: и . A partir de agora, para criptografar qualquer número , ele calcula . Por exemplo, se Bob escolheu и , então o número será criptografado como .

Digamos que no dia 28 de dezembro percebemos que Bob estava rabiscando algo em seu diário. Quando ele terminar, iremos pegá-lo silenciosamente e assistir a última entrada:

Дата: 235/520

Querido Diário,

Hoje foi um bom dia. Através 64 hoje tenho um encontro com a Alisa, que mora em um apartamento 843. Eu realmente acho que ela pode estar 26!

Como levamos muito a sério a ideia de seguir Bob em seu encontro (temos ambos 15 anos neste cenário), é fundamental saber a data, bem como o endereço de Alice. Felizmente, notamos que o sistema criptográfico de Bob é vulnerável a um ataque de interpolação. Podemos não saber и , mas sabemos a data de hoje, então temos dois pares de texto simples-texto cifrado. Ou seja, sabemos que criptografado em E - em . Isto é o que vamos escrever:

Desde os 15 anos já conhecemos um sistema de duas equações com duas incógnitas, o que nesta situação é suficiente para encontrar и sem quaisquer problemas. Cada par texto simples-texto cifrado impõe uma restrição à chave de Bob, e as duas restrições juntas são suficientes para recuperar completamente a chave. No nosso exemplo a resposta é и (em de modo que 26 no diário corresponde à palavra 'aquele', ou seja, “o mesmo” - aprox. faixa).

Os ataques de interpolação não estão, obviamente, limitados a exemplos tão simples. Todo criptosistema que se reduz a um objeto matemático bem compreendido 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 recém-chegados costumam reclamar que a criptografia é “a arte de projetar as coisas da maneira mais feia possível”. Os ataques de interpolação são provavelmente os principais culpados. Bob pode usar um design matemático elegante ou manter privado seu encontro com Alice - mas, infelizmente, geralmente não é possível ter as duas coisas. Isso ficará bastante claro quando chegarmos ao tópico da criptografia de chave pública.

Protocolo cruzado/downgrade

Em Now You See Me (2013), um grupo de ilusionistas tenta roubar toda a sua fortuna do corrupto magnata dos seguros Arthur Tressler. Para ter acesso à conta bancária de Arthur, os ilusionistas devem fornecer seu nome de usuário e senha ou forçá-lo a comparecer pessoalmente ao 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. Então eles escolhem a terceira opção possível: o cúmplice liga para o banco e finge ser Arthur. O banco faz diversas perguntas para verificar a identidade, como o nome do tio e o nome do primeiro animal de estimação; nossos heróis antecipadamente eles extraem facilmente essas informações de Arthur usando engenharia social inteligente. Deste ponto em diante, uma excelente segurança de senha não importa mais.

(De acordo com uma lenda urbana que verificamos e verificamos pessoalmente, o criptógrafo Eli Beaham encontrou certa vez um caixa de banco que insistiu em fazer uma pergunta de segurança. Quando o caixa perguntou o nome de sua avó materna, Beaham começou a ditar: “X maiúsculo, pequeno y, três... ").

O mesmo acontece na criptografia, se dois protocolos criptográficos forem usados ​​em paralelo para proteger o mesmo ativo, e um for muito mais fraco que o outro. O sistema resultante torna-se vulnerável a um ataque entre protocolos, onde um protocolo mais fraco é atacado para chegar ao prêmio sem tocar no mais forte.

Em alguns casos complexos, não basta simplesmente contactar o servidor utilizando um protocolo mais fraco, mas requer a participação involuntária de um cliente legítimo. Isso pode ser organizado usando o chamado ataque de downgrade. Para entender esse ataque, vamos supor que nossos ilusionistas tenham uma tarefa mais difícil do que no filme. Vamos supor que um bancário (caixa) e Arthur se depararam com algum imprevisto, resultando no seguinte diálogo:

Assaltante: Olá? Este é Arthur Tressler. Gostaria de redefinir minha senha.

Caixa: Ótimo. Por favor, dê uma olhada em seu livro pessoal de códigos secretos, página 28, palavra 3. Todas as mensagens a seguir serão criptografadas usando esta palavra específica como chave. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…

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

Caixa: Eu não recomendo fazer isso.

Assaltante: Eu só... olha, tive um péssimo dia, ok? Sou um cliente VIP e não estou com vontade de vasculhar esses estúpidos livros de códigos.

Caixa: Multar. Se insiste, Sr. Tressler. O que você quer?

Assaltante: Por favor, gostaria de doar todo o meu dinheiro ao Fundo Nacional Arthur Tressler para Vítimas.

(Pausa).

Caixa: Está claro agora. Forneça seu PIN para transações grandes.

Assaltante: Meu o quê?

Caixa: A seu pedido pessoal, transações desse porte exigem um PIN para transações grandes. Este código foi fornecido a você quando você abriu sua conta.

Assaltante:... Eu perdi isso. Isso é realmente necessário? Você não pode simplesmente aprovar o acordo?

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

Nossos heróis adiam a operação. Eles escutam várias grandes transações de Tressler, na esperança de ouvir o PIN; mas toda vez que a conversa se transforma em um jargão codificado antes que algo interessante seja dito. Finalmente, num belo dia, o plano é colocado em ação. Eles esperam pacientemente pelo momento em que Tressler precisa fazer uma grande transação por telefone, ele atende e então...

Tresler: Olá. Gostaria de concluir uma transação remota, por favor.

Caixa: Ótimo. Por favor, dê uma olhada em seu livro de códigos secretos pessoal, página...

(O ladrão aperta o botão; a voz do caixa se transforma em um ruído ininteligível).

Caixa: - #@$#@$#*@$$@#* será criptografado com esta palavra como chave. AAAYRR PLRQRZ MMNJK LOJBAN…

Tresler: Desculpe, não entendi muito bem. De novo? Em que página? Qual palavra?

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

Tresler: O quê?

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

Tresler: Seriamente! Já basta! Você e seu protocolo de segurança são uma espécie de circo. Eu sei que você pode falar comigo normalmente.

Caixa: Eu não recomendo…

Tresler: E eu não aconselho você a perder meu tempo. Não quero ouvir mais nada sobre isso até que você resolva os problemas da sua linha telefônica. Podemos finalizar este acordo ou não?

Caixa:… Sim. Multar. O que você quer?

Tresler: Gostaria de transferir $20 para Lord Business Investments, número de conta...

Caixa: Um minuto por favor. É um grande negócio. Forneça seu PIN para transações grandes.

Tresler: O que? Ah, exatamente. 1234.

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

Você pode se perguntar quem em sã consciência projetaria um sistema real "seguro até que solicitado o contrário" como o descrito acima. Mas tal como um banco fictício assume riscos para reter clientes que não gostam de criptografia, os sistemas em geral gravitam frequentemente em torno de requisitos que são indiferentes ou mesmo totalmente hostis à segurança.

Foi exatamente isso que aconteceu com o protocolo SSLv2 em 1995. O governo dos EUA há muito começou a ver a criptografia como uma arma que é melhor manter longe de inimigos estrangeiros e internos. Pedaços de código foram aprovados individualmente para exportação dos Estados Unidos, muitas vezes com a condição de que o algoritmo fosse deliberadamente enfraquecido. A Netscape, desenvolvedora do navegador mais popular, o Netscape Navigator, recebeu permissão para SSLv2 apenas com a chave RSA de 512 bits inerentemente vulnerável (e 40 bits para RC4).

No final do milénio, as regras foram flexibilizadas e o acesso à encriptação moderna tornou-se amplamente disponível. No entanto, clientes e servidores têm suportado criptografia de "exportação" enfraquecida durante anos devido à mesma inércia que mantém o suporte para qualquer sistema legado. Os clientes acreditavam que poderiam encontrar um servidor que não suportasse mais nada. Os servidores fizeram o mesmo. É claro que o protocolo SSL determina que clientes e servidores nunca devem usar um protocolo fraco quando um melhor estiver disponível. Mas a mesma premissa se aplica a Tressler e ao seu banco.

Essa teoria foi encontrada em dois ataques de alto perfil que abalaram a segurança do protocolo SSL em 2015, ambos descobertos por pesquisadores da Microsoft e INRIA. Primeiro, os detalhes do ataque FREAK foram revelados em fevereiro, seguido três meses depois por outro ataque semelhante chamado Logjam, que discutiremos com mais detalhes quando passarmos aos ataques à criptografia de chave pública.

Vulnerabilidade FREAK (também conhecido como "Smack TLS") veio à tona quando pesquisadores analisaram implementações de cliente/servidor TLS e descobriram um bug curioso. Nessas implementações, se o cliente nem mesmo solicitar o uso de criptografia de exportação fraca, mas o servidor ainda responder com tais chaves, o cliente diz “Tudo bem” e muda para um conjunto de cifras fraco.

Na época, a criptografia de exportação era amplamente considerada desatualizada e fora dos limites, por isso o ataque foi um choque completo e afetou muitos domínios importantes, incluindo os sites da Casa Branca, do IRS e da NSA. Pior ainda, muitos servidores vulneráveis ​​estavam otimizando o desempenho reutilizando as mesmas chaves em vez de gerar novas para cada sessão. Isto tornou possível, após o downgrade do protocolo, realizar um ataque pré-computação: quebrar 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 foi significativamente reduzido. Basta selecionar a chave do servidor uma vez e quebrar a criptografia de todas as conexões subsequentes a partir desse momento.

E antes de prosseguirmos, há um ataque avançado que precisa ser mencionado...

Ataque oráculo

Moxie Marlinspike mais conhecido como o pai do aplicativo de mensagens criptográficas multiplataforma Signal; mas pessoalmente gostamos de uma de suas inovações menos conhecidas - princípio da destruição criptográfica (Princípio da desgraça criptográfica). Parafraseando um pouco, podemos dizer o seguinte: “Se o protocolo funcionar qualquer executa uma operação criptográfica em uma mensagem de uma fonte potencialmente maliciosa e se comporta de maneira diferente dependendo do resultado, está condenado." Ou de forma mais nítida: “Não receba informações do inimigo para processamento e, se for preciso, pelo menos não mostre o resultado”.

Vamos deixar de lado buffer overflows, injeções de comando e coisas do gênero; eles estão além do escopo desta discussão. A violação do “princípio da destruição” leva a sérios hacks de criptografia devido ao fato de o protocolo se comportar exatamente como esperado.

Como exemplo, tomemos um projeto fictício com uma cifra de substituição vulnerável e depois demonstremos um possível ataque. Embora já tenhamos visto um ataque a uma cifra de substituição usando análise de frequência, não é apenas “outra maneira de quebrar a mesma cifra”. Pelo contrário, os ataques oracle 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 a cifra simples é escolhida apenas para tornar o exemplo mais claro.

Assim, 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 comprimento das mensagens: elas têm exatamente 20 caracteres. Então eles concordaram que se alguém quisesse enviar uma mensagem mais curta, deveria adicionar um texto fictício no final da mensagem para ter exatamente 20 caracteres. Após alguma discussão, eles decidiram que aceitariam apenas os seguintes textos fictícios: a, bb, ccc, dddd etc. Assim, um texto fictício de qualquer comprimento necessário é conhecido.

Quando Alice ou Bob recebem 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 esse o caso, eles respondem com uma mensagem de erro apropriada. Se o comprimento do texto e o texto fictício estiverem corretos, o destinatário lê a mensagem e envia uma resposta criptografada.

Durante o ataque, o invasor se faz passar por Bob e envia mensagens falsas para Alice. As mensagens são completamente absurdas - o invasor não possui a chave e, portanto, não pode forjar uma mensagem significativa. Mas como o protocolo viola o princípio da destruição, um invasor ainda pode fazer com que Alice revele as informações principais, conforme mostrado abaixo.

Assaltante: PREWF ZHJKL MMMN. LA

Alice: Texto fictício inválido.

Assaltante: PREWF ZHJKL MMMN. LB

Alice: Texto fictício inválido.

Assaltante: PREWF ZHJKL MMMN. LC

Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

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

Assaltante: REWF ZHJKL MMMN. LAA

Alice: Texto fictício inválido.

Assaltante: REWF ZHJKL MMMN. LBB

Alice: Texto fictício inválido.

Depois de várias tentativas...

Assaltante: REWF ZHJKL MMMN. LGG

Alice: Texto fictício inválido.

Assaltante: 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 observa que H deve corresponder a b, pois Alice aceitou o texto fictício.

E assim sucessivamente até que o atacante saiba o significado de cada caractere.

À primeira vista, o método se assemelha a um ataque de texto simples escolhido. No final, o invasor seleciona os 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 de acesso à transcrição real – uma resposta do servidor, mesmo que seja tão inócua como “Texto fictício inválido”, é suficiente.

Embora este ataque em particular seja instrutivo, não se preocupe muito com as especificidades do esquema de “texto fictício”, o sistema criptográfico específico usado ou a sequência exata de mensagens enviadas pelo invasor. A ideia básica é como Alice reage de maneira diferente com base nas propriedades do texto simples, e o faz sem verificar se o texto cifrado correspondente realmente veio de uma parte confiável. Assim, Alice permite que o invasor extraia informações secretas de suas respostas.

Há muita coisa que pode ser mudada nesse cenário. Os símbolos aos quais Alice reage, ou a própria diferença em seu comportamento, ou mesmo o criptossistema utilizado. 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 deste ataque ajudou a descobrir vários bugs de segurança, que veremos em breve; mas primeiro há algumas lições teóricas a serem aprendidas. Como usar esse "script Alice" fictício em um ataque que pode funcionar em uma cifra moderna real? Isso é possível, mesmo em teoria?

Em 1998, o criptógrafo suíço Daniel Bleichenbacher respondeu afirmativamente a esta pergunta. Ele demonstrou um ataque oracle ao amplamente utilizado sistema criptográfico de chave pública RSA, usando um esquema de mensagem específico. Em algumas implementações RSA, o servidor responde com diferentes mensagens de erro dependendo se o texto simples 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 no cenário 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 usam. Em particular, o ataque de Vaudenay tem como alvo cifras de tamanho de entrada fixo ("cifras de bloco") quando são usadas no chamado "modo de criptografia CBC" e com um certo esquema de preenchimento popular, basicamente equivalente ao do cenário Alice.

Também em 2002, o criptógrafo americano John Kelsey - coautor Dois peixes – propôs vários ataques oracle a sistemas que compactam mensagens e depois as criptografam. O mais notável deles foi um ataque que se aproveitou do fato de que muitas vezes é possível inferir o comprimento original do texto simples a partir do comprimento do texto cifrado. Em teoria, isso permite um ataque oracle que recupera partes do texto simples original.

Abaixo fornecemos uma descrição mais detalhada dos ataques Vaudenay e Kelsey (daremos uma descrição mais detalhada do ataque Bleichenbacher quando passarmos aos ataques à criptografia de chave pública). Apesar dos nossos melhores esforços, o texto torna-se um tanto técnico; portanto, se o que foi dito acima for suficiente para você, pule as próximas duas seções.

O ataque de Vodene

Para entender o ataque de Vaudenay, primeiro precisamos falar um pouco mais sobre cifras de bloco e modos de criptografia. Uma "cifra de bloco" é, como mencionado, uma cifra que recebe uma chave e uma entrada de um determinado comprimento fixo ("comprimento de bloco") e produz um bloco criptografado do mesmo comprimento. As cifras de bloco são amplamente utilizadas e consideradas relativamente seguras. O agora aposentado DES, considerado a primeira cifra moderna, era uma cifra de bloco. Conforme mencionado acima, o mesmo se aplica ao AES, que é amplamente utilizado atualmente.

Infelizmente, as cifras de bloco têm uma fraqueza evidente. O tamanho típico do bloco é 128 bits ou 16 caracteres. Obviamente, a criptografia moderna requer trabalhar com dados de entrada maiores, e é aqui que os modos de criptografia entram em ação. O modo de criptografia é essencialmente um hack: é uma maneira de aplicar de alguma forma uma cifra de bloco que aceita apenas entradas de um determinado tamanho para entradas de comprimento arbitrário.

O ataque de Vodene está focado no popular modo de operação CBC (Cipher Block Chaining). O ataque trata a cifra de bloco subjacente como uma caixa preta mágica e inexpugnável e ignora completamente sua segurança.

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

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

1. Executando uma operação XOR no segundo bloco de texto simples com o primeiro bloco de texto cifrado.
2. Criptografar o bloco resultante com uma cifra de bloco usando uma chave.

Como o CBC faz uso intenso da operação binária XOR, vamos relembrar algumas de suas propriedades:

• Idempotência:
• Comutatividade:
• Associatividade:
• Auto-reversibilidade:
• Tamanho do byte: byte n de = (byte n de ) (byte n de )

Normalmente, essas propriedades implicam que se tivermos uma equação envolvendo operações XOR e uma incógnita, ela poderá ser resolvida. Por exemplo, se soubermos que com o desconhecido e famoso и , então podemos confiar nas propriedades mencionadas acima para resolver a equação para . Aplicando XOR em ambos os lados da equação com , Nós temos . Tudo isso se tornará muito relevante em um momento.

Existem duas pequenas diferenças e uma grande diferença entre o nosso cenário Alice e o ataque de Vaudenay. Dois menores:

• No roteiro, Alice esperava que os textos simples terminassem com os caracteres a, bb, ccc e assim por diante. No ataque Wodene, a vítima espera que os textos simples terminem N vezes com o N byte (isto é, hexadecimal 01 ou 02 02, ou 03 03 03, e assim por diante). Esta é uma diferença puramente cosmética.
• No cenário Alice, era fácil saber se Alice havia aceitado a mensagem pela resposta “Texto fictício incorreto”. No ataque de Vodene, é necessária mais análise e é importante uma implementação precisa por parte da vítima; mas, por uma questão de brevidade, tomemos como certo que esta análise ainda é possível.

Principal diferença:

• Como não estamos usando o mesmo sistema criptográfico, a relação entre os bytes do texto cifrado controlados pelo invasor e os segredos (chave e texto simples) será obviamente diferente. Portanto, o invasor terá que usar uma estratégia diferente ao criar textos cifrados e interpretar as respostas do servidor.

Essa grande diferença é a peça final do quebra-cabeça para entender o ataque de Vaudenay, então vamos parar um momento para pensar sobre por que e como um ataque de oráculo à CBC pode ser montado em primeiro lugar.

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

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

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

Vamos chamar isso de “equação de Alice”. Controlamos o texto cifrado; o servidor (Alice) vazou informações vagas sobre o texto simples recebido; e isso nos permitiu deduzir informações sobre o último fator – a chave. Por analogia, se conseguirmos encontrar tal conexão para o script CBC, poderemos extrair algumas informações secretas também.

Felizmente, existem relacionamentos que podemos usar. Considere a saída da chamada final para descriptografar uma cifra de bloco e denote essa saída como . Também denotamos blocos de texto simples e blocos de texto cifrado . Dê uma outra olhada no diagrama CBC e observe o que acontece:

Vamos chamar isso de “equação CBC”.

No cenário de Alice, monitorando o texto cifrado e observando o vazamento do texto simples correspondente, conseguimos montar um ataque que recuperou o terceiro termo da equação – a chave. No cenário CBC, também monitoramos o texto cifrado e observamos vazamentos de informações no texto simples correspondente. Se a analogia for válida, podemos obter informações sobre .

Vamos supor que realmente restauramos , e então? Bem, então podemos imprimir todo o último bloco de texto simples de uma só vez (), simplesmente digitando (que temos) e
recebido na equação CBC.

Agora que estamos otimistas em relação ao plano geral de ataque, é hora de definir os detalhes. Preste atenção exatamente como as informações de texto simples vazam no servidor. No script de Alice, o vazamento ocorreu porque Alice só responderia com a mensagem correta se $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ terminasse com a linha a (ou bb, e assim por diante, mas as chances dessas condições serem desencadeadas pelo acaso eram muito pequenas). Semelhante ao CBC, o servidor aceita o preenchimento se e somente se termina em hexadecimal 01. Então, vamos tentar o mesmo truque: enviar textos cifrados falsos com nossos próprios valores falsos até que o servidor aceite o recheio.

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

Agora usamos a propriedade XOR byte-byte:

Conhecemos o primeiro e o terceiro termos. E já vimos que isto nos permite recuperar o termo restante - o último byte do :

Isso também nos dá o último byte do bloco de texto simples final por meio da equação CBC e da propriedade byte por byte.

Poderíamos deixar por isso mesmo e ficar satisfeitos por termos realizado um ataque a uma cifra teoricamente forte. Mas na verdade podemos fazer muito mais: podemos recuperar todo o texto. Isso requer um truque que não estava no script original de Alice e não é necessário para o ataque do oráculo, mas ainda vale a pena aprender.

Para entender isso, primeiro observe que o resultado da saída do valor correto do último byte é temos uma nova habilidade. Agora, ao forjar textos cifrados, podemos manipular o último byte do texto simples correspondente. Novamente, isso está relacionado à equação CBC e à propriedade byte por byte:

Como agora conhecemos o segundo termo, podemos utilizar o nosso controlo sobre o primeiro para controlar o terceiro. Simplesmente calculamos:

Não pudemos fazer isso antes porque ainda não tínhamos o último byte .

Como isso nos ajudará? Suponha que agora criemos todos os textos cifrados de modo que nos textos simples correspondentes o último byte seja igual a 02. O servidor agora só aceita preenchimento se o texto simples terminar com 02 02. Como corrigimos o último byte, isso só acontecerá se o penúltimo byte do texto simples também for 02. Continuamos enviando blocos de texto cifrado falsos, alterando o penúltimo byte, até que o servidor aceite o preenchimento para um deles. Neste ponto obtemos:

E restauramos o penúltimo byte assim como o último foi restaurado. Continuamos com o mesmo espírito: corrigimos os dois últimos bytes do texto simples para 03 03, repetimos esse ataque para o terceiro byte a partir do final e assim por diante, restaurando completamente .

E o resto do texto? Observe que o valor é na verdade $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Podemos colocar qualquer outro bloco , e o ataque ainda será bem-sucedido. Na verdade, podemos pedir ao servidor para fazer $inline$text{BLOCK_DECRYPT}$inline$ para quaisquer dados. Neste ponto, o jogo termina - podemos descriptografar qualquer texto cifrado (dê outra olhada no diagrama de descriptografia CBC para ver isso; e observe que o IV é público).

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

O ataque de Kelsey

Nosso simpático John Kelsey expôs os princípios subjacentes a muitos ataques possíveis, não apenas os detalhes de um ataque específico a uma cifra específica. Dele Artigo do ano 2002 é um estudo de possíveis ataques a dados compactados criptografados. Você achou que a informação de que os dados estavam compactados antes da criptografia não era suficiente para realizar um ataque? Acontece que isso é o suficiente.

Este resultado surpreendente deve-se a dois princípios. Primeiro, 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 é realizada, 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 é "alta entropia" ).

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

Texto simples 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Texto simples 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Vamos supor que ambos os textos simples sejam compactados e 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 poderia ser compactado no pequeno comprimento do segundo texto cifrado. Descobrimos isso sem saber nada sobre o algoritmo de compactação, a chave de criptografia ou mesmo a própria cifra. Comparado com a hierarquia de possíveis ataques criptográficos, isso é meio maluco.

Kelsey ressalta ainda que, sob certas circunstâncias incomuns, esse princípio também pode ser usado para realizar um ataque ao oráculo. Em particular, descreve como um invasor pode recuperar o texto simples secreto se puder forçar o servidor a criptografar os dados do formulário (o texto simples seguido por enquanto ele está no controle e pode de alguma forma verificar o comprimento do resultado criptografado.

Novamente, como outros ataques oracle, temos o relacionamento:

Novamente, controlamos um termo (), vemos um pequeno vazamento de informações sobre outro membro (texto cifrado) e tentamos recuperar o último (texto simples). Apesar da analogia, esta é uma situação um tanto incomum em comparação com outros ataques de oráculos que vimos.

Para ilustrar como tal ataque pode funcionar, vamos usar um esquema de compressão fictício que acabamos de criar: TOYZIP. Ele procura linhas de texto que 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, a linha helloworldhello pode ser compactado em helloworld[00][00][05] 13 bytes de comprimento em comparação com os 15 bytes originais.

Suponha que um invasor tente recuperar o texto simples de um formulário password=..., onde a senha em si é desconhecida. De acordo com o modelo de ataque de Kelsey, um invasor poderia solicitar ao servidor que compactasse e depois criptografasse mensagens de formulário (texto simples seguido de ), Onde  - Texto livre. Quando o servidor termina de funcionar, ele informa a duração do resultado. O ataque é assim:

Assaltante: Compacte e criptografe o texto simples sem qualquer preenchimento.

Servidor: Comprimento do resultado 14.

Assaltante: Comprima e criptografe o texto simples ao qual está anexado password=a.

Servidor: Comprimento do resultado 18.

As notas do cracker: [original 14] + [três bytes que substituíram password=] + a

Assaltante: Comprima e criptografe o texto simples ao qual é adicionado password=b.

Servidor: Comprimento do resultado 18.

Assaltante: Comprima e criptografe o texto simples ao qual é adicionado password=с.

Servidor: Comprimento do resultado 17.

As notas do cracker: [original 14] + [três bytes que substituíram password=c]. Isso pressupõe que o texto simples original contém a string password=c. Ou seja, a senha começa com uma letra c

Assaltante: Comprima e criptografe o texto simples ao qual é adicionado password=сa.

Servidor: Comprimento do resultado 18.

As notas do cracker: [original 14] + [três bytes que substituíram password=с] + a

Assaltante: Comprima e criptografe o texto simples ao qual é adicionado password=сb.

Servidor: Comprimento do resultado 18.

(… Algum tempo depois…)

Assaltante: Comprima e criptografe o texto simples ao qual é adicionado password=со.

Servidor: Comprimento do resultado 17.

As notas do cracker: [original 14] + [três bytes que substituíram password=co]. Usando a 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 restaurada.

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

Vulnerabilidades da marca: CRIME, POODLE, DROWN

Finalmente, depois de estudar detalhadamente a teoria, podemos ver como essas técnicas são aplicadas em ataques criptográficos da vida real.

CRIME

Se o ataque for direcionado ao navegador e à rede da vítima, alguns serão mais fáceis e outros mais difíceis. Por exemplo, é fácil ver o trânsito da vítima: basta sentar-se com ela no mesmo café com WiFi. Por esta razão, as potenciais vítimas (ou seja, todas as pessoas) são geralmente aconselhadas a usar uma ligação encriptada. Será mais difícil, mas ainda possível, fazer 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 web maliciosa com um script que faça a solicitação. O navegador fornecerá automaticamente o cookie de sessão correspondente.

Isso parece incrível. Se Bob fosse para evil.com, o script deste site poderia simplesmente pedir ao Google para enviar por e-mail a senha de Bob para [email protected]? Bem, em teoria sim, mas na realidade não. Este cenário é chamado de ataque de falsificação de solicitação entre sites (Falsificação de solicitação entre sites, CSRF) e era popular em meados dos anos 90. Hoje se evil.com tentar esse truque, o Google (ou qualquer site que se preze) geralmente responderá: “Ótimo, mas seu token CSRF para esta transação será... hum... три триллиона и семь. Por favor, repita este número." Os navegadores modernos têm algo chamado de "política de mesma origem", segundo a qual os scripts no site A não têm acesso às informações enviadas pelo site B. Portanto, o script no site A não tem acesso às informações enviadas pelo site B. evil.com pode enviar solicitações para google.com, mas não consegue ler as respostas nem concluir a transação.

Devemos enfatizar que, a menos que Bob esteja usando uma conexão criptografada, todas essas proteções não têm sentido. Um invasor pode simplesmente ler o tráfego de Bob e recuperar o cookie de sessão do Google. Com esse cookie, ele simplesmente abrirá uma nova guia do Google sem sair de seu navegador e se fará passar por Bob sem encontrar políticas incômodas de mesma origem. Mas, infelizmente para um ladrão, isto está se tornando cada vez 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 encolheu antes da criptografia; essa era uma prática comum para reduzir a latência.

É aqui que entra em jogo CRIME (Taxa de compressão Infoleak Made Easy, vazamento simples através da taxa de compressão). A vulnerabilidade foi 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 fizeram e como. Um invasor pode forçar o navegador de Bob a enviar solicitações ao Google e depois ouvir as respostas na rede local de forma compactada e criptografada. Portanto temos:

Aqui o invasor controla a solicitação e tem acesso ao farejador de tráfego, incluindo o tamanho do pacote. O cenário fictício de Kelsey ganhou vida.

Compreendendo 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 modernos, resultando no lançamento de patches que enterraram silenciosamente o recurso de compactação em SSL para que ele não fosse usado. O único protegido da 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 causou impacto na comunidade de segurança. Eles conseguiram explorar uma vulnerabilidade no protocolo SSL que havia sido corrigida há mais de dez anos.

Acontece que enquanto os servidores estão executando o novíssimo TLSv1.2, muitos deixaram o suporte para o legado SSLv3 para compatibilidade com versões anteriores do Internet Explorer 6. Já falamos sobre ataques de downgrade, então você pode imaginar o que está acontecendo. Uma sabotagem bem orquestrada do protocolo de handshake e os servidores estão prontos para retornar ao bom e velho SSLv3, desfazendo essencialmente os últimos 15 anos de pesquisas de segurança.

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

Transport Layer Security (TLS) é o protocolo de segurança mais importante da Internet. [..] quase todas as transações que você faz na Internet dependem de TLS. [..] Mas o TLS nem sempre foi TLS. O protocolo começou sua vida em Comunicações Netscape chamado "Secure Sockets Layer" ou SSL. Há rumores de que a primeira versão do SSL era tão terrível que os desenvolvedores coletaram todas as impressões do código e as enterraram em um aterro secreto no Novo México. Como consequência, a primeira versão publicamente disponível do SSL é, na verdade, versão SSL2. É muito assustador e [..] foi um produto de meados dos anos 90, que os criptógrafos modernos consideram como "idade das trevas da criptografia" Muitos dos ataques criptográficos mais hediondos que conhecemos hoje ainda não foram descobertos. Como resultado, os desenvolvedores do protocolo SSLv2 foram essencialmente deixados à deriva no escuro e enfrentaram muitos monstros terríveis - para desgosto deles e para nosso benefício, uma vez que os ataques ao SSLv2 deixaram lições valiosas para a próxima geração de protocolos.

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

Felizmente para os ladrões, “alguns” não significa “todos”. No geral, o SSLv3 forneceu todos os elementos necessários para lançar um ataque Vodene. O protocolo usava uma cifra de bloco no modo CBC e um esquema de preenchimento inseguro (isso foi corrigido no TLS; daí a necessidade de um ataque de downgrade). Se você se lembra do esquema de preenchimento em nossa descrição original do ataque Vaudenay, o esquema SSLv3 é muito semelhante.

Mas, infelizmente para os ladrões, “semelhante” não significa “idêntico”. O esquema de preenchimento SSLv3 é "N bytes aleatórios seguidos do número N". Tente, nessas condições, selecionar um bloco imaginário de texto cifrado e seguir todas as etapas do esquema original de Vaudene: você descobrirá que o ataque extrai com sucesso o último byte do bloco de texto simples correspondente, mas não vai além. Descriptografar cada 16 bytes do texto cifrado é um ótimo truque, mas não é uma vitória.

Diante do fracasso, a equipe do Google recorreu a um último recurso: mudou para um modelo de ameaça mais poderoso – aquele usado no CRIME. Supondo que o invasor seja um script executado na aba do navegador da vítima e possa extrair cookies de sessão, o ataque ainda é impressionante. Embora o modelo de ameaça mais amplo seja menos realista, vimos na secção anterior que este modelo específico é viável.

Dadas estas capacidades de ataque mais poderosas, o ataque pode agora continuar. Observe que o invasor sabe onde o cookie de sessão criptografado aparece no cabeçalho e controla a duração da solicitação HTTP que o precede. Portanto, ele é capaz de manipular a solicitação HTTP para que o último byte do cookie fique alinhado com o final do bloco. Agora este byte é adequado para descriptografia. Você pode simplesmente adicionar um caractere à solicitação e o penúltimo byte do cookie permanecerá no mesmo local e poderá ser selecionado pelo mesmo método. O ataque continua desta forma até que o arquivo cookie seja completamente restaurado. É chamado POODLE: Padding Oracle na criptografia legada rebaixada.

AFOGAR

Como mencionamos, o SSLv3 tinha suas falhas, mas era fundamentalmente diferente de seu antecessor, já que o SSLv2 com vazamento era um produto de uma época diferente. Lá você poderia interromper a mensagem no meio: соглашусь на это только через мой труп se tornou соглашусь на это; o cliente e o servidor poderiam se encontrar on-line, estabelecer confiança e trocar segredos na frente do invasor, que poderia facilmente personificar ambos. Há também o problema com a criptografia de exportação, que mencionamos ao considerar o FREAK. Estas eram Sodoma e Gomorra criptográficas.

Em março de 2016, uma equipe de pesquisadores de diferentes áreas técnicas se reuniu e fez uma descoberta surpreendente: o SSLv2 ainda é usado em sistemas de segurança. Sim, os invasores não podem mais fazer o downgrade das sessões TLS modernas para SSLv2, pois essa lacuna foi fechada após FREAK e POODLE, mas eles ainda podem se conectar a servidores e iniciar sessões SSLv2 por conta própria.

Você pode perguntar: por que nos importamos com 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, não exatamente. Sim, é assim que deveria ser em teoria. Mas não - porque a geração de certificados SSL impõe uma certa carga, resultando em muitos servidores usando os mesmos certificados e, como resultado, as mesmas chaves RSA para conexões TLS e SSLv2. Para piorar a situação, devido a um bug do OpenSSL, a opção “Desativar SSLv2” nesta popular implementação SSL não funcionou de fato.

Isso tornou possível um ataque entre protocolos ao TLS, chamado AFOGAR (Descriptografando RSA com criptografia obsoleta e enfraquecida, descriptografando RSA com criptografia obsoleta e enfraquecida). Lembre-se de que isto não é o mesmo que um ataque curto; o invasor não precisa agir como um “intermediário” e não precisa envolver o cliente para participar de uma sessão insegura. Os invasores simplesmente iniciam uma sessão SSLv2 insegura com o servidor, atacam o protocolo fraco e recuperam a chave privada RSA do servidor. Essa chave também é válida para conexões TLS e, a partir de agora, nenhuma segurança TLS impedirá que ela seja comprometida.

Mas para quebrá-lo, você precisa de um ataque funcional contra SSLv2, que permite recuperar não apenas o tráfego específico, mas também a chave secreta do servidor RSA. Embora esta seja uma configuração complexa, os pesquisadores podem escolher qualquer vulnerabilidade que tenha sido completamente fechada após o SSLv2. Acabaram por encontrar uma opção adequada: o ataque Bleichenbacher, que mencionámos anteriormente e que explicaremos em detalhe no próximo artigo. SSL e TLS estão protegidos contra esse ataque, mas alguns recursos aleatórios do SSL, combinados com chaves curtas na criptografia de nível de exportação, tornaram possível uma implementação específica de DROWN.

No momento da publicação, 25% dos principais sites da Internet foram afetados pela vulnerabilidade DROWN, e o ataque poderia ser realizado com recursos modestos disponíveis até mesmo para hackers solitários e maliciosos. A recuperação da chave RSA do servidor exigiu oito horas de computação e US$ 440, e o SSLv2 passou de obsoleto a radioativo.

Espere, e quanto ao Heartbleed?

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

Vamos fazer uma pausa

Começamos com algumas técnicas básicas: força bruta, interpolação, downgrade, protocolo cruzado e pré-computação. Em seguida, examinamos uma técnica avançada, talvez o principal componente dos ataques criptográficos modernos: o ataque oracle. Passamos algum tempo descobrindo isso - e entendemos não apenas o princípio subjacente, mas também os detalhes técnicos de duas implementações específicas: o ataque Vaudenay ao modo de criptografia CBC e o ataque Kelsey aos protocolos de criptografia de pré-compressão.

Ao revisar os ataques de downgrade e pré-computação, descrevemos brevemente o ataque FREAK, que usa ambos os métodos, fazendo com que os sites alvo sejam rebaixados para chaves fracas e, em seguida, reutilize as mesmas chaves. Para o próximo artigo, salvaremos o ataque Logjam (muito semelhante), que tem como alvo algoritmos de chave pública.

Em seguida, analisamos mais três exemplos de aplicação desses princípios. Primeiro, CRIME e POODLE: dois ataques que dependiam da capacidade do invasor de injetar texto simples arbitrário próximo ao texto simples alvo, depois examinar as respostas do servidor e então,usando a metodologia de ataque Oracle, explore essas informações esparsas para recuperar parcialmente o texto simples. CRIME seguiu o caminho do ataque de Kelsey à compressão SSL, enquanto POODLE usou uma variante do ataque de Vaudenay ao CBC com o mesmo efeito.

Em seguida, voltamos nossa atenção para o ataque DROWN entre protocolos, que estabelece uma conexão com o servidor usando o protocolo SSLv2 legado e depois recupera as chaves secretas do servidor usando o ataque Bleichenbacher. Por enquanto, ignoramos os detalhes técnicos desse ataque; como o Logjam, terá que esperar até que tenhamos um bom entendimento dos criptossistemas de chave pública e suas vulnerabilidades.

No próximo artigo falaremos sobre ataques avançados como meet-in-the-middle, criptoanálise diferencial e ataques de aniversário. Vamos fazer uma rápida incursão nos ataques de canal lateral e depois passar para a parte divertida: criptossistemas de chave pública.

Fonte: habr.com