CAPÍTULO 7 MÓDULOS IMPLEMENTADOS

Transcrição

1 CAPÍTULO 7 MÓDULOS IMPLEMENTADOS 7.1 MÓDULO DE TIMEOUT E RETRANSMISSÃO Como se está utilizando para a transferência de arquivos o protocolo de transporte UDP, que não é orientado à conexão, os problemas que são tratados, internamente, pelo protocolo de transporte TCP, têm de ser implementados para lhe conferir confiabilidade. Dentre os problemas que devem ser tratados tem-se o do aproveitamento da largura de banda disponível para retransmissão, o da confirmação do recebimento, o dos pacotes perdidos ou duplicados, dentre outros. Para esta dissertação somente os problema da retransmissão e dos pacotes perdidos e o da confirmação do recebimentos foram abordados. Este último é tratado pelo protocolo do serviço TFTPS implementado, enquanto que o primeiro é tratado mantendo-se um módulo de timeout e retransmissão na máquina que estiver enviando dados, que pode ser tanto o cliente como o servidor. Se um pacote de dados é perdido o remetente não recebe o pacote de confirmação e, consequentemente, seu tempo de espera da confirmação expira. Nesse momento ele retransmite o pacote. Se um pacote de confirmação, enviado pelo destinatário, se perder, o remetente do pacote de dados também atinge o tempo limite de qualquer maneira e retransmite o pacote original. Se um pacote chegar ao destinatário duplicado ele consegue identificar esta situação através do número identificador do pacote recebido. Caso confirmada a duplicação o destinatário descarta o pacote duplicado mas remete uma confirmação de qualquer maneira. O método clássico para tratamento de pacotes perdidos ou duplicados envolve as seguintes etapas: a) remete-se uma mensagem e aguarda-se por N segundos; 123

2 b) se durante estes N segundos nenhuma resposta chegar remete-se um novo pacote e aguarda-se outros N segundos;. c) Após ter remetido um certo número de pacotes sem que uma cofirmação tenha chegado deduz-se que a outra extremidade da conexão está fora do ar e o processo de transmissão é encerrado. O problema desta técnica é que ela utiliza um contador de tempo linear para estimar a quantidade de tempo necessária para que um pacote trafegue pela rede, conhecido por RTT round trip time. Ela usa um único valor que não representa, com exatidão, o estado atual da rede. Este estimador pode variar de pequenas frações até alguns segundos, em razão da distância entre os extremos da conexão, da velocidade do tráfego de dados e de situações de congestionamento. Torna-se necessário, portanto, o uso de um estimador que consiga mensurar o tempo efetivo, daquele instante, para o tráfego do pacote. Uma técnica que atende esta característica é a que utiliza um tempo de timeout adaptativo com retardo exponencial. O termo adaptativo significa que o RTT de cada datagrama enviado é medido e o valor do timeout é alterado cada vez que há uma alteração no RTT. O termo retardo exponencial significa que o primeiro tempo a ser utilizado para retransmitir um pacote deve ser o timeout atual multiplicado por 2. O próximo será multiplicado por 4 e assim por diante, sempre multiplicando-se por um fator 2 n. Para esta dissertação tratou-se do problema de timeout e retransmissão, através do algoritmo de Jacobson, em ponto flutuante. Nele, não somente os RTT são medidos, como também se calcula o desvio da média dos valores de RTT. Este valor é aceito como uma boa aproximação do desvio padrão e é obtido com maior facilidade de cálculo. Além do algoritmo de Jacobson adaptou-se o algoritmo de Karn para trabalhar de forma conjunta permitindo um melhor tratamento do problema inerente a várias retransmissões, isto é, ocorre um timeout, várias retransmissões são efetuadas e uma confirmação finalmente chega. Como considerar o tempo de tráfego do pacote? O algoritmo de Karn utiliza o seguinte esquema: 124

3 a) Não usa o RTT deste pacote para atualizar os estimadores. Uma vez que o pacote foi transmitido mais de uma vez não se pode ter certeza a qual retransmissão a resposta se refere. Este problema é conhecido por problema da ambigüidade da retransmissão; b) Uma vez recebida uma resposta antes de expirar o timeout reutiliza o valor do timeout atual para o próximo pacote. Uma vez que um pacote retransmitido, uma ou mais vezes, tem o valor de timeout multiplicado por alguma potência de 2 pelo retardo exponencial, somente uma resposta à primeira transmissão do último pacote permite um novo cálculo do valor de timeout baseado nas medidas de RTT. Para implementação das técnicas de retransmissão e timeout há necessidade do uso de uma sinalização por alarme. Assim, antes da chamada à rotina de sistema para recepção de dados, recvfrom(), deve ser feita uma chamada à função alarm() passando-se, como parâmetro, o timeout desejado. O comportamento da função alarm() é dependente do sistema operacional empregado. Para o caso específico dos sistemas Linux Red Hat V5.1, V5.2 e Guarani 3.0, seu comportamento padrão é reiniciar as chamadas que bloqueiem o sistema, como a recvfrom(), por exemplo, imediatamente após a emissão do sinal. Não é isso que se pretende! Para alterar este comportamento é necessário a utilização de siginterrupt(). Para o controle da retransmissão e do timeout utiliza-se a estrutura abaixo discriminada: struct rtt_struct { float rtt_rtt; /* O mais recente RTT */ float rtt_srtt; /* RTT suavizado */ float rtt_rttdev; /* Média dos desvios, suavizado */ short rtt_nrexmt; /* Número de vezes retransmitido */ short rtt_currto; /* Timeout de retransmissão atual (RTO) */ short rtt_nxtrto; /* Timeout de retransmissão para o próximo pacote, se diferente de zero */ struct timeval time_start; /* Para o tempo decorrido */ struct timeval time_stop; /* Para o tempo decorrido */ }; 125

4 Para o primeiro pacote os valores da estrutura de controle são inicializados da seguinte forma: a) Ao timeout (rtt_rtt) é atribuído zero; b) Ao RTT suavizado (rtt_srtt) é atribuído o valor zero; c) Ao valor do desvio da média suavizado (rtt_rttdev) é atribuído metade do valor desejado para o timeout da primeira retransmissão; d) Ao valor do número de vezes retransmitido é atribuído o valor zero; e) O valor do timeout de retransmissão atual (rtt_currto) é calculado como rtt_srtt + (2* rtt_rttdev); e, f) Ao valor do timeout de retransmissão do próximo pacote (rtt_nxtrto) é atribuído o valor zero. A partir do segundo pacote não é mais necessário reinicializar todos os campos, somente o número de vezes retransmitido e sempre com zero. Para se alterar o valor de timeout atual de retransmissão (rtt_currto) existem três possibilidades: a) É a primeira transmissão de um pacote calcula-se o valor de timeout atual baseado nos estimadores correntes: srtt + (2 * rttdev); b) É a primeira transmissão de um pacote mas o último pacote transmitido foi retransmitido é utilizado o último valor de timeout de retransmissão do próximo pacote, atribuído quando da retrasnmissão do pacote anterior, isto é, rtt_currto recebe o valor de rtt_nxtrto; c) É uma retransmissão aplica-se o retardo expoencial. Uma vez recebida uma confirmação atualizam-se os campos da estrutura de controle. Duas situações podem ocorrer: 126

5 d) A confirmação recebida diz respeito a um pacote que foi retransmitido ao valor de timeout para o próximo pacote (rtt_nxtrto) é atribuído o valor corrente de timeout (rtt_currto) sem nenhuma modificação já que não se pode ter certeza a qual transmissão a confirmação recebida se refere; ou, e) A confirmação diz respeito a um pacote que não foi retransmitido atualizam-se os estimadores da seguinte forma: f) rtt_rtt: tempo decorrido entre o envio do pacote e a recepção da confirmação; g) rtt_rttdev: valor corrente acrescido de um quarto da diferença entre o rtt_rtt obtido, o valor corrente do RTT suavizado e o valor corrente do desvio da média; h) rtt_srtt: valor corrente acrescido de um oitavo da diferença entre o rtt_rtt obtido e o valor corrente do RTT suavizado. Cada vez que se atinge o limite de tempo de espera do pacote de confirmação o valor de rtt_nxemt é acrescido de 1 até que se atinja o número máximo de retransmissões programadas. Para esta dissertação, quatro. Atingido este valor a recepção de dados é encerrada indicando ao usuário que a outra extremidade da conexão está fora de serviço e, consequentemente, interrompe a execução do programa. Se esta situação ocorrer no servidor o serviço não é interrompido, somente o processo ativo é finalizado. Função de como se encara o problema da retrasmissão e dos timeouts pode ocorrer uma síndrome conhecida por Sorcerer s Aprentice Syndrome quando tanto o cliente como o servidor utilizam módulos de retransmissão e timeout e ambos retransmitem seu último pacote. Esta situação pode ser melhor entendida com a ilustração apresentada na Figura

6 Fig. 7.1 Envia DATA(n) timeout Retransmite DATA(n) Recebe ACK(n) Envia DATA(n+1) Recebe ACK(n) (duplicado) Envia DATA(n+1) (duplicado) Recebe ACK(n+1) Envia DATA(n+2) Recebe ACK(n) (duplicado) Recebe DATA(n) Envia ACK(n) Recebe DATA(n) (duplicado) Envia ACK(n) (duplicado) Recebe DATA(n+1) Envia ACK(n+1) Recebe DATA(n+1) (duplicado) Envia ACK(n+1) (duplicado) Recebe DATA(n+2) Envia ACK(n+2) Representação esquemática da Sorcerer s Apprentice Syndrome. FONTE: Adaptada de Stevens (1990, p. 469). Para que esta síndrome seja evitada o remetente não pode remeter um pacote de dados caso receba uma confirmação em duplicata e, ainda, que o receptor desconsidere pacotes de dados enviados em duplicata. Desta forma o receptor dos dados não necessita do módulo de retransmissão e timeout, somente quem envia os dados. 7.2 MÓDULO DE CRIPTOGRAFIA Todas as transmissões de dados no TFTPS são criptografadas. Uma abordagem do problema da criptografia já foi feita para o problema da autenticação. Agora será vista uma segunda abordagem utilizada, especificamente, para a transferência de dados. Dentro do Sistema de Transferência de Arquivos foi implementado um conjunto de rotinas que realiza esta função. Esta dissertação utiliza, para transferência de arquivos, um algoritmo de criptografia simétrico, com cifragem de blocos utilizando o modo CBC. 128

7 Considerou-se, também, que o processo de decifragem somente será possível quando o usuário tiver recebido toda a informação a ser transmitida. Esta restrição é imposta dentro das rotinas de decodificação. Uma vez considerado o modelo de segurança mais restritivo justifica-se esta decisão. Dos vários algoritmos públicos disponíveis optou-se pela utilização de dois deles, o Data Encryption Standard (DES) e o Blowfish combinados conforme a explicação que se segue. Ambos são algoritmos de cifragem por blocos baseados nas redes de Feistel. Este projeto toma, como ponto de partida, um bloco de tamanho n e o divide em duas metades, cada uma de tamanho n/2, chamadas de L e R. Com estes sub blocos, e de uma fução f, é possível definir um processo de cifragem interativo onde o resultado da i-ézima interação é função de todas as anteriores. Matematicamente este fato pode ser expresso como: L i = R i-1 R I = L i-1 f (R i-1, K i ) Onde K i é a chave usada para a i-ézima interação e f é uma função arbitrária. Garante-se a reversibilidade deste procedimento, independentemente de qual seja a função f uma vez que o operador binário XOR é utilizado para combinar a metade L com a saída da função aleatória, isto é: L i-1 f (R i-1, K i ) f (R i-1, K i ) = L i-1 Um algoritmo que utiliza esta construção é sempre reversível uma vez que a entrada da função, em cada interação, pode ser reconstruída O algoritmo DES usa chave de 56 bits, na realidade 64 sendo que o último bit de cada byte não é utilizado para a cifragem. A descrição do funcionamento deste algoritmo pode ser encontrada em Schneier (1996, p. 265 a 301). 129

8 Por ter seu código de domínio público este esquema apresenta uma série de trabalhos de pesquisa que conseguem explorar deficiências no seu algoritmo. Se por um lado a existência de falhas pode parecer problemática, por outro, exibe claramente quais as vulnerabilidades do mesmo e como explorá-las, isto é, suas falhas são públicas. Os demais algoritmos também devem apresentar suas falhas mas as mesmas não são conhecidas o que dificulta o problema do administrador do sistema. Para contornar as deficiências conhecidas optou-se por utilizar uma combinação de algoritmos de forma que cada um supere as vulnerabilidades do outro. Para esta dissertação utiliza-se a técnica de combinar algoritmos diferentes de criptografia conhecida por encrypt-decrypt-encrypt (EDE). Nela, utilizam-se duas chaves e três operações de criptografia. Uma mensagem cifrada, C, é obtida a partir de um texto às claras P, segundo a seguinte seqüência de operações: C = E k1 (D k2 (E k1 (P))) Sendo a operação inversa: P = D k1 (E k2 (D k1 (C))) Realiza-se uma cifragem utilizando DES, com uma chave k1, seguida de uma decifragem utilizando Blowfish, com uma chave k2, e, finalmente, nova cifragem com DES e chave k1. Lembrando que, nesta implementação, a chave k1 (56 bits) é obtida a partir de uma one way hash function que tem como entrada a senha do usuário e a chave k2 (448 bits) é obtida a partir de um algoritmo gerador de números pseudo aleatórios tendo como semente a chave k1. O método de criptografia Blowfish, foi desenvolvido por Bruce Schneier, e seu código fonte, em C, pode ser encontrado em Schneier (1996, p 647 a 654), sendo, o mesmo, de domínio público. 130

9 A opção por este método se deu, dentre outras considerações, por ser de domínio público, ser rápido, usar somente operações simples e permitir chaves de tamanho variável até 448 bits. A descrição do funcionamento deste algoritmo pode ser encontrado em Schneier (1996, p. 336 a 339). Ele foi implementado de forma a tratar somente de dados do tipo unsigned long int. Todos os dados que não sejam deste tipo, como os dados do tipo char que descrevem o nome do usuário, são tratados através de uma estrutura de dados do tipo union. Os blocos a serem criptografados não tenham um número par de dados são complementados com paddings. 7.3 MÓDULO DE COMPRESSÃO Todas as operações de criptografia consomem tempo de processamento! Arquivos de tamanho variado podem ser transferidos consumindo recursos de rede! As afirmações acima conduziram à necessidade de utilização de um processo de compressão de dados para diminuir o tamanho do arquivo e, consequentemente, minimizar o tempo de processamento necessário às operações de criptografia e o uso dos recursos de rede durante a transferência. Ele não está enquadrado dentro dos critérios de segurança embora, se corretamente dimensionado, pode ser um auxiliar valioso por reduzir a redundância do arquivo original e, consequentemente, melhorar a criptografia. Assim sua utilização pode ser feita de duas formas: a) O arquivo é disponibilizado, no diretório do usuário, comprimido; ou b) Comprime-se o arquivo na hora da transferência do arquivo. Dos testes realizados verificou-se que este módulo é o responsável pela maior parcela de tempo despendido durante a execução do processo de transferência de arquivos. Portanto, para esta dissertação, optou-se por disponibilizar os arquivos já comprimidos. Foram analisados vários métodos clássicos de compressão de arquivos sem perdas (lossless), com código fonte de domínio público. Dentre eles: 131

10 a) Método de compressão por aritimética adptativa; b) Método de Huffman clássico; c) Método de Huffman adaptativo; e, d) Várias combinações possíveis dos três métodos acima. Em razão dos resultados obtidos nos testes realizados optou-se por utilizar o método de compressão por aritmética adaptativa já que foi o que apresentou as maiores taxas de compressão sacrificando o tempo de processamento. A descrição do método adotado pode ser encontrado em Sayood (1996, p. 61 a 96). Foi utilizado o algoritmo LZARI, desenvolvido por Haruhiko Okumura, operador de sistemas do SIG do PV-VAN, Japão, cujo código fonte é de domínio público. 7.4 MÓDULO PROXY O cliente, durante todo o processamento, não se comunica diretamente com o servidor de arquivos confidenciais, somente com o gateway do serviço. Desta forma preserva-se a arquitetura da rede interna e fortalece-se a segurança. Porém, quando da transferência do arquivo, esta é feita de uma máquina da rede interna para outra, externa, passando pelo gateway do serviço. A partir deste momento esta máquina passa simplesmente a repassar o arquivo para o cliente. Este serviço pode ser feito de duas formas: a) O servidor transfere todo o arquivo para a máquina gateway e esta, após a recepção integral do mesmo passa a ser o servidor; ou, b) À medida que pacotes vão chegando do servidor ela simplesmente os repassa para o cliente trocando o endereço IP privado do servidor pelo seu, público. Esta dissertação optou por utilizar a primeira abordagem fazendo com que este módulo seja extremamente simples. 132

11 Além de repassar o arquivo para o cliente ele também é o responsável por, após ter enviado o último pacote e recebido a confirmação de recebimento do mesmo, enviar ao servidor mensagem informando que a transferência foi bem sucedida e que podem ser atualizados os bancos de dados do Servidor de Autorização. 133