Security WatchO BitLocker e a complexidade da confiança

Justin Troutman

Windows Vista. Eu jamais escrevi essas duas palavras em um artigo, e é por isso que escrever esta coluna me faz sentir como uma criança de cinco anos com um cheque em branco entrando em uma loja de brinquedos. Há tantos recursos para abordar, tanto espaço que vale a pena explorar e tantos caminhos a serem tomados em uma abordagem.

Há pouco tempo, eu estava lendo o blog do guru da segurança Bruce Schneier e me deparei com uma entrada sobre algo que era totalmente novo para mim naquele momento – BitLocker™. Depreendi rapidamente que ele tinha o objetivo de fornecer funcionalidade criptográfica no Windows Vista® – tive a sensação imediata de "Ah não! O Windows Vista está criptografando? Isso não deve ser nada bom. E, mesmo que faça um trabalho decente, deve haver uma porta dos fundos em algum lugar".

Há alguns argumentos históricos (válidos ou não) relacionados aos motivos pelos quais alguém pode hesitar em confiar nos recursos de segurança integrados do Windows®. Mas não é por isso que estou escrevendo esta coluna. Na verdade, eu gostaria de relatar um caso detalhando por que eu acredito haver boas razões para dar uma chance ao BitLocker. Eu também quero apostar algumas moedas no tipo de filosofia que garante a vitalidade do software e do hardware de criptografia.

Mas não se confunda: não estou propondo que o BitLocker seja a solução completa para a segurança como um todo – o BitLocker é apenas mais uma das muitas peças que formam o quebra-cabeça da segurança. A sua meta é oferecer resiliência em determinados modelos de ameaça.

Em especial, o BitLocker volta suas atenções para o laptop perdido (ou roubado). Os trabalhadores móveis estão sempre transportando todos os tipos de informações confidenciais por todos os lugares – trens e aviões, restaurantes e hotéis, em casa e filiais. E eles estão levando essas informações em laptops e em outros dispositivos móveis que normalmente não têm nenhuma segurança real, o que deixa os dados que eles contêm extremamente vulneráveis. E o que acontece com esses dados quando um dos usuários deixa um laptop em algum lugar?

Não é possível eliminar a sordidez da natureza humana. Felizmente, você pode limitar o estrago que isso poderia causar. O custo para que uma empresa substitua um laptop é mínimo se comparado ao custo de lidar com dados confidenciais que tenham sido comprometidos. É essa a segurança que o BitLocker pretende oferecer.

Atravessando os créditos

Estou abordando o BitLocker aqui de uma perspectiva interessante. Veja, eu não tentei nada ainda. Eu sei o que você deve estar pensando: como um cara que sequer usou o BitLocker pode ter uma opinião a respeito e encontrar alguma coisa útil para escrever um artigo? Tenha paciência comigo. O que eu realmente quero abordar é a criptografia vista de um nível mais alto e as filosofias de design essenciais para que haja uma solução bem-sucedida.

Tudo isso começou com o que li no blog de Bruce Schneier. Digamos que você queira ver um novo filme nos cinemas. Com base no trailer e nos atores principais do elenco, você fez algumas suposições sobre a obra. Para falar a verdade, um bom elenco não significa um bom filme. Mas o elenco pode dizer muito a respeito do filme e o que você pode esperar dele. As estrelas são Chris Rock e Ben Stiller? Ou o filme é com Kate Winslet e Johnny Depp?

Da mesma forma, quando vi que um guru da segurança respeitado internacionalmente estava abordando o BitLocker em seu blog, eu fiz algumas suposições. Primeiro, eu pensei que essa nova tecnologia devia ser boa o bastante para merecer uma menção honrosa ou tão ruim que merecia receber destaque publicamente. E, para a minha surpresa, o veredicto final de Bruce Schneier era positivo.

Uma frase em especial me chamou a atenção em seu texto: "Não há nenhuma porta aberta para a polícia". A frase é de forte impacto. Ela foi dita com muita confiança e incluía um link para o blog da equipe da Microsoft® System Integrity. Segui o link e encontrei uma postagem de Niels Ferguson, desenvolvedor especializado em segurança na Microsoft, denunciando a existência de rumores de que a Microsoft tinha intencionalmente incluído portas abertas no BitLocker para fins legais. Ferguson dizia que portas abertas são inaceitáveis e que ele não participaria de nenhuma parte de um projeto que desse suporte a elas (Ele também explicou que, mesmo que a Microsoft fosse forçada a incluir uma porta aberta por lei, a empresa anunciaria a porta publicamente ou retiraria integralmente o recurso).

