alguns pensamentos sobre Engenharia criptográfica

algumas semanas atrás, escrevi um longo post sobre o projeto ‘BULLRUN’ da NSA para subverter os padrões modernos de criptografia. Eu pretendia voltar a isso em algum momento, já que não tive tempo de discutir os problemas em detalhes. Mas então as coisas atrapalharam. Muitas coisas, na verdade. Alguns dos quais espero escrever em um futuro próximo.

Mas antes de eu chegar lá, e correndo o risco de aborrecer todos às lágrimas, eu queria voltar a este assunto, pelo menos por mais tempo, se apenas de pontificado, um pouco sobre uma questão que vem me incomodando.Veja, a folha de instruções da NSA BULLRUN menciona que a NSA vem quebrando algumas tecnologias de criptografia, algumas das quais são mais interessantes do que outras. Uma dessas tecnologias é particularmente surpreendente para mim, já que eu simplesmente não consigo descobrir como a NSA pode estar fazendo isso. Neste post extremamente longo, vou tentar me aprofundar um pouco mais na questão mais importante que a Internet enfrenta hoje.

especificamente: como diabos a NSA está quebrando o SSL?

seção da folha de instruções do BULLRUN. Fonte: New York Times.

para manter as coisas no alvo, vou fazer algumas regras básicas básicas.

primeiro, estou bem ciente de que a NSA pode instalar malware em seu computador e pwn qualquer criptografia que você escolher. Isso não me interessa, pela simples razão de que não escala bem. A NSA pode fazer isso com você, mas eles não podem fazer isso por uma população inteira. E isso é realmente o que me preocupa sobre os vazamentos recentes: a possibilidade de que a NSA está quebrando criptografia para fins de Vigilância em massa.

pelo mesmo motivo, não vamos nos preocupar com ataques man-in-the-middle (MITM). Embora saibamos que a NSA os executa, eles também são um ataque muito direcionado. Não só os MITMs são detectáveis se você os fizer em grande escala, eles não se comportam com o que sabemos sobre como a NSA faz interceptação em grande escala-principalmente por meio de Divisores de feixe e torneiras. Em outras palavras: estamos realmente preocupados com a vigilância passiva.

as regras acima não são absolutas, é claro. Consideraremos ataques direcionados limitados a servidores, desde que posteriormente permitam a descriptografia passiva de grandes quantidades de tráfego; por exemplo, descriptografia de tráfego para os principais sites. Também consideraremos modificações arbitrárias em software e hardware — algo que sabemos que a NSA já está fazendo.

um último ponto: para evitar que as coisas saiam dos trilhos, dividi este post em duas seções. O primeiro cobrirá ataques que usam apenas técnicas conhecidas. Tudo nesta seção pode ser implementado por um funcionário da TAO com bom senso e acesso a software. A segunda seção, que eu intitulei o ‘Tinfoil Hat Spectrum’ cobre as coisas divertidas e especulativas — que vão desde novos ataques de canal lateral até aquele enorme computador quântico que a NSA mantém ao lado do BWI.

começaremos com o’prático’.

ataques que usam técnicas conhecidas

roubo de chaves RSA. A maneira mais óbvia de “quebrar” o SSL não envolve realmente quebrar nada. Por que perder tempo e dinheiro em criptoanálise quando você pode simplesmente roubar as chaves? Esse problema é particularmente preocupante em servidores configurados para o handshake TLS RSA, onde uma única chave de servidor de 128 bytes é tudo o que você precisa para descriptografar todas as conexões passadas e futuras feitas a partir do dispositivo.Na verdade, essa técnica é tão óbvia que é difícil imaginar a NSA gastando muitos recursos em sofisticados ataques criptoanalíticos. Sabemos que GCHQ e NSA são perfeitamente confortáveis subornando até mesmo provedores dos EUA no exterior. E dentro de nossas fronteiras, eles demonstraram vontade de obter chaves TLS/SSL usando poderes de intimação e ordens de mordaça. Se você estiver usando uma conexão RSA para um site importante, pode ser sensato assumir que a chave já é conhecida.É claro que, mesmo quando a NSA não recorre a medidas diretas, sempre há a possibilidade de obter chaves por meio de uma exploração remota de software. A beleza é que esses ataques nem exigem Execução Remota de código. Dada a vulnerabilidade certa, pode simplesmente exigir um punhado de solicitações SSL malformadas para mapear o conteúdo completo do heap OpenSSL/SChannel.

