TCC II Eduardo Jorge dos Santos Cordeiro

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.

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).

http://www.iti.gov.br/twiki/bin/view/Certificacao/WebHome

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

http://www.iti.gov.br/twiki/bin/view/Certificacao/WebHome

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


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.


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.


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


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”.



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.


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.


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.

http://pt.wikipedia.org/wiki/JavaScript

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

http://pt.wikipedia.org/wiki/Ethernet

http://pt.wikipedia.org/wiki/Wireless

http://pt.wikipedia.org/wiki/Software

http://pt.wikipedia.org/wiki/Log_de_dados

http://pt.wikipedia.org/wiki/Pacote

http://pt.wikipedia.org/wiki/Criptografia

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



91



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).


93




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.

http://www.iti.gov.br/twiki/bin/view/Certificacao/

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.

http://pt.wikipedia.org/wiki/Request_for_Comments

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)

http://www.leidireto.com.br/lei-10741.html

http://www.leidireto.com.br/lei-9459.html

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

TCC II Eduardo Jorge dos Santos Cordeiro

Documents

Transcript of TCC II Eduardo Jorge dos Santos Cordeiro