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.

Codificadores Kim Dotcom de hackers em criptografia Mega mesmo enquanto falamos - em verdadeiro "beta perpétuo" estilo

Filed Under: Featured, Privacy

Kim Dotcom novo empreendimento de armazenamento de arquivos de compartilhamento, Mega, quer se proteger das acusações de não tomar medidas contra a pirataria.

Ele faz isso usando criptografia para garantir que ele não vê, e de fato não pode dizer, o que você fez upload.

Que proporciona privacidade para você (outras pessoas, incluindo pessoal próprio Mega, não podem espionar seus arquivos) e negação de Mega (outras pessoas, incluindo Mega próprio pessoal, não pode sequer dizer que seus arquivos podem ser).

Mas para cumprir essa promessa, você tem que ter o direito de criptografia.

Como se explicou ontem , os primeiros indícios eram de que os codificadores de Mega não tivesse feito isso: nós escreveu sobre problemas com a entropia (aleatoriedade), a deduplicação eo uso de dados mal escolhidos em sign-up Mega-mails, sem necessidade de fazer dicionário de senhas possíveis ataques.

Pesquisadores do grupo de hackers fail0verflow posteriormente escreveu-se ainda um outro erro de criptografia: o uso de uma função de hash com defeito para autenticar o código JavaScript que faz o trabalho de serviço todo.

Vou tentar explicar brevemente.

Você esperaria um site seguro para entregar todo o seu conteúdo via HTTPS, inclusive (ou talvez especialmente) o código JavaScript que aciona a criptografia.

Mega usa HTTPS, mas para salvar o dinheiro que serve a maior parte de seu JavaScript de "baratos" servidores em redes de conteúdo distribuídas de entrega que usam 1024-bit chaves RSA.

→ chaves RSA mais curtos exigem menos poder de CPU, de modo a obter mais desempenho para um esforço determinado. Mas redes distribuídas significa mais servidores e exigir a distribuição de chaves widepsread, assim você aumenta o risco de um compromisso.

Para aumentar a segurança geral, Mega também serve-se, a partir de servidores centralizados que usam chaves de 2048 bits-, uma lista de hashes criptográficos para o conteúdo hospedado nos "assentos baratos". Esses servidores centralizados também servir-se o código de criptografia necessária para verificar os hashes.

Isso significa que você teria que comprometer os servidores 2048-bits protegidas e os servidores 1024-bits protegidas a fim de servir scripts não autorizados a partir da parte inferior de segurança da rede.

Lo! Uma maneira elegante de ter seu bolo de segurança, mas pagam menos para entregá-lo.

Ontem, no entanto, fail0verflow documentado o código de criptografia servido a partir dos servidores de segurança maior.

O código de hash usado para autenticar o JavaScript vindo de menor segurança de servidores era a função h () ​​abaixo:

<br /> function h(s) <br /> { <br /> var a = [0,0,0,0]; <br /> var aes = new sjcl.cipher.aes([111111,222222,333333,444444]); <br /> s += Array(16).join('X');</span> </p> <p> for (var i = s.length &amp; -16; i -;) { <br /> um [(i &gt;&gt; 2) &amp; 3] ^ = s.charCodeAt (i) &lt;&lt; ((7-i &amp; 3) &lt;&lt; 3); <br /> se a = aes.encrypt (a) ((i &amp; 15)!); <br /> } <br /> retornar um; <br /> } <br /> [Sourcecode /] </p><p> Não se preocupe se você não fala JavaScript. Tudo o que você precisa saber é isto: </p><ul><li style='font-size:95%;'> A função <tt>h ()</tt> ​​é um algoritmo conhecido como um keyed <a href="http://en.wikipedia.org/wiki/CBC-MAC" rel="nofollow">CBC-MAC</a> . </li><li style='font-size:95%;'> CBC-MAC não são seguros, a menos que a chave é segura. Você pode criar uma falsificação se você sabe a chave. </li><li style='font-size:95%;'> A chave usada em <tt>h ()</tt> ​​é conectado e inseguro. É aí: a matriz JavaScript <tt>[111111,222222,333333,444444].</tt> </li></ul><p> Ouch. Você não pode usar CBC-MAC assim. Você precisa usar um hash criptográfico adequado vez. </p><p> <a href="http://nakedsecurity.sophos.com/2012/10/04/sha-3-hash-competition-concludes-keccak/">SHA-3</a> ou SHA-256 provavelmente seria uma boa idéia. Como <tt>fail0verflow</tt> apontou, SHA-1 seria OK e mesmo MD5 seria melhor do que o código acima, apesar da fraqueza do MD5 criptográfico conhecido. </p><p> O forro de prata, é claro, é que os serviços de nuvem pode emitir atualizações quase que instantaneamente. Apenas servir o novo código da próxima vez que um usuário visita seu site. </p><p> (Sim, você sidestep de controle de mudanças tradicional, porque o usuário não consegue escolher se ou quando a atualização. Mas você também evitar lentidão de controle de mudanças, porque o usuário não consegue escolher se ou quando a atualização.) </p><p> E, com certeza, esta tarde, Mega tinha seguido o conselho <tt>fail0verflow</tt> 's. </p><p> O 2048-bit protegido por código de criptografia que protege a 1024 bits de criptografia protegida por código foi atualizado para: </p><p> <span class="notranslate">1 <br /> function sha256(d) <br /> { <br /> h = new sjcl.hash.sha256(); <br /> for (var i = 0; i &lt; d.length; i += 131072) <br /> h = h.update(d.substr(i,131072)); <br /> return h.finalize(); <br /> } <br />

Agora, SHA-256 é utilizada em vez de CBC-MAC com uma chave de hard-wired.

Bom trabalho por codificadores Mega para obter as correções rapidamente. Mas se você está confiando em mega para sua própria privacidade, você provavelmente vai querer se perguntar por que não ter o básico da sua aplicação de criptografia bem na frente.

Commenters em nosso artigo anterior ofereceu a sugestão razoável que a necessidade de Mega criptográfico principal é a auto-preservação: assegurar a sua negação própria, a fim de evitar retirado junto com os dados de seus usuários. Sua privacidade e segurança vem em segundo lugar.

Há duas soluções muito simples, se isso é verdade. Você pode escolher um ou ambos: usar um provedor diferente, ou criptografar os dados a si mesmo antes de você deixar mega criptografá-la.

Na verdade, por que não criptografar seus dados mesmo, sempre e de qualquer maneira? É seus dados, depois de tudo.

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