This article is an automated machine-translation of an article in English. We know the translation isn't perfect, but we hope it's useful for people who don't read English.

Criptografia de 'crack' Boffins HTTPS em Sorte Treze ataque

Filed Under: Featured, Privacy, Web Browsers

A segurança das transações online está novamente no centro das atenções como um par de criptógrafos Reino Unido mirar em TLS.

TLS, ou Transport Layer Security, é o sucessor do SSL, ou Secure Sockets Layer.

É o sistema que coloca o S em HTTPS (que é o cadeado que você vê em sites seguros), e fornece a segurança para muitos outros protocolos, também.

Como 2011 é infame ataque BEAST , ele tem um nome groovy: Lucky Thirteen .

O nome vem do fato de que os pacotes criptografados TLS tem 13 bytes de cabeçalho que são consumidos em um dos cálculos criptográficos em que TLS confia.

→ O nome do papel é um pouco atrevido - ironicamente os autores observam que "em certo sentido, 13 é sorte, mas 12 teria sido mais sorte", desde 12 de byte cabeçalhos faria seu ataque ainda mais eficiente.

Para lhe dar uma ideia do que faz criptógrafos carrapato, e como eles conseguem extrair ordem, mesmo a partir do caos, cuidadosamente planejado, veja como tudo começou.

Os autores do estudo notou que os pacotes criptografados na maioria das sessões TLS:

  • São criptografados com uma cifra de bloco seguro, geralmente AES no modo CBC, para manter o segredo conteúdo.
  • Incluir uma soma de verificação criptográfica forte, geralmente HMAC-SHA1, para evitar erros e falsificações.

Você pode supor que o uso não uma, mas duas primitivas criptográficas fortes inevitavelmente aumentar a segurança, mas criptógrafos não pensar dessa forma.

Nadhem Alfardan e Kenneth Paterson da Royal Holloway, um renomado centro de pesquisa de segurança da informação que faz parte da Universidade de Londres, perceberam que poderiam usar esses dois recursos de segurança contra o outro por causa da maneira como eles são combinados em TLS.

Muito simplista, o ataque conta com os seguintes detalhes:

  • A cifra de bloco AES criptografa 16 bytes de cada vez. Os pacotes de dados que não são um múltiplo de 16 bytes de comprimento deve ser preenchido até que eles são.
  • As somas de verificação de pacotes TLS estão armazenadas dentro da camada de criptografia, depois de os dados brutos, mas antes de qualquer estofo necessário.

Quando um servidor TLS recebe um pacote que é HMAC-SHA1 checksummed e AES-CBS criptografado, ele precisa validá-lo, como este:

  • Descriptografar os dados recebidos, que deve ser um múltiplo de 16 bytes de comprimento.
  • Identificar qualquer preenchimento no fim do buffer decifrado, e retira-lo fora.
  • Retire os últimos 20 bytes (o comprimento de uma soma de verificação HMAC-SHA1) e armazená-lo como referência.
  • Calcular o HMAC-SHA1 do que resta no buffer (menos estofo e verificação de referência).

Se o checksum computado HMAC-SHA1 não corresponde a soma de verificação de referência, então, tem havido um erro ou uma falsificação. O servidor irá enviar de volta uma mensagem de erro e terminar a ligação.

Agora imagine que você é um MITM, ou um man-in-the-middle. Você não pode descriptografar e criptografar novamente os pacotes como eles voam passado, mas você pode interceptá-los, abreviá-los, alterá-los de forma sutil, e transmitir as versões modificadas.

Toda vez que você fizer isso, você vai quebrar a sessão TLS você está atacando, mas você pode fazer isso de uma maneira que pode apenas vazar informações sobre o que estava dentro da sessão, agora quebrado.

Isso não vai imediatamente dar-lhe as jóias da coroa, mas se você pode extrair nada do fluxo de dados cifrados, você violou a santidade de criptografia TLS que é suposto fornecer.

O truque é que, quando você truncar um pacote criptografado, há uma chance de que o texto original no final do fluxo de dados amputado será parecido com o tipo de estofo bytes que TLS teria acrescentado se os dados originais tinham sido mais curto para começar .

