CAPÍTULO 6 O SERVIÇO TFTPS

Transcrição

1 CAPÍTULO 6 O SERVIÇO TFTPS 6.1 INTRODUÇÃO Como o objetivo desta dissertação é a transferência de dados utilizando um projeto de segurança que atenda às características de privacidade, confiabilidade e integridade do sistema ao usuário, um programa de serviço tem de ser desenvolvido para este fim. Como foi estabelecido, também, no objetivo deste trabalho que a transferência de dados seria feita utilizando-se o protocolo de transporte UDP, tomou-se como base para o serviço do transferência o serviço TFTP, considerado, a princípio, como inseguro para as finalidades que se propõe. Se considerado que este serviço não prevê nenhuma verificação de permissão de acesso nada impede de que o mesmo seja utilizado para obter arquivos de senhas, por exemplo Assim, se utilizado este tipo de serviço de forma a garantir as características que se propôs no início do trabalho este terá atingido seus objetivos. Como explicado na Seção 5.4 não será um único programa que irá fornecer as características que se deseja, mas sim um conjunto de serviços que, a partir deste ponto, será chamado, de forma genérica, de Trivial File Transfer Protocol Secure TFTPS. TFTPS representa uma série de programas que se comunicam entre si e se propõe a fornecer um ambiente computacional que atenda aos requisitos de privacidade, confiabilidade e integridade. São componentes deste serviço: a) O Sistema Autenticador; b) O Sistema Autorizador; e, c) O Sistema de Transferência de Arquivos. Além destes componentes apresenta-se, no final do capítulo, o projeto de interface do programa cliente e as opções da linha de comando dos programas servidores. 83

2 6.1.1 CONVENÇÕES Para melhor descrever as interações de cada um dos sistemas serão utilizadas as seguintes convenções: a) host: nome da máquina gateway do serviço desejado; b) user: nome do usuário; c) S origem : senha da origem. Pode ser do user ou do host; d) U: chave do usuário, de 160 bits. U = f(s user ); e) GW: chave da máquina gateway, de 160 bits. GW = f(s gateway ); f) ALE0, ALE1, : números aleatórios. Cada um destes números aleatórios são, na realidade, dois números de 4 bytes cada, gerados a partir das funções de geração de números aleatórios do sistema tendo a hora atual como semente para o primeiro e, o primeiro número, manipulado, como semente para o segundo. O trecho de código abaixo ilustra sua geração: #define ulong unsigned long int #define BYTELONG sizeof(ulong) #define BYTE2LONG 2*BYTELONG union { /* Cada número aleatório compartilha sua área de memória com um vetor de caracteres */ ulong alebl[2]; uchar ch_alebl[byte2long+1]; } uni; time_t agora; time(&agora); /* Obtém a data/hora atual do sistema */ srandom(agora); /* Inicializa o gerador de números */ /* Os elementos 0 e 1 do campo alebl, da union uni representam os números aleatórios gerados */ for(r = 0; r < 2; r++) { ulong teste, teste1; /* Variáveis auxiliares */ teste = random()%0xffff; teste1 = random()%0xffff; 84

3 /* Formulação usada para a geração dos números aleatórios */ uni.alebl[r] = ((1+(int)(0xFFFF*teste/(0xFFFF+1.0))) << 4) (1+(int)(0xFFFF*teste1/(0xFFFF+1.0))); agora = uni.alebl[r]<<2; /* Manipula o nº gerado */ srandom(agora); /* Reinicializa o gerador */ } g) K: chave de sessão para transferência de dados. Tem como entrada uma combinação de parâmetros exclusivos da conexão em curso, isto é, K = f(p). O trecho de código abaixo ilustra a montagem de uma semente que será usada na geração de uma chave de sessão: #define ulong unsigned long int #define uchar unsigned char #define BYTELONG sizeof(ulong) #define MAXHASH 5*BYTELONG #define MAXHASHBL 14*BYTELONG uchar passuser[maxhash+1]; /* U */ uchar passhost[maxhash+1]; /* GW */ uchar seedk[maxhash+1]; /* K */ uchar operador[bytelong+1]; /* parâmetro exclusivo */ union { /* Estrutura de dados a ser utilizada. Contém o valor da seguinte expressão: E(GW)[E(GW)[ALE2], E(GW)[T]] */ ulong dados[4]; uchar ch_dd[(4*bytelong)+1]; }uni3; /* Obtém um valor inicial para a semente operando U ^ GW */ for(r = 0; r < MAXHASH; r++) seedk[r] = passuser[r]^passhost[maxhash-r]; /* Obtém o parâmetro exclusivo da conexão operando o conteúdo da union */ for(r = 0; r < (BYTELONG-1); r++) operador[r] = (uni3.ch_dd[r+1]<<4) uni3.ch_dd[r]; operador[r] = (uni3.ch_dd[0]<<4) uni3.ch_dd[r]; operador[bytelong]='\x0'; /* Obtém o valor final de K: K ^ parâmetro exclusivo */ 85

4 for(r = 0; r < MAXHASH; r+=4) for(ii = r; ii<4; ii++) seedk[r] = seedk[r]^operador[ii]; seedk[maxhash]='\x0'; h) T: timestamp, número de 4 bytes que contém a informação data e hora; i) E(X)[ ]: criptografa usando a chave X, sobre o conteúdo dos colchetes; e, j) D(X)[ ]: decifra usando a chave X, sobre o conteúdo dos colchetes. A senha do usuário é obtida pela de digitação da mesma no terminal em que o programa cliente estiver executando e a do gateway a partir de arquivo de parâmetros. Este último deve ser apagado logo após a inicialização do serviço. 6.2 SISTEMA AUTENTICADOR É o responsável por confirmar a identidade do usuário permitindo ou negando acesso à rede interna. Ele é composto de duas partes, uma no sistema de autenticação propriamente dito e outra na máquina gateway. A idéia central deste sistema é fornecer, a cada conexão, uma chave de criptografia, exclusiva para cada sessão, chamada de chave de sessão, a partir de outra chave utilizada para autenticar o usuário, chamada de chave do usuário. Optou-se pelo uso de técnicas de criptografia simétrica. Embora o uso de técnicas assimétricas seja mais adequado para esta finalidade, se a combinação de fatores de segurança aqui apresentados funcionar com este tipo de técnica funcionará, ainda melhor, com outra mais adequada. Uma vez feita esta escolha deve-se examinar mais de perto o problema da segurança em um sistema de criptografia simétrico. De acordo com Schneier (1996) a segurança de um sistema simétrico é função de dois itens: a) A resistência do algoritmo a ataques; e, b) O tamanho da chave. 86

5 A resistência do algoritmo a ataques é difícil de ser mensurado. O mais importante é que o código do mesmo se torne público de forma que sua segurança não se baseie em estruturas colocadas dentro do mesmo mas, sim, no tamanho da chave, na sua constituição e na interação entre os diversos elementos do sistema. Portanto, se a chave é o ponto principal, de que tamanho a mesma deve ser? Para se responder à pergunta sobre o tamanho a ser adotado para a chave deve-se, inicialmente, questionar a motivação, a finalidade ou o objetivo que existe em quem se dispõe a quebrar uma chave. É fato incontestável que esta ação exige investimento. Será que o mesmo será recompensado com a obtenção da informação? Dois pontos de vistas bem distintos podem ser considerados: a) O roubo da informação, por si só, somente é compensador se o conteúdo da mesma for suficientemente valioso para arcar com os custos efetuados; ou b) O desafio intelectual. O fato de se conseguir acesso a sistemas aparentemente impenetráveis aguça a mente de estudantes e pesquisadores sem que a informação obtida tenha qualquer valor comercial. Qualquer que seja a ótica, a informação, dado mais importante a ser preservado, está vulnerável. Logo, para a adoção de um tamanho da chave a seguinte premissa deve ser considerada: o tamanho da chave deve ser tal que não exista probabilidade superior a 1 em 2 32 de um atacante com US$ 100 milhões para gastar possa quebrar o sistema num período inferior a um ano, mesmo assumindo que a tecnologia empregada avança a uma taxa de 30% por ano Além desse dado deve-se analisar o aspecto relativo ao tempo de relevância da informação contra o tempo que se gastaria tentando quebrar o sistema. Isto quer dizer que o tamanho da chave deve estar adaptado à validade da informação. A Tabela 6.1 resume alguns tipos de informação, seus períodos médios de validade e tamanhos de chave recomendáveis para cada um: 87

6 TABELA 6.1 TAMANHO DA CHAVE PARA DIFERENTES INFORMAÇÕES Tipo da Informação Tempo de Vida Tamanho Mínimo da Chave Informação militar tática Minutos/horas bits Planos de negócios Anos 64 bits Fórmulas patenteadas Décadas 112 bits Adaptada de Schneier (1996, p. 167). Como, para esta dissertação, o fator segurança é primordial, todos os tamanhos de chave foram super dimensionados. No serviço desenvolvido foram adotados dois tamanhos distintos de chaves: a) Chaves do usuário com 160 bits; e, b) Chaves de sessão com 448 bits. A fase de autenticação é o alvo predileto dos invasores do sistema, particularmente em sistemas simétricos, já que nela são transmitidas as chaves a serem utilizadas durante a sessão. Ataques à informação propriamente dita são mais custosos e demorados já que a mesma, uma ver cifrada, deve ser analisada por métodos criptográficos, geralmente custosos tanto financeira como computacionalmente. Portanto, a chave do usuário, gerada a partir da senha de cada usuário através de uma one way hash function, tem de ser suficientemente longa para resistir por um período de tempo razoável já que alterações constantes de senhas, por mais que sejam ideais em termos de segurança, causam problemas de ordem prática. Implementou-se um período de validade de sete dias para a chave do usuário externo e de trinta dias, para o interno. As chaves de sessão, como o próprio nome diz, são exclusivas de cada sessão. Elas são obtidas a partir de um gerador de números pseudo aleatórios que tem como semente a chave do usuário. Como, na transferência de dados, a informação que pode ser obtida, através de um ataque de análise criptográfica, pode ter um período de validade que ultrapassa o da transferência dos dados, optou-se por utilizar um tamanho grande para que sua análise por meios criptográficos seja demorado e o tempo de validade da informação se perca com o esforço necessário a ser despendido. 88

7 6.2.1 CHAVE DO USUÁRIO Para o protocolo do Sistema Autenticador implementado prevê-se que cada extremidade da conexão, usuário externo e gateway, não necessitem compartilhar nenhum tipo de chave de forma explícita. Como todo sistema de segurança é tão forte quanto o seu ponto mais fraco, no esquema proposto o ponto mais vulnerável é, com certeza, o Sistema Autenticador. Assim o mesmo deve ser configurado de forma a se tornar o menos acessível. Em função desta preocupação é que o mesmo foi posicionado na rede privada, atrás de dois roteadores com filtros de pacotes e utilizando um endereço IP privativo e somente aceitando conexões de máquinas que estejam na DMZ, através de um protocolo específico. Ainda assim é possível que o mesmo sofra algum tipo de ataque como, por exemplo, o conhecido por Man-in-the-middle Attack, situação em que um invasor personaliza um dos elementos da conexão introduzindo mensagens, aparentemente verdadeiras, que podem alterar a lógica do sistema. A proteção a ser dada contra este ataque é o fornecimento de um meio que consiga averiguar se as extremidades que estão se conectando são realmente quem dizem ser. Mas como garantir ao mesmo que o cliente é quem diz ser? O uso de senhas é o primeiro passo. O usuário introduz sua senha, pessoal e intransferível, premissas nem sempre verdadeiras no mundo real, e o servidor, conhecedor desta parte da informação verifica se a mesma está correta. Este é o tipo mais primário de autenticação. Este esquema apresenta uma série de vulnerabilidades. Para contorná-las, ao invés do servidor conhecer a senha do usuário, ele conhece uma one way hash function da mesma, isto é, ao invés de verificar a senha propriamente dita ele deve ser capaz de diferenciar entre senhas válidas e inválidas. Hash functions, segundo Schneier (1996), são funções matemáticas, ou de qualquer outro tipo, que relacionam uma entrada de tamanho variável, chamada de pré imagem, em uma saída de tamanho fixo, chamada de hash value. A one way hash function é uma 89

8 hash function que trabalha numa única direção, isto é, obtém-se o hash value a partir da pré imagem com relativa facilidade mas, o inverso é muito difícil. Além disso, ela deve ser livre de colisões, isto é, a geração de dois hash values a partir da mesma pré imagem tem de ser muito difícil. Uma vez obtidas as hash functions elas devem permanecer à disposição do Sistema Autenticador e, para tal, mantidas em arquivos. Este também é vulnerável a ataques do tipo dictionary attack, onde o invasor reúne uma série de senhas freqüentemente utilizadas e calcula suas respectivas hash functions executando seu ataque pela simples comparação entre os valores obtidos na transmissão com os valores previamente armazenados. Para ser possível evitar esta forma de ataque é crucial que não sejam utilizadas senhas comuns, isto é, senhas que envolvam o nome do usuário, sua data de nascimento e assim por diante. Para o sistema implementado e, de acordo com a política de segurança adotada, o nome do cliente e sua senha devem obedecer às regras: a) O nome do usuário deve ter um número mínimo de 12 caracteres alfanuméricos sendo pelo menos um numérico e outro de pontuação. Não pode ser usado o caracter espaço e o caracter :. Seu tamanho está limitado a um máximo de 23 caracteres. Internamente é feita uma verificação com os demais nomes já existentes para verificar se a soma de todos os seus caracteres, convertidos em inteiros, coincide com algum outro nome. Caso coincida este nome não poderá ser usado; b) A senha deve ter pelo menos 20 caracteres alfanuméricos sendo pelo menos dois maiúsculas e dois minúsculos, pelo menos um caracter numérico, pelo menos um caracter de pontuação e pelo menos uma vez o caracter espaço. Seu tamanho é limitado a 1024 caracteres. Recomenda-se o uso de frases que sejam de fácil memorização. O uso de caracteres ASCII estendidos, acima de 127, são desejáveis mas não podem ser obrigatórios já que, função do terminal que o usuário estiver utilizando, estes podem não ser aceitos. 90

9 A partir do conhecimento da senha do usuário, utilizando-se uma implementação de uma one way hash functions pertencente ao Secure Hash Algorithm (SHA), desenvolvido por Steve Reid, inteiramente de domínio público, obtém-se a chave do usuário. Este algoritmo prevê que qualquer entrada de tamanho menor que 2 64 produz uma saída de 160 bits conhecida por message digest. A descrição do funcionamento deste algoritmo pode ser encontrado em Schneier (1996, p. 442 a 445) CHAVE DE SESSÃO A chave de sessão, gerada de forma pseudo aleatória a cada sessão estabelecida, não precisa ser do conhecimento de todos os elementos participantes do sistema computacional. Somente do servidor de arquivos, para cifrar, e do cliente, para decifrar. A máquina gateway, em alguns momentos precisará desta informação para validar o usuário externo. Nestes momentos a informação necessária lhe é, de alguma forma passada, usada e, a seguir, destruída. Ela é obtida a partir de um gerador de números pseudo aleatórios, desenvolvido por Bill Chambers, de domínio público, obtido do artigo número 139 de sci.crypt.research, de primeiro de março de 1995, sob o título A cryptographic pseudorandom number generator. É uma implementação específica para máquinas cuja representação interna dos inteiros longos seja feita com 32 bits e a representação dos caracteres sem sinal, com 8 bits. A geração do número pseudo aleatório é feito a partir de uma chave de entrada, única para cada sessão, cujo tamanho pode variar entre 256 e 1536 bytes, utilizada para inicializar as tabelas internas do programa. De posse da chave de entrada dois tipos diferentes de algoritmos de criptografia por fluxo são utilizados de forma combinada aproveitando-se o melhor de cada um deles. O algoritmo mais lento é usado para gerar chaves para o mais rápido a cada oito passos, conseguindo, desta forma, anular os métodos de análise criptográficas que necessitam de grandes quantidades de valores de saída para cada valor de chave de entrada. O algoritmo rápido é um gerador de Jenkins, desenvolvido por Bob Jenkins (rjenkins@ us.oracle.com); um modificador de tabelas muito resistente a análises de criptografia. A 91

10 partir de um número pré determinado de interações, informado ao gerador pelo sistema, pode-se obter o número desejado de números aleatórios PROTOCOLO DE AUTENTICAÇÃO O protocolo adotado para autenticação utiliza troca de chaves. Na literatura especializada existem várias referências a protocolos que abordam esse ponto. Nesta dissertação utiliza-se o protocolo de Newton-Stubblebine, descrito em Schneier (1996, p. 60 a 62), um pouco modificado, com alguns conceitos de Needham-Schroeder, também descrito em Schneier (1996, p. 58 e 59). Embora o protocolo Kerberos seja, hoje, um dos mais utilizados para resolver o problema da autenticação, ele depende de uma sincronização de tempos entre as máquinas participantes e, para efeito deste trabalho, principalmente pela diversidade de clientes que podem acessar o sistema, esta sincronização foi considerada como não desejável. Os passos a serem executados por este sistema correspondem aos descritos na Figura 6.1 e são detalhados a seguir. Autenticação 3, 7, 9, 21 Roteador Externo Filtragem de Pacotes Gateway 2, 4, 6, 10, 12, 14 Usuário externo 1, 5, 11, 13 Fig. 6.1 Roteador Interno Filtragem de Pacotes Passos a serem executados pelo serviço TFTPS pelo Sistema Autenticador Passo 1. O usuário entra com sua senha S user, a qual é validada, e, então, gerada uma one way hash function U. Gera-se um número aleatório ALE que é criptografado com a chave U. Remete para o gateway a mensagem: 92

11 user, E(U)[ALE]; Passo 2. O gateway gera um número aleatório ALE2 e o criptografa tendo GW como chave. Gera um timestamp que também é criptografado. Remete, para o Sistema Autenticador, a mensagem: host, user, E(U)[ALE], E(GW)[E(GW)[ALE2], E(GW)[T]]; Passo 3. O serviço de autenticação verifica a existência do host e do user no seu banco de dados obtendo, do mesmo, S gateway e S user. Descriptografa a mensagem usando as chaves apropriadas para cada pedaço da mesma. Verifica a validade da sessão do usuário, isto é, se não há uma sessão já ativa para o mesmo usuário, situação não permitida e atualiza o banco de dados com o timestamp recebido. Opera ALE m = ALE 1. Gera a chave de sessão K. Remete para o gateway a mensagem: E(U)[E(U)[ALE m, K, T], ALE2, E(GW)[user, K, T]]; Passo 4. Passo 5. O gateway repassa a mensagem recebida para o usuário; O programa do usuário decodifica a parte da mensagem cifrada com sua chave obtendo ALE m, que é confrontado com ALE. Se os valores não são diferentes em uma unidade encerra a execução do programa, caso contrário prossegue o processamento obtendo K, T e ALE2 e operando ALE2 m = ALE2 1. Remete para o gateway a mensagem: E(K)[ALE2 m ], E(GW)[user, K, T]; Passo 6. O gateway decodifica a parte da mensagem cifrada com sua chave obtendo user, K e T. De posse de K obtém ALE2 m que é comparado com ALE2. Se os valores não são diferentes em uma unidade encerra o processamento, caso contrário verifica o nome do usuário e o timestamp. Nestas duas últimas comparações caso haja qualquer discrepância o processamento é encerrado. Uma vez usado o valor de K este 93

12 é imediatamente excluído da memória. Remete para o servidor de arquivos a mensagem: user, E(GW)[K, T]; Passo 7. Servidor de arquivos remete para o Sistema Autorizador mensagem para obter relação de disponibilidades para o usuário: E(GW) [user, T] Passo 9. Recebe relação de disponibilidades do Sistema Autorizador e as repassa para o gateway do serviço. Passo 10. Gateway do serviço recebe mensagem e a repassa para cliente. Passo 11. O cliente, de posse dos nomes dos arquivos que pode dispor ou do diretório para o qual pode transferir arquivos, está apto a solicitar uma tarefa de escrita ou de leitura. Em qualquer um dos casos, antes do pedido do serviço a ser executado nova autenticação será executada, a cada nova uma solicitação. Para tal gera um número aleatório ALE3 e remete para o gateway a mensagem: E(GW)[user, K, T], E(K)[ALE3]; Passo 12. O gateway do serviço decodifica a parte da mensagem cifrada com sua chave e extrai o nome do usuário, o timestamp e a chave de sessão. De posse destas informações age como no Passo 6 acima. Neste ponto o valor de K não é imediatamente apagado da memória. Aguarda-se a próxima mensagem para aí então apagá-lo. Gera o número aleatório ALE4 e remete para o usuário a mensagem: E(K)[ALE3 m, ALE4]; Passo 13. O usuário verifica ALE3 m. Se não forem diferentes em uma unidade encerra a execução caso contrário faz ALE4 m = ALE4 1. Deste ponto em diante o cliente já considera o gateway autenticado. Portanto, além da parte relativa à autenticação, envia o pedido do serviço so- 94

13 licitado pelo usuário. A mensagem, no que diz respeito a autenticação, contém: E(K)[ALE4 m ] Passo 14. O gateway obtendo ALE4 m irá verificá-lo. Caso não esteja diferente de uma unidade do valor ALE4 encerra a execução, caso contrário inicia a transferência de arquivos; Passo 21. De posse do nome do host e consequentemente da sua chave, obtém T e atualiza o campo do registro do usuário com o horário de término da conexão SERVIÇO DE AUTENTICAÇÃO O programa do usuário inicia a conexão com o gateway do serviço desejado. Uma vez estabelecida a conexão um processo filho é criado no gateway. Esse novo processo é o responsável por se comunicar com o servidor de autenticação e responder ao cliente. Como são vários passos envolvidos no processo de autenticação, a descrição do programa seria muito difícil. Portanto o mesmo será explicado a partir de um diagrama de transição de estados, onde se utilizam os seguintes códigos de operação: a) OP_USR código do usuário solicitando autenticação; b) OP_AUT código do gateway solicitando autenticação do servidor de autenticação ou código do usuário respondendo a 1ª fase da autenticação ou do usuário informando que ele está solicitando confirmação de autenticação; c) OP_AUTOK, OP_AUTERR, OP_AUTFAIL códigos de resposta do servidor de autenticação indicando que o usuário consta de seu banco de dados e está autorizado a continuar, que houve algum erro no protocolo ou que há problema com o acesso deste usuário, respectivamente; d) OP_AUTH código do gateway solicitando autorização através do servidor de arquivos confidenciais; 95

14 e) OP_AUTHOK, OP_AUTHERR, OP_AUTHFAIL código de resposta do servidor de autorização indicando que o usuário consta de seu banco de dados e está autorizado a continuar, de que houve algum erro no protocolo ou de que há problema com o acesso deste usuário, respectivamente; f) OP_AUTERRO ou OP_AUTHERRO quando a resposta recebida é qualquer um dos códigos de erro anteriormente listados; g) OP_QUIT código do usuário emitido toda vez que o usuário termina a execução do seu programa; h) OP_RRQ, OP_WRQ códigos do usuário que requisitam operações de transferência de arquivos após validação da autenticação; e, i) - representam qualquer código, válido ou não. A Figura 6.2 ilustra a máquina de transição de estados para os Passos 1 a 10 da Figura 6.1. Embora haja o Passo 8, pertencente ao Sistema de Autorização, embutido dentro da apresentação do funcionamento do Sistema de Autenticação, a lógica do relacionamento entre os programas impõe que o mesmo seja apresentado neste ponto. Numa máquina de transição de estados, ou de estados finitos, uma ação somente é tomada função de duas entradas, neste caso enviado e recebido. Além do que a ação a ser executada é função do valor assumido pelas duas variáveis de controle. 96

15 AGUARDA recebido: OP_USR Servidor de Autenticação Servidor de Arquivos Confidenciais enviado: OP_AUT recebido: OP_AUTOK recebido: OP_AUTERR recebido: OP_AUTFAIL enviado: OP_AUTH recebido: OP_AUTHOK recebido: OP_AUTHERR recebido: OP_AUTHFAIL Processo Filho recebido: OP_USR enviado: OP_AUT REC USR recebido: OP_AUTERRO ENVIA AUT enviado: 0 enviado: OP_AUT recebido: OP_AUTOK enviado: OP_AUT recebido: OP_AUTH enviado: OP_AUTH REC AUT recebido: OP_AUTHERRO enviado: OP_AUTH recebido: OP_AUTHOK Termina Processo Filho ENVIA ERRO ENVIA AUTH 3 CLOSE TCP 2 1 Fig. 6.2 Diagrama de transição de estados da primeira parte da autenticação de um cliente pelo Sistema Autenticador. Na Figura 6.2 a máquina gateway permanece aguardando uma conexão. Na hora em que chega uma requisição de um cliente há criação de um processo filho para tratar do serviço se o código do protocolo constante da mensagem que chegou for OP_USR. Sendo ou não este o código presente o servidor retorna à situação de ficar aguardando novas conexões. A primeira etapa a ser cumprida pelo novo processo criado é a autenticação do cliente utilizando a máquina de estados finitos ilustrada. Ela é inicializada considerando que o servidor enviou o código 0 (ainda não enviou nada) e recebeu OP_USR. Este par de códigos conduz ao conjunto de rotinas que executa a ação REC_USR. Dentre outras coisas 97

