Um Mecanismo de Segurança para o Protocolo HTR

Transcrição

1 Um Mecanismo de Segurança para o Protocolo HTR Gregório Patriota 1, Eduardo Feitosa 2, Djamel Sadok 1 1 CIn/UFPE, Recife, Brasil {gregorio, jamel}@gprt.ufpe.br, efeitosa@icomp.ufam.edu.br Abstract. Data security has become an essential requirement for any system in the network to adhoc networks this would be no different. Among the range of existing adhoc protocols no focus on protecting the data that travels. The Heterogeneous Technologies Routing (HTR) is a protocol developed to provides an efficient data routing with the lowest energy consumption, but their data travels in the clear between the elements that make up the network. This work aims to evaluate the impact of a security system on Mobile adhoc network HTR. Resumo. Segurança de dados tornou-se um requisito essencial para todo e qualquer sistema em rede, para as redes adhoc isto não seria diferente. Entre a gama de protocolos para adhoc existentes não há foco na proteção dos dados que trafegam. O Heterogeneous Technologies Routing (HTR) foi um protocolo desenvolvido que provê um roteamento eficiente de dados com o menor consumo energético, porém seus dados trafegam em claro entre os elementos que compõem a rede. Este trabalho tem como foco avaliar o impacto causado por um sistema de segurança sobre a rede adhoc móvel HTR. 1. Introdução Recentemente foi elaborado um novo framework de roteamento para interligar dispositivos em um ambiente de redes adhoc móveis (MANET), chamado HTR (Heterogeneous Technologies Routing) [Souto et al. 2012]. Ele cria uma MANET heterogênea fechada capaz de lidar com mudanças rápidas e imprevisíveis da topologia da rede. Essas MANETs podem ser configuradas rapidamente em diversos ambientes e podem ser compostas de diferentes tecnologias de comunicação, como Bluetooth, Wi-Fi, 6LoWPAN, Zigbee e Ethernet. HTR também fornece suporte de auto-organização para inicializar seus nós, requerendo o mínimo de interação humana. Por ter sido projetada para cenários de emergência, uma rede HTR parte do pressuposto que todos os nós que a compõem são confiáveis, ou seja, não há nós que praticam ações maliciosas. Desta forma, todas as informações de dados e de controle trafegam em texto claro, sem controles de integridade e autenticidade da informação. Em outras palavras, as preocupações de segurança foram deixadas de lado. Porém, tal situação não condiz com a realidade. A ausência de uma estrutura física permite que os canais de comunicações fiquem abertos, possibilitando que um elemento não autêntico da rede possa interceptar o sinal e capturar os dados. Outras questões como ausência de um elemento central coordenador, largura de banda e estabilidade limitam os mecanismos de criptografias que poderiam ser utilizados para proteger o canal aberto de comunicação entre os nós. 357 c 2014 SBC Soc. Bras. de Computação

2 Assim, este trabalho desenvolve uma versão segura para o framework HTR, chamada S-HTR. A solução proposta tem como objetivo garantir os pilares da integridade e autenticidade para o ambiente HTR. A ideia base é utilizar um esquema de HMAC (Hash-based MAC) para prover uma interface entre funções de criptografia. O restante do artigo é organizado como segue: na Seção 2 são apresentados os conceitos básicos relacionados ao tema. A Seção 3 descreve sucintamente as mudanças na arquitetura HTR para a criação do S-HTR. A Seção 4 explica todo o protocolo experimental deste trabalho. Na Seção 5 são apresentados as análises dos resultados obtidos via ambiente de simulação, bem com uma discussão sobre a adequação do HTR a certos ataques. Por fim, na Seção 6 estão expostas as conclusões obtidas, as dificuldades encontradas e as possibilidades de trabalhos futuros. 2. Conceitos Básicos Essa seção apresenta os conceitos básicos necessários para o melhor entendimento deste trabalho HTR Heterogenous Technologies Routing (HTR) é um protocolo de roteamento próativo focado em apoiar heterogeneidade em termos de tecnologia de comunicação [Souto et al. 2012]. Baseado no protocolo OLSR [Clausen and Jacquet 2003], o HTR usa as mensagens de Topology Control (TC) e HELLO para disseminar informação sobre o estado do enlace (link state) e vizinhança (neighbor). Além disso, herda Multipoint Relays (MPRs), técnica para evitar o controle de inundação de mensagem escolhendo alguns nós para serem responsáveis pela disseminação de mensagens de controle. Contudo, o HTR alcança melhores tempos de convergência [Lima et al. 2013]. O roteamento do HTR utiliza o algoritmo de Dijkstra para executar a computação do caminho [Souto et al. 2012], mas também utiliza uma abordagem multipath [Lima et al. 2014] para encontrar melhores caminhos no processo de roteamento. Uma das diferenças entre o HTR e outros protocolos de redes adhoc reside no fato dele ter como foco a manutenção da rede em operação pelo maior tempo possível. Isso é alcançado pelo uso da métrica HTRScore, definida usando fatores como estado do enlace e eficiência energética [Souto et al. 2012]. Esta métrica é usada para melhorar o cálculo de rota e também é aplicável ao conjunto de cálculos do MPR. HTRScore também introduz a probabilidade de perda de pacotes, um parâmetro que avalia a estabilidade do link, uma otimização que beneficia caminhos com alta taxa de emissão de pacotes Ataques a Redes Adhoc Os ataques a redes adhoc visam, em geral, a tabela de roteamento dos elementos que a compõem. Como forma de facilitar o entendimento do problema e, mais a frente, da solução proposta, os principais ataques a redes adhoc encontrados na literatura [Agrawal et al. 2011] são descritos na Tabela Função hash Uma função hash [Stallings 2007] mapeia uma mensagem de tamanho variável em um resumo de mensagem com tamanho fixo. Também conhecida como síntese de 358 c 2014 SBC Soc. Bras. de Computação

3 Tabela 1. Principais Ataques a Redes AdHoc Ataque Descrição Inundação (Flooding Visa sobrecarregar os nós autênticos com a criação de rotas falsas com destino para nós não existentes. ) É classificado com um tipo de ataque de negação de serviço onde os protocolos proátivos são os mais susceptíveis Sleep Depravation Com o foco no consumo energético de um determinado nó, neste ataque o atacante faz consecutivas requisições de rota sobrecarregando um elemento da rede. O nó atacado irá desperdiçar a sua energia processando as requisições do nó malicioso Impersonation Um nó malicioso finge ser um nó legítimo da rede. Dessa forma, junta-se a rede e envia informações falsas de rotas, mascarando os nós autênticos Black Hole É um ataque de negação de serviço em que o atacante injeta rotas falsas na rede, afirmando ter o menor caminho para um dado destino, atraindo todo o tráfego para ele. Desta forma, o atacante pode interceptar os pacotes e fazer mau uso deles Node Isolation O atacante tem como meta isolar um determinado nó dentro da rede, evitando que rotas sejam construídas para este nó destino. Routing Table Poisoning O atacante gera e envia tráfego falso ou altera o conteúdo de uma mensagem autentica, criando entradas falsas nas tabelas de roteamento Wormhole Um atacante replica os dados que trafegam em um determinado ponto da rede em outro ponto. Ou seja, os dados são inseridos em um túnel que liga dois pontos distintos da rede Location Disclosure A partir de uma análise de tráfego, o atacante pode descobrir a localização de um nó dentro da rede, podendo descobrir também a topologia da rede. Rushing Aproveitando o esquema de requisição de rotas nas redes adhoc, o atacante passa a responder o mais rápido essas requisições, de forma a garantir que todas as rotas tenham como elemento intermediário o nó malicioso. As requisições que são respondidas com atraso são descartadas pelos nós Blackmail Ataque contra protocolos que implementam um sistema seguro baseado em blacklist. O atacante cria a própria blacklist e propaga dentro da rede. Nela o atacante inseri elementos autênticos e retira nós maliciosos. Snare Trata-se de um ataque físico, onde um elemento da rede é capturado. O atacante pode usar o dispositivo, se passando por um indivíduo autentico da rede, interceptando o tráfego. The Invisible Node É um ataque passivo, onde o nó malicioso participa da ações da rede sem revelar sua identidade, com o intuito de apenas coletar as informações que trafegam na rede mensagem ou valor de hash, a função hash é uma função unidirecional, pois a partir do resumo gerado não é possível recuperar a mensagem original. O código de hash é uma função que utiliza todos os bits da mensagem e oferece a capacidade de detecção de erros. Qualquer mudança de bit ou bits na mensagem resulta em uma mudança no código hash. Um valor de hash h é gerado por uma função H na forma h=h(m), onde M é uma mensagem de tamanho variável e H(M) é o valor de hash de comprimento fixo. A finalidade de uma função hash é produzir uma impressão digital de um arquivo, mensagem ou qualquer outro conjunto de dados MAC O Código de Autenticação de Mensagem (Message Authentication Code - MAC)[Stallings 2007], também conhecido como soma de verificação criptográfica (checksum), é uma técnica de autenticação que envolve o uso de uma chave secreta para gerar um bloco de dados de tamanho fixo. Este bloco é anexado à mensagem na transmissão no momento em que a mensagem é conhecida como sendo correta. Na recepção, a mensagem é autenticada a partir de um novo MAC gerado e comparado. Para geração do novo código, tanto o receptor quanto o elemento que transmite a mensagem, devem estar de posse da chave secreta. Com o uso de MAC é possível garantir que: (i) a mensagem recebida não foi alterada; (ii) a mensagem recebida é do emissor declarado; (iii) se a mensagem inclui um número de sequência, então o receptor poderá ter a certeza que a mensagem está na devida sequência. O algoritmo de MAC é uma função irreversível, ou seja, não é possível a partir do código gerado obter a mensagem original. 359 c 2014 SBC Soc. Bras. de Computação

4 2.5. HMAC Uma vez que algumas funções Hash não foram projetadas para uso com o MAC (Código de Autenticação de Mensagem - Message Authentication Code), pois não dependem de uma chave secreta, várias propostas surgiram para incorporar uma chave simétrica em algoritmo de Hash. A técnica que obteve maior suporte foi Hash-based MAC (HMAC) [Stallings 2007]. Publicado na RFC2104 [Krawczyk et al. 1997] e escolhido como MAC de implementação obrigatória para segurança IP, O HMAC é usada em protocolos da Internet, como SSL. O HMAC trata a função hash como uma caixa-preta, ou seja, como um módulo independente onde o esquema HMAC não precisa ter conhecimento de seu funcionamento. Isso o torna adaptável a qualquer nova função hash que possa vir a surgir e facilita a troca de uma função hash por outra, sem necessidade de uma reimplementação. A força da segurança do HMAC está diretamente associada ao tamanho da chave simétrica utilizada e a segurança do algoritmo de Hash utilizado. Uma chave pequena pode comprometer a segurança do esquema, mas uma chave grande não aumentará mais o nível de segurança. A relação de tamanho ideal para a chave é expressa em [Krawczyk et al. 1997] Protocolos Seguros Embora existam soluções e protocolos seguros, como SAODV, SDSDV, SOLSR, entre outros (todos descritos em [Abusalah et al. 2008]), este trabalho não tem o propósito de fazer uma comparação direta entre o S-HTR e as outras soluções. Por isso elas não serão exploradas e/ou detalhadas neste trabalho. 3. Arquitetura Para alcançar o objetivo proposto, prover um ambiente seguro para o tráfego das mensagens de controle do protocolo HTR, foi utilizado um esquema de HMAC. Como explicado na Seção 2.1, o framework HTR usa dois tipos de mensagens de controle: HELLO e TC. Assim, para implementar a versão segura do HTR, o cabeçalho padrão do protocolo foi alterado (Figura 1). Figura 1. Cabeçalho da mensagem de controle do S-HTR Os campos Packet Length e Packet Type, ambos de 2 bytes cada um, representam, respectivamente, o tamanho total da mensagem e o tipo da mensagem (HELLO ou TC). Para o S-HTR, independente da mensagem encapsulada, os campos dessa mensagem serão usados como entrada para a função hash. Ou seja, o resumo gerado será composto por todos os campos da mensagem encapsulada. O tamanho do campo HashDigest varia conforme a função hash utilizada, podendo ser de 128, 160, 256, 384 e 512 bits (conforme disposto na Tabela 2). O resumo é encriptado por um protocolo de criptografia simétrica AES, que utiliza uma chave 360 c 2014 SBC Soc. Bras. de Computação *

5 previamente trocada entre os participantes para fornecer o código de autenticação da mensagem baseado em hash. O esquema HMAC para as mensagens do HTR é ilustrado na Figura 2. Figura 2. Estrutura do HMAC no S-HTR No processo de transmissão, a partir de uma mensagem M e uma chave simétrica K é gerado o código HMAC da mensagem M pela função hash H e a chave simétrica K. O código é concatenado com a mensagem e então propagado para o devido destino. Na recepção da mensagem, a partir da mensagem recebida M e de uma chave simétrica K, a mesma utilizada na etapa de transmissão, é então gerado um novo código HMAC da mensagem. O novo código é comparado com o código recebido na mensagem. Esse processo de comparação é responsável por verificar e garantir a integridade e autenticidade da mensagem. 4. Protocolo Experimental A solução proposta foi desenvolvida em ambiente simulado, através do simulador ns-3 [NS-3 Consortium 2014] e da biblioteca Crypto++ [Boost Software License ]. As simulações foram executadas em computadores com 8 processadores quad-core de 3.4GHz, com 8Gb de memória e 1Tb em disco. A versão do sistema operacional foi o Debian GNU/Linux 7.1 Wheezy Cenário Os elementos que compõem a rede foram alinhados com uma distância de 30 metros separando uns dos outros. O protocolo utilizado na camada de transporte foi o UDP, com taxa de dados de 300, 600 e 1000kbps. Os nós são estáticos na rede durante todo o processo de simulação. Os experimentos foram executados 400 vezes para cada um dos cenários com duração máxima de 1800 segundos. Cada cenário possuí uma densidade de nós e um protocolo. A densidade foi variada entre 25, 49, 64 e 81 nós na rede, valores estes escolhidos pelo autor. Já entre os protocolos utilizados, foi permutado entre HTR, S-HTR(MD5), S-HTR(SHA-1), S-HTR(SHA- 128), S-HTR(SHA-256), S-HTR(SHA-384), S-HTR(SHA-512) Métricas Foram empregadas as três (3) mesmas métricas de avaliação utilizadas em [Junior 2013, Lima et al. 2013]. São elas: 1. Tempo de Convergência: é o tempo que a rede leva para que a tabela de roteamento de cada elemento esteja preenchida com rotas para todos os nós restantes que compõem a rede. 2. Sobrecarga das Mensagens: é definida como o fluxo médio de dados de controle ao longo da simulação. A sobrecarga do novo cabeçalho é diretamente proporcional a função Hash utilizada (vide Tabela 2). 3. Perda de Pacotes: é o número de pacotes transmitidos dentro da rede que não são recebidos. 361 c 2014 SBC Soc. Bras. de Computação

6 Tabela 2. Tamanho dos resumos gerados pelas respectivas funções Hash Algoritmo Tamanho da Saída (bits) MD5 128 SHA SHA SHA SHA Avaliação de Resultados Esta seção apresenta e discute os resultados das avaliações Resultados Tempo de Convergência A Figura 3 apresenta os tempos de convergência nos diferentes cenários. Para o cenário de menor densidade(a), 25 nós, percebe-se que a diferença entre o HTR e os S-HTR é mínima, com variação menores do que 2%. Valor este que, além de estar dentro da margem de erro, testes estatísticos determinaram que os valores de suas medianas não diferem em localidade. Contudo, conforme a densidade da rede cresce o impacto torna-se notório. Para o cenário com 49 nós (b), o impacto do S-HTR em relação ao HTR chega 6% (em média). Para os cenários com 64 nós (c) e 81 nós (d), o tempo de convergência dos protocolos com o mecanismo de segurança são visivelmente maiores que o protocolo base. Tal fato se deve ao tempo de processamento que cada função Hash demanda e conforme a rede vai se expandindo, o impacto vai aumentando.!,-/*!,-.*!,-,*!,--*! ((*! (+*! ()*!,-5*!,-:*!,-/*!,-.*!,-,*!,--*! ((*! (+*! %%#$!"!#$!"&#$ ()*! 012! 345! 6078,! ! 6078/+:! 60785,.! 012! 345! 6078,! ! 6078/+:! 60785,.!!! "#$! "%$!,-9*!!"(#$!"(#$!"&#$!"(#$!"'#$ 012! 345! 6078,! ! 6078/+:! 60785,.! "&$!,-)*!,-9*!,-5*!,-:*!,-/*!,-.*!,-,*!,--*! ((*! (+*!,-5*!,-:*!,-/*!,-.*!,-,*!,--*! ((*! (+*!!"'#$!"'#$!"(#$!"'#$!"&#$!")#$!")#$!")#$!"*#$!")#$ ()*! 012! 345! 6078,! ! 6078/+:! 60785,.!!! "'$! Figura 3. Comparação entre os tempos de convergência para cenários com: (a) 25 nós, (b) 49 nós, (c) 64 nós, e (d) 81 nós. 362 c 2014 SBC Soc. Bras. de Computação

7 Sobrecarga das Mensagens A Figura 4 apresenta a sobrecarga das mensagens nos diferentes cenários. Como mencionado na Seção 4.2, a carga depende da função Hash. Em outras palavras, o novo cabeçalho de segurança insere uma sobrecarga nas mensagens. Isto é facilmente percebido no cenário com 25 nós (a), onde a sobrecarga é de quase 100% na comparação do HTR com o protocolo com esquemas criptográficos. Para os cenários maiores (b), (c) e (d), esta proporção na sobrecarga se mantém. Em média, a cada função Hash utilizada no protocolo, a quantidade de dados no cabeçalho da mensagem dobra em relação ao HTR. Contudo, também pode-se observar que apesar do crescimento em relação ao HTR, quando comparados entre si, a sobrecarga da mensagem mantém uma proporção igual. Isso significa que, independentemente do protocolo seguro utilizado, os custos de banda são muito próximos, com pouca variação. -(,,,( +!%%#$ &"'#$ &!(#$ &&%#$ &')#$,( +!%%#$ &"&#$ &!"#$ &!*#$ &&+#$ +( +(,./0! 12*! 3.45+! 3.45,*6! ! 3.45*+,!./0! 12*! 3.45+! 3.45,*6! ! 3.45*+,!!! "#$! "%$!,,( &""#$ &"!#$ &"+#$ &!)#$ &&"#$,(!%*#$ &""#$ &"'#$ &"%#$ &!'#$ + + +( +(!./0! 12*! 3.45+! 3.45,*6! ! 3.45*+,! "&$!./0! 12*! 3.45+! 3.45,*6! ! 3.45*+,!!! "'$! Figura 4. Comparação entre as cargas de dados de controle para cenários com: (a) 25 nós, (b) 49 nós, (c) 64 nós, e (d) 81 nós Perda de Pacotes No caso da métrica de perda de pacotes, todos os protocolos seguros apresentaram um aumento na taxa de perda de pacotes, como pode ser visto na Figura 5. No cenário de 25 nós (a), os pacotes perdidos chegam a ser de 50% quando comparados com o HTR. Conforme a densidade da rede aumenta, o impacto dos protocolos seguros sobre a perda de pacotes aumenta também. Porém, conforme observado na Figura 5 (b), (c) e (d), o impacto causado pelos protocolos seguros, quando comparados entre si, tendem a manter um nível médio igual, ou seja, não apresentam 363 c 2014 SBC Soc. Bras. de Computação

8 grandes variações. A perda de pacotes está diretamente associado à qualidade do canal que é definido pelo modelo de propagação.!.,.+..( -, + *(.-.,.+..( -, +!%&#$!%'#$!%(#$!)%#$!*!#$ /01! 234! 5/67.! 5/67*4,! 5/678-+! 5/674.*! /01! 234! 5/67.! 5/67*4,! 5/678-+! 5/674.*!!! "#$! "%$! *(!+*#$!++#$!+(#$!')#$!(&#$ /01! 234! 5/67.! 5/67*4,! 5/678-+! 5/674.*! "&$! *(.-.,.+..( -, +.-.,.+..( -, +!*(#$!+"#$!+&#$!'"#$!'"#$!'*#$!'"#$!'(#$!'*#$!()#$! /01! 234! 5/67.! 5/67*4,! 5/678-+! 5/674.*!! "'$! Figura 5. Comparação entre a perda de pacotes de controle para cenários com: (a) 25 nós, (b) 49 nós, (c) 64 nós, e (d) 81 nós Discussão Ao analisar as três métricas, é notório que existe um custo associado à geração de um resumo para cada função Hash, o que influência no tempo de convergência da rede, na sobrecarga das mensagens e na perda de pacotes. Sobre o Tempo de Convergência cada função de Hash influncia diretamente, porém para o ambiente HTR, os dados que são a entrada para as funções de Hash são os dados das mensagens de controle, a carga desses dados é muito pequena, na ordem de dezenas de bytes. Sendo assim o tempo de convergência dos protocolos com seus respectivos esquemas de Hash não diferiu tanto do protocolo HTR sem criptografia. Para todos os protocolos seguros, a sobrecarga da rede é maior que o dobro em relação ao protocolo HTR sem criptografia. Mas quando comparamos o custo entre os protocolos seguros, o custo de banda é muito próximo com pouca variação de pontos percentuais. Isto é devido aos resumos inseridos que, conforme a Tabela 2, entre eles há apenas uma pequena diferença de tamanho. Quanto as perdas de pacotes causadas pelos protocolos seguros, observamos que para redes com uma alta densidade de nós, a perda de pacotes chega a quase dobrar, porém não há uma grande variação de impacto quando comparamos os protocolos seguros entre si. Contudo, ao se considerar o aspecto de segurança, um ambiente com o S- HTR é capaz de mitigar vários dos ataques descritos na Seção 2.2. Embora uma análise em ambiente real tenha sido realizada, uma rápida análise teórica permite (Tabela 3) apontar em quais desses ataques o S-HTR consegue atuar. 364 c 2014 SBC Soc. Bras. de Computação

9 Tabela 3. Status dos Ataques em um ambiente com o S-HTR Ataque Status Explicação Inundação (Flooding Mitiga Apenas nós autênticos na rede irão ter posse da chave simétrica. No caso dos elementos ) que não possuem a chave simétrica, não conseguirão gerar pacotes com o resumo Hash. Sleep Depravation Não se enquadra Este tipo de ataque tem impacto em protocolos reativos, onde as rotas são montadas no instante em que são requisitados. O S-HTR ó um protocolo próativo onde os destinos são armazenados em tabelas, logo não há requisição de rota. Impersonation Não Mitiga ó necessário um esquema de troca periódica de chaves entre os nós autênticos, garantindo que apenas os nós autênticos terão acesso as chaves simétricas e assimétricas. Black Hole Mitiga A escolha do melhor caminho no HTR ó calculada através do algoritmo de Dijkstra, onde os pesos dos enlaces são ponderados pelo HTRScore. Node Isolation Não Mitiga ó um ataque criado especificamente contra o OLSR, logo, como o HTR herda várias características do OLSR ele também é vulnerável a este ataque. O S-HTR não implementa mecanismos para corrigir este tipo de ataque. Routing Table Poisoning Mitiga O uso da função Hash com a chave simétrica protege o conteúdo das mensagens de controle, garantindo assim a integridade dos dados. Logo não é possível que um nó não autêntico altere ou falsifique os dados das mensagens de controle. Wormhole Não Mitiga Não foi encontrada uma solução tangível para resolver este tipo de ataque. Location Disclosure Não Mitiga Para evitar este ataque ó preciso que todo o conteúdo seja criptografado. O S-HTR usa o esquema do HMAC que criptografa apenas o resumo Hash gerado. Rushing Mitiga No framework HTR, a seleção de melhor rota é atribuída ao cálculo do MPR. O S-HTR mantém esta funcionalidade. Blackmail Não se enquadra Nem HTR e nem o S-HTR fazem uso de mecanismos de segurança de Blacklist, logo este ataque não se enquadra. Snare Não Mitiga Hó necessidade de autenticação biométrica para evitar este ataque. The Invisible Node Não Mitiga Ataques do tipo passivo, onde o atacante não tem influência alguma sobre a rede, são difíceis de serem detectados. 6. Conclusão Prover segurança é um requisito imprescindível para qualquer sistema e rede atualmente. Para uma rede adhoc esse requisito tem maior importância devido à alta vulnerabilidade e mobilidade inerente a sua arquitetura. Entretanto, por serem construídas por elementos geralmente com restrições de recursos, o uso de mecanismos seguros também pode significar aumentos no custo de processamento, do uso da banda e de memória, impossibilitando ou inviabilizando sua utilização. Neste trabalho foi feita uma análise do impacto de um mecanismo de segurança sobre a rede adhoc implementada usando o protocolo HTR. Como contribuição, este trabalho foi capaz de gerar argumentos que permitem a escolha do melhor esquema de segurança para o protocolo de redes adhoc, o HTR. A questão de melhores garantias de segurança e de menor impacto sobre a rede foram avaliadas, demonstrando o impacto causado pelas funções: MD5, SHA-1, SHA-256, SHA-384 e SHA-512. Embora tenha as funções Hash tenham gerado impacto sobre a rede (tempo de convergência, sobrecarga das mensagens e até perda de pacotes), pode-se afirmar que: (1) funções SHA-384 e SHA-512 irão sobrecarregar a rede de forma desnecessária; (2) função MD5 não é confiável [Turner and Chen 2011]; e (3) função SHA-1 apresentou significativamente o impacto menor e SHA-256 o máximo impacto suportado. Desta forma, os resultados dos testes e a arquitetura do protocolo HTR nos levam a concluir que o esquema de HMAC com uso da função Hash SHA-1 trará menor impacto e garantirá, de forma eficiente, integridade e autenticidade das mensagens de controle do framework, já que o tempo de vida da mensagem de controle [Souto et al. 2012] é muito inferior ao tempo necessário para a criptoanálise do SHA c 2014 SBC Soc. Bras. de Computação

10 6.1. Dificuldades Encontradas Entre as dificuldades encontradas, destacam-se: Falta da implementação de um modelo de consumo energético próprio para cada função de Hash utilizada no ns-3, o que impossibilitou que esta métrica pudesse ser coletada. A segunda e maior dificuldade encontrada reside no fato da biblioteca Crypto++ possuir uma pequena falha de gerenciamento da memória. Tal falha ocasiona um vazamento de memória, conhecido como memory leak. Esse vazamento era evidente em cenários de alta densidade de nós, o que impossibilitou a simulação de cenários maiores Trabalhos Futuros Como propostas de trabalhos futuros: (i) criação de um esquema seguro de distribuição de chaves simétricas em ambiente inseguro; (ii) extensão para o protocolo para dar suporte a CMAC; (iii) criação de modelos de energia no ns-3 para cada função Hash. Referências Abusalah, L., Khokhar, A., and Guizani, M. (2008). A survey of secure mobile ad hoc routing protocols. Commun. Surveys Tuts., 10(4): Agrawal, S., Jain, S., and Sharma, S. (2011). A Survey of Routing s and Security Measures in Mobile Ad-Hoc Networks. 3(1): Boost Software License 1.0 (2013). Crypto++ R library cryptopp.com/. Clausen, T. and Jacquet, P. (2003). Optimized Link State Routing Protocol (OLSR). RFC 3626 (Experimental). Junior, J. (2013). An energy-aware multipath routing extension for heterogeneous ad hoc networks. Master s thesis, Federal University of Pernambuco. Master Thesis. Krawczyk, H., Bellare, M., and Canetti, R. (1997). HMAC: Keyed-Hashing for Message Authentication. RFC 2104 (Informational). Lima, J., Rodrigues, T., Melo, R., Correia, G., Kelner, J., and Feitosa, E. (2013). On the tuning of wireless heterogeneous routing. In Personal Indoor and Mobile Radio Communications (PIMRC), 2013 IEEE 24th International Symposium on, pages IEEE. Lima, Josias, J., Rodrigues, T., Melo, R., Correia, G., Sadok, D., Kelner, J., and Feitosa, E. (2014). A multipath extension for the heterogeneous technology routing protocol. In Guo, S., Lloret, J., Manzoni, P., and Ruehrup, S., editors, Ad-hoc, Mobile, and Wireless Networks, volume 8487 of Lecture Notes in Computer Science, pages Springer International Publishing. NS-3 Consortium (2014). ns-3. Souto, E., Aschoff, R., Junior, J. L., Melo, R., Sadok, D., and Kelner, J. (2012). Htr: A framework for interconnecting wireless heterogeneous devices. In CCNC, pages IEEE. Stallings, W. (2007). Criptography and Networking Security. Pearson Education, 4 edition. Turner, S. and Chen, L. (2011). RFC c 2014 SBC Soc. Bras. de Computação