6- Discussão em torno de exemplos didáticos
Vamos ilustrar com exemplos a gravidade do que está aqui em jogo, didáticos o suficiente para tentar convencer os incrédulos dessa gravidade, mas não o suficiente para ofender possíveis atores com referências diretas à vida real. Para isso, precisamos examinar mais alguns detalhes sobre o processo de certificação, isto é, do processo de registro, emissão (assinatura) e revogação de certificados digitais.
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 criptográ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 apenas a pública..
O certificado faz também outras referências a chaves. Como precisa ser assinado para obedecer aos padrões vigentes (x509), 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 antes 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 esta verificação de integridade do certificado requer a chave pública do certificador, pressupõe-se que tal chave venha em um outro certificado. 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.
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 e titular de um certificado auto-assinado é alguem que se apresenta a si mesmo. 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 já vimos, 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 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 a AC-Raiz, e só ela, tem o direito natural de apresentar-se a si mesma com presunção de veracidade, para os que transitam por um novo portão por ela aberto, separando o mundo virtual do mundo jurídico. E que 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. 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. É uma lei esperta pois o legislador pode, através dela, instituir neste portão o pedágio que quiser, enquanto quem se beneficiar desta presunção poderá conduzir ou forçar seus interlocutores através do mesmo.
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 madeira no mundo da vida, 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 você aceite ou recuse os riscos envolvidos, na medida em que os perceba. Não ter a quem cobrar por eventuais prejuízos decorrentes de 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, a lei americana de assinatura digital (e-Sign) universaliza a interpretação subjetiva da veracidade das apresentações no novo portão dela. Segundo ela, ninguém tem ali qualquer privilégio em relação à presunção de veracidade. Fosse assim também a MP2200, isto é, omitisse ela o parágrafo único do artigo 10, a sedução do pedágio da certificação credenciada desapareceria para os grandes agentes econômicos e sociais, como panacéia para seus riscos se demandada aos cidadãos que queiram ou precisem contratar seus serviços, e a estrutura de castas em árvore se faria desnecessária para a certificação.
Em lugar desta árvore, uma malha de confiança para aceitação da autocertificação, baseada nas relações sociais do mundo da vida diluiria a vulnerabilidade da ICP-B ao calcanhar de Aquiles da autocertificação de sua AC-Raiz, a exemplo da primeira caricatura de ICP surgida na internet com o PGP, vulnerabilidade esta que comentamos em seguida. Entretanto, no que tem de ruim a lei americana, este direito de igualdade subjetiva nela opera para escamotear desequíbrios abissais em desfavor da cidadania, como comento em meu artigo "Uncitral". Numa e noutra, entre optar pela cidadania ou pelo Grande Irmão a lei escolhe, cada uma a seu modo, o segundo.
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 do seu 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 subsequentes neste portão, critérios 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 sustenta por exemplo, em meu entender, que a lógica desta justificativa não pode ser de natureza jurídica sem abalar vários pilares da tradição jurídica do país, referentes à natureza da fé pública. Tampouco pode ser de natureza técnica, pois as características dos sistemas não podem embasar a presunção de veracidade na identficação do signatário autocertificado, seja qual for sua titulação. Desvendar a verdadeira lógica desta justificativa é matar a charada da referida equidistância do hermetismo simplista da MP2200.
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, a maior autoridade do país, etc. Tudo isto oferece à sociedade apenas parte das garantias que ela deveria esperar e cobrar de tamanho privilégio e poder. Porem, 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 faz a segurança jurídica desta presunção. A saber, do elo cujo risco de ruptura é o uso sorrateiro da chave privada da AC-Raiz, 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 computador 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 com titulação e nome do certificador idênticos ao seu 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, sendo ambos auto-assinados? Ou então, como pode a sua autocertificação garantir proteção à chave privada de um signatário qualquer, contra quebra indevida de sigilo no seu ambiente? Depois de entendermos como e porque não podem, sobrará o poder de homologação do comitê gestor da ICP-B para oferecer as garantias que faltam ao vínculo jurídico que gerencia. Mas a homologação só poderá oferecer tais garantias se puder comprovar a segurança da operação dos "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. A segurança jurídica de uma assinatura digital de casta, isto é, presumidamente veraz quanto à sua capacidade de identificar o signatário, será tão forte quanto a mais fraca dessas garantias. Isto, os arquitetos do modelo americano perceberam logo e por isso as evitaram. 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, foi, em outras palavras, que o rei está nu!
Para enxergarmos através da roupa nova do rei, vamos descrever a mais simples das fraudes que explora a presunção de veracidade ditada pelo parágrafo único do artigo 10 da MP2200. Trata-se de uma fraude de documento eletrônico que se assemelha, 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. Porém, uma fraude com relação risco/recompensa desproporcionalmente distinta daquela, devido ao valor probante das possíveis provas do crime.
No caso da falsificação da carteira de motorista do chefe do DENATRAN, o promotor terá boas chances de sucesso caso responsabilize pelo crime um sujeito cujo rosto corresponde à foto na carteira falsa. Enquanto no caso do certificado, o promotor só terá 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. Esta fraude seria mais fácil que o "roubo" da chave privada da vítima pois, para consumá-la, bastará 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.
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. Na intimidade do seu computador desconectado da rede ele redige e assina este documento com a chave privada de um par por ele gerado 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 do certificado verdadeiro o nome do titular e o da sua certificadora, 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 do seu 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, pois só quem possui estas chaves privadas poderia ter produzido os certificados falsos, e estará pronto para se conectar na rede e aplicar o golpe.
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 se fizer 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 visitá-lo para verificar se o certificado sobre o qual seu navegador lhe perquire é 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 lhe estaria 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 a veracidade de sua autoria estão garantidas pelo parágrafo único do artigo 10 da 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 pode ser acionado também para reestabelecer o estado anterior deste software, após sua aceitação do documento fraudulento, em relação aos exemplares de certificados que mantém armazenados em disco, e depois deletar-se. 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 o software anti-virus ou outro software de segurança da mesma 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 grampear ou quebrar esta senha, e outra para modificar, de forma indetectável, o arquivo contendo os certificados no disco da vítima. Por exemplo, com a instalação via este boot de um rootkit contendo grampo de teclado. Ou numa intervenção mais limpa, que não suja os bits da vítima, via chip que se coloca dentro do teclado para grampear senhas. 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.