Fonte: New York Times

Suborning criptografia de hardware fichas. Uma fração significativa do tráfego SSL na Internet é produzida por Dispositivos de hardware, como terminadores SSL e roteadores habilitados para VPN. Felizmente, não precisamos especular sobre a segurança desses dispositivos — já sabemos que a NSA/GCHQ tem colaborado com fabricantes de hardware para “habilitar” a descriptografia em vários chips de criptografia VPN importantes.

os documentos da NSA não são claros sobre como essa capacidade funciona, ou se ela envolve SSL. Se isso acontecer, o palpite óbvio é que cada chip criptografa e exflitra bits da chave de sessão por meio de campos ‘aleatórios’, como IVs e handshake nonces. Na verdade, isso é relativamente fácil de implementar em um dispositivo de hardware opaco. A questão interessante é como se garante que esses backdoors só possam ser explorados pela NSA-e não por agências de inteligência rivais. (Alguns pensamentos sobre isso aqui.)

ataques de canal lateral. Tradicionalmente, quando analisamos algoritmos criptográficos, nos preocupamos com as entradas e Saídas esperadas do sistema. Mas Sistemas reais vazam todos os tipos de informações extras. Esses “canais laterais” — que incluem tempo de operação, consumo de recursos, tempo de cache e emissões de RF — geralmente podem ser usados para extrair material de chave secreta.

A boa notícia é que a maioria desses canais só são exploráveis quando o invasor está em proximidade física com um servidor TLS. A má notícia é que existem condições em que o atacante pode se aproximar. O exemplo mais óbvio envolve servidores TLS virtualizados na configuração de nuvem, onde um invasor inteligente pode compartilhar recursos físicos com o dispositivo de destino.

uma segunda classe de ataque usa informações de tempo remoto para recuperar lentamente uma chave RSA. Esses ataques podem ser desativados por meio de contramedidas, como cegamento RSA, embora divertidamente, alguns co-processadores de hardware ‘seguros’ podem realmente desativar essas contramedidas por padrão! Pelo menos, Isso torna o hardware vulnerável a ataques de um usuário local e pode até facilitar a recuperação remota de chaves RSA.

geradores de números aleatórios fracos. Mesmo se você estiver usando ciphersuites strong Perfect Forward Secrecy, a segurança do TLS depende fundamentalmente da disponibilidade de números aleatórios imprevisíveis. Não por coincidência, adulterar os padrões do gerador de números aleatórios parece ter sido um foco particular dos esforços da NSA.

os números aleatórios são críticos para vários elementos no TLS, mas são particularmente importantes em três lugares:

  1. no lado do cliente, durante o aperto de mão RSA. O RNG é usado para gerar o segredo pré-mestre do RSA e o preenchimento de criptografia. Se o invasor puder prever a saída desse gerador, ele poderá descriptografar a sessão inteira posteriormente. Ironicamente, uma falha do servidor RNG é muito menos devastadora para o handshake RSA.*
  2. no lado do cliente ou servidor, durante o handshake(s) Diffie-Hellman. Como Diffie-Hellman requer uma contribuição de cada lado da conexão, um RNG previsível em ambos os lados torna a sessão completamente transparente.
  3. durante a geração de chaves de longo prazo, particularmente de chaves RSA. Se isso acontecer, você está ferrado.
e você simplesmente não precisa ser tão sofisticado para enfraquecer um gerador de números aleatórios. Esses geradores já são surpreendentemente frágeis e é muito difícil detectar quando alguém está quebrado. Os mantenedores do Debian fizeram este ponto lindamente em 2008, quando uma limpeza de código errante reduziu a Entropia efetiva do OpenSSL para apenas 16 bits. Na verdade, os RNGs são tão vulneráveis que o desafio aqui não é enfraquecer o RNG — qualquer idiota com um teclado pode fazer isso — está fazendo isso sem tornar a implementação trivialmente vulnerável a todos os outros.

A boa notícia é que é relativamente fácil adulterar uma implementação SSL para criptografá-la e exfiltrar a semente RNG atual. Isso ainda requer que alguém altere fisicamente a biblioteca ou instale um exploit persistente, mas pode ser feito de forma inteligente, mesmo sem adicionar muito novo código ao código OpenSSL existente. (O amor de OpenSSL por ponteiros de função torna particularmente fácil adulterar essas coisas.)

