Product Rationale

Arariwe – um componente aberto para criptografia na web

Marco Antônio Gutierrez & Diego von Sohsten (Caixa Econômica Federal)
marco.gutierrez@caixa.gov.br, diego.sohsten@caixa.gov.br

Comunicação apresentada à 3a. Conferência Web W3C Brasil (conferenciaweb.w3c.br)

---

RESUMO

Os certificados digitais se transformam em commodities no Brasil, com a emissão de milhões para atender à demanda governamental da ICP-Brasil. Porém, seu uso na web está ainda dominado por soluções proprietárias, suportado por um único navegador, em vista da pequena abrangência do padrão definido em HTML 5. Ao descrever uma extensão em software livre que capacita o Firefox a realizar essas operações a partir de requisições originadas na web, pretendemos sensibilizar a comunidade de desenvolvimento para a urgência de soluções, passo preliminar para que o Consórcio venha a considerar a necessidade de novas especificações.

Palavras-Chave

Desenvolvimento web, certificados digitais, criptografia, ICP-Brasil.

---

1. INTRODUÇÃO

Os certificados digitais emitidos no âmbito da ICP-Brasil (Infraestrutura de Chaves Públicas do Brasil) se transformarão em commodities até o fim deste ano, quando todas as empresas brasileiras estarão obrigadas a utilizá-los no seu relacionamento com os órgãos sociais governamentais. A ICP-Brasil é uma iniciativa que regula a emissão de certificados digitais no país, principalmente no âmbito governamental, mas não somente, contando. com entidades credenciadas (ACs – Autoridades Certificadoras) ligadas ao governo (Caixa, Serpro, etc.), justiça (Justiça Federal), ao setor bancário (Serasa) e estritamente privado (Certisign). Como objetivo primário, a melhoria dos serviços governamentais, buscando substituir a papelada em celulose por bits na Internet, assegurando o não repúdio das operações através de assinaturas digitais.

Essa abrangência indica que dezenas de milhares de tokens criptográficos se transformarão subitamente em vários milhões. E todos destinados aos domínios www.br. É que o motor dessa transformação – o Conectividade Social, um produto destinado ao intercâmbio de documentos entre as empresas e as áreas sociais do governo, – ao contrário do utilitário do Imposto de Renda, é uma aplicação web. É fácil prever que esses gadgets criptográficos rapidamente alcançarão o grande público, sobretudo com a adaptação dos aplicativos web de Internet Banking, já em marcha. Para além das conexões SSL/TLS, a esfera www.br será invadida pela criptografia: pela contínua geração de chaves criptográficas e pelo uso diário de assinaturas digitais.

Esse cenário impõe um importante desafio para este fórum e outros como ele. Ao contrário das demais tecnologias web, onde a adoção de padrões abertos é finalmente realidade que ninguém é capaz de questionar, o uso da criptografia na web está ainda dominado na prática pelas soluções proprietárias. E não é previsível que esse predomínio se altere no horizonte próximo, em que pesem os louváveis esforços padronizadores do ITI. Neste momento, quem procura uma das Autoridades Certificadoras da ICP-Brasil é informado que deve ser usuário de um único navegador (e do sistema operacional associado). A razão é enganosamente simples: como não existem padrões abrangentes para a exposição na web de funções criptográficas, o problema deve ser resolvido por cada implementação de navegador. E apenas um único fabricante se deu a esse trabalho...

Ainda que não tenha a pretensão de propor padrões para a tecnologia, esta comunicação não quer se limitar a chamar atenção para o problema. Ao descrever um componente de software destinado a preencher uma pequena parte dessa lacuna, queremos assinalar alguns possíveis caminhos imediatos para a mitigação dos riscos inerentes a essa falta de padrões.

2. O PROBLEMA

Não é inteiramente correto afirmar que padrões não estão a caminho. Porém, a introdução do elemento keygen em HTML 5 resolve esse problema apenas parcialmente. Com ele, estamos aptos a gerar chaves criptográficas para a emissão dos certificados digitais, mas não estamos aptos a utilizar esses certificados nas operações diárias exigidas pelos órgãos públicos (e Internet Bankings). Ocorre que o novo padrão não dá suporte a assinaturas digitais. Portanto, apenas uma pequena fração do uso efetivo da tecnologia é atendida pela nova especificação.

É compreensível que o grupo de trabalho HTML 5 não se tenha preocupado em incluir suporte a assinaturas digitais na especificação. Afinal, no vasto mundo web, a criptografia se limita às conexões SSL/TLS, raramente autenticadas do lado cliente. A universalização das assinaturas digitais na web é um problema tipicamente brasileiro, que emerge da adoção de algumas poucas (mas de uso quase que universal) aplicações web. Essa pequena demanda no resto do mundo torna o suporte criptográfico uma questão particular de cada navegador, de pouco interesse das organizações padronizadoras. Como regra, a total ausência de suporte a operações criptográficas originadas em páginas web, com a exceção do MS Internet Explorer. Como as operações com este navegador representam 43,% do tráfego registrado no Brasil, podemos dizer que esse cenário ainda avesso à padronização afeta negativamente metade dos usuários brasileiros, pelo menos em parte significativa da sua navegação.

2.1 Uma API criptográfica para a web

Provavelmente, o melhor caminho para um padrão criptográfico web não é o indicado pela introdução de novos elementos HTML. Os marcadores são estáticos demais para atender ao desenvolvimento de aplicações não só para a emissão de certificados, mas sobretudo para assinaturas digitais, acordos de troca de chaves e esquemas de envelopes criptográficos. Aqui a variedade de algoritmos é grande, mesmo sob os padrões restritivos do ITI. O DOC ICP-01.01 regulamenta o uso de dois algoritmos de geração de chaves assimétricas (RSA e ECDSA) com cinco diferentes tamanhos possíveis de chaves, três algoritmos de resumos criptográficos (SHA-1, SHA-256 e SHA-512) e dois algoritmos de criptografia simétrica (3DES e AES), também com vários tamanhos de chaves.

Para complicar o problema do desenvolvedor, diferentes tokens criptográficos e diferentes smart-cards suportam diferentes algoritmos e tamanhos de chaves. Isso significa que uma aplicação web robusta e de boa usabilidade precisa assegurar-se que o algoritmo pretendido seja suportado pelo dispositivo criptográfico em uso. Sob HTML estático, a única solução é perguntar ao usuário – e se algo a experiência com criptografia prática nos ensinou é que esse é um assunto inteiramente fora do domínio de conhecimentos do usuário final.

Portanto, sugerimos que a melhor solução para um padrão criptográfico para a web que venha a ser definido eventualmente consiste na especificação de uma interface de programação, a exemplo de XMLHttpRequest, padrão orientado a linguagens de script. Essa alternativa não apenas concede mais flexibilidade aos desenvolvedores de aplicações web, como também facilita os implementadores de navegadores, permitindo-lhes aproveitar diretamente os recursos hoje disponíveis em seus próprios produtos.

2.2 Requisitos mínimos de uma API criptográfica para a web

É certo que, do ponto de vista funcional, o melhor ponto de partida para a definição dos requisitos dessa API (Application Programming Interface) é a implementação da Microsoft, disponível para scripts destinados exclusivamente ao seu navegador. Para uma primeira abordagem do problema isso deve bastar. Assim, sugerimos a satisfação pelo menos das seguintes funcionalidades:

• Enumerar os dispositivos criptográficos presentes;
• Enumerar as capacidades (algoritmos e tamanhos de chaves) de um dado dispositivo;
• Gerar chaves criptográficas para o algoritmo e tamanho especificados;
• Compor e assinar uma requisição de certificado digital;
• Instalar um certificado assinado, correspondente a um par de chaves anteriormente gerado;
• Enumerar as chaves criptográficas instaladas num dado dispositivo;
• Assinar um dado qualquer com a chave e o algoritmo especificados;
• Compor um envelope de assinatura digital;
• Decompor um envelope de assinatura, obtendo suas partes (documento, assinantes, certificados, etc.);
• Verificar a validade de uma assinatura digital.

Como dissemos, a maior parte dessas funcionalidades está disponível para o MS Internet Explorer. Dois são, portanto, os problemas que movem esta comunicação: a disponibilidade dessas funcionalidades também em outros navegadores e a padronização das interfaces de acesso a elas. Não podemos endereçar o segundo problema – apenas chamar a atenção deste fórum para ele. No entanto, está ao nosso alcance resolver o primeiro, pelo menos em parte e enquanto um padrão não é definido e adotado pelos implementadores de navegadores. É o que discutiremos a seguir.

3. ARARIWE

A ideia por trás do projeto Arariwe (o espírito da arara, na mitologia yanomami) é implementar software capaz de expor na web, para aplicações de scripting destinadas a outros navegadores que não o MSIE, aquelas funcionalidades criptográficas. Distribuído sob licença GPL v3, o software atende neste momento somente aos cinco primeiros itens do elenco da seção 2.2 e somente para um único navegador (o Mozilla Firefox). No entanto, o objetivo é atender em breve a todos os requisitos. E na medida em que venha a ser adotado (e eventualmente mantido por comunidade própria de desenvolvedores), a ideia é implementá-lo também para o Google Chrome. Se a iniciativa for bem sucedida, esperamos com ela assegurar que 98,69% do market share de navegadores no Brasil seja capaz de utilizar aplicações criptográficas na web com esforço mínimo de desenvolvimento.

A ideia de conduzir o projeto desse modo, com entregas parceladas, decorre dos diferentes contextos de uso dessa API. As cinco primeiras funcionalidades são necessárias exclusivamente ao software das Autoridades Certificadoras, enquanto que as restantes são requeridas pelas aplicações de instituições usuárias dos certificados digitais (por exemplo, os Internet Bankings). Nossa expectativa é de que a primeira versão do produto venha a ser adotada pelo menos pela Autoridade Certificadora Caixa (cuja solução é conhecida por utilizar exclusivamente software livre na sua composição) e a segunda, pelo Conectividade Social.

3.1 A escolha do Mozilla Firefox

A decisão de iniciar o projeto pelo terceiro colocado no ranking de navegadores pode ser explicada por uma única palavra: preguiça! O fato é que o Chrome, para um desenvolvedor, padece das limitações da juventude: há ainda muito pouco conhecimento disponível na forma de documentos sobre seu funcionamento e seu modelo de extensibilidade.

Com o Firefox, ao contrário, essa disponibilidade de informações e conhecimentos nos assegurava de antemão que o projeto seria bem sucedido mais cedo ou mais tarde. Simplesmente porque todas aquelas funcionalidades criptográficas já estão disponíveis no produto e são acessíveis à programação de extensões. Toda a criptografia do Firefox é fundada sobre a biblioteca compartilhada NSS (Network Security Services), consagrada pelo uso (o que é importantíssimo em criptografia) e bastante completa. Todo o nosso problema residia, portanto, em expor na web aquela funcionalidade mínima necessária.

Também nesse aspecto o Firefox se revelou escolha excelente do ponto de vista da produtividade. Seu modelo de extensibilidade é elegante, simples, muito bem documentado e dotado de inúmeros recursos e facilidades. A principal facilidade foi certamente o módulo js-ctypes, introduzido na versão 4 do produto.
Baseada na implementação open source libffi, o módulo expõe uma interface destinada a converter as convenções de chamada e tipos de dados (se é que é possível utilizar essa expressão com linguagens fracamente tipadas) do JavaScript nas convenções e tipos suportados pelo C/C++. Isso permite ao desenvolvedor de complementos (mas não ao desenvolvedor web) para o Firefox acessar diretamente código nativo escrito naquela linguagem usando o interpretador JavaScript.
Isso nos permitiu que o complemento fosse inteiramente desenvolvido em JavaScript. A alternativa seria implementar o acesso à NSS em linguagem C, expondo uma interface XPCOM (um modelo de implementação de interfaces para acesso cross platform por diferentes linguagens de programação, similar ao Microsoft COM) para os complementos em JavaScript. Novamente a preguiça falou mais alto!

Por outro lado, o desenvolvimento inteiramente em JavaScript permite que o software seja mantido, evoluído e personalizado por praticamente quaisquer desenvolvedores web, que parecem receber essa linguagem misturada ao leite materno. Essa é uma característica importante em produto que gostaríamos de ver utilizado por organizações cujo foco não é tecnologia – as Autoridades Certificadoras da ICP-Brasil, empresas públicas e até mesmo instituições bancárias.

3.2 A arquitetura do complemento

O design da arquitetura do componente foi guiado pelo princípio KISS (Keep it simple, Sir!). Como se trata apenas de expor na web determinadas funcionalidades do Firefox, o complemento não requer uma interface com o usuário, mas tão somente uma interface (de programação) com as páginas web. Neste caso, a própria arquitetura do Firefox (e, por extensão, dos seus complementos) nos indicou o caminho para a exposição dessa interface de programação.
Toda a interface de usuário do Firefox é implementada em XUL e JavaScript. XUL (XML User Interface Language) é simplesmente uma gramática XML que fornece elementos de interface com usuário (botões, janelas, menus, etc.) cujo comportamento é especificado em JavaScript. Esse comportamento associado aos elementos de interface é acionado, naturalmente, por eventos gerados pelo usuário ou pelo próprio navegador na sua operação na web. A janela cliente do próprio browser, que hospeda as páginas web renderizadas, é implementada desse modo.

Isso significa que é possível interceptar eventos gerados pela interação do usuário com as páginas HTML obtidas da web. Esse foi o mecanismo escolhido para a comunicação entre o complemento e as páginas dos aplicativos residentes na web. Quando é carregado pelo navegador, o complemento registra o atendimento a um pequeno conjunto de eventos próprios (arariwe-enumerateslots, arariwe-enumeratemechanisms, etc.). Para se comunicar com o complemento e requerer seus serviços criptográficos, uma aplicação web precisa tão somente disparar um evento DOM Level 2 do tipo correspondente ao registrado pelo complemento, normalmente através de JavaScript. Tantos os parâmetros necessários ao serviço quanto sua resposta são passados através de elementos DOM definidos especialmente para o complemento.

O núcleo criptográfico do complemento não passa de uma interface com a NSS, quem de fato realiza o trabalho. Aqui o esforço maior foi redeclarar para JavaScript os tipos C e funções necessários, utilizando os objetos da biblioteca js-ctypes para efetuar a conversão. Mais significativa foi a solução encontrada para a inicialização do gerador de números randômicos da NSS.

Como é sabido, boa parte da força de um algoritmo de geração de chaves criptográficas assimétricas (por exemplo, RSA) se funda em números primos escolhidos previamente ao cálculo. No caso de RSA, são requeridos dois números tais que sejam suficientemente grandes, diferentes entre si e (naturalmente) aleatórios. O trabalho de escolha desses números é realizado pelo dispositivo de geração de números randômicos da NSS. O dispositivo é forte e sem bugs conhecidos (hoje). No entanto, é um algoritmo e, como tal, seu resultado pode ser previsto, conhecidas as condições iniciais de sua execução. Aliás, Schneier nos lembra que uma falha na implementação deste mesmo dispositivo já fez com que o Netscape Navigator 1.1, tataravô do Firefox, ao gerar chaves simétricas de 128 bits produzisse entropia não maior que 20 bits, facilmente computável por força bruta. A falha foi corrigida, é claro, mas a necessidade de evitar a previsibilidade das condições iniciais de execução permanece. Na NSS, essas condições iniciais são estabelecidas por uma “semente” randômica fornecida externamente.

A produção dessa semente foi, portanto, um relevante problema de segurança a ser resolvido por conta da indisponibilidade de boas fontes de ruído sem recursos especializados de hardware. A escolha recaiu sobre o próprio usuário. Nossa suposição foi que o conteúdo (tags HTML, texto, scripts, etc.) da totalidade das páginas web visitadas pela navegação concreta do usuário antes de chegar à página do aplicativo que requer a geração das chaves criptográficas é imprevisível. Essa talvez não seja uma suposição descabida num mundo web de conteúdo dinâmico como o que vivemos, onde as mesmas URLs fornecem conteúdo diferente a cada visita.

Assim, o componente inicia seu dispositivo de captação de ruído com a carga do próprio navegador. Cada página web recebida pelo navegador, independente da sua origem (o que incluí as próprias janelas do Firefox), é interceptada antes de ser renderizada para o usuário e seu conteúdo HTML utilizado no cálculo de um resumo criptográfico SHA-512. Esse processo prossegue sempre, independente da URL, até que ocorra a requisição da geração de um par de chaves criptográficas, quando o cálculo do hash é finalizado e seu produto enviado à NSS como semente de inicialização.

Naturalmente, não estamos certos de que esta seja a melhor solução possível, sobretudo para usuários conservadores que jamais visitam o Facebook e o Twitter. Esperamos, porém, que a liberação do software sob GPL estimule a avaliação crítica e as sugestões da comunidade de especialistas.

O último elemento da implementação que queremos considerar é a interface de programação para a interação com o complemento. De modo a evitar que os desenvolvedores precisem interagir com as características próprias do complemento, fornecemos um pequeno conjunto de objetos de script para serem utilizados nas páginas web dos aplicativos de Autoridade Certificadora. A ideia foi assegurar que o código de aplicação de AC seja escrito na total independência do browser utilizado. Os próprios objetos detectam o navegador utilizado pelo usuário e decidem qual a API apropriada a cada caso.

Aqui precisamos lidar com uma última complexidade, esta relacionada à implementação criptográfica da Microsoft. A partir do Windows Vista, a empresa descontinuou seu objeto web criptográfico relacionado à MS CryptoAPI, o componente ActiveX CEnroll, substituindo-o pela interface IX509Enrollment, com API totalmente distinta, batizada CNG (Cryptography API: Next Generation). O fato de 49,92% dos usuários brasileiros da web ainda utilizarem o Windows XP nos obrigou a sustentar ambas as implementações. Na prática, isso foi equivalente a suportar três navegadores distintos.

3.3 Considerações de segurança

Como se trata de uma extensão de navegador, Arariwe não é capaz de ser mais seguro do que seu hospedeiro. Mais especificamente, ele deve se integrar ao modelo de confiabilidade do próprio navegador e não mais do que isso. Por outro lado, o componente é perfeitamente capaz de ser menos seguro do que o navegador e, com isso, comprometer todo o produto. Examinemos o problema.

Deve-se notar que, por padrão, uma página web não se comunica com uma extensão, já que ambas existem em diferentes sand boxes, separadas por um fosso. Este fosso é construído de tal modo que a página web é visível e acessível pela extensão, mas não o contrário. Como uma extensão do browser, o complemento tem privilégios de acesso aos recursos computacionais locais inaceitáveis para uma página web.

Ao registrar o atendimento a eventos oriundos de páginas da web, o que fizemos foi estender uma ponte sobre este fosso. Isso significa que um atacante pode introduzir script malicioso numa página web visitada pelo usuário e que não pertença à Autoridade Certificadora e, através dele, evocar a extensão para realizar silenciosamente atividades não pretendidas pelo usuário.

Há dois ataques óbvios aqui. O primeiro deles implica em fazer com que Arariwe realize seu trabalho, mas com intenção maliciosa. Por exemplo, assinar um documento (digamos, uma transação bancária) que o usuário não pretendia assinar. Isso é perfeitamente possível imediatamente após uma assinatura legítima efetuada pelo usuário. Para realizá-la, o usuário é obrigado a efetuar logon no token criptográfico, fornecendo seu PIN (Personal Identification Number) de acesso ao dispositivo. Porém, se a operação de assinatura (legítima) não for concluída por um logout, o dispositivo criptográfico não solicitará novamente o PIN na tentativa maliciosa de acesso – e o documento indesejado será assinado silenciosamente!

A contra medida óbvia (Arariwe sempre forçar um logout após uma operação que exija autenticação no token) pode não ser suficiente. Como o usuário não sabe o que está acontecendo (aliás, não tem como saber, já que, do seu ponto de vista, o computador é uma caixa preta), não necessariamente será alertado pelo segundo logon, este malicioso.

Por outro lado, é possível que a extensão verifique a origem da requisição, não aceitando requisições originadas de URLs não confiáveis. O modo mais evidente de realizar isso é registrar o atendimento somente a eventos originados em sites confiáveis, o que, na prática, significa que a página web requisitante deve ter seu JavaScript assinado digitalmente por um certificado emitido por uma Autoridade Certificadora em quem o Firefox confia implicitamente, como a Verisign, por exemplo.

O problema dessa solução é que a assinatura digital é uma garantia de origem e não de confiabilidade. O fato de a Verisign proclamar que a URL xpto está associada ao Common Name xyz não significa que as pessoas por trás de xyz sejam honestas e confiáveis. Por outro lado, mesmo que o sejam, a proclamação não implica que xpto seja um site realmente seguro e que um atacante não tenha sido capaz, por exemplo, de realizar um ataque de XSS (Cross-site scripting) contra ele, injetando script malicioso para afetar a extensão. Além disso, essa verificação de confiabilidade é feita silenciosamente pelo navegador – e se o certificado tiver sido emitido por uma AC já instalada no navegador, o usuário não saberá que a sand box entre a web e o componente foi transposta.
Uma solução um pouco melhor é não confiar em nenhuma dessas contra medidas por si só, combinando-as (no que costumamos chamar defesa em profundidade). Em outras palavras: Arariwe pode ser configurado para sempre forçar o logout do token após uma operação criptográfica autenticada, aceitar eventos disparados somente de sites confiáveis (isto é, por JavaScript assinado) e sempre alertar o usuário para a origem de uma requisição criptográfica.

Esta última contra medida reduz seriamente a usabilidade do componente. Além disso, a frequência de mensagens de alerta pode levar o usuário simplesmente a ignorá-las. E isso pode ser usado por um atacante. Schneier assinala que “é perfeitamente compreensível aquela parte da natureza humana que passa a ignorar alarmes falsos frequentes, mas este é também um aspecto da natureza humana que pode ser explorado por um atacante”. Para melhorar a usabilidade, Arariwe permite que o usuário escolha não ser alertado novamente para requisições originadas daquela URL. Mas isso não resolve o problema do alarme falso.
O fato é que não pudemos encontrar solução melhor que as apresentadas, pelo que agradecemos sugestões. Consola-nos, porém, o fato de os componentes ActiveX expostos no browser da Microsoft não fornecerem segurança melhor. Assim, o usuário do Firefox poderá estar convicto de que não é pior servido que os usuários do Internet Explorer...

O segundo ataque possível que podemos mencionar é a injeção de script malicioso através da passagem de parâmetros para a extensão, para realizar tarefas que nada tem a ver com criptografia. Esse risco é agravado pela escolha do JavaScript como linguagem de implementação. A linguagem dispõe do mais insidioso recurso de programação possível: a função eval(), que tenta executar seja lá o que lhe for passado como parâmetro.

A contra medida contra isso é óbvia mas não necessariamente eficaz: nós não confiamos nos parâmetros recebidos, que sofrem validação estrita contra white list. Além disso, procuramos não utilizar os argumentos recebidos no processamento JavaScript, apenas em comparações, passando-os às funções da NSS. Isso, porém, não significa que não seja possível a injeção de parâmetros maliciosos. O fato de não termos sido capazes de notar vulnerabilidades nesse território pode indicar mais nossa própria incompetência que a segurança da aplicação.

Neste caso, o melhor que pudemos fazer foi abrir o código para inspeção pela comunidade, na esperança de que falhas sejam encontradas e comunicadas. Nenhuma medida (fútil) de ofuscação foi tomada e a licença GPL pode ser entendida como um convite à inspeção. Até porque trata-se de software a ser instalado na estação do usuário – e não é possível proteger os detalhes de um software desse modo, fora do nosso perímetro seguro. De qualquer modo, não acreditamos que a obscuridade no projeto assegure a segurança do software. Como Schneier, acreditamos que um sistema “projetado com segurança por obscuridade (…) só é seguro enquanto os detalhes permanecerem secretos”. Por outro lado, “um projeto de sistema bom é seguro mesmo que os detalhes se tornem públicos”.

3.4 Limitações do produto

Um último problema precisa ser considerado no projeto de Arariwe. Trata-se dos algoritmos criptográficos suportados. O projeto da NSS, muito acertadamente, delega a responsabilidade pela implementação dos algoritmos criptográficos (mecanismos, no jargão da biblioteca) aos dispositivos criptográficos (tokens e smart-cards) instalados pelo usuário, em conformidade com a especificação PKCS#11. Para garantir que as funções criptográficas do próprio browser (conexões SSL, por exemplo) sejam executadas sempre, mesmo que o usuário não instale nenhum dispositivo, o navegador embute um dispositivo de software próprio, nomeado NSS Internal PKCS #11 Module. Foi contra esse dispositivo que Arariwe foi inicialmente testado.

Ora, um dos algoritmos de geração de chaves e de assinatura recomendados pela ICP-Brasil, ECDSA (Elliptic Curve Digital Signature Algorithm), foi originalmente implementado para este token e, posteriormente, removido. A razão se deveu a dúvidas quanto a disputas de patente. Por conta disso, a remoção foi intempestiva e a cirurgia, não muito asseada. Foram introduzidas diretivas de compilação condicional no código da NSS e não somente do token PKCS#11. Essa solução apressada produziu bugs. Por exemplo, se interrogarmos o token NSS, ele responderá que suporta ECDSA; no entanto, falhará se solicitarmos a geração das chaves correspondentes, assegurando o respeito à patente, mas não a consistência do código. Outros comportamentos inesperados foram também relatados. Trata-se de bug conhecido e que não será corrigido pela comunidade de desenvolvimento do produto.

Isso significa que é possível que um usuário instale um token que supostamente deveria suportar ECDSA e que este não funcione apropriadamente com o algoritmo. Não dispúnhamos de um tal token durante o desenvolvimento de Arariwe. Assim, não pudemos verificar a hipótese. Portanto, é possível que a extensão não suporte ECDSA em circunstância alguma, o que não deveria ocorrer. Trata-se, porém, de limitação incontornável do Firefox.

4. CONSIDERAÇÕES FINAIS

Para concluir queremos assinalar que o primeiro objetivo dessa comunicação não é tanto chamar atenção para um software – afinal, uma iniciativa modesta e de pequeno alcance – e mais procurar sensibilizar os participantes deste fórum para considerarem os problemas inerentes à falta de padrões abrangentes para a criptografia na web, pelo menos no caso brasileiro. Em primeiro lugar, é preciso reconhecer que o problema existe e não está inteiramente endereçado pela especificação de HTML 5. Sem este passo preliminar, é muito difícil que o Consórcio venha a considerar a necessidade de novas especificações.

O segundo objetivo é menos ambicioso: trata-se de demonstrar para a comunidade de desenvolvimento, particularmente aquela envolvida com criptografia na web (equipes de Autoridades Certificadoras, agências públicas e bancos), que o problema de universalizar o uso de certificados digitais para além das fronteiras atuais (um único browser, um único sistema operacional) pode ser facilmente mitigado a curto prazo, pelo menos para os navegadores distribuídos em regime de software livre. Tudo o que é necessário é a decisão de empreender o esforço.

Esse esforço pode, naturalmente, ser empreendido isoladamente, através de soluções proprietárias. Esse caminho não difere muito do atual em qualidade, apenas em quantidade. Pode, porém, ser desenvolvido em comum, favorecendo-se as iniciativas de código e padrões abertos, como Arariwe ou qualquer outra – melhor – que venha a se apresentar.

5. REFERÊNCIAS

1 GPL. Gnu General Public License Version 3. http://www.gnu.org/licenses/gpl-3.0.txt.

2 HOUSLEY, R. Cryptographic Message Syntax (CMS). RFC 3852. http://www.ietf.org/rfc/rfc3852.txt.

3 ITI. Padrões e algoritmos criptográficos da ICP-Brasil. DOC ICP-01.01. http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-01.012.1.pdf.

4 LIBFFI. A Portable Foreign Function Interface Library. http://sourceware.org/libffi/.

5 MDN. Mozilla Developers Network. https://developer.mozilla.org.

6 MSDN. Cryptography. http://msdn.microsoft.com/en-us/library/aa380255%28v=VS.85%29.aspx.

7 PIXLEY, T. Document Object Model (DOM) Level 2 Events Specification. W3C Recommendation 13 November, 2000. http://www.w3.org/TR/DOM-Level-2-Events/.

8 RIVEST, R.L. et all. Cryptographic communications system and method. Disponível em: http://www.google.com/patents?vid=4405829.

9 RSA Laboratories. PKCS #7: Cryptographic Message Syntax Standard. http://www.rsa.com/rsalabs/node.asp?id=2129.

10 RSA Laboratories. PKCS #10: Certification Request Syntax Standard. http://www.rsa.com/rsalabs/node.asp?id=2132.

11 RSA Laboratories. PKCS #11: Cryptographic Token Interface Standard. http://www.rsa.com/rsalabs/node.asp?id=2133.

12 SCHNEIER, B. Beyond Fear. Thinking Sensibly About Security in an Uncertain World. New York, Copernicus Books, 2003.

13 SCHNEIER, B. Secrets & lies. Digital Security in a Networked World. New York, Wiley & Sons, 2000.

14 STATCOUNTER. Global stats. http://gs.statcounter.com/#browser-BR-monthly-201007-201107. Acesso em: 20 ago 2011.

15 VAN KESTEREN, A. XMLHttpRequest. W3C Candidate Recommendation 3 August 2010. http://www.w3.org/TR/XMLHttpRequest/.