Interlúdio no FISL12: Software Livre na Infra de Segurança do Governo

Hoje eu assisti uma palestra no FISL12 que me deu uma oportunidade tão boa de desfazer alguns mal-entendidos sobre certificação digital que vale até a pena sair da sequência que eu tinha originalmente planejado para a esta série de artigos.

A palestra se chamava "Software Livre na Infra-Estrutura de Segurança do Governo Brasileiro". Quando vi o título, pensei que "infra-estrutura" se referia às redes, roteamento, sistemas autônomos, etc., que conectam os vários setores do governo à Internet. Por isso, surpreendi-me um pouco quando vi o palestrante falar sobre certificados digitais e autoridades certificadoras. Títulos ambíguos e imprecisos são, infelizmente, uma tática muito comum para atrair audiência.

A palestra se revelou um exemplo clássico da ladainha do Governo sobre as "virtudes" da "certificação digital" – inclusive com todas as incorretudes técnicas tradicionais. Não pude resistir a dissecar algumas delas aqui.

Queria, antes de mais nada, deixar claro que não tenho absolutamente nada contra o palestrante. Muitíssimo pelo contrário, ele tem o meu mais profundo respeito e admiração – tratou meus comentários e colocações com total cortesia, objetividade e franqueza, respondendo minhas perguntas da melhor forma que sabia. Ficou claríssimo pra mim que nele não havia má fé; ele parecia genuinamente convicto de que tudo que dizia estava correto. Os erros que propalou têm origem muito antes dele; ele apenas repetiu a cartilha enviesada pela qual foi ensinado. Ele não tentou deliberadamente confundir o público; ele o fez apenas porque estava, ele mesmo, confuso.

Sem mais delongas, vamos às patinadas. No slide 7, por exemplo, diz-se que por causa da Medida Provisória 2200-2, documentos assinados digitalmente passam a ter "validade jurídica". Esse é um vício de linguagem dolorosamente comum, incentivado até pela própria redação obtusa da MP, que diz, logo no seu artigo primeiro:

Fica instituída a Infra-Estrutura de Chaves Públicas Brasileira - ICP-Brasil, para garantir a autenticidade, a integridade e a validade jurídica de documentos em forma eletrônica...

Acontece que, para os juristas, dizer que um documento (eletrônico ou não) tem validade jurídica é tecnicamente impreciso porque, segundo o art. 104 do Código Civil, o que tem "validade jurídica" são os "negócios jurídicos", e não os documentos que os espelham. Para uma discussão rigorosa sobre esse assunto, ainda que forma didática e acessível, recomendo a leitura deste clássico artigo do advogado Marcos da Costa.

Segundo esse entendimento, o que um documento tem é uma maior ou menor eficácia probante – a capacidade de servir como prova de um fato. A assinatura digital torna documentos eletrônicos mais "eficazes" nesse sentido, pois, quando corretamente usadas, dificultam sobremaneira adulterações.

Mas também não é verdade que documentos eletrônicos sem assinaturas digitais não tenham nenhuma eficácia probante. Com efeito, há ampla jurispurdência baseada em evidências digitais sem assinatura digital. Para citar apenas dentre várias situações clássicas, na justiça trabalhista há dezenas de casos em que demissões por justa causa foram mantidas porque empregados usavam emails da empresa para fins impróprios, como disseminar pornografia. Se emails não assinados não tivessem eficácia probante nenhuma, eles não seriam admissíveis como prova, o que faria o juiz provavelmente decidir a favor do empregado demitido. E há uma miríade de outros casos; por exemplo, recentemente saiu um artigo na Folha de São Paulo dando conta de que juizes estão usando posts nas redes sociais como provas em processos.

No slide 8, vê-se uma afirmação de que o uso de "certificados digitais" pode "garantir que o cidadão realmente é quem diz ser". Trata-se de outra forçada de barra clássica, pois os certificados digitais não garantem nada disso. Eu posso perfeitamente passar a minha chave privada para outrem que eu confie e esse outrem operar em meu nome. Quem conferir a assinatura digital não terá como distinguir se fui eu ou se foi outra pessoa que tivesse acesso à minha chave privada. O que realmente acontece é que, na condição de titular da chave (é o meu nome que consta no certificado), convenciona-se que eu seja o responsável pelos atos assinados por aquela chave. Se o cara para quem eu tiver passado a chave fizer algo que eu não aprove, será problema meu arcar com as consequências. E essa é uma "convenção" apoiada por uma redação muito pouco clara na legislação ("matéria controversa", como dizem os juristas), mas nem vou entrar aqui no mérito dessa questão, porque nos desviaria demais do assunto principal.

No mesmo slide, lê-se "Garantir que dados fornecidos pelo cidadão estão sendo lidos apenas pelo governo, e vice versa". Aqui o autor implicitamente mudou de contexto: agora ele fala sobre sigilo de comunicações. A afirmação pode até ser considerada verdadeira, se nos limitarmos a um contexto bem estreito: o sigilo se estende apenas ao canal de comunicação (seja ele HTTPS, email cifrado, ou o que for). Mas, saindo desse contexto, a coisa muda de figura: a partir do momento que os dados são decifrados e, digamos, inseridos em um banco de dados (e na ausência de outros mecanismos de proteção), os dados podem "vazar", como já aconteceu várias vezes no passado. Os americanos usavam cifragem por certificado digital na Wiki da comunidade de inteligência e mesmo assim dados secretos vazaram para a Wikileaks.

A apresentação prosseguiu descrevendo o Projeto João de Barro, uma iniciativa do governo para sair de uma cilada que eles mesmos criaram: quando começaram com a ICP-BR, contrataram para AC Raiz uma solução importada dos EUA e totalmente fechada, com um contrato quase draconiano que vedava ao Governo Brasileiro uma série de coisas que eles queriam fazer; e, entre as poucas coisas permitidas, havia certos upgrades que custavam fábulas de doer até nos gestores acostumados com cifras milionárias.

A idéia do projeto João de Barro era reimplementar, com tecnologia e capital humano nacionais, seu próprio software de Autoridade Certificadora para emitir certificados digitais. Em tese, a idéia parece ótima, mas é nos detalhes que a coisa desanda.

Primeiro, como mostrado no slide 21, eles usaram várias bibliotecas criptográficas de código aberto, mas que foram em sua quase totalidade por desenvolvedores estrangeiros. À primeira vista, não parece algo fora do normal – de fato, uma das grandes virtudes do modelo de desenvolvimento aberto é justamente o reaproveitamento do trabalho já feito por outrem. Mas, nesse caso, fica difícil dizer que o software é totalmente nacional; na realidade, a grande maioria das funcionalidades críticas não é nacional. O que foi feito por técnicos brasileiros foi só a "pontinha do iceberg." Será que os técnicos brasileiros auditaram todo o resto do código de todas as bibliotecas que se basearam para ter certeza de que não há algo que fira nossos interesses nacionais?

Segundo, no final da palestra, perguntei sob qual licença o software seria disponibilizado e onde poderíamos baixá-lo. O palestrante disse que não fazia mais parte do projeto mas que tinha ouvido falar que ele seria eventualmente aprontado para ser disponibilizado sob a GPL (qual versão? v2? v3?) após o registro de marca no INPI. De fato, isso foi prometido em 2009, mas aparentemente ele ainda não consta na Lista de Softwares do Portal Software Público. Se de repente o software já foi disponibilizado em algum outro lugar e você, leitor, sabe onde, por favor me conte!

Na palestra, não pude deixar de comentar que, se não se sabe a licença e não há URL para se baixar o código, então não se trata, pelo menos por enquanto, de software livre. Pode até ser um software "nacional", ou pode ser "livre" no sentido que estamos "livres" de um fornecedor estrangeiro. Mas não é um "software livre" no sentido próprio do termo. Pode até vir a se tornar se e quando o código for disponibilizado para o público sob uma licença de código aberto, mas, por enquanto, ainda não é.

Por isso, achei que o título da palestra, que começa com "software livre", ficou, no mínimo, inapropriado, pois sugere uma coisa que o software ainda não é; e "Infra-estrutura de Segurança do Governo" é muito mais do que apenas as Autoridades Certificadoras da ICP-BR.

E há muito mais em um software genuinamente livre do que sua mera disponibilização sob uma licença livre. Por exemplo, qual o roadmap para o futuro desse software? Haverá um repositório (subversion, git, ou algo que o valha) público onde a comunidade de desenvolvedores possa enviar patches e contribuições? Qual o processo para criação de versões ("releases") futuros? Como serão tratadas vulnerabilidades de segurança e upgrades emergenciais?

Comentários Finais

Quero deixar claro que não sou contra a "certificação digital". Pelo contrário: sou grande fã dessa tecnologia. Lá na Tempest nós a usamos diariamente e pra um monte de coisas. Quando corretamente implementada, ela pode dar garantias que nenhuma outra tecnologia que eu conheça pode dar; e quando bem aplicada a projetos governamentais, pode redundar em grandes benefícios sociais.

Mas, como eu disse em artigos anteriores, essa é uma área em que ainda há muitas confusões – inclusive na cabeça de muitos de seus praticantes. O que tentei neste artigo e estou tentando ao longo desta série é desfazê-las, tentando atingir a clareza necessária para que o leitor possa apreciar por si próprio esses benefícios de que tanto falo.

Partes anteriores

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.