O nome na postagem – Niels Ferguson – explica a confiança de Schneier e também a minha. Ferguson é alguém que sabe o que está falando, e ele tem um histórico que garante que você pode confiar no que ele diz. Bruce Schneier e Niels Ferguson são co-autores de Practical Cryptography (Criptografia Prática), um livro de grande influência sobre a aplicação da boa criptografia, com uma abordagem simples, correta e segura) e co-designers da codificação de bloco, Twofish – uma rede Feistel de 128 bits que ganhou sua estrutura de análise criptográfica como finalista do processo de seleção AES (Advanced Encryption Standard).

É claro que ter um criptógrafo experiente em um projeto não é uma garantia de segurança do produto final. Às vezes, mesmo os mestres dessa arte podem cometer um ou dois erros. Mas independentemente de como o BitLocker evoluirá com o tempo, é possível pelo menos ter a certeza de que estratégias de design consistentes fizeram parte de sua criação.

Falando em erros, há tentativas legítimas feitas por desenvolvedores sem a mínima noção criptográfica e tentativas de má-fé feitas por aqueles mais preocupados apenas com o lançamento de um produto. Ambos os esforços, independentemente de suas intenções, são falhas de segurança na criação. No entanto, nenhuma parece ser o caso em relação ao BitLocker. Contar com pelo menos um criptógrafo competente envolvido e amplos recursos que apóiam essa iniciativa é um bom sinal.

Uma palavra sobre segurança

Não faz muito tempo que Phil Zimmerman, criador da criptografia PGP, compartilhou algumas regras gerais comigo. Se, em algum dia, fosse publicado o "Credo da segurança para desenvolvedores", suas orientações certamente figurariam no topo da lista. Embora suas opiniões não sejam específicas sobre o BitLocker, as filosofias de design que elas promovem podem ser aplicadas a praticamente qualquer solução criptográfica. Você talvez as ache óbvias e excessivamente zelosas. Mas, dado o estado atual da segurança, vale a pena explicá-las detalhadamente.

Ao projetar uma infra-estrutura criptográfica, o desenvolvedor deve ser simples, correto e seguro. Embora sejam inevitáveis, os erros não devem ser aceitos como algo natural e simplesmente ignorados. O desenvolvedor deve ser um entusiasta implacável de nada menos do que o mais meticuloso perfeccionismo. Como diz Zimmerman: "crie o projeto como se cometer um erro fosse custar a vida de alguém". Acha isso um exagero? Durante a Conferência Anual de Aplicativos de Segurança para Computador em 2005, o criptógrafo da NSA Brian Snow (já aposentado) disse: "eu queria funções e garantias em um dispositivo de segurança. Nós não fizemos o teste beta no cliente. Se o meu produto falhasse, alguém poderia morrer". Portanto, lembre-se: erros podem custar muito mais do que dinheiro.

Os usuários querem garantia. Obter – e manter – a confiança dos usuários é essencial. Zimmerman deixa isso bem claro quando diz: "Ganhe a confiança dos usuários. Uma vez colocado esse fardo em seus ombros, você jamais pode se desfazer dele". Ao fazer isso, a empresa preserva a garantia do usuário e sua própria reputação de segurança. Uma vez perdidas, elas podem ser irrecuperáveis.

Essas são as perspectivas que eu espero que a Microsoft tenha mantido em mente ao projetar o BitLocker (ou qualquer um dos demais produtos da empresa em relação a isso). Dito isso, quero explicar por que estou otimista que a Microsoft tenha efetivamente feito isso direito e ofereceu uma parte da tecnologia de criptografia que deve ser levada a sério.

Um pobre homem e seu elefante

Fundamentalmente, o BitLocker é a forma como o Windows Vista (mais especificamente, as edições Enterprise e Ultimate) criptografa todos os dados de volume do sistema. Isso pode parecer um aplicativo bem simples, mas considere as restrições. Como o BitLocker criptografa dados por nível de setor e o texto cifrado não pode exceder o tamanho do texto não criptografado, não há espaço para mais nada – como, por exemplo, nonce (um número ou cadeia de caracteres usada apenas uma vez na autenticação), IV (vetor de inicialização) ou MAC (Message Authentication Code). Eu presumo que essas restrições e as condições que elas impõem sejam semelhantes, embora também saiba que a autenticação de mensagens seria abordada de alguma forma.

O BitLocker conta com o que normalmente chamamos de autenticação do pobre homem. O comprometimento não é tão conservador quanto você normalmente gostaria que fosse, uma vez que ele pressupõe que o texto cifrado manipulado não resulte em um texto não criptografado significativo. Em outras palavras, caso seja manipulado, o texto cifrado deve, por exemplo, fazer com que o sistema falhe e não permita que um adversário realize alguma função.

