A Medida Provisória 2200-2, de 24 de agosto de 2001, estabelecendo a Infra-Estrutura de Chaves Públicas Brasileira, a ICP-Brasil, de modo "garantir a autenticidade, a integridade e a validade jurídica de documentos em forma eletrônica, das aplicações de suporte e das aplicações habilitadas que utilizem certificados digitais, bem como a realização de transações eletrônicas seguras", tende a agir no sentido de superaquecer a demanda por softwares e outros serviços de valor agregado na área de segurança da informação, particularmente naqueles ramos ligados às implementações criptográficas. Ao estabelecer regras para a emissão de certificados digitais no âmbito da infra-estrutura e praticamente obrigar as instituições estatais a segui-las (ver, por exemplo, o Decreto 3.996, de 31 de outubro de 2001), a MP tende a colocar essa tecnologia de identificação no centro das atenções do setor de Tecnologia da Informação do Brasil nos próximos anos.
Isso é fácil de inferir em vista da abrangência da ação estatal na vida econômica do país. Por exemplo, há alguns anos, a Portaria Interministerial MPS/MTE 116, de 9 de fevereiro de 2004, obrigou a utilização pelas empresas de aplicativo Internet que adota a tecnologia de certificados digitais para identificar seus usuários, tecnologia que, evidentemente, precisará ser adequada às normas da ICP-Brasil. Com isso, não são necessários dotes premonitórios para prever a inundação nos próximos anos de certificados digitais desse padrão. Estimando-se número mínimo de dois usuários por empresa, podemos prever a emissão (e renovação periódica) de pelo menos sete milhões de certificados nos próximos anos. Boa notícia para os fabricantes de smart-cards e outros atores desse ecossistema de negócios. Tais notícias são ainda melhores se considerarmos também a estratégia da Receita Federal de estimular (e possivelmente obrigar) o uso dessa tecnologia na entrega anual das declarações de rendimentos. Em longo prazo, isso implicará na agregação de mais alguns milhões de usuários...
Uma conseqüência dessa inundação é a extensão do uso dessa tecnologia para outros setores que não o estatal. Se os certificados digitais estão lá disponíveis, por que não usá-los? Assim, segmentos de serviços privados onde a identificação dos usuários é considerada crítica (a MP, no seu Artigo 10 parágrafo 1, simplesmente estabelece que uma assinatura digital efetuada com o uso desses certificados é equivalente legalmente a uma assinatura autógrafa) rapidamente incorporarão essa tecnologia. Novamente, não há qualquer premonição aqui: simplesmente observamos a movimentação (ainda incipiente, mas bastante concreta) do setor bancário, que prevê sua utilização nos seus Internet Bankings e outros serviços eletrônicos.
Esses poucos indícios são suficientes para prevermos forte demanda por softwares especializados nessa tecnologia ou que dela façam uso. Não apenas aplicativos ligados à infra-estrutura de emissão e gestão de certificados digitais (softwares de Autoridade Certificadora, drivers para tokens criptográficos, aplicativos para uso de HSMs - Hardware Security Modules e TSAs - Time-Stamp Authorities, etc.) como também aqueles relacionados à infra-estrutura de suporte a aplicativos que façam uso de certificados digitais estarão cada vez mais sendo exigidos: softwares para autenticação no contexto das normas da ICP-Brasil, aplicativos para assinatura digital e sigilo das comunicações, protocoladores de documentos, etc. - este elenco está ainda longe de se esgotar.
Tais softwares precisam ter características bem definidas, ainda que não exclusivas dessa categoria de sistemas: confiabilidade, escalabilidade, segurança, rigor no atendimento a padrões (nacionais e internacionais) bem estabelecidos, além de conformidade de design a especificações institucionais, normas e regulamentos legais. Com exceção desta última, tais características são típicas de softwares de infra-estrutura para missão-crítica.
O primeiro problema neste cenário é que a capacidade do mercado atender a essa demanda emergente é ainda notavelmente baixa, a começar pela oferta insignificante de softwares especializados. Por exemplo, as soluções disponíveis para a infra-estrutura elementar das Autoridades Certificadoras podem ser inventariadas com os dedos de uma única mão! Além disso, o software existente, quando encontrado, está longe de atender a esses requisitos, no mínimo porque alguns deles são baseados em normas e regulamentos brasileiros, mas não só. Um aspecto que parece condicionar suas limitações consiste no fato de, historicamente, as soluções de criptografia serem principalmente aplicadas a domínios militares e de segurança nacional, domínios de aplicação necessariamente restritos. Isso significa que a abrangência esperada para a ICP-Brasil não tem paralelo no mundo. Um outro problema bastante concreto é a acelerada mudança nas regras da ICP-Brasil. Desde 2001 foram publicas 66 Resoluções e retificações, sendo revogadas 35 delas; desde 2005, foram publicas 29 Instruções Normativas e revogadas 8. Não é de se admirar, portanto, que o software disponível seja escasso e não atenda aos requisitos esperados.
Um outro problema que precisa ser considerado refere-se às premissas da legislação. Uma dessas premissas assume que a assinatura digital exprime a vontade do assinante - que conduz à decorrência do não-repúdio (não posso negar que fui eu que assinei o conteúdo). No mundo das demonstrações matemáticas, isso é perfeitamente correto. No mundo real, nem sempre...
Quando assino um documento em papel, todo o conteúdo está à minha disposição e o ato de assiná-lo é realizado pelas minhas próprias mãos, à minha vista e, possivelmente, de testemunhas (que estão ali para assegurar que o ato exprime a minha vontade e não a de um eventual agressor com uma arma encostada à minha cabeça). No mundo digital, o conteúdo apenas parece estar à minha disposição: o que vejo na tela não é o conteúdo que estou assinando, mas uma representação dele, que de fato é um padrão de bits gravado na memória (inacessível diretamente por mim) do computador. Se a representação que vejo na tela corresponde estritamente ao conteúdo da memória física depende do software que estou utilizando. Por outro lado, a operação de assinatura não é realizada pela minha mão (ela apenas clicou no botão do mouse), mas pelo software executado no computador e no smart-card, inteiramente fora da minha vista...
É certo, portanto, que a assinatura digital exprime a vontade do conjunto de pessoas envolvidas no desenvolvimento do software e do hardware mobilizados no processo. Ela só exprime a minha vontade se esta coincidir com a vontade daquelas pessoas... E todos sabemos que isso acontece sempre. Afinal, todos os fabricantes de software e hardware são pessoas honestas e bem intencionadas, não admitindo colocar os interesses nacionais acima dos interesses dos seus clientes, todos os analistas e engenheiros sabem exatamente o que estão fazendo (e o fazem com perfeição), todos os programadores produzem código consistente, robusto, confiável e sem bugs. Não há, portanto, razões para preocupações...
O projeto Signthing visa colaborar no atendimento àquela demanda em crescimento, fornecendo software para assinatura digital em conformidade com os padrões definidos para a ICP-Brasil em regime de software livre. A escolha do software livre decorre do problema que assinalamos nos parágrafos anteriores. Como o código do produto é aberto, o usuário não precisa confiar implicitamente nos desenvolvedores: ele (ou especialistas no assunto, o que ajuda na confiabilidade necessária) pode simplesmente inspecionar o código, determinando com precisão o que é feito. Aliás, se isto não for satisfatório, o usuário é livre para adaptar o aplicativo ás suas próprias necessidades, corrigindo eventuais erros e efetuando melhorias.
O fato de se tratar de projeto de software livre agrega ao problema uma outra vantagem: como não há restrição de uso, um software bem sucedido pode ser testado amplamente, já que não há restrição orçamentária; como o código está aberto, erros podem mais facilmente ser diagnósticados e corrigidos. Isso vale igualmente para falhas de segurança. Portanto, o software livre tende a ser mais confiável e seguro que o software proprietário, caso o projeto seja bem sucedido (naturalmente) - e um projeto de software livre bem sucedido pode ser identificado simplesmente inventariando a abrangência da sua comunidade de usuários e desenvolvedores.
A criptografia de chaves assimétricas (ou de chaves públicas) baseia-se em duas chaves criptográficas: uma delas, utilizada para cifrar as mensagens (isto é, assinar digitalmente o conteúdo), deve ser mantida secreta, inacessível por qualquer um que não o seu proprietário - é a chave privada. A outra é tornada pública, e como só esta última chave é capaz de decifrar o conteúdo assinado pela chave privada, o sucesso da operação de decifração indica que a mensagem foi cifrada pela chave privada, "provando" que a mensagem foi criada pelo proprietário daquele par de chaves. Essa "prova" de autenticidade e origem depende, evidentemente, de uma premissa: a chave privada foi mantida secreta pelo seu proprietário.
Não há restrições lógicas quanto ao conteúdo a ser assinado, já que a operação criptográfica é realizada sobre um conjunto de bits armazenados na memória do dispositivo computacional. Portanto, o "documento" a ser assinado pode ser qualquer coisa relevante para o usuário, desde um arquivo do processador de texto até os dados de uma transação bancária volátil, passando por imagens, mensagens de correio eletrônico, etc. Naturalmente, de um modo geral uma assinatura em si pode não significar nada. Pode, por exemplo, ser relevante o instante no tempo em que a assinatura foi realizada sobre o documento. Assim, o conteúdo assinado costuma incluir também a data e hora em que a operação foi realizada, sendo a precisão dessa informação dependente do tipo de negócio relacionado à assinatura.
Por outro lado, se não existem restrições lógicas, é evidente que lidamos com restrições físicas, particularmente a memória (mas também a capacidade computacional, sobretudo quando envolvidos dispositivos computacionais móveis) disponível. Essa limitação é particularmente relevante em vista do fato de as chaves criptográficas utilizadas normalmente serem armazenadas em smart-cards. Nesse caso, as assinaturas digitais são realizadas no próprio dispositivo, de modo a não permitir que a chave privada seja enviada à memória do computador utilizado pelo usuário, que é um dispositivo de uso geral conectado às redes e, portanto, muito mais vulnerável a ataques que um dispositivo criptográfico dedicado. Isso aumenta a segurança do usuário, mas impõe restrições ao tamanho do conteúdo que é assinado. Isso faz com que não assinemos diretamente o conteúdo desejado, mas o produto de uma operação criptográfica realizada sobre ele, conhecida como função de hash.
Uma função de hash (unidirecional) é como impressão digital: são pequenos pedaços de dados que podem servir para identificar objetos digitais de qualquer tamanho. Tais funções são fáceis de calcular numa direção e muito difíceis de calcular na outra, daí serem unidirecionais. È fácil calcular o hash desse texto, por exemplo; no entanto, dado o hash desse texto, é computacionalmente inviável criar um outro texo que tenha o mesmo valor de hash ou derivar o texto original. Portanto, o cálculo do hash de dois textos de qualquer tamanho que sejam diferentes em um único bit deve (ao menos teoricamente) resultar em dois valores de hash completamente diferentes, daí utilizarmos a metáfora da impressão digital. Uma outra característica dessas funções é que não importa o tamanho do conteúdo, o cálculo do hash sempre resultará num valor do mesmo tamanho (digamos 128 ou 256 bits). Assim, para assinar um conteúdo, calculamos o hash da informação e do instante corrente (entre outros atributos eventualmente necessários) e enviamos o seu produto para o dispositivo criptográfico, caso um seja utilizado para a guarda das chaves, que realizará a operação criptográfica final, devolvendo seu resultado (o hash cifrado pelo algoritmo com a chave privada do usuário) para o software requisitante.
Dissemos que as assinaturas digitais se baseiam em duas chaves criptográficas, uma delas utilizada para assinar os conteúdos e necessariamente mantida secreta, e outra utilizada para conferir as assinaturas e, portanto, tornada pública. Esse par de chaves deve atender a alguns requisitos mínimos, a saber: a função de assinatura só deve precisar da chave privada; a função de verificação só deve requerer a chave pública e, por fim, deve ser computacionalmente viável obter e chave pública a partir da chave privada, mas não o contrário. Vimos também que é a premissa de manter secreta a chave privada que nos permite afirmar que um determinado conteúdo foi assinado por alguém e ninguém mais. Isto significa que o par de chaves deve estar associado a uma pessoa e essa associação deve ser conhecida a partir somente da chave pública... Mas como saber que uma chave pública está associada a uma pessoa em particular? É aqui que entram os certificados digitais.
Um certificado digital é uma espécie de identidade eletrônica, destinada a associar uma pessoa a uma chave pública. Estritamente, um certificado digital é uma proclamação que assegura que uma determinada chave pública está associada a uma determinada pessoa, proclamação feita por uma instituição que se deu ao trabalho de identificar previamente essa pessoa. Portanto, um certificado digital é um arquivo que contém pelo menos informações a propósito da pessoa para o qual foi emitido e do seu emitente, tudo isso associado à chave pública daquela pessoa. Este arquivo é assinado digitalmente pelo emitente, de modo que qualquer um de posse da sua chave pública (aliás, a chave pública do emitente é incluída no certificado digital assinado) possa verificar a autenticidade da proclamação e, se confiar nessa instituição (chamada Autoridade Certificadora), aceitar aquele certificado como prova de identidade da pessoa.
Um problema surge aqui. Digamos que eu receba um certificado digital emitido para um certo Bob por uma instituição chamada Autoridade Certificadora do Trent. De posse da chave pública de Trent, que é incluída no seu certificado digital, eu posso então verificar a autenticidade da identidade de Bob, já que eu assumo que Trent é uma pessoa confiável, que cumpre com rigor o seu papel de identificar pessoas. Imaginemos, porém, que um certo Mallory, malvado indivíduo sem escrúpulos, fez um acordo com uma certa Eve, que quer se fazer passar por Bob. Mallory emite um certificado falso em nome de Trent e, com ele, assina a chave pública de Eve, associando-a, porém, a Bob. Fica claro, portanto, que preciso ter meios de assegurar que a chave pública da Autoridade Certificadora de fato pertence a ela e a ninguém mais. Isso é feito por outras Autoridades Certificadoras, que assumem o papel de credenciar entidades para emitir certificados digitais destinados aos usuários finais, e assim por diante. A cadeia de confiança entre instituições produzidas por esse ato se chama infra-estrutura de chaves públicas. O último elo dessa cadeia, aquele cujo certificado é auto-assinado e cuja confiabilidade é proclamada por Deus, é conhecido como Autoridade Certificadora Raiz. No Brasil essa rede de confiança recebeu o nome de ICP-Brasil e é definida como "um conjunto de técnicas, arquitetura, organização, práticas e procedimentos, implementados pelas organizações governamentais e privadas brasileiras que suportam, em conjunto, a implementação e a operação de um sistema de certificação".
Como assinalamos, o produto de software - de agora em diante designado como Signthing - deve atender às especificações e restrições estabelecidas pelos órgãos normativos da ICP-Brasil, de modo a adequar-se ao seu âmbito de utilização. Além desses, padrões internacionais do IETF e W3C também são aplicáveis. Esse conjunto de padrões e especificações definem requisitos que precisarão ser atendidos pelo projeto, independente de tais requisitos serem ou não perceptíveis para os usuários. Como tais requisitos estão documentados nas especificações daqueles padrões, eles não serão descritos aqui, salvo como características gerais.
O público alvo esperado do aplicativo é tanto o usuário privado quanto o usuário corporativo e de governo. Espera-se que o primeiro tipo de usuário tenha amplas possibilidades de configuração do aplicativo, definindo algoritmos e comportamentos de acordo com suas próprias necessidades, enquanto que o segundo tipo (tratamos de forma única usuários corporativos e de governo) pode não ter essa liberdade, sendo obrigado a atender os padrões da organização à qual pertence. Além disso, usuários corporativos não necessariamente têm permissão de acesso à Internet e esta é requerida para a verificação da revogação dos certificados digitais. Por fim, aplicações corporativas podem requerer trilhas de auditoria e outras características voltadas para a segurança da corporação. Essas diferenças impõem o projeto de dois produtos, batizados de Signthing Personal Edition e Signthing Corporate Edition. Ambos os produtos devem, evidentemente, atender às especificações da ICP-Brasil e aos demais padrões aplicáveis, o que implica a existência de características comuns, além de atenderem a aos seus próprios requisitos.
Esses vários requisitos e as próprias especificidades do "negócio" assinatura digital impõem características tais que podem ser mapeadas diretamente numa arquitetura de solução esperada para um software desse tipo, ilustrada na figura a seguir:
Observe-se que os processos em destaque estão fora dos domínios da aplicação, cabendo ao projeto apenas lidar com a interface com tais dispositivos. A TSA é a autoridade responsável por fornecer, mediante requisição, um carimbo de tempo. De um modo geral, é esperado que tais requisições estejam acessíveis através do protocolo HTTP (o protocolo TSP independe do protocolo portador das suas mensagens), mas não necessariamente. Provisoriamente, definimos que o aplicativo deve suportar TSP sobre HTTP, nos termos da RFC 3161. Por outro lado, o CSP é o software responsável pela interface com o dispositivo (de hardware ou software) de armazenamento das chaves criptográficas, sendo fornecido pelos fabricantes de dispositivos criptográficos. Há dois "padrões" fundamentais de interface com o CSP: o "padrão" da Microsoft CryptoAPI, utilizado somente no contexto da arquitetura proprietária de desenvolvimento para o sistema operacional Windows, e padrão RSA PKCS#11 - Cryptographic Token Interface Standard, utilizado nos demais casos e de uma forma geral suportado pelos fabricantes de smart-cards. Evidentemente, o aplicativo deve suportar ambos os padrões de interface. Para simplificar o desenvolvimento e o teste do aplicativo, decidimos suportar também chaves criptográficas armazenadas em arquivos no formato definido no padrão PKCS#12 - Personal Information Exchange Syntax Standard.
O componente de interface com o usuário traz algumas restrições significativas. Como o dispositivo de assinatura digital deve interagir com o CSP, conjunto de software e hardware periférico instalado diretamente no computador do usuário, ele deve executar localmente. Isto significa que a sandbox do browser não é adequada ao seu funcionamento. Isso faz com que a interface com o usuário mais adequada a este tipo de aplicação (ou pelo menos a mais simples de ser desenvolvida) seja aquela típica de aplicações desktop. Isso significa que, uma versão desktop do aplicativo deve, necessariamente ser portável, pelo menos entre o sistema operacional da Microsoft, o de mais largo uso, e o Linux. Essa restrição obrigou a escolha da plataforma Java muito cedo no projeto, ainda na sua análise preliminar, de modo a assegurar essa portabilidade com o mínimo de esforço.
Por outro lado, a demanda por aplicações web recomenda que a versão desktop não seja a única disponível para o aplicativo. Esse requisito é reforçado pela necessidade de assinar conteúdos transacionais, geridos por aplicações normalmente web, como Internet Bankings, por exemplo. Assim, prevê-se a disponibilização também de interface web com o usuário. Isso implica, obrigatoriamente, na adoção de estratégias de código móvel para o dispositivo de assinatura, pelo que assinalamos no parágrafo anterior, o que reforça a adoção da plataforma Java.
É esperado que o dispositivo de assinatura seja capaz de assinar qualquer coisa, como sugerido anteriormente, desde transações oriundas em outros aplicativos até documentos armazenados em disco e mensagens de correio eletrônico. Esse requisito, porém, tem forte impacto na arquitetura da solução. Para assinar transações eletrônicas, o dispositivo deve ser disponibilizado na forma de uma applet de código móvel que fornece uma interface do tipo API (application programming interface), de modo a ser facilmente incorporada a uma aplicação externa. Para assinar mensagens de correio, ele deve estar também disponível na forma de plugin de pelo menos um cliente de correio eletrônico (a escolha óbvia recai sobre o Thuderbird, da família Mozilla). Para assinar conteúdos na forma de objetos do sistema de arquivos de um computador pessoal, o dispositivo deve ser disponibilizado como uma aplicação desktop. Esses múltiplos sabores, recomendam fortemente uma estratégia de desenvolvimento incremental, com entregas parciais, assegurando software útil o mais cedo possível.
Como dissemos anteriormente, uma assinatura digital é simplesmente o produto de uma operação criptográfica sobre um buffer de memória, normalmente tão pequeno quanto o produto de uma função de hash. Isso significa que deve haver um meio para que a assinatura persista e seja trocada entre as aplicações envolvidas, além de evidentemente auditada em casos de disputa. Dois são os padrões disponíveis para envelopamento (e consequente troca e armazenamento) das assinaturas digitais: o padrão CMS (Cryptographic Message Syntax), regulado pelo IETF e o padrão XMLDSig, regulado pelo W3C. Assim, é esperado que o projeto venha eventualmente a suportar ambos os padrões.
Os dispositivos de configuração e auditoria são requeridos somente em contextos corporativos. Sua finalidade é assegurar que as várias políticas da organização aplicáveis ao produto sejam efetivamente cumpridas pelos usuários. Um exemplo desse tipo de política é a possibilidade de assinar um documento com um certificado revogado. Evidentemente, em se tratando de um usuário privado, isso pode ser perfeitamente possível, já que o ato é de sua inteira responsabilidade, suas consequências afetando somente a ele. No entanto, uma organização pode entender que isso não deva ser possível em se tratando de documentos corporativos. Portanto, no segundo caso deve existir uma restrição em tempo de execução que assegure o cumprimento dessa regra, restrição que não precisa existir no primeiro caso (as recomendações do ITI falam somente de alertar o usuário para o problema). Isso não pode ser feito se, por exemplo, a configuração do produto for obtida localmente, como normalmente ocorre com as aplicações desktop. Dai termos modelado tais dispositivos como sub-sistemas, de modo a que possam ser implementados, por exemplo, como web services.
Por fim, o dispositivo de validação se destina a assegurar a conformidade às definições da ICP-Brasil dos certificados digitais utilizados nas assinaturas. Como dissemos anteriormente, um dos componentes dessa validação é a verificação da revogação do certificado, o que requer acesso à Internet, já que tais listas são publicadas na web pelas autoridades certificadoras. Ora, nem sempre usuários corporativos e de governo têm acesso irrestrito à Internet, o que recomenda um dispositivo claramente destacado, com requisitos próprios. Um outro aspecto a ser considerado no projeto desse dispositivo é que ele deve ser independente da ICP, de modo a permitir que diferentes regras de validação próprias de infra-estruturas de outros países possam ser aplicadas. Esse requisito decorre da natureza de um projeto de software livre, onde a maior parte da comunidade não tem interesse na ICP-Brasil, mas pode ter interesse em criptografia, o que recomenda o alargamento do escopo do projeto.
Podemos, então, resumir os seguintes requisitos preliminares:
A regulamentação mencionada na seção anterior, em particular os DOC-ICP-15.*, define um conjunto mínimo de requisitos que devem ser atendidos pela aplicações para a realização e verificação de assinaturas digitais em conformidade à ICP-Brasil. Como o alvo do projeto é a satisfação desses requisitos, as próximas seções descrevem aqueles documentos como requisitos do software a ser desenvolvido.
O DOC-ICP-15.01 define um conjunto de perfis de assinaturas digitais que determinam a composição mínima dos atributos assinados e não assinados incluídos nos envelopes criptográficos. Tais perfis servem de base para a definição das políticas de assinatura correntemente suportadas na ICP-Brasil, descritas em detalhes no DOC-ICP-15.03. Em linhas gerais, são os seguintes os perfis suportados pela ICP-Brasil:
Por outro lado, o DOC-ICP-15.03, recomenda a utilização do atributo assinado CommitmentType, que define o tipo de compromisso assumido pelo assinante. Tais compromissos são padronizados pelo IETF na RFC 3126 e estendidos por este regulamento da ICP-Brasil. Assim, acrescentamos os seguintes requisitos ao projeto:
Ainda que o alvo primário do projeto seja o atendimento aos requisitos da ICP-Brasil, o fato de se tratar de software livre recomenda a ampliação do seu escopo para quaisquer infra-estruturas eventualmente disponíveis, já que o público alvo possível para o projeto inclui desenvolvedores e usuários de outros paises. Em vista disso, incorporamos ao projeto os seguintes requisitos adicionais:
Em vista do que dissemos anteriormente, são pertinentes para o projeto os instrumentos normativos referentes não só ao processo de assinatura digital esperado dentro da infra-estrutura, como também normas sobre a emissão dos certificados digitais e listas de certificados revogados (que precisarão ter sua autenticidade verificada), cujas especificações devem ser atendidas onde cabível:
Os seguintes instrumentos normativos são diretamente aplicáveis, já que se referem aos procedimentos e implementações de assinatura digital no âmbito da ICP-Brasil, e, portanto, devem ser rigorosamente obedecidos:
Como a regulamentação da ICP-Brasil não necessariamente contradiz padrões internacionais e a infra-estrutura de chaves públicas é padronizada por vários orgãos, são aplicáveis igualmente inúmeros padrões, listados a seguir:
Documentos de requisitos:
Documentos de design:
Gerenciamento da configuração: