Site Meter Problemas com Encriptação no Formato ODF - Negócio de Risco - Site Home - TechNet Blogs

Negócio de Risco

Blog do Time de Segurança da Microsoft Brasil

Problemas com Encriptação no Formato ODF

Problemas com Encriptação no Formato ODF

  • Comments 3
  • Likes

No post anterior nós vimos porque agilidade criptográfica é tão importante para as aplicações atuais. Os algoritmos de criptografia tem um prazo de validade (que pode se encerrar abruptamente), e ao longo do ciclo de vida de uma aplicação é provável que os algoritmos que ela usa tenham que ser trocados até mais de uma vez.

Além disto, boa parte dos governos nacionais tem legislação obrigando o uso de determinados algoritmos pelos órgãos governamentais e em alguns casos por todo o país. Os americanos possuem os padrões FIPS, adotados como referência por boa parte dos governos ocidentais (incluindo a ICP-Brasil). A Federação Russa possui o GOST, a China o chip Hengzhi, etc. Estes requisitos exigem também que aplicações tenham agilidade em trocar a sua criptografia, tornando-a plugável. Por este motivos o Office 2007 Service Pack 2 introduziu agilidade criptográfica na encriptação de documentos OpenXML.

O Office 2007 Service Pack 2 também introduziu o suporte ao formato de documentos OpenDocument Format (ODF) 1.1, padronizado pela OASIS. Mas ao contrário do OpenXML, o ODF é um exemplo desastroso de “engessamento” criptográfico devido a uma limitação na especificação.

Especificar o uso de criptografia em um padrão internacional não é uma atividade trivial. Algumas especificações simplesmente adotam o padrão FIPS, já que é o mais usado no ocidente. Outras definem o padrão FIPS como sendo o mínimo necessário para conformidade, mas deixam espaço para implementação opcional de outros algoritmos. Outras especificações abstraem os algoritmos utilizados, deixando a escolha a cargo da implementação. Por fim, ainda temos as que preferem não incluir encriptação na especificação, como por exemplo o OpenXML.

O criadores do formato ODF – grupo do qual o Brasil não fez parte – preferiram no entanto não fazer igual e sim pior. Aqui está o trecho relevante da especificação ODF 1.1 (grifos meus):

The encryption process takes place in the following multiple stages:

1. A 20-byte SHA1 digest of the user entered password is created and passed to the package component.

2. The package component initializes a random number generator with the current time.

3. The random number generator is used to generate a random 8-byte initialization vector and 16-byte salt for each file.

4. This salt is used together with the 20-byte SHA1 digest of the password to derive a unique 128-bit key for each file. The algorithm used to derive the key is PBKDF2 using HMAC-SHA-1 (see [RFC2898]) with an iteration count of 1024.

5. The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in cipher-feedback (CFB) mode.

Existem dois problemas sérios aqui. Ao contrário do que você possa imaginar, eles não tem a ver com o uso de SHA1. Os ataques de colisão não se aplicam neste caso, e que do ponto de vista de segurança provavelmente seja até melhor usar SHA1 do que SHA2 porque ele é mais exigente em termos de recursos.

O primeiro problema é a escolha do algoritmo Blowfish. Não que existam problemas com o algoritmo em si (apesar do autor recomendar o uso do Twofish), e sim porque ele não faz parte da FIPS ou de qualquer outra norma nacional. O e-Ping  por exemplo recomenda o uso de 3DES ou AES - ambos algoritmos FIPS – para cifra, e qualquer implementação ODF está automaticamente fora da recomendação. Por que motivo o ODF não usa 3DES ou AES é um mistério.

Ninguém no entanto vai atacar o algoritmo simétrico de encriptação – o atacante vai atacar a senha, que é o elo mais fraco. E aqui está justamente o segundo e pior problema:o número de iterações para derivação da chave está limitado em somente 1024.

Estas iterações são feitas para tornar os ataque de força bruta mais lentos – o software usado para o ataque vai ter que fazer para cada tentativa este mesmo número de interações. No caso do Office 2007 o atacante precisa fazer por default 50.000 interações para cada tentativa de abrir um arquivo OpenXML. No Service Pack 2 o número aumentou para 100.000 operações, e o usuário tem a opção de configurá-lo para até 10 milhões. Ao aumentar o número de iterações você aumenta em razão direta o tempo necessário para fazer um ataque, e pode acompanhar a evolução do poder de processamento disponível para os atacantes.

No ODF no entanto número está limitado em 1024, número por si só já bastante baixo. O pior é que não existe possibilidade de este número ser aumentado sob pena de estar fora de conformidade com o padrão. Isto torna muito mais fácil para softwares de recuperação fazerem ataques de força bruta, e a situação só vai piorar a medida em que o poder de processamento continua aumentando.

Se serve de consolo, a encriptação do Adobe Acrobat 9 consegue ser ainda pior do que a do ODF. Mas eu não utilizaria nenhuma das duas, e o Office 2007 Service Pack 2 não implementa encriptação nestes formatos.

Comments
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment