certificação digital : uma nova era de segurança eletrônica
DESCRIPTION
Monografia de Samuel Vasconcellos Serra sobre Certificacao Digital.TRANSCRIPT
1
UNIVERSIDADE TIRADENTES
SAMUEL VASCONCELLOS SERRA
CERTIFICAÇÃO DIGITAL :
UMA NOVA ERA DE SEGURANÇA ELETRÔNICA
ARACAJU 2006
2
SAMUEL VASCONCELLOS SERRA
CERTIFICAÇÃO DIGITAL :
UMA NOVA ERA DE SEGURANÇA ELETRÔNICA
Monografia apresentada a Universidade Tiradentes como um dos pré-requisitos para a obtenção do grau de Bacharel em Sistemas de Informação.
ANDRÉS IGNÁCIO MARTÍNEZ MENÉNDEZ
ARACAJU 2006
3
SAMUEL VASCONCELLOS SERRA
CERTIFICAÇÃO DIGITAL :
UMA NOVA ERA DE SEGURANÇA ELETRÔNICA
Monografia apresentada como exigência parcial para obtenção do grau de Bacharel em Sistemas de Informação à comissão julgadora da Universidade Tiradentes.
Aprovada em ___/___/_____
BANCA EXAMINADORA
_______________________________________________ Andrés Ignácio Martínez Menéndez
Universidade Tiradentes
_______________________________________________ Alex Sandro Mateus Dantas
Universidade Tiradentes
_______________________________________________ Givanildo Santana do Nascimento
Secretaria de Estado da Fazenda de Sergipe
4
Aos meus familiares que sempre
estiveram presentes nesta vitória.
5
AGRADECIMENTOS
A Deus, por me dar forças nos momentos difíceis e fazer com que eu seguisse o
caminho correto para a realização deste trabalho.
Ao amor da minha vida, minha esposa Ivi, por todo carinho, paciência e pela
compreensão nos momentos de ausência, e por está sempre ao meu lado, apoiando
e incentivando.
Ao meu orientador, Andrés Menéndez, pela dedicação e o excelente trabalho de
orientação e pelos conhecimentos passados.
Aos professores da Universidade Tiradentes por toda aprendizagem transmitida e
que fizeram assim contribuir para meu crescimento pessoal e profissional.
Ao amigo Luiz Ricardo pela contribuição e experiência passada neste trabalho.
O meu muito obrigado a todos aqueles que de alguma forma contribuíram e
permitiram que eu atingisse meus objetivos durante este projeto final.
6
SUMÁRIO
LISTA DE FIGURAS ........................................................................................................................................... 8
LISTAGENS DE CÓDIGO .................................................................................................................................. 9
RESUMO ............................................................................................................................................................. 10
ABSTRACT ......................................................................................................................................................... 11
1. INTRODUÇÃO ............................................................................................................................................... 12
2. CRIPTOGRAFIA............................................................................................................................................ 15
2.1 CRIPTOGRAFIA SIMÉTRICA .......................................................................................................................... 16
2.2 CRIPTOGRAFIA ASSIMÉTRICA ...................................................................................................................... 18
3. ASSINATURA DIGITAL............................................................................................................................... 21
3.1 ALGORITMOS CRIPTOGRÁFICOS................................................................................................................... 22
3.2 PROCESSO DE ASSINATURA DIGITAL ........................................................................................................... 24
4. CERTIFICADO DIGITAL ............................................................................................................................ 27
4.1 AUTORIDADES CERTIFICADORAS................................................................................................................. 29
4.1.1 Estrutura Hierárquica da ICP-Brasil ................................................................................................. 30
4.2 MODELOS DE CERTIFICADO DIGITAL........................................................................................................... 32
4.2.1 - Modelos de Armazenamento............................................................................................................. 32
4.2.2 Modelos de Aplicação de Certificado Digital..................................................................................... 36
4.3 RENOVAÇÃO E REVOGAÇÃO DE UM CERTIFICADO....................................................................................... 39
4.4 PROTOCOLO SSL ......................................................................................................................................... 40
4.4.1 Processo de estabelecimento de uma sessão SSL ............................................................................... 42
4.5 REQUISIÇÃO E INSTALAÇÃO DE UM CERTIFICADO DIGITAL ......................................................................... 45
5. TECNOLOGIAS DISPONÍVEIS EM JAVA................................................................................................ 47
6 - ASSINATURA DIGITAL EM ARQUIVOS XML ..................................................................................... 57
6.1 - ESTRUTURA DE UM DOCUMENTO XML..................................................................................................... 57
7
6.2 - SEGURANÇA DE UM DOCUMENTO XML..................................................................................................... 58
6.3 - ELEMENTOS DE UMA ASSINATURA DIGITAL EM XML............................................................................... 61
6.3.1 - Elemento <Signature> ..................................................................................................................... 61
6.3.2 - Elemento <SignedInfo> ................................................................................................................... 61
6.3.3 - Elemento <SignatureValue>............................................................................................................ 63
6.3.4 - Elemento <KeyInfo> ........................................................................................................................ 64
7 - ESTUDO DE CASO....................................................................................................................................... 67
7.1 - DESCRIÇÃO E FUNCIONAMENTO DA APLICAÇÃO ........................................................................................ 67
7.2 - ESTRUTURA DO PROJETO........................................................................................................................... 70
7.3 - CONSIDERAÇÕES GERAIS .......................................................................................................................... 70
8 - CONCLUSÃO ................................................................................................................................................ 72
REFERÊNCIAS BIBLIOGRÁFICAS............................................................................................................... 75
ANEXO I - CLASSES DO PROJETO DO ESTUDO DE CASO ................................................................... 78
ANEXO II - ARQUIVOS DO PROJETO DO ESTUDO DE CASO .............................................................. 93
8
LISTA DE FIGURAS
FIGURA 2.1 - PROCESSO DE CRIPTOGRAFIA EM UM TEXTO ...............................................16
FIGURA 2.2 - ESQUEMA DO PROCESSO DE CRIPTOGRAFIA SIMÉTRICA ...............................17
FIGURA 2.3 - EXEMPLO DE CONFIDENCIALIDADE COM CRIPTOGRAFIA ASSIMÉTRICA ............19
FIGURA 2.4 - EXEMPLO DE AUTENTICIDADE COM CRIPTOGRAFIA ASSIMÉTRICA...................20
FIGURA 3.1 - PROCESSO DE ENVIO DE UM DOCUMENTO ASSINADO DIGITALMENTE .............24
FIGURA 3.2 - PROCESSO DE RECEPÇÃO DE UM DOCUMENTO ASSINADO DIGITALMENTE ......25
FIGURA 3.3 - PROCESSO DE ASSINATURA DIGITAL COM CONFIDENCIALIDADE.....................26
FIGURA 4.1 - MODELO DA ARQUITETURA DA ICP-BRASIL.................................................31
FIGURA 4.2 - DISPOSITIVO SMARTCARD COM CPF DIGITAL.............................................34
FIGURA 4.3 - DISPOSITIVO SMARTCARD COM CNPJ DIGITAL ..........................................34
FIGURA 4.4 - DISPOSITIVO SMARTCARD COM IDENTIDADE DIGITAL ..................................35
FIGURA 4.5 - DISPOSITIVO TOKEN USB.........................................................................35
FIGURA 4.6 - EXEMPLO DE CERTIFICADO DE SERVIDOR WEB ............................................38
FIGURA 4.7 - USO DO PROTOCOLO SSL NO NAVEGADOR INTERNET EXPLORER .................41
FIGURA 4.9 - PROCESSO DE HANDSHAKE POR SSL ........................................................43
FIGURA 5.1 - ARQUITETURA DA JCA..............................................................................48
FIGURA 5.2 - INTERFACE DE EXECUÇÃO DE UM ARQUIVO .CER GERADO PELO KEYTOOL .....51
FIGURA 5.3 - CAMINHO DE CERTIFICAÇÃO DO CERTIFICADO DA FIGURA 17........................51
FIGURA 5.4 - INTERFACE DE EXECUÇÃO DE UM ARQUIVO .CER APÓS A INSTALAÇÃO ...........52
FIGURA 5.5 - CAMINHO DE CERTIFICAÇÃO DO CERTIFICADO DA FIGURA 5.4.......................52
9
FIGURA 5.6 - CAMINHO DE CERTIFICAÇÃO DE UM CERTIFICADO DA CAIXA .........................53
LISTAGENS DE CÓDIGO
LISTAGEM 5.1 - CRIAÇÃO DE UM KEYSTORE COM KEYTOOL ............................................48
LISTAGEM 5.2 - IMPORTAÇÃO DE UM CERTIFICADO X.509 PARA UM KEYSTORE JKS..........50
LISTAGEM 5.3 - EXPORTAÇÃO DE UM CERTIFICADO X.509 DO KEYSTORE JKS .................50
LISTAGEM 5.4 - CLASSES DA API JAVA ..........................................................................53
LISTAGEM 5.5 - MÉTODO DE EXTRAÇÃO DE UMA CHAVE PRIVADA .....................................54
LISTAGEM 5.7 - MÉTODO DE CRIAÇÃO DE UMA ASSINATURA DIGITAL .................................55
LISTAGEM 5.8 - MÉTODO DE VALIDAÇÃO DE UMA ASSINATURA DIGITAL ..............................56
LISTAGEM 6.1 - CÓDIGO FONTE DE UM EXEMPLO DE DOCUMENTO XML ............................58
LISTAGEM 6.2 - ESPECIFICAÇÃO SIMPLIFICADA DE UMA ASSINATURA XML. .......................60
LISTAGEM 6.3 - ELEMENTOS OBRIGATÓRIOS DE UMA ASSINATURA XML............................60
LISTAGEM 6.4 - DEFINIÇÃO DO ESQUEMA DO ELEMENTO <SIGNATURE>............................61
LISTAGEM 6.5 - DEFINIÇÃO DO ESQUEMA DO ELEMENTO <SIGNEDINFO> ..........................62
LISTAGEM 6.6 - DEFINIÇÃO DO ESQUEMA DO ELEMENTO <REFERENCE>...........................63
LISTAGEM 6.7 - DEFINIÇÃO DO ESQUEMA DO ELEMENTO <SIGNATUREVALUE> ..................64
LISTAGEM 6.8 - DEFINIÇÃO DO ESQUEMA DO ELEMENTO <KEYINFO>................................65
10
RESUMO
A cada dia percebe-se um crescimento no número de aplicações que estão sendo
desenvolvidas e disponibilizadas na internet devido às vantagens por ela oferecidas,
e por este motivo as pessoas vêm procurando este meio de comunicação para fazer
publicações, comércio eletrônico e realizar a troca de mensagens e arquivos de
forma mais rápida e eficiente. Com isso, na mesma proporção em que cresce a
disponibilização de aplicações na internet, também aumentam os riscos
relacionados à segurança da informação. Diante destas circunstâncias, este trabalho
demonstra a importância e as principais técnicas das tecnologias de certificado
digital e assinatura digital as quais, juntas e bem aplicadas, garantirão a
autenticidade, a confidencialidade, a integridade e o não repúdio nas informações
transitadas em aplicações desenvolvidas para a Internet. Ainda será mostrado de
forma prática, através de uma aplicação de comércio eletrônico, o uso dos
certificados digitais que fornecem a autenticação do servidor e a autenticação do
cliente. Esta aplicação irá gerar também arquivos XML que através destes
certificados e de um framework específico para assinatura digital em documentos
XML, serão assinados digitalmente e enviados para seus destinos. As mensagens e
arquivos irão trafegar na aplicação dentro de um canal de comunicação único e
seguro entre um cliente e um servidor, que será criado durante a utilização dos
protocolos de segurança, SSL e HTTPS, exibidos na aplicação após ser incorporado
um certificado digital de servidor web. Desta forma, será de fácil conhecimento e de
conscientização do público, principalmente leigo, a necessidade e as situações
relevantes de uso da tecnologia de certificação digital.
11
PALAVRAS-CHAVE: Segurança; Certificado Digital; Assinatura Digital; XML
ABSTRACT
Every day a growth in the number of applications is perceived that are being
developed and available in the Internet due its offered advantages, and because of it
people come looking this media to make publications, electronic commerce and to
carry through the exchange of messages and archives of faster and efficient form.
With this, in the same ratio where the availability of applications in the Internet grows,
also they increase the related risks large-scale with the security of the information.
Ahead of these circumstances, this work demonstrates to the importance and the
main techniques of the technologies of digital certificate and digital signature, where
together and applied well they will guarantee the authenticity, the confidentiality, the
integrity and not the repudiation in the information transited in applications developed
for the Internet. Still it will be shown of practical form, through a developed
application of electronic commerce, the use of the digital certificates that supply to
the authentication of the server and the authentication of the customer. This
application will go to also generate archives XML that through these certificates and
one framework specific for digital signature in documents XML, will be signed digitally
and envoyed for its destinations. The messages and archives will go to pass through
in the application inside of a safe communication channel only e between a customer
and a server, who will be created during the use of the protocols of security, SSL and
HTTPS, shown in the application after to be incorporated a digital certificate of server
web. In this way, it will be easy known and awareness of the public, mainly strangers,
the necessity and the excellent situations of use of the technology of digital
certification.
12
Key-words : Security; Digital Certificate ; Digital Signature; XML
1. INTRODUÇÃO
Com o surgimento da internet as pessoas passaram a vivenciar um novo
paradigma e começaram a executar procedimentos de forma automática, rápida e
com maior qualidade. Procedimentos como, de troca de mensagens, de
armazenamento de dados, pesquisa e acesso às informações de diversas
naturezas, movimentação de compras e vendas através do comércio eletrônico e
troca de informações confidenciais entre empresas.
Na mesma proporção que a internet vem trazendo facilidade para as
pessoas, também traz risco e insegurança, este é o preço que deve ser pago pelo
conforto, agilidade, eficiência e economia gerada que ela proporciona [1].
Para garantir a confiança no mundo digital, tecnologias de segurança da
informação vêm sendo desenvolvidas e adotadas para o uso seguro na Internet de
documentos digitais e de transações eletrônicas.
Novas tecnologias como o certificado digital e a assinatura digital estão a
cada dia sendo mais utilizadas para garantir a segurança e a confiança digital na
Internet. A idéia é que a mesma segurança e confiança dada no mundo
convencional (o do papel) para manipulação dos processos burocráticos também
seja dada no mundo digital [2].
O certificado digital é um documento eletrônico que, associado a uma
assinatura digital, garante autenticidade, confidencialidade e integridade dos dados,
ou seja, é uma identidade digital que dá a permissão de acesso e a segurança às
informações disponibilizadas em serviços on-line [3].
Para que o certificado digital tenha validade jurídica ele tem que ser
emitido por uma autoridade certificadora, pois é ela quem dará uma identidade
digital a uma pessoa ou a uma empresa e determinará as políticas e os
procedimentos de orientação de uso dos certificados.
13
Com os certificados digitais é possível criptografar e assinar informações
digitais de modo que as pessoas sem autorização não acessem e nem modifiquem o
conteúdo de uma informação.
Atualmente o certificado digital é o meio mais seguro de identificar as
partes envolvidas em uma comunicação, isto porque apenas os logins e as senhas
tradicionalmente utilizados não garantem uma identificação segura de acesso
exclusivo devido a necessidade de compartilhamento dos mesmos.
Para estabelecer um canal de comunicação seguro entre navegadores
Web e servidores é utilizado, junto com os certificados digitais, o protocolo SSL
(Secure Sockets Layer) que garantirá a autenticação, privacidade da mensagem e a
integridade da mensagem, eliminando assim a possibilidade das mensagens serem
interceptadas ou visualizadas sem autorização [4].
Diante de toda uma pesquisa e estudo realizado, este projeto deverá
mostrar a importância na utilização dos certificados digitais para pessoas físicas e
jurídicas nos dias atuais, e também mostrar a segurança existente no uso da
assinatura digital quando aplicada em documentos confidenciais que deverão ser
assinados, garantindo assim através de técnicas de criptografia a total proteção e
sigilo das informações a serem enviadas a um destinatário.
No segundo capítulo serão mostrados, os conceitos, os tipos de
criptografia simétrica e assimétrica, vantagens e desvantagens de cada uma delas.
Em seguida, o terceiro capítulo explicará a importância e o processo de assinatura
digital em mensagens e arquivos, e ainda os principais algoritmos criptográficos
utilizados atualmente neste processo.
No quarto capítulo será conceituada e explicada a tecnologia de
certificado digital, o que são autoridades certificadoras e como está formada a
estrutura hierárquica da infra-estrutura de chave pública no Brasil e a relevância
destas autoridades para os certificados digitais. Neste capítulo serão também
mostrados os principais modelos de armazenamento e de aplicações de certificados
digitais, como é feita a renovação e revogação de um certificado, a importância do
protocolo SSL e os passos de como é criada uma sessão SSL no processo de
certificação digital e, de forma breve, será explicado de como é feita a requisição e a
instalação de um certificado digital através de uma autoridade certificadora.
No quinto capítulo, serão mostradas as tecnologias disponíveis na
Plataforma Java para assinatura digital de mensagens e arquivos utilizando padrões
14
de certificados digitais. No sexto capítulo, será explicado a assinatura digital em
arquivos XML (Extensible Markup Language) e os principais elementos de uma
especificação existente para este fim.
E no sexto capítulo será mostrado de forma prática, através de uma
aplicação desenvolvida de um estudo caso de comércio eletrônico, o uso dos
certificados digitais que fornecem a autenticação do servidor e a autenticação do
cliente. Esta aplicação irá gerar também arquivos XML que, através destes
certificados e de um framework específico para assinatura digital em documentos
XML, serão assinados digitalmente e enviados aos seus destinos para que nestes
sejam feitas às devidas validações utilizando as técnicas que envolvem assinatura
digital e certificado digital a serem demonstradas no decorrer deste documento.
15
2. CRIPTOGRAFIA
A importância da segurança da informação no mundo digital vem
aumentando a cada dia e, a depender da necessidade de sigilo, deve-se conhecer o
meio pelo qual a informação será transitada e para quem ela será enviada. Com
isso, técnicas de segurança são aplicadas para se garantir a confidencialidade de
uma informação, dentre elas a criptografia.
A criptografia surgiu da junção das palavras gregas Kryptós (Cripto), que
significa esconder/ocultar e Grápho (Grafia) de escrita. A criptografia pode ser
conceituada como o processo de codificação da informação para que apenas o
emissor e o receptor possam acessá-la, evitando assim que uma pessoa não
autorizada tenha acesso ao seu conteúdo.
Os primeiros métodos de criptografia eram feitos utilizando sempre o
mesmo algoritmo de codificação, com isso bastava que o receptor da informação
tivesse conhecimento desse algoritmo para poder interpretá-la. Mas havia um
problema: caso um emissor fosse enviar uma informação sigilosa para uma outra
pessoa, corria o risco de uma pessoa sem autorização decifrá-la, já que ela também
tinha o mesmo algoritmo que decifrava informações vindas deste emissor [11].
Para resolver este problema foram criadas as chaves criptográficas, o
emissor poderia usar o mesmo algoritmo para diversos receptores de uma
informação, para isto bastava que cada receptor utilizasse uma chave diferente. Se
a chave fosse perdida ou roubada, era apenas necessário trocá-la e o mesmo
algoritmo era mantido. Sendo assim, para conseguir decifrar e ler a informação, a
chave do receptor deverá ser compatível com a chave do emissor.
A chave de criptografia é um número utilizado em um determinado
algoritmo de criptografia que, quanto maior seu tamanho, maior será o número de
combinações e mais segura será a criptografia. Quando se fala, por exemplo, de
uma chave de 8 bits, significa dizer que 256 chaves poderão ser usadas para
criptografar e descriptografar uma informação. Este cálculo é feito com a fórmula de
16
2 elevado a n, onde n é quantidade de bits. Uma chave de 8 bits não garante muita
segurança, pois qualquer pessoa pode gerar 256 chaves e ficar tentando descobrir
qual delas foi utilizada no algoritmo de criptografia. Para garantir uma maior
segurança, devem ser utilizadas chaves maiores. Se no algoritmo for usada uma
chave de 128 bits, teremos uma quantidade grande de combinações possíveis para
descobrir a chave e isto garantirá uma maior segurança na criptografia da
informação [11].
A criptografia não garante que uma informação não possa ser interceptada
ao ser enviada a um destinatário, mas garante que quem interceptou não possa
decifrar o seu conteúdo ou então que o custo de quebrar a criptografia seja maior do
que o benefício trazido no acesso da informação secreta [3].
A figura 2.1 mostra o processo de criptografia de um texto, no qual a partir
de um texto claro, também conhecido como texto plano, se aplica o algoritmo
criptográfico e gera um texto cifrado.
Figura 2.1 - Processo de criptografia em um texto
Fonte : http://www.iconenet.com.br/cd/cd_guia.pdf
2.1 Criptografia Simétrica
Existem dois tipos de criptografia: simétrica e assimétrica. A criptografia
simétrica utiliza a mesma chave para cifrar e decifrar informação, a chave secreta
deve ser compartilhada entre as partes envolvidas neste processo de cifragem e
decifragem de informação.
O emissor e o receptor da mensagem devem conhecer esta chave secreta
e, com ela, apenas ambas as partes poderão trocar informações de forma
17
confidencial. Isto impede que pessoas que não tenham autorização acessem o
conteúdo da mensagem transitada.
A figura 2.2 mostra como funciona o processo de criptografia simétrica.
Inicialmente, um determinado emissor, utilizando um algoritmo de criptografia e de
posse da chave secreta, criptografa a mensagem. Em seguida o receptor, que irá ler
a mensagem que está cifrada, aplica o mesmo algoritmo e a mesma chave secreta
utilizados pelo emissor para fazer a descriptografia da mensagem e obter a
mensagem em original.
Figura 2.2 - Esquema do processo de criptografia simétrica
Fonte : http://www.acate.com.br/kit_imprensa/artigo_certificacao_digital.pdf
Se a chave secreta utilizada no algoritmo de criptografia precisar ser
substituída por outra, seja por motivo de perda, de roubo de chave ou para aumentar
a segurança, o responsável pela modificação da chave terá que enviar esta nova
chave para todas as pessoas com quem já se comunicava com a chave antiga, isto
para que nas próximas vezes que os receptores receberem as informações possam
decifrá-las utilizando esta nova chave.
Diante desta situação, percebe-se que o principal problema da criptografia
simétrica é o compartilhamento da chave secreta que deve ser feito entre as partes
que precisem se comunicar. Por isso, deve-se utilizar um meio seguro ou adotar
uma política de segurança para o envio desta chave única entre ambas as partes
[10]. Caso não exista tal segurança, um intruso ou uma terceira pessoa poderá
capturar a mensagem, e em uma situação extrema, porém possível, descobrir a
18
chave secreta e o algoritmo utilizado e neste caso conseguirá decifrar o conteúdo da
mensagem e ter acesso às informações.
Um outro problema percebido da criptografia simétrica está na distribuição
das chaves, pois, sempre que mais uma pessoa precise ler um documento através
deste tipo de criptografia, precisa também receber esta chave para ser utilizada no
algoritmo de criptografia e ter acesso ao conteúdo da informação [10].
A criptografia simétrica é bem aplicada se o objetivo de uma aplicação é
apenas criptografar dados em ambiente local, ou seja, os dados que deverão ser
armazenados de forma segura não serão enviados para ninguém [3]. Por exemplo,
poderia utilizar a criptografia simétrica para criptografar informações que fossem
manipuladas e salvas fisicamente através de programas clientes, onde estas
informações não fossem trafegadas por uma rede.
2.2 Criptografia Assimétrica
A criptografia assimétrica é também chamada de criptografia de chave
pública. Este tipo de criptografia utiliza um par de chaves que são geradas e
relacionadas entre si. Uma chave é chamada de chave pública e outra de chave
privada. A chave pública, como o nome já diz, pode ser do conhecimento de todos,
mas a chave privada apenas deve pertencer ao dono da chave. Os algoritmos de
criptografia de chave pública garantem a confidencialidade e a autenticidade das
informações [4].
Se o emissor quiser enviar uma informação de forma sigilosa, ele deverá
utilizar a chave pública do receptor para cifrar a informação. Para isto, o receptor
deverá disponibilizar sua chave pública em diretórios públicos acessados pela
Internet [4].
O exemplo da figura 2.3 mostra como uma pessoa pode enviar uma
informação sigilosa onde apenas Beto poderá acessá-la, para isso esta pessoa
deverá utilizar a chave pública de Beto para cifrar a informação e enviá-la. Desta
forma, somente Beto poderá descriptograr a mensagem e recuperar as informações
19
originais, pois somente ele possui a chave privada correspondente à chave pública
que foi cifrada a mensagem, desta forma é mantida a confidencialidade da
informação.
Figura 2.3 - Exemplo de confidencialidade com criptografia assimétrica
Fonte : http://www.iti.br/twiki/pub/Main/Cartilhas/brochura01.pdf
A autenticidade da informação é feita no sentido contrário ao da
confidencialidade. O emissor utiliza sua chave privada para cifrar a informação para
que se garanta a autoria desta informação ou a identificação em uma determinada
transação. Esta garantia é feita pelo motivo de que a chave privada é de posse única
deste emissor [4].
No exemplo da figura 2.4, Alice quer enviar para Beto uma informação
que garantirá a autenticidade da informação. Para isso Alice utiliza a sua chave
privada para cifrar a informação e enviá-la para Beto. Desta forma, Beto poderá
descriptograr a mensagem e recuperar as informações originais, pois ele possui a
chave pública de Alice correspondente à chave privada que foi cifrada a mensagem.
Qualquer pessoa poderá decifrar a informação enviada por Alice, para
isso basta conhecer a chave pública dela. Desta forma é mantida a autenticidade da
informação, uma vez que o processo de cifrar o texto com a chave privada foi feito
apenas por Alice.
20
Figura 2.4 - Exemplo de autenticidade com criptografia assimétrica
Fonte : http://www.iti.br/twiki/pub/Main/Cartilhas/brochura01.pdf
O algoritmo de chave pública garante que mensagens cifradas com a
chave pública só serão acessíveis com a chave privativa e mensagens cifradas com
a chave privativa só serão acessíveis com a chave pública [3].
Devido a seu sistema de geração de par de chaves em cada parte da
comunicação, acaba-se com os problemas de compartilhamento de chave única e
de distribuição de chaves, uma vez que a chave pública poderá ser disponibilizada
na internet e a chave privada será do conhecimento apenas do dono da chave e não
deverá ser divulgada a ninguém.
As técnicas de cifragem de informação utilizando o conceito de chaves
públicas garantem a confidencialidade e a autenticidade no conteúdo da informação,
e para garantir também a integridade dos dados e a não repudiação da mensagem,
outra técnica de segurança chamada de assinatura digital deverá ser aplicada, e
este assunto será abordado no próximo capítulo.
21
3. ASSINATURA DIGITAL
O uso de assinatura em documentos está sempre presente na vida das
pessoas. Um documento é assinado para que o responsável pela assinatura garanta
a sua autenticidade e sua responsabilidade sobre o mesmo. No mundo tradicional,
utilizando o papel, a identificação de uma assinatura pode ser feita através da
assinatura de punho ou da impressão digital de um dos dedos que é mais utilizada
por pessoas que não conseguem assinar seu próprio nome.
É importante deixar claro que uma assinatura digital não é igual a uma
assinatura digitalizada e nem a assinatura eletrônica. A assinatura digitalizada é
quando uma pessoa assina manualmente em um papel e com o auxilio de um
aparelho, chamado scanner, a imagem da assinatura no papel é passada para o
computador, depois a imagem contendo a assinatura é incluída a documentos que
serão enviados aos destinatários. Já a assinatura eletrônica é uma senha utilizada
por exemplo por clientes de bancos que, ao ser informada através de um teclado
virtual, permite que sejam feitas transações específicas como, pagamentos de
contas e transferências. Este tipo de assinatura é apenas uma senha adicional para
acesso de serviços específicos e que precisam de uma segurança maior.
Já a assinatura digital é utilizada para assinar documentos eletrônicos que
deverão ser enviados com segurança aos seus destinatários. Nela também serão
utilizados os conceitos de criptografia de chave privada e pública, e se forem usados
algoritmos assimétricos mais modernos para geração deste par de chaves, será
praticamente impossível descobrir a chave privada a partir da chave pública.
Através da assinatura digital é possível garantir:
• A autenticidade, ou seja, a identidade de quem está enviando o
documento assinado, isto através do uso da chave privada única do
emissor do documento;
• Integridade dos dados, ou seja, que o conteúdo da informação
contida em um documento não seja alterado e chegue íntegro ao
seu destino. Isto é feito a partir de um processo de geração de um
resumo das informações contidas no documento que será único
para cada documento diferente, ou seja, com este resumo é
22
possível checar se o documento foi alterado ao chegar ao seu
destino;
• A não-repudiação do documento, ou seja, uma vez o documento
assinado digitalmente o emissor/receptor não poderá recusar
dizendo que não foi ele quem enviou ou recebeu o documento. Isto
pelo motivo de que apenas uma chave privada poderá ter gerada
aquela assinatura digital.
3.1 Algoritmos Criptográficos
Os algoritmos criptográficos são algoritmos que implementam os métodos
necessários de criptografia para se obter autenticidade, confidencialidade e
integridade de uma determinada informação. Diante de toda uma questão de
segurança, deve-se sempre analisar a validade do algoritmo de criptografia que será
aplicado em um determinado processo, de forma que se tenha conhecimento de que
se ele já está ultrapassado ou se alguém já conseguiu quebrar sua proteção.
A seguir serão mostrados os algoritmos de criptografia mais utilizados nos
dias de hoje e que são aplicados no processo de assinatura digital.
• RSA: Possui este nome por causa dos nomes dos seus inventores,
Ron Rivest Adi Shamir e Len Adleman, e foi criado em 1977. Este é
um algoritmo assimétrico ou de chave pública mais utilizado
atualmente, por ser considerado um dos mais poderosos algoritmos
de criptografia até o momento e por isso é usado na geração de
assinatura digital. Atualmente, os tamanhos das chaves de
segurança mais utilizados em algoritmos do tipo RSA são de 1024
bits e de 2048 bits, os quais, de acordo com os estudos realizados
por cientistas, garantirão segurança nos próximos anos. Antes do
RSA era utilizado o algoritmo assimétrico DSA (Digital Signature
Algorithm), mas devido a uma falha de segurança encontrada foi
considerado fraco e perigoso. Mesmo assim o DSA ainda é
utilizado em situações que não exigem um alto nível de segurança;
23
• MD5: A sigla MD significa Message Digest (resumo da mensagem)
e 5 por ser uma versão mais nova do seu antecessor, o MD4, que
foi publicado em 1991. Este é um algoritmo que utiliza uma função
de hashing, que a partir de um texto informado e através de um
complexo algoritmo matemático, gera um valor hash, que é um
resumo do texto ou uma seqüência de bytes única que identifica
este texto [12]. Esta função de resumo é unidirecional, ou seja, uma
vez ela criada não será mais possível recuperar o documento
original a partir deste resumo. Este algoritmo foi projetado para ser
rápido, simples e seguro e ele produz um valor hash de 128 bits.
Apesar de que foi descoberta uma fraqueza neste algoritmo, ele
ainda é considerado bastante seguro e bem usado ainda nos
sistemas computacionais [6];
• SHA1 – A sigla SHA significa Secure Hash Algorithm (Algorítmo de
Resumo Seguro) e 1 por ser uma revisão do SHA, ele foi publicado
em 1994. Este é um algoritmo também de hashing com o do MD5.
Neste algoritmo é eliminada a fraqueza que existia em uma parte
do MD5. Com isso se torna mais seguro do que o MD5. E, para
garantir uma segurança maior, o valor de hash gerado no SHA1 é
de 160 bits [6]. Este valor de 160 bits é o original do SHA1, que já
é um algoritmo muito rápido e seguro, mas poderá ser estendido
para 256 e 512 bits para ocasiões que venham precisar de uma
segurança ainda maior.
Os algoritmos assimétricos não são utilizados por completo no processo
de assinatura digital por serem lentos. Se fosse utilizá-los para cifrar e decifrar os
documentos eletrônicos causaria uma demora muito grande e, a depender do
tamanho do documento, o tempo ainda seria maior, isto porque estes algoritmos
criptografam todo o conteúdo do documento.
É por isso que a melhor solução é o uso de algoritmos de hashing como o
MD5 e o SHA1, que geram apenas um resumo da mensagem, oferecendo assim
agilidade e integridade no documento [6]. Os algoritmos assimétricos são utilizados
no processo de assinatura digital apenas para cifrar e decifrar o resumo gerado pela
função de hashing, garantindo assim autenticidade e confidencialidade no
documento assinado.
24
Atualmente, o algoritmo assimétrico e o algoritmo de hash que são mais
utilizados no processo de assinatura digital são o RSA e o SHA1, devido às
seguranças oferecidas.
3.2 Processo de Assinatura Digital
Para deixar claro o processo de assinatura digital em um documento
eletrônico será mostrado passo a passo, desde o momento em que o emissor
recebe o par de chaves, a pública e a privada, e utiliza as técnicas específicas da
assinatura digital, até a recepção do mesmo por um determinado destinatário.
A figura 3.1 mostra inicialmente o usuário A de posse do documento
original utilizando um algoritmo de hashing para gerar um resumo deste documento.
Em seguida este resumo será cifrado com a sua chave privada e com isso o emissor
estará gerando a sua assinatura digital. Em seguida essa assinatura será anexada
ao documento original, gerando um documento assinado e este será enviado ao
destinatário [1].
Figura 3.1 - Processo de envio de um documento assinado digitalmente
Fonte : http://www.iconenet.com.br/cd/cd_guia.pdf
25
A figura 3.2 demonstra como é feita a recepção de um documento
assinado digitalmente pelo usuário A. Inicialmente, o receptor (usuário B), recebe o
documento original mais a assinatura digital e aplica o mesmo algoritmo de hash
utilizado pelo Usuário A no documento original recebido, com isso ele terá o resumo
deste documento. Em seguida, a assinatura digital que veio anexa ao documento é
decifrada com a chave pública do emissor (usuário A), e com isso é recuperado o
resumo do documento gerado pelo o usuário A [1]. A autenticidade do documento
será garantida se a decifragem da assinatura digital for feita com sucesso, isto
porque a decifragem utilizou a chave pública correspondente à chave privada do
usuário A, que garante que foi ele mesmo que enviou o documento assinado.
De posse do resumo do documento gerado pelo o usuário A, o usuário B
compara o seu resumo com o resumo do usuário A. Se os dois resumos forem
diferentes é porque documento original foi modificado ou outra pessoa assinou o
documento, do contrário, o documento estará íntegro. A comparação dos resumos
garantirá a integridade de um documento ou de uma mensagem.
Figura 3.2 - Processo de recepção de um documento assinado digitalmente
Fonte : http://www.iconenet.com.br/cd/cd_guia.pdf
26
O processo de assinatura digital não garante a confidencialidade de um
documento ou de uma mensagem, pois um intruso poderá utilizar a chave pública de
um emissor e capturar a informação. A figura 3.3 mostra como garantir a
confidencialidade com assinatura digital, o processo de gerar a assinatura digital é
idêntico ao já explicado, o que é feito a mais é criptografar o documento assinado do
usuário A com a chave pública do usuário B [6].
Em seguida, na recepção do documento, só o usuário B terá acesso ao
conteúdo do documento devido que apenas ele tem a chave privada correspondente
a sua chave pública disponível, isto garantirá a privacidade no documento. Com
isso, além da autenticidade, integridade e o não repúdio já obtidos pelo processo
normal de assinatura digital, teremos também, agora, a confidencialidade de uma
mensagem ou de um documento assinado digitalmente por uma determinada
pessoa.
Figura 3.3 - Processo de assinatura digital com confidencialidade
ASSINATURA DIGITAL COM CONFIDENCIALIDADE
Usuário A (Emissor)
Documento Algoritmo Original Hashing Resumo da Mensagem Chave Privada Assinatura Documento do Usuário A Digital Assinado Chave Pública do usuário B
YW2U85P398YGH7A
Usuário B (Receptor)
Chave Privada Algoritmo Resumo da Mensagem do usuário B Hashing Documento Original COMPARA Documento Assinado Assinatura Digital Resumo da Mensagem Chave Pública
do usuário A
YW2U85P398YGH7A
YW2U85P398YGH7A
27
4. CERTIFICADO DIGITAL
O certificado digital é um documento eletrônico e uma tecnologia de
segurança que serve para identificar pessoas e entidades no mundo digital. Um
certificado digital é associado a um nome e a vários outros atributos de uma pessoa
ou instituição a uma chave criptográfica�pública. O certificado digital é considerado
como uma identidade digital no mundo computacional.
Esta tecnologia usa técnicas de criptografia assimétrica que utiliza um par
de chaves eletrônico, uma chave privada e uma pública. A chave privada ou a
chave secreta terá uma senha para acessá-la e que deve ser de posse apenas do
dono do certificado que irá utilizá-la para assinar mensagens e documentos
eletrônicos e a chave pública será utilizada por todos que irão se comunicar de
forma sigilosa com o dono do certificado, seja uma pessoa física ou jurídica.
Ao utilizar uma chave pública, uma entidade precisa ter a garantia de que
esta chave pertence realmente à entidade que irá se comunicar e que possui a
chave privada correspondente. Isto porque qualquer entidade pode gerar um par de
chaves relacionadas e deixar pública uma delas [13]. No entanto, um emissor de
uma mensagem precisa saber se a chave pública que está utilizando para assinar
uma mensagem ou um documento é realmente de quem se diz dono e isto faz
eliminar a possibilidade de usar a chave pública disponibilizada por uma pessoa não
autorizada ao acesso da informação.
Somente a assinatura digital aplicada em mensagens e documentos
eletrônicos não garante de forma segura a autenticidade, a integridade e o não
repúdio, mas quando utilizada através de um canal seguro de comunicação criado
no uso de um certificado digital estes serão efetivamente garantidos.
Estas propriedades de segurança citadas acima serão completamente
garantidas se no processo de comunicação realizado entre duas entidades, ambas
as partes possuam certificados digitais. Estes certificados deverão estar assinados e
registrados por uma autoridade confiável que é chamada de autoridade certificadora,
como veremos no item 4.1.
Com o certificado digital é ainda possível garantir a confidencialidade que
antes com a assinatura digital só poderia ser feita aplicando na assinatura a
28
criptografia com a chave pública do destinatário, e que mesmo assim não garantia
uma total segurança devido à inexistência de um canal de comunicação seguro.
Para garantir a confidencialidade de uma informação utilizando certificado
digital, uma pessoa usará o certificado do destinatário para utilizar a chave pública
deste certificado para criptografar a informação e enviá-la. Em seguida, quando o
destinatário, dono do certificado, receber esta informação com o seu conteúdo
cifrado terá que usar a sua chave privada, pois só ele poderá decifrar o conteúdo já
que somente ele terá acesso à chave privada correspondente a chave pública [5].
A assinatura digital associada a um certificado dará uma total credibilidade
e confiança devido ao canal único e seguro de comunicação criado durante a troca
de mensagens e documentos, esta segurança será possível através do protocolo
SSL (Secure Sockets Layer) de cifragem de 128 bits, que é a mais moderna
tecnologia de criptografia aplicada durante uma comunicação na internet e que será
abordada mais adiante.
Diante desta situação, se faz necessário e percebe-se a importância de
utilizar um certificado digital em aplicativos de softwares. Este certificado será
emitido e assinado por uma autoridade confiável e esta disponibilizará ao
proprietário, através deste certificado, o par de chaves. O proprietário, de posse do
seu certificado, poderá utilizar seu par de chaves de forma confiável, seja para
assinar mensagens e documentos, através do processo de assinatura digital, ou
para disponibilizar a sua chave pública para aqueles que desejam enviar
informações sigilosas (autenticação do cliente).
O uso de um certificado assinado por uma autoridade certificadora dará ao
seu proprietário validade jurídica em suas transações eletrônicas, considerando
também que assinatura digital utilizada nestas transações terá a mesma validade
jurídica de uma assinatura feita no papel.
Existem padrões de certificados digitais, o predominante atualmente é o
X.509, que já se encontra na versão 3.
Os campos existentes em um certificado padrão X.509 são:
• Número da versão – representa o número da versão do certificado
que atualmente é a 3;
• Número de série – este campo fornece uma identificação única para
cada certificado emitido por uma autoridade certificadora e esta deve garantir
que não existam dois certificados com o mesmo número de série;
29
• Algoritmo de Assinatura – representa o algoritmo de hash utilizado
na assinatura. O resumo da mensagem criado por uma função hash, MD5 ou
SHA1 que são os mais conhecidos, é cifrado com a chave privada para gerar
a assinatura;
• Nome – indica o nome do proprietário do certificado;
• Nome do Emissor – representa o nome da autoridade certificadora
emissora do certificado;
• Período de Validade – determina o intervalo de tempo em que o
certificado é válido;
• Chave Pública – este campo possui a chave pública e a identificação
do algoritmo do certificado. Esta chave é geralmente gerada utilizando
algoritmo de criptografia assimétrico de chave pública RSA;
• Assinatura Digital da CA – este campo indica a assinatura digital da
autoridade certificadora que emitiu o certificado.
4.1 Autoridades Certificadoras
Da mesma forma que temos confiança em órgãos que emitem
documentos pessoais que possuem validade jurídica como, por exemplo, uma
carteira de identidade e um CPF, devemos também confiar em entidades que façam
a emissão de certificados digitais para que tenhamos garantia, credibilidade e
segurança na obtenção dos mesmos. Estas entidades confiáveis são chamadas de
autoridades certificadoras (AC).
Os certificados digitais são gerenciados através de uma PKI (Public Key
Infrastrusture) ou ICP (Infra-estrutura de chave pública) que é um ambiente a ser
criado pelas autoridades certificadoras e que é composto por técnicas, práticas e
procedimentos necessários para operar um sistema de certificação baseado em
criptografia de chave pública de forma confiável e segura [14].
Além de montar uma estrutura de segurança e de confiabilidade na
emissão de certificados digitais, uma ICP deve contar ainda com leis e decretos
elaborados pelo governo federal para dar a legalidade no negócio digital,
30
possibilitando assim fazer o uso da Internet para realizar transações com
informações sigilosas entre pessoas físicas e jurídicas, principalmente as que
movimentam dados financeiros.
Diante da importância de ser ter uma ICP no Brasil para regularizar a
certificação digital, o governo brasileiro criou através da medida provisória - MP
2200-2, de 24 de agosto de 2001, uma estrutura hierárquica denominada ICP –
Brasil que define as devidas responsabilidades de cada entidade desta estrutura [1].
4.1.1 Estrutura Hierárquica da ICP-Brasil
Abaixo, a figura 4.1 mostra a arquitetura da ICP-Brasil, onde temos:
• O comitê gestor que foi criado para estabelecer os procedimentos e as
regras que serão adotadas pelas autoridades certificadoras e que caso
não sejam cumpridas poderão perder o credenciamento e não fazer
mais parte da ICP-Brasil;
• A autoridade certificadora raiz que auto-assina seu certificado e está
no topo da hierarquia e quem gerencia é o Instituto Nacional de
Tecnologia da Informação (ITI). A AC raiz tem como funções: assinar,
emitir, distribuir, revogar, gerenciar os certificados de autoridades
certificadoras de nível inferior ao seu, dando o direito a estas
autoridades de assinarem os certificados finais, ou seja, os certificados
dos usuários. Deve também gerenciar a lista dos certificados emitidos,
revogados e vencidos, fazer a fiscalização e auditoria das autoridades
certificadoras, autoridades de registros e prestadores de serviços
habilitados na ICP-Brasil. A AC raiz não emite certificados para o
usuário final e nem possui uma autoridade de registro associada, pois
ela mesma faz este papel [16];
• As autoridades certificadoras que poderão ser entidades privadas ou
públicas e tem como principal função emitir certificados digitais
associando a uma chave pública do seu proprietário, após ter feito o
credenciamento com a AC raiz. Elas têm ainda autorização para
31
assinar, emitir, distribuir, revogar e gerenciar certificados das
autoridades intermediárias e usuários finais. Estas ACs devem também
divulgar aos usuários as listas de certificados revogados e manter
registros de suas operações [1]. Atualmente são oito as autoridades
certificadoras credenciadas pela ICP-Brasil, são elas: SERPRO, Caixa
Econômica Federal, SERASA, Receita Federal, Certisign, Presidência
da República e Autoridade certificadora da Justiça;
• As autoridades de registros que são autoridades associadas às
autoridades certificadoras e têm com funções: identificar e cadastrar
usuários, de forma presencial, encaminhar solicitações de certificados
para as ACs e deve também armazenar os registros das suas
operações [1].
Figura 4.1 - Modelo da arquitetura da ICP-Brasil
Fonte : http://www.iconenet.com.br/cd/cd_guia.pdf
O custo para uma entidade que deseja se credenciar à ICP-Brasil é alto e
a depender dos privilégios de credenciamento o custo ainda será maior. Poderão se
credenciar nos níveis subseqüentes a autoridade certificadora raiz, como as
autoridades certificadoras, autoridades intermediárias, autoridades de registros e
prestadores de serviço de suporte a ICP-Brasil.
32
Além deste custo alto de credenciamento, a entidade também deverá
investir, às vezes, até milhões, em hardware, software e infra-estrutura de rede e
ainda a entidade passará por um processo de auditoria prévia para análise da sala
cofre, verificação do ambiente físico, a rede de dados, a infra-estrutura, o ambiente
de softwares instalados e configurações dos mesmos e ainda deverá ser avaliada a
capacitação técnica e a segurança existente no ambiente de trabalho [16].
Na internet existem softwares de autoridade certificadora que podem ser
instalados em empresas para a emissão de certificados que poderão ser viáveis
para uso interno ou seja, quando estas não fazem transações on-line com outras
entidades. Porém, é importante analisar o custo benefício antes de serem utilizados,
pois se é para utilizar um sistema de certificação digital seguro e que tenha
legalidade, esta deverá ser adquirida através de autoridades certificadoras que
fazem parte da ICP-Brasil.
4.2 Modelos de Certificado Digital
Para um melhor entendimento quanto aos modelos existentes de
certificado digital, serão mostrados a seguir duas categorias. A primeira categoria é
relacionada quanto aos modelos de armazenamento e a segunda com relação aos
modelos de aplicações de certificado digital.
4.2.1 - Modelos de Armazenamento
Atualmente, os dois certificados mais comuns são o A1 e o A3. O A1 é um
certificado de software que é instalado no computador e seus dados serão
armazenados na memória do computador, a sua validade será de um ano contado a
partir da data de emissão do certificado.
Este tipo de certificado possibilita que seus dados, inclusive sua chave
privada, sejam exportados para que ele seja distribuído em outros computadores
33
que o proprietário deseja utilizá-lo, com isso ele estará assumindo os riscos da
distribuição do seu certificado. A sua cópia também será útil para no caso de
formatação de máquina ou reinstalação do sistema operacional para que o
certificado possa ser reinstalado. A chave pública por sua vez estará disponível na
internet e a chave privada apenas no computador onde foi instalado o certificado [9].
É importante que o software de geração de par de chaves ofereça
proteção para acessar a chave privada através de senha, para que caso ocorra
perda ou roubo da chave privada esta esteja cifrada, seja no A1 em caso de cópia
do certificado que contém a chave privada ou no A3 se alguém perder ou for
roubado o dispositivo que contém o certificado com a chave privada armazenada [4].
Já o A3 é um tipo de certificado armazenado em um hardware
criptográfico como o SmartCard, que são cartões inteligentes e são parecidos com
cartões de créditos tradicionais ou através de um Token USB. Neste tipo de
certificado os dados serão armazenados em um dispositivo, por isso é mais seguro
do que o A1, e a sua validade é de até 3 anos [8].
O A3 é um tipo de certificado mais seguro pelo motivo de que o par de
chaves gerado, a chave pública e a privada, será gravado apenas no dispositivo e
não poderá ser exportado e nem ser retirado. Apenas a chave pública será
disponibilizada e a chave privada estará armazenada no dispositivo e para ser
acessada deverá estar protegida por senha. Com isso torna-se obrigatória a
presença do dispositivo para realização da assinatura digital em documentos para
permitir o acesso a sistemas e ainda para dar autorização de transações eletrônicas
[9].
A senha de proteção da chave privada, em ambos os tipos de certificados,
não pode ser compartilhada, pois ela será utilizada apenas pelo proprietário do
certificado e deve-se ter cuidado para não deixar cair nas mãos de pessoas não
autorizadas. Por este motivo, não se deve também instalar certificados com a chave
privada em computadores de uso público, para que pessoas mal intencionadas não
façam um mau uso do certificado fazendo se passar de proprietário do mesmo.
Abaixo serão mostradas figuras de certificados do tipo A3 armazenados
em dispositivos de hardware criptográfico do tipo SmartCard que com eles será
possível gerar as chaves criptográficas e armazená-las dentro de um ambiente
seguro, uma vez que as operações criptográficas serão feitas dentro do próprio
dispositivo. Eles possuem um microprocessador com memória capaz de armazenar
34
e processar diversas informações. Estes cartões são lidos através de um dispositivo,
chamado leitora, que será acoplada ao computador [4].
As figuras 4.2 e 4.3 são de cartões demonstrativos emitidos pela Certisign
que é uma autoridade certificadora privada do país e que também é habilitada pela
Receita Federal para emissão do CPF e CNPJ eletrônico.
Figura 4.2 - Dispositivo SmartCard com CPF Digital
Fonte : http://www.certisign.com.br/produtos/ecpf/e-cpf.jsp
Figura 4.3 - Dispositivo SmartCard com CNPJ Digital
Fonte : http://www.certisign.com.br/produtos/ecnpj/e-cnpj.jsp
Os tipos de certificado e-CPF e o e-CNPJ poderão ser emitidos tanto em
formato de A3 como também em A1.
35
A figura 4.4 representa um cartão de identidade digital que também é
emitido pela Certisign e é uma credencial eletrônica mais completa e segura emitida
atualmente no Brasil.
Figura 4.4 - Dispositivo SmartCard com Identidade Digital
Fonte : http://www.certisign.com.br/produtos/id/id_aplicacoes.jsp
A figura 4.5 representa o dispositivo de hardware criptográfico token USB.
O uso deste dispositivo é bem simples, basta conectá-lo a um computador que
possui uma porta USB, em seguida deve ser instalado o seu driver e um software
gerenciador criptográfico. Após ter feitas estas etapas o token USB poderá ser
conectado ao computador que será reconhecido pelo sistema operacional.
Figura 4.5 - Dispositivo Token USB
Fonte : http://www.certisign.com.br/produtos/ecpf/pop_faq.jsp
36
A segurança de tecnologias de certificação digital está diretamente ligada
a forma com que a chave privada está protegida, por isso que a tendência para o
uso de certificados que são armazenados em dispositivos de hardware criptográfico
aumentem a cada dia. Apesar de que o custo para adquirir certificados armazenados
em hardware ainda é elevado com relação aos certificados armazenados em
software, com o tempo o mercado deverá estar investindo para que estes
dispositivos se tornem mais acessíveis à população [3].
4.2.2 Modelos de Aplicação de Certificado Digital
Quanto às aplicações de certificação digital as mais conhecidas e
utilizadas no mercado são:
• Certificado de e-mail seguro pessoal;
• Certificado de e-mail seguro corporativo;
• Certificado para servidor web;
• Solução corporativa de certificados que é conhecida como PKI
gerenciada;
• Certificado de CPF eletrônico;
• Certificado de CNPJ eletrônico;
• Certificado de identidade digital.
Ainda existem outras aplicações de certificação digital no mercado que
são utilizadas para fins específicos, mas que neste projeto não convém citá-las.
A seguir será feita uma breve descrição de cada uma das aplicações de
certificados digitais citadas acima.
Um certificado de e-mail seguro pessoal, para pessoa física, possibilita
que uma determinada pessoa assine digitalmente uma mensagem eletrônica para
que o destinatário identifique a origem da informação, ainda permite que
informações sejam criptografados utilizando o certificado digital do destinatário, ou
seja, cifrar as mensagens eletrônicas utilizando a chave pública do destinatário. Com
estes recursos será garantida que as mensagens confidenciais ou e-mails com os
arquivos em anexo tenham a identificação de um remetente, mantenha a integridade
37
e o sigilo das mensagens. Este certificado é recomendado para troca de
informações pessoais [14].
Um certificado de e-mail seguro corporativo, para pessoa jurídica, também
oferece os mesmos recursos de proteção do e-mail seguro pessoal, a única
diferença é que ele será direcionado para organizações.
Um certificado de servidor web está a cada dia sendo mais utilizado na
internet, ele serve de identificação e autenticação de sites na web. Ele permite que
um determinado usuário confira a autenticidade de um site em que está navegando,
garantindo que o site é verdadeiro e não uma cópia disponibilizada por fraudadores,
além disso, ainda será criado um canal criptográfico seguro que protegerá o sigilo e
a integridade das informações durante a comunicação entre o navegador web do
usuário e o servidor do site [14].
Um exemplo prático do uso de um certificado de autenticação de servidor
são os serviços on-line que os bancos oferecem para seus clientes. O banco
disponibiliza na internet seus serviços através de um aplicativo de software que
permitirá o acesso ao banco. Um banco utiliza certificado digital para certificar-se
que o cliente é o verdadeiro dono de uma determinada conta bancária que será
acessada por ele.
Por outro lado o banco apresentará ao seu cliente os dados do seu
certificado digital para que sejam validados como, por exemplo, a sua validade e
autoridade certificadora que assinou e emitiu o certificado, isto garantirá ao cliente
que ele estará usando um ambiente seguro para acessar e movimentar a sua conta
bancária.
A figura 4.6 mostra um exemplo de certificado de servidor web existente
no Internet Banking da Caixa Econômica Federal, que foi retornado para máquina
cliente via SSL, assunto a ser abordado mais adiante, após clicar no cadeado de
segurança localizado na parte inferior do navegador da Microsoft, o Internet
Explorer. Nesta interface são mostradas as informações básicas de um certificado e
o caminho de certificação que valida o mesmo. Neste caso a autoridade certificadora
que emitiu o certificado foi a AC CAIXA IN que é uma autoridade certificadora
intermediária da caixa cujo certificado foi emitido pela AC CAIXA que é uma das oito
autoridades certificadoras que atualmente fazem parte da ICP-Brasil e que o seu
certificado foi emitido pela autoridade certificadora raiz do Brasil.
38
Figura 4.6 - Exemplo de certificado de servidor web
Alguns sites exigem que as pessoas possuam também um certificado
digital instalado no seu computador para permitir acesso às áreas restritas e outros,
como exemplo de bancos, que distribuem gratuitamente certificados a seus clientes
como opção de garantir uma maior segurança no acesso e movimentação dos
dados de uma conta bancária.
Já a solução corporativa de certificados que é chamada de PKI
gerenciada, para pessoa jurídica, pode ser utilizada para proteger informações que
trafegam em intranets, extranets, Redes Privadas Virtuais (VPN) e aplicativo de
comércio eletrônico em organizações através da moderna tecnologia de Infra-
Estrutura de Chave Pública (PKI). Ao invés de implantar PKI própria onde teria um
custo alto de implantação, uma empresa poderá adquirir esta solução, onde terá
poder para controlar a emissão e gerenciamento de certificados próprios [14].
Os certificados de CPF eletrônico (e-CPF) e de CNPJ eletrônico (e-CNPJ)
são documentos eletrônicos em forma de certificado digital que garantem
autenticidade e integridade na comunicação entre pessoas físicas ou jurídicas e a
Secretaria da Receita Federal.
E o certificado de identidade digital, por sua vez, permite o acesso de
diversos serviços oferecidos pelo governo através da internet, que facilitará a vida de
39
cada cidadão brasileiro. Pois, os mesmos processos que hoje são feitos em
documentos de papel poderão ser executados utilizando o meio digital. Com este
cartão ainda será possível realizar a assinatura digital, o sigilo dos documentos e os
contratos digitais, e além disso possibilitará utilizar outros serviços on-line de forma
segura [15].
4.3 Renovação e Revogação de um Certificado
Após expirar a data de validade de um certificado e caso a chave privada
não esteja comprometida, o usuário do certificado poderá optar por adquirir um novo
certificado ou manter os dados do certificado ou até mesmo o par de chaves. Mas,
independente da situação, será importante a substituição do certificado, pois o
campo validade de um certificado existe para que ele seja expirado e a renovação
do mesmo seja feita. Com isso um novo par de chaves será gerado com uma
tecnologia de criptografia mais moderna e os dados de um usuário de um certificado
serão também atualizados, se necessário. Além disso, uma nova relação de
confiança será criada entre o usuário e a autoridade certificadora [4].
Se houver suspeita de que a chave privada esteja comprometida ou, por
exemplo, se um funcionário de uma empresa que possuía um certificado tenha sido
demitido, será necessário que seja solicitada a revogação do certificado à autoridade
certificadora responsável pela emissão e registro do mesmo. No caso de renovação,
seja por qualquer motivo, um novo certificado poderá ser emitido para que seja
gerado um novo de par de chaves e no caso do A3 este par de chaves deverá ser
adquirido e armazenado no hardware já existente.
As assinaturas digitais que forem realizadas através de um certificado
digital serão invalidadas a partir do momento que o certificado for expirado ou
revogado. Apenas estarão válidas as assinaturas feitas antes da expiração ou da
revogação do certificado, para isso, técnicas de inclusão de data e hora na
assinatura poderão ser adotadas para comprovar o período em que o documento foi
assinado [4].
40
4.4 Protocolo SSL
Protocolos de segurança são utilizados em conjunto com os certificados
digitais para garantir que durante um processo de envio e de troca de informações
seja criado um canal criptográfico seguro de comunicação entre as partes. Estes
protocolos são o S/MIME (Secure Multi-Purpose Internet Messaging Extensions) que
é utilizado em correio eletrônico e que permite que os e-mails assinados e
criptografados sejam transmitidos com segurança e o protocolo SSL (Secure Socket
Layer) que é utilizado em sites web para permitir em transações eletrônicas a
criptografia dos dados trafegados e a autenticação do servidor. A autenticação do
cliente poderá também ser feita caso o servidor faça o pedido.
O protocolo SSL será o nosso foco principal por ser a tecnologia utilizada
nos certificados digitais aplicados nas páginas web da maioria das empresas
disponíveis na internet que movimentam informações sigilosas. Inicialmente a
versão SSL 2.0 suportava apenas autenticação do servidor, mas no momento na
versão 3.0 já suporta tanto a autenticação do cliente como a do servidor [16].
Quanto ao nível de codificação, atualmente os certificados digitais para
servidor web de 128 bits em diante são considerados os mais seguros e os mais
utilizados pelas empresas devido ao forte nível de criptografia. Também estão
disponíveis certificados SSL de níveis de codificação abaixo de 128 bits, como por
exemplo os de 40 bits, que possuem um custo mais baixo do que os de 128 bits em
diante e podem ser utilizados em situações em que não se exige um alto nível de
segurança. Isto porque com este nível de encriptação já existe a possibilidade de
decodificar informações trafegadas em uma comunicação.
Pela maior segurança oferecida pelos certificados de 128 bits, os
navegadores precisam estar atualizados com este nível de codificação e, por
questão de segurança, não podem estar com um nível mais baixo daquele utilizado
pelo certificado do servidor. Isto se deve ao fato que a codificação mais baixa será
priorizada e considerada durante uma sessão estabelecida entre o cliente e o
servidor e com isso terá uma perda de segurança [17].
Para identificar que um site na web está utilizando protocolo SSL e
consequentemente um certificado digital, um cliente deverá verificar se na barra de
endereços da página acessada possui “https://” ao invés de “http://” que é o padrão.
41
Além disso, deve-se verificar se há um cadeado fechado no lado inferior direito da
página acessada no caso do navegador da Microsoft, o Internet Explorer, conforme
figura 4.7 mostrada abaixo que ainda mostra que é uma sessão SSL que foi
estabelecida com o nível de codificação de 128 bits. Uma página padrão da web que
utiliza ”http://” utiliza a porta 80 do servidor web e a página com “https://” utiliza o
protocolo SSL e a porta 443 de um servidor web.
A identificação de um site seguro utilizando SSL, dará a um cliente a
confiança necessária para ele poder realizar as transações eletrônicas com a
garantia de que caso as informações trafegadas durante uma comunicação sejam
interceptadas, elas estejam totalmente cifradas e impossíveis de serem identificadas
ou decifradas.
Figura 4.7 - Uso do protocolo SSL no navegador Internet Explorer
O cliente ainda poderá utilizar o cadeado de identificação de uso de
protocolo SSL para verificação dos dados do certificado digital utilizado no site da
web, dentre estes dados o cliente poderá verificar, por exemplo, a validade do
certificado e a autoridade certificadora responsável pela sua emissão.
Algumas autoridades certificadoras ainda disponibilizam na página “https”
um selo de identificação de site seguro, para que um usuário possa através dele
conferir as informações essenciais de um certificado digital em tempo real.
A figura 4.8 mostra um selo de identificação de site seguro que a Certisign
disponibiliza como uma proteção extra aos seus clientes para serem exibidos na
página “https://" onde será feita a autenticação do servidor.
Figura 4.8 - Selo Certisign de identificação de site seguro
Fonte : http://www.certisign.com.br/suporte/config_instala_selo.jsp
42
Durante uma sessão SSL, os dados transitados são criptografados e
descriptografados, além disso, o uso de SSL aumenta a quantidade de dados
transmitidos pela inclusão de novos pacotes. Com isto a troca de informações entre
o cliente e o servidor será mais lenta [16].
Percebe-se assim que o uso do SSL envolve um processamento extra
durante uma comunicação e por este motivo devem ser analisadas sempre quais
páginas web deverão realmente conter a proteção SSL. A prioridade de proteção
será dada às páginas que irão trafegar informações confidenciais e que precisam
garantir segurança.
Criptografias de chave pública e simétrica serão utilizadas para garantir o
sigilo das informações trafegadas durante uma sessão SSL. A chave pública do
certificado será utilizada para cifrar a chave simétrica que será responsável pela
troca segura de informações durante uma sessão SSL. Os dados que trafegam entre
o cliente e o servidor são criptografados com um algoritmo simétrico, como por
exemplo o DES, RC4 e o AES e que por sua vez são mais rápidos do que os
algoritmos de chave pública [18].
4.4.1 Processo de estabelecimento de uma sessão SSL
Uma sessão de SSL será iniciada sempre com uma troca de mensagens
chamada handshake por SSL. O Protocolo Handshake é a principal parte do SSL e
é feito em duas partes. Inicialmente é feita a escolha da chave entre o cliente e o
servidor, a autenticação do servidor e a troca da chave e depois é feita a
autenticação do cliente, se solicitada pelo servidor, e o fim do handshake. Após o
handshake estar completo, a transferência de dados entre aplicações poderá ser
iniciada [18].
43
Abaixo serão mostrados os passos que são executados para estabelecer
uma sessão SSL utilizando certificado digital.
Figura 4.9 - Processo de handshake por SSL
CLIENTE SERVIDOR
(1)
(2)
(3)
(4)
(5)
(6)
(7)
1. Uma sessão SSL será sempre iniciada pelo lado cliente quando é feito
inicialmente o envio de uma solicitação de uma sessão segura, ou
seja, quando o cliente acessa uma página “https://” estará sendo feito
um pedido de certificado digital do servidor. Além disso, o cliente
enviará o número da sua versão SSL, as cifras simétricas suportadas
para troca de chaves, como por exemplo RC4 e AES, e ainda outras
informações que o servidor precisa serão enviadas para se comunicar
com o cliente utilizando SSL.
2. O servidor responde retornando a cifra escolhida e informações
específicas de sessão que serão utilizadas pelo cliente para a
comunicação com o servidor. Quanto às cifras disponíveis pelo cliente
e o servidor, ambos deverão ter pelo menos uma cifra compatível e
caso tenham mais de uma, será escolhida pelo servidor aquela mais
segura, isto é chamado de acordo de chaves.
44
3. O servidor envia ao cliente seu certificado digital e caso seja
necessária a autenticação do cliente, o servidor enviará um pedido de
certificado ao cliente.
4. O cliente recebe o certificado digital do servidor e confere se o
certificado provém de uma autoridade de certificação segura através do
certificado raiz desta AC instalado no cliente, se o certificado expirou
ou ainda não é válido e se o nome do site do certificado é igual ao site
acessado, pois um servidor intruso poderá interceptar a solicitação do
cliente e enviar o seu certificado com sua chave pública e se comunicar
com o cliente fazendo se passar do servidor verdadeiro e acessar
informações confidenciais, por isso que é feita a comparação dos sites.
Se ocorrer pelo menos uma dessas situações, o cliente receberá uma
mensagem e o usuário terá a opção de aceitar a continuidade da
negociação SSL e acessar o site ou desconfiando do site e do
certificado digital recebido poderá não aceitar o acesso finalizando
assim a conexão. Se a negociação SSL prosseguir o cliente extrairá a
chave pública do certificado do servidor.
5. O cliente irá gerar uma chave de sessão onde será criptografada com a
chave pública do certificado do servidor e em seguida enviada ao
mesmo.
6. O servidor descriptografa a chave de sessão com a sua chave privada
do seu certificado associada a chave pública que foi disponibilizada e
informa ao cliente que a partir deste momento as mensagens serão
enviadas encriptadas com a chave de sessão.
7. A partir daí a sessão será iniciada e um canal seguro de comunicação
será criado. O cliente e o servidor utilizarão a chave de sessão para
encriptar e desencriptar os dados trafegados entre si e caso o cliente
também possua um certificado digital será capaz de realizar
assinaturas digitais em mensagens e documentos através deste canal
seguro, isto enquanto durar a sessão.
É importante perceber que antes a assinatura digital e a confidencialidade
de uma informação poderia ser feita sem uso de uma sessão SSL e certificado
digital, mas o problema é que estes procedimentos não eram feitos através de um
45
canal seguro e não eram aplicados os passos acima durante a comunicação entre
duas partes.
O SSL não oferece proteção dos dados quando eles estiverem ainda na
origem e quando chegarem ao destino, ou seja, não protege os dados locais,
apenas garantirá a segurança dos mesmos durante a transmissão. Além disso o
SSL não garantirá também o não repúdio, sendo assim necessário o uso da
assinatura digital para provar a execução da transação e o envio da informação.
Quando a assinatura digital, o certificado digital e o protocolo SSL forem
juntos utilizados, será possível garantir o completo ciclo de segurança que envolve a
autenticidade, a integridade, a confidencialidade e o não-repúdio de mensagens e
documentos trafegados em um ambiente web até o seu destino.
4.5 Requisição e Instalação de um Certificado Digital
Existem outras soluções de emissão de certificado digital onde não há a
necessidade de comprar de uma autoridade certificadora, estas soluções permitem
que certificados auto-assinados sejam criados e instalados e sejam utilizados para
assinar documentos, podendo ainda contar com o recurso de proteção da chave
privada no momento da autenticação e o uso do protocolo SSL.
Quanto à criação e à instalação de um certificado digital através de uma
autoridade certificadora será feita inicialmente com a geração de um arquivo texto
chamado CSR (Certificate Signing Request), que significa Pedido de Assinatura de
Certificado e que deve ser gerada através de um software de servidor web. Um CSR
é um arquivo criptografado que possui a chave publica, um nome, a localidade e o
endereço web que utilizará o certificado. Na solicitação do certificado, a chave
privada do certificado será armazenada no computador em que foi feita a solicitação
e a CSR será encaminhada à autoridade certificadora através de formulários
disponibilizados na internet que utilizarão páginas “https://” que garantirá a
segurança dessas informações.
Além do conteúdo da CSR, o responsável pela requisição do certificado
informará também outros dados necessários para o processo de emissão do
certificado. Após ser feita a validação das informações enviadas pelo responsável, a
AC enviará um arquivo contendo informações que serão utilizadas para instalação
46
final do certificado no servidor web, bem como as senhas que serão utilizadas para
finalização do processo de instalação do certificado e para manutenção deste no site
da autoridade certificadora que emitiu o certificado.
O processo de requisição de um certificado digital para instalação será
necessário apenas quando este for adquirido através de uma autoridade
certificadora, pois quando for uma solução alternativa, onde não se quer gastos ou a
depender da necessidade o certificado poderá ser criado e manipulado por uma
pessoa física ou jurídica sem interferência de uma autoridade certificadora que faça
parte ou não da ICP-Brasil.
47
5. TECNOLOGIAS DISPONÍVEIS EM JAVA
A Plataforma Java dispõe de um framework chamado JCA (Java
Cryptography Architecture) que contém um conjunto de classes com funcionalidades
criptográficas para serem utilizadas em aplicações que necessitem de segurança,
como as que utilizam certificado digital e assinatura digital. Este framework pertence
à API (Application Programming Interface) básica do Java e integra funcionalidades
de segurança para aplicações desenvolvidas nesta linguagem e, que por sua vez,
tem como principal vantagem a independência de plataforma.
A JCA é uma especificação ou uma referência que contém
funcionalidades que podem possuir implementações diferentes e que entre elas
haverá compatibilidade desde que sigam esta especificação. Além disso, ainda
existe a possibilidade de extensão, que significa acrescentar ao framework novos
serviços, como no caso da JCE (Java Cryptography Extension) que é uma extensão
da JCA e que incorporam técnicas criptográficas com recursos mais avançados [19].
5.1 JCA e JCE
O JCA usa o conceito de Provider Criptográfico que é um pacote de
classes que fornece a implementação concreta dos serviços definidos na API. A
figura 5.1 mostra que uma aplicação pode utilizar o JCA e/ou JCE, mostra também o
provider da própria SUN para JCA e para o JCE, SUN Provider e SunJCE Provider,
e ainda um outro provider qualquer, Acme Provider, que implementa tanto o JCA
como o JCE.
48
Figura 5.1 - Arquitetura da JCA
Fonte : http://www.di.uminho.pt/~jmv/CriptografiaAplicada/CA-Pratica-I.pdf
O JDK (Java Development Kit) da SUN já inclui no seu pacote
java.security e no pacote javax.crypto a implementação de um provider da
especificação JCA e um provider da JCE e estes incluem implementações de :
• Algoritmos de assinatura digital DSA e RSA;
• Algoritmos de hash MD5 e SHA1;
• Gerador de pares de chaves DSA e RSA;
• Classe para uso de certificados X. 509;
• Um KeyStore (repositório de certificados) chamado “JKS” (KeyStore
da SUN).
O acesso a um certificado no KeyStore é feito através de um “Alias” que é
um nome dado ao certificado no momento da sua criação e que identificará o
certificado. Tanto o acesso a um KeyStore quanto a uma chave privada de um
certificado será feito através de senha de proteção.
No JDK existe uma ferramenta de linha de comando chamada Keytool
para criação e manipulação de certificados em um KeyStore. A listagem 5.1 mostra
um exemplo do uso desta ferramenta para criação de um certificado.
Listagem 5.1 - Criação de um KeyStore com Keytool
keytool -genkey -alias sam -keyalg RSA -keysize 2048 -sigalg "SHA1withRSA"
-keypass sam123 -storepass sam123 -keystore C:/samuel.jks -dname
"cn=SAMUEL, ou=Monografia, o=SAMUEL, l=Aracaju, S=SE, c=BR" -validity 365
49
Os argumentos passados para o keytool são:
-genkey : indica que será gerada a chave;
-alias : é o nome das chaves que serão armazenadas no KeyStore;
-keyalg : indica qual o algoritmo para geração do par de chaves;
-sigalg : indica o algoritmo de assinatura a ser utilizado;
-keypass : indica a senha de proteção da chave no KeyStore;
-storepass : é a senha de proteção do KeyStore;
-keystore : indica onde as chaves serão armazenadas;
-dname : nome da entidade que vai gerar o par de chaves. Exemplo:
cn = Nome Comum, ou = Unidade Organizacional (departamento ou
divisão), o = Nome da Organização, l = localidade (cidade), s = Estado,
c = País;
Além de outras funcionalidades, o Keytool permite que certificados
possam ser exportados e importados para um repositório JKS.
5.2 Padrão JKS e o PKCS#12
Os providers implementados pela SUN do JCA e JCE possibilitam
manipular arquivos de certificados do tipo PKCS#12, com a extensão .pfx ou .p12.
PKCS significa Public-Key Cryptography Standards, que na prática é um conjunto de
padrões de tecnologias de criptografia que utiliza o conceito de chave pública, e 12
porque é um dos padrões de certificado utilizado pelos navegadores web para troca
de informações pessoais, incluindo a autenticidade do servidor. Este padrão junto
com o JKS serão os tipos de certificado a serem abordados.
A importação e exportação de uma chave pública no formato X509 são
possíveis por estes dois tipos de certificados, a partir de um repositório JKS. Estes
dois tipos de arquivos poderão também ser lidos e manipulados através dos
providers acima citados, para que sejam extraídos os dados do certificado e em
específico a chave privada que será aplicada na assinatura digital de mensagens e
de arquivos.
50
A listagem 5.2 mostra um exemplo de uma importação de um certificado
no formato X.509 com a extensão .cer, chamado samuel_certisign.cer, que foi
exportado a partir de um certificado PKCS#12 e emitido pela autoridade certificadora
Certisign, como certificado de teste, e instalado no navegador da Microsoft, o
Internet Explorer. Este certificado foi importado para dentro do KeyStore criado na
listagem 5.1 com o nome samuel.jks, o nome do alias para importação será “sam1”,
como na listagem 5.1 já foi criado um certificado com o nome do alias “sam” e este
não é permitido que se repita no mesmo arquivo JKS.
Listagem 5.2 - Importação de um certificado X.509 para um KeyStore JKS
keytool -import -alias sam1 -file C:/ samuel_certisign.cer
-keystore C:/samuel.jks -storepass sam123
Em seguida a listagem 5.3 mostra um exemplo de uma exportação de um
certificado digital no formato X.509 que foi armazenado no KeyStore samuel.jks com
o alias “sam1”.
Listagem 5.3 - Exportação de um certificado X.509 do KeyStore JKS
keytool -export -alias sam1 -keystore C:/samuel.jks
-file C:/samuel_keytool.cer -storepass sam123
As listagens 5.2 e 5.3 mostram a compatibilidade de certificados X.509
entre ferramentas de manipulação de certificado digital. Inicialmente foi importado
um certificado contendo a chave pública chamado samuel_certisign.cer que havia
sido exportado pelo Internet Explorer e depois de armazenado no KeyStore
samuel.jks foi possível exportá-lo também com a chave pública um arquivo no
formato X.509 chamado samuel_keytool.cer através da ferramenta Keytool do JDK.
Outro ponto a ser explicado na geração de um certificado digital pelo
Keytool é a questão da autoridade certificadora que emitiu este certificado. Um
certificado digital com a chave privada gerado pelo Keytool é um certificado auto-
assinado por quem o gerou. Um exemplo prático disso é mostrado através da figura
5.2, no qual, ao executar um arquivo com extensão .cer, gerado pelo Keytool, é
exibida uma interface contendo informações do certificado. Nesta interface contém o
51
seguinte aviso de problema do certificado “Este certificado raiz da autoridade
certificadora não é confiável. Para ativar a confiabilidade, instale este certificado no
armazenamento das autoridades de certificação da raiz de confiança”. Já na figura
5.3 é mostrado o caminho de certificação com o ícone de inválido. Isto porque, como
foi criado pela ferramenta Keytool e nela não há um certificado raiz que emita o
certificado.
Figura 5.2 - Interface de execução de um arquivo .cer gerado pelo Keytool
Figura 5.3 - Caminho de Certificação do certificado da figura 17
Mas, após a instalação deste certificado através da opção de instalar
certificado, localizada na parte inferior da interface, ele ficará armazenado no
navegador Internet Explorer em “autoridades de certificação raiz confiáveis”, e após
52
ser instalado neste local será reconhecido como um certificado válido, desde que
esteja com seus dados realmente válidos, e isto é observado através das figuras 5.4
e 5.5.
Figura 5.4 - Interface de execução de um arquivo .cer após a instalação
Figura 5.5 - Caminho de Certificação do certificado da figura 5.4
53
Se este certificado fosse emitido por uma autoridade certificadora, o
caminho de certificação estaria com um ou mais níveis acima contendo as
autoridades certificadoras que fazem parte do caminho de certificação do certificado
de “SAMUEL”. A figura 5.6 mostra um certificado existente no Internet Banking da
Caixa Econômica Federal que foi emitido pela autoridade certificadora AC CAIXA IN,
que é uma autoridade certificadora intermediária da Caixa, cujo certificado foi
emitido pela AC CAIXA, que é uma das oito autoridades certificadoras que fazem
parte da ICP-Brasil e cujo certificado foi emitido pela autoridade certificadora raiz do
Brasil.
Figura 5.6 - Caminho de Certificação de um certificado da Caixa
5.3 API Java para Assinatura Digital
Nas próximas listagens serão mostrados os códigos em Java para
extração da chave privada e da chave pública de um certificado, para que seja feita
a assinatura digital de uma mensagem e a validação da mesma. E ainda será
mostrado como é feita a leitura de um arquivo de certificado do tipo JKS e do tipo
PKCS#12, para que seja manipulado em uma classe Java. A listagem 5.4 mostra as
classes da API Java que foram utilizadas para extração da chave privada e pública,
assinatura e validação de uma mensagem.
Listagem 5.4 - Classes da API Java
54
A listagem 5.5 e 5.6 mostram a extração de uma chave privada e de uma
chave pública a partir de um arquivo JKS com extensão .jks ou um arquivo do tipo
PKCS#12 com a extensão .pfx ou .p12. O tipo de KeyStore será informado como
nos métodos abaixo de extração de chaves. O que difere entre ambos os tipos será
apenas na forma de como é capturado o alias de acesso ao certificado no KeyStore.
Quando a instância de uma classe KeyStore é feita a partir um JKS, já sabemos qual
o nome do alias para que possamos acessar o certificado, uma vez que foi criado
pela ferramenta Keytool e em um ambiente local.
Mas, quando a instância do KeyStore é feita a partir de um arquivo do tipo
PKCS#12, não se sabe a princípio o nome do alias, pois este arquivo foi gerado e
exportado de um servidor web e que havia sido instalado junto a uma autoridade
certificadora. No entanto, para capturar um alias de um certificado .pfx, será utilizado
um método da instância da classe KeyStore chamado “aliases” que retorna os
aliases de um repositório de certificados, que no caso de um arquivo .pfx teremos
apenas um alias a ser obtido.
Listagem 5.5 - Método de extração de uma chave privada
55
Listagem 5.6 - Método de extração de uma chave pública
Uma vez de posse da chave privada e da chave pública, serão mostrados,
através das listagens 5.7 e 5.8, métodos de assinatura e de validação de uma
mensagem, para os quais esta será passada como parâmetro em forma de array de
bytes. Os métodos de assinatura e validação utilizam na instância da classe
Signature a string “SHA1withRSA” que significa que o algoritmo a ser utilizado para
assinatura da mensagem será o SHA1, para geração do message digest, e que será
combinado com RSA que é o algoritmo assimétrico utilizado na geração do par de
chaves.
Listagem 5.7 - Método de criação de uma assinatura digital
56
Listagem 5.8 - Método de validação de uma assinatura digital
As listagens acima mostram de forma simples que a assinatura digital
pode ser utilizada com a API existente no Java. Mas, ainda é importante deixar claro
que uma assinatura digital pode ser aplicada tanto em uma mensagem como em um
arquivo. Além disso, pode ser gerada dentro da própria mensagem ou de um
arquivo, com a informação a ser assinada, ou em arquivos a parte como por
exemplo : uma assinatura pode ser criada em um arquivo separado e enviada a um
destino para ser validada junto com a mensagem ou o arquivo original contendo o
conteúdo da informação.
57
6 - ASSINATURA DIGITAL EM ARQUIVOS XML
O XML (Extensible Markup Language) ou Linguagem Extensível de
Marcação) foi criado para permitir que um usuário de linguagem de marcação de
texto crie suas próprias regras em documentos digitais e que estes sejam lidos e
manipulados de forma padronizada. As regras para estruturas de documentos XML
são definidas em um arquivo separado, chamado de esquema, e é através deste
que o documento XML pode ser construído dentro de um padrão e com isto é
possível ser validado. Além disso, através de um documento XML a troca de dados
entre entidades na internet se torna padrão e consequentemente eficiente.
Diante da padronização ou uma especificação a ser seguida, uma outra
grande vantagem de um documento XML é a independência de plataforma, ou seja,
este tipo de documento não depende de sistema operacional e pode ser interpretado
por diversas linguagens de programação [24].
6.1 - Estrutura de um Documento XML
A listagem 6.1 mostra que um documento XML segue uma estrutura de
um modelo de árvore de elementos, onde existem elementos internos a outros, que
são chamados de elementos filhos. Na listagem, da mesma forma que os elementos
<remetente> e <destinatario> são filhos do elemento <cabecalho>, os elementos
<cabecalho> e <corpo> são também filhos do elemento raiz <mensagem>. A
listagem a seguir mostra um exemplo de um documento XML contendo a mensagem
de um e-mail.
58
Listagem 6.1 - Código fonte de um exemplo de documento XML
6.2 - Segurança de um documento XML
Para garantir a segurança no conteúdo de arquivos XML foi criada
também uma especificação que garante segurança na informação neste tipo de
arquivo através da assinatura digital. A especificação a ser utilizada é a da W3C
(World Wide Web Consortium) que é uma organização oficial para padrões web.
Dentre estes padrões está definido o da assinatura digital e validação da mesma em
documentos XML onde assegura a sua interoperabilidade em diversas plataformas
[23].
Existem diversas API’s que implementam assinatura digital em
documentos XML, nelas podem ser agregados tanto os providers da própria API
Java quanto serem implementados novos providers da especificação JCA e da JCE.
Junto a estes providers, estas API’s irão formar um pacote de classes ou um
59
framework específico para assinatura digital de documentos XML e que ainda
permitirá manipular certificados digitais na assinatura desses documentos.
Existem três formas de utilização de assinatura digital em documentos
XML, estas são:
Detached : A assinatura digital é criada em um arquivo separado do
conteúdo do documento XML assinado;
Enveloped : A assinatura é criada dentro do conteúdo que é assinado,
ou seja, a assinatura é um elemento filho do documento XML assinado;
Enveloping : O conteúdo assinado estará dentro da assinatura, ou
seja, o conteúdo do documento XML assinado é um elemento filho da assinatura
digital do XML.
Para o estudo de caso deste projeto será utilizado o tipo enveloped para
demonstração de assinatura digital em um documento XML, bem como o processo
de validação de assinatura deste próprio documento.
A listagem 6.2 demonstra a especificação simplificada dos elementos de
assinatura de documento XML de acordo com a especificação W3C-DSIG (2002).
Como recomendado na referência, o sinal de interrogação “ ? ” indica a existência de
zero ou uma ocorrência do elemento, o sinal de soma “ + ” indica que pode existir
uma ou mais ocorrências para o elemento e para o “ * ” zero ou mais ocorrências.
60
Listagem 6.2 - Especificação simplificada de uma assinatura XML.
Os elementos que possuem o sinal de interrogação são elementos
opcionais, assim como o atributo ID do elemento <Signature> e (Object), e o atributo
URI do elemento <Reference>. A listagem 6.3 mostra apenas os elementos
obrigatórios para uma assinatura de XML.
Listagem 6.3 - Elementos obrigatórios de uma assinatura XML.
61
6.3 - Elementos de uma Assinatura Digital em XML
Os elementos existentes em uma assinatura de XML serão explicados
com base na especificação da W3C para assinatura digital em documento XML
W3C-DSIG (2002).
6.3.1 - Elemento <Signature>
Este elemento é a raiz de uma assinatura XML e que contém como
elementos filhos obrigatórios o <SignedInfo> e <SignatureValue> e como opcionais
os elementos <KeyInfo> e <Object>. A listagem 6.4 mostra a definição do esquema
do elemento <Signature>.
Listagem 6.4 - Definição do esquema do elemento <Signature>.
<element name="Signature" type="ds:SignatureType"/> <complexType name="SignatureType"> <sequence> <element ref="ds:SignedInfo"/> <element ref="ds:SignatureValue"/> <element ref="ds:KeyInfo" minOccurs="0"/> <element ref="ds:Object" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="Id" type="ID" use="optional"/> </complexType>
Os elementos filhos do elemento <Signature> serão comentados a seguir.
6.3.2 - Elemento <SignedInfo>
O elemento <SignedInfo> é responsável por conter as informações de
configuração do processo de assinatura de um documento XML junto aos seus
62
elementos filhos. A listagem 6.5 mostra a definição do esquema do elemento
<SignedInfo>.
Listagem 6.5 - Definição do esquema do elemento <SignedInfo>
<element name="SignedInfo" type="ds:SignedInfoType"/> <complexType name="SignedInfoType"> <sequence> <element ref="ds:CanonicalizationMethod"/> <element ref="ds:SignatureMethod"/> <element ref="ds:Reference" maxOccurs="unbounded"/> </sequence> <attribute name="Id" type="ID" use="optional"/> </complexType>
Conforme listagem 6.5, os elementos filhos do elemento <SignedInfo> são :
<CanonicalizationMethod> - Indica qual o algoritmo que será
utilizado para canonicalizar todo conteúdo do elemento <SignedInfo>, ou seja,
normalizar o conteúdo de um documento XML através de um algoritmo que
será referenciado neste elemento. Isto será feito antes do documento XML ser
assinado ou validado;
<SignatureMethod> - indica o algoritmo que será utilizado na
assinatura do documento;
<Reference> - indica quais os dados deverão ser assinados e
como a assinatura deve ser feita antes de aplicar a função de hashing. O
atributo URI (Uniform Resource Identifier) é opcional e significa um
identificador uniforme de recursos, representa os dados que serão assinados.
O elemento <Reference> pode aparecer mais de uma vez indicando que está
assinando mais de uma informação no XML [24].
O elemento <Reference> possui três elementos filhos como é
demonstrado na listagem 6.6 e que são explicados a seguir.
63
Listagem 6.6 - Definição do esquema do elemento <Reference>.
<element name="Reference" type="ds:ReferenceType"/> <complexType name="ReferenceType"> <sequence> <element ref="ds:Transforms" minOccurs="0"/> <element ref="ds:DigestMethod"/> <element ref="ds:DigestValue"/> </sequence> <attribute name="Id" type="ID" use="optional"/> <attribute name="URI" type="anyURI" use="optional"/> <attribute name="Type" type="anyURI" use="optional"/> </complexType>
<Transforms> - Este elemento pode conter um ou vários elementos
<Transform>, onde cada um deste indicará a transformação que deve ser feita para
o objeto referenciado na URI do elemento <Reference>, se a URI estiver vazia
significa que cada transformação será aplicada no conteúdo existente fora de todo o
elemento <Signature>. Uma transformação é um tipo de normalização que deve ser
feita antes de gerar o message digest da informação referenciada na URI, esta
normalização é feita com referência ao padrão XML;
<DigestMethod> - indica o algoritmo de hashing que será utilizado para
geração do message digest da informação referenciada pela URI do elemento
<Reference>;
<DigestValue> - indica o message digest ou valor do hash gerado, da
informação referenciada pela URI do elemento <Reference> após aplicação do
algoritmo de hashing definido no elemento <DigestMethod>.
6.3.3 - Elemento <SignatureValue>
O elemento <SignatureValue> contém o valor da assinatura digital de todo
o conteúdo existente no elemento <SignedInfo> utilizando o algoritmo de assinatura
especificado no elemento <SignatureMethod> e a aplicação da chave privada do
64
certificado digital do remetente de um arquivo XML. A validação de uma assinatura
digital em um arquivo XML é feita inicialmente gerando um message digest de todo
conteúdo do elemento <SignedInfo> e comparando este com o message digest
obtido após decifrar o valor da assinatura digital do elemento <SignatureValue> com
a chave pública do certificado do remetente do XML [23].
Se não passar nesta primeira validação, o documento XML será
considerado como inválido e não dará continuidade ao processo de validação da
assinatura. Entretanto, caso seja feita esta primeira validação com sucesso serão
validados os elementos <Reference> existentes em <SignedInfo>, fazendo a
geração de cada message digest da informação referenciada na URI a partir do
algoritmo de hashing definido no elemento <DigestMethod> e comparando com o
valor do elemento <DigestValue>. Caso estas validações sejam feitas com sucesso,
o documento XML será considerado válido para utilização.
A listagem 6.7 mostra a definição do esquema do elemento
<SignatureValue>.
Listagem 6.7 - Definição do esquema do elemento <SignatureValue>
<element name="SignatureValue" Type="ds:SignatureValueType"/> <complexType name="SignatureValueType"> <simpleContent> <extension base="base64Binary"> <attribute name="Id" type="ID" use="optional"/> </extension> </simpleContent> </complexType>
6.3.4 - Elemento <KeyInfo>
O elemento <KeyInfo> é opcional na especificação de uma assinatura
XML, ele possui elementos filhos que podem ser utilizados para armazenar a chave
65
pública e os dados de um certificado digital, como no caso do <KeyValue> e do
<X509Data>. O <KeyValue> armazena no seu elemento filho a chave pública do
certificado do remetente, este elemento filho pode ser de acordo com a definição do
seu esquema o <RSAKeyValue> ou o <DSAKeyValue>. Na especificação da
listagem 6.2, no início do capítulo, foi inserido o elemento <RSAKeyValue> pelo fato
de ser o elemento que conterá a chave pública gerada através de uma algoritmo
assimétrico mais seguro atualmente que é o RSA [23].
Já o elemento <X509 Data> contém informações sobre o certificado digital
do remetente de um arquivo XML. Este elemento possui um elemento filho chamado
<X509Certificate>, que armazenará os dados codificados de um certificado. Estes
elementos podem ser visualizados também na listagem 6.2 onde mostra a
especificação de uma assinatura digital em um documento XML.
A listagem 6.8 mostra além dos elementos <KeyValue> e do <X509Data>
os outros elementos existentes no esquema do elemento <KeyInfo>.
Listagem 6.8 - Definição do esquema do elemento <KeyInfo>
<element name="KeyInfo" type="ds:KeyInfoType"/> <complexType name="KeyInfoType" mixed="true"> <choice maxOccurs="unbounded"> <element ref="ds:KeyName"/> <element ref="ds:KeyValue"/> <element ref="ds:RetrievalMethod"/> <element ref="ds:X509Data"/> <element ref="ds:PGPData"/> <element ref="ds:SPKIData"/> <element ref="ds:MgmtData"/> <any processContents="lax" namespace="##other"/> </choice> <attribute name="Id" type="ID" use="optional"/> </complexType>
Quando o elemento <KeyInfo> não consta na assinatura de um XML,
significa dizer que o destinatário que irá receber o XML já possui a chave pública e o
66
algoritmo utilizado para geração da mesma ou então estas informações mais outros
dados necessários de um certificado serão obtidas através do certificado do
remetente durante o estabelecimento de uma sessão SSL onde torna também
possível e mais segura a validação de uma assinatura de um documento XML.
67
7 - ESTUDO DE CASO
Este trabalho tem como objetivo demonstrar a importância do uso da
tecnologia de certificação digital em aplicações, principalmente daquelas que são
desenvolvidas para a Internet, onde as informações necessitam de uma maior
segurança por serem trafegadas em uma rede aberta. Sendo assim, o estudo de
caso proposto mostrará, através de um estudo de caso, os benefícios trazidos para
a segurança da informação.
Nesta aplicação serão mostrados também quais os momentos necessários
para utilizar certificado digital de servidor web, certificado cliente ou pessoal e ainda
aplicar por sua vez a assinatura digital em documentos XML, que garantirá a
autenticidade e a integridade das informações.
7.1 - Descrição e funcionamento da aplicação
A aplicação do estudo de caso foi desenvolvida baseada no modelo
tradicional de uma loja virtual na Internet, onde inicialmente são listados produtos
existentes na loja e, a partir deste momento, o cliente poderá escolher os produtos
desejados, incluindo-os no carrinho de compras. Após finalizar o pedido, a aplicação
solicitará a identificação do cliente que caso o cliente ainda não esteja cadastrado na
loja terá a opção de cadastramento.
Desde o momento da exibição da página web de identificação do cliente
até o fim do pagamento do pedido do cliente, todas as informações referentes a
compra do cliente estarão protegidas através do uso do certificado de servidor web
que demonstrará autenticação do servidor perante o cliente.
Sendo feita a identificação do cliente, o cliente será levado para uma página de
confirmação do pedido, onde serão mostrados os dados referente a compra, como
os produtos escolhidos, a quantidade de cada produto e o valor final do pedido do
cliente. Nesta mesma página também serão exibidos dados de identificação do
cliente e dados referentes ao endereço de entrega do pedido.
68
Após a confirmação do pedido, o cliente deverá informar a forma de
pagamento do pedido através de algum cartão de crédito conveniado a loja. Ao
escolher o cartão, o cliente será encaminhado para a página onde serão informados
os dados do cartão de crédito. Sendo que neste momento, antes de acessar esta
página, será solicitada a autenticação mediante certificado do cliente, seja do tipo A1
e A3. O cliente deverá escolher o seu certificado e informar a senha de acessa a
chave privada, que estando correta será feita a validação de que se o cliente do
certificado é o mesmo do responsável pela compra e o existente no cadastro da
operadora do cartão de crédito, isto porque poderá existir um ou mais certificados do
tipo cliente instalados no computador em que está sendo feita a compra.
A validação estando correta, permitirá que a página onde serão
informados os dados do cartão de crédito seja acessada pelo cliente. Para finalizar o
seu pedido, o cliente deverá informar os dados corretos do cartão e confirmar a
conclusão da compra. Em seguida será mostrada a mensagem de que o pedido foi
realizado com sucesso.
Neste momento dois arquivos XML serão gerados, assinados digitalmente
e enviados aos seus destinos. O primeiro arquivo XML armazenará os dados do
pedido do cliente e que será enviado ao servidor da loja virtual, já o segundo arquivo
terá os dados referentes ao cartão de crédito, que será enviado para operadora do
cartão. O conteúdo dos dois arquivos será validado nos seus destinos através da
assinatura digital do conteúdo de cada arquivo XML.
Para fazer a validação dos arquivos XML’s de pedido e de cartão de
crédito em outro momento como se fosse o servidor da loja e servidor da operadora
do cartão, foi criado um JSP para que possamos validar estes arquivos e até mesmo
alterá-los após terem sido gerados pela aplicação. Isto, para fazermos a simulação
de que caso alterado o conteúdo venha a ocasionar um erro de integridade nos
arquivos e consequentemente uma mensagem de erro informando de que o arquivo
foi alterado. A resposta da validação dos arquivos XML neste JSP exibirá um log
mostrando do ocorrido durante o processo de validação de cada arquivo XML.
A figura 7.1 abaixo mostra o fluxo das atividades do processo de compra na loja
virtual através de um diagrama de atividades.
69
Cliente/Visitante Sistema
70
7.2 - Estrutura do Projeto
O projeto do estudo de caso da loja virtual foi dividido em quatro pacotes,
são eles: entidades, objetoXML, assinaturaXML e persistência. O pacote entidades
contém os JavaBeans que irão representar o cliente, o Item do pedido, os produtos,
o pedido que é o carrinho de compras e o cartão de crédito como forma de
pagamento.
O pacote objetoXML que contém uma classe que fará o mapeamento dos
objetos pedido e cartão de crédito para arquivos XML e utiliza para isso uma API
simples chamada XStream. O pacote assinaturaXML que contém as classes que
irão assinar e validar os arquivos XML’s de pedido e cartão de crédito e que utilizam
a API da Apache para geração desses arquivos seguindo a especificação da W3C.
O pacote persistência contém uma classe de acesso a dados que fará a
persistência e permitirá o armazenamento dos dados do cliente e dos produtos. Para
manter a simplicidade da aplicação do estudo de caso, apenas os clientes e os
produtos estarão armazenados em bando de dados, já as classes e os dados
referentes a manipulação do carrinho de compras estarão em memória, na sessão
da aplicação.
Por fim foi criado o módulo web que contém as páginas JSP da aplicação.
Nos anexos I e II estão os códigos fonte das classes do projeto, os principais JSP’s
e um exemplo mostrando o conteúdo do arquivo XML de cartão de crédito antes e
depois da aplicação de assinatura digital no arquivo.
7.3 - Considerações Gerais
Uma das situações que devem ser consideradas na aplicação desse
estudo de caso é que desde a identificação do cliente até a finalização do pedido do
cliente as informações trocadas entre o navegador, lado cliente, e o servidor,
estavam sendo feita através da autenticação do servidor, com o protocolo “https://” e
conseqüentemente com o protocolo SSL. Este permitirá que as informações sejam
trafegadas em um canal seguro de comunicação e com isso o cliente durante o
processo de compra na loja enviará as mensagens e os arquivos XML assinados
digitalmente de forma confidencial aos seus destinos.
71
Outra situação importante a ser explicada é que a validação da integridade
do conteúdo dos arquivos XML está sendo feita a partir da chave pública do
certificado que se encontra no próprio arquivo XML. Por sua vez, o elemento KeyInfo
da especificação XML não é obrigatório e com isso poderia não existir a chave
pública do certificado no arquivo. Sendo assim, a chave pública para validação da
assinatura digital dos arquivos seria capturada do certificado digital durante a
negociação SSL no destino, ou seja, ao chegar no servidor da loja e no servidor da
operadora do cartão de crédito.
72
8 - CONCLUSÃO
Este trabalho demonstrou a importância do uso da tecnologia de
certificação digital em aplicações para Web, onde a cada dia vem sendo mais
aplicada, devido ao seu alto nível de segurança na proteção das informações
manipuladas por estas aplicações. Seja utilizando uma PKI Gerenciada dentro de
uma própria empresa ou de certificados digitais de servidor Web e de cliente para
uso em aplicações para Internet, como sendo os mais utilizados pelas pessoas
jurídicas e físicas.
Diante de uma implementação de uma aplicação de comércio eletrônico,
foi possível mostrar a utilização e a necessidade de uso de certificado digital em
aplicações, determinar em quais os momentos deveriam ser utilizados e exigidos um
certificado de servidor Web e certificado cliente para a troca de informações
confidenciais em um canal seguro de comunicação entre o cliente e o servidor, e a
ainda mostrar a assinatura digital em arquivos XML utilizando certificados digitais.
Isto porque o uso do protocolo SSL, ou seja, páginas Web com o protocolo “https://”
envolve um processamento extra pelo motivo de que os dados trafegados estarão
sempre sendo cifrados e decifrados e, por isso, deve-se saber em quais situações
da aplicação devem ser realmente necessários aplicados os certificados digitais.
Mas ainda é necessário, por exemplo, adotar políticas para distribuição de
certificados clientes bem como traçar estratégicas para dar conhecimento e
conscientização da importância desses certificados as pessoas físicas, ou seja,
pessoas que precisem trocar informações confidenciais com empresas virtuais
disponíveis na Internet com a total segurança transmitida pelo sistema de
certificação digital.
Atualmente, órgãos do governo como a receita federal e bancos já estão
disponibilizando a opção de acesso a seus sistemas on-line através da certificação
digital, mas ainda é clara a deficiência quanto à divulgação e a forma de distribuição
desses certificados aos contribuintes da receita e aos clientes de bancos.
Esta questão de distribuição é outro ponto que precisa ser analisado bastante. Por
exemplo, em nosso estudo de caso foi utilizado um certificado cliente no momento
do acesso a página que contém os dados do cartão de crédito, mas este foi obtido
73
diante da solicitação de um certificado de teste a autoridade certificadora Certisign
para demonstrar na aplicação como este tipo de certificado é utilizado e a sua
importância.
Na prática a distribuição desses certificados do tipo cliente aos clientes
das lojas virtuais deve ser da forma mais transparente possível para o cliente que for
fazer compras na loja, senão o que poderia acontecer era a loja começar a perder
seus clientes caso fosse grande a burocracia de uso deste certificado, sem contar
com o custo para obtenção destes certificados que deveriam ser pagos pela própria
loja. Além disso, o sistema de loja virtual deve dar a opção ao cliente de utilizar a
forma tradicional, sem certificado cliente, ou com a opção de utilização de certificado
digital, estas opções já são dadas atualmente por muitos bancos e órgãos do
governo. A diferença entre ambas as escolha estará no nível de segurança
estabelecido tanto para o cliente como para a o sistema da loja.
Outra situação encontrada com a certificação digital é a questão dos
certificados do tipo A3, ou seja, de Token USB ou de cartão SmartCard, apesar de
mais seguros, são mais caros. Além disso, nem todos os computadores têm porta
USB, apenas os mais novos, e, para cartão SmartCard tem-se que ficar
transportando a leitora deste cartão para onde se tenha a necessidade de uso deste
tipo de certificado. O problema maior é do cartão SmartCard e para contornar este
problema, já vem sendo discutida a possibilidade de tornar-se um padrão nacional
para teclados o acoplamento de uma leitora de cartão nos mesmos.
Diante dessas situações apresentadas, fica clara a importância da tomada
de decisão correta quanto ao tipo de certificação digital a ser adotado em qualquer
que seja a situação, analisando sempre o custo benefício na implantação do mesmo
em uma determinada aplicação.
A tendência nos próximos anos é que se tenha um crescimento na
utilização de certificados digitais, as pessoas deverão ter o conhecimento suficiente
a respeito do assunto através de trabalhos de divulgação, entendendo a
necessidade de utilização dos mesmos, e as empresas, por sua vez, deverão
encontrar meios que venham a facilitar a obtenção e manuseio desses certificados.
Além disso, o custo deverá ser reduzido pelas autoridades certificadoras
responsáveis pela emissão desses certificados, sejam eles do tipo A1, de software,
ou do tipo A3, de hardware.
74
Trabalhos futuros relacionados ao mesmo tema poderão ser
desenvolvidos para disponibilizar um framework, baseado em outros já existentes,
para aplicar técnicas de certificação digital que envolvam tanto certificados de
software como de hardware, dentre elas a de assinatura digital em mensagens e
arquivos. Estas técnicas serão fornecidas de forma bem encapsuladas e ao mesmo
tempo flexíveis, para que se torne fácil a utilização destas no desenvolvimento de
aplicações que, por sua vez, venham a incorporar a tecnologia de certificação digital.
75
REFERÊNCIAS BIBLIOGRÁFICAS
[1] CÂMARA BRASILEIRA DE COMÉRCIO ELETRÔNICO. Disponível em : <http://www.iconenet.com.br/cd/cd_guia.pdf>. Acesso em : 12/02/2006. [2] VIGNOLI, Fábio Lose. CRIPTOGRAFIA. 2002. Disponível em : <http://descartes.ucpel.tche.br/WFC/2002/01-cripto.pdf>. Acesso em : 12/02/2006. [3] LIMA, Marcelo Ferreira de. Assinatura Digital: Solução Delphi & CAPICOM. Florianópolis: Visual Books, 2005. [4] INSTITUTO NACIONAL DE TECNOLOGIA DA INFORMAÇÃO – ITI. O que é Certificação Digital?. Disponível em <http://www.iti.br/twiki/pub/Main/Cartilhas/brochura01.pdf>. Acesso em : 12/02/2006. [5] REZENDE, Pedro Antônio Dourado de. O que é Certificação Digital?. 2005. Disponível em <http://www.cic.unb.br/docentes/pedro/trabs/certdigital.html>. Acesso em : 17/02/2006. [6] MAIA, Luiz Paulo; PAGLIUSI, Paulo Sergio. Criptografia e Certificação Digital. Disponível em <http://www.training.com.br/lpmaia/pub_seg_cripto.htm>. Acesso em : 18/02/2006. [7] MARTINS, Alessandro. Autoridade Certificadora para Acesso Seguro. 2001. Disponível em : <http://www.lockabit.coppe.ufrj.br/downloads/academicos/CA.pdf>. Acesso em : 18/02/2006. [8] FUSCO, Camila. O que é um certificado digital?. 2006. Disponível em : <http://www.serpro.gov.br/noticiasSERPRO/20060215_02>. Acesso em : 18/02/2006. [9] CERTISIGN. Peticionamento Eletrônico. 2005. Disponível em : <http://www.certisign.com.br/solucoes/trt4/trt4_faq.jsp>. Acesso em : 18/02/2006. [10] SILVESTRE, Alexandre Higashi. Segurança na Internet e Certificação Digital. Disponível em: <http://www.acate.com.br/kit_imprensa/artigo_certificacao_digital.pdf>. Acesso em : 19/02/2006. [11] ALECRIM, Emerson. Criptografia. 2005. Disponível em:<http://www.infowester.com/criptografia.php>. Acesso em : 21/02/2006. [12] ALECRIM, Emerson. Criptografia. 2005.
76
Disponível em:< http://www.infowester.com/assincertdigital.php>. Acesso em : 23/02/2006. [13] MARTINS, Alessandro. Autoridade Certificadora para acesso seguro. 2001. Disponível em: <http://www.lockabit.coppe.ufrj.br/downloads/academicos/CA.pdf>. Acesso em : 26/02/2006. [14] CERTISIGN. Primeira Leitura sobre Certificação Digital. Disponível em: <https://www.certisign.com.br/treinamento/guia_cert_digital_down.jsp>. Acesso em : 26/02/2006 [15] CERTISIGN. Identidade Digital. Disponível em: <http://www.certisign.com.br/produtos/id/id_aplicacoes.jsp>. Acesso em : 01/03/2006. [16] SILVA, Lino Sarlo da. Public Key Infrastructure – PKI. Novatec, 2004. [17] ALBUQUERQUE, Fernando. TCP/IP Internet - Protocolos & Tecnologias. Axcel Books, 1999. [18] MICROSOFT BRASIL. Descrição de handshake por Secure Sockets Layer (SSL). 2003. Disponível em: <http://support.microsoft.com/default.aspx?scid=kb%3Bpt%3B257591>. Acesso em : 08/03/2006. [19] BARBOSA, Marcelo. Java Cryptography Architecture. 2001. Disponível em: <http://www.di.uminho.pt/~jmv/CriptografiaAplicada/CA-Pratica-I.pdf>. Acesso em : 25/03/2006. [20] DESTRO, Daniel. Trabalhando com encriptação e assinatura digital. 2004. Disponível em : <http://www.guj.com.br/java.tutorial.artigo.141.1.guj>. Acesso em : 27/03/2006. [21] SUN MICROSYSTEMS. Java Cryptography Architecture - API Specification & Reference. 2004. Disponível em: <http://java.sun.com/j2se/1.5.0/docs/guide/security/CryptoSpec.html>. Acesso em : 29/03/2006. [22] SUN MICROSYSTEMS. keytool - Key and Certificate Management Tool. 2002. Disponível em: <http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html>. Acesso em : 29/03/2006 [23] W3C – WORD WIDE WEB CONSORTIUM. XML-Signature Syntax and Processing. 2002. Disponível em: <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/Overview.html>.
77
Acesso em : 02/04/2006. [24] TOBAR NETO, Heres Edison Valdivieso. XML SECURITY NA PLATAFORMA .NET. 2004. Disponível em: <http://www.ulbra-to.br/ensino/43020/artigos/relatorios2004-2/Arquivos/Heres_TCC.pdf>. Acesso em : 02/04/2006.
78
ANEXO I - CLASSES DO PROJETO DO ESTUDO DE CASO Pacote entidades :
Cliente.java package br.com.projetoWeb.entidades; /** * <p>Title: Projeto do Estudo de Caso da Monografia</p> * <p>Description: Classe Cliente </p> * <p>Copyright: Copyright (c) 2006</p> * <p>Company: UNIT - Universidade Tiradentes</p> * @author Samuel Vasconcellos Serra * @version 1.0 */ public class Cliente { private String login; private String senha; private String nome; private String cpf; private String telefone; private String endereco; public Cliente() { } public Cliente(String login, String senha, String nome, String cpf, String telefone, String endereco) { this.login = login; this.senha = senha; this.nome = nome; this.cpf = cpf; this.telefone = telefone; this.endereco = endereco; } public String getCpf() { return cpf; } public void setCpf(String cpf) { this.cpf = cpf; } public String getEndereco() { return endereco; } public void setEndereco(String endereco) { this.endereco = endereco; }
79
public String getNome() { return nome; } public void setNome(String nome) { this.nome = nome; } public String getTelefone() { return telefone; } public void setTelefone(String telefone) { this.telefone = telefone; } public String getSenha() { return senha; } public void setSenha(String senha) { this.senha = senha; } public String getLogin() { return login; } public void setLogin(String login) { this.login = login; } }
Produto.java package br.com.projetoWeb.entidades; /** * <p>Title: Projeto do Estudo de Caso da Monografia</p> * <p>Description: Classe Produto </p> * <p>Copyright: Copyright (c) 2006</p> * <p>Company: UNIT - Universidade Tiradentes</p> * @author Samuel Vasconcellos Serra * @version 1.0 */ public class Produto { private int codigo; private String descricao; private String detalhe; private String figura; private int valor; public Produto() { }
80
public Produto(int codigo, String descricao, String detalhe, String figura, int valor) { this.codigo = codigo; this.descricao = descricao; this.detalhe = detalhe; this.figura = figura; this.valor = valor; } public int getCodigo() { return codigo; } public void setCodigo(int codigo) { this.codigo = codigo; } public String getDescricao() { return descricao; } public void setDescricao(String descricao) { this.descricao = descricao; } public int getValor() { return valor; } public void setValor(int valor) { this.valor = valor; } public String getDetalhe() { return detalhe; } public void setDetalhe(String detalhe) { this.detalhe = detalhe; } public String getFigura() { return figura; } public void setFigura(String figura) { this.figura = figura; } }
Item.java
package br.com.projetoWeb.entidades; /** * <p>Title: Projeto do Estudo de Caso da Monografia</p>
81
* <p>Description: Classe de item do carrinho de compras </p> * <p>Copyright: Copyright (c) 2006</p> * <p>Company: UNIT - Universidade Tiradentes</p> * @author Samuel Vasconcellos Serra * @version 1.0 */ public class Item { private int nrSeq; private Produto produto; private int quantidade; public Item() { } public Item(int nrSeq, Produto produto, int quantidade) { this.nrSeq = nrSeq; this.produto = produto; this.quantidade = quantidade; } public Produto getProduto() { return produto; } public void setProduto(Produto produto) { this.produto = produto; } public int getQuantidade() { return quantidade; } public void setQuantidade(int quantidade) { this.quantidade = quantidade; } public int getSeq() { return nrSeq; } public void setSeq(int nrSeq) { this.nrSeq = nrSeq; } }
PedidoItens.java package br.com.projetoWeb.entidades; /** * <p>Title: Projeto do Estudo de Caso da Monografia</p> * <p>Description: Classe de Pedido dos itens referente ao carrinho de compras </p> * <p>Copyright: Copyright (c) 2006</p>
82
* <p>Company: UNIT - Universidade Tiradentes</p> * @author Samuel Vasconcellos Serra * @version 1.0 */ import java.util.ArrayList; import java.util.List; public class PedidoItens { private int codigo; private Cliente cliente; private List itens; public PedidoItens() { this.itens = new ArrayList(); } public void addItem(Item item) { this.itens.add(item); } public Cliente getCliente() { return cliente; } public void setCliente(Cliente cliente) { this.cliente = cliente; } public int getCodigo() { return codigo; } public void setCodigo(int codigo) { this.codigo = codigo; } public List getItens() { return itens; } public void setItens(ArrayList itens) { this.itens = itens; } }
CartaoCredito.java
package br.com.projetoWeb.entidades; /** * <p>Title: Projeto do Estudo de Caso da Monografia</p> * <p>Description: Classe de Cartao de Credito </p> * <p>Copyright: Copyright (c) 2006</p> * <p>Company: UNIT - Universidade Tiradentes</p> * @author Samuel Vasconcellos Serra * @version 1.0 */
83
public class CartaoCredito { private String nomeTitular; private String nrCartao; private String dtValidade; private String codSeguranca; public CartaoCredito() { } public CartaoCredito(String nomeTitular, String nrCartao, String dtValidade, String codSeguranca) { this.nomeTitular = nomeTitular; this.nrCartao = nrCartao; this.dtValidade = dtValidade; this.codSeguranca = codSeguranca; } public String getCodSeguranca() { return codSeguranca; } public String getDtValidade() { return dtValidade; } public String getNomeTitular() { return nomeTitular; } public String getNrCartao() { return nrCartao; } public void setCodSeguranca(String codSeguranca) { this.codSeguranca = codSeguranca; } public void setDtValidade(String dtValidade) { this.dtValidade = dtValidade; } public void setNomeTitular(String nomeTitular) { this.nomeTitular = nomeTitular; } public void setNrCartao(String nrCartao) { this.nrCartao = nrCartao; } }
84
Pacote objetoXML :
ObjetoXML.java package br.com.projetoWeb.objetoXML; import java.io.FileWriter; import com.thoughtworks.xstream.XStream; import br.com.projetoWeb.entidades.*; /** * <p>Title: Projeto do Estudo de Caso da Monografia</p> * <p>Description: Classe responsável pelo mapeamento de um objeto em
arquivo XML </p> * <p>Copyright: Copyright (c) 2006</p> * <p>Company: UNIT - Universidade Tiradentes</p> * @author Samuel Vasconcellos Serra * @version 1.0 */ public class ObjetoXML { Object objetoXml = null; String nomeArquivoXML = null; public ObjetoXML(Object objetoXml, String nomeArquivoXML) { this.objetoXml = objetoXml; this.nomeArquivoXML = nomeArquivoXML; } public String getNomeArquivoXML() { return this.nomeArquivoXML; } public void gerarXML() throws Exception { // Configurando o XStream XStream xstream = new XStream(); xstream.alias("Pedido", PedidoItens.class); xstream.alias("Cliente", Cliente.class); xstream.alias("Produto", Produto.class); xstream.alias("Item", Item.class); xstream.alias("CartaoCredito", CartaoCredito.class); String cab = "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n"; // Passando os dados de Objetos Java para XML FileWriter writer = new FileWriter(nomeArquivoXML); writer.write(cab); xstream.toXML(objetoXml, writer); } }
85
Pacote assinaturaXML :
AssinarXML.java package br.com.projetoWeb.assinaturaXML; import java.io.File; import java.io.FileInputStream; import java.io.FileOutputStream; import java.util.Enumeration; import java.security.KeyStore; import java.security.PrivateKey; import java.security.cert.X509Certificate; import org.apache.xml.security.signature.XMLSignature; import org.apache.xml.security.transforms.Transforms; import org.apache.xml.security.utils.Constants; import org.apache.xml.security.utils.XMLUtils; import org.w3c.dom.Element; import org.w3c.dom.NodeList; /** * <p>Title: Projeto do Estudo de Caso da Monografia</p> * <p>Description: Classe responsável pela assinatura digital em um arquivo
XML </p> * <p>Copyright: Copyright (c) 2006</p> * <p>Company: UNIT - Universidade Tiradentes</p> * @author Samuel Vasconcellos Serra * @version 1.0 */ public class AssinarXML { String pathCertificado = null; String arquivoXML = null; String nomeArquivoAssinado = null; String tagPrincipalXML = null; public AssinarXML(String pathCertificado, String arquivoXML, String nomeArquivoAssinado, String tagPrincipalXML) { this.pathCertificado = pathCertificado; this.arquivoXML = arquivoXML; this.nomeArquivoAssinado = nomeArquivoAssinado; this.tagPrincipalXML = tagPrincipalXML; } public boolean assinar() throws Exception { try { Constants.setSignatureSpecNSprefix(""); //certificados/Cert_Certisign.pfx String keystoreFile = pathCertificado; String keystorePass = "123"; String privateKeyPass = "123";
86
String certificateAlias = null; File arquivoAssinado = new File(nomeArquivoAssinado); KeyStore ks = KeyStore.getInstance("PKCS12"); FileInputStream fis = new FileInputStream(keystoreFile); ks.load(fis, keystorePass.toCharArray()); Enumeration aliasCert = ks.aliases(); if (aliasCert.hasMoreElements()) certificateAlias = (String) aliasCert.nextElement(); PrivateKey privateKey = (PrivateKey) ks.getKey(certificateAlias, privateKeyPass.toCharArray()); javax.xml.parsers.DocumentBuilderFactory dbf = javax.xml.parsers.DocumentBuilderFactory.newInstance(); dbf.setNamespaceAware(true); javax.xml.parsers.DocumentBuilder db = dbf.newDocumentBuilder(); org.w3c.dom.Document docXML = db.parse(new
FileInputStream(arquivoXML)); NodeList nodeTeste = docXML.getElementsByTagName(tagPrincipalXML); Element rootTeste = (Element) nodeTeste.item(0); XMLSignature sig = new XMLSignature(docXML, nomeArquivoAssinado,
XMLSignature.ALGO_ID_SIGNATURE_RSA); rootTeste.appendChild(sig.getElement()); { Transforms transforms = new Transforms(docXML); transforms.addTransform(Transforms.TRANSFORM_ENVELOPED_SIGNATURE); transforms.addTransform(Transforms.TRANSFORM_C14N_WITH_COMMENTS); sig.addDocument("", transforms, Constants.ALGO_ID_DIGEST_SHA1); } { X509Certificate cert = (X509Certificate) ks.getCertificate(certificateAlias); sig.addKeyInfo(cert); sig.addKeyInfo(cert.getPublicKey()); sig.sign(privateKey); } FileOutputStream f = new FileOutputStream(arquivoAssinado); XMLUtils.outputDOMc14nWithComments(docXML, f); f.close(); return true; } catch (Exception ex) { return false; } } static { org.apache.xml.security.Init.init(); } }
87
ValidarXML.java
package br.com.projetoWeb.assinaturaXML; import java.io.File; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.security.PublicKey; import java.security.Principal; import java.security.cert.X509Certificate; import org.apache.xml.security.keys.KeyInfo; import org.apache.xml.security.signature.XMLSignature; import org.apache.xml.security.utils.Constants; import org.apache.xml.security.utils.XMLUtils; import org.apache.xpath.XPathAPI; import org.w3c.dom.Element; /** * <p>Title: Projeto do Estudo de Caso da Monografia</p> * <p>Description: Classe de validaçao da assinatura digital de um arquivo XML </p> * <p>Copyright: Copyright (c) 2006</p> * <p>Company: UNIT - Universidade Tiradentes</p> * @author Samuel Vasconcellos Serra * @version 1.0 */ public class ValidarXML { String nomeArquivoAssinado = null; public ValidarXML(String nomeArquivoAssinado) { this.nomeArquivoAssinado = nomeArquivoAssinado; } public String validar() { javax.xml.parsers.DocumentBuilderFactory dbf = javax.xml.parsers.DocumentBuilderFactory.newInstance(); dbf.setNamespaceAware(true); dbf.setAttribute("http://xml.org/sax/features/namespaces",
Boolean.TRUE); String mensagem = null; try { File arquivoAssinado = new File(nomeArquivoAssinado); mensagem = "Iniciando a validação do arquivo " +
arquivoAssinado.getName() + "\n\n"; javax.xml.parsers.DocumentBuilder db = dbf.newDocumentBuilder(); db.setErrorHandler(new org.apache.xml.security.utils .IgnoreAllErrorHandler());
88
org.w3c.dom.Document docXML = db.parse(new java.io.FileInputStream( arquivoAssinado)); Element nscontext = XMLUtils.createDSctx(docXML, "ds", Constants.SignatureSpecNS); Element sigElement = (Element) XPathAPI.selectSingleNode(docXML, "//ds:Signature[1]", nscontext); XMLSignature signature = new XMLSignature(sigElement, nomeArquivoAssinado); KeyInfo ki = signature.getKeyInfo(); mensagem = mensagem + "Verificando a existência do elemento KeyInfo...\n\n"; if (ki != null) { if (ki.containsX509Data()) mensagem = mensagem + "Foi encontrado o elemento X509Data no KeyInfo\n\n"; X509Certificate cert = signature.getKeyInfo().getX509Certificate(); try { cert.checkValidity(); } catch (Exception ex) {
mensagem = mensagem + "A data de validade do certificado expirou\n\n";
} if (cert != null) { mensagem = mensagem + "Validando a assinatura digital através do
elemento X509 Certificate...\n\n"; if (signature.checkSignatureValue(cert)) mensagem = mensagem + "Assinatura validada com sucesso através
do elemento X509 Certificate\n\n"; else mensagem = mensagem + "O conteúdo do documento assinado foi alterado\n\n"; } else { mensagem = mensagem + "Não foi encontrado o elemento X509
Certificate no arquivo XML\n\n"; PublicKey pk = signature.getKeyInfo().getPublicKey(); if (pk != null) { mensagem = mensagem + "Validando a assinatura digital através do elemento KeyValue que contém a chave pública ...\n\n"; if (signature.checkSignatureValue(pk)) mensagem = mensagem + "Assinatura validada com sucesso através da chave pública do certificado\n\n"; else { mensagem = mensagem + "Chave pública do certificado
inválida\n\n"; } } else
89
mensagem = mensagem + "Não foi encontrada a chave pública do certificado no arquivo XML\n\n";
} } else mensagem = mensagem + "Elemento KeyInfo não encontrado para
validaçao do arquivo XML \n\n"; mensagem = mensagem + "Fim da validação do arquivo\n\n"; return mensagem; } catch (Exception ex) { mensagem = "Ocorreu um erro ao tentar validar a assinatura digital do arquivo XML\n\n"; return mensagem + ex.getMessage(); } } static { org.apache.xml.security.Init.init(); } }
Pacote persistência :
AcessoBD.java package br.com.projetoWeb.persistencia; import java.util.*; import java.sql.*; import br.com.projetoWeb.entidades.*; /** * <p>Title: Projeto do Estudo de Caso da Monografia</p> * <p>Description: Classe de persistência e consulta no banco de dados * para produtos para Clientes e Produtos utilizando * o banco de dados HSQLDB </p> * <p>Copyright: Copyright (c) 2006</p> * <p>Company: UNIT - Universidade Tiradentes</p> * @author Samuel Vasconcellos Serra * @version 1.0 */ public class AcessoBD { private String url = "jdbc:hsqldb:db/LojaVirtual"; private String usuario = "sa"; private String senha = ""; private Connection conn = null;
90
public AcessoBD() throws ClassNotFoundException { Class.forName("org.hsqldb.jdbcDriver"); } public void conectar() throws SQLException { conn = DriverManager.getConnection(url, usuario, senha); } public Cliente getCliente(String loginCliente) throws SQLException { PreparedStatement stmt = null; Cliente cliente = null; try { String sql = "select login, senha, nome, cpf, telefone, endereco" + " from tb_cliente where login = ?"; stmt = conn.prepareStatement(sql); stmt.setString(1, loginCliente); ResultSet rslt = stmt.executeQuery(); if (rslt.next()) { String login = rslt.getString("login"); String senha = rslt.getString("senha"); String nome = rslt.getString("nome"); String cpf = rslt.getString("cpf"); String telefone = rslt.getString("telefone"); String endereco = rslt.getString("endereco"); cliente = new Cliente(login, senha, nome, cpf, telefone, endereco); } rslt.close(); stmt.close(); } catch (SQLException ex) { throw ex; } return cliente; } public Collection getClientes() throws SQLException { PreparedStatement stmt = null; Collection col = new LinkedList(); try { String sql = "select login, nome, senha, cpf, telefone, endereco " + "from tb_cliente"; stmt = conn.prepareStatement(sql); ResultSet rslt = stmt.executeQuery(); while (rslt.next()) { String login = rslt.getString("login"); String senha = rslt.getString("senha"); String nome = rslt.getString("nome"); String cpf = rslt.getString("cpf"); String telefone = rslt.getString("telefone"); String endereco = rslt.getString("endereco"); Cliente cliente = new Cliente(login, senha, nome, cpf, telefone, endereco); col.add(cliente); } rslt.close(); stmt.close(); } catch (SQLException ex) { throw ex; } return col; }
91
public void criarTabelaProduto() throws SQLException { Statement stmt = conn.createStatement(); String sql = "CREATE TABLE TB_PRODUTO (" + "Codigo Integer NOT NULL PRIMARY KEY, " + "Descricao VARCHAR(40) NOT NULL, " + "Detalhe VARCHAR(250) NOT NULL, " + "Valor int NOT NULL " + ")"; stmt.executeUpdate(sql); stmt.close(); } public Produto getProduto(int codigo) throws SQLException { PreparedStatement stmt = null; Produto produto = null; try { String sql = "select codigo, descricao, detalhe, figura, valor from tb_produto where Codigo = ?"; stmt = conn.prepareStatement(sql); stmt.setInt(1, codigo); ResultSet rslt = stmt.executeQuery(); if (rslt.next()) { int cod = rslt.getInt("codigo"); String descricao = rslt.getString("descricao"); String detalhe = rslt.getString("detalhe"); String figura = rslt.getString("figura"); int valor = rslt.getInt("valor"); produto = new Produto(cod, descricao, detalhe, figura, valor); } rslt.close(); stmt.close(); } catch (SQLException ex) { throw ex; } return produto; } public Collection getProdutos() throws SQLException { PreparedStatement stmt = null; Collection col = new LinkedList(); try { String sql = "select codigo, descricao, detalhe, figura, valor from TB_PRODUTO "; stmt = conn.prepareStatement(sql); ResultSet rslt = stmt.executeQuery(); while (rslt.next()) { int cod = rslt.getInt("codigo"); String descricao = rslt.getString("descricao"); String detalhe = rslt.getString("detalhe"); String figura = rslt.getString("figura"); int valor = rslt.getInt("valor"); Produto produto = new Produto(cod, descricao, detalhe, figura,
valor); col.add(produto); } rslt.close(); stmt.close();
92
} catch (SQLException ex) { throw ex; } return col; } public void inserirCliente(Cliente cliente) throws SQLException { PreparedStatement stmt = null; try { String sql = "INSERT INTO TB_CLIENTE VALUES(?,?,?,?,?,?)"; stmt = conn.prepareStatement(sql); stmt.setString(1, cliente.getLogin()); stmt.setString(2, cliente.getSenha()); stmt.setString(3, cliente.getNome()); stmt.setString(4, cliente.getCpf()); stmt.setString(5, cliente.getTelefone()); stmt.setString(6, cliente.getEndereco()); stmt.executeUpdate(); stmt.close(); } catch (SQLException ex) { throw ex; } } public void desconectar() throws SQLException { conn.close(); } }
93
ANEXO II - ARQUIVOS DO PROJETO DO ESTUDO DE CASO
Principais JSP’s :
LogicaAssinaXML.jsp <%@page import="br.com.projetoWeb.entidades.PedidoItens"%> <%@page import="br.com.projetoWeb.entidades.CartaoCredito"%> <%@page import="br.com.projetoWeb.assinaturaXML.AssinarXML"%> <%@page import="br.com.projetoWeb.objetoXML.ObjetoXML"%> <%@page import="java.io.FileInputStream"%> <%@ page contentType="text/html; charset=iso-8859-1" language="java" import="java.sql.*" errorPage="" %> <% /** * <p>Title: Projeto do Estudo de Caso da Monografia</p> * <p>Description: JSP responsável geração e assinatura digital do arquivo XML </p> * <p>Copyright: Copyright (c) 2006</p> * <p>Company: UNIT - Universidade Tiradentes</p> * @author Samuel Vasconcellos Serra * @version 1.0 */ %> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <body> <%@include file="conexao.jsp"%> <% String retorno = ""; try{ PedidoItens pedidoCliente = (PedidoItens) session.getAttribute("CarrinhoCompras"); pedidoCliente.setCodigo(0001); //Gerando o arquivo xml com os dados do pedido ObjetoXML objetoXml = new ObjetoXML(pedidoCliente, request.getRealPath("/arquivoXml/PedidoCliente.xml") ); objetoXml.gerarXML(); //Obtendo dados do Cartão String nomeTitular = request.getParameter("txtNomeTitular"); String nrCartao = request.getParameter("txtNrCartao");
94
String mesValidade = request.getParameter("cbxMesValidade"); String anoValidade = request.getParameter("cbxAnoValidade"); String mesAnoValidade = mesValidade + "/" + anoValidade; String codSeguranca = request.getParameter("txtCodSeguranca"); CartaoCredito cartaoCred = new CartaoCredito(nomeTitular, nrCartao, mesAnoValidade, codSeguranca); //Gerando o arquivo xml com os dados do cartão de crédito do cliente ObjetoXML objetoXmlCartao = new ObjetoXML(cartaoCred, request.getRealPath("/arquivoXml/CartaoCredito.xml") ); objetoXmlCartao.gerarXML(); //Obtendo o caminho do certificado digital no padrão PKCS12 String pathCertificado = request.getRealPath("/certificados/Cert_Cliente_SVS.pfx"); //Assinando o arquivo xml gerado com os dados do pedido String pathArqAssinadoPedido = request.getRealPath("/arquivoXml/PedidoClienteAssinado.xml"); AssinarXML assinarXMLPedido = new AssinarXML(pathCertificado, objetoXml.getNomeArquivoXML(), pathArqAssinadoPedido, "Pedido"); assinarXMLPedido.assinar(); //Assinando o arquivo xml gerado com os dados do cartão de crédito do cliente String pathArqAssinadoCartao = request.getRealPath("/arquivoXml/CartaoCreditoAssinado.xml"); AssinarXML assinarXMLCartao = new AssinarXML(pathCertificado, objetoXmlCartao.getNomeArquivoXML(), pathArqAssinadoCartao, "CartaoCredito"); assinarXMLCartao.assinar(); session.setAttribute("CarrinhoCompras", null); session.setAttribute("MensagemValidacaoArquivo", null); retorno = "sucessoPedidoCliente.jsp"; }catch(Exception ex){ retorno = "erroPedidoCliente.jsp"; } %> <jsp:forward page="<%=retorno%>"/> </body> </html>
LogicaValidaXML.jsp <%@page import="br.com.projetoWeb.assinaturaXML.ValidarXML"%> <%@page import="java.io.FileInputStream"%> <%@ page contentType="text/html; charset=iso-8859-1" language="java" import="java.sql.*" errorPage="" %>
95
<% /** * <p>Title: Projeto do Estudo de Caso da Monografia</p> * <p>Description: JSP responsável pela validaçao da assinatura digital nos arquivos XML </p> * <p>Copyright: Copyright (c) 2006</p> * <p>Company: UNIT - Universidade Tiradentes</p> * @author Samuel Vasconcellos Serra * @version 1.0 */ %> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <body> <%@include file="conexao.jsp"%> <% String mensagem = null; try{ String tipoValidaXml = request.getParameter("tipo"); if (tipoValidaXml.equals("Pedido")){ //Assinando o arquivo xml gerado com os dados do pedido String pathArqAssinadoPedido = request.getRealPath("/arquivoXml/PedidoClienteAssinado.xml"); ValidarXML validarXMLPedido = new ValidarXML(pathArqAssinadoPedido); mensagem = validarXMLPedido.validar(); }else{ //Assinando o arquivo xml gerado com os dados do cartão de crédito do cliente String pathArqAssinadoCartao = request.getRealPath("/arquivoXml/CartaoCreditoAssinado.xml"); ValidarXML validarXMLCartao = new ValidarXML(pathArqAssinadoCartao); mensagem = validarXMLCartao.validar(); } } catch(Exception ex){ mensagem = "Ocorreu um erro na validação do arquivo xml"; } session.setAttribute("MensagemValidacaoArquivo", mensagem); %> <jsp:forward page="mensagemArquivosXML.jsp"/> </body> </html>
96
CarrinhoCompras.jsp <%@page import="br.com.projetoWeb.entidades.Produto"%> <%@page import="br.com.projetoWeb.entidades.Item"%> <%@page import="br.com.projetoWeb.entidades.PedidoItens"%> <%@page import="java.util.Collection"%> <%@page import="java.util.Iterator"%> <%@ page contentType="text/html; charset=iso-8859-1" language="java" import="java.sql.*" errorPage="" %> <% /** * <p>Title: Projeto do Estudo de Caso da Monografia</p> * <p>Description: JSP responsável pela inclusão dos produtos no carrinho </p> * <p>Copyright: Copyright (c) 2006</p> * <p>Company: UNIT - Universidade Tiradentes</p> * @author Samuel Vasconcellos Serra * @version 1.0 */ %> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <body bgcolor="#FFFFFF"> <div align="center"><font color="#0000FF"><font color="#0000FF"> <table width="100%" border="0"> <tr bgcolor="#FFFFFF"> <td><font color="#0000FF"> <table width="100%" border="0"> <tr bgcolor="#FFFFFF"> <td colspan="5"><strong><font color="#6600FF" size="5">Carrinho de Compras</font></strong></td> </tr> <tr bgcolor="#FFFFFF"> <td colspan="5"><a href="produtosLoja.jsp">Página Inicial</a></td> </tr> <tr bgcolor="#FFFFFF"> <td width="17%"> <% String codProduto = request.getParameter("cdProduto"); PedidoItens carrinho = (PedidoItens)
session.getAttribute("CarrinhoCompras"); Item itemPed = null; Produto prod = null; if (codProduto != null){ int cdProduto = Integer.parseInt(codProduto); Produto produto = ad.getProduto(cdProduto); int ultimoSeqItem = 0; if (carrinho != null) ultimoSeqItem = Integer.parseInt( (String)
session.getAttribute("SequencialItem") ) + 1; else{ carrinho = new PedidoItens();
97
ultimoSeqItem = 1; } //Verificando se o produto já está no carrinho boolean existeProd = false; if (carrinho != null){ Iterator ite = carrinho.getItens().iterator(); while ( ite.hasNext() ) { itemPed = (Item) ite.next(); prod = itemPed.getProduto(); if (prod.getCodigo() == cdProduto ) existeProd = true; } } //Verificando se o produto já está no carrinho if (!existeProd) { carrinho.addItem( new Item(ultimoSeqItem, produto, 1) ); session.setAttribute("CarrinhoCompras", carrinho); session.setAttribute("SequencialItem",
String.valueOf(ultimoSeqItem) ); } } %> </td> <td width="22%"> </td> <td width="21%"> </td> <td width="17%"> </td> <td width="23%"> </td> </tr> <tr bgcolor="#FFFFFF"> <td colspan="5"> <div align="center"> <table width="100%" border="0"> <tr> <td width="41%"><strong><a href="produtosLoja.jsp"><img src="imagens/botao_continuarcompra.gif" width="89" height="31" border="0" alt=""></a></strong></td> <td width="20%"><div align="center"><img src="imagens/botao_recalcular.gif" width="92" height="31" alt=""></div></td> <td width="39%"><div align="right"><a href="identificacaoCliente.jsp"><img src="imagens/botao_finalizarcompra.gif" width="117" height="31" border="0" alt=""></a></div></td> </tr> </table> </div> <div align="center"><strong></strong></div></td> </tr> <tr bgcolor="#FFFFFF"> <td colspan="5"><table width="100%" border="0"> <tr bgcolor="#6600FF"> <td width="66%"> <div align="center"><font color="#FFFFFF"><strong><font size="2">PRODUTO</font></strong></font></div></td> <td width="6%"> <div align="center"><font color="#FFFFFF"><strong><font size="2">QTDE.</font></strong></font></div></td> <td width="10%"> <div align="center"><font color="#FFFFFF"><strong><font size="2">VALOR UNITÁRIO</font></strong></font></div></td>
98
<td width="7%"> <div align="center"><font color="#FFFFFF"><strong><font size="2">VALOR TOTAL</font></strong></font></div></td> <td width="11%"> <div align="center"><font color="#FFFFFF"><strong><font size="2">REMOVER ITEM</font></strong></font></div></td> </tr> <%@include file="conexao.jsp"%> <% //Listando os itens do carrinho int totalPedido = 0; if (carrinho != null) { Iterator ite = carrinho.getItens().iterator(); while ( ite.hasNext() ) { itemPed = (Item) ite.next(); prod = itemPed.getProduto(); totalPedido = totalPedido +
(prod.getValor()*itemPed.getQuantidade()); %> <tr> <td width="66%" height="81"> <div align="left"> <table width="100%" border="0"> <tr> <td width="22%" height="80"><strong><img src="imagens/<%=prod.getFigura()%>" width="93" height="68" alt=""> </strong></td> <td width="78%"><strong><font color="#6600FF" size="2"><%=prod.getDescricao()%></font></strong></td> </tr> </table> <strong></strong></div></td> <td width="6%"><div align="center"><strong><font color="#6600FF" size="2"> <input name="txtQtde" type="text" value=<%=itemPed.getQuantidade()%> size="4" maxlength="4"> </font></strong></div></td> <td width="10%"><div align="center"><strong><font color="#6600FF" size="2"><%=prod.getValor()%></font></strong></div></td> <td width="7%"><div align="center"><strong><font color="#6600FF" size="2"><%=prod.getValor()*itemPed.getQuantidade()%></font></strong></div></td> <td width="11%"><div align="center"><strong><font color="#6600FF" size="2"><a href="excluirItem.jsp?nrSeq=<%=itemPed.getSeq()%>">excluir</a></font></strong></div></td> </tr> <% } %> <% } %> </table></td> </tr> </table> </font></td> </tr> <tr bgcolor="#FFFFFF"> <td bgcolor="#FFFFFF"> </td> </tr> <tr bgcolor="#FFFFFF"> <td bgcolor="#FFFFFF"><table width="100%" border="0"> <tr bgcolor="#6600FF">
99
<td width="71%" bgcolor="#FFFFFF"> <div align="right"></div></td> <td width="29%"><font color="#FFFFFF" size="4"><strong> TOTAL : R$ <%=totalPedido%> </strong> </font></td> </tr> </table></td> </tr> </table> </font></font></div> </body> </html>
Exemplo do XML gerado e outro assinado pela aplicação da loja virtual contendo dados do cartão de crédito de um cliente que realizou uma compra.
CartaoCredito.xml
� ���������� �������� ���� ������������������
� �������������� �� ���� �������������������������������� ������������ � ������ ���������������� �������� �� �������!������������� � ��!���������� ����"���� ������� ���"���� �����
�� �������������
CartaoCreditoAssinado.xml
���������� �������� ���� ������������������-��������������� �� �������������������������������� ������������ �� ������ ���������������� �������� ����!��������������� ��!���������� �����"���� ������� ���"���� �����-��"�� �������� ������������������ ���������!"#$%& '���-��"�� ��# $��� ���� � �����%���� &��'���(�����'������������������� �(���������)!"#)*��+)
���������� ���
��"�� ����&��'���(�����'������������������� ���������!"#$%& '�%,)%�,��� ���-��)�$�� ���*)#�����-���� $���� ���� $���(�����'������������������� ���������!"#$%& '-+.-#��-$)
%& +,�/�-�� ��� ���� $���(�����'������������������� �(���������)!"#)*��+)
��������'0&���""-+�%�� ��� �� �� $����
��+����&��'���(�����'������������������� ���������!"#$%& '%�,��� ��� ��+����!�����(,�1*�23����-��4.&��5�+��3*6� +����!�������
�� )�$�� ���� �� "�� ��# $���
100
��"�� ����!������/"27"879�1��:%,;<<+�4�2=>��?�$��"�5�2@.>"A-9!2,�
���B�$����A.@����=. C�7?A�+&�;.D8B0:41�-+?#(�%E9A�B�C8����;C���>7
;B�;3 % >+��*���(1��C��?.B5?�&#���:.E���F �41�BF�<($�>6� "�� ��
��!�������-��,�-# $���-��.���+����� �
�.�������$�������7733(F4 ��7F� 75;<22�2�<3$2EA���A����(��F >D�>&
8���F�5�3�EF�E�/��8������#5��1$8#9,0$/7��#*+��C"#:=0�.*"�
�8#+,<��2F�$8���:�A�F�8����!�0�"�1,���C�� �4?�*�5 ("��$��1,
9���E�8����!���8�12<� 2�= $<�#783�78��$4F9&�.$�$��"�#*+��*�#+2&�:2��/=+7.�#FF7�:@(���(�� =E�55E�9�EC<?�,<��C�� 5�!�*�� ��
FE2��9$0�#*&F?2"��$"#>$03%73��=+�:*"#&C<7 5���4�*��E=��(���E��
�E��0�*��E=��9���:��(��0:�0�!@9��F ��F���7>�#*+����#+2&FE
C<?�,0C�=�3>2�?�7���C�#�=0� ���!�(�;F ��F�%���%=<�9C��!�(*��
5=E�55��1��C<?�*1F.C&F�*�� =<5 $�$��"�#*+��*�#+2&�:2��/=+7.�#FF7�
:@(���(��;5=E�55��9CF$<��C0��,0��$8�>78?�7��#*+��*�#+2&FEC<?�,
0C�=�3>2�?�7���C�#�=0� (4�>=��!?9�#F ��F�%(4>�#20?#*&� �"�1,���
C�� �4?�*�5 ("��$��1,9�-�F�8����!���8�1*��/=�F2�5 �"3%,0��
$8�>��%�85=E�55��!?�,0$�$83%7�#�7��%=<�97E�!79��F ��F��(8#�0�1
��7��#*+��C"#:=0�.78�#73�#*��#��*�?5=?@�C7�.*��5>F3��9=0��C0!�*��
1*"3�,8��203�2�:2��� C��E5=?@�C7�.*��5�FF5�E =���78?��8F���
�3@��$�,$%��&#-=EDE�?5�8��1! 28&��D:/�% 57?,��2!��, �!5�9�5�9
��?A� %4$�4.7,�������<��.�+�">$(,/@@+� &�*<%2E9"581�@�"!> F����%-A���D,F@<8�0#>#��1BE�7��>�!/�D�$/�4�:� �F��8: 3��77F�(�?F
��4����:���8*8���$4�� �3��<@F,�3&8�"��$4� �1�.2+��$8�:*"�/=
��1$8#9,0$/�"�.2��&*&�EC<?�,���C��EC<?�,0C�=�3>2�?��8#+,<��23�F5
�!�*��#����=<�#*��E�>�/=�?%�78%F ��4��� ,5� ,�� C�8�8��88B�
�FF��F�78� 8%8�5�3F�7F3�!�$4��*9�.��$�$1��C<?�*�#+2&�:2��.5
�F(�878%8�5�3F�7�3=�3�=�"�1,���C��%7�#/=1����7F�����"�1,
���C��+*1FE�3� ,0�:2�?��&F&�
-�F1C0C#*"�/=�� 28#�=&� 24�>�&��=1>��1F0C<?���#+2:��F # �> F�.��
5��F��F����5=@=7C7�=2��5�855E�54����8�D8�72�E5�FF5����8F
�8��-��.>�,E�5�!2�!B5� 9.BCC5+2:����+**&�D��<�=:��� 5?,B$,C#:�8�
;��.�>;�@�F����++%�;"9����@5 $!&/$9F#*<FD���3�=�F���D4����&
7;��C&�-7.���@ 9�"�?2. +1>$��(� 9��#:/;�� 0� .�������$�������� �� .���+�����
-��,�-!������-��)"(,�-!������
�&������9E=���3�3���1"@�� �;>#E%C<(�8F%,��/D��1E�� #�2C.43D
4�?F<;�EE;F5#�:D�$��-���49,&.��*��B/$�,���D��D-&��!-!%;C�2���1
28��4&3(&!��B+5�����*,�,0�<5.���;=&:(<8�����@�5A&�6� &�������� ��/�0� � ���5�F� /�0� � ����
�� )"(,�-!������ �� ,�-!������ �� ,�-# $��� �� "�� ������ �� ������������