16 ele se comunica com o Sistema de Autenticação para validar o usuário enviando uma mensagem com o código OP_AUT. Ele pode receber do servidor de autenticação o código OP_AUTOK ou OP_AUTERRO. Se erro vai para o conjunto de ações ENVIA ERRO e termina a execução do processo. Se a autenticação se deu com sucesso vai para o próximo conjunto de rotinas ENVIA AUT, já que as variáveis de controle contém os valores OP_AUT e OP_AUTOK para enviado e recebido, respectivamente. Se recebido o código OP_AUTH o novo par conduz para o conjunto REC_AUT que, dentre outras coisas, se comunica com o Servidor de Arquivos que é o responsável por se comunicar com o Sistema de Autorização, enviando-lhe o código OP_AUTH. Ele pode receber o código OP_AUTH ou OP_AUTHERRO do servidor de arquivos. Se erro vai para o de ações ENVIA ERRO e termina a execução do processo. Se a autorização se deu com sucesso vai para o próximo conjunto de rotinas ENVIA AUTH, já que as variáveis de controle contém os valores OP_AUTH e OP_AUTHOK para enviado e recebido, respectivamente. Finalmente fecha o socket para o protocolo de transporte TCP usado para a autenticação. Os elementos de ligação numerados por 1, 2 e 3 representam pontos de entrada ou de saída desta máquina de transição de estados para sua continuação. A continuação do processo de autenticação, no servidor, se dá com os Passos 11 a 14 com a confirmação da autenticação do cliente e do servidor no instante em que há uma requisição de serviço de transferência de arquivo. A máquina de transição de estados para esta nova fase encontra-se ilustrada na Figura

17 1 3 REPITA ATÉ OP_QUIT FECHA CONEXÃO TCP AGUARDA CONEXÃO UDP enviado: OP_AUT REC AUT1 recebido: OP_AUTFAIL enviado: OP_AUTH recebido: OP_AUTOK ENVIA AUT enviado: OP_AUTH recebido: OP_AUT Máquina de Transição de Estados da Transferência de Arquivos enviado: OP_AUTOK recebido: OP_RRQ/OP_WRQ enviado: OP_AUTOK REC RRQ/WRQ recebido: OP_AUTHFAIL enviado: OP_AUTOK recebido: OP_RRQ/OP_WRQ enviado: recebido: OP_ERRO 2 Fig. 6.3 Diagrama de transição de estados da segunda parte da autenticação de um cliente pelo Sistema Autenticador. Uma vez terminada a primeira fase da autenticação o cliente está apto a solicitar uma requisição de serviço. A cada requisição que ele faz o esquema ilustrado na Figura 6.3 é repetido confirmando sua autenticação. Nesta fase do programa a conexão com o cliente já não utiliza mais o protocolo de transporte TCP mas sim o UDP. É o cliente quem, uma vez mais, se conecta ao servidor enviando uma mensagem cujo código do protocolo tem de ser OP_AUT. Qualquer outro código o processo filho é imediatamente encerrado. Tendo o par correto das variáveis de controle o conjunto de rotinas REC_AUT1 é acionado para revalidar a autenticação do usuário sem a necessidade de acessar o servidor de autenticação. 99

18 A validação do usuário pode resultar em dois resultados. Se OP_AUTFAIL é automaticamente encerrado o processo filho. Se OP_AUTOK o conjunto de rotinas ENVIA AUT é acionado. Nesta situação a variável de controle assume OP_AUTOK. O usuário enviando OP_RRQ ou OP_WRQ estará terminando o processo de autenticação e solicitando um serviço de transferência de arquivos. Para este par de variáveis de controle o conjunto de rotinas REC RRQ/WRQ é acionado. Sua execução pode resultar em dois códigos: OP_AUTOK ou OP_AUTFAIL. Se erro termina o processo imediatamente. Se autenticado chama a máquina de transição de estados para tratar da transferência de arquivos. Finalmente deve-se reparar que esta última seqüência de operações é sempre executada até que o código OP_QUIT seja enviado pelo cliente ou que haja erro na transmissão do arquivo. Em ambas as situações o processo filho é imediatamente encerrado. O programa cliente que interage com o servidor tem de possuir passos que tenham um correspondente direto com o que foi desenvolvido para o servidor sendo que, neste caso, todo o processamento é realizado na máquina do cliente. A máquina de transição de estados do cliente, para a primeira fase da autenticação, encontra-se ilustrada na Figura

19 Entra com nome do usuário e senha Gera U CONECTA SERV. ENVIA USR Termina Programa Cliente enviado: OP_USR recebido: 0 enviado: OP_USR REC AUT recebido: OP_AUTERRO ENVIA AUT enviado: OP_USR recebido: OP_AUTOK REC ERRO REC AUTH enviado: OP_AUTH recebido: OP_AUTHERRO enviado: OP_AUTH recebido: OP_AUTHOK Relação de disponibilidades 2 3 CLOSE TCP 1 Fig. 6.4 Diagrama de transição de estados para a primeira parte do programa cliente. O cliente inicia seu processamento dando como entrada seu nome e sua senha. A one hash function da senha é calculada. Estabelece a conexão com o gateway e inicia a transferência de dados enviando mensagem contendo o código de operação OP_USR. Processada esta mensagem no servidor a mensagem resposta pode conter um de dois valores: OP_AUTOK ou OP_AUTERRO. Se erro o conjunto de rotinas REC ERRO é acionado e a execução do processo encerrado. Caso contrário o conjunto de rotinas ENVIA AUT é chamado quando se envia mensagem com o código OP_AUTH. 101

20 O módulo REC_AUTH é chamado seqüencialmente e, uma vez mais, duas respostas são possíveis: OP_AUTHOK ou OP_AUTHERRO. Em caso de erro REC_ERRO é acionado e o processo encerrado. Caso contrário o usuário é considerado autenticado, a relação de arquivos disponíveis para operações é conhecida e a conexão via TCP encerrada. Os elementos de ligação numerados por 1, 2 e 3 representam pontos de entrada ou de saída desta máquina de transição de estados para sua continuação. A continuação do processo cliente ocorre conforme ilustrado na Figura REPITA ATÉ EXIT/^C Não ABRE CONEXÃO UDP Sim FECHA CONEXÃO UDP Término normal da transmissão Sim EXIT/^C Não ENVIA OP_AUT enviado: OP_AUT recebido: OP_AUTHOK REC AUT enviado: OP_AUT recebido: OP_AUTERRO enviado: OP_AUT recebido: OP_AUTOK ENVIA RRQ/WRQ enviado: OP_RRQ/OP_WRQ recebido: OP_AUTOK 2 Máquina de Transição de Estados da Transferência de Arquivos enviado: recebido: OP_ERRO Fig. 6.5 Diagrama de transição de estados para a segunda parte do programa cliente. 102

21 Para que o cliente solicite um serviço de transferência de arquivos ele tem de confirmar sua autenticação. Assim ele entra numa parte do código que permite que o mesmo solicite o serviço desejado tendo, para tal que confirmar sua autenticação a cada requisição. O processo é executado até que o cliente interrompa sua execução pela digitação do comando exit ou pressionando Ctrl + C. O início desta fase, para o cliente, é totalmente transparente. Ele digita o comando get ou put, conforme queira obter ou transferir um arquivo. Internamente este comando é traduzido para um código de protocolo OP_AUT que é enviado ao servidor do serviço desejado. A este passo duas respostas são possíveis. Se não confirmada a autenticação, OP_AUTERRO recebido, o processo cliente é imediatamente encerrado. Caso contrário ele executa um conjunto de rotinas que irão validar o servidor e enviar a requisição propriamente dita juntamente com a fase final da autenticação cujo objetivo é permitir ao gateway autenticar o cliente. Finalmente, após esses passos, entra-se na máquina de estados finitos para a transferência de arquivos. Qualquer condição de erro termina o processo cliente imediatamente enquanto que se tudo ocorrer a contento retorna-se à linha de comando aguardando novo comando do cliente que pode solicitar outro serviço ou encerrar seu processamento. O banco de dados para controlar a autenticação pode ser implementado de várias formas. Para efeito de simplicidade implantou-se um sistema constituído de um arquivo texto chamado de chaves.has onde cada linha corresponde a um registro, único para cada usuário ou máquina autorizada a acessar o Sistema Autenticador. Este registro é constituído dos seguintes campos, na ordem indicada, todos separados por : : Nome do Usuário/host: One way hash function da senha do usuário/host: timestamp da criação do registro: tempo de vida do registro: timestamp início sessão O campo nome do usuário/host contém o nome do usuário ou da máquina que estão autorizados a acessar o servidor de autenticação. 103

22 O campo seguinte informa a one way hash function da senha do usuário ou da máquina. Os dois campos seguintes são para controle. O timestamp da criação do registro é lido a cada autenticação e serve para verificar se o usuário, ou máquina, que está acessando o servidor tem seu registro válido função da política de segurança da organização. Na mensagem que chega ao servidor de autenticação há um campo para o timestamp do gateway do serviço desejado. Este então é comparado com o que está no registro do banco de dados, somado do campo tempo de vida do registro, para verificar se o prazo estipulado pela política de segurança é válido. Como este registro utiliza o tempo do gateway do serviço é necessário que os relógios de todos os serviços estejam sincronizados e, na hora da criação do registro, haja uma comunicação com um deles para colocação do valor correto. O último campo é um alerta a tentativas de invasão tendo como valor padrão zero. No momento da autenticação este campo é substituído pelo o valor do timestamp que chega na mensagem do gateway do serviço desejado. Toda vez que uma comunicação termina, ou é interrompida, o servidor de autenticação deve ser informado de tal forma que este campo retorne ao valor padrão. Desta forma, caso um usuário tente realizar autenticação enquanto seu registro contiver um valor diferente de zero, neste campo, a autenticação será negada. É uma política restritiva já que um usuário somente poderá estabelecer uma única sessão por ver por mais que tenha autorização para realizar vários serviços mas, pelo ponto de vista da segurança, mais adequada. O programa do servidor de autenticação tem seu funcionamento ilustrado conforme a Figura

23 Processo Pai Repetir infinitamente Recebe mensagem da máquina gateway do serviço Processo Filho Fecha socket do processo pai Cria novo socket Procura por host no BD Não Host pertence à rede privada? Sim Cria processo filho Não Envia mensagem de erro existe host? Sim Envia mensagem de erro Fecha socket/processo Procura por user no BD Envia mensagem de erro Fecha socket/processo Envia mensagem de erro Fecha socket/processo Não Não Existe user? Calcula tempo de vida É válido? Processamento Grava T da sessão Envia mensagem informando sucesso Sim Sim Fig. 6.6 Fluxograma do servidor de autenticação. Fecha socket/processo Como se pode ver na Figura 6.6 o servidor é executado em dois processos. O pai que somente atente às requisições dos interessados e o filho que executa o processamento propriamente dito. 105

24 Deve ser lembrado o fato de que as máquinas gateway possuem duas NIC, uma com endereço público e outra com endereço privado. Como somente máquinas da rede privada podem acessar o servidor o processo pai realiza esta verificação função da máscara de rede adotada. Somente se pertencer à rede privado é que o processo filho será criado. Este, por sua vez é quem examina o banco de dados. Procura pelo nome do host obtendo sua one way hash function, caso exista. Idem para o nome do usuário. Terminada esta etapa gera a chave de sessão, atualiza o registro do usuário com o timestamp recebido, envia mensagem ao gateway e encerra seu processamento. Como há necessidade de escrever no banco de dado e uma série de processos concorrentes podem estar tentando acessá-lo ao mesmo tempo foi introduzido um mecanismo de semáforo de tal forma que cada acesso seja exclusivo tanto para leitura como para escrita. 6.3 SISTEMA AUTORIZADOR É o responsável por informar os direitos e as permissões de acesso de um determinado usuário, ou máquina, aos serviços da rede interna da organização. Ele, como o sistema autenticador, é constituído de duas partes: uma no sistema de autorização e outra no sistema de transferência de arquivos. A idéia central é ter um único local que concentre todos os direitos e restrições dos vários componentes do sistema computacional. Isto é feito mantendo-se um banco de dados que contém as informações necessárias PROTOCOLO DE AUTORIZAÇÃO Os passos a serem executados por este sistema correspondem aos descritos na Figura 6.7 e são detalhados a seguir. 106

25 Roteador Externo Filtragem de Pacotes Gateway Autorização 8, 19 Roteador Interno Filtragem de Pacotes Fig. 6.7 Passos a serem executados pelo serviço TFTPS pelo Sistema Autenticador Passo 8. Uma vez estabelecida a conexão do gateway com o servidor de arquivos este último estabelece conexão com o servidor de autorização enviando-lhe a mensagem: E(GW) [user, T] De posse desta mensagem e do conhecimento da senha da máquina gateway ele obtém o nome do usuário e o timestamp do início da sessão. Procura em seu banco de dados o registro correspondente ao usuário, caso exista atualiza os campos necessários e monta uma nova mensagem a ser enviada ao servidor de arquivos, criptografado com a senha do gateway, contendo o conjunto de permissões do usuário; Passo 19. Recebida a mensagem do servidor de arquivos atualiza o registro do usuário no banco de dados com as tarefas executadas pelo mesmo. O relacionamento deste Sistema com os demais componentes do sistema computacional se dá conforme ilustrado na Figura

26 Servidor de Arquivos REC AUTH OP_AUTH OP_AUTHERRO REC AUT Servidor OP_AUTH de OP_AUTHFAIL Autorização ou OP_AUTHNUL 1 1 Cria processo UDP filho ENVIA AUTH Termina processo UDP filho OP_AUTHOK ou OP_AUTHERRO Gateway do Serviço Fig. 6.8 Relacionamento do Sistema Autenticador com os demais elementos do sistema computacional FORMATO DO REGISTRO DE AUTORIZAÇÃO A mensagem de autorização é montada função do conteúdo do banco de dados do Sistema Autorizador. Portanto é fundamental a implementação de uma formatação de cada registro neste banco de dados de tal forma que o mesmo traduza a informação desejada com exatidão. Para esta implementação simples propõe-se um esquema constituído de dois arquivos texto. Em um deles, sgbd.ind, há o nome do usuário e a posição do registro do usuário no arquivo sgbd.txt. Neste último cada linha corresponde a um registro único de cada usuário. Ele é constituído dos seguintes campos, na ordem indicada, todos separados por : : Nome do Usuário: Nome do host para download: Diretório Download: Nome do host para upload: Diretório Upload: Número Máximo para arquivos de upload: Tamanho máximo de cada arquivo: Byte controle 1: Arquivo1 download: Byte controle 2: Arquivo2 download:...: Byte controle n: Arquivo n download: timestamp criação do registro: tempo de vida do registro: timestamp início sessão: timestamp término sessão O campo Nome do Usuário é o mesmo constante do banco de dados do Sistema Autenticador. Para facilitar as buscas o banco de dados será ordenado pelo campo Nome do Usuário. 108

27 O campo Nome do host para download informa o nome da máquina onde o usuário tem acesso para executar esta tarefa. É aconselhável o uso de máquinas diferentes para serviços de download e de upload. Esta afirmação se justifica tendo-se em vista que o conteúdo do arquivo transferido é desconhecido podendo ter componentes programados que podem interferir nos procedimentos da rede como vírus e cavalos de tróia. O campo Diretório de download, informa qual diretório, no servidor de arquivos anteriormente especificado, que o usuário pode acessar. Para esta dissertação foi utilizado o diretório /home/arqpub/down/nome_do_usuário/. Como ele é constante, no nosso e na maioria dos casos, ele não precisa ser explicitamente informado sendo substituído por 0. O campo Nome do host para upload, como o nome diz, informa o nome da máquina para a qual devem ser transferidos os arquivos de upload. O campo Diretório de upload, informa qual diretório, no servidor de arquivos anteriormente especificado, o usuário pode acessar para executar este serviço. Para esta dissertação este diretório será sempre /home/arqpub/up/nome_do_usuário/. Como no caso de diretório padrão para download, também, pode ser substituído por 0. Os dois campos de diretório constam do registro do usuário para permitir maior flexibilidade ao administrador do sistema. A condição padrão é a acima descrita. Caso o programa encontre algo diferente de espaço em branco nestes campos ele automaticamente carrega a informação aí constante. O campo Número máximo de arquivos para upload, refere-se ao número máximo que o usuário pode transferir por sessão. É possível configurar o sistema de maneira a controlar o intervalo de tempo entre as sessões. Implementou-se o valor de 24 horas. O campo Tamanho máximo de cada arquivo, refere-se ao tamanho máximo a ser aceito para transferência. Esta informação é controlada de duas formas. A primeira, que se encontra no programa do usuário, se nega a transferir arquivos que sejam maiores do que o permitido e, a segunda, no servidor de arquivos que interrompe a recepção dos dados quando atingido o valor máximo definido. 109

28 Os campos ArquivoN download, informam os nomes dos arquivos disponíveis para download dentro da área do usuário. Uma vez mais o acesso aos arquivos é controlado de duas maneiras, uma no programa do usuário e outra no servidor de arquivos. Em ambos os controles caso haja uma solicitação de transferência de um arquivo que não conste da relação autorizada esta não será validada. Os campos Byte controle N, referem-se a um byte de controle que pode ser utilizado para controlar o status dos arquivos disponibilizados para o usuário. Sua configuração encontra-se ilustrada na Figura 6.9. Fig Bit Descrição 1 Se ativado o arquivo pode ser transferido inúmeras vezes; 2 Se ativado indica que o arquivo já foi transferido; 3 Se ativado indica que o arquivo foi transferido com erro. Deve ser ativado juntamente com o bit 2. Indica que o usuário pode tentar descarregar este arquivo numa nova sessão; 4 Reservado para uso futuro 5 Reservado para uso futuro 6 Reservado para uso futuro 7 Reservado para uso futuro 8 Reservado para uso futuro Campo Byte de controle N do banco de dados do Sistema de Autorização. Uma vez chegada a solicitação de serviço, no registro do usuário, somente são lidos os nomes dos arquivos se: a) o bit 1 está ativado; b) o bit 1 e o bit 2 estão desativados; e, c) o bit 1 está desativado e os bits 2 e 3 ativados. 110

29 Quando do término de uma transferência o bit 2 é sempre ativado, independentemente de como ocorreu o término da conexão. No caso de uma transferência bem sucedida é a única alteração a ser feita. No caso de mal sucedida além dele o bit 3 também é ativado. Sempre que bit 1 estiver ativado os demais bits, também ativados, não têm significado especial. O campo timestamp de criação do registro, é o mesmo armazenado no banco de dados do Sistema Autenticador. É o campo a ser consultado pelo programa de atualização do banco de dados. Cada registro tem um tempo de vida que não pode exceder uma semana, valor default, para esta dissertação. Existirão duas situações onde o registro do cliente deixa de existir, por tempo ou por término de tarefa, isto é, quando todos os arquivos que não tenham o bit 1 ativado tenham sido transferidos e o usuário não tiver permissão para upload. O campo tempo de vida do registro, indica o tempo que o registro pode permanecer ativo. Se contiver o valor 0 indica que se está utilizando o valor default do sistema que é de uma semana. Se contiver o valor 1 indica que o registro terá tempo indeterminado e qualquer outro valor corresponde ao tempo concedido ao usuário para que o mesmo utilize o sistema. Os demais campos, como seus nomes indicam, representam informações para controle estatístico do acesso ao sistema SERVIÇO DE AUTORIZAÇÃO O acesso ao serviço de autorização somente pode ser feito através dos servidores dos serviços da rede interna da organização. Como, para esta dissertação, somente está sendo considerado o servidor de arquivos este será o único que pode ter acesso a esta máquina. Recomenda-se o uso de servidores de autorização distintos, um para cada serviço, de forma a facilitar a gerência e aumentar a segurança. Todo os demais acessos à esta máquina deve ser feita de forma local e somente pelo administrador do sistema. Este serviço é responsável por verificar os direitos concedidos a determinado usuário a partir do registro de permissões do usuário, no seu banco de dados, repassando as in- 111

30 formações necessárias para que o servidor de arquivos continue o processamento. Sua tarefa é, portanto, buscar no banco de dados a existência do nome do cliente e, caso exista o registro, ler seu conteúdo. Verifica, então, a validade da requisição através do tempo de vida do registro e monta um pacote de dados para o servidor de arquivos que passa a ser o responsável por cuidar da transferência e recepção dos arquivos. A verificação da validade da requisição é feita comparando-se o timestamp recebido com o timestamp da criação do registro mais o tempo de vida do registro. Caso a requisição seja válida ele monta a mensagem de retorno para o servidor de arquivos confidenciais. Esta mensagem é constituída das informações constantes do registro do cliente ou substituídas por 0 no caso de valor padrão. Todas as informações são separadas por \ e entre as informações de download e de upload por \\. Portanto, para um usuário que tem permissão para ler o arquivo abcde.txt no diretório default /home/arqpub/down/ nome_do_usuário, da máquina , teria uma mensagem de retorno do tipo: \0\abcde.txt Outro usuário que tenha permissão de leitura para este mesmo arquivo além de permissão de escrita para 5 outros arquivos, de 16Kb cada um, tudo na máquina , receberia a seguinte mensagem: \0\abcde.txt\\ \0\5\16 Uma vez montado a mensagem de retorno esta será criptografada utilizando-se a senha do gateway e transferida para o servidor de arquivos. A senha do gateway a que se refere este servidor de autorização, caso usado um para cada serviço disponível, é compilada juntamente com o código, por motivos de segurança. Para esta dissertação o número máximo de arquivos que podem ser disponibilizados é de 10 arquivos, por usuário, quando ele possui direito a executar operações de download e a upload ou de 12 arquivos quando o mesmo não tem permissão de executar upload. 112

31 O servidor de autorização tem seu funcionamento representado através do fluxograma constante da Figura Processo Pai Processo Filho Não Envia mensagem de erro Repetir infinitamente Recebe mensagem solicitando autorização para user endereço servidor conhecido? Sim Cria processo filho Fecha socket do processo pai Não Cria novo socket D(GW)[user,T is ] Procura por user em sgbd.ind Envia mensagem de erro Fecha socket/processo existe user? Sim Procura em sgbd.txt Envia mensagem de erro Fecha socket/processo Envia mensagem: OP_AUTHFAIL Fecha socket/processo Não Não Registro? Calcula tempo de vida É válido? Grava T is Envia mensagem de sucesso na autorização Sim Sim Fecha socket/processo Fig Fluxograma de funcionamento do módulo de autorização. O servidor de autorização permanece aguardando uma conexão do servidor de arquivos confidenciais. Quando ocorre uma conexão ele verifica o endereço da máquina que re- 113

32 meteu o datagrama para ver se ela está autorizada a se comunicar com o serviço. Caso esteja cria um processo filho para tratar do serviço e retorna à condição de espera. O processo filho então passa, então, a executar os passos necessários para determinar se o usuário está autorizado a acessar o serviço solicitado e, se estiver, quais são seus direitos. Quando o serviço de transferência de arquivos termina, novo acesso ao servidor de autorização é feito pelo servidor de arquivos para que o registro do usuário seja atualizado com o serviço executado. Esta conexão somente é feita após a máquina gateway do serviço enviar mensagem informando que todos os pacotes foram recebidos pelo usuário. Esta confirmação é importante uma vez que, a simples atualização do registro do cliente pode fazer com que, com uma possível queda da comunicação, impeça-se o cliente de solicitar, novamente, um determinado arquivo que não tenha recebido por completo. Esta necessidade de confirmação pode ser a causa de uma vulnerabilidade do sistema. O cliente pode modificar seu programa de tal forma que ele não remeta a confirmação do último pacote. Este problema pode ser contornado com a utilização de duas técnicas: a) Não informando o cliente o tamanho do arquivo sendo transmitido; e, b) Fazendo com que as rotinas de criptografia e descompressão atuem somente sobre arquivos completos. Como são necessários acessos a arquivos para leitura e escrita, por vários processos diferentes, este acesso é feito de forma exclusiva, isto é, há um sistema de semáforos que permite somente um processo, por vez, acessar o arquivo. 6.4 SISTEMA DE TRANSFERÊNCIA DE ARQUIVOS Responsável por executar os Passos 15 a 18 e 20, anteriormente ilustrados na Figura 6.1, e reproduzidos, a seguir, na Figura

33 Servidor 15, 18 Roteador Externo Filtragem de Pacotes Gateway 16, 20 Usuário externo 17, 20 Roteador Interno Filtragem de Pacotes Fig Passos a serem executados pelo serviço TFTPS pelo Sistema de Transferência de Arquivos. Passo 15. Servidor transmite arquivo solicitado pelo cliente criptografado e comprimido; Passo 16. Gateway repassa arquivo para o cliente utilizando o seu endereço IP público; Passo 17. Usuário recebe dados. Quando recebe o último pacote ele executa a decifragem e a descompressão. Neste momento ele informa o status da transmissão ao gateway, se com sucesso, ou não; Passo 18. O servidor recebe a informação de como se processou a transferência do arquivo para o usuário. Envia mensagem ao Sistema Autorizador para que o mesmo atualize o registro do usuário com o status da transmissão realizada; Passo 20. Usuário encerra a sessão com o sistema computacional. O gateway identificando o término da conexão envia mensagem ao Sistema Autenticador para que este atualize o registro do usuário com dados relativos à conexão realizada. Para transferência de arquivos foram adotadas as especificações constantes de Sollins (1999). Descreve-se, a seguir, a parte mais significativa do protocolo de comunicações implementado. 115