se adulteração não é o seu estilo,por que não colocar o backdoor à vista? Essa é a abordagem que a NSA adotou com o Dual_EC RNG, padronizado pelo NIST na publicação especial 800-90. Há evidências convincentes de que a NSA deliberadamente projetou este gerador com um backdoor — um que lhes permite quebrar qualquer conexão TLS/SSL feita usando-o. Como o gerador é (era) o padrão na biblioteca BSAFE da RSA, você deve esperar que todas as conexões TLS feitas usando esse software sejam potencialmente comprometidas.

e eu nem mencionei os planos da Intel de substituir o kernel Linux RNG por seu próprio hardware RNG.

fraquezas Esotéricas nos sistemas PFS. Muitos servidores da web, incluindo Google e Facebook, agora usam ciphersuites de sigilo avançado perfeito como efêmero Diffie-Hellman (DHE e ECDHE). Em teoria, esses ciphersuites fornecem o melhor de todos os mundos possíveis: as chaves persistem por uma sessão e desaparecem assim que a conexão termina. Embora isso não o salve de problemas de RNG, torna o roubo de chaves muito mais difícil.

ciphersuites PFS são uma coisa boa, mas uma variedade de questões sutis pode apertar seu estilo. Por um lado, o mecanismo de retomada da sessão pode ser exigente: as chaves de sessão devem ser armazenadas localmente ou criptografadas e distribuídas aos usuários na forma de tickets de sessão. Infelizmente, o uso de tickets de sessão diminui um pouco a “perfeição” dos sistemas PFS, uma vez que as chaves usadas para criptografar os tickets agora representam uma grande fraqueza no sistema. Além disso, você não pode nem mesmo mantê-los internos a um servidor, pois eles precisam ser compartilhados entre todos os servidores front-end de um site! Em suma, eles parecem uma espécie de pesadelo.

uma área final de preocupação é a validação dos parâmetros Diffie-Hellman. O design SSL atual assume que os grupos DH são sempre gerados honestamente pelo servidor. Mas uma implementação maliciosa pode violar essa suposição e usar parâmetros ruins, que permitem a espionagem de terceiros. Este parece ser um caminho bastante improvável para permitir a vigilância, mas mostra como esses sistemas são delicados.

o Tinfoil Hat Spectrum

vou me referir ao próximo lote de ataques como vulnerabilidades ‘tinfoil hat’. Onde os problemas anteriores alavancam técnicas bem conhecidas, cada uma das propostas a seguir requer técnicas criptoanalíticas totalmente novas. Tudo isso é uma maneira de dizer que a seção a seguir é pura especulação. É divertido especular, é claro. Mas exige que assumamos fatos não em evidência. Além disso, temos que ter um pouco de cuidado sobre onde paramos.

então, daqui em diante, estamos essencialmente conduzindo um experimento mental. Vamos imaginar que a NSA tem uma capacidade passiva de quebra de SSL; e, além disso, que não depende dos truques da seção anterior. O que resta?

A lista a seguir começa com as teorias mais “prováveis” e trabalha para os verdadeiramente insanos.

quebrando chaves RSA. Há um boato persistente em nosso campo de que a NSA está quebrando chaves RSA de 1024 bits. É duvidoso que esse boato provenha de qualquer conhecimento real das operações da NSA. É mais provável que seja impulsionado pelo fato de que quebrar chaves de 1024 bits é altamente viável para uma organização com os recursos da NSA.

quão viável? Vários pesquisadores confiáveis tentaram responder a essa pergunta, e acontece que o custo é menor do que você pensa. Em 2003, Shamir e Tromer estimaram US $ 10 milhões para uma máquina construída especificamente que poderia fatorar uma chave de 1024 bits por ano. Em 2013, Tromer reduziu esses números para cerca de US $1 milhão, levando em consideração os avanços de hardware. E pode ser significativamente menor. Esta é uma troca de bolso para a NSA.

em linhas semelhantes, Bernstein, Heninger e Lange examinaram a viabilidade de quebrar a RSA usando redes distribuídas de PCs padrão. Seus resultados são bastante perturbadores: em princípio, um cluster do tamanho da botnet Conficker da vida real poderia causar violência séria às chaves de 1024 bits.