A equipe da Microsoft responsável pelo BitLocker sabia que um bloco cifrado totalmente novo exigiria mais tempo para ser analisado do que o aceitável, mas os projetos existentes ainda não foram bem analisados o suficiente ou não eram suficientes o bastante. Portanto, para a criptografia, a Microsoft optou pelo AES no modo CBC (Cipher Block Chaining), ao qual eu irei me referir como AES-CBC. Isso é invisível sob o modelo de ataque de texto não criptografado escolhido (abreviado como IND-CPA), embora não mantenha a integridade. E como não há espaço para MAC, e CBC é um modo de confidencialidade, não há nenhuma preservação da integridade. Essa é a deixa para o elefante.

O novo componente Elefante tem dois difusores, criados para processar autenticações melhores do pobre homem do que AES-CBC simples (no entanto, eu devo fazer uma observação de que há uma opção para executar AES-CBC sem Elefante para os que precisam obedecer políticas rígidas de conformidade em relação aos padrões). Embora nem sempre seja ideal, a autenticação do pobre homem é a solução mais apropriada dadas essas restrições, e Elefante tem o objetivo de conseguir o melhor dessa situação. Como tudo isso funciona exatamente?

A Figura 1 ilustra o fluxo da compreensão. Quando ocorre a criptografia, o texto não criptografado é combinado, por meio de XOR, a uma chave de setor. Em seguida, o texto passa por dois difusores sem chave. Lá, o texto é criptografado usando AES-CBC. A chave de setor e AES-CBC exigem o material da chave e, por isso, são criptografados – de forma independente. Esse método simplifica a formalização de uma prova para reduzir a segurança de AES-CBC e da construção de Elefante do AES-CBC. Elefante é um novo primitivo, e novos primitivos podem ser encarados com relutância até serem analisados rigorosamente. Mas essa abordagem equilibra a escala, uma vez que o BitLocker pode mostrar que AES-CBC com Elefante não é mais de ser atacado do que o AES-CBC sozinho.

Figura 1** Autenticação do pobre homem com Elefante **

A chave de setor e os componentes de AES-CBC recebem 256 bits do material da chave, o que cria uma chave com 512 bits. Por padrão, porém, esses componentes usam apenas 128 bits do material de chave cada, o que significa que parte do material de chave não é usada. A razão disso é simplesmente porque é mais fácil ignorar os bits desnecessários do que alterar a infra-estrutura de gerenciamento da chave, já que as chaves podem variar de tamanho.

O tamanho do bloco pode ser uma combinação com dois, dentro da faixa entre 512 e 8192 bytes. Para garantir que todas as alterações feitas no texto cifrado resultem na modificação aleatória de todo o texto não criptografado de um setor, o bloco cifrado foi projetado para se comportar com um tamanho de bloco variável. Além disso, caso ele se comporte como um bloco cifrado ajustável (conforme descrição de Liskov, Rivest e Wagner), com o algoritmo mudando um pouco de setor para setor, um adversário não consegue mover um texto cifrado de um setor para outro.

Só o tempo dirá

Especular sobre a segurança criptográfica do BitLocker deixa de lado o aspecto mais importante. Para o BitLocker, ser seguro não é necessariamente suficiente para que ele faça seu trabalho. Isso porque ele não é uma solução em si – é apenas mais um dos muitos suplementos do Windows Vista. A Microsoft diz que o BitLocker está totalmente integrado ao Windows Vista. Mas, se há essa total integração com o sistema operacional, não é plausível que a falha de outro componente pudesse, por sua vez, causar uma falha ou comprometer o BitLocker?

Particularmente, eu acredito na modularidade e na falha isolada. A plena integração sem modularidade leva à complexidade. Tudo bem, talvez esse não seja o caso entre o Windows Vista e o BitLocker, mas apenas o tempo – e uma ampla análise – dirão se isso está certo.

E o que eu acho do BitLocker? Tiro o meu chapéu para a equipe da Microsoft System Integrity pela confiança depositada em criptógrafos confiáveis e verdadeiros, que fizeram as coisas como deveriam. É claro que esse recurso foi projetado para criptografia, e não para uma campanha de marketing. Então a minha resposta para essa pergunta é que o BitLocker deve ser levado a sério. Observe que isso deixa de lado o veredicto se a segurança é consistente. Mais uma vez, só o tempo e a avaliação do mundo real dirão. Muitos primitivos criptográficos e protocolos foram quebrados. Mas, na pior das hipóteses, a equipe da Microsoft System Integrity nos ofereceu informações e plataformas a partir das quais podemos criar soluções ainda melhores.

Justin Troutman é criptógrafo experiente e aluno universitário de matemática. Sua atenção está voltada principalmente para a criptografia simétrica. Ele também é fundador da Extorque, empresa especializada em pesquisa e consultoria em criptografia.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..