Ataque do Homem do Meio

Com a existˆencia de uma grande troca de mensagens no protocolo, uma quest˜ao que deve ser minuciosamente avaliada ´e a dos ataques. Conforme visto no cap´ıtulo 4, a

comunicac¸˜ao est´a sujeita a ataques passivos e ativos, podendo aumentar ou diminuir a circulac¸˜ao de mensagens entre os participantes, dependendo das atividades ou intenc¸˜oes do oponente. O oponente ou homem do meio, como tamb´em ´e chamado, ´e aquele que participa da comunicac¸˜ao entre duas entidades de forma clandestina, objetivando algum benef´ıcio pr´oprio com a interceptac¸˜ao, fabricac¸˜ao ou captura de informac¸˜oes para uso futuro. O protocolo, por sua vez, deve prever situac¸˜oes deste tipo e por isso, cada uma das mensagens trocadas descritas na sec¸˜ao 5.4, ser˜ao avaliadas sobre este aspecto:

1. A requisic¸˜ao do cliente: REQ =
HJI

[requisic¸˜ao]

Essa mensagem pode ser um dos alvos preferidos por um oponente para a gerac¸˜ao de um ataque por repetic¸˜ao (replay). Uma vez interceptada, a mes- ma poderia ser incansavelmente apresentada para a empresa solicitando um mesmo servic¸o. No entanto, como a mensagem ´e assinada pelo cliente e o seu conte´udo n˜ao pode ser alterado, facilmente poderia se identificar tal ata- que atrav´es de testes com regras de consistˆencia das mensagens. Uma outra alternativa para se resolver este problema, seria a determinac¸˜ao de um tempo de validade para a mensagem atrav´es de um carimbo de tempo (time stamp) no momento da requisic¸˜ao. Maiores detalhes sobre time stamp podem ser encontrados no cap´ıtulo 4

2. A empresa recebe a requisic¸˜ao:

Ao receber uma requisic¸˜ao do cliente, a empresa gera um resumo (hash da mensagem e envia para a AD para que este seja datado:

RESUMO REQ =
K

[Hash(REQ)]

Esse processo faz parte de um protocolo espec´ıfico para a datac¸˜ao de docu- mentos eletrˆonicos e ´e considerado seguro e confi´avel pelo protocolo propos- to;

PROTOCOLO REQ =
! L

[RESUMO REQ  DATA  HORA]

Essa mensagem tamb´em ´e parte integrante do protocolo de datac¸˜ao citado acima e portanto, tamb´em ´e considerada neste caso, segura;

4. Composic¸˜ao e envio do recibo da requisic¸˜ao (RR) para o cliente: RR = [REQ  PROTOCOLO REQ]

Essa mensagem comprova a requisic¸˜ao do cliente e o aceite de execuc¸˜ao pela empresa. Como encontra-se datada, passa a ser um documento oficial do pro- tocolo, podendo ser utilizada como prova. Logo, a sua captura e apresentac¸˜ao permitir´a o acionamento da autoridade fiscalizadora da empresa a qualquer momento. Entretanto, como a AF tamb´em tem em seu banco de dados uma c´opia, (tanto da requisic¸˜ao como do fechamento), ela poder´a verificar facil- mente a fraude, acionando a empresa somente se a sua apresentac¸˜ao for pro- cedente.

Caso o envio da mensagem seja interrompido por um intruso e o prazo de resposta `a requisic¸˜ao se esgote, o cliente poder´a acionar a autoridade de aviso para que esta estabelec¸a contato com a empresa. Com isso, a empresa tomar´a conhecimento da interrupc¸˜ao da mensagem;

5. C´opia do recibo que ´e remetida para a autoridade fiscalizadora:

Sendo a mesma mensagem do passo anterior e servindo apenas para atualizar o banco de dados da AF, ela n˜ao ´e fundamental neste momento. Caso haja uma reclamac¸˜ao por parte do cliente e a AF n˜ao tenha os devidos registros dos recibos, a empresa poder´a ser intimada de qualquer forma;

6. O fechamento da OS:

Para gerar o comprovante de fechamento (FEC), ap´os a empresa fechar a OS, ela dever´a dat´a-la para comprovar o prazo de atendimento ao cliente com o envio da seguinte mensagem para a AD:

RESUMO FEC =
K

[Hash(OS)]

Assim como acontece na requisic¸˜ao, esse processo faz parte de um protocolo espec´ıfico para a datac¸˜ao de documentos eletrˆonicos e ´e considerado seguro e

confi´avel pelo protocolo proposto, dispensando a an´alise de poss´ıveis ataques; 7. A datac¸˜ao do fechamento:

PROTOCOLO FEC =
! L

[RESUMO FEC  DATA  HORA]

Essa mensagem ´e gerada pelo protocolo de datac¸˜ao e portanto, considerada segura;

8. Composic¸˜ao e envio da solicitac¸˜ao de fechamento da OS (FEC) para o cliente: FEC = [OS  PROTOCOLO FEC]

A utilizac¸˜ao maliciosa dessa mensagem, pouco poder´a afetar o protocolo, pois, qualquer entidade participante poder´a verificar o seu conte´udo, obser- vando que se trata de uma requisic¸˜ao e de uma OS em espec´ıfico, inclusive com datac¸˜ao.

Caso o envio da mensagem seja interrompido por um intruso e o prazo de aten- dimento se esgote, o cliente poder´a reclamar com o seu recibo de requisic¸˜ao (RR) junto `a AF. Se a AF recebeu o FEC, ela poder´a retransmiti-lo ao cliente, caso contr´ario, ela intimar´a a empresa;

9. C´opia da solicitac¸˜ao de fechamento da OS (FEC) que ´e remetida para a auto- ridade fiscalizadora:

Sendo a mesma mensagem do passo anterior e servindo apenas para atualizar o banco de dados da AF, ela n˜ao ´e fundamental neste momento. Caso haja uma reclamac¸˜ao por parte do cliente e a AF n˜ao tenha os devidos registros dos recibos, a empresa poder´a ser intimada;

10. O recibo de fechamento: RF =
HM

[FEC]

O cliente precisa assinar o fechamento da transac¸˜ao (FEC) para comprovar que a mesma foi conclu´ıda. Se tratando de uma requisic¸˜ao e de uma OS em espec´ıfico, e podendo isso ser verificado facilmente, essa mensagem de nada serve para um oponente do protocolo. Caso o seu envio seja interrompido, a empresa poder´a recorrer `a autoridade de aviso ap´os um certo per´ıodo para que

esta estabelec¸a contato com o cliente. Assim o cliente tomar´a conhecimento da interrupc¸˜ao da mensagem.

5.7 Conclus˜ao

Considerando as hip´oteses previstas neste cap´ıtulo como ponto de partida para a implementac¸˜ao, instalac¸˜ao e utilizac¸˜ao do SAC seguro, pode-se considerar o proto- colo seguro e confi´avel para a garantia da qualidade de servic¸os.

A legislac¸˜ao brasileira para o tratamento de transac¸˜oes eletrˆonicas precisa ainda evoluir muito para que as provas geradas pelo protocolo que s˜ao computacional- mente seguras, possam ser utilizadas em casos de lit´ıgio entre as entidades.

Cap´ıtulo 6

Formalizac¸˜ao do SAC Seguro

6.1 Introduc¸˜ao

No cap´ıtulo anterior, o protocolo proposto foi descrito conforme as fases de sua utilizac¸˜ao, por´em, a formalizac¸˜ao do modelo se faz necess´aria para que atrav´es de uma representac¸˜ao matem´atica, seja assegurado o seu funcionamento e efic´acia para a resoluc¸˜ao do problema estudado nesse trabalho. Segundo Tanenbaum [TAN 97], os protocolos s˜ao geralmente complicados e por isso, diversas pesquisas foram re- alizadas com o intuito de se aplicar t´ecnicas matem´aticas formais para a especifica- c¸˜ao e verificac¸˜ao dos mesmos.

Naturalmente, os resultados alcanc¸ados com a an´alise e verificac¸˜ao do SAC seguro poder˜ao ser empregados na fase de implementac¸˜ao do protocolo, proporcionando uma vis˜ao confi´avel do comportamento dos elementos e entidades envolvidas. Para a an´alise e verificac¸˜ao do SAC seguro, ser˜ao empregadas as t´ecnicas das redes de Petri, abordadas na sec¸˜ao 6.2. A an´alise das fases do protocolo ser´a realizada com base nos modelos criados nas redes de Petri na sec¸˜ao 6.3. Os resultados obtidos da modelagem das fases do protocolo, ser˜ao discutidos na sec¸˜ao 6.4.