Autoridade de Aviso

UNIVERSIDADE FEDERAL DE SANTA CATARINA

CURSO DE GRADUAC

¸ ˜

AO EM SISTEMAS DE INFORMAC

¸ ˜

AO

Eduardo Bruno Hadlich

Leandro Amˆancio

Autoridade de Aviso

Trabalho de Conclus˜ao de Curso

Ricardo Felipe Cust´odio

Autoridade de Aviso

Eduardo Bruno Hadlich

Leandro Amˆancio

Este Trabalho de Conclus˜ao de Curso foi aprovado em sua forma final pelo Curso de Sistemas de

Informac¸˜ao da Universidade Federal de Santa Catarina.

Ricardo Felipe Cust´odio

Olinto Varela Furtado

Banca Examinadora

Daniel Santana de Freitas

iii

Oferecemos este trabalho a nossos pais, parentes, amigos e

sem d´uvida aos colegas de faculdade, principalmente os

que lutaram bravamente durante todo o curso e formaram,

junto conosco, a primeira turma de Sistemas de

Informac¸˜ao da Universidade Federal de Santa Catarina.

Agradecimentos

Aos nossos pais, que apostaram em nosso potencial durante toda a faculdade, sempre nos

dando apoio, n˜ao importanto qu˜ao dif´ıceis eram as situac¸˜oes por que passamos.

Aos amigos, que por mais que tenham participado de todo processo, ou n˜ao, s˜ao parte da

base necess´aria para seguirmos sempre a buscar nossos objetivos.

Aos colegas de curso, cujo trabalho foi honradamente oferecido, pois apenas os que

passa-ram por este caminho sabem das dificuldades encontradas, os obst´aculos mais diversos, `as vezes

lutando praticamente contra todos, para finalizar de forma her´oica este curso. Todos n´os sabemos

o quanto fomos importantes.

Resumo

Com o advento dos sistemas digitais, a Internet, e toda a atual dependˆencia tecnol´ogica que

tornou-se necess´aria, ´e normal da natureza humana que problemas de cunho duvidoso surjam nas

comunicac¸˜oes online, assim como surjem na vida real.

Quando deseja-se enviar uma mensagem qualquer (e-mail, documentos digitais ou

ima-gens, por exemplo) para um determinado destino, al´em dos problemas normais, como problemas

de conex˜ao, servidores fora do ar e demais, existe uma outra classe de problemas, obviamente mais

complicados de resolver. S˜ao problemas de confianc¸a entre as partes, ou de cunho duvidoso, onde

uma das partes pode atuar de forma mal-intencionada no processo. Supondo que na transmiss˜ao

de uma mensagem de Alice para Bob, Bob pode ter recebido a mensagem, n˜ao ter gostado do seu

conte´udo e afirmar para Alice que ele n˜ao recebeu tal mensagem, por exemplo. Alice, por sua vez,

pode nem sequer ter enviado uma mensagem para Bob mas ter dito que o fez, reclamando uma

atitude por parte de Bob.

Estes problemas s˜ao ditos problemas de rep´udio, onde, com base em evidˆencias emitidas,

todas as partes envolvidas no processo n˜ao podem negar que participaram dele. O uso de uma

ferramenta que implemente o n˜ao rep´udio tende a ser a soluc¸˜ao para resolver tais problemas, e neste

trabalho propomos e desenvolvemos uma ferramenta de n˜ao rep´udio, baseada numa terceira parte

confi´avel, que atuar´a ativamente no processo, ajudando a emitir tais evidˆencias, indispens´aveis

para a resoluc¸˜ao dos conflitos que possam surgir.

Abstract

With the arrival of digital systems, the Internet, and the technologic dependency that

be-came necessary, it is normal from the human nature that doubt problems happen on the online

communications, as they do on real life.

When you wish to send any message (e-mail, digital documents or images, i.e.) to a given

destination, along with the regular problems, as connection problems, servers offline and some

other, there is another class os problems, obviously more complicated to solve. They are trust

problems between the parts, or doubt problems, where one of the parts can actuate without fairness

in the process. Supposing that in the transmission of a message from Alice to Bob, Bob may have

received the message, didn´t like of the contents and tell Alice that he didnt receive the message,

as example. Alice, by the way, may didnt even send the message to Bob but said she did, asking

for a reaction from Bob.

Those problems are labeled as repudiation problems, where, based on generated evidences,

all parts involved in the process can´t deny that they did. The use of a tool that implements

non-repudiation seems to be the solution to solve this problems, and in this paper we propose and

implementat an non-repudiation tool, based on a trusted third party, that will act actively in the

process, helping to provide the evidences, necessary to the resolution of the conflitcs that may

arrive.

Sum´ario

Resumo

v

Abstract

vi

Sum´ario

1

Lista de Figuras

3

Lista de Siglas

5

1

Introduc¸˜ao

6

1.1

Conceitos . . . .

8

2

Objetivos e Motivac¸˜ao

11

3

Metodologia utilizada

13

3.1

Pesquisa . . . 14

3.2

An´alise . . . 15

3.3

Projeto . . . 15

3.4

Implementac¸˜ao . . . 15

3.5

Testes . . . 16

4

Caracterizac¸˜ao do Problema

17

5

Protocolos Existentes

20

6

Aspectos Jur´ıdicos

23

7

Protocolo Adotado

25

7.1

Protocolo proposto . . . 25

2

8

Aspectos t´ecnicos

28

9

Sistema de Autoridade de Aviso

31

9.1

Implementac¸˜oes . . . 31

9.2

Funcionamento Interno . . . 33

9.2.1

Tratamento de excec¸˜oes . . . 36

9.2.2

Observac¸˜oes Gerais . . . 36

9.3

Divis˜ao da Aplicac¸˜ao . . . 37

9.3.1

Aplicac¸˜ao Receptora . . . 37

9.3.2

Aplicac¸˜ao Web . . . 38

9.4

Utilizac¸˜ao . . . 39

9.4.1

Enviando Mensagens . . . 39

9.4.2

Recebendo Mensagens . . . 40

9.5

Observac¸˜oes sobre a seguranc¸a do Sistema . . . 44

9.5.1

NRS - N˜ao Rep´udio da Submiss˜ao . . . 44

9.5.2

NRO - N˜ao rep´udio da Origem . . . 45

9.5.3

NRR - N˜ao Rep´udio do Recebimento . . . 45

9.6

Conclus˜oes sobre a Implementac¸˜ao . . . 46

10 Conclus˜oes e Perspectivas futuras

47

Referˆencias Bibliogr´aficas

49

Apˆendice A - C´odigo-fonte

50

Lista de Figuras

9.1

Exemplo de e-mail . . . 40

9.2

E-mail de Aviso . . . 41

9.3

Lista de Certificados Digitais do Cliente . . . 42

9.4

Permiss˜ao para acessar Certificado Digital . . . 42

9.5

Permiss˜ao para usar Chave privada . . . 43

5

Lista de Siglas

AC

Autoridade Certificadora

API

Application Program Interface

B2B

Business-to-Business

DLL

Dynamic Load Library

FTP

File Transfer Protocol

ICP

Infra-estrutura de Chaves P´ublicas

IMAP

Internet Message Access Protocol

ISO

International Organization for Standardization

JCE

Java Criptography Extension

JDK

Java Development Kit

JSP

JavaScript Pages

MP

Medida Provis´oria

NRD

N˜ao rep´udio do Envio

NRO

N˜ao rep´udio da Origem

NRR

N˜ao rep´udio do Recebimento

NRS

N˜ao rep´udio da Submiss˜ao

OO

Orientac¸˜ao a Objetos

PDDE

Protocoladora Digital de Documentos Eletrˆonicos

KPCS

Public Key Certificate Signature

POP

Post Office Provider

SFTP

Secure File Transfer Protocol

SMTP

Simple Mail Transfer Protocol

SSH

Secure SHell

SSL

Secure Socket Layer

TCC

Trabalho de Conclus˜ao de Curso

TTP

trusted Third Party

UFSC

Universidade Federal de Santa Catarina

UML

Unified Modeling Language

Cap´ıtulo 1

Introduc¸˜ao

No mundo do papel, existem diversas maneiras para se conseguir evidˆencias na transmiss˜ao

de documentos. A forma mais simples deve ser a carta registrada, servic¸o provido pelos Correios

do Brasil. A carta registrada tem um funcionamento simples: a origem, ou remetente, dirige-se

at´e uma agˆencia do correio, preenche os dados necess´arios para enviar sua carta e sai da agˆencia

portando um recibo que prova que ele pelo menos tentou enviar tal carta. Os Correios fazem todo

seu procedimento interno para fazer a carta chegar at´e a agˆencia mais pr´oxima do destino, e quando

esta chega um aviso ´e emitido informando-o que ele deve ir at´e a agˆencia para retirar sua carta.

Caso o destino queira recebˆe-la, obviamente ele deve ir at´e a agˆencia, assinar um recibo que prova

que ele realmente tomou posse da carta e o processo se finaliza.

Do ponto de vista comercial, diversos acontecimentos podem gerar disputa entre as partes

em uma transmiss˜ao de documentos. Alguns deles podem ser causados por algu´em mal

inten-cionado ou simplesmente por problemas no meio. Podemos citar v´arios, mas de acordo com

[ZHO 96b], documentos forjados, diferenc¸as na hora da postagem de um documento, documentos

modificados acidentalmente ou de forma fraudulenta dentro de uma organizac¸˜ao ou enquanto em

trˆansito entre organizac¸˜oes, e documentos perdidos ou atrasados durante o processo de envio s˜ao

os mais comuns. ”Em cada uma destas situac¸˜oes, duas possibilidades distintas podem ser

identi-ficadas. O documento pode ser genu´ıno ou uma c´opia; ele pode ter sido enviado ou n˜ao; ele pode

ter chegado ao destino ou n˜ao; ele pode ter sido entregue dentro de um prazo ou n˜ao; dentre

ou-tros. Sempre que n˜ao conseguimos distinguir entre uma possibilidade ou outra, alguma das partes

envolvidas no processo pode negar alguma coisa”, como:

- negar a autoria de um documento;

7

- negar que recebeu um documento; ou

- negar que enviou ou recebeu um documento numa data e hora espec´ıficos.

Para uma entidade `a parte, um juiz, fica extremamente f´acil resolver quaisquer disputas

que possam ocorrer entre a origem e o destino, desde que eles guardem as evidˆencias (recibos)

do procedimento. Nosso trabalho visa fazer uma analogia dos procedimentos dos Correios, s´o

que no mundo dos documentos digitais. Faremos uso de assinaturas digitais, marcas de tempo

(timestamps) e outros recursos para implementar tal servic¸o. A base deste estudo ´e o n˜ao rep´udio.

Podemos conceituar n˜ao rep´udio como o fato de que se A e B trocam mensagens, ambas

as partes n˜ao podem dizer que n˜ao participaram desta comunicac¸˜ao.

[KRE 02] nos diz que, com a explos˜ao da internet, a utilizac¸˜ao de transac¸˜oes por meio

eletrˆonico ´e cada vez mai comum. Quest˜oes como confidencialidade, autenticac¸˜ao, controle de

acesso e outras tˆem recebido alto grau de estudos e discuss˜oes h´a muito tempo, enquanto o n˜ao

rep´udio tem recebido a devida atenc¸˜ao apenas mais recentemente. Tal fato pode ser encarado como

motivac¸˜ao para desenvolver trabalhos nesta ´area, visto que os estudos ainda s˜ao em sua maioria

te´oricos, e a discuss˜ao na comunidade cient´ıfica ainda n˜ao ´e t˜ao intensa como em outros assuntos.

Tomando por base os protocolos sugeridos por diversos autores, visamos, ao final deste

tra-balho, implementar um sistema baseado em correio eletrˆonico e assinaturas digitais, que fornec¸a

todas as evidˆencias necess´arias para funcionar como uma Autoridade de Aviso (Delivery

Autho-rity). O trabalho usa e desenvolve conceitos de seguranc¸a em computac¸˜ao, mais precisamente o

conceito de n˜ao rep´udio. O desenvolvimento envolve outros temas, como criptografia sim´etrica e

assim´etrica, assinaturas e certificados digitais, dentre outros.

Foram pesquisadas e analisadas diversas sugest˜oes de protocolos, e adaptac¸˜ao dos mesmos

`a realidade da UFSC. O trabalho desenvolvido usa tamb´em outra soluc¸˜ao implementada no

labo-rat´orio de seguranc¸a em computac¸˜ao da universidade (LabSEC): a PDDE (Protocoladora Digital

de Documentos Eletrˆonicos), que ´e uma entidade que fornece um recibo com carimbo de data

oficial, respaldada pelo Observat´orio Nacional, ´org˜ao do governo que controla a hora oficial do

Brasil. Esta soluc¸˜ao nos ajuda a prover as evidˆencias de tempo necess´arias para o processo de n˜ao

rep´udio.

Este ´e um projeto te´orico-pr´atico, onde a parte te´orica fornece subs´ıdios suficientes para a

execuc¸˜ao da parte pr´atica. A parte pr´atica est´a mais relacionada ao objetivo geral do projeto de

implementac¸˜ao de um sistema Autoridade de Aviso capaz de garantir o n˜ao rep´udio.

8

objetivos do trabalho, a motivac¸˜ao para o mesmo e as metodologias utilizadas no desenvolvimento.

A parte te´orica ´e apresentada de forma discursiva e inicia-se com a caracterizac¸˜ao dos problemas

que os sistemas atuais enfrentam para garantir o n˜ao rep´udio, no cap´ıtulo 4. Dando sequencia, no

cap´ıtulo 5, ´e feito um estudo sobre os tipos de protocolos existentes que fornecem o n˜ao rep´udio.

A seguir s˜ao explanados aspectos jur´ıdicos que envolvem as assinaturas digitais e as evidˆencias de

n˜ao-rep´udio, no cap´ıtulo 6. No cap´ıtulo 7, ´e feita uma descric¸˜ao mais aprofundada do protocolo

escolhido e implementado. O cap´ıtulo 8 procura explicar o ambiente em que o sistema deve operar,

escolha da linguagem de programac¸˜ao e outros aspectos t´ecnicos. E por fim, no cap´ıtulo 9, ser˜ao

descritos a implementac¸˜ao do sistema e, encerrando com o cap´ıtulo 10, os objetivos que foram

alcanc¸ados com a mesma, conclus˜oes e perspectivas.

1.1

Conceitos

Antes de dar prosseguimento, algumas definic¸˜oes e termos devem ser demonstrados com

maior clareza, pois os mesmos s˜ao indispens´aveis para o entendimento do trabalho como um todo:

Integridade dos dados: tem como objetivo garantir que um conjunto de dados n˜ao foi

alterado em seu caminho;

Autenticidade: visa garantir que uma determinada mensagem foi emitida por uma

deter-minada origem e n˜ao sofreu qualquer tipo de alterac¸˜ao em seu conte´udo durante o trˆansito da

mesma;

Confidencialidade: tem como objetivo garantir o segredo de uma mensagem;

Criptografia Assim´etrica: utiliza o conceito de par de chaves (chave p´ublica e chave

privada) para certificar que, quando uma pessoa criptografa um documento com sua chave privada,

o mesmo s´o pode ser descriptografado com sua respectiva chave p´ublica. Este mesmo sistema

possibilita a assinatura digital de mensagens, ou seja, quando o usu´ario utiliza sua chave privada

para criptografar ou assinar um documento, ele est´a assumindo que foi ele quem confeccionou tal

documento. Isso assegura que o documento n˜ao sofreu qualquer tipo de violac¸˜ao entre origem e

destino e conseq¨uentemente assegura a procedˆencia do documento: seu emissor;

Criptografia sim´etrica: ´e o modo mais utilizado de criptografia, e utiliza uma ´unica chave

compartilhada pelas entidades participantes. Neste caso, as mensagens s˜ao criptografadas e

des-critografadas utilizando a mesma chave;

9

caracter´ıstica receber como entrada um arquivo de qualquer tamanho e produzir, a partir de todos

os bytes deste arquivo, um sa´ıda ´unica. Para que uma func¸˜ao resumo ou hash seja considerada

”boa”, deve ser computacionalmente invi´avel achar outro arquivo que resulte no mesmo resumo, e

tamb´em invi´avel chegar ao arquivo original a partir do seu resumo;

Assinatura digital: prop˜oe uma analogia com assinaturas manuais, devendo ter algumas

propriedades, como a possibilidade de se verificar o autor, data e hora da assinatura, ter condic¸˜oes

de ser analisada para resolver disputas, inviabilidade computacional de se forjar uma assinatura,

possibilidade de armazenamento, dentre outras;

Autoridade de Aviso: terceira parte confi´avel, que atua no processo de transmiss˜ao das

mensagens de A para B. O objetivo principal deste trabalho ´e implementar uma Autoridade de

Aviso, e estabelecer regras e condic¸˜oes para sua utilizac¸˜ao. Ela ´e respons´avel por gerar algumas

das evidˆencias necess´arias e garantir que nenhuma das partes saia favorecida do processo de

trans-miss˜ao;

Terceira parte confi´avel - TTP: TTP ´e a sigla em inglˆes para “Trusted Third Party”, ou

simplesmente terceiro confi´avel em portuguˆes. A Autoridade de Aviso que implementamos neste

trabalho nada mais ´e do que uma TTP. Segundo definic¸˜ao da ISO, a TTP ´e uma autoridade de

seguranc¸a, ou seu agente, confi´avel por entidades no que diz respeito a atividades que envolvem

seguranc¸a em computac¸˜ao;

Protocoladora Digital de Documentos Eletrˆonicos - PDDE: a PDDE fornece um recibo

com carimbo de data oficial, respaladada pelo Observat´orio Nacional, ´org˜ao do governo que

con-trola a hora oficial do Brasil. Tal recibo tem seu formato definido atrav´es de norma ISO, e deve

garantir diversas pr´e-condic¸˜oes, que est˜ao fora do escopo deste trabalho;

Carimbo: termo que diz respeito ao ato da PDDE de receber um documento e emitir um

recibo baseado naquele documento, o termo Carimbo ´e usado pela sua analogia com um Carimbo

de recebimento de documentos por um ´org˜ao ou organizac¸˜ao;

Recepc¸˜ao seletiva: define que um destino de uma mensagem pode optar por receber ou

n˜ao a mensagem, analisando-a de alguma forma antes de tomar esta decis˜ao;

N˜ao rep ´udio: prevˆe que as partes envolvidas em um troca de mensagens, Origem e

Des-tino, n˜ao possam negar a ocorrˆencia de uma ac¸˜ao previamente realizada por uma das partes;

N˜ao rep ´udio da Origem - NRO: evidˆencia gerada por uma Autoridade de Aviso (ou

du-rante uma troca de mensagens com n˜ao rep´udio) que prova o fato de que uma Origem A enviou

uma determinada mensagem M num dado momento para um dado destino B, e protege contra a

situac¸˜ao em que a origem nega que tenha enviado uma determinada mensagem;

10

N˜ao rep ´udio do Recebimento - NRR: evidˆencia gerada por uma Autoridade de Aviso (ou

durante uma troca de mensagens com n˜ao rep´udio) que prova o fato de que um destino B recebeu,

num dado momento, uma determinada mensagem M enviada por A, e protege contra a situac¸˜ao

em que o destino afirma n˜ao ter recebido uma mensagem;

N˜ao rep ´udio da Submiss˜ao - NRS: evidˆencia gerada por uma Autoridade de Aviso (ou

durante uma troca de mensagens com n˜ao rep´udio) que prova o fato de que uma origem A ao

menos tentou enviar uma mensagem M, num determinado momento, para o destino B;

N˜ao rep ´udio do Envio - NRD: serve como evidˆencia para provar que a TTP enviou uma

determinada mensagem enderec¸ada para o destino B;

Infra-estrutura de Chaves P ´ublicas - ICP: organizac¸˜ao em n´ıveis hier´arquicos que define

os relacionamentos de confianc¸a entre as entidades que fazem parte da infra-estrutura, e tem como

objetivo fornecer certificados digitais para seus usu´arios;

Autoridade Certificadora - AC: emite, gerencia e revoga certificados digitais para uma

comunidade de usu´arios. Cada certificado ´e assinado digitalmente com a chave privada da AC, e

tamb´em cont´em outras informac¸˜oes, como n´umeros de identificac¸˜ao e a chave p´ublica do usu´ario.

Tais chaves p´ublicas s˜ao armazenadas em reposit´orios p´ublicos e abertos, pois o conhecimento

de seus dados ´e livre a quem interessar. Utilizando os servic¸os de uma AC, uma ICP fornece os

certificados e pares de chave a usu´arios.

Cap´ıtulo 2

Objetivos e Motivac¸˜ao

Nosso objetivo com este trabalho resume-se em implementar um sistema que, aplicado a

problemas da vida real, tende a ser de grande utilidade nas trocas de informac¸˜oes atrav´es da via

digital. A gama de situac¸˜oes de troca de documentos que a soluc¸˜ao se aplica, como contratos,

leil˜oes, licitac¸˜oes, ordens de compra e venda e notificac¸˜oes, provˆe um mercado-alvo gigantesco.

Praticamente todas as pessoas jur´ıdicas utilizam a id´eia do n˜ao rep´udio, mesmo sem terem

conhecimento de que o est˜ao fazendo. Trazer estas situac¸˜oes, bem como uma soluc¸˜ao que n˜ao deixe

d´uvidas em problemas que por ventura possam ocorrer, para o meio eletrˆonico, ´e uma justificativa

mais do que plaus´ıvel para pesquisa e desenvolvimento de soluc¸˜oes nesta ´area. Vamos usar o

exemplo das licitac¸˜oes: suponhamos que o prazo de entrega dos envelopes para participac¸˜ao se

esgota `as 23:59:59 de um determinado dia. Uma empresa que deseja participar do processo teve

problemas para confecc¸˜ao da proposta e a terminou praticamente em cima do prazo, `as 23:50

daquele dia. Certa de que ainda tem tempo, envia um e-mail para o licitante `as 23:55 mas, por

problemas no roteador da rede, o e-mail chegou na caixa de entrada do licitante apenas `as 00:05 do

dia seguinte, o que o forc¸ou a retirar a empresa da licitac¸˜ao. Este problema ´e mais comum do que

parece, e pode ser resolvido (na verdade ele nem iria acontecer) com o uso de uma Autoridade de

Aviso, que poderia provar atrav´es de evidˆencias que a empresa que desejava concorrer `a licitac¸˜ao

enviou sua proposta dentro do prazo legal.

As justificativas para escolhermos este tema nos fazem dizer que a escolha foi ´obvia. A

´area de seguranc¸a em computac¸˜ao, em paralelo com a computac¸˜ao distribu´ıda, s˜ao as duas frentes

que mais crescem em Pesquisa e Desenvolvimento. O fato do termo n˜ao rep´udio ser quase

desco-nhecido em territ´orio nacional, fornece um vasto campo de pesquisa, e tamb´em um enorme desafio

pois, com pouca pesquisa ainda sobre o tema, consequentemente tem-se menos bibliografia para

12

trabalhar, menos pessoas para discutir e maior dificuldade para validar as id´eias que surgem.

A escolha de ferramentas chamadas de software livre, visando sempre manter o trabalho

independente de fabricantes de tecnologia, nos proporciona oportunidade de utilizar agora o que o

mercado estar´a apostando para os pr´oximos anos, agregando uma vantagem competitiva diante da

forte competic¸˜ao existente no mercado de desenvolvimento de sistemas. Podemos praticar diversos

conceitos que foram ministrados em disciplinas como engenharia de software, an´alise e projeto de

sistemas, gerˆencia de projetos, e v´arias outras.

Para a implementac¸˜ao, foi necess´aria pesquisa em diversos setores, alguns fatores

princi-pais foram o tipo de servic¸o que prover´a o n˜ao rep´udio, as linguagens de programac¸˜ao utilizadas

e outras ferramentas para o desenvolvimento, tal como escolha do servidor Web, conex˜ao com

a PDDE e outros. Para o desenvolvimento, foi usado o paradigma de programac¸˜ao orientada a

objetos, com o projeto sendo feito de acordo com os ciclos de desenvolvimento propostos por

[PRE 95], e documentac¸˜ao no padr˜ao UML, especificado em [BOO 98].

Cap´ıtulo 3

Metodologia utilizada

A func¸˜ao dos trabalhos de conclus˜ao de curso ´e aplicar um teste final aos graduandos,

formar uma barreira entre os aptos e os n˜ao aptos. Um trabalho de conclus˜ao de curso serve

principalmente para preparar o acadˆemico para o mercado, que o espera. Um TCC exemplifica

as dificuldades que ser˜ao encontradas logo `a frente, onde estas devem ser superadas atrav´es de

muito esforc¸o e pesquisa; pontos fundamentais para compor um trabalho de qualidade. Antes

de tentarmos inventar a roda a cada dia, existem pessoas que com certeza j´a divagaram sobre os

mesmos assuntos que podem estar nos rodeando no momento, obtendo soluc¸˜oes eficazes ou pelo

menos chegando a algum tipo de conclus˜ao sobre o tema.

Atrav´es da literatura, conseguimos sempre achar um detalhe que estava passando

des-percebido, comprovar que nossa opini˜ao sobre um determinado assunto estava certa, ou “abrir

a cabec¸a” para novas perspectivas. Todo este esforc¸o rende, principalmente, conhecimento. Cada

experiˆencia, vivida dia ap´os dia, sempre nos enriquece de alguma forma, seja aprendendo com os

erros ou utilizando formas diferentes de lidar com os problemas.

Para que o nosso trabalho de conclus˜ao de curso fac¸a sua parte, ajudar a formar melhores

profissionais, escolhemos com cuidado cada forma de desenvolver nosso projeto, adaptando as

soluc¸˜oes existentes `a nossa realidade.

Como o paradigma de programac¸˜ao orientada a objetos foi utilizado durante todo o curso,

e ´e padr˜ao de todas as empresas de ponta na ´area de desenvolvimento de software, nada mais justo

do que continuar trabalhando com orientac¸˜ao a objetos. Existe vasta documentac¸˜ao na Internet e

em livros sobre o assunto, praticamente todas as fontes de recursos usam e se baseiam na OO para

fornecer informac¸˜ao na ´area. Uma leitura interessante sobre orientac¸˜ao a objetos, bem introdut´oria,

pode ser encontrada em [BOR 03].

14

Ainda falando de aspectos t´ecnicos para depois entrar a fundo no problema, foi necess´aria

a escolha de uma metodologia de desenvolvimento de software, para n˜ao voltar aos prim´ordios da

computac¸˜ao, com 70% do tempo sendo gasto em correc¸˜oes de especificac¸˜oes e implementac¸˜oes

mal feitas.

Recorremos `a engenharia de software, disciplina da 4a fase do curso, para aplicarmos seus

modelos de desenvolvimento de software. Na bibliografia existem diversos modelos a serem

se-guidos, como modelo Incremental, modelo em V e modelo Cascata.

Como nos foi sugerido na ´epoca, e a afirmac¸˜ao ainda persiste, ´e raro adotar um modelo

puro, as melhores opc¸˜oes s˜ao h´ıbridas, adotando as melhores caracter´ısticas de cada modelo. A

´unica pr´e-condic¸˜ao ´e que este modelo h´ıbrido adotado seja seguido conforme especificado, sen˜ao

as metodologias de desenvolvimento perdem seu sentido. Adotamos fases do modelo em Cascata,

do modelo em V, do modelo Incremental e do modelo em Espiral.

Pretendemos, desta forma, aplicar todos os conceitos solidificados atrav´es dos livros e

re-cursos existentes, em nosso projeto, visando sempre fazer um trabalho de alta qualidade, e

incre-mentando cada vez mais o ciclo de aprendizado que o desenvolvimento de um TCC visa

proporci-onar.

A seguir, cada umas das etapas desenvolvidas, An´alise, Projeto, Implementac¸˜ao e Testes, ´e

descrita de forma conceitual. Estas etapas s˜ao sugeridas pelo modelo em Cascata de

desenvolvi-mento de software, e devem ser largamente documentadas.

3.1

Pesquisa

´

E a fase inicial do trabalho e ´e voltada `a pesquisa, tanto para o embasamento te´orico quanto

para familiarizac¸˜ao com as tecnologias que s˜ao utilizadas na implementac¸˜ao do projeto final. A

proposta apresentada e seu conseq¨uente desenvolvimento lhe conferem um bom misto de

dis-ciplinas; a pesquisa realizada se distribui em diversos campos dentro da ´area da Computac¸˜ao.

Destacam-se os seguintes:

- Linguagem de Programac¸˜ao;

- Paradigma de Programac¸˜ao;

- Tipos de Autoridade de Aviso;

15

- Criptografia, Assinaturas Digitais e Seguranc¸a.

No que diz respeito ao uso das ferramentas, foi dada preferˆencia ao uso das tecnologias

abertas e sem patentes. Quanto `a bibliografia sobre o tema (Autoridade de Aviso), foi composta

basicamente de artigos cient´ıficos, visto que este ´e um conceito recente e em desenvolvimento,

existem poucos livros que comentam o assunto. Foram necess´arias leituras e comparac¸˜oes

mi-nuciosas para que seja poss´ıvel extrair os aspectos mais positivos de cada autor. Tamb´em foram

consultados livros que conceituam e exploram os demais assuntos que servem de base te´orica do

tema ou que s˜ao abrangidos por ele.

3.2

An´alise

As pesquisas realizadas de forma mais aprofundada sobre o tema s˜ao importantes, pois

permitiram compor mais detalhadamente o conjunto de necessidades e funcionalidades exigidas

pelo sistema. Ainda nesta etapa foram levantadas alternativas de implementac¸˜ao e as mesmas

passaram por uma avalic¸˜ao quanto `a viabilidade, bem como a identificac¸˜ao de m´odulos e estruturas

que compˆoem o sistema. Por fim, ´e nesta etapa que se obteve o conhecimento sobre tudo que

envolve o tema, que foi de suma importˆancia para que o sistema pudesse ser desenvolvido de

acordo com o que foi idealizado.

3.3

Projeto

Destina-se `a definic¸˜ao e documentac¸˜ao pormenorizada da estrutura e m´odulos identificados

utilizando tendenciosamente o padr˜ao UML. Em outras palavras, toda a definic¸˜ao da organizac¸˜ao

do projeto, dos aspectos f´ısicos, funcionais, de interface, ambiente em que se pretende hospedar o

sistema e etc, est˜ao presentes nesta etapa. Desta forma pode-se evidenciar a relevˆancia do projeto,

visto que nela ocorreram decis˜oes de projeto mais importantes, e que foram extensamente

docu-mentadas para que futuramente possam ser consultadas, reutilizadas ou at´e mesmo continuadas.

3.4

Implementac¸˜ao

Ap´os pesquisadas e definidas as tecnologias, ferramentas e linguagens a serem utilizadas,

a implementac¸˜ao apresentou-se como sendo uma “transcric¸˜ao natural” do conte´udo gerado pela

etapa de projeto para a linguagem computacional.

16

3.5

Testes

Ap´os a conclus˜ao de cada m´odulo foram realizados testes para verificar as funcionalidades

implementadas. Nos est´agios finais do desenvolvimento foram aplicados testes mais abrangentes

e complexos visando identificar e eliminar todos os problemas encontrados. Esta tornou-se uma

pr´atica constante durante todo o desenvolvimento do projeto.

Faz-se claro que como todo bom projeto de engenharia de software as etapas descritas n˜ao

s˜ao definidas por completo de imediato num primeiro momento, mas sim com o desenvolvimento

gradual, c´ıclico e incremental de todas as etapas e m´odulos do projeto. Tamb´em ´e importante

res-saltar que o projeto como um todo tende a utilizar ferramentas abertas e sem patentes, al´em de ser

desenvolvido visando-se sempre um alto grau de legibilidade, reusabilidade e manutenibilidade,

al´em de outras caracter´ısticas que o paradigma de Orientac¸˜ao a Objetos proporciona.

Cap´ıtulo 4

Caracterizac¸˜ao do Problema

Supondo uma situac¸˜ao em que ambas as partes estejam dispon´ıveis e atuem de maneira

justa durante uma troca de mensagens, ter´ıamos uma situac¸˜ao parecida com a descrita a seguir.

Uma fonte A, desejando enviar uma mensagem M para um destino B, faria uma requisic¸˜ao `a uma

PDDE usando M. Ap´os ter em m˜ao o carimbo de M, enviaria para B a mensagem M propriamente

dita e seu respectivo carimbo, assinados com sua chave privada, garantindo a origem. B, por sua

vez, quando receber esta mensagem, afirma seu recebimento gerando um carimbo sobre M, obtido

de alguma PDDE, e envia este carimbo de volta para A, tamb´em utilizando sua chave privada para

garantir a autenticidade do emissor.

Este ´e o procedimento ideal para uma troca de mensagens com n˜ao rep´udio, mas como

podemos ver tudo deve funcionar de maneira ideal, e ambas as partes devem seguir os passos

explanados. Aplicando estes passos `a vida real, temos diversos problemas em potencial, e

destaca-mos alguns: a indisponibilidade de B para receber a mensagem; A afirmar que enviou a mensagem

com seu recibo e n˜ao o fez; B recebeu a mensagem M mas afirma que nunca a recebeu; A ou B

afirmarem que efetuaram uma determinada ac¸˜ao em um tempo T diferente do real; e mais uma

gama de poss´ıveis eventos.

Visando suprimir estes problemas, v´arias soluc¸˜oes s˜ao propostas. Neste trabalho optamos

por utilizar a soluc¸˜ao chamada de Autoridade de Aviso, um sistema que deve prover `as partes

interessadas evidˆencias de seus atos, com o objetivo de resolver disputas que possam surgir entre

as partes.

De modo geral e simplificado pode-se dizer que a Autoridade de Aviso ´e um agente

in-termediador entre uma fonte e um destino quando se trata do processo de transferˆencia de dados

digitais, ou seja, a fonte n˜ao mais enviar´a os dados diretamente para o destino, mas sim para uma

18

entidade (Autoridade de Aviso). A Autoridade de Aviso deve ser uma autoridade confi´avel para

ambas as partes (emissor e receptor), e deve prover maior seguranc¸a e sigilo dos dados transferidos,

al´em de ser um mecanismo que deve dar maior respaldo aos seus usu´arios quanto aos

acontecimen-tos que possam envolver os dados durante todo o seu processo de transferˆencia. Esse respaldo diz

respeito a diversas informac¸˜oes (recibos) datadas, registradas e dotadas de valor legal que a

Auto-ridade de Aviso deve gerar durante a transferˆencia dos dados de forma a garantir aos seus usu´arios

as tentativas de envio e entrega. Explicando de forma mais detalhada, ´e poss´ıvel garantir quando

e qual fonte enviou determinado documento e se o destino recebeu ou n˜ao e quando recebeu o

documento digital. Dessa maneira a fonte pode provar legalmente que tentou enviar o documento

numa determinada data e hora, e pode provar que o destino recebeu o documento, se isto realmente

ocorreu. J´a o destino pode provar que recebeu determinado documento de dada fonte numa certa

data e hora.

Em vista desses fatos a Autoridade de Aviso surge com o objetivo principal de tratar o n˜ao

rep´udio de documentos digitais, ou seja, fazer com que as partes envolvidas no processo de

trans-ferˆencia dos dados digitais n˜ao possam negar a ocorrˆencia uma ac¸˜ao previamente realizada. Alem

dessa caracter´ıstica, a Autoridade de Aviso engloba ainda outros aspectos de seguranc¸a importantes

no processo, tais como:

- Integridade dos dados: tem como o verificar e saber se as informac¸˜oes dos dados foram

manipuladas por outro que n˜ao a fonte;

- Autenticidade: permite comprovar se os dados foram confeccionados por uma determinada

entidade ou pessoa.

Estes conceitos de seguranc¸a em computac¸˜ao s˜ao indispens´aveis para garantir que o

pro-cesso ocorra de forma que nenhuma das partes seja prejudicada no propro-cesso. No mundo real, um

documento ´e uma representac¸˜ao de um fato, no mundo digital, tal afirmac¸˜ao, levemente

contextu-alizada, tamb´em ´e verdadedeira. Um documento no meio digital ´e um sequencia de bits, que vista

de forma adequada, torna-se a representac¸˜ao de um fato.

Tais fatos s˜ao, em nosso caso, as mensagens trocadas entre as partes interessadas, e

preci-sam estar ´ıntegras e autˆenticas durante todo o transcorrer dos eventos. A utilizac¸˜ao das assinaturas

digitais sobre estas mensagens ir´a prover tal integridade e autenticidade. Sua l´ogica de utilizac¸˜ao

e funcionamento ´e um tanto simples: uma func¸˜ao de resumo, ou “hash”, ´e aplicada sobre a

men-sagem, evitando que esta tenha que ser repetida por inteiro para garantir integridade. Sobre este

19

resumo ´e utilizada a chave privada do emissor, criptografando-o, e o resultado desta operac¸˜ao ´e a

pr´opria assinatura digital da mensagem, ´unica, segundo as propriedades da func¸˜ao hash. Em um

momento posterior algu´em que pretende verificar a integridade de uma mensagem ir´a aplicar uma

func¸˜ao hash apropriada e comparar seu resultado com o hash contido na assinatura da mensagem.

Caso estes sejam idˆenticos, a mensagem ´e ´ıntegra.

Como esta operac¸˜ao foi feita usando a chave privada do emissor, por definic¸˜ao podemos

afirmar que este emissor foi o respons´avel pela confecc¸˜ao da mensagem, visto que, teoricamente,

ele ´e o ´unico que pode portar sua chave privada. Este fato garante a autenticidade da referida

mensagem.

Como j´a citado anteriormente neste documento, diversos problemas existem hoje em dia

nas comunicac¸˜oes por meio digital. Documentos forjados, diferenc¸as na hora da postagem de

um documento, doucmentos modificados acidentalmente ou de forma fraudulenta dentro de uma

organizac¸˜ao ou enquanto em trˆansito entre organizac¸˜oes, e documentos perdidos ou atrasados

du-ranto o processo de envio s˜ao os mais comuns, de acordo com [ZHO 96a]. Quando uma destas

situac¸˜oes aconteceu ou pode ter acontecido, deve existir algum mecanismo que supra algu´em de

informac¸˜oes necess´arias para tomada de decis˜ao sobre o impasse. Esta ´e a func¸˜ao da Autoridade

de Aviso.

Teoricamente, a Autoridade deve estar sempre apta a receber requisic¸˜oes de entrega, seja

usando m´ultiplas instˆancias ou outras t´ecnicas discutidas na bibliografia, mas esta garantia n˜ao ´e

aplicada ao nosso trabalho, visto que foge do escopo principal do mesmo. Al´em disso, o sistema

n˜ao tem garantias de envio dos documentos por ele recebidos, visto que o destino pode estar

indefinidamente fora do ar, e as tentativas de envio tˆem seu limite. Mas se for poss´ıvel enviar a

mensagem, esta operac¸˜ao deve ocorrer.

Outro item que nossa implementac¸˜ao n˜ao abrange diz respeito `a confidencialidade dos

do-cumentos, mensagens que por ventura estejam criptografadas s˜ao tratadas da mesma forma que

mensagens normais pela Autoridade de Aviso. Existe na bibliografia estudos sobre como aplicar

criptografia nas mensagens enviadas ao destino, sem que a Autoridade de Aviso tenha acesso ao

seu conte´udo, mas este t´opico tamb´em foge do escopo no nosso trabalho, mas n˜ao deixa de ser

uma excelente sugest˜ao para estudos futuros. As assinaturas digitais j´a fornecem o que

necessi-tamos, que ´e integridade e autenticidade. alguns estudos interessantes podem ser encontrados em

[HER 02].

Cap´ıtulo 5

Protocolos Existentes

Segundo [KRE 02], existem v´arios tipos de terceiras partes confi´aveis, ou TTP, baseadas

no seu n´ıvel de envolvimento no protocolo como um todo:

- TTP Inline: uma TTP envolvida em todas as transmiss˜oes de mensagens durante o protocolo,

´e dita inline;

- TTP Online: uma TTP envolvida em cada sess˜ao do protocolo, mas n˜ao em cada transmiss˜ao

de mensagens ´e dita online;

- TTP Offline: uma TTP envolvida em um protocolo apenas em situac¸˜oes de comportamento

incorreto de entidades desonestas ou erros de rede ´e dita offline;

- TTP Neutra: uma TTP ´e conhecida como neutra quando a assistˆencia que ela provˆe para a

realizac¸˜ao com sucesso do protocolo n˜ao est´a condicionada ao conhecimento de qualquer

informac¸˜ao que est´a sendo trocada pelas partes;

- TTP transparente: uma TTP offline produzindo evidˆencias indisting¨uiveis das evidˆencias

que Alice e Bob deveriam ter trocado em um caso bem sucedido, ´e dita TTP transparente.

Como visto, cada tipo de TTP trabalha de forma espec´ıfica e diferente das demais. A

escolha de uma em detrimento de outra deve ser feita com base no tipo de servic¸o que deve ser

executado, o custo envolvido e as premissas necess´arias ao funcionamento das mesmas.

Dentre os artigos pesquisados, v´arios protocolos para prover n˜ao rep´udio s˜ao propostos.

Eles diferem uns dos outros em alguns aspectos b´asicos. Os par´agrafos abaixo ir˜ao explicar estes

aspectos.

21

A propriedade de Honestidade, do inglˆes “fairness”, ´e um fator indispens´avel a ser

anali-sado quando da escolha de um protocolo para Autoridade de Aviso. A Honestidade nada mais ´e

o fato de que nenhuma das entidades participantes pode lesar a outra, ou seja, se o destino recebe

o NRO a origem obrigatoriamente dever´a receber o NRR. Ainda no artigo de [KRE 02], temos o

conceito de Honestidade forte, ou “strong fairness”, onde “um protocolo de n˜ao rep´udio fornece

Honestidade forte se e somente se no final da execuc¸˜ao do protocolo ou a origem recebeu o NRR de

uma mensagem M, e o destino recebeu a mensagem M correspondente e o NRO desta mensagem

ou ambos n˜ao receberam nenhuma informac¸˜ao com valor”.

Outro tipo de Honestidade ´e a Honestidade verdadeira (“True fairness”), que ´e conceituada

da seguinte forma: “um protocolo de n˜ao rep´udio fornece Honestidade verdadeira se e somente se

ele provˆe Honestidade forte e, se o processo for feito com sucesso, as evidˆencias de n˜ao rep´udio

produzidas durante o protocolo s˜ao independentes de como o protocolo foi utilizado”. Atrav´es

desta afirmac¸˜ao podemos concluir que fica imposs´ıvel de verificar se uma TTP teve que intervir

no protocolo ou n˜ao, e isto ´e uma das premissas de uma TTP transparente. Portanto, uma TTP

transparente fornece Honestidade verdadeira e a Honestidade verdadeira ´e uma das propriedades

indispens´aveis de uma TTP transparente.

Outro fator que diferencia de forma marcante os protocolos ´e a propriedade da recepc¸˜ao

se-letiva. Este item refere-se exclusivamente ao destino que, em determinados protocolos estudados,

pode optar em fornecer ou n˜ao o n˜ao rep´udio do recebimento (NRR) ap´os visualizar uma

mensa-gem M, dando-lhe uma vantamensa-gem sobre a orimensa-gem. A recepc¸˜ao seletiva n˜ao existe em protocolos

que oferecem “Honestidade”.

Existem protocolos que visam prover o n˜ao rep´udio sem o uso de uma terceira parte, mas

eles n˜ao s˜ao estudados neste trabalho. Um exemplo ´e descrito em [MAR 99]. A cada passo do

protocolo, com excec¸˜ao do ´ultimo, nenhuma das partes fica em vantagem sobre a outra, pois a

origem n˜ao tem interesse de interromper o protocolo antes do seu fim, e, por outro lado, o destino

n˜ao ter´a nenhum lucro caso fac¸a isso. O ´unico modo do destino receber a mensagem sem ser

obrigado a enviar o NRR ´e adivinhar o n´umero de passos do protocolo.

Para garantir o n˜ao rep´udio sem a participac¸˜ao de um terceiro confi´avel, no protocolo o

destino n˜ao sabe quando a ´ultima transmiss˜ao vai acontecer. Assim, a origem escolhe

aleatoria-mente um n´umero n de passos para o protocolo. Esta informac¸˜ao nunca ´e revelada para o destino

e nem pode ser calculada por este.

Embora este protocolo seja bastante interessante, ele ainda apresenta falhas, como exigir

que as partes tenham um poder computacional semelhante, ou, se por qualquer motivo o destino

22

decidir n˜ao receber informac¸˜oes de uma determinada origem, esta nada pode fazer, n˜ao tendo nem

como provar que despachou a mensagem, pois o recibo ´e gerado e enviado pelo destino, que nem

sempre ´e confi´avel.

Cabe a cada desenvolvedor escolher qual TTP aplica-se melhor `a aplicac¸˜ao que est´a sendo

desenvolvida. Como cada uma tem suas vantagens e desvantagens, qualidades e defeitos, ´e dif´ıcil

julgar de forma absoluta qual tipo ´e melhor, pois isto ´e relativo, dependente do contexto.

Cap´ıtulo 6

Aspectos Jur´ıdicos

A discuss˜ao em ˆambito nacional em torno da validade das assinaturas digitais e,

principal-mente, das entidades que poder˜ao fornecer tais assinaturas, est´a a todo vapor. A Medida provis´oria

No 2.200-2, de 24 de agosto de 2001, reconheceu legalmente o uso de assinaturas digitais por

processo criptogr´afico para garantir autenticidade e integridade a documentos eletrˆonicos.

Segue texto extra´ıdo da MP:

Medida Provis´oria n

o

2.200-02, de 2001:

Art. 10. Consideram-se documentos p´ublicos ou particulares, para todos os fins legais, os

documentos eletrˆonicos de que trata esta Medida Provis´oria.

§ 1

o

_{As declarac¸˜oes constantes dos documentos em forma eletrˆonica produzidos com a}

utilizac¸˜ao de processo de certificac¸˜ao disponibilizado pela ICP-Brasil presumem-se verdadeiros

em relac¸˜ao aos signat´arios, na forma do art. 131 da Lei no 3.071, de 1o de janeiro de 1916

-C´odigo Civil.

§ 2

o

_{O disposto nesta Medida Provis´oria n˜ao obsta a utilizac¸˜ao de outro meio de}

comprovac¸˜ao da autoria e integridade de documentos em forma eletrˆonica, inclusive os que

utilizem certificados n˜ao emitidos pela ICP-Brasil, desde que admitido pelas partes como v´alido

ou aceito pela pessoa a quem for oposto o documento.

Em sua primeira edic¸˜ao, de 28 de junho de 2001, constava em seu artigo 12, “ficava

estabe-lecido que o documento deveria estar ajustado `a ICP-Brasil, ou seja, que tenha sido assinado com

chaves certificadas por uma certificadora credenciada. Assim sendo, a exigˆencia de certificac¸˜ao

das chaves utilizadas para gerar uma assinatura digital passaria a ser da essˆencia do ato praticado

24

(Art. 130 do C´odigo Civil)”, segundo [dC 01].

Neste artigo estava a polˆemica, pois como afirmado acima a ICP-Brasil seria respons´avel

pelo cadastro e regulamentac¸˜ao de todas as ACs que desejassem emitir certificados digitais para os

mais diversos fins, e seria a Autoridade Raiz destas ACs.

Como citado anteriormente, sua segunda vers˜ao extinguiu tal obrigatoriedade,

conside-rada exdr´uxula, principalmente pela responsabilidade que seria atribu´ıda `a certificadora da

ICP-Brasil, que teria em sua chave raiz a maior mina de ouro que se teve conhecimento at´e ent˜ao. A

distribuic¸˜ao desse risco ´e a medida mais ´obvia a ser tomada neste ˆambito, onde chaves emitidas

por entidades privadas, desde que aceitas por ambas as partes, podem se tornar instrumentos para

gerac¸˜ao de documentos com valor jur´ıdico.

Como pode-se notar, existem ainda diversos problemas relativos `a legislac¸˜ao para

docu-mentos eletrˆonicos, e os mesmos fogem do escopo desta an´alise. Apenas vale aqui ressaltar que

assinaturas digitais valem tanto quanto assinaturas manuscritas em papel, com firma reconhecida

em cart´orio ou n˜ao.

O fato de que assinaturas digitais servem, do ponto de vista jur´ıdico, como prova legal de

que algu´em tomou uma determinada ac¸˜ao, nos faz crer que as evidˆencias geradas pela Autoridade

de Aviso, por serem todas baseadas em assinaturas digitais, ser˜ao mais do que suficientes para que

um Juiz possa analis´a-las e decidir, de forma n˜ao amb´ıgua, qual parte tem raz˜ao em uma poss´ıvel

disputa.

Cap´ıtulo 7

Protocolo Adotado

O protocolo escolhido para ser implementado em nosso trabalho ´e um h´ıbrido de protocolos

estudados com a realidade encontrada no ambiente computacional da Universidade Federal de

Santa Catarina. Portanto, n˜ao ´e igual a nenhum dos protocolos apresentados na bibliografia, mas

sim a utilizac¸˜ao dos melhores conceitos presentes em alguns deles com algumas adaptac¸˜oes para

um melhor enquadramento da soluc¸˜ao no modelo de implementac¸˜ao e outras particularidades do

desenvolvimento em si.

7.1

Protocolo proposto

Para explicar como funciona o protocolo desenvolvido, s˜ao necess´arias antes algumas

definic¸˜oes de notac¸˜ao, estas seguem um padr˜ao informal apresentado pelos autores que escrevem

sobre o assunto:

- NRO: N˜ao rep´udio da Origem, caracterizado pelo uso da assinatura digital da Origem;

- NRS: N˜ao rep´udio da Origem, caracterizado pelo uso da assinatura digital da Autoridade;

- NRR: N˜ao rep´udio da Origem, caracterizado pelo uso da assinatura digital do destino;

- M: Uma mensagem qualquer;

- L(M): Um valor ´unico referente `a uma mensagem M espec´ıfica;

- ts: Carimbo de tempo retornado pela PDDE.

O Protocolo funciona assumindo que as mensagens eletrˆonicas, ou e-mails, consigam

che-gar ao destino em um limite indeterminado de tempo, ou retornem mensagens de erro caso n˜ao

26

consigam. Seus passos s˜ao listados a seguir:

1. A

→

TTP

:

M, NRO

2. TTP

→

PDDE

:

M, NRO

3. PDDE

→

TTP

:

ts(M, NRO)

4. TTP

→

A

:

NRS

5. TTP

→

B

:

L(M)

6. B

→

TTP

:

NRR

7. TTP

→

PDDE

:

NRR

8. PDDE

→

TTP

:

ts(M, NRR)

9. TTP

→

B

:

M, NRO

10. TTP

→

A

:

ts(M, NRR)

O procotolo inicia-se com A enviando uma mensagem assinada para a Autoridade,

infor-mando sua vontade de envi´a-la para B. Em seguida, nos passos 2 e 3, a TTP encaminha esta

mensagem assinada como um arquivo para a PDDE que, ap´os carimb´a-la, retorna este carimbo

rec´em emitido.

O passo 4, por sua vez, encerra as obrigac¸˜oes de A no protocolo. Ap´os receber o carimbo

da PDDE, a TTP envia para A uma mensagem (NRS) que consiste neste carimbo sobre M, e esta

serve para afirmar que A tentou enviar a mensagem M para B no momento informado no carimbo.

Seguindo, no passo 5, a Autoridade de aviso informa a B que ele tem uma mensagem

aguardando para ser recebida, mas para evitar que B aceite ou n˜ao esta mensagem dependendo da

origem da mesma, esta origem n˜ao ´e informada. Tudo que ele receber´a ´e um link para acessar tal

mensagem, onde ele ter´a que primeiro fornecer o NRR para depois ter acesso `a mensagem M. Este

passo pode ser repetido diversas vezes, dependendo de crit´erios a serem definidos, como tempo

m´aximo para resposta de B e intervalos para reemiss˜ao de avisos.

Os passos 6, 7 e 8 devem ser implementados de forma atˆomica. Ou estes trˆes passos s˜ao

superados sem nenhum problema ou um processo de retrocesso ser´a efetuado, evitando que B

fornec¸a o NRR sem ter acesso `a mensagem M. No passo 6, B fornece sua assinatura digital para

que esta seja anexada `a mensagem M vinda de A. Este envelope (M, NRR) ent˜ao ´e enviado para a

PDDE, que fornecer´a um carimbo de tempo sobre ele, isso ´e feito nos passos 7 e 8.

Caso tudo tenha se passado de forma correta at´e aqui, a Autoridade por fim fornece a

men-sagem M a B no passo 9, que assim encerra sua participac¸˜ao no processo. O ´ultimo passo consiste

27

do envio para A do NRR, que afirma que B recebeu a mensagem M no momento informado no

segundo carimbo (Passo 10). Vale aqui salientar que a ordem dos passos 9 e 10 n˜ao influenciam

no processo como um todo, e pode ter sua ordem trocada sem maiores implicac¸˜oes.

Visto que, ou os passos 6 a 8 acontecem ou nenhum deles o ´e, evitamos assim que A tenha

alguma vantagem sobre B, que fornece seu NRR antes de receber a mensagem M, mas a TTP

garante que ou ele poder´a receber M ou seu NRR n˜ao ser´a utilizado. No passo 5, apenas um aviso

sobre uma mensagem M ´e enviado a B, e este aviso n˜ao informa o origem da mensagem, evitando

o problema da recepc¸˜ao seletiva. Ou B afirma que deseja receber a mensagem antes de vˆe-la, ou

ele nunca ter´a acesso a ela.

Tendo em m˜aos o NRS, A pode provar que tentou enviar a mensagem M para B. Com o

NRR, ele pode tamb´em provar que B coletou esta mensagem em um determinado tempo T. Com o

NRO, B pode provar que recebeu M de A, e tamb´em verificar a autenticidade de M.

Concluindo, destacamos aqui que sempre visamos evitar os problemas listados na

biblio-grafia, como a recepc¸˜ao seletiva e a quest˜ao da honestidade. A soluc¸˜ao que aqui chamamos de

Autoridade de Aviso ´e classificada como uma TTP Inline, segundo as definic¸˜oes apresentadas no

cap´ıtulo 5.

Cap´ıtulo 8

Aspectos t´ecnicos

Como j´a comentamos no in´ıcio deste relat´orio, demos ˆenfase na utilizac¸˜ao de ferramentas

que utilizem o conceito de software livre, onde sua distribuic¸˜ao e utilizac¸˜ao depende apenas de

algumas premissas, como distribuic¸˜ao das licenc¸as originais. N˜ao ´e necess´ario nenhum tipo de

contrato nem compra de produtos/servic¸os.

Nossa primeira quest˜ao no desenvolvimento do trabalho foi decidir como os passos do

protocolo seriam transformados em ac¸˜oes tang´ıveis aos usu´arios em seus computadores. Optamos

por utilizar a ferramenta mais comum dos internautas: o e-mail. Outra opc¸˜ao sugerida, mas que

foi descartada, foi o uso de conex˜oes diretas entre as entidades, utilizando o conceito de soquetes,

ou algo similar. Esta opc¸˜ao necessitaria tamb´em que fossem desenvolvidos aplicativos espec´ıficos

tanto para a origem como para o destino.

A opc¸˜ao do e-mail foi escolhida principalmente por n˜ao necessitar que os clientes do

servic¸o tenham que instalar programas extras, visto que a grande maioria dos sistemas

operaci-onais j´a vem com algum software para gerenciamento de e-mails.

A seguir, foi decidida em qual linguagem de programac¸˜ao seria desenvolvida a Autoridade

de Aviso, a parte mais importante do sistema. A linguagem escolhida foi a linguagem Java,

de-vido a diversos crit´erios. Primeiramente, Java ´e a linguagem de programac¸˜ao que mais cresce no

mercado, e tem como caracter´ıstica a facilidade de acoplar componentes de software de terceiros

de forma bastante f´acil. Possui centenas de p´aginas web com grupos de discuss˜ao que trabalham

com a linguagem, bem como sites que provˆem tutoriais, artigos e exemplos diversos.

Outro fator preponderante ´e a quest˜ao da portabilidade, em que Java distancia-se de

ou-tras linguagens de programac¸˜ao. O chamado “byte code” gerado pelo compilador Java pode ser

utilizado em qualquer sistema operacional que suporte a linguagem.

29

Neste ponto n˜ao analisamos outras opc¸˜oes, como C++, ou Object Pascal. Fizemos um

estudo em sites especializados e alguns livros que tratam dos assuntos seguranc¸a e Java, e

cons-tatamos que Java tinha todos os recursos necess´arios que n´os precisar´ıamos. As implementac¸˜oes

java.security, javax.mail, e org.bouncycastle foram as mais utilizadas, e forneceram os

requisi-tos necess´arios para implementar ac¸˜oes de criptografia, assinaturas digitais, leitura de e-mails,

verificac¸˜ao de assinaturas, caminhos de certificados, dentre outros. Vale salientar que esta ´ultima

(org.bouncycastle), faz parte do projeto BouncyCastle, e provˆe bibliotecas de classes de seguranc¸a

que complementam as que se encontram no JDK padr˜ao de Java. Estas bibliotecas tamb´em s˜ao

desenvolvidas com o conceito de software livre, e s˜ao usadas em larga escala por desenvolvedores

que trabalham com Java e seguranc¸a.

Como alguns passos do nosso protocolo precisam que os usu´arios interajam com p´aginas na

Internet, precisamos escolher um servidor para prover estas p´aginas. Existem algumas opc¸˜oes mais

tradicionais, como o Apache, dispon´ıvel para v´arias plataformas, o Tomcat, tamb´em dispon´ıvel

para diversas plataformas, e o IIS, da Microsoft, dispon´ıvel para o sistema operacional Windows.

Em noso trabalho escolhemos o Tomcat, principalmente pela sua facilidade de configurac¸˜ao,

pos-sibilidade de usar conex˜oes seguras (SSL) e capacidade do uso de p´aginas web criadas em JSP e

servlets, tamb´em escritos em Java. Estes servlets s˜ao programas que rodam em servidores Web, e

implementam as mais diversas func¸˜oes.

Existem outras soluc¸˜oes ao inv´es de servlets, como scripts CGI, as linguagens PHP e ASP,

mas sua similaridade com a linguagem Java e sua f´acil utilizac¸˜ao em um servidor rodando Tomcat

foram os quesitos principais que nos levaram a escolher esta opc¸˜ao.

Um outro ponto a ser levantado ´e a validade dos certificados digitais que ser˜ao utilizados

para o funcionamento da Autoridade de Aviso. Como o trabalho foi desenvolvido para estar situado

no laborat´orio de seguranc¸a em computac¸˜ao da UFSC (LabSec), demos preferˆencia `a utilizac¸˜ao da

infra-estrutura de chaves p´ublicas da UFSC, tamb´em desenvolvida pelo LabSec. Atrav´es do site

do laborat´orio, qualquer aluno, professor ou servidor vinculado `a Universidade pode requisitar um

certificado digital em seu nome, utilizando a Autoridade Certificadora da UFSC.

Pela facilidade e tamb´em at´e pelo posicionamento geogr´afico, ser´a necess´ario ent˜ao que as

partes interessadas em utilizar este servic¸o tenham um certificado digital v´alido, emitido pela AC

do LabSec. Destacamos que isto ´e apenas uma simples restric¸˜ao, mas que pode ser retirada sem

maiores problemas, fazendo com que o sistema funcione com qualquer certificado digital, desde

que as partes concordem que este certificado seja v´alido para as func¸˜oes desejadas.

30

um servidor no labSec, e atende a requisic¸˜oes de carimbos com base no enderec¸o IP do requisitante.

Esta PDDE deve, por sua vez, atender a v´arios requisitos de seguranc¸a especificados em norma

ISO. Um aspecto interessante ´e o fato de que a chave privada desta PDDE ´e armazenada em uma

placa acoplada ao servidor, alimentada por uma pilha comum. Caso algu´em tente abrir fisicamente

a tampa do servidor da Protocoladora sem estar autorizado via software, esta alimentac¸˜ao ´e cortada

e a chave privada da PDDE ´e perdida, inutilizando-a.

Cap´ıtulo 9

Sistema de Autoridade de Aviso

Este cap´ıtulo, descritivo da parte pr´atica da Autoridade de Aviso, ´e divido em cinco sec¸˜oes.

Primeiramente detalharemos as implementac¸˜oes de terceiros que auxiliaram no desenvolvimento

do sistema. Posteriormente, explicaremos como ele funciona internamente, de como ele

imple-menta o protocolo proposto no cap´ıtulo 7. Dando sequencia, descrevemos como a aplicac¸˜ao se

divide em dois m´odulos distintos, na quarta sec¸˜ao detalharemos como deve ser utilizado pelos

usu´arios, exemplificando cada passo do processo, desde a intenc¸˜ao de se enviar uma mensagem

usando a Autoridade de Aviso at´e a recepc¸˜ao das envidˆencias pelas partes interessadas e, por

´ultimo, analisaremos a implementac¸˜ao efetuada.

9.1

Implementac¸˜oes

Utilizamos diversas implementac¸˜oes para complementar as funcionalidades do JDK padr˜ao.

Estas implementac¸˜oes s˜ao chamadas de pacotes, pois s˜ao encapsuladas geralmente um um ´unico

arquivo que, uma vez configurado, pode ser utilizado no desenvolvimentos de aplicac¸˜oes.

Com certeza o pacote mais importante foi o do projeto BouncyCastle, que implementa

algoritmos criptogr´aficos de acordo com a especificac¸˜ao da JCE, que regularmenta o padr˜ao de

implementac¸˜ao destes algoritmos. Os pacotes BouncyCastle implementam um “Provider”, que

nada mais ´e do que um conjunto de chamadas que implementam m´etodos abstratos ou

sobrees-crevem m´etodos concretos da API Java. Este provedor fornece v´arias utilidades necess´arias `a

Autoridade de Aviso, e podemos destacar algumas:

- Classes que manipulam mensagens de e-mail digitalmente assinadas;

32

- Classes que implementam m´etodos de acesso a certificados digitais;

- Classes que permitem verificar integridade, validade e diversas propriedades de certificados

digitais;

- Classes que auxiliam a assinar digitalmente arquivos e mensagens de e-mail.

Outro pacote importante foi a API Javamail, fornecida `a parte pela Sun, e serve para

forne-cer funcionalidades de e-mail `a aplicac¸˜ao. Javamail ´e utilizada para criar e utilizar conex˜oes POP3,

IMAP e SMTP com servidores destes servic¸os. Este pacote foi utilizado para leitura e envio de

todas as mensagens eletrˆonicas que passam pela Autoridade de Aviso.

Para utilizac¸˜ao do servic¸o de FTP, que ´e utilizado para armazenar arquivos em um

servi-dor de arquivos, foi utilizado o pacote j2ssh, que por sua vez fornece classes que implementam

conex˜oes seguras para a transferˆencia dos arquivos, o chamado SFTP. Quando ´e comentado no

texto FTP, deve-se entender por SFTP, visto que o projeto foi implementado para ser utilizado nos

servidores da UFSC, que n˜ao suportam conex˜oes n˜ao seguras de transferˆencia de arquivos, o FTP

comum.

Um pacote bastante ´util foi o pacote jConfig, utilizado para armazenar as configurac¸˜oes da

Autoridade. Este pacote permite que todas estas configurac¸˜oes sejam informadas em um arquivo

XML bem simples, e bem organizado, facilitando a visualizac¸˜ao e alterac¸˜ao das informac¸˜oes de

configurac¸˜ao. O pacote fornece classes que lˆeem e manipulam estes arquivos XML.

Os itens que causaram a dependˆencia de plataforma no sistema s˜ao uma DLL da empresa

BRy Tecnologia, e a DLL Capicom, da Microsoft.

A DLL da BRy, chamada de BRyPDDECom, fornece as rotinas necess´arias para comunicac¸˜ao

com a PDDE, cuja implementac¸˜ao tamb´em ´e desta mesma empresa. Possui m´etodos para emiss˜ao

de carimbos de tempo e verificac¸˜ao de carimbos emitidos. Sua utilizac¸˜ao deu-se pelo motivo de

que era a ´unica PDDE que conseguimos dispon´ıvel para uso em nosso trabalho.

J´a a DLL Capicom, da Microsoft, fornece rotinas para que o usu´ario possa emitir sua

assinatura digital atrav´es de uma p´agina Web. Sua utilizac¸˜ao ser´a detalhada mais a frente. Existem

modos de fazer estas func¸˜oes de maneira independente de plataforma, mas devido `a premˆencia de

tempo, utilizamos esta soluc¸˜ao.

33

9.2

Funcionamento Interno

A seguir descreveremos todos os passos que a aplicac¸˜ao efetua assim que ´e executada.

Quando da sua inicializac¸˜ao, timers s˜ao instanciados e estes timers fazem as chamadas aos

proce-dimentos de verificac¸˜ao de mensagens, dentre outros.

1. O Delivery Authority periodicamente, num intervalo de tempo pr´e-configurado, verifica se

recebeu novas mensagens de email. Todas as mensagens ap´os terem sido recebidas s˜ao

exclu´ıdas do servidor de e-mail. Quando o Delivery Authority recebe um email de uma

origem A, s˜ao feitas todas as verificac¸˜oes necess´arias para garantir que o mesmo est´a dentro

dos padr˜oes pr´e-estabelecidos por este servic¸o:

- Verifica se o email foi assinado;

- Verifica se a assinatura foi feita com base num certificado aceito pelo Delivery

Autho-rity;

- Verifica se o certificado usado para assinar est´a dentro do prazo de validade;

- Verifica se o enderec¸o de email do certificado digital coincide com o do remetente do

email;

- Verifica se o subject corresponde a um ´unico enderec¸o de email v´alido,: o destino B.

Observac¸˜ao: Caso o Delivery Authority encontre problema em qualquer uma das verificac¸˜oes

realizadas, ´e enviado para a origem A um email assinado (com a mensagem recebida em

anexo) avisando e indicando os problemas que o email apresentou.

2. Caso o email n˜ao apresente qualquer problema, o Delivery Authority salva o email atribuindo

um identificador ´unico ao nome do arquivo do email. Exemplo de arquivo salvo: 5656.eml.

3. Este arquivo ´e enviado para a PDDE que, por sua vez, retorna para o Delivery

Autho-rity um arquivo protocolado (“carimbo”) contendo a assinatura digital da PDDE com sua

protocolac¸˜ao de data e hora, representando assim, a data e hora em que a origem A enviou a

mensagem para o destino B. Exemplo de nome do arquivo protocolado: 5656.eml.tsr.

4. De posse do arquivo protocolado, o Delivery Authority assina a mensagem salva (5656.eml)

e o arquivo protocolado (5656.eml.tsr) e salva os arquivos gerados. Exemplo de assinaturas

das mensagens assinadas: 5656.eml.tsr.p7s e 5656.eml.str.p7s.

34

5. Ap´os gerar as assinaturas, o Delivery Authority compacta todos os arquivos (mensagem

salva, arquivo protocolado e assinaturas geradas) em um ´unico arquivo compactado. Esse

arquivo compactado serve tanto como a evidˆencia de n˜ao rep´udio da submiss˜ao (NRS), assim

como evidˆencia de n˜ao rep´udio da origem (NRO). Desta forma, o arquivo compactado ´e

enviado, servindo como NRS, por email assinado pela Delivery Authority para a origem A. E

tamb´em ´e salvo para posteriormente ser entregue ao destino B servindo como NRO. Exemplo

de nome do arquivo compactado: 5656.zip. Observac¸˜ao: O arquivo compactado (NRO) pode

ser salvo localmente, caso a Aplicac¸˜ao Web e Aplicac¸˜ao Receptora estejam executando na

mesma m´aquina, ou pode ser salvo em FTP, caso a Aplicac¸˜ao Web e Aplicac¸˜ao Receptora

estejam executando em m´aquinas diferentes.

6. Ap´os gerar e enviar o NRS para a origem A, o Delivery Authority envia um email (“notificac¸˜ao

de aviso”) para o destino B avisando-o de que recebeu uma mensagem e indicando o enderec¸o

da internet onde o destino B pode obtˆe-la. Por´em, o Delivery Authority n˜ao revela em

ne-nhum momento o remetente da mensagem afim de evitar o problema de recepc¸˜ao seletiva.

Observac¸˜ao: A mensagem ´e guardada por um per´ıodo de 14 dias e depois ´e automaticamente

exclu´ıda, independentemente do fato de B ter recebido a mensagem ou n˜ao. Durante esse

per´ıodo, enquanto o destino B ainda n˜ao se prontificou a receber a mensagem, outros emails

com o mesmo aviso s˜ao enviados periodicamente para o destino B. O primeiro aviso sempre

´e enviado, por´em, se o destino B ainda n˜ao recebeu a mensagem outros 2 avisos s˜ao enviados

quando faltarem 7 ou 3 dias para expirar o prazo de 14 dias em que a mensagem ´e guardada

pelo Delivery Authority. Ainda assim, se o destino B n˜ao tiver obtido a mensagem que lhe

foi enviada e o prazo tiver sido expirado, ent˜ao um ´ultimo aviso ´e enviado comunicando-o

que a mensagem foi exclu´ıda.

7. Assim que o destino B for at´e enderec¸o da internet fornecido atrav´es dos avisos que recebe

do Delivery Authority, ´e realizada uma conex˜ao HTTPS para troca segura de informac¸˜oes

pela internet. Essa conex˜ao HTTPS exige a autenticac¸˜ao do destino B que, para isso, deve

fornecer o seu certificado digital pelo qual quer se autenticar com o Delivery Authority.

Observac¸˜ao: Para facilitar, o Delivery Authority restringe as possibilidades de escolha do

certificado para autenticac¸˜ao somente aos certificados que o destino possui instalado e que

s˜ao aceitos pelo Delivery Authority.