Autenticaç˜ao e assinatura de documentos na Internet

Propaganda

Michel Zanini
Autenticação e assinatura de documentos
na Internet com polı́tica de certificados
digitais A3
Florianópolis - SC
2007
Michel Zanini
Autenticaçã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 Ciências da
Computação da Universidade Federal de
Santa Catarina
Orientador:
Ricardo Felipe Custódio
Universidade Federal de Santa Catarina
Centro Tecnológico
Florianópolis - SC
2007
Sumário
Lista de Figuras
1 Introduçã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
Contribuições e Relevância . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 7
1.4
Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 8
2 Revisão Teórica
2.1
Criptografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 9
p. 9
2.1.1
Simétrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 10
2.1.2
Assimétrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11
2.2
Funçõ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
Padrões de criptografia de chave pública . . . . . . . . . . . . . . . . . . p. 18
2.6.1
PKCS #7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
2.6.2
2.7
PKCS #11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
Dispositivos de segurança . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
2.7.1
Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
2.7.2
Smart card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
3 Tecnologias Java para segurança
p. 21
3.1
Applets e polı́ticas de seguranç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
Segurança na camada web do JavaEE . . . . . . . . . . . . . . . . . . . . p. 26
3.5.1
Exemplo de segurança declarativa . . . . . . . . . . . . . . . . . . p. 27
3.5.2
Tipos de autenticação na camada web . . . . . . . . . . . . . . . p. 28
4 Conclusão
p. 29
Referências
p. 30
Lista de Figuras
1
Criptografia simétrica para enviar um texto seguro: o texto é criptogradado e descriptografado utilizando a mesma chave secreta compartilhada
(GROUP, 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 10
2
Criptografia assimétrica para enviar um texto seguro: o processo é lento
pois o texto é criptografado utilizando uma chave pública. Depois é
descriptografado utilizando uma chave privada pessoal (GROUP, 2007) . . p. 11
3
Função de hash: um resumo único é gerado a partir do texto (GROUP,
2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12
4
Assinatura digital rudimentar: o processo é lento pois o texto é criptografado utilizando um algoritmo de chave pública (GROUP, 2007) . . . . p. 13
5
Assinatura digital: ao combinar assinatura digital com funçõ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 usuários finais . . . . . . . . . p. 15
7
Exemplo de um nome único X.500 . . . . . . . . . . . . . . . . . . . . . . p. 16
8
Conteú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
Introdução
Desde 2001 com a promulgação da medida provisória 2.200-2 ficou instituı́do a InfraEstrutura de Chaves Públicas Brasileira (ICP-Brasil), garantir a autenticidade, a integridade e a validade jurı́dica de documentos em forma eletrônica e das aplicações habilitadas
que utilizem certificados digitais. Dessa forma, documentos eletrônicos passaram a ter eficácia semelhante aos em papel, ou legalmente equivalentes. Isso significa que, as mesmas
leis que se aplicam a documentos em papel, também se aplicam aos digitais.
Diversas aplicações do governo já estão disponı́veis, fazendo uso de documentos eletrônicos certificados por alguma autoridade certificadora ligada à ICP-Brasil. A criação
do CPF eletrônico (e-CPF) e o CNPJ eletrônico (e-CNPJ) possibilitam a pessoa fı́sica
ou jurı́dica, a utilização de diversos serviços públicos ou privados. Por exemplo, com a
identidade digital representada pelos certificados ligados a ICP-Brasil, o e-CPF e e-CNPJ,
é possı́vel consultar e realizar serviços relacionados com a Receita Federal, como verificar
o histórico das declarações de imposto renda.
Os certificados eletrônicos podem ser requeridos por qualquer cidadã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 transações eletrônicas. Com o e-CNPJ
empresas podem trocar documentos e contratos oficias, de forma eletrônica e segura;
com o e-CPF advogados podem peticionar processos na justiça, sem sair de casa para se
movimentar até um fórum.
Com o uso dos certificados podemos comprovar nossa identidade digital, dessa forma,
aplicações com requisitos avançados de segurança, podem utilizar autenticação através
de um certificado assinado por uma autoridade certificadora ligada à ICP-Brasil. Dessa
forma, é possı́vel que o usuário não apresente um login e uma senha como credenciais, e
sim, um certificado que comprova sua identidade.
Há duas polı́ticas de certificados digitais e-CPF e e-CNPJ, a tipo A1 e a tipo A3.
A diferença entre uma e outra é 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 é gerado no computador do titular, onde também fica
armazenada a chave privada.
A Tipo A3 tem o certificado válido por três anos e utiliza um hardware, isto é, um
elemento fı́sico para gerar o par de chaves e armazenar a chave privada. Este hardware é
representado por um cartão inteligente (smartcard ) ou um token.
Através desse modelo de segurança, pode-se realizar transações que exigem assinaturas
fı́sicas em papel, como firmar contratos, empréstimos e procurações, entre outros. Tudo
isso feito com segurança pela Internet, através de uma aplicação web, podendo estar em
casa ou até mesmo em um quiosque público. Basta conectar o dispositivo de segurança
ao computador, efetivar a autenticação com uso do certificado, e realizar a transação
eletrônica segura.
Como a cada dia se populariza o uso dos certificados por usuários comuns, aplicações
começam a surgir tirando proveito de suas caracterı́sticas. Um bom exemplo são as
aplicações de peticionamento eletrônico, como o Peticionamento Seguro da Justiça do
Trabalho (e-DOC) onde é possı́vel assinar, protocolar e enviar documentos através da
Internet. Através de tais aplicações advogados podem se autenticar no sistema, utilizando
certificados ligados à ICP-Brasil, e posteriormente, assinar e enviar documentos do seu
computador diretamente para a aplicação web que fará a validação do certificado e da
assinatura.
Outro exemplo, é o acesso a conta bancária pelo Banco do Brasil, através de certificado
digital. A aplicação do banco acessa o token ou smartcard conectado no computador do
usuário através de um applet Java, confere o certificado, e então efetua sua autenticação.
A autenticação por certificado garante mais segurança para o cliente, e ele pode efetuar
transações com limites superiores em relação ao acesso tradicional.
O presente trabalho de pesquisa visa construir uma aplicação web demonstrando esses
conceitos. A aplicação requisita a autenticação através de certificados do tipo A3, acessando a máquina do usuário através de um applet, e possibilita a assinatura digital e o
envio dos documentos assinados digitalmente com um certificado ligado à ICP-Brasil.
7
1.1
Objetivos
1.1.1
Objetivos Gerais
Demonstrar a prática e os conceitos necessários para criar uma aplicação web em Java
que utilize certificados digitais do tipo A3, para autenticação e assinatura de documentos.
1.1.2
Objetivos Especı́ficos
• Fazer uma revisão sobre os principais conceitos ligados a criptografia.
• Estudar o suporte de Java para autenticação e autorização na web.
• Estudar conceitos de assinatura digital e certificados X.509.
• Estudar as API’s Java de acesso ao hardware do token, e também ao repositório do
Windows.
• Estudar o framework BouncyCastle para assinar e conferir documentos no padrão
PKCS #7.
• Desenvolver um applet capaz de interagir com o token localizado na máquina do
usuário.
1.2
Problema
Devido a pouca documentação encontrada na Internet desenvolver uma solução com
os objetivos citados acima, se torna difı́cil. Não existem exemplos práticos, que tornam
claro o que deve ser feito.
Somado a isso, existe o problema de integrar o mecanismo de autenticação por certificado com a segurança declarativa do Java Enterprise Edition (JavaEE).
1.3
Contribuições e Relevância
A contribuição do trabalho é fornecer uma aplicação de exemplo, a qual se possa
basear, para desenvolvimento de aplicações com os mesmos requisitos de segurança. Junto
com o exemplo, também prover os conceitos necessários para seu entendimento, bem como
apresentar suas vantagens e limitações.
8
1.4
Motivação
É curioso notar que muitos processos e transações efetuados de forma presencial hoje
em dia podem ser realizados com segurança pela Internet. Isso é possı́vel com a utilização
de certificados e assinatura digital. Dessa forma, em breve será possı́vel estender essas
aplicações de forma ampla, quando os certificados do tipo A3 se tornarem populares.
2
Revisão Teórica
2.1
Criptografia
Segundo Menezes, Oorschot e Vanstone (1996) criptografia é o estudo de técnicas
matemáticas relacionadas aos aspectos de segurança da informação como confiabilidade,
integridade dos dados, autenticação de entidades e origem de dados. Uma definição mais
clara para criptografia pode ser entendida como sendo uma técnica matemática usada
para transformar (criptografar) um texto plano (legı́vel) em conteúdo cifrado (ilegı́vel),
que deixe a informação transmitida segura, assim como o processo inverso, transformar
(descriptografar) o texto cifrado em formato original. Para que a mensagem possa ser
cifrada, é utilizado uma chave, que pode ser privada ou pública, e através dela o algoritmo
criptográfico consegue cifrar a informação.
A troca de mensagens de forma segura nos acompanha historicamente de longas datas.
Desde os sı́mbolos secretos utilizados pelos egı́pcios, à brincadeira da “lı́ngua do pê”, até as
técnicas utilizadas pelos americanos na Segunda Guerra Mundial para proteger estratégias
e segredos nacionais. Com a evolução dos computadores e sistemas de comunicações
na década de 60 originou a necessidade de proteger as informações e serviços em meio
digital. Com os computadores passamos a poder fazer cálculos matemáticos sofisticados
baseados em problemas muito difı́ceis de resolver, como a fatoração de números primos.
A criptografia se baseia em tais algoritmos para garantir que mesmo com a velocidade
atual dos computadores, ninguém possa decifrar facilmente um texto criptografado.
De acordo com Menezes, Oorschot e Vanstone (1996) a criptografia permite a implantação de diversos serviços de segurança, dos quais, os principais são:
• Confiabilidade É um serviço usado para manter o conteúdo da informação seguro
de todos os que não estejam autorizados a vê-lo.
• Integridade dos dados Serviço que permite detectar se os dados foram alterados
ou corrompidos por terceiros.
10
• Autenticação Autenticação está relacionado com identificação. Quando duas partes desejam se comunicar, ambas precisam se identificar e provar sua identidade
umas as outras.
• Não-repúdio É um serviço que previne entidades de negar suas ações.
A criptografia pode ser classificada de acordo com o uso da chave. A criptografia
simétrica utiliza uma chave secreta, tanta para cifrar, quanto para decifrar. Essa chave
deve ser mantida como segredo para que a informação possa continuar confidencial. Já a
criptografia assimétrica utiliza uma chave privada e uma chave pública. A chave privada
deve ser mantida em segredo, assim como a chave secreta da criptografia simétrica, e a
chave pública deve ser disponibilizada para todos que tiverem interesse em obtê-la.
2.1.1
Simétrica
A criptografia mais simples é a que usa a mesma chave tanto para criptografar quanto
para descriptografar. São os chamados algoritmos simétricos, ou algoritmos de chave
simétrica. A segurança do algoritmo simétrico está em manter a chave compartilhada a
salvo, por isso normalmente ela é chamada de chave secreta. Entre os algoritmos mais
famosos estão o DES e o Triple DES, ambos criados pelo governo dos EUA. Uma visão
geral do processo pode ser observado na Figura 1.
Figura 1: Criptografia simétrica para enviar um texto seguro: o texto é criptogradado e
descriptografado utilizando a mesma chave secreta compartilhada (GROUP, 2007)
Os algoritmos simétricos trazem um problema. Para enviar a mensagem de forma
segura, é preciso enviar também a chave secreta. Alem disso, para manter a comunicação
com diversas pessoas, você precisa compartilhar diversas chaves, e mantê-las seguras.
Entretanto, esse algoritmos são muito rápidos, e são utilizados para efetuar a maior parte
do trabalho de criptografia.
11
2.1.2
Assimétrica
Para resolver o problema dos algoritmos simétricos, foram criados os algoritmos assimétricos ou algoritmos de chave pública. Eles utilizam chaves diferentes para criptografar
e descriptografar, chamadas de chave pública e chave privada.
Nesse esquema, uma mensagem que foi criptografada com uma chave só pode ser
descriptografada com a outra. Ou seja, só pode ser descriptografada com a chave privada,
a mensagem que foi criptografada com a chave pública. O algoritmo assimétrico mais
conhecido é o RSA, inicialmente publicado em 1977 por Ronald Rivest, Adi Shamir e
Leonard Adleman. Uma visão geral do processo pode ser observado na Figura 2.
Figura 2: Criptografia assimétrica para enviar um texto seguro: o processo é lento pois o
texto é criptografado utilizando uma chave pública. Depois é descriptografado utilizando
uma chave privada pessoal (GROUP, 2007)
Como sugerem seus nomes, a chave pú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 pública de B (que por ser
pública pode estar disponı́vel pela Internet) para criptografar a mensagem, dessa forma
apenas a chave privada de B poderá descriptografar e ler a mensagem original. Como a
chave privada de B está guardada a salvo, somente B pode vê-la. Dessa forma, a criptografia assimétrica evita a troca de chaves, pois cada entidade terá sua chave privada, e
disponibilizará a sua chave pública.
Uma das principais limitações dos algoritmos de chave pública é o desempenho. Com
cálculos bem mais complexos, esse algoritmos chegam a ser mil vezes mais lentos que os de
chave simétrica. Por conta disso, se utiliza um processo em duas etapas para criptografar
mensagens: um algoritmo simétrico é usado para criptografar toda a mensagem e depois
é criptografada apenas a chave simétrica utilizada, com um algoritmo de chave pública.
Devem ser enviadas duas informações, a mensagem e a chave simétrica criptografadas,
12
para que o processo possa ser invertido do outro lado.
Em geral é utilizado a chave pública para criptografar, porque o processo inverso,
criptografar com a chave privada, permitiria que qualquer um que obtenha acesso a chave
pública possa ler a mensagem. Essa capacidade é importante na implementação de assinaturas digitais.
2.2
Funções de resumo (Hash)
A função de resumo, ou função de hash, é um cálculo que visa transformar a mensagem em um resultado de tamanho fixo. O processo é interessante por causa de duas
propriedades que o resultado, também chamado de hash, tem. Primeiro, dependendo do
tamanho da mensagem, e do tipo de algoritmo usado, as chances de gerar o mesmo resultado são extremamente pequenas. Segundo, mudando um bit da mensagem original da
qual o hash foi gerado, produz uma mudança imprescindı́vel no novo resultado calculado,
depois do novo hash gerado. Essas propriedades de unicidade e resultado não previsto
fazem as funções de resumo muito úteis para o processo de criptografia. Outra caracterı́stica das funções de resumo é a velocidade, elas executam rapidamente. A Figura 3 ilustra
o processo.
Figura 3: Função de hash: um resumo único é gerado a partir do texto (GROUP, 2007)
As funções de hash são muito úteis para detectar a integridade dos dados, ou seja,
detectar se uma mensagem enviada foi alterada ou editada no caminho de envio. Esse
processo é importante pois de posse de um conhecimento prévio sobre o tipo de mensagem
enviada, pode-se adulterá-la para que ela produza outra mensagem ao ser descriptografada.
Antes da mensagem ser enviada aplica-se uma função de hash a ela, produzindo um
resultado único para essa mensagem. Então é enviado, juntamente com a mensagem, o seu
13
hash, ambos criptografados. Do outro lado, após descriptografar, o hash e a mensagem
original são recuperados. Novamente se aplica a função de hash sobre a mensagem, e se,
os hash’s baterem, significa que a mensagem não foi alterada durante o envio.
2.3
Assinaturas digitais
Na troca de mensagens é possı́vel utilizar a criptografia para garantir a confidenciabilidade dos dados. Mas as vezes queremos apenas garantir a procedência da mensagem,
para termos certeza de que ela foi enviada por quem esperamos. Esse é 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 criá-la, e ela pode ser verificada utilizando informação
pública (chave pública). Assinaturas digitais estão ligadas ao não-repúdio, ou seja, uma
entidade não pode negar ter assinado uma mensagem, caso sua chave pú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 é criptografada com a chave privada,
então temos a certeza de que foi enviada pelo dono da chave.
Figura 4: Assinatura digital rudimentar: o processo é lento pois o texto é criptografado
utilizando um algoritmo de chave pública (GROUP, 2007)
Este é o conceito do processo, na implementação real as coisas são mais complexas.
Algoritmos de chave pública são lentos, portanto não é viável usá-los para criptografar o
texto inteiro. Por outro lado, os algoritmos de função de resumo (hash) são muito rápidos
e úteis para criar uma espécie de “impressão digital” do texto.
14
Para implementar esse processo gera-se um hash do texto que se deseja enviar, e então
o hash é criptografado usando uma chave privada. Como o hash é de tamanho fixo, e
em geral é bem menor que o texto, é mais eficiente criptografá-lo. Então, antes do envio,
o texto e o hash são concatenados. De posse do texto original e o hash criptografado,
pode-se inverter o processo. O hash é descriptografado utilizando a chave pública, então
outro hash é novamente calculado do texto original, depois eles são comparados. Caso a
comparação falhe, ou o texto foi alterado no envio ou nã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 funções de hash podemos
verificar a integridade dos dados, e melhorar o desempenho do processo (GROUP, 2007)
Utilizando-se algoritmos assimétricos podemos garantir o envio de mensagens de forma
segura, e através de assinaturas digitais garantir a identidade do emissor da mensagem.
Porém ainda resta um pouco de falha. Tudo depende da posse da chave pública de quem
quer trocar informações. Como garantir se está se recebendo a chave pú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 você recebesse a assinatura digital pessoalmente de um amigo seu, teria certeza de
que é confiável. Se seu amigo também confirmou a validade de chaves recebidas pessoalmente, então você pode confiar nelas. Caso alguém perca sua chave pública, você precisa
de alguma forma ser notificado, para que possa trocá-la por uma nova confiável. Uma rede
15
de confiança dessas fica enormemente complexa numa abrangência como a Internet. Para
resolver esse problema foram criadas as Autoridades Certificadoras (AC) que certificam
que uma determinada pessoa possui a chave pública que diz possuir.
As autoridades certificadoras são responsáveis por gerenciar o ciclo de vida dos certificados e fornecer aos usuários garantias necessárias para seu uso. Uma AC emite um
certificado digital, com uma chave pública, para o usuá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 pública de uma entidade é realmente dela, se uma AC
confiável a assinou. Para conferir a assinatura podemos obter a chave pública que a AC
disponibiliza, para uso.
As AC costumam possuir também uma Lista de Certificados Revogados (LCR), onde
apresentam quais certificados foram revogados de seus donos. Assim, além de verificar se
a chave pública foi assinada por uma AC confiável, deve-se acessar a LCR para saber se
o certificado não foi revogado.
A Infra-estrutura de Chaves Públicas brasileira (ICP-Brasil) é 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 intermediárias. Essas, por sua vez, podem assinar certificados de outras AC
intermediárias, ou de usuários finais. A figura 6 ilustra a hierarquia.
Figura 6: Hierarquia de autoridades certificadoras e usuários finais
Para um certificado e-CPF ou e-CNPJ, pertencente a um usuário final, ser considerado
válido, ele deve ser assinado por uma AC intermediária, que por sua vez, foi assinada pela
ICP-Brasil. Além disso, nã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 é como um “envelope” que possui uma chave pública e informações de quem é o seu dono. Esse “envelope” é assinado por uma autoridade certificadora,
que atesta a validade, autenticidade e confiabilidade da chave pública.
Todo certificado está associado a uma chave privada e uma cadeia de certificados.
Exceto o primeiro e o último, cada certificado da cadeia tem uma chave privada que assina
o certificado seguinte. O primeiro certificado, o raiz, é auto-assinado e deve ser considerado
confiável para que a cadeia seja válida. O último, do usuário final, simplesmente apresenta
a chave pública que normalmente se está interessado em conhecer para alguma finalidade.
2.5.1
X.500
O padrão X.500 define como deve ser organizada a informação referente a identificação
de uma entidade. É usado no formato de certificados X.509 para identificar o emissor e o
titular do certificado. Um nome único no padrão X.500 contem as seguintes informações
(Figura 7):
Figura 7: Exemplo de um nome único X.500
• Nome comum (CN - commonName) Normalmente o nome de uma pessoa.
• Setor da empresa (OU - organizationUnit) Subdivisão da empresa ou organização.
• Nome da empresa (O - organizationName) Nome da empresa ou organizaçã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 informações podem estar presentes
em um certificado e descreve em que formato os dados devem ser escritos. Atualmente se
encontra na terceira versão. Em um certificado no formato X.509 v3 estão presentes as
seguintes informações (Figura 8):
Figura 8: Conteúdo de um certificado digital X.509 (GROUP, 2007)
• Identificador do algoritmo de assinatura Identifica qual algoritmo foi utilizado
para assinar o certificado.
• Versão do certificado Versão do formato do certificado X.509. Pode ser v1, v2
ou v3.
• Número serial Representa o número de série do certificado. Esse número é único
para cada autoridade certificadora.
• Emissor Nome único no padrão X.500 da AC responsável por emitir o certificado.
• Prazo de validade Nesse campo estão a data de inı́cio e fim da validade do certificado.
• Titular Nome único no padrão X.500 do dono do certificado.
• Assinatura do emissor O emissor do certificado assina os dados presente nele,
sendo que qualquer alteração nos mesmos, pode ser detectada.
• Extensões Os certificados X.509 versão 3 possuem extensões que podem conter
informações diversas além das presentes acima, como por exemplo, o CPF ou CNPJ
do titular.
18
2.6
Padrões de criptografia de chave pública
A empresa RSA Security definiu uma série de padrões de criptografia de chave pública
denominados Public Key Cryptography Standards (PKCS). As aplicações que utilizam a
criptografia de chave pública, em geral, utilizam esses padrões. Atualmente existem quinze
padrões e a seguir dois deles serão descritos pois são necessários para desenvolvimento de
aplicações que acessam dispositivos de segurança para assinar documentos.
2.6.1
PKCS #7
O padrão PKCS #7, também conhecido como Cryptographic Message Syntax (CMS),
descreve uma sintaxe geral para dados criptografados ou assinados. Permite que diferentes
tipos de proteçã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 também podem ter atributos anexados a ela que podem ser
inclusos na assinatura final. É um protocolo importante pois não apenas pode ser usado
por si mesmo, mas també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 é uma API, desenvolvida para ser independente de plataforma, que define
uma interface genérica para dispositivos criptográficos: tokens, smart cards e Hardware
Security Modules (HSM). A API foi desenvolvida para ser uma camada de abstração sobre
o dispositivo e executar funções de criptografia. A API foi denominada de “Cryptoki” e é
escrita em C. Através dela é possı́vel acessar o dispositivo para assinar utilizando a chave
privada que o dispositivo protege.
A API PKCS #11 é largamente usada para acessar os dispositivos, e como foi feita em
C, existem várias API’s escritas em outras linguagens que funcionam como uma camada
que reside sobre a cryptoki. Dessa forma a aplicação acessa a API da linguagem utilizada,
que repassa a chamada para a cryptoki em C.
19
2.7
Dispositivos de segurança
Um dispositivo de segurança é um hardware que visa proteger a chave privada associada com uma cadeia de certificados. Essa proteção é necessá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 são capazes de executar algoritmos de criptografia internamente, dessa forma não precisam enviar
a chave privada para o computador que estão conectados. Quando for requisitado ao
dispositivo a realização de uma funçã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 Criptográfico” (Figura 9) é um tipo de dispositivo de segurança geralmente
ligado a porta USB do microcomputador sem a necessidade de uma leitora especı́fica para
entrar em comunicação com o computador ao qual se conecta.
Figura 9: Exemplo de dispositivo token USB
2.7.2
Smart card
Smart card é um cartão que geralmente assemelha-se em forma e tamanho a um cartão
de crédito convencional de plástico com tarja magnética. Na Figura 10 podemos observar
o layout de um smart card do certificado e-CPF.
O smart card é conectado ao computador atravé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
segurança
3.1
Applets e polı́ticas de segurança
Um applet é um programa escrito em Java que pode ser incluı́do dentro de uma página
HTML, assim como uma imagem. O navegador necessita ter instalado a Máquina Virtual
Java para poder exibir o applet. Dessa forma, o código do applet é transferido para o
computador cliente e é executado na Máquina Virtual local. Geralmente, é utilizado um
applet para disponibilizar uma interface gráfica complexa, incapaz de ser feita apenas com
HTML. Applets também são utilizados quando se torna necessário acessar um recurso da
máquina cliente, o qual o servidor não tem acesso.
Applets não assinados são considerados não confiáveis, e não tem permissão para ler e
escrever no sistema de arquivos do cliente e fazer conexões com qualquer servidor diferente
do que deu origem ao applet. São proibidos de iniciar novos programas no computador
cliente e carregar bibliotecas nativas ou fazer chamadas ao sistema operacional. Essas
limitações sã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 confiável ele deve ser assinado por um certificado que possui uma autoridade certificadora raiz confiável pelo navegador. Se a AC raiz
não estiver na lista de autoridades certificadoras confiáveis pelo navegador, a Máquina
Virtual Java irá questionar o usuário, para que ele possa aceitar ou não a confiabilidade
do certificado.
Se o applet for considerado confiável, ele pode acessar o sistema de arquivos da máquina cliente, bem como acessar um dispositivo de hardware, como um token USB ou um
smart card. Através dessa capacidade é 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 básica para funções
de segurança em Java. A JCA traz interfaces e objetos fundamentais para criptografia,
porém não os implementa. Trata-se de uma abstração que permite ser estendida por
outros fabricantes através de providers que farão o trabalho de criptografia real. Dessa
forma, o desenvolvedor de aplicações pode escolher quais implementações dos algoritmos
de criptografia que melhor atenda suas necessidades.
Providers são implementações concretas dos algoritmos de criptografia. Eles implementam as classes do JCA que acharem necessárias, fornecendo apenas os algoritmos
desejados. Atualmente a instalação do Java já traz um provider instalado que contêm as
implementações dos algoritmos mais comuns, o SunJCE. Outro provider bastante conhecido é o Bouncy Castle, uma implementação open source.
A Java Cryptography Extensions (JCE) é uma extensão da JCA. Ela não foi incluı́da
anteriormente no Java Development Kit (JDK) por questões de proibição de exportação
de implementações de criptografia do governo dos Estados Unidos.
A arquitetura JCA/JCE permite ao fabricante fornecer os algoritmos que julgar mais
importante. Ela é comumente chamada de“arquitetura baseada em provedores de serviço”.
O desenvolvedor utiliza classes do JCA e JCE, que através do padrão de projetos fábrica,
instancia as classes concretas implementadas pelos providers. As classes concretas não
ficam visı́veis ao programador, ele apenas informa ao método fábrica qual provider deseja
usar.
Uma visão da Figura 12 mostra como as camadas da arquitetura trabalham juntas.
O código da aplicaçã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 implementação do
provider, onde estão as implementações dos algoritmos propriamente ditas.
3.3
Keystore
Uma keystore é um repositório de certificados e chaves privadas. Permite armazenamento e gerenciamento centralizado dos certificados. A keystore habilita um usuário a
administrar e armazenar seus pares de chaves públicas e privadas com certificados associados para usá-los em serviços de autenticação e integridade de dados. A implementação
padrão de uma keystore é em arquivo, e protege suas chaves privadas com senha. Sem
23
Figura 12: Arquitetura JCA/JCE
uma keystore seria necessário cuidar de vários arquivos: dois para o par de chaves pública
e privada e mais vários para cada chave pública recebida. Porém, com um keystore em
arquivo, todas as chaves poderiam ser armazenadas em um lugar com uma ú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. É armazenado em um formato protegido para prevenir
acesso não autorizado.
• Certificados confiáveis Contém a chave pública e as informações pertencente a
uma entidade confiável. São chamados de certificados confiáveis pois o dono da
keystore acredita que a chave pública pertence mesmo a entidade associada.
Todas as entradas de dados (chaves e certificados confiáveis) armazenadas na keystore
são acessados por aliases únicos. O alias é um nome lógico com caracteres não sensı́veis
ao caso. É escolhido na hora de adicionar uma entrada a keystore, e usado posteriormente
para resgatar a informação para uso.
O utilitátio keytool do JDK permite a criação de keystores em arquivo, bem como
importação e exportação de certificados, chaves públicas e privadas.
A classe “java.security.KeyStore” possui um método de fá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 implementação comum, feita
pela Sun Microsystems, que vem junto com o JDK, é a keystore em arquivo utilizando
um formato de dados proprietário chamado JKS. Além do JKS, é possı́vel utilizar keystore em arquivo no formato padrão PKCS #12 (Personal Information Exchange Syntax
24
Standard), que define um formato portável de armazenar e transportar chaves privadas
e certificados associados. Outras implementações de keystores estão disponı́veis, como as
implementações oferecidas pelos providers SunPKCS11 e a SunMSCAPI.
3.3.1
SunPKCS11
O padrão PKCS #11 define uma interface de programação nativa para acessar tokens
criptográficos e smart cards. Para ajudar aplicaçõ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 aplicação Java e a
interface nativa PKCS #11, a cryptoki.
O provider SunPKCS11 fornece uma implementação de keystore capaz de acessar o
dispositivo de segurança de forma transparente. Ou seja, para passar a usar a keystore
do SunPKCS11 em uma aplicação, pouco código precisa mudar, é necessário apenas mudar a forma de obter a implementação da keystore. É possı́vel, por meio do keystore
da SunPKCS11, acessar as chaves privadas e certificados armazenados no dispositivo de
segurança e utilizar as suas funções de criptografia.
3.3.2
SunMSCAPI
No sistema operacional Microsoft (MS) Windows, a CryptoAPI (CAPI) define uma
interface padrão para realizar operações criptográficas assim como acessar as chaves e
certificados do usuá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
aplicações em Java a acessar os serviços criptográficos oferecidos pela CryptoAPI usando
a tecnologia e arquitetura JCA/JCE.
As aplicações em Java podem utilizar uma implementação de keystore que acessa a
CryptoAPI, oferecido pelo provider SunMSCAPI. Isso significa que após obter-se a keystore da CryptoAPI, o resto das operações não mudam devido a arquitetura JCA/JCE,
ou seja, devido ao uso de interfaces e implementações abstratas, basta escolher a implementação de keystore, e o resto fica transparente. É possı́vel, por meio do keystore
da SunMSCAPI, acessar as chaves privadas e certificados armazenados no repositório do
Windows, bem como utilizar as implementaçõ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 usuários ou processos a apenas alguns recursos da aplicação, independente da
tecnologia de segurança utilizada. O JAAS pode ser usado para dois propósitos:
• Autenticação É o processo de identificação de uma entidade em um sistema. Isso
é feito comparando-se as credenciais passadas pela entidade com as esperadas pelo
sistema. O método mais comum de autenticação é o uso de senhas, mas pode-se
utilizar várias outras técnicas, como certificados digitais ou biometria.
• Autorização É o processo de verificação dos direitos que uma entidade possui para
acessar / manipular um determinado recurso do sistema. Por exemplo, restringir o
acesso de um usuário de um sistema operacional para que apenas ele possa acessar
/ manipular sua pasta pessoal.
A autenticação no JAAS é realizada de forma flexı́vel, independente de como as credenciais são obtidas. Para cada tecnologia de autenticação é implementado um módulo
de segurança estendendo a interface “javax.security.auth.spi.LoginModule”. Toda a dependência da tecnologia de autenticação está localizada nas implementações de LoginModules. A seguir são descritos alguns módulos de autenticação disponı́veis, os dois primeiros estão presentes no pacote “org.jboss.security.auth.spi” e os três restantes no pacote
“com.sun.security.auth.module”.
• UsersRolesLoginModule Disponı́vel ao utilizar o servidor de aplicações JBoss
esse módulo permite autenticar entidades através de logins e senhas em arquivos de
propriedades.
• DatabaseServerLoginModule Esse módulo está disponı́vel ao utilizar o servidor
de aplicações JBoss e permite autenticar entidades através de logins e senhas em
tabelas de um banco de dados.
• Autenticação através do sistema operacional As classes NTLoginModule e
UnixLoginModule implementam os módulos para obter as credenciais dos usuários
do Microsoft Windows NT e sistemas operacionais baseados em Unix, respectivamente.
26
• JndiLoginModule Através desse módulo é possı́vel autenticar uma entidade através de um servidor de diretórios, desde que ele esteja configurado através do Java
Naming and Directory Interface (JNDI).
• KeyStoreLoginModule Esse módulo permite autenticar através de qualquer implementação de keystore, ou seja, keystores em arquivo utilizando os formatos JKS
ou PKCS #12, ou mesmo as implementações de keystores oferecidas pelos providers SunPKCS11 e SunMSCAPI. Isso significa que através desse módulo é possı́vel
autenticar um usuário utilizando seu certificado digital.
Enquanto os LoginModules obtêm as informações para autenticação, o objeto “javax.security.auth.login.LoginContext” é responsável por armazenar essas informações, durante o perı́odo de tempo que a entidade permanecer autenticada. Para iniciar um
processo de autenticaçã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 informações relacionadas a uma entidade colhidas no processo de autenticaçã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 usuário é um administrador. O CallbackHandler é responsável por relacionar o
LoginContext com um ou mais LoginModules e por solicitar informações necessárias para
que os módulos possam executar, como por exemplo: solicitar ao usuário a digitação de
seus dados de login e senha.
3.5
Segurança na camada web do JavaEE
O Java Enterprise Edition (JavaEE) utiliza uma abordagem declarativa de configurações de segurança baseada no conceito de papéis. Uma aplicação define um ou mais
papéis e depois quais operações podem ser executados por cada papel. No contexto de
aplicação web as operações consistem em acesso a uma URL pelo navegador. A abordagem é declarativa pois o desenvolvedor não precisa chamar nenhum método para validar
uma senha, nem para autorizar ou não a realização de uma operação. Essa configuração
é feita de forma declarativa em um arquivo XML, o descritor da aplicação web, chamado
de “web.xml”.
Entretanto, a especificação JavaEE não define como as credenciais da entidade são
validadas, nem como uma entidade é associada a um papel. Essas questões são de responsabilidade do administrador do servidor de aplicações, e cada produto tem liberdade
27
para implementá-las da forma que julgar mais adequada. O servidor de aplicações JBoss
utiliza o JAAS para resolver tais questões, dessa forma, é possı́vel utilizar os LoginModules para obter e validar as credenciais. O JAAS também está disponı́vel para ser utilizado
na maioria dos servidores de aplicações ou containers web.
Os seguintes requisitos de segurança são implementados pelos servidores de aplicação
ou containers web:
• Autenticação O servidor fornece algum mecanismo para autenticação. O JAAS
geralmente é o mais usado.
• Controle de acesso Definir, de forma declarativa, quais operações estão disponı́veis
para quais papéis.
• Integridade dos dados Fornecer a garantia de que os dados enviados para o
servidor não sejam alterados por terceiros.
• Confiabilidade dos dados Garantir que os dados não sejam vistos por terceiros.
3.5.1
Exemplo de segurança declarativa
O trecho do arquivo descritor da aplicação web abaixo demonstra a sintaxe para a
declaração de papéis e regras de controle de acesso para URLs. Note em “security-role”
a presença de dois papéis: administrador e participante. Em “web-resource-collection”
define-se uma restrição de acesso a URL para um determinado papel. No exemplo, o
primeiro “web-resource-collection” da permissão tanto ao participante, quanto ao administrador para acessar todas as URLs que tenham o padrão “/participante/*”, ou seja,
todas URLs que se encaixarem nessa expressão são permitidas apenas para os papéis informados, um usuário que não se autenticou não pode vê-las. É importante notar que todas
as URLs que não se encaixarem em nenhum “web-resource-collection” serão disponı́veis
para qualquer entidade nã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 autenticação na camada web
A especificação da camada web do JavaEE define quatro formas de requisitar as credenciais do usuário para autenticação, três delas gerenciadas pelo servidor web e definidas
pelo protocolo HTTP, e uma (a última) gerenciada pelo próprio container web:
• HTTP Basic Authentication O navegador exibe uma janela de login, sendo
fornecidas as credenciais do usuário por meio de cabeçalhos HTTP.
• HTTP Digest Authentication O mesmo da anterior, exceto pelo fato de que
com o Digest as informações sã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 próprio formulário de login em HTML, o qual irá ser usado para obter as credenciais do usuário.
4
Conclusão
Muitas aplicações web estão surgindo com requisitos de assinatura digital de documentos. Para manter a segurança também é importante que a autenticação seja feita com
menores riscos possı́veis. Uma abordagem para resolver esse problema é utilizar certificados digitais com polı́ticas de segurança do tipo A3, que protegem a chave privada com
hardware especı́fico.
O presente trabalho visa contruir uma aplicação web demonstre como implementar
tais requisitos. Nesse sentido, servirá como exemplo para futuras aplicações desenvolvidas,
que também necessitem tais funcionalidades.
Referências
DIANA, M. de. Segurança com jaas. Java Magazine, v. 16, p. 54–57, 2004.
EDOC. Peticionamento Seguro da Justiça do Trabalho. 2007. Acesso em: 03
janeiro 2007. Disponı́vel em: <http://www.trt4.gov.br/edoc/certificados.htm>.
FEDERAL, R. Serviç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. Introdução à 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 Públicas Brasileira. 2007. Acesso em: 03
janeiro 2007. Disponı́vel em: <http://www.icpbrasil.gov.br>.
LOZANO, F. Seguranç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>.
REPúBLICA, P. da. Medida Provisória nú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. Começando com criptografia. Java Magazine, v. 22, p. 16–23, 2005.

Autenticaç˜ao e assinatura de documentos na Internet

Documentos relacionados

Produtos

Suporte

Autenticaç˜ao e assinatura de documentos na Internet

Documentos relacionados

Adicionar este documento para recolha (s)

Adicionar este documento para salva

Sugira-nos como melhorar StudyLib