entrevista ao Diario de Pernambuco

primeiro email

Luiz Pinto: No seu artigo entitulado "O silêncio que produz ruídos" o senhor trata do problema da distribuição das chaves. E afirma que 'qualquer um que gerar um par de chaves pode assinar sua própria chave pública com sua chave privada". A dúvida é: esse par de chaves a que o senhor se refere é o registrado na ICP BR? Se sim, qual o objetivo de quem assina a chave pública com a chave privada?

Pedro Rezende: Nesta primeira pergunta estão embutidas várias questões que se prendem a pontas soltas do que estamos tratando. Antes de respondê-la, vou encadear uma abordagem preliminar a estas questões embutidas, para benefício da nossa compreensão mútua e a do leitor.

O que se registra na ICP-B são certificadoras. Certificadoras atuam como prestadoras de serviços. Estes serviços são os de assinar certificados de chave pública de terceiros, bem como o de registrar o histórico da validade e titulação destas chaves. O registro de uma certificadora na ICP-B se destina, na prática, a diferenciar o serviço prestado, no sentido que lhe dá o parágrafo primeiro do artigo 10 da MP2200-2, que diz:

"As declarações constantes dos documentos em forma eletrônica produzidos com a utilização de processo de certificação disponibilizado pela ICP-Brasil presumem-se verdadeiros em relação aos signatários, na forma do art. 131 da Lei no 3.071, de 1o de janeiro de 1916 - Código Civil."

Entretanto, o viés Orwelliano do texto da MP2200-2 confunde enormemente a compreensão leiga sobre o objeto e alcance da lei, e o que realmente significa para o cidadão comum esta diferenciação. Veja como a lei começa:

"Art. 1o 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, das aplicações de suporte e das aplicações habilitadas que utilizem certificados digitais, bem como a realização de transações eletrônicas seguras."

Ora, quem pode garantir a autenticidade e a integridade de documentos em forma eletrônica são sistemas criptográficos apropriados (os de pares de chaves assimétricas - púbilca e privada) operando em condições adequadas, e não a norma jurídica. Em linguagem técnica, o uso do termo "Infra Estrutura de Chaves Públicas" se refere a um conjunto desses sistemas e dos meios adequados para sua operação. Tais sistemas são propriedade de certas formas matemáticas do mundo platônico, de conhecimento público há mais de 24 anos e de domínio público há mais de dois. São sistemas de manipulação de símbolos que obedecem a certas leis semiológicas, mensuráveis enquanto os sistemas operam em condições adequadas. Tendo sido já descobertas e não sendo criação ou propriedade intelectual ou material do legislador, ou de quem quer que seja, não estão em seu poder para serem por ele instituídos no sistema jurídico brasileiro. Estão na bagagem cultural da sociedade, na forma como esta os disponha. O que caberia a uma norma jurídica instituir, sobre uma tal infra estrutura, seria, apenas, a regulação dos efeitos jurídicos do uso de tais sistemas sob condições adequadas. A norma jurídica não pode, por si só, garantir integridade e autenticidade digital alguma. São leis semiológicas que garantem. Da mesma forma que não faz sentido uma norma jurídica decretar ou revogar uma lei física, como a lei da gravidade, a lei da relatividade ou as leis da termodinâmica, estas últimas as que mais se assemelham a leis semiológicas.

A validade jurídica de documentos eletrônicos -- cuja instituição por lei especial alguns juristas dizem ser de necessidade discutível, e a presunção de veracidade quanto à identificação de seus signatários -- cujo efeito jurídico é o cerne da MP2200-2, deveriam ser instituídas através de vínculos entre a produção e o processamento dos documentos eletrônicos, por um lado, e as condições adequadas ao apropriado funcionamento de tais sistemas, por outro, se a norma instituinte estiver buscando preservar a segurança jurídica buscada pelo Código Civil. E não instituídas pela intermediação de serviços credenciados capazes de induzir apenas uma parte dessas condições, como fazem a MP2200-2 e as normas dela até hoje derivadas. Como diz, e gosta de repetir incessantemente um dos diretores da maior empresa de serviços de segurança computacional do Brasil, Fernando Nery, a segurança é uma corrente tão forte quanto seu elo mais fraco. Esta máxima certamente é válida para qualquer tipo de segurança, seja física, computacional, jurídica ou de qualquer natureza.

Assim, para compreendermos a MP2200-2, temos que nos ater aos verdadeiros sujeito e objeto da sua ação instituidora. O que ela pode estar instituindo é um vínculo entre, por um lado, a validade jurídica e a presunção de autoria de documentos eletrônicos, e por outro, a intermediação de serviços credenciados capazes de constituir um dos elos da corrente de procedimentos necessários à operação adequada desses sistemas. Ao passo que esses sistemas só são capazes de garantir, através do processo de assinatura digital, a autenticidade e integridade desses documentos se operarem sob condições completamente adequadas. Mas o desequilíbrio da MP2200-2 não para por aí. Ela se torna Orwelliana na medida em que ignora outros elos, ao mesmo tempo em que institui poderes ao orgão controlador deste vínculo para subverter a capacidade dos signatários buscarem, por si mesmos, o controle da robustez dessa corrente, se obrigados a expressarem sua vontade através dela. Duas formas importantes desta subversão ocorrem, por um lado, nas condições de credenciamento que limitam a transparência dos procedimentos dos prestadores do serviço credenciado, restringindo sua auditabilidade àquela praticada internamente pelo órgão credenciador, como determinam as resoluções 1 a 9 já emitidas pelo comitê gestor da ICP-B, e por outro, no poder que outorga a este comitê para homologar aplicações dos mecanismos de assinatura digital, sem critérios objetivos para o exercício deste poder.

Falar de chave pública registrada na ICP-B, como faz você na pergunta acima, é falar de chave pública que estaria sendo transportada em certificado assinado por uma certificadora credenciada pela ICP-B. Um tal certificado, por sua vez, pretende identificar publicamente o titular de um par de chaves, registrar a intenção deste titular quanto ao uso deste par, bem como sua concordância em relação às implicações legais deste uso. Mas quem gera um par de chaves criptográficas assimétricas, e quem verdadeiramente manipula qualquer delas, são softwares. Não importa se imerso em hardware dedicado ou instalado em hardware genérico. Podemos assim dizê-lo pois a geração sadia de um par de chaves precisa interagir com o suposto titular, para que este insemine com aleatoriedade o processo de geração de suas chaves. Esta é uma das condições adequadas. O titular de um par de chaves é, pelo parágrafo primeiro do artigo 6 da MP2200-2, quem teria comandado a algum software a geração deste par, e se dispõe a responder pelo uso da chave privada para fins de autenticação da sua vontade em documentos eletrônicos. A titulação de uma chave pública em um certificado emitido por uma certificadora credenciada registra, portanto, esta intenção e concordância. Esta seria a interpretação técnica mais razoável para a linguagem do parágrafo primeiro do artigo 10, à luz do artigo 1 da mesma MP, citados acima. Estaremos analisando ao longo desta entrevista o que isto significa em termos de riscos à cidadania.

Por sua vez, um software que lavra ou verifica assinaturas por meio de um desses sistemas precisa seguir padrões e formatos digitais que sejam públicos. Isto porque a lavra e a verificação de asssinaturas, possibilitadas por um tal par de chaves, destinam-se a ocorrer em diferentes computadores, com diferentes softwares e em variados tipos e formatos de documentos eletrônicos, já que, no contexto duma tal infra estrutura, entende-se por assinatura digital uma marca publicamente reconhecível identificadora da autoria de sua lavra. Os primeiros padrões propostos pela indústria para este fim vieram a ser conhecidos como PKCS (1 a 13), e se tornaram padrão de fato através do uso disseminado na internet. Um desses -- o PKCS 7, que evoluiu para o X.509 -- trata do formato e significados dos registros em um tipo de documento eletrônico destinado a transportar, depois de assinado, uma chave pública titulada destinada a verificar assinaturas do titular em outros documentos. Abreviadamente, um certificado digital.

Qualquer discriminação que um software porventura imponha ao uso de uma chave privada qualquer, só poderá basear-se na interpretação que sua lógica faça do significado daquilo que seu usuário queira, com tal chave, assinar. Teria, portanto, que basear-se na semântica de padrões e formatos digitais de documentos eletrônicos. E para que esta discriminação seja do conhecimento de outros softwares que devam com ele interagir, conhecimento este que evitaria verditos enganosos na intermediação que operam, esses padrões devem ser públicos.

Tecnicamente, o processo pelo qual um software lavra uma assinatura em um documento não carece dos bits que constituem tal documento. O processo de lavra consiste em misturar a chave privada e um digesto (hash criptográfico) deste documento, segundo as instruções do sistema de assinatura digital implementado. Este digesto é uma sequência de bits (normalmente de 160 bits) que funciona como "impressão digital" do documento, e a mistura resultante se destina a ser aposta ao documento, para autenticá-lo. Portanto, como não há razão para o software que executa a lavra da assinatura tomar conhecimento dos bits do documento a ser assinado, e sim os do seu digesto, seria de se esperar que nenhum padrão público para lavra e verificação de assinaturas digitais preveja tais discriminações.

