torradeira.net

Mas, por que coloquei ‘bug” entre aspas? Esta palavra inglesa aplica-se comumente aos erros lógicos que os programadores cometem ao conceber o código de seu software. Bem, seres humanos não são perfeitos. Mas o que aconteceu com o PGP não foi exatamente um erro desse tipo.

Vejamos. O erro nasceu da necessidade que órgãos de segurança têm de facilitarem o key escrow, de patrocinarem a tutelas de chaves de outrem. Ou seja: alguém deve ter a tutela das chaves dos cidadãos, no caso deles querem fazer coisas indesejáveis. Todos sabemos que a criptosistemas de chave-pública geram um par de chaves: um privado para desencriptar ou decifrar, e uma chave pública para encriptar ou cifrar. Se desejo mandar uma mensagem para o “josé da Silva”, uso sua chave pública para cifrar a mensagem; ele e, somente ele, pode ler tal mensagem, já que possui a chave privada correspondente. Esta é a lógica já sabida dos sistemas assimétricos… Porém, a NAI comprometeu-se com a Key Recovery Alliance (KRA), o que fez com que alteram-se o PGP, admitindo uma característica bastante questionável: o ADK, additional decryption key, ou seja, uma espécie de “‘recuperação de dados” por terceiros, às vezes também chamada de Corporate Message Recovery (CMR). Assim, quando o usuário cria seu par de chaves, pode pôr uma chave adicional, o ADK ao seu certificado PGP (onde reside o seu nome, data, etc.). Assim quando o remetente encripta uma mensagem para alguém também a encripta para o ADK e o seu proprietário. No entanto, uma falha de implementação do PGP permite ADKs não assinados, e que foram de forma maliciosa acrescidos ao certificado, serem usados para encriptar dados (Ver CA-2000-18, Overview). Desta forma, os dados criptografados com o PGP que está usando um certificado maliciosamente alterado gerará dados cifrados sujeitos a seguinte vulnerabilidade segundo o CERT: atacantes que forem capazes de modificar o certificado pública de uma vítima, serão capazes de recuperar o texto puro (plaintext) de qualquer texto cifrado enviado pela vítima que usou o certificado alterado (idem, II. Impact). Para que alguém possa explorar esta seríssima vulnerabilidade, é preciso:

* o remetente deve estar usando um versão vulnerável do PGP (5.5.x a 6.5.3)
* o remetente deve encriptar dados com um certificando alterado pelo atacante
* o remetente deve conhecer reconhecer um aviso indicando que um ADK está associado ao certificado
* o remetente possui a chave para o falso ADK já acrescido ao seu chaveiro digital
* o falso ADK dever ser assinado por uma CA
* o atacante deve ser capaz de obter o texto que foi cifrado da vítima

A turma da antiga dizia: o inferno está calçado às vezes com boas intenções. Sim, “boas intenções” – quando Jon Callas justificou a inclusão do ADK nas versões do PGP, dizia ela que era a única forma de fugir de uma desagradável regulamentação governamental da criptografia. A idéia seria que o empregado de uma empresa, por exemplo, quando enviasse um relatório encriptado para a empresa X, seria também criptografado para o seu venerado chefe, o big boss, ou o Grande Irmão, se desejarmos ainda olhar por outra ótica. O especialista em criptografia Bruce Schneier (http://www.counterpane.com) sem dúvida tocou na ferida:

“Uma idéia estúpida, mas que é o tipo de coisa que o key escrow pede.”

Este evento mostra de forma contundente que um política de segurança não deve ser confundida com vigilância. A confirmação esta chegando neste caso específico: todo vez que se tentar pôr facilidades para “bisbilhotar”, os criptosistemas terão seu desenho comprometido, e buracos como esse irão brotar feito água.

Os prejuízos no episódio são inquestionáveis. Para a opinião pública, mais imediatista, é tecnologia OpenPGP que sairá mais arranhada. Neste instante, alguém deve estar dizendo: “não falei?! PGP, GnuPG, criptografia, nada disso adianta!”. Não que haja alguma tecnologia perfeita, longe disso, mas o equívoco deste evento ADK, foi muito mais ético-político do que técnico, – ainda que tenha inexoravelmente implicações técnicas.

A falha de segurança do PGP causada pela introdução dos ADKs e sua possível e indesejada manipulação, foi descoberta pelo alemão Ralf Senderek, e foi por ele mesmo amplamente documentada no artigo “Key-experiments. How PGP deals with manipulated keys. An experimental approach”. Aí você terá todo o material técnico a respeito do bug. É sem dúvida uma das exposições mais brilhante que tive a oportunidade de ler. Não só do ponto de vista da Ciência da Computação ou da Criptografia. Mas da Ciência como um todo; é um texto com um enorme poder analítico e tão bem desenvolvido, tão bem documentado que sua aceitação foi imediata, – não deixou margens às controvérsias, que são tão comuns neste âmbito. Seguiu-se a ele, o inevitável, o documento da CERT, como de hábito sacramentando o problema, e dando os passos a seguir.

Nosso software livre, o GnuPG, é uma implementação completa do padrão OpenPGP (RFC 2440), e pode descriptografar e verificar mensagens do PGP versão 5.x. Quando nasceu tinha que ser compatível com o padrão PGP. Ele não suporta ADKs , mas pode importar chaves com ADK por conta de sua compreensível compatibilidade. Portanto, talvez seja afetado indiretamente… Segundo o CERT em seu comunicado os sistemas afetados diretamente são o PGP versões 5.5.x até 6.5.3.

Já Senderek em seu artigo mostrou que o GnuPG importou todas as chaves que o analista criou de forma experimental, com exceção de uma chave RSA versão 4. E concluiu, por outro lado, que qualquer chave DSS/DH pode ser manipulada para constar novos ADKs sem o consentimento do usuário ou seu conhecimento.

Não houve ainda um comunicado oficial da equipe de desenvolvimento do GnuPG. Mas os threads já começam a explodir na lista de correio de nosso programa. Werner Koch, o principal desenvolverdor do software, por email me relatou que já recebeu milhares de emails sobre o problema! Eu também, confesso… O assunto é polêmico e há sérias controvérsias a respeito. Acho que o usuário do GnuPG deve se precaver, pois em minha opinião pessoal está indiretamente envolvido. Para Koch: “Até quinta-feira não conhecia o formato destes pacotes ARR (Additional Recipient Request), – como eles foram chamados numa proposta rejeitada da NAI para o OpenPGP. Sexta-feira mudei a forma como o GnuPG lista tais pacotes usando ‘–list-packet’ para incluir toda a informação disponível …”, e “GnuPG não usa aquela requisição Big Brother, exceto para objetivos de inspeção de pacotes.”

Desta forma, podemos usar o próprio software GnuPG, que possui uma ferramenta de análise, para investigar certificados com ADKs , e eliminá-los, usando a flag “–list-packet”. Certificados com ADKs legítimos têm a seguinte saída em sua tela:

hashed subpkt 10 len 23 (additional recipient request)

Enquanto certificados manipulados maliciosamente eliminam a palavra ‘hashed’:

subpkt 10 len 23 (additional recipient request)

Participo sobretudo de uma conclusão de Senderek: “quando penso na mudança futura do formato de dados do PGP, dever-se-ia achar uma forma de integrar certificados X-509 num único e seguro formato para SMIME e PGP conjuntamente”. O tópico é muito extenso para aqui ser desenvolvido. Mas nunca entendi a contradição que especialistas colocavam em ambas as tecnologias: o padrão aberto PGP e o PKI. Alguns diziam: “PGP? Padrão superado… A moderna Internet precisará mais do que isso!”; já outros asseveravam: “PKI e certificação digital? Mais uma ilusão, posso confiar em quem tem a posse de minha chave privada?!”.

Como sempre, e como deve ser, as tecnologias devem se complementar a favor do cidadão.