Desenvolvimento de um portal para assinatura digital de arquivos

JHONATAS HENRIQUE DE LIMA MOTA
DESENVOLVIMENTO DE UM PORTAL PARA ASSINATURA
DIGITAL DE ARQUIVOS
Palmas – TO
2013

Jhonatas Henrique de Lima Mota
DIGITAL DE ARQUIVOS
Palmas – TO
2013
Trabalho de Conclusão do Curso de
Sistemas de Informação da Faculdade
Católica do Tocantins, apresentado como
parte dos requisitos para obtenção do
título de Bacharel em Sistemas de
Informação.
Orientadora: Me. Stephany Martins.

Jhonatas Henrique de Lima Mota
DIGITAL DE ARQUIVOS
Esta monografia foi julgada adequada pra obtenção do diploma de Bacharel em Sistemas
de Informação do curso de graduação em Sistemas de Informação da Faculdade Católica
do Tocantins.
Banca Examinadora
Assinatura do Orientador
Membros da Banca Examinadora
_________________________,_________/_____________________/_____________
Local e data de aprovação:
Nota: ________________

AGRADECIMENTOS
Primeiramente a Deus por mais essa conquista, por estar ao meu lado em todos os
momentos da minha vida, por se fazer presente a ponto de nunca ter me deixado sequer
sentir-me só.
A minha inigualável e querida família, pai, mãe, irmão, irmã e cunhada, que
souberam me entender nos momentos de ausência e estavam sempre comigo nos
momentos de descontração. Que me apoiaram durante toda minha caminhada provendo
carinho, força, incentivo, motivação e princípios.
A minha orientadora Me. Stephany Martins por exercer tão bem o dom de repassar
seu conhecimento, pela paciência com meus erros e teimosias e por ser uma pessoa tão
calma, compreensiva e prestativa.
A esta monografia, pela compreensão por não tela escrito antes, pois apesar da
necessidade de pausar por duas vezes o curso, ela me aguardou pacientemente durante sete
longos e trabalhosos anos para enfim nos encontrarmos e sermos parte do conjunto nessa
vitória.
Aos meus amigos, colegas e demais professores que contribuíram direta e
indiretamente com o conhecimento adquirido durante toda minha vida acadêmica.
A todos, meu muito obrigado!

Transportai um punhado de
terra todos os dias e fareis
uma montanha!
Confúcio

SUMÁRIO
1. INTRODUÇÃO ....................................................................................................................... 13
1.1. DEFINIÇÃO DO PROBLEMA............................................................................................... 14
1.2. JUSTIFICATIVA..................................................................................................................... 15
1.3. OBJETIVOS ............................................................................................................................ 16
1.3.1. Objetivo Geral.................................................................................................................. 16
1.3.2. Objetivos Específicos....................................................................................................... 16
1.4. ESTRUTURA DA MONOGRAFIA........................................................................................ 17
2. FUNDAMENTAÇÃO TEÓRICA ........................................................................................... 18
2.1. CRIPTOGRAFIA..................................................................................................................... 18
2.1.1. Criptografia Simétrica...................................................................................................... 19
2.1.2. Criptografia Assimétrica .................................................................................................. 20
2.2. FUNÇÃO DE HASH ............................................................................................................... 21
2.3. ASSINATURA DIGITAL ....................................................................................................... 22
2.4. CERTIFICADO DIGITAL ...................................................................................................... 24
2.5. CERTIFICADO DIGITAL X.509 ........................................................................................... 27
2.6. REVOGAÇÃO DE CERTIFICADOS DIGITAIS................................................................... 29
2.7. A INFRAESTRUTURA DE CHAVES PÚBLICAS BRASILEIRA ...................................... 30
3. METODOLOGIA .................................................................................................................... 33
3.1. TRABALHOS RELACIONADOS.......................................................................................... 34
3.1.1. Uma Abordagem da Infraestrutura de Chaves Públicas para Ambientes Corporativos... 34
3.1.2. Assinatura Digital No Processo Legislativo Da Câmara Dos Deputados ........................ 35
3.1.3. Assinatura Digital de Documentos Eletrônicos Através da Impressão Digital................ 36
3.2. FRAMEWORK DE DESENVOLVIMENTO WEB ............................................................... 37
3.3. BANCO DE DADOS............................................................................................................... 38

3.4. REQUISITOS FUNCIONAIS ................................................................................................. 39
3.5. REQUISITOS NÃO FUNCIONAIS........................................................................................ 39
3.6. MODELAGEM........................................................................................................................ 40
3.6.1. Diagramas de Classes....................................................................................................... 40
3.6.2. Diagramas de Casos de Uso............................................................................................. 41
4. VISÕES DO SISTEMA E CODIFICAÇÃO ........................................................................... 45
4.1. ARQUITETURA DO SISTEMA............................................................................................. 45
4.2. PADRÃO MVC ....................................................................................................................... 46
4.2.1. Modelo ............................................................................................................................. 47
4.2.2. Visão ................................................................................................................................ 47
4.2.3. Controlador ...................................................................................................................... 47
4.3. VISÕES DO SISTEMA........................................................................................................... 48
4.3.1. Modelo D001Pessoa......................................................................................................... 48
4.3.2. Modelo D002Certificado.................................................................................................. 55
4.3.3. Modelo D003Documento................................................................................................. 57
4.3.4. Modelo D004Assinatura .................................................................................................. 59
4.3.5. Modelo D005Compartilhamento...................................................................................... 62
4.4. CODIFICAÇÃO....................................................................................................................... 63
4.4.1. O processo de assinatura digital....................................................................................... 64
4.4.2. Verificação de Auto Assinatura ....................................................................................... 65
4.4.3. Verificação do Caminho de Certificação ......................................................................... 66
4.4.4. Verificação de Revogação do Certificado........................................................................ 66
4.4.5. Internacionalização........................................................................................................... 67
5. CONCLUSÕES E TRABALHOS FUTUROS........................................................................ 69
REFERÊNCIAS............................................................................................................................... 70

LISTA DE ABREVIATURAS E SIGLAS
AC – Autoridade Certificadora.
AES – Advanced Encryption Standart
AR – Autoridade de Registro.
ASN1 – Abstract Sintax Notation
DES – Data Encryption Standard
DH – Diffie e Hellman
HSM – Hardware Security Module
HTML – HyperText Markup Language
ICP – Infraestrutura de chaves publicas.
ID – Identificação do Usuário
IDE – Integrated Development Environment.
IPSec – Internet Protocol Security
ITI – Instituto de Tecnologia da Informação
ITU – International Telecommunication Union
LSB – Least Significant Bit
MD5 – Message Digest 5
MVC – Model View Controller.
NIST – National Institute of Standards and Technology
NSA – National Security Agency

OSCP – Online Certificate Status Protocol.
RAD – Rapid Application Development
RGB – Red, Green, Blue
RSA – Rivest Shamir Adleman
SGBD – Sistema Gerenciador De Banco De Dados
SHA – Secure Hash Algorithm
SSL – Secure Sockets Layer
UML – Unified Modeling Language
URL – Uniform Resource Locator
WPA – Wi-Fi Protected Access
XML – Extensible Markup Language

ÍNDICE DE FIGURAS
Figura 1 - Scytale ............................................................................................................................. 18
Figura 2 - Processo de criação e verificação da assinatura digital ................................................... 24
Figura 3 - Mídias criptográficas....................................................................................................... 26
Figura 4 - Certificado digital padrão X.509v3 ................................................................................. 29
Figura 5 - Estrutura resumida da ICP-Brasil.................................................................................... 32
Figura 6 - Diagramas de Classes...................................................................................................... 40
Figura 7 - Caso de uso do usuário não autenticado.......................................................................... 41
Figura 8 - Ações do usuário autenticado.......................................................................................... 42
Figura 9 - Caso de uso "Gerenciar Certificados" ............................................................................. 43
Figura 10 - Caso de uso “Gerenciar Documento”............................................................................ 43
Figura 11 - Caso de uso "Visualizar Perfil" ....................................................................................... 44
Figura 12 - Arquitetura de um sistema WEB................................................................................... 46
Figura 13 - Arquitetura MVC........................................................................................................... 48
Figura 14 - Visão [avatar] ................................................................................................................ 50
Figura 15 – Visão: [d001Pessoacreate]............................................................................................ 51
Figura 16 – Visão: [autenticação] .................................................................................................... 52
Figura 17 – Visão: [RecuperarAcesso] ............................................................................................ 52
Figura 18 - Visão: [show] do modelo [D001Pessoa] .................................................................... 53
Figura 19 - Visão: [convidar]........................................................................................................... 53
Figura 20 - Visão [dashboard] do modelo [D001Pessoa] ................................................................ 54
Figura 21 - Visão [Create] do modelo [D002Certificado] ............................................................... 56
Figura 22 - Visão [show] do modelo [D002Certificado] ................................................................. 56
Figura 23 - Visão [create] do modelo [D003Documento] ............................................................... 57
Figura 24 - Visão: [buscaDocumentos] do modelo [D003Documento]........................................... 58
Figura 25 - Visão [show] do modelo [D003Documento]................................................................. 59
Figura 26 - Visão [create] do modelo [D004Assinatura]................................................................. 60
Figura 27 - Visão [show] do modelo [D004Assinatura] .................................................................. 61
Figura 28 - Visão [create] do modelo [D005Compartilhamento] .................................................... 62
Figura 29 - Visão [show] do modelo [D005Compartilhamento] ..................................................... 63
Figura 30 - Demonstração do uso de Finders dinâmicos ................................................................. 64
Figura 31 - Codificação da assinatura digital do arquivo................................................................. 65
Figura 32 - Verificação de auto assinatura....................................................................................... 66
Figura 36 - Arquivos de internacionalização ................................................................................... 67

RESUMO
Nos últimos anos a quantidade de transações que deixaram o papel para se tornarem
digitais vem crescendo exponencialmente e em paralelo surgem problemas de
confiabilidade das informações envolvidas por se tratarem de dados trafegados em um
ambiente não seguro como a Internet. A assinatura digital pode ser utilizada para garantir a
confiabilidade dessas informações e contribuir para o processo eletrônico confiável. Este
trabalho propõe um portal para assinatura digital de arquivos, capaz de armazenar
documentos e a partir das informações lidas do certificado digital do usuário, efetuar a
assinatura digital do documento assim como a validação do certificado utilizado junto à
Autoridade Certificadora responsável, garantindo assim a validade jurídica do documento
depois de armazenado e assinado.
Palavras-Chave: Assinatura Digital. Portal para Assinaturas. Segurança da
Informação

ABSTRACT
In recent years the amount of transactions that left the paper to become digital has been
growing exponentially and in parallel there are reliability problems of the information
involved for treatment of traffic data in an unsafe environment such as the Internet. The
digital signature can be used to ensure the reliability of this information and contribute to
the reliable electronic process. This work proposes a portal for digital signature files
capable of storing documents and from the information read from the user's digital
certificate, the digital signature of the document as well as the validation of the certificate
used by the certification authority in charge, thus ensuring the legal validity of the
document after stored and signed.
Keywords: Digital Signature. Portal for subscriptions. Information security

13
1. INTRODUÇÃO
A preocupação com a segurança da informação cresce em paralelo ao surgimento da
percepção da necessidade das empresas em expandir seus negócios e levar seus produtos
ou serviços a mais pessoas independente de suas localizações geográficas. Com o uso das
redes de computadores e o advento da Internet, hoje uma informação pode passar a ser
conhecida por mais de um terço da população mundial em poucas horas. Só no Brasil o
número de usuários com acesso à Internet já passa dos 50,9 milhões de pessoas, segundo o
IBOPE Nielsen Online. Em março, o total de usuários ativos na Internet, tanto em casa
como no trabalho, cresceu 4,6% em relação a fevereiro, atingindo 53,9 milhões de pessoas.
Os dados são da pesquisa NetView, do IBOPE Media, e apontam crescimento de 8% na
comparação com março de 2012, quando o número de usuários ativos era de 49,7 milhões.
Dessa forma tornou-se extremamente importante e necessária a criação de métodos que
deem segurança ao tráfego de toda essa informação. Protocolos como o SSL, WPA e o
IPSec foram desenvolvidos para garantir a segurança da informação em seu tráfego, envio
e entrega na Internet. Segundo (Pinheiro, 2009, p. 228) os crimes virtuais vem crescendo
com o passar do tempo sendo que estes, em breve, ultrapassarão os crimes comuns (não
virtuais). Isso se deve ao fato de que o Brasil é o país com maior incidência de crimes
eletrônicos. Além disso, afirma (Pinheiro, 2009), isto vem ocorrendo devido a fatores
como a popularização da Internet, a falsa impressão de anonimato, a falta de
conscientização e a falta de informação aos usuários que utilizam blogs, fóruns e redes
sociais.
Uma das ferramentas utilizadas para garantir a segurança da informação é a assinatura
digital. Segundo (Machado, 2010), em 1976 Whitfield Diffie e Martin Hellman chegaram
ao algoritmo que poderia resolver o problema de entrega de chaves que ocorria na
criptografia simétrica. A partir de então a tecnologia de certificação digital vem crescendo
exponencialmente. Diversos segmentos da sociedade, dentro dos setores público e privado,
utilizam de maneira crescente a assinatura digital de documentos para seus procedimentos
diários. No Brasil a medida provisória nº 2.200-2 definiu o Instituto Nacional de
Tecnologia da Informação como responsável pela manutenção da infraestrutura de chaves
públicas Brasileira (ICP-Brasil). Segundo o próprio ITI de março de 2012 até março de
2013 foram emitidos 2.237.949 certificados digitais e com isso a tecnologia de certificação

14
digital vem tomando uma importância cada vez maior. A Medida Provisória 2.200-2, de
agosto de 2001, deu um importante incentivo à utilização da assinatura digital, ao dar
condição de presunção de veracidade com relação ao signatário ao documento digital
assinado sob a estrutura da ICPBrasil, como é possível ver no seguinte trecho:
" Art. 10. Consideram-se documentos públicos ou particulares, para todos
os fins legais, os documentos eletrônicos de que trata esta Medida Provisória.
§ 1o As declarações constantes dos documentos em forma eletrônica
produzidos com a utilização de processo de certificação disponibilizado pela
ICP-Brasil presumem-se verdadeiros em relação aos signatários, na forma do art.
131 da Lei no 3.071, de 1o de janeiro de 1916 - Código Civil.”
Dessa forma desde que em conformidade com os padrões definidos pela ICP-Brasil, a
assinatura digital passa a gozar um status de igualdade com a assinatura de próprio punho.
Ao longo deste trabalho poderemos observar que com o auxílio de tecnologias de
criptografia de dados como o RSA e o hash a assinatura digital pode contribuir
imensamente com a segurança da informação dando sentido à termos como, autenticação,
privacidade, autorização, integridade dos dados, não repúdio e formando o que hoje é
possível chamar de processo eletrônico confiável.
1.1. DEFINIÇÃO DO PROBLEMA
O problema consiste em encontrar uma plataforma grátis ou de baixo custo que
disponibilize aos usuários um espaço para armazenamento e a assinatura digital de
documentos, de acordo com as normas definidas pela ICP Brasil. Existem empresas, na
grande maioria detentoras do título de Autoridades Certificadoras, como a Certisign e Bry,
que juntamente com a comercialização do certificado digital disponibilizam uma
plataforma para gerenciamento e assinatura de documentos diversos, porém a um custo
inalcançável por pequenas empresas e profissionais liberais, chegando à mensalidade na
casa dos milhares de Reais, é o caso dos valores cobrados por sistemas como o Portal
Nacional do Documento Eletrônico e o Portal de Assinaturas Certisign.
Com o crescimento incontrolável do uso da Internet, o avanço da WEB 2.0 e a
popularização da Cloud Computing, a troca de arquivos eletrônicos por meio digital
cresceu na mesma proporção, gerando uma série de problemas de segurança quanto à

15
confiabilidade das informações contidas no arquivo. Na maioria dos casos as informações
são transmitidas pela Internet seguindo protocolos que em sua essência não efetuam a
proteção necessária dos dados que estão sendo transmitidos, tornando possível a leitura e
modificação de seu conteúdo por um terceiro que possua o mínimo de conhecimento sobre
o assunto. Utilizando a assinatura digital é possível verificar com garantias se uma
determinada informação chegou ao seu destinatário sem que seu conteúdo original tenha
sido alterado, alcançando assim o nível de confiabilidade necessário para que o documento
tenha sua validade comprovada. A função precípua da assinatura digital é a de elevar o
estado de segurança do documento assinado, atribuindo validade a seu conteúdo
independentemente da vinculação a um suporte físico (Gandini, Salomão, & Jacob, 2001).
Como visto, torna-se indispensável o fomento do uso da tecnologia de certificação digital,
fazendo com que esses documentos mesmo armazenados na nuvem e sem a necessidade de
impressão tenham validade Jurídica por serem acompanhados da garantia de sua
inalterabilidade.
1.2. JUSTIFICATIVA
Todo profissional e uma grande parte das pessoas físicas em algum momento tiveram a
necessidade de reconhecer firma em um documento. Em pesquisa de campo feita na cidade
de Palmas – TO em junho de 2013 pôde-se calcular uma média de R$ 4,50 (quatro reais e
cinquenta centavos) por firma reconhecida nos cartórios da cidade. Considerando um
deslocamento de cinco quilômetros até o cartório mais próximo em um carro que consome
um litro de gasolina a cada doze quilômetros percorridos, o consumo seria de 416ml
(quatrocentos e dezesseis) mililitros de combustível. Com o preço da gasolina variando
atualmente em torno de R$ 3,05 (três reais e cinco centavos), o valor gasto com
deslocamento seria de R$ 1,25 (um real e vinte e cinco centavos). Somando o valor do
descolamento de ida e volta com o serviço de reconhecimento de firma no cartório, o valor
final da assinatura não passaria dos R$ 7,00 (sete reais).
No Brasil, temos dois reconhecidos portais para assinatura digital de arquivos, são eles, o
Portal de Assinaturas da empresa Certisign e o Portal Nacional do Documento Eletrônico
da empresa QualiSoft. O valor cobrado por assinatura em um documento eletrônico é de
R$ 10,80 (dez reais e oitenta centavos) e R$ 9,65 (nove reais e sessenta e cinco centavos)
respectivamente. O valor é consideravelmente maior que uma assinatura reconhecida em

16
cartório considerando ainda o gasto com deslocamento. A diferença dos valores tende a ser
cada vez maior de acordo com o número de assinaturas diárias.
Portanto, profissionais liberais e pessoas físicas com um certificado digital próprio
possuem hoje provavelmente nenhuma forma de armazenar e assinar seus documentos na
Internet de forma gratuita ou a um baixo custo. O portal para assinaturas AssineDocs será
mantido por doações e patrocínios, dessa forma será possível disponibilizar gratuitamente a
resolução do problema citado, provendo a redução de custos pela extinção de remessas de
documentos enviadas por Correios, a agilidade na formalização de contratos e documentos
diversos que precisam ser assinados, extinguir a necessidade de guarda física em arquivos,
armários e cofres e ainda fomentar o uso da tecnologia de certificação digital, servindo à
sociedade, contribuindo com a inclusão digital, garantindo a segurança, autenticidade,
integridade e não repúdio dos documentos, promovendo a mobilidade e ainda através da
redução do uso de papel, cartuchos de tinta e toner poder contribuir com a preservação do
meio ambiente. Esses foram os fatos justificantes e motivadores para a realização desta
monografia.
1.3. OBJETIVOS
1.3.1. Objetivo Geral
Construir um portal de acesso gratuito para assinatura digital e armazenamento de
documentos, possibilitando múltiplas assinaturas e o compartilhamento gerenciável dos
documentos armazenados.
1.3.2. Objetivos Específicos
 Armazenar documentos possibilitando o gerenciamento de permissões para
assinatura e compartilhamento.
 Permitir o convite de novos usuários pelos usuários atuais
 Efetuar a certificação da validade do certificado através de seu emissor.
 Informar o status da revogação do certificado utilizado no momento da
assinatura.
 Difundir de forma gratuita a tecnologia e fomentar seu o uso por pessoas
físicas.

17
1.4. ESTRUTURA DA MONOGRAFIA
A seção dois desse trabalho mostrará a fundamentação teórica desde os principais
conceitos que envolvem a assinatura digital até sua aplicabilidade em diversos setores da
sociedade. A metodologia será apresentada na seção três, listando e descrevendo diversos
pontos sobre as ferramentas, métodos e procedimentos utilizados neste trabalho. A seção
quatro apresentará a prototipação de telas do sistema proposto, bem como os principais
trechos de código utilizados no processo de assinatura e gestão dos recursos e
funcionalidades do portal. E, por fim, a seção cinco trará as conclusões e os trabalhos
futuros.

18
2. FUNDAMENTAÇÃO TEÓRICA
Nessa seção será apresentada toda tecnologia relacionada à assinatura digital, desde o
processo de criptografia até a legislação vigente e aplicável na infraestrutura de chaves
públicas.
2.1. CRIPTOGRAFIA
Segundo (Stallings, 2008, p. 16),
“Criptologia é o estudo das técnicas para garantir o sigilo e/ou a autenticidade da
informação. Os dois ramos principais da criptologia são a criptografia, que é o
estudo do projeto dessas técnicas; e a Criptoanálise, que trata das formas de
reverter essas técnicas, recuperar informações ou forjar informações que serão
aceitas como autênticas”.
A criptografia teve seu início a milhares de anos atrás, pois assim que a comunicação
escrita foi popularizada surgiu a necessidade de encontrar meios para garantir a
confidencialidade das comunicações. Uma das formas encontradas para criptografia de
textos foi o Scytale (Machado, 2010), mostrado na figura 1, que consistia em uma vara
onde o emissor enrolava um pedaço de papel à sua volta e escrevia a mensagem
longitudinalmente. A decriptação ou desembaralhamento da mensagem sem o
conhecimento do comprimento e bitola das varas utilizadas à época era considerado
impossível.
Figura 1 - Scytale

19
"Podemos atribuir as primeiras utilizações de métodos técnicos para encriptar (embaralhar)
as mensagens aos antigos gregos, em meados do séc. VI A.C." (Machado, 2010).
Na época juntamente com o Scytale surgiram outras formas de criptografia, como a escrita
ao contrário e a substituição mono alfabética, sendo esta última atribuída ao imperador
romano Júlio Cesar e consistia em quatro fases, a primeira era relacionar as vinte e seis
letras do alfabeto com um número que representava sua posição na sequência de letras,
depois se escolhia um número qualquer e o enviava ao destinatário como chave, então se
somava o valor escolhido como chave ao número representante de cada letra e em seguida
convertia-se o número resultante em letra, obedecendo sempre a ordem alfabética. Dessa
forma a palavra JHONATAS cifrada pelo método de Júlio Cesar e utilizando a chave
5(cinco) resultaria em: OMTSFYFX.
Outras pessoas importantes tiveram suas contribuições para a criptografia com o passar do
tempo, como o Duque de Mantua que inventou a Substituição Homofônica e Leon Baptista
com a Substituição Poli alfabética. A evolução continuou e no século XIX Kerchoffs
escreveu os princípios da criptografia como a conhecemos hoje, para logo no século XX
ser utilizada em grande escala para fins militares, pois com a ajuda das maquinas
disponíveis na época era possível cifrar e decifrar mensagens mais rapidamente, podendo
assim enviar estratégias à tropas distantes sem que o inimigo as compreendesse. (Machado,
2010)
2.1.1. Criptografia Simétrica
A criptografia simétrica, também chamada de criptografia convencional ou criptografia de
chave única, era o único tipo de criptografia em uso antes do desenvolvimento da
criptografia por chave pública na década de 1970. Esse continua sendo, de longe, o mais
usado dos dois tipos de criptografia (Stallings, 2008, p. 18). O processo de criptografia
simétrica possui cinco ingredientes básicos, que são: o texto claro que é a mensagem
original e inteligível que deverá ser codificada, o algoritmo de criptografia, a chave secreta
que é um valor informado ao algoritmo que por sua vez a utilizará como base para o
cálculo da codificação, o texto cifrado que é a mensagem cifrada, produzida como

20
resultado final do algoritmo de criptografia e o algoritmo de descriptografia que faz o
mesmo que o algoritmo de criptografia, porém em ordem inversa, com o objetivo de
produzir o texto claro a partir do texto cifrado utilizando a chave secreta como base.
O principal problema encontrado na criptografia simétrica é o compartilhamento da chave,
pois para que o receptor da mensagem seja capaz de descriptografá-la, o mesmo necessita
obrigatoriamente da chave utilizada no momento da cifragem do texto, portanto a chave
precisa ser enviada ao receptor da mensagem e o receptor precisa manter o sigilo da
mesma. Dessa forma temos uma falha de segurança, pois se o remetente ou o destinatário
ou mesmo o meio de tráfego da chave quebrarem o sigilo de alguma forma e por qualquer
motivo a chave vier a ser conhecida, toda a comunicação poderá ser lida por um terceiro
interessado (Machado, 2010).
2.1.2. Criptografia Assimétrica
Nessa modalidade, existem duas chaves que são ligadas matematicamente, onde uma das
chaves é pública e pode ser distribuída livremente enquanto a outra é privada e deve
permanecer segura com seu proprietário. O que é criptografado com a chave pública só
pode ser descriptografado com a chave privada correspondente. Chaves assimétricas são
mais fáceis de gerenciar já que é possível compartilhar livremente a chave pública. Porém
o lado negativo na criptografia assimétrica é seu alto custo de processamento devido a
dificuldade de fatoração de números grandes, limitando seu uso em determinadas
situações, como a encriptação de textos ou arquivos muito extensos (Machado, 2010).
O desenvolvimento da criptografia de chave pública é a maior e talvez a única verdadeira
revolução na história da criptografia. Desde o seu início até os tempos modernos,
praticamente todos os sistemas criptográficos têm sido baseados nas ferramentas
elementares da substituição e permutação. A criptografia de chave pública oferece uma
mudança radical em relação a tudo o que havia sido feito. Os algoritmos de chave pública
são baseados em funções matemáticas, em vez de na substituição e permutação. O uso de
duas chaves tem profundas consequências nas áreas de confidencialidade, distribuição de
chaves e autenticação (Stallings, 2008, p. 182)

21
Muitos matemáticos diziam ser impossível a troca mensagens criptografadas sem o
compartilhamento prévio de chaves secretas, porém no ano de 1976 os criptógrafos
Whitfield Diffie e Martin Hellman publicaram um artigo sobre troca de chaves que
batizaram de Diffie-Hellman. Apesar de criar o conceito de criptografia com chaves
públicas em 1976, apenas em 1978 o algoritmo foi finalmente implementado. Ronald
Rivest, Adi Shamir e Leonard Adleman, todos professores do MIT deram origem ao
algoritmo RSA que ao invés de logaritmos discretos e exponenciação, utiliza a
exponenciação e fatoração de números primos. Para se ter uma ideia da força do RSA, "Em
1977 foi lançado um desafio: Fatorar um número com 129 dígitos. Em 1994 o número foi
então fatorado com sucesso por 600 voluntários" (Machado, 2010).
2.2. FUNÇÃO DE HASH
Segundo (Pisa, 2012) é possível definir a função de hash como qualquer algoritmo que
mapeie dados grandes e de tamanho variável para pequenos dados de tamanho fixo. Por
esse motivo, as funções hash são conhecidas por resumirem o dado. A principal aplicação
dessas funções é a comparação de dados grandes ou secretos. (Stallings, 2008, p. 234) diz
que uma função de hash aceita uma mensagem de comprimento variável M como entrada e
produz uma saída de comprimento fixo, conhecida como código de hash.
O hash é uma soma de verificação criptográfica ou um código de integridade de mensagens
(MIC) que cada parte deve calcular para verificar a mensagem. Por exemplo, o computador
que está enviando os dados utiliza a função de hash e uma chave compartilhada para
calcular a soma de verificação da mensagem, incluindo-a com o pacote. O computador que
está recebendo os dados deve executar a mesma função de hash na mensagem recebida e
na chave compartilhada e compará-la com a original (incluída no pacote do remetente). Se
a mensagem tiver sido alterada quando estava em trânsito, os valores de hash serão
diferentes e o pacote será rejeitado (Microsoft, 2013).
A função de hash recebe como entrada um arquivo, mensagem ou bloco de dados de
tamanho variável, efetua cálculos utilizando algoritmos como o MD5 e o SHA e retorna
um texto de tamanho fixo como resultado. A função de hash possui características
especificas como, poder ser aplicada a um bloco de dados de qualquer tamanho, produzir
uma saída de comprimento fixo, ser relativamente fácil de calcular, precisa ser

22
unidirecional de forma que seja inviável chegar aos dados variáveis a partir do hash
gerado. São utilizadas na maioria das vezes para busca de elementos em bases de dados,
verificação de integridade de dados e armazenamento de senhas com segurança.
Existem diversos tipos de função resumo e a sua complexidade depende, basicamente, das
propriedades que se deseja garantir. A propriedade básica de todas as funções resumo é ser
unidirecional. No contexto da teoria matemática, significa dizer que a função não tem
inversa (Pisa, 2012).
2.3. ASSINATURA DIGITAL
É possível entender por Assinatura Digital, o resultado de uma transformação criptográfica
de dados, que quando implementada apropriadamente, provê os seguintes serviços de
segurança: autenticação, integridade de dados e não repudio do assinante (Machado, 2010).
Tal processo está associado aos certificados digitais ICP-Brasil de tipos A1, A2, A3 e A4.
(ITI, 2007, p. 5). De acordo com (ITI, 2010, p. 5) a Assinatura Digital é um código
anexado ou logicamente associado a uma mensagem eletrônica que permite de forma única
e exclusiva a comprovação da autoria de um determinado conjunto de dados (um arquivo,
um e-mail ou uma transação). A assinatura digital comprova que a pessoa criou ou
concorda com um documento assinado digitalmente, como a assinatura de próprio punho
comprova a autoria de um documento escrito.
O National Institute of Standards and Technology (NIST) publicou o Federal Information
Processing Standard (FIPS 186), conhecido como padrão de assinatura digital (Digital
Signature Standard - DSS). O DSS utiliza o Secure Hash Algorithm (SHA) e apresenta
uma nova técnica de assinatura digital, o Digital Signarure Algorithm (DSA). O DSS foi
proposto originalmente em 1991 e revisado em 1993 em resposta ao feedback público com
relação à segurança do esquema. Houve outra revisão secundária em 1996. Em 2000, uma
versão expandida do padrão foi publicada como FIPS 186-2. Esta versão mais recente
também incorpora os algoritmos de assinatura digital baseados no RSA e na criptografia de
curva elíptica (Stallings, 2008, p. 280).
Como exemplo prático, digamos que João precisa enviar uma mensagem para Maria, para
que ele tenha certeza que a mensagem não foi modificada no caminho até Maria, João gera

23
o valor de hash da mensagem e criptografa o valor do hash com sua chave privada
enviando o hash criptografado junto com a mensagem e a sua chave pública referente à
chave privada utilizada. O resultado da criptografia do hash da mensagem é a assinatura
digital. Quando Maria receber de João a mensagem e a assinatura, ela deve descriptografar
o hash com a chave pública de João se conseguir ela terá certeza que foi João que
criptografou o hash já que apenas ele tem acesso à sua chave privada. De posse do hash
descriptografado, Maria deve calcular o hash da mensagem recebida, se os dois valores de
hash forem idênticos isso significa que a mensagem não foi alterada, caso contrário isso
prova que a mensagem teve seu conteúdo alterado.
Outro caso seria se a mensagem de João possuísse caráter sigiloso, então João deveria
criptografar a mensagem utilizando a chave pública de Maria, dessa forma ele pode
garantir que apenas Maria irá ler a mensagem partindo do suposto que apenas ela tem
acesso a sua chave privada. Essa abordagem apesar de funcional pode gerar um problema
de performance caso o conteúdo da mensagem de João seja muito grande, pois
diferentemente da criptografia simétrica que utiliza cifras de substituição ou transposição,
o cálculo utilizado pela criptografia assimétrica de chaves públicas é baseado na fatoração
de números primos grandes as vezes chegando a 300(trezentos) dígitos. Para sanar esse
problema João deve cifrar a mensagem utilizando a criptografia simétrica e cifrar a chave
utilizada na criptografia simétrica com a chave pública de Maria de forma assimétrica.
Logo após criptografar o hash da mensagem que será sua assinatura e enviá-la juntamente
com a chave simétrica criptografada. Quando Maria receber a mensagem ela deve
descriptografar a chave simétrica com sua chave privada e utilizando a chave simétrica
obtida deve descriptografar a mensagem recebida utilizando a criptografia simétrica
baseada na chave que João enviou, logo após calcular o hash da mensagem e comparar
com o hash recebido na assinatura de João. Dessa forma João pode garantir tanto a
integridade dos dados como o sigilo, sem que a performance da operação fosse
comprometida já que a criptografia utilizada para cifragem da mensagem foi simétrica que
por definição é mais rápida que a assimétrica. Na figura 2 é demonstrado o processo de
criação e verificação de uma assinatura digital.

24
Figura 2 - Processo de criação e verificação da assinatura digital
Como é possível acompanhar na figura 2, ao enviar uma mensagem assinada, temos um
bloco de dados que é informado à função de hash que por sua vez retorna uma
identificação única. Essa identificação passa pela criptografia assimétrica utilizando como
base a chave privada do remetente, o resultado é a assinatura digital. Então a mensagem é
enviada contendo o bloco de dados, a assinatura e a chave pública do remetente. O
destinatário ao receber a mensagem efetua o processo inverso, calculando o hash do bloco
de dados, descriptografando o hash enviado pelo remetente e comparando-o com o hash
calculado. Caso os dois valores de hash sejam iguais é possível garantir que o bloco de
dados não foi alterado.
2.4.CERTIFICADO DIGITAL
O certificado digital da ICP-Brasil, além de personificar o cidadão na rede mundial de
computadores, garante, por força da legislação atual, validade jurídica aos atos praticados
com o seu uso. A certificação digital é uma ferramenta que permite que aplicações como
comércio eletrônico, assinatura de contratos, operações bancárias, iniciativas de governo
Bloco de dados Função de Hash
Requisição da
Chave Privada
Cifragem
Assimétrica do
Hash
Bloco de Dados
Assinatura
Chave Pública
Envio da
Mensagem
Mensagem
recebida
Função de Hash
Decifragem
Assimétrica do
Hash
Comparação do
Hash

25
eletrônico, entre outras, sejam realizadas. São transações feitas de forma virtual, ou seja,
sem a presença física do interessado, mas que demanda identificação clara da pessoa que a
está realizando pela intranet (ITI, 2013). O certificado digital é o resultado da atividade de
reconhecimento em meio eletrônico que se caracteriza pelo estabelecimento de uma
relação única, exclusiva e intransferível entre uma chave privativa de criptografia e uma
pessoa física, jurídica, máquina ou aplicação. Esse reconhecimento é inserido em um
Certificado Digital, por uma Autoridade Certificadora. Segundo (ITI, 2010, p. 11), os
certificados da ICP-Brasil são utilizados, de acordo com o seu tipo, em aplicações como:
 Tipo A: confirmação da identidade na web, correio eletrônico, transações on-
line, redes privadas virtuais, transações eletrônicas, informações eletrônicas,
cifração de chaves de sessão e assinatura de documentos com verificação da
integridade de suas informações.
 Tipo S: cifração de documentos, bases de dados, mensagens e outras
informações eletrônicas.
O certificado digital possui informações sobre seu proprietário como CPF, número de
identidade, nascimento, e-mail e qualquer outra que esteja explicitado na política de
segurança da autoridade certificadora responsável. Esses dados são pessoalmente validados
por uma autoridade de registro vinculada a uma AC e só após a verificação presencial é
feita a liberação do certificado pela AC garantindo a titularidade do certificado. Existem
diversos tipos de certificado, cada um com uma utilidade específica, cada certificado
possui a sua forma adequada de armazenamento, a figura 3 ilustra os tipos de mídias
utilizadas para o armazenamento de certificados. Alguns exemplos de tipos de certificados
são:
 e-CPF – Tem como finalidade a identificação de uma pessoa física, é utilizado nos
formatos A1 e A3 que se diferem na forma de armazenamento. Enquanto o
certificado A1 pode ser instalado e armazenado no computador juntamente com sua
chave privada, o certificado A3 é armazenado em uma mídia criptografia especial
com um token ou smart card, garantindo que a chave privada não saia do
dispositivo.
 e-CNPJ – O mesmo que o e-CPF porém é utilizado para identificação de uma
pessoa jurídica.

26
 NF-e – São certificados utilizados para emissão de notas fiscais eletrônicas. O NF-e
A1 é indicado para empresas que necessitam de um certificado digital armazenado
no computador e não em cartão inteligente para assinatura de notas fiscais da sua
empresa. Pode ser utilizado também no padrão A3 e HSM que é indicado para
empresas que precisam armazenar o certificado digital NFe em seu próprio
hardware de HSM.
 Certificado SSL – Permite confirmar autenticidade e tornar segura a transmissão de
informações e dados de um website. As informações trafegam criptografadas até o
servidor da empresa.
Figura 3 - Mídias criptográficas
A figura 3 ilustra dois Smart Cards utilizados para armazenamento dos certificados digitais
e-CPF e e-CNPJ assim como o cabo USB utilizado para conexão do Smart Card ao
computador. A outra mídia criptográfica que a figura ilustra é um token USB que pode ser
reconhecido pelo computador sem a necessidade de um leitor secundário.

27
2.5.CERTIFICADO DIGITAL X.509
A agência especializada das Nações Unidas para as tecnologias de informação e
comunicação (ITU) reuni especialistas de todo o mundo para desenvolver padrões
internacionais que são referências que funcionam como elementos definidores da
infraestrutura global de tecnologia e telecomunicações (TIC). O certificado digital tem o
seu formato especificado pelo padrão X.509 e publicado na RFC5280. O formato de
certificado X.509 versão 1 (v1) foi posteriormente estendido para incorporar dois novos
campos para suportar controle de acesso a diretório resultando no formato X.509 2 (v2).
Atualmente a versão X.509 mais utilizada é a versão 3(X509 v3) que permite campos
adicionais de extensão (Batista, 2004). O comitê gestor da Infraestrutura de Chaves
públicas Brasileira regida pelo ITI de acordo com a (Receita Federal, 2013, p. 3) define
como obrigatórias as seguintes extensões do certificado e-CPF no padrão X.509 v3:
 Número de Versão - Os certificados digitais e-CPF implementam a versão 3 dos
certificados definida no padrão ITU-T X.509, de acordo com o perfil estabelecido
na RFC 3280 (Request for Comments – Internet X509 Public Key Infrastructure).
 Campo Issue - Todo certificado e-CPF possui neste campo o nome X.500 da
Autoridade Certificadora.
 Algoritmos de Criptografia, Tamanho e Processo de Geração de Chave - O
algoritmo utilizado para a geração das chaves dos certificados e-CPF é o RSA.
 Algoritmo de Assinatura Digital - Os certificados deverão ser assinados com uso do
algoritmo conforme documento PADRÕES E ALGORITMOS
CRIPTOGRÁFICOS DA ICP-BRASIL (DOC ICP-01.01).
 Limite de Tamanho - O tamanho máximo de cada componente do Distinguished
Name (DN), CN, OU, O e C, é de 64 caracteres.
 Chave Pública do Titular do Certificado - Conforme definido na RFC 3280.
 Identificação do Sistema Criptográfico Utilizado - Conforme definido na RFC
3280.
 Conjunto de Caracteres – definido em (Receita Federal, 2013, p. 9)
 Identificação e Assinatura Digital da Autoridade Certificadora Emitente -
Conforme definido na RFC 3280
 Número de Série Exclusivo do Certificado - Conforme definido na RFC 3280.

28
 Validade do Certificado Digital - Conforme definido na RFC 3280.
 Composição do Distinguished Name (DN) do certificado e-CPF
CN=<Nome da Pessoa Física> <:> <número de inscrição no
CPF>
OU= <Identificação da AR >
OU=<Domínio do certificado>
OU=<RFB e-CPF >
OU=Secretaria da Receita Federal do Brasil – RFB
O=ICP-Brasil
C=BR
Segundo (Batista, 2004, p. 32) a versão 3 da recomendação X.509 V3 adiciona novos
campos ao certificado básico chamados "Extensões". Esse campo é opcional, portanto um
certificado pode ter zero ou mais campos de extensão. A principal função das extensões é
permitir que novos campos sejam adicionados sem modificar o certificado. As extensões
permitem associar informações adicionais sobre titulares, chaves públicas, gerenciamento
de hierarquia de certificação e gerenciamento da distribuição da lista de revogação de
certificados. Assim, comunidade e organizações podem definir seus próprios campos de
extensões para atender suas necessidades. A figura 4 ilustra todos os possíveis campos e
extensões de um certificado no padrão X.509.

29
Figura 4 - Certificado digital padrão X.509v3
É possível perceber na figura a grande quantidade de informações contidas no certificado
X.509v3. Através das extensões é possível obter informações essenciais como o caminho
da certificação até a AC Raiz como também a URL para download da lista de certificados
revogados, entre outras.
2.6.REVOGAÇÃO DE CERTIFICADOS DIGITAIS
Todo certificado digital possui um tempo de validade predefinido, porém caso o sigilo da
chave privada do certificado for comprometido o proprietário tem a opção de revoga-lo
junto à autoridade certifizcadora que emitiu o mesmo e caso exista uma alteração do CPF
do titular do certificado a Receita Federal faz automaticamente a solicitação de revogação
às demais autoridades certificadoras da cadeia de confiança da ICP-Brasil. A partir da
solicitação o número de série do certificado é adicionado à Lista de Certificado Revogados
(LCR). Toda autoridade certificadora tem como obrigação manter publicada e atualizada
em um repositório público a lista de certificados revogados. Cada publicação é assinada
com o certificado digital da autoridade certificadora correspondente e recebe um carimbo

30
do tempo. O tempo entre publicações pode variar e dependerá da política adotada pela AC.
Essa mesma verificação pode ser feita em tempo real utilizando-se o protocolo OCSP. O
protocolo OCSP é descrito na RFC-2560 e foi criado como uma alternativa à LCR.
" Art. 6º. As AC, entidades credenciadas a emitir certificados digitais
vinculando pares de chaves criptográficas ao respectivo titular, compete emitir,
expedir, distribuir, revogar e gerenciar os certificados, bem como colocar à
disposição dos usuários listas de certificados revogados e outras informações
pertinentes e manter registro de suas operações."
(Presidência da República, 2001)
2.7.A INFRAESTRUTURA DE CHAVES PÚBLICAS BRASILEIRA
A Infraestrutura de Chaves Públicas Brasileira (ICP-Brasil) é uma cadeia hierárquica e de
confiança que viabiliza a emissão de certificados digitais para identificação virtual do
cidadão. Observa-se que o modelo adotado pelo Brasil foi o de certificação com raiz única,
sendo que o ITI, além de desempenhar o papel de Autoridade Certificadora Raiz (AC-
Raiz), também tem o papel de credenciar e descredenciar os demais participantes da
cadeia, supervisionar e fazer auditoria dos processos (ITI, 2013).
A ICP Brasil foi instituída pela MEDIDA PROVISÓRIA Nº 2.200-2 em agosto de 2001
com o objetivo de garantir a autenticidade, integridade e a validade jurídica de documentos
em forma eletrônica. Possui um comitê gestor que é vinculado à Casa Civil da Presidência
da República, composto por cinco representantes da sociedade civil, integrantes de setores
interessados, designados pelo Presidente da República, e representantes de órgãos diversos
como o Ministério da Justiça, Ministério da Fazenda, Ministério da Ciência e Tecnologia,
entre outros. O Comitê Gestor da ICP-Brasil é responsável por estabelecer a política, os
critérios e as normas técnicas para o credenciamento das AC, das AR e dos demais
prestadores de serviço de suporte, bem como várias outras atribuições que também podem
ser delegadas à AC Raiz (Presidência da República, 2001).
A Autoridade Certificadora Raiz da ICP-Brasil (AC-Raiz) é a primeira autoridade da
cadeia de certificação. Executa as Políticas de Certificados e normas técnicas e
operacionais aprovadas pelo Comitê Gestor da ICP-Brasil. Portanto, compete à AC-Raiz

31
emitir, expedir, distribuir, revogar e gerenciar os certificados das autoridades certificadoras
de nível imediatamente subsequente ao seu. A AC-Raiz também está encarregada de emitir
a lista de certificados revogados (LCR) e de fiscalizar e auditar as Autoridades
Certificadoras (ACs), Autoridades de Registro (ARs) e demais prestadores de serviço
habilitados na ICP-Brasil. Além disso, verifica se as ACs estão atuando em conformidade
com as diretrizes e normas técnicas estabelecidas pelo Comitê Gestor da ICP-Brasil. (ITI,
2013). A Estrutura resumida da ICP-Brasil pode ser conferida na figura 5:

32
Figura 5 - Estrutura resumida da ICP-Brasil

33
A figura 5 ilustra as 13 (treze) autoridades certificadoras diretamente ligadas à AC Raiz
brasileira juntamente com as demais autoridades responsáveis pela emissão dos
certificados digitais utilizados na cadeia de confiança da infraestrutura de chaves públicas
no Brasil.
3. METODOLOGIA
Buscando um processo que ordenasse as contribuições científicas sobre o tema e
fornecesse subsídios para a solução do problema, foram adotados como método de
pesquisa as abordagens bibliográficas e documentais bem como a pesquisa experimental e
descritiva, por meio de artigos, livros, sites governamentais e privados especializados no
assunto. O desenvolvimento da monografia pode ser dividido em duas etapas, porém
executadas em paralelo, sendo elas: O planejamento das funcionalidades do portal,
levantamento de requisitos e protótipos de telas bem como a criação dos possíveis casos de
uso. O levantamento bibliográfico e a escrita da monografia, observando os principais
conceitos, legislação associadas e estrutura dos órgãos envolvidos.
O campo de pesquisa foi a assinatura digital de documentos. Todos os experimentos foram
desenvolvidos em locais de apoio como o Núcleo de Tecnologia da Informação (NTI),
vinculado ao curso de Sistemas de Informação da Faculdade Católica do Tocantins. O
período para realização do trabalho teve cronograma próprio definido no início da
pesquisa.
As metodologias citadas nessa seção foram desenvolvidas em um notebook com a seguinte
configuração de software e hardware: Asus G74SX com sistema operacional Windows 7,
processador Intel® Core™ i7-2630QM, memória de 16 GB com sistema operacional de 64
Bits. Sendo assim, todos os componentes de software necessários foram instalados e
configurados neste equipamento.
Os recursos necessários para a realização deste trabalho se baseiam em ferramentas
gratuitas e versões comunitárias. Utilizou-se a IDE Groovy/Grails Tool Suite para
desenvolvimento do software no padrão MVC, H2 Database Console e pgAdmin para
gestão da camada de persistência em banco de dados.

34
3.1. TRABALHOS RELACIONADOS
Para um melhor embasamento teórico sobre Certificação Digital, foram consultados alguns
trabalhos acadêmicos na área. A análise abordará os conceitos, metodologias e objetivos
dos seguintes trabalhos: Uma Abordagem da Infraestrutura de Chaves Públicas para
Ambientes Corporativos de Bruno de Melo Silva, Assinatura Digital No Processo
Legislativo Da Câmara Dos Deputados de Ariádna Edenice de Mendonça Vasconcelos,
Marco Valério Ruas da Silva e Miguel Gerônimo da Nóbrega Netto e Assinatura Digital de
Documentos Eletrônicos Através da Impressão Digital de Juliano Fontoura Kazienko.
3.1.1. Uma Abordagem da Infraestrutura de Chaves Públicas para
Ambientes Corporativos
Este trabalho objetivou o estudo dos padrões e definições de uma Infraestrutura de Chaves
Públicas seguindo o modelo hierárquico e também o desenvolvimento de um projeto de
uma Infraestrutura de Chaves Públicas privada para ambientes corporativos provendo um
aplicativo com as funcionalidades necessárias para a utilização dessa infraestrutura. A
metodologia utilizada por Bruno de Melo Silva teve caráter teórico realizando o
mapeamento e análise de literaturas através de pesquisas bibliográfica a livros e artigos,
com foco na criação de uma ICP privado. O projeto abrange a criação de uma Autoridade
Certificadora interna a uma empresa e a implantação de um aplicativo para efetivar o
gerenciamento de chaves públicas e privadas e utilização das mesmas para criptografia
assimétrica dos dados. (SILVA, 2004)
Apesar de promover a integridade, autenticidade e não repúdio às informações dentro de
uma corporação, esse projeto faz com que a assinatura seja juridicamente inválida fora dos
âmbitos da empresa por não seguir o determinado no Art. 1° da MP N° 2.200-2 que diz.
"Fica instituída a Infraestrutura de Chaves Públicas Brasileira - ICP-Brasil, para
garantir a autenticidade, a integridade e a validade jurídica de documentos em
forma eletrônica, das aplicações de suporte e das aplicações habilitadas que
utilizem certificados digitais, bem como a realização de transações eletrônicas
seguras."

35
Como o objetivos do trabalho é criar uma nova ICP que seja interna e de posse da empresa,
logo os certificados emitidos por essa ICP não são validados pela ICP-Brasil. Segundo
(Costa, 2003, p. 7) um documento emitido por uma autoridade pública, no exercício de
uma função pública, e outro, por uma empresa, têm eficácias jurídicas diferentes. Uma
diferença entre ambos é que o documento público tem algo próximo ao curso forçado, ou
seja, deve ser aceito por todos, pela presunção de veracidade do Estado em face da
sociedade; já o documento privado é aceito ou não em função da confiança que gera em
seu destinatário.
Assim, se considerarmos o certificado como uma credencial, é fácil imaginar a diferença
entre um título de eleitor, uma cédula de identidade, um cartão de CPF, um passaporte, e
um cartão de crédito, ou uma carteira de um clube desportivo. Ao menos que desconfie de
fraude, ninguém pode recusar um passaporte, ou uma cédula de identidade, como prova
civil de identidade, enquanto que ninguém é obrigado a aceitar, como prova daquela
espécie, uma carteira de funcionário de uma empresa (Costa, 2003, p. 8).
3.1.2. Assinatura Digital No Processo Legislativo Da Câmara Dos
Deputados
Nesse projeto os autores estudam a viabilidade da implantação da assinatura digital no
processo legislativo da Câmara dos Deputados apresentando as vantagens do seu uso sob o
enfoque da atuação parlamentar objetivando identificar sob quais condições e parâmetros
essa tecnologia pode ser implantada observando os recursos tecnológicos disponíveis. Cita
pontos que dificultam a implantação como o custo na aquisição de equipamentos para a
utilização da tecnologia, tais como microcomputador, tokens ou smart cards e o próprio
certificado digital. Como metodologia, além da pesquisa exploratória com consultas
bibliográficas, pode observar a pesquisa descritiva através da visita do grupo de autores à
Casa Civil para levantamento sobre a implantação da tecnologia no âmbito do Poder
Executivo. Segundo os autores, no âmbito do Poder Executivo, a elaboração de atos
normativos e demais documentos oficiais realizavam-se mediante a tramitação em papel
entre os Ministérios e a Presidência da República. Na estrutura administrativa havia
pessoas encarregadas de colher as assinaturas em todos os Ministérios e entregar o
documento completo na Presidência da República. Às vezes, esse procedimento fazia com
que se levasse dias ou até meses para concluir a tramitação naquele poder.

36
No segundo mandato do ex-presidente Fernando Henrique Cardoso, o então Ministro da
Casa Civil, Pedro Parente, lançou o programa denominado DOC–Eletrônico, disciplinado
pelo Decreto n° 4.522, de 2002, para diminuir o tempo gasto e elevar a eficiência na
tramitação de documentos para elaboração de atos normativos no âmbito do Poder
Executivo. Tal fato gerou a necessidade da existência de uma Autoridade Certificadora
para credenciar as pessoas, no âmbito do Poder Executivo, a fim de terem acesso à gestão
de documentos eletrônicos. O Serviço Federal de Processamento de Dados (SERPRO) foi
criado para sanar essa necessidade.
Por fim concluiu-se que atualmente, a Câmara opera com duas infraestruturas de
certificados digitais. A primeira refere-se à Certsign, a Autoridade Certificadora vinculada
à ICP-Brasil, e a segunda, à Autoridade Certificadora interna da Câmara (ICP-CD). Sendo
que na realidade, nenhuma dessas infraestruturas foi utilizada de forma plena pelos
segmentos da Casa, uma vez que se faz necessário o desenvolvimento de aplicativos que
viabilizem o uso dessa tecnologia. (Vasconcelos, Silva, & Nóbrega Netto, 2008)
3.1.3. Assinatura Digital de Documentos Eletrônicos Através da
Impressão Digital
Nessa dissertação o agora mestre Juliano Fontoura Kazienko teve como objetivo utilizar a
impressão digital para a verificação da identidade do usuário quando da assinatura de
documentos eletrônicos. Como metodologia foram adotados levantamentos acerca do uso
de impressões digitais na polícia civil catarinense. Procurou-se detectar seu uso desde a
confecção da carteira de identidade até a comparação de impressões digitais latentes
coletadas em locais de crime. O documento pode ser dividido em dois temas, o primeiro
sendo a apresentação das formas de autenticação da identidade dos usuários que vão desde
as tradicionais senhas até aos sistemas biométricos. O segundo são apresentados conceitos
envolvidos na assinatura digital de documentos como o de criptografia, Hash e a
infraestrutura de chaves públicas.
Segundo Kazienko, a escolha de que tipo de autenticação usar deve ser pautada por suas
peculiaridades e pelo ambiente onde será inserido. Muitas vezes, a união de tipos de
autenticação diferenciados pode ser vantajosa para se possa aumentar a confiabilidade no
processo de autenticação da identidade, considerando que cada forma de autenticação tem

37
prós e contras. Assim, são utilizados cartões, senhas e impressões digitais no modelo que
se propõe, visando autenticar a identidade de usuários durante a assinatura de documentos
eletrônicos.
Por fim é apresentado um protótipo de um sistema computacional desenvolvido com o
objetivo de mostrar a viabilidade de realização da assinatura digital utilizando a
autenticação do usuário através da impressão digital. Assim a proposta adiciona um
método a mais de segurança no processo de certificação dando mais uma garantia de que o
usuário que está assinando o documento é de fato quem ele diz ser. (Kazienko, 2003)
3.2. FRAMEWORK DE DESENVOLVIMENTO WEB
Com o avanço da Internet o mercado tecnológico fez uma natural migração dos sistemas
desktop para os sistemas web, fazendo-se necessários recursos e ferramentas que permitam
ao mercado de software realizar o processo de desenvolvimento de forma mais ágil. Os
frameworks permitem que os desenvolvedores de software preocupem-se pouco com a
escrita de código e os reaproveite bastante obtendo rápidos resultados. Desta forma,
visando sanar os problemas do desenvolvimento web baseado em Java, surgiram diversos
frameworks, dentre eles destaca-se o projeto Grails, que foi iniciado em 2005, baseado em
outro framework denominado Ruby on Rails. Segundo (Antunes, 2011, p. 26), o
framework Grails foi criado no intuito de fornecer um maior nível de abstração com o
enfoque em simplificar e facilitar as configurações e aproveitar mais a sintaxe bem
expressiva e limpa da linguagem dinâmica Groovy. Desta forma, o Grails apresenta-se
como uma solução ágil para ser utilizada com a plataforma Java para a web.
Grails tem como principal objetivo ser um framework Open Source de alta produtividade,
e para isso ele utiliza tecnologias, tais como, os frameworks Hibernate e Spring, por meio
de uma interface simples e consistente. O framework Grails utiliza o padrão de
desenvolvimento MVC de forma natural, livrando o desenvolvedor dos detalhes
complexos da persistência de dados, assim como também fornecendo um template web
para facilitar a implementação da interface com o usuário (Antunes, 2011, p. 32).
Tal como o framework no qual é inspirado, o Grails baseia-se no conceito de convenção ao
invés de configuração e DRY (Don´t repeat yourself). De fato, é possível desenvolver uma
aplicação baseada em Grails sem ter que alterar um único arquivo de configuração, o que

38
normalmente não é o caso com a maior parte dos frameworks para o desenvolvimento de
aplicações web com os quais já estamos acostumados a trabalhar na plataforma Java.
Outra característica bastante interessante do Grails consiste no fato dele ser um ambiente
de desenvolvimento completo. Depois de instalado, todas as bibliotecas e ferramentas
necessárias para começar a trabalhar já estarão disponíveis ao desenvolvedor. Nem sequer
um servidor de aplicações será necessário, uma vez que o Grails já vem com o Jetty
instalado e configurado. Portanto, é possível afirmar que o framework Grails desempenha
uma grande contribuição no desenvolvimento web baseado em Java, tornando-o mais
amigável, rápido e eficiente (Weissmann, 2008).
3.3. BANCO DE DADOS
Em ambiente de desenvolvimento foi adotado o H2 Database Engine por já estar integrado
ao Framework Grails e ser totalmente compatível com o projeto proposto. É um banco de
dados leve, desenvolvido totalmente em Java, permite o armazenamento temporário de
dados em memória, a conexão via JDBC e o mapeamento relacional utilizado pelo
Hibernate. O desenvolvimento do H2 foi iniciado em maio de 2004, mas ele foi publicado
pela primeira vez em 14 de dezembro de 2005. O autor principal do H2, Thomas Mueller,
é também o desenvolvedor original do Hypersonic SQL. O nome H2 significa Hypersonic
2, porém H2 foi construído do zero e não compartilha o código com o Hypersonic SQL ou
HSQLDB (h2database, 2013, p. 1).
O banco de dados adotado para o ambiente de produção do sistema foi o PostgreSQL, que
sob a liderança de Michael Stonebraker, foi desenvolvido a partir do projeto Postgres, que
teve seu início em 1986 na Universidade da Califórnia. Desde então, este projeto vem se
mantendo por um grupo de desenvolvedores sob o nome de PostgreSQL. É considerado o
melhor SGBD open source da atualidade, pois além de ter o código aberto, sendo uma
alternativa aos SGBDs Oracle ou Informix, possui recursos comuns aos tradicionais
SGBDs comerciais, com o suporte a consultas complexas, gatilhos, chaves estrangeiras,
visões, controle de concorrência e integridade relacional, e foi o primeiro SGBD apossuir
vários recursos que somente algum tempo depois foram incorporados aos SGBDs
comerciais. É bastante flexível no que se diz respeito à extensibilidade, sendo dotado de
um mecanismo que permite a ampliação de sua capacidade, com o objetivo de fornecer um

39
gerenciamento de dados mais eficiente (Casanova, Câmara, Davis , Vinhas, & Ribeiro de
Queiroz, 2005, p. 271).
3.4. REQUISITOS FUNCIONAIS
RF1. O sistema deverá permitir que o usuário se cadastre utilizando um formulário
próprio e faça a escolha de uma senha de acesso.
RF2. Permitir ao usuário a exclusão de seu perfil.
RF3. Permitir o envio e armazenamento, edição e exclusão de documentos.
RF4. Permitir a assinatura dos documentos pelo usuário que enviou o documento ou por
quem ele definir.
RF5. Permitir o compartilhamento do documento com um ou mais usuários do portal.
RF6. Permitir o envio de convites para novos usuários.
RF7. Permitir o vínculo de um certificado de uso padrão no perfil do usuário.
3.5. REQUISITOS NÃO FUNCIONAIS
RF8. O sistema será executado em ambiente WEB tornando-o acessível e utilizável sem
dependências com o sistema operacional dos usuários.
RF9. Os dados informados pelos usuários devem ser validados com suas respectivas
regras, para só então serem armazenados em um banco de dados que por sua vez
deve ser gratuito.
RF10. Para realizar qualquer ação que envolva a modificação de dados armazenados pelo
sistema é necessário que o usuário esteja autenticado.
RF11. As senhas dos usuários devem ser armazenadas com criptografia no banco de
dados.
RF12. Os arquivos devem ser compactados antes do seu armazenamento no banco de
dados.
RF13. A interface disponibilizada para os usuários devem ser simples, informativa e
intuitivas.

40
3.6.MODELAGEM
3.6.1. Diagramas de Classes
No projeto proposto, existem cinco classes que representam respectivamente os objetos
responsáveis pelo gerenciamento de certificados, pessoas, compartilhamentos, documentos
e assinaturas envolvidas no sistema. Uma pessoa após se cadastrar no portal faz o vínculo
de um certificado ao seu perfil e com ele é possível criar assinaturas, que por sua vez
agregam o documento assinado, o certificado utilizado e a pessoa que assinou. Após isso o
usuário poderá criar um compartilhamento, que conterá o documento compartilhado, as
informações sobre a pessoa que compartilhou e a pessoa que está recebendo o
compartilhamento. A figura 6 demonstra o diagrama de classes do sistema.
Figura 6 - Diagramas de Classes

41
3.6.2. Diagramas de Casos de Uso
Os diagramas de casos de uso apresentados aqui são responsáveis por descrever as
funcionalidade do sistema. Existem duas instancias diferentes de atores, uma delas é o
usuário antes de efetuar sua autenticação no sistema e a outra refere-se ao usuário
autenticado. Como ilustrado na figura 7, antes de ser autenticado o usuário pode efetuar
quatro operações, são elas: Efetuar login, recuperar senha, criar perfil e pesquisar
documento.
Figura 7 - Caso de uso do usuário não autenticado
Após efetuar sua autenticação no sistema o usuário é redirecionado para sua dashboard,
onde poderá enviar um documento, gerenciar certificados, convidar uma pessoa, verificar
uma assinatura, pesquisar por um documento, efetuar logoff, visualizar seu perfil, assinar,
gerenciar, baixar e compartilhar seus documentos previamente enviados, baixar, visualizar
e assinar documentos compartilhados com ele. Os casos de uso do usuário autenticado são
mostrados na figura 8.

42
Figura 8 - Ações do usuário autenticado
No caso de uso “Gerenciar Certificado”, mostrado na figura 9, o usuário autenticado
poderá vincular um certificado ao seu perfil, visualizar as informações do certificado
vinculado, baixar a chave pública do certificado e definir o certificado como padrão. Ao
visualizar as informações do certificado o usuário também terá acesso à chave pública do
mesmo, podendo efetuar o download. Outra opção que estende o caso de uso “Visualizar”
é a de excluir o certificado vinculado.

43
Figura 9 - Caso de uso "Gerenciar Certificados"
No caso de uso “Gerenciar Documento”, o usuário poderá, assinar, editar, fazer download,
deletar e compartilhar o documento, como mostra a figura 10.
Figura 10 - Caso de uso “Gerenciar Documento”

44
Como mostrado na figura 11, o usuário autenticado após visualizar seu perfil, possui
funcionalidades como: Editar, remover perfil, alterar sua foto e alterar sua senha. A foto do
usuário ou seu “Avatar” será enviada e armazenada diretamente no banco de dados do
sistema, tendo um limite de 2MB de tamanho máximo. Como as senhas serão
criptografadas, o caso de uso “Alterar Senha” terá que gerar uma nova senha para o usuário
e enviá-la ao e-mail cadastrado no perfil. Ao remover seu perfil, o usuário exclui suas
informações vinculadas ao perfil, porém, os certificados e assinaturas que se referem a
documentos compartilhados com outros usuários, não serão excluídos.
Figura 11 - Caso de uso "Visualizar Perfil"

45
4. VISÕES DO SISTEMA E CODIFICAÇÃO
Nessa seção serão apresentados os elementos do sistema desenvolvido, as ferramentas
utilizadas e os principais trechos de código e os conceitos por trás da tecnologia utilizada.
4.1.ARQUITETURA DO SISTEMA
A arquitetura do sistema proposto segue os padrões definidos para sistema WEB 2.0, a
figura 8 demonstra a possibilidade de sua utilização por diversos usuários simultaneamente
por se tratar de uma arquitetura cliente/servidor, onde o sistema está disponibilizado no
servidor podendo ser acessado através de um navegador. Para cada acesso uma nova sessão
é criada e o navegador WEB para a gerenciar as informações trafegadas entre o cliente e a
aplicação.
Na forma tradicional dos sistemas WEB os elementos são organizados da seguinte forma:
de um lado está o cliente WEB, ou navegador, que solicita dados ao servidor WEB, recebe
as respostas, formata a informação e a apresenta ao usuário. Do outro lado, está o servidor
WEB que recebe as requisições, lê os dados (páginas HTML) do disco e as retorna para o
cliente. Este modo não permite uma interação dinâmica entre o usuário e o sistema, pois
todas as informações que são retornadas pelo servidor não podem ser alteradas ou
customizadas pelos usuários (Araujo, 1997).
A forma encontrada para modificar esta situação e permitir a criação de páginas dinâmicas
foi a seguinte: o usuário entra com informações através do browser utilizando formulários
HTML. O browser repassa as informações ao servidor WEB que executa um programa
transferindo-lhe as informações vindas do cliente. O programa remoto (server-side
gateway program) trata as informações e retorna uma página HTML criada
dinamicamente. Esta página é passada ao servidor que a entrega ao cliente. O padrão para
comunicação entre o servidor WEB e o "Server-side gateway program" é conhecido como
CGI (Common Gateway Interface) (Araujo, 1997).

46
Figura 12 - Arquitetura de um sistema WEB
Como mostra a figura 12, o portal AssineDocs estará hospedado em um servidor WEB que
por sua vez proverá o acesso a um servidor de banco de dados, permitindo que os usuário
tenham acesso ao sistema de qualquer computador conectado à internet.
4.2. PADRÃO MVC
A modelagem de projetos de software sempre foi um desafio aos profissionais de TI, que
por sua vez dedicam parte do tempo buscando novas perspectivas para a modelagem e o
desenvolvimento de software. A constante pesquisa no setor de engenharia de software e
padrões de projetos trouxe uma nova forma de se enxergar um projeto de software, esse
modelo é o MVC. A figura 13 ilustra a arquitetura do padrão MVC.
Com o aumento da complexidade dos sistemas/sites desenvolvidos hoje, essa arquitetura
tem como foco dividir um grande problema em vários problemas menores e de menor
complexidade. Dessa forma, qualquer tipo de alterações em uma das camadas não interfere
nas demais, facilitando a atualização de layouts, alteração nas regras de negócio e adição
de novos recursos. Em caso de grandes projetos, o MVC facilita muito a divisão de tarefas
entre a equipe (Bastos, 2011).

47
O sucesso para o desenvolvimento de aplicações com tecnologia orientada a objetos está
intimamente ligada à arquitetura que vamos usar para construir a aplicação. A tendência
indica que esta arquitetura estará baseada na organização da aplicação em camadas e na
observação dos padrões utilizados pelo mercado (Macoratti, 2013).
4.2.1. Modelo
O modelo é utilizado para gerenciamento de toda a informação do sistema e o
recomendável é que todo tipo de manipulação de dados seja feita no modelo. É nele que
está definido o tipo e as configurações de conexão com o banco de dados bem como as
entidades do sistema que terão suas informações persistidas.
4.2.2. Visão
A visão é a responsável pela interação com o usuário do sistema é nela que todos os dados
são informados antes de serem tratados pelos controladores e repassados para os modelos.
Cores, tamanho de fonte, estilos e formulários são componentes comuns nessa camada.
4.2.3. Controlador
O Controlador, como o nome já sugere, é responsável por controlar todo o fluxo de
informação que passa pelo site/sistema. É no controlador que se decide “se”, “o que”,
“quando” e “onde” deve funcionar. Define quais informações devem ser geradas, quais
regras devem ser acionadas e para onde as informações devem ir, é no controlador que
essas operações devem ser executadas. Em resumo, é o controlador que consulta dados no
modelo, executa uma regra de negócio e repassa a informação para a visão.

48
Figura 13 - Arquitetura MVC
Como é possível observar na figura 13, um aplicativo na arquitetura MVC recebe
comandos do usuário pelo Controlador que por sua vez efetua operações predefinidas e
persiste os dados no Modelo. Por fim o resultado da operação é apresentado ao usuário
através de uma visão.
4.3.VISÕES DO SISTEMA
Cada modelo definido será citado e os pontos principais serão apresentados, bem como
seus respectivos controladores e por fim suas respectivas visões. Foi utilizada a
padronização da nomenclatura dos modelos visando facilitar futuras manutenções e
atualizações, pois com a forma utilizada as chave estrangeira do banco de dados e os objeto
das classes ficam visivelmente relacionados não só pela configuração do projeto mas pela
relação entre suas nomenclaturas.
4.3.1. Modelo D001Pessoa
É o modelo responsável por persistir em banco de dados as informações de cada pessoa
usuária do portal. Possui em sua estrutura os atributos [nome], [cpf], [nascimento],
[email], [status], [hashSenha] e [avatar]. Está relacionado com os modelos
[D002Certificado], [D003Documento] e [D005Compartilhamento], trazendo na navegação
entre entidades um lista de objetos de cada modelo relacionado através da propriedade
hasMany do Grails. Os atributos [nome], [cpf], [email] e senha não aceitam valores nulos

49
sendo que [cpf] e [email] devem ser únicos na base de dados. O atributo [senha] além da
validação de nularidade possui uma validação extra de forma a garantir que a senha
digitada nos dois campos do formulários de cadastro sejam idênticas.
O atributo [avatar] é um array de byte que armazena a foto exibida no perfil do usuário,
pode ser nulo mas caso não seja, é feita a validação de tamanho máximo para a imagem
enviada, fixado em 2MB. O atributo [nascimento] possui o formato “dd/mm/yyyy” e pode
variar entre as datas 01/01/1910 até 31/12/2099.
O controlador [D001Pessoa] possui os métodos [index], [show], [edit], [update], [delete],
[logout], [carregaSessao], [autenticar], [recuperarAcesso], [convidar], [d001Pessoasave],
[avatar], [updateAvatar], [avatarLink], [listaPessoas] e [dashboard]. O método [index] é
chamado como visualização padrão e assim que invocado efetua o redirecionamento para a
ação [dashboard] que por sua vez leva o usuário ao painel principal do sistema. O método
[show] recebe como parâmetro o [Id] da pessoa proprietária do perfil a ser exibido, faz a
verificação de existência do [Id] recebido e caso exista, envia os dados para a visão, caso
contrário retorna uma mensagem de erro redirecionando o usuário para sua dashboard.
O método [edit] também recebe o [Id] como parâmetro juntamente com os dados enviados
pela sua visão correspondente, verifica a existência da pessoa pelo [Id] recebido, repassa os
dados ao método [update] que fica encarregado de atualizar as informações do usuário na
base de dados. O método [delete] recebe o [Id], faz a verificação de existência e desativa o
usuário na base de dados marcando o atributo [status] como falso. O método [autenticar]
faz uma busca pelo [email] e [senha] informado e em caso positivo verifica se o checkbox
“lembrar-me” da visão [autenticar] está marcado, caso esteja faz a gravação do Cookie
contendo as informações de acesso do usuário, logo após chama a ação [carregaSessao]
que faz a inicialização da sessão do usuário definindo o tempo máximo de permanência em
novecentos segundos. O método [logout] invalida a sessão anteriormente criada e
redireciona o usuário à tela de autenticação. O método [recuperarAcesso] é responsável
pelo envio do e-mail contendo a nova senha de acesso do usuário. Como as senhas são
criptografadas antes do armazenamento no bando de dados, uma nova senha é definida e
enviada. O método [convidar] recebe como parâmetro o e-mail da pessoa a ser convidada e
faz o envio do convite. O método [d001Pessoasave] salva os dados enviados pela sua visão

50
criptografando a senha informada, criando a sessão do usuário e redirecionando o mesmo à
sua dashboard.
Temos três métodos relacionados ao avatar, um responsável pelo recebimento da imagens
enviada pelo usuário, o outro pela gravação e atualização do array de bytes resultante no
banco de dados e por fim o avatarLink que recebe o [Id] da pessoa como parâmetro e
carrega o array de bytes correspondente à imagem dentro da propriedade outputStream do
objeto response da aplicação. A visão de envio do avatar é mostrada na figura 14.
Figura 14 - Visão [avatar]
O método [listaPessoas] foi criado com o intuito de alimentar o componente auto
completar da visão de envio de convites. É criado um objeto JSON contendo a lista de
pessoas resultante baseada no texto digitado pelo usuário no campo nome da visão de
envio de convites, este objeto é enviado para a visão que faz o carregamento da lista
através da biblioteca jQuery.
O modelo D001Pessoa possui oito visões, são elas: [autenticar], [avatar], [convidar],
[d001Pessoacreate], [dashboard], [edit], [recuperarAcesso] e [Show]. Ao acessar o portal o
usuário é redirecionado à visão [autenticação] onde tem as opções de efetuar logon,
pesquisar por arquivos, um link para cadastro e outro para recuperação da senha, além de
informações diversas sobre segurança da informação e assinatura digital. A figura 15
mostra o cadastro do usuário.

51
Figura 15 – Visão: [d001Pessoacreate]
No espaço para logon o usuário precisa informar o e-mail cadastrado e sua senha, tendo
ainda a funcionalidade de gravar seus dados de acesso em um cookie marcando a opção
“Lembrar-me”. Clicando no link “Esqueci minha senha” o sistema redireciona-o para a
visão [recuperarAcesso]. Clicando no link “Ainda não sou cadastrado” é redirecionado
para a visão [d001Pessoacreate]. No campo de pesquisa de arquivos o usuário pode
informar todo ou parte do nome ou descrição do arquivo e também pesquisar informando o
[ID] ou o [Hash]. A figura 16 ilustra a visão de autenticação.

52
Figura 16 – Visão: [autenticação]
Na visão [recuperarAcesso], mostrada na figura 17, após o usuário informar seu e-mail
cadastrado anteriormente, uma nova senha é gerada e enviada.
Figura 17 – Visão: [RecuperarAcesso]

53
A visão [d001Pessoacreate] possui os dados principais para cadastramento com as devidas
validações definidas no modelo respectivo. Após cadastrado o usuário é redirecionado para
a visão [show], mostrada na figura 18, onde tem as opção de editar ou excluir o perfil
criado, modificar a senha ou enviar uma foto para o perfil. Assim que o usuário se cadastra
no portal é disponibilizada uma opção na barra de ferramenta que possibilita o envio de
convites a novas pessoas.
Figura 18 - Visão: [show] do modelo [D001Pessoa]
A visão [convidar] é a responsável por coletar o e-mail informado pelo usuário e enviar ao
controlador que por sua vez enviará o convite ao proprietário do e-mail informado. Ela
possui apenas o campo de e-mail como pode ser conferido na figura 19.
Figura 19 - Visão: [convidar]

54
Após autenticado o usuário tem como ambiente padrão a visão [dashboard], onde são
listados todos os documentos enviados para o portal bem como os documentos
compartilhados entre os usuários. Para cada documento listado são exibidos botões de
comando com opções de gerenciamento, visualização, compartilhamento e assinatura,
dependendo do tipo de permissão de cada documento listado. A visão [dashboard] é
ilustrada na figura 20.
Figura 20 - Visão [dashboard] do modelo [D001Pessoa]
A figura 12 demonstra a principal visão do usuário, onde é possível ter acesso a todas as
funções do sistema. Existem dois espaços de acesso aos documentos, o primeiro espaço
lista os documentos enviados pelo usuário enquanto o segundo espaço lista os documentos
compartilhados por outros usuário do portal.

55
4.3.2. Modelo D002Certificado
O modelo [D002Certificado] possui como atributos todos os campos do certificado no
padrão x.509, possui um relacionamento com o modelo [D001Pessoa] permitindo que cada
pessoa possa ter vários certificados vinculados e cada certificado pertence ao uma única
pessoa. No momento da execução do método [create] uma nova instancia do modelo
[D001Pessoa] é criada baseada na sessão do usuário ativo, dessa forma é possível garantir
de forma automática que cada certificado estará vinculado à pessoa que o cadastrou.
No momento da inclusão do certificado é feita a verificação de duplicidade e caso o
mesmo já esteja cadastrado o sistema retorna uma exceção impedindo a duplicação do
certificado. No momento do cadastro é feita a solicitação de acesso à chave privado de
forma a cadastrar-se apenas certificados válido e que poderão ser utilizados para assinatura
de arquivos. O usuário poderá cadastrar diferentes certificados e definir um deles como
padrão, sendo que no momento da assinatura o sistema emite uma mensagem de
advertência caso outro certificado esteja sendo utilizado, prevenindo um possível erro.
O controlador D002Certificado possui as funções essenciais para gerenciamento como
[create], [edit], [delete] e [show] além do método [chavePublicaBaixar] que permite o
download da chave pública do certificado. Os métodos [create] e [show] possuem suas
respectivas visões onde é possível cadastrar um novo certificado e visualizar as
informações de um certificado previamente cadastrado. Na visão [create] são listados todos
os certificados vinculados ao perfil do usuário e também exibido um campo de seleção
onde é listado os certificados digitais instalados no diretório pessoal do usuário.
Ao lado do campo de seleção o usuário pode utilizar o botão para atualizar a lista de
certificados caso o token ou cartão seja inserido após o acesso à visão citada. Após o
cadastro do certificado o sistema redireciona o usuário à visão [show] onde é possível
visualizar todas as informações do certificado vinculado além do download da chave
pública correspondente. A figura 21 ilustra a visão [create] do modelo [D002Certificado].

56
Figura 21 - Visão [Create] do modelo [D002Certificado]
Ao vincular o certificado ao seu perfil, as informações principais do certificado estarão acessíveis
na visão [Show] do modelo [D002Certificado] como é possível visualizar na figura 22.
Figura 22 - Visão [show] do modelo [D002Certificado]
Na figura 22 e possível visualizar o resultado da vinculação do certificado ao perfil do
usuário. Apesar do certificado possuir diversas outras informações, apenas as principais
são mostradas.

57
4.3.3. Modelo D003Documento
Os documentos enviado para o portal são armazenados através do modelo
[D003Documento] que possui como atributos: [nome], [descrição], [filename], [hash],
[tipoPermissão], [arquivo], [tamanhoReal] e [tamanhoCompactado]. É relacionado com os
modelos [D004Assinatura] e [D005Compartilhamento], trazendo na navegação entre
entidades um lista de objetos de cada modelo relacionado através da propriedade hasMany
do Grails. Os atributos [arquivo], [tipoPermissão] e [descrição] são obrigatórios e são os
únicos que constam na visão [create]. A visão [create] é mostrada na figura 23.
Figura 23 - Visão [create] do modelo [D003Documento]
O documento pode possuir três tipos de permissão, pode ser privado ou público, no caso do
tipo privado o documento não é listado no resultado das pesquisas feitas por usuários do
portal, sendo visualizado apenas via compartilhamento pelo seu proprietário. Caso seja
público, pode permitir a assinatura por qualquer usuário ou apenas o download do arquivo.
Tanto a visão de autenticação como a barra de ferramentas dos usuários autenticados
possui um campo para pesquisa de arquivo, esse campo refere-se ao método
[buscaDocumentos] do controlador [D003Documento]. A visão interligada esse método
pode ser vista na figura 24.

58
Figura 24 - Visão: [buscaDocumentos] do modelo [D003Documento]
Esse método recebe como parâmetro o texto digitado pelo usuário e faz a pesquisa por um
documento cadastrado buscando pelos atributos [Id], [nome], [descrição], [hash] ou
[filename], obedecendo as configurações de permissão definidas em cada documento. Os
resultados da busca são retornados pelo controlador e podem ser visualizados na visão
[buscaDocumentos].
O controlador [D003Documento] possui as funções essenciais para gerenciamento como
[create], [edit], [delete], [update] e [show] além do método [arquivoBaixar] que recebe
como parâmetro o id do arquivo e como resultado escreve o conteúdo do arquivo na
propriedade outputStream do objeto response da sessão HTTP, provendo o download do
arquivo pelo usuário. Possui ainda dois templates que são exibidos em visões
compartilhadas como a [dashboard].
Os templates são visões que podem ser incluídas dentro de visões, o Grails disponibiliza o
método [Render] que tem como objetivo a inclusão de uma visão dentro de outra. Na visão
[show] é possível visualizar todas as informações e ações relacionadas ao arquivo, como
suas assinaturas e compartilhamentos.

59
Todas as informações relacionadas ao documento incluindo informações sobre suas
assinaturas e compartilhamentos, podem ser visualizados na visão [show] do modelo
[D003Documento], como mostra a figura 25.
Figura 25 - Visão [show] do modelo [D003Documento]
A figura 25 mostra as informações sobre um documento na visão [show] do modelo
[D003Documento]. É possível ver informações como o hash do documento enviado, sua
lista de assinaturas e sua lista de compartilhamentos.
4.3.4. Modelo D004Assinatura
Cada assinatura feita pelo portal é armazenada pelo modelo [D004Assinatura], os atributos
[assinatura], [dataHoraAssinatura], [pessoa], [certificado], [arquivo], [ehAutoAssinado],
[estahRevogado] e [caminhoOk] fazem parte da estrutura do modelo. Nenhum dos
atributos é informado pelo usuário pois a assinatura é gerada programaticamente, portanto
nenhum dos atributos permitem valores nulos. É relacionado com os modelos
[D001Pessoa], [D002Certificado] e [D003Documento], trazendo na navegação entre

60
entidades um instancia de objetos de cada modelo relacionado através da propriedade
belongsTo do Grails.
No momento da assinatura é feita uma solicitação de acesso à chave privada do certificado
do usuário, nesse momento o sistema operacional existe uma tela solicitando a senha do
certificado, após a informação da senha a chave privada é utilizada para criptografia do
hash do arquivo e a assinatura é criada e armazenada como um array de bytes no atributo
[assinatura] do modelo.
O controlador D004Assinatura possui as funções essenciais para gerenciamento como
[create], [edit], [save], [delete] e [show] além do método [assinaturaBaixar] que permite o
download da assinatura do arquivo. Na visão [create], mostrada na figura 26, o usuário
escolhe o certificado a ser utilizado e clica no botão assinar, a assinatura é criada e o
usuário é redirecionado para a visão [show], mostrada na figura 27, com as informações
sobre a assinatura do documento.
Figura 26 - Visão [create] do modelo [D004Assinatura]
Como é possível ver na figura 26, o portal lista os certificados instalados no computador do
usuário. Clicando no botão “Assinar” o software dá início ao processo de assinatura
utilizando a chave e as informações do certificado escolhido na lista.

61
Figura 27 - Visão [show] do modelo [D004Assinatura]
Além da criação da assinatura digital do arquivo, são efetuadas três verificações com o
certificado utilizado. As verificações são identificadas pelas cores verde e vermelho de
acordo com o resultado obtido, como pode ser visualizado na figura 27. A primeira
verificação informa se o certificado utilizado é auto assinado ou foi assinado por uma
autoridade certificadora superior, caso seja auto assinado o ícone da verificação contento
as letras “AA” se apresentará na cor vermelha, caso o certificado seja assinado por um AC
superior o ícone será verde.
A segunda verificação faz a leitura do campo “cRLDistributionPoints” localizado nas
extensões do certificado e recupera a URL contendo a lista de revogação publicada pela
AC responsável pela emissão do certificado, faz o download da lista e verifica se o número
serial do certificado encontra-se nela, caso positivo o certificado utilizado foi revogado e o
ícone de verificação contendo as letras “RC” ficará vermelho, caso contrário o ícone estará
verde informando que o certificado não estava revogado no momento da assinatura.
A terceira verificação é feita sobre o caminho de certificação e retorna o ícone verde caso o
certificado seja assinado por uma autoridade certificado intermediaria que por sua vez
precisa ter seu certificado assinado por uma autoridade certificado raiz. Caso não exista
essa relação de confiança na cadeia de certificados o ícone apresenta-se vermelho
informando que o certificado não está em conformidade com as regras estabelecidas pela
ICP-Brasil.

62
4.3.5. Modelo D005Compartilhamento
Quando um documento é compartilhado o sistema cria uma nova instancia no modelo
[D005Compartilhamento] que armazena a data e hora em que o compartilhamento ocorreu
e o tipo de compartilhamento escolhido pelo usuário. É relacionado com os modelos
[D001Pessoa], e [D003Documento] vinculando o documento compartilhado à duas
pessoas. Nesse momento o documento passa a aparecer no template [docsCompartilhados]
do modelo [D003Documento].
Possui as funções essenciais para gerenciamento como [create], [edit], [save], [delete] e
[show]. Na visão [create], mostrada na figura 28, o usuário deve digitar o nome da pessoa
com quem quer compartilhar o arquivo, o campo possui a função auto completar e caso o
usuário não apareça na lista, um convite deve ser enviado antes que o arquivo possa ser
compartilhado. Na visão [edit] é possível alterar o tipo de compartilhamento do arquivo e
na visão [show], mostrada na figura 29, é possível visualizar as informações sobre o
compartilhamento.
Figura 28 - Visão [create] do modelo [D005Compartilhamento]
Na visão [create] demonstrada na figura 28 temos a tela para compartilhamento de
documentos. Ao iniciar a digitação no campo de texto o sistema faz uma busca pelos
usuários do portal e os lista para escolha. Caso o usuário não apareça na lista, um convite

63
deve ser enviado. Caso o usuário já seja cadastrado, o compartilhamento pode ser
controlado com permissões de assinatura ou apenas download do documento.
Figura 29 - Visão [show] do modelo [D005Compartilhamento]
Após a conclusão do compartilhamento a visão [show] demostrada na figura 29 diz o
resultado e as informações sobre o compartilhamento criado.
4.4.CODIFICAÇÃO
A linguagem de programação utilizada para o desenvolvimento da aplicação foi uma
mesclagem das linguagens Groovy e Java devido a interoperabilidade do framework Grails
com as mesmas. Parte da codificação foi produzida nos próprios controladores do sistema,
porém se fez necessária a criação de serviços extras devido a utilização de um mesmo
procedimento por mais de um ou controlador, como é o caso da compactação e
descompactação de arquivos e as verificação de validade dos certificados.
O Grails utiliza a filosofia “dont repeat yourself” e baseando-se nela disponibiliza Finders
dinâmicos para consulta de dados entre modelos. Com a utilização dos Finders dinâmicos
foi possível poupar a criação de diversas customizações nas classes de modelo, pois o
Grails já traz as consultas básicas prontas e sem a necessidade da criação de nenhuma linha
de código. A figura 30 mostra um exemplo de uso dos Finders dinâmicos.

64
Figura 30 - Demonstração do uso de Finders dinâmicos
Como é possível perceber na figura 30, o modelo [D001Pessoa] nos fornece um método
chamado [findByEmailAndHashSenha] que recebe como parâmetro o e-mail e a senha do
usuário. Esse método não foi codificado no modelo porém o Grails fornece métodos
básicos de pesquisa seguindo convenções predefinidas. Esses métodos são chamados de
Finders Dinâmicos (GRAILS, 2013).
4.4.1. O processo de assinatura digital
Para criação da assinatura digital é preciso ter acesso à chave privada do certificado
informado. Para isso o sistema cria uma instancia da classe [KeyStore] passando como
parâmetro o nome do certificado escolhido pelo usuário. Após obter a chave privada, o
sistema cria uma instancia da assinatura baseada no algoritmo [SHA1withRSA] e passa a
chave privada obtida como parâmetro, assim a assinatura será criada com o algoritmo
informado e baseada na chave privada do usuário.
O documento é lido byte a byte e o objeto da assinatura é atualizado com o conteúdo do
mesmo. Após o fim da leitura um bloco de bytes é criado contendo o hash do documento
criptografado com a chave privada do certificado informado, esse bloco de dados é a
assinatura digital, obtida através do método “sign()” do objeto assinatura.
Após a criação da assinatura são feitas as verificações de auto assinatura, revogação e do
caminho de certificação do certificado utilizado, após a conclusão das três verificações a
assinatura e armazenada em banco de dados. O trecho de código responsável pela
assinatura do documento pode ser conferido na figura 31.

65
Figura 31 - Codificação da assinatura digital do arquivo
É possível verificar na figura 31 a utilização de um objeto Keystore responsável pelo
armazenamento das chaves criptográficas. O mesmo é protegido por uma senha e a partir
dele é possível ter acesso à chave pública e privada do certificado escolhido pelo usuário e
passado como parâmetro ao controlador. O objeto da assinatura é instanciado tendo como
base o algoritmo “SHA1withRSA” e alimentado com o conteúdo do arquivo, gerando no
final do processo a assinatura digital. Logo após o certificado escolhido passa pelas
verificações de auto assinatura, revogação e caminho de certificação. A assinatura é
persistida em banco de dados e o sistema retorna a visão [show] do modelo
[D004Assinatura].
4.4.2. Verificação de Auto Assinatura
Diversas ferramentas podem ser encontradas para criação de chaves criptográficas e
certificados digitais, mas como vimos anteriormente, para que uma assinatura tenha
validade jurídica no Brasil, o certificado correspondente precisa ser assinado por uma
autoridade certificadora válida na arvore de certificação da ICP-Brasil.
Em Java é possível efetuar essa verificação instanciando-se o objeto do pacote
“java.security.cert.Certificate” que disponibiliza o método “verify(PublicKey key)”. Esse
método recebe como parâmetro uma chave pública e verifica se o certificado foi assinado
com a chave privada correspondente. Caso não seja, o método retorna uma exceção

66
informando que a assinatura não corresponde à chave informada, do contrário retorna um
resultado verdadeiro, confirmando que a assinatura foi criada com a chave privada
correspondente à chave pública informada. É possível ver um exemplo dessa verificação
na figura 32.
Figura 32 - Verificação de auto assinatura
4.4.3. Verificação do Caminho de Certificação
Como visto anteriormente a ICP-Brasil define que para ser válido, um certificado precisa
ser emitido dentro da arvore de confiança definida pela legislação. Assim para
verificarmos a validade do caminho de certificação precisamos nos assegurar que o
certificado foi assinado por uma autoridade certificadora intermediária e por fim verificar
se o certificado da autoridade intermediária foi assinado pela certificadora raiz.
Em Java precisamos instanciar o objeto da classe “java.security.cert.TrustAnchor” para
criarmos uma ancora de confiança. Essa ancora é composta por três certificados, o
certificado da AC Raiz, o certificado da AC intermediária e o certificado que precisa ser
validado. Por fim, através do método “validade()” do objeto da classe
“java.security.cert.CertPathValidator”, passamos como parâmetro, os certificados a serem
validados, os parâmetros do algoritmo de certificação e a ancora de confiança e recebemos
como resultado a validação do caminho. O método validade faz a verificação citada
anteriormente baseando-se na ancora de confiança, caso todo o processo ocorra sem
problemas, o método retornar um resultado verdadeiro e em caso negativo lança a devida
exceção.
4.4.4. Verificação de Revogação do Certificado
Toda autoridade certificadora tem por obrigação manter em um diretório público, uma lista
com todos os certificados revogados. Essa lista pode ser acessada pelo campo

Desenvolvimento de um portal para assinatura digital de arquivos

Desenvolvimento de um portal para assinatura digital de arquivos

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (18)

Semelhante a Desenvolvimento de um portal para assinatura digital de arquivos

Semelhante a Desenvolvimento de um portal para assinatura digital de arquivos (20)

Desenvolvimento de um portal para assinatura digital de arquivos