Privacidade e Riscos

num mundo de chaves públicas

Relatório sobre o tema "Privacidade e Responsabilidades
na Infra-estrutura de Chaves Públicas ICP-BR"

I Fórum sobre Segurança, Privacidade e Certificação Digital
ITI -Casa Civil da Presidência da República

Prof. Pedro Antonio Dourado de Rezende (*)
Depto. de Ciência da Computação, Universidade de Brasília
7 de Outubro de 2003

---

Índice

Sobre a Primeira Fase do Fórum

Introdução
Privacidade versus Interoperabilidade
Privacidade e Riscos

Epifania

Ato Primeiro
Ato Segundo
Ato Terceiro
Ato Final

As Quatro Damas do PKIpse

A inversão do ônus da prova
A certificação para uso geral
A raiz única
A quadratora do círculo

Conclusão

Bibliografia

Referências
Sobre o Autor

---

 
 

Sobre a Primeira Fase do Fórum

 

Introdução

O coordenador do Tema "Privacidade e Responsabilidades" do Fórum sobre Segurança, Privacidade e Certificação Digital, realizado em 2003 sob os auspícios do Instituto Nacional de Tecnologia da Informação, submete, através deste documento, relato das atividades correspondentes.

Na primeira etapa desta fase foram submetidos, sobre o referido tema, quatro artigos de autores distintos, e na segunda etapa mais quatro, sendo três de um mesmo autor.  Sob ângulos e pontos de vista distintos, os autores abordaram a aparente -- e não apenas aparente -- contradição entre a privacidade do titular de uma chave pública, vista como um dos quesitos de segurança de uma ICP, e a funcionalidade do certificado que titula e transporta essa chave, vista como seu objetivo primeiro.

Os autores ora levantam obstáculos legais, ora buscam remédio para tais contraposições, no amparo que o ordenamento jurídico oferece ao titular de certificado zeloso der sua privacidade. Pareceu-me que o consenso mínimo entre essas posições, objetivo desse relato, lastreia-se no senso comum e pode ser resumido no comentário postado pelo Diretor de Auditoria, Fiscalização e Normalização do ITI:

As resoluções da ICP-Brasil já garantem aos usuários o direito de escolher quais informações podem ser liberadas. Isto assegura a privacidade, mas pode impossibilitar o uso em futuras aplicações.

Esse denominador comum enseja, entretanto, um simplismo perigoso e enganador, cuja elucidação motiva o restante deste relato, e as sugestões apresentadas, em conclusão, visando o controle dos seus efeitos.
 

Privacidade versus Interoperabilidade

O direito do titular decidir quais informações "libera" ou "não libera" é limitado pela natureza do certificado. Certa quantidade de informação terá que ser liberada, sem a qual o certificado não servirá para aplicação alguma. A aplicação que usa o certificado precisa identificar univocamente o titular da chave, e esta unicidade não pode ser prejudicada pelo desejo de privacidade do titular, pois o transporte de chaves públicas assim tituladas é a utilidade mesma de certificados para uma ICP.

Por que o princípio da unicidade é importante? Porque a  ICP-Brasil pretende estabelecer, para o ordenamento jurídico brasileiro, força probante às assinaturas digitais lavráveis e verificáveis através dos meios que estabelece e regula. E qual a correspondência entre condição de unicidade e força probante? A correspondência surge da necessidade das assinaturas digitais cumprirem a função da assinatura de punho não só no espírito da ICP, mas também do ordenamento jurídico onde a ICP se insere.

Os meios para esse cumprimento precisam ser estabelecidos, pela ICP, através de padrões abertos (no sentido da publicidade e da transparência de significados) de forma tal a garantir, além de funcionalidade pretendida, um mínimo de interoperabilidade e auditabilidade às suas diversas aplicações, ou seja, aos softwares que usam certificados. Isto porque, diferentemente da assinatura de punho, que a mão lavra e o olho reconhece, à assinatura digital interpõe-se sempre a intermediação de algum software. Isto significa que um certificado é público num sentido bem amplo de transparência.

Esses padrões precisam obedecer, no mínimo, as condições sine qua non para a possibilidade do seu objetivo. E a primeira dessas condições é que cada certificado identifique, de forma unívoca perante as aplicações, o titular da chave pública transportada. Um certificado digital é uma estrutura de dados destinada a representar uma relação. No caso, entre uma chave pública que o próprio certificado transporta e uma identificação do seu titular. Certos atributos do titular, quer seja ele pessoa natural, jurídica ou funcional (um software), precisam estar ali representados em quantidade e qualidade suficientes para que alguma identificação social, que corresponda a esta titulação, possa ser univocamente reconstruída pela aplicação que irá usar o certificado.

 No contexto jurisdicional da ICP, e das premissas sobre conhecimento e uso da correspondente chave privada, o conceito de unicidade na identificação do titular corresponde à eficácia jurídica do valor probante de sua assinatura, já que, no mundo dos bits, é este conceito que substitui o reconhecimento físico -- de pessoas ou documentos eletrônicos propriamente ditos --  por terceiros.

A unicidade dessa identificação corresponde à garantia pública de que o titular, como se fez conhecer à certificadora, E APENAS ELE, poderia, em qualquer parte do território nacional, se fazer reconhecido por intermédio desses atributos: "João da Silva", apenas, seria pouco. E se a aplicação pressupor a comunicabilidade digital de "João da Silva", seu endereço de e-mail (ou equivalente) será atributo necessário, porém não suficiente. Se "João da Silva" for pessoa jurídica ou software, e não pessoa física, o significado da sua assinatura, isto é, o valor probante da mesma, muda.

Por isso, pelo valor jurídico pretendido à sua função, alguma privacidade precisa ser abdicada para que a identificação do titular de um certificado possa ser, ao mesmo tempo, univocamente construída pelo emissor, ao emitir o certificado, e univocamente reconstruída pela aplicação, ao usar esse certificado. A questão é: quanta privacidade precisa ser abdicada? A resposta simples é imprecisa: quanto maior o escopo de aplicações que se utilizariam do certificado, tanto maior será essa quantidade necessária. E quanto maior o escopo jurisdicional da ICP, tanto maior também.

A ICP-Brasil foi instituída por ato normativo do Poder Executivo equiparável a lei ordinária (Medida Provisória), como uma ICP que adota o modelo de certificação de raiz única, inicialmente regulada para operar com certificados de uso geral. Em outras palavras, uma certificadora credenciada na ICP-BR poderá vender certificados que sirvam para verificar assinatura em qualquer tipo de documento ou transação, com valor probante em todo o território nacional.

Se a certificadora atender a exigências severas de privacidade de um titular pessoa física, estará lhe vendendo um certificado de uso restrito, a um custo praticamente igual ao de um certificado de uso geral, que devassaria sua privacidade para garantir unicidade a uma vasta gama de aplicações. A utilidade do certificado será, portanto, inversamente proporcional à privacidade que preserva. Este princípio será fato notório com a primeira geração de aplicações habilitadas para a ICP-BR, que usarão, além dos certificados, bases de dados legadas de versões anteriores à ICP-BR, carentes de um identificador universal compartilhado e único.

Doutra parte, um identificador universal e único para a ICP-BR não evitaria o choque entre privacidade e interoperabilidade. Apenas o escamotearia, distribuindo informações que doutra forma estariam no certificado, mas que serão por ele interligadas. Assim, o princípio da economicidade no negócio da certificação se choca com o da proteção à privacidade, mas este choque é apenas a parte visível de uma considerável horda de problemas.
 

Privacidade e Riscos

Abaixo da superfície avistada em belas interfaces gráficas, a flutuar no oceano de informações da era digital, circulam correntes onde choques bem mais graves que este ocorrem. Uma ICP põe em marcha uma dinâmica não linear de propagação de riscos e responsabilidades, ainda mal compreendida, mas com desequilíbrios catalisados pela arquitetura e modelo normativo escolhidos para a ICP-BR. Nesse ponto, esse relatório precisa mudar de tom e escopo.

É que, quando se fala de riscos na informática, uma legião de tecnófilos se põe logo em pé de guerra. Adeptos de uma perigosa seita, formada por gente que gosta de usar terno preto e acredita na santificação por meio de rituais de beberagem, se entrincheiram na defesa da sua fé. É a seita dos que crêem, ou agem como se cressem, que a ingestão de uma mistura de domínio tecnológico e poder político transforma programadores em seres angelicais. Quanto mais alto o perfil de riscos dos sistemas que informatizam ou querem informatizar, como ICPs e processos eleitorais, mais imune a tentações, a falhas de projeto e a agendas ocultas se arvoram seus beatos.

É a seita do santo byte. Para seus fanáticos, riscos na informática são adolescentes desajustados e rancorosos que fuçam ou programam por conta própria. Hackers, cada vez mais confundíveis com adeptos do software livre. Quem ousa dizer que sua beberagem pode induzir efeitos colaterais perigosos, que se manifestam na forma de riscos para a sociedade usuária dos seus sistemas, estaria, segundo eles, possuído pelo demônio da tecnofobia. Paranóico, antiquado, ignorante da realidade. Quanto ao perigo do crime organizar-se sob o excesso de poder, dizem: "É mito". Não há provas do crime organizado agindo dentro da indústria da informática.

Eis a questão: o que significa não existirem tais provas? Das duas, uma. Ou programadores se santificam mesmo com a informatização do poder, ou a produção e uso de softwares precisam ser melhor fiscalizados por quem se vê alvo dos seus efeitos. A resposta para esta questão shakespeareana é um ato de fé. Mito, como dizia Carl Jung, é religião alheia: o de cada um se chama realidade.

Como acadêmico e representante da sociedade civil junto ao comitê gestor da ICP-BR, o autor deve buscar a imparcialidade. Nesse relato, não deve professar qualquer fé que lhe mova. Resta-lhe, então, apenas narrar a epifania vivida como moderador desse tema.
 
 

Epifania

Ato Primeiro

Certificação e assinatura digitais não existem no vácuo. Terão valor apenas quando assentadas sobre as premissas de confiança previstas em sua semiologia, isto é, pela própria conceituação que as definem. Para terem esse valor, certificação e assinatura digitais não demandam apenas a implementação sadia dos softwares, padrões e protocolos correspondentes. Sua operação deverá, também, estar assentada em dois pilares a serem erguidos no mundo da vida, externos à ICP.

Esses dois pilares são a confiança na singularidade do segredo da chave privada que lavra, e a confiança na origem da chave pública na raiz de uma cadeia de certificados que valida, assinaturas digitais. A externalidade dessas premissas é incontornável. No padrão X.509, por exemplo, uma chave pública raiz é transportada em um certificado dito auto-assinado. O transporte deste certificado não pode ser pela ICP, sem que esse certificado internalize-se na cadeia, deixando de ser raiz.

O transporte externo de um certificado auto-assinado é necessário para finalizar o que, doutra forma, seria uma cadeia infinita de certificação. Um certificado auto-assinado será ponto de confiança para a verificação de assinaturas, isto é, ponto onde confiança externa precisa ser injetada no processo, pois, sendo necessário, ele nada prova sobre si mesmo além do fato de que quem o emitiu estava de posse, ao fazê-lo, da chave privada correspondente. Um certificado auto-assinado nada garante sobre a identidade do emissor nele nomeado, garantia esta que se supõe, por isso, externa aos elementos da ICP.

A questão que se coloca é: como avaliar a solidez desses pilares? Há que se conhecer, primeiramente, as características sísmicas do terreno onde se erguem. Esse terreno é o ambiente computacional onde operam as aplicações habilitadas à ICP, onde chaves privadas e certificados auto-assinados precisam ser armazenados. Para avaliar esse risco de natureza sísmica, a ciência atuarial permite-nos validar a seguinte regra empírica:. O terreno tenderá a sofrer maremotos em magnitude equivalente ao maior dos valores que os pontos de confiança representam, para titular, validador e potencial fraudador, e com freqüência inversamente proporcional ao risco de punição para o último, podendo este se confundir, vale lembrar, com qualquer dos primeiros.

Ilustremos com um exemplo. Aquele que vier a comprar um certificado ICP-BR de uso geral, quando quiser um apenas para pagar impostos, por exemplo, estará atraindo ao seu computador a cobiça de falsários que poderão invadi-lo pela internet para copiar sua chave privada ou para induzi-lo a assinar, sem saber, documentos falsificados em seu nome. Transferências de imóveis, aberturas de conta-corrente, registro de empresas, contratação de crédito, de serviços, etc., poderiam assim ser fraudados. E o titular só vai descobrir quando confrontado com os efeitos dos atos jurídicos daí ensejados.

O que ocorreria num caso desses? A resposta pode estar no parágrafo primeiro do artigo 10 da MP 2200-2, que instituiu a ICP-BR. Prevalecendo a interpretação dos que a defendem, significa inversão do ônus da prova. Nesse caso, caberá ao titular do certificado provar que não foi ele quem comandou a lavra da "sua" assinatura digital nos documentos que ensejaram tais atos. E não podendo identificar positivamente quem o teria feito, remotamente ou em seu próprio computador [1], ficaria com a responsabilidade e/ou os prejuízos pelos mesmos.

Como pode, então, um titular proteger sua chave privada? Pode-se ver, hoje, que quase ninguém pode. Nove em cada dez pretensos titulares teriam que delegar a guarda da sua chave privada a um sistema operacional inauditável e praticamente improtegível, cuja vulnerabilidade contra invasões vem sendo cada vez mais furiosamente escamoteada [2].

Enquanto a inversão do ônus da prova, aliada ao uso geral de certificados, valoriza no mundo do crime o conhecimento furtivo da chave privada de quem tenha posses, crédito ou bem intangível a ser destruído, como a honra, por exemplo. O artigo "Responsabilidade e Escolhas num mundo de chaves públicas" [2], da primeira fase deste Fórum, analisa, em profusão de detalhes e referências, o risco associado a este valor. Nesse ponto, podemos ouvir ecos de uma cantilena do santo byte: "nunca se comprovou que esse tipo de fraude vem acontecendo na vida real!". "Pode-se também optar por um smart card". "Trata-se de paranóia, ideologia anti-isso, anti-aquilo."
 

Ato Segundo

A história da ICP-Brasil nos ajuda a compreender a cena. A ICP-Brasil surgiu de uma canetada do presidente FHC, em 28 de junho de 2001, na Medida Provisória 2200. Esta medida estendeu uma iniciativa que até então vinha sendo internamente debatida, para se regulamentar uma infra-estrutura de chaves públicas para o governo federal. Esse debate foi suspenso e a regulamentação abruptamente extrapolada a toda a sociedade, atropelando anos de debate e vários projetos de lei que tramitavam no legislativo federal.

Como restou comprovado pelas modificações em reedições subseqüentes, não teria havido reflexão suficiente acerca dos efeitos colaterais desta extrapolação. Quem seriam os seus maiores interessados? Num seminário promovido pela OAB, um mês depois, para debater o tema, e na imprensa desde então, só uma entidade tem se manifestado em defesa do texto e do espírito da MP 2200: a Febraban [3]. E é fácil entender porque.

A internet possibilitou um novo nível de automação de serviços bancários, que seus filiados aproveitaram com otimismo e menos cautela do que é praxe no ramo. Orgulham-se de ter saído na frente, em uma desabalada corrida por contenção de custos e pioneirismo na oferta de novos serviços a clientes, através da grande rede aberta, corrida que destacou nossa indústria entre seus pares no mundo. Como foram avaliados os riscos? De forma precária. Avaliar riscos que se propagam de forma não linear, como os de invasão e fraude através da internet, não é ciência exata e tem muito de chute. O otimismo entrou nos chutes.

"O risco de fraudes pela internet é irrisório". "Os incidentes são esporádicos e raros". "Investiremos em futuras tecnologias de proteção, conforme a relação custo/benefício". O mesmo já se disse, e segue sendo dito, sobre spam, ataques de DoS, vírus e vermes que exploram vulnerabilidades instaladas por uma cultura monopolista que confunde segurança do monopólio com segurança do usuário dos seus produtos. E que se mantém no estado de confusão graças ao marketing monopolista, ao fascínio coletivo pela tecnologia-enquanto-panacéia, e à moralidade capitalista nos quais se ampara. São "as maiores marcas do planeta!", gaba-se uma revenda da capital federal, em anúncios diários de meia página. É a crença no santo byte, removendo montanhas.

Porém, com a evolução da cultura criminal eletrônica, a indústria bancária brasileira veio a perceber que a sangria de seus ativos, a título de fraudes irrecuperáveis, não arrefece com "mais investimento em segurança". Ocorre que segurança não é orégano de pizza, que se acrescenta antes de se levá-la ao forno. A indústria continua em destaque entre seus pares no mundo, só que agora por motivos menos nobres. A saber, pelo altíssimo custo do crédito, oficialmente atribuído à inadimplência. Ocorre que os números revelados, postos em relação, não batem com a explicação. Enquanto os números sobre fraudes irrecuperáveis precisam ser dissimulados. Como atacar o problema, corrosivo para o principal ativo da indústria, que é a credibilidade?

Primeiro, observe o leitor que o que torna irrecuperável certos tipos de fraude pode ser uma combinação de tecnologia e lei. Alguém, por exemplo, que empresta seu cartão de débito a um terceiro para, em conluio, repartirem um saque que o titular irá depois refutar, acusando o banco de ter permitido a clonagem do seu cartão, é um golpe que encontra guarida no código de defesa do consumidor: como o sistema informático é propriedade do banco, e o banco não pode provar que se trata de golpe, deve ressarcir o cliente-estelionatário.

A saída encontrada? Declara-se de caráter público a parte do sistema informático que presta serviços financeiros pela internet, baseando-se a identificação de clientes na singularidade do segredo e, em conseqüência, a classificação do serviço em lei ordinária (assinatura digital pela ICP-BR), possibilitando a inversão do ônus da prova. O problema? Tecnicamente, a inversão do ônus da prova pressupõe que as premissas expressas nos dois pilares de confiança de uma ICP estejam de antemão asseguradas.

Mas uma dessas premissas -- a da singularidade do segredo da chave privada -- depende do cliente. Da sua cultura, da sua escolha de ambiente computacional, ambos agudamente precários. Solução temporária? Ignorar tal premissa na lei provisória, enquanto se busca alguma "tecnologia de proteção". Mais do mesmo. A aposta, desta vez? Uma tal tecnologia estará em uso antes que a "solução" temporária se torne um problema maior. Eis, então, o parágrafo primeiro do artigo 10 da MP 2200, que perpetua a estratégia de se solucionar um problema agudo atual com uma semente para o problema seguinte.

"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..."

Ato Terceiro

Embora os métodos para se avaliar riscos que se propagam de forma não linear sejam precários, eles podem se valer, no caso em tela, de invariantes semiológicos, já que a internet é, ao mesmo tempo, um processo e um conjunto de técnicas para comunicação intermediada por rede digital aberta, e neste sentido equivalente a um idioma, com a peculiaridade deste precisar ser intermediado por castas de tradutores automáticos e ubíquos.

O risco de se depender de interlocutores de castas que se restringem a dialetos (vendor lokin), na luta dos seus "proprietários" por predomínio semiológico, que se traduz ao economês em solidez de posição no mercado de TI, é o cerne da batalha entre os modelos de negócio proprietário e livre/open-source, cujo resultado certamente influirá no perfil da segurança jurídica oferecida por uma ICP, conforme comentaremos adiante. O modelo livre/open-source vê o software como linguagem, e o seu negócio baseado no serviço, enquanto o modelo proprietário vê o software como propriedade, e o seu negócio baseado na venda de licenças de uso.

Nesse tipo de avaliação, a abordagem semiológica tenderá a acertar nas médias globais, mas sua adoção tende a esbarrar em estratégias locais, de se empurrar a questão, como diz o ex-ministro Delfim Neto, com a barriga econômica. Do ponto de vista semiológico, a estratégia local de barrigadas é irracional, já que o próximo problema tende a ser mais complexo, e de solução mais difícil, do que o problema agudo atual. No caso em tela, como argumentaremos nas últimas sessões deste relato, as escolhas de modelo e arquitetura para a ICP-BR consolidam como fato aquilo que, no caso geral, seria apenas tendência.