Nesse caso, o servidor TLS irá retirar o que ele pensa que é o preenchimento, extrair o que ele pensa que é a soma de verificação de pacotes, e depois verificar se o checksum.

A soma de verificação não irá corresponder, é claro, mas você não se importa com isso.

O que importa é quanto tempo o servidor TLS necessário para responder com a sua mensagem de erro quando ele percebe que o pacote é inválido.

Por causa da maneira que HMAC-SHA1 obras, que leva quatro unidades de tempo de CPU para soma de verificação os primeiros 55 bytes de dados, além de uma unidade de tempo extra para cada pedaço adicional de 64 bytes (ou parte dele no final).

Os autores perceberam que, ao fazer um de dois bytes ajustar a parte de um pacote criptografado e truncando-lo, eles tiveram uma chance de aproximadamente uma em 65 mil que o servidor iria acabar mal pensando que a mensagem foi preenchido, tirando o preenchimento e checksumming o que era à esquerda.

A menos que o código de servidor TLS foi cuidadosamente concebido para consumir a mesma quantidade de tempo, independentemente do conteúdo do pacote descriptografado, isto levaria quatro quintos do tempo de processamento de um pacote untweaked.

Isso aconteceria porque o pacote tweaked tinha enganado o servidor em checksumming 55 bytes ou menos de dados, não 56 ou mais.

Se os pesquisadores puderam medir de forma confiável este aumento de velocidade por tempo quão rápido a resposta do servidor de erro voltou, então, com base na emenda, que poderia agora calcular dois bytes do pacote original.

Por sistematicamente tentando todas as possíveis ajustes de dois bytes (2 16, ou 65.536 deles), e assumindo medição timing perfeito, que poderia garantir para extrair dois dos bytes criptografados.

Uma vez que os dois primeiros bytes são rachado, mais 14 bytes pode ser quebrada, um byte de cada vez, tentando todas as 256 emendas possíveis de cada byte, para um total de "custo tweak" de 2 16 + 8 14x2.

E isso é o ataque Sorte Treze, em grotescamente operacional breve, se não teórico, termos.

Não é um ataque muito prático, até porque as medidas de duração perfeitas são impossíveis:

  • Cada tentativa ajustar provoca uma sessão TLS para finalizar, que tanto pode ser perceptível e demorado.
  • Cada sessão tweaked precisa de ter o mesmo texto simples no local do mesmo pacote para o ajuste deve ser feito de forma exaustiva.
  • Os autores necessário 2 7 repetições de um conjunto exaustivo de 2 16 emendas (que tem oito milhões de sessões TLS insucesso!) Para produzir dados de tempo suficiente estatisticamente significativos para um resultado confiável.

Ah, e que estava sob circunstâncias ideais de rede, com o cliente TLS servidor e MITM computador na mesma LAN dedicada.

No entanto, é um resultado importante, pois, como mencionado acima, alguns dos perfura a santidade de criptografia TLS que é suposto fornecer.

Soluções e mitigações, o que os designers de futuros protocolos pode ter em mente, incluem:

  • Desenhar e escrever o seu código para que ele não é mensurável mais rápido ou mais lento quando ocorrem erros, mesmo que isso signifique realizar cálculos redundantes.
  • Use uma cifra de fluxo, não uma cifra de bloco, para evitar a necessidade de preenchimento de texto simples.
  • Checksum os dados após a criptografia, em vez de criptografar a soma de verificação. Isto assegura que a quantidade de dados a serem checksummed não depende de o texto simples.
  • Use um algoritmo de criptografia autenticado, como AES-GCM , que combina soma de verificação e cifragem.

Curiosamente, a mitigação de última listadas acima (usar criptografia autenticado) já é suportado no TLS versão 1.2, que foi lançado há quase cinco anos .

Infelizmente, como os autores de fora do ponto Sorte Treze, TLS 1.2 é ainda "ainda não amplamente suportado em implementações."

De acordo com o SSL-Pulse projeto, menos de 12% dos sites inquiridos que em janeiro de 2013 apoiado TLS 1.2, e a maioria dos navegadores (IE no Windows 7 e 8, uma notável exceção) não incluí-lo, também.

Provavelmente hora de seguir em frente!

You might like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog