certificaÇÃo digital: uma proposta de um processo …
TRANSCRIPT
SERVIÇO PÚBLICO FEDERAL
MINISTÉRIO DA EDUCAÇÃO INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO PARÁ
CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
LUCIANA SAYURI TSUCHIYA MASUDA
CERTIFICAÇÃO DIGITAL: UMA PROPOSTA DE UM PROCESSO DE AUTENTICAÇÃO
BELÉM 2010
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO PARÁ
CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
LUCIANA SAYURI TSUCHIYA MASUDA
CERTIFICAÇÃO DIGITAL: UMA PROPOSTA DE UM PROCESSO DE AUTENTICAÇÃO
Trabalho Acadêmico de Conclusão de
Curso apresentado ao Instituto Federal de Educação, Ciência e Tecnologia do Pará – IFPA, como requisito para a obtenção do
Grau em Tecnólogo em Desenvolvimento de Sistemas, sob a orientação do Prof. Msc. Cláudio Roberto de Lima Martins.
BELÉM 2010
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO PARÁ
CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
LUCIANA SAYURI TSUCHIYA MASUDA
CERTIFICAÇÃO DIGITAL: UMA PROPOSTA DE UM PROCESSO DE
AUTENTICAÇÃO
DATA DA DEFESA: 04/02/2010
CONCEITO: ___________________
BANCA EXAMINADORA
_____________________________________________________ Prof. Orientador Msc. Cláudio Roberto de Lima Martins – IFPA
_____________________________________________
Prof. Msc. Rita de Cássia Cerqueira Gomes - IFPA
_____________________________________________
Prof. Msc. Ricardo José Souza de Cabeça - IFPA
À minha família, pelo eterno incentivo.
AGRADECIMENTOS
Agradeço em primeiro lugar a Deus, pois sem Ele nada seria possível.
Aos meus pais, Yuji e Yukuko que com toda paciência, dedicação,
dificuldades e limitações não pouparam esforços para me educar, ajudando a
superar os obstáculos com humildade.
Aos meus irmãos, Suzana, Diana e Hector pela ajuda, motivação e incentivo.
Ao meu grande orientador, Cláudio Martins pelo aprendizado, apoio,
paciência, motivação e dedicação.
A todos os professores com os quais tive a oportunidade e o prazer de
aprender.
Ao Instituto Federal de Educação, Ciência e Tecnologia do Pará por ser uma
instituição pública.
Aos meus amigos pelo incentivo e apoio.
E a todas as pessoas que de alguma forma, seja direta ou indiretamente,
ajudaram na elaboração deste trabalho.
“A melhor maneira de ficar em segurança
é nunca se sentir seguro.”
(Benjamin Franklin)
RESUMO
Na segurança da informação, é necessário estabelecer uma política de criação e
uso de senhas pelos funcionários de uma empresa, pois, como muitos dos sistemas
usam senhas na autenticação de usuários, os mesmos optam por utilizar senhas
fáceis ou deixar anotados em um papel, facilitando um usuário malicioso conseguir
esses dados de acesso e utilizá-los para um ato ilícito. Em virtude desses problemas
de segurança, muitos especialistas da área procuram alternativas na autenticação
de usuários para minimizar esse problema de segurança. Uma das soluções para
esse problema é o uso de certificados digitais no lugar dos tradicionais login e
senha. Os certificados digitais são documentos que garantem a identidade de
pessoas e de computadores remotos, além de servirem para assinar e garantir a
integridade dos documentos. Portanto, este trabalho acadêmico tem como objetivo
propor um sistema de autenticação utilizando certificados digitais para uma rede
interna.
PALAVRAS-CHAVE: Segurança, Autenticação, Criptografia Assimétrica, Certificação
Digital.
ABSTRACT
In information security, it's needed to establish a policy for creating and use of
passwords by the employees in a company, because many systems use passwords
in its users authentication, them generally choose weak passwords or write it on a
paper, making for a malicious user to obtain these access data and use them for a
tort. Because these security problems, many specialists are looking for alternatives in
the users authentication to reduce these security problems. One solution to these
problems is the use of digital certificates in the place of traditional login and
password. The digital certificates are documents that guarantee the people and
remote computers identity, as well as serving to sign and guarantee the documents
integrity. Therefore, this academic work have as objective propose an authentication
system that uses digital certificates for a internal network.
KEYWORDS: Security, Authentication, Asymmetric Encryption, Digital Certificate.
LISTAS DE ILUSTRAÇÕES
1 Política de Segurança de Informações e seus relacionamentos 19
2 Esquema para cifragem e decifragem com chaves simétricas 21
3 Exemplo de criptografia simétrica por substituição, técnica de Júlio
César 21
4 Criptografia de chaves públicas 23
5 Analogia entre o processo para expedir um RG e um Certificado Digital 27
6 Estrutura do ICP-Brasil de forma resumida 29
7 Simplificação do sistema de certificação digital 30
8 Certificado Digital 33
9 Estrutura do formato X.509 34
10 Pilha TCP/IP – Camadas para um usuário navegando com SSL 40
11 Janela Opções, na categoria “Avançado”, na aba “Criptografia” 43
12 Gerenciador de Certificados 44
13 Diálogo para a importação do Certificado da AC 44
14 Dados do Certificado do Cliente no Gerenciador de certificados 45
15 Solicitação de identificação do usuário utilizando certificado digital 45
16 Ícone do cadeado na barra de status do navegador 46
17 Fluxo de funcionamento do sistema 47
18 Página index.jsp do protótipo do Sistema de Autenticação 47
19 Solicitação de identificação do usuário 48
20 Página dadosCertificado.jsp, mostra os dados do certificado do Cliente 49
21 Página entradaForca.jsp 50
SUMÁRIO
1 INTRODUÇÃO.......................................................................................... 12
1.1 OBJETIVO GERAL................................................................................... 13
1.2 OBJETIVO ESPECÍFICO......................................................................... 13
1.3 ORGANIZAÇÃO DO TRABALHO............................................................. 13
2 SEGURANÇA DA INFORMAÇÃO........................................................... 15
2.1 MODELO CIA (CONFIDENTIALITY, INTEGRITY AND AVAILABITY)...... 15
2.2 OUTROS PRINCÍPIOS DE SEGURANÇA............................................... 16
2.3 AMEAÇAS................................................................................................ 17
2.4 POLÍTICA DE SEGURANÇA DA INFORMAÇÃO..................................... 18
3 CRIPTOGRAFIA....................................................................................... 20
3.1 CRIPTOGRAFIA SIMÉTRICA................................................................... 20
3.2 CRIPTOGRAFIA ASSIMÉTRICA.............................................................. 22
3.2.1 Funcionamento do Algoritmo RSA............................................................ 23
4 CERTIFICAÇÃO DIGITAL........................................................................ 26
4.1 ESTRUTURA HIERÁRQUICA DA CERTIFICAÇÃO DIGITAL.................. 26
4.2 INFRA-ESTRUTURAS DE CHAVES PÚBLICAS BRASILEIRAS (ICP-
BRASIL).................................................................................................... 28
4.2.1 Comitê Gestor (CG).................................................................................. 30
4.2.2 Autoridade Certificadora Raiz (AC-Raiz).................................................. 31
4.2.3 Autoridades Certificadoras (ACs)............................................................. 31
4.2.4 Autoridades de Registro (ARs)................................................................. 31
4.3 TIPOS DE CERTIFICADOS..................................................................... 32
4.4 ESTRUTURA DE UM CERTIFICADO DIGITAL....................................... 33
5 AUTENTICAÇÃO WEB COM CERTIFICADOS DIGITAIS...................... 37
5.1 TECNOLOGIAS UTILIZADAS.................................................................. 37
5.1.1 Apache Tomcat......................................................................................... 38
5.1.2 Eclipse Ganymede.................................................................................... 38
5.1.3 Java Development Kit (JDK)..................................................................... 38
5.1.4 OpenSSL.................................................................................................. 39
5.2 PROCESSO DE AUTENTICAÇÃO.......................................................... 39
5.3 GERAÇÃO DE CERTIFICADOS.............................................................. 40
5.3.1 Criação da Chave e do Certificado da Autoridade Certificadora.............. 40
5.3.2 Criação do Keystore, do Certificado do Servidor e do Truststore............. 41
5.3.3 Criação do Certificado do Cliente............................................................. 42
5.4 CONFIGURAÇÃO DO SSL...................................................................... 42
5.5 AUTENTICAÇÃO E MANIPULAÇÃO DE CERTIFICADOS..................... 46
6 CONCLUSÃO........................................................................................... 51
REFERÊNCIAS........................................................................................ 53
APÊNDICE A............................................................................................ 55
12
1. INTRODUÇÃO
Tradicionalmente, as organizações (bancos, empresas grandes ou
pequenas, governos) davam mais atenção à proteção de seus meios físicos e
financeiros do que às informações que possuíam. A tecnologia da informação servia
de retaguarda ou na melhoria de processos, mas dificilmente tinha destaque dentro
das organizações.
Atualmente, as organizações necessitam da tecnologia da informação para
o seu funcionamento, devido à automatização e agregação de valores aos
processos organizacionais. As redes de computadores facilitam bastante a
comunicação entre as organizações e pessoas do mundo todo, porém, a partir da
década de 90, com a globalização surgiu a preocupação com a segurança das
informações.
Atividades que antes não precisavam do uso da informática e da Internet se
fazem necessárias hoje em dia. Por exemplo, fazemos transações bancárias,
fazemos compra, estudamos e trabalhamos utilizando um computador, e, para
garantir a segurança e a privacidade das transações realizadas por pessoas e
empresas no ambiente virtual, usamos ferramentas de hardware e software que
provêem a segurança do sistema. Mesmo com todas as ferramentas disponíveis no
mercado, há sempre uma possibilidade de falhas na segurança, e com o
crescimento de Aplicações Web surge a necessidade de ambientes seguros que
possam dispor de informações confiáveis e verdadeiras.
A importância na segurança da aplicação está crescendo de forma rápida
devido ao incremento das necessidades de transações virtuais por parte do negócio.
A fraude em Aplicações Web tornou-se um problema em escala mundial, que tem
custado bilhões às organizações.
À medida que a Web cresce, também crescem os problemas de segurança
associados a ela. Os navegadores e servidores tornaram-se mais complexos,
porém, com muitas brechas para os hackers tirarem proveito. E com o uso de
informações confidenciais e privadas trafegando através da Web, os hackers têm
um grande incentivo para descobrir essas brechas.
Na maioria dos casos, é simplesmente impossível para os usuários
gerenciarem a própria segurança; os problemas são muito complexos e o ambiente
13
é muito flexível. Grande parte da responsabilidade pela segurança deve,
consequentemente, recair sobre o desenvolvedor de aplicativos Web, que tem de
codificá-los de forma defensiva e segura para tentar impedir problemas relacionados
à segurança.
Uma das categorias de segurança muito crítica para Aplicações Web é a
autenticação, pois falhas nesta área geralmente podem estar ligadas a roubo de
contas de usuários ou administradores, o que resulta em um contorno de controles
de autorização e responsabilidade, causando violações de privacidade, e como
consequência causaria um grande prejuízo para o usuário e a empresa, pois,
imagine se a conta de um usuário de uma empresa e-commerce fosse roubada.
Uma das possíveis soluções para este problema de segurança seria
trabalhar com a encriptação de dados que trafegam na rede, por meio de algoritmos
de assinatura, como o RSA, e o uso de certificados digitais. “A certificação digital
assegurada pelos pilares da autenticidade, integridade e confidencialidade pode ser
uma grande parceira na tarefa de minimizar os problemas de segurança” (SILVA et
al., 2008, p. 44).
1.1. OBJETIVO GERAL
Propor um processo de autenticação com certificados digitais para redes
internas.
1.2. OBJETIVOS ESPECÍFICOS
a) Esclarecer a diferença entre a criptografia simétrica e criptografia assimétrica.
b) Mostrar como configurar um servidor web (Apache Tomcat) de forma a
permitir que um usuário se autentique utilizando certificados digitais.
c) Esclarecer como os certificados digitais garantem a segurança da informação.
1.3. ORGANIZAÇÃO DO TRABALHO
O trabalho está organizado da seguinte forma:
No capítulo 2, são apresentados conceitos fundamentais da segurança da
14
informação, os principais requisitos de segurança e sobre o que vem a ser política
de segurança da informação.
No capítulo 3, aborda-se o que vem a ser criptografia, e são apresentados os
dois tipos de criptografia, a simétrica e a assimétrica, além de ser explicado como
funciona o algoritmo RSA.
No capítulo 4, apresentam-se os conceitos sobre certificação digital,
abordando conceitos sobre a infra-estrutura de chaves públicas, em especial a
adotada pelo Brasil.
No capítulo 5, é disposto o objetivo geral deste trabalho, onde será abordado
o processo de autenticação, geração dos certificados, implementação do protótipo
do sistema de autenticação e as tecnologias utilizadas.
Finalmente, no capítulo 6, são apresentadas as conclusões e os trabalhos
futuros.
15
2. SEGURANÇA DA INFORMAÇÃO
A informação, atualmente, é considerada como um bem de maior valia. É
como se fosse um patrimônio de uma organização e por consequência é uma
vantagem competitiva no mercado. Assim, a segurança de informação tornou-se um
ponto importante para a sobrevivência das organizações.
A segurança de informação busca reduzir ao máximo possível os riscos de
fraudes em arquivos, banco de dados, vazamento de informação, uso indevido do
sistema por falta de treinamento, paralisações de rede ou serviços, sabotagens,
roubo de informações ou qualquer outra ameaça que possa prejudicar a organização
ou equipamentos da mesma. Para Dias (2000, p.41), segurança é a proteção de
informações, sistemas, recursos e serviços contra desastres, erros, manipulações
não autorizadas, de forma a reduzir a probabilidade e o impacto de incidentes de
segurança.
De acordo com Albuquerque e Ribeiro (2002, p. 25):
Segurança é um termo tão genérico que é melhor pensarmos em aspectos
de segurança da informação. Em vez de perguntar quanto queremos de
segurança, devemos perguntar quanto queremos de disponibilidade do
sistema ou qual a necessidade de confidencialidade, por exemplo.
2.1. MODELO CIA (CONFIDENTIALITY, INTEGRITY AND AVAILABITY)
A segurança de informação segue um conjunto de princípios em que se
podem estabelecer métricas para a definição do nível de segurança existente, os
principais objetivos que orientam a análise, o planejamento e a implementação da
segurança é a tríade CIA (Confidentiality, Integrity and Availabity – Confidencialidade,
integridade e disponibilidade).
Para fornecer uma melhor compreensão, a definição dos principais objetivos
está disposta a seguir:
a) Confidentiality (Confidencialidade): Assegura que as informações estejam
acessíveis somente para pessoas autorizadas, protegendo-as contra leituras e
cópias indevidas.
b) Integrity (Integridade): Proteger as informações contra alterações ou
modificações, garantindo que seu conteúdo não foi corrompido nem forjado.
16
c) Availabity (Disponibilidade): Assegura que os usuários autorizados acessem a
informação quando requisitada, protegendo-a de forma que ela não seja degradada
nem se torne indisponível.
2.2. OUTROS PRINCÍPIOS DE SEGURANÇA
Além do modelo CIA, há outros princípios que são importantes de acordo com
a natureza da aplicação. A seguir é apresentada a definição de cada princípio:
a) Autenticação: Provê a garantia de identidade do usuário, sistema ou informação,
ou seja, é responsável por verificar que um requerente é quem ele alega ser.
b) Não repudio: Impede que um usuário venha a negar falsamente a sua
participação em qualquer ação no sistema.
c) Legalidade: Aderência de um sistema à legislação.
d) Privacidade: Assegura que dados confidenciais não são revelados a pessoas
que não possuem o privilégio de acesso.
e) Auditoria: Engloba o exame cuidadoso das operações, processos, sistemas e
responsabilidades gerenciais de uma determinada entidade, cujo objetivo é
averiguar se elas estão de acordo com as disposições planejadas e estabelecidas.
De acordo com a norma ISO/IEC 17.799/2005, para uma organização é
fundamental conhecer os seus requisitos de segurança, os quais podem ser
identificados por três fontes principais:
a) A primeira é obtida a partir de uma avaliação de risco, ou seja, é feito um
estudo sobre a probabilidade de ocorrência das ameaças e do impacto
potencial que causará à organização se esses riscos acontecerem;
b) A segunda é com relação à legislação vigente, os estatutos, a
regulamentação e as cláusulas contratuais que a organização, seus
parceiros, contratados e provedores de serviço têm que atender;
c) A terceira é definido um conjunto de princípios, objetivos e requisitos para
processamento de informação que uma organização tem que desenvolver
para apoiar suas operações.
17
2.3. AMEAÇAS
Quando ocorre a perda de um dos princípios citados anteriormente, como a
confidencialidade de um dado, estamos nos deparando com um problema de
segurança do qual estamos querendo evitar. Alguns desses problemas são
ocasionados por desastres naturais, outros por alguma operação incorreta, ou então,
por um ataque ao sistema. Sendo que o último é um dos mais sérios em virtude do
“agente que está realizando o ataque visa obter algum retorno, podendo, com isso,
provocar grande prejuízo. Ao contrário dos demais, o ataque pode ser planejado,
sistemático e é muito difícil de prever” (ALBUQUERQUE e R IBEIRO, 2002, p. 3).
Vale lembrar que o agente não precisa ser necessariamente uma pessoa.
Pode ser também um grupo ou empresa. A ameaça causada por ação da natureza,
também, provoca danos. Afeta a confidencialidade, a integridade e a disponibilidade
de uma informação ou bem, fazendo uso de uma ou mais vulnerabilidades.
O ataque só acontecerá se houver uma ameaça à segurança. A ameaça é
uma tríade composta por Agente, Vulnerabilidade (ou Mecanismo) e Ativo com alto
valor.
Com base na ISO/IEC 15.408 e Albuquerque e Ribeiro (2002, p.4), os termos
ataque, ativo, vulnerabilidade e ameaça têm as seguintes definições:
a) Ataque: é um tipo de problema de segurança caracterizado pela existência
de um agente que busca obter algum retorno, atingindo um ativo de alto valor.
O retorno pode ser financeiro ou não.
b) Ativo: algo de valor resguardado pelo sistema.
c) Vulnerabilidade: é uma fraqueza no sistema, ou seja, erro de operação só
pode causar dano se houver um ponto fraco no sistema que permita que o
ativo seja atingido.
d) Ameaça: como afirmamos acima, é composta pelos elementos: agente,
vulnerabilidade e ativo de alto valor. É um ataque potencial.
A ameaça pode ser classificada como intencional (humana), acidental
(humana) ou natural, e pode ser também externa ou interna.
Vários profissionais da área de segurança da informação afirmam que não
existe sistema totalmente impenetrável, pois é impossível prevenir todos os ataques.
O sistema que concentra suas defesas nos ataques mais prováveis e com maior
18
perda esperada são os considerados seguros.
2.4. POLÍTICA DE SEGURANÇA DA INFORMAÇÃO
Uma política de segurança da informação é um conjunto de normas e
procedimentos que definem as melhores práticas para manuseio, armazenamento,
transporte e descarte das informações. É um mecanismo preventivo de proteção da
informação, de forma a restringir acessos e manipulações por pessoas não
autorizadas.
Uma política de segurança representa as ações que são ou não permitidas
durante a operação de um sistema. Uma política de segurança de alto nível
leva em consideração a operação segura de um sistema em caráter
integral, sem necessariamente prover detalhes de implementação de como
os resultados desejados devem ser alcançados. A política de segurança
representa as considerações gerais em termos mais precisos dos requisitos
de segurança do sistema, passando por um processo de refinamento na
especificação do sistema para o qual ela será aplicada. (SILVA ET AL.,
2008, p.6)
É importante lembrar que a política de segurança tem um caráter de processo
de aculturação de segurança, pois deve ser seguida pelo corpo técnico e gerencial e
pelos usuários, internos ou externos, e estabelece, ainda, procedimentos de
segurança adequados, processos de auditoria e uma base para procedimentos
legais na sequência de ataques.
A política de segurança, assim como toda política institucional, deve ser clara,
alinhada com os objetivos de negócio, aprovada e apoiada pela alta gerência e
divulgada a todos os funcionários e usuários. A sua definição deve ir além dos
aspectos relacionados com sistema de informações e recursos computacionais, visto
que, uma má ou boa política de segurança vai influenciar em impactos sobre todos
os projetos de informática e todas as informações da organização. A figura 1 mostra
esse relacionamento da política de segurança de informações com vários projetos e
com a estratégia da organização.
19
Figura 1: Política de Segurança de informações e seus relacionamentos.
Fonte: DIAS, 2000, p. 49
20
3. CRIPTOGRAFIA
A criptografia, do grego kriptós, oculta, e grápho, grafia, é a arte ou ciência de
escrever em cifra ou em códigos, de forma a permitir que somente o destinatário a
decifre (KRONBAUER, 2007, p.17). Para Silva et.al (2008, p.13), a “criptografia é a
'ciência' de fazer com que o custo de adquirir uma informação de maneira imprópria
seja maior que o custo obtido com a informação”.
A criptografia usa uma chave (algoritmo criptográfico) para cifrar um texto
original e para decifrar faz-se o procedimento inverso com o texto cifrado.
(…) um algoritmo criptográfico da Alice com chave K criptografa um texto
legível x obtendo-se um outro texto ilegível 𝑓𝑘 𝑥 = 𝑦. O texto y é transmitido
para o computador-destino do Beto onde y é decriptografado pelo algoritmo
inverso 𝑓𝑘−1 𝑦 obtendo-se x se e só se o destinatário Beto conhece a chave
K. Para quem desconhece a chave K é computacionalmente difícil obter-se
x a partir do conhecimento de y, se o algoritmo for bem projetado, isto é, se
for seguro (TERADA, 2000, p.18).
As técnicas criptográficas podem ser usadas como um meio efetivo de
proteção de dados suscetíveis a ataques, estejam eles armazenados em um
computador ou trafegando pela rede. Assim, a criptografia serve de base a uma
série de mecanismos de segurança, como: garantir serviços básicos de
autenticação, privacidade e integridade dos dados. Existem basicamente dois tipos
de criptografia: a simétrica e a assimétrica, que serão tratados a seguir.
3.1. CRIPTOGRAFIA SIMÉTRICA
A criptografia simétrica realiza a cifragem e a decifragem de uma informação
através de algoritmos que utilizam a mesma chave, garantindo sigilo na transmissão
e armazenagem de dados.
Sistema simétrico ou de chave secreta é o método de encriptação que utiliza
uma mesma chave (o segredo, como nos tempos antigos) para encriptar e
decriptar a mensagem. Esta forma é conhecida como Criptografia por Chave
Secreta ou Chave Única, Criptografia Simétrica ou Criptografia Tradicional
(XAVIER, 2005, p.28).
A figura 2 ilustra de forma simples o funcionamento da chave simétrica. A
soma da mensagem com a chave gera uma mensagem criptografada, após é
21
enviada através da rede e ao chegar ao lado oposto é decriptografado com a chave
que está no destino.
Figura 2: Esquema para cifragem e decifragem com chaves simétricas
Fonte: XAVIER, 2005, p.29
Os algoritmos criptográficos envolvem a substituição de um dado por outro. E
um algoritmo de chaves simétricas muito conhecido é a cifra de César, utilizada pelo
imperador romano Júlio César. A técnica consiste em se trocar cada letra do alfabeto
por uma letra que se encontra a n lugares da original (onde n é um número natural,
que no caso do imperador romano era 3). Por exemplo, a mensagem original “casa”
se torna “fdvd” em texto cifrado. A figura 3 mostra um exemplo de criptografia
simétrica por substituição, a partir da técnica de Júlio César.
Figura 3: Exemplo de criptografia simétrica por substituição, técnica de Júlio César
Fonte: BROCARDO, 2006, p.16
22
Outro algoritmo de chave secreta é o DES (Data Encryption Standard), um
padrão de criptografia de chaves simétricas desenvolvido em 1977. Porém, em
1997, o NIST (National Institute of Standards in Technology) lançou uma competição
aberta para o sucessor do DES, chamado AES (Advanced Encryption Standards).
Além da necessidade de se ter um algoritmo mais seguro e eficiente que o DES, já
que este apresentava fragilidades, o NIST iniciou um programa para
desenvolvimento de um padrão único para a proteção de dados informatizados e
comunicação de dados, de tal forma que este padrão fosse totalmente público e
permitisse que diferentes equipamentos pudessem interoperar (BROCARDO, 2006,
p. 19).
E de acordo com Kurose (2006, p.520), o Padrão Avançado de Criptografia
(Advanced Encryption Standards – AES), também conhecido como algoritmo de
Rijndael, é um algoritmo de chave simétrica que processa dados em blocos de 128
bits e pode funcionar com chaves de 128, 192 e 256 bits de comprimento. O NIST
estima que uma máquina que conseguisse quebrar o DES de 56 bits em 1 segundo
(isto é, experimentar 255
chaves por segundo), levaria aproximadamente 149 trilhões
de anos para quebrar uma chave AES de 128 bits.
3.2. CRIPTOGRAFIA ASSIMÉTRICA
A criptografia assimétrica surgiu devido aos problemas relacionados a
segurança da criptografia simétrica.
O principal problema relacionado à criptografia simétrica está no fato de que
as partes que necessitam utilizá-la devem ter acesso à mesma chave.
Portanto, há a necessidade da adoção de uma política de segurança para a
troca e guarda das chaves. Esta política acarreta dois problemas quanto à
segurança, decorrentes do gerenciamento das chaves. O primeiro diz
respeito à conservação do segredo de uma chave que é de conhecimento
de várias pessoas. Bastaria uma delas agir de forma dolosa para que todos
sofressem as eventuais consequências. O segundo problema refere-se à
própria distribuição da chave. Sempre que uma nova pessoa fosse admitida
no grupo, necessitaria receber essa chave. (BROCARDO, 2006, p.19)
A criptografia assimétrica, também chamada de criptografia de chaves
públicas, envolve o uso de duas chaves distintas, a pública e a privada, que
funcionam em conjunto (uma das chaves cifra e a outra consegue decifrar). A chave
23
privada deve ser mantida em segredo, enquanto que a chave pública deve ser
distribuída. O algoritmo que atualmente é a base da maioria das aplicações que
utilizam criptografia assimétrica é o RSA (cujo nome se deve a seus inventores –
Ron Rivest, Adi Shamir e Leonard Adleman).
A figura 4 representa o funcionamento da criptografia assimétrica, onde
alguém que possui a chave pública de Beto cifra uma mensagem e somente o Beto
pode decifrar a mensagem, pois só ele tem a chave privada correspondente.
Figura 4: Criptografia de chaves públicas
O princípio do algoritmo RSA é construir chaves públicas e privadas utilizando
números primos. Assim, de acordo com Kurose (2006, p. 522), há dois componentes
inter-relacionados no RSA:
a) a escolha da chave pública e da chave privada;
b) o algoritmo de criptografia/decriptografia.
3.2.1 FUNCIONAMENTO DO ALGORITMO RSA
Para a obtenção das chaves, seguem os seguintes passos:
a) Escolhe-se de forma aleatória dois números primos de valores altos, 𝑝 e 𝑞. Para
maior segurança, deve-se escolher dois primos com o mesmo número de bits e
quanto maiores os valores, mais difícil será quebrar o RSA, porém mais tempo se
levará para realizar a codificação e decodificação (KUROSE, 2006, p.522).
24
b) Efetua-se os produtos:
𝑛 = 𝑝𝑞 e 𝑧 = 𝑝 − 1 (𝑞 − 1)
“O RSA Laboratories recomenda que o produto de 𝑝 e 𝑞 seja da ordem de
1024 bits para uso empresarial e de 768 bits para utilização com 'informações
menos valiosas'” (KUROSE, 2006, p.522).
c) Escolhe-se de forma aleatória um número 𝑒 de forma que seja menor do que 𝑛 e
que 𝑒 e 𝑧 sejam números primos entre si, ou seja, não têm fatores comuns (exceto o
1).
d) Calcula-se 𝑑 (chave para decifrar), tal que 𝑒𝑑 − 1 seja divisível exatamente por 𝑧,
isto é, dado 𝑒,obtém-se 𝑑 tal que o resto da divisão de 𝑒𝑑 por 𝑧 seja o número inteiro
1.
e) A chave pública é o par de números 𝑛, 𝑒 e a chave privada, 𝑛, 𝑑 .
A criptografia e a decriptografia acontece da seguinte maneira:
a) Suponha que se queira enviar um padrão de bits 𝑚 tal que 𝑚 < 𝑛. Para codificar,
calcula-se a potência 𝑚𝑒 e gera-se o resto inteiro da divisão de 𝑚𝑒 por 𝑛. Assim, o
valor cifrado, 𝑐, da mensagem em texto aberto, 𝑚, é:
𝑐 = 𝑚𝑒 𝑚𝑜𝑑 𝑛
b) Para decifrar a mensagem em texto cifrado, 𝑐, basta processar:
𝑚 = 𝑐𝑑 𝑚𝑜𝑑 𝑛
Para um melhor entendimento (KUROSE, 2006, p.523), vamos supor que Bob
escolha 𝑝 = 5 e 𝑞 = 7 (note que admitimos valores muito pequenos, para ser seguro
é necessário que os valores sejam altos). Logo, temos 𝑛 = 35 e 𝑧 = 24. Bob escolhe
𝑒 = 5, já que 5 e 24 não têm fatores em comuns. Por fim, obtém-se 𝑑 = 29, pois
5 ∙ 29 − 1 é divisível exatamente por 24 ( 5 ∙ 29 𝑚𝑜𝑑 24 = 1). Ele divulga os dois
valores 𝑛 = 35 e 𝑒 = 5, e mantém em segredo o valor 𝑑 = 29. Agora, suponha que
Alice queira enviar as letras 'l', 'o', 'v' e 'e' a Bob. Cada letra do alfabeto é
representado por um número como mostra a tabela 1.
Tabela 1: Representação numérica de cada letra do alfabeto
A criptografia e a decriptografia realizadas por Alice e Bob estão mostradas na
25
tabela 2 e 3, respectivamente.
Tabela 2: Criptografia RSA para Alice: e= 5 , n= 35
Fonte: KUROSE, 2006, p.523
Tabela 3: Decriptografia RSA para Bob: d = 29 , n= 35
Fonte: KUROSE, 2006, p. 524
26
4. CERTIFICAÇÃO DIGITAL
De acordo com o ITI (Instituto Nacional de Tecnologia da Informação), “a
certificação digital é um conjunto de técnicas e processos que propiciam mais
segurança às comunicações e transações eletrônicas, permitindo também a guarda
segura de documentos” (ITI, 2009). Utilizando-se a certificação digital é possível
evitar que hackers interceptem ou adulterem as comunicações realizadas via
Internet ou, então, garantir a integridade de dados confidenciais.
A certificação digital baseia-se na existência de certificados digitais, que, para
Brocardo (2006, p. 34), “é um documento eletrônico assinado digitalmente por uma
autoridade certificadora, e que contém diversos dados sobre o emissor e seu titular”.
Assim, o certificado digital visa atestar a identidade de seu titular (pessoa física ou
jurídica) em documentos ou e-mails digitalmente assinados, em navegações na
Internet ou em operações online, inclusive as sigilosas.
Podemos dizer, de forma genérica, que um certificado digital é a versão
digital de um documento de identidade. Quando é necessário comprovar
sua identidade, o certificado é utilizado como forma de presença, por
mostrar a chave privada que se relaciona com uma chave pública. (SILVA et
al, 2008, p.25)
A função do certificado digital é a de vincular uma pessoa ou uma entidade a
uma chave pública.
4.1. ESTRUTURA HIERÁRQUICA DA CERTIFICAÇÃO DIGITAL
Muitos profissionais costumam fazer uma analogia entre a estrutura
hierárquica de um certificado digital e de uma carteira de identidade. Por exemplo, o
documento oficial de identificação, o RG, é expedido pela Secretaria de Segurança
Pública, que atesta quem você realmente é, e no mundo virtual, o processo não é
diferente. A figura 5 mostra essa analogia.
27
Figura 5: Analogia entre o processo para expedir um RG e um Certificado Digital.
Fonte: BROCARDO, 2006, p. 35
Para que os certificados digitais possam ser aceitos e utilizados por pessoas,
empresas e governos, precisam ser emitidos por entidades apropriadas. Conforme
Brocardo (2006, p. 35) afirma:
O certificado digital é emitido por uma Autoridade de Certificação (AC), que
pode ser uma empresa, organização ou indivíduo, tanto público quanto
privado. A Autoridade de Registro (AR) atua como tabelião para verificar e
autenticar a identidade dos usuários de um sistema criptográfico de chave
pública. Uma AC pode fazer o papel de uma AR.
A AC responsabiliza-se pela distribuição da chave pública e pela garantia de
que uma determinada chave pública esteja seguramente ligada ao nome de
seu dono.
28
4.2. INFRA-ESTRUTURAS DE CHAVES PÚBLICAS BRASILEIRAS
(ICP-BRASIL)
Como já foi abordado, o uso da certificação digital proporciona aos usuários
autenticidade, integridade, sigilo e não repúdio em um ambiente inseguro, o que
possibilita a execução de operações que necessitem de um grau elevado de
segurança. Vimos também que um certificado deve ser emitido por uma AC. Quando
essa AC é reconhecida, ou como os especialistas chamam confiáveis, o certificado
digital é reconhecido perante o mundo, ou seja, garante, por força da legislação,
validade jurídica aos atos praticados com seu uso. Porém, por esses certificados
serem um pouco caros, quando se quer trabalhar com certificados digitais de uma
forma interna (por exemplo, comunicação interna na empresa) não é necessário
uma solicitação para uma AC reconhecida, pois qualquer pessoa pode produzir seu
próprio certificado digital.
Na maioria dos países, os certificados não seguem um protocolo único de
segurança, causando problemas, como: dificuldades inter-relacionais e em muitos
casos o certificado não tem um valor legal.
Para evitar esses problemas, o Brasil se baseou em um Estrutura Única de
Certificação, em que o Governo tem o controle de toda a cadeia de regulamentação
para que a certificação funcione corretamente.
Assim, uma das formas de um certificado digital ter a validade jurídica e até
mesmo garantir segurança em transações eletrônicas que o Governo venha a fazer
é a implantação de uma Infra-Estrutura de Chaves Públicas (ICP). No Brasil foi
implantado a ICP-Brasil (Infra-Estrutura de Chaves Públicas Brasileira) como mostra
a Medida Provisória nº 2.200-2, de 24 de Agosto de 2001:
O PRESIDENTE DA REPÚBLICA, no uso da atribuição que lhe confere o
art.62º da Constituição, adota a seguinte Medida Provisória, com força de
lei:
Art. 1º Fica instituída a Infra-Estrutura de Chaves Públicas Brasileira – ICP-
Brasil, para garantir a autenticidade, a integridade e a validade jurídica de
documentos em forma eletrônica, das aplicações de suporte e das
aplicações habilitadas que utilizem certificados digitais, bem como a
realização de transações eletrônicas seguras.
A ICP-Brasil, segundo o próprio site, se define como um conjunto de técnicas,
29
práticas e procedimentos implementados pelas organizações governamentais e
privadas brasileiras com o objetivo de estabelecer os fundamentos técnicos e
metodológicos de um sistema de certificação digital baseado em criptografia de
chave pública.
A estrutura da ICP-Brasil é do tipo hierárquica e tem uma concepção
institucional, definição de Raiz Única, com as Autoridades Certificadoras como
âncoras de confiança. A figura 6 mostra a estrutura da ICP-Brasil de forma resumida,
com as Autoridades Certificadoras de 1º nível e de 2º nível, sendo que no topo da
estrutura temos a Autoridade Certificadora Raiz (AC-Raiz).
Figura 6: Estrutura da ICP-Brasil de forma resumida
A figura 7 mostra de forma simplificada o sistema de certificação digital
brasileiro, note que a ICP-Brasil está vinculada ao ITI, pois o ITI é o órgão
responsável por manter a ICP-Brasil. O Comitê Gestor da ICP-Brasil e a Autoridade
Certificadora Raiz, assim como as demais entidades que compõem a estrutura,
30
foram instituídas pela Medida Provisória 2.200-2, de 24 de Agosto de 2001. A partir
dessa medida, foram elaborados os regulamentos que passaram a reger as
atividades das entidades integrantes da ICP-Brasil, chamados de resoluções do
Comitê Gestor da ICP-Brasil.
Figura 7: Simplificação do sistema de certificação digital brasileiro
Fonte: VERONESE; FREITAS, 2007, p.18
A certificação digital da ICP-Brasil é considerada segura devido a auditoria
que é feita nas autoridades, seja certificadora ou de registro, representando assim
teias de confiança.
As entidades participantes da ICP-Brasil são auditadas previamente ao
credenciamento, para verificar se estão aptas a desenvolver suas atividades
conforme os regulamentos. São efetuadas auditorias, também, anualmente,
para verificar se todos os procedimentos previstos foram executados. (SILVA
et al, 2008, p. 80)
Para um melhor entendimento da estrutura da ICP-Brasil, vamos descrever
cada tipo de entidade componente, a seguir.
4.2.1. COMITÊ GESTOR (CG)
É a entidade máxima dentro da estrutura da ICP-Brasil, é quem coordena a
implantação e o funcionamento da ICP-Brasil, estabelece a política e as normas
31
para credenciamento das Autoridades Certificadoras e das Autoridades de Registro,
definindo níveis da cadeia de certificação, e fiscaliza a atuação da Autoridade
Certificadora Raiz.
Os membros do CG são nomeados pelo Presidente da República, entre
representantes dos poderes da República, bem como, de segmentos da sociedade e
das Instituições de Ensino Superior, como forma de dar estabilidade, transparência e
confiabilidade ao sistema.
4.2.2. AUTORIDADE CERTIFICADORA RAIZ (AC-RAIZ)
É a primeira autoridade da cadeia de certificação. É a executora das políticas
de certificados e normas técnicas e operacionais aprovadas pelo CG, portanto, a
AC-Raiz emiti, expedi, distribui, revoga e gerencia os certificados das autoridades
certificadoras de nível imediatamente subsequente ao seu.
A AC-Raiz, também, está encarregada de emitir a lista de certificados
revogados e de fiscalizar e auditar as autoridades certificadoras e as autoridades de
registro, bem como, as demais prestadoras de serviço habilitados na ICP-Brasil.
4.2.3. AUTORIDADES CERTIFICADORAS (ACs)
São entidades, pública ou privada, credenciadas a emitir certificados digitais,
vinculando pares de chaves criptográficas ao respectivo titular.
As ACs são responsáveis por emitir, distribuir, renovar e gerenciar certificados
digitais, e colocá-los à disposição dos usuários. De acordo com o site da ICP-Brasil,
desempenha, como função essencial, a responsabilidade de verificar se o titular do
certificado possui a chave privada que corresponde à chave pública que faz parte do
certificado. Cria e assina digitalmente o certificado do assinante, onde o certificado
emitido pela AC representa a declaração da identidade do titular, que possui um par
único de chaves (pública e privada).
4.2.4. AUTORIDADES DE REGISTRO (ARs)
De acordo com o site da ICP-Brasil, as ARs são entidades responsáveis pela
32
interface entre o usuário e a AC. Elas são vinculadas a uma AC e tem por objetivo o
recebimento, validação, encaminhamento de solicitações de emissão ou revogação
de certificados digitais às ACs e identificação, de forma presencial, de seus
solicitantes.
As ARs têm como responsabilidade manter o registro de suas operações e
pode estar fisicamente localizada em uma AC ou ser uma entidade de registro
remota.
4.3. TIPOS DE CERTIFICADOS
A ICP-Brasil oferece duas categorias de certificados digitais: A e S, sendo que
cada uma se divide em quatro tipos: A1, A2, A3 e A4; S1, S2, S3 e S4. A categoria A
é direcionada para assinatura digital e a do tipo S é direcionada para atividades
sigilosas.
A seguir apresentamos a tabela 4 em que apresenta as descrições dos tipos
de certificados.
Tabela 4: Tipos de certificados e suas descrições
4.4. ESTRUTURA DE UM CERTIFICADO DIGITAL
O certificado digital é uma estrutura de dados, dentro do qual estão, no
mínimo, as seguintes informações:
Nome da pessoa ou entidade a ser associado à chave pública
33
Período de validade
Chave pública
Nome e assinatura da entidade que emitiu o certificado
Número de série
Figura 8: Certificado Digital
Embora existam vários tipos de formatos de certificados em uso na Internet. A
maior aceitação, atualmente, é o certificado descrito pela recomendação X.509 do
ITU-T (International Telecommunication Union – Telecommunication Standartization
Sector). De acordo com Silva et al (2008, p. 26), o formato X.509 é um padrão de
formato criado pela ITU-T, primeiramente publicado em 1988. A versão um (v1) deste
34
formato foi estendida, em 1993, para incorporar dois campos usados em controle de
acesso, resultando na versão dois (v2) do formato, posteriormente, mais um recurso
foi necessário e em 1996 foi lançada a versão três (v3) com a possibilidade de usar
campos de extensão.
A figura 9 ilustra o formato X.509 com os campos que cada versão apresenta.
Figura 9: Estrutura do formato X.509
Fonte: Site http://www.cic.unb.br/~pedro/c003/c2.htm
As extensões (extensions) presentes na versão três do formato X.509
proporcionam uma possibilidade de entidades (organizações e empresas) definirem
seus próprios campos de extensões e codificar informações específicas às suas
necessidades. A própria ICP-Brasil, através da Resolução nº 41, de 18 de Abril de
2006, definiu as seguintes extensões obrigatórias:
Authority Key Identifier, não crítica: o campo keyIdentifier deve conter o hash
SHA-11 da chave pública da AC;
Key Usage, crítica: em certificados do tipo A, somente os bits digitalSignature,
nonRepudiation e keyEncipherment podem estar ativados. Em certificados do
tipo S, somente os bits keyEncipherment e dataEncipherment podem estar
ativados;
Certificates Policies, não crítica: deve conter o OID2 da Política de
1 Hash SHA-1 é um tipo de função hash, ou seja, é um tipo de algoritmo criptográfico que está
diretamente ligado com a assinatura digital. 2 OID ou Object Identifier é um identificador usado para nomear um objeto.
35
Certificação correspondente e o endereço Web da Declaração de Práticas de
Certificação da AC que emite o certificado;
CRL3 Distribution Points, não crítica: deve conter o endereço Web onde se
obtém a Lista dos Certificados Revogados correspondente.
A ICP-Brasil também define como obrigatória a extensão Subject Alternative
Name, não crítica, e com os seguintes formatos:
a) Para certificado de pessoa física, três campos othername, obrigatórios, contendo:
OID = 2.16.76.1.3.1
Conteúdo = nas primeiras oito posições, a data de nascimento do titular, no
formato ddMMaaaa; nas onze posições subsequentes, o Cadastro de Pessoa
Física (CPF); nas onze posições subsequentes, o Número de Identificação
Social – NIS (PIS, PASEP ou CI); nas quinze posições subsequentes, o
número do Registro Geral (RG) do titular; nas seis posições subsequentes, as
siglas do órgão expedidor do RG e respectiva UF.
OID = 2.16.76.1.3.6
Conteúdo = nas doze posições, o número do Cadastro Específico do INSS
(CEI) da pessoa física titular do certificado.
OID = 2.16.76.1.3.5
Conteúdo = nas primeiras doze posições, o número de inscrição do Título de
Eleitor; nas três posições subsequentes, a Zona Eleitoral; nas quatro posições
seguintes, a Seção; nas vinte e duas posições subsequentes, o município e a
UF do Título de Eleitor.
b) Para certificados de pessoa jurídica, quatro campos othername, obrigatórios,
contendo, nesta ordem:
OID = 2.16.76.1.3.4
Conteúdo = nas primeiras oito posições, a data de nascimento do responsável
pelo certificado, no formato ddMMaaaa; nas onze posições subsequentes, o
Cadastro de Pessoa Física (CPF) do responsável; nas onze posições
subsequentes, o Número de Identificação Social – NIS (PIS, PASEP ou CI) do
responsável; nas quinze posições subsequentes, o número do RG do
responsável; nas seis posições subsequentes, as siglas do órgão expedidor
do RG e respectiva UF;
3 CRL é a lista de certificados revogados.
36
OID = 2.16.76.1.3.2
Conteúdo = nome do responsável pelo certificado;
OID = 2.16.76.1.3.3
Conteúdo = Cadastro Nacional de Pessoa Jurídica (CNPJ) da pessoa jurídica
titular do certificado;
OID = 2.16.76.1.3.7
Conteúdo = nas doze posições, o número do Cadastro Específico do INSS
(CEI) da pessoa jurídica titular do certificado.
37
5. AUTENTICAÇÃO WEB COM CERTIFICADOS DIGITAIS
Este capítulo apresentará uma abordagem sobre o processo de autenticação,
bem como, a implementação de um protótipo de um sistema de autenticação
utilizando certificados digitais.
No capítulo anterior foi abordada a certificação digital de acordo com a ICP-
Brasil. Porém, neste trabalho, os certificados digitais usados não são emitidos por
uma AC credenciada pela ICP-Brasil, em virtude de que cada certificado do tipo
A1(tipo utilizado na aplicação) em uma AC credenciada custa em torno de R$ 110,00
(cento e dez reais), o que torna inviável o uso desse certificado neste trabalho
acadêmico. Mas, os certificados usados no aplicativo estão de acordo com as
especificações do capítulo anterior, pois, para que haja segurança na emissão dos
certificados os mesmos serão emitidos por uma AC. Mais adiante será simulada a
criação de uma “AC” para que todo certificado cliente seja criado e assinado
digitalmente, atendendo, assim, um sistema web para ambiente fechado, ou seja,
sistema com público alvo conhecido em que os usuários são identificados e
registrados pela própria instituição.
O tipo de certificado utilizado neste trabalho é do tipo A1, ou seja, suas
chaves criptográficas vão ser geradas por software, que no caso é o OpenSSL ou a
ferramenta Keytool, e o tamanho de suas chaves é de 1024 bits.
A aplicação de demonstração é um protótipo de autenticação típica em
sistemas web. O processo de autenticação empregado pode ser indicado para
sistemas em que exigem uma conexão segura. Por exemplo, um sistema de
lançamento de notas ou controle de reserva de publicações de uma biblioteca em
uma instituição de ensino. Tais sistemas devem prover a integridade das
informações, portanto, necessitam de uma conexão segura. Nesse caso, a própria
instituição poderá emitir e criar os próprios certificados dos usuários. É este o
cenário que será tratado neste trabalho.
5.1. TECNOLOGIAS UTILIZADAS
Para a implementação do protótipo do sistema de autenticação foram
38
utilizadas as seguintes tecnologias: Apache Tomcat, Eclipse Ganymede, JDK e
OpenSSL, que serão apresentadas cada uma a seguir.
5.1.1. APACHE TOMCAT
O próprio site do Apache Tomcat apresenta como definição que Apache
Tomcat é uma implementação de software Open Source do Java Servlet e
tecnologias Java Server Pages.
O Tomcat é um servidor web, mais especificamente, um contêiner. Possui
características próprias de um servidor de aplicação, porém, não pode ser
considerado um servidor de aplicação devido não preencher os requisitos
necessários; por exemplo, não tem suporte a Enterprise JavaBeans (EJB).
Desenvolvido pela Apache Software Foundation, dentro do projeto Jakarta, sendo
utilizado tanto em ambientes de desenvolvimento, quanto de produção, portanto,
robusto. A versão 6.0.20 foi a utilizada no presente trabalho.
5.1.2. ECLIPSE GANYMEDE
Eclipse Ganymede é uma plataforma de desenvolvimento para várias
linguagens de programação, e é composto por Ambiente de Desenvolvimento
Integrado (IDE) e um sistema de plugins para estendê-lo. É um software Open
Source e para seu funcionamento é necessário que se tenha uma Java Virtual
Machine (JVM) instalada no computador. A versão Ganymede do Eclipse utilizada foi
a 3.4.0.
5.1.3. JAVA DEVELOPMENT KIT (JDK)
Java Development Kit (JDK), que em português significa kit de
desenvolvimento Java, é um produto da Sun Microsystems destinado a
programadores Java. Constitui um conjunto de programas que englobam
compilador, interpretador e utilitários, fornecendo, assim, um pacote de ferramentas
básicas para o desenvolvimento de aplicações Java.
O JDK é liberado pela Sun sob a licença GNU General Public License (GPL) e
39
a versão utilizada neste trabalho é a 1.6.0_17.
5.1.4. OPENSSL
De acordo com o site do OpenSSL (OPENSSL, 2009), o projeto OpenSSL é
um esforço colaborativo, ou seja, é mantida por um grupo de voluntários de todo o
mundo, cujo o objetivo é desenvolver uma biblioteca criptográfica robusta e com
várias funcionalidades.
A sua biblioteca é de domínio público que pode ser utilizada livremente para
desenvolvimento de aplicações comerciais ou não. Nestas bibliotecas são
implementados protocolos para camadas de Secure Sockets Layer (SSL v2/v3) e de
Transport Layer Security (TLS v1), além de funcionalidades criptográficas de
propósitos gerais.
5.2. PROCESSO DE AUTENTICAÇÃO
O processo de autenticação vai utilizar a criptografia assimétrica. A sua
principal utilização não é só garantir a autenticação e o não repudio do emissor, mas
também garantir a confidencialidade e a integridade das mensagens.
O uso dos certificados digitais determina quem é efetivamente o dono das
chaves públicas distribuídas, pois, como já foi dito, o certificado digital é um
documento eletrônico assinado digitalmente por uma autoridade certificadora, e que
contém diversos dados sobre o emissor e seu titular, cuja função é vincular uma
pessoa ou entidade a uma chave pública.
De acordo com Kurose (2006, p. 555), o protocolo SSL foi desenvolvido pela
Netscape e é um protocolo projetado para fornecer criptografia de dados e
autenticação entre um cliente e um servidor Web.
A combinação do protocolo SSL (Secure Sockets Layer) com o protocolo
HTTP (Hypertext Transfer Protocol) nos dá o HTTPS (Hypertext Transfer Protocol
Secure), que fornece encriptação de dados, autenticação de servidor, integridade de
mensagem e autenticação de cliente. Caso seja feita uma análise na pilha TCP/IP,
podemos dizer que o SSL está em uma sub-camada localizada entre a camada de
aplicação e a camada de transporte, como mostra a figura 10.
40
Aplicação (HTTP)
Segurança (SSL)
Transporte (TCP)
Rede (IP)
Enlace de Dados (PPP)
Física (Modem, ADSL)
Figura 10: Pilha TCP/IP – Camadas para um usuário navegando com SSL
O sistema implementado consiste no uso de um certificado servidor e do
certificado cliente em que há a utilização do SSL duplo. O uso do certificado servidor
irá garantir a identidade do servidor e os clientes terão certeza de que estão
acessando o site desejado. Quando a autenticação é somente do servidor,
chamamos de SSL simples, mas quando a autenticação é de ambos os lados
(servidor e cliente), chamamos de SSL duplo. Para os propósitos do trabalho, é
utilizado o SSL duplo.
5.3. GERAÇÃO DOS CERTIFICADOS
Obter um certificado emitido por uma AC dentro da cadeia do ICP-Brasil pode
ser um pouco caro e burocrático. Em virtude disso, estaremos gerando e simulando
certificados que serão utilizados no sistema. Para a geração desses certificados
serão utilizadas as ferramentas OpenSSL e o Keytool4.
5.3.1. CRIAÇÃO DA CHAVE E DO CERTIFICADO DA AUTORIDADE
CERTIFICADORA
O comando para a criação da chave :
O comando acima gera a chave privada com tamanho de 1024 bits e usa o
4 Keytool é uma ferramenta de gerenciamento de chaves e certificados e é uma das ferramentas
presente no Java Development Kit (JDK).
C:\OpenSSL\bin>openssl req -new -newkey rsa:1024 -nodes -out
C:\Certificados\CA.csr -keyout C:\Certificados\CA.key
41
algoritmo criptográfico RSA. O arquivo “CA.key” é o que contém a chave privada da
AC.
O comando para a geração do certificado da AC é:
Após a execução deste comando, teremos o certificado da AC com validade
de cinco anos. As informações da chave privada e do certificado estão armazenados
no arquivo “CA.pem”.
5.3.2. CRIAÇÃO DO KEYSTORE, DO CERTIFICADO DO SERVIDOR E
DO TRUSTSTORE
Para a criação do certificado do servidor é utilizada a ferramenta Keytool. O
comando keytool será usado para criar um Keystore5 contendo um certificado digital
para o servidor, que no caso será o Tomcat.
O comando abaixo é para a criação do Keystore e do certificado do servidor.
O comando acima gera um par de chaves e um certificado referenciado pelo
alias “tomcat” com validade de 365 dias e que será armazenado no Keystore
“tomcat.jks”, e usa algoritmos RSA e SHA1WithRSA para gerar o par de chaves e o
certificado.
Antes da criação do Truststore6 é necessário converter o certificado da AC
que está na extensão “.pem” para a extensão “.der”, como segue abaixo:
E para a criação do Truststore, segue o comando:
5 Keystore é um armazenamento de chave que contém a chave privada, logo contém também o
certificado do servidor. 6 Truststore contém os certificados das Autoridades Certificadoras que pode confiar.
C:\OpenSSL\bin>openssl x509 –in C:\Certificados\CA.pem –out
C:\Certificados\CA.der –outform DER
C:\Arquivos de Programas\Java\jdk1.6.0_17\bin>keytool –genkey –
alias tomcat –keyalg RSA –sigalg SHA1WithRSA –keystore
C:\Certificados\tomcat.jks –validity 365
C:\OpenSSL\bin>openssl x509 –trustout –signkey
C:\Certificados\CA.key –days 1825 –req –in C:\Certificados\CA.csr
–out C:\Certificados\CA.pem
42
5.3.3. CRIAÇÃO DO CERTIFICADO DO CLIENTE
Para a solicitação do certificado do cliente é executado o seguinte comando:
O comando acima cria um novo pedido de certificado e uma nova chave
privada, onde se utiliza o algoritmo criptográfico RSA e o tamanho da chave é 1024
bits. O arquivo “CLIENTE.key” guarda as informações da chave privada criada.
O próximo passo é criar e assinar o certificado do cliente através da AC
criada. Para tal procedimento é executado o seguinte comando:
Como muitos utilizam o padrão Windows, é necessário criar o arquivo “.p12”,
como segue abaixo:
5.4. CONFIGURAÇÃO DO SSL
A proposta que se quer apresentar é a construção de um sistema de
autenticação usando certificados digitais, mas para que a autenticação seja
considerada forte é necessário habilitar o SSL duplo, configurando o servidor
Apache Tomcat. O código abaixo é a configuração da porta 8443 para o SSL duplo,
em que pertence ao arquivo server.xml da pasta conf do Tomcat.
C:\OpenSSL\bin>openssl pkcs12 –export –in
C:\Certificados\CLIENTE.pem –inkey C:\Certificados\CLIENTE.key –
out C:\Certificados\CLIENTE.p12
C:\OpenSSL\bin>openssl x509 –req –in C:\Certificados\CLIENTE.req –
CA C:\Certificados\CA.pem –CAkey C:\Certificados\CA.key –
CAcreateserial –out C:\Certificados\CLIENTE.pem
C:\OpenSSL\bin>openssl req –new –newkey rsa:1024 –nodes –out
C:\Certificados\CLIENTE.req –keyout C:\Certificados\CLIENTE.key
C:\Arquivos de Programas\Java\jdk1.6.0_17\bin>keytool –importcert
–alias ifpa –file C:\Certificados\CA.der –keystore
C:\Certificados\truststore.jks –storepass c796ne
43
Vale lembrar que o Keystore e o Truststore criados na sub-seção 5.3.2 devem
estar na pasta conf do Tomcat.
Antes de testarmos a configuração do Apache Tomcat é necessário importar o
certificado da AC e do cliente no Browser (como exemplo, será utilizado o Mozilla
Firefox).
No Mozilla Firefox, utilizaremos o menu “Ferramentas/Opções”, na categoria
“Avançado”, na aba “Criptografia”, conforme a figura 11:
Figura 11: Janela “Opções”, na categoria “Avançado”, na aba “Criptografia”
Clicando o botão “Certificados”, teremos o Gerenciador de Certificados.
<Connector port= “8443” protocol= “HTTP/1.1” SSLEnabled= “true”
maxThreads= “150” scheme= “https” secure= “true” keystoreFile=
“conf/tomcat.jks” keystorePass= “c796ne” truststoreFile=
“conf/truststore.jks” truststorePass= “c796ne” clientAuth= “true”
sslProtocol= “TLS” />
44
Figura 12: Gerenciador de Certificados
Para a importação do certificado da AC, selecionamos a aba “Autoridades” e
clicamos no botão “Importar”. Navegamos até o diretório em que se encontra o
certificado da AC, que no caso deste trabalho, conforme seção 5.3.1, chama-se de
“CA.pem”. Será apresentado o diálogo a seguir:
Figura 13: Diálogo para a importação do Certificado da AC
Marcando todas as opções e clicando no botão “OK” será concluída a
importação do certificado da AC.
Para a importação do certificado do cliente, selecionamos a aba “Seus
45
certificados” e clicamos no botão “Importar”. Navegamos até o diretório em que se
encontra o certificado do cliente e clicamos em “OK”. Os dados do certificado
deverão aparecer na lista do Gerenciador, como mostra a figura 14.
Figura 14: Dados do Certificado do Cliente no Gerenciador de certificados
Quando testamos a configuração do Apache Tomcat, em vez de
http://localhost:8080, deve-se trabalhar com a seguinte URL: https://localhost:8443.
Acessando essa página, o servidor solicita a identificação do usuário com uso de
certificado digital, confirmando a solicitação, é redirecionado para a página do
servidor.
Figura 15: Solicitação de identificação do usuário utilizando certificado digital
46
A utilização do certificado do servidor em conjunto com a tecnologia SSL
possibilita criptografar e proteger as informações transmitidas pela internet,
garantindo uma conexão segura entre o navegador do usuário e o servidor web. O
ícone do cadeado na barra de status simboliza essa conexão segura, como visto na
figura 16.
Figura 16: Ícone do cadeado na barra de status do navegador
5.5. AUTENTICAÇÃO E MANIPULAÇÃO DE CERTIFICADOS
O protótipo desenvolvido utilizou as tecnologias Java Server Pages (JSP) e
Servlet, e dentre as bibliotecas usadas temos o Bouncy Castle e o Java
Cryptography Architecture (JCA). O Bouncy Castle, assim como o JCA, é uma API
de segurança da linguagem de programação Java que permite aos programadores
incluir nas aplicações funcionalidades criptográficas.
A figura 17 ilustra o fluxo de funcionamento do sistema. O sistema obtém o
certificado do browser através do atributo da interface ServletRequest. Caso o valor
do atributo seja nulo, ocorre uma exceção. Se o valor do atributo não for nulo,
podem ocorrer duas alternativas: ou são mostrados os dados do certificado ou é
feita a autenticação.
47
Figura 17: Fluxo de funcionamento do sistema
Na figura 18 é mostrada a página principal do protótipo (index.jsp). No
Apêndice temos o código da página index.jsp, assim como os demais códigos.
Figura 18: Página index.jsp do protótipo do Sistema de Autenticação
48
Figura 19: Solicitação de identificação do usuário
Quando solicitamos Mostrar Certificado ou Acessar, ocorre o que foi abordado
na seção 5.2, ou seja, sucede a autenticação de ambos os lados (servidor e cliente),
conforme mostra a figura 19 com a solicitação de identificação do usuário. Há,
também, outro fato acontecendo: a obtenção do certificado do cliente no browser
através do seguinte atributo da interface ServletRequest:
E quando colocamos o código abaixo, estamos retornando o valor do atributo,
ou seja, estamos obtendo informações sobre o certificado do cliente.
Após obter o certificado do cliente, é possível verificar os dados do certificado,
como: assunto, número de série, as datas de início e de término da validade e o
emissor. Basta extrair os dados listados e preencher as variáveis apropriadas.
X509Certificate[] certs = (X509Certificate[]) req.getAttribute
(CLIENT_CERT);
private static final String CLIENT_CERT =
“javax.servlet.request.X509Certificate”;
49
A figura 20 mostra a página JSP dos dados do certificado do cliente.
Figura 20: Página dadosCertificado.jsp, mostra os dados do certificado do cliente
Para que possamos trabalhar com a autorização e autenticação do sistema é
necessário extrair o CN7, ou seja, o campo assunto do certificado identifica o titular
(proprietário do certificado) e nesse campo há o CN, que, normalmente, contém o
nome de uma empresa ou nome de uma pessoa. E para obter esse campo,
utilizamos a função getSubjectX500Principal() que retorna uma instância da classe
X500Principal.
7 CN é o Common name, é o campo do certificado que contém o nome de uma empresa ou nome de
uma pessoa.
String assunto = eeCert.getSubjectX500Principal().toString();
String numeroDeSerie = eeCert.getSerialNumber().toString(16);
String inicioValidade = eeCert.getNotAfter().toString();
String fimValidade = eeCert.getNotBefore().toString();
String emissor = eeCert.getIssuerX500Principal().toString();
req.setAttribute (Constantes.ASSUNTO, assunto);
req.setAttribute (Constantes.NUMERO_DE_SERIE, numeroDeSerie);
req.setAttribute (Constantes.INICIO_VALIDADE, inicioValidade);
req.setAttribute (Constantes.FIM_VALIDADE, fimValidade);
req.setAttribute (Constantes.EMISSOR, emissor);
50
A figura 21 mostra a página de acesso autorizado, ou seja, quando o
certificado é autorizado pelo sistema, conseguimos acessar esta página.
Figura 21: Página entradaForca.jsp
req.setAttribute(“nome”,
IcpBrasilUtils.getNome(eeCert.getSubjectX500Principal());
static String getNome(X500Principal assunto){
if(assunto != null){
X509NameTokenizer NameTokenizer = new
X509NameTokenizer(assunto.toString());
while (NameTokenizer.hasMoreTokens()){
String token = NameTokenizer.nextToken();
if(token.startsWith(“CN=”)){
return token.substring(3, token.length());
}
}
}
Return “”;
}
51
6. CONCLUSÃO
Sabe-se que a informação é um bem valioso e disputado, e a Internet se
tornou um meio de acelerar e movimentar as informações. Portanto, a necessidade
de autenticação de usuários para a segurança de sistemas é evidente e o uso de
mecanismos tradicionais, como login e senha, tem se mostrado muito vulnerável a
ataques. E além do mais, qualquer informação transmitida em redes de
computadores, ou na Internet, está vulnerável a interceptação por outros não
autorizados. Logo, uma das soluções para esse tipo de problema é o uso de
certificados digitais.
Então, combinando conceitos de segurança da informação, criptografia,
certificação digital e processo de autenticação utilizando SSL Duplo, propomos uma
alternativa de autenticação para atender um sistema web de ambiente fechado. O
uso da criptografia assimétrica em conjunto com o certificado digital torna possível
chegar ao objetivo de proteção de dados, que é proporcionado pela configuração do
Apache Tomcat.
Portanto, o sistema desenvolvido contribui para fornecer a autenticidade,
integridade e confidencialidade das informações, já que, atualmente, as informações
são consideradas um bem valioso. E o Instituto Federal de Educação, Ciência e
Tecnologia do Pará (IFPA) pode usufruir desta solução, melhorando a sua segurança
em seu sistema de Lançamento de Notas ou até mesmo em outro sistema, como por
exemplo, a reserva de livros na Biblioteca.
Como muitas redes internas buscam uma melhoria na sua segurança, essa
proposta de autenticação colabora para essa melhoria. Porém, não podemos deixar
de citar que para um sistema ter um nível de segurança alto é interessante empregar
os três paradigmas (algo-que-você-sabe, algo-que-você-tem e algo-que-você-é).
Mecanismos de autenticação se baseiam principalmente em três
paradigmas: algo-que-você-sabe, algo-que-você-tem ou algo-que-você-é.
No paradigma algo-que-você-sabe, um requerente apresenta conhecimento
de algo, como uma senha. Na abordagem algo-que-você-tem, um
requerente demonstra a posse de algo como uma chave física, cartão ou
arquivo. O paradigma algo-que-você-é é baseado em uma característica
imutável verificável do requerente, como a voz, impressão digital ou padrão
de retina (SILVA et al, 2008, p. 7).
52
Vale lembrar que o sistema desenvolvido é apenas um protótipo e os
certificados apresentados não podem ser de uso externo, pois não há validade
jurídica. Para ter essa validade é necessário que os certificados sejam emitidos por
uma AC credenciada pelo ICP-Brasil.
A certificação digital não se resume somente na autenticação de usuários,
muitas são as aplicações dessa tecnologia. Deste modo, há vários pontos a serem
aprofundados e consequentemente, muitos trabalhos científicos podem, assim como
devem ser desenvolvidos futuramente. Por exemplo, não foi tratado neste trabalho e
que pode ser trabalhado futuramente:
a) testar a aplicação web em outras linguagens de programação;
b) validar a proposta em um sistema real;
c) implementar e integrar um SGBD ( Sistema de Gerenciamento de Banco de
Dados);
d) obter OIDs válidos para uso nas extensões dos certificados;
e) trabalhar uma das aplicações da certificação que vem sendo bastante
utilizada: a assinatura digital, que recentemente o Ministério da Educação
vem adotando em suas transações eletrônicas; e muitas outras.
Apesar da certificação digital ser um tema pouco conhecido até por aqueles
que lidam constantemente com diversas tecnologias presentes na
contemporaneidade, a certificação digital tem trazido melhorias de processos e
possibilidade de novas formas de interação entre governo-governo, cidadão-governo
e governo-negócio, sendo assim, é uma tecnologia recente que vem aos poucos
permeando várias práticas sociais e políticas.
53
REFERÊNCIAS
ABNT NBR ISO/IEC 17799:2005 – Tecnologia da informação – Técnicas de
segurança – Código de prática para a gestão da segurança da informação.
ALBUQUERQUE, Ricardo; RIBEIRO, Bruno. Segurança no Desenvolvimento de
Software: Como garantir a segurança do sistema para seu cliente usando
ISO/IEC 15.408. Rio de Janeiro, Campus, 2002.
BRASIL. Medida Provisória 2200-2, de 24 de Agosto de 2001.
BRASIL. Resolução nº 41, de 18 de Abril de 2006.
BROCARDO, Marcelo Luiz et al. Introdução à Certificação Digital: Da Criptografia ao
Carimbo de Tempo. Florianópolis, BRy Tecnologia, 2006.
DIAS, Claúdia. Segurança e Auditoria da Tecnologia da Informação. Rio de Janeiro,
Editora Axcel Books do Brasil, 2000.
GOMES, Kleiton da Silva; SANTOS, Newton. Segurança no Desenvolvimento de
Aplicações Web. 2006. 83f. Trabalho de Conclusão de Curso (Bacharelado
em Ciência da Computação) – Universidade da Amazônia – UNAMA, Belém,
2006.
ICP-Brasil – Infra-Estrutura de Chaves Públicas Brasileira. Disponível em:
<http://www.icpbrasil.gov.br>. Acessado em 20 de out. 2009.
ISO/IEC 15408 – Common Criteria. Disponível em:
<http://www.commoncriteriaportal.org/>. Acessado em 18 de out. 2009.
ITI – Instituto Nacional de Tecnologia da Informação. Disponível em:
<http://www.iti.gov.br>. Acessado em: 20 de out. 2009.
KRONBAUER, Julio Cezar. Um Modelo Centralizado de Autenticação de Usuários
usando Certificação Digital. 2007. 64f. Trabalho de Conclusão de Curso
(Bacharelado em Ciência da Computação) – Universidade de Santa Cruz do
Sul – UNISC, Santa Cruz do Sul, 2007.
KUROSE, James F.; ROSS, Keith W. Segurança em Redes de Computadores.
In:_____. Redes de Computadores e Internet: uma abordagem top-down.
São Paulo, Pearson Addison Wesley, 2006. Cap. 8, p. 512-568.
OPENSSL – The Open Source toolkit for SSL/TLS. Disponível em:
http://www.openssl.org/. Acessado em: 20 de out. 2009.
54
REZENDE, Pedro Antônio Dourado de. Infraestrutura de Chaves Públicas.
Disponível em: <http://www.cic.unb.br/~pedro/c003/C2.htm>. Acessado em
22 de dez. 2009.
SILVA, Luiz Gustavo Cordeiro da et al. Certificação Digital – Conceitos e Aplicações.
Rio de Janeiro, Ciência Moderna Ltda., 2008..
SUTIL, Jeandré Monteiro. Implementando uma Nova Abordagem para a Troca do
Par de Chaves de uma AC-Raiz. 2006. 54f. Trabalho de Conclusão de Curso
(Bacharelado em Ciência da Computação) – Universidade Federal de Santa
Catarina – UFSC, Florianópolis, 2006.
TERADA, Routo. Segurança de Dados: Criptografia em Redes de Computador. São
Paulo, Editora Edgard Blücher Ltda., 2000.
VERONESE, Alexandre; DE FREITAS, Christiana Soares. Segredo e Democracia:
certificação digital e software livre. Informática Pública, Belo Horizonte, v.8,
n. 2, p. 09-26, 2007
XAVIER, Fabricio da Silva Valadares. Desenvolvimento de um Laboratório Virtual
baseado em PHP para estudo de criptografia RSA em Ambiente de Internet.
2005. 100f. Projeto de Conclusão de Curso (Bacharelado em Ciência da
Computação) – Universidade Vale do Rio Verde – UninCor, Três Corações,
2005.
55
APÊNDICE A – CÓDIGO FONTE DO SISTEMA DE AUTENTICAÇÃO
index.jsp
<html>
<head>
<title>::. Certificação Digital .::</title>
<link rel="stylesheet" href="styles/padrao.css"/>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-
1”>
<script type="text/javascript">
function setAction(action, form) {
if(action == 'mostraDados') {
form.action = 'https://localhost:8443/digitalCertification/
DetalhesDoCertificado’;
} else if (action == 'loga') {
form.action = 'https://localhost:8443/digitalCertification/
Entrada’;
}
return true;
}
</script>
</head>
<body>
<%@ include file="/banner.jsp"%>
<form id="formulario" name="formulario" method="POST" action="">
<table>
<tr>
<td>Para se autenticar com seu certificado digital, clique no
botão abaixo.</td>
</tr>
<tr>
<td></td>
</tr>
<tr>
<td><input type="submit" value="Acessar"onclick =
"setAction('loga', document.formulario)"/></td>
</tr>
<tr>
<td> </td>
</tr>
<tr>
<td>Para mostrar os dados do certificado, clique no botão
abaixo.</td>
</tr>
<tr>
<td></td>
</tr>
<tr>
<td><input type="submit" value="Mostrar Certificado" onclick =
"setAction('mostraDados', document.formulario)" /><br>
</tr>
</table>
</form>
</body>
</html>
56
banner.jsp
<table cellspacing="10" cellpadding="10">
<tr>
<td align="center">
<img src="images/ifpa.jpg" alt="IFPA">
</td>
<td align="center">
<table cellspacing="2" cellpadding="2">
<tr>
<td align="center"><h1>Sistema de Autenticação usando</h1></td>
</tr>
<tr>
<td align="center"><h1>Certificado Digital</h1></td>
</tr>
</table>
</td>
</tr>
</table>
entradaForca.jsp
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<link rel="stylesheet" href="styles/padrao.css"/>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-
1">
<title>::. Certificação Digital .::</title>
</head>
<body>
<%@ include file="/banner.jsp"%>
<br>
<br>
<h3>Seja bem-vindo, ${nome}</h3>
<br>
Você foi identificado(a) como um(a) ${papel}.
<br>
<br>
<h3>Ações</h3>
<ul>
<c:forEach items="${acoes}" var="acao">
<li>${acao}</li>
</c:forEach>
</ul>
</body>
</html>
57
dadosCertificado.jsp
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<link rel="stylesheet" href="styles/padrao.css"/>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-
1">
<title>::. Certificação Digital - Dados do Certificado .::</title>
</head>
<body>
<%@ include file="/banner.jsp"%>
<br>
<br>
<h3>Dados do Certificado</h3>
<br>
<table>
<tr class="cor1">
<td>Assunto: </td>
<td>${assunto}</td>
</tr>
<tr class="cor2">
<td>Numero de Serie: </td>
<td>${numeroDeSerie}</td>
</tr>
<tr class="cor1">
<td>Data de Início de Validade:</td>
<td>${inicioValidade}</td>
</tr>
<tr class="cor2">
<td>Data de Término de Validade:</td>
<td>${fimValidade}</td>
</tr>
<tr class="cor1">
<td>Emissor:</td>
<td>${emissor}</td>
</tr>
</table>
</body>
</html>
acessoNegado.jsp
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<link rel="stylesheet" href="styles/padrao.css"/>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-
1">
<title>::. Certificação Digital .::</title>
</head>
58
<body>
<%@ include file="/banner.jsp"%>
<br>
<br>
<h3>Erro ao Liberar o Acesso</h3>
<br>
Você não pode entrar no sistema.
</body>
</html>
erro.jsp
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<link rel="stylesheet" href="styles/padrao.css"/>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-
1">
<title>::. Certificação Digital .::</title>
</head>
<body>
<%@ include file="/banner.jsp"%>
<br>
<br>
<h3>Erro ao obter o certificado</h3>
<br>
Verifique se você escolheu um certificado válido.
</body>
</html>
AutorizacaoException.java
package br.edu.ifpa.tac.cert;
public class AutorizacaoException extends Exception{
private static final long serialVersionUID = 1L;
public AutorizacaoException(){
super();
}
public AutorizacaoException(String message, Throwable cause){
super(message, cause);
}
public AutorizacaoException(String message){
super(message);
}
public AutorizacaoException(Throwable cause){
super(cause);
}
}
59
Autorizador.java package br.edu.ifpa.tac.cert;
import java.io.IOException;
import java.math.BigInteger;
import java.security.cert.X509Certificate;
import java.util.HashMap;
import java.util.Map;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class Autorizador {
public static final String PAPEL_ADMIN = "ADMINISTRADOR";
public static final String PAPEL_USU = "USUARIO";
private static Log logger = LogFactory.getLog(Autorizador.class);
private static Map<BigInteger, String> numSerieUsuarios;
static {
numSerieUsuarios = new HashMap<BigInteger, String>();
//Luciana
numSerieUsuarios.put(new BigInteger("f789f3ddb61fe00d", 16),
PAPEL_ADMIN);
//Isabella
numSerieUsuarios.put(new BigInteger("f789f3ddb61fe00f", 16),
PAPEL_USU);
//Jasper
numSerieUsuarios.put(new BigInteger("f789f3ddb61fe010", 16),
PAPEL_USU);
}
public static String autoriza(X509Certificate eeCert, String recurso)
throws AutorizacaoException, IOException {
// Verificar se o certificado enviado não é nulo
if(eeCert == null) {
logger.warn( "Certificado não encontrado na conexão." );
throw new AutorizacaoException("Não foi possível autenticar o
usuário.");
}
// Obter papel do usuário
String papel=getPapelUsandoNumeroDeSerie(eeCert.getSerialNumber());
// Validar se o papel foi encontrado
if( papel == null ) {
// Loga erro de autenticação
logger.info("\nAcesso negado para o certificado apresentado.
\nEmissor: '" + eeCert.getIssuerX500Principal().
toString() + "' \nNúmero de série: '" +
eeCert.getSerialNumber().toString(16) + "'" );
// Lança exceção
throw new AutorizacaoException("Acesso negado para o certificado
apresentado. Recurso: '" + recurso
+ "' Emissor: '" +
60
eeCert.getIssuerX500Principal().
toString() + "' Número de série:
'" + eeCert.getSerialNumber().
toString(16) + "'");
}
logger.info("\nAcesso liberado para o certificado apresentado.
\nRecurso: '" + recurso + "' \nEmissor: '" +
eeCert.getIssuerX500Principal().toString() + "'
\nNúmero de série: '" +
eeCert.getSerialNumber().toString(16) + "'
\nPapel: '" + papel + "'" );
// Retorna papel
return papel;
}
@SuppressWarnings("unused")
private static final String getPapelUsandoNumeroDeSerie(BigInteger
numeroDeSerie) {
return numSerieUsuarios.get(numeroDeSerie);
}
}
Constantes.java
package br.edu.ifpa.tac.cert;
public class Constantes {
public static final String PAPEL_USUARIO = "papel";
public static final String INICIO_VALIDADE = "inicioValidade";
public static final String FIM_VALIDADE = "fimValidade";
public static final String NUMERO_DE_SERIE = "numeroDeSerie";
public static final String ASSUNTO = "assunto";
public static final String EMISSOR = "emissor";
protected static final String accessDeniedPage = "/acessoNegado.jsp";
protected static final String noClientCertPage =
"/certificadoNaoEncontrado.jsp";
private Constantes(){
}
}
ControleDeAcesso.java
package br.edu.ifpa.tac.cert;
import java.io.IOException;
import java.security.cert.X509Certificate;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.RequestDispatcher;
61
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class ControleDeAcesso implements Filter{
private Log logger = LogFactory.getLog(this.getClass().getName());
private static final String CLIENT_CERT =
"javax.servlet.request.X509Certificate";
private static final String NO_CLIENT_CERT_PAGE =
"/certificadoNaoEncontrado.jsp";
private static final String ACCESS_DENIED_PAGE = "/acessoNegado.jsp";
@Override
public void destroy() {
}
@Override
public void doFilter(ServletRequest req, ServletResponse resp,
FilterChain chain) throws IOException, ServletException {
logger.trace(">doFilter");
X509Certificate[] certs = (X509Certificate[])
req.getAttribute(CLIENT_CERT);
if (certs == null){
logger.warn("Certificado não encontrado na conexão");
dispatchErrorPage(NO_CLIENT_CERT_PAGE, req, resp);
return;
}
X509Certificate eeCert = certs[0];
try{
String papel = Autorizador.autoriza(eeCert,"Certificado Digital");
req.setAttribute(Constantes.PAPEL_USUARIO, papel);
chain.doFilter(req, resp);
}catch(AutorizacaoException e){
dispatchErrorPage(ACCESS_DENIED_PAGE, req, resp);
}
}
private void dispatchErrorPage(String errorPage, ServletRequest req,
ServletResponse resp)throws ServletException, IOException {
62
logger.trace(">dispatchErrorPage: " + errorPage);
RequestDispatcher dispatcher = req.getRequestDispatcher(errorPage);
dispatcher.forward(req, resp);
}
@Override
public void init(FilterConfig arg0) throws ServletException {
}
}
EntradaServlet.java
package br.edu.ifpa.tac.cert;
import java.io.IOException;
import java.security.cert.X509Certificate;
import java.util.ArrayList;
import java.util.List;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class EntradaServlet extends HttpServlet{
private static final long serialVersionUID = 1L;
private static final String CLIENT_CERT =
"javax.servlet.request.X509Certificate";
private Log logger = LogFactory.getLog(this.getClass().getName());
protected void doGet(HttpServletRequest req, HttpServletResponse
resp)throws ServletException, IOException{
this.doPost(req, resp);
}
protected void doPost(HttpServletRequest req, HttpServletResponse
resp)throws ServletException, IOException{
X509Certificate[] certs = (X509Certificate[])
req.getAttribute(CLIENT_CERT);
63
String page = "/erro.jsp";
if (certs != null){
X509Certificate eeCert = certs[0];
req.setAttribute("nome",
IcpBrasilUtil.getNome(eeCert.getSubjectX500Principal()));
List<String> acoesPapel = getAcoes((String)
req.getAttribute(Constantes.PAPEL_USUARIO));
req.setAttribute("acoes", acoesPapel);
page = "/entradaForca.jsp";
}else{
logger.fatal("Erro inesperado. Certificado não foi encontrado");
}
RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher(page);
dispatcher.forward(req, resp);
}
private List<String> getAcoes(String papel) {
List<String> acoes = new ArrayList<String>();
if(papel == Autorizador.PAPEL_ADMIN){
acoes.add("Administrar a rede");
acoes.add("Gerenciar contas de usuário");
}else if(papel == Autorizador.PAPEL_USU){
acoes.add("Acessar sua conta");
}
return acoes;
}
}
IcpBrasilUtils.java
package br.edu.ifpa.tac.cert;
import javax.security.auth.x500.X500Principal;
import org.bouncycastle.asn1.x509.X509NameTokenizer;
public class IcpBrasilUtil {
private IcpBrasilUtil(){
}
static String getNome(X500Principal assunto){
64
if(assunto != null){
X509NameTokenizer NameTokenizer = new
X509NameTokenizer(assunto.toString());
while (NameTokenizer.hasMoreTokens()){
String token = NameTokenizer.nextToken();
if (token.startsWith("CN=")){
return token.substring(3, token.length());
}
}
}
return "";
}
}
MostraCertificado.java
package br.edu.ifpa.tac.cert;
import java.io.IOException;
import java.security.cert.X509Certificate;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class MostraCertificado extends HttpServlet {
private static final long serialVersionUID = 1L;
@SuppressWarnings("unused")
private Log logger = LogFactory.getLog(this.getClass().getName());
@SuppressWarnings("unused")
private static final String SSL_SESSION =
"javax.servlet.request.ssl_session";
private static final String CLIENT_CERT =
"javax.servlet.request.X509Certificate";
protected void doGet(HttpServletRequest req, HttpServletResponse
65
resp)throws ServletException, IOException{
this.doPost(req, resp);
}
protected void doPost(HttpServletRequest req, HttpServletResponse
resp)throws ServletException, IOException{
X509Certificate[] certs = (X509Certificate[])
req.getAttribute(CLIENT_CERT);
String page = "/erro.jsp";
if(certs != null){
X509Certificate eeCert = (X509Certificate) certs[0];
String assunto = eeCert.getSubjectX500Principal().toString();
String numeroDeSerie = eeCert.getSerialNumber().toString(16);
String inicioValidade = eeCert.getNotAfter().toString();
String fimValidade = eeCert.getNotBefore().toString();
String emissor = eeCert.getIssuerX500Principal().toString();
req.setAttribute(Constantes.ASSUNTO, assunto);
req.setAttribute(Constantes.NUMERO_DE_SERIE, numeroDeSerie);
req.setAttribute(Constantes.INICIO_VALIDADE, inicioValidade);
req.setAttribute(Constantes.FIM_VALIDADE, fimValidade);
req.setAttribute(Constantes.EMISSOR, emissor);
page = "/dadosCertificado.jsp";
}
RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher(page);
dispatcher.forward(req, resp);
}
}