Outrossim, ninguém ousa, do ponto de vista econômico, questionar as barrigadas, por se tratar daquilo que se conhece por "auto-correção dos mercados", na mitologia fundamentalista neoliberal predominante. A Febraban nunca escondeu seu interesse e seu lobby pela MP 2200. Diante desse fato, a "auto-correção dos mercados" constitui a melhor explicação disponível para a escolha da semente para os nossos futuros problemas de segurança digital. Trata-se da escolha mais propensa a induzir agentes sociais e econômicos à transição ou adesão à ICP-BR, que por sua vez induzirão, em cascata, agentes que agregam em menor peso, e cidadãos comuns.

Raiz única, certificados de uso geral e inversão do ônus da prova compõem o portfólio capaz de atrair, com maior eficácia, agentes que desejam se livrar dos riscos e responsabilidades na administração digital dos seus serviços e operações, e que estejam em condições de bancar tal desejo. E esses, por sua vez, incumbir-se-ão de atrair, para dar eficácia à motivação do desejo, seus clientes de varejo ao maravilhoso mundo dos certificados digitais. Para onde irão os riscos? Os riscos estão sendo exorcizados por rezas do santo byte. Quanto ao choque entre modelos negociais? Ninguém propenso a barrigadas verá ineficiências no seu próprio modelo.

A palavra de ordem, a senha para a modernidade, é: "abaixo a escravidão do papel, viva o byte libertador!". Não importa se o exorcismo não funcionar. Não importa se o custo desta transição for um crescente desequilíbrio global dos riscos e responsabilidades envolvidos. A saber, os do titular de um par de chaves, pelo uso fraudulento de sua chave privada; os do usuário de certificados, pelo reconhecimento embusteiro de assinatura falsificada; os do emissor de certificados, por falsidades rastreáveis à sua inépcia ou má fé; e os do ordenamento jurídico, pela ineficácia probante advinda da inauditabilidade do software proprietário: tudo em grau proporcional à disseminação de uso por ela mesma induzida.
 

Ato Final

Uma primeira reza apregoa que só nos resta dar partida na transição, rumo ao mundo dos santos bytes. Só nos resta acionar o Estado para que saia na frente, assumindo custos, riscos e responsabilidades de emissor dos primeiros certificados e de ressegurador da certificação, já que cabe a ele, é claro, promover a "inclusão digital". O Estado precisa ser induzido, seduzido ou conduzido, nessa ordem de preferência, a cumprir o papel que lhe reserva a lógica capitalista, nessa transição que representa a próxima etapa da sua inexorável marcha pela fetichização da mercadoria. A reza seguinte é o oba-oba, na mídia cartelizada, de loas à salvação econômica e social através da inclusão digital.

Estaria a história dos vírus, da bolha da internet, do spam, a se repetir? Talvez não, pois o nível de fanatismo está atingindo níveis inusitados, e as conseqüências podem atingir patamares também inusitados. Com essa transição, a mercadoria por excelência passa a ser a confiança nos bytes, enquanto, sobre o processo, as críticas são rebatidas com rezas da seita que os santifica: "ninguém provou nada sobre riscos em ICPs", "Trata-se de paranóia tecnofóbica de ignorantes, ideologia anti-isso, anti-aquilo". Amém

Se essas rezas têm servido à indústria monopolista de TI, para induzir dependência e riscos asfixiantes num mercado ávido por produtividade, viciando-o com sua beberagem modernosa, por que não funcionaria com vistas a uma aliança tripartite, na qual a indústria monopolista de TI, a indústria financeira e o Estado se juntam para promover essa transição, repartindo a nova estrutura de poder que daí emergirá?

É notável que, em meio a manchetes explicando nosso purgatório de escassez em créditos internacionais, atribuível à irresponsabilidade administrativa do nosso Estado, haja crédito abundante em Washinton para financiar a instalação de salas-cofre de certificadoras em órgãos estatais brasileiros. Caixa, Correios, Serpro, e por aí vai. É notável, também, a transformação sofrida por este Fórum, desde sua fase inicial virtual até sua fase presencial, na qual uma tal aliança finalmente se delineia com precisão, na programação dos eventos.

Mas, como toda aliança, uma assim apresentaria riscos e compromissos, requerendo planejamento, negociação e salvaguardas. O processo cultural que complementa a alardeada transição precisa ser controlado, de forma a neutralizar o anseio humano por liberdade e autonomia semiológicas, que pode assaltar o livre pensador e contaminar formadores de opinião. O mundo dos bytes precisa ser percebido como o único a conferir legitimidade ao conhecimento e à informação nesta nova era, mas não antes de se planejar os meios e os termos para a partilha do seu controle. Podemos detectar sinais desse planejamento?

Haja vista a origem e evolução da ICP-BR, e como explico adiante, o Brasil surge em cena como potencial laboratório para ensaios desse tipo de aliança, com o Estado em papel coadjuvante. Como já dito, o modelo e a arquitetura aqui adotados induzem uma transição à ICP a custos de crescente desequilíbrio de riscos e responsabilidades. Induzem-na através do interesse de grandes agentes em se livrar dos riscos jurídicos na manipulação de documentos, transferindo-os para os clientes dos seus serviços ou operações, lá amplificados na medida em que mais agentes aderirem a ICP-BR, e menos alternativas de contratação restarem.

Esses elementos, a saber, a inversão do ônus da prova, o uso geral dos certificados e a a raiz única, são finalmente analisados em detalhe suficiente a nos permitir chegar a uma conclusão neste relato. Antes disso, porém, o desfecho desta Epifania irá contextualizar o primeiro desses elementos, a inversão do ônus da prova.

É comum no Direito, com respeito a provas documentais, o entendimento de caber àquele que as apresenta provar sua autenticidade. A prática contrária, aparentemente instituída pela ICP-BR, é chamada de inversão do ônus da prova, objeto do conceito de fé pública em nossa tradição jurídica.

Porém, a justificativa para esta inversão, na MP, aparenta estar desvinculada do conceito de fé pública, pois a mesma mescla interesses e atribuições públicas e privadas. É mais provável que tenha ali sido inspirada numa recomendação da UNESCO, que produziu, há cinco anos, um "modelo de lei de comércio eletrônico" [4], sob lobby da BSA (Business Software Alliance), entidade que alia os maiores players da industria monopolista do software proprietário.

Restam, como justificativas na MP 2200: de forma indireta, os rígidos critérios estabelecidos para credenciamento e auditoria (interna à ICP-BR) das entidades certificadoras aderentes à ICP-BR; e, de forma que se pode entender como direta, o parágrafo único do artigo 6o., que contém linguagem à qual se poderia pretender ampará-la, porem não sem problemas. É que esta linguagem constitui verdadeira aberração, tanto semiológica quanto jurídica:

Parágrafo único. O par de chaves criptográficas será gerado sempre pelo próprio titular e sua chave privada de assinatura será [sic.] de seu exclusivo controle, uso e conhecimento.

Uma norma jurídica não pode decretar um estado cognitivo para todos os seres humanos, a saber, o estado de desconhecimento ou desuso duma seqüência de zeros e uns a constituir chave privada alheia. Da mesma forma que não pode criar ou revogar leis naturais, como a lei da gravitação universal, ou como as leis propabilísticas da semiologia em que se assenta a ciência criptográfica. Das leis naturais ou semiológicas, uma norma jurídica pode apenas reconhecê-las (no que seria inócua), a menos que o legislador se divinize em um demiurgo platônico, lapso freqüente nos adeptos do santo byte.

Um simples truque, em poucas linhas de código, no software gerador de chaves criptográficas pode negar esse estado decretado, se um conhecedor do truque assim desejar, independente do grau de cautela e diligência, infinito que seja, exercido por um titular zeloso do cumprimento de tal ditame. Com agravante: a inauditabilidade do software, que torna indemonstrável esta negação, se estiver blindada por direitos "de propriedade intelectual" e de "segredos de negócio".

Ademais, longe de tais violações serem hiptóteses paranóicas apenas, a hubris do legislador é tão grave que sua Lei será violável, acidentalmente ou não, sempre que o par de chaves seja gerado, pelo titular, por intermédio do navegador web embutido no sistema operacional usado por 9 entre 10, clicando "OK" em todos os passos. A chave privada de assiatura estará sob controle, e disponível para uso, de qualquer um que iniciar o sistema, sistema esse que nas versões 95, 98, Millenium e CE não terá qualquer controle de acesso. É só verificar.

Não se pode confundir as propriedades semiológicas da criptografia assimétrica que permitem à assinatura digital fazer prova de autoria e autenticidade sobre bytes, com as condições de admissibilidade das mesmas. Desnecessário alertar, novamente, sobre o perigo de se sofismar com ausência de provas (no caso, provas de inadmissibilidade), como em mantras do santo byte. Ausência de prova de inadmissibilidade não é prova de admissibilidade (Deus existe?), e melhor seria que todos despertassem, quando o assunto for ICP, da alucinação mística que as iguala. No contexto ao qual se dirige, a última frase do parágrafo único do artigo 6 equivale a "Não cobiçarás a chave privada do próximo", que pega melhor em parágrafo único de mandamento religioso, do que de um artigo de uma MP sobre ICP.
 
 

As Quatro Damas do PKIpse

A inversão do ônus da prova

É necessário o entendimento racional de que a condição decretada, como estado cognitivo, pelo disposto no parágrafo único do artigo 6o. é, antes que tal estado seja, condição de admissibilidade para o uso sadio e pretendido das ditas chaves criptográficas, não se podendo presumir, portanto, que tal estado decorra da primeira parte do dispositivo. Quer do estado natural ou diligente do titular, quer da primeira condição decretada no mesmo dispositivo (condição sob a qual o titular deva gerar seu par de chaves), quer de ambas.

Ademais, normas decretando condições de admissibilidade à certificação de chaves púbilcas e à validação de assinaturas digitais, objeto do restante da lei, nada tem a ver, e nada podem influir (salvo algum mistério sobrenatural), nas condições de controle, uso e conhecimento das correspondentes chaves privadas. E este fato se reveste de importância na medida em que ambas condições constituem os dois pilares de sustentação de uma ICP. Ao invés de conjugar o verbo "ser" no futuro do imperativo em sua segunda ocorrência, citada in verbis acima, deveria a norma conjugá-lo em modo condicional composto, caracterizando a condição como de admissibilidade.

A robustez de um dos pilares da ICP não pode se sustentar sobre erros gramaticais, e uma ICP sustentada em um só pilar nada significa para a segurança jurídica pretendida. Significa, outrossim, algo para o marketing de uma tal aliança, já que tal situação lhe basta para ocultar o papel essencial do outro pilar. Mas como uma Lei funcionará mal se redigida como peça publicitária, isto é, como um tal ocultamento terá efeito temporário (todavia crucial para a partida da transição à ICP-BR), promoveu-se, ato seguinte, a padronização do uso de tokens criptográficos (smart cards e dispositivos dedicados a armazenar e operar com a chave privada).

Mas novamente, o uso de tokens ainda não garante solidez ao outro pilar, e consequentemente, à segurança jurídica pretendida. Mantido o status quo atual, o token quase certamente estará operando sobre sistema operacional monopolista e praticamente indefensável. Neste cenário, o único risco que um titular com token criptográfico estará apto a controlar é o da leitura indevida de sua chave privada.

Permanece o risco da lavra cega de assinaturas, pois o sistema pode ser invadido por um programa que induz o token a assinar documentos outros, ao invés ou além daquele que se vê na tela, no momento em que se aciona a chave privada para lavrar assinatura. Poderá ser invadido, quer através das várias portas de fundo embutidas em sistema proprietário, pelo fabricante, para "gerenciar seus direitos digitais" (16 portas de fundo na versão XP []), quer através das vulnerabilidades que inevitavelmente decorrem de tal complexidade e obscurantismo.

Entretanto, o maior risco que a inversão do ônus da prova representa para o titular não é o dele ser induzido, por programas espiões, furtivos, embusteiros ou totalitaristas, a assinar documentos desconhecidos, sob o ônus da prova de fraude. Pode ser que a conveniência compense ao titular esse risco. Afinal, segurança tanto é risco aceitável, quanto o inverso da conveniência. Cada um que meça as suas com suas próprias escalas. O maior risco que se corre é o de não se ter escolha.

Se prestadores de serviços obrigatórios, como os tributários, os financeiros e os civis (ex: eleitorais), avaliarem que tal inversão lhes compensa, mas que seus clientes, pelos mesmos motivos, não iriam aceitá-la, poderão inviabilizar alternativas, por qualquer meio a seu alcance (a Justiça Eleitoral, por exemplo, é nisso escolada e mestra). Não havendo alternativas, tampouco haverá controle sobre a qualidade do serviço, qualidade esta que compensaria os riscos associados à responsabilidade pela guarda da chave privada. Este é um claro exemplo de como riscos se propagam de forma não linear, através de bytes.

A posição da Febraban em relação ao parágrafo primeiro do artigo 10 da MP 2200, que, segundo ela, estaria invertendo o ônus da prova de autenticidade de documentos digitalmente assinados sob o signo da ICP-BR, parece clara: a Febraban o considera o cerne inegociável da iniciativa de se instituir uma ICP Brasileira. É a posição que melhor se ajusta ao contexto do seu lobby pela MP, comentado no segundo ato da Epifania aqui narrada.

Explica melhor, inclusive, que a versão oficial a respeito, qual seja, a necessidade de se legitimar o Sistema de Pagamento Brasil (SPB). Pois o SPB é um sistema de compensação eletrônica do Banco Central para operações financeiras entre bancos. Sempre foi, e continua sendo, uma rede virtual fechada que opera sobre TCP/IP. E as redes fechadas apresentam premissas de confiança totalmente distintas das redes abertas, como a internet, que é o meio semiológico subentendido e subjacente à ICP-BR. A ubiqüidade dos protocolos TCP/IP não deve nos confundir.

Ademais, o SPB não serve de parâmetro para os riscos engendrados pela MP 2200, não só porque seria como medir bananas com laranjas -- segurança em redes abertas com a de redes fechadas --, mas também porque é inútil sofismar sobre o significado da ausência de provas. Afinal, conforme relatado em [3], desde a aprovação da Lei 9613 contra lavagem de dinheiro, há cinco anos, só houve uma condenação, nenhuma pelos sucessivos escândalos que sinalizam perigosos conflitos de interesse na fiscalização das entradas e saídas desse sistema [5].

Para validar esta hipótese, podemos observar como a Febraban se comporta em relação aos imponderáveis, na sua defesa da MP 2200. Há o risco de que a MP seja declarada inconstitucional, mas esta possibilidade estaria situada em horizonte temporal longínquo e previsível. Há um outro risco, mais imediato, que é o de conflito com o código de defesa do consumidor (CDC), sob o qual já se estabeleceu jurisprudência contra associados, em indefensáveis posições de vulnerabilidade a fraudes, em serviços considerados indispensáveis, aqui comentada.

Talvez não por coincidência, a Febraban já havia ajuizado ação pela restrição jurisdicional do CDC, visando reverter tais posições e jurisprudência, ação que está para ser julgada no STF: uma decisão favorável à Febraban eliminaria o citado risco imediato de conflito jurídico, abrindo caminho para que vija sua interpretação do parágrafo primeiro do artigo 10 da MP 2200 (inversão do ônus da prova); uma decisão contrária, e o espírito mesmo da MP 2200 terá que ser testado em tribunais (poderia a MP declarar inversão do ônus da prova, contra atual jurisprudência?).

E como anda esta ação? O ministro Nelson Jobim pediu vistas, retendo o processo além do prazo regimental para vistas. O que nos leva a outro imponderável. Por que esta ação é uma das 77 no STF que, segundo matéria do jornal Tribuna da Imprensa do Rio de Janeiro de 5 de Outubro deste ano, interessaria ao ministro Jobim reter delongadamente "para vistas"?
 

A Certificação para Uso Geral

Outro ponto de feroz resistência a mudanças no arcabouço da ICP-BR, por parte dos que defendem sua configuração original, diz respeito à regulamentação de políticas de uso de certificados. Uma política de uso de certificados é um mapa que representa, externamente para usuários, e internamente para softwares de aplicações que usem certificados, a função normativa, nos planos jurídico e negocial, das assinaturas e cifras que os mesmos permitem lavrar, validar e operar.

A MP 2200 outorga ao Comitê Gestor (CG) da ICP-BR, no inciso V do seu artigo 4o, a competência para "estabelecer diretrizes e normas técnicas para a formulação de políticas de certificados e regras operacionais das AC e das AR", e no inciso VI a de "aprovar políticas de certificados, práticas de certificação e regras operacionais, credenciar e autorizar o funcionamento das AC e das AR". O padrão X.509 v3, adotado pela ICP-BR, prevê a codificação de políticas de uso nos certificados, e uma das normas do CG ICP-BR estabelece como obrigatória uma política de uso geral, estratificada por nível de certificação.

O que significa, entretanto, "uso de certificados"? Pode significar que uma aplicação habilitada à ICP-BR seja obrigada a reconhecer a titulação, se válida, de uma chave pública que tenha sido emitida por qualquer entidade certificadora credenciada para o seu nível. Mas pode também significar a obrigação da aplicação aceitar termos e condições em documentos cuja lavra ou autoria um tal certificado identifica. A primeira seria uma condição de admissibilidade, uma obrigatoriedade em modo conceitual, para o uso geral de certificados. E a segunda seria uma imposição à lógica negocial da aplicação, uma obrigatoriedade em modo funcional, desse uso geral.

Se a linguagem da norma permitir interpretações múltiplas, será mais um imponderável a turvar -- e amplificar -- a propagação de riscos. Uma tal medida, turva ou clara, pode ser vista como motivada pelo princípio da economicidade. Agentes dispostos, ou de uma forma ou outra obrigados, a participar da ICP-BR não precisariam adquirir vários certificados de acesso a distintos serviços digitalizados, públicos ou privados. Porém, por outro ângulo, é uma medida que propaga riscos de forma não linear, como já comentado, prnicipalmente se ao titular não restar alternativa.

Se as certificadoras credenciadas se cartelizarem na uniformização de suas políticas, pode ocorrer que as escolhas dos titulares venham a ser limitadas, induzindo-os à compra de certificados com cláusulas de uso geral, no sentido funcional.  Esse problema foi levantado por vários autores na primeira fase, porém, no geral, apenas em relação aos riscos à privacidade. As certificadoras poderiam se ver motivadas a alavancar seus negócios, com outros serviços, através de um tal viés de uniformização, porém, à custa da exposição máxima dos titulares aos riscos associados à responsabilidade pela guarda da chave privada, conforme já comentado.

Passando agora do plano normativo ao técnico, um dos possíveis motivos para alianças estratégicas entre fornecedores de tecnologias e serviços seria a manutenção e consolidação de dependências da sociedade. ESte motivo pode também manifestar-se em viés nas políticas de certificação, de forma a afunilar a interoperabilidade, e a distribuição dos riscos e responsabilidades, dentro dos parâmetros e limites estabelecidos por acordo, pressão ou chantagem, que por razões óbvias não seriam publicamente admitidos. Se, ao Estado, couber papel coadjuvante nesse tipo de aliança, quer por inação, inabilidade, ou incompetência, quer por decisão política, caber-lhe-á o grosso dos riscos e responsabilidades, conforme comentado no ato final da Epifania aqui narrada.

Como o Estado não alcança controlar diretamente interesses privados numa tal aliança, resta-lhe o controle do seu papel, que pode, doutra forma, estar sendo desenhado à sua revelia. Para isso, deve se valer, com eficácia, da competência normativa que lhe atribui a legislação vigente. A política de uso geral vigente na ICP-BR pode portanto, à luz do lobby que entoa a segunda reza do santo byte, e das posições já assumidas, também ser vista como um atrator ali plantado para que o Estado aceite papel coadjuvante. Uma sugestão sobre como o Estado pode bem organizar a eficácia do seu papel será objeto da conclusão deste relato.
 

A raiz única

Uma infra-estrutura de chaves públicas não é apenas uma Lei, ou, no nosso caso, como disse a Folha de São Paulo em editorial, um ucasse. É um conjunto de regimes normativos, procedimentos, padrões de formatos, algoritmos e protocolos digitais, e, finalmente, implementações de softwares e serviços que disponibilizam e/ou viabilizam o uso interoperável e escalável da criptografia assimétrica em rede digital aberta, compatíveis com tais padrões. O desafio de quem planeja e implementa uma ICP é manter interoperabilidade e eficácia normativa diante dos obstáculos apresentados pelo requisito de escalabilidade.

Estratégias para se dominar tal desafio são mapeadas em arquiteturas e modelos. O modelo de certificação, por exemplo, descreve as relações de confiança reconhecidas pelo regime normativo externo das certificadoras, no tocante às políticas de certificação. Em outras palavras, o modelo diz quem pode emitir certificado para quem, em quais condições. Modelos de certificação podem ser inicialmente classificados em três tipos de arquitetura: hierárquico (raiz única), malha (mesh) e roteado (bridge).

A escolha de arquitetura para o modelo de certificação influi em praticamente toda a ICP. Desde o ordenamento jurídico vigente em seu escopo, até as implementações de softwares que verificam assinaturas. Para verificar uma assinatura, o software precisa montar uma seqüência de certificados que se autenticam em cadeia, começando por um certificado raiz e terminando pelo certificado que contém a chave necessária para a verificação da assinatura em questão. O modelo influi no procedimento de montagem dessas cadeia porque tal montagem ocorre em ordem reversa à das autenticações.

Este procedimento de verificação é mais simples no modelo hierárquico. Entretanto, como tudo em informática, a simplicidade terá preço proporcional à ambição dos objetivos. No modelo hierárquico, a certificadora raiz necessita de um canal confiável, externo ao meio onde opera a ICP e abrangendo toda a sua jurisdição, para distribuir, ou validar a distribuição, do seu certificado auto-assinado. O ITI, como operador da certificadora raiz da ICP-BR, vale-se de acordos com distribuidores de sistemas operacionais, e da publicação no diário oficial da "impressão digital" (valor de hash) do seu certificado auto-assinado, além da internet, para distribuir, e permitir que usuários validem, esse ponto de confiança da ICP-BR.

As vulnerabilidades deste modelo é que não são simples. Para incluir um certificado auto-assinado, que seja raiz única de uma ICP, nas entranhas do código de um sistema operacional, com vistas a dificultar embustes na verificação de assinaturas, o distribuidor do sistema pode se alavancar numa posição monopolista para estende-la à partilha do novo poder engendrado na ICP, se o seu negócio de distribuição basear-se na venda de licenças de uso proprietárias.

Pode atingir tal objetivo de forma indireta, esquivando-se de choques com jurisprudências anti-monopolistas, discriminando internamente questões técnicas relativas à interoperabilidade das aplicações, sob o manto protetor do direito comercial aos seus "segredos de negócio" e "propriedade intelectual", explorada sua sombra aos limites da racionalidade, pela indústria monopolista do software proprietário.

Já no modelo em malha, a certificação entre certificadoras é livre, e o procedimento de construção das cadeias de validação de certificados e verificação de assinaturas se torna bastante complexo. E no modelo roteado, busca-se o meio termo. Neste último, a complexidade pode variar entre extremos. Num dos extremos, a montagem de cadeias de certificados pode ser tão simples quanto no modelo hierárquico, se a arquitetura de roteamento for dele herdada, com certificação cruzada nos galhos da árvore e com a certificadora "raiz" no papel de roteador. Nesta configuração, vantagens simplificadoras de natureza regulatória e operacional do modelo hierárquico são mantidas, enquanto alguns riscos globais são pulverizados, sob melhor controle dos agentes finais.

Nesta configuração (árvore bidirecional roteada), diversifica-se o ponto de confiança necessário às verificações de assinaturas, que fica sendo o de acesso de cada agente final à sua certificadora, com quem poderá construir e monitorar uma relação fiducial direta no mundo da vida. Evita-se a concentração de riscos e de critérios de interoperabilidade através de um único intermediador, e seus acordos com fornecedores, espúrios ou não. Possibilita-se o controle uniforme e concomitante da chave privada e do certificado-raiz, por exemplo em tokens, sem prejuízo à hirarquização normativa.

Entretanto, qualquer menção à certificação cruzada eriça adeptos do santo byte que rondam a ICP-BR, e que ressoam ecos de lobbies monopolistas. "O modelo roteado não deu certo em lugar nenhum, porque é muito complicado", diz o ex-secretário do CG ICP-BR. "A Alemanha, a Coréia do Sul e a Índia estão implantando o modelo hierárquico unidirecional: o que esses países têm em comum?" pergunta o representante do MCT.

Há, de fato, uma iniciativa para se aglutinar PKIs num modelo roteado, que vem se arrastando há algum tempo nos EUA. Mas se trata de um esforço do tipo "consertar o bonde andando". E, ainda, com o boicote da indústria monopolista de TI. Há que se ter em conta que é muito mais difícil rotear numa floresta de malhas do que numa árvore bidirecional. Portanto, o Brasil não tem por que se amedrontar com o desafio de evoluir sua ICP para a arquitetura roteada, pois, se começa com uma única árvore unidirecional, as adaptações necessárias aos protocolos e aplicações serão mínimas, sem prejuízo ao mapeamento de políticas de certificação de varejo.

Quanto aos demais países citados: a raiz única na Alemanha é só para o governo federal. E foi de um governo alemão que nasceu o Nazismo. Já a Coréia e a Índia, são países que tem em comum uma indústria de TI que, apesar de ostentar grande peso interno no comércio internacional, é peso satélite da indústria global e monopolista de TI e de software proprietário. Justamente a quem interessa induzir Estados a adotar modelos hierárquicos, como parte da estratégia de consolidação monopolista, já comentada.
 

A Quadratora do Círculo

A vulnerabilidade coletiva a essa estratégia, que dogmatiza, entre outros mistérios, virtudes do modelo hierárquico, é considerada tão grave pelos mais competentes pesquisadores da segurança digital que sete deles acabam de lançar um manifesto, sob auspícios da Computer & Communications Industry Association (CCIA), alertando a sociedade globalizada sobre o crescente risco sistêmico daí decorrente. Antes que os fanáticos do santo byte comecem a exorcismo, observe-se que um dos autores do manifesto, Bruce Schneier, fundou e dirige a primeira empresa de segurança digital a conseguir, para seus clientes, apólices de seguro contra invasões [6].

Não serão truques marqueteiros, como o de confundir a auditabilidade efetiva de software com o mistério da eucaristia do santo byte, por meio da licença GSLP (Government Security Licencing Program [7]), que irão mudar a essência do modelo negocial do software proprietário. Ou, em outras palavras, a essência do alerta lançado pela CCIA. De que trata a GSLP? Uma primeira apresentação, fechada, no começo do ano dá pistas: código-fonte será desvelado aos olhos do licenciado, através de telas baixadas de Redmond, sem direito à compilação. Ao ser avistado, o código-fonte se transmuta em software já instalado (outra licença), abençoando o licenciado com a co-responsabilidade pela guarda dos segredos de negócio da empresa, e com a fé no mistério do corpo dos bytes, como prega a palvra da GLSP. Que pregação é essa? Alguém já leu uma GLSP?

Desconheço quem tenha lido. Mas quem lê o Wall Street Journal pode ter lido, no mês passado, matéria dando conta de que a empresa negocia, com o governo brasileiro, o que se poderia inferir sejam licenças GSLP [8]. Alguém sabe com quem no governo ela negocia? O ITI não sabe. A Casa Civil não sabe. O maior monopólio de software proprietário negocia secretamente a venda, ao governo brasileiro, de licenças secretas que ritualizam uma eucaristia pós-moderna para garantir a transparência dos seus produtos. Não é Kafka, é Wall Street Journal. Entrementes, segue oculto do público os termos de um outro acordo, firmado entre a mesma empresa e a gestão passada do ITI, para distribuição do certificado raiz da ICP-BR em seus softwares.

E cá está ela, em posição de destaque na programação deste Fórum, junto à Febraban. O que ambas sinalizam, em termos de uma possível aliança? Vejamos os sinais. Contrariando a estratégia de autonomia tecnológica frente ao risco monopolista, que antes marcava o maior banco estatal do país e que agora marca a política pública para TI do atual governo federal, que o nomeou, o presidente em exercício do Banco do Brasil vem declarando estar em vias de licitar dezenas de milhares de licenças de uso do sistema operacional XP, com suas 16 portas de fundo "para gerenciamendo de direitos digitais", da empresa diversas vezes condenada por práticas monopolistas predatórias. Saberia ele o que é privacidade?

Enquanto isso, o representante da Febraban no Fórum, que engrossa na mídia cartelizada o coro do santo byte pela excomunhão dos modelos alternativos de desenvolvimento e distribuição de software, já dirige o case a ser consagrado numa eventual aliança, a partir de uma instituição inexpressiva entre os associados. O que teria a maior empresa de software do mundo a oferecer? O que tanto atrai os guardiões do dinheiro alheio àquilo que, para sérios pesquisadores e cientistas da segurança digital, representa iminente perigo à sociedade?

A resposta mais cabível, para quem pode apenas especular sobre sinais, parece ser o poder. O passo seguinte que resta à empresa, em sua estratégia barrigal, é conduzir os legisladores da globalização, em Washington, a cooptarem a indústria do hardware e o mercado em favor do seu plano de fechamento final e completo das arquiteturas de TI. Fechamento em que sentido? Em algum sentido embalado no clima de paranóia coletiva de uma guerra onde o inimigo só pode ser identificado ao atacar, e nisto, mas só nisto, assemelhada à guerra por segurança digital.

Este plano teria várias frentes, e fulcro em sua posição monopolista no mercado de sistemas operacionais. A frente técnica está delineada em seu projeto TCPA (Trusted Computing Platform Alliance). A frente legislativa no projeto de Lei CDBPTA, e a frente política na agenda imperial de negociação para o "livre comércio", que o negociador brasileiro junto à Alca chamou, em reunião recente em Port-of-Spain, de "teológica". Nesse ponto, pode-se observar como o estilo metafórico deste relato se alinha com a palavra oficial da diplomacia brasileira.

Se o congresso norte-americano aprovar o projeto de lei CDBPTA, passa a ser crime fabricar, vender ou distribuir hardware não habilitado ao TCPA. No hardware, terá que vir indelevelmente gravada uma chave pública raiz, para bloquear qualquer software que não esteja assinado pela correspondente chave privada, que a aliança TCPA usará para -- eis o sentido -- autorizar softwares "confiáveis" a rodarem. E se a imperial agenda teológica for aceita em acordos internacionais, à guisa de livre comércio, a imposição dessas "proteções à propriedade intelectual" se globaliza. Vem aí o chifre longo (longhorn), o novo sistema, assaz penetrante.

Noutras palavras, resta à empresa quadrar o círculo, com a barriga. Impossível? Por aproximação, de passo em passo, quem sabe? Afinal, há U$ 50 bilhões em cash. Primeiro, pauta-se a mídia cartelizada com a agenda teológica do império, para que se nos doure a pílula. Aqui, já a vemos nos noticiários da TV Globo, que ontem, por exemplo, nos serviu uma salada citando leis de patentes e disputas judiciais sobre marcas, pelo direito ou não de se poder usar, juntas, as palavras "Padre" e "Cícero", nessa ordem.

 Os que se acham espertos, podem querer se alinhar primeiro. E se todos, por bem ou por mal, se alinharem, estaremos diante do fim da privacidade, da autonomia do conhecimento e da liberdade semiológica. Primeiro a digital, e depois a liberdade de expressão propriamente dita, num mundo cada vez mais informatizado. Segurança digital deixará de ser um conceito técnico, passando a ser um princípio místico. Como na idade média, quando os bytes estavam na alma (tedioso citar Kafka e Orwell).

O que pode fazer o Estado brasileiro para tentar controlar os efeitos desse tipo de aliança, em seu aparelho e na sociedade que organiza, partícipe por vontade ou revelia que nela seja? Pode fazer, ao menos, o mínimo. O mínimo consiste em exercer com racionalidade sua competência normativa, para homologar padrões e políticas digitais na ICP-BR que preservem sua própria autonomia.
 

Conclusão

Diante do consenso mínimo levantado sobre o tema "Privacidade e Responsabilidades na ICP-BR" na primeira fase do Fórum, prenhe de complicadores e contradições que se buscou trazer à luz e analisar em seguida, diante do quadro político e cultural narrado em Epifania, e diante do quadro técnico, econômico, ideológico e social que se buscou mapear com as Quatro Damas do PKIpse, resta-nos concluir apresentando uma recomendação prática, operacional, para o que o Estado brasileiro possa cumprir com eficácia a missão que se propôs, ao lançar à sociedade a ICP-BR

A saber, a missão de analisar, homologar e normatizar padrões e procedimentos, dos quais os mais sensíveis dizem respeito à interoperabilidade e à eficácia jurisdicional.

Propomos a criação de um Laboratório Permanente de Interoperabilidade, que seria montado, dirigido e operado sob os auspícios do ITI e do Comitê Técnico da ICP-BR (COTEC), para subsidiá-los, como também ao Comitê Gestor, na tarefa de homologar padrões, políticas e normas operacionais para a ICP-BR.