Este é o caso do conjunto de padrões de fato hoje em uso na internet (PKCS 1 a 13). Havendo programas auditáveis que implementam algum ou alguns desses padrões, como é o caso do PGP, do OpenSSL, do Netscape Navigator e outros, torna-se de conhecimento público a existência de softwares que podem assinar digitalmente qualquer sequência de bits. Da mesma forma como é de conhecimento público que existem canetas que podem assinar qualquer papel. E mesmo que softwares não discriminatórios inexistissem, sendo tais sistemas criptográficos de domínio público, nada impediria, em tese, a legítima construção de softwares não discriminatórios que os implementem. Daí a minha afirmação: 'qualquer um que gerar um par de chaves pode assinar sua própria chave pública com sua chave privada'. "Pode" no sentido de inexistir impedimento técnico (o que permite certo tipo de fraude), e não no sentido da lei facultar explicitamente (o que não faria sentido). Aliás, a MP2200-2 reconhece a validade jurídica da assinatura num certificado auto-assinado, como ato gerador de presunção ne identificação do signatário, apenas para a certificadora raiz da ICP-Brasil, mas sem nenhum embasamento nas características ou condições adequadas à operação dos sistemas de assinatura.

Agora, sobre sua dúvida. Este par pode muito bem ser um par cuja chave pública tenha sido certificada em certificadora credenciada. Ter sido ou não, é, neste caso, imaterial, pois o software que lavra assinaturas em certificados não tem como saber o que já teria sido feito, ou o que virá a ser feito, com a chave privada que faz par com a chave pública transportada pelo certificado que está assinando. Uma das coisas que se pode fazer com tal chave privada é, na mesma ou noutra máquina, com o mesmo ou com outro software, depois ou antes, assinar um certificado contendo o seu próprio par (um certificado auto-assinado, também eufemisticamente chamado de certificado raiz). Um detalhe é que há também outras coisas no certificado, além da chave pública. Delas, a mais importante é o nome do seu titular.

Se aquele que é nomeado titular neste certificado for mesmo quem comandou a geração deste par de chaves, o significado deste certificado auto-assinado equivale ao de um cartão de visitas com o nome e número do telefone do titular, e uma frase assinada de punho dizendo "eu testei este número, e funciona". Aliás, é assim que algumas certificadoras distribuem sua chave pública, já que os softwares a que destinam tais chaves seguem padrões e formatos que supõem o transporte de tais chaves em certificados assinados. Se assim não lhes forem passadas as chaves, eles não funcionarão. Doutra parte, se o nomeado titular não for o mesmo que comandou a geração do par de chaves, não estando quem as gerou agindo por seu consentimento e anuência, o certificado possui titulação forjada, e, para efeito do uso público a que se destinam os certificados digitais, a saber, a identificação de assinantes de documentos eletrônicos, este seria um certificado falso.

Mas por que as certificadoras precisam distribuir sua chave pública? Porque tal chave é que cria mercado para o seu serviço, já que ela se faz necessária na ponta do consumidor final dos certificados emitidos para seus clientes, para que esses consumidores possam validar a integridade desses certificados. E por que esta chave é distribuída em certificados assinados? Porque é assim que os softwares desses clientes esperam receber chaves. Portanto, ou a certificadora distribui sua chave pública em certificado assinado por outra certificadora, se for subordinada, ou a distribui em certificado assinado por ela mesma (auto-assinado), se for raiz.

No caso do cartão de visitas, se alguém que você já conhece lhe entregar um em mãos, o fato dele estar assinado pelo próprio titular nada significa. Você já conhece o titular. E se algúem que você não conhece jogar um tal cartão em sua caixa postal, o fato deste cartão estar assinado pelo próprio titular também nada sigifica. Aquela assinatura nada acrescenta, ou diminui, à crença que você porventura sustente sobre a veracidade do que está ali impresso. Você não tem como conhecer a assinatura de quem ainda não conhece. O mesmo ocorre com os certificados digitais na internet, com a diferença de um detalhe importante, que veremos em seguida: o da "carona no navegador".

Portanto, o único objetivo de se assinar um certificado destinado a transportar o par da chave que o assina (certificado auto-assinado) é o de se alcançar autonomia na distribuição de uma chave pública, para softwares que esperam receber chaves públicas em certificados assinados. Por outro lado, esta autonomia é que permite a esses softwares interomperem o que seria uma cadeia infinita de validações necessárias para a verificação de qualquer assinatura, respeitados os padrões estabelecidos. A expectativa de que estes certificados lhes cheguem assinados cria para estes softwares a necessidade de receberem pelo menos um certificado auto-assinado, para operarem adequadamente. No caso dos certificados digitais na internet, como hoje usados, esta necessidade esconde um calcanhar de Aquiles no processo de identificação de autoria de documentos.

Este calcanhar de Aquiles está num detalhe. A saber, na confiança implícita na carona que alguns certificados auto-assinados pegam com um navegador (browser Internet Explorer, Netscape Navegator, Opera, Mozilla, etc.), uma jogada que impulsionou inicialmente o negócio da certificação. O internauta, que recebe o navegador "de graça", estará "reconhecendo", e dando por confiáveis, os titulares dos certificados auto-assinados que já vêm neste navegador, quando interpreta o cadeado amarelo se fechando, no canto inferior esquerdo da janela, como sinal de identificação segura do seu interlocutor naquela conexão.

Do sucesso desta jogada surge em outros o desejo de pegarem o "bonde do browser" andando, promovendo a distribuição de seu certificado auto-assinado independentemente do browser, o que exporá esse calcanhar de Aquiles do processo. Enquanto este processo for facultado ao cidadão virtual, o uso que faça deste processo equivale ao da contratação particular de uma espécie de apólice de seguro. Mas, se este uso se tornar obrigatório e ocorrer sob a vigência da norma em questão, este detalhe passa a abrigar possibilidades de logro para fraudes, contra o usuário do navegador ou seus interlocutores, que são, com a vigência da norma, influenciadas pelo efeito jurídico do sucesso no logro.

LP: Existe algum crime que possa ser cometido a partir desse procedimento (distribuição de certificados auto-assinados falsos)?

PR: Se o nome do titular num certificado auto-assinado não for o de quem comandou a geração do par de chaves referenciado, a informação que o certificado estaria transportando é falsa. Se, por exemplo, o nome do titular for o da certificadora raiz da ICP Brasil (AC-Raiz), tal logro poderia ser classificado como falsificação de documento público, crime previsto no Código Penal. Porém, no caso do documento público ser eletrônico, o equilíbrio entre risco de punição e benefício da fraude se desmancha, devido às dificuldades adicionais na caracterização do crime, peculiares ao fato do documento ser eletrônico.

Vejamos porque. No ciberespaço, o conceito de portador de um documento não pode ter o mesmo sentido clássico de responsabilização perante a lei, devido à opacidade introduzida pela intermediação do software e à natureza semiológica do documento eletrônico: um tal documento é apenas um padrão simbólico imaterial, cujas cópias são indistinguíveis do "original". Portanto, haverá não apenas um "portador do original", mas portadores de exemplares indistinguíveis. Em especial, no caso dos certificados, o esperado é que haja uma xusma de portadores de exemplares indistinguíveis, pois seu valor é proporcional a esta quantidade. A identificação do falsificador dificilmente poderá ser equacionada a partir do portador, pois, além deste não ser único, na maioria das vezes ele não terá ciência da identidade de quem lhe transmitiu seu exemplar, que terá sido algum software em alguma máquina na internet.

Até a perícia nos registros das transações eletrônicas terá enorme dificuldades para rastrear o vínculo entre esses softwares e uma pessoa que tenha originado um documento falso, da mesma forma que ocorre hoje com invasores de sites. Mesmo que seja rastreado, basta ao falsificador ter tido o cuidado de escrever zeros sobre o único exemplar da chave privada com que assinou o documento eletrônico falso, para destruir qualquer possível prova documental contra si.

Estas peculiaridades semiológicas dos sistemas criptográficos assimétricos, caso não sejam contempladas ao se instituir a presunção de veraridade na identificação de signatários de documentos eletrônicos, introduzirão graves desequilíbrios na teia jurídica, pois a falsificação de certificados auto-assinados servirá para a falsificação de qualquer documento. A tendência para se tentar neutralizar estes desequilíbrios semiológicos tem sido a aprovação de leis draconianas que se desequilibram na direção de "compensá-los", eivadas de exageros na prescrição das penas, de inconsistênicas e de simplismos na caracterização do crime, o que causa efeito ainda mais perverso na segurança jurídica, pois, ao migrarem para as leis, tais desequilibrios podem vir a servir a outros propósitos, nem sempre confessáveis. Aliás, tais efeitos colaterais podem se antecipar e se valerem desta tendência para escamotear, sob a necessidade desta "compensação", propósitos inconfessáveis ou indefensáveis no lobby por novas leis sobre o virtual, como tenho comentado e examinado em vários dos meus artigos. A ressaca da corrida do ouro digital certamente nos aguarda.

LP: É possível roubar a chave privada do navegador do usuário sem que ele perceba? Se isso for posível, então o criminoso pode realizar transações financeiras em nome da vítima?

PR: . Sim, embora tecnicamente o termo correto seja "vazamento", pois o ato não priva o dono da chave de sua "posse". O que consitui um complicador jurídico, pois o exemplar vazado pode ser usado, como você indica, sem que o titular disso suspeite. Normalmente a chave privada reside em um arquivo cifrado por senha, no diretório do browser ou no registro do sistema operacional. Em 70% dos casos de escolha de senha, esta cifragem pode ser quebrada por crackers (hackers criminosos), usando programas que aplicam ataques de dicionário em tais encriptações. E quando a senha for robusta, o atacante pode se valer de programas cavalos-de-tróia, amplamente difundidos no mundo do cibercrime e facilmente implementáveis na linguagem de comunicação de processos do Windows (VBscript), também linguagem de script para conteúdo ativos no Internet Explorer e no Outolook (coincidência que a faz a linguagem de maior sucesso já visto para confecção de vírus), para furtivamente interceptarem do teclado a digitação da senha e o acesso ao chaveiro do navegador, transmitindo-as ao atacante, até através de carona em conexões a sites insuspeitos.

E aqui está o nó de um novo golpe branco contra a cidadania, perpetrável por meio de leis de assinatura digital obtusas em que poderiam se encaixar como luva objetivos não confessáveis, mencionados acima. Segundo a letra do artigo 1 da MP2200, esta lei teria sido promulgada

"para garantir a autenticidade, a integridade e a validade jurídica de documentos em forma eletrônica, das aplicações de suporte e das aplicações habilitadas que utilizem certificados digitais, bem como a realização de transações eletrônicas seguras."

Tudo bem, se for para garantir tudo isto. Mas falta explicar como, o que fica para a norma a ser estabelecida por uma autoridade gestora, conforme o artigo 3 da mesma MP:

"A função de autoridade gestora de políticas [será exercida pelo Comitê Gestor da ICP-Brasil, vinculado à Casa Civil da Presidência da República".

Estamos, portanto, diante de um dos três Poderes reescrevendo, na prática, parte significativa de um novo Código Civil. Ao menos o princípio de contrapesos dos três Poderes, basilar na democracia moderna, foi aqui desprezado. Mas tudo bem, se for em boa causa. O motivo apresentado pelos defensores da MP2200 para este desprezo é o de que o Legislativo tem sido muito lento para decidir estas coisas tão urgentes. Tudo bem, se, ao final, se estiver buscando a manutenção da segurança jurídica, isto é, o equilíbrio de riscos e responsabilidades nas práticas sociais intermediadas pelo virtual. Podemos até ignorar que a morosidade do Legistalivo, que vinha debatendo o tema com a socieade há mais de dois anos, possa ter sofrido a inflluência do próprio Executivo para praticar esta morosidade.

O que se vê então, até aqui, no trabalho dos que tomaram para si toda esta autoridade e responsabilidade? O que deste trabalho primeiro se depreende é uma preocupação muito maior com a segurança do negócio do pedágio a ser cobrado, do cidadão e da Justiça, para trânsito de valores jurídicos no espaço virtual, do que com a segurança jurídica do cidadão e dos agentes sociais subrepresentados nesse novo jogo de poder. Apesar da linguagem pomposa e cheia de tecnicismos dessas normas sugerir ao leigo o contrário. Cito em meus artigos vários indícios do que estou aqui afirmando.

O que significa, por exemplo, a linguagem da MP2200 que diz

"garantir a validade jurídica ... das aplicações de suporte e das aplicações habilitadas que utilizem certificados digitais"? O que significa "aplicações habilitadas"?

Habilitadas por padrões públicos de interoperabilidade, por critérios técnicos que capacitem garantias de segurança computacional aos elos do sistema onde atuam, por critérios burocráticos, por critérios indiretos de discriminação forçada por padrões proprietários, ou por combinação desses? Ainda não sabemos o que virá a ser isso na prática, no escopo da ICP-B. Mas já o sabemos na Inglaterra. Lá, na prática, só funcionam aplicações "habilitadas" pelo padrão de fato introduzido pelo produtor de software que licenciou a operação e a custódia de todos os bancos de dados do governo britânico, a maior empresa do mundo, recém condenada em última instância por práticas monopolistas predatórias. Da mesma forma como acontece hoje com alguns serviços do internet banking da Caixa Econômica Federal.

Na lei italiana, os critérios são conhecidos e claros, estando neles visível a busca do equilíbrio que representa a segurança jurídica dos signatários digitais. A lei só estabelece a validade jurídica e a presunção de autoria de documentos assinados por chaves privadas em torno das quais os critérios de segurança computacional na sua geração, guarda e operação melhor aproximam os seus equivalentes na jurisprudência do processo clássico da assinatura de punho. Isto envolve, pelo menos mas não apenas, hardware dedicado (por exemplo, cartão inteligente).

Na lei brasileira, dos atos normativos do comitê gestor da ICP-B, que parecem se preocupar muito mais com a segurança do negócio do pedágio do que com a segurança jurídica dos titulares das chaves, emanam efeitos desequilíbrantes na teia jurídica que por sua vez podem induzir nefastas influências, que passo a listar. Como explicado antes, por razões semiológicas que escapam ao legislador e aos operadores do Direito, e que discuto em vários dos meus artigos, na esfera virtual o conceito de ônus da prova resulta muito próximo ao conceito de sentença condenatória. Por isso, em transações virtuais do governo e comércio eletrônicos, os riscos decorrentes de fraudes podem ser, na prática, transferidos para o interlocutor sobre o qual recaia o ônus da prova de fraude. Por sua vez, o descaso na norma jurídica com a totalidade dos elos da corrente da segurança operacional dos sistemas de assinatura digital onde esses intelocutores atuam consolida esta transferência.

Assim, vigindo norma jurídica que, como parece ser o caso do artigo 10 da MP2200-2, imputa ao titular da chave que verifica uma assinatura o ônus da prova de fraude sempre que esta titulação esteja registrada por certificadora credenciada, duas tendências surgirão naturalmente da lógica de poder desta vigência. Monopólios, grandes agentes econômicos e estatais tenderão a demandar, do cidadão comum ou do agente social que com ele precise transacionar, a forma eletrônica de transacionar e a certificação credenciada de sua chave pública. Tenderão certamente a eliminar alternativas. Se a lei proibir esta eliminação eles irão dificultá-las, como faz a Receita Federal com a declaração de renda via formulário em papel, e como estão fazendo os bancos com alguns dos serviços que prestam, ou com a tentativa de circunscrever a jurisdição do Código de Defesa do Consumidor em exclusão aos serviços bancários.

Esta demanda sofrerá menos resitência do leigo se ele for importunado ao mínimo para aceitar novos riscos. Como 19 entre 20 já usam o navegador e o sistema operacional da Microsoft, e os pacotes de "desenvolvimento integrado" para a "nova geração de serviços web" estão empurrando as empresas e os desenvolvedores de sistemas de informação para o círculo de controle semiológico (padrões proprietários) desta mesma empresa, sem que as normas para credenciamento na ICP-B especifiquem qualquer critério ou patamar de proteção à chave privada em posse do titular no varejo, a tendência é cairmos todos na vala comum da insegurança jurídica que você acaba de descrever.

E se o acesso a serviços universais for inviablizado a softwares concorrentes, como está acontecendo na CEF e na Inglaterra, nos veremos impedidos de nos proteger, por iniciativa própria, desses novos riscos a que estaremos sendo forçados a nos expor. Neste caso, estaremos sendo obrigados a gerar um par de chaves e certificá-lo em certificadora credenciada, a operar a chave privada em ambiente no qual não exercemos controle adequado sobre riscos, ao mesmo tempo em que somos forçados a arcar com o ônus da prova de uso indevido desta chave. O cidadão só irá aceitar isso se achar que a conveniência compensa os riscos, mas dificilmente irá acreditar que este cenário corrresponde, para ele, a uma escravidão consentida a um grande irmão.

Não devemos nos esquecer de que os módulos de segurança dos softwares da Microsoft são inauditáveis, e de que há indícios copiosos de abuso desta opacidade para fins de espionagem e de controle semiológico sobre seus usuários, e pior, de falhas estruturais comprometedoras da segurança desses usuários que não poderão nunca ser efetivamente corrigidas, a menos de mudanças na filosofia da arquitetura dos softwares. Porém, mundanças que inviablizariam tal controle semiológico sobre usuários, controle sobre o qual assenta a segurança do negócio da empresa, e portanto, mudanças cuja ocorrência não devemos esperar como voluntárias ou irresistíveis. Este assunto, que perpassa os autos do processo em que foi condenada por danos sociais decorrentes de prática monopolista predatória, é visitado com frequência em meus artigos.

Tal cenário de insegurança computacional, por sua vez, justifica a necessidade jurídica da possibilidade da revogação de chaves, bem como a expectativa de sua ocorrência frequente. Estão previstas, nas normas ditadas pelo comitê gestor da ICP-B, dois tipos de revogação: por iniciativa do titular ou do certificador. A revogação por iniciativa do titular se destina a amenizar o desequilíbrio jurídico decorrente das possibilidades de vazamento de sua chave privada. Amenizar, e não neutralizar, pois a inicativa do titular em revogar sua chave presume-se decorrente de suspeita da quebra indevida do sigilo de sua chave, ao passo que este quebra normalmente é sorrateira, pois sua chave "continuará onde sempre esteve". Tais peculiaridades fazem com que, na prática e no caso geral, tal suspeita só se materialize perante o conhecimento da ocorrência de fraude, para as quais a revogação será inóqua, a menos que retroaja. E se puder retroagir, a norma estará escancarando a porta para o tipo de fraude que trataremos em seguida.

Por sua vez, a revogação por iniciativa do certificador se destina a amenizar o desequilibrio jurídico decorrente de possivel falsidade ideológica na titulação da chave. E novamente: amenizar, e não neutralizar, pelos mesmos motivos. A supracitada norma não especifica detalhes das exigências documentais e processuais a serem cumpridas para o registro da revogação de chaves pelas certificadoras credenciadas. Apenas da padronização de sua divulgação em meio eletrônico. Nesta omissão estão as brechas para o tipo de fraude descrito abaixo, que parece ser o mais grave possível.. E por fim, a frequência de revogações que se pode esperar do uso disseminado de chaves assimétricas em ambientes computacionalmente promíscuos, por usuários a ele forçados sem a devida aculturação aos seus riscos e consequências, servirá para melhor escamotear esse tipo de fraude.

LP: No mesmo artigo o senhor comenta que o grande calcanhar de Aquiles da ICP Brasil é a revogação das chaves de pessoas envolvidas em denúncias de corrupção, ou a falta de segurança desse procedimento. Gostaria de mais explicação sobre isso. Uma pessoa acusada de crime tem que ter suas chaves revogadas? É isso?

PR: Não, não é bem isso. Estava falando da transitividade de riscos. Riscos se contaminam e se retroalimentam, como no cenário que tento ali descrever. Passo então a detalhar melhor este cenário. Um corrupto em potencial que precise, por exemplo, emitir ordens de pagamento digitalmente assinadas para cometer atos ilícitos, ordens essas que constituem prova de conduta irregular do assinante, irá buscar uma forma de se livrar da autoria das mesmas, assim que surtam o efeito desejado, como o de fazer algum dinheiro mudar de lugar. Tendo praticado um tal ato, ele em princípio poderá aguardar até que o rastro eletrônico deste ato produza acusação de ilícito, para então argumentar que sua chave teria sido usada indevidamente, fato do qual teria tomado conhecimento pela acusação mesma. Este argumento justificaria um possível pedido de revogação de sua chave, mas não o livraria das pesadas responsabilidades decorrentes do paragrafo primeiro do artigo 10 da MP, se a revogação não retroagir.

LP: Nesse caso não existe segurança de que ela seja revogada, mas e daí? O trecho "Isso sabendo-se que uma revogação com data retroativa pode transformar, sem tocá-la, provas documentais eletrônicas de prática criminosa em prova de falsidade ideológica e evidência de "roubo" da chave privada imputáveis ao denunciante" siginfica que o denunciante pode ser acusado de roubo da chave privada do verdadeiro criminoso? É um ponto que me chamou muito a atenção e que gostaria de destrinchar da forma mais acessível possível aos leitores.

PR: Voltemos ao ponto onde estava, na descrição do hipotético cenário de interação entre o crime organizado e a normatização do valor jurídico da assinatura digital. Ao avaliar os riscos a que estará exposto ao praticar ilícitos por meio de documentos eletrônicos, o corrupto em potencial estará examinando a possibilidade de, se e quando uma eventual acusação de ilícito lhe for dirigida, poder obter da sua certificadora a revogação de sua chave com data anterior à do documento que estaria consubstanciando tal imputação, sem que tal retroação seja publicamente admitida. Assim, ele poderia continuar fraudando com esta chave até ser acusado, safar-se da acusação, e continuar as fraudes com uma nova chave. Se puder assim obtê-la, isto é, se puder obter a revogação de sua chave com data retroativa, estaria obtendo garantias de impunidade, na medida em que a retrodatação da revogação seja, publicamente, apenas uma hipótese indemonstrável. Afinal, a lista de certificados revogados por uma certificadora é assinada por ela, e se ela for credenciada, o artigo 10 da MP 2200 reza que ela é presumida verdadeira, e a resolução 2 do CG diz que ela é externamente inauditável.

No caso da revogação retroativa numa lista supostamente não retroativa, o corrupto estaria obtendo também, de quebra, a possibilidade de reverter a imputação de ilícito sobre quem vier a lhe acusar, pois o acusador se poria, com sua "prova", na posição de principal suspeito de ter lhe provocado as suspeitas de vazamento, que o teriam levado a revogar sua chave "na data que consta da sua revogação". Mesmo se o acusador tiver o cuidado de, antes de decidir anexar tal documento aos autos do processo, verificar, junto à certificadora do signatário suspeito, que aquela chave de assinatura estava em vigor na data de assinatura do documento.

Mesmo se o acusador tiver o cuidado extra de anexar aos autos a lista de revogação desta certificadora, assinada por ela e com data posterior à do documento probante do ilícito, mostrando que a revogação em questão não constava naquela data, a certificadora poderá produzir, e sustentar como legítima, para a defesa do corrupto, uma outra lista assinada com mesma data onde consta a revogação em questão. Esta sustentação seria inatacável devido à blindagem contra auditoria externa que lhe dá a norma emanada da MP2200-2, e o acusador poderia neste caso se ver acusado de também fraudar a certificadora. E como, em caso de dúvida, beneficia-se o réu, o acusador teria feito papel de palhaço e o corrupto ganho impunidade e oportunidade de capitalização política, por ter sido "vítima de maliciosa perseguição".

Este jogo não seria novidade, já existindo com os documentos de papel. A diferença é que, com o papel, o jogo é de astúcia processual e arbitrado pela jurisprudência dos códigos de processo, ao passo que, como armado pelo cenário das normas em vigor para os documentos eletrônicos, torna-se um jogo de cartas marcadas onde o poder Judiciário poderia ser fácil presa ou cúmplice de logro pela manipulação de opacidades e desequilíbrios de natureza semiológica. Quem estiver nas lides da justiça para fazer justiça, e não tráfego de influência, estaria amordaçado.

Dependendo do contexto e do modo como faça sua avaliação, o potencial corrupto poderá concluir que estará melhor se antencipando. Estimulando o conluio com certificadoras, legisladores e gestores, para que a norma impossibilite a detectação de retroação em revogações. O avaliador dos riscos de corrupção pode agir, então, como corruptor, se expuser a relação risco/benefício deste conluio não em público, como estou tentanto fazer aqui, mas reservadamente e para público alvo específico, no contexto adequado de pressões subjetivas e indiretas.

A indemonstrabilidade da retroação de revogações pode ser alcançada, por exemplo, impedido-se a auditoria externa sobre os processos e procedimentos das certificadoras credenciadas. Sinais compatíveis com as hipóteses deste cenário estão estampados nas normas da ICP-Brasil, que insiste em ignorar os riscos na opacidade e na falta de garantias públicas no processo de revogação, razão da minha linguagem dramática e do meu apelo de alerta, pois quanto mais despercebidas e desimpedidas puderem ocorrer estas hipotéticas interações nefastas, mais difícil será reverter seus efeitos. Nem mesmo a inexperiência e limitações no domínio técnico do legislador justifica esta coincidência, pois ela certamente irá atrair a má fé alheia, até a exploração pelo crime organizado, se ignorada.

LP: A primeira grande aplicação do ICP Brasil começará nos próximos meses com a implementação do Sistema de Pagamentos Brasileiro (SPB). Que riscos o senhor vê nesse processo? O consumidor/usuário dos serviços bancários corre riscos?

PR: Em princípio, o SBP é uma rede fechada interbancária. MAs nada impede sua integração com serviços bancários de varejo. Neste caso o cidadão passa a correr riscos na medida em que possa se ver obrigado a ter que gerar chaves sob o regime da ICP-B para transacionar com bancos, em vista do exposto acima sobre a questão do ônus da prova digital e das práticas discriminatórias inauguradas pela Caixa Econômica Federal nos seus serviços via internet. O equilíbrio jurídico na presença de normas que explicitem valores jurídicos da assinatura digital depende de uma delicada e minunciosa ponderação determinante do ônus da prova digital. E a iniciativa da Febraban em questionar, no STF, o alcance do código de defesa do consumidor aos serviços bancários, código que poderia se opor ao cerne do efeito pretendido pela MP2200, é um péssimo sinal para o consumidor/usuário. Por outro lado, o poder fiscalizador exógeno do Estado passa a correr novos riscos, na medida em que lhe é vedada a normatização e a auditoria nos processos de revogação de chaves conduzidos pelas certificadoras credenciadas.

LP: No artigo "Totalitarismo digital ", o senhor escreve que a pressa na publicação da MP, no ano passado, que criou a ICP Brasil aconteceu "porque os métodos de assinatura digital caíram todos em domínio público, com a expiração da patente do algoritmo RSA em 20 de setembro do ano passado. Com isso, implementações em software livre desses métodos podem agora alastrar seus benefícios de auditabilidade e gratuidade, minando o controle de indústrias monopolistas sobre necessidades artificialmente criadas para seus produtos. Essas indústrias precisam portanto criar, o quanto antes, novas necessidades que excluam o software livre. E dá-lhe lobby mais propaganda enganosa, não só no Brasil, mas em todo o mundo! ". Os padrões usados na ICP pretendem então excluir o software livre?

PR: Este artigo foi escrito diante da primeira versão da MP2200, que incluia linguagem não mais presente na versão 2200-2. Tal linguagem falava explicitamente da atribuição do comitê gestor da ICP-Brasil para "homologar software" cuja intermediação daria validade jurídica a documentos eletrônicos. Primeiro, esta homologação seria inexequível para um processo sadio de geração de chaves: como pode o software da certificadora saber qual software teria gerado meu par de chaves? Só poderia saber mediante exigência ao titular, no sentido de abdicar do controle desta geração em favor da certificadora, o que implicaria, na prática, em custódia forçada da chave privada, o que implicaria, na prática, em anulação da segurança jurídica da assinatura, o que a primeira versão da MP, por sinal, também ditava.

Entretanto, estas necessidades artificiais podem ser criadas, na prática, sem o expediente da norma legal, através da introdução de padrões proprietários na prestação de serviços universais informatizados, a exemplo do que acontece na Inglaterra e na Caixa Econômica Federal. A estratégia para descarte do software livre, de código aberto e auditável, e propaganda enganosa em todo o mundo, se refere ao lobby pela adesão ao modelo americano de lei de assinatura digital, baseada no modelo da Uncitral, analisado em artigo apresentado em congresso internacional em Miami ("Uncitral"). Este modelo legitima inicativas como a da Inglaterra e a da Caixa Econômica Federal, que na prática impõem padrões proprietários ao consumidor, impedindo-o de exercer controle sobre sua exposição a riscos, controle que poderia exercer optando por software auditável e livremente adaptável às suas necessidades. Se não diretamente por si, pelo menos de quem possa escolher por critérios de confiança.

Se isto vier a ocorrer com serviços universais, a segurança jurídica na esfera virtual será natimorta, como natimorto viria o rei de Angolmois, de acordo com a décima centúria de Nostradamus, numa estrofe ancorada à última eclipse solar do segundo milênio (72). Na ocasião em que escrevi "Totalitarismo Digital" este lobby tinha recém conseguido aprovar no Senado a mais esdrúxula das leis de assinatura digital até então em discussão no Brasil, o PL SF672/99, do Senador Lúcio Alcântara do PSDB, uma pobre tradução do modelo da Uncitral e alterativa até então mais palpável ao objetivo da MP2200. Parecia-me plausível que a mudança de curso do Executivo, que passou do apoio ao PL SF672/99 ao ucasse da MP2200, manteria possíveis alianças e compromissos implícitos no apoio ao primeiro.

LP: É por isso que a auditabilidade é vedada?

PR: A adoção de padrões proprietários, quer por meios diretos ou indiretos, seria uma desculpa jurídica para se vedar a auditoria externa ao software que implementa as aplicações. Esta desculpa havia sido empregada pelo TSE em 2000, em relação ao sistema operacional da urna eletrônica, e esta hipótese apresentava alta plausibilidade nos momentos iniciais do jogo de quebra-cabeças para a leitura das intenções cifradas nos atos que então se praticavam na cozinha do Planalto. Auditoria que, em minha opinião, é essencial para a segurança jurídica da assinatura digital, principalmente do software que gera chaves. Explico o porquê no parecer técnico que produzi para o Instituto de Registros Imobiliários no Brasil, sobre um contrato de prestação de serviços de certificação que lhe alcançaria.

LP: Os softwares proprietários não permitem auditabilidade?

PR: Alguns, e em variados graus. Podemos classificar as licenças de uso de software (EULAs) em relação a um espectro que mede a liberdade do licenciado em relação ao objeto da licença. Este espectro não mede preço ou custo de se licenciar o uso do software, mas o que podemos chamar de grau de liberdade. Este espectro vai da licença mais radical do software proprietário (UCITA) até a licença GPL. No centro da aferição deste grau está o código-fonte do software, comparável ao mesmo tempo a seu código genético, em que é criado, e a seu canal de consciência, que permite à inteligência humana acessar sua lógica.

Nesta escala, em ordem de proximidade à licença proprietária clássica (na qual se paga pelo direito de uso, sem direito de acesso ao código fonte) estão as licenças de softwares com código aberto (paga-se pela direito de uso, que inclui o direito de acesso ao código fonte, mediante cláusulas de non-disclosure e/ou não alteração), o freeware (nenhuma restrição em relação a uso e redistribuição, etc.), o freeware com código aberto, e finalmente, na outra ponta do espectro a licença GPL (General Public License), que proíbe a supressão da liberdade do seu objeto.

Mas existem nuanças. Algumas empresas liberam acesso a código fonte passando-o antes por um "tratamento" para torná-lo propositadamente ininteligível à mente humana, tratamento que elimina a auto-documentação do autor em comentários e que troca nomes de variáveis para obscurecer sua semântica, truques que não afetam sua tradução para código de máquina. Este tratamento funciona como o estilhaçar de uma pedra de Roseta, tornando o software em tese auditável, pois tecnicamente os "meios necessários" para tal auditoria estariam sendo disponibilizados, mas na prática inauditável, pois os meios de sua criação teriam sido conspurcados para bloquear sua inteligibilidade, servindo para o produtor jogar confete sobre as necessidades de garantias reclamadas por quem licencia seus softwares (como no caso da Microsoft com a França, explicado no artigo "Cacos de uma Pedra de Roseta"). Os softwares para certificadoras desenvolvidos no Brasil pela e-Sec são licenciados com permissão para qualquer auditoria no código fonte, na sua versão original, e para compilação on-site sob controle do licenciado. O código fonte do openSSL e do navegador Mozilla, desenvolvidos no movimento do software livre, são por sua vez abertos, sem restrições.

LP: A comunidade acadêmica está se mobilizando contra ou a favor sobre o assunto?

PR: Não o suficiente, em minha opinião. Houve um protesto público da SBC, os dois congressos nacionais de segurança computacional (da SBC e do ITA) tem dedicado mesas redondas e palestras sobre o tema, mas o debate tem sido, por diversas razões, insípido ali também, até agora.

segundo email

LP: Desculpe professor, mas não entendi direito. Quer dizer que o sujeito que assina um certificado que contém o par de chaves o faz para tornar conhecida a chave pública?

PR: A chave de um par assimétrico que é submetida a certificação é a pública. Entretanto, o certificado precisa também dizer para qual sistema critpográfico (algoritmo) aquela chave se destina. Um tal algoritmo é algo semelhante a um modelo de fechadura digital. Ao mencionar o algoritmo, e sendo este assimétrico, o certificado estará fazendo referência à existência de uma outra chave (a chave privada) que forma par com esta chave pública, que teria sido gerada junto com ela, com a propriedade de que uma reverte a ação da outra no sistema, sem entretanto permitir sua imitação. Portanto, o certificado digital que transporta uma chave pública faz referência ao par pública-privada a que pertence esta chave, mas transporta (contém) apenas a pública..

Mas o certificado faz também outras referências a chaves. O certificado precisa ser assinado, para obedecer aos padrões vigentes (x509). Assim, ele precisa transportar também o nome daquele que o assinou (do certificador), para que sua integridade possa ser verificada por quem for usá-lo. Obviamente, usando a chave pública deste certificador. Assim, um certificado assinado por uma certificadora cujo titular seja um cidadão, faz, no total, referência a quatro chaves. O par pública-privada do cidadão, cuja pública ele transporta, e o par pública-privada da certificadora, cuja privada o teria assinado, e cuja pública é necessária para verificar sua integridade. Como estão relacionadas na prática essas chaves? Quem pretende verificar uma assinatura em um documento eletrônico, deve usar para isso a chave pública do signatário. Precisa para isso de um exemplar do certificado que transporta esta chave, e, para confiar na integridade do exemplar que lhe chega às mãos, precisa verificar a assinatura neste certificado. Isto lhe asseguraria que o nome do titular no exemplar do certificado, em seu poder, é o mesmo que nele constava no ato da sua assinatura, pela certificadora.

Como tal verificação de integridade do certificado requer a chave pública do certificador, pressupõe-se que tal chave venha em um outro certificado (assinado). A necessidade de verificar uma assinatura disparou assim uma cadeia recursiva de necessidades de verificação de assinaturas em certificados. Esta cadeia seria infinita se não chegasse a um certificado no qual a chave transportada é a mesma que "verifica sua integridade". Um tal certificado é dito auto-assinado, ou raiz. Os dois pares de chaves a que ele se refere, o do titular e o do certificador, são o mesmo.

E a resposta à sua pergunta é sim. Tanto um certificado "normal" (no qual o titular e o certificador nomeados são distintos), quanto um certificado auto-assinado (no qual o titular e o certificador tem o mesmo nome, presumindo que os dois pares de chaves referidos são os mesmos), destinam-se a tornar conhecida a chave pública transportada. O certificador é simplesmente alguém que apresenta o titular ao portador do certificado. Assim, o certificador de um certificado auto-assinado é alguem que apresenta-se a si mesmo.

LP: Por que isso é ruim para o usuário? Talvez se o senhor me explicar com exemplos fique mais fácil de entender...

PR: Aqui você está a um passo de matar a charada, de pegar o coelho que tem nesse mato. Isto que você menciona, o fato de que qualquer um pode se apresentar no mundo virtual através de um certificado auto-assinado, não é, em si, nem bom nem ruim para ninguém. Aliás, como vimos acima, sob os padrões vigentes é inevitável que alguém assim o faça. E esses padrões estão hoje em uso porque foram os que, até aqui, melhor funcionaram. A discussão jurídica sobre a ICP-B começa pelo direito natural de fazê-lo. A MP2200-2 está dizendo quem só a AC-Raiz tem o direito natural de apresentar-se a si mesma, para os que transitam por um novo portão por ela aberto, separando o mundo virtual do mundo jurídico. A saber, o portão da presunção de veracidade de docuemntos eletrônicos.

Consequentemente, só ela tem o direito de apresentar aqueles que vão poder apresentar, com presunção de veracidade, os que transitam por este portão. Ela pode, desta forma, instituir, neste portão, o pedágio que quiser. A MP2200-2 vai além e cria, com sua estrutura de certificação em árvore (estrutura erroneamente denomidada "cadeia" no artigo 2o.), um regime de castas para esta nova "etiqueta social", com a AC-Raiz no papel de soberano supremo e o comitê gestor como guardião do regime: Quem se apresentar por meio desta hierarquia é presumido verdadeiro, cabendo a quem duvidar o ônus da prova, ao reverso para os párias.

Quando, na verdade, o direito à auto-apresentação presumidamente verdadeira é, subjetivamente, uma questão de foro íntimo, e, objetivamente, uma questão regida por norma constitucional, se considerarmos qualquer outro portão no mundo da vida que tenha significado na esfera jurídica. Se você, ao cruzar um portão de ferro no mundo da carne, se depara com alguém que se apresenta a si mesmo e lhe propõe um contrato, na tradição jurídica clássica nada lhe impede de aceitar ou recusar, desde que aceite ou recuse os riscos envolvidos, na medida em que os perceba. Não ter a quem cobrar eventuais prejuízos, devidos a falsas representações nesta auto-apresentação, é um desses riscos, para cujo controle a presunção de veracidade é regulada pelo artigo 236 da Constituição Federal. No que tem de bom, o modelo americano de lei de assinatura digital universaliza a interpretação subjetiva da veracidade das apresentações nesse novo portão. Segundo ela, ninguém tem ali qualquer privilégio que seja, em relação à presunção de veracidade. Mas, no que tem de ruim, este direito de igualdade subjetiva opera para escamotear desequíbrios abissais em desfavor da cidadania, empurrando-lhe outros riscos.

Espera-se, portanto, de quem engendrou e de quem defende a MP2200, uma justificativa razoável para a adoção do regime de castas no espaço social em volta desse novo portão. Uma justificativa para a escolha dos critérios que designam quem pode apresentar-se a si mesmo com tal presunção, e quem pode fazer herdar esta presunção em apresentações neste portão, critérios esses que ignoram o artigo 236 da Contituição Federal. Esta justificativa, e não o fato de que alguém precisa, e pode, apresentar-se a si mesmo, é que será boa ou ruim. A comissão de informática jurídica da OAB, por exemplo, sustenta, em meu entender, que a lógica desta justificativa não pode ser de natureza jurídica, sem ferir vários pilares da tradição jurídica do país, referentes à natureza da fé pública, e ao significado jurídico do que venha a ser "presunção de veracidade". Seria a veracidade do conteúdo, e não da identificação positiva do assinante do documento. Mas então, para que serviria a certificação credenciada? Afinal, a identificação do assinante, através da chave pública e do nome ali transportados, é o conteúdo de documentos que aqui denominamos certificados digitais credenciados!

Tampouco a lógica desta justificativa pode ser de natureza técnica, pois nenhuma técnica pode embasar a presunção de veracidade na identficação do signatário de qualquer certificado auto-assinado, seja lá qual for sua titulação. Trata-se de impedimento semiológico. E desvendar a verdadeira lógica desta justificativa é matar a charada da qual você está a um passo. É pegar o coelho que tem nesse mato.

Pois então vamos dar este passo.

A justificativa que tem sido recitada pelos defensores da MP2200 é baseada na competência técnica e na autoridade. A chave privada da AC-Raiz estaria no cofre mais seguro, gerada pelo software mais caro, operada pelo serviço de processamento de dados com maior escala e volume de serviço no país, com a supervisão e o aval da Casa Civil da Presidência da República, etc. Tudo isto oferece à sociedade apenas parte das garantias que ela espera do enorme privilégio e responsabilidades a serem justificados. As garantias recitadas arrazoam apenas sobre um dos aspectos da segurança jurídica em questão. Só descrevem a resistência de um dos elos da corrente que vem a ser a segurança jurídica desta presunção. A saber, do elo cujo risco de ruptura é o uso sorrateiro da chave privada designada raiz da infra estrutura, para assinar certificados com titulação falsa.

Em relação a outros aspectos, a justificativa recitada nada arrazoa. Outros elos dessa corrente são por ela ignorados. Senão vejamos. A AC raiz precisa, para cumprir o que promete a MP2200, fazer sua chave pública conhecida de todo software destinado a verificar assinaturas digitais que presumam veraz a identificação do signatário, em qualquer parte do território nacional, chave esta que dará a palavra final sobre a integridade de uma cadeia de assinaturas avalisadoras desta presunção. E é só isto que ela pode fazer. E sendo só isto o que o certificado auto-assinado da AC-Raiz é capaz de oferecer, escapam do seu controle os outros elos. Como pode a certificadorra raiz e seu certificado garantirem, por exemplo, que um certificado auto-assinado com titulação idêntica ao seu verdadeiro certificado (ambos auto-assinados), não irá se apresentar a um desses softwares para arrematar uma cadeia de assinaturas falsas, visando a consumação de uma fraude eletrônica?

Ou então, como podem garantir proteção à chave privada de um signatário qualquer, contra quebra indevida do sigilo desta? Depois de entendermos como e porque não podem, sobrará o poder de homologação do comitê gestor da ICP-B para oferecer garantias suficientes ao vínculo jurídico que lhe cabe gerenciar. Mas a homologação só poderá oferecer tais garantias se puder comprovar a segurança da operação das "aplicações de suporte e homologadas".. E será que pode? Para intuirmos a resposta, basta observar o crescimento de incidentes de segurança na internet, maior até que o da própria grande rede.

Nada nos argumentos costurados na justificativa recitada têm, como visto, qualquer relevância para superar, para equacionar, ou para amenizar, o verdadeiro problema da robustez de tal corrente. Por este ângulo, perante a justificativa recitada cabe muito bem a sua indagação: "E daí?" Afinal, a segurança jurídica de uma assinatura digital de casta, isto é, presumidamente veraz quanto à sua capacidade de identificar o signatário através de certificado credenciado, será tão forte quanto a mais fraca dessas garantias. Isto, os arquitetos do modelo americano perceberam logo. Já os arquitetos da lei brasileira põe a desfilar o rei, com sua maravilhosa roupa nova. O que eu disse no artigo "O silencio que produz ruídos", em relação ao calcanhar de Aquiles da distribuição de chaves auto-assinadas na ICP-B, e que você cita em sua primeira pergunta, foi, em outras palavras, que o rei está nu!

LP: Não entendo como pode um titular de certificado não ser a mesma pessoa que comandou a geração do par de chaves. Qual o crime que daí advém?

PR: Quanto ao como: Alguém simplesmente gera um par de chaves, edita um certificado colocando a chave pública do par recém gerado como chave a ser transportada, coloca o que bem quiser como nome do titular, e assina com a chave privada do par recem gerado, tudo na intimidade de seu ambiente computacional. Simplesmente uma questão de escolha correta de software e entrada de dados para um fim específico, software e dados cuja existência, possibilidades e legitimidade discorri nos preâmbulos da resposta à primeira pergunta.

Quanto ao crime: Se a pessoa falsamente nomeada como titular é uma autoridade pública, e o documento falsificado é um documento público (como quer a MP 2200-2 para o certificado auto-assinado da AC-Raiz), então o crime que daí advém seria o de falsificação de documento público, presumindo-se que um documento eletrônico seja também um documento no sentido que lhe dá o Código Civil. No caso acima descrito se enquadraria, por exemplo, a geração de um certificado auto-assinado cujo titular nomeado é a AC-Raiz, mas cuja chave ali contida não pertence a nenhum par que a AC-Raiz tenha gerado para si. Este crime equivale, por exemplo, ao da falsificação da carteira de habilitação do chefe do DENATRAN, onde a foto falsa corresponde à chave pública de origem falsa.

Quanto à relação risco/recompensa pelo crime: A diferença em relação à prova do crime na comparação acima é o que muda drasticamente, como assinalo na resposta anterior. No caso da falsificação da carteira de motorista do chefe do DENATRAN, o promotor terá boas chances de sucesso caso apresente, como acusado de responsabilidade pelo crime, um sujeito cujo rosto corresponde à foto na carteira falsa. Enquanto no caso do certificado, o promotor só terá alguma chance se encontrar, no computador do acusado, uma sequência de bits que faça par com a chave pública que está no certificado auto-assinado de titulação falsa, na dança do sistema criptográfico para o qual foi gerado aquele par, conforme especificado neste certificado.

LP: O caso da revogação das chaves. Um exemplo de possível crime seria esse (?): Um crimisoso autoriza uma transação financeira ilícita e espera que isso fique registrado. Se acusado pelo ato, o sujeito solicitaria à autoridade certificadora revogação da chave para uma data anterior ao do crime praticado.

PR: Sim, este seria um exemplo ilustrativo. É razoável que o corrupto espere que seu crime fique registrado, já que ele espera que a autorização surta efeito. Mas o essencial aqui são duas outras coisas.

Ninguém, dentre os que precisam saber da retroação para poder perpetrá-la, irá admitir que houve retroação na revogação. Ningém vai sequer admitir a sua possibilidade. Vão insistir, sempre, que a datação retroativa é tecnicamente impossível no "sistema". Porém, uma data em um documento eletrônico assinado e verificado íntegro são apenas bits que entraram no documento antes da assinatura. E assim como o papel aceita tudo, uma sequência de bits aceita qualquer subsequência. Com a vantagem de que bits não desbotam, não envelhecem sua tinta, não deixam marca de rasura ao serem rearranjados, pois são apenas símbolos.
Os que sabem de eventuais revogações retroativas, da sua possibilidade, ou da relação risco/benefício nesta possibilidade, vão cuidar para que sinais de tais fatos não venham à tona. O bloqueio à auditoria externa seria o primeiro passo neste cuidado, se o revogador não estiver seguro da superioridade de sua habilidade em apagar rastros eletrônicos, em relação ao de um auditor externo em descobri-los. Teremos que confiar na palavra do revogador, sobre a impossibilidade técnica da datação retroativa pelo "sistema".

Para rogar tal confiança, ou para cuidar da ocultação de tais sinais, o argumento da incompetência alheia advinda da ignorância "do sistema", direcionado a desqualificar o questionamento de quem critica esta rogação, ou de quem aponta tais sinais, cai como uma luva Kafkiana E esta luva já foi publicamente oferecida em pelo menos três ocasiões, e nelas calçada pela mídia.

Numa entrevista coletiva à imprensa em 4/7/01, seis dias após a publicação da primeira versão da MP2200, pelo então subchefe de assuntos jurídicos da Casa Civil, Jóse Bonifácio de Andrada, em matéria publicada pela Folha de São Paulo.
Num debate aberto sobre a MP2200, organizado pela OAB-SP em 27/07/01, pelo então diretor-geral da Federação Brasileira dos Bancos (Febraban), Hugo Dantas Pereira, único participanate a defender a MP2200 naquele evento, publicado pelo Estadão na coluna eletrônica "tecnologia da informação" de 5/08/01.
No evento e-Gov de 28/11/01, após a cerimônia de geração do par de chaves da AC-Raiz pelo SERPRO, seu custodiante, pelo Diretor do Serpro, Wolney Martins, publicada pela revista eletrônica ComputerWorld, no mesmo dia. Comento o relato do que teria dito o Sr Dantas no artigo "Sobre a ICP-Brasil", e sobre o que teria dito o Sr. Wolney Martins no artigo "O silêncio que produz ruídos".

LG:

Isso lhe daria prova de que não poderia ter cometido o crime porque é como se ele já não estivesse usando a chave. E lhe daria também a chance de acusar alguém de estar usando suas chaves.

PR: Supostamente para incriminá-lo, certamente por motivos políticos, tal qual na investigação do escândalo da SUDAM. Mas com a crucial diferença de que as provas seriam tecnicamente insustentáveis. E na dúvida, pró réu, o que significa garantia de impunidade.

terceiro email

LG: Resumindo: A emissão de certificados auto-assinados é necessário para que as instituições que terão alguma relação com o usuário (bancos, lojas virtuais, instituições públicas) possam reconhecê-lo. É possível a um criminoso roubar as chaves dessa pessoa e fazer-se passar por ele, dando ordens de pagamento, fazendo empréstimos, etc. É isso?

PR: Não precisa tanto. Mesmo porque as chaves privadas verdadeiras, das certificadoras credenciadas, dos párias que se prezam e dos que estejam ligados nos riscos, estarão muito bem protegidas, longe de Hard Disks visíveis na grande rede. Basta ao falsário "roubar" (usar indevidamente) os nomes das instituições a serem envolvidas no golpe, que são públicos (pois estão nos certificados verdadeiros das mesmas), e casá-los, um a um, com chaves públicas de pares que ele tenha gerado exclusivamente para aplicar o golpe (pares dos quais ele, e não cada instituição, possuirá a chave privada).

LG: No caso da falsificaão de um certificado da ICB Brasil, para que serve essa falsificação? Preciso de exemplos práticos para explicar ao leitor.

PR: Você está diante de um tremendo desafio, devido às limitações de espaço no papel do jornal. Mas temos que tentar. Então vamos lá. Primeiro: Neste "exemplo prático" o professor não deve nomear instituições que existem na vida real, pois alguém pode se ofender com a nomeação e processar o professor por difamação. Num golpe mais simples que o que você sugere, o falsário falsifica um documento assinando-o com uma chave privada gerada por ele mesmo, junto com um cenário que ele constrói para fazê-la passar por verdadeira.

Digamos, por exemplo, que ele queira produzir uma falsa declaração negativa de débito, ou liberação de verba para depósito em conta laranja, assinada em nome de um órgão público. Ele redige e assina este documento com a chave privada de um par que ele gera só para este golpe. Para que esta assinatura seja tida como autêntica, ele precisa antes colocar a chave pública deste par num certificado falso que contenha, como nome do titular, o desse órgão público. Ele pode, por exemplo, simplesmente copiar ipsi literis o nome do titular e o da sua certificadora, do certificado verdadeiro deste orgão público. Acontece que este certificado falso precisa estar assinado por esta certificadora. O falsário estará, então, diante da necessidade da falsificação recursiva.

Ele precisa gerar também outros pares de chaves. Ele então gera mais um par, para fazê-lo passar por par de chaves da certificadora que emitiu o certificado do órgão público. Com a chave privada deste novo par, ele assina o certificado falso do órgão público, completando a falsificação iniciada no passo anterior. A chave pública deste novo par ele põe num certificado falso, cujo titular é a tal certificadora. Novamente, ele pode copiar ipsi literis o nome do titular que está no certificado verdadeiro desta certificadora, e o da certificadora desta, que seria, digamos, a AC-Raiz. Ele agora tem um certificado falso da certificadora que ainda precisa ser assinado, pela chave da AC-Raiz da ICP-Brasil.

No passo seguinte ele termina esta etapa: Ele gera mais um par de chaves, para fazê-lo passar por par de chaves da AC-Raiz. A chave pública deste último par ele põe no certificado falso da AC-Raiz. E com a chave privada desse novo par ele assina dois certificados: o certificado falso da certificadora do órgão público, completando a falsificação iniciada no passo anterior, e também o último certificado, este da AC-raiz, auto-assinado tal e qual o verdadeiro certificado da AC-Raiz. A cadeia de assinaturas falsas, que presumem a veracidade da identificação do signatário no documento fraudulento, está completa.

Ele agora apaga as três chaves privadas que gerou para aplicar este golpe, eliminando do seu computador as únicas possíveis provas documentais de fraude (só quem possui estas chaves privadas poderia ter produzido os certificados falsos!), e está pronto para se conectar com sua vítima.

Na conexão através da qual ele vai aplicar o golpe, isto é, apresentar o documento fraudulento como se fosse autêntico, ele precisa fazer o software da vítima usar os certificados falsos como se fossem verdadeiros. Se os certificados verdadeiros (necessários para a cadeia de verificação das asssinaturas envolvidas) já tiverem exemplares armazenados sob controle do software da vítima, o falsário pode, ou não (dependendo das configurações do software da vítima, de detalhes nos certificados verdadeiros, e do protocolo que abre a conexão), precisar antes forçar a troca dos mesmos. Neste caso um software embusteiro (um cavalo-de-troia) poderia ser usado para inseminar os certificados falsos no ambiente onde opera o software da vitima.

Se este software ainda não conhece exemplares dos certificados verdadeiros desta cadeia, ou se a inseminação dos certificados falsos não for necessária, basta ao fraudador configurar a conexão para que os certificados falsos sejam enviados junto com o documento fraudulento. Vamos examinar em detalhe o caso em que o software da vítima seja um navegador, ou outro programa que empregue o protocolo SSL para transacionar com documentos digitalmente assinados. Quando esses certificados falsos forem recebidos, este software perguntará à vítima se "quer mesmo aceitar aquele certificado auto-assinado da AC-Raiz da ICP-Brasil". Isto não lhe será surpresa, pois, para instalar o certificado verdadeiro da AC-Raiz, ele terá, ou teve, que responder à mesma pergunta, já que o certificado verdadeiro também é auto-assinado e tampouco vem com o navegador.

Como a ICP-B divulga no seu site a chave pública, e não o fingerprint do seu certificado auto-assinado, caso ele queira verificar se aquele certificado é mesmo o que a ICP-Brasil teria gerado, não terá como saber, pois o navegador só lhe mostra o fingerprint do certificado, e não a chave pública transportada. E mesmo que ele saiba qual é o fingerprint do verdadeiro certificado da AC-Raiz, e estiver usando o navegador Internet Explorer, ele não saberá se o fingerprint sendo mostrado na tela foi também copiado pelo falsário do certificado verdadeiro, ou se está sendo calculado pelo navegador naquele instante. E nem poderá saber, por si mesmo ou por alguém de sua confiança, pois o módulo de segurança que funciona com o Internet Explorer da Microsoft é inauditável.

Mesmo que a vítima já tenha passado por isto antes, ao instalar o verdadeiro certificado da AC-Raiz em seu Windows, ele poderá ficar confuso, achando que o navegador está lhe perguntando sobre o certificado da AC-Raiz já instalado por ele, e não sobre um que estaria lhe sendo enviado naquele momento, pelo interlocutor daquela conexão. Ou achar que se trata de uma renovação do certificado verdadeiro, já em posse do seu interlocutor mas não dele. Se estiver com pressa ou preguiça mental ele pode até desconfiar mas acabar racionalizando: afinal, a validade do documento, e sua presunção de veracidade, estão garantidas pela MP2200-2, já que aquele documento é da própria AC-Raiz da ICP-B, como ele próprio diz (o calcanhar de Aquiles!). Este seria um cenário onde o golpe através de certificados falsos seria mais fácil que o do "roubo" (vazamento) da chave privada da vítima.

Caso o falsário precise inseminar certificados falsos no ambiente de operação do software da vítima ele estará, em princípio, ainda diante de um ataque mais fácil que o do "roubo" da chave privada, pois precisa apenas alterar um ou mais arquivos neste ambiente, cuja codificação não envolve nenhuma senha da vítima. Se ele quiser fazer um serviço limpo, que não deixa rastro, o cavalo-de-tróia usado para o golpe pode ser acionado também para reestabelecer o estado anterior do software da vítima, após sua aceitação do documento fraudulento, em relação aos exemplares de certificados que mantém armazenados em disco. Se o falsário já negocia eletronicamente com a vítima, fica mais fácil contaminar seu ambiente com um cavalo-de-troia, pelo hábito de ambos trocarem arquivos pela rede.

Se necessária, a inseminação anterior da máquina da vítima com certificados falsos só será detectada se seu software antivirus vigiar adequadamente o software de verificação de assinaturas, mas cavalos-de-tróia feitos ou adaptados sob medida podem burlar qualquer anti-virus, se houver competência suficiente na sua confecção ou adaptação. Se o falsário não souber fazer tudo isso sozinho, há uma pizzaria em Brasília onde se reúnem semanalmente cibervândalos de aluguel, onde tal serviço pode ser contratado. Serviços corriqueiros já tem preço tabelado. Se e quando este tipo de golpe virar rotina, certamente suas variantes também terão preço tabelado.

E se a ferramenta para inseminação remota de certificados falsos falhar, resta sempre a alternativa do suborno ou ação furtiva para contaminar in loco a máquina da vítima. Neste caso seria suficiente, na maioria das situações, um disquete de boot e um curto circuito na bateria da BIOS para zerar a senha de setup do computador da vítima. Para detectar esta ação furtiva simples, o software de lavra e verificação de assinaturas teria que estar fazendo validação mediante senha dos arquivos que armazenam certificados. Neste caso a ação furtiva precisa de duas etapas: uma para capturar ou quebrar esta senha, e outra para modificar, de forma indetectável, o arquivo contendo os certificados no disco da vítima. Neste caso o golpe dos certificados falsos seria de mesmo grau de dificuldade técnica, e mais arriscado que o do "roubo" da chave privada, pois tende a deixar mais rastros.

Deste cenário de riscos decorre a importância de uma lei de assinatura digital se ocupar da segurança computacional do ambiente criptográfico no varejo, onde assinaturas são lavradas e verificadas pelo cidadão comum. A necessidade de tal lei se ater objtivamente às condições de operação dos sistemas criptográficos, cuja ação surtirá efeitos jurídicos diretos e indiretos por ela criados. Isto busca fazer, por exemplo, a lei italiana, que, depois de mais de cinco anos de debate, deixou claro seu objetivo de buscar a segurança jurídica da sociedade, e não os interesses deste ou daquele grupo, confessáveis ou não. Daí minha preocupação com a atribuição do comitê gestor para "homologar aplicativos", num contexto onde este comitê não exibe ainda o perfil adequado para compreender ou se sensibilizar com o impacto e a dimensão dos riscos à segurança jurídica da sociedade decorrentes das normas que dita.

Ademais, um contexto no qual o caminho de menor resistência para este comitê será justamente o de "sacramentar" o uso no varejo de ambientes computacionais dos mais promíscuos e vulneráveis possíveis. Isto é, os que hoje pululam o ciberespaço. A norma da ICP-B só se ocupa da segurança computacional no ambiente das certificadoras crendenciadas. A pressa com que o Executivo quer instalá-las, e pô-las em operação, ainda não está bem explicada, nem compreendida. Por sua vez, esta operacionalização precipitada, sob o atrativo dos desequilíbrios jurídicos da MP2200-2, pode ser o passo necessário par se criar "fatos consumados" que justifiquem passos seguintes no projeto virtualizante por detrás deste ucasse, como por exemplo, o da homologação de aplicativos por critérios obscuros ou mal explicados.

Como disse no artigo "O silêncio que produz ruídos", e explico em mais detalhes no início desta entrevista, a revogação retroativa sem possibilidade de auditoria externa nas certificadoras é um golpe muito mais limpo do que o "roubo" de chaves privadas ou o da falsificação de certificados em ambientes computacionais promíscuos. Doutra parte, é um golpe de possível interesse para quem estiver, no mercado do crime organizado, em posição oposta em relação ao da falsificação de certificados e "roubo" de chaves, mas facilitado pela justificativa de se ter que combater estes. A solução para os problemas aqui levantados certamente não estará, como já se cogitou, no Executivo negociar, a peso de ouro, a distribuição do certificado auto-assinado da AC-raiz da ICP-Brasil no navegador usado por nove entre dez estrelas, e nos obrigar a usá-lo como "garantia de validade jurídica das transações eletrônicas", algo semelhante ao que tentaram fazer os gestores do FUST em relação ao programa internet na Escola, com sua "garantia de sucesso no mercado de trabalho do futuro" para os alunos da rede pública do ensino médio e fundamental.

Não sabemos exatamente do que veio tratar o presidente da Microsoft com o Presidente da República, que o recebeu no Planalto em 20/8/01. Mas sabemos que sua empresa está negociando sua apenação por práticas monopolistas predatórias que vem exerendo no negócio em torno deste navegador. E também sabemos que ela deseja legitimar a ocultação, aos seus usuários, da verdadeira dimensão dos riscos a que estão se expondo através do uso de seus softwares, valendo-se de argumentos Kafkianos, através da recente fundação do OIS e de muito dinheiro para gastar com lobby e com mídia.

LG: E que solução o senhor sugere?

A solução para os problemas aqui levantados é a sociedade se aperceber das consequências do desequilíbrio jurídico na norma que o Executivo está querendo lhe impor, e demandar, dos outros Poderes, a correção de rota na evolução desta norma, em direção ao equilíbrio jurídico, antes que seja tarde. Caso contrário estaremos contribuindo, com nosssa omissão, para a construção de um Estado predatório, como o define Manuel Castells em sua monumental trilogia "A Era da Informação: Economia, Sociedade e Cultura", obra essencial para aprendermos a navegar no turbulento espaço de fluxos que tece a realidade contemporânea.

Aberrações Jurídicas com a ICP-Brasil