dado tudo isso, você pode perguntar por que essa possibilidade está mesmo na categoria ‘tinfoil hat’. A resposta simples é: porque ninguém realmente fez isso. Isso significa que é pelo menos concebível que as estimativas acima sejam dramaticamente muito altas — ou mesmo muito baixas. Além disso, as chaves RSA-1024 estão sendo eliminadas rapidamente. Quebrar chaves de 2048 bits exigiria avanços matemáticos significativos, levando-nos muito mais fundo no chapéu de papel alumínio.**

Cracking RC4. No papel, o TLS suporta uma variedade de algoritmos de criptografia fortes. Na prática, cerca de metade de todo o tráfego TLS é protegido com a velha cifra RC4. E isso deve preocupá — lo-porque o RC4 está começando a mostrar sua idade. Na verdade, como usado no TLS, já é vulnerável a ataques práticos (limítrofes). Assim, parece um bom candidato para um verdadeiro avanço criptanalítico por parte da NSA.Infelizmente, o problema com esta teoria é que nós simplesmente não sabemos de qualquer ataque que permitiria a NSA para quebrar utilmente RC4! As técnicas conhecidas exigem que um invasor colete milhares ou milhões de ciphertexts que são (a) criptografados com chaves relacionadas (como no WEP) ou (b) contêm o mesmo texto simples. O ataque mais conhecido contra o TLS assume a última forma-requer que a vítima estabeleça bilhões de sessões e, mesmo assim, recupera apenas elementos de texto simples fixos, como cookies ou senhas.

o contra-argumento é que a comunidade de pesquisa pública não tem pensado muito sobre RC4 na última década-em parte porque pensamos que era tão quebrado que as pessoas pararam de usá-lo (Opa!) Se estivéssemos focando toda a nossa atenção nisso (ou melhor, a atenção da NSA), quem sabe o que teríamos hoje.Se você me dissesse que a NSA tinha uma capacidade criptanalítica verdadeiramente nova, eu concordaria com Jake e apontaria o dedo para RC4. Principalmente porque as alternativas são muito mais assustadoras.

novos ataques de canal lateral. Na maior parte, os ataques de tempo remoto parecem ter sido eliminados pela implementação de contramedidas, como cegamento RSA, que confundem o tempo multiplicando um fator de cegamento Aleatório em cada texto cifrado antes da descriptografia. Em teoria, isso deve tornar as informações de tempo essencialmente inúteis. Na prática, muitas implementações TLS implementam compromissos no código ofuscante que podem ressuscitar esses ataques, coisas como quadratura de um fator ofuscante entre as operações de descriptografia, em vez de gerar um novo a cada vez. É bastante improvável que haja ataques aqui, mas quem sabe.

coisas Patetas. Talvez a NSA tenha algo realmente incrível na manga. O problema de abrir a caixa de Pandora é que é muito difícil fechá-la novamente. Jerry Solinas realmente cozinhou o NIST p-curves para apoiar algum novo ataque incrível (que a NSA sabia sobre o caminho de volta no final dos anos 1990, mas ainda não descobrimos)? A NSA tem um supercomputador gigante chamado TRANSLTR que pode forçar qualquer criptosistema? Existe um computador quântico gigante no Anexo da Amizade BWI? Para obter respostas a essas perguntas, você também pode agitar a bola mágica 8, Porque eu não tenho ideia.

conclusão

não sabemos e não podemos saber a resposta para essas coisas, e honestamente isso vai te deixar louco se você começar a pensar sobre isso. Tudo o que podemos realmente fazer é tomar NSA/GCHQ em sua palavra quando eles nos dizem que essas capacidades são “extremamente frágeis”. Isso deve pelo menos nos dar esperança.

A questão agora é se podemos adivinhar bem o suficiente para transformar essa fragilidade de um aviso em uma promessa.
notas:

* uma falha do RNG do servidor pode resultar em alguns valores previsíveis, como o ServerRandom e IDs de sessão. Um invasor que pode prever esses valores pode ser capaz de executar ataques ativos contra o protocolo, mas — no ciphersuite RSA, pelo menos — eles não admitem compromisso passivo.

** embora as chaves RSA de 1024 bits estejam sendo eliminadas, muitos servidores ainda usam 1024 bits para Diffie-Hellman (principalmente por razões de eficiência). Os ataques a essas chaves são semelhantes aos usados contra RSA — no entanto, a principal diferença é que novas chaves ‘efêmeras’ Diffie-Hellman são geradas para cada nova conexão. Quebrar grandes quantidades de tráfego parece bastante caro.

Deixe uma resposta

O seu endereço de email não será publicado.