i
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
AUTENTICAÇÃO DE CONTEÚDO WEB COM ASSINATURA
DIGITAL E CARIMBO DO TEMPO
Área de Segurança em Sistemas Distribuídos
por
Eduardo Jorge dos Santos Cordeiro
Michelle S. Wangham, Dra.
Orientadora
São José, novembro / 2012.
ii
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
AUTENTICAÇÃO DE CONTEÚDO WEB COM ASSINATURA
DIGITAL E CARIMBO DO TEMPO
Eduardo Jorge dos Santos Cordeiro
São José, novembro de 2012.
Orientadora: Michelle Silva Wangham, Dra.
Área de Concentração: Gestão da Segurança em Sistemas Distribuídos
Linha de Pesquisa: Autenticação de Conteúdo Web
Palavras-chave: Assinatura Digital, Crimes Eletrônicos, Carimbo do Tempo.
Número de páginas: 121
RESUMO Devido à larga utilização da Internet, diversos crimes eletrônicos vêm ocorrendo no meio
digital. Dentre estes se destacam a calúnia, a injúria, a difamação e a violação dos direitos autorais.
Estes crimes vêm aumentando por diversos fatores tais como, por exemplo, a falsa sensação de
anonimato que os usuários sentem, a política dos servidores Web em não autenticar seus usuários, o
desconhecimento das ações que a vítima pode realizar e ainda as dificuldades de se registrar um fato
ocorrido na Internet. O presente trabalho é caracterizado por uma pesquisa aplicada, cujo objetivo é
auxiliar o registro de um possível ato criminoso, arquivando o conteúdo web suspeito em meio digital,
através do desenvolvimento de uma aplicação Web para criação de atas notariais eletrônicas para
Cartórios Digitais. Na etapa de projeto, foi realizada a modelagem da aplicação Web, contendo casos
de uso, diagramas e requisitos funcionais e não funcionais. A segurança foi um dos requisitos mais
importantes no desenvolvimento deste trabalho, pois, no contexto desta aplicação, os dados
armazenados representam uma grande importância na confiabilidade da aplicação. Para atingir este
objetivo foram utilizados mecanismos de criptografia, com o protocolo SSL, e mecanismos de controle
de acesso para garantir que somente usuários legítimos da aplicação tenham acesso. Além disso, no
trabalho foi utilizado um mecanismo que garante a integridade, autenticidade e tempestividade dos
dados armazenados, utilizando da assinatura digital no momento de sua geração através do
procedimento de verificação e validação da assinatura digital. Estruturalmente, a aplicação
desenvolvida consiste de módulos que interagem entre si, sendo cada um responsável em implementar
um conjunto de funcionalidades que completam a aplicação. Por fim, a principal contribuição deste
trabalho foi o desenvolvimento da aplicação Web segura responsável pelo armazenamento de dados
coletados da Internet através de um endereço previamente fornecido utilizando-se da interface da
iii
aplicação. Outra contribuição deste trabalho foi o desenvolvimento da funcionalidade de criação de
modelos (templates) pré-cadastrados para agilizar o processo de geração de atas notariais.
Palavras Chave: Ata Notarial, Assinatura Digital, Carimbo do Tempo.
iv
ABSTRACT
Due to the wide use of Internet, various electronic crimes are occurring in the digital medium.
Among these stand out slander, libel, defamation and copyright infringement. These crimes have
increased by several factors such as, for example, the false sense of anonymity that users feel, the
policy of the Web servers do not authenticate their users, unaware of the actions that the victim can
perform and still difficulties registering an event that happened on the Internet. This work is
characterized by an applied research, whose goal is to support the registration of a possible criminal
act, filing suspicious web content in digital media by developing a web application for creating
electronic notarial minutes to Digital Notary. In the design phase, the modeling was performed web
application, containing use cases, diagrams and functional and nonfunctional requirements. Security
was one of the most important requirements in the development of this work, because in the context of
this application, the stored data represent a great importance in the application reliability. To achieve
this objective we have used encryption mechanisms with SSL, and access control mechanisms to
ensure that only legitimate users have access to the application. Also, at work we used a mechanism
that ensures the integrity, authenticity and timeliness of data stored using digital signature at the time
of their generation through the procedure of verification and validation of the digital signature.
Structurally, the developed application consists of modules that interact with each other, each being
responsible for implementing a set of features that complete the application. Finally, the main
contribution of this work was the development of secure web application responsible for storing data
collected through an Internet address previously provided using the application interface. Another
contribution of this work was the development of functionality for creating models (templates) pre-
registered to streamline the process of generating notarial minutes.
Keywords: Notarial Minutes, Digital Signature, Time Stamp.
v
“A vida nos apresenta obstáculos
para que possamos superá-los
a fim de nos aperfeiçoarmos”
vi
Dedico este trabalho à minha mãe Marilete Agostinha dos Santos,
que nunca mediu esforços e sempre acreditou em mim em todos
os momentos e que se não fosse por ela hoje eu não estaria nem
perto de chegar onde cheguei. E uma dedicatória especial à
memória de meu pai Gilmar Tarcisio Cordeiro que infelizmente
teve a sua intensa e alegre passagem pela Terra encurtada.
vii
AGRADECIMENTOS
Em primeiro lugar agradeço ao apoio, incentivo, motivação, amizade e descontração
proporcionada por toda a minha família, em especial pelas minhas tias Cristiane Cordeiro Berbler,
Fernanda Letícia Cordeiro e Valéria Cordeiro, primos Glaucio Tadeu Cordeiro, Michelly Cordeiro
Berbler e Carolina Luiza dos Santos Vieira e irmã Heloisa dos Santos Cordeiro Dias.
Em seguida, gostaria de deixar a minha gratidão à minha orientadora Michelle Wangham que
aconselhou em todas as minhas dúvidas, corrigiu cada vírgula e me deu toda a base e estrutura
necessária para poder desenvolver este trabalho.
Também agradeço à equipe da BRy, em especial ao Jeandré Monteiro pelas ideias fornecidas, à
Janira Silveira Pereira e Davi Garcia Pereira pela compreensão e suporte necessário.
Aos meus padrinhos Roberto Bez e Denise Martins Bez que eu sempre admirei e também
sempre me serviram de exemplo durante toda a minha vida.
Por último, mas não menos importantes, a todos os meus amigos que eu tanto considero, em
especial ao meu amigo Gert Campos Hentschel que auxiliou a várias dúvidas estruturais e jurídicas
deste trabalho, meu eterno amigo Daniel Martins Bez, aos irmãos Vinicius França de Souza e Rafael
França de Souza, e aos amigos da pinheira Jeison Lostada, Sangela Cirolini, Gabriel Cabelo Pereira,
Rafael Schlemper e Maria Luiza Zapelini
8
SUMÁRIO
1 INTRODUÇÃO ..................................................................................................... 12
1.1 PROBLEMA DE PESQUISA ........................................................................... 13
1.1.1 SOLUÇÃO PROPOSTA ........................................................................................ 15
1.1.2 DELIMITAÇÃO DO ESCOPO ............................................................................... 16
1.2 OBJETIVOS ....................................................................................................... 17
1.2.1 OBJETIVO GERAL ............................................................................................. 17
1.2.2 OBJETIVO ESPECÍFICO ..................................................................................... 17
1.3 METODOLOGIA .............................................................................................. 18
1.3.1 METODOLOGIA DE PESQUISA ........................................................................... 18
1.3.2 PROCEDIMENTOS METODOLÓGICOS ............................................................... 19
1.4 ESTRUTURA DO TRABALHO ................................................................................. 19
2 FUNDAMENTAÇÃO TEÓRICA ....................................................................... 21
2.1 CRIPTOGRAFIA .............................................................................................. 22
2.1.1 CRIPTOGRAFIA SIMÉTRICA .............................................................................. 23
2.1.2 CRIPTOGRAFIA ASSIMÉTRICA .......................................................................... 23
2.1.3 FUNÇÕES DE HASH ........................................................................................... 25
2.1.4 ASSINATURA DIGITAL ....................................................................................... 26
2.1.4.1 PROTOCOLOS DE AUTENTICAÇÃO ................................................................ 29
2.1.5 GERENCIAMENTO DE CHAVES PÚBLICAS E CERTIFICADO DIGITAL ................. 30
2.1.6 CARIMBO DO TEMPO........................................................................................ 33
2.1.7 VALIDADE JURÍDICA DE DOCUMENTOS DIGITAIS ............................................. 36
2.2 CRIMES ELETRÔNICOS................................................................................ 37
2.2.1 LEIS E TIPIFICAÇÃO DE CRIMES ELETRÔNICOS ................................................ 38
2.2.2 TERRITORIALIDADE E A INTERNET .................................................................. 39
2.2.3 FORENSE COMPUTACIONAL E EVIDÊNCIA DIGITAL ......................................... 40
2.3 ATA NOTARIAL ............................................................................................... 42
2.4 CARTÓRIO DIGITAL ...................................................................................... 43
2.4.1 CARTÓRIO 24 HORAS ........................................................................................ 43
2.4.2 SERVIÇO OFERECIDO ATRAVÉS DE UMA APLICAÇÃO WEB ............................... 45
3 DESENVOLVIMENTOS ..................................................................................... 46
3.1 VISÃO GERAL DA APLICAÇÃO WEB .......................................................... 46
3.2 REQUISITOS ..................................................................................................... 48
3.2.1 REQUISITOS FUNCIONAIS ................................................................................. 49
3.2.2 REQUISITOS NÃO FUNCIONAIS ......................................................................... 50
3.2.3 REGRAS DE NEGOCIO ....................................................................................... 51
3.3 DIAGRAMAS DE CASO DE USO ................................................................... 51
3.4 DIAGRAMA DE SEQUÊNCIA ........................................................................ 58
3.5 TECNOLOGIAS E FERRAMENTAS UTILIZADAS ................................... 64
9
3.6 DETALHAMENTO DO DESENVOLVIMENTO ......................................... 66
3.6.1 AUTENTICAÇÃO E CADASTRO DE USUÁRIOS NA APLICAÇÃO WEB .................. 66
3.6.2 GERENCIAMENTO DE ATAS NOTARIAIS. ........................................................... 71
3.6.3 MÓDULO DE DOWNLOAD DO CONTEÚDO WEB E CONVERSÃO PARA PDF ...... 78
3.6.4 MÓDULO DE CONVERSÃO E CONCATENAÇÃO DA ATA NOTARIAL E DO
CONTEÚDO WEB .......................................................................................................... 78
3.6.5 GERENCIADOR DE ASSINATURA DIGITAL E CARIMBO DO TEMPO .................... 79
3.6.6 COMPACTAÇÃO DOS DADOS ARMAZENADOS .................................................... 81
3.6.7 CRIAÇÃO DE MODELOS DE ATAS NOTARIAIS .................................................. 82
3.6.8 PREVENÇÃO CONTRA ATAQUES ........................................................................ 85
3.6.8.1 CROSS-SITE SCRIPTING (XSS) ...................................................................... 85
3.6.8.2 SNIFFING OU SNIFFERS .................................................................................. 86
3.6.8.3 BUFFER OVERFLOW ...................................................................................... 87
3.6.8.4 SQL INJECTION ............................................................................................. 87
3.7 DESCRIÇÃO DOS EXPERIMENTOS ........................................................... 88
4 CONCLUSÃO ....................................................................................................... 95
4.1 TRABALHOS FUTUROS ................................................................................. 97
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................... 99
ANEXO A - MEDIDA PROVISÓRIA Nº 2200-2 ................................................. 103
ANEXO B - DECRETO-LEI 2.848, DE 7 DE DEZ. DE 1940 ............................. 106
ANEXO C - CASOS DE TESTE ............................................................................ 108
ANEXO D - TESTES UNITÁRIOS ....................................................................... 114
ANEXO E - CONTRATO DE LICENÇA ............................................................. 121
10
LISTA DE ABREVIATURAS
AC Autoridade Certificadora
AC-Raiz Autoridade Certificadora Raiz
ACT Autoridade Certificadora do Tempo
AD-RB Assinatura Digital com Referência Básica
AD-RT Assinatura Digital com Referência para o Tempo
AD-RV Assinatura Digital com Referência para Verificação
AD-RC Assinatura Digital com Referência Completa
AD-RA Assinatura Digital com Referência para Arquivamento
AR Autoridades de Registro
CADES CMS Advanced Electronic Signatures
CETIC Centro de Estudos da Tecnologia da informação e Comunicação
CPF Cadastro de Pessoa Física
CMS Advanced Electronic Signature
CNPJ Cadastro Nacional de PEssoa Jurídica
CNSEC Centro Notarial de Serviços Eletrônicos Compartilhados
DDD Discagem Direta a Distância
FBI Federal Bureau of Investigation
ICP Infraestrutura de Chaves Públicas
ICP-Brasil Infraestrutura de Chaves Públicas do Brasil
IETF Internet Engineering Task Force
ITI Instituto Nacional de Tecnologia da Informação
ITU International Telecommunications Union
JSF Java Server Faces
NIST National Institute of Standards and Technology
PKI Public Key Infrastructure
RFC Request for Comments
RG Registro Geral
RSA Ronald Rivest, Adi Shamir e Leonard Adleman
11
SaaS Software as a Service
SAS Sistema de Auditoria e Sincronismo
SCT Servidor de Carimbo do Tempo
SHA Security Hash Algorithm
SSL Secure Sockets Layer
TIC
UML
Tecnologia da informação e comunicação
Unified Modeling Language
XML eXtensible Markup Language
12
1 INTRODUÇÃO
Segundo a pesquisa sobre o uso das Tecnologias de Informação e Comunicação no Brasil –
TIC Domicílios, realizada anualmente pelo Cetic.br, sob coordenação do Comitê Gestor da Internet,
53% da população teve algum acesso à Internet em 2011. Tomando-se por base as pessoas que
acessaram a rede por pelo menos uma vez nos últimos três meses do ano de 2011, a proporção
aumentou de 24% (vinte e quatro por cento), em 2005, para 45% (trinta e nove por cento), em 2011
(CETIC.BR, 2011). De acordo com a Fecomércio-RJ/Ipsos, o percentual de brasileiros conectados à
Internet aumentou de 27% (vinte e sete por cento) para 48% (quarenta e oito por cento), entre 2007
e 2011.
Segundo Reis (2003), os problemas com crimes eletrônicos aumentarão cada vez mais, pois
a Internet permite que seus usuários não sejam obrigados a revelar a sua identidade ou, que pelo
menos, tenham a falsa sensação de anonimato, o que facilita algumas espécies de crimes.
Segundo Pinheiro (2009, p.170 – 229), 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. Segundo a autora, 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.
Pereira et al.(2007) ressaltam a importância que a computação forense terá na sociedade,
pois com esta será possível auxiliar a identificação dos crimes virtuais cometidos e assim, punir
apropriadamente os infratores.
Pinheiro (2009, p.228 – 229) descreve que, atualmente, diversos incidentes vêm sendo
verificados, como por exemplo, os crimes de calúnia, difamação, injúria, constrangimento ilegal,
ameaça e violação de direito autoral (plágio), sendo que estes crimes ocorridos em meio virtual, não
são mais considerados como incomuns.
Naturalmente, um dos problemas enfrentados é a identificação do usuário, pois o mesmo
possui a alternativa de negação da ação, ou seja, sua irretratabilidade não está assegurada, pois, em
muitos casos, os provedores não exigem uma autenticação dos usuários. Para Kurosse e Ross (2006,
13
p.531) a irretratabilidade pode ser entendida como o não repúdio, ou seja, garantir que um emissor
não possa negar a autenticidade de suas ações (p.ex., suas mensagens).
É importante ressaltar que, em matéria de segurança, os provedores de conteúdo transferem
toda a responsabilidade do conteúdo de páginas web (sejam conteúdos adicionados e/ou editados)
para os usuários que incluíram este conteúdo (PINHEIRO 2009, p.61 - 62). Por exemplo, o acordo
de termos de uso do servidor Wix.com1 prevê que:
“(...) o Wix.com não garante nenhuma proteção em relação a quaisquer envios. Você entende
que todos os envios do usuário são de exclusiva responsabilidade do usuário que está
enviando este conteúdo. Você, e não o WIX é inteiramente responsável por todo o conteúdo
que você envia, posta, transmite ou de outra forma disponibilizar através do serviço. O WIX
não controla o conteúdo postado através do serviço e, como tal, não garante a precisão, a
integridade ou a qualidade desse conteúdo ou que esse envio não viola nenhum direito de
terceiros. (...) o WIX renuncia expressamente toda e qualquer responsabilidade em relação
aos Envios do Usuário. (...) O WIX não se responsabiliza pelo conteúdo de qualquer Envio
do Usuário e expressamente isenta-se de toda a responsabilidade daí relacionada.”.
O fragmento acima não só limita a responsabilidade do provedor, como a exclui por
completo possibilitando que o usuário possa fazer publicações irresponsáveis na Internet, ou seja,
não existe um responsável verídico, pois a real identificação do usuário infrator pode não estar
disponível facilitando desta forma a irretratabilidade.
Dentro deste contexto, este trabalho procurou fazer uma contribuição para auxiliar o registro
de incidentes que possam vir a ser caracterizados como crimes virtuais.
1.1 PROBLEMA DE PESQUISA
Como Pereira et al.(2007) descreve, estão entre os crimes mais comuns a calúnia, injúria,
difamação e violação dos direitos autorais. Os tipos de ações criminais podem ser realizados em
diversos ambientes no meio eletrônico, pois como ressalta Pinheiro (2009, p.228), a facilidade de
mobilidade de acesso à Internet do usuário facilita as mais diversas ações dentro da rede, da mesma
1 Que está disponível na íntegra em http://pt.wix.com/about/terms-of-use
14
forma que dificulta as investigações, pois são poucas as equipes preparadas para realização da
investigação e perícia de um crime virtual.
Pode-se citar como exemplo dos problemas decorrentes dos crimes eletrônicos o caso de
Ana Carolina Favano, namorada do guitarrista da banda NX_Zero. Após o sucesso da banda, os
inúmeros perfis falsos no Orkut, passando-se por ela, foram criados, juntamente com comentários
maldosos e fotos falsas distorcendo a sua imagem. Este caso pode ser considerado como um crime
contra a honra. Devido a falta de informação de Ana Carolina e sua família, esta situação incômoda
e constrangedora ocorreu por alguns meses (DUPRAT, 2008).
Segundo afirmação de Pinheiro (2009, p.60), é importante ressaltar que muitos conteúdos
que estão na Internet poderão ser acessados por pessoas e sendo desta forma, não existe uma
materialização do objeto como existe no mundo real para transportar os direitos, que é o que ocorre
com bens materiais como livros, filmes, CD, entre outros, pois estes quando sofrem a violação do
direito autoral (ex: cópia ilegal), por exemplo, a localização da fonte geralmente se torna mais fácil
do que esta busca em meios virtuais.
Conforme Pinheiro (2009), o Brasil tem investido em delegacias especializadas em crimes
eletrônicos, porém, estas delegacias ainda existem em número reduzidos, o que dificulta a rápida
tomada de ações e, também, o acesso a informações da melhor maneira da vítima proceder. Porém,
estas não são do conhecimento da maioria da população e também estas não existem em todos os
estados e cidades o que pode tornar difícil realizar o registro de algum indício de crime eletrônico.
Atualmente, o processo de registro de um crime ocorrido contra a honra ou contra os direitos
autorais é feito de forma tradicional e pode se tornar demorado, pois depende da vítima se dirigir
aos locais onde se encontram os órgãos especializados como um cartório e relatar o fato ocorrido
para produção de uma ata notarial. Após este registro, a vítima deverá possuir uma cópia impressa
da ata notarial, contendo todas as informações relevantes e relacionadas ao fato. Posteriormente, a
vítima deverá procurar uma delegacia de polícia para realizar o registro de um boletim de
ocorrência para concretizar a prova (SANT’ANA & ROVER, 2011).
Em Sant’ana e Rover (2011), os autores descrevem os procedimentos para lavrar uma ata
notarial em Cartório, que pode ser entendida como um documento público que guarda o mesmo
valor “probandi” de uma escritura pública, sendo que os procedimentos jurídicos a serem tomados
estarão descritos no Capítulo 2.
15
Segundo Pinheiro (2009), para o auxílio à proteção da informação, é necessário gerar prova
de autoria, requisito jurídico para validar obrigações e responsabilidades e utilizar meios adequados
para garantir a integridade do documento eletrônico.
Atualmente, uma vítima de um crime eletrônico tem que recorrer ao método tradicional
descrito por Sant’ana e Rover (2011), o que poderá acarretar em tempo perdido e dificuldades de
autenticação de um conteúdo possivelmente criminoso. Este trabalho contribuiu de forma a auxiliar
o registro, a denúncia e investigação de alguns tipos de crimes virtuais. Conforme descrito, este
problema vem crescendo pela falta de informação e também pela dificuldade da vítima fazer, de
forma rápida, um registro do conteúdo que esteja em meio eletrônico e que o mesmo tenha uma
validade jurídica. Este trabalho visou automatizar este processo e produzir um registro em meio
eletrônico com validade jurídica que pode ser utilizado como prova de crimes contra a honra e
violação de direitos autorais.
A partir da contextualização apresentada, formularam-se os seguintes itens de pesquisa,
indicando os desafios a serem enfrentados:
Como automatizar o processo de registro de um crime cometido em meio eletrônico?
Analisar quais evidências ou provas que podem ser geradas e quais as informações
relevantes devem ser incluídas para que estas possam ser utilizadas em processos
judiciais de crimes eletrônicos contra a honra e de violação de direitos autorais.
Modelar e desenvolver a aplicação web capaz de assinar digitalmente e de gerar um
carimbo do tempo de conteúdos publicados em sítios web.
Avaliar a aplicação Web desenvolvida através de testes de software e testes de
segurança.
1.1.1 Solução Proposta
Como não há nenhum sistema que ofereça uma forma eletrônica e automatizada para que
uma vítima possa fazer o pedido e iniciar o processo de registro de uma ata notarial, pretende-se
desenvolver neste trabalho uma aplicação web que possa ser utilizada pelos órgãos competentes
para registro de atas notariais ou provas tais como os Cartórios. A aplicação web irá utilizar
conceitos e mecanismos de segurança para prover segurança ao processo de registro dos fatos de
um possível crime cometido em meio eletrônico, bem como melhorar o acesso às informações e o
seu armazenamento.
16
Três atores estarão interagindo com a aplicação para realizar todo o processo de registro de
uma ata notarial eletrônica. O primeiro ator será a vítima que se sentiu lesada de alguma forma, esta
será denominada de Requerente. O encarregado de realizar verificação e validação dos fatos
descritos pelo Requerente será o ator denominado Tabelião, pois este possui por função a
responsabilidade da tarefa de registro e comprovação dos fatos relatados pela vítima. Por último, o
ator Administrador que será responsável pelo cadastro do ator Tabelião e também de configurações
adicionais como o cadastro da ACT (Autoridade de Carimbo do Tempo).
A aplicação proposta fornecerá uma interface de fácil utilização que atenda tanto as
necessidades dos Requerentes (muitas vezes leigos neste tipo de procedimento eletrônico) quanto
dos Tabeliães que utilizarão a aplicação. A medição da interface para verificar se ela é de fácil
utilização, foi através de um teste de aceitação e do preenchimento de um questionário por parte dos
usuários que utilizarão a aplicação.
Os conceitos e mecanismos de segurança que serão utilizarão como base no
desenvolvimento da solução proposta são: a criptografia de dados, o protocolo SSL, a assinatura
digital, o carimbo do tempo e o certificado digital.
Conforme Stallings (2008, p.272), uma assinatura digital é um mecanismo de autenticação
que permite ao criador de uma mensagem anexar um código que atue como uma assinatura. A
assinatura é formada tomando o hash da mensagem e criptografando-a com a chave privada do
criador. A assinatura digital garante a autenticidade e a integridade da mensagem.
Para assinatura da ata notarial gerada, o tabelião usará certificados digitais emitidos pela
cadeia de certificação da Infraestrutura de Chaves Públicas Brasileiras (ICP Brasil), para garantir a
validade jurídica do documento eletrônico produzido.
Já o carimbo do tempo possui por função indicar de modo seguro a tempestividade, ou seja,
o tempo exato que este foi gerado (RFC 3161, IETF, 2001), sendo que na aplicação proposta este
será anexado a uma assinatura digital.
1.1.2 Delimitação do Escopo
Pretende-se neste trabalho auxiliar os cartórios e as vítimas no registro dos fatos que
comprovam um crime eletrônico, através de uma aplicação web. Para isto, o estudo e as análises
realizadas estarão concentrados no processo de registro de atas notariais.
17
Dentre os inúmeros crimes eletrônicos existentes, este trabalho tem como foco tratar dos
crimes contra honra e contra os direitos autorais. É importante ressaltar que a solução proposta não
pretende evitar ou eliminar os crimes ocorridos em meio eletrônico, mas sim automatizar, de forma
segura, o processo de registro dos fatos relacionados ao crime.
Não foi objetivo deste trabalho desenvolver uma aplicação sem a participação direta do
Tabelião no processo de geração de uma ata notarial, pois no final do processo é o Tabelião que
realiza a verificação e validação dos dados relacionados ao fato descrito pela vítima com a
utilização de seu certificado digital.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral deste trabalho é desenvolver uma aplicação Web capaz de assinar
digitalmente e de gerar um carimbo do tempo para conteúdos que estão em locais públicos na
Internet de forma que estes conteúdos possam ser usados como indícios ou provas em processos
judiciais (produção de uma ata notarial eletrônica).
1.2.2 Objetivo Específico
Visando atingir o objetivo geral proposto, os seguintes objetivos específicos foram
definidos.
Analisar quais evidências ou provas podem ser geradas e quais as informações
relevantes devem ser incluídas para que estas possam ser utilizadas em processos
judiciais de crimes eletrônicos contra a honra e de violação de direitos autorais.
Desenvolver a aplicação web segura capaz de assinar digitalmente e de gerar um
carimbo do tempo de conteúdos publicados em sítios Web.
Avaliar a aplicação Web desenvolvida através de testes de software e testes de
segurança.
18
1.3 METODOLOGIA
Para atender aos objetivos específicos apresentados foram realizadas duas etapas: estudo
bibliográfico e modelagem, conforme demonstrado a seguir.
A primeira etapa (estudo bibliográfico) foi destinada à realização de pesquisas sobre
conceitos gerais de segurança computacional, mecanismos de segurança que garantam a
autenticidade e integridade das informações em uma aplicação, tendo por objetivo a análise de suas
características e cenários. Foram realizadas pesquisas referentes aos crimes eletrônicos, forense
computacional e evidência digital, leis e projetos de lei a serem aprovados e serviços oferecidos por
cartórios dentro e fora da internet. As principais fontes foram livros sobre criptografia e direito,
trabalhos acadêmicos e artigos, sendo usados também textos encontrados na web e documentos
técnicos.
A segunda etapa foi destinada a realização da modelagem da aplicação web para produção
de atas notariais relacionadas a crimes eletrônicos que será desenvolvida no TCC II. Nesta etapa,
uma visão geral da aplicação foi descrita, bem com o levantamento dos requisitos funcionais e não
funcionais da aplicação foram realizados. Diagramas UML (Unified Modeling Language) de casos
de uso, de classe, de sequência e os protótipos das telas da solução proposta também foram
desenvolvidos.
1.3.1 Metodologia de Pesquisa
Para a realização das etapas de pesquisa conceitual e modelagem, foi empregado o método
indutivo. Este método foi utilizado, pois foi realizado um levantamento de dados específicos e sobre
estes dados foi proposta uma aplicação web.
A natureza da pesquisa utilizada é aplicada, pois a mesma busca gerar o desenvolvimento de
uma aplicação web sobre um conhecimento específico com base científica.
Com relação ao ponto de vista da forma de abordagem do problema, a metodologia utilizada
é voltada para a melhora da qualidade, ou seja, qualitativa. Esta forma de caracterizar a pesquisa foi
utilizada, pois o objetivo é melhorar (automatizar) um processo já existente para que as pessoas
possam ter uma maior comodidade, agilidade e segurança.
O objetivo desta pesquisa pode ser entendido como sendo exploratório, descritivo e
explicativo. Exploratória, pois, busca entender com maior profundidade o assunto, de modo a torna-
19
lo mais claro ou construir questões importantes para o andamento da pesquisa. Descritivo, pois
descreve características, realiza coleta de dados e estabelece relações ocorridas na Internet. E
explicativo, pois foi identificado, interpretado e classificado alguns dos fatores responsáveis ou que
contribuem a pesquisa de dados relacionados.
1.3.2 Procedimentos Metodológicos
Visando atingir os objetivos, foi realizada uma pesquisa bibliográfica pesquisa participante e
num próximo passo uma pesquisa documental. A pesquisa bibliográfica voltou-se para saber quais
as publicações existentes vinculadas ao assunto e o que poderá ser melhorado. A pesquisa
participante visa o envolvimento dos possíveis futuros atores da aplicação, que serão o Tabelião e o
requerente. A pesquisa documental será focada em informações que serão coletadas em documentos
em ambientes eletrônicos e públicos e através de estatísticas públicas também.
1.4 ESTRUTURA DO TRABALHO
Este documento está estruturado em quatro capítulos. O Capítulo 1, denominado Introdução,
apresenta uma visão geral do trabalho, a solução proposta, os objetivos (geral e específicos) que
foram alcançados com o desenvolvimento do trabalho e a descrição dos materiais e métodos já
utilizados.
No Capítulo 2, Fundamentação Teórica, é apresentada uma revisão bibliográfica sobre:
conceitos de criptografia, assinatura digital, gerenciamento de chaves públicas, protocolos
criptográficos. Uma descrição do funcionamento atual do cartório digital, da situação atual da
frequência que vem ocorrendo crimes eletrônicos relacionados à honra e a violação dos direitos
autorais bem como os trabalhos relacionados também estão descritos no Capítulo 2.
O Capítulo 3 apresenta o desenvolvimento detalhado da aplicação web desenvolvida,
incluindo a visão geral da aplicação Web para uma melhor compreensão do funcionamento básico
da aplicação juntamente com a sua modelagem dos diagramas UML. Este Capítulo também discute
como foi implementado a aplicação, apresentando as ferramentas, métodos, metodologias e demais
detalhamentos pertinentes ao melhor entendimento. Por fim demonstra-se os testes realizados
visando validar as funcionalidades implementadas na aplicação Web.
Por fim, no Capítulo 4, apresentam-se as conclusões, no qual são abordados os resultados
preliminares, estratégias de desenvolvimento do projeto, dentre outros.
20
21
2 FUNDAMENTAÇÃO TEÓRICA
Primeiramente, precisa-se aduzir que o conceito de segurança da informação pode ser
entendido como sendo “[...] a proteção da informação de vários tipos de ameaças para garantir a
continuidade do negócio, minimizar o risco e maximizar o retorno sobre investimentos e
oportunidades” (ABNT NBR ISO/IEC 27002:2005).
Assim, para auxiliar na segurança da informação, Stallings (2008, p.7) descreve alguns
conceitos como o de autenticidade, confidencialidade, integridade, disponibilidade e
irretratabilidade (não repúdio).
Conforme Stallings (2008, p.8), a autenticação tem por função garantir que uma
comunicação seja autêntica e no caso de uma mensagem é garantir que esta mensagem tenha vindo
de onde esta afirma ter vindo.
Com relação à confidencialidade, Stallings (2008, p.10) diz que é preciso proteger toda e
qualquer informação que está sendo transmitida contra ataques que possam tentar interceptar e
analisar o seu conteúdo.
Já a integridade de dados pode ser entendida como a garantia de que os dados recebidos
estão exatamente como foram enviados por uma entidade autorizada, ou seja, estará garantida se
todos os dados recebidos estiverem intactos (STALLINGS 2008, p.10).
Stallings (2008, p.10) apresenta o conceito de disponibilidade como sendo um sistema que
estará disponível se oferecer os serviços de acordo com o projeto do sistema sempre que os usuários
os solicitarem.
Já o conceito de irretratabilidade pode ser definido como o ato de impedir que um emissor
ou receptor repudie/negue uma mensagem transmitida ou recebida (STALLINGS, 2008, p.10).
Neste Capítulo, são apresentados os conceitos de criptografia simétrica e assimétrica bem
como de assinatura digital, certificados digitais e carimbo do tempo, que foram os mecanismos de
segurança utilizados na solução proposta. Os crimes eletrônicos que estão sendo considerados no
contexto deste trabalho e outros tópicos importantes para a compreensão da solução proposta como
o de cartório digital e de ata notarial são também descritos neste Capítulo. Por fim, alguns trabalhos
relacionados são também analisados.
22
2.1 CRIPTOGRAFIA
O CERT.BR (2006) define que criptografia é a ciência e arte de escrever mensagens em
forma cifrada ou em código. É parte de um campo de estudos que trata das comunicações secretas,
usadas, dentre outras finalidades, para autenticar a identidade de usuários, autenticar e proteger o
sigilo de comunicações pessoais e de transações comerciais e bancárias e proteger a integridade de
transferências eletrônicas de fundos.
Conforme a National Research Council (2001 apud STALLINGS, 2008, p.15), a
criptografia provavelmente é o aspecto mais importante da segurança de comunicações e está se
tornando cada vez mais importante como um componente básico para a segurança computacional
das aplicações distribuídas.
Diante desta afirmação, Stallings (2008, p.15) complementa que a ferramenta automatizada
mais importante para a segurança da rede e das comunicações é a criptografia.
Conforme Stallings (2008, p.19), os sistemas criptográficos podem ser caracterizados em
três dimensões independentes:
1. O tipo das operações usadas para transformar texto claro em texto cifrado. Todos os
algoritmos de criptografia são baseados em dois princípios gerais: substituição e
transposição. Na substituição, cada elemento no texto claro (bit, letra, grupo de bits ou
grupo de letras) é mapeado em outro elemento. Já na transposição, os elementos no texto
claro são reorganizados. O requisito fundamental é que nenhuma informação seja
perdida.
2. O número de chaves usadas: Esta dimensão caracteriza se o sistema criptográfico será
simétrico ou assimétrico, pois se o sistema utilizar mais de uma chave será considerado
assimétrico.
3. O modo como o texto claro é processado: este processamento pode ser sobre um bloco
de informações ou sobre um fluxo de informações, neste segundo a saída é gerada
continuamente, enquanto no primeiro, a saída é feita da mesma forma que a entrada, em
blocos.
Conforme Tanenbaum (2003, p.782), o primeiro princípio criptográfico é que as mensagens
devem conter algum tipo de redundância para poder aumentar a sua segurança. Este princípio tem
por objetivo evitar que mensagens criptografadas válidas sejam geradas por um mal feitor e impedir
23
que sejam transmitidos dados inválidos e que estes dados inválidos possam ser interpretados como
dados válidos por algum sistema.
O segundo princípio descrito para aumentar a segurança de mensagens criptográficas é o da
atualidade, visando a não reutilização de mensagens, pois se a mensagem em algum momento foi
válida, ela sempre será válida, salvo se o sistema possuir algum método para anular ataques de
mensagens repetidas (TANENBAUM, 2003).
2.1.1 Criptografia Simétrica
Stallings (2008, p.17) ensina que a criptografia de chave simétrica também conhecida como
criptografia convencional ou sistema de chaves compartilhadas, realiza tanto a criptografia como a
decriptografia utilizando a mesma chave.
Tendo em vista algumas necessidades, Tanenbaum (2003, p.784) explica que o problema da
distribuição das chaves simétricas sempre foi o elo mais fraco nos sistema de criptografia simétrica,
pois se um malfeitor uma vez possuir acesso a esta chave, todo o sistema de criptografia se torna
inútil. Por exemplo, se uma pessoa chamada Alice deseja enviar mensagens sigilosas a seus amigos,
Alice deverá definir uma chave diferente com cada um deles, caso contrario, seus amigos poderão
interceptar e decifrar todas as mensagens trocadas com os outros amigos.
Um exemplo de algoritmo criptográfico simétrico é o AES (Advanced Encrypted Standard)
que suporta tamanho de chave e de bloco de 128 a 256 bits. Finalizando, o autor complementa que
atualmente a quebra deste algoritmo por força bruta se torna um procedimento inviável
(STALLINGS, 2008).
2.1.2 Criptografia Assimétrica
Segundo Stallings (2008, p.182), a busca por soluções para o problema da distribuição de
chaves da criptografia simétrica foi a principal motivação para o desenvolvimento da criptografia
assimétrica que foi proposta por Diffie e Hellman em 1976. Na criptografia assimétrica ou de chave
pública, o processo de cifragem dos dados e decifragem, são feitos utilizando diferentes chaves. Na
cifragem dos dados se utiliza a chave pública do destinatário e na decifragem a chave privada do
emissor. Normalmente, os criptossistemas de chave pública são utilizados para garantir
24
confidencialidade e autenticidade dos dados. Uma das aplicações da criptografia assimétrica que
tem sido amplamente utilizada é a Assinatura Digital.
Housley e Polk (2001, p.11) comentam que a criptografia assimétrica requer, entretanto,
muito mais poder computacional que operações equivalentes usando criptografia simétrica. Por
isso, não é normalmente usada para cifragem de dados. Ao invés disso, a criptografia assimétrica é
usada para auxiliar no compartilhamento seguro de uma chave simétrica, que é então usada para
cifrar os dados (distribuição de chaves simétricas). Há dois mecanismos deste tipo: acordo de
chaves (como exemplo, o algoritmo de Diffe-Hellman) e transporte de chave (como exemplo, o
algoritmo RSA).
Em 1978, Ronald Rivest, Adi Shamir e Leonard Adleman desenvolveram o algoritmo RSA,
o primeiro algoritmo cifrador assimétrico. Este algoritmo nasceu devido à inviabilidade
computacional da época em fatorar grandes números (STALLINGS, 2008). Conforme Martina
(2005), este algoritmo já passou por diversas melhorias e é o algoritmo de criptografia assimétrica
mais difundido atualmente.
Stallings (2008, p.193) aborda a segurança envolvida no algoritmo RSA e cita as quatro
formas de ataque contra o algoritmo:
A força bruta, que envolve tentar todas as chaves privadas possíveis. A sua defesa é
utilizar um tamanho de chave grande.
Ataques matemáticos, no qual utiliza-se o esforço computacional de fatorar do
algoritmo.
Ataques de temporização que dependem diretamente do tempo de execução do
algoritmo de decriptografia.
E por ultimo, o ataque de texto cifrado escolhido que explora a estruturação e
propriedades do algoritmo RSA.
Stallings (2008, p.183) afirma que os algoritmos de criptografia assimétrica necessitam de
chaves muito maiores do que algoritmos de criptografia simétrica de força equivalente. A segurança
das chaves na criptografia assimétrica é garantida pela dificuldade de se executar os cálculos
necessários que o algoritmo exige. Mas toda a técnica utilizada não é garantia de que sempre o
algoritmo será seguro, pois constantemente algoritmos estão sendo quebrados devido ao
melhoramento das técnicas de ataques e também do aumento do poder computacional.
25
2.1.3 Funções de Hash
Conforme Stallings (2008, p.226), uma função hash é uma função matemática que recebe
como entrada uma mensagem ou um número qualquer de bits e produz como saída um valor hash
de tamanho fixo, também chamado de um resumo de mensagem (message digest). É importante
ressaltar que apesar de diversas funções possuírem estas características citadas, funções de hash
devem conter ainda mais duas características essenciais na criptografia moderna:
deve ser computacionalmente impossível recuperar os dados de entrada a partir do hash
gerado; e
deve ser computacionalmente impossível gerar duas entradas diferentes que produzam o
mesmo valor quando passadas pela função de hash.
Com o resumo de mensagem gerado, é possível garantir a integridade de uma mensagem,
porque o resumo obtido no destino deve ser igual ao resumo obtido na origem. Caso haja alguma
alteração durante o envio da mensagem, o resultado obtido no destino será diferente daquele que se
teve na origem da mensagem (MIGNONI, 2003).
A principal fonte de segurança da função de hash está na impossibilidade (computacional)
de realizar a operação inversa. A mudança de um único bit na entrada muda, em média, metade dos
bits gerados na saída (SCHNEIER, 2009).
Dentre os algoritmos de hash mais populares, pode-se citar os da família SHA-1(Security
Hash Algorithm – Algoritmo Seguro de Hash), que, conforme Kurosse e Ross (2006, p.536), é um
algoritmo bastante utilizado por possuir baixo custo computacional e alta probabilidade de detectar
mudanças no texto criptografado.
Subsequente a este, tem-se a família SHA-2 que, conforme dados do NIST (2006), vem
sendo amplamente utilizado nas novas aplicações que necessitam de maior robustez em sua
segurança. Esta família possui como característica uma saída de tamanho variado, normalmente de
224 a 512 bits. O SHA-2 utiliza seis estágios de cálculos, sendo que cada estágio opera com
mensagens de 64 bits e o resultado de cada função é uma nova palavra de 64 bits. O custo
computacional para conseguir quebrar este algoritmo é altíssimo e atualmente computacionalmente
inviável.
26
2.1.4 Assinatura Digital
Segundo o ITI (2012), a assinatura digital é uma modalidade de assinatura eletrônica,
resultado de uma operação matemática que utiliza criptografia e permite aferir, com segurança, a
origem e a integridade do documento. A assinatura digital fica de tal modo vinculada ao documento
eletrônico que, caso seja feita qualquer alteração no documento, a assinatura se torna inválida. A
técnica permite não só verificar a autoria do documento, como estabelece também uma
“imutabilidade lógica” de seu conteúdo, pois qualquer alteração do documento, como por exemplo,
a inserção de mais um espaço entre duas palavras, invalida a assinatura.
Segundo Tanenbaum (2003, p.802), a autenticidade de muitos documentos legais,
financeiros e outros documentos é determinada pela presença de uma assinatura autorizada. A ideia
é substituir o transporte físico de documentos para o meio eletrônico e, para que os sistemas de
mensagens computadorizadas consigam realizar esta operação, deve-se utilizar um método no qual
a assinatura seja algo que não possa ser forjado.
Ainda para Tanenbaum (2003, p.802), a assinatura digital tem por objetivo substituir a
assinatura escrita a mão e que esta assinatura atenda aos requisitos de segurança como
irretratabilidade, autenticidade e integridade.
Uma assinatura digital é um mecanismo de autenticação que permite ao criador de uma
mensagem anexar um código que atue como uma assinatura. A assinatura é formada tomando uma
parte específica da mensagem chamada de hash da mensagem (ou resumo da mensagem) e
criptografando-a com a chave privada do criador (assinante da mensagem). Desta forma, a
assinatura garante a origem e a integridade da mensagem (STALLINGS, 2008, p.272).
A Figura 1 demonstra de forma resumida este processo criptográfico de criação de uma
assinatura digital:
O signatário gera um resultado hash de um documento eletrônico;
O signatário cifra o resultado hash com sua chave privada, associada a uma chave
publica constante do seu certificado digital, gerando a assinatura digital;
O documento eletrônico e a assinatura digital ficam associados, para futura validação.
27
Figura 1: Processo de Assinatura digital.
Fonte: ITI (2007)
Faz parte do ciclo de vida da assinatura digital, a verificação de uma assinatura (ver Figura
2). A seguir, tem-se a descrição deste processo criptográfico (ITI 2007):
O documento eletrônico e a assinatura digital associada são disponibilizados para o
verificador, juntamente com o certificado digital do signatário;
O verificador calcula novamente o resultado hash do documento eletrônico;
O verificador decifra a assinatura digital com a chave pública do signatário, contida no
certificado digital, obtendo o resultado hash gerado pelo signatário;
O verificador compara os resultados hash obtidos nos passos 1 e 2. Se forem iguais,
significa que o documento eletrônico está íntegro e que é possível identificar o
signatário por meio do certificado digital. Caso contrário, a assinatura digital é inválida.
Figura 2: Diagrama simplificado de verificação de assinatura.
Fonte: ITI (2007)
28
Conforme documento do ITI (2011), para facilitar a utilização de assinaturas digitais pelos
usuários finais, o ITI (Instituto Nacional de Tecnologia da Informação) criou 10 políticas de
assinaturas digitais divididas em dois subgrupos derivados dos padrões CMS Advanced Electronic
Signature (CAdES – RFC 5126) da IETF e XML-DSig Advanced Electronic Signature (XAdES) da
W3C. Dentro destes subgrupos, encontram-se as políticas de assinatura digital com referência
básica (AD-RB), referência para o tempo (AD-RT), referência para validação (AD-RV), referência
completa (AD-RC) e referência para arquivamento (AD-RA).
A ICP-Brasil descreve cada uma destas assinaturas que possui funções e aplicações
específicas. A seguir, tem-se uma breve descrição, iniciando pela assinatura mais simples (AD-RB)
para a assinatura mais complexa (AD-RA) (ITI 2011):
AD-RB: agrega segurança à autenticação de entidades e verificação de integridade,
permitindo sua validação durante o prazo de validade dos certificados dos signatários.
Uma vez que não são usados carimbos do tempo, a validação posterior só será possível
se existirem referências temporais que identifiquem o momento em que ocorreu a
assinatura digital.
AD-RT: abrange todo o campo de aplicação da assinatura AD-RB é voltada para o uso
em aplicações ou processos de negócios nos quais a assinatura digital necessita de
segurança em relação à irretratabilidade do momento de sua geração através da
utilização do carimbo do tempo.
AD-RV: abrange todo o campo de aplicação da assinatura AD-RT e inclui referências
sobre os certificados que compõem a cadeia de certificação e permite que se verifique a
validade da assinatura digital mesmo que ocorra comprometimento da chave privada da
AC.
AD-RC: implementa a AD-RV e realiza a verificação completa da validade da
assinatura digital a qualquer momento, pois os dados necessários estão auto-contidos na
assinatura.
AD-RA: implementa a AD-RV e é voltada para aplicações que necessitam realizar o
arquivamento do conteúdo digital assinado por longos períodos e provê proteção contra
fraqueza dos algoritmos, funções e tamanho de chaves criptográficas.
29
2.1.4.1 Protocolos de Autenticação
Os protocolos de autenticação podem ser separados em duas áreas gerais, sendo estas
autenticação mútua e autenticação unidirecional.
A autenticação mútua pode ser vista como um protocolo que permite que as partes em
comunicação possam validar a real identidade da outra parte. Para isto, Stallings (2008, p.275)
aborda as duas questões centrais: confidencialidade e adequação no tempo. A primeira serve para
não tornar pública as informações essenciais de identificação, para isso essas informações precisam
ser comunicadas de forma criptografada. A adequação no tempo serve para proteção da repetição de
mensagens que são genuínas.
Ainda conforme Stallings (2008, p.276), uma técnica para lidar com ataques de repetição é a
utilização do carimbo do tempo, no qual o receptor da mensagem somente irá aceitar se esta tiver
um carimbo do tempo com o horário próximo o suficiente do horário atual. Esta técnica exige que
os relógios de ambas as partes estejam sincronizados. Outra técnica utilizada para lidar com ataques
é o da utilização de nonce, na qual a parte receptora gera um número chamado de nonce e o envia
para o remetente. A mensagem recebida deve conter exatamente o mesmo nonce para que seja esta
válida, caso contrário, esta será descartada.
A autenticação unidirecional apresenta técnicas direcionadas para a criptografia de chaves
simétricas e criptografia de chave pública, porém, neste trabalho o foco será somente nas técnicas
voltadas a criptografia de chave pública.
De acordo com Stallings (2008, p.280), uma das técnicas utilizadas para a autenticação da
criptografia de chaves públicas é um emissor denominado (A) utilizar a sua chave privada para
criptografar a mensagem e um receptor denominado (B) utilizar a chave pública de (A) para
decriptografar a mensagem. Desta forma garantindo autenticidade da mensagem, porém não garante
a confidencialidade.
Para oferecer confidencialidade e autenticação, (A) pode criptografar uma mensagem
utilizando a sua chave privada e depois utilizar a chave pública do destinatário desejado, no caso
(B). Para o destinatário (B) realizar a decriptografia, o mesmo irá realizar a operação inversa, ou
seja, utilizar a chave pública do emissor (A) e em seguida aplicar a sua chave privada para finalizar
o processo, assim garantindo a autenticidade e confidencialidade da mensagem (STALLINGS,
2008, 230).Esta abordagem possui como desvantagem a utilização do algoritmo de chave pública,
que é complexo, e que precisa ser usado quatro vezes, duas vezes em cada comunicação.
(STALLINGS, 2008, 231).
30
2.1.5 Gerenciamento de chaves públicas e certificado digital
Uma das dificuldades da criptografia de chaves públicas é o problema de obter a chave
pública verdadeira de alguém. Este problema pode ser solucionado utilizando um intermediário de
confiança que, no caso da criptografia de chaves públicas, este intermediário é denominado de
Autoridade Certificadora (AC) (KUROSSE & ROSS 2006, p.536).
“Na prática, o certificado digital funciona como uma carteira de identidade virtual que
permite a identificação segura do autor de uma mensagem ou transação feita nos meios
virtuais, como a rede mundial de computadores - Internet. Tecnicamente, o certificado é um
documento eletrônico que por meio de procedimentos lógicos e matemáticos asseguraram a
integridade das informações e a autoria das transações” (ITI, 2012b).
Segundo Housley e Polk (2001, p.21), um certificado digital deve possuir uma combinação
de importantes propriedades, tais como:
deverá ser um objeto puramente digital para ser possível a sua distribuição via meio
eletrônicos;
possuir informações relevantes para que o detentor do certificado possa ser facilmente
identificado;
deverá ser fácil determinar se o certificado foi emitido recentemente;
deverá ser emitido por uma autoridade de confiança, chamada Autoridade Certificados,
e não pelo próprio usuário;
quando uma autoridade emite muitos certificados, inclusive para o mesmo usuário,
deverá ser fácil distingui-los;
deverá ser a prova de falsificação de modo que ninguém poderá alterar o seu conteúdo;
e
deverá ser possível determinar imediatamente se alguma informação do certificado não
é mais atual;
deverá ser possível determinar, a partir do tipo de certificado, para quais aplicações o
certificado poderá ser utiliza.
31
Choudhury (2002, p.59) complementa que é importante a emissão do certificado digital
através de uma Autoridade Certificadora (AC), pois quando esta emite um certificado, esta afirma
que o proprietário do certificado possui a chave privada correspondente à chave pública contida no
certificado.
Seguindo a linha de Choudhury (2002, p.59), com relação à emissão de um certificado,
a AC assina digitalmente estes certificados com sua chave privada. Essa assinatura digital da AC
emissora do certificado ajuda os usuários a identificar se a AC que emitiu o certificado é uma AC
confiável ou não. Para garantir a autenticidade do certificado, os usuários podem verificar a
assinatura da AC usando a chave pública da mesma.
Conforme constata o ITI (2010), os tipos de certificados mais comercializados são os
certificados do tipo A1 contendo validade de um ano e que são armazenados em computadores e o
certificado do tipo A3 contendo validade de até três anos e que são armazenados em cartões ou
tokens criptográficos.
Segundo Choudhury (2002, p.59), os certificados que são emitidos têm que estar em um
formato padrão de modo que estes certificados sejam reconhecidos mundialmente. Um formato
que é reconhecido mundialmente é o padrão X.509. Em 1988, a International Telecommunications
Union (ITU) criou e começou a recomendar o padrão X.509 para certificados digitais. Desde então,
o X.509 se tornou um padrão de fato para certificação em sistemas abertos, como a Internet. A
versão mais recente do padrão é a X.509 v3.
Conforme Tanenbaum (2003, p.816), o certificado X.509 v3 possui diversos campos e, entre
estes, os mais importantes são:
Certificate Version: descreve a versão do X.509;
Certificate Serial number: este número somado ao nome da AC, deverá ser capaz de
identificar de forma exclusiva um certificado;
CAs Signature algorithm: algoritmo utilizado para assinar o certificado;
Issuer: nome X.500 da Autoridade Certificadora;
Validity period: contempla o período de validade do certificado;
Subjects name: a entidade cuja chave está sendo referenciada;
Subject public key information: a chave pública do sujeito;
Subject unique identifier: um valor que identifica de forma exclusiva o sujeito do
certificado;
Extensions: extensões que foram definidas; e
32
Signature: a assinatura que está contida no certificado (que deverá estar assinado com
chave privada da AC).
Tanenbaum (2003, p.817) descreve que fazer uma única AC realizar a emissão de todos os
certificados do mundo não seria possível, pois a probabilidade de ocorrer falhas no sistema seria
grande. Uma solução para este problema seria existência de várias AC’s, todas administradas pela
mesma organização e todas utilizando a mesma chave privada para assinar certificados, porém a
probabilidade da distribuição não autorizada das chaves privada colocaria todo o sistema e sua
segurança em risco. Desta forma, foi proposto o uso de uma ICP – Infra Estrutura de Chaves
Públicas (PKI – Public Key Infrastructure), que possui por função fornecer um modo de estruturar
esses componentes e definir padrões para os vários documentos e protocolos.
Uma infraestrutura de chaves públicas (ICP) pode ser vista como uma estrutura criada com o
intuito de realizar autenticação e identificação de usuários e serviços e garantir que as mensagens
compartilhadas não estejam disponíveis a entidades que não devam ter conhecimento destas (ITI,
2011).
A ICP-Brasil é composta por uma cadeia de autoridades certificadoras (conforme ilustrado
na Figura 3) formada por uma Autoridade Certificadora Raiz (AC-Raiz), Autoridades Certificadoras
(AC) e Autoridades de Registro (AR) e, ainda, por uma autoridade gestora de políticas, ou seja, o
Comitê Gestor da ICP-Brasil (ITI, 2012).
33
Figura 3: Um exemplo de Cadeia de certificação da ICP-Brasil.
Fonte: ITI (2007)
O Comitê Gestor é composto por representantes da sociedade civil e de alguns órgãos
públicos, com competência para determinar as políticas a serem executadas pela AC-Raiz (ITI,
2012).
A Autoridade Certificadora Raiz da cadeia da ICP-Brasil tem como função básica a
execução das políticas de certificados e normas técnicas e operacionais aprovadas pelo Comitê
Gestor, atuando: na emissão, expedição, distribuição, revogação e gerenciamento de certificados de
autoridades certificadoras de nível imediatamente inferior ao seu, chamadas Autoridades
Certificadoras Principais; no gerenciamento da lista de certificados revogados (LCR), emitidos e
vencidos; e na execução, fiscalização e auditoria das autoridades certificadoras, de registro e
prestadoras de serviço de suporte habilitadas na ICP-Brasil (ITI, 2012).
2.1.6 Carimbo Do Tempo
Segundo CNSEC (2007), a datação de documentos eletrônicos é necessária para que estes
possam ser utilizados da mesma forma que documentos tradicionais em papel. A datação fornece
34
uma referência temporal, a qual permite determinar a existência de um documento eletrônico em
determinado instante do tempo. Outro aspecto da datação de documentos eletrônicos que deve ser
levado em consideração é em relação ao uso de assinaturas digitais.
A assinatura digital possui sua eficácia jurídica associada a validade do certificado digital do
signatário. Sem esta referência de tempo não é possível determinar em qual período a assinatura foi
produzida sobre uma mensagem e, se neste mesmo período, o certificado do signatário era válido.
Uma das prerrogativas do sistema notarial brasileiro é exatamente a prioridade, ou seja, a
determinação da hora/data legal de um documento para efeitos de pré-notação e eficácia jurídica
perante terceiros (CNSEC, 2007).
Consta no documento da RFC 3161 (IETF, 2001), que o carimbo de tempo foi criado a
partir da necessidade de provar que as assinaturas digitais já existiam em um determinado
momento, ou seja, uma informação que atue como âncora temporal para estes dados. A
especificação do formato dos carimbos de tempo e do protocolo de comunicação entre clientes e
servidores é dada por esta RFC.
Conforme descrito no documento de especificação do ITI (2010), a estrutura para geração de
um carimbo do tempo necessita de um conjunto de regulamentos e normas no âmbito da ICP-Brasil,
ou seja, é necessário um conjunto de sistemas, autoridades e servidores, devidamente
regulamentados, conforme descritos a seguir:
ACT (Autoridade Certificadora do Tempo): é toda e qualquer organização que está
filiada a ICP-Brasil e que implementa os ambientes, sistemas e procedimentos descritos
pela própria ICP-Brasil para realizar a emissão do carimbo do tempo;
SCT (Servidor de Carimbo do Tempo): servidores conectados à rede de carimbo do
tempo da ICP-Brasil, que geram carimbos em nome da ACT; e
SAS (Sistema de Auditoria e Sincronismo): Audita e sincroniza os servidores que são
utilizados para a geração do carimbo do tempo (SCT).
Um carimbo de tempo é composto pela identificação dos dados, normalmente um hash dos
dados a serem assinados, a data e hora em que o carimbo foi gerado. Estes dados são então enviados
pelo requerente à ACT. Com esses dados, a ACT gera o carimbo do tempo, assina este utilizando a
sua chave privada e o enviado de volta ao requisitor. Este usuário deve checar (a) se o que foi
carimbado corresponde ao que foi enviado ao SCT, (b) se o certificado utilizado na geração do
carimbo do tempo pertence à ACT, e (c) checar o tempo incluso na resposta (carimbo do tempo
35
grado) com uma fonte confiável de tempo (SCT). Adicionalmente, pode-se incorporar à requisição
um número aleatório (chamado de nonce - number once), para que o requerente verifique se o
nonce recebido na resposta corresponde ao que foi enviado. Como consta na especificação (RFC
3161, IETF, 2001), o carimbo do tempo poderá ser utilizado para carimbar documentos
confidenciais, pois não existe a necessidade do envio do documento para a geração do carimbo. O
envio do carimbo do tempo será necessário apenas para a verificação e validação de sua integridade
(SCHNEIER, 2009).
O processo de carimbo de tempo, esquematizado na Figura 4, é muito similar a uma
assinatura digital comum, com a adição aos dados assinados de uma data obtida de um relógio
confiável. Deve ser realizada por uma entidade confiável, chamada Autoridade de Carimbo de
Tempo. Com o carimbo de tempo, é possível validar a assinatura baseado nas informações da data
em que o carimbo foi gerado, e não da data em que a assinatura está sendo verificada (ITI 2010).
Figura 4: Modelo de Funcionamento do Carimbo do Tempo em Assinatura Digital.
Fonte: Moecke (2008).
36
Finalizando, o ITI (2010) complementa que como os SCTs são sincronizados e auditados
pelo SASs, a dificuldade de qualquer tipo de ação maliciosa aumenta drasticamente.
O carimbo de tempo poderá ser aplicado em uma assinatura ou documento eletrônico a fim
de garantir que este já existia em um momento específico. Mas a utilização do carimbo do tempo é
facultativa, pois nem todas as assinaturas necessitam de uma comprovação de tempo que ocorreu,
pois documentos eletrônicos assinados digitalmente com chave privada correspondente a
certificados ICP-Brasil são válidos com ou sem o carimbo do tempo (ITI, 2010).
O Carimbo do Tempo é um documento eletrônico que é assinado por uma terceira parte
confiável (ACT) serve como evidência irrefutável da existência de uma informação digital numa
determinada data e hora (CNSEC, 2007).
2.1.7 Validade jurídica de documentos digitais
Embora a validade das declarações de vontade no sistema legal não dependa de forma
especial, preocupa os usuários o valor probante dos documentos produzidos em meio eletrônico.
Através da certificação digital os documentos eletrônicos ganham a mesma eficácia probatória dos
documentos material, pois esta tecnologia de segurança permite afirmar a autenticidade do
documento, na medida em que garante a identidade das partes e a integridade do conteúdo
(OTTONI, 2003).
Muitos usuários se preocupam com o valor probante dos documentos produzidos em meio
eletrônico, muitas vezes por desconhecer a legislação vigente sobre o assunto (OTTONI, 2003).
Baseado na Medida Provisória nº 2200-2, que entrou em vigor no dia 24 de agosto de 2001,
os documentos eletrônicos possuem validade jurídica incontestável desde que este documento
eletrônico esteja submetido aos aspectos gerais do órgão de confiança ICP-Brasil descritos no
Apêndice A (PORTAL DO PLANALTO, 2001).
A medida é clara e objetiva, porém, para que isto funcione e seja amplamente utilizado,
alguns aspectos devem ainda serem observados (CORADINI, 2004) :
1. Efetuar a obrigatoriedade de órgãos e meios que utilizem documentos eletrônicos ou
transações a aplicarem esta Lei, provendo serviços seguros e beneficiando tanto o usuário
como o provedor de sistemas e obtendo então documentos judicialmente válidos (contendo
assinatura digital);
37
2. Criar um órgão máximo para regulamentar documentos e transações eletrônicas, obrigando
os provedores a se regularizar e seguir um conjunto mínimo de regras para que as transações
tenham um caráter judicial. Isto garante ao usuário a idoneidade do provedor de serviços;
3. No caso de outro modo para garantir a autenticidade, integridade e validade jurídica, o
provedor que utilizar estes outros modos, deverá colocar este método à prova perante o
órgão regulamentador de documentos e transações eletrônicas para que o mesmo possua
validade jurídica;
4. A partir da obrigatoriedade, estabelecer prazos e leis a serem cumpridas, com multas severas
e aplicáveis aos que não se condicionarem ao propósito, perdendo este o direito de oferecer
serviços digitais sem forma segura e sem assinatura digital; e
5. Fornecer informações, selos ou imagens (do próprio Governo), nos programas, sites e
transações online, instruindo a pessoa que está utilizando o sistema digital que aquele
serviço está padronizado com a lei MP 2200-2, bem como informando o usuário que os
documentos online gerados têm validade jurídica e a pessoa é responsável por quaisquer
informações fornecidas e poderá responder por crime eletrônico, respondendo em juízo por
tais atos;
2.2 CRIMES ELETRÔNICOS
Entende-se por crime eletrônico qualquer tipo de crime que possa vir a ser praticado
utilizando-se de um meio virtual (PINHEIRO, 2009, p.225).
Apesar de nenhuma lei específica até o presente momento ser aprovada que trate sobre os
crimes digitais, quase que em sua maioria, estes são passíveis de qualificação penal perante a
legislação vigente, uma vez que a título de exemplo, um crime contra a honra não deixa de ferir a
honra de alguém por ter sido praticado com o advento da Internet (NEVES, 2009).
Como Pinheiro (2009, p.170) expõe, em breve, os crimes virtuais ultrapassarão os crimes
físicos. Isso se deve ao fato do Brasil ser o país com maior incidência de crimes eletrônicos.
Segundo a autora, é necessário ressaltar a importância que a computação forense terá na sociedade,
pois com esta será possível auxiliar a identificação dos crimes virtuais cometidos e assim punir
melhor os infratores.
Abranger todos os atos que são praticados nos meios digitais e tidos como lesivos e
criminosos pela sociedade é tarefa difícil, pois o código penal vigente é obsoleto. Além disso, a
38
falta de uma estrutura policial e logística direcionada à questão permitiu que, por muito tempo, a
Internet ganhasse o predicado de "terra de ninguém" devido a sensação de impunidade por parte dos
autores (PÍCOLO, 2012).
Neves (2009) descreve que, mesmo com a possibilidade de um usuário vir a ser processado
criminalmente, o crescimento dos crimes eletrônicos é notório e este crescimento pode ser atribuído
principalmente ao usuário, por motivos de falta de informação, demora em registrar denúncias às
autoridade ou simplesmente não levar adiante o caso de um possível crime.
A grande maioria dos usuários entra no mundo virtual sem grandes informações
relacionadas à segurança ficando vulneráveis a criatividade de usuários mal intencionados que
utilizam de mecanismos como a engenharia social para realizar um feito criminoso (NEVES, 2009).
2.2.1 Leis e tipificação de crimes eletrônicos
Este trabalho tem foco tratar dos crimes de violação de direitos autorais e contra a hora. É
necessário primeiro entender a diferença entre os crimes de violação do direito autoral, calúnia,
difamação e injúria que estão previstos no Código Penal Brasileiro.
Segundo Bittar (1999, p.236), será considerado como violador, aproveitador ou explorador
do direito do autor aquele que realizar as ações de cópia, venda, exposição à venda, aquisição,
ocultação e manutenção em depósito para lucro próprio.
Já com relação à calúnia, esta consiste em atribuir, falsamente, a alguém a responsabilidade
pela prática de um fato determinado definido como crime. Assim, se “A” disser que “B” roubou a
moto de “C” , sendo tal imputação não verídica, constitui crime de calúnia. (QUEIROZ, 2000).
Quando se trata da difamação, a diferença para a calúnia é que o ato da difamação se
materializa independente da veracidade do caso, ou seja, a divulgação de um fato que possa vir a ser
ofensiva a reputação poderá ser considerado como calúnia (OLIVEIRA, 2004, p.26, p.60).
No caso da injúria, o autor trata este crime como sendo sentimental, ou seja, algo íntimo. Se
a vítima sentir que a sua honra foi atacada de forma negativa, já é o suficiente para ter ocorrido o
ato criminoso, não sendo necessária a divulgação do fato a uma terceira pessoa (OLIVEIRA, 2004,
p.26, p.60).
No ordenamento jurídico, os crimes citados são tratados com base no Decreto-Lei 2.848, de
7 de dezembro de 1940, que institui as Leis.
39
2.2.2 Territorialidade e a Internet
É necessário entender os princípios da territorialidade para saber até onde um ordenamento
jurídico tem alcance, ou seja, onde o direito pode ser aplicado e a quais leis jurídicas um ato
potencialmente criminoso poderá estar sujeito (PINHEIRO 2009, p.37 - 38).
Para identificar a norma a ser aplicada, é necessário identificar os limites territoriais, ou seja,
a origem do ato e onde este fato tem ou teve os seus efeitos para assim poder aplicar as ações
cabíveis do país, estado ou região (PINHEIRO 2009, p. 38).
Este conceito infelizmente não se aplica a Internet, pois diversas vezes não é possível obter
uma localização exata de um usuário que está interagindo na rede, ou seja, se uma vítima de uma
ofensa realizada através de um site reside no Canadá, esta vítima está submetida as leis do Canadá.
Caso este mesmo site não queira responsabilizar-se por problemas fora da sua área de atuação, este
deverá de alguma forma informar aos usuários a qual legislação o site está submetido (PINHEIRO
2009, p. 39).
Esta preocupação pela territorialidade surgiu pelo fato dos usuários poderem estar
virtualmente em qualquer lugar a qualquer tempo através de espaços públicos. Como exemplo
destes meios, pode-se citar as comunidades online, blogs, fotologs e fotoblogs (PINHEIRO 2009, p.
254).
Conforme Pinheiro (2009 p.256 - 257) a palavra blog pode ser definida como um diário
online publicado na Internet e atualizado com frequência. O fotolog, similar ao blog, pode ser visto
com um registro frequente de fotos. E o fotoblog seria a junção dos dois meios citados
anteriormente, no qual um usuário inclui fotos e relato de informações, permitindo ou não que
outros usuários interajam através de comentários direcionados para o dono ou para o assunto
abordado.
Infelizmente, estes espaços tidos como públicos,tornaram-se um espaço para grupos que
promovem apologias a assuntos diversos, ofensas e crimes contra a hora, falsidade ideológica,
violação de direitos autorais, prática do bulling entre outros. Estes espaços acabam criando a falsa
impressão de que as pessoas são completamente livres quando estão online e que a conduta não
possa vir a refletir na realidade, ou seja, estes usuários pensam que estão completamente anônimos
(PINHEIRO 2009, p. 254 - 255).
40
2.2.3 Forense computacional e evidência digital
De acordo com Pereira et al.(2007), para auxiliar as investigações de crimes realizados em
meio digital, se faz necessário o uso da Forense Computacional. A computação forense pode ser
entendida como a utilização de métodos científicos na preservação, coleta, validação, identificação,
análise, interpretação, documentação e apresentação de evidências digitais (PINHEIRO, 2009
p.171).
O FBI (2011) descreve a ciência forense como sendo destinada a preservar, adquirir, obter e
apresentar dados que foram inseridos em meio digital e armazenados em dispositivo eletrônicos tais
como o computador.
Por evidência digital, entende-se como toda informação ou assunto sujeito ou não a
intervenção humana e que possa ser extraída de um computador ou de qualquer outro dispositivo
eletrônico. É importante ressaltar que a evidência sempre deve estar num formato de entendimento
humano (PINHEIRO, 2009, p.172).
Reis (2006) descreve que mesmo que a princípio não exista a intenção de se iniciar um
processo criminal, toda investigação deve considerar como prática predefinida a utilização de
métodos e documentações que garantam sua aceitação em caso de possível processo judicial. Pois
como o autor complementa, as formalidades sempre ajudam a desenvolver bons métodos e hábitos
de investigação.
Pereira et al.(2007) cita algumas práticas podendo ser vistas como formalidades para uma
boa investigação forense computacional:
Coleta de informações: dados relacionados ao evento precisam ser coletados e a sua
integridade preservada.
Exame dos dados: utiliza ferramentas e técnicas com o intuito de identificar e extrair
informações relevantes ao caso e sempre mantendo a integridade das informações.
Análise das informações: utiliza das informações coletadas no passo anterior para obter
informações relevantes e úteis e que as mesmas possam auxiliar diretamente a
solucionar o caso; e
Interpretação dos resultados: esta etapa deve descrever os procedimentos realizados e os
resultados obtidos. Após esta etapa deve ser possível construir um laudo pericial.
41
Estas mesmas práticas são apresentadas na Figura 5 na forma de um ciclo (PEREIRA et al,
2007):
Figura 5: Fases do processo de investigação forense
Fonte: Pereira et. al. (2007).
Pereira et al.(2007) descrevem que um laudo pericial deve possuir informações como uma
conclusão imparcial e final relacionada à investigação. É importante que o laudo pericial se torne de
fácil interpretação por qualquer pessoa, pois a intenção é que este documento seja utilizado por
pessoas do meio jurídico e/ou técnico e é indicado que o mesmo seja organizado em seções como:
finalidade da investigação, autor do laudo, resumo do incidente, relação de evidências analisadas e
seus detalhes, conclusão, anexos e glossário.
Reis (2006) ainda explica que toda a informação que possa vir a ser relevante deve ser
coletada e guardada para futura análise e, conforme as evidências digitais forem encontradas, estas
devem ser extraídas, documentadas e devidamente preservadas. Após estes passos, as evidências
coletadas podem ser relacionadas entre si, permitindo desta forma a reconstrução do fato descrito
pela vítima ligada ao incidente investigado. É importante que todas essas etapas sejam feitas, pois,
por vezes, a análise realizada sobre as evidências resulta em novas descobertas e informações.
42
2.3 ATA NOTARIAL
Um instrumento importante que visa a validade jurídica de fatos ocorridos em meio
eletrônico é a homologação de uma ata notarial (SANT’ANA & ROVER , 2011). Pode-se definir
uma ata notarial como sendo "um instrumento público através do qual o notário capta, por seus
sentidos, uma determinada situação, um determinado fato, e o translada para seus livros de notas ou
para outro documento" (BRANDELLI, 2004, p. 44).
Neste sentido, IPIENS (2004) descreve de maneira mais analítica uma ata notarial como
sendo:
"[...] instrumento público autorizado por notário competente, a requerimento de uma pessoa
com interesse legítimo e que, fundamentada nos princípios da função imparcial e
independente, pública e responsável, tem por objeto constatar a realidade ou verdade de um
fato que o notário vê, ouve ou percebe por seus sentidos, cuja finalidade precípua é a de ser
um instrumento de prova em processo judicial, mas que pode ter outros fins na esfera
privada, administrativa, registral, e, inclusive, integradores de uma atuação jurídica não
negocial ou de um processo negocial complexo, para sua preparação, constatação ou
execução."
A princípio, a ata notarial se presta como prova circunstanciada e com fé pública. Trata-se
de uma prova pré constituída em termos periciais, regulamentada pela Constituição de 1988 e pela
Lei 8.935/94 (SANT’ANA & ROVER , 2011).
A homologação da ata notarial, que é a narração de fatos verificados pessoalmente pelo
tabelião, compreende: local, data e horário de sua lavratura; nome e qualificação do solicitante;
narração circunstanciada dos fatos; declaração de haver sido lida ao solicitante e, sendo o caso, às
testemunhas; assinatura do solicitante e das testemunhas; assinatura e sinal público do tabelião
(SANT’ANA & ROVER , 2011).
A seguir, são descritos os procedimentos necessários para a homologação de uma ata
notarial referente a conteúdos publicados na Internet (SANT’ANA & ROVER , 2011):
1. O requerente deve se dirigir a um Cartório e requisitar ao tabelião que lavre uma ata
notarial.
2. O requerente deverá fornecer o endereço eletrônico do web site ao tabelião.
3. O tabelião deverá verificar os dados e constar os fatos veiculados em seu monitor.
43
4. O tabelião deverá descrever os fatos ali presenciados e realizar uma assinatura sob
duas cópias do documento lavrado.
5. Por fim, uma cópia da ata notarial será fornecida para o requerente e outra cópia
ficará de posse do cartório.
6. Posteriormente, a pessoa lesada deverá procurar uma delegacia e registrar um
boletim de ocorrência munido da ata notarial.
7. Ingressar ação criminal juntamente com a ata notarial em anexo ao processo.
2.4 CARTÓRIO DIGITAL
Malta (2009, p.17) descreve um cartório digital como sendo uma instituição apta a atribuir
fé pública para documentos digitais de forma competente e adequada, e para isto se faz necessário
de todo o suporte jurídico como tecnológico.
É necessário ressaltar a importância dos cartórios como sendo uma grande fonte para
pesquisas, uma vez que neles estão arquivados os registros notórios dos atos legais dos cidadãos
(MALTA 2009, p.15).
Para que exista uma validade jurídica em documentos eletrônicos se faz necessário do uso
da certificação digital. Esta técnica muito utilizada e difundida em diversos países permite a
identificação das partes envolvidas, integridade do documento eletrônico e a autenticidade da
assinatura realizada (PINHEIRO 2009, p. 160 - 163).
Atualmente o processo de autenticação de um documento em meio eletrônico está sob a
responsabilidade de um Tabelião de Notas, ditas como tarefas dos serviços notarias, ou seja, cabe
ao Tabelião de Notas a exclusividade desta autenticação conforme constituição federal em vigor
(MALTA 2009, p.17).
2.4.1 Cartório 24 horas
Atualmente é possível realizar solicitações de segunda via de certidões de qualquer natureza
através do serviço online Cartorio24horas. Atualmente o serviço de solicitação via Internet de
documentos que estão em meio eletrônico está sendo fornecida por apenas cinco estados.
44
Um problema ainda enfrentado é a subutilização do serviço online, pois o mesmo ainda não
está presente em todos os estados (vinte e dois estados e o Distrito Federal) e mesmo nos estados
que utilizam, nem todos os cartórios estão incluídos no sistema. Isto pode ocasionar problemas,
pois, se um documento solicitado está em posse de um cartório não cadastrado no sistema, a
solicitação será em vão.
Atualmente, o procedimento para realizar a solicitação de um documento que não está em
meio eletrônico pode ser feito através dos passos:
1. Aceitar o termo de utilização do serviço.
2. Fornecer os dados: CPF ou CNPJ, nome RG, DDD+telefone e e-mail.
3. Selecionar o Estado e Documento desejado.
4. Selecionar Cidade e o cartório responsável pelo documento selecionado.
5. Fornecer os dados da pessoa relacionada à certidão solicitada.
6. Selecionar a forma de retirada entre Sedex, Carta Registrada ou retirada no próprio
cartório (não existe um envio via meio eletrônico).
7. Fornecer os dados de entrega se necessário.
8. Escolher a forma de pagamento e aguardar a data que varia de 14 a 30 dias úteis.
Já para a solicitação de uma certidão que está em meio eletrônico, os passos são
(Cartorio24horas, 2012):
1. Aceitar o termo de utilização do serviço.
2. Fornecer os dados: CPF ou CNPJ, nome RG, DDD+telefone e e-mail.
3. Selecionar o Estado e Documento desejado.
4. Selecionar Cidade e o cartório responsável pelo documento selecionado.
5. Fornecer os dados da pessoa relacionada à certidão solicitada.
6. Fornecer um e-mail válido para a entrega do certificado.
7. Escolher a forma de pagamento e aguardar a data de envio que são de até seis dias
úteis.
45
2.4.2 Serviço oferecido através de uma aplicação web
O serviço online disponibilizado pelo sistema Cartorio24horas se enquadra na modalidade
SaaS (Software as a Service) por oferecer o serviço através de uma pagina web cujo objetivo é
oferecer ao cartório maior produtividade no exercício de sua função (CNSEC, 2007).
Esta maior produtividade se dá pelo recebimento automatizado de requisições vindas
eletronicamente através dos interessados nos serviços oferecidos e da possibilidade dos cartórios
produzirem respostas mais rápidas (CNSEC, 2007).
Estes mesmos serviços não precisam ser necessariamente voltados aos usuários finais que
realizam solicitações de documentos eletrônicos, um SaaS pode oferecer serviços (através de web-
services por exemplo) a outros estabelecimentos como cartórios, por exemplo, pois o seu objetivo é
oferecer um meio para a gestão dos serviços oferecidos e provendo soluções, mas sempre se
concentrando na prestação de serviços já existentes como também no possível desenvolvimento de
novos serviços a serem oferecidos (CNSEC, 2007).
Atualmente, é possível implementar serviços de cartório digital integrados aos cartórios
tradicionais, pois a computação permite que haja uma completa integração e suporte entre software,
hardware e a legislação vigente (MALTA 2009, p.17 - 18).
46
3 DESENVOLVIMENTO
Neste capítulo, será apresentada a aplicação na qual estão incluídos os mecanismos de
criptografia e segurança abordados no Capítulo 2. Inicialmente, uma visão de geral do
funcionamento da aplicação Web proposta é apresentada. Em seguida, os requisitos funcionais e
não funcionais e as regras de negócio da aplicação são descritos. Os aspectos dinâmicos da
aplicação são apresentados através da descrição dos casos de uso, dos diagramas de sequência e das
imagens de algumas telas da aplicação. Por fim, as tecnologias e ferramentas utilizadas no
desenvolvimento deste projeto.
3.1 VISÃO GERAL DA APLICAÇÃO WEB
Conforme Reis (2003), o Brasil vem sofrendo grande aumento de crimes via Internet.
Visando melhorar o processo de registro de um possível crime ocorrido em meio eletrônico. Este
trabalho desenvolveu uma aplicação Web voltada à automatização do registro de uma ata notarial
realizada pelos cartórios bem como realizar o armazenamento de atas notariais em meio eletrônico.
Considerando este cenário, a solução proposta pretende melhorar a interação da vítima com os
cartórios visando maior agilidade no registro e consulta de atas notariais eletrônicas.
Aplicação Web utiliza como mecanismos de segurança a assinatura digital, o carimbo do
tempo e o protocolo SSL. O uso da assinatura digital e do carimbo do tempo tem por objetivo
garantir a autenticidade, integridade e o não repúdio da ata notarial produzida e o protocolo SSL
garantirá a comunicação segura entre um requerente de uma ata notarial (cliente do cartório) e o
servidor Web da aplicação. Os mecanismos de assinatura digital e carimbo do tempo deverão estar
dentro das regulamentações da ICP-Brasil para que as atas notariais possuam validade jurídica.
Esta aplicação conta com três atores, que estarão interagindo com a aplicação para realizar
todo o processo de registro de uma ata notarial eletrônica. O primeiro ator é a vítima que se sentiu
lesada de alguma forma, esta será denominada de Requerente. O encarregado de realizar verificação
e validação dos fatos descritos pelo Requerente é o ator denominado Tabelião, pois este possui por
função a responsabilidade da tarefa de registro e comprovação dos fatos relatados pela vítima. Por
último a aplicação web conta com um administrador que realiza o cadastro do usuário com perfil
47
Tabelião e também cadastra a ACT a ser utilizada no momento da geração de um carimbo do
tempo.
A Figura 6 ilustra o funcionamento da aplicação Web proposta. Os passos estão descritos a
seguir.
Figura 6: Visão Geral da Aplicação Web Proposta.
48
1. Requerente solicita a ata notarial fornecendo uma descrição do fato e o endereço
Web para o acesso aos dados que comprovam o fato relatado.
2. A aplicação web realiza o download de todo o conteúdo Web indicado no endereço
Web fornecido pelo Requerente.
3. O Tabelião acessa uma listagem de solicitações realizadas pelos requerentes e que
estão pendentes e então seleciona a solicitação mais antiga. Este analisa os fatos
descritos na solicitação de ata notarial feita por um requerente e compara com os
dados armazenados no banco de dados da aplicação web que foram coletados através
do endereço Web indicado na solicitação. O tabelião então inicia o processo de
elaboração da ata notarial eletrônica com validade jurídica. Para isto, este redige a
ata notarial (tendo como base alguns templates), assina digitalmente tanto o conteúdo
web coletado quanto a ata notarial utilizando seu certificado digital2.
4. Após o Tabelião assinar a ata notarial e realizar a autenticação dos dados, a aplicação
web solicita à ACT (Autoridade de Carimbo do Tempo) um carimbo do tempo.
5. A ACT realiza esta solicitação ao SCT (Servidor de Carimbo do Tempo).
6. O servidor SCT então devolve um carimbo do tempo válido para a ACT.
7. A ACT por sua vez responde a solicitação da aplicação web com um carimbo do
tempo válido.
8. A aplicação web armazena a ata notarial com a assinatura digital e com o carimbo do
tempo já anexado e o conteúdo web coletado no banco de dados do Cartório e
atualiza o status da solicitação (concluída).
9. A ata notarial fica disponível para consultas.
3.2 REQUISITOS
Visando identificar os objetivos a serem alcançados pela aplicação, foram levantados os
requisitos funcionais e não funcionais. Os primeiros descrevem o comportamento da aplicação,
impondo condições que devem ser atendidas. Os segundos descrevem a maneira como a aplicação
deve realizar certos procedimentos. Para definição destes requisitos, além dos conhecimentos
2 Certificado digital tipo A3 emitido por uma autoridade certificadora pertencente a cadeia de certificação da ICP Brasil.
49
obtidos do estudo bibliográfico, foram necessárias outras informações adquiridas através de uma
entrevista feita com um tabelião de um Cartório do município de Florianópolis. A seguir, são
apresentados estes requisitos.
3.2.1 Requisitos Funcionais
Perfil de Requerente:
REF 01: O A aplicação deve permitir o cadastro de usuários com o perfil Requerente;
REF 02: A aplicação deve permitir o cadastro de solicitações para lavrar atas notariais;
REF 04: A aplicação deve permitir a exclusão de solicitações para lavrar atas notariais;
REF 05: A aplicação deve permitir a pesquisa de suas solicitações de atas notariais cujo
status pode ser pendente ou concluída; e
REF 06: A aplicação deve permitir que um requerente solicite suas atas notariais
concluídas.
Perfil de Tabelião
REF 10: A aplicação deve permitir a pesquisa das solicitações pendentes de atas notariais;
REF 11: A aplicação deve permitir que o tabelião visualize o conteúdo web indicado pelo
requerente (armazenado no banco de dados do Cartório) de forma que este verifique se o
conteúdo confere com a descrição feita pelo requerente em sua solicitação;
REF 12: A aplicação deve permitir redigir atas notariais com base em templates;
REF 13: A aplicação deve permitir assinar e carimbar digitalmente atas notariais; e
REF 14: A aplicação deve permitir assinar e carimbar digitalmente o conteúdo web
coletado.
50
Perfil de Administrador
REF 15: A aplicação deve permitir o cadastro de usuários com o perfil Tabelião;
REF 15: A aplicação deve permitir o cadastro de uma ACT; e
REF 16: A aplicação deve permitir o cadastro de um template de ata notarial.
3.2.2 Requisitos Não Funcionais
RNF 02: A aplicação deve ser desenvolvida para a plataforma web;
RNF 03: A aplicação deve ser desenvolvida utilizando a especificação JSF 2.0;
RNF 04: A aplicação deve ser desenvolvida utilizando o framework RichFaces 4.2.2;
RNF 05: A aplicação deve ser desenvolvida utilizando o banco de dados PostgreSQL;
RNF 06: A aplicação deve ser desenvolvida utilizando o servidor de aplicação JBoss;
RNF 07: A aplicação deve ser homologada no sistema operacional Windows XP ou
Windows 7;
RNF 08: A aplicação deve ser homologado nos navegadores Internet Explorer 7 ou
superior, Mozilla Firefox 4 ou superior, Google Chorme;
RNF 09: A aplicação deve exigir autenticação dos requerentes através do mecanismo de
usuário e senha;
RNF 10: A aplicação deve guardar logs das operações de todos os usuários;
RNF 11: A aplicação deve guardar logs da operação de exclusão de uma solicitação para
lavrar uma ata notaria;
RNF 12: A aplicação deve guardar logs das atas notariais lavradas pelo Tabelião;
RNF 13: A aplicação deve exigir autenticação do Tabelião e do Administrador para acesso
ao sistema através do certificado digital emitido por uma autoridade certificadora
pertencente à cadeia da ICP-Brasil;
51
RNF 14: A aplicação deve utilizar o algoritmo de assinatura digital RSA com o tamanho de
chave tamanho da chave 1024 bits; e
RNF 15: O sistema deve utilizar o protocolo SSL de comunicação segura.
3.2.3 Regras de Negócio
RN 01: A aplicação não deve permitir acesso de usuários não autenticados;
RN 02: A aplicação não deve permitir mais de 20 solicitações pendentes para lavrar atas
notarias;
RN 03: A aplicação deve permitir descrições de até 20000 caracteres na descrição realizada
pelo Requerente;
RN 04: A aplicação deve permitir descrições de até 20000 caracteres na descrição realizada
pelo Tabelião;
RN 05: A aplicação deve permitir tamanho do endereço web de até 1000 caracteres;
RN 06: A listagem de atas notariais deverá apresentar apenas os itens em que o Tabelião
participou, através do seu CPF; e
RN 07: A aplicação não deve permitir que requerentes visualizem solicitações de atas
notariais de outros requerentes.
3.3 DIAGRAMAS DE CASO DE USO
Conforme descrito na visão geral da aplicação, a mesma possui três atores: o Requerente, o
Tabelião e o Administrador. Foi definido o Diagrama de caso de uso conforme ilustrado nas figuras
6, 7 e 8. A seguir, são apresentados os Casos de Uso expandidos para cada case de uso.
Este primeiro diagrama (Figura 7) de casos de uso é referente ao ator Requerente e possui
cinco casos de usos que foram ser desenvolvidos ao longo do desenvolvimento da aplicação web. A
seguir será feito uma breve descrição dos casos de uso:
USC - 01 – Cadastrar: O Requerente pode se cadastrar na aplicação;
USC - 02 – Solicitar Ata Notarial: O Requerente pode solicitar atas notarias;
USC - 04 – Obter Ata Notarial: O Requerente pode obter atas notarias;
52
USC - 05 – Autenticar na aplicação: O Requerente pode se autenticar na aplicação; e
USC - 08 – Consultar Ata Notarial: O Requerente pode consultar atas notarias.
Figura 7: Diagrama de Casos de Uso do Requerente
O segundo diagrama (Figura 8) de caso de uso é referente ao ator Tabelião e possui quatro
casos de usos que foram ser desenvolvidos ao longo do desenvolvimento da aplicação web. A
seguir será feito uma breve descrição dos casos de uso:
USC - 03 – Lavrar Ata Notarial: O Tabelião pode lavrar atas notariais;
USC - 04 – Obter Ata Notarial: O Tabelião pode obter atas notarias;
USC - 05 – Autenticar na aplicação: O Tabelião pode se autenticar na aplicação; e
USC - 08 – Consultar Ata Notarial: O Tabelião pode consultar atas notarias.
53
Figura 8: Diagrama de Casos de Uso Tabelião
O terceiro diagrama (Figura 9) de caso de uso é referente ao ator Administrador que
realizará configurações necessárias para o funcionamento da aplicação e possui quatro casos de
usos que deverão ser desenvolvidos ao longo do desenvolvimento da aplicação web. A seguir será
feita uma breve descrição dos casos de uso:
USC - 05 – Autenticar na aplicação: O Administrador pode se autenticar na aplicação;
USC - 06 – Cadastrar Tabelião: O Administrador pode cadastrar Tabelião;
USC - 07 – Cadastrar ACT: O Administrador pode cadastrar ACT; e
USC - 09 – Cadastrar Template Ata Notarial: O Administrador pode cadastrar Templates de
atas notariais.
54
Figura 9: Caso de Uso do Administrador
55
Nome do caso de uso USC - 01: Cadastrar Usuário
Breve descrição O Requerente pode se cadastrar na aplicação.
Ator(es) Primário(s) Requerente
Pré-condições Nenhuma
Fluxo principal 1. O Requerente entra na página inicial da aplicação
2. O Requerente clica em “Cadastro”.
3. O Requerente preenche todos os campos necessários e
clica no botão ‘Salvar.
4. A aplicação solicita que o requerente confirme o seu
cadastro através de um desafio enviado por e-mail.
5. Após a confirmação (resposta ao desafio), o requerente
poderá se autenticar na aplicação.
Fluxos alternativos e exceções 1. Fluxo alternativo (4): Caso o Requerente não responda
ao desafio enviado por e-mail
1. O Requerente receberá uma mensagem em seu
navegador para primeiro confirmar o desafio
enviado por e-mail.
2. Fluxo alternativo (3): Caso o Requerente inclua um
CPF já cadastrado
1. O Requerente receberá uma mensagem em seu
navegador para verificar o CPF digitado e irá
avisar que já existe um usuário com este CPF
cadastrado.
3. Fluxo alternativo (3): Caso o Requerente digite uma
senha menor do que 8 dígitos.
1. O Requerente receberá uma mensagem em seu
navegador para verificar a senha digitada, pois a
mesma possui menos de 8 dígitos.
Pós-condições Nenhuma
Nome do caso de uso USC - 02: Solicitar Ata Notarial
Breve descrição O Requerente pode solicitar atas notariais.
Ator (es) Primário(s) Requerente
56
Pré-condições 1. O Requerente estar autenticado na aplicação.
Fluxo principal: 1. O Requerente clica em “Solicita ata notarial”.
2. Requerente faz uma breve descrição do fato ocorrido e
informa o endereço web onde se encontra o conteúdo a
ser registrado na ata notarial e clica em “Enviar
Solicitação”.
3. A aplicação faz o download dos dados indicados pelo
requerente para futura analise do Tabelião.
4. (OPCIONAL) Após o pagamento da solicitação da ata
notarial, a mesma será liberada para verificação.
Fluxos alternativos e exceções 1. Fluxo alternativo (2): Caso o Requerente ultrapasse o
número máximo de solicitações
1. O Requerente receberá uma mensagem na tela
informando o número máximo de solicitações
permitidas.
2. Finalizará o processo
2. Fluxo alternativo (1): Caso o Requerente forneça um
endereço web não válido.
1. O requerente receberá uma mensagem em seu
navegador alertando para verificar o endereço
web fornecido.
Pós-condições Nenhuma
Nome do caso de uso USC - 03: Lavrar Ata Notarial
Breve descrição O Tabelião pode lavrar atas notariais.
Ator(es) Primário(s) Tabelião
Pré-condições 1. O Tabelião estar autenticado na aplicação.
57
Fluxo principal 1. Tabelião clica em “Ata notarial” e seleciona o pedido
mais antigo através do botão “Lavrar Próxima Ata”.
2. Tabelião analisa a descrição do pedido, solicita os
dados coletados na aplicação web referente à
solicitação através do botão “Baixar Dados”.
3. A aplicação retorna o conteúdo web coletado.
4. O tabelião verifica se o conteúdo confere com a
descrição feita pelo Requerente.
5. Tabelião redige a ata notarial de acordo com o
conteúdo verificado (pode escolher um Template).
6. Sistema exibe a ata notarial com a opção para assinar e
carimbar a ata notarial (“Lavrar Ata Notarial”).
7. Tabelião assina e a carimba digitalmente a ata notarial.
Fluxos alternativos e exceções Nenhum
Pós-condições Nenhuma
Nome do caso de uso USC - 04: Obter Ata Notarial
Breve descrição O Tabelião pode solicitar atas notariais concluídas.
Ator(es) Primário(s) Tabelião
Pré-condições 1. O ator estar autenticado na aplicação.
Fluxo principal 1. Ator clica em “Ata notarial” e seleciona o status
“concluídas” e seleciona a ata notarial que desejada
visualizar.
2. Ator clica em “Baixar Ata Notarial”.
Fluxos alternativos e exceções Nenhum
Pós-condições Nenhuma
Nome do caso de uso USC - 05: Cadastrar Tabelião
Breve descrição O Administrador pode cadastrar Tabelião.
Ator(es) Primário(s) Administrador
Pré-condições 1. O Administrador estar autenticado na aplicação.
58
Fluxo principal 1. Administrador clica em “Cadastrar Tabelião”.
2. A aplicação apresenta um formulário para
preenchimento das informações de cadastro.
3. Administrador preenche os dados necessários para o
cadastro do Tabelião.
4. Administrador clica em “Salvar” para finalizar o
cadastro.
Fluxos alternativos e exceções Nenhum
Pós-condições 1. A aplicação solicita que o Tabelião confirme o seu
cadastro através de um desafio enviado para o seu
email.
2. Após a confirmação (resposta ao desafio), o Tabelião
poderá se autenticar na aplicação.
Nome do caso de uso USC - 06: Cadastrar ACT
Breve descrição O Administrador pode cadastrar ACT.
Ator(es) Primário(s) Administrador
Pré-condições 1. O Administrador estar autenticado na aplicação.
Fluxo principal 1. Administrador clica em “Cadastrar ACT”.
2. O Administrador preenche todos os campos
necessários.
3. Administrador clica em “Cadastrar” para finalizar o
cadastro.
Fluxos alternativos e exceções Nenhum
Pós-condições 1. A aplicação deverá apresentar o nome e o DNS da ACT
cadastrada.
3.4 DIAGRAMA DE SEQUÊNCIA
A seguir serão demonstradas as principais funcionalidades da aplicação web na forma de
diagramas de sequência para melhor apresentar a sequência de processos que serão tratados. Estes
59
diagramas mostram a sequência da chamada de métodos que será realizada pela aplicação para a
realização da operação desejada.
Este primeiro diagrama (Figura 10) de sequência mostra os passos para um Requerente se
cadastrar na aplicação. O diagrama está subdividido em duas etapas:
O Requerente inclui seus dados na tela de cadastro e salva; e
O Requerente confirma o seu cadastro através de um desafio (confirmação de cadastro
enviada ao seu e-mail).
Após a confirmação deste desafio por e-mail, o usuário então poderá se autenticar na
aplicação, caso não tenha feito a confirmação, o mesmo receberá uma mensagem solicitando que
realize a confirmação de cadastro.
Figura 10: Diagrama de sequência Cadastro de Usuário
60
O diagrama de sequência que demonstra os passos da aplicação para realizar uma solicitação
de uma ata notarial pelo Requerente necessita que o mesmo esteja autenticado na aplicação. Após se
autenticar ele poderá solicitar via interface web uma ata notarial, dando início aos passos
demonstrados no diagrama de sequência (Figura 11).
Figura 11: Diagrama de sequência Cadastro de Ata Notarial
O diagrama de sequência (Figura 12) que demonstra os passos para um Tabelião lavrar uma
ata notarial na aplicação está subdividido em três etapas:
o Tabelião irá carregar a listagem de atas notariais pendentes;
o Tabelião irá solicitar a aplicação os dados da ata notarial desejada; e
o Tabelião irá realizar a verificação dos dados relacionados à ata notarial e por fim
realizar a validação da mesma.
Após estes passos a ata notarial deverá estar disponível tanto para o Requerente como para o
Tabelião.
61
Figura 12: Diagrama de sequência Lavrar Ata Notarial
62
O diagrama de sequência (Figura 13) a seguir demonstra os passos para um Tabelião ou
Requerente baixar uma ata notarial que está armazenada na aplicação. Neste diagrama será utilizado
como exemplo o ator Tabelião para demonstrar os passos que são os mesmo para um Requerente
realizar a mesma ação na aplicação. Este diagrama de sequência está subdividido em duas etapas:
o Tabelião irá carregar a listagem de atas notariais concluídas;
o Tabelião irá visualizar a ata notarial desejada; e
o Tabelião irá clicar no botão para baixar (fazer o download) a ata notarial desejada.
Após estes passos o Requerente e o Tabelião deverão possuir a ata notarial, assinatura digital
e o carimbo do tempo em seu computador ou em outro local desejado.
Figura 13: Diagrama de sequência Baixar Ata Notarial
63
O diagrama de sequência (Figura 14) demonstra os passos para um Tabelião, Administrador
ou Requerente realizar a autenticação na aplicação web. Neste diagrama será utilizado como
exemplo o ator Administrador para demonstrar os passos que são os mesmo para um Requerente ou
Tabelião realizar a mesma ação na aplicação.
Figura 14: Diagrama de sequência Autenticação na Aplicação Web
64
O diagrama de sequência (Figura 15) demonstra a forma de cadastrar um Tabelião na
aplicação web. Foi modelado desta maneira para atribuir maior segurança à aplicação. Neste
diagrama será utilizado o ator Administrador para demonstrar os passos necessários.
Figura 15: Diagrama de sequência Cadastrar Tabelião
3.5 TECNOLOGIAS E FERRAMENTAS UTILIZADAS
A escolha de ferramentas e tecnologias utilizadas para o desenvolvimento da aplicação web
foi baseada no uso de tecnologias e softwares utilizados em larga escala no mercado e que sejam
abertos e/ou livres. Para o desenvolvimento foi escolhida a linguagem Java utilizando a
especificação JSF 2.0 com o Framework RichFaces 4.2.2, por ser utilizado para aplicações web com
interfaces mais leves.
Para a realização de testes unitários foi utilizado o Framework JUnit 4.0. Com esta
ferramenta, é possível gerar todos os testes unitários de método e também configurar o seu acesso
ao banco de dados para a própria ferramenta estar realizando testes do tipo cadastro, edição,
pesquisa e exclusão.
Para a iteração com o cliente, através do navegador, será utilizada a linguagem HTML e
Javascript e para a criação do layout serão utilizados estilos CSS (Cascade Style Sheets).
65
O banco de dados que iria inicialmente ser utilizado seria o PostgreSQL, por ser uma
ferramenta altamente utilizada para o desenvolvimento de aplicações Web, porém a configuração
do container de segurança Realm, nativo no servidor da aplicação não se comportou conforme
esperado, impedindo a sua utilização. Assim o banco de dados PostgreSQL foi substituído pelo
MySQL Server versão 5.5.27, que se integrou perfeitamente ao Realm. Além de ser uma ferramenta
livre, como o PostgreSQL, o MySQL possui uma arquitetura robusta capaz de suportar grandes
quantidades de dados e na versão utilizada recebeu melhorias de velocidade, disponibilidade,
escalabilidade e facilidade de utilização. Portanto a mudança do banco de dados é justificável, pois
não ameaçou qualquer conceito ou mecanismo e segurança já propostos.
A ferramenta para o desenvolvimento em Java, JSF, HTML, Javascript e CSS foi o Eclipse
Indigo. A escolha foi feita por ser uma ferramenta livre, estável e amplamente utilizada para o
desenvolvimento Web além de fornecer componentes que auxiliam no desenvolvimento das
aplicações.
O Servidor da aplicação J2EE (Java 2 Enterprise Edition) que estava previsto para ser
utilizado na aplicação era o JBoss 6.1.0, por oferecer suporte nativo as tecnologias JavaEE, JSF e
Richfaces 4.2.2. Porém a sua utilização foi abandonada no inicio do desenvolvimento do projeto,
visto que para um desenvolvimento mais ágil a utilização do Container Web Apache Tomcat versão
6.0 Final seria mais interessante. Além de um desenvolvimento mais ágil, o Tomcat contempla as
funcionalidades que seriam utilizadas no servidor de aplicação JBoss, como o gerenciado de
segurança da aplicação (Security Manager), o gerenciador de autenticação (Realm - que vem nativo
no Tomcat) e o suporte à especificação JSF 2.0 e o Framework RichFaces 4.2.2.
Conforme já mencionado, foi utilizado para gerenciar a autenticação de usuários na
aplicação o Realm. Este é responsável por não permitir que sejam acessados dados da aplicação sem
a permissão específica. Esta ferramenta vem nativa com o container Tomcat e é feita em Java o que
proporciona uma flexibilidade e extensibilidade.
A assinatura digital sobre a ata notarial e sobre o conteúdo coletado pelo servidor foi
realizada através da biblioteca privada e comercial BRy Signer SDK que foi fornecida pela Empresa
BRy Tecnologia.
O carimbo do tempo que é anexado a assinatura digital será gerada através da biblioteca
privada e comercial BRy PDDE SDK que pertence a mesma empresa fornecedora do Signer SDK.
66
3.6 DETALHAMENTO DO DESENVOLVIMENTO
Nesta seção são descritos em detalhes os módulos que compõe a aplicação Web, suas
características, funcionalidades, informações de implementação e as interações entre os módulos.
3.6.1 Autenticação e cadastro de usuários na aplicação Web
Para realizar o processo de autenticação na aplicação, é necessário que o usuário já esteja
cadastrado na aplicação. A aplicação contempla três tipos perfis de usuário: administrador, tabelião
e requerente. Cada tipo de perfil é cadastrado de uma forma diferente na aplicação e contempla
funções diferentes.
O perfil administrador é cadastrado no momento da criação da base de dados da aplicação,
não sendo possível cadastrar outro administrador na aplicação. Foi criada esta restrição para que
diminuam as possibilidades de falhas e algum usuário mal intencionado possa se cadastrar, ou
cadastrar outra pessoa, como administrador, conforme segue o código de cadastro do administrador
a seguir (Quadro 1):
usuarios.add(FabricaDAO.getUsuarioDAO().makePersistent(new Usuario(id, "NomeAdministrador","[email protected]","usuario","senha",perfilAdministrador, "CPF_administrador")))
Quadro 1: Persistência do usuário com perfil 'Administrador'
O perfil tabelião é cadastrado somente através do perfil administrador, justamente para
apenas uma pessoa ficar responsável pelo cadastramento de usuário com perfil tabelião. Após o
administrador salvar o cadastro do novo usuário, este novo usuário irá receber um e-mail da
aplicação contendo um código único de verificação. Este código de verificação é gerado a partir de
dados cadastrais do tabelião utilizando o algoritmo de criptografia SHA-2. O tabelião então deverá
copiar o código recebido em seu e-mail e inserir na aplicação para que a mesma verifique e libere o
novo usuário, caso contrário o usuário não terá poderes de realizar quaisquer tipos de solicitações.
As imagens a seguir (Figura 16,Figura 17 e Figura 18) demonstrarão todos os passos citados:
67
Figura 16: Tela de cadastro de usuário
68
Figura 17: Mensagem de sucesso da operação de cadastro de usuário.
Figura 18: Tela responsável por confirmar o cadastro de um usuário através do código de
verificação.
69
Já com relação ao cadastro de usuário com o perfil requerente, este deverá ser feito pelo
próprio usuário iniciando o processo na tela inicial da aplicação. A tela de cadastro do requerente é
similar ao cadastro do tabelião, possuindo apenas como diferencial o campo de profissão que é
mostrado e obrigatório no cadastro de requerente e de tabelião não. Os processos de envio de um
código de verificação e validação do código são idênticos ao do perfil tabelião. As imagens a seguir
mostram como acessar a tela de cadastro de um requerente (Figura 19) e a tela de cadastro do
requerente (Figura 20).
Figura 19: Tela inicial da aplicação.
70
Figura 20: Tela de cadastro de usuário com perfil requerente
71
3.6.2 Gerenciamento de atas notariais
O Gerenciador de Atas Notariais é responsável por permitir aos usuários de acordo com os
seu perfil: solicitar, lavrar, acompanhar, visualizar e baixar (download) os dados armazenados e a
assinatura gerada após lavrar uma ata notarial.
O perfil requerente possui como funções: solicitar, acompanhar, visualizar os dados e baixar
o conteúdo solicitar bem como o carimbo do tempo anexado a assinatura digital depois de
concluído o fluxo de lavrar uma ata notarial.
Para realizar qualquer processo referente à ata notarial é necessário que o usuário esteja já
cadastrado na aplicação e que o mesmo esteja com o seu status ‘ativo’. A cada operação solicitada à
aplicação, este status é checado, pois caso o usuário por qualquer motivo fique com o status
‘bloqueado’, o mesmo perde o seu poder de solicitar operações. Apesar da existência do status
bloqueado, atualmente as duas únicas maneiras de um usuário ficar bloqueado é no momento em
que o mesmo se cadastra e ainda não inseriu o código de ativação do cadastro, ou alterar via banco
de dados. Caso futuramente seja implementada uma função de bloquear usuários, a aplicação já está
pronta para permitir e suportar este tipo de ação.
O processo de solicitar uma ata notarial é feita somente a partir do usuário que possuir o
papel de ‘requerente’ na aplicação. O processo é iniciado a partir da tela da listagem de atas
notariais, onde o requerente solicita uma nova ata notarial, e então o mesmo é redirecionado para a
tela de cadastro da solicitação da ata notarial conforme demonstrado na Figura 21.
72
Figura 21: Tela com as atas notariais cadastradas pelo requerente e inicio do processo para
solicitação de uma ata notarial.
Na tela de cadastro da solicitação, é necessário o requerente fornecer uma fiel descrição do
fato que o mesmo deseja registrar. Esta descrição irá contextualizar o tabelião no momento de lavrar
a ata notarial, para que o mesmo direcione a sua verificação no fato desejado pelo requerente. Este
processo é similar ao processo que ocorre na forma tradicional, onde o requerente narra os fatos “in
loco” para um tabelião. A Figura 22 demonstra a tela de cadastro de uma nova solicitação.
Após a descrição dos fatos, o requerente fornece um endereço eletrônico (link) para que
assim que a solicitação for salva, a aplicação acesse estes endereço eletrônico e salve todo o
conteúdo no banco de dados.
Para implementar a função de carregar e salvar todo o conteúdo que está em meio Web no
banco de dados foram necessárias a implementação de outras três funcionalidade: Download do
conteúdo Web e conversão de conteúdo web para um arquivo no formato PDF e a compactação
73
destes dados para uma melhor preservação do banco de dados. Todas essas funcionalidades serão
descritas adiante. As imagens a seguir demonstram estes passos.
Somente após a ata notarial estar concluída (passo que depende do tabelião e será descrito a
seguir) é que o requerente poderá realizar a operação de baixar a ata notarial e os respectivos dados
como também baixar a assinatura digital do seu documento para verificação se necessário.
Figura 22: Cadastro da solicitação de uma ata notarial
A segunda parte da implementação do gerenciador de atas notariais é voltada para o
tabelião, e contempla as funções pesquisar, lavrar, visualizar e baixar os dados associados às atas
notariais. Para a utilização das funcionalidades do usuário com o perfil tabelião, é necessário que o
usuário esteja com o seu status ativo no banco de dados e que tenha um certificado cadastrado, para
que no momento de lavrar a ata notarial este possa ser carregado e dado início ao processo de
autenticação dos dados através da assinatura digital e carimbo do tempo.
A pesquisa realizada sobre as atas notariais pode levar em consideração um intervalo de
datas de solicitação, por exemplo: solicitar as atas solicitadas entre os dias 01/10/2012 até
10/10/2012. É possível também pesquisar pelo status das atas notariais através da seleção do status
na tela de listagem das atas notariais.
Os métodos de listagem e pesquisa de atas notariais foram implementados utilizando
framework de persistência Hibernate através da linguagem HQL (Hibernate Query Language) que é
74
uma abstração da linguagem SQL (Structure Query Language) e facilita as pesquisas e retorno de
dados. A Figura 23 demonstra a interface da listagem das atas notariais:
Figura 23: Tela da listagem das atas notariais
A função de lavrar atas notariais pode ser executada de duas formas: através do botão de
“Lavrar Próxima Ata” ou através do botão “Lavrar” localizado ao final de cada linha da listagem. A
função do botão “Lavrar Próxima Ata” é carregar sempre a ata notarial que está a mais tempo
esperando para ser executada.
Após o tabelião selecionar uma das duas formas de lavrar a ata notarial, o mesmo será
redirecionado para a tela de Lavrar Ata Notarial. É nesta tela que o tabelião poderá visualizar os
dados da solicitação como, por exemplo: nome do requerente, descrição dos fatos do requerente,
endereço eletrônico fornecido pelo requerente como também baixar os dados que a aplicação
armazenou para estar verificando e validando as informações fornecidas pelo requerente conforme
demonstra a Figura 24.
75
Figura 24: Tela onde o tabelião lavra a ata notarial
Ao verificar a descrição do fato narrado e visualização dos dados armazenados pela
aplicação, o tabelião deverá escolher o modelo de ata notarial que deseja utilizar. Caso não tenha
nenhum modelo cadastrado, o tabelião poderá sair da tela de lavrar ata notarial, cadastrar um
modelo e retornar a tela, ou poderá digitar um texto que represente o documento da ata notarial.
Feitas todas as verificações, o tabelião poderá lavrar a ata notarial. Quando a ação de lavrar
ata notarial for executada, a aplicação executará uma série de procedimentos como:
carregar e descompactar os dados armazenados a partir do endereço fornecido;
carregar e transformar a descrição do tabelião em um arquivo txt;
converter em um arquivo no formato PDF a descrição do tabelião;
concatenar em um único arquivo PDF a descrição do tabelião seguida pelos dados
armazenados a partir do endereço fornecido;
enviar para o módulo assinador este arquivo concatenado juntamente com o usuário
tabelião;
76
atualizar a ata notarial com:
o a assinatura digital;
o o novo arquivo concatenado contendo a ata notarial e os dados;
o tabelião responsável pela assinatura do documento;
o data da autenticação;
o status para “Concluído”.
atualizar a ata notarial no banco de dados.
No Quadro 2 apresenta-se o método principal do gerenciador de atas notariais no momento
de lavrar uma ata notarial.
77
public void concluirProcessoLavrarAtaNotarial(String usuarioLogado, AtaNotarial ataNotarial) throws ExcecaoAtaNotarial { try { Usuario usuario = FabricaDAO.getUsuarioDAO().findByLogin(usuarioLogado); // Carrega e descompacta o arquivo original byte[] arquivoOriginal = ataNotarial.getDadosArmazenados(); arquivoOriginal = Utils.descompactar(arquivoOriginal); String AtaNotarial = ataNotarial.getDescricaoTabeliao(); String caminhoTemp = UteisIO.getDiretorioTemporario() + new Date().getTime(); System.out.println("criando diretório temporários: " + new File(caminhoTemp).mkdirs()); // Transforma os dados da ata notarial em arquivo texto File arquivoAta = new File(caminhoTemp + "\\" + ataNotarial.getId() + "_arquivoParaAta.txt"); FileWriter fw = new FileWriter(arquivoAta); PrintWriter saida = new PrintWriter(fw); saida.println(AtaNotarial); saida.close(); fw.close(); // Converte os dados da ata notarial para pdf FileInputStream ataConvertidaParaPDF = new FileInputStream(arquivoAta); ConversorPDF c = new ConversorPDF(); File arquivoAtaConvertidaParaPDF = c.converterPDF(ataConvertidaParaPDF, caminhoTemp); ataConvertidaParaPDF = new FileInputStream(arquivoAtaConvertidaParaPDF); ByteArrayInputStream bis = new ByteArrayInputStream(arquivoOriginal); X509Util.escreverArquivo(caminhoTemp + "\\assinatura.pdf", arquivoOriginal); // Cria a lista de InputStream para enviar ao concatenador de PDF ConcatenadorPDF concatenadorPDF = new ConcatenadorPDF(); List<InputStream> lista = new ArrayList<InputStream>(); lista.add(ataConvertidaParaPDF); lista.add(bis); // Concatena os dados da ata notarial com os dados obtidos da // internet File arquivoRetornoPDFConcatenado = new File(caminhoTemp + "\\" + ataNotarial.getId() + "_ata_final.pdf"); concatenadorPDF.concatenarObjetos(lista, arquivoRetornoPDFConcatenado); InputStream ataNotarialCompleta = new FileInputStream(arquivoRetornoPDFConcatenado); // Assina a ata notarial gerada byte[] ataNotarialCompletaByteArray = IOUtils.toByteArray(ataNotarialCompleta); IGerenciadorAssinatura gerenciadorAssinatura = new GerenciadorAssinatura(); byte[] assinatura = gerenciadorAssinatura.assinarArquivo(ataNotarialCompletaByteArray,usuario); // atualiza a ata notarial já com os dados assinados ataNotarial.setAssinatura(assinatura); ataNotarialCompletaByteArray = Utils.compactar(ataNotarialCompletaByteArray, "ataNotarial.pdf"); ataNotarial.setDadosArmazenados(ataNotarialCompletaByteArray); ataNotarial.setStatus(Status.CONCLUIDO); ataNotarial.setTabeliao(usuario); ataNotarial.setDataAutenticacao(new Date()); IAtaNotarialDAO dao = new AtaNotarialHibernateDAO(); dao.atualizar(ataNotarial); } catch (ExcecaoX509UtilEscreverArquivo e) { throw new ExcecaoAtaNotarial("Erro ao concluir o processo de lavrar ata notarial"); } catch (IOException e) { throw new ExcecaoAtaNotarial("Erro ao concluir o processo de lavrar ata notarial", e); } catch (ExcecaoManipuladorPDF e) { throw new ExcecaoAtaNotarial("Erro ao concluir o processo de lavrar ata notarial", e); }
}
Quadro 2: Método de finalização do fluxo da ata notarial
78
3.6.3 Módulo de Download do conteúdo Web e conversão para PDF
Após um requerente realizar a solicitação de uma ata notarial, a aplicação Web se comunica
com o módulo que é responsável por realizar o download do conteúdo na linguagem HTML e
realizar a conversão deste conteúdo em um arquivo no formato PDF através do endereço eletrônico
fornecido.
Conforme previsto na análise de risco, este módulo forneceu uma grande complexidade no
seu desenvolvimento. Por desconhecimento, foi iniciado o desenvolvimento de um processamento
de todo o código HTML proveniente do link fornecido pelo requerente, através da aplicação. Após
dias investidos nessa funcionalidade, foi abandonada a ideia devido à variedade de construções de
código HTML e pela complexidade que a mesma estava fornecendo; então, foi iniciada a pesquisa
de uma forma alternativa para sanar este problema e o resultado é apresentado a seguir.
Este módulo foi implementado utilizando a ferramenta Wkhtmltopdf sob a licença GPL
(General Public License ou Licença Pública Geral) que permite a utilização, distribuição e
modificação de sua ferramenta. Esta ferramenta utiliza internamente o Webkit (motor de
renderização) do navegador Safari que também é um projeto de código aberto (open source).
Como a ferramenta Wkhtmltopdf é desenvolvida na linguagem C++, optou-se pela criação
de um módulo que realize o gerenciamento da comunicação entre a linguagem Java e a aplicação
Wkhtmltopdf para diminuir o acoplamento e preservar a coesão da aplicação Web proposta.
Fez-se isso, por dois motivos: primeiramente ficou inviável implementar um analisador e
conversor HTML para que este fosse utilizado somente nesta aplicação Web; o segundo motivo e
mais importante foi relacionado à segurança, pois a ferramenta utilizada retorna um arquivo no
formato PDF e não HTML, e já possui mecanismos de segurança principalmente contra o ataque
XSS (Cross-site Scripting), que será explicado mais a frente.
3.6.4 Módulo de conversão e concatenação da ata notarial e do conteúdo Web
Foi necessário o desenvolvimento de um módulo para realizar o gerenciamento de arquivos
que exigem uma conversão para um arquivo no formato PDF ou de dois ou mais arquivos que
utilizam a concatenação também em um arquivo no formato PDF. Dentro do contexto da aplicação,
este arquivo contém todos os dados relevantes referentes à ata notarial. Para a conclusão do
79
processo de lavrar uma ata notarial, é gerado um único documento contendo a ata notarial e o
conteúdo web num único arquivo de formato PDF.
A implementação deste módulo passou por duas etapas. Na primeira etapa foi realizado o
desenvolvimento de um conversor de arquivos no formato TXT para arquivos no formato PDF. A
melhor ferramenta encontrada que se encaixa nas necessidades desta aplicação Web foi o
Jodconverter desenvolvido e mantido pelo Artofsolving. O Jodconverter é distribuído sob a licença
LGPL (Lesser General Public License ou Licença Pública Geral Reduzida) que permite a sua cópia,
utilização e distribuição desta cópia, proibindo apenas a sua modificação.
A segunda etapa de desenvolvimento deste módulo caracterizou-se pela necessidade de
concatenar os dados relevantes de uma ata notarial bem como os dados armazenados de endereço
eletrônico fornecido pelo requerente. Desta forma, optou-se pelo desenvolvimento de um
concatenador de arquivos no formato TXT e PDF para que o módulo retornasse apenas um único
arquivo já concatenado no formato PDF.
Nesta segunda etapa foi utilizada a ferramenta da Fundação Apache, o Pdfbox que possui
por função a conversão de arquivos para o formato PDF. O Pdfbox está sob a licença
Apache.License.v2.03, que permite a sua utilização e redistribuição.
3.6.5 Gerenciador de assinatura digital e carimbo do tempo
Conforme especificado na fundamentação teórica, para atribuir maior segurança e
confiabilidade em dados eletrônicos foi criado um gerenciador de assinatura digital e carimbo do
tempo. Este gerenciador tem por finalidade receber uma cadeia de bytes e gerar um carimbo do
tempo anexado a uma assinatura digital (ADRT - Assinatura Digital com Referência Temporal).
Para a realização da assinatura digital e carimbo do tempo, foram utilizadas duas bibliotecas
de classes fornecidas pela empresa BRy Tecnologia sob contrato4 de não fornecimento para
qualquer tipo de utilização a não ser para esta aplicação.
Antes de iniciar o processo de assinatura digital e carimbo do tempo, é carregado o
certificado do tabelião (signatário – usuário que irá realizar a assinatura digital) que deve ter sido
previamente cadastrado, caso contrário a aplicação não permitirá a inicialização do fluxo.
3 Que está disponível na íntegra em http://www.apache.org/licenses/LICENSE-2.0 4 A imagem digitalizada deste contrato está disponível na íntegra nos anexos deste documento.
80
Posteriormente a este processo, será solicitada a senha do certificado para que a mesma seja
fornecida ao Signer SDK.
Para a utilização da biblioteca de assinatura digital é necessário primeiramente a
configuração de uma autoridade carimbadora (ACT) através da biblioteca BRy PDDE SDK
(Protocoladora Digital de Documentos Eletrônicos). Esta PDDE é configurada a partir de um
endereço (IP ou DNS) de uma SCT que por sua vez está sob responsabilidade da respectiva ACT.
Após esta configuração inicial da PDDE, é possível iniciar a configuração da biblioteca
responsável pela assinatura digital que é a BRy Signer SDK (ou Signer SDK – Assinador). Para
utilizar esta biblioteca, é necessário informar todas as configurações realizadas da PDDE para o
Signer SDK.
Feita a configuração, é iniciado o processamento do cálculo de hash sobre o arquivo que se
deseja assinar, utilizando o algoritmo de criptografia SHA-1 e armazenado para utilização posterior.
Neste momento o certificado do signatário será acessado e fornecido ao Signer SDK, juntamente
com a senha previamente fornecida.
Subsequente é então fornecido o tipo de política de assinatura digital que se deseja utilizar.
No caso desta aplicação será somente o tipo ADRT (Assinatura Digital com Referência Temporal) e
o tipo de algoritmo que se utilizou para o calculo do hash que o algoritmo SHA-1. Conforme o
trecho de código a seguir (Quadro 3) pode-se observar os quatro itens descritos neste parágrafo
sendo enviados por parâmetro. Este mesmo processo está demonstrado na Figura 44 da página 33.
byte[] assinaturaADRT = assinador.assinar(hash, certificado, ADRT_CMS, algHash);
Quadro 3: Trecho onde é solicitada a geração de uma assinatura do tipo ADRT
Para finalizar o procedimento é então iniciado o processo de geração da assinatura digital e
carimbo do tempo, onde o Signer SDK retorna a assinatura digital em forma de uma cadeia de
bytes. Esta cadeia de bytes que é retornada do Signer SDK será salva no banco de dados para ficar
disponível pra futuras análises tanto para o requerente como para o tabelião.
Para uma melhor confiabilidade do processo, foi incluída uma função no gerenciador de
assinatura digital, que é a verificação desta mesma assinatura digital. A configuração deste
verificador de assinatura digital consiste em informar a assinatura que se deseja verificar, o
algoritmo de hash utilizado na geração da assinatura digital (SHA-1) e o hash que foi armazenado
no inicio do processo de assinatura digital.
81
Se por algum motivo a assinatura digital não estar válida (como por exemplo, algum ataque
realizado a aplicação, ou inconsistência de dados), a ata notarial se torna inválida, alterando o seu
status para cancelado.
3.6.6 Compactação dos dados armazenados
Foi vista a necessidade da implementação de um compactador de dados por três motivos. O
primeiro motivo foi, pois a manipulação de dados do tipo texto e HTML com estilos (CSS –
Cascade Style Sheet) ou imagens de tamanhos e extensões diferente, ocorrem constantemente
durante a utilização da aplicação. O segundo, e principal, foi para garantir um menor uso do banco
de dados (preservação) ao longo do uso da aplicação. E o terceiro motivo foi para reduzir a
quantidade de informações que serão trafegadas entre servidor e cliente.
Para realizar a implementação do compactador, foram utilizadas as próprias classes e
interfaces de funções e métodos que o Java fornece para a manipulação de arquivos. Entre as
classes que estão ligadas diretamente as funções de compactação e descompactação estão:
InputStream, OutputStream e ZipOutputStream. No Quadro 4 será demonstrado um trecho de
código onde se realiza a compactação de dados e o método retorna um InputStream.
public static InputStream compactar(InputStream is, String nomeDoArquivo) throws IOException { if (is.markSupported()) { is.reset(); } File temporario = File.createTempFile(TMP_PREFIXO + "zip-" + nomeDoArquivo + ".", TMP_SUFIXO); FileOutputStream fos = new FileOutputStream(temporario); ZipOutputStream out = new ZipOutputStream(fos); out.setLevel(Deflater.BEST_COMPRESSION); out.setMethod(ZipOutputStream.DEFLATED); ZipEntry entry = new ZipEntry(nomeDoArquivo); entry.setMethod(ZipOutputStream.DEFLATED); out.putNextEntry(entry); IOUtils.copy(is, out); out.closeEntry(); IOUtils.closeQuietly(is); IOUtils.closeQuietly(out); TempFileInputStream tfis = new TempFileInputStream(temporario); return tfis; }
Quadro 4: Implementação do método de compactação
82
3.6.7 Criação de Modelos de Atas Notariais
Tendo em vista uma maior facilidade no momento de lavrar atas notariais, foi criada uma
tela onde é possível cadastrar um modelo de ata notarial. Este modelo poderá incluir variáveis que
fazem referência aos dados do requerente, localidade, temporal e do tabelião. O intuito deste
modelo pré-cadastrado na aplicação é poder utilizar no momento em que o tabelião está lavrando
uma ata notarial para reduzir o seu esforço.
As chaves utilizadas pela aplicação possuem a palavra que faz referência ao banco de dados
ao centro, iniciando com sinal de maior (<) e finalizando com sinal de menor (>). Por exemplo, a
chave <NOME.REQUERENTE> no modelo de ata notarial quando carregado na tela de lavrar a ata
notarial, será substituída pelo nome do requerente a qual pertence a solicitação de lavrar a ata
notarial, conforme demonstram as imagens a seguir respectivamente:
83
Figura 25: Cadastro do Template da Ata Notarial
A próxima imagem (Figura 26) já demonstra a utilização de um modelo de ata notarial pré-
cadastrada no momento de lavrar a ata notarial. É possível comparar as Figura 23 e Figura 24
(páginas 74 e 75) e verificar a substituição das chaves pelos valores reais que estão armazenados no
banco de dados.
84
Figura 26: Painel com o template já processado
Após realizar o cadastro do modelo de ata notarial, é possível realizar o gerenciamento
através da tela de listagem dos modelos, onde pode-se cadastrar, editar ou excluir, conforme
apresentado na Figura 27.
Figura 27: Listagem dos Modelos de Atas Notariais
85
3.6.8 Prevenção contra ataques
Após o estudo bibliográfico e pesquisas realizadas foram então levantados alguns dos
principais ataques que a aplicação poderia sofrer. Com o intuito de minimizar a possibilidade de
ataques, e neste sentido, maximizar a segurança a ser atribuída para a aplicação, viu-se a
necessidade de circundar a aplicação com tecnologias que já estão maduras em seu
desenvolvimento e utilização tanto dentro do contexto acadêmico como comercial.
Infelizmente não é possível evitar todos os tipos de ataques a um serviço, mas é possível
minimizar estes possíveis ataques para que se possa oferecer uma aplicação cada vez mais confiável
e robusta. Estes ataques podem ser subdivididos em:
Acesso físico;
Interceptação de comunicação;
Indisponibilidade do serviço;
Alteração de privilégios;
Engenharia Social;
Backdoors.
A aplicação foca em quatro principais ameaças da aplicação web, descritas nas seções
abaixo.
3.6.8.1 Cross-site Scripting (XSS)
Esta é uma vulnerabilidade encontrada em aplicações web, pois ainda é comum os
desenvolvedores utilizarem técnicas de desenvolvimento que possuem brechas de segurança que já
são amplamente conhecidas. Este tipo de ataque injeta códigos JavaScript em um campo texto de
uma página já existente e este JavaScript é apresentado e poderá ser executado para outros usuários.
Este tipo de ataque pode permitir que o navegador do usuário (tabelião no caso) execute um
código JavaScript indesejado em seu computador. Entre as diversas funções que o JavaScript
possui, está a de redirecionamento de página, ou seja, se um navegador executar o comando de
redirecionamento de página, o usuário pode acabar indo para uma falsa página idêntica a uma
original e fornecer o seu usuário e senha.
A medida tomada foi não fornecer nenhum conteúdo ou arquivo no formato HTML para o
tabelião que estará abrindo os dados armazenados através do endereço fornecido por um requerente.
86
O formato de arquivo fornecido é PDF onde mesmo se existir algum código JavaScript mal
intencionado, o mesmo não será executado.
Diante dos fatos demonstrados, fica claro que este tipo de ataque estaria colocando em risco
alguns conceitos de segurança como a confiabilidade, confidencialidade, autenticidade e a
disponibilidade da aplicação web.
3.6.8.2 Sniffing ou Sniffers
É o procedimento realizado por um programa ou dispositivo conhecido
como Sniffer (também conhecido como Packet Sniffer, Analisador de Rede, Analisador de
Protocolo, Ethernet Sniffer em redes do padrão Ethernet ou ainda Wireless Sniffer em
redes wireless). Esta ferramenta, normalmente constituída de um software, é capaz de interceptar
e registrar o tráfego de dados em uma rede de computadores. Conforme o fluxo de dados trafega na
rede, o Sniffer captura cada pacote e eventualmente decodifica e analisa o seu conteúdo.
Um Sniffer é capaz de interceptar todo e qualquer dado enviado em uma rede, como por
exemplo, o de capturar conversas de mensagens instantâneas, senhas não criptografadas e arquivos
enviados/baixados do computador de um usuário. Fica evidente a importância de estar aumentando
a dificuldade de um usuário qualquer monitorar todas as informações trocadas, inclusive quando
trata-se de uma aplicação web voltada a segurança.
Este tipo de ataque já é conhecido e é possível evitar que os dados estejam facilmente
disponíveis para estes sistemas que ficam monitorando (Sniffer) todo e qualquer dado trocado via
internet. Uma forma de não cair em armadilhas é através da utilização de antivírus e firewalls nos
dispositivos de rede, computadores e servidores.
Outra forma de prevenir estes tipos de ataques é através da criptografia de dados trocados
entre cliente e servidor. Este mecanismo de segurança chamado de SSL é utilizado a partir do
próprio servidor que fornece de forma nativa a criptografia das trocas de dados, através de um canal
criptografado. Este tipo de configuração necessita da criação de um certificado digital para o que o
Container Tomcat possa está armazenando a chave pública da aplicação que deseja utilizar o canal
seguro (SSL).
Desta forma, se um Sniffer estiver monitorando a rede da aplicação web ou de um usuário
desta aplicação web, será em vão, pois os dados que o Sniffer irá capturar não irão fazer sentido
algum pois estão criptografados pelo mecanismo de canal seguro (SSL). Assim como no ataque
87
anterior, se a aplicação não estivesse preparada para este tipo de ataque (Sniffing), os riscos de não
garantir os conceitos de segurança (confiabilidade, confidencialidade, autenticidade e a
disponibilidade da aplicação web) propostos seriam os mesmo.
3.6.8.3 Buffer Overflow
Ataque conhecido como estouro de buffer, pode ser executado ou criado por entradas que
são projetadas para executar código, ou mudar o modo como a aplicação funciona. Caso isso ocorra,
um laço de repetição (onde executa uma ação de leitura e escrita em disco), por exemplo, pode
continuar após a sua parada prevista, o que resultaria em perda de dados pela parte da aplicação e
do servidor onde a aplicação está hospedada.
Isso pode resultar em diversas modificações e instabilidades da aplicação web, incluindo
acessos inválidos à memória, resultados incorretos contendo dados de outras partes da aplicação,
parada total da aplicação, ou uma brecha num sistema de segurança.
A forma de lidar com este tipo de ataque consiste em uma série de escolhas, como por
exemplo, a linguagem de programação que será utilizada para o desenvolvimento da aplicação. A
linguagem fornece mecanismos de estar evitando este tipo de erro, como por exemplo, funções de
controle de limites de arrays ou até mesmo laços de repetição onde o controle é feito internamente,
não sendo possível a aplicação estar controlando esses índices, como é o exemplo do for each.
No caso do for each, a própria JVM (Máquina Virtual Java) controla as iterações do laço de
repetição; já o mesmo não ocorre na linguagem C ou C++, onde a aplicação está mais suscetível a
estes tipos de ataques ou erros.
Durante o desenvolvimento da aplicação, foram tomados os devidos cuidados para que as
entradas de dados não extrapolassem o permitido e o previsto, prevenindo este tipo de erro. A
manipulação de arquivos também foi algo já pensando no possível estouro de erros, porém como
mencionado, a linguagem Java já fornece auxílio neste quesito.
3.6.8.4 SQL Injection
Este tipo de ataque conhecido como SQL Injection ou Injeção de SQL, é um ataque que visa
injetar comandos a serem processados pela aplicação ou pelo banco de dados.
88
A intenção pode ser a mais variada possível, mas normalmente, este ataque visa atacar a
integridade dos dados, corrompendo-os, ou atacar a confidencialidade da aplicação através do
acesso não autorizado a informações e dados do banco de dados.
Este tipo de ataque ficou muito comum quando grande parte dos sites e das aplicações
utilizava a passagem de parâmetros através do endereço do navegador de forma similar a esta:
http://www.alvo.com/news?id=5.
Neste caso a passagem de parâmetro ocorre através do envio do identificador de algum
objeto para o banco de dados. Caso um usuário com más intenções quisesse vasculhar outros
objetos com identificadores diferentes, bastava ele trocar o identificador e enviar a solicitação ao
servidor que por sua vez retornaria o objeto desejado e todas as suas informações através do
identificador.
Prevendo este tipo de ataque, a aplicação utiliza o método de transmissão de dados POST,
que “esconde” as informações enviadas ao servidor, deixando invisível para o usuário. Outra
proteção contra o SQL Injection é que todas as consultas são estáticas, ou seja, não é possível
realizar nenhum tipo de busca, cadastro, edição ou exclusão do banco de dados a não ser passando
pelos métodos pré-definidos na aplicação.
Outro tipo de ataque comum é a tentativa de autenticação via SQL Injection. O usuário
malfeitor tenta se autenticar na aplicação através de uma condição lógica conforme quadro abaixo.
nome = admin
senha = ' or 1=1--
nome = ' or 1=1--
senha =
nome = ' OR "='
senha = ' OR "='
Quadro 5: Exemplos de injeção de SQL
Estes tipos de ataques, a própria ferramenta de autenticação Realm, realiza toda a
verificação e validação das tentativas de autenticação na aplicação, e se não estiver de acordo, não é
realizada tentativa de autenticação.
Desta forma os dados da aplicação estão com um nível de segurança muito bom,
dificultando as ações de qualquer tipo de usuário mal intencionado em estar atacando a aplicação.
3.7 DESCRIÇÃO DOS EXPERIMENTOS
Com o objetivo de avaliar a aplicação web e seus mecanismos de segurança, foram
realizadas algumas simulações. Para cada simulação realizada, foram coletados os armazenados os
89
dados de entrada e saída dos testes. Os testes foram testadas em um computador com processador
Intel Core 2 Duo, com frequência de clock de 2,27 Ghz, 4GB de memória RAM e o sistema
operacional Windows 7.
Os testes foram realizados no intuito de garantir o correto funcionamento e atendimento aos
requisitos funcionais propostos neste projeto. Ao longo da implementação foram realizados
repetidos testes com o intuito de corrigir falhas em tempo de execução. A execução destes testes foi
de caixa preta ou depurações diretas no próprio código.
Ao finalizar o desenvolvimento, os casos de uso foram submetidos a testes e descritos no
anexo III - Casos de teste e Anexo IV - testes unitários, para verificar e ser validado a fim de tornar
possível sua possível eficácia e aceitação no âmbito acadêmico comercial.
Após os testes de caso de uso, a aplicação Web foi submetida a testes com um grupo de
usuários. Este grupo de usuários foi submetido a uma pesquisa após a utilização da aplicação para
poder obter dados a respeito da facilidade de entendimento da aplicação, facilidade em operar a
aplicação, atratividade/satisfação do usuário, se a aplicação lhe será útil, e se foram encontrados
muitos erros. Cada item da pesquisa pode ser quantificado entre a faixa 1 (um) e 5 (cinco),
representando respectivamente muito ruim/difícil e muito fácil/bom.
A pesquisa está dividida em duas partes. A primeira parte contempla perguntas direcionadas
à aplicação Web que referenciam a experiência que os usuários tiveram com a mesma, totalizando
14 (quatorze) usuários participantes. A pesquisa foi realizada da seguinte forma:
foi realizada uma breve introdução da aplicação Web, explicando a sua finalidade;
os usuários realizaram o fluxo completo dos atores Requerente e Tabelião, solicitando,
pesquisando, lavrando e baixando os dados da ata notarial concluída e da assinatura
digital; e
ao término, os usuários foram submetidos à pesquisa, quantificando a aplicação.
90
Figura 28: Pergunta 1
Figura 29: Pergunta 2
Figura 30: Pergunta 3
91
Figura 31: Pergunta 4
Figura 32: Pergunta 5
Após verificar os resultados demonstrados nas perguntas 1, 2 e 3 (Figuras 27, 28 e 29), é
possível concluir que a aplicação Web possui boa aceitação perante os usuários que realizaram os
testes na aplicação. É válido observar que todos os usuários realizaram o fluxo completo dos atores
Requente e Tabelião.
Por parte do Requerente foi executando as ações de solicitar ata notarial, verificar a listagem
das suas solicitações de ata notarial, visualizar os dados das atas notariais e por fim, poder baixar a
assinatura digital e a ata notarial gerada pelo ator Tabelião.
E por parte do ator Tabelião foram executadas as ações de lavrar a ata notarial, pesquisar as
atas notariais, visualizar os dados das atas notariais e assim como o Requerente, baixar a assinatura
digital e a ata notarial gerada.
92
O gráfico da pergunta demonstrada na Figura 31 demonstra a visão por parte dos usuários da
possível utilidade que a aplicação Web iria ter se estivesse sendo fornecida como uma forma de
serviço. Conforme o gráfico apresenta, 50% dos usuários que responderam a pesquisa deram a nota
máxima (nota 5 numa escala de 1 até 5) neste quesito, o que mostra a sua possível aceitação, visto
que os usuários se agradaram da ideia.
A Figura 32 tentou demonstrar se os usuários acharam algum tipo de erro na aplicação,
porém ela não foi bem formulada, pois não foi especificado o tipo de erro para os usuários o que
pode ter ocasionado certa ambiguidade no momento da resposta. Porém ela mostra de uma forma
geral que não foram encontrados erros de execução, ou se foram encontrados, foram erros
considerados não impactantes.
A segunda parte da pesquisa foi direcionada para os cartórios. Foi selecionada uma lista de
cartório que realizam o procedimento de lavrar ata notarial e feito uma série de perguntas
relacionadas à aplicação utilizada, suas limitações e o interesse em estar utilizando uma aplicação
Web automatizada que realize a assinatura digital juntamente com o carimbo do tempo. O total de
cartórios que aceitaram participar do questionário foi de 7 (sete).
Figura 33: Pergunta 1
93
Figura 34: Pergunta 2
Figura 35: Pergunta 3
Figura 36: Pergunta 5
94
A primeira pergunta é referente ao volume de solicitações que um cartório recebe
diariamente e é demonstrada na Figura 33. A maioria (57% dos cartórios entrevistados) informou
que recebe uma grande quantidade de solicitações diárias para lavrar atas notariais.
Já na Figura 34 que apresenta o gráfico de respostas da pergunta 2, é possível verificar que
os cartórios ainda não dispõe de um fornecimento via Web deste serviço.
Na Figura 35, infelizmente a pergunta 3 não foi bem formulada, não deixando opção de uma
resposta mais abrangente e deixando uma impressão de completa insatisfação, porém verificando as
demais perguntas do questionários, foi possível concluir que a atual aplicação que os cartórios
utilizam atende a maioria dos casos, porém em certos momentos ela não atende o que ocasionava
perda de informações, retrabalho e as vezes uma ata notarial sem todas as informações desejadas
pelo Requerente, conforme é possível verificar na Figura 36.
Estes casos aconteciam quando a imagem possuía uma dimensão muito grande e a aplicação
não comportava a imagem. Outro caso de limitação de algumas das aplicações é com relação ao
tamanho que a imagem ocupava em disco, ou seja, imagens com o tamanho de 1 Mb (mega byte),
que não são aceitas, ou travam a aplicação, causando instabilidade e possível perda de dados.
Foi possível verificar ao final da análise dos dois questionários que existe um nicho de
mercado que pode ser explorado. É possível observar o interesse em uma aplicação que auxilie ao
usuário comum que deseja realizar um registro de uma ata notarial, da mesma forma que é possível
visualizar as limitações e possíveis melhorias nos serviços fornecidos pelos cartórios através de uma
aplicação Web que já não estaria sujeita as limitações fornecidas pelas atuais aplicações sendo
utilizadas pelos cartórios.
95
CONCLUSÃO
A utilização de uma aplicação Web em automatização de processos realizados por cartórios
ainda é muito pouco explorada no Brasil. Esse tipo de aplicação permite aos cartórios aumentar a
sua qualidade de serviço oferecido a população. Esta qualidade pode ser vista ou quantificada
através da maior quantidade de clientes atendidos em um menor espaço de tempo. Outra melhoria
está na otimização e melhor utilização do esforço e dos recursos humanos dos cartórios, como por
exemplo, um tabelião poderá gerar uma quantidade maior de atas notarias de maneira mais prática e
rápida através da aplicação.
Durante o período de desenvolvimento do trabalho proposto foram consolidados os
conhecimentos na área de protocolos de rede, segurança na Web e validação jurídica de documentos
digitais.
O objetivo principal deste trabalho foi desenvolver uma aplicação Web que permite um
requerente solicitar de maneira rápida e fácil uma ata notarial e que um tabelião também possa estar
lavrando de forma automatizada as solicitações de atas notariais de maneira segura e que estas atas
notariais geradas possuam validade jurídica para serem utilizadas de forma legal.
De forma a criar a aplicação proposta, foi necessário elencar e analisar quais evidências ou
provas que podem ser geradas e quais as informações relevantes que deverão ser incluídas para que
estas possam ser utilizadas em processos judiciais de crimes eletrônicos contra a honra e de
violação de direitos autorais. Este objetivo foi alcançado através da revisão bibliográfica de artigos,
trabalhos de conclusão de cursos e monografias que abordavam este assunto.
Neste trabalho foi realizada uma revisão bibliográfica sobre os conceitos correlacionados as
formas de se estar gerando e utilizando documentos digitais de forma legal através da utilização de
métodos e cálculos criptográficos. Foram abordadas estatísticas e tópicos sobre a Web e sua atual
utilização dentro do contexto desta pesquisa, a falta de suporte a vítimas que sofrem algum tipo de
crime na Internet, tecnologias para geração da aplicação Web, parametrização de assinatura digital e
carimbo do tempo e protocolo SSL.
A aplicação Web proposta utilizou um conjunto de tecnologias previamente estudadas,
analisadas e comparadas para prover o suporte necessário a todo o fluxo da ata notarial, que se
inicia na solicitação de uma ata notarial até a conclusão do processo através do ato do tabelião de
lavrar a ata notarial.
96
A implementação da aplicação Web foi desenvolvida na linguagem Java, já que esta
linguagem oferece um melhor desenvolvimento e suporte quando comparado a outras linguagens de
desenvolvimento Web como .Net ou PHP por exemplo.
Os fluxogramas elaborados, a descrição dos módulos e a documentação da implementação
da aplicação Web possibilitam que outros desenvolvedores reaproveitem a estrutura da aplicação
Web para adicionar mais funcionalidades e serviços voltados os oferecidos pelos cartórios. É
possível também integra-la em outras aplicações já existentes, já que todas as regras de negócios da
aplicação podem ser utilizadas através das interfaces que a aplicação fornece. Inclusive o
reaproveitamento deste trabalho já está sendo estudado pela empresa BRy Tecnologia, que possui a
intenção de fornecer serviços voltados aos cartórios utilizando esta aplicação Web.
Ainda com relação à integração da aplicação Web em outras aplicações, estes podem
aproveitar a implementação desenvolvida de maneira quase integral, devido à forma modularizada
de desenvolvimento da aplicação e também da documentação de código fornecida (através do
formato fornecido pela linguagem Java, o Javadoc).
A principal contribuição desta aplicação Web está relacionada ao social, ou seja, a vítima
(requerente), pois como demonstrado estatisticamente, o aumento de crimes ocorridos em meio
eletrônico está superando os crimes ditos tradicionais, desta forma, esta aplicação visa auxiliar as
vítimas e qualquer pessoa que queira estar registrando um conteúdo em meio eletrônico e que o
mesmo possua validade jurídica. A aplicação Web visa também uma maior comodidade ao
requerente que sem precisar do seu local, o mesmo pode solicitar ao cartório lavrar uma ata notarial
em qualquer lugar a qualquer momento, não dependendo de horário de funcionamento do cartório,
indisponibilidade futura das informações desejadas e sim da disponibilidade da aplicação Web.
Outra contribuição da aplicação Web desenvolvida é que a mesma irá proporcionar aos
tabeliães, além da automatização do procedimento de lavrar a ata notarial, a automatização do
processo de preenchimento dos dados de uma ata notarial com os dados pertinentes. Esta será
utilizada através da funcionalidade de cadastro de Template para ser utilizado no momento de lavrar
as atas notariais.
Por fim a avaliação Web desenvolvida foi submetida a testes unitários ou de software que
garantiram a qualidade do desenvolvimento e também foi possível constatar através dos testes de
segurança que a aplicação implementa os conceitos de segurança abordados na fundamentação
teórica.
97
Conclui-se desta forma que a aplicação Web proposta pode vir a tornar-se uma solução
voltada aos cartórios para auxiliar no gerenciamento de suas atas notarias. Este gerenciamento
inclui o armazenamento em meio digital, uma maior praticidade e agilidade tanto nas solicitações
quanto no processo de lavrar ata notarial, e a sua utilização de forma eletrônica em meio jurídico.
Outro quesito importante foi a pesquisa de aceitação dos usuários e também a pesquisa de
problemas atuais e interesse em estar adquirindo uma aplicação que facilite e agilize todo o
processo de lavrar uma ata notarial.
3.8 TRABALHOS FUTUROS
Como parte complementar da pesquisa, foi realizado uma pesquisa entre alguns cartórios e
verificado quais serviços não são disponíveis via Internet. Apesar de já existir projetos voltado ao
cartório digital denominados SaaS (Software as a Service), a sua utilização ainda não está sendo
realizada. Como exemplo de funcionalidades futuras que poderão ser implementadas ou integradas
à aplicação pode-se citar:
· Solicitação e automatização do processo de lavrar escrituras e procurações públicas: Visto
que o processo ou fluxo de lavrar documentos cartoriais são similares e utilizando-se da base já
implementada da aplicação Web, é viável incorporar esta funcionalidade à aplicação. É possível
utilizar as funcionalidades implementadas dos Templates para serem utilizados também para lavrar
escrituras e procurações públicas, não necessitando de nenhuma customização devido a alta coesão
e baixo acoplamento que a aplicação dispõe das suas funcionalidades.
· Registro de títulos e documentos: as regras levantadas para a geração de um documento
eletrônico e que este possa ser utilizado no âmbito jurídico são as mesmas regras que deverão ser
utilizadas nos registros de títulos e documentos. A diferença entre o processo que a aplicação faz e
este, é que a aplicação busca na Internet os dados e monta um documento digital de forma
automatizada. No caso de registro de títulos e documentos, se este estiver de forma não digital, será
necessária a conversão para um formato digital, para que subsequentemente este possa ser
carregado na aplicação e processado da maneira necessária para então atribuir toda a segurança que
é prevista para estes tipos de documento.
· Solicitações de registro de imóveis: seguindo a mesma ideia da reutilização das funcionalidades
implementadas nesta aplicação, é possível adicionar o serviço de solicitação de registro de imóveis.
Entre os serviços pesquisados, não se encontra uma forma de solicitação eletrônica do mesmo. Este
tipo de serviço poderá utilizar-se da funcionalidade de solicitações via Internet e do cadastro de
98
Templates. Os métodos utilizados para lavrar uma ata notarial podem ser reutilizados, não
necessitando de customização nos métodos.
· Emissão para pagamentos de protestos: atualmente os cartórios não dispõem de um serviço para
automatizar este processo, sendo ele completamente tradicional e manual, podendo ser comparado
ao processo de geração de uma ata notarial. Apesar de não necessitar de uma assinatura tão robusta
como a ADRT, um serviço voltado à emissão de protestos poderia ser integrado à aplicação, pois
poderia estar utilizando a sua estrutura de auto cadastramento e autenticação de usuários
(requerentes) bem como a funcionalidade de conversão de qualquer documento para arquivos no
formato PDF e download do pagamento.
99
REFERÊNCIAS BIBLIOGRÁFICAS
BRANDELLI, Leonardo. Ata Notarial. 1. Edição. Porto Alegre: Sergio Antonio Fabris Editor.
2004.
BUARQUE, Vitor Jerônimo. Padrão de Criptografia Simétrica – DES/AES. 1. Edição. Francisco
Beltrão, Grafisul, 2009.
Cartorio24horas. O que é Cartório 24 horas?. Disponível em
<http://www.cartorio24horas.com.br>. Acesso em: 10 jun. 2012.
CETIC.BR . Centro de Estudos sobre as Tecnologias da Informação e da Comunicação -
Pesquisa sobre o uso das Tecnologias de Informação e Comunicação no Brasil. Disponível em:
<http://op.ceptro.br/cgi-bin/indicadores-cgibr-2010?pais=brasil&estado=sc&academia=academia&
age=de-25-a-34-anos&education=pos-lato-sensu&purpose=pesquisa-academica>. Acesso em: 10
mar. 2012.
CETIC.BR . Centro de Estudos sobre as Tecnologias da Informação e da Comunicação -
Cartilha de Segurança para Internet. Disponível em: <http://cartilha.cert.br/download/cartilha-
01-conceitos.pdf>. Acesso em: 20 mar. 2012.
CHOUDHURY, Suranjan. Public Key Infrastructure Implementation and Design. Nova Iorque,
NY, M&T Books, 2002.
CNSEC - Central Notarial de Serviços Eletrônicos Compartilhados. 2007. 89f. Disponível em:
<http://projetos.inf.ufsc.br/arquivos_projetos/projeto_663/CNSEC.pdf>. Acesso em: 13 mar. 2012.
CORADINI, Evandro. O que falta na MP2200-2. Validade jurídica dos documentos digitais. São
Paulo, 2004. Disponível em: <http://www.iti.gov.br/twiki/pub/OLD/Forum/ArtigoD04/artigoD04-
coradini.rtf>. Acesso em: 31 mar. 2012.
DEL NERO, Patrícia Aurélia. Propriedade Intelectual. 2. edição. São Paulo: Revista dos
Tribunais, 2004
DUPRAT, Nathalia. Cyberbullying: uma triste violência da internet. REVISTA CAPRICHO. 2008.
Disponível em: <http://capricho.abril.com.br/voce/cyberbullying-triste-violencia-internet-
415968.shtml>. Acesso em: 10 jun. 2012.
FBI - Federal Bureal of Investigation. 2011. Disponível em:
<http://www.fbi.gov/news/stories/2011/may/forensics_05311>. Acesso em: 01 jun. 2012
HOUSLEY, Russ; POLK, Tim. Planning for PKI - Best practices guide for deploying
public key infrastructures. John Wiley and Sons, 2001.
100
IPIENS, José Antonio Escartin. El acta notarial de presencia en el proceso. In: Revista del
Notariado. 2004. nº 399, p. 176.
ITI. Instituto Nacional de Tecnologia da Informação. 2012. Disponível em:
<http://www.iti.gov.br/twiki/bin/view/Certificacao/EstruturaIcp>. Acesso em: 25 mar. 2012.
ITI-B. Instituto Nacional de Tecnologia da Informação. 2012. Disponível em: <Assinatura
Digital http://www.iti.gov.br/twiki/bin/view/Certificacao/>. Acesso em: 25 mar. 2012.
ITI. Instituto Nacional de Tecnologia da Informação – Carimbo do Tempo. 2011. 85f.
Disponível em: <http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-15.03.pdf>.
Acesso em: 27 mar. 2012.
ITI. Instituto Nacional de Tecnologia da Informação – Carimbo do Tempo. 2010. 15f.
Disponível em: <http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-11_-
_Versao_1.2.pdf>. Acesso em: 27 mar. 2012.
ITI Instituto Nacional de Tecnologia da Informação – Assinaturas Digitais na ICP-Brasil.
2007. 19f. Disponível em: <http://www.iti.gov.br/twiki/pub/Certificacao/DocIcp/DOC-ICP-15_-
_versao_1.0.pdf> Acesso em: 29 mar. 2012.
KUROSE, James F.; ROSS, Keith W. Redes de Computadores e a Internet. 3. edição. São Paulo:
Pearson Addison Wesley, 2006.
MALTA, Felipe Uriel Felipetto. Cartórios Online do Brasil. 1. Edição. Francisco Beltrão,
Grafisul, 2009.
MARTINA, J. E. Projeto de um Provedor de Serviços Criptográficos Embarcado para Infra-
estrutura de Chaves Publicas e suas Aplicações. Dissertação (Mestrado em Ciência da
Computação) - Universidade Federal de Santa Catarina, Santa Catarina, 2005.
MIGNONI, M. Eloisa. Políticas e Declaração de Práticas de Certificação Digital para UFSC.
Dissertação (Mestrado em Ciência da Computação) - Universidade Federal de Santa Catarina, Santa
Catarina, 2003.
MOECKE, Cristian Thiago. Assinatura digital de documentos eletrônicos. 2008. 103f.
Monografia (Bacharelado em Ciência da Computação). - Universidade Federal de Santa Catarina,
Santa Catarina, 2008.
NEVES, Michel Weiler. Crimes Eletrônicos: a responsabilidade do usuário. Jornal do Povo de
Três Lagoas. Três Lagoas, 10 jun. 2009. Disponível em:
<http://www.uol.com.br/fsp/opiniao/inde03112002.htm>. Acesso em: 31 mar. 2012.
NIST National Institute of Standards and Technology. 2012. 35f. Disponível em:
<http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf> Acesso em: 29 mar. 2012.
OLIVEIRA, Frederico Abrahão de. Crimes Contra a Honra. Porto Alegre: Livraria do Advogado,
2004.
101
OTTONI, Marcia Benedicto. Validade jurídica dos documentos digitais. 2003. 11f. I Fórum
sobre Segurança, Privacidade e Certificação Digital. Disponível em:
<www.iti.gov.br/twiki/pub/OLD/Forum/ArtigoD07/artigoD07-ottoni.rtf>. Acesso em: 14 mar.
2012.
PEREIRA, Evandro; FAGUNDES, Leonardo Lemes; NEUKAMP, Paulo; LUDWIG, Glauco;
KONRATH, Marlon. Forense Computacional: fundamentos, tecnologias e desafios atuais. VII
Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais. 2007. Disponível
em <http://www.dainf.ct.utfpr.edu.br/~maziero/lib/exe/fetch.php/ceseg:2007-sbseg-mc1.pdf>. Acesso em:
20 abr. 2012.
PÍCOLO, Guilherme Gouvêa. A Lei Azeredo e os crimes eletrônicos. 29/05/2012. 9f. Disponível
em < http://scsampaio.files.wordpress.com/2012/05/lei-azeredo.pdf> Acesso em: 31 mar. 2012.
PINHEIRO, Patricia Peck. Direito Digital. São Paulo: Saraiva, 2009.
PORTAL DO PLANALTO. 2001. Disponível em:
<http://www.planalto.gov.br/ccivil_03/mpv/Antigas_2001/2200-2.htm>. Acesso em: 14 jun. 2012.
PRODASER Informática e Comercio LTDA. Disponível em
<http://www.prodaser.com.br/>. Acesso em: 10 jun. 2012.
QUEIROZ, Ricardo Canguçu Barroso de. CALÚNIA , DIFAMAÇÃO E INJÚRIA –
DIFERENÇAS. 2000. Disponível em:
<http://www.advogado.adv.br/artigos/2000/barroso/caldifaminjuria.htm>. Acesso em: 31 maio
2012.
RFC 3161 - Request for Comments. 2001. 25f. Disponível em:
<http://www.ietf.org/rfc/rfc3161.txt> Acesso em: 10 maio 2012.
REIS, Marcelo Abdalla dos. Forense Computacional e sua aplicação em segurança
imunológica. Dissertação (Mestrado em Ciência da Computação) - Universidade Estadual de
Campinas, Campinas, 2003.
SANT’ANA, Mateus; ROVER, Aires J. Como proceder no caso de difamação na Internet. 2011.
Disponível em: <http://www.egov.ufsc.br/portal/sites/default/files/anexos/
29645-29661-1-PB.pdf>. Acesso em: 12 mar. 2012.
SCHNEIER, Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C. 2.
Edição. Minneapolis, John Wiley and Sons, 1996.
SCHÖNROCK, Khristian Alexander. Desenvolvimento de aplicações provedoras de serviços
criptográficos: carimbos de tempo e certificados otimizados. 2009. 107f. Monografia
(Bacharelado em Ciência da Computação) - Universidade Federal de Santa Catarina, Santa
Catarina, 2009. Disponível em: <http://projetos.inf.ufsc.br/arquivos_projetos/projeto_887/tcc-
khristian-final.pdf>. Acesso em: 02 maio 2012.
SERVCOM. Disponível em <http://www.servcom.com.br>. Acesso em: 10 maio 2012.
102
SOUSA, Evandro Araujo de. Software para Assinatura Digital. 2006. 137 f. Monografia
(Bacharelado em Ciência da Computação) - Universidade Federal de Santa Catarina, Santa
Catarina, 2006.
STALLINGS, William. Criptografia e segurança de redes. 4. edição. São Paulo: Pearson Prentice
Hall, 2008.
TANENBAUM, Andrew S. Redes de Computadores. 4. edição. Rio de Janeiro: Elsevier, 2003.
WIX. Acordo de Termos de Uso. Disponível em: <http://pt.wix.com/about/terms-of-use>. Acesso
em: 12 mar. 2012.
103
ANEXO I - MEDIDA PROVISÓRIA Nº 2200-2
Art. 1o Fica instituída a Infra-Estrutura de Chaves Públicas Brasileira - ICP-Brasil, para garantir a autenticidade,
a integridade e a validade jurídica de documentos em forma eletrônica, das aplicações de suporte e das aplicações habilitadas que utilizem certificados digitais, bem como a realização de transações eletrônicas seguras.
Art. 2o A ICP-Brasil, cuja organização será definida em regulamento, será composta por uma autoridade
gestora de políticas e pela cadeia de autoridades certificadoras composta pela Autoridade Certificadora Raiz - AC Raiz, pelas Autoridades Certificadoras - AC e pelas Autoridades de Registro - AR.
Art. 3o A função de autoridade gestora de políticas será exercida pelo Comitê Gestor da ICP-Brasil,
vinculado à Casa Civil da Presidência da República e composto por cinco representantes da sociedade civil,
integrantes de setores interessados, designados pelo Presidente da República, e um representante de cada um dos seguintes órgãos, indicados por seus titulares:
I - Ministério da Justiça;
II - Ministério da Fazenda;
III - Ministério do Desenvolvimento, Indústria e Comércio Exterior;
IV - Ministério do Planejamento, Orçamento e Gestão;
V - Ministério da Ciência e Tecnologia;
VI - Casa Civil da Presidência da República; e
VII - Gabinete de Segurança Institucional da Presidência da República.
§ 1o A coordenação do Comitê Gestor da ICP-Brasil será exercida pelo representante da Casa Civil da
Presidência da República.
§ 2o Os representantes da sociedade civil serão designados para períodos de dois anos, permitida a recondução.
§ 3o A participação no Comitê Gestor da ICP-Brasil é de relevante interesse público e não será remunerada.
§ 4o O Comitê Gestor da ICP-Brasil terá uma Secretaria-Executiva, na forma do regulamento.
Art. 4o Compete ao Comitê Gestor da ICP-Brasil:
I - adotar as medidas necessárias e coordenar a implantação e o funcionamento da ICP-Brasil;
II - 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 à ICP-Brasil, em todos os níveis da cadeia de certificação;
III - estabelecer a política de certificação e as regras operacionais da AC Raiz;
IV - homologar, auditar e fiscalizar a AC Raiz e os seus prestadores de serviço;
104
V - estabelecer diretrizes e normas técnicas para a formulação de políticas de certificados e regras operacionais das AC e das AR e definir níveis da cadeia de certificação;
VI - aprovar políticas de certificados, práticas de certificação e regras operacionais, credenciar e autorizar o funcionamento das AC e das AR, bem como autorizar a AC Raiz a emitir o correspondente certificado;
VII - identificar e avaliar as políticas de ICP externas, negociar e aprovar acordos de certificação bilateral,
de certificação cruzada, regras de interoperabilidade e outras formas de cooperação internacional, certificar,
quando for o caso, sua compatibilidade com a ICP-Brasil, observado o disposto em tratados, acordos ou atos internacionais; e
VIII - atualizar, ajustar e revisar os procedimentos e as práticas estabelecidas para a ICP-Brasil, garantir sua
compatibilidade e promover a atualização tecnológica do sistema e a sua conformidade com as políticas de segurança.
Parágrafo único. O Comitê Gestor poderá delegar atribuições à AC Raiz.
Art. 5o À AC Raiz, primeira autoridade da cadeia de certificação, executora das Políticas de Certificados e
normas técnicas e operacionais aprovadas pelo Comitê Gestor da ICP-Brasil, compete emitir, expedir, distribuir,
revogar e gerenciar os certificados das AC de nível imediatamente subseqüente ao seu, gerenciar a lista de
certificados emitidos, revogados e vencidos, e executar atividades de fiscalização e auditoria das AC e das AR e
dos prestadores de serviço habilitados na ICP, em conformidade com as diretrizes e normas técnicas estabelecidas
pelo Comitê Gestor da ICP-Brasil, e exercer outras atribuições que lhe forem cometidas pela autoridade gestora de políticas.
Parágrafo único. É vedado à AC Raiz emitir certificados para o usuário final.
Art. 6o Às 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.
Parágrafo único. O par de chaves criptográficas será gerado sempre pelo próprio titular e sua chave privada de assinatura será de seu exclusivo controle, uso e conhecimento.
Art. 7o Às AR, entidades operacionalmente vinculadas a determinada AC, compete identificar e cadastrar usuários na presença destes, encaminhar solicitações de certificados às AC e manter registros de suas operações.
Art. 8o Observados os critérios a serem estabelecidos pelo Comitê Gestor da ICP-Brasil, poderão ser credenciados como AC e AR os órgãos e as entidades públicos e as pessoas jurídicas de direito privado.
Art. 9o É vedado a qualquer AC certificar nível diverso do imediatamente subseqüente ao seu, exceto nos
casos de acordos de certificação lateral ou cruzada, previamente aprovados pelo Comitê Gestor da ICP-Brasil.
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.
§ 2o O disposto nesta Medida Provisória não obsta a utilização de outro meio de comprovação da autoria e
integridade de documentos em forma eletrônica, inclusive os que utilizem certificados não emitidos pela ICP-
Brasil, desde que admitido pelas partes como válido ou aceito pela pessoa a quem for oposto o documento.
Art. 11. A utilização de documento eletrônico para fins tributários atenderá, ainda, ao disposto no art. 100
da Lei no 5.172, de 25 de outubro de 1966 - Código Tributário Nacional.
105
Art. 12. Fica transformado em autarquia federal, vinculada ao Ministério da Ciência e Tecnologia, o Instituto Nacional de Tecnologia da Informação - ITI, com sede e foro no Distrito Federal.
Art. 13. O ITI é a Autoridade Certificadora Raiz da Infra-Estrutura de Chaves Públicas Brasileira.
Art. 14. No exercício de suas atribuições, o ITI desempenhará atividade de fiscalização, podendo ainda aplicar sanções e penalidades, na forma da lei.
Art. 15. Integrarão a estrutura básica do ITI uma Presidência, uma Diretoria de Tecnologia da Informação, uma Diretoria de Infra-Estrutura de Chaves Públicas e uma Procuradoria-Geral.
Parágrafo único. A Diretoria de Tecnologia da Informação poderá ser estabelecida na cidade de Campinas, no Estado de São Paulo.
Art. 16. Para a consecução dos seus objetivos, o ITI poderá, na forma da lei, contratar serviços de terceiros.
§ 1o O Diretor-Presidente do ITI poderá requisitar, para ter exercício exclusivo na Diretoria de Infra-
Estrutura de Chaves Públicas, por período não superior a um ano, servidores, civis ou militares, e empregados de
órgãos e entidades integrantes da Administração Pública Federal direta ou indireta, quaisquer que sejam as funções a serem exercidas.
§ 2o Aos requisitados nos termos deste artigo serão assegurados todos os direitos e vantagens a que façam
jus no órgão ou na entidade de origem, considerando-se o período de requisição para todos os efeitos da vida
funcional, como efetivo exercício no cargo, posto, graduação ou emprego que ocupe no órgão ou na entidade de
origem.
Art. 17. Fica o Poder Executivo autorizado a transferir para o ITI:
I - os acervos técnico e patrimonial, as obrigações e os direitos do Instituto Nacional de Tecnologia da
Informação do Ministério da Ciência e Tecnologia;
II - remanejar, transpor, transferir, ou utilizar, as dotações orçamentárias aprovadas na Lei Orçamentária de
2001, consignadas ao Ministério da Ciência e Tecnologia, referentes às atribuições do órgão ora transformado,
mantida a mesma classificação orçamentária, expressa por categoria de programação em seu menor nível,
observado o disposto no § 2o do art. 3o da Lei no 9.995, de 25 de julho de 2000, assim como o respectivo
detalhamento por esfera orçamentária, grupos de despesa, fontes de recursos, modalidades de aplicação e
identificadores de uso.
Art. 18. Enquanto não for implantada a sua Procuradoria Geral, o ITI será representado em juízo pela Advocacia Geral da União.
Art. 19. Ficam convalidados os atos praticados com base na Medida Provisória no 2.200-1, de 27 de julho de 2001.
Art. 20. Esta Medida Provisória entra em vigor na data de sua publicação.
106
ANEXO II - DECRETO-LEI 2.848, DE 7 DE DEZ. DE 1940
Lei nº 2.848, de 7 de dezembro de 1940 em seu artigo 138º Calúnia - Caluniar alguém, imputando-lhe falsamente
fato definido como crime:
Pena - detenção, de seis meses a dois anos, e multa.
§ 1º - Na mesma pena incorre quem, sabendo falsa a imputação, a propala ou divulga.
§ 2º - É punível a calúnia contra os mortos.
Exceção da verdade - § 3º - Admite-se a prova da verdade, salvo:
I - se, constituindo o fato imputado crime de ação privada, o ofendido não foi condenado por sentença
irrecorrível;
II - se o fato é imputado a qualquer das pessoas indicadas no nº I do art. 141;
III - se do crime imputado, embora de ação pública, o ofendido foi absolvido por sentença irrecorrível.
Lei nº 2.848, de 7 de dezembro de 1940 em seu artigo 139º -Difamação - Difamar alguém, imputando-lhe fato
ofensivo à sua reputação:
Pena - detenção, de três meses a um ano, e multa.
Exceção da verdade
Parágrafo único - A exceção da verdade somente se admite se o ofendido é funcionário público e a ofensa é
relativa ao exercício de suas funções.
Lei nº 2.848, de 7 de dezembro de 1940 em seu artigo 138º Art. 140 - Injúria - Injuriar alguém, ofendendo-lhe a
dignidade ou o decoro:
Pena - detenção, de um a seis meses, ou multa.
§ 1º - O juiz pode deixar de aplicar a pena:
I - quando o ofendido, de forma reprovável, provocou diretamente a injúria;
II - no caso de retorsão imediata, que consista em outra injúria.
§ 2º - Se a injúria consiste em violência ou vias de fato, que, por sua natureza ou pelo meio empregado, se
considerem aviltantes:
Pena - detenção, de três meses a um ano, e multa, além da pena correspondente à violência.
§ 3o Se a injúria consiste na utilização de elementos referentes a raça, cor, etnia, religião, origem ou a condição
de pessoa idosa ou portadora de deficiência: (Redação dada pela Lei 10741, de 2003)
Pena - reclusão de um a três anos e multa. (Incluído pela Lei 9459, de 1997)
Lei nº 2.848, de 7 de dezembro de 1940 em seu artigo 146º - Constrangimento ilegal - Constranger alguém,
mediante violência ou grave ameaça, ou depois de lhe haver reduzido, por qualquer outro meio, a capacidade de
resistência, a não fazer o que a lei permite, ou a fazer o que ela não manda:
Pena - detenção, de três meses a um ano, ou multa.
Aumento de pena
§ 1º - As penas aplicam-se cumulativamente e em dobro, quando, para a execução do crime, se reúnem mais de
três pessoas, ou há emprego de armas.
§ 2º - Além das penas cominadas, aplicam-se as correspondentes à violência.
§ 3º - Não se compreendem na disposição deste artigo:
I - a intervenção médica ou cirúrgica, sem o consentimento do paciente ou de seu representante legal, se
justificada por iminente perigo de vida;
II - a coação exercida para impedir suicídio.
Lei nº 2.848, de 7 de dezembro de 1940 em seu artigo 147º - Ameaça - Ameaçar alguém, por palavra, escrito ou
gesto, ou qualquer outro meio simbólico, de causar-lhe mal injusto e grave:
Pena - detenção, de um a seis meses, ou multa.
Parágrafo único - Somente se procede mediante representação.
Lei nº 2.848, de 7 de dezembro de 1940 em seu artigo 184º - Violação de direito autoral - Violar direitos de autor
e os que lhe são conexos: (Redação dada pela Lei nº 10.695, de 1º.7.2003)
Pena - detenção, de 3 (três) meses a 1 (um) ano, ou multa. (Redação dada pela Lei nº 10.695, de 1º.7.2003)
§ 1o Se a violação consistir em reprodução total ou parcial, com intuito de lucro direto ou indireto, por qualquer
meio ou processo, de obra intelectual, interpretação, execução ou fonograma, sem autorização expressa do autor,
do artista intérprete ou executante, do produtor, conforme o caso, ou de quem os represente: (Redação dada pela
Lei nº 10.695, de 1º.7.2003)
Pena - reclusão, de 2 (dois) a 4 (quatro) anos, e multa. (Redação dada pela Lei nº 10.695, de 1º.7.2003)
107
§ 2o Na mesma pena do § 1o incorre quem, com o intuito de lucro direto ou indireto, distribui, vende, expõe à
venda, aluga, introduz no País, adquire, oculta, tem em depósito, original ou cópia de obra intelectual ou
fonograma reproduzido com violação do direito de autor, do direito de artista intérprete ou executante ou do
direito do produtor de fonograma, ou, ainda, aluga original ou cópia de obra intelectual ou fonograma, sem a
expressa autorização dos titulares dos direitos ou de quem os represente. (Redação dada pela Lei nº 10.695, de
1º.7.2003)
§ 3o Se a violação consistir no oferecimento ao público, mediante cabo, fibra ótica, satélite, ondas ou qualquer
outro sistema que permita ao usuário realizar a seleção da obra ou produção para recebê-la em um tempo e lugar
previamente determinados por quem formula a demanda, com intuito de lucro, direto ou indireto, sem autorização
expressa, conforme o caso, do autor, do artista intérprete ou executante, do produtor de fonograma, ou de quem os
represente: (Redação dada pela Lei nº 10.695, de 1º.7.2003)
Pena - reclusão, de 2 (dois) a 4 (quatro) anos, e multa. (Incluído pela Lei nº 10.695, de 1º.7.2003)
§ 4o O disposto nos §§ 1o, 2o e 3o não se aplica quando se tratar de exceção ou limitação ao direito de autor ou
os que lhe são conexos, em conformidade com o previsto na Lei nº 9.610, de 19 de fevereiro de 1998, nem a
cópia de obra intelectual ou fonograma, em um só exemplar, para uso privado do copista, sem intuito de lucro
direto ou indireto. (Incluído pela Lei nº 10.695, de 1º.7.2003)
108
ANEXO III - CASOS DE TESTE
Neste anexo serão apresentados os casos de testes realizados para validar e avaliar a
aplicação Web. Os testes estão relacionados aos casos de uso da aplicação Web.
Número do Teste: 1
Caso de Uso/Fluxo: USC – 01: Cadastrar Usuário
Dados do teste:
Nome: Eduardo Cordeiro
Login: eduardo
Senha: 123456
Confirmação da senha: 123456
Sexo: Masculino
Data de Nascimento: 23/08/1986
CPF: 009.362.739-41
E-mail: [email protected]
Telefone: (48) 99219866
Profissão: Estudante
Endereço: Rua Lauro Linhares
CEP: 88036-200
Município: Florianópolis
Bairro: Trindade
Número: 114
Complemento: Casa
Ponto de referência: Restaurante Rolando Arroz
Passos:
1. O Requerente entra na página inicial da aplicação;
2. O Requerente clica em “Cadastro”;
3. O Requerente preenche todos os campos necessários conforme especificado nos dados de
teste e clica no botão ‘Salvar;
4. A aplicação solicita que o requerente confirme o seu cadastro através de um desafio
enviado por e-mail; e
5. Após a confirmação (resposta ao desafio), o requerente poderá se autenticar na aplicação.
Resultado esperado: uma mensagem na página será mostrada, avisando o sucesso da operação e
solicitando ao Requerente verificar o seu e-mail. Em seguida, a página inicial será apresentada ao
Requerente.
Status: aprovado.
109
Número do Teste: 2
Caso de Uso/Fluxo: USC – 02: Solicitar Ata Notarial
Dados do teste:
Login: Eduardo
Senha: 123456
Descrição dos fatos: A comunicação deve descrever os fatos relevantes ao caso, acontecidos e os
direitos afetados pela alegada violação aos direitos.
Endereço da página solicitada: http://forum.xda-developers.com/showthread.php?t=1931968
Passos:
1. O Requerente clica em “Solicita ata notarial”;
2. Requerente faz uma breve descrição do fato ocorrido e informa o endereço web onde se
encontra o conteúdo a ser registrado na ata notarial e clica em “Salvar”; e
3. A aplicação faz o download dos dados indicados pelo requerente para futura analise do
Tabelião.
Resultado esperado: O Requerente deverá ser redirecionado para a tela de listagem de solicitações
de suas atas notariais para acompanhar o fluxo através do status da mesma. Neste momento a
aplicação estará armazenando os dados obtidos através do endereço fornecido e posteriormente a
conclusão deste processo, o Tabelião responsável poderá estar averiguando a solicitação.
Resultado alternativo: O Requerente enviou um endereço Web não válido. Neste caso o
Requerente irá ser redirecionado para a tela de listagem de suas solicitações assim como acontece
no resultado esperado. Após a aplicação verificar que se trata de um endereço inválido, a aplicação
irá enviar um e-mail para o Requerente informando o endereço inválido e também irá alterar o
status da solicitação para “Cancelado”.
Status: aprovado.
110
Número do Teste: 3
Caso de Uso/Fluxo: USC – 03: Lavrar Ata Notarial
Dados do teste:
Login: Joao.machado
Senha: joao2012
Descrição dos fatos: ATO Nº 20121104. ATA NOTARIAL DE VERIFICAÇÃO.
Aos quatro dias do mês de outubro de 2012 da solicitação, mediante solicitação formal da Senhora
(Gabriela Zanin Camilo, com profissão estilista), a qual fica arquivada nestas Notas, às (2:55),
averiguei no endereço designado por (
http://forum.xda-developers.com/showthread.php?t=1931968), a fim verificar o estado da
comunicação do referido endereço. Analisando os dados, verifiquei que se trata de um crime que
fere a sua honra. Foi o que pude constatar. Nada mais tendo sido visto, ouvido ou percebido, lavro
a presente Ata Notarial, em conformidade com a solicitação do interessado, aos cinco dias do mês
de outubro de 2012. Eu, João Machado, lavrei, dou fé e assino.
Passos:
1. Tabelião clica em “Ata notarial” e seleciona o pedido mais antigo através do botão
“Lavrar Próxima Ata”;
2. Tabelião analisa a descrição do pedido, solicita os dados coletados na aplicação web
referente à solicitação através do botão “Baixar Dados”;
3. A aplicação retorna o conteúdo web coletado.;
4. O tabelião verifica se o conteúdo confere com a descrição feita pelo Requerente;
5. Tabelião redige a ata notarial de acordo com o conteúdo verificado (pode escolher um
Template);
6. Sistema exibe a ata notarial com a opção para assinar e carimbar a ata notarial (“Lavrar
Ata Notarial”); e
7. Aplicação acaba de concluir o processo de assinatura digital e carimbo do tempo sobre a
ata notarial.
Resultado esperado: O Tabelião deverá ser redirecionado para a tela de listagem de solicitações de
atas notariais. Neste momento a deverá alterar o status da ata notarial que o Tabelião acabou de
lavrar de “pendente” para “concluída”
Resultado alternativo: O Tabelião seguiu o fluxo acima, porém a Protocoladora (servidor
responsável pelo carimbo do tempo) está indisponível. A ata notarial irá continuar com o status
pendente e a aplicação irá enviar um e-mail para o administrador da aplicação.
Status: aprovado.
111
Número do Teste: 4
Caso de Uso/Fluxo: USC – 04: Obter Ata Notarial
Dados do teste:
Login: Joao.machado
Senha: joao2012
Pré-condição:
1. O ator estar autenticado na aplicação.
Passos:
1. Ator clica em “Ata notarial” e seleciona o status “concluído” e seleciona a ata notarial que
desejada visualizar.
2. Ator clica em “Baixar Ata Notarial”.
Resultado esperado: A aplicação deverá retornar na forma de “download” o arquivo contendo os
dados relevantes da ata notarial e os dados coletados de forma que remonte de forma legível a
página Web solicitada pelo Requerente.
Status: aprovado.
Número do Teste: 5
Caso de Uso/Fluxo: USC – 05: Cadastrar Tabelião
Dados do teste:
Dados Administrador:
Login: administrador
Senha: administrador
Dados Tabelião:
Nome: João Machado
Login: joao.machamdo
Senha: joao123
Confirmação da senha: joao123
Sexo: Masculino
Data de Nascimento: 23/11/1956
CPF: 481.774.669-68
E-mail: Joã[email protected]
Telefone: (48) 99224455
Endereço: Rua Lauro Linhares
CEP: 88036-003
Município: Florianópolis
112
Bairro: Trindade
Número: 2123
Complemento: Ed. Coimbra
Ponto de referência: -
Pré-condição:
1. O administrador estar autenticado na aplicação.
Passos:
1. Administrador clica em “Cadastrar Tabelião”.
2. A aplicação apresenta um formulário para preenchimento das informações de cadastro.
3. Administrador preenche os dados necessários para o cadastro do Tabelião conforme
tabela de dados acima.
4. Administrador clica em “Salvar” para finalizar o cadastro.
Resultado esperado: A aplicação solicita que o Tabelião confirme o seu cadastro através de um
desafio enviado para o seu email. Após a confirmação (resposta ao desafio), o Tabelião poderá se
autenticar na aplicação.
Status: aprovado.
Número do Teste: 6
Caso de Uso/Fluxo: USC – 06: Cadastrar ACT
Dados do teste:
Dados Administrador:
Login: administrador
Senha: administrador
Dados ACT:
Nome: pdde-teste.bry.com.br
DNS: pdde-teste.bry.com.br
Pré-condição:
1. O Administrador estar autenticado na aplicação.
Passos:
113
1. Administrador clica em “Cadastrar ACT”.
2. O Administrador preenche todos os campos necessários.
3. Administrador clica em “Cadastrar” para finalizar o cadastro.
Resultado esperado: A aplicação deverá apresentar o nome e o DNS da ACT cadastrada.
Status: aprovado.
114
ANEXO IV - TESTES UNITÁRIOS
Para garantir o funcionamento de todos os métodos implementados durante toda a fase de
desenvolvimento, foi utilizado duas ferramentas para realizar os testes unitários. O motivo da
utilização de testes unitários foi para aumentar a qualidade da aplicação desenvolvida, garantindo
que a cada novo método ou alteração de métodos da aplicação continuassem a retorar os dados
válidos que se espera que retornem, ou seja, que todos os outros métodos da aplicação não parem de
funcionar ou continuem íntegros.
Para a criação e configuração dos testes unitários utilizou-se a biblioteca de código-aberto da
organização JUnit. Foram sendo elencados durante o desenvolvimento os métodos de maior
importância para a aplicação e a partir deles foram criados os testes unitários para que
periodicamente a estes testes sejam executados.
A execução dos testes unitários pode ser feitos de duas maneiras, a primeira forma é manual,
onde o método é selecionado e explicitamente o desenvolvedor solicita que a aplicação execute o
caso de teste. Esta forma é utilizada somente na construção do caso de teste para verificar e validar
os resultados retornados.
A segunda maneira de executar os casos de teste é através do projeto de gestão de software
Maven. Este foi configurado para ser responsável pela construção, integração entre projetos,
versionamento de dependências e configurações da aplicação Web. Entre as suas configurações está
a configuração de execução dos testes unitários configurados.
Quando solicitado que construa a aplicação, o Maven busca pelos casos de testes unitários,
executa todos esses casos de teste e somente se todos os casos retornarem sucesso é que a aplicação
é construída e publicada no Container Web Tomcat.
Desta forma o desenvolvimento a longo prazo da aplicação acaba ganhando qualidade e
otimizando o tempo de desenvolvimento de um desenvolvedor, porque já existe uma garantia de
que todos os métodos configurados estão funcionando conforme o esperado.
Abaixo serão demonstrados alguns casos de testes unitários que foram desenvolvidos ao
longo do desenvolvimento.
115
@Test public void testSalvarUsuario() { usuario.setNome("Usuario teste JUnit"); usuario.setCpf("000000000"); usuario.setDataCadastro(new Date()); usuario.setDataNascimento(new Date()); usuario.setEmail("email"); usuario.setEndereco(new Endereco(null, "rua", "114", "", "88036200", "trindade", null, "Floripa")); usuario.setLogin("junit"); usuario.setProfissao("testador"); usuario.setSenha("123456"); usuario.setSexo(SexoEnum.MASCULINO); usuario.setStatus(Status.PENDENTE); usuario.setTelefone("2345678"); try { usuarioDAO.salvarUsuario(usuario); } catch (ExcecaoAtaNotarial e) { e.printStackTrace(); } assertNotNull(usuario.getId()); }
Teste unitário 1: Salvar Usuário
@Test public void testConfirmarCadastro() { try { testSalvarUsuario(); String hashGerado = usuario.getHashConfirmacao(); usuarioDAO.confirmarCadastro(hashGerado); } catch (ExcecaoAtaNotarial e) { assertNull(new Boolean(false)); e.printStackTrace(); } }
Teste unitário 2: Confirmar Cadastro Usuário
116
@Test public void testSalvarACT() { try { ACT act = new ACT(); act.setNome("ACT JUnit"); act.setDns("pdde-tete.bry.com.br"); act.setStatus(Status.ATIVO); Session session = HibernateUtil.getSessionFactory().openSession(); Transaction transaction = null; transaction = session.beginTransaction(); act = (ACT) session.merge(act); transaction.commit(); session.close(); assertNotNull(act.getId()); } catch (ConstraintViolationException e) { e.printStackTrace(); } catch (HibernateException e) { e.printStackTrace(); } }
Teste unitário 3: Salvar Autoridade de Carimbo do Tempo
@Test public void testAtualizarACT() { try { Session session = HibernateUtil.getSessionFactory().openSession(); Transaction transaction = null; transaction = session.beginTransaction(); ACT act = new ACT(); act.setNome("ACT JUnit"); act.setDns("teste"); act.setStatus(Status.ATIVO); act = (ACT) session.merge(act); assertNotNull(act.getId()); String dns = "pdde-tete.bry.com.br"; act.setDns(dns); act = (ACT) session.merge(act); if(!act.getDns().equals(dns)){ throw new Exception("Erro ao atualizar ACT"); } transaction.commit(); session.close(); assertNotNull(act.getId()); } catch (ConstraintViolationException e) { e.printStackTrace(); } catch (HibernateException e) { e.printStackTrace(); } catch (Exception e) { e.printStackTrace(); } }
Teste unitário 4: Atualizar ACT
117
@Test public void testRemoverACT() { IACTDAO dao = new ACTHibernateDAO(); Session session = HibernateUtil.getSessionFactory().openSession(); Transaction transaction = null; transaction = session.beginTransaction(); session.persist(act); transaction.commit(); session.close(); try { dao.removerACT(act.getId()); act = dao.findById(act.getId()); assertNull(act); } catch (ExcecaoAtaNotarial e) { e.printStackTrace(); } }
Teste unitário 5: Remover Autoridade de Carimbo do Tempo
@Test public void testIsExisteACTAtiva() { IACTDAO dao = new ACTHibernateDAO(); try { boolean ACTAtiva = dao.isExisteACTAtiva(); //assert true = conseguiu retornar o valor correto assertTrue(ACTAtiva == true || ACTAtiva==false); } catch (ExcecaoAtaNotarial e) { e.printStackTrace(); } }
Teste unitário 6: Verificar se existe ACT ativa na aplicação
118
@Test public void testSalvarAtaNotarial() { ataNotarial.setDataSolicitacao(new Date()); ataNotarial.setDescricaoRequerente("descrição requerente"); ataNotarial.setLinkEndereco("http://acidcow.com/pics/38234-prisons-in-south-america-45-pics.html"); Usuario u = new Usuario(); u.setLogin("requerente"); ataNotarial.setRequerente(u); ataNotarial.setStatus(Status.PROCESSANDO); ParserHTML parserHTML = new ParserHTML(); parserHTML.setIdAtaNotarial(ataNotarial.getId()); parserHTML.setUrlstring(ataNotarial.getLinkEndereco()); parserHTML.start(); try { dao.salvarAtaNotarial(ataNotarial); assertNotNull(ataNotarial.getId()); File arquivoPDF = parserHTML.getArquivoPdfSaida(); if (arquivoPDF.exists()) { assertTrue(arquivoPDF.exists()); } assertTrue(arquivoPDF.exists()); } catch (ExcecaoAtaNotarial e) { e.printStackTrace(); } }
Teste unitário 7: Salvar Ata Notarial
@Test public void testGetListaAtaNotarialPorRequerente() { try {
List<AtaNotarial> lista = dao.getListaAtaNotarialPorRequerente("requerente");
assertTrue(lista.size() > 0); } catch (ExcecaoAtaNotarial e) { e.printStackTrace(); } }
Teste unitário 8: Retorno da listagem de ata notarial por login de Requerente
119
@Test public void testGetAtaNotarialPorId() { try { AtaNotarial ata = dao.getAtaNotarialPorId(1l); assertNotNull(ata); } catch (ExcecaoAtaNotarial e) { e.printStackTrace(); } }
Teste unitário 9: Retorno de ata notarial por identificador
@Test public void testAtualizarAtaNotarial() { try { AtaNotarial ata = dao.getAtaNotarialPorId(1l); String novaDesc = "nova descrição"; ata.setDescricaoRequerente(novaDesc); dao.atualizar(ata); ata = dao.getAtaNotarialPorId(1l); assertEquals(novaDesc, ata.getDescricaoRequerente()); } catch (ExcecaoAtaNotarial e) { e.printStackTrace(); } }
Teste unitário 10: Atualização de ata notarial
@Test public void testRemover() { ataNotarial.setDataSolicitacao(new Date()); ataNotarial.setDescricaoRequerente("descrição requerente");
ataNotarial.setLinkEndereco("http://acidcow.com/pics/38234-prisons-in-south-america-45-pics.html");
Usuario u = new Usuario(); u.setLogin("requerente"); ataNotarial.setRequerente(u); ataNotarial.setStatus(Status.PROCESSANDO); try { dao.salvarAtaNotarial(ataNotarial); Long id = ataNotarial.getId(); dao.remover(id); ataNotarial = dao.getAtaNotarialPorId(id); assertNull(ataNotarial); } catch (ExcecaoAtaNotarial e) { e.printStackTrace(); } }
Teste unitário 11: Remoção de ata notarial por identificador
120
@Test public void testGetTodosTemplatesAtivos() { List lista = dao.findAll("titulo"); assertTrue(lista.size()>0); }
Teste unitário 12: Retorno da listagem de templates ativos na aplicação
@Test public void testSalvarTemplate() { templateAtaNotarial.setCorpo("Corpo do template"); templateAtaNotarial.setDataCadastro(new Date()); templateAtaNotarial.setStatus(Status.ATIVO); templateAtaNotarial.setTitulo("Título do template"); IUsuarioDAO uDao = FabricaDAO.getUsuarioDAO(); Usuario usuario = uDao.findByLogin("tabeliao"); templateAtaNotarial.setUsuarioCadastrador(usuario); try { dao.salvarTemplate(templateAtaNotarial); assertNotNull(templateAtaNotarial.getId()); } catch (ExcecaoAtaNotarial e) { e.printStackTrace(); } }
Teste unitário 13: Salvar template
@Test public void testGetTemplateById() { templateAtaNotarial.setCorpo("Corpo do template"); templateAtaNotarial.setDataCadastro(new Date()); templateAtaNotarial.setStatus(Status.ATIVO); templateAtaNotarial.setTitulo("Título do template"); IUsuarioDAO uDao = FabricaDAO.getUsuarioDAO(); Usuario usuario = uDao.findByLogin("tabeliao"); templateAtaNotarial.setUsuarioCadastrador(usuario); try { dao.salvarTemplate(templateAtaNotarial); templateAtaNotarial = dao.getById(templateAtaNotarial.getId()); assertNotNull(templateAtaNotarial); } catch (ExcecaoAtaNotarial e) { e.printStackTrace(); } }
Teste unitário 14: Retorno do template por identificador
121
ANEXO V - CONTRATO DE LICENÇA
Top Related