Análise de Viabilidade da Biblioteca de

Análise de Viabilidade da Biblioteca de Criptografia
TinyECC em Redes de Sensores Sem Fio
Daniel A. Merege1, Cíntia B. Margi2
1
Escola de Artes, Ciências e Humanidades – Universidade de São Paulo (USP)
São Paulo – SP – Brasil
2
Escola Politécnica – Universidade de São Paulo (USP)
São Paulo – SP – Brasil
{dmerege,cintia}@usp.br
Abstract. Currently, wireless sensors networks (WSN) applications demanding
security are more common. To deal with this issue, recently, an elliptic curve
cryptography package for wireless sensors networks applications was
presented: TinyECC. The main contribution of this work, given WSN platforms
constraints, is to analyze the viability and the security level of TinyECC, when
applied to a real application using encrypted messages exchange between
TelosB sensor nodes.
Resumo. Atualmente, aplicações de Redes de Sensores sem Fio (RSSF) com
necessidades de segurança têm se tornando comuns. Para lidar com essa
questão, recentemente, foi proposta a biblioteca de criptografia de
curvas elípticas TinyECC. O objetivo deste trabalho é, considerando as
restrições das plataformas de RSSF, analisar a viabilidade e nível de
segurança na utilização dessa biblioteca, utilizando uma aplicação real
de trocas de mensagens criptografadas entre nós sensores com a
plataforma TelosB.
1. Introdução
As aplicações para a tecnologia de sensores1 são as mais variadas possíveis. Encontramse esses equipamentos nas áreas de agricultura, pecuária e militar; no monitoramento de
mudanças climáticas e do meio ambiente. Esses dispositivos, quando conectados em
rede, podem trocar dados entre si e aumentar o poder de aplicação. São baratos,
possuem baixo custo de comunicação e podem extrair dados riquíssimos de fenômenos
físicos para pesquisas. No entanto, por serem de baixo custo, possuem configurações
restritas de hardware e, portanto, são limitados, tanto na velocidade de processamento,
quanto na capacidade de armazenamento e largura de banda [CULLER et al. 2004].
Adicionalmente, na maioria dos casos, trafegam, nas redes de sensores, dados sigilosos
1
Os termos sensores, nó sensores e motes são utilizados como sinônimos neste trabalho.
51
52
Workshop de Trabalhos de Iniciação Científica e de Graduação (WTICG)
ou estratégicos e uma interceptação e, possivelmente, uma modificação indevida desses
dados podem causar prejuízos enormes a quem as utiliza.
Para garantir que o serviço de confidencialidade não seja afetado, é necessário,
como mecanismo de segurança, o uso de criptografia na comunicação entre os nós de
uma RSSF (Rede de Sensores Sem Fio). Foi desenvolvida, recentemente, e como parte
da solução para que os dados pudessem trafegar de forma segura em redes de sensores,
uma biblioteca para criptografia de curva elíptica, denominada TinyECC [LIU e NING
2008]. A Criptografia de Curva Elíptica (ECC, na sigla em inglês) é, assim como o
algoritmo RSA, assimétrica. Parece oferecer mesmo nível de segurança que o RSA, mas
com um tamanho de chave muito menor, o que reduz a necessidade de processamento
[STALLINGS 2008], fator crucial para a aplicação nas redes de sensores.
Dadas as restrições das plataformas em RSSF, torna-se necessário abordar três
aspectos a respeito do TinyECC: (i) esta é, realmente, a melhor solução apresentada para
criptografar dados em redes de sensores; (ii) existem recursos suficientes para executar
as funções de criptografia e decriptografia de cada mensagem trocada entre sensores; e
(iii) esta solução é viável, ou seja, sua aplicação pode dividir recursos de um sensor com
outros programas. Para responder a essas questões, neste trabalho, utilizamos a
aplicação de troca de mensagens Hermes, desenvolvida para sensores, e que utiliza a
biblioteca TinyECC para cifrar e decifrar as mensagens. Em seguida, são realizadas
medidas experimentais de consumo de memória ROM e RAM, de energia e tempos de
execução, o que permite a análise da viabilidade de utilização desta biblioteca em redes
de sensores sem fio que necessitam de segurança no tráfego de mensagens entre
sensores.
A principal contribuição deste trabalho é analisar a viabilidade e o nível de
segurança da biblioteca TinyECC quando aplicada em uma aplicação real de troca
segura de mensagens entre sensores sem fio.
Na seção 2, é apresentada uma breve revisão bibliográfica sobre redes de
sensores sem fio e sobre a segurança nessas redes. A seção 3 trata da metodologia
aplicada neste trabalho. A seção 4 apresenta o programa Hermes, enquanto a seção 5
aborda os resultados experimentais e a discussão dos testes feitos nos sensores.
Finalmente, as considerações finais são realizadas na Seção 6.
2. Redes de Sensores Sem Fio
Um sensor consiste em um microprocessador, uma unidade de armazenamento de
dados, sensores para captação de fenômenos físicos, conversores de informações
analógicas para digitais (ADCs), um transceptor de dados, controladores e uma fonte de
energia, que pode ser uma pilha comum, por exemplo. Todos esses componentes,
juntos, fazem com que os dados sejam capturados e processados para utilização em
diferentes aplicações. No entanto, utilizar somente um sensor para aplicar em uma
determinada área não é suficiente para atingir objetivos de estudo.
Um dispositivo sensor, sozinho, possui limite de processamento, capacidade
limitada de armazenamento e pequena largura de banda para comunicação; além disso,
as aplicações atuais envolvem estudos complexos e, para isso, são necessários que esses
sensores sejam conectados em rede para que possam trocar informações entre si e
X Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais
53
disponibilizá-las de maneira centralizada. Dessa maneira, faz-se necessária a criação de
uma rede de sensores (Sensors Network), onde cada dispositivo é um nó dessa rede e é
responsável por captar uma informação específica.
Uma rede de sensores funciona, basicamente, da seguinte maneira:
primeiramente, os nós, através de seus sensores, captam dados do mundo real de
maneira analógica. Cada nó possui um componente de sensor de acordo com sua
aplicação. Se um nó deve coletar raios solares, por exemplo, então ele possui um sensor
capaz de captar luz solar incidente. Assim que capta as informações físicas, o nó
converte esses sinais analógicos em informações digitais, através de seu componente
ADC (Analogic-to-Digital Converter). Essas informações, então, são processadas
conforme a aplicação e enviadas para a rede, que pode ser tanto cabeada quanto sem fio.
Para que isso seja feito, é necessário que esses dados sejam empacotados e sigam um
protocolo de comunicação entre os nós.
Nas Redes de Sensores Sem Fio, o empacotamento ocorre e os pacotes são
enviados via ondas de rádio para um nó específico ou para todos os nós que estão
escutando um canal determinado de comunicação e estão no alcance do sinal. No
momento em que um nó recebe um pacote, ele verifica se é o destinatário e, então,
desempacota os dados e os utiliza conforme está programado.
Existem, atualmente, centenas de diferentes aplicações que utilizam redes de
sensores sem fio para captação de informações físicas. Entre elas, está a aplicação na
monitoração de animais selvagens, monitoração de fenômenos climáticos,
monitoramento de pacientes em hospitais, controle de presença em espaços físicos de
acesso restrito, entre outros. Em geral, CULLER et al. (2004) consideraram que as
aplicações podem ser diferenciadas em monitoramento de espaço, monitoramento de
coisas e monitoramento de interações de coisas entre si e o com o espaço.
TinyOS [HILL et al. 2000] é um dos sistemas operacionais mais conhecidos e
utilizados em RSSF. Este sistema operacional utiliza a linguagem nesC [GAY et al.
2003]. Programas desenvolvidos na linguagem nesC consistem em um ou mais
componentes conectados entre si, para formar uma aplicação executável. Nos sensores,
esses componentes representam os componentes físicos do mote e sua execução é
gerenciada pelo sistema operacional TinyOS. Um componente define dois escopos: a
interface e a implementação. A interface define exatamente quais os comandos tal
componente deve ser capaz de executar e a quais eventos ele deve responder, ou seja,
contém toda a sua especificação. Na implementação, é feita a declaração de todas as
ações que o componente deve executar, tendo como base uma interface que o
componente pode utilizar ou prover. Quando se utiliza uma interface, então o
componente apenas deve tratar eventos pré-definidos por ela, enquanto que, quando a
interface é provida, o componente deve implementar seus comandos.
As aplicações de redes de sensores sem fio são variadas e atingem importantes
setores acadêmicos, industriais e de governos. E, em todas essas áreas, existem
informações que são consideradas sigilosas e devem receber tratamento especial. É
crucial, portanto, que as informações trafeguem de maneira segura e que sua
confidencialidade e integridade sejam mantidas. Existem, ainda, outros serviços de
segurança que devem ser garantidos nessa comunicação, como autenticidade de nós e
54
Workshop de Trabalhos de Iniciação Científica e de Graduação (WTICG)
disponibilidade. Para isso, devem-se implementar mecanismos de segurança em cada nó
sensor de uma RSSF que garantam que os dados sejam cifrados e autenticados.
Foram propostas algumas arquiteturas de segurança para garantir os serviços de
segurança em RSSF, tais como: SPINS, TinySec e MiniSec. Os dois últimos tentam
prover serviço de confidencialidade na camada de enlace. Sendo assim, é necessário que
mecanismos de segurança sejam executados a cada salto do pacote na rede RSSF,
aumentando o overhead da comunicação. Além disso, pelas características das soluções
propostas, nós não autênticos conseguiriam se disfarçar na rede e gerar mensagens
autênticas. Considera-se, portanto, que os mecanismos de segurança só serão realmente
eficientes quando implementados na camada de aplicação [MARGI et al. 2009].
Considerando os limites físicos dos dispositivos sensores, deve-se tomar cuidado
ao selecionar um algoritmo de criptografia para garantir a confidencialidade do tráfego
de informações na rede sem fio. O uso excessivo de memória e armazenamento por um
algoritmo pode se tornar um gargalo nas aplicações de redes de sensores. A questão
ligada a RSSF é se um algoritmo de criptografia simétrica será eficientemente executado
nos nós sensores. Adotar cifras que operam sobre blocos muito grandes, por exemplo,
pode levar a um desperdício de energia decorrente da grande quantidade de
processamento, já que os sensores trabalham com blocos de mensagens pequenos.
Ainda considerando as cifras simétricas, para a distribuição da chave secreta, é
necessário utilizar complexos protocolos de distribuição de chaves, o que eleva os
custos computacionais do dispositivo, impossibilitando sua aplicação nas RSSFs. O
padrão atual utilizado em redes com criptografia simétrica é a pré-distribuição, o que
implica que as chaves não mudam. Nesse esquema, as chaves criptográficas utilizadas
pelos sensores são carregadas na memória antes que a rede seja montada, evitando,
assim, o uso de complexos protocolos de distribuição de chaves.
Dessa maneira, uma alternativa melhor é a utilização de algoritmos de
criptografia assimétrica para o gerenciamento de chaves entre pares de sensores, pois a
distribuição é feita de forma dinâmica, independe da topologia da rede e a quantidade de
informação armazenada nos sensores é menor, uma vez que somente uma chave privada
e uma pública são mantidas em cada nó da rede [MARGI et al. 2009]. Neste contexto, a
biblioteca TinyECC se apresenta como uma solução a ser empregada.
3. Metodologia
Para analisar a viabilidade de utilização da biblioteca TinyECC, foi desenvolvido o
Hermes, um programa simples para troca de mensagens criptografadas entre sensores de
uma RSSF. A linguagem utilizada foi nesC, extensão da linguagem C, e o sistema
operacional utilizado foi o TinyOS 1.x, que é a versão para a qual o TinyECC foi
desenvolvido.
Com o programa em funcionamento, foram feitas simulações de trocas de
mensagens utilizando dois sensores TELOS B Mote 8 MHz (TPR2400), com 48KBytes
de memória ROM e 10Kbytes de RAM, para se certificar de que todas as funções
estavam sendo executadas corretamente e obedeciam à especificação.
Para a análise de viabilidade da utilização da biblioteca TinyECC, quatro
métricas foram consideradas: consumo de memória ROM, consumo de memória RAM,
X Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais
55
tempo de execução e consumo de energia das funções criptográficas. Essas variáveis
levam em consideração a principal restrição de um dispositivo sensor que é a utilização
de seus recursos limitados. Avaliando-se a quantidade de memória exigida pela
biblioteca e o tempo de execução de suas funções, pode-se chegar a um resultado
satisfatório para a análise da viabilidade, quando se testa a biblioteca em uma aplicação
real.
As três curvas elípticas utilizadas nos testes de consumo de ROM e RAM,
recomendadas pela SECG (Stands for Efficient Cryptography Group), são secp160k1,
secp160r1 e secp160r2. Para coletar esses dados, foi utilizado um script em Perl,
chamado check_size.pl, disponível no diretório do TinyOS, que mostra o consumo
dessas duas memórias pelo programa compilado. Cada compilação do Hermes ativava
um método de otimização da biblioteca TinyECC e desativava todos os demais. Dessa
maneira, todos os métodos eram testados individualmente com todas as três curvas
elípticas. Esses métodos otimizam cálculos em grandes números inteiros e na curva
elíptica. Devido à limitação de espaço, maiores detalhes em [LIU e NING 2008].
Para obter tempos de execução e consumo de energia, foram utilizados um
multímetro digital Agilent 34401A e uma versão do Hermes para Testes (Hermes v.
Teste). Nesta versão, os mesmos componentes da versão original são utilizados, porém
o programa não espera o recebimento de uma mensagem para decifrá-la. Ou seja, na
execução desta versão de teste, o sensor gera, cifra e envia um pacote via rádio. Na
sequência, decifra o pacote gerado por ele mesmo, agindo como o emissor e o receptor
da comunicação. Existe, portanto, uma simulação real de troca de pacotes entre sensores
sem fio, porém sem o atraso introduzido pela comunicação.
Durante os testes, o Hermes v. Teste era reinstalado em um nó sensor a cada
compilação, que considerava somente a curva secp160r1, um método de otimização
ativado por vez, todos juntos ou sem nenhum método ativado. A cada compilação, o
sensor era conectado ao multímetro e o programa Labview lia as amostras que o
multímetro envia pela porta USB durante a execução do Hermes v. Teste, conforme
metodologia utilizada em [MARGI et al. 2010]. Assim, é possível obter o tempo de
execução e o consumo de energia de cada tarefa.
4. O programa Hermes
O programa Hermes foi criado para que a biblioteca de criptografia assimétrica
TinyECC pudesse ser utilizada e testada. Seu objetivo é fazer com que dois ou mais
sensores sem fio em uma RSSF troquem mensagens de 41 bytes criptografadas entre si,
uma vez que o meio em que os pacotes trafegam não é seguro. Consequentemente, para
que isso seja possível, o programa deve fazer com que os sensores gerem chaves
privadas e públicas e troquem estas chaves um com o outro, antes de enviar uma
mensagem criptografada. Por fim, o Hermes, por rodar em um sensor que pode tanto
enviar quanto receber pacotes, deve poder decriptografar as mensagens recebidas. A
biblioteca TinyECC possui um componente, denominado ECIESM, que implementa as
funções de criptografia e decriptografia de mensagens; para gerar chaves privadas e
públicas, é utilizado o componente ECCM. Outras interfaces da biblioteca, com a NNM,
são auxiliares para que as duas interfaces principais possam funcionar corretamente.
56
Workshop de Trabalhos de Iniciação Científica e de Graduação (WTICG)
O Hermes possui seis principais funções: inicializarComponentes()
executa as funções init dos módulos ECC e ECIES; criarMensagem() cria textos
claros aleatórios; gerarChavePrivada()define um vetor contendo uma chave
privada e executa a função gen_private_key, do componente ECCM, para que a chave
seja criada; gerarChavePublica()gera uma chave pública a partir da chave
privada gerada pela função anterior, utilizando a função gen_public_key do componente
ECCM; criptografar()criptografa uma mensagem gerada aleatoriamente,
utilizando a chave pública do nó comunicante e executando a função encrypt, do
componente ECIESM; por fim, decriptografar()decriptografa uma mensagem
recebida via rádio de outro nó, utilizando a chave privada do nó receptor e executando a
função decrypt do componente ECIESM.
A Figura 1 descreve a sequência de estados do sensor ao rodar o programa
Hermes. No Estado inicial, um temporizador é iniciado. Ao receber o evento
Timer1.fired(), que significa que o temporizador atingiu o tempo determinado, o
programa executa as funções de inicialização. Depois disso, passa para o segundo
estado, que faz com que o sensor espere receber uma chave pública de um outro sensor
para continuar com a execução. Quando recebe, dispara um segundo temporizador,
Timer2.start(), que repete, constantemente, o envio de mensagens cifradas para a
rede. O sensor, no terceiro e último estado, pode também receber um pacote da rede
contendo uma mensagem cifrada a ele, e, nesse caso, a mensagem deve passar pela
decriptografia.
Figura 1. Diagrama de Estados do sensor executando o programa Hermes.
Primeiramente, a execução do Hermes inicia-se executando a função
inicializarComponentes(). Feito isso com sucesso, passa para a próxima
função, que é gerarChavePrivada(). Na sequência, se feito com sucesso, o
programa executa a função gerarChavePública(), pois depende da chave privada
gerada anteriormente. Se gerado e enviado corretamente para o componente de rádio
para distribuição, então o sensor aguarda o recebimento de uma chave pública para, aí
sim, pode gerar mensagens aleatórias, com a função criarMensagem() e
criptografá-las através da função criptografar(). Se nesse momento o sensor
receber um pacote da rede, então ele executa a função decriptografar().
X Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais
57
5. Análise de Desempenho
A primeira medida executada foi o consumo de memória ROM e RAM. Foi coletada a
utilização dos recursos de ROM e RAM do sensor para cada uma das 3 curvas elípticas
selecionadas e cada método de otimização. A Tabela 1 mostra os resultados, que estão
em kbytes.
Tabela 1. Consumo de memórias ROM e RAM para cada uma das curvas
elípticas selecionadas e cada um dos métodos de otimização do TinyECC.
Curva: secp160k1
Curva: secp160r1
Curva: secp160r2
Métodos de otimização
Consumo de ROM Consumo de RAM Consumo de ROM Consumo de RAM Consumo de ROM Consumo de RAM
Barrett Reduction
23.546
1.826
23.542
1.826
23.544
1.826
Hybrid Multiplication
22.156
1.776
22.152
1.776
22.154
1.776
Hybrid Square
22.252
1.776
22.248
1.776
22.250
1.776
Curve-Specific Optmization
22.544
1.776
22.610
1.776
22.542
1.776
Projective Coordinate
23.304
1.776
23.300
1.776
23.302
1.776
Sliding Window
22.372
3.104
22.368
3.104
22.370
3.104
Com todos
27.688
3.484
27.868
3.484
27.686
3.484
Sem nenhum
22.112
1.776
22.108
1.776
22.110
1.776
Dentre as três curvas recomendadas pela SECG, a que menos consome a
memória ROM quando todos os métodos de otimização são utilizados é a secp160r2,
representando um consumo de 57,6% do total de ROM disponível no sensor. O método
de otimização da biblioteca TinyECC que mais aumenta o consumo dessa memória é o
Barrett Reduction, preenchendo cerca de 49% do total de ROM. O método que
consumiu mais da memória RAM, por sua vez, quando todos os outros foram
desativados, foi o Sliding Window, consumindo 31% do total de RAM disponível.
O segundo passo da análise foi identificar o tempo de execução e consumo de
energia de cada uma das funções utilizadas da biblioteca TinyECC utilizando a curva
secp160r1 e cada um dos métodos de otimização.
Tanto o tempo de execução quanto o consumo de energia das funções de
inicialização e geração de chave privada mostraram-se constantes e muito pequenos,
quando comparados com os tempos das demais funções. A média de todos os tempos
observados para a função inicializarComponentes() foi de 1,926 segundos e,
para a função gerarChavePrivada(), foi de 0,018 segundos. Foi observado um
tempo de 7,891 segundos para a função de inicialização quando todos os métodos de
otimização da biblioteca TinyECC estão ativados. Não houve grandes variações para a
função responsável por gerar a chave privada.
Tabela 2. Tempo de Execução médio para 4 execuções com 95% de intervalo de
confiança, em segundos, para as funções gerarChavePublica(), criptografar() e
decriptografar().
gerarChavePublica()
criptografar()
decriptografar()
Métodos de otimização
Tempo de Execução Tempo de Execução Tempo de Execução
Barrett Reduction
42,18 ± 0,06
86,38 ± 0,13
43,45 ± 0,07
Hybrid Multiplication
41,07 ± 0,08
84,11 ± 0,15
41,87 ± 0,07
Hybrid Square
40,91 ± 0,04
65,80 ± 35,36
37,75 ± 6,05
Curve-Specific Optmization
40,41 ± 0,04
82,77 ± 0,05
41,29 ± 0,02
Projective Coordinate
7,95 ± 0,01
16,33 ± 0,01
8,78 ± 0,02
Sliding Window
34,09 ± 0,05
70,38 ± 1,08
37,49 ± 0,03
Com todos
2,93 ± 0,0
6,45 ± 0,0
4,21 ± 0,01
Sem nenhum
41,22 ± 0,05
84,43 ± 0,10
42,13 ± 0,06
58
Workshop de Trabalhos de Iniciação Científica e de Graduação (WTICG)
Para
as
funções
gerarChavePulica(),
criptografar()
e
decriptografar(), foram observadas duas quedas no tempo de execução quando
se utiliza somente o método Projective Coordinate e quando se utilizam todos os
métodos de otimização. A Tabela 2 apresenta os resultados de tempo de execução das
três funções.
Com relação ao consumo de energia, pôde-se verificar uma constante para as funções
inicializarComponentes() e gerarChavePrivada(), havendo apenas um
pico de 40 milijoules quando se utiliza todos os métodos de otimização. A Tabela 3
apresenta o consumo de energia, em milijoules, para as outras três funções do Hermes.
Tabela 3. Consumo de energia médio para 4 execuções com 95% de intervalo
de confiança, em milijoules (mJ), para as funções gerarChavePublica(),
criptografar() e decriptografar().
gerarChavePublica()
criptografar()
decriptografar()
Métodos de otimização
Consumo de Energia Consumo de Energia Consumo de Energia
Barrett Reduction
215 ± 2
439 ± 2
221 ± 1
Hybrid Multiplication
205 ± 3
422 ± 7
210 ± 4
Hybrid Square
206 ± 3
333 ± 180
196 ± 33
Curve-Specific Optmization
207 ± 2
427 ± 5
213 ± 3
Projective Coordinate
41 ± 1
84 ± 2
45 ± 0
Sliding Window
174 ± 3
361 ± 6
192 ± 3
Com todos
15 ± 0
33 ± 0
22 ± 0
Sem nenhum
205 ± 2
418 ± 6
209 ± 3
Com relação ao tempo de execução e consumo de energia, observou-se que a
função que mais consome tempo e energia foi a criptografar(), com média de
62,08 segundos e 315 milijoules nos testes executados. As funções
gerarChavePublica() e decriptografar() possuem médias de tempo de
execução muito próximas, ao redor de 32 segundos. Finalmente, as funções que menos
consomem tempo e energia são inicializarComponentes()
e
gerarChavePrivada(). A função de inicialização de componentes só consumiu
mais tempo e energia quando todos os métodos de otimização da biblioteca foram
ativados, podendo-se afirmar que, para que a execução das demais funções se torne mais
rápida, é necessário que se carregue os componentes necessários na memória, o que
demanda tempo extra de processamento dessa função.
Com relação aos métodos de otimização, o que mais reduz o tempo de execução
das funções é o Projective Coordinate, cujo principal objetivo é acelerar adição em
pontos e multiplicação em pontos escalares [LIU e NING, 2008]. O ganho maior em
relação ao tempo de execução e consumo de energia, entretanto, é quando se combinam
todos os métodos de otimização, fazendo com que, por exemplo, a função de
criptografia possa ser executada em pouco mais de 6 segundos e consuma cerca de 33
milijoules, decrescendo o tempo e consumo de energia até 90% para essa função,
segundo os dados coletados.
MARGI et al. (2010) demonstra tempo de execução de três algoritmos de
criptografia simétrica, Curupira-2, AES e SkipJack, em sensores TelosB com TinyOS
2.0.2. Os tamanhos dos blocos cifrados variaram de acordo com o algoritmo. Para o
Curupira-2, foi utilizado um bloco de 12 bytes; para o AES, um de 16 bytes; e para o
SkipJack, um bloco de 8 bytes. A Tabela 4 mostra os resultados [MARGI et al. 2010].
X Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais
59
Observamos que algoritmos simétricos gastam muito menos tempo para executar
as operações de cifragem e decifragem quando comparados aos testes feitos neste
trabalho com o algoritmo de criptografia assimétrica ECC. Com o tempo de execução da
função de criptografia do AES, o mais demorado dos três algoritmos analisados,
verifica-se uma taxa de 39,9 bytes/s. Fazendo a mesma relação com a função de
criptografia do TinyECC, quando todos os métodos de otimização estão ativados, temse a taxa de 6,35 bytes/s O desempenho da criptografia simétrica em sensores, portanto,
mostrou-se melhor do que o da assimétrica, sob as mesmas condições.
Tabela 4. Tempos de Execução de algoritmos simétricos em sensores TelosB,
retirados de MARGI et al. (2010)
Curupira-2
AES
SkipJack
Função Tempo (ms) Tempo (ms) Tempo (ms)
init
67
109
5
crypt
175
401
175
decrypt
192
476
196
6. Considerações Finais
A comparação dos resultados obtidos neste trabalho com os resultados da análise de
algoritmos de criptografia simétrica demonstra que o desempenho de funções de
criptografia em algoritmos simétricos é muito superior ao de algoritmos assimétricos,
como o ECC. Entretanto, conforme discutido na revisão bibliográfica deste trabalho, a
criptografia assimétrica resolve um problema relevante da criptografia simétrica que é o
problema da distribuição de chaves de sessão. Deste modo, ao utilizar a biblioteca
TinyECC para cifrar e decifrar chaves secretas de algoritmos simétricos, permitindo a
distribuição de chaves de modo seguro e, para proteger mensagens, utilizar-se de
algoritmos simétricos, então chega-se em uma solução ideal de criptografia para as
Redes de Sensores Sem Fio.
Em relação à existência de recursos necessarios em um sensor, conforme os
testes realizados mostraram, se se configurar a biblioteca para ser utilizada com todos os
métodos de otimização ativados, então se tem um alto consumo de memórias ROM e
RAM. Entretanto, consegue-se eficiência máxima na execução das funções de
criptografia. Desse modo, deve-se analisar cada aplicação de RSSFs, verificar quais os
requisitos de segurança e desempenho, para que a biblioteca seja configurada a fim de
ser eficiente, tanto em execução quanto no consumo de memória. Mesmo utilizando
todos os métodos, no entanto, o sensor ainda possuiu recursos para execução de outras
tarefas.
A biblioteca TinyECC atingiu o seu maior objetivo, que é prover um pacote
aberto e pronto-para-usar com operações de ECC que fossem flexíveis e facilmente
integradas em programas para redes de sensores sem fio. É muito simples ativar e
desativar métodos de otimização e escolher com qual curva elíptica deseja trabalhar. O
TinyECC é, portanto, viável para aplicação em RSSFs, principalmente, quando se
utiliza o máximo de seus recursos de otimização e quando se combina seu uso com o
uso de algoritmos de criptografia simétrica para cifragem e decifragem de mensagens.
A grande dificuldade em relação à biblioteca TinyECC está em sua versão. Os
autores da TinyECC a desenvolveram quando a versão 1.x do sistema operacional
60
Workshop de Trabalhos de Iniciação Científica e de Graduação (WTICG)
TinyOS estava disponível. Essa versão, no entanto, é muito confusa e não provê muitos
recursos para o desenvolvimento de programas para sensores. Apesar da versão atual do
TinyOS ser a 2.1.1, os autores da TinyECC não publicaram uma nova versão da
biblioteca para a nova versão do sistema operacional.
Trabalhos futuros incluem o desenvolvimento da biblioteca TinyECC para a
versão 2 ou superior do TinyOS. Como uma alternativa, pode-se escrever as funções da
biblioteca em C e disponibilizar como um pacote que pode ser utilizado por qualquer
versão do TinyOS. Posteriormente, seria interessante o desenvolvimento de um
programa que combinasse a utilização da biblioteca TinyECC para a distribuição de
chaves de sessão e um algoritmo de criptografia simétrica, como o Curupira-2. Então,
poder-se-ia mensurar os consumos de memória ROM e RAM, os tempos de execução
das funções e, adicionalmente, e também importante, o consumo de energia do sensor na
execução deste programa, para analisar a viabilidade e nível de segurança dessa solução
em aplicações reais de Redes de Sensores Sem Fio.
7. Referências
Culler, D., Estrin, D. e Srivastava, M. (2004) ―Overview of Sensor Networks‖ IEEE
Computer Magazine v. 37, n.1, p. 41-49.
D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler, ―The nesC
language: A holistic approach to networked embedded systems,‖ in PLDI’03. New
York, NY, USA: ACM, 2003, pp. 1–11.
J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister, ―System architecture
directions for networked sensors,‖ in Architectural Support for Programming
Languages and Operating Systems, 2000, pp. 93–104.
Liu, A. e Ning, P. (2007) "TinyECC: Elliptic Curve Cryptography for Sensor Networks
(Version 1.0)", http://discovery.csc.ncsu.edu/software/TinyECC/, November.
Liu, A. e Ning, P. (2008) "TinyECC: A Configurable Library for Elliptic Curve
Cryptography in Wireless Sensor Networks" In: Proceedings of the 7th International
Conference on Information Processing in Sensor Networks (IPSN 2008), SPOTS
Track, pages 245—256.
Margi, C., Simplicio, M., Barreto, P. e Carvalho, T. (2009) ―Segurança em Redes de
Sensores sem Fio‖, In: Altair Santin; Raul Ceretta Nunes; Ricardo Dahab. (Org.).
Minicursos: SBSEG 2009 / IX Simpósio Brasileiro de Segurança da Informação e de
Sistemas Computacionais. 1 ed. Porto Alegre, RS: Sociedade Brasileira de
Computação, v. , p. 149-194.
Margi, C., Oliveira, B., Sousa, G., Simplicio, M., Barreto, P., Carvalho, T., Naslund,
M., Gold, R. (2010) ―Impact of Operating Systems on Wireless Sensor Networks
(Security) Applications and Testbeds‖, aceito em IEEE ICCCN WiMAN 2010,
Zurique, Suíça.
Stallings, W. (2008) ―Criptografia e segurança de redes: Princípios e Práticas‖ 4a ed.
São Paulo: Pearson Prentice Hall, 512 p.