Michel Zanini Autenticação e assinatura de documentos na Internet com polı́tica de certificados digitais A3 Florianópolis - SC 2007 Michel Zanini Autenticação e assinatura de documentos na Internet com polı́tica de certificados digitais A3 Trabalho apresentado na disciplina INE5327, ministrada pelo Professor Renato Cislagui, do curso de Bacharelado em Ciências da Computação da Universidade Federal de Santa Catarina Orientador: Ricardo Felipe Custódio Universidade Federal de Santa Catarina Centro Tecnológico Florianópolis - SC 2007 Sumário Lista de Figuras 1 Introdução 1.1 p. 5 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 7 1.1.1 Objetivos Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 7 1.1.2 Objetivos Especı́ficos . . . . . . . . . . . . . . . . . . . . . . . . . p. 7 1.2 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 7 1.3 Contribuições e Relevância . . . . . . . . . . . . . . . . . . . . . . . . . . p. 7 1.4 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 8 2 Revisão Teórica 2.1 Criptografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 9 p. 9 2.1.1 Simétrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 10 2.1.2 Assimétrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11 2.2 Funções de resumo (Hash) . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12 2.3 Assinaturas digitais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13 2.4 Autoridade Certificadora (AC) . . . . . . . . . . . . . . . . . . . . . . . . p. 14 2.5 Certificados digitais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16 2.6 2.5.1 X.500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16 2.5.2 X.509 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16 Padrões de criptografia de chave pública . . . . . . . . . . . . . . . . . . p. 18 2.6.1 PKCS #7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18 2.6.2 2.7 PKCS #11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18 Dispositivos de segurança . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19 2.7.1 Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19 2.7.2 Smart card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19 3 Tecnologias Java para segurança p. 21 3.1 Applets e polı́ticas de segurança . . . . . . . . . . . . . . . . . . . . . . . p. 21 3.2 JCA e JCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22 3.3 Keystore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22 3.3.1 SunPKCS11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24 3.3.2 SunMSCAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24 3.4 Java Authentication and Authorization Service . . . . . . . . . . . . . . . p. 25 3.5 Segurança na camada web do JavaEE . . . . . . . . . . . . . . . . . . . . p. 26 3.5.1 Exemplo de segurança declarativa . . . . . . . . . . . . . . . . . . p. 27 3.5.2 Tipos de autenticação na camada web . . . . . . . . . . . . . . . p. 28 4 Conclusão p. 29 Referências p. 30 Lista de Figuras 1 Criptografia simétrica para enviar um texto seguro: o texto é criptogradado e descriptografado utilizando a mesma chave secreta compartilhada (GROUP, 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 10 2 Criptografia assimétrica para enviar um texto seguro: o processo é lento pois o texto é criptografado utilizando uma chave pública. Depois é descriptografado utilizando uma chave privada pessoal (GROUP, 2007) . . p. 11 3 Função de hash: um resumo único é gerado a partir do texto (GROUP, 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12 4 Assinatura digital rudimentar: o processo é lento pois o texto é criptografado utilizando um algoritmo de chave pública (GROUP, 2007) . . . . p. 13 5 Assinatura digital: ao combinar assinatura digital com funções de hash podemos verificar a integridade dos dados, e melhorar o desempenho do processo (GROUP, 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14 6 Hierarquia de autoridades certificadoras e usuários finais . . . . . . . . . p. 15 7 Exemplo de um nome único X.500 . . . . . . . . . . . . . . . . . . . . . . p. 16 8 Conteúdo de um certificado digital X.509 (GROUP, 2007) . . . . . . . . . p. 17 9 Exemplo de dispositivo token USB . . . . . . . . . . . . . . . . . . . . . p. 19 10 Layout de um smart card para o e-CPF . . . . . . . . . . . . . . . . . . . p. 20 11 Leitora de smart card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20 12 Arquitetura JCA/JCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23 1 Introdução Desde 2001 com a promulgação da medida provisória 2.200-2 ficou instituı́do a InfraEstrutura de Chaves Públicas Brasileira (ICP-Brasil), garantir a autenticidade, a integridade e a validade jurı́dica de documentos em forma eletrônica e das aplicações habilitadas que utilizem certificados digitais. Dessa forma, documentos eletrônicos passaram a ter eficácia semelhante aos em papel, ou legalmente equivalentes. Isso significa que, as mesmas leis que se aplicam a documentos em papel, também se aplicam aos digitais. Diversas aplicações do governo já estão disponı́veis, fazendo uso de documentos eletrônicos certificados por alguma autoridade certificadora ligada à ICP-Brasil. A criação do CPF eletrônico (e-CPF) e o CNPJ eletrônico (e-CNPJ) possibilitam a pessoa fı́sica ou jurı́dica, a utilização de diversos serviços públicos ou privados. Por exemplo, com a identidade digital representada pelos certificados ligados a ICP-Brasil, o e-CPF e e-CNPJ, é possı́vel consultar e realizar serviços relacionados com a Receita Federal, como verificar o histórico das declarações de imposto renda. Os certificados eletrônicos podem ser requeridos por qualquer cidadão ou empresa do paı́s, que podem ter sua chave privada protegida por hardware (tokens ou smartcards) e permitem confirmar legalmente sua identidade em transações eletrônicas. Com o e-CNPJ empresas podem trocar documentos e contratos oficias, de forma eletrônica e segura; com o e-CPF advogados podem peticionar processos na justiça, sem sair de casa para se movimentar até um fórum. Com o uso dos certificados podemos comprovar nossa identidade digital, dessa forma, aplicações com requisitos avançados de segurança, podem utilizar autenticação através de um certificado assinado por uma autoridade certificadora ligada à ICP-Brasil. Dessa forma, é possı́vel que o usuário não apresente um login e uma senha como credenciais, e sim, um certificado que comprova sua identidade. Há duas polı́ticas de certificados digitais e-CPF e e-CNPJ, a tipo A1 e a tipo A3. A diferença entre uma e outra é o tempo de validade do certificado digital associado ao 6 documento e a forma de armazenamento da chave privada. A tipo A1 possui um ano de validade e o par de chaves é gerado no computador do titular, onde também fica armazenada a chave privada. A Tipo A3 tem o certificado válido por três anos e utiliza um hardware, isto é, um elemento fı́sico para gerar o par de chaves e armazenar a chave privada. Este hardware é representado por um cartão inteligente (smartcard ) ou um token. Através desse modelo de segurança, pode-se realizar transações que exigem assinaturas fı́sicas em papel, como firmar contratos, empréstimos e procurações, entre outros. Tudo isso feito com segurança pela Internet, através de uma aplicação web, podendo estar em casa ou até mesmo em um quiosque público. Basta conectar o dispositivo de segurança ao computador, efetivar a autenticação com uso do certificado, e realizar a transação eletrônica segura. Como a cada dia se populariza o uso dos certificados por usuários comuns, aplicações começam a surgir tirando proveito de suas caracterı́sticas. Um bom exemplo são as aplicações de peticionamento eletrônico, como o Peticionamento Seguro da Justiça do Trabalho (e-DOC) onde é possı́vel assinar, protocolar e enviar documentos através da Internet. Através de tais aplicações advogados podem se autenticar no sistema, utilizando certificados ligados à ICP-Brasil, e posteriormente, assinar e enviar documentos do seu computador diretamente para a aplicação web que fará a validação do certificado e da assinatura. Outro exemplo, é o acesso a conta bancária pelo Banco do Brasil, através de certificado digital. A aplicação do banco acessa o token ou smartcard conectado no computador do usuário através de um applet Java, confere o certificado, e então efetua sua autenticação. A autenticação por certificado garante mais segurança para o cliente, e ele pode efetuar transações com limites superiores em relação ao acesso tradicional. O presente trabalho de pesquisa visa construir uma aplicação web demonstrando esses conceitos. A aplicação requisita a autenticação através de certificados do tipo A3, acessando a máquina do usuário através de um applet, e possibilita a assinatura digital e o envio dos documentos assinados digitalmente com um certificado ligado à ICP-Brasil. 7 1.1 Objetivos 1.1.1 Objetivos Gerais Demonstrar a prática e os conceitos necessários para criar uma aplicação web em Java que utilize certificados digitais do tipo A3, para autenticação e assinatura de documentos. 1.1.2 Objetivos Especı́ficos • Fazer uma revisão sobre os principais conceitos ligados a criptografia. • Estudar o suporte de Java para autenticação e autorização na web. • Estudar conceitos de assinatura digital e certificados X.509. • Estudar as API’s Java de acesso ao hardware do token, e também ao repositório do Windows. • Estudar o framework BouncyCastle para assinar e conferir documentos no padrão PKCS #7. • Desenvolver um applet capaz de interagir com o token localizado na máquina do usuário. 1.2 Problema Devido a pouca documentação encontrada na Internet desenvolver uma solução com os objetivos citados acima, se torna difı́cil. Não existem exemplos práticos, que tornam claro o que deve ser feito. Somado a isso, existe o problema de integrar o mecanismo de autenticação por certificado com a segurança declarativa do Java Enterprise Edition (JavaEE). 1.3 Contribuições e Relevância A contribuição do trabalho é fornecer uma aplicação de exemplo, a qual se possa basear, para desenvolvimento de aplicações com os mesmos requisitos de segurança. Junto com o exemplo, também prover os conceitos necessários para seu entendimento, bem como apresentar suas vantagens e limitações. 8 1.4 Motivação É curioso notar que muitos processos e transações efetuados de forma presencial hoje em dia podem ser realizados com segurança pela Internet. Isso é possı́vel com a utilização de certificados e assinatura digital. Dessa forma, em breve será possı́vel estender essas aplicações de forma ampla, quando os certificados do tipo A3 se tornarem populares. 2 Revisão Teórica 2.1 Criptografia Segundo Menezes, Oorschot e Vanstone (1996) criptografia é o estudo de técnicas matemáticas relacionadas aos aspectos de segurança da informação como confiabilidade, integridade dos dados, autenticação de entidades e origem de dados. Uma definição mais clara para criptografia pode ser entendida como sendo uma técnica matemática usada para transformar (criptografar) um texto plano (legı́vel) em conteúdo cifrado (ilegı́vel), que deixe a informação transmitida segura, assim como o processo inverso, transformar (descriptografar) o texto cifrado em formato original. Para que a mensagem possa ser cifrada, é utilizado uma chave, que pode ser privada ou pública, e através dela o algoritmo criptográfico consegue cifrar a informação. A troca de mensagens de forma segura nos acompanha historicamente de longas datas. Desde os sı́mbolos secretos utilizados pelos egı́pcios, à brincadeira da “lı́ngua do pê”, até as técnicas utilizadas pelos americanos na Segunda Guerra Mundial para proteger estratégias e segredos nacionais. Com a evolução dos computadores e sistemas de comunicações na década de 60 originou a necessidade de proteger as informações e serviços em meio digital. Com os computadores passamos a poder fazer cálculos matemáticos sofisticados baseados em problemas muito difı́ceis de resolver, como a fatoração de números primos. A criptografia se baseia em tais algoritmos para garantir que mesmo com a velocidade atual dos computadores, ninguém possa decifrar facilmente um texto criptografado. De acordo com Menezes, Oorschot e Vanstone (1996) a criptografia permite a implantação de diversos serviços de segurança, dos quais, os principais são: • Confiabilidade É um serviço usado para manter o conteúdo da informação seguro de todos os que não estejam autorizados a vê-lo. • Integridade dos dados Serviço que permite detectar se os dados foram alterados ou corrompidos por terceiros. 10 • Autenticação Autenticação está relacionado com identificação. Quando duas partes desejam se comunicar, ambas precisam se identificar e provar sua identidade umas as outras. • Não-repúdio É um serviço que previne entidades de negar suas ações. A criptografia pode ser classificada de acordo com o uso da chave. A criptografia simétrica utiliza uma chave secreta, tanta para cifrar, quanto para decifrar. Essa chave deve ser mantida como segredo para que a informação possa continuar confidencial. Já a criptografia assimétrica utiliza uma chave privada e uma chave pública. A chave privada deve ser mantida em segredo, assim como a chave secreta da criptografia simétrica, e a chave pública deve ser disponibilizada para todos que tiverem interesse em obtê-la. 2.1.1 Simétrica A criptografia mais simples é a que usa a mesma chave tanto para criptografar quanto para descriptografar. São os chamados algoritmos simétricos, ou algoritmos de chave simétrica. A segurança do algoritmo simétrico está em manter a chave compartilhada a salvo, por isso normalmente ela é chamada de chave secreta. Entre os algoritmos mais famosos estão o DES e o Triple DES, ambos criados pelo governo dos EUA. Uma visão geral do processo pode ser observado na Figura 1. Figura 1: Criptografia simétrica para enviar um texto seguro: o texto é criptogradado e descriptografado utilizando a mesma chave secreta compartilhada (GROUP, 2007) Os algoritmos simétricos trazem um problema. Para enviar a mensagem de forma segura, é preciso enviar também a chave secreta. Alem disso, para manter a comunicação com diversas pessoas, você precisa compartilhar diversas chaves, e mantê-las seguras. Entretanto, esse algoritmos são muito rápidos, e são utilizados para efetuar a maior parte do trabalho de criptografia. 11 2.1.2 Assimétrica Para resolver o problema dos algoritmos simétricos, foram criados os algoritmos assimétricos ou algoritmos de chave pública. Eles utilizam chaves diferentes para criptografar e descriptografar, chamadas de chave pública e chave privada. Nesse esquema, uma mensagem que foi criptografada com uma chave só pode ser descriptografada com a outra. Ou seja, só pode ser descriptografada com a chave privada, a mensagem que foi criptografada com a chave pública. O algoritmo assimétrico mais conhecido é o RSA, inicialmente publicado em 1977 por Ronald Rivest, Adi Shamir e Leonard Adleman. Uma visão geral do processo pode ser observado na Figura 2. Figura 2: Criptografia assimétrica para enviar um texto seguro: o processo é lento pois o texto é criptografado utilizando uma chave pública. Depois é descriptografado utilizando uma chave privada pessoal (GROUP, 2007) Como sugerem seus nomes, a chave pública pode ser distribuı́da a vontade, e a chave privada deve ser armazenada e protegida. Nesse esquema, se a entidade A quer mandar uma mensagem confidencial para B, ela utiliza a chave pública de B (que por ser pública pode estar disponı́vel pela Internet) para criptografar a mensagem, dessa forma apenas a chave privada de B poderá descriptografar e ler a mensagem original. Como a chave privada de B está guardada a salvo, somente B pode vê-la. Dessa forma, a criptografia assimétrica evita a troca de chaves, pois cada entidade terá sua chave privada, e disponibilizará a sua chave pública. Uma das principais limitações dos algoritmos de chave pública é o desempenho. Com cálculos bem mais complexos, esse algoritmos chegam a ser mil vezes mais lentos que os de chave simétrica. Por conta disso, se utiliza um processo em duas etapas para criptografar mensagens: um algoritmo simétrico é usado para criptografar toda a mensagem e depois é criptografada apenas a chave simétrica utilizada, com um algoritmo de chave pública. Devem ser enviadas duas informações, a mensagem e a chave simétrica criptografadas, 12 para que o processo possa ser invertido do outro lado. Em geral é utilizado a chave pública para criptografar, porque o processo inverso, criptografar com a chave privada, permitiria que qualquer um que obtenha acesso a chave pública possa ler a mensagem. Essa capacidade é importante na implementação de assinaturas digitais. 2.2 Funções de resumo (Hash) A função de resumo, ou função de hash, é um cálculo que visa transformar a mensagem em um resultado de tamanho fixo. O processo é interessante por causa de duas propriedades que o resultado, também chamado de hash, tem. Primeiro, dependendo do tamanho da mensagem, e do tipo de algoritmo usado, as chances de gerar o mesmo resultado são extremamente pequenas. Segundo, mudando um bit da mensagem original da qual o hash foi gerado, produz uma mudança imprescindı́vel no novo resultado calculado, depois do novo hash gerado. Essas propriedades de unicidade e resultado não previsto fazem as funções de resumo muito úteis para o processo de criptografia. Outra caracterı́stica das funções de resumo é a velocidade, elas executam rapidamente. A Figura 3 ilustra o processo. Figura 3: Função de hash: um resumo único é gerado a partir do texto (GROUP, 2007) As funções de hash são muito úteis para detectar a integridade dos dados, ou seja, detectar se uma mensagem enviada foi alterada ou editada no caminho de envio. Esse processo é importante pois de posse de um conhecimento prévio sobre o tipo de mensagem enviada, pode-se adulterá-la para que ela produza outra mensagem ao ser descriptografada. Antes da mensagem ser enviada aplica-se uma função de hash a ela, produzindo um resultado único para essa mensagem. Então é enviado, juntamente com a mensagem, o seu 13 hash, ambos criptografados. Do outro lado, após descriptografar, o hash e a mensagem original são recuperados. Novamente se aplica a função de hash sobre a mensagem, e se, os hash’s baterem, significa que a mensagem não foi alterada durante o envio. 2.3 Assinaturas digitais Na troca de mensagens é possı́vel utilizar a criptografia para garantir a confidenciabilidade dos dados. Mas as vezes queremos apenas garantir a procedência da mensagem, para termos certeza de que ela foi enviada por quem esperamos. Esse é o conceito de assinatura digital. A utilidade das assinaturas digitais reside no fato que apenas o criador da assinatura sabe o segredo (chave privada) para criá-la, e ela pode ser verificada utilizando informação pública (chave pública). Assinaturas digitais estão ligadas ao não-repúdio, ou seja, uma entidade não pode negar ter assinado uma mensagem, caso sua chave pública confirme que foi assinada. Se invertermos o processo da Figura 2, como na Figura 4 temos uma forma rudimentar de assinatura digital. Ou seja, como a mensagem é criptografada com a chave privada, então temos a certeza de que foi enviada pelo dono da chave. Figura 4: Assinatura digital rudimentar: o processo é lento pois o texto é criptografado utilizando um algoritmo de chave pública (GROUP, 2007) Este é o conceito do processo, na implementação real as coisas são mais complexas. Algoritmos de chave pública são lentos, portanto não é viável usá-los para criptografar o texto inteiro. Por outro lado, os algoritmos de função de resumo (hash) são muito rápidos e úteis para criar uma espécie de “impressão digital” do texto. 14 Para implementar esse processo gera-se um hash do texto que se deseja enviar, e então o hash é criptografado usando uma chave privada. Como o hash é de tamanho fixo, e em geral é bem menor que o texto, é mais eficiente criptografá-lo. Então, antes do envio, o texto e o hash são concatenados. De posse do texto original e o hash criptografado, pode-se inverter o processo. O hash é descriptografado utilizando a chave pública, então outro hash é novamente calculado do texto original, depois eles são comparados. Caso a comparação falhe, ou o texto foi alterado no envio ou não foi assinado por quem que se espera. Esse processo pode ser observado na Figura 5. Figura 5: Assinatura digital: ao combinar assinatura digital com funções de hash podemos verificar a integridade dos dados, e melhorar o desempenho do processo (GROUP, 2007) Utilizando-se algoritmos assimétricos podemos garantir o envio de mensagens de forma segura, e através de assinaturas digitais garantir a identidade do emissor da mensagem. Porém ainda resta um pouco de falha. Tudo depende da posse da chave pública de quem quer trocar informações. Como garantir se está se recebendo a chave pública correta? E se a chave foi adulterada durante o envio? Aqui entram as autoridades certificadoras e os certificados digitais. 2.4 Autoridade Certificadora (AC) Se você recebesse a assinatura digital pessoalmente de um amigo seu, teria certeza de que é confiável. Se seu amigo também confirmou a validade de chaves recebidas pessoalmente, então você pode confiar nelas. Caso alguém perca sua chave pública, você precisa de alguma forma ser notificado, para que possa trocá-la por uma nova confiável. Uma rede 15 de confiança dessas fica enormemente complexa numa abrangência como a Internet. Para resolver esse problema foram criadas as Autoridades Certificadoras (AC) que certificam que uma determinada pessoa possui a chave pública que diz possuir. As autoridades certificadoras são responsáveis por gerenciar o ciclo de vida dos certificados e fornecer aos usuários garantias necessárias para seu uso. Uma AC emite um certificado digital, com uma chave pública, para o usuário que o requisita. Para garantir a validade do processo, a AC assina o certificado com sua chave privada. Dessa forma, podemos garantir que a chave pública de uma entidade é realmente dela, se uma AC confiável a assinou. Para conferir a assinatura podemos obter a chave pública que a AC disponibiliza, para uso. As AC costumam possuir também uma Lista de Certificados Revogados (LCR), onde apresentam quais certificados foram revogados de seus donos. Assim, além de verificar se a chave pública foi assinada por uma AC confiável, deve-se acessar a LCR para saber se o certificado não foi revogado. A Infra-estrutura de Chaves Públicas brasileira (ICP-Brasil) é uma autoridade certificadora tomada como base para certificados usados pelo governo, chamada de AC raiz. A autoridade certificadora raiz tem por objetivo assinar certificados de autoridades certificadoras intermediárias. Essas, por sua vez, podem assinar certificados de outras AC intermediárias, ou de usuários finais. A figura 6 ilustra a hierarquia. Figura 6: Hierarquia de autoridades certificadoras e usuários finais Para um certificado e-CPF ou e-CNPJ, pertencente a um usuário final, ser considerado válido, ele deve ser assinado por uma AC intermediária, que por sua vez, foi assinada pela ICP-Brasil. Além disso, não deve estar presente na lista de certificados revogados, bem como, estar dentro do prazo de validade. 16 2.5 Certificados digitais Um certificado digital é como um “envelope” que possui uma chave pública e informações de quem é o seu dono. Esse “envelope” é assinado por uma autoridade certificadora, que atesta a validade, autenticidade e confiabilidade da chave pública. Todo certificado está associado a uma chave privada e uma cadeia de certificados. Exceto o primeiro e o último, cada certificado da cadeia tem uma chave privada que assina o certificado seguinte. O primeiro certificado, o raiz, é auto-assinado e deve ser considerado confiável para que a cadeia seja válida. O último, do usuário final, simplesmente apresenta a chave pública que normalmente se está interessado em conhecer para alguma finalidade. 2.5.1 X.500 O padrão X.500 define como deve ser organizada a informação referente a identificação de uma entidade. É usado no formato de certificados X.509 para identificar o emissor e o titular do certificado. Um nome único no padrão X.500 contem as seguintes informações (Figura 7): Figura 7: Exemplo de um nome único X.500 • Nome comum (CN - commonName) Normalmente o nome de uma pessoa. • Setor da empresa (OU - organizationUnit) Subdivisão da empresa ou organização. • Nome da empresa (O - organizationName) Nome da empresa ou organização. • Local (L - localityName) Nome da cidade. • Estado (S - stateName) Nome do estado ou provı́ncia. • Paı́s (C - country) Nome do paı́s. 2.5.2 X.509 O formato de certificados X.509 foi desenvolvido pela International Standards Organization (ISO) e incorporado pela American National Standards Institute (ANSI) e Internet 17 Engineering Task Force (IETF). O X.509 define quais informações podem estar presentes em um certificado e descreve em que formato os dados devem ser escritos. Atualmente se encontra na terceira versão. Em um certificado no formato X.509 v3 estão presentes as seguintes informações (Figura 8): Figura 8: Conteúdo de um certificado digital X.509 (GROUP, 2007) • Identificador do algoritmo de assinatura Identifica qual algoritmo foi utilizado para assinar o certificado. • Versão do certificado Versão do formato do certificado X.509. Pode ser v1, v2 ou v3. • Número serial Representa o número de série do certificado. Esse número é único para cada autoridade certificadora. • Emissor Nome único no padrão X.500 da AC responsável por emitir o certificado. • Prazo de validade Nesse campo estão a data de inı́cio e fim da validade do certificado. • Titular Nome único no padrão X.500 do dono do certificado. • Assinatura do emissor O emissor do certificado assina os dados presente nele, sendo que qualquer alteração nos mesmos, pode ser detectada. • Extensões Os certificados X.509 versão 3 possuem extensões que podem conter informações diversas além das presentes acima, como por exemplo, o CPF ou CNPJ do titular. 18 2.6 Padrões de criptografia de chave pública A empresa RSA Security definiu uma série de padrões de criptografia de chave pública denominados Public Key Cryptography Standards (PKCS). As aplicações que utilizam a criptografia de chave pública, em geral, utilizam esses padrões. Atualmente existem quinze padrões e a seguir dois deles serão descritos pois são necessários para desenvolvimento de aplicações que acessam dispositivos de segurança para assinar documentos. 2.6.1 PKCS #7 O padrão PKCS #7, também conhecido como Cryptographic Message Syntax (CMS), descreve uma sintaxe geral para dados criptografados ou assinados. Permite que diferentes tipos de proteção sejam aninhados, ou seja, uma mensagem assinada pode ser usada como texto plano para ser criptografada ou uma mensagem criptografada pode ser assinada. As mensagem assinadas também podem ter atributos anexados a ela que podem ser inclusos na assinatura final. É um protocolo importante pois não apenas pode ser usado por si mesmo, mas também forma a base para ser usado em outros protocolos como o S/MIME (Secure/Multipurpose Internet Mail Extensions). 2.6.2 PKCS #11 PKCS #11 é uma API, desenvolvida para ser independente de plataforma, que define uma interface genérica para dispositivos criptográficos: tokens, smart cards e Hardware Security Modules (HSM). A API foi desenvolvida para ser uma camada de abstração sobre o dispositivo e executar funções de criptografia. A API foi denominada de “Cryptoki” e é escrita em C. Através dela é possı́vel acessar o dispositivo para assinar utilizando a chave privada que o dispositivo protege. A API PKCS #11 é largamente usada para acessar os dispositivos, e como foi feita em C, existem várias API’s escritas em outras linguagens que funcionam como uma camada que reside sobre a cryptoki. Dessa forma a aplicação acessa a API da linguagem utilizada, que repassa a chamada para a cryptoki em C. 19 2.7 Dispositivos de segurança Um dispositivo de segurança é um hardware que visa proteger a chave privada associada com uma cadeia de certificados. Essa proteção é necessária para a polı́tica de certificados do tipo A3, onde define-se que a chave privada deve ser protegida pelo hardware, e nunca deve deixar o dispositivo. Em geral tais dispositivos possuem pequena capacidade de processamento, e são capazes de executar algoritmos de criptografia internamente, dessa forma não precisam enviar a chave privada para o computador que estão conectados. Quando for requisitado ao dispositivo a realização de uma função de criptografia que utilize sua chave privada o dispositivo requisita uma senha, chamada de PIN (Personal Identification Number). 2.7.1 Token O “Token Criptográfico” (Figura 9) é um tipo de dispositivo de segurança geralmente ligado a porta USB do microcomputador sem a necessidade de uma leitora especı́fica para entrar em comunicação com o computador ao qual se conecta. Figura 9: Exemplo de dispositivo token USB 2.7.2 Smart card Smart card é um cartão que geralmente assemelha-se em forma e tamanho a um cartão de crédito convencional de plástico com tarja magnética. Na Figura 10 podemos observar o layout de um smart card do certificado e-CPF. O smart card é conectado ao computador através de um dispositivo de hardware, uma leitora de smart cards, que pode ser vista na Figura 11. 20 Figura 10: Layout de um smart card para o e-CPF Figura 11: Leitora de smart card 3 Tecnologias Java para segurança 3.1 Applets e polı́ticas de segurança Um applet é um programa escrito em Java que pode ser incluı́do dentro de uma página HTML, assim como uma imagem. O navegador necessita ter instalado a Máquina Virtual Java para poder exibir o applet. Dessa forma, o código do applet é transferido para o computador cliente e é executado na Máquina Virtual local. Geralmente, é utilizado um applet para disponibilizar uma interface gráfica complexa, incapaz de ser feita apenas com HTML. Applets também são utilizados quando se torna necessário acessar um recurso da máquina cliente, o qual o servidor não tem acesso. Applets não assinados são considerados não confiáveis, e não tem permissão para ler e escrever no sistema de arquivos do cliente e fazer conexões com qualquer servidor diferente do que deu origem ao applet. São proibidos de iniciar novos programas no computador cliente e carregar bibliotecas nativas ou fazer chamadas ao sistema operacional. Essas limitações são conhecidas como sandbox (caixa de areia), onde o applet roda sem ter acesso aos recursos do cliente. Para que o applet possa ser considerado confiável ele deve ser assinado por um certificado que possui uma autoridade certificadora raiz confiável pelo navegador. Se a AC raiz não estiver na lista de autoridades certificadoras confiáveis pelo navegador, a Máquina Virtual Java irá questionar o usuário, para que ele possa aceitar ou não a confiabilidade do certificado. Se o applet for considerado confiável, ele pode acessar o sistema de arquivos da máquina cliente, bem como acessar um dispositivo de hardware, como um token USB ou um smart card. Através dessa capacidade é possı́vel, com um applet assinado, realizar assinatura digital de documentos na Internet, utilizando um certificado digital com polı́tica do tipo A3. 22 3.2 JCA e JCE A Java Cryptography Architecture (JCA) fornece a arquitetura básica para funções de segurança em Java. A JCA traz interfaces e objetos fundamentais para criptografia, porém não os implementa. Trata-se de uma abstração que permite ser estendida por outros fabricantes através de providers que farão o trabalho de criptografia real. Dessa forma, o desenvolvedor de aplicações pode escolher quais implementações dos algoritmos de criptografia que melhor atenda suas necessidades. Providers são implementações concretas dos algoritmos de criptografia. Eles implementam as classes do JCA que acharem necessárias, fornecendo apenas os algoritmos desejados. Atualmente a instalação do Java já traz um provider instalado que contêm as implementações dos algoritmos mais comuns, o SunJCE. Outro provider bastante conhecido é o Bouncy Castle, uma implementação open source. A Java Cryptography Extensions (JCE) é uma extensão da JCA. Ela não foi incluı́da anteriormente no Java Development Kit (JDK) por questões de proibição de exportação de implementações de criptografia do governo dos Estados Unidos. A arquitetura JCA/JCE permite ao fabricante fornecer os algoritmos que julgar mais importante. Ela é comumente chamada de“arquitetura baseada em provedores de serviço”. O desenvolvedor utiliza classes do JCA e JCE, que através do padrão de projetos fábrica, instancia as classes concretas implementadas pelos providers. As classes concretas não ficam visı́veis ao programador, ele apenas informa ao método fábrica qual provider deseja usar. Uma visão da Figura 12 mostra como as camadas da arquitetura trabalham juntas. O código da aplicação chama as classes do JCA/JCE, que por sua vez chamam classes da Service Provider Interface (SPI), que por fim, invocam as classes da implementação do provider, onde estão as implementações dos algoritmos propriamente ditas. 3.3 Keystore Uma keystore é um repositório de certificados e chaves privadas. Permite armazenamento e gerenciamento centralizado dos certificados. A keystore habilita um usuário a administrar e armazenar seus pares de chaves públicas e privadas com certificados associados para usá-los em serviços de autenticação e integridade de dados. A implementação padrão de uma keystore é em arquivo, e protege suas chaves privadas com senha. Sem 23 Figura 12: Arquitetura JCA/JCE uma keystore seria necessário cuidar de vários arquivos: dois para o par de chaves pública e privada e mais vários para cada chave pública recebida. Porém, com um keystore em arquivo, todas as chaves poderiam ser armazenadas em um lugar com uma única senha. Existem dois tipos de entrada de dados armazenados em uma keystore: • Chaves Normalmente uma chave secreta ou uma chave privada com uma cadeia de certificados associada. É armazenado em um formato protegido para prevenir acesso não autorizado. • Certificados confiáveis Contém a chave pública e as informações pertencente a uma entidade confiável. São chamados de certificados confiáveis pois o dono da keystore acredita que a chave pública pertence mesmo a entidade associada. Todas as entradas de dados (chaves e certificados confiáveis) armazenadas na keystore são acessados por aliases únicos. O alias é um nome lógico com caracteres não sensı́veis ao caso. É escolhido na hora de adicionar uma entrada a keystore, e usado posteriormente para resgatar a informação para uso. O utilitátio keytool do JDK permite a criação de keystores em arquivo, bem como importação e exportação de certificados, chaves públicas e privadas. A classe “java.security.KeyStore” possui um método de fábrica chamado “getInstance” que funciona de acordo com a arquitetura do JCA/JCE, ou seja, cada provider pode implementar uma keystore em formatos diferentes. Uma implementação comum, feita pela Sun Microsystems, que vem junto com o JDK, é a keystore em arquivo utilizando um formato de dados proprietário chamado JKS. Além do JKS, é possı́vel utilizar keystore em arquivo no formato padrão PKCS #12 (Personal Information Exchange Syntax 24 Standard), que define um formato portável de armazenar e transportar chaves privadas e certificados associados. Outras implementações de keystores estão disponı́veis, como as implementações oferecidas pelos providers SunPKCS11 e a SunMSCAPI. 3.3.1 SunPKCS11 O padrão PKCS #11 define uma interface de programação nativa para acessar tokens criptográficos e smart cards. Para ajudar aplicações Java a acessar a interface nativa PKCS #11 de acesso aos tokens um novo provider foi adicionado no JDK 5 da Sun Microsystems, o SunPKCS11. Ele funciona como uma ponte entre a aplicação Java e a interface nativa PKCS #11, a cryptoki. O provider SunPKCS11 fornece uma implementação de keystore capaz de acessar o dispositivo de segurança de forma transparente. Ou seja, para passar a usar a keystore do SunPKCS11 em uma aplicação, pouco código precisa mudar, é necessário apenas mudar a forma de obter a implementação da keystore. É possı́vel, por meio do keystore da SunPKCS11, acessar as chaves privadas e certificados armazenados no dispositivo de segurança e utilizar as suas funções de criptografia. 3.3.2 SunMSCAPI No sistema operacional Microsoft (MS) Windows, a CryptoAPI (CAPI) define uma interface padrão para realizar operações criptográficas assim como acessar as chaves e certificados do usuário, que o Windows gerencia. O provider SunMSCAPI, disponı́vel no JDK 6 da Sun Microsystems, define uma camada no topo da CryptoAPI e ajuda aplicações em Java a acessar os serviços criptográficos oferecidos pela CryptoAPI usando a tecnologia e arquitetura JCA/JCE. As aplicações em Java podem utilizar uma implementação de keystore que acessa a CryptoAPI, oferecido pelo provider SunMSCAPI. Isso significa que após obter-se a keystore da CryptoAPI, o resto das operações não mudam devido a arquitetura JCA/JCE, ou seja, devido ao uso de interfaces e implementações abstratas, basta escolher a implementação de keystore, e o resto fica transparente. É possı́vel, por meio do keystore da SunMSCAPI, acessar as chaves privadas e certificados armazenados no repositório do Windows, bem como utilizar as implementações de seus algoritmos de criptografia. 25 3.4 Java Authentication and Authorization Service O Java Authentication and Authorization Service (JAAS) se proproe a restringir o acesso de usuários ou processos a apenas alguns recursos da aplicação, independente da tecnologia de segurança utilizada. O JAAS pode ser usado para dois propósitos: • Autenticação É o processo de identificação de uma entidade em um sistema. Isso é feito comparando-se as credenciais passadas pela entidade com as esperadas pelo sistema. O método mais comum de autenticação é o uso de senhas, mas pode-se utilizar várias outras técnicas, como certificados digitais ou biometria. • Autorização É o processo de verificação dos direitos que uma entidade possui para acessar / manipular um determinado recurso do sistema. Por exemplo, restringir o acesso de um usuário de um sistema operacional para que apenas ele possa acessar / manipular sua pasta pessoal. A autenticação no JAAS é realizada de forma flexı́vel, independente de como as credenciais são obtidas. Para cada tecnologia de autenticação é implementado um módulo de segurança estendendo a interface “javax.security.auth.spi.LoginModule”. Toda a dependência da tecnologia de autenticação está localizada nas implementações de LoginModules. A seguir são descritos alguns módulos de autenticação disponı́veis, os dois primeiros estão presentes no pacote “org.jboss.security.auth.spi” e os três restantes no pacote “com.sun.security.auth.module”. • UsersRolesLoginModule Disponı́vel ao utilizar o servidor de aplicações JBoss esse módulo permite autenticar entidades através de logins e senhas em arquivos de propriedades. • DatabaseServerLoginModule Esse módulo está disponı́vel ao utilizar o servidor de aplicações JBoss e permite autenticar entidades através de logins e senhas em tabelas de um banco de dados. • Autenticação através do sistema operacional As classes NTLoginModule e UnixLoginModule implementam os módulos para obter as credenciais dos usuários do Microsoft Windows NT e sistemas operacionais baseados em Unix, respectivamente. 26 • JndiLoginModule Através desse módulo é possı́vel autenticar uma entidade através de um servidor de diretórios, desde que ele esteja configurado através do Java Naming and Directory Interface (JNDI). • KeyStoreLoginModule Esse módulo permite autenticar através de qualquer implementação de keystore, ou seja, keystores em arquivo utilizando os formatos JKS ou PKCS #12, ou mesmo as implementações de keystores oferecidas pelos providers SunPKCS11 e SunMSCAPI. Isso significa que através desse módulo é possı́vel autenticar um usuário utilizando seu certificado digital. Enquanto os LoginModules obtêm as informações para autenticação, o objeto “javax.security.auth.login.LoginContext” é responsável por armazenar essas informações, durante o perı́odo de tempo que a entidade permanecer autenticada. Para iniciar um processo de autenticação cria-se um LoginContext, e associa-se a ele um objeto “javax.security.auth.Subject” e um “javax.security.auth.callback.CallbackHandler”. O Subject armazena as informações relacionadas a uma entidade colhidas no processo de autenticação, por exemplo: o nome, o login e a senha. Um objeto Subject possui um ou mais “java.security.Principal” para representar sua identidade, por exemplo, representar que o usuário é um administrador. O CallbackHandler é responsável por relacionar o LoginContext com um ou mais LoginModules e por solicitar informações necessárias para que os módulos possam executar, como por exemplo: solicitar ao usuário a digitação de seus dados de login e senha. 3.5 Segurança na camada web do JavaEE O Java Enterprise Edition (JavaEE) utiliza uma abordagem declarativa de configurações de segurança baseada no conceito de papéis. Uma aplicação define um ou mais papéis e depois quais operações podem ser executados por cada papel. No contexto de aplicação web as operações consistem em acesso a uma URL pelo navegador. A abordagem é declarativa pois o desenvolvedor não precisa chamar nenhum método para validar uma senha, nem para autorizar ou não a realização de uma operação. Essa configuração é feita de forma declarativa em um arquivo XML, o descritor da aplicação web, chamado de “web.xml”. Entretanto, a especificação JavaEE não define como as credenciais da entidade são validadas, nem como uma entidade é associada a um papel. Essas questões são de responsabilidade do administrador do servidor de aplicações, e cada produto tem liberdade 27 para implementá-las da forma que julgar mais adequada. O servidor de aplicações JBoss utiliza o JAAS para resolver tais questões, dessa forma, é possı́vel utilizar os LoginModules para obter e validar as credenciais. O JAAS também está disponı́vel para ser utilizado na maioria dos servidores de aplicações ou containers web. Os seguintes requisitos de segurança são implementados pelos servidores de aplicação ou containers web: • Autenticação O servidor fornece algum mecanismo para autenticação. O JAAS geralmente é o mais usado. • Controle de acesso Definir, de forma declarativa, quais operações estão disponı́veis para quais papéis. • Integridade dos dados Fornecer a garantia de que os dados enviados para o servidor não sejam alterados por terceiros. • Confiabilidade dos dados Garantir que os dados não sejam vistos por terceiros. 3.5.1 Exemplo de segurança declarativa O trecho do arquivo descritor da aplicação web abaixo demonstra a sintaxe para a declaração de papéis e regras de controle de acesso para URLs. Note em “security-role” a presença de dois papéis: administrador e participante. Em “web-resource-collection” define-se uma restrição de acesso a URL para um determinado papel. No exemplo, o primeiro “web-resource-collection” da permissão tanto ao participante, quanto ao administrador para acessar todas as URLs que tenham o padrão “/participante/*”, ou seja, todas URLs que se encaixarem nessa expressão são permitidas apenas para os papéis informados, um usuário que não se autenticou não pode vê-las. É importante notar que todas as URLs que não se encaixarem em nenhum “web-resource-collection” serão disponı́veis para qualquer entidade não autenticada. Veja o exemplo: <security-constraint> <web-resource-collection> <web-resource-name>Paginas do participante</web-resource-name> <url-pattern>/participante/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>participante</role-name> 28 <role-name>administrador</role-name> </auth-constraint> </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>Paginas do administrador</web-resource-name> <url-pattern>/admin/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>administrador</role-name> </auth-constraint> </security-constraint> <security-role> <role-name>participante</role-name> </security-role> <security-role> <role-name>administrador</role-name> </security-role> 3.5.2 Tipos de autenticação na camada web A especificação da camada web do JavaEE define quatro formas de requisitar as credenciais do usuário para autenticação, três delas gerenciadas pelo servidor web e definidas pelo protocolo HTTP, e uma (a última) gerenciada pelo próprio container web: • HTTP Basic Authentication O navegador exibe uma janela de login, sendo fornecidas as credenciais do usuário por meio de cabeçalhos HTTP. • HTTP Digest Authentication O mesmo da anterior, exceto pelo fato de que com o Digest as informações são criptografadas para o envio. • HTTPS Client Authentication Necessita de Secure Sockets Layer (SSL) ativado e funciona tanto com o cliente, como o servidor apresentando certificados digitais uns aos outros, para se autenticarem. • Form Based Authentication Permite ao desenvolvedor criar o seu próprio formulário de login em HTML, o qual irá ser usado para obter as credenciais do usuário. 4 Conclusão Muitas aplicações web estão surgindo com requisitos de assinatura digital de documentos. Para manter a segurança também é importante que a autenticação seja feita com menores riscos possı́veis. Uma abordagem para resolver esse problema é utilizar certificados digitais com polı́ticas de segurança do tipo A3, que protegem a chave privada com hardware especı́fico. O presente trabalho visa contruir uma aplicação web demonstre como implementar tais requisitos. Nesse sentido, servirá como exemplo para futuras aplicações desenvolvidas, que também necessitem tais funcionalidades. Referências DIANA, M. de. Segurança com jaas. Java Magazine, v. 16, p. 54–57, 2004. EDOC. Peticionamento Seguro da Justiça do Trabalho. 2007. Acesso em: 03 janeiro 2007. Disponı́vel em: <http://www.trt4.gov.br/edoc/certificados.htm>. FEDERAL, R. Serviço Interativo de Atendimento Virtual, Receita 222. 2007. Acesso em: 03 janeiro 2007. Disponı́vel em: <http://www.receita.fazenda.gov.br/Receita.222/default.htm>. GROUP, T. N. Introdução à Criptografia. 2007. Acesso em: 03 fevereiro 2007. Disponı́vel em: <http://www.tdec.com.br/Parceiros/PGP/PGPIntro.htm>. HOOK, D. Beginning Cryptography with Java. [S.l.]: wrox, 2005. ISBN 0-7645-9633-0. ICP-BRASIL. Infra-estrutura de Chaves Públicas Brasileira. 2007. Acesso em: 03 janeiro 2007. Disponı́vel em: <http://www.icpbrasil.gov.br>. LOZANO, F. Segurança no j2ee. Java Magazine, v. 22, p. 24–34, 2005. MENEZES, A. J.; OORSCHOT, P. C. van; VANSTONE, S. A. Handbook of Applied Cryptography. [S.l.]: CRC Press, 1996. ISBN 0-8493-8523-7. MICROSYSTEMS, S. JAAS Reference Guide. 2007. Acesso em: 03 janeiro 2007. Disponı́vel em: <http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASRefGuide.html>. MICROSYSTEMS, S. Key and Certificate Management Tool. 2007. Acesso em: 03 janeiro 2007. Disponı́vel em: <http://java.sun.com/j2se/1.3/docs/tooldocs/win32/keytool.html>. REPúBLICA, P. da. Medida Provisória número 2.200-2. 2001. Acesso em: 03 janeiro 2007. Disponı́vel em: <http://www.planalto.gov.br/ccivil/mpv/Antigas2001/22002.htm>. SOUZA, B. Começando com criptografia. Java Magazine, v. 22, p. 16